anond:20240624084844 を読んで思ったこと。2番目以降は正直良くわからないが、一点目についてはわかりみしかない。
うちはメガベンチャーで内製アプリの開発保守をしてるんだが、新卒で採った青(水色？)のエンジニアが連続でクソ野郎でめちゃくちゃしんどかった。
■ ◯色コーダーマウント
ちょくちょく自分は◯色コーダーだって主張してくる。
こっちはお前が学生時代に取った資格の話なんて興味ねえんだよ。
センター試験の点数自慢してる社会人いるか？いねえだろ。
評価されたければ与えられたタスク以上の成果を挙げろ。
資格自慢をしたければ、社会人にふさわしい資格を取れ。
お前のガクチカなんぞ知らん。
■ コードがゴミ
競プロエンジニアといっしょに仕事したことある人なら大体頷いてくれると思うんだが、彼らの書くコードは本当にひどい。
処理がどれだけ効率的だろうが、実務においてメンテナンサビリティの無いコードはゴミだということが理解できないらしい。
しかも彼らは「コードは短くて高速なのが善」という前提を頑なに信奉しているので、注意しても聞く耳を持たない。
実験でPython触ってましたくらいの理系プログラマの方が可塑性があってよっぽど有益だ。
■ 典型的ブリリアントジャーク
PRやSlackの文面がいちいちキツく、他のチームメンバーを萎縮させることもしばしば。
「そんなこともわからないんですか」って本当に言う(しかも文面が永久に残る場所で)やつ本当にいるんだ、って驚愕した。
しまいには自分の業務と全く関係のないリポジトリにゴミPRを投げて別の部署との間で一悶着起こす始末。
流石にこれについては上長経由で苦情が来たので、コミュニケーションに問題があるって人事評価で伝えることになった。
コイツらのせいであまりにも空気が悪くなり、部署全体のミッションとして「心理的安全性を高めよう」と書かざるを得ないところまで行った、といえば影響の大きさがわかるだろうか。
最終的に二人共インフラ系の部署に移ってくれて、俺等は内心ホッとしている。同じような経緯で追放された赤コーダー二人の下で、彼らの好む"競争的"環境をさぞ楽しんでいるに違いない。
■ 自律性のなさ
彼らは与えられたタスク以上の「余計なこと」をやらない。
これはまだタスクとして振られてはいないけど、間違いなく誰かがやらないといけない事だから自分の仕事にしてしまおう、みたいな気の利くムーブができない。
先見の明に欠けるというか、たぶん、彼らの中には「上から問題が与えられ、それをクリアできたら合格」という価値観が染み付いているのだろう。
もっと悲観的に捉えると、むしろ同僚を貶めれば相対的に自分の評価が上向くと思っているので、チームメンバーへの協力を積極的に回避しているのかもしれない。
不思議なのが、この子達、出身も大学も全然違うのに上記の問題行動は共通してたんだよね。
競技プログラミングが学生の人格を歪めているのか、元々歪んだやつが競技プログラミングにハマるのかわからないけど、何らかの相関はあると確信してる。
…とはいえ、もしかすると我々は彼らにとって役不足だったのかもしれない。競技プログラミング出身者を採って上手くハンドリングできてる事例があったら教えてほしい。
いずれにせよ、うちは全社的にエンジニア採用の時に競技プログラミング実績は加味しないという方針になった(実際のところはマイナス評価点になっているらしいが)ので、このような悲しいミスマッチはもう起こらないだろう。
既存のプッシュ通知システムは、XMPPサーバーである「ejabberd」を利用して、複数クラスタで構成。AWSのAmazon EC2やAmazon RDSなど、実績のある安定したサービスを採用していたという。
リプレイス後のシステムでは、ロードバランサーには「ELB（Elastic Load Balancing）」を、コンピューティングリソースにはサーバレスの「AWS Fargate（ECS on Fargate）」を、データベースには「DynamoDB」を採用した。
Nintendo Switchがプッシュ通知システムに接続する流れは次のとおりだ。まず、ID払い出しサービスにアクセスして、プッシュ通知システム用のIDを作成する。その後、接続先振り分けサービスへアクセスし、接続する常時接続サービスのURLを取得する。そして、常時接続サービスが、Nintendo SwitchとTCPコネクションを確立、長時間接続を維持する。接続中には、HTTP/2を利用した独自プロトコルで双方向通信する。
この常時接続サービスは、NLB（Network Load Balancer）とECSサービスをひとつのUnitとして、複数のUnitに分割されている。本サービスの性能要件は、“最大1億台の同時接続”に耐えうるスケーラビリティだ。
逆に、Nintendo Switchに通知が送られる流れは次のようになる。まずネットワークサービスが、プッシュ通知システムが用意する通知送信用APIを利用して通知を送信。正常に受け付けられた通知は、メッセージキューイングサービスである「Amazon SQS」に保存される。
そして通知振り分けサービスがSQSから通知を受け取り、DynamoDB上のセッション情報を用いて、対象のNintendo Switchが接続する常時接続サービスのFargateのタスクを特定して通知を送る。最後に、通知を受け取った常時接続サービスが、対象のNintendo Switchに対して通知を届ける。
「なぜ」を「WHY」以外の4W1Hに言い換えて質問します。
例文1
「なぜ進捗が予定よりも遅れているの？」
WHATを使う：「何が遅れの要因になっているの？」
WHENを使う：「いつのきっかけから遅れ始めたの？」
例文2
「なぜその仕様になったの？」
WHATを使う：「そのソリューションにした決め手は何だったの？」
HOWを使う：「どういう経緯でその仕様に至ったの？」
WHEREを使う：「どこか参考にした情報があったの？」
例文3
「なぜルールを破ったの？」
WHATを使う：「何があなたをルール破りにさせてしまったの？」
WHEREを使う：「ルールのどういうところが守りづらかったの？」
Googleは、超高速に評価できて移植性が高い、安全に実行できる式言語「Common Expression Language」（CEL）を発表しました。
[...]CELは正にこうした要件に対応した式言語となっており、Googleは次のような特徴があるとしています。
- ナノ秒からマイクロ秒程度の高速な評価に最適化されている
- C++、Java、Goでサポートされるスタックによるポータブル性
- 何千もの適合性テストにより、スタック間での一貫した動作を保証
- 言語の拡張とサブセットをサポート
AWSは2023年に似たような用途のためにポリシー言語「Cedar」をオープンソースで公開しています。
またCELは真（True）、偽（False）、エラー（Error）、不明（Unknown）の4値論理を備えていること、SQLにシームレスに変換できることも特徴と説明されています。
特に大量のデータに対してCELを適用する場合、1つ1つのデータにCELを評価するよりも、データベースにSQLクエリを投げて処理する方が高速になるケースが考えられるとして、SQLへの変換可能性は高性能な式言語の設計における重要な要素だったとのことです。
急ぐ必要は無いんだ。20年間、ドメインのことを考え続け、技術も学んで、少しずつ実践を続ければ、誰でも、素晴らしいプロダクトを作れるようになる。「明日から現場で使えること」を追い続けていたら、20年後も「明日から現場で使えること」を追っているだろう。
時間を味方に付ける。多くの人は、急ぎ過ぎることによって、時間を敵に回している。ちょっとやってはあきらめ、ちょっとやってはこれじゃ間に合わない、ダメだと嘆き。それを繰り返している。
Blind For Businessに、2024年2月29日に、Microsoftは日本でソフトウェアエンジニアを募集しているかと質問したユーザーに対して、日本マイクロソフトは、最近、エンジニアチームの80％をリストラし、現在20人足らずしか残っておらず、アカウント・エグゼクティブ、営業担当者、マーケティング・スペシャリストだと返信が付けられていました。
この小さなエンジニアチームは、例えばAzureを使ったシステム設計など、マイクロソフトに顧客を取り込むための対外的なコンサルタント業務のみを行っていて、基本的には技術的な売り手だそうです。
株式会社ドワンゴ（本社:東京都中央区、代表取締役社長:夏野剛）は、2024年6月8日付けのニコニコインフォで公表したとおり、6月8日早朝から当社が運営する「ニコニコ」のサービス全般を利用できない状態が続いております。本障害は、ランサムウェアを含む大規模なサイバー攻撃によるものであることが確認され、現在サービスの利用を一時的に停止し、被害状況の全容把握と復旧に向け、調査と対応を進めております。
当社は、サイバー攻撃を確認後、直ちに関連するサーバーをシャットダウンするなど緊急措置を実施するとともに、対策本部を立ち上げ、被害の全容解明、原因究明およびシステムの復旧対応に総力を上げて取り組んでおります。現時点までの調査で判明した内容および今後の対応について、以下の通りご報告いたします。
ユーザーの皆様、関係者の皆様に、多大なるご迷惑とご心配をおかけしておりますことを心より深くお詫び申し上げます。
わし詳細設計書書くのやだよ(￣･ω･￣)
細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ
改修コストを下げるための設計になってることは前提だけどね。
だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書いらないわけで…
必要に応じて状態遷移図とかシーケンスとか、ER図書くのは許されるけど、日本語の文章で書かれたドキュメントなんていらん。完了条件だけくれ。そこからテストコード起こして、それで機能を満たしているか検証する。これだよ。
「どの言語を使って開発してもらってもいいです」
「ほんとですか？じゃあPythonやGo、Rustあたりを使ってサクっと開発したいんですが」
「その、GoやRustっていうのはちょっと…」（※）
「え？どの言語でも良いって言ったじゃないですか？」
「言いましたけど、そのGoやRustを扱える技術者が集まらないんです」
「それって、どの言語でもいいわけじゃなくて、技術者を集めやすい言語の中で、どれでもいいのを選んでねってことですよね？」
「ええ、そうなります」
「ちなみに開発者を集めやすい言語というのは？」
「JavaやC#になりますね」
「・・・（選択肢が狭すぎる）」
という会話を最近したんだけど、残念すぎる。集めた技術者に覚えさせればいいじゃない。どの言語でもいいなんて言うから、そう思うじゃない。
（※）話した人自体が、そもそもRustのことをそもそもご存知じゃなかった。
固定スクロールをオンまたはオフにする
- Visual Studio のメニュー バーで、[ツール]>[オプション]>[テキスト エディター]>[全般] を選びます。
- [固定スクロール] セクションで、[Group the current scopes within a scrollable region of the editor window] (エディター ウィンドウのスクロール可能な領域内で現在のスコープをグループ化する) チェックボックスをオンにします。
アプリケーション全体のテストを書くには、外部リソースに依存する部分をレポジトリとして抽象化することが大切です。 アプリケーションから外部依存をレポジトリとして分離することでロジック自体のテストが書きやすくなります。 完全なクリーンアーキテクチャを採用していなくても、外部依存要素を抽象化し、テストを簡素化するという考え方は有効です。 レポジトリの実装のテストは、実際のリソースを用いるかエミュレーターを利用するかなど、状況に応じて適切な方法を選択していきましょう。
弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。
バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。
長年にわたりISOイメージ形式で配布してきた「Ubuntu日本語Remix」ですが、Ubuntu 24.04 LTSではリリースしないことに決定しましたのでお知らせします。
理由は以下の通りです。
- 新しいインストーラー採用に伴うカスタマイズ難易度の増加
- Ubuntu 24.04 LTSから新しいインストーラーが導入され、ISOイメージのファイル構成が変更されました。この変更により、ISOイメージをカスタマイズすることが難しくなりました。
- 多言語ライブ環境の非対応化
- Ubuntu 24.04 LTSの公式ISOイメージは英語以外のライブ環境に対応しておらず、日本語ライブ環境を実現するためには大きな変更が必要となりました。
Ubuntu日本語RemixのISOイメージの主な利点は、日本語ライブ環境が使えること、およびインターネット未接続状態でも日本語のデスクトップ環境をスムーズにセットアップできることでしたが、同様の対応をUbuntu 24.04 LTSで行うことは上記の理由で困難であるため、リリースをスキップする決断に至りました。
24.10以降のバージョンについても同様となる見込みですが、ISOイメージのカスタマイズ機能が提供されるなど状況の変化により再びUbuntu日本語Remixの配布を行うことになった場合は、改めてお知らせいたします。
Windows は I/O 関連の API はぜんぶ Windows Defender や 3rd party のために filter/hook でウィルススキャナとか噛ませるフレームワークみたいになってるはずなので、TeX に限らず小さなファイルたくさん I/O する処理は全部絶望的に遅いはず（git とかもそう
Windows でも TeXLive のアップグレード作業完了。動作確認で typeset したら、絶望的に遅かった（学部時代、よくこれでレポート作成してたな...）。これだと確かに Overleaf で良いわってなる。
なぜ TeX はここまで Windows との相性が悪いのか。
ReFS (Resilient File System) でフォーマットされる DevDrive とか作ってそっちでやる、とかやるしかなさそうで、公式に npm や pip や cargo のパッケージキャッシュの読み書きする場所を DevDrive に逃す方法まで案内されてる
あとは Windows Defender そのものを無効化するとかでも似た効果は得られるはずだけどさすがにそれは危険性が高すぎるので特定のファイルツリー配下でのみ無効化できる DevDrive をつくろうということで……（パーティション増やさなくても VHD のディスクイメージ作ってマウント、もできる
旨い小料理屋に行くと、なんでも旨いし、不味い店はなんでも不味い。旨い店の亭主は味覚がちゃんとしているから、不味いものなんて出せないんだな。ソフトウェア作りもこれと同じで、あれが出来てこれが出来ないということは、本当は無いのだろうと思っている。
世の中の一部の設計論は、とにかく味の素を振れ、みたいなことを言っている気がする。それが「設計原則」だそうだ。
最近、社内外からマネジメントの相談を受けることが多くなりました。
「どうすればマネージャーになれますか？」と「どうすればマネジメントができるようになりますか？」の2つが多いです。
結論、知らんし、わからん。です。
ただ、自分なりに2つの真理があります。
1. マネジメントに最も必要なスキルは胆力。
2. 人は、自分が受けたマネジメントしか他人にできない。
色々見えるようになってきてわかったのは、マネジメントの仕事っていうのは、定量的に見るとチームのKPIの達成ですが、実際にはその達成のためにこういう感じのことをする仕事のことなんだと思う。
放置できない問題であれば、首も手も突っ込んで自分で動かす。他人の失敗が原因だったとしても。
歪みのない完璧な状態はいつだってないって前提で歪みに正面から向き合ってなんとかする。歪みを嘆くだけにしない。
思い通りに他人が動いてくれたら奇跡くらいの気持ちで全体のバランスをとる。他人が思い通りに動くと思ってるのは娘（4歳）だけで十分。
間違ったときは、「ごめん、私が悪かった」って言う。しょうもないプライドは捨てる。
厳しいことちゃんと厳しく言う。言える距離感を保つ。
部下を守る。自分の立場や周りからどう評価されるかとかは後回し。
数字と正しい言葉で話す。それっぽい雰囲気でうやむやにしない。
最後に、「どうすればマネージャーになれますか？」と「どうすればマネジメントができるようになりますか？」の2つに答えて終わります。
どうすればマネージャーになれますか？
マネージャー = 役職（ラベル）であればアサインされたらなれます。
マネージャー = マネジメントの仕事をする人であればマネジメントができるようになればなれます。
どうすればマネジメントができるようになりますか？
あなたがなりたい姿のマネージャーと一緒に働くか、経験豊富なマネージャから学ぶ機会を持って、セルフフィードバックサイクルを続ければできるようになります。
（私は今でも師匠にサウナでよく相談します）
株式会社KADOKAWA（本社：東京都千代田区、取締役 代表執行役社長 CEO：夏野剛）は、現在当社グループの複数のウェブサイトが利用できない事象が発生していることをお知らせいたします。この原因として、現時点では、当社グループが利用しているサーバーに対して、外部からの不正なアクセスが行われたことによる可能性が高いと分析しております。
お客様、お取引先様をはじめ、関係先の皆様に多大なるご心配とご迷惑をおかけし、深くお詫び申し上げます。
本件について、影響を最小限にとどめるべく、システムの保護と復旧に向けて、現在対応を進めております。現時点で判明している内容について、以下の通りご報告いたします。
1. 経緯
6月8日（土）未明より、当社グループの複数のサーバーにアクセスできない障害が発生しました。この事実を受け、データ保全のため関連するサーバーを至急シャットダウンしました。同日中に社内で分析調査を実施した範囲においては、サイバー攻撃を受けた可能性が高いと認識しております。
2. 現在の状況
現在、調査・対応を進めておりますが、現時点で「ニコニコサービス」全般、「KADOKAWAオフィシャルサイト」、「エビテン（ebten）」などで影響が発生していることを確認しております。なお、情報漏洩の有無についても調査を進めております。
３. 今後の対応
今後、外部専門家や警察などの協力を得て調査を継続し、迅速に対応を進めてまいります。より正確な影響範囲を調査・特定し、お知らせすべき新たな事実が判明しましたら、改めてお知らせいたします。
以上
オープンソースとして開発されているOLAP用データベース「DuckDB」が正式版となるバージョン1.0に到達したことが発表されました。
OLAP用のデータベースといえば、クライアント／サーバ方式の大規模なサーバアプリケーションが一般的ですが、DuckDBは、SQLiteのようにローカル環境上でシングルバイナリでローカル環境でも簡単に実行できる点が最大の特徴です。
SQLでクエリを記述すると同時に、Python、Java、Node.js、Rust、Go、C/C++、R、ODBCなどから呼び出せるAPIも備えており、クライアントアプリケーションに組み込むこともできます。
DuckDBは高速なOLAP処理を実現するために並列実行が可能なカラム型エンジンを搭載しています。
単一ファイルとして扱える独自フォーマットのデータベースファイルに加えて、CSV、Parquet、JSON形式のデータの読み書きも可能。Amazon S3のエンドポイントにも対応します。
この記事を読んで思い出した、少し前の話
ただ思い出したこと書きなぐるだけなので、内情がどうとかそういうのは知らない
http://tnaoto.hatenablog.com/entry/2019/04/09/070227
その頃俺は富士通やパナソニックの下請けで現場に入る、所謂人売りIT企業（SESって言うの？）にいて
どの現場も多かれ少なかれ酷い事はあったんだけど、富士通の現場は本当に最低だった
製造工程から参加してたんだけど、俺の主な仕事はOracleプロシージャで作られたシステム間連携処理を
富士通の用意しためちゃめちゃ使いにくいExcelフォーマットで文字にして起こすこと
円柱の図で表したテーブルを矢印と線を使って繋げて取得元テーブルを表現
取得項目は図の右に表を書いて、条件と結合は全てSQLをそのままコピーして「項目Aと項目Bを結合」って日本語に書き直してた
それを200本くらい？作る仕事。
それはまぁ酷いとは言え人売りIT企業としてはオーソドックスな仕事じゃないですか？
でもプロシージャは毎日書き変わっていて、自分がどれを設計書に起こせば良いか分からなくてさ
確認するには富士通の奴に聞かないとダメなのね
でもあいつら朝来ないんだよ、早くて11時くらい、遅いと18時とかかな。連絡無しに来ない日もあったな
そのくせ会議大好きで、日次ミーティングは絶対にやらなきゃならないってルールなんだよ
始まる時間はあいつらの思いつき。でも絶対に定時後。
もう嫌で嫌でしょうがなかったなー
結局一年半くらいやったのかな
最後は会社自体辞めて終わり
はてなにいるとキラキラしたエンジニアを良く見るけど
俺の知ってるIT業界ってこういうのなんだよね
富士通やPやHやNの下請けで、大企業の古臭いシステムを泥臭く作って、何か起きた時の言い訳のために無意味なExcelファイル量産して。
あー、もう二度と戻りたくない
声明ではAI技術のリスクとして、既存の不平等をさらに固定化したり、誤情報を拡散したりすることが挙げられているほか、自律AIシステムの制御喪失により人類滅亡の可能性があることも指摘している。
声明の発表者らは、科学界や政策立案者、一般市民からの適切な指導があれば、これらのリスクは十分に軽減できると期待している。しかし、AI企業には効果的な監視を回避する強い財政的インセンティブがあり、現行の企業統治だけではこれを変えるのには不十分であると主張している。AI企業が保有する非公開情報は膨大であり、その情報共有の義務は弱い現状も問題視している。
発表者らは声明内で、AI企業に対して以下の4つの原則に従うように要求している。
- AIリスク関連の懸念を理由とした、自社への批判を禁止する契約を結ばず、報復も行なわないこと
- 従業員が匿名でAIリスク関連の懸念を提起できるプロセスを整備すること
- オープンな批判文化を支持し、AIリスク関連の懸念を一般人や企業の取締役会、規制当局、独立組織に提起できるようにすること
- 機密情報を不必要に公開することは避けるべきだが、適切な報告プロセスが存在しない場合に公に懸念を報告しても報復措置を取らないこと
政府は、全国約１８００の地方自治体が使うＩＴシステムを共通化する方針を固めた。人口減少とともに、自治体の職員も不足してシステムの維持が困難になる恐れがあり、学校の事務など各自治体に共通する業務のシステムを統一して行政事務を効率化する。政府が６月に策定する「国・地方デジタル共通基盤に関する基本方針」に盛り込む。
都道府県や市区町村は現在、新たな業務が増えるたびに個別にシステムを構築しており、３００を超えるシステムを保有する政令市もある。今後は、政府が主導してシステムを整備し、自治体が利用する形に転換する。
１９９４年に３３０万人いた自治体の職員は２０２３年に２８０万人にまで減少した。人手不足が深刻化しており、政府のデジタル行財政改革会議によると、情報システムの担当者が１人以下の自治体は３００近くに達する。職員がさらに減れば、システムの維持や住民サービスの提供にも支障を来しかねず、「各自治体に共通する業務は、システムの統一化が望ましい」との声が上がっていた。
設計書などドキュメント類は一切作りません！テスト結果もありません！でもその代わりシステムの出来上がりは超速で価格も激安です。っていう恐ろしい地方ベンダーの存在を知った。とにかく安く早くを求める地方企業や支社などの要望とマッチして管理不能なシステムが量産されてる
2021年にO'Reilly Media, Inc.から出版された「Learning Domain-Driven Design」の待望の日本語訳『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』がついに出版されます。
2020年代に、ドメイン駆動設計を学ぶための最初の入り口としてどの本を読めば良いかは、かなり悩ましい...というのはよく言われるのですが（元祖のエバンス本はさすがにだいぶ古くなってきたし、回りくどい表現も多いし...）、そんな時におすすめできる1冊です。
2021年に原著が出版された時に買ってざっと読んでいたのですが、パート1で戦略的DDD（主にビジネス面からの分析）、パート2で戦術的DDD（主に実装面のプラクティス）、パート３でそれを使った実践の方法という流れで、それぞれのトピックに集中できるようになっています。
特に後半は現代的なプラクティスや、アーキテクチャとの関係も明示されていて、1冊で基本的な知識をざっと習得する、という目的には丁度良い構成です。
個人的にはパート1と、パート2の結びつきが大事というか、パート1でユビキタス言語と、境界づけられたコンテキストが揃ったらもう実装に行く？というのは有りますが、この辺は実装例などと比較しながら読み進めた方が良さそうです。DDD百科事典ではなく、あくまで入り口に立つための本だし、そのために必要なところと、そうじゃないところをメリハリつけられているな、という印象でした。
筆者のプレゼンテーションは、以下の3つについてお話しました。
- イテレータとは何なのか？
- Go1.23以降で加わるイテレータに関する変更について
- イテレータが作るGoのエコシステムについて
ここでは、イテレータの概要について説明しますが、さらなる詳細はGo Conference 2024でもお話する予定です（2024年5月27日現在）。
Goにもイテレータが入るのか
技術は日進月歩で進化しており、それは既存の技術についても同様です。普段仕事で使っている技術について、最新トレンドをキャッチアップしているでしょうか？
DEV UPDATEでは、すでに知られているテクノロジーに関する最新情報・トレンドについて、それを推進するベンダーの方に話してもらうイベントです。オンラインで開催しますので、手軽に聞きつつ、情報をアップデートしましょう！
第一回のテーマは「オブザーバビリティ」です。DatadogのSenior Developer Advocate、萩野 たいじさんにお話いただきます。
2024年4月下旬に、Googleが誤ってオーストラリアの年金基金UniSuperのGoogle Cloudアカウントを削除してしまったとThe Guardianが報じました。UniSuperが管理している年金の総額は日本円にしておよそ17兆2500億円。UniSuperにお金を預けている62万人が1週間以上も自分の口座にアクセスできない状況が続いたそうです。
実は、このような事態を防ぐためにでしょうか、UniSuperはふだんからクラウド上で2カ所にデータを保存しておいて、万が一どちらかがダウンしても別の場所からデータを復元できるようにしていたそうなんです。ところが、今回はアカウントそのものが削除されてしまったため、せっかく別々に保存しておいたデータが同時に消し飛ぶハメに…。
幸いUniSuperは別のプロバイダ元にもデータを保存していたため、5月2日には復旧を果たし、預金も無事だったそうです。
A.DBトランザクション後にメールを送る
同一トランザクションはあきらめ、データベースを先にコミットし、その後でメールを送る、という設計です。
メール送信でエラーになったら、データベースには書き込めているので、メールだけ再送するように仕組みを作ったりします。
B. 送信リクエストテーブルに書き出し、別プロセスで送る
一度メール送信要求をテーブルに書きだして、そこで同一トランザクションとし、別プロセスがその送信要求を取り出して、実際にメール送信するという設計です。
C. [現実解] A + ローカルキューに送る
さてここでSMTPのプロトコルについて考えてみます。もともとサーバをリレーして目的の宛先まで届く仕組みです。直接外部送信用のSMTPサーバに送ろうとするから、失敗の可能性が高まるわけです。ローカルに送ってスプーリングすればエラーの確率は、ほぼ考慮しなくても良くなります(プロセスの起動忘れか、ディスクフルのケースくらい、のレベルの違うトラブルだという点において)。さらに流量制御も比較的容易にできるようになります。
同じことがやはりキューイングの仕組みをもつアーキテクチャ全般に言えます。MQを使ってデータ送るときも、ローカルキューを作ってそこからリレーさせるのが定石のようです。
品質を担保するには、適切なアーキテクチャの選択と実装が重要となっています。これは全エンジニアに共通することでありながら、昨今はサービスの多様化により、機能の一つからシステム全体までと設計にミクロとマクロ両方の視点が求められ、その難易度も上がっております。
本カンファレンスでは、半日を通じて、ご登壇者の方々に今一度システムの基盤となるアーキテクチャの思考法や手法といった全体像から、他社が実践した具体的な構築事例といった部分像までをお話しいただくことで、アーキテクチャに対する考え方を学び直し、整理することができるカンファレンスを目指します。
ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。
本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します。自分のチェックリストからチームワーク、カプセル化から分解、API設計から単体テストまで、ソフトウエア開発の重要な課題に対する考え方やテクニックを紹介します。サンプルプロジェクトで使うコードは、Gitリポジトリの形で入手でき、試しながら学べます。
有効に機能するプロセスを選び、効果のない方法論から脱却する方法。チェックリストを使うことで、すでに持っているスキルを活用する方法。アプリケーションのバーティカルスライス（ひとつの機能をUIからバックエンドまで一通り実装したもの）を作成しデプロイすることで、分析による停滞から脱却する方法を学びます。さらに、コードの腐敗や不必要な複雑さにつながる要因を避ける方法、コードの振る舞いを変更するためのテクニック、コードの問題を迅速かつ効果的に解決する方法について解説します。
一番スムーズに進んだウェブ開発プロジェクトは、ミーティングなんて週に一時間のみ、見積もりやタスク整理もろくにしてませんでした
一番上手く行ってないプロジェクトは、作業時間の半分以上はミーティングやチャット、タスク整理や見積作成で消耗してました
不思議なものですね……（白目）