  |
はてなキーワード: サーバとは
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
会社で使ってるシステムが1日2回くらい停止するようになったのでベンダーに連絡。サーバとかログとか見てもらったんだけど
「わかりませんねー」「昨日ネットワークの調子が悪かったんですよね？そのせいでは？」等言われて直らず。
上司にも、ベンダーから匙を投げられた事は連絡し、仕方ないねという空気になったものの
使っている人は1日に2回も止まると大変なので改めて苦情が来る。
ここで登場したのが仕事ができる同僚。
ベンダーに連絡を取り、仕事ができる同僚が改めて「1日に2回くらい止まるんですけど、原因わかりますか？」と聞くと、ベンダーが突然「ログDBが壊れている可能性がある」などと言い出した。
お前いままでそんな事一度も言わなかっただろうが。
で、30分くらいなにか作業したらあっさり直る。
この件に限らず、別のベンダーもそう。自分にはろくに説明せず、会話もしたがらない。
酷いところだと同僚が打ち合わせに居ないと「あーじゃあ今日は打ち合わせにならないですねぇー」とか言ってくる。
おかげで「仕事ができないやつ」の完成だ。自分ひとりでは何もできない。頼んでも誰も何もやってくれず、トラブル解決能力がない。
ミスをしないとか、頼まれた仕事を完遂するとか、そういう部分だけで評価されるなら自分ひとり頑張ればなんとかなったけど
舐めらるともうどうしていいのか分からない。
かといって怒ったりすると今はコンプラ的にアウトだし。
あんまりキーボードを使わない。プログラミングするんだけど、大体はコピペで済む。後はソフトウェアキーボード出しておいて、ぽちぽちクリックして補完でなんとかなる。これだと右手でマウスを持ってるのがホームポジションだから楽。
だけど、そんなおじさんの仕事の様子を見ている若い人からは「あいつ大丈夫かよ」みたいに思われてたようで、Linuxの作業でミスってVPSのサーバのネットワークが切れたときに、気付かれる前に直そうと急いで両手のブラインドタッチでキーボード打った時は、後ろで小さなどよめきがあって、「できるんだな」って聞こえた。
できるわ！
Windows 95が出た時くらいのビル・ゲイツだって、もうプログラムは書かないってインタビューの返答の時に、「キーボードも右手しか使わない」って言ってたからな。では右利きの男子が左手でマウスを使う時は、どんなとーきだ？
最初にNapsterがあったりWinMXがあったりしてのWinnyで
Winnyの特徴は単に匿名性が高いという点のみでP2Pとしての仕組みは大したことない
そもそもWinnyとかのP2P系は非構造化P2Pと呼ばれていて適当にコネクション張りまくる仕組みだから非常に効率が悪い
この辺の効率を高めようという話もあったし、Winnyとかはそういう挙動をするんだけど
当時からちゃんと構造化させた方が効率も良くて管理しやすいということは分かりきっていて研究の最先端はそっちだった
簡単に言うと構造化P2Pの方はきっちりと管理されているので数学的に効率性が保証されている代わりに匿名性が低い
逆に非構造化P2Pは適当に良さそうな方法で効率を高めようとしているので数学的な効率性を越えることは無いが匿名性を高められる
他にも効率を重視するならBitTorrentみたいな方式もあったしWinnyはただただ違法性を高めただけだった
しかも後期になると後発のPerfectDarkとかの方が圧倒的に匿名性も高いし構造化P2Pを取り入れるなどしていて相当に強かった
P2Pの強みは中央集権的なサーバレスによるコストダウンとネットワーク負荷の低減だったわけだが
プログラマーの想像するフラットなネットワークというのはどこにもなくて
実際には非対称かつ中央集権的なネットワークが（日本の）インターネットを支えていたので
ネットワーク負荷が大きな問題になってP2Pは規制対象になった
ネットワーク負荷的な問題がなければ47氏が妄想したような著作権の方の改変がもしかしたら起きたかも知れないし
今のようなストリーミングやライブが中心の音楽業界・メディア構造になっていたかもしれない
プロバイダは本当にネットワーク負荷に困っていたのか、政治的にネットワークが規制されただけではないかという疑問は残っている
https://b.hatena.ne.jp/entry/s/qiita.com/Sicut_study/items/6238413b66e274bccd7b
深夜4時まで勉強している割には他の記事やTwitterからあんま深い事を感じないので怪しさMAXです。
もちろん書かれている流れも良いですが、増田のおススメも書こうと思う。
記事では全否定されていますがAWSを学ぶ最短はこれだと思います。
IPAのITパスポートのAWS版でこれを取得すればぼんやりとAWSの各サービスとつながりが分かります。このぼんやりとってのが重要でAWSはとにかくサービスが多いですが実際に開発すると使うのは大体限られます。もちろん記事のような流れでも良いですが、まずは全体を俯瞰できることが重要です。この資格取ればAWSへの苦手意識は持たなくなりますし、AWSのCM見て「んなわけあるか！途中端折りすぎ！」と突っ込めるようになります
次にやるのは参考書の写経です。なんでも良いですがサーバレス系の参考書だとリソースの削除も楽で良いです。AWSの公式のでも良いですが大体和訳されていません。Amplifyとかは和訳されたのもありますがバージョンアップで動かなくなったりして検索するのも面倒です。
もちろん参考書も2年前のものでも今では動かなかったりしますが、だいたいググるとメモで書いている人居るので感謝しながらマネしましょう。1冊やりきれば充分です。
また資格です。SAA。IPAなら基本情報です。正直これ取ればAWSを好きになります。でもサービスは組めません。でも苦手意識持たないのはこの業界では重要です。
正直CLFよりはだいぶ難しいですが初心者でも取れる資格なので頑張りましょう。
たぶんこれが増田の思うベストプラクティスだと思う。と言うよりSAA取ればAWSに関しては日本のエンジニアの半数より上に居れると思う。それくらい人が少ない。
ここから業務を経てSAPを取得したり、DVAやSOAの残りのアソシエイトも取って基礎を盤石にしたりとかは人それぞれだか、ひとつだけ言えるのは深夜4時まで勉強した付け焼刃のECSのコンテナとかマジで触りたくない！
コンテナとかはAWS以外の知識も要るから時間をかけて人に説明できるレベルに理解した方が良い。言いたいことはそれだけ。あとリソース削除言うけど無料枠とよほどの無茶しなきゃ金はほとんどかからないし、だいたいAWSが300クレジットくれるからどうにかなる。
自分でサービス作るなら話は別だけど、試算ツールもあるし収益と運用をちゃんと見積もるのが大事だしAWS使うと大半はリソースどうしようか考えるのがメイン。どうせあとから増やせるでしょって思うサービス程増やせない
その検索ワード、距離にして数万キロのかなたにあるサーバ上で処理して返ってきてるわけじゃん。
参照したデータベースのレコードってエクサバイトみたいなサイズでしょ？
そこからあれこれ演算して最適な結果を抽出して返すわけでしょ？
1秒以内でそれができるのかよ。マジかよ。こわい。ちょうこわい。
バーコードスキャナ→レジ→回線→数万キロのかなたにあるサーバ上のおれのカード残高情報を参照＆更新→回線→沖縄のクソ田舎にあるおれの最寄りの楽天モバイルの基地局の電波塔→おれのスマホという経路を1秒で往復するとかヤバくない？どうやってんの？
極力言動に出さないように気をつけているが、みんなどう対処しているのか。
# LGBT
LGBTであることをセールスポイントにしているタレントやコメンテーターは薄っぺらく見える。
性自認は本来人間の尊厳に関わる部分であり、商品として切り売りするものではない。それにもかかわらずセールスポイントとして売り物にする理由は、価値あるものを他に持たないからである。
彼らをテレビで観ていると、家族に失言をこぼしてしまいそうになる。
対処としては観るのをやめる。映画や小説なども、LGBTが主要人物であるものには近づかない。観ると私の中で差別感情が増幅されてしまう。
# アイドルマニア、キャバクラやホストクラブにはまっている人、音楽家・作家・漫画家のマニア
生きる活力は自らの内面から生み出すものである。他人に過度に依存する可哀想な人、意志薄弱な人たちだろう。
対処としては、彼らに近づかない。
親族に該当者がいるので、この手の話題が出ることがある。その際には「一時の息抜きにはイイネ」という肯定的なスタンスに自らを固定して会話することで、差別的な言動が出ないようにする。
ラーメン屋、町中華、一部の居酒屋は店内が汚く、客層もそれに応じて悪いのだが、それをあえて好む人たちがいる。通ぶりたい馬鹿である。
対処としては、この手合いと飲食店へ行くときには、私の方で前もって候補を決めておく。この手の馬鹿は通ぶることが出来ればなんでもいいので、エスニック料理とか駅からちょっと歩く立地の店を選ぶとスムーズに決まる。
# 他の職種を見下す人たち
研究開発部門には、たまに、マーケティング部門にマーケティングさせるよりも俺たちでマーケティングしたほうがいいとか、営業よりも俺たちのほうが売り方が分かっていると本気で言ってしまう人がいる。研究開発の人間がマーケティング・営業のプロにどうやって勝つのか、理解が難しいのだが、彼らは真顔だ。
要は思い上がりだ。付き合いきれない。
対処としては無視する。反対にしても聞き入れる人はいないし、逆に協力しても失敗するので。
プログラマであることに固執する技術者がかなりいる。勝手に固執するだけならいいが、プログラマであることになぜか特権意識を持ち、他の工程に従事する人をバカにする。
実際は、ソフトウェア開発において、プログラミングは数ある工程のたった一つでしかない。さらに、プログラミングよりも前の工程、例えば要件定義や仕様検討のほうが遥かに重要だという事実は常識である。
○私はプログラミングをそれなりに理解しているつもりである。仕事でコンパイラやインタプリタの実装経験がある。特許も取った。またAWSでサーバレスなウェブアプリケーションを実装したことがあるし、趣味で開発したAndroidアプリはDAU一万人である。
対処としては、彼らをむしろ褒めるスタンスを取ることである。率直にいって低賃金でプログラミングに従事する人がいるから会社としては儲かるという側面がある。
券面に資格情報が印字されていないので、マイナカードを持っていても見せても健康保険に加入しているかわからない。
持っている本人もわからないし、第三者も見ただけではわからない。病院の読み取り機にかざしてはじめてわかる。
はてな村の住人くらいのデジタルネイティブからは、券面に記載が無くてもスマホアプリで読み取れるとか反論があると思うが、一般人に通用する理屈ではない。
例えばSUICAでは、定期券情報をわざわざ券面に印字している。これも、チャージ額と同じように読み取り機で確認する仕様にすることも可能だっただろうし、その方が低コストだったはずだが、それでも定期券情報の印字にこだわったのは、一般に普及させるためには「見てすぐわかる」ことが必要だったのだろう。
マイナ保険証もICカード形態で普及させるのなら、券面に印字スペースを作って健康保険証情報を印字すべきだったと思う。
これは、モバイルSUICAがそうであるように、アプリになれば解決するかもしれない。
「健康保険証の確認ごとき」で暗証番号の入力が必要になるのは、ユーザーにとって利便性が悪い。
現状で暗証番号が広く受け入れられているのは、キャッシュカードとクレジットカードの一部だが、これはユーザーの金を引き出す/使うという「重要な取引きのトレードオフ」だから。
パスポートにもICチップが埋め込まれているが情報を読み取るのに暗証番号は必要ない。免許証は本籍地を見るための暗証番号を設定するが、使われていない。
とはいえ、認証なしに情報を読み取れるようになるとスキミングの問題もあるので難しいのだけど、安易に暗証番号を入力させると、病院などで盗み見られる問題が起こる可能性があって、こちらの方がユーザーにとっては重大だろう。
この問題のキモは銀行とは違って病院では暗証番号の入力を隠すことへの意識が低いところにある。
他人に教えてはいけない秘密の番号（マイナンバー）が印字されてしまっているという問題。
マイナカードがマイナンバーと個人を紐づけるためのカードだとしても、マイナンバーそのものを印字する必要があったのか。
例えば、クレジットカードでは再発行によってカード番号が変わることがあるが、それでもカード会社は個人を特定することができている。同じようにマイナンバー本体はサーバ内で管理して、券面には一時的な番号を記載する、あるいは電子データ内のみに持つようにするので良かったのではないか。
Pythonの初歩を学ぶ→機械学習のサンプル(mnistなど)を少し動かす→機械学習に興味を持つ→機械学習を学ぶ
機械学習に興味が出なかった場合、上で作ったmnist+αなコードをAWS Lambdaで動かす。javascriptを学んで、推論する画像をアップロードして、結果をwebブラウザ上で表示してみる。
この時、サーバサイドの実装に興味を持ったか、AWSの動かし方に興味を持ったか、webブラウザに表示する部分に興味を持ったか、３通りくらいいると思う。
次はその技術を使って、別のものを作ってみる。AWSなら別のAWSのマネージドサービスや、Auth0で認証系を作ってサービスを拡張してみる。CloudformationやCDKをいじってみる。
サーバサイドの実装に興味を持ったら、機械学習結果をDBに保存したり、いろんな学習モデルを実行できるAPIを作ってみる。
javascriptならリッチな見栄えのUIを目指してみる、Next.jsなりに置き換えてみる。
