世界最大級のモノリスcookpad_allどうする会議
クックパッドのレシピサービスを支えるシステム（レポジトリ名cookpad_all）は、 かつて稼働コードだけで40万行を越える世界最大級のモノリシックRailsアプリケーションでした。 2017年からの様々な改善により、コンテナ化やアプリケーション構成の整理が行われ、 さらにいくつかの機能はマイクロサービスとして分離されてもいます。 next-cookpadにより一部のページのReact化にも成功しました。
ですが多くの改善を経てもcookpad_allはいまなお30万行以上の超重量級アプリケーションであり、 様々な問題を抱えています。マイクロサービスの問題も見えてきましたが、しかし元に戻すのも得策でない。 Shopifyのようなモジュラモノリスも我々には適切でない。
ならば我々はcookpad_allの問題に対してどのように立ち向かっていくべきなのか、 10年後のcookpad_allがどうあるべきなのか。 今回のラウンジではcookpad_all改善を手掛ける現場のエンジニアがぶっちゃけて話します。
急いでいるのでがっちり安定したものを作ってくれる人達に対して”進みが遅い”と言って、”こんなのすぐに出来ますよ”というプロトしか作れない人達の話を鵜呑みにしたくなる気持ちは分からんでもないけど、前者を切って後者に頼ったら後でそのツケを大きい。安定までにかかる時間は一緒。現実はそう。
要求されたものに対してプロトを作れるエンジニアなんてぶっちゃけどこからでも調達できる。でも外部のノイズに乗らずがっちり作ってくれるエンジニアは本当に貴重。こういうエンジニアを軽視すると本当にいい事ない。土壇場で最後に頼れるのはこういう人達なので大事にしていきたい所。ホント。
プロトタイプしか作れない人達は自分達の作った物が氷山の一角でしかない事は認識しているし、その下にある氷山は口では大きいと言うけど実際は大したことがないと思っている。海面にはでてないから見えないし経験がないから。でも実際はその下は彼らが考えるよりも巨大である。
がっちり安定したものを作れるエンジニアはこの肉眼では見えない氷山の規模が経験等から見える。目に見えない氷山の全体規模を限定的情報から想定できるという能力がどんだけ貴重か、そしてその見えない暗闇を照らして安定した道が作れる人達は得難い人材という事を偉い人達は認識してくれ。マジで。
とはいえ、「作業スピードは遅いし、成果物の質も低い」みたいなエンジニアも沢山いるから（震え声）
Rustで実装されたMeCab互換の形態素解析エンジン。
MeCabより2倍早く動作するとのこと。
まぁ、アプリ内ブラウザはそもそも開発元にフリーハンド与えるような機能ではあるし。
あちこちの日系大企業からIT人材に年収1000万出しても採用できないって話を聞くけど、理由は２つあってIT人材のTwitter利用率が高く、Twitter内でJTCのヤバさを曝露するツイによる風評被害で日系大企業を対象外にしてる人が多いのが原因の１つ。もう１つの理由はそのヤバい噂が事実であること。
格安PCボード「Raspberry Pi」（ラズパイ）の主要な販売元だった英RS Components（以下、RS）が、ラズパイの製造・販売から2022年6月末で撤退したことが明らかになった。
これまでラズパイは、RS（製造は関連会社のOKdoが担当）、element14（英Premier Farnellの子会社）、英Raspberry Pi財団の3つの製造元（ブランド）が供給していた。このうち、RS（OKdo）のブランドがなくなり、今後は残り2つのブランドだけになる。
ラズパイは世界での需要が高まっているのに対し、半導体不足などから製造が追いつかず、品薄の状態が続いている。このため、RSにラズパイを発注して出荷を待っていたユーザーは多くいた。ところが、日本法人のアールエスコンポーネンツは2022年8月10日に突然、「2022年7月1日をもってRSが製造ライセンス契約を終了した」とするメールをユーザーに送った。販売も中止となり、既存の注文もキャンセルになった。
そのメールには、RS以外の製造元もライセンス契約を終了すると書かれており、その情報がSNSで拡散されたことから混乱が生まれた。実際にはこれは事実とは異なり、RS以外の製造元は変わらず生産を続ける。Raspberry Pi財団が電子掲示板で8月11日に表明した。
マイクロソフトとCanonicalは、Linuxの代表的なディストリビューションの1つであるUbuntuが.NET 6をネイティブにサポートすると発表しました（マイクロソフトの発表、Canonicalの発表）。
もともと.NET 6はWindows、macOS、Linuxのクロスプラットフォームに対応するフレームワークですが、Ubuntuが正式サポートを発表したことで、aptコマンドによるシンプルで確実なインストールが実現されると同時に、セキュリティパッチやアップグレードもタイムリーに提供されることになります。
.NET 6を公式にサポートするLinuxディストリビューションが登場したことで、企業がLinux上で.NETを利用する環境が整ってきたと言えそうです。
おぉー
Dev Boxは、「Windows」上で動作するあらゆる統合開発環境（IDE）、ソフトウェア開発キット（SDK）、内部ツールに対応している。Dev Boxはクラウド上に置かれたWindows環境であるため、「Windows Subsystem for Linux」や「Windows Subsystem for Android」も利用でき、Windows、「ｍacOS」、「Android」、「iOS」を搭載するデバイスや、ウェブブラウザーからアクセスできる。
Dev Boxには、4 vCPU／メモリー16GBから32 vCPU／メモリー128GBまで、さまざまな構成が用意されている。プレビュー期間中は、8 vCPU／メモリー32GBのDev Boxを毎月15時間まで無料で利用でき、Dev Box用のストレージも512GBのSKUを365時間分無料で利用できる。それ以降は、使用量に応じて1時間当たりで設定された利用料金を支払うことになる。
ふーむ。
まず1つは「DDDの構成要素をすべて利用しなければいけない」っていう誤解なんですけど、これも結構あるあるですね。例えば、レイヤードアーキテクチャを用いて、ドメイン層にエンティティを作ったり値オブジェクトを作ったり、それを集約して、さらにそれをファクトリにして、みたいな。で、それ以外のものはサービスやモジュールにして、みたいな。こんな感じですべて入れないとDDDじゃないよみたいな誤解があると思うんですけど、そうではなくて、サービスとかモジュールっていうのは責務や概念を分離するものなので、必要なときだけ使います。あと、ファクトリも集約の生成が複雑になった場合の手法なので、必要じゃなければ使わなくていいということです。
また、これもあるあるですが「データの詰替作業がとてもツラい」と。これは確かにそういう側面はあるんですが、そもそも、データの詰め替えがなぜ発生するかというと、それは責務や概念を分離してレイヤーに閉じ込めているからだという前提があります。なので、そもそも不要なレイヤーを設けていないかとか、そもそもドメインモデルの設計が正しいかどうかを、そのとき確認した方がよいと考えています。
重要な点は、モノリスは必ずしも悪いアーキテクチャではなく、単一のテストおよび展開パイプラインなど多くのメリットがある、ということだ。新たな機能を短期間で提供する必要のあるプロジェクトを立ち上げるには、これは非常に有用だ。アーキテクチャの改善に着手すべきなのは、"設計のペイオフライン"を越えた時、すなわち設計の悪さが機能開発を妨げるポイントにおいてのみである。
Shopifyは当初、保守性のよい代替アーキテクチャとしてマイクロサービスを検討していたが、分散システムの複雑性を理由に除外され、代わりに、より保守性のよいモノリスが求められることになった。
結果として、モノリスのような単一で展開可能なユニットを維持しながら、マイクロサービスのようにシステムのモジュール性を高めることが設計目標であるという認識に達したのだ、とWesteinde氏は説明する。これを実現するため、Shopifyでは、モジュラモノリス(modular monolith)パターンを採用した。この方法では、コード間のバウンダリは可能になるが、コードは同じ場所に配置され、同じ場所に展開される。マイグレーションパスは次のようなものだ。
・コードの再編成: 当初のコードは、典型的なRailsアプリケーションのような編成で、トップレベルのパーツには"controllers"など、技術的コンポーネントにちなんだ名前が付けられていた。これを"billing"や"oders"など、ビジネス機能に基づいた編成に変えることで、コードの所在を見つけやすくした。
・依存関係の分離: 各ビジネスコンポーネントを相互に分離し、公開APIを通じて使用できるようにした。各コンポーネントの分離の達成状況を追跡するために、Wedgeという名前の社内ツールが開発された。このツールはコールグラフを作成して、コンポーネント間のコールなど、違反しているコールを見つけ出すことでこれを行う。
・境界の施行: 各コンポーネントが100％分離されると、それらの間には境界が施行される。基本的な考え方は、明示的に依存していないコンポーネントのコードへのアクセスに対して、ランタイムエラーを発生させる、というものだ。このような依存関係を宣言することにより、依存関係グラフで依存関係を視覚化することも可能になる。
created_at と updated_at をアプリケーションで使うな必要なら別カラム作れってのと同じ理屈で、idも脳死でuuidにしてしまって自然キー必要なら別途作れって言いたくなってきてる
uuidが自然キーとして使われ始めたら詰む（そんなことありえる？
UUIDの時点でサロゲートキーとしての運用なのでは？？
The experimental user interface toolkit being built at golang.org/x/exp/shiny includes several text elements, but there is a problem with testing them: What font should be used? Answering this question led us to today’s announcement, the release of a family of high-quality WGL4 TrueType fonts, created by the Bigelow & Holmes type foundry specifically for the Go project.
golang.org/x/exp/shiny で構築されている実験的なユーザー インターフェイス ツールキットには、いくつかのテキスト要素が含まれていますが、それらをテストするには問題があります。どのフォントを使用する必要がありますか? この質問に答えることが、今日の発表につながりました。これは、Bigelow & Holmes タイプ ファウンドリが Go プロジェクト専用に作成した、高品質の WGL4 TrueType フォント ファミリのリリースです。
GoのGUIライブラリであるshinyのテストの為に作られたフォントとのこと。
こんな感じ↓でgin.CreateTestContextでコンテキストを作る＆ルーティングを定義して実行してやればOKぽい
package example
import (
"net/http"
"net/http/httptest"
"testing"
"github.com/gin-gonic/gin"
)
func TestGetRoot(t *testing.T) {
gin.SetMode(gin.TestMode)
w := httptest.NewRecorder()
_, r := gin.CreateTestContext(w)
r.GET("/", HuddlerFunction)
req, _ := http.NewRequest("GET", "/", nil)
r.ServeHTTP(w, req)
asserts := assert.New(t)
asserts.Equal(w.Code, 200)
}
おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。
まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。
あと、「住めば都」原理により、人間はそれなりに散らかったコードでも割と適応して、結構コードを把握できてしまって、リファクタリングの効果が構造の変化ほどは出ないんではないかというのもあり。
もちろん、リファクタリングがちゃんとされているコードと書き散らしのコードでは、作業の気持ちよさが違います。ということはリファクタリングはエンジニアの精神衛生を保つ福利厚生の面が高いんではないでしょうか。
福利厚生、つまり、エンジニアに与えられる金銭以外の報酬ってことです。
Twitter IT界隈会話デッキ
・情報商材は悪
・SESが良いか悪いか
・ベンチャーVS大企業
・プログラミングスクールの悪口
・動的型付け言語のデメリットについて
・コメントを書くか綺麗なコードを書くか
・動くコードが偉いか綺麗なコードが偉いか
・本物のオブジェクト指向を知っているのは俺だ選手権
草
日本のIT業界の人材の質、未経験新卒にちょろっと研修して仕事をさせる、あたりが存在しているので、一番下は素人同然なのは疑いようがない。
それより更に厳しい気持ちになるのが、未経験新卒にちょろっと研修してプロジェクトマネジメント業務をさせるやつ。
グチるだけグチって肝心な部分は全部省きおったｗ
Python 書いてて「type hinting 書きましょう」みたいなレビューされても正直全然同意できないんだよな。そこ頑張るんだったら静的型付言語への移行にコスト割いたほうがいいんじゃないのって感じ。
これは本当にそう思う。
製作していたゲームはどんなものだったのかな？ と思って動画を見たら「お、おぅ...」という感じで、こういうのに人生を掛けて取り組めるのも若さ故というところはあるか。
仕事の期限があるならば時間を区切った上で、まるっと部下に任せ、困ったら聞いてね、というふうにしたほうがいい。後ろからじーっと見られると仕事は誰でもしにくい。一方で上司が問題の先回りばかりやっていると、想像力が育たない。部下が試行錯誤する権利も含めて時間を切って、やってみなさいと言ったら質問してくるまでは、待たなければいけない。
これが思いのほか難しい。自分がやったら数分で済むことが、数時間かかることさえある。仕事を細かく切り分けて部下に仕事を渡すが想定外のもととなる。これが我慢できなくて、自分でやってしまうことがこれまで何度もあった。
1. 開発職は、開発テーマの達成を目標にはできない
[...]なかでも重要な成果は「開発テーマを達成する」ということです。しかし、これを営業の予算と同じく、目標とすることは好ましくありません。自主性を入れにくいからです。
また、顧客の都合や会社の都合でテーマやスケジュールは入れ替わるものですし、受注生産的な会社の場合それは頻繁に起こるはずです。その度ごとに目標管理シートを書き直していたのでは仕事になりません。開発日程管理や開発予算管理という役目は、開発計画書が果たしているはずです。
2. 開発業務のプロセスの向上目標を
開発テーマは頻繁に変わったとしても、開発プロセスは共通な場合が多いはずです。以下のようなプロセスに着目させると効果的です。担当している業務の生産性を向上させ、ミスを減らす、質を向上する、納期・タイムラグを短縮する、というようなものを目標に取り込むのが相応しいでしょう。
・開発テーマ企画・仕様打ち合わせ・仕様確認・基本設計
・概略設計・詳細設計・プログラミング・デバック・最終検査
・外注先の管理・販売支援用技術資料の整備
・販売支援（営業同行）・技術セミナー開催
・技術サービス、サポート・技術の標準化
微妙に定量化が難しいものが多いような。
数値目標を出しにくいものは達成率を判定しづらい問題があるのだが。
DFDを用いた分析技法はバッチ処理が主流の時代のバッチ処理の為の分析技法という印象だった。
このスライド書いた人、ビジネスルールを記述しえないprotobuf(しかもint型とstring型で大半が構成されている)をハードに使い込んでる現場に来たら泡吹いて倒れるんじゃないかな…。
こんなプログラミング業界のマナー講師みたいなのに取り合うとろくなことが無いので、各位自分のビジネスロジックに集中して真面目にコード書きましょう。
「このスライド」とは↓のこと
この人はGoogle勤務らしいのでGoogle内部のシステムのことを言っていると思うだけど。
protobufはシステム間のデータ転送に使うもので、要はアプリケーション層の技術。
ドメインモデルはドメイン層で扱うものなので、当然アプリケーション層から変換されることが前提である。
CSVやJSON、プレインテキストでデータ連携するシステムだって、受信したデータをドメインモデルに変換することは普通にやるものである。
そういった観点を無視している点でこの意見は的外れなものに感じる。
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。
かくして、分析・設計する対象はソフトウェアではなくソフトウェアの環境であり、工夫する対象はソフトウェアをどう作ってどう配備してどう運用するかというプロセスであり、コードに関してはあらかじめスケッチするのではなく方針や原則を決めプラクティスを実践する、ということに落ち着いたのではないかと思います。
つまり、DDD、アジャイル、継続的インテグレーション、SREという感じになったわけですね。これらは実装パラダイムには依存しないので、プログラマは自分たちに適した技術を採用できます。
プロジェクトを止めるのに理由は要りません。プロジェクトを進めるのに理由がいるのです。プロジェクトを進められる材料が揃わなかったら、まず止める。それだけで、だいぶ不幸なプロジェクトは減らせます。
それはまぁそうなんだが
Modus uses logic programming to express interactions among build parameters, specify complex build workflows, automatically parallelise and cache builds, help to reduce image size, and simplify maintenance.
Modus はロジック プログラミングを使用して、ビルド パラメーター間の相互作用を表現し、複雑なビルド ワークフローを指定し、ビルドを自動的に並列化してキャッシュし、イメージ サイズを縮小し、メンテナンスを簡素化します。
Modus is a language for building Docker/OCI container images. Modus uses logic programming to express interactions among build parameters, specify complex build workflows, automatically parallelise and cache builds, help to reduce image size, and simplify maintenance.
Modus は、Docker/OCI コンテナー イメージを構築するための言語です。 Modus はロジック プログラミングを使用して、ビルド パラメーター間の相互作用を表現し、複雑なビルド ワークフローを指定し、ビルドを自動的に並列化してキャッシュし、イメージ サイズを縮小し、メンテナンスを簡素化します。
Dockerfileの上位互換みたいなイメージでいいのか
logglyは簡潔に言うとkibanaをログ参照用に使いやすくしたです。ログをためているのがElasticsearchだからです。
ソースコードのコメント不要、必要論。
いつも思うがコンテキストがズレてる気がするんだよなぁ。
「コメントが不要なくらい、シンプルでリーダブルなコードを書くように意識しましょう」と「ちゃんとコメントを書いてコードに現れない意図を伝えましょう」は両立するのにいつまでも不要な争いしてる。
ちゃんとコメントを書くのはコードを書くよりも遥かに難しい高度スキル。
クソ駄文なコメントは全て消せ、というコードコメントと駄文を一緒くたに語られてるのが問題。
// hogeで受け取った値を減算する
このクソ駄文を書いたやつは誰だ！
過去のわしじゃ！！！！！死ね！！！
まぁその通りなんだけど、ちゃんとしたコメントを書くのは高等技能で、一山幾らのエンジニアにはできないと言うのであれば、ノイズにしかならんからコメントを書いてくれるなという極論にも一理はある。
このビデオは OSC2022 Online/Kyoto 7-29 B-5
”イベントストリーミング入門 〜Apache Kafkaを活用した大規模リアルタイムデータ処理〜”
2022年7月29日(金) 14:00 〜 14:45
セッション概要
IoTやハイブリッド・マルチクラウドなどコンピューティング環境が分散する中、データが生み出される場所と、データが処理される場所が異なることが一般的になってきており、データをリアルタイムで伝達する技術の必要性が高まっています。Apache KafkaはOSSのイベントストリーミングプラットフォームとして存在感を増しています。
本セッションでは、初心者向けにApache Kafkaのアーキテクチャの概要とKstream、ksqlDBなどのエコシステム、実際のユースケースをご紹介します。
たいていのサーバは1台で充分だ。多くの場合マイクロサービス他の複雑化が開発コストに見合うかどうか疑問である。現代のサーバ (64core, 1TB RAM)は1台で以下のことができる:
- 動画ファイルを400Gbpsで配信
- NoSQLで100万IO処理/秒 (IOPS)
- nginxで50万リクエスト/秒
etc.
いや、サーバスペックすごくて草
とはいえ、ターゲットの顧客が限定されるニッチなサービスなら4core/8GBメモリのVPSを2-3台並べとけば十分なことは多いしなぁ
Kubernetesの運用はほぼ開発者の趣味みたいなところはある。
ただ、マイクロサービスはエンジニアを惹き付ける魔性があるのもまた事実（アーキテクチャとしては綺麗に見える）。
・UUID
・ULID
・CUID
・Nano ID
株式会社グリッドは、エネルギー分野における「不確実な環境における深層強化学習による最適化」の開発に成功した。これは現在のAIにとって最大の課題のひとつとされている「フレーム問題」を解決する糸口になる、と言う。そして、その成果を、米国物理学協会が発刊する「Journal of Renewable and Sustainable Energy」に評価され、論文が掲載されたことを発表した。
曽我部氏は「1つのAIモデルで学習しようとすると精度は高くなるが、状況の変化には順応できず、想定外のことがあると特定の答えを出してしまうという欠点がある。サンプル学習ではそれぞれモデルがそれぞれの状況による答えを出すので、結果的に幅広い状況に答えられるモデルが作れる。アウトプットはそれぞれ適度にバラけながら、これを多数並列化させて、多数決を取ることによって、最終的には精度が高い答えを得るという考え方」と説明した。
「フレーム問題」はAIに行動させる前に、環境下で発生しうる全ての事象を厳密に判断させようとするが故に、考慮すべき事項が多すぎて対処できなくなることで生じる。一方で、人間は行動する前に厳密な判断はせず、将来の状況をいくつか想定し、平均値的な手段をとるという曖昧性によって、様々な変化に対応しているという。この研究では、こうした人間が持つ曖昧性の高い手法に着目し、アンサンブル学習を採用した。
この結果、アンサンブル学習を適応しない手法と比較して未知のデータに対しても経済的に合理性のある電力の需給計画を立案することが可能であることを確認したという。さらに、算出された計画に対する年間単位でのリスク分析も可能とし、実運用において計画を採択する上での判断材料を示すことに成功した。
ZincはElasticsearch代替として開発されたオープンソースの全文検索エンジンです。Elasticsearchとは対照的にシンプルで簡単に操作できるそうです。GoとVueで書かれており、インデックスライブラリにblugeが採用されています。
Elasticsearchほど高度では無いものの、APIでデータ取り込み、検索するだけなら代替可能との事。ただし、kibanaはサポートされておらず、独自のUIが提供されています。
へぇー
特定のサービスにロックインされるのはよくないという意見はよく分かる。
テストコードをDRYにするとプロダクトコードとの境界が曖昧になってテストの意義が薄れるという観点、確かにと思う
・本見積はXXXプロジェクトの［概算or正式］見積です（概算＝まだ金額などすべて変わる可能性があるよ）
・正式見積もりのスコープ（要件定義とそれ以降で基本的に分ける）
・本書に記載のない機能が必要となった場合は、再度見積もりをご提示いたします
・本書に記載された非機能要件を超えた場合、動作などを保障することはできかねます
・非機能などフィジビリティスタディが必要な場合、その範囲は担保できないことを記載する
・本プロジェクトにて作成するすべてのドキュメントは、弊社書式といたします（相手書式に合わせると大幅なコスト増になる可能性が高い）
・XXXX年XX月XX日までにご発注いただけない場合、見積金額・スケジュールが大きく変更となる可能性があります
・要件定義移行の作業は、要件定義完了後に改めて再見積もりする前提といたします
・スケジュールが期をまたがる場合、中間成果物を納品させていただき、都度清算いただけることを前提とします
・フェーズや期跨ぎにより契約期間を分割する場合、次フェーズの開始XX日前までにご発注いただける前提とします
・発注が遅延した場合、プロジェクト体制の解散につながり、大幅なスケジュール変更が発生します
・開発に当たって、貴社ネットワーク環境など必要な情報は適宜開示いただける前提とします
・開発に必要な資料は、個人情報など適切にマスクを実施した上で、ご提供いただける前提とします
・貴社内にて、プロジェクトを遂行する上で必要な裁量をもった担当者を選定いただける前提とします
・プロジェクトを遂行する上で、弊社と十分な協力体制をとってプロジェクトを運営いただける前提とします
・プロジェクトを遂行する上で、必要となる関係者にプロジェクトチームへ参画いただき、十分な協力が得られる前提とします
・プロジェクトの打ち合わせは基本的にリモートとし、オンサイトでは原則実施いたしません
・感染症等の状況が変化した場合、スケジュールについて見直しいただく場合があります
・外部要因によりハードウェア等の納入が遅延した場合、スケジュールについて見直しいただく場合があります
・業務運用マニュアル・操作手順書などの作成、利用にあたっての教育などは対象外といたします（必要となるレベルが対象によってまったく 異なるため安易に受けない）
・運用保守見積が別途の場合は、含まれていないことを明確にする
Meta（旧Facebook）は、ブログ「Engineering at Meta」で公開した記事「Programming languages endorsed for server-side use at Meta」で、Rustを新たに社内の正式サポート言語に追加したことを明らかにしました。
明らかにされているガイドラインによると、サポートされる言語の使用用途として下記が推奨されています。
- 性能が重視されるバックエンドサービスではC++もしくはRust
- コマンドラインツール（CLI）ではRust
- ビジネスロジックや比較的ステートレスな仕組みのアプリケーションはHack
- 特定のユースケースでは、Java、Erlang、Haskell、Goなど、他の言語もサポートしていく
また、データサイエンスや機械学習の分野およびインスタグラムにおいてはPythonをサポートし、継続した投資を続けていくことも表明されています。
GoではなくRustを選んだのは低レベルレイヤーへの適合性がGoより高かったからということなのだろうか。
無理難題の事例集
（U1）実績を求める要求
（U2）技術的に実現が難しい要求
（U3）仕様の分からない既存のシステムの移行，連携を求める要求
（U4）将来の課題への対応を求める要求
確かにそういう要求あるな...って感じの内容
マンガだからある程度極端な設定にしてるんだろうけど、これだけ教育・受け入れ体制が整ってない上に学生インターンに全てを丸投げするの、完全にやばい会社なんだよなぁ
やっぱり新卒さんの仕事の質の許容限界は2年くらいなんだなぁとしみじみ思う。3年目に入った瞬間に露骨に周りの評価がシビアになる。まあわかるけど。一気に引き取り手がいなくなる。まあ分かるけど。結果抱き合わせ販売みたいになる。ベンダーさんがそうする気持ちがよく分かる。ホントしんどい。
このままじゃヤバいと感じて発奮をしてもらう為に題材違うけど同じ仕事を何人かと一緒にやってもらったんだけど全く効果がない。なんでそんなに泰然自若としていられるのか。逆に大物なのかもと前向きに捉えたいけど流石に大物ならそろそろ片鱗くらい見せてくれないとフォローのしようがない。トホホ。
エンジニアという仕事は適性というものが残酷なまでにはっきりする仕事なので、適性が無い人はいつまで経ってもアレだからなぁ
複雑な GUI はバグるしメンテコスト高いしマニュアル整備等でユーザーサポートも大変なので、それをサービスのコアにするのは大変な覚悟が必要なことだと思っていて、できるだけ小さい実装・ショボい GUI でユーザーの課題を解決できないものかとサボる方向で知恵を絞ってしまうのが普通だと思う
これは機能豊富で使いやすい GUI はそれだけで競争力たり得るということでもある
Elasticsearchよりも4〜29倍高速らしい。
基本的には民生用OSを兵器の制御に採用する事はありません。
複数の理由があるようですが……。
・メーカー自身が内部に関与できないとバグすら直せません。
・一般に兵器はリアルタイム性が求められますので、非RTOSのWindows-OSは不適です。
・兵器は寿命が長く、短命な民生用OSになじみません。
・民生用OSだとハッキングリスクが高くなります。
一方では、携帯型の情報通信機器にはPanasonicの"Toughbook"を採用したり、戦術情報の分析や演習支援などには普通にWindowsベースのアプリケーションとして各種の専用／汎用のソフトウェアが利用されています。
・militaryaerospace.com/computers/article/14037650/rugged-laptop-computers-us-marine-corps-battlefield
ここ10数年ほどで、Android-OSを始め Linuxベースで情報機器が容易に組めるようになったので、軍用の電子装置のほとんど全てがLinux系にシフトしており、そうでない物は（OS無しの）ベアプログラムだと思われます。
例えばL3社製F-35コックピットディスプレイのインタフェース制御は”LynxOS-178”というLinux系のリアルタイムOSだとされます。
へぇー
〜ソフトウェアポエム作法〜
1、なんか言う。検証不可能な言説であることが望ましい
2、「要はバランス」、「銀の弾丸はない」、「状況によって臨機応変に」のうちいずれかを選択して締めくくる
>「要はバランス」、「銀の弾丸はない」、「状況によって臨機応変に」
こういう結論見る度に「そんな事は分かってるんだよ。知りたいのはどういうパターンの時にどういうものがハマるかっていう具体例なんだよ」ってなる。
大企業の採用をくぐり抜けてデスマーチの会議に毎回出席している人物はほぼ例外なく勤勉であり、その会議を行う組織そのものも「勤勉」と言える。であるが、デスマーチに陥っている時点で「愚か」である。つまりまさに「愚かで勤勉な」知性体の活動こそがデスマーチである。
軍隊の将校で言うなら「あの将校を追い出すか銃殺せよ」で究極的には話が済む。 しかし大企業のデスマーチの中では「個人レベルでは利口かも知れないがそれを合計した会議体としては愚か」という抽象的な組織がうごめいており「誰を追い出すか銃殺すればいいんだ」という答えが出てこない。そこで大真面目に犯人探しをしても全員それなりの道理があって行動しているので個別事象で見れば正しく動いているようにすら見える。
誰が悪いとかどこが悪いとか明示的に指し示して切り離せるものではなく、強いて言うなら悪いものは会議室の空気というか組織全体の漠然とした流れのような物である。だから専務であっても容易に「○○課長を左遷すればうまく行く」などと切り出せたりはしない。
これは究極的には「企業内力学」とでも呼ぶべき未だ科学では解明されていない未知の力の結果である。原子の振る舞いを追う量子力学と、原子が集まった集合での振る舞いを追う量子統計力学が別の領域であるのと同様にして、人類は「大企業の組織が誤った判断をした際に止まらないのは何故か」という命題に対する統計力学は未だ大企業の振る舞いをモデル化しきれる方程式を見つけていない。
まとめるとValue Objectとは
- 比較がIDではなく値で行われるオブジェクトであって、ドメインの語彙として値のように振る舞うので便利。
- 複製と共有の違いをぼかしているオブジェクト指向言語ではオブジェクトを値のように振り回すと事故るので、不変性を強制する・常に複製するなどの工夫がある。
- 大事なのはプログラマのメンタルモデルをプリミティブ型の取り回しと揃える事であって、Valueのように振る舞うObjectなので"Value Object"と呼ぶ。
Value Objectとは何でないか?
- Value Objectの出発点はそもそもcompound（合成物）であって単一の値を包めとは一言も言ってない
- プリミティブ型を包んでもID（e.g. ポインタ）で比較していたらValue Objectと呼べない
- 包まれる値はプログラム言語のプリミティブ型とは限らなくて別のValue Objectであるケースも有り得る
- ポインタやIDで比較しようが型システムの恩恵は得られるのでValue Objectに固有のアイデアではない
- クラスを定義する際に固有の振る舞いを定義するのはOOPの基本でありValue Objectに固有のアイデアではないし、Value Objectを表すクラスに常に便利なメソッドを足せとはマーチン・ファウラーも言っていない
- immutableは共有と複製の違いをぼかしたまま使うための工夫に過ぎなくて、常に複製しても良いとマーチン・ファウラーも言っている
ソフトウェアは人が作るもので、文字通り柔らかい。その寿命は人よりは長くないと思われがちだが、実際には、そのソフトをメンテナンスする人、という文脈で考えるとソフトウェアの寿命のほうが人よりも長いことのほうが、特に自社サービスでは多い。なぜなら人は会社を辞める、異動する、飽きるので。
ので、ソフトウェアの方が開発者よりも寿命が長いという前提でやりくりしていかないといけない。つまり、開発者の世代交代が当たり前のように起きるのだと考える必要がある
レガシーなソフトウェアを作り直すのは生産性云々の視点もあるけれども、実際にはそこじゃなくて、開発者の世代交代に適応するための活動だと思います
レガシーソフトウェアの再構築を通じてドメイン知識を次の世代の開発者に継承し、オーナーシップを新しい開発者に移譲する。そこで働くソフトウェア開発車の在籍期間よりも、サービスの方が長く存続するならそういうことを当たり前に繰り返していく必要がある
レガシーなのは嫌だから作り直す、というのは個人の視点で、マクロなマネジメント視点としては、そこにあるソフトウェアが提供するサービスを長く繁栄ささるために必要な組織の新陳代謝のために作り直すという視点があります
スマホで打ったもんでミスタイプ多い。。。
なので、ある程度サービスが流行ると、常にそのサービスを動かしながら作り替える。一通り作り替えたと思っても。すでに作り替えたところが古くなってるので、また作り直す。の繰り返し。一見無駄なようで、この延々とした作り直しのプロセスが、プロダクトや組織も、今その時点に適応することに繋がる
サービスが下火になって作り直しのコストをかけることができなくなると、そこで営みが止まる。経済みたいなもんですね、ずっと回ってないといけないっていつ
一休のサービスなんてもう20年前くらいからありますけど、社員で20年在籍してる人なんて1人もいないですからね。今どきのソフトウェアエンジニアは、3〜5年くらいで次のチャレンジを目標に辞めていくので、その世代交代に適応できるよう常に作り替えていくみたいな発想が必要です
やっぱBIOSに高度な機能を持たせてはいけなかったと思うんだよね
若手のITエンジニアが足りない問題、本当にエンジニアが足りないんじゃなくて
・基本的な情報工学の知識があり
・自分で考えて問題を発見できて
・トラブルがあっても黙って抱え込まずにちゃんと報連相できて
・勉強や向上心があり
・コミュニケーションスキルがある
人が足りないって感じ
かつ年収300万で文句言わない人
エンジニアをマネジメントするのはどうやらムリっぽいということが判明してからこっち、エンジニアに対する自己管理能力の要求が爆上げしてる感はある。
また、年収に関しては設立年次が浅めの企業ならそれなりに上がってる感じはある。
逆に年収が低めにキープされてる企業というのは、氷河期世代とかを安く抱えてるので新人に高い給料払うとオッサン世代のモチベーションが崩壊する怖れがあるそれなりに長く存続している企業だったりする。
企業が氷河期世代のオッサンを安く雇ってるのは社会道徳的にどうなの感はあるけど、氷河期世代のオッサンの方も定収入のある正社員という地位に甘えて待遇改善をしてこなかった為に下の世代に迷惑かけてることを反省しなければならない。
アーキテクチャと製造の視点があり、自分は製造側にいたことがあるのでその話をしたいと思います。
自分は15年ほど前に日本メーカーでロジックのFEOLの開発部門に在籍していました（IEDMに登壇したこともあります）。そこで感じたのは圧倒的な最適化の難しさ。パラメターが多い割には結果が出ることが数ヶ月後で、全然性能が出ないことはしょっちゅうでした。そんな中、intelが90nmでstrained-siliconといってスイッチ部分の横に別の物質を掘って埋め込み、性能を2倍に上げたものを市場に投入してきました。研究レベルではなく市場に投入です。これはかなり衝撃でした。日本でも研究レベルではやろうとした人はいたかもしれませんが、「ゴミが出る」、「汚染される」、「そもそも、、」とかいろいろ言われて、他社の実績無しでは多分試作すらできなかったと思います。
ここで感じたのが、海外メーカーは数人の天才・異才に指揮権を与えられているんだろうなということ。この部分でデメリットはあるけどこの部分が大きなメリットだからこれを適用する、という判断ができる体制があり、できる人がいること。分析が得意で直感にも優れた天才が指揮しないとCPUのような複雑なプロダクトで世界で戦うことはできないのを痛感しました。自分のいた部署、製造ラインのエンジニアは平均すると海外メーカーより全然優秀だと思いましたが、権限がフラットなので全体最適を取ることは至極困難でした（日本は一時期メモリで覇権を取りましたが、メモリは統合より各モジュールの平均で勝負できるので、「平均が高めの人が多い組織」で戦いになるのが突出した原因かと思います）。
いまの世の中はいままで以上に一部の変わった人を普通の人が支援する仕組みが重要になってきています。日本人は他人のやっていることに影でこそこそコメントするのを止めて、「やってみなよ、少し手伝うから！」というマインドの人が多くなると良いですね。
以下の記事もご参照ください。
ITエンジニアが不足しているの、仕事の専門性・複雑性が昔より上がっているのでいわゆる「駆け出しエンジニア」の手に負えるようなものでは無くなっている点にある。
「駆け出しエンジニア」に無理な仕事は「一人前のエンジニア」が代行するしかないので、そこの人手が足りていない。
更に「駆け出しエンジニア」がガンガン心折られて離職していくので、「一人前のエンジニア」へ進化する個体も少なく、やっぱり人手は不足する。