面接そのものは実際そんな大事じゃないのかなと改めて思ったりもしました。
書類からある程度ペルソナができていて、その検証作業のような気がします。
1時間やそこらで人間の深いところなんてわかんないですし、騙そうと思えばいくらでも騙せると思いますし。
IT企業の採用において、「迷ったら見送る」「採用基準は下げない」というのが鉄則みたいです。
■ スキル
- Githubアカウント見て、コード見るのが一番早くて安心感がある
- 論より証拠
- 仕事より雑に書いてたとしても、それでもレベル感は把握できる
- アーキテクチャー/テストの意識があるか
- ただ特定のアーキテクチャーへの思想が強すぎるとか、TDDを絶対視してるとかは危ないかも
- 原理主義の傾向がある人は避ける
■ コミュニケーション
- HRTの原則で行動できているか
- 有害性が高い人は真っ先に弾きたい Brilliant Jerk（優秀だが攻撃的で周りに悪影響を与える人材）は避ける
- 受動的すぎる人もなるべく避けたい
- が、エンジニア採用だと、優秀な人ほど面接の印象が受け身に見えがち
- 実績で判断するのが良いか
- 質問に対して、適切な回答が来る、というのは大事
- 質問がわかりづらいパターンもあるので、そこはふりかえる
■ カルチャーマッチ
- その人のやりたいことと会社&ポディションがマッチするか
- 担当することになるプロダクトに興味あるか
- 必須条件ではないが、あった方が本人のモチベになるので結果的には良いと思う
- 単純にノリが合いそうかどうか
- 多様性の担保も大事だが、あまり攻めすぎると早期離職や人間関係悪化が起こる
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。
TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。
■ トランザクション境界
トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。
だから、トランザクション境界を作ってDBを小さく保てば、そこに対するサービス（アプリケーション）も小さく保てるかなと。サービスが小さければその中でSQLの力を活かした素朴なコードを書いても、そこまで複雑にはならないんじゃないかなという気持ち。
トランザクション境界があると、それを超えた整合性の伝搬には非同期処理を使う必要があるなど、別の複雑さを持ち込んでしまうけど、DBが一手に担ってくれてた複雑さをどう分散させるか、そのあたりをうまくやることに今は興味がある。
■ ユビキタス言語
ユビキタス言語は、とても意識している。PdMが喋る言葉から、ドキュメントはもちろん、プログラムの中まで同じ言葉を使うようにしている。
たとえば「薬品」はプログラムの中でもそのまま「Yakuhin」となっている。バックエンドで変数名などに漢字を使うのは予期せぬ問題にぶつかりそうだから、ローマ字にしてる。ちなみに、フロントエンドでは日本語コンポーネントを使ってる。ぱっと見て理解できる漢字のすばらしさよ。
■ 小さく保つ、名前にこだわる、それで複雑さに立ち向かう
という感じで、今は、影響範囲を小さく保つことと、名前にこだわることに興味を持っている。いちどに気にする範囲を小さく保って、レイヤーを分けて、意識しておくべきロジックは凝集させて、変数や関数やモジュールの名前にこだわる。1つの関数をできるだけ小さくする。依存の向きは一方向にする。イミュータブルにする。
スタートアップ的な開発と技術的負債の話、スタートアップからの案件相談とか聞いてて思うのは、安定化・リファクタリング期間を明示的に積む経営判断をすれば済んでる話を、現場レベルで技術的負債が生まれる前に完璧なアーキテクチャを組もうみたいなアプローチをして爆散してる印象なんだよな
まあ、このあたりの話、単に経営者が技術に疎いとかそういう話ではなく、CTO的な人間がそういうマネジメント概念を持ってないケースもあり
Ryan Brewer氏は、「SaberVM（Saber仮想マシン）」を1月18日（現地時間）に発表した。
SaberVMは関数型言語のコンパイラバックエンドで、さまざまな用途での実装が可能な抽象スタックマシンであり、クロージャ変換およびホイストされたCPSコードを取り込んで実行するか、AOTがネイティブバイナリにコンパイルして実行される。
malloc/freeスタイルの内部メモリ管理システムを備えたアリーナであり、寿命が終了するとアリーナのように解放されるリージョンと、引数を受け取らず実行に失敗した命令がプログラムをクラッシュさせることなく、例外ハンドラにジャンプする例外という、2つの主要なシステムによって構成されている。
SaberVMでは、安全性、表現力、移植性、信頼性を目指しており、全体的には約半分の実装が完了しているという。
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。
影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。
コンウェイの法則
「システムを設計する組織は、その組織の構造をそっくりまねた構造のシステムを設計してしまう」という法則。
例えば、1つのソフトウェアを複数のチームが協力して作るとき、そのソフトウェアはチームと同じ数のモジュールに分割された内部構造を持つシステムとして設計されてしまう。
コンピュータ科学者メルヴィン・コンウェイ氏により提唱された。
パレートの法則
「全体の数値の８割は、全体を構成する要素のうちの２割の要素が生み出している」という法則。
イタリアの経済学者ヴィルフレド・パレートが発見した。
グッドハートの法則
「計測結果が目標になると、その計測自体が役に立たなくなる」という法則。
数値目標が重視される組織では、組織の構成員はその数値目標を達成することを優先し、本来の目的を見失い、場合によっては不正な手段に走ってしまうことに対する警鐘が込められている。
英国のエコノミストであるチャールズ・グッドハート氏により提唱された。
パーキンソンの法則
「第1法則：仕事の量は、その仕事を完成させるために与えられた時間をすべて満たすまで膨張する。第2法則：支出の額は、収入の額に達するまで膨張する」という法則。
元は英国の官僚制を観察して導かれた経験則だが、コンピュータに適用されたバリエーションとして「データ量は与えられた記憶装置のスペースを満たすまで膨張する」なども存在する。
英国の歴史学者・政治学者シリル・ノースコート・パーキンソンの著作「パーキンソンの法則：進歩の追求」で提唱された。
ブルックスの法則
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則。
フレデリック・ブルックス氏の著書「人月の神話」で提唱された。
リトルの法則
「自分が行列に並んだときに、1分待って、前に並んでいる人数を後ろに並んでいる人数で割ると、何分待つかが予測できる」という法則。
リトルの法則は、ソフトウェアの性能テストにおいて応答時間などの見積もりや改善に応用できる。ケース・ウェスタン・リザーブ大学にいたジョン・リトル（John Little）氏によって証明が発表された。
ピーターの法則
「能力主義の階級社会においては、誰もがその能力の極限まで出世してしまう。例えば有能な平社員は無能な中間管理職に出世する。そして最終的には各階層が無能な人間で埋め尽くされてしまう」という法則。
教育学者ローレンス・J・ピーター氏とレイモンド・ハル氏の共著による書籍で提唱された。
ハインリッヒの法則
「1件の重大事故の背後には、重大事故に至らなかった29件の軽微な事故が隠れており、さらにその背後には300件もの危険な状況、いわゆるヒヤリハット（ヒヤリとしたりハッとしたりする危険な状態）が隠れている」という法則。
1920年代にアメリカの損害保険会社に勤めていたハーバード・ウィリアム・ハインリッヒ氏に由来する。
ピーク・エンドの法則
「人はある出来事に対し、感情が最も高まったとき（ピーク）の印象と、最後の印象（エンド）だけで全体的な印象を判断する」という法則。
心理学・行動経済学者のダニエル・カーネマン氏が1999年に発表した論文の中で提唱された。
ホフスタッターの法則
「物事はつねに予測した以上の時間がかかるものである。あらかじめホフスタッターの法則を計算に入れていたとしても」という、複雑な作業にかかる時間は正確に見積もることができないことを示す法則。
ダグラス・ホフスタッター氏の1979年の著書「ゲーデル、エッシャー、バッハ」の中で提唱された。
Easy: 手数の少なさを重視（そのかわり覚えることが増え、特定の状況には強いが他には弱い設計になる）
Simple: 覚えることの少なさを重視（そのかわり手数が増えたり、自分で組み合わせたりしなければならない）
この二つを混ぜると設計の軸がぶれるので、分けることが重要
技術選定の審美眼 / Understanding the Spiral of Technologies - Speaker Deck
（言及いただいたので補足します）Simple と Easy は軸が違う（それぞれ対極は Complex と Hard）ので、対象が十分に小さければ両立できないわけではないのですが、多くの場合では結局トレードオフになります。二つを意識して分けないと（例えば層を分ける）、どっちつかずの設計をしてしまいがちです
翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』（オライリー・ジャパン）が明日（2024年1月24日）発売となります（電子書籍はオライリー・ジャパンのサイトでの購入となります）。
本書で取り扱われるトピックには、次のようなものがあります。
- Four Keys メトリクスの計測と可視化の実践
- アーキテクチャ適応度関数（architectural fitness functions）の考え方を用いてアーキテクチャが目的を満たしているかを検証する方法やヒント
- モジュール性成熟度指数（Modularity Maturity Index:MMI）を用いて技術的負債を計測する方法
- DevOps文化に組織が移行できているかを測るのに役立つメトリクス
- ビジネス目標と結びついた適切なKPIからソフトウェアアーキテクチャメトリクスを導く方法や実践
- メトリクスベースのフィードバックループを実践して保守性を保つ方法
Lumeの紹介ゲーム開発ひいてはクライアントサイドの開発において「クリーン」かどうかは正直けっこうどうでもよく、設計すべき一番のポイントは「制御フロー」にあります。
ところがゲーム開発の場合は、こういった特徴を一般化してフレームワークに追いやれるか? というと そういうわけでもない。
「ゲーム」と一口に言っても色々で、アクションゲーム的なものとRPG的なものではかなり中身の性格は違っているし、 ゲームでは「ドメインロジックが主」というよりもむしろ、「プロジェクト固有のViewコンポネを自前でつくっていく」ことの方にどう考えても重みがある。
ゲ開発で、そのゲーム固有の色々なものをつくる、ということは、imgタグそのものを実装する、という姿が近いとおもっている。つまり、人間に理解しやすい抽象化されたデータよりも、もっと細かくて複雑なフレーム毎の見た目の変化をプログラムしていくことになることが多い。
Viewコンポネの実装の詳細はいつも複雑なので、それを外から見るともっと抽象的で扱いやすいインターフェイスにしていく必要がある(imgタグしかり) のはゲームも別に変わらない。違うのは 部品そのものを自作することがゲーム開発の主な関心事になってくること。HTMLであれば基本は 標準化されたパーツを組み合わせて集約させたものを扱うのだけど。
「ドメインロジックとプレゼンテーションの分離」はゲームであっても普通にやっといた方が良いであろう。抽象的なデータと Viewの境界は疎結合になっていないとまじで困る。 「キャラクターのデータ」 と、「画面に適用させたい対象」との関連性は、1:1 ではないし、まだ画面には出てないけどデータを参照したい、みたいなケースは死ぬほどあるからである。 つまるところMVCが言っている「Model」というのは、遷移する状態全てではなくて、「アプリケーション固有の状態」のことだからである。
しかし、なんか強力なフレームワークとか足回りを前提とした設計パターンをあてはめることはゲームでは単に手間になる。
Viewへのマッピングの自動化はあきらめた方が生産性も保守性も柔軟性も高い。
重要なことは、MとVを分けること。それからイベント発火からの制御フローを明確にすること。
最も有名なWebアプリケーションフレームワークの1つである「Ruby on Rails」は、もともと37signals社が社内向けに開発したフレームワークでした。
現在ではGitHubやShopifyなど大規模なWebサービスを支えるRuby on Railsも、登場初期には「スケールしない」という批判にさらされ、また競合となるフレームワークが登場するなどの経緯を経ています。
こうしたRuby on Railsのこれまでを、作者であるDavid Heinemeier Hansson（以下、DHH）氏や関係者が振り返る動画「Ruby on Rails: The Documentaryが、昨年（2023年）11月に公開されました。
Ruby on Railsがどのような経緯で開発され、発展してきたのか。DHH氏やコアチームの発言によって紹介されています。この記事では、その内容をかいつまんで紹介していきましょう。
皆さんに長年ご愛顧いただいたスラドだが、残念ながらこの度終了する運びとなった。
アピリッツが OSDN を OSChina へ譲渡する際、スラドを分離して別の受け入れ先へ譲渡する対応をお願いしていたが、対応が進まないまま時が過ぎていたようだ。最近になって OSChina からスラドと OSDN を閉鎖する計画があると聞いた編集部が交渉したところ、分離してかまわないとの回答を得たのだが、日本側受け入れ先の都合が悪く、分離計画は頓挫してしまった。
スラドはしばらく更新を続けるが、1 月末にはサービスを停止する。データを保存したい方は早めに進めてほしい。
本書のテーマは「データモデリング」と「基幹系システム」です。
Web上で台頭しつつある新たなビジネスは，新たな基幹系システムを必要としています。一方，既成ビジネスでは，モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。
基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があります。そのデザイン，つまりデータモデリングがいずれの取り組みにおいてもカギですが，データモデリングが真価を発揮するには，その知識体系を現代的に仕立て直す必要があります。
本書では，「活動のシステム」と「経営管理のシステム」という線引きを導入し，2つの領域で異なる帳簿特性を踏まえて，分散／非同期／疎結合な基幹系システムのための実践的データモデルを詳説します。さらには，データモデル理論の基礎にも新たな光をあてて，論理削除，テーブル分割，履歴管理といった共通論点に解決の糸口を提供し，支持を得ているドメイン駆動設計との関係性を探究します。
2024-02-24発売か
[...]ただ、そこからどう捻れたのかわからないが、「Rustは低レベルに入門する最後のチャンスだ！」「Rustを勉強すれば低レベルを理解出来る！」という人間をTwitterで見て、さすがに舐めすぎではと思ったのでここではっきりさせておくと、お前らはRustを勉強しても意味ない。
Rustのありがたみを理解するには、CやC++を真剣に書いて、リソース管理の難しさを体験しなければいけない。あるいは、GCのある言語で難しいことをして、本来ありがたい存在であるはずのGCの挙動を理解しながらコードを書くことの不毛さを体験しなければいけない。そこまでやってはじめて、Rustを学ぶ価値が生まれてくる。彼らの言葉を借りるならば、低レベルを理解している人間にしかRustは価値ないんです。パターンマッチとか関数型のテイストだとか、そんなものが欲しいならばOCamlやScalaでもやればいいんです。わざわざこんな学習コストの糞高い言語を学ぶ価値なんかひとっつもないんです。がんばってください
FastSDCPUをノートパソコンに電源を繋いでAMD 8コアCPUターボブーストでフルスピードで計算させたらトータルでわずか19.36秒という高速っぷりw
標準のStable diffusionがいかにCPUで遅いかという事が分かってしまった。
20秒以下ならGPUなくてもそこまで困らないな・・・
ほー
パスワードの利用は、もはや時代遅れと考えられ、パスキーの利用が推奨されつつある。本記事では、パスキーへ移行することで得られるメリットや、その際の課題を解説する。
パスキーは公開鍵暗号方式の仕組みを利用している。Webサイトやアプリ、そのほかのオンラインサービスでアカウントを保護するよう、公開鍵と秘密鍵のペアが生成される。
秘密鍵は、暗号化された長い文字列としてデバイスに保存される。一方、それに対応する公開鍵は、GoogleやAppleのiCloudにあるパスワード管理システムのような、オンラインサービスのサーバーへ送信される。
ログインしようとすると、PINコードや指紋、ほかのデバイスを使ったスクリーンロックによる認証が要求される。パスワードを入力したり記憶したりする必要はなく、プロセスがより安全で利便性のよいものになる。
ログイン時には、サーバーからデバイスへ暗号化されたチャレンジが送られる。デバイスは秘密鍵でこれを復号し、サーバーへ送り返す。返信された値によって、認証に必要な秘密鍵と公開鍵のペアが正しいことが検証される。
■ パスキーの課題
[...]
・同じOSで動くデバイス間でのみパスキーを同期できる：ほかの記事で解説されているように、パスキーはOSごとに同期される。例えば、iOSデバイスとWindowsコンピューターを使っている場合、ユーザー体験は悩ましいものとなるだろう。異なるOSのデバイス間でパスキーを利用するには、QRコードを読み取ってBluetoothをONに切り替える必要がある。現行のパスワードの仕組みと比べても、さらに使い勝手は悪くなってしまう。
■ 10の原則
- (1) すべての要素を冗長化する
- (2) 自己復旧できるようにする
- (3) 調整を最小限に抑える
- (4) スケールアウトできるようにする
- (5) 分割して上限を回避する
- (6) 運用を考慮する
- (7) マネージドサービスを活用する
- (8) 用途に適したデータストアを選ぶ
- (9) 進化を見込んで設計する
- (10) ビジネスニーズを忘れない
ソフトウェアには大きく分けて2つの側面があります。気候問題の一部という側面、そして気候問題の解決 方法という側面です。
グリーンソフトウェアを開発し、普及させるためには、人材、標準、ツール、およびベストプラクティス からなる信頼できるエコシステムを構築する必要があります。まさにそれがグリーンソフトウェア財団の ミッションです。
■ 炭素
私たちは、ソフトウェアが気候問題の一部ではなく、気候問題解決のためのものになることを望んでいま す。これが、私たちがソフトウェアによる炭素排出量を削減することで気候に及ぼす負の影響を減らすこ とに重点を置いている理由です。
ソフトウェアは気候問題のソリューションにもなりえます。ソフトウェアはあらゆる産業や社会の脱炭素 化を加速させることができます。我々人類はグリーンなソフトウェアの開発とグリーン化のためのソフト ウェアの開発の両方に取り組む必要がありますが、私たちが注力するのはグリーンソフトウェアを開発す るためのエコシステムを構築することです。
グリーンソフトウェア財団は非営利組織で、ソフトウェア開発に携わる人々のために設立されました。私 たちの責務は、ソフトウェアによる排出量を削減するために開発者がすべき行動の正解を与えることです 。
■ 削減
私たちは削減に注力しています。相殺ではありません。大気中に排出されなかった1グラムの炭素と、相殺 された1グラムの炭素は同じではありません。明らかに望ましいのはまずに炭素を排出しないことです。
削減することは、相殺することよりも困難です。それは必然的に、より多くのリスクと投資を伴います。 リスクと軽減し投資へのインセンティブを増すためには、人材、標準、ツール、およびベストプラクティ スからなるソフトウェアの炭素排出量削減のためのエコシステムを構築する必要があります。財団のミッ ションは、そのエコシステムを育てることです。
■ 活動
私たちはソフトウェアの炭素排出量を削減する方法は次の3つだけだと考えています。
- 利用する物理的なリソースを減らす
- 利用するエネルギーを減らす
- エネルギーをよりインテリジェントに利用する
エネルギーをよりインテリジェントに利用するということは、より低炭素のエネルギー源を消費するか、 低炭素な未来への移行に資するように電力を消費することを意味します。
ソフトウェアの炭素排出量を削減するためにできることはすべて、上記の1つ以上のカテゴリーに該当しま す。財団のミッションは、ソフトウェア業界全体でこの3つがより多く行われるようにすることです。
恥ずかしながら、「グリーンソフトウェア」という言葉自体知らなかった。
調べてみると、Green Software Foundation なる団体があり、そのサイトによると、グリーンソフトウェアとは温室効果ガスの排出を削減するソフトウェアのことらしい。
正直、「温室効果ガスの排出を削減するソフトウェア」と言われても、リソース使用を抑えた作りのソフトウェア？ 富豪的プログラミングとは相容れない？ くらいしか考えが浮かばないのだが、これからこの言葉が流行ったりするのだろうか。
1️⃣ コードをより詳細化するコメント(lower-level comment)
2️⃣ コードをより抽象化するコメント(higher-level comment)
どちらも必要なコメントとしつつ、本書では後者のコメントをより重視しています。
1️⃣ コードを詳細化するコメント(lower-level comment)
変数名などに残すタイプのコメントで、宣言した対象の単位や境界値、null許容などの詳細を明示することで、コードの正確性を高めます。こちらのタイプのコメントも必要ではあるが、命名でカバーできる範囲が広く必ずしもコメントが必要ではないタイプになります。コードの実装詳細の説明もこちらのタイプに属すると思います。
2️⃣ コードを抽象化するコメント(higher-level comment)
主にクラスやメソッドなどのインターフェイスに残すタイプのコメントで、コードの直感性を高めます。インターフェイスを切る作業はコードを抽象化する作業ですが、命名などで伝えきれない抽象化された内容を自然言語でコメントとして補足し、直感性を強化します。抽象化の精度について本書では、「メソッドの利用者がそのメソッドの実装詳細を読まないといけない状態は利用者のコードリーディング時間を無駄に生み出しており、インターフェイスの果たす役割である抽象化に失敗している」と述べています。もっともなことですが、個人的には普段各レイヤーを縦横無尽にコードジャンプして色んな実装詳細を結局読んでいるため耳が痛い話でした。
良い抽象化が行われているインターフェイスには必ずコメントが必要になります。 良い抽象化を「複雑な実装詳細が隠蔽されてシンプルなインターフェイスが提供されていること」であるとした時、その抽象化を説明する手段として「コード」だけを用いると具体的かつ詳細的になりすぎて説明が不足します。言い換えると、命名だけで支えられるインターフェイスは、その抽象化が弱いことを示していると言えるでしょう。
本書では、自然言語を利用できる「コメント」が最も抽象化を体現できる手段と捉えて、コードを書き始める前に先にコメントを書く「コメントファーストアプローチ」を採用することで、抽象化の具合を点検し、より良いシステムデザインを導くことができると主張しています。[...]
【近況報告】
ご無沙汰してます。小林です。
しばらく発信を控えていましたが、近況についてご報告させてください。
実は、昨年8月頃にprimeNumber社の役員を急遽退任することとなりました。
ここで退任の理由を記載するのは控えますが、troccoの生みの親として本気で向き合ってきた結果、このような形となり無念です。
何よりも、私の作ったプロダクトをご愛顧いただいているお客様に、本当に申し訳なく思っております。
また、私が同社時代に立ち上げた勉強会 #DataEngineeringStudy についても手を離さなければいけなくなりました。
データ人材の育成には人一倍熱い想いを持っていたのですが、とても悔しいです。
いつもご視聴・ご参加いただいていた皆様には、深くお詫び申し上げます。
（勉強会自体は私抜きでまだ続けているみたいですが…）
そんな私ですが、今後はデータテック系のプロダクトを再び1人で作っていこうと思って地道に仕込んでます！
そのためにも一度データエンジニアとして現場に戻りたいと思い、現在はフリーでデータテック関連の開発やアドバイザリーもさせていただいていおります。
最近はもっぱらdbt触ったり、PdM+開発セットでのご支援もしてます。
（お仕事いただける方は是非DMください笑）
そして #DataEngineeringStudy はこのような形となりましたが、今後もデータエンジニアを目指す方へのご支援についても、熱い想いを持って続けていきたいと考えてますのでご期待ください。
辛い時期も長かったですが、現在は前向きに頑張っています。
そんな私を励ましていただける方、データテックについて語り合いたい方、（お仕事いただける方笑、）是非ご飯・飲みに誘ってください！
リファクタリングをプロジェクトとしてやったことありますけど、知見としてはリファクタリングをプロジェクトとしてやってはいけない、コードの品質で本当に困っていても、全てを諦めてそのまま運用し、仮に十分な工数が取れるなら品質の知見を活かして作り直したほうがよい、というのが得られました。
作り直した方が「早い」のではなく、現状塩漬け以外は不幸な未来しかない（ので動いている限り無視する、どうしようもなくなったら作り直す）、というかなり悲観的なやつですね。
「Object-Oriented Conference」は、オブジェクト指向についてあれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのカンファレンスです。
オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。
Object-Oriented Conference ではプログラミング言語の縛りを超えて、オブジェクト指向に関連するセッションであればなんでも OK！
セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。
オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください！
動画配信してくれるかな？
JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。
典型例として、最近メーカーで多いのが、デリバリーの高速化・高頻度化対応の阻害です。
[...]
しかし、品質保証部門が、その変化に対応できずに、旧来のウォーターフォールプロセスを実質的に強制するような、長大な時間・コストを要する品質保証を強制し続けて、開発アプローチの改革を困難にしてしまう事例が、JTCにて今でも普通に見受けられます。
[...]さらにプロダクトの品質も低下させます。必要最低限の有限な開発リソース（コスト、時間、人）を、重厚長大な品質保証対応で浪費させて、本当に必要な品質の確保・保証のためのリソースを不足させてしまうためです。これは品質の向上・保証のために膨大なリソースと時間の投入を強制しているのに、逆に品質を悪化させているという、いびつな構図を生み出します。
求められる品質が大きく変わり、それに応じて開発の体制やプロセスの改革が求められているのに、権力を持った旧来の品質保証部門が改革をブロックしている状態は「品質保証部門の老害化」というべきものです。
プロダクトへの価値貢献ではなく、旧来のプロセスの権威化で自分たちの存在価値を確保している
過去の実績に基づいて構築した品質保証プロセスをトップダウンで守らせ続けることで、自分たちの影響力・権力を維持する傾向です。
一方で「今の自分達がこれからのプロダクトへの価値貢献に貢献できているか」という責任からは逃避します。
また、旧来の品質保証プロセスを、最新のプロダクト状況に合わせて改善することは、自分たちの能力不足を隠すために、暗に抵抗します。
本質的な品質理解を行わなず、旧来のメトリクスの数字で品質を判断する
ソフトウェアの品質が妥当か、本質的な判断を行わず、旧来のメトリクスの数字が基準以上かで品質判断する傾向です。
この傾向でありがたられるメトリクスの定番としては、テストカバレッジ、テスト密度、バグ密度、レビュー密度、レビュー指摘密度などがあります。
例えば、本質的にテスト設計が適切か判断できないため、テスト密度やバグ密度の数字が基準を満たしているかでテスト品質の判断を確定します。
プロダクトバリデーションを放棄して、プロセスバリデーションに偏重する
能力不足により、本質的に必要な品質の確保・保証（プロダクトバリデーション）に手を出せない状態です。かわりに、旧来のプロセスルール（ドキュメントテンプレート、構成管理、レビュー量、承認プロセスなど）の遵守をもって品質保証の判断を行う傾向を強めます。
能動的な品質理解を行わず、受け身で品質を判断する
能力不足により、自立して主体的に品質を評価できない傾向です。
自力で評価できないリカバリとして、自分たちが品質を理解できるまでの説明責任を、開発部門に負わせます。そこでは自分たちの能力不足で理解できないものは、開発部門の説明責任の不備に責任転化します。
開発のリードタイム高速化による品質改善を評価しない。品質ゲートによるバグゼロ志向に傾倒する
時間をかけて（テストやレビューを増やす等）品質を改善するアプローチしかとれないという傾向です。
ビジネスやユーザにとっての品質をリードせず、内向きの品質のみを扱う
ユーザの要求を満たしたり、ビジネスに成功したりするのに必要な品質を見出して、その実現のために開発をリードするアプローチを取らないという傾向です。代わりに、プロセス定義の合致性や、開発部門が検出した不具合の解消、インシデント対応といった、品質要求の変化の影響を受けない妥当性確認・検証に閉じこもります。
実務書には、こうすべきだという著者の主張には賛同できなくとも、読み進むうちに、著者がその考えに至った背景、状況、問題認識がぐっと迫ってくる本がある。一方で、主張だけが宙に浮いていて、著者がどんな状況と格闘してきたのかさっぱり見えない本もある。たぶん、格闘してないんだろう。
ハードル上げてきたな。
この御仁の美しくないところは「自分が一番優れている」と言い切るのではなく、他者を貶めることで自分の価値を持ち上げようとする卑屈な虚栄心にある。
技術者としてはともかく人間性に関しては...であるな。
マイクロサービスの苦労話を聞くほど、APIファーストじゃなくて必要なのはDBファーストだよなって思う。トランザクションでどこまでのデータを一緒に扱いたいか、データの更新頻度とか。裏のデータベースにある内容を後から取り出したいと追加するのは簡単。後から境界を跨ぐのは困難。
データベースを隠すべき実装詳細と見るのか、アプリケーションから見た時の外部システムと見るのか、という視点の違いだと思う。
まあヘキサゴナルアーキテクチャも永続化のレイヤーは外にいるので「APIファースト」と言いつつDBファースト設計するのは両立する。
本を書きました。設計本ですが、設計のプロセスや手法ではなく、どんな基幹系システムを実現できればステキと思うかという点に重点をおいた本です。
プロセスや手法は、もういいんです。必要でないということはありませんが、過剰です。
入門書ではありませんが、あまり予備知識なく読めるよう工夫したので、みなさん、是非お読みください。
基幹系システム、それに「設計する」ということに対するイメージを変えて頂けるのではないかと思います。
本書のテーマは「データモデリング」と「基幹系システム」です。
Web上で台頭しつつある新たなビジネスは、新たな基幹系システムを必要としています。一方、既成ビジネスでは、モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。
基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があります。そのデザイン、つまりデータモデリングがいずれの取り組みにおいてもカギですが、データモデリングが真価を発揮するには、その知識体系を現代的に仕立て直す必要があります。
本書では、「活動のシステム」と「経営管理のシステム」という線引きを導入し、2つの領域で異なる帳簿特性を踏まえて、分散／非同期／疎結合な基幹系システムのための実践的データモデルを詳説します。さらには、データモデル理論の基礎にも新たな光をあてて、論理削除、テーブル分割、履歴管理といった共通論点に解決の糸口を提供し、支持を得ているドメイン駆動設計との関係性を探究します。
どの言語を使ってるとかで侮る風潮未だに残ってる気がするんですが、もうそろそろやめません？というのが最近の気持ちです。
Insomnia は、オープンソースの API クライアントです。API 通信を GUI で直感的に検証・保存できる、というのが最も基本的な機能です。似たようなツールだと Postman などが有名だと思います。
Insomnia は一般的な REST API だけでなく、GraphQL や gRPC の API にも対応したツールです。JX通信社では、NewsDigest や FASTALERT などのサービスで GraphQL を活用しているため、GraphQL にネイティブ対応しているのは非常に便利です。
過去にブログシステムを自作したときは「Webで食っていくならブログぐらいは自作してあるべき」と考えていたらしいです。そんな感じのことは今もほんのり思いつつも、実際に自作するとなると作るべき機能が山ほどある（参考: The Surprisingly High Table Stakes of Modern Blogs）わけだし、無理にしょぼいサイトを作るぐらいならば素直にはてなブログを使ったほうが良いだろうな、という気持ちです。はてなブログは機能が超充実していて普通にすごい。
と言いつつも、自分のサイトの一部としてブログをホストしていること自体が記事を書くモチベーションにつながっていたりして、人間の感情は複雑だなぁと思っています。
アプリ自体は先述した通りRails製で、何かをすごく工夫している点はないです（強いて言えばルーティングぐらい）。デプロイはVPS上にHashicorp Nomadを使ってやっていて、こちらも何かしら特別な仕掛けがあるわけでもなし。Nomadは何もしなくてもすてきなコンソールがついてきてよい。
半導体業界の変化の年
上述したような半導体業界の動き、という意味では、2024年にはさらに異なる視点の変化もあります。
今年はIntelの新世代CPUであるMeteor Lake（そしてその後継となるArrow Lake）や、AMDのZen 5のような、10～20パーセント近い大きな性能ジャンプが生じるプロセッサの登場が予定されています。もちろんあまりにも大きなジャンプは「既存の製品が売れなくなる」という結果をもたらすため、ある程度は「手加減された」変化になる可能性はあるものの、この10年ほどの「CPUのクロック周波数やクロックあたりの性能はそこまで伸びない、マルチコアによって性能を伸ばす」という展開とは異質な変化が起きる年であると言えるでしょう。
さらに、いわゆるx64 CPUだけでなく、ArmとRISC-VベースのCPUも大きく性能を伸ばしてきています。Windows 10の終焉と併せて、ここから2-3年の間は業界地図が大きく変化していくことになるでしょう。また、vRANブーストのような「特定目的向けCPU」というものも広がっていくことになります。
Pagefind は、静的サイト向けの全文検索エンジンと UI ライブラリです。Cloud CMS を提供している CloudCannon 社により開発されています。
特定のフレームワークに依存しない JavaScript ライブラリとして実装されており、静的サイトジェネレーターで生成された HTML ファイルに対して検索機能を追加できます。追加するコードの量も少なく、簡単に検索機能を実装できます。
興味深い
クリーンアーキテクチャのことで「DBを入れ替えることが無い」という話がよくあるけど、モバイルアプリだと無料でローカル、有料でリモートのデータストアを利用することがあるよね。
それはサービスのバックエンドの部分ではDBを入れ替えることは現実的に考えにくいという話で、アプリ側ではそういうニーズがあるんです！ というなら、それならそれを考慮して設計しましょうという話にしかならないのだ。
要するに思考停止してはいかんというだけの話である。
ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。
- テクノロジーマネジメント
- アーキテクチャやテストなど
- プロジェクトマネジメント
- 見積もりやアジャイル開発など
- プロダクトマネジメント
- ビジョンや仮説検証など
- ピープルマネジメント
- メンバーの成長やメンタリングなど
分散型プロトコル「Nostr」上に構築した動画共有サイト「Flare」が登場しました。FlareはYouTubeのように動画を投稿したり再生したりでき、運営による収益化の停止やアカウントの凍結がないことが売りとなっています。しかし、中央集権型ではなく分権型による動画サイトでのモデレーションをどうするべきかが議論されています。
「Nostr」は分散型ネットワークプロトコルです。分散型ネットワークプロトコルには、MastodonやThread、Misskeyなどで使われている「ActivityPub」が有名ですが、ActivityPubはインスタンス単位で管理が行われる連合型分散プロトコルであるのに対し、Nostrはリレーサーバーとクライアントがやり取りするというかなりシンプルなリレー型分散プロトコルとなっています。
正社員が20名規模かつ各ストリームアラインドチームが担当サービスのRealibityに責をもち自己完結して継続開発・改善できている状態
本番環境のオペレーションやSLO・SLIなどの指標通じてSite Reliabilityと継続的改善にプロダクト開発エンジニアが責任を持つ文化を維持・強化していく過程で手段として必然的に各プロダクト開発エンジニアが平均してインフラやCI/CDへの技術的知見が高い組織の状態になっています。
とても極端に言うと（多少デフォルメしてます）「スミマセン涙...Kubernetesのポッドが立ち上がらないんですけど...」「デプロイがコケたんですが助けてほしいです...」とSREチームのサポート無しではプロダクトを自己完結して継続提供できない状態の組織でした。当然SREチームのメンバーはとてもフォローしてくださっていましたが（それはまるでド◯えもんのような心で「しょうがないな、プロダクト開発チームは〜」といった感じで）、同時に本来的にSREが担うべき戦略領域に時間を割けていないことにフラストレーションを感じていたのも当然理解していました。
相談や壁打ちをするのは悪いことではない。しかし、そこに目的が存在しないと、壁打ち相手もどのような観点で意見を求められているのかわからず、アドバイスしづらいだろう。結果、何も決まらず相手や自分の時間まで無駄になってしまう。
【セットで伝えるべきこと】
- 何をゴールとした相談・壁打ちなのか
- 自分は今どんな課題を抱えているのか
- その相談や壁打ちが終わった後、どんな状態になりたいのか
- どんな観点で意見が欲しいのか
- データとコードの分離を心がける
- CQRSを採用する
- 必要にならない限り詳細を隠蔽しない
- 単体テストでロジック網羅を試みつつ、統合テストで全体をカバーする
- API・DBスキーマに関するものを二重管理しない
- AIに理解してもらいやすいコーディングを心がける
IT系勉強会タダ飯タダ酒乞食おじさんが先鋭化してるらしい
- (1) APIのスキーマ品質を向上させる事ができる
- (2) テストを迅速に開始できる
- (3) UIテストに比べて実行スピードが早い
- (4) テストの安定度が高い
- (5) テストを効率的に書ける
- (6) シナリオがドキュメント代わりになる
- (7) 自動テストへの組み込みが容易
- (8) リグレッションテストにも使える
- (9) ネガティブテストをしやすい
- (10) 負荷テストにも活用できる
時下益々ご清栄のこととお慶び申し上げます。平素より弊社電子書籍をご愛読いただき篤く御礼申し上げます。
弊社では、このたび令和6年1月10日より現行弊社ウェブサイトで販売している電子書籍（EBook）の価格を書籍の価格と同額にすることといたしました。
今回、弊社としてこのような判断に至った経緯としては、2008年12月に弊社Ebook Storeを開設した当時、まだ黎明期であった電子書籍の市場を開拓する上で定価の2割引きでの販売を始めました。
それ以降、これまでにDRM Free化、再ダウンロード機能の追加、そしてコロナ禍以降の出版メディア及びコンテンツビジネスを取り巻く環境が変化している中、その間も従来の価格を維持してまいりましたが、昨今の市場環境を鑑み「弊社オライリー・ジャパンのコンテンツ」の価値に見合った形で、書籍、電子書籍の形にかかわらず、同一の価格とする判断に至りました。
ご愛読者皆さまのご理解のほど、なにとぞ宜しくお願い申し上げます。
ご不明な点がありましたらば、 カスタマー・サービス専用メール までご連絡ください。
今後とも弊社電子書籍のご愛読を賜りますよう、よろしくお願い申し上げます。
オライリーはDRMフリーの「本物の電子書籍」を出してくれるので同じ値段でも仕方ない。
同社は米国時間12月12日、常識的な推論と言語理解が可能なSLMの「Phi-2」を発表した。現在、「Azure AI Studio」のモデルカタログで利用可能となっている。
「小規模」という言葉に惑わされてはいけない。Phi-2は27億個のパラメーターを持ち、その数は「Phi-1.5」の13億個から飛躍的に増加している。
同社によると、Phi-2はパラメーターが130億個以下の言語モデルの中で「最先端の性能」を発揮し、複雑なベンチマークでは最大25倍の言語モデルを上回ったという。
同社がSLMに注力しているのはなぜだろう。それは、LLMに対するコスト効率の優れた代替となるからだ。SLMはLLMほどのパワーを必要としないタスクで役立つ。LLMよりはるかに少ない計算能力で実行できるため、データの処理要件を満たすために高額なGPUへ投資する必要がなくなる。
プロパーがSIerさん侮辱した結果、SIerさんブチギレて全撤退するそうだ。そのプロパーは懲戒くらって、プロジェクトこれ完全に延期だな。
電話でもメールでもSIerさん下に見てて、毎回バカにしたような態度と文章だったから自業自得って感じ。
コンプライアンス守れない１人のせいで、プロジェクトが止まるって関係者はたまったもんじゃないな…
第1位: 凝縮度に基づくメソッド設計
第2位: 書籍ASoSDにおけるDeepModuleになってない
第3位: panicをinterceptorでhandlingするテクニック
第4位: ロジックを追加するレイヤーを考えよう
第5位: error flowの書き方
- 自動修復機能を設計します 。 分散システムでは、障害が発生します。 障害の発生に備えてアプリケーションの自動修復機能を設計します。
- すべての要素を冗長にします 。 単一障害点をなくすようにアプリケーションに冗長性を組み込みます。
- 調整を最小限に抑えます 。 アプリケーション サービス間の調整を最小限に抑えてスケーラビリティを実現します。
- スケール アウトするように設計します 。需要に応じて新規インスタンスを追加または削除し、水平方向に拡張できるようにアプリケーションを設計します。
- 制限に対処するようにパーティション化します 。 パーティション分割を使用して、データベース、ネットワーク、コンピューティングの制限に対処します。
- 操作に合わせて設計します 。 運用チームが必要なツールを得られるようにアプリケーションを設計します。
- 管理対象サービスを使用します 。 可能であればサービスとしてのインフラストラクチャ (IaaS) ではなくサービスとしてのプラットフォーム (PaaS) を使用します。
- ID サービスの使用. 独自の ID を構築または運用する代わりに、サービスとしての ID (IDaaS) プラットフォームを使用します。
- ジョブに最適なデータ ストアを使用します 。 データに最適なストレージ技術とその使用方法を選択します。
- 展開を見込んで設計します 。 成功するすべてのアプリケーションは時間の経過と共に変化します。 改良を見込んだ設計は、継続的なイノベーションのための鍵です。
- ビジネスのニーズに合わせて構築します 。 設計の決定はすべてビジネス要件によって正当化される必要があります。
欧州連合（EU）の議会と理事会は、サイバーレジリエンス法（CRA）について合意に達し、待望のセキュリティ規制について、最終承認・採択への道筋をつけるとともに、オープンソースソフトウェアを除外する新たな規則を定めた。
議会と理事会での採択から 20 日後に施行される CRA は、ハードウェアおよびソフトウェアメーカーにいくつかの威圧的な目標を達成することを求めるものとなる。この規則には、新たに発見された脆弱性が悪用されている場合に 24 時間以内に開示することや、5 年間のセキュリティパッチサポート、すべてのセキュリティ機能の完全な文書化などが含まれている。
製造業者、輸入業者、流通業者は、36 か月以内にこの要件を採用しなければ、最高で 1,500 万ユーロまたは世界での年間総売上高の 2.5 ％以下の罰金を科せられる。
とりあえずOSSは除外された模様
米Wasmer社は、WebAssemblyへのコンパイルだけに特化した新しいプログラミング言語「Onyx」を発表しました。
同社はWebAssemblyにかつてのCGIの仕組みを取り込んだ「WCGI」や、WebAssemblyでBashのコマンドプロンプトなどをを実装可能にするWebAssemblyを拡張してPOSIX対応にした「WASIX」など、WebAssemblyをベースとしたさまざまな技術を発表し実装しています。今回のOnyxもそうした技術の1つとなります。
構文はGo言語など命令型プログラミング言語をベースにしていると、次のように説明されています。「Onyx, a new programming language powered by WebAssembly」から引用します。
こんな感じ↓の言語らしい（公式サイトより引用）
use core { printf, iter }
main :: () {
for i: 1 .. 10 {
fact := factorial(i);
printf("{}! = {}\n", i, fact);
}
}
factorial :: (n: i32) -> i32 {
return iter.as_iter(1 .. n)
|> iter.fold(1, (x, y) => x * y);
}