よく見ると普通に作ると復数のスライドに分割する内容を単純に一枚のスライドに集約しているだけのものも多い（一枚絵の資料は除く）。
ということは、最初は普通に作り、ある程度骨子が完成したらそれぞれの内容を一枚のスライドに移動させてくれば効率的にポンチ絵スライドを量産できそう。
はてブなどではポンチ絵を馬鹿にしている人も多いけど、一般企業の民は逆に神Excelを量産していることが多く、他人のこと笑ってられないと思う。
表なのに表として読み解くことができない謎資料を投げ付けられて困惑することも多いのだ。
5年エンジニアとして務めた富士通を一昨年退職した。そろそろほとぼりも冷めたと思うので、書く。
真面目に書いている増田もいるが、僕は自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる。
■ 開発環境がだめ
まずこれがトップにくる。
本当にだめだった。多分開発させる気なんてなかったんだろうなあ。ニートでももうちょっといい環境を使っていると思う。
メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノートPCしか支給されなかった。
Macなんか認めん！iOSアプリも富士通PCで作れ！（本当にあった話）。
■ 机上環境もだめ
いろんな環境にいたが、その中でもひどかったのは、もともと生産ラインがあった場所に机を置いて事務所として使っていた場所だ。机もせまかったし、気温も暑いか寒いかのどちらかだった。
そこに協力会社を大量に押し込んで、ソフトウェアの生産ラインを作っていたのだった。つまりライン工だね！
椅子もすりきれ、キャスターもついていたらまだいい方みたいな感じだった。自腹で買ってもちこんでいる人もいた。
■ 事務室環境もだめ
電話会議をみんな四六時中している。
エンジニアが全員ヘッドセットしている異様な光景は、入社時、ここはコールセンターかと思ったほどだ。
だいたい協力会社と進捗会議しているのである。そんなに毎日電話したら、進捗するものも進捗しないだろう。
なので、ここのエンジニアはあまりコーディングをせず、もっぱら進捗管理している。僕はそのなかでもコーディングするレアな人間だったので、うるさくてしょうがなかった。でもイヤホンで音楽聞くのは禁止だった。
上長が君を呼んでいるのが聞こえなかったらどうすんの？だってさ。いや、みんなヘッドセットしてますやん。
■ 評価制度の納得感がない
評価はプロジェクトの成否にかかわらない。
じゃ、何を評価するのか。よくわからない。
一応目標は書く。達成しても評価低いときもあったし、未達でも昇格するときもあった。
数半期連続で目標達成したのに全然昇格しない時期があって、上司に問うたら、「いや〜、うちは年功序列だからね。。」だってさ。そうすると僕の目標は1年で10年分の年をとることだ。
■ 古い方法へのこだわり
社内にとある開発標準がある。
これに従えばプロジェクトは成功すると信じられている。というよりも、何かがうまくいかなかったときに「なんで開発標準に従わなかったの？」という責められ方をする。たちの悪いISOみたいなものだ。
内容は明らかに古く、ウォーターフォールのシステム開発用にしか使えない。これを無理やりモバイルアプリ開発に適用したり、Webに適用したりする。Webをウォーターフールでつくるもんだから、一度作ったら終わりの作りきりの製品になる。
工程だけでなく、品質についても言及されている。例えば試験項目の品質はいかにバグが検出されたかで測られる。
「試験してバグは1件です！」
「おかしい、もっとバグが出るはずだ！バグが出るまで試験しろ！」
■ 新しい方法・技術の導入の難しさ
開発手法にしてもアジャイルをなかなか実践できなかった。常にウォーターフォールの設計だった。承認フローが差し込めないからね。未だにアジャイルがウォーターフォールに対してどうメリットがあるのか、どう導入するのかを議論して、「なんちゃってアジャイル」（単なる細かいウォーターフォールの実践）を導入してみたりする。
技術に関しても導入は難しかった。クラウドなんて信用できない。他社のしかも、どこにあるかわからない場所になんてデータが保管できるわけがない！
■ 残業時間の評価
僕のサラリーに一番影響するのは残業時間だった。正直残業しないと生活がしんどかった。
自動化？
ふざけちゃいけない。全て手作業で時間をかけて、丹精込めてビルドするんだ。
バグを埋め込むのもいい方法だ。残業時間が増えてサラリーも増えるし、試験も楽になる！炎上させて鎮火すると、上司の評価もあがるぞ！
■ スキルと無関係の異動
本人の志向やスキルとはだいたい無関係に異動がきまる。
どう考えてもG Suiteを使えば一発でおわるのに、何番煎じかわからないアプリを作らされる。JSPで。こんなんを作りにきたんだっけ？
■ 社外技術への関心のなさ
僕はまずはGitの啓蒙から始めるのが通例だった。でもこれがまた苦労するんだ。
しかもだいたい信用してくれない。日付が入ったフォルダにgitからコピったファイルをおいて作業している。それ、Git使ってる意味は？？
■ なんちゃってフレックス
8:50から12:00がコアタイムのフレックスだった。どうしても連日深夜作業したエンジニアを朝に叩き起こしたいらしい。遅刻にはかなり厳しく、評価にもダイレクトにひびくので、朝忘れ物して5分遅れそうだな、と思うと「体調悪いです」と言って午前休をとることも多かった。そこまでして8:50に出社しても、べつに特別な業務があるわけでもない。
そこまでエンジニアの行動を縛る意味はあるんですかねー。
■ 人が均質的
なんかみんなおんなじに見えてくる。自社の文化に染まってんなって感じの。ほとんど新卒しかいないから、他社の文化なんてのはなかなか入ってこないしね。
みんな真剣なようで真剣でない。悪い意味で真面目。面白い人や尊敬できる人はあまりいなかった。
■ 個人時間のなさ
人の時間を奪うことに関して悪ではない雰囲気だった。自席にいるとすぐに呼び出されるので、どうしても仕事に集中したい場合は会議室や打ち合わせスペースを予約してそこにノートPCを持ち込むようなハックが必要だった。僕は残業時間に仕事の時間を確保していた。会社にきているのに仕事の時間を確保しないといけないとは。
会議は特に時間泥棒なんだけど、上司が率先してやるもんだから、みんな船漕いじゃってもう。みんなが船こぐような会議は必要？
難しい顔しながら居眠りするのがうまくなった。
■ 未来のほの暗さ
最近45歳以上のリストラがバズっているが、あまり未来が明るい雰囲気の会社でなかった。景気の良い部門もあまり見たことがないし、野心的なプロジェクトもあまりなかった。
個人でみても、特段給与もよくなく、昇進しないかかぎり給与はよくならないし、現状が特に良くなかった。給与サイトを見ると、平均年収は比較的高い方だが、それは残業をした場合である。最近は残業規制も厳しく、あまりもらえないんじゃないかと思う。まあ、最終的には給与だよね。
■ ちょっと追記
まさかここまでバズるとは..
消したい衝動に駆られつつもまだ残しておきます。
ここにかいたのは僕の観測範囲です。非常に大きな企業なので、もしかしたら良い環境の部署もあるかもしれません。また、僕がいた時期と今は変わっているかもしれません。
Rust
もともと今度性能を求められる野を開発する場合は Zig を検討していたが、Zig が思っていたより中長期的な開発戦略をとることに変化したことや、自分たちが作りたい製品が Erlang の分散機能を利用した仕組みということもあり、Rust に切り替えることにした。
[...]
Rust で作りたいのは Erlang/OTP の分散機能の仕組みに参加できるような Rust アプリ。つまり CPU バウンドな処理を Erlang VM や NIF (C 拡張) で行わず、Erlang VM と連携する Rust アプリに任せてしまうという仕組みだ。
簡単に言えば Erlang アプリのクラスターに、Rust アプリを参加可能にしてしまう。
ブラウザ外 WebAssembly
ブラウザでの WebAssembly は普通に利用しているが、ブラウザ外にも手を出していこうと考えている。
Cloudflare D1 や DO
Cloudflare Workers だけ動くウェブミーティングアプリを開発していきたいと考えている。気軽に安全に利用できるアプリ。
そこでのアプリ向けのデータベースには D1 を採用したい。sqlc-gen-ts-d1 が想像以上によくできているので気軽に使えるはず。
DO はロックを取るための仕組みとして便利なので、うまく使っていきたい。
sqldef
現在はマイグレーションツールとして go-migrate を利用しているが、結果的に SQL スキーマの差分メンテナンスがあまりにもツライので、 sqldef を利用する事で、楽になりたい。
pg-schema-diff も使いたいが SQLite でも利用したいので sqldef が無難そうという認識。
Electron
Cloudflare Workers だけで動くウェブミーティングアプリのデスクトップ版として Electron 版を OSS として公開したい。
WebRTC をデスクトップで利用する場合は Electron がほぼほぼ最適解になる。Cloudflare Workers でのアプリは Remix なので Remix をそのまま Eleectron にもってこれると嬉しそう。
アプリやサービスをソフトウェアエンジニアが作るときに「ここはSaaSで賄いましょう」「ここは自作しましょう」みたいな判断を迫られがちです。
プロダクトごとに背景が違うので一般論は述べにくいですが、最近の僕の気持ちはこんな感じ、というのをまとめておきます。
内製したい人たちは一定いまして
- 「ここはコア機能だし、SaaSにするとサービスクローズされて詰みますよ！」
- 「SaaSの料金はスケールで掛かってくるから、この想定ユーザ規模だと内製した方がお得ですよ」
みたいなことを言ってきます。（それは確かにその通りなんですが）
ここで一個邪悪な論点があります。
エンジニア的には「認証基盤を内製しました」とか「課金基盤を内製しました」とか「エラー監視機構を内製しました」みたいな事が言えると、SaaSを使ったって言うより将来のキャリア形成で有利と言うのがあります。
さらにCTOやCEOにとっても「わが社はここを内製しました」みたいなアピールをするのは「SaaSを組み合わせてペペッと作りました」よりかっこいいという問題があります。
技術的挑戦は福利厚生という話の一種だ
もう8年くらい前かな。会社がリモートワークを取り入れた頃に先輩からキツく言われたのは「口頭でやり取りを終えるヤツは何をやってもダメ」でした。
それはプロとして最低限のコミュニケーション水準に達してないと。
話してる当事者間でしか情報が共有されないし、当事者が忘れたら情報はなくなる。
かつては口頭以外のやり取りが面倒くさすぎて続けられない時代はあったが、それも変わった。
メーリングリストはチャットへ、ファイルサーバーは変更管理へ、コードレビューはプルリクへ
そこまで環境が整っても、人はまだ口頭に流れる。それまで培った生活習慣から抜け出すことは簡単では無い。
だからリモートで鍛えろと。
リモートワークを、単に自分が働きやすくなるためだけじゃなく、自身のコミュニケーション作法を見直す機会と捉えろと。
本当にありがたい助言だった。
口頭で情報共有されても一番重要なトピック以外はすぐに忘れ去られるのはみんな体感や経験則として持っているはずなのに、何故か口頭でコミュニケーションしたがる輩が減らないものである。
お前は一通り捲し立てれば情報共有できた気になれるのかもしれないが、こちらは何を言ってるのかさっぱりわからんので、解釈を踏まえて再確認する手間が掛かる。
チャットなどでも気を使ってくだけた口調で話しかけてくる人は多いが、くだけた口調になるほど情報のファジーさは増加するので、逆に真意を深読みする必要があったりして無駄手間が掛かる。
結局のところ、ある程度固めのプロトコルを定義しておくのが一番手堅いのではないかなと。
重度のADHDでなくても、注意力が散漫、一つのことに集中できない、
興味の対象がすぐ目移りしてしまうタイプの人間は少なくないと思う。
特にIT系のエンジニアにはその傾向が多い気がする。
自分もその一人だ。
ふと隣のハイパフォーマーな同僚をみると、やるべき1つの仕事だけに数時間ずっと没頭して、ものすごい成果をあげている。
それを見て自分もタスクにとりかかるもやる気が起きず、つい趣味のコードを書いたり文献調査をして1時間を過ごしてしまう。
隣の彼の姿と自分を重ねると、自分はなんて生産性が低いんだと辟易としてしまう。
しかし、我々はそのフィールドで勝負をしてはいけない。
1つのことをずっとやり続ける集中力なんて持ち合わせていないし、多分一生手に入れることはない。
我々の武器は、様々なことに興味を持つことだ。
そして興味をもったことに対しては、「仕事として」ではなく「遊びとして」愛をもって取り組めることだ。
だから2つルールを定めよう。
まず第一に、目の前のタスクに興味がわかない時は、他の興味が湧くコードを思う存分書くこと。
業務時間でもなりふりかまわず好きな趣味のコードを書け。飽きるまで趣味のコードを書きまくれ。
生産性でなんか負けてもいい、ただ興味と知見の広さでは絶対に負けるな。
そのうちきっと趣味のコードにも飽きてくる。そうしたら自ずと仕事のコードに興味が向いてくる。
そうなってしまえばこっちのものだ。興味を持つようになった時の集中力がすごいことは自分が一番知っているだろう。
第二に、終わらせた仕事の数を追う代わりに、趣味を含めて書いたコードの総量、学んだ知識の総量だけに着目すること。
その尺度で君のことを測れば、いま隣で猛烈にタスクに集中している隣の同僚にも匹敵するだろう。それどころか、勝りさえするだろう。
注意力散漫なADHDエンジニアへ。
目の前のタスクに興味が持てない？
じゃあそのタスクは一旦横にどけておいて、好きなコードを満足いくまで書いてしまおう。
業務時間であっても遠慮はいらない(ただバレないようにうまくやれ)。その散漫さを武器にしよう。それが我々の戦い方だ。
＜概略＞
数あるサイバー攻撃の中でも、特定の攻撃手法が既に広く世間に周知され、かつ実際に被害も頻発しているようなケースでは、当攻撃手法に関し、システムベンダーは医療機関等に対し、委託契約又は信義誠実の原則に基づく付随義務として、医療機関等が患者に対する安全管理義務を履行するために必要な情報を適時適切に提供する義務を負うと考えられる。
従って、医療情報システムに設置されたFortinet製VPN装置（CVE-2018-13379）の脆弱性を突いたサイバー事故が医療機関に発生した場合、たとえ医療機関とシステムベンダーで締結したシステム保守契約において、当リスクにかかるシステムベンダーの情報提供義務が明記されていなかったとしても、当該装置の脆弱性に関する情報提供がなされていなければ、医療機関からシステムベンダーに対し、「信義誠実の原則」違反を理由に一定の責任を問える可能性がある。
先月末で約15年程勤めた技術者派遣を辞めてメーカーの正社員に転職した。
辞めるに当たって思っていた気持ちとかを書いておくので、技術者派遣に就職・転職しようと思ってる人は是非参考にしてほしい。
ただし、以下は俺が所属していた技術者派遣会社の話と、派遣先で一緒になった他の技術者派遣会社の人から聞いた話だけなので
全てが全て当てはまるわけでは無いとだけは言っておく。
■ 辞める理由について
辞める理由は大体3個くらいあって、
- 理由1：給料が上がらない
- 理由2：正当に評価されないケースが多い
- 理由3：家族、親戚、友人から誤解される
以下でそれぞれについて説明する
■■ 理由1：給料が上がらない
もちろん技術者派遣会社にも寄るが、労働組合があっても機能していない(ただ存在があるだけ)のケースが多く、
世間がやれベースアップだ、物価高高騰してるんだから給料上げろみたいな風潮になっても
上がる給料は所属年数で上がる昇給額の数千円くらいなもの。
転職サイトとか見ると技術者派遣会社は最低保障給が比較的良い会社が多いが、
それ以上大幅に上がることは無いと思った方が良い。
■■ 理由2：正当に評価されないケースが多い
派遣先に評価者が一緒に派遣されている場合であれば多少融通は利くのだろうが、
派遣元会社から一人で派遣先に派遣されている場合だと評価者が業務内容を把握しにくいケースが多い。
どんなに派遣先企業から良い評価を頂いていて、実績として売り上げなどに貢献した数字が出ていても
それらが評価として自分に返ってくることは非常に希
なぜなら評価者は他の派遣者からも盛りに盛られた自己評価を出す一方で業務中のミスなど失敗は全て隠すので、
それらを全て信じて評定をつけていたら全員の評価が優秀になる。
そのため、自己評価の5〜7割程度しか自社からは評価されないケースが多い。
■■ 理由3：家族、親戚、友人から誤解される
これが正直一番キツかった。
技術者派遣会社は俺の知る限り全てが登録型ではなく技術者派遣会社に正規雇用された社員を派遣している。
そのため派遣先企業からすると「派遣」であっても、社会的には技術者派遣会社の「正社員」である。
しかし世の中では「派遣」というと「登録型派遣」が真っ先にイメージされ、
どこの会社にも正規雇用されていない非正規雇用だと思われる。
そのため、親族や友人と仕事の話になり、今は技術者派遣会社であることを話すと大体が哀れんだ目で見てくるか、
偉そうにも上から目線で「早く正社員になれるといいね」などとぬかされる始末。
その都度、技術者派遣は旧・特定派遣なので技術者派遣会社に正規雇用された正社員がメーカーなどに派遣されて働いているので、
社会的な肩書きは正社員の会社員であるという話をしないといけない。
そしてそこまでしっかり話してもそのうちの3割程度は理解出来ない人が多い。もちろんそれは俺の説明が悪い場合もあるが。
先日実家に帰った際、技術者派遣を辞めてメーカーに転職するという話を母親にしたところ、母親すら誤解していたようで
「ようやく正社員になれたんだね、良かったね」などと言ってきた。
技術者派遣会社に勤める前に業種の話だとかはもちろんして、正社員だから福利厚生もしっかりあるという話をしていたにも関わらず、だ。
つまり俺は親から"15年もの間非正規雇用の不安定な業種に就いている"と思われていたという事である。
さすがにこれにはガックリきた。せめて親ならばそこは把握していて欲しかった。
■ 結論
技術者派遣は理系大学でも入社、未経験者でも転職できる事が多いので、
技術系の会社で働きたいがメーカーには転職できないのでという踏み台として使うのは最適だと思う。
だが、上に挙げたようなデメリットも多いため、転職の踏み台として考えるのであれば5年程度を目安にすると良いと思う。
■ 個人的なお気持ち表明
一般的に思われがちな派遣を広めた元凶と言われている竹中平蔵氏についてだが、
真意はどうであれ少なくとも俺は竹中氏に感謝こそするが恨み辛みは1mmも無い。
技術者派遣が無ければ次の転職企業には入れなかったのは確実なので、広めてくれてありがとうという気持ちが強い。
(先日なにかの記事で派遣を広めたのは竹中氏では無いとあったが)
それよりも『「派遣」=「登録型派遣」である』
という風潮を広めたヤツ、お前が死ぬときはマジで苦しんで苦しんで苦しんで苦しんでから死んでもらいたい。
そいつには非常に強い恨みがある。お前のせいで俺は何度受けなくて良い職業差別を受けなくてはいけなかったのだ。
本当にこの風潮を広めたヤツだけは許せない。誰だかさっぱりわからんのだが。
このケース多過ぎて嫌になる
事業会社の一部門が独自Webサイトを作ろうとする
↓
デザイナーにお願いする
↓
デザイナーから「サーバはレンタルサーバー借りて」と言われる
↓
テキトーな所で借りる
↓
サイトができて公開
↓
セキュリティ上の懸念が発生する
↓
部門の担当者「セキュリティ？なんですかそれ？レンタルで借りてるから問題ないですよね？」
デザイナー「私は何も分かりません。レンタルサーバーのお問い合わせに聞いて下さい。」
レンタルサーバ「それはお客様の方で実施して頂く作業です」
担当者「できません」
デザイナー「私は何も分かりません」
担当者「情シスさんお願いします」
分散型SNSであるMastodonを「Rama」というプラットフォームを用いて実装することで、X(旧Twitter)と同等規模のアクセスをさばけるインスタンスをXの100分の1のコード量で実現することに成功したとRamaの開発者がブログで発表しました。
今回のMastodonの実装コードやRamaは記事作成時点ではまだ非公開となっており、今後徐々に公開されていく予定とのこと。2023年8月22日までにRamaのクラスターをシミュレートできるデモとドキュメントが登場し、2023年8月29日までに今回のMastodonの実装コードをオープンソース化すると述べられています。
なお、具体的なコード自体はまだ公開されていませんが、Ramaの思想やその思想をどのように今回のMastodonインスタンス構築に生かしたのかについて、元のブログで非常に詳しく解説されているので、興味がある人は確認してみてください。
「日本のIT業界、大手五大SIer本社とそのグループ会社で業界を回せるやろ。万年下請けベンダーのせいで業界のプレゼンスが低下している。万年下請けベンダーは全て廃業すれば、業界はまともになる。」とIPAコンソーシアムでアジったら炎上してお蔵入りになった。
一理ある
東京大学院工学系研究科・松尾研究室（主宰：松尾豊教授）は8月22日、「オープンソース」として18日に公開した大規模言語モデル（LLM）「Weblab-10B」について、「商用利用不可のため定義に当てはまらない」としてオープンソースの記述を削除した。
Weblab-10Bは、日本語と英語のデータセットを学習させることで学習データ量を増やし、日本語の精度を高めたモデルとしている。パラメータサイズは100億。研究目的での利用のみ認めており、商用利用は不可としている。
しかし、X（Twitter）などでは「商用利用不可ならオープンソースとはいえないのではないか」といった旨の指摘が相次いでいた。
めでたしめでたし
・論理的に物事を整理するスキル
・ビジネスの数字を理解するスキル
・業務のフローを理解するスキル
・要求を具現化するスキル
・要求を達成するために必要な機能を洗い出すスキル
40歳超完全未経験でエンジニアになるという夢。それは叶う可能性がゼロじゃないと思う。
もちろん、夢が叶わない人の方が確率的には高いと思います。
ただ、1番の問題はエンジニアになってからが本当の厳しい現実の始まりだと感じた。
まず、設計とか開発以前に基本的な業務についていけないです。
40代未経験でもエンジニアになることはできるが、それを生業としてやっていくには相当厳しいものがある。
一次「このシステム改修してよ」
二次「無理です、間に合いません」
一次「なんとかしてよ」
二次「この時期に追加要件を頂いても人も期間も足りません」
一次「じゃあいいよ！俺やるから」
→本番障害が発生しました。
品管「なぜバグが出たんですか？」
二次「一次さんに聞いてください」
一次「この話は二次も知ってるんだから二次にも責任があるだろう！！！！」
二次「いや全くありません」
一次「少しでも見たんだから共同責任だろう！」
二次「？？？？」
未だにこんなことあるんかな？
とはいえ、常識が通用しないレベルの理不尽な客はいつの時代もいるし、いるのかもな（絶望）。
Stable Diffusionなどの画像生成AIは自身の所有するマシンにインストールしてローカルで実行することが可能です。しかし、快適な画像生成に必要な「大容量のVRAMを備えたグラフィックボード」はPCパーツの中でも高価な部類に入るため、予算の都合から画像生成を諦めている人も多いはず。新たに、安価なAPUでも実用的な速度で画像を生成できたという検証結果がAI関連YouTubeチャンネル「Tech-Practice」によって報告されています。
Ryzen 5 4600Gを用いてStable Diffusionで「解像度512×512ピクセル」「ステップ数50」という設定で画像を生成した結果、画像1枚当たり約1分50秒で生成に成功したとのこと。
512×512ピクセルかぁ...
HD（1280*720）ぐらいだとどのぐらいのスピードになるのだろうか
このライブラリは、golang で保守可能でテスト可能なコードを簡単かつ楽しく作成できるデータ型と関数のセットを提供することを目的としています。 次のようなパターンが奨励されます。
- 小さくてテスト可能な純粋な関数、つまり入力にのみ依存して出力を生成し、副作用を実行しない関数を多数作成します。
- 副作用を遅延実行関数 (IO) に分離するためのヘルパーを提供します。
- 一貫した構成セットを公開して、既存の関数から新しい関数を作成する
- データ型ごとに、小さな合成関数のセットが存在します。
- これらの関数はすべてのデータ型で同じように呼び出されるため、少数の関数名を覚えるだけで済みます。
- 同じ名前の関数のセマンティクスはすべてのデータ型で一貫しています。
IBMのGo向け関数型プログラミングライブラリ。
パッと見た感じsamber/loの方が分かりやすい感じはあるかな。
日本の機械系技術者ってクソの集まりだからすぐ「日本人は投資しない」みたいに間違った主張するんだけど
一方で日本の食品系技術者は普通に働いてるんで、ちゃんと投資を受けてるし、どんどん新技術を開発してるしで、しっかり回ってるんで別に日本は技術者や研究者を軽視してるわけじゃないのよね
じゃあ何なのかっつーと
・ロボやITなど一部のオタク臭え分野は資金を私的な挑戦に横領するゴミ人格が多くて避けられてる
・真人間の多い食品・建築・自動車などはちゃんと多額の研究投資を受けている
結論としては、ゴミ技術者とかゴミ研究者が集まりやすい分野から投資が引き上げられてるだけ
これは別にアメリカでも同じことで、向こうの研究者らも「アメリカは技術に投資しない」とか言ってますからね。Google とか Amazon があってもそれ
結局こういうのって「ゴミ技術者が遊ぶために金をドブに捨ててくれる人が居ない」ってだけの話なんで、大体全部の国で言われてますね
これって国の研究力に問題があるとかではなくて「国の特定分野の技術者の人格に問題がある」ってだけの話なんで、まともに相手をする必要は無いですよ
そこに金入れるのってドブに捨てるのと同じで、100％絶対に何も出てこないからな。それをゴミ共は屁理屈で「わからない」にしたいわけ
でもね、当たり前なんだけど、真っ当に働く技術者集団と、資金を得た瞬間に遊び始めるゴミの集まりだったら「当たる確率は明確に違う」んだわ
違うから「資金を出した人間が破産する確率が違う」わけ、真面目な人に金を出した人は生き残り、ゴミに金出した奴は死ぬ
それで経済淘汰が進んで、ある国のゴミ技術者が集まりやすい産業に金を出す人間ってのはどんどん減って消えていく、日本だとそれがロボ系ってわけ
アメリカだと食品加工系の分野がゴミで、だから UberEats みたいな飯屋→家みたいなサービスが産まれる
これは本当にそうで、明らかに個人的な趣味やこだわりを製品に盛り込むエンジニアは多い。
己の業務経歴書の彩りを増やす為にキャッチーな技術を使いたがるのも広義の意味では同じだ。
マンガやアニメでそういうのが「技術者魂」みたいに美化されているのも原因だろうか。
結果としてオーバーエンジニアリングや使われもしない機能セットなどが発生し、技術的負債と化して後任のエンジニアが怨嗟の叫びを上げることになる（その頃には最初に作った人間は転職している）。
ベンチャー企業などはエンジニアが技術で遊ぶことを福利厚生の一環（＝求人戦略）としているので、余計に勘違いしたエンジニアが増えやすいという問題がある。
スライドは公開してくれないのかしら
1人で開発するためのアーキテクチャ
5人で開発するためのアーキテクチャ
30人で開発するためのアーキテクチャ
100人で開発するためのアーキテクチャ
ってそれぞれ全然違うよな。
1人で開発してるのに100人で開発するためのアーキテクチャで開発してる人多いなって思います。逆に100人なのに
5人で開発するためのアーキテクチャで開発してるところも多くてとても辛そうだなという感想です
こういう感覚は重要。
とはいえ、100人で開発みたいな状況は全力で回避するのでよくわからんけど。
リードタイム（開発、製造）
リードタイム（企画）
フロー効率
デプロイの頻度
変更失敗率
Four Key Metrics
ベロシティ
開発者のエンゲージメントや幸福度
テストカバレッジ
コード品質
信頼性
指標の改善が組織的な能力を高める
その他としては、スクラムを採用していない、開発用マシンが指定されない、という2点を譲れないポイントとして置いていた。
前者はスクラムイベントによる強制拘束時間で時間の使い方の自由度がどうしても減ること、後者は自社開発と合わせてマシンが2台になる不便さが許容できなかったため。
大きめの会社だとスキルの均一化の都合上スクラムを採用しがちだし、内部統制の都合上マシンは支給になりがちですね。
デファクトに合わせがちというところはある
「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。
なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。
HashiCorp が OSI オープンソース・ライセンス のソフトウェア (以降 OSS) 製品を MPL 2.0 から BSL 1.1 (以降 BSL) にライセンス変更して話題になっています。自社は主力製品はクローズドソース、それ以外は Apache License 2.0 で OSS として公開という戦略をとっていることもあり、 BSL について自分の考えを雑に書いておこうと思います。
かなり良いライセンスに見えます。特にミドルウェアやツールをソースコードを公開しつつ競合対策するには良さそうです。競合でなければ制限は特にないため困ることはありません。
BSL で提供している企業は「別途お金を払えば競合でも利用可能にする」という選択肢も用意しています。HashiCorp も同様です。お金で解決できるのはとても健全だと思いますので、競合もお金を払って使い続けることができます。一切のシャットアウトってわけじゃないのも良いです。
クローズドソースでサブスクリプションライセンスって、気軽に使って貰いづらいです。そのため自社の顧客は多くが大企業です。もっと中小や零細企業に使って欲しいのですが、特別価格とかは既存顧客への裏切りになるため一切やりたくないため、新規に主力製品の一部機能互換（つまり色々機能が実装されていない）版の開発 (Erlang ではなく Go で実装する)を検討しています。
ただ、このソースコード公開版を競合によいように利用されるは普通に怠いです。なので BSL は選択肢の１つとしてとても良いなと感じています。
仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。
スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか？。
システムトラブルに対し、ITエンジニアばかりチラチラ見るのは止めるべきだ。どういう業務なのか。業務内容は法律の変化などでどれぐらい変更頻度や量があるか。メインシステムとサブシステムなど、変化時の柔軟性は構築当初どの程度考えられていたか。システム構築時の想定を大きく変えた利用の仕方となり、無理に適応させていないか。
大きい・小さいという尺度は、面積や体積をもった物体同士を比較するのに使われる表現だ。そして、リリースは物体ではない。尺度とは比較できるということである。リリースという概念に直接計測可能な大小の尺度がない限りは、「何をもってリリースの大小とするか」という定義を置かないと話が進まない。われわれがリリースの大きさについて語るとき、実際に考えているのはリリースそのものの大小ではありえず、つねに何か別のものについて考えている。だからこそ「リリースが小さいとはどういうことか」と問わねばならない。
リリースの大小という共通の尺度を手に入れることができれば、「この尺度において、リリースはこの程度小さくなければわれわれには不都合だ」と言えるような条件を作ることができる。そうしてようやく「どのように小さくリリースするか」という問題設定にたどり着く。
全世界で1,000万本に迫る実売数を誇り、日本でも累計実売数100万本を突破（2023年5月時点）した大ヒットゲーム『Ghost of Tsushima (ゴースト・オブ・ツシマ) 』をはじめ、『怪盗スライ・クーパー』などで著名なゲーム制作スタジオ、Sucker Punch Productions（サッカーパンチプロダクションズ）の共同創設者であるChris Zimmermanによる、プログラミングのベストプラクティス集。
全部で21の「ルール」から成り立っており、すべてのプログラマーが知っておくべき本質的な知恵と、熟練したプログラマーにとって示唆に富む洞察を含んでいます。また、コードを書く際だけでなく、デバッグや最適化の際に有用な知識にも触れています。ゲーム領域に限らず、幅広いプログラマーを対象とした、必読のプログラミング哲学。
おもしろそう
Googleは、「Project IDX」と呼ばれる新しいクラウドベースの統合開発環境（IDE）を発表した。この新製品は、アプリケーションをより効率的に構築するためのAIツールや機能を提供することで、ソフトウェア開発者のエクスペリエンスを向上させることを目的としている。
Project IDXは、Google Cloud上に構築されたブラウザベースの開発環境であり、コード上で学習され、PaLM 2上に構築された基礎的なAIモデルであるCodeyを搭載している。
GoogleはProject IDXをVisual Studio Codeの上に構築し（Code OSSを使用）、CodeyやPaLM 2のようなAI統合に集中できるようにした。GoogleのAIプログラミング・アシスタントCodeyは、スマートなコード補完、コーディングの質問に答えるチャットボット、文脈に応じたコードの推奨を可能にする。
今回ご紹介する内容は、未経験でエンジニア就活をする際に、採用担当の方が読みたくなるようなREADMEを作成することを目的とした内容となります。
そっちかぁ...
Zoomが従業員のフルリモート勤務を中止し、オフィスへの出勤を要求していることが明らかになり波紋を呼んでいる。
これは同社がフルリモートの勤務を廃止し、同社のオフィス近くで働く従業員に対して、週に少なくとも2日のオフィスへの出勤を義務付けたというもの。同社の広報担当者はBusiness Insiderの取材に対し、従業員がチームと対話するために週2日出勤することが、同社にとって最も効果的だとコメントしている。同社は自社サイト上でさまざまなワークスタイルを提案しており、その中にはフルリモートだけでなく今回同社が導入したようなハイブリッドワークスペースも提案しているが、当のZoomですらフルリモートを断念したという事実は、今後何かにつけて引き合いに出されることは間違いない。一部の海外メディアはこの件について「Remote Work Is Dead」（リモートワークは死んだ／終焉を迎えた）などと辛辣な見出しをつけて報じるなど、ネット上では波紋が広がっている。
ふーむ
足が遅い人に、どうして君は足が遅いんだと、何かを教えて叱咤するよりも、技術を応用して巡回バスという社会システムを発明する方が、よほどエンジニアらしい行いなんじゃないかな? バスを作る力のある人を、バスを知らない足の遅い人たちの理論から救い出すことが、全員の幸せにつながる教育なのでは
普通のプログラマーでは思いつかないような、たいへん創造的な「悪いコード」を書いてしまう層は、たとえば DRY じゃないと困ることにさえ経験で気付かない時点で、いくら教えても自走できる見込みがない。残酷なようだけど、彼らの書くコードを悪い例として晒して溜飲を下げる方がより残酷なのかも
IT雇用を想定するからだいぶ可燃背の高い言葉に見えるけど、学問や芸術、ほか、それこそ陸上競技だと考えればどうかな。犬を見て犬の絵を描けないタイプの人を例に挙げて、画家としての心得を語る先生とか想像してみてください。そもそもなぜ、そんな画力の人が絵を描かなきゃならんのでしょうか
プログラミングについても、ほとんどの人は実は設計なんてできないとわかっていて、だから業界は「あなたはPGなんですから、何も設計しなくてもいいんですよ。コードを打ち込む単純作業です」ということにしたかった。それは本当は、善意だったんじゃないだろうか
まあ現実は残酷で、プログラミングに設計力が必要でなかった時なんて、これまで一度もなかったけど。プログラミングのうちコツコツ単純労働な成分(人月の神話に出てくる偶有的困難さ)は、半世紀のうちにどんどん自動化されてしまって、いまや設計しか残っていない状態になった
それこそが、下手な人の尻を叩かず、黙ってモノを作り積み上げてきた、エンジニアリングの成果だと思うんだ。彼らの動機は、救い出せる一部の人に、より抽象度の高い言語(パターンなどコード以外も含む)を提供することで、それは紆余曲折あっても、わかる人には伝承されてきて、生存バイアスで今がある
途中だいぶ省略になるけど、究極的には、たくさん作って売るという産業と雇用のイメージが、ソフトウェアという概念と本質的に矛盾することを、50年かけても覆せない人類が諸悪の根源。多くを作るより、最高のものを多くのハードウェアに乗せる方がいいに決まってるのに、無駄に作りすぎなんだ
※ 最高のものと言っても、それは世界にひとつではなく、理論上は地球人口の数と同じだけある。つまりエンドユーザーコンピューティングのこと。これが、無駄に作りすぎるべきでないことと、ぜんぜん矛盾しないのがソフトウェアの面白さだと思う。できる人は、他と違うところだけを小さく作る
ZincSearch is a search engine that does full text indexing. It is a lightweight alternative to Elasticsearch and runs using a fraction of the resources. It uses bluge as the underlying indexing library.
It is very simple and easy to operate as opposed to Elasticsearch which requires a couple dozen knobs to understand and tune which you can get up and running in 2 minutes
It is a drop-in replacement for Elasticsearch if you are just ingesting data using APIs and searching using kibana (Kibana is not supported with ZincSearch. ZincSearch provides its own UI).
ZincSearch は、全文インデックスを作成する検索エンジンです。 これは Elasticsearch の軽量な代替品であり、リソースの一部を使用して実行されます。 基盤となるインデックス作成ライブラリとして bluege を使用します。
Elasticsearch は理解して調整するために数十のノブを必要とし、2 分で立ち上げて実行できるのとは対照的に、非常にシンプルで操作が簡単です。
API を使用してデータを取り込み、kibana を使用して検索するだけの場合、これは Elasticsearch のドロップイン代替品です (Kibana は ZincSearch ではサポートされていません。ZincSearch は独自の UI を提供します)。
ZincSearch の簡単なデモについては、以下のビデオをチェックしてください。
セットアップが簡単なことがElasticsearchに対するメリットらしい
情報としては一年前に遭遇していたらしいい。
本日 2023-08-05、悲しいお知らせが入ってきました。Vim の作者 Bram Moolenaar 氏が亡くなりました。謹んでお悔やみを申し上げます。 以下は Bram Moolenaar 氏のご家族から vim_announce に送られたメッセージです。
https://groups.google.com/g/vim_announce/c/tWahca9zkt4t
親愛なる皆様へ
Bram Moolenaar が 2023年8月3日に逝去したことを、謹んでお知らせいたします。 Bram はここ数週間で急速に進行した病状に苦しんでいました。
Bram は人生の大部分を Vim に捧げ、皆様が一員である Vim コミュニティを大変誇りに思っておりました。
安らかに
SIerの管理職だった僕の経験だと
・SIerは技術力をむしろ称賛する
・けどSIerの仕事はそれだけで成立しない
・なので技術を鼻にかけてビジネスを冷笑する奴は冷笑される
というお話。
ITで大きなビジネスがしたい学生ならSIerはおすすめ。
自分で手を動かして実装するITが好きなら避けた方がいい。
ITが好きな学生さんさ、一つ忠告だけど
「この前出たオライリーの本がね」
「あれ面白いですよね！！」
みたいな「普通の」オタク会話を同僚としたいならWeb系行こう。
SIerだったら、ごく一部を除いて「なに無駄なこと頑張っちゃってんの？？」って冷笑されるだけだぞ？
マジで。
いずれにしてもそんな話でキャッキャッしてるのは20代の若手だけなので、若い内は自分が楽しいと思える方をやるべきである。
なぜ、難しいか
- 基本的に抽象的なことを扱っている上に、前提や語彙の定義があいまいなこと
- 歴史が浅いこと
- 具体例を表に書きづらいこと
DDDの落ち着き方
1. 技術や用語、概念などから、一部だけ盗む
ValueObject、Repository、Dependency Injection、テスタビリティ、ユビキタス言語、などの概念や用語だけを盗みます。
例えば、永続化するわけではなく各テーブルにamountと単位および単位に関する計算ロジックがあるなら、それを1つのドメインモデルとしてValueObjectの形でAmountモデルを作って、そこに集約させたら扱いやすいかも知れません。どうもamountに関するロジックが散らばっているが、直し方がいまいち分からないし、大勢が参加するPJだといちいち語彙の統制が取れないという時に、ValueObjectとしてAmountモデル¥を利用したらいいなと気づくことができます。
FileやIO、外部API、DBやRedis、別プロセスといった外部への通信は、だいたいレポジトリ層にまとめておくと、依存性の注入によりテスタビリティを上げられるでしょう。一旦それでいいと考えます。
「起業しました！」どしたん話聞こか〜🍄
10,000,000円でエンジェルするから株ちょっとちょうだい(30%)。ん？
有名コンサルタントの外部取締役就任
有名投資家のアドバイザリー就任
有名おじさんの就任
だれーw
経費で買われてる
・バランスボールは3日で使わなくなる
・スタンディングデスクは5日で使わなくなる
・懸垂マシーンは1時間で使わなくなる
どうだい？ウチの会社イケてるだろ？𓁹‿𓁹
社長！今、そちらの電話番号に、MFAの番号が飛んできたはずです、いつものごとく番号を言ってください！
突然ツートップの退職と
社長の知り合いの就任。あっ
OOっといったところでございます。はい、っといったところで、といったところでございます。はい？
何もしないけどとりあえず業務提携
仲が良いのでとりあえず業務提携
虚無に向かってとりあえず業務提携
大手育ちは上長の復唱しかできんのか
ワードプレスはじめましたとか、くそやばい
なんでみんなサウナそんなに好きなん？？
だれですか！？共有アカウントのパスワードを変えたのは！？んんん？
きみかわいいねー、仕事あげるかもしれないから、一回ホテル行こ。は？
Web Environment Integrity（WEI）は、ウェブサイトがクライアント（ブラウザ）のデバイスとネットワークトラフィックの真正性を評価し、偽造や安全でないインタラクションをブロックする新しいAPI提案です。例えば、この仕組みを使って、ウェブサイトは人間かボットかを判別したり、特定のデバイスの特定のブラウザが信頼できるかどうかを判断したりすることができます。ウェブサイトは認定された「attester」からトークンを取得し、改ざんできないように暗号化されたトークンを使って、クライアント情報が正当であることを確認します。
Googleによれば、このWEI提案の目的は、ウェブサイトがトラフィックを受け取るデバイスとソフトウェアの真正性を判断し、不正なオンライン活動を防止することにあります。例えば、ソーシャルメディアでの偽のエンゲージメント、フィッシング詐欺、非人間のトラフィック、多数のアカウントを乗っ取る試み、ゲームのチート行為、侵害されたデバイス、パスワードの総当たり攻撃などの問題を防止するのに役立つとされています。Googleは、この提案がプライバシーのリスクを伴わないと強調しています。
Vivaldiブラウザの開発者であるJ. Picalausa氏は、WEIを「危険だ」としています。彼は「あるエンティティが信頼できるブラウザを決定する権限を持っている場合、どのブラウザも信頼されない可能性がある」と述べています。また、Googleの提案があいまいであり、クライアントからの行動データを収集するなどの悪用の余地があるとも指摘しています。彼はさらに、WEIを実装しない選択をすることが難しく、Googleが広告市場での支配的な立場を悪用して多数のサイトに採用させる可能性も懸念しています。
Debian開発者のAurelien Jarnoは7月23日、DebianプロジェクトのRISC-V開発者向けメーリングリストに「riscv64 is now an official architecture」と題したメッセージを投稿、次期リリースの「Debian 13 "Trixie"」ではRISC-Vが正式なCPUアーキテクチャ（riscv64）としてサポートされることを明らかにした。
おっ
SQLiteの開発チームは、複数クライアントからの同時書き込みを可能にするBEGIN CONCURRENT文を実装していることを明らかにしました。
同時書き込み処理は、データベースのジャーナルモードが「wal」（Write-Ahead-log）もしくはwalを改良した「wal2」で、BEGIN CONCURRENT文を実行した場合に可能となります。
アプリケーション開発者としてはこの同時書き込み機能を活用するために、できるだけトランザクションの衝突を起こさないように配慮するべきでしょう。
SQLiteでは、各テーブルと各インデックスは個別のb-treeとして格納され、それぞれが個別のデータベースページの集合に分散されているため以下の2つが言えると説明されています。
1）異なるテーブル・セットに書き込む2つのトランザクションが衝突することはない。
2）同じテーブルまたはインデックスに書き込む2つのトランザクションが衝突するのは、キー（主キーまたはインデックス行）の値がかなり近い場合だけである。
つまりテーブルが異なればページも異なるため、衝突することはなく、同じテーブルであってもキーの値が遠ければページが異なる可能性が高い、ということのようです。
SQLite 3での同時書き込みによるアプリケーションの高速化の恩恵を受けるために、今後はこれらを可能な範囲で配慮したデータベースのスキーマや格納する値などを慎重に設計するとよさそうです。
SQLiteみたいな歴史のあるプロダクトに抜本的な機能追加ができるのすごい。
SQLiteが単体で同時書き込みをサポートするならサーバレス環境での採用が増えそう。
サーバレスに限らず、シングルホストなシステムやラズパイみたいなシングルボードコンピュータでも使い道が開ける。
京都大学などが仏教に特化した対話型AI「ブッダボットプラス」を2023年7月19日に発表した。ChatGPTの最新版でも採用する大規模言語モデル（LLM）「GPT-4」を組み込み、さまざまな悩みに宗教的観点で回答する。
マジかよブッダ最高だな
パソコンやスマートフォンなどに割り当てるインターネットの住所「IPアドレス」を管理する、アジア太平洋地域の国際団体の理事会選挙で不正行為が起きていたことが29日、関係者への取材で分かった。中国系IT企業が身元を隠し、自社の推薦候補への投票を強要する電話をかけるなどした。理事を送り込むことで団体が管理する大量のIPアドレスを獲得し、高値で売りさばくことを狙ったとみられる。
古い規格のIPアドレスは不足しており、中国やアフリカで争奪戦となっている。日本の管理団体「日本ネットワークインフォメーションセンター」（東京）の前村昌紀政策主幹は「ネットが世界的な社会インフラになった結果、関係者の性善説で成り立っていた運営の基盤が揺るがされている」と指摘。総務省データ通信課は「引き続き事態を注視する」とコメントした。
Amazon Web Services（AWS）は、サービスを外部に公開するためのパブリックなIPv4アドレスを使用する場合に、1時間あたり0.005ドルの課金を2024年2月1日から開始することを発表しました。
1時間当たり0.005ドルは1日当たりに換算すると0.12ドル、1カ月を30日とすると1カ月当たり3.6ドル。1ドル140円換算で1カ月当たり504円となります。
インターネットで広く使われているIPv4アドレスは数に限りがあり、12年以上前の2011年2月には管理団体からの配布が終了しています。
つまり、クラウド事業者やデータセンター事業者などが利用者に提供しているIPv4アドレスは、以前から事業者が所有していたか、もしくは何らかの方法で他のユーザーや事業者などから取得したものです。
つい先日、中国系IT企業がIPv4アドレスの獲得を狙って選挙で不正を働いたことが毎日新聞で報道されたように、IPv4アドレスは高値で売り買いされるものとなっています。
なんか未だにIPv6で通信できないプロバイダもあるらしい
古くから日本で着用されている上着「はんてん」を製造している宮田織物株式会社では、パンチカードを使用してデータを処理するPCが現役で使われています。そんな宮田織物のはんてん製造過程を、製品の製造過程を映像に収めるYouTubeチャンネル・プロセスXが紹介しています。
東京大学発のスタートアップ企業であるLightblue（ライトブルー）は、公開モデルとしては国内最大規模の67億パラメーターの日本語大規模言語モデルを開発し、オープンソース・ソフトウェアとして公開した。ライセンスはApache 2.0。
この言語モデルは、米モザイクML （MosaicML）が公開した多言語大規模言語モデル「MPT-7B」を基にしたもの。グーグルが開発した多言語データセット「MC4」をアレン人工知能研究所（Allen Institute for AI）がそれぞれの言語ごとに利用可能にしたサブセットの日本語部分を使って追加学習した。
Lightblueは、今回公開したモデルを法人向けに提供する。業界用語や部署特有の専門用語、慣習などに合わせて訓練・調整することで、企業や部署によって異なる要望に応じるという。加えて、自社サービスの提供も予定しているとのことだ。
サイバーエージェントのモデルより1億少ない感じなのか
モック使うときにとても重宝していた mockgen が2023年6月28日をもって読み取り専用になってしまってしまったので、いろいろ新しいリポジトリに置き換えしたのでメモ
mockgen、メンテナンス放棄されてたのか。
Update, June 2023: This repo and tool are no longer maintained. Please see go.uber.org/mock for a maintained fork instead.
2023年6月更新: このリポジトリとツールはメンテナンスされなくなりました。 代わりに、メンテナンスされたフォークについては go.uber.org/mock を参照してください。
使い続けるならuberがforkしたリポジトリを使ってねということらしい。
Organizational Decision Records とは
ADRの考えを組織の決定に適用したものが、 ODR です。 ODR を用いることで、後からでも組織の決定を確認／共有ができます。
組織改変や新しい制度の導入など、その背景や経緯を後になって知りたくなることもあるでしょう。 そのような時は、 ODR に記録されている情報を参照することで、組織の決定の背景や経緯を把握できます。
また、組織の決定に対して、賛成／反対の意見を述べる場を提供できます。 単なるログではなく、エンジニアリング組織全体で議論をしたうえで、組織の決定が可能になります。 これにより、エンジニアリング組織全体を、組織の決定に巻き込めるのです。
Organizational Decision Records の運用方法
ODR は、組織的な課題の検討時点で作成しています。
一般に、課題に対してどのような解決方法を取るのか、いくつかのソリューションを比較検討することでしょう。 その際に、 ODR を作成することで、考えるべきポイントを明確にして、課題の解決を促進できます。
ODR の作成から、組織の決定をするまでの流れは、次のようになります。
- ODR の軽量なテンプレートを使用して、決定の背景、影響、代替案、期待されるの結果などを記載する
- ODR を作成したら、エンジニアリング組織に公開して、チームメンバーにフィードバックをもらう
- フィードバックをもとに、提案内容の調整する
- チームメンバーの賛成を得たら、 ODR を承認する
時にはセンシティブな内容を含むことがあるでしょう。 その際は、 ODR を公開する前に、関係者にフィードバックをもらうことで、決定内容の調整ができます。 最終的には、全員が見られる情報として ODR を公開します。
Organizational Decision Records のメリット
ODR のメリットは ADR と同様で、組織に対してさまざまなメリットをもたらします。
- 組織の決定を記録できる
- 他の生成物と組み合わせて、全体的な組織戦略を作成できる
- 組織の決定を記録することで、組織の進化に関する展望を得られる
- ODRテンプレートを提供することで、組織の決定における思考を訓練できる
- 組織の決定をピアレビューできる
Organizational Decision Records のテンプレート:
# ODR-0001: ODRのタイトル
## Summary
ODR の概要を記載する
### Status
- [] draft
- [] proposed
- [] accepted
- [] rejected
- [] deprecated
- [] superseded
### Deciders
ODR を作成した人を記載する
## Context
### Background
ODR を作成する背景を記載する
### Problem Statement
対処すべき問題または改善すべき事項を記載する
## Solutions
課題解決のために検討したソリューションを記載する
### Alternative Solutions
代替案を記載する
## Decision
ODR の結論を記載する
## Consequences
ODR の結論によって生じる影響を記載する
## References
関連するドキュメントやリンクを記載する
コードリーディングが楽になる前提知識
私がコードを読む前に必要だと感じた前提知識は以下のものになります
- システム全体像の理解
- 使用アーキテクチャ
- サービスが担当するドメインの知識(私でいうと飲食店のテイクアウトサービを扱っているので、飲食業界の基礎的な知識ですね)
- ユースケースの理解
複雑なユースケースは図に描いてみる
コードリーディングで特に大事だと私が感じたのは、ユースケースの理解です。
複雑なユースケースの分岐はmiroなどで可視化してみるのがお勧めです。
輪読会の進め方
輪読会は、発表者が翻訳した内容を読み上げるというスタイルがベースです。 参加者は、内容を聞いて感想や疑問などを、チャットやボイスでディスカッションをします。
特に工夫をしたのは、輪読の内容をオンラインホワイトボード（Miro）を使ってモデリングをしたことです。 輪読を進めるごとに、モデリングとリファクタリングを続けて、本書のモデルを作りました。 これにより、本書から抽象的な概念を抽出するとともに、参加者の学びの相互作用が生まれるようになりました。
輪読会では、目次をツリー状にビジュアル化して、各章の関連を洗い出しました。 参加者のみんなで、各章の要素をディスカッションして、全体図を作ります。 例えるなら「本書の地図」を作るようなイメージです。
続いて、本書の構成要素を整理しました。 これにより、本書の構成を把握できて、 全体を俯瞰しながら各章を読み進めるられるようになりました。
各章を輪読しながらモブモデリングする
各章の輪読では、スピーカーが発表している内容を聞きながら、モブモデリングを行いました。
いろいろなところからマサカリが飛んでくるのはわかっているが、以前から感じていた疑問について書いてみたい。「データセンターの所在地ってやっぱり書いてはいけないのか？」である。だって、ググれば所在地は出てくるんですよ。いろいろ秘密の多いデータセンターだが、インフラ界隈での内輪受けみたいな感じになっていやしませんかね。
データセンター見学の機会は、記者としては本当にありがたいのだが、見たモノを正直に書けない、説明のために撮影できないのは、けっこうストレスだ。そもそも秘匿すべきデータセンターの所在地は昔からググれば簡単に出てくるのだ。とあるデータセンターの見学会の案内メールでは「場所は秘匿しているので、タクシーで案内する」と書かれていたのにもかかわらず、調べてみたら行き方や外見までしっかり書かれたブログが出てきて、ずっこけた経験がある。また、駅前でタクシーに乗って、「●●のデータセンターまでおねがい」と言えば、特段住所を言わなくても黙って連れて行ってくれるという笑い話もある。
巨大な建築物であるデータセンターでは、建築時も、運用時も、なにかしらの作業が発生する。機器のメンテナンス、機材の搬入などで、エンジニアや工事担当は立ち入るため、所在地を知っている関係者はけっこう多い。目隠しして、車で移動させるスパイ映画のようなことをしない限り、所在地を秘匿するのは困難。「探せば出てくるから非公開の意味はない」わけではないが、本気で物理的なテロや攻撃を目論む人にとっては比較的容易に所在地が特定されてしまう点は指摘しておきたい。
芸能事務所みたいなものかなと（本気で探せば住所はすぐ分かるが、保安上極力外部にはおおっぴらにはしない程度の温度感的な）
仕事そのものに情熱は無いので、ミッション！バリュー！ビジョン！みたいな文化とは非常に相性が悪い部分がある。
Wizは7月26日(米国時間)、「GameOverlay Vulnerability Impacts 40% of Ubuntu Workloads｜Wiz Blog」において、UbuntuのOverlayFSモジュールに複数の深刻な脆弱性があるとして、注意を呼び掛けた。この問題の影響を受けるUbuntuのバージョンがクラウドで広く普及しているため、Ubuntuユーザーの約40%がこれらの欠陥に対して脆弱であると警告している。
今回、Wizの調査によりOverlayFSに2つの脆弱性が存在することが判明した。発見された脆弱性は次のとおり。
・CVE-2023-32629(CVSSスコア値：7.8) - UbuntuカーネルにおけるOverlayFSのローカル特権昇格の脆弱性。特定の状況下でパーミッションチェックが適切に実行されないため、ローカルの攻撃者が昇格された権限を取得できる可能性がある
・CVE-2023-2640(CVSSスコア値：7.8) - UbuntuカーネルにおけるOverlayFSのローカル特権昇格の脆弱性。非特権ユーザーがマウントされたファイルに特権拡張属性を設定できる可能性があり、適切なセキュリティチェックが行われずに上位ファイルに特権拡張属性が設定されてしまう可能性がある
どちらの脆弱性も、UbuntuのOverlayFSモジュールに対する個別の変更に起因しているため、カーネル特有の脆弱性であることが報告されている。また、Ubuntuからこれらの問題を含む脆弱性に対処したセキュリティアップデートがリリースされている。Ubuntuユーザーは公開されているセキュリティアップデートを確認するとともに、必要に応じてシステムを更新することが推奨されている。
確認しないと
最近思うのは、軽量DDDとかってデザパタテクニックだけ使う連中はどうか、DDDの本質はそちらではない、と、モデリング活動をアピールする人は立派だと思ってたの、あれ実は、単に現場離れして技術的な問題がわからないけど偉そうにしたいという、アレルギー反応なだけだったのかもということ
モデルとユースケースを先に安定させようとして、本当にコードを書いていたなら、すぐに、サッとそこ完結させて単体テストでヨシにしようができないになって、体験的に依存チェーンの問題を認識できるはずなんです。そこが抜けるから、モデリングの夢物語にとって邪魔なパターンを否定したがるのかなと
軽量DDDがけしからんと言ってる人見たこと無い説。
むしろ軽量DDDをやってる人達が予防線や自虐として言ってたように見えた。
とはいえ、そういう風潮ができる程度にはモデリングが上等なものだと思われていたということではあるか。
DDD本やIDDD本でもモデリングの重要性を説いてるからそういう気持ちになるのは仕方ないのかもしれんね。
無料でワイルドカード証明書作れるようになったのか