部下に対して難しめの仕事を振った時に、『丸投げ』とか『責任放棄』と捉えられるタイプの上司と、『成長機会を提供している』と捉えられる上司の違いはなんだろうかと考えている
上司自身がその仕事のアウトプットやアプローチに対して何らかの仮説がある、若しくは仮説を考えるつもりがある、か否かが分かれ目なんだろうなぁ
途中経過を適切にフォローしているかどうかかな？ という気はする。
仕事を振った後は我関せずみたいな態度を取る上司はこいつ丸投げしやがったなと思われると思う。
原典：https://www.tumblr.com/numberonecatwinner/701567544684855296/elon-wyd
私は何年か前SpaceXのインターンをしていて、そのころSpaceXは今よりずっと小さい会社だった。イーロンが植毛をしたのよりは後で、イーロンを個人崇拝するカルトが盛り上がるのよりは前のことだ。なので知ってることをいくつか語ってみようと思う。
私がSpaceXにいたころ、イーロンは基本的には子供の王様だった。彼は会社に金と権力とPRをもたらす大切な傀儡だったが、毎日の意思決定をするのに必要な知識や（率直に言えば）成熟した人格を持っていなかったし、そのことをみんな知っていた。彼の周辺の人々の仕事は、本質的には、まともな意思決定をするよう彼をうまく操ることだった。
イーロンを管理することは会社の文化の大きな部分を占めていた。私のような底辺のインターンでさえ、会議でそういう会話が大っぴらにされているのを聞けた。社員はイーロンが食いつくようにアイデアをプレゼンする方法を知っていたし、イーロンの気が狂っているとしか思えない要求をうまく再解釈する（もしくは無視する）クリエイティブな方法を知っていたし、更にはイーロンが気に入るようにオフィス内を「演出」する方法も知っていた。
記憶にある一番面白い「演出」の例は、あるITセキュリティ部門の社員だ。彼は自分がコンピューターで何かすごいことをしているように見せるため、モニターの一つでマトリックス風のランダムなでたらめな表示をし続けるスクリプトを走らせ続けていた。二番目に面白かったのは、遅くまで働いているように見せようと午後5時以降にオフィスでWorld of Warcraftをプレイしていた社員たちだ。
SpaceX社員がこういうことをしていたのは、宇宙に進出するという社員にとっても重要な仕事のために、イーロンが金（と誇大広告）をもたらしてくれるからだ。会社はイーロンと一緒に大きくなったし、イーロンの周囲の組織も大きくなった。イーロンと末端の従業員の間には、何層にもなるマネージャーの組織が存在したし、彼らは経験豊富なイーロンの管理者だった。繰り返しになるが、社内の文化のどれほど多くの部分がこの一人の男をうまく管理するために捧げられていたか、どれだけ強調してもしすぎることはできない。
Twitterにはこれらの要素が存在しない。Twitterにはイーロン・マスクを管理するという問題に対処するための社内文化も組織も存在しない。私が思うに、部下がこの男の言うことを真剣に聞いてそのまま行動するとどうなるか、おそらく我々は初めて目撃しているのだ。更に悪いのは、このちょっとした実験が、この男が数十年に渡って自分の複数の会社でうまくやってきた後で起きていることだ。これらの会社では、社員が自分たち自身をこの男から守るためにかなりの労力を費やしてきたのだが、この男はあまりにナルシシストなのでそのことに気づけないのだ。
長い投稿になったのでついでにイーロンについてお気に入りの話をしよう。ある日会社で、今日はイーロンの誕生日なので強制参加のサプライズパーティを食堂で行うという一斉送信のメールを受け取った。おそらくイーロンも同じメールを受け取ったと思うのだが、ともかく、我々は食堂に行って照明を暗くして待っていた。イーロンは（まだクビにしていなかった）秘書につれられてやってきて、私たちが待っていたことについて嘘の驚きと感動を大げさに表現した。そしてケーキが運ばれてきた。
ここで、あなたが今までに見た中で一番大きなペニス型のケーキというものを想像してみてほしい。奇抜な性的なケーキの王様といったやつだ。ただし、それは砂糖で白く覆われていて、きんたまの部分は炎と煙に見えるような模様になっている。これがイーロンの「ロケット」誕生日ケーキだ。
生きている限り、あの場にいた人々の表情を私は忘れないだろう。ほぼ男のエンジニアばかりの暗い室内で、イーロンが願い事をしながら先端にナイフを入れた瞬間を。
ポリコレ的に「正しく」あるよりも、狂人でも社会を前進させるならその存在を認められる社会の方が自分は好みなんだよなぁ
米連邦通信委員会（ＦＣＣ）は２５日、中国の通信機器大手、華為技術（ファーウェイ）と中興通訊（ＺＴＥ）などが製造する通信機器の承認を禁止した。米国の国家安全保障に「容認しがたいリスク」をもたらす恐れがあるためとしている。
ＦＣＣは、国家安全保障上のリスクをもたらすと見なされる機器の販売または輸入を禁止する最終規則を採択したと発表。浙江大華技術（ダーファ・テクノロジー）、杭州海康威視数字技術（ハイクビジョン）、中国海能達通信（ハイテラ・コミュニケーションズ）にも適用される。
この件に関してファーウェイとＺＴＥからコメントは得られていない。
具体的にはどのようなリスクがあるのか知りたいけど、いまいちフワッとしてるんだよな。
詳細が知りたい。
"難しい人"、"有害な振る舞い"というのは、大変よろしくないラベリングになる。
こういったときに「言ってることはわからなくないけど、なんか違うな」と違和感を持ち、解決策を探るのがエンジニアである。
■機械的に判断できない基準を用いない
アクションに落とし込めないもの、計測できないもの、機械的に判断できないものは、いわゆる人間力に頼ることになる。
具体的に以下を例に挙げる。（元の記事の一番最初に例示されているもの）
チームの創造的な議論を阻害したり他者の時間を奪う
この短い（１行８０文字以下を短いと言う）文章の中に、人間力に頼る判断は何か所あるだろうか？
私は、「創造的」「議論」「阻害」「時間を奪う」の４つは、機械的な判断が難しいと思う。
他者の話に割り込んで自分の意見を差し込む
例えば、以下のパターンを想像してほしい。
- 加湿器を開発している、管理職、デザイナー、営業、ハードウェアエンジニア、組み込みソフトウェアエンジニアの５人の会議
- 管理職と営業が「電気代が低く、超音波式ではない加湿器を開発すべきだ」と会話している
- その会話の途中で組み込みソフトエンジニアが「今はまず超音波式の次の開発の方向性を議論すべきです」と発言した
これは客観的な基準で「他者の話に割り込んで、自分の意見を差し込」んでいる。
機械的に判断できているが、どこの何が問題だろうか？
■■「創造的」「議論」「阻害」とは、誰が判定するのか
先ほどの例だが、こんな前提があったとする。
- 「販売中の超音波式加湿器の、来年度の次版開発キックオフミーティングを３０分でやる」会議
- 会議のゴールは、チームに初めて入るデザイナーを含む、全員の顔合わせと、スケジュールの共有、会社の方針の再確認
そうすると、「営業と管理職から見て、大変有意義で創造的な議論に、毎度口をはさむ難しい組み込みエンジニア」というレッテルは正しいだろうか？
- デザイナーは、まだ名前しか知らない管理職と営業が雑談していると思っていた。短い会議だから軌道修正してくれて良かった。
- ハードウェアエンジニアは、営業の方向性は知っておきたいと思っていた。今後の方針に関わるのに途中で割り込まなくても……
- 営業は、会議前に管理職の意向を確認しつつアイスブレイクしていたと思っていた。なんだよ空気読めないな。
- 管理職は、人が会話を終えていないのに口を挟まれてムッとした。社会人としてなっていないな、客先には出さないようにしよう。
各人の判断は、正しいだろうか？
■■チームの大多数がそう思っていれば、そうなのでは？
人間力に頼る判断基準で多数決を用いるのは、エンジニアリングで無く、政治的な解決だと思う。
先ほどの会議の例でいえば、５人中３人が心理的な負担を感じており、不愉快な気分になっている。
チームの60%が「創造的な議論を阻害する有害な振る舞い」だと認定している。
その判断は、正しいだろうか？
この場合、組み込みエンジニアが、難しい人 or 有害な振る舞いをする人として、指導もしく排除されたとする。
それは、心理的安全性をあげ、チームの生産性をあげる行為だろうか？
例えば、今後デザイナーは、営業と管理職が「どのような雑談をどの長さでしていても」発言しなくなるかもしれない。
デザイナーからみて、その会話が創造的な議論か判断ができないからだ。
■有害な振る舞いをする機械に対して、アラートを出したいとき
さて、Web系のバックエンドエンジニアや、クラウドインフラエンジニアだと、アラートを設定したり、対応したいことがある。
「何かまずいことが起こっていることを、何らかの方法で監視して、対応したい」という場合だ。
例えば、待機系サーバーの起動時に妙に時間がかかっている場合、自動対応ができないので、アラートメールを飛ばして手動対応したいと思ったとする。
必要なのは「妙に時間がかかっている」を定義することである。
絶対値（10分）か、相対値（過去5回の起動時間の平均値）かは場合によるし、それが適切かはまた別の話だ。
■■アラートの基準を設定する
チームの創造的な議論を阻害したり他者の時間を奪う
他者の話に割り込んで自分の意見を差し込む
この基準が正しいとして、アクションに起こしたいとする。
「他者の話に割り込まない」というルールは、誤検知を引き起こしやすいアラートだ。
- 営業がこの間行った客先の話を会議の冒頭で10分間にわたり毎回しているときに、誰も口を挟めない
そんなのは常識で考えたらわかるだろう？曖昧な基準は「俺のは有意義な議論の発言だ」の判断を誰かが決めることになる。
大多数がそう思っていれば、という複合的な基準もありうる。その場合、先ほどの例の組み込みエンジニアは、アラート対象になる。
「会議のアジェンダに記載されている内容を3分以内で喋っている場合に、割り込まない」というのは、一つの基準になる。
この場合、営業が「営業概況を冒頭のアジェンダに加えて欲しい」と交渉する余地がある。
また「報告時間が10分は欲しいが、3回以上は一度会話を止めるので、営業概況に対する質問はその時に」という合意もできる。
- 営業概況ではない話をしている営業と管理職にアジェンダに沿うよう促してもルール違反ではない。
- デザイナーもアジェンダに記載してない場合は、口を挟んでも咎められないのだなと学習できる。
- アジェンダにあるのに営業概況の3分間に口を挟めば、それはルール違反だと指摘できる。
そして、顔合わせのキックオフミーティングで、営業概況をやるかは、会社やチームによる。
■とはいえ、そんなルールばかりにできない
明示的なルールで縛るのが正しいかと言えば、そうした方が良い職場もあるだろうが、窮屈な職場も多いだろう。
チームの創造的な議論を阻害したり他者の時間を奪う
他者の話に割り込んで自分の意見を差し込む
という簡単な話に見えることですら、ルールを作って守らせることに違和感を感じる感性も正しいと思う。
チーム（もしくはマネージャー）に求められるのは、こうした「何かチームに嫌な感じがある」ときに軌道修正できることだ。
一例でしかないが、例えば以下の流れでルールを作らずに、解決できることもある。
- 発言そのものにフォーカスする。「次の超音波加湿器の開発の議論を促す」のは会議の意図に沿うか？
- 口を挟むべきではないと思った人が、「それは口を挟んだ形になるので、自分は良くないと思うが、発言の背景は何か」と聞く
- 多少の雑談は良いだろうと合意する or 会議の目的に沿うように促すのは良いとする
■まとめ
コミュニケーションコストを、チームを維持するのに必要なコストとして、きちんと時間を割けるかが重要だと思う。
さらに言えば、「それは有害な振る舞いだと自分は思うが、あなたがそう思わない理由は何か」とコミュニケーションを取れないのであれば、そこに課題があるだろう。
チームやマネージャーがある人を「難しい人だなあ」と思ったとして、2つの解決策が出てこないのなら、その思考には課題があるのではないか。
- 該当する人を指導して振る舞いを変えさせる
- チーム側を指導、ルール作成して、振る舞いを変えさせる
「他者に配慮できる」という曖昧な基準で異物を弾くようなチーム作りは、蛸壷化して致命的な結果を引き起こすことがある。
パワハラ、セクハラ、試験結果改ざんが、「なんでそんなんなるまで誰も言わなかったんだよ」となるのは、
「その構成員が他者に配慮できる人たちで構成されていて、異物を弾き続けた結果」であることが多い。
少なくとも、「エンジニアの”有害な振る舞い”への対処法」には、機会、動機、正当化のいわゆる不正のトライアングルのうち、動機と正当化を満たしている。
いやいや極端だろと思うだろう？
快不快が、正しい正しくないに繋がっていることは社会生活を送っていると極めて多い。
「マネージャーならば」法律や外部の意見も含めてかなり慎重に判断する必要がある。
「エンジニアならば」相手に快適に聞こえるようにコミュニケーションするスキルは磨いておいて損はない。
（あと、機械的に判断可能なルールを守ることが自分を守ることに繋がる。ルール順守か業績なら、常にルールを守れ。記録を軽視するな）
部長が「当社の新卒～中堅は、業務やマネジメントは覚えてきてるけど、プログラミングはわからないし、SQLも知らない。情報技術を専攻してた学生もこない。ベンダーに言われるがまま。リリース判定でもベンダーがそう言ってるから…と報告してくる。そしてコンサルに転職してっちゃう」って言ってた。
SI屋さんって今でもそんな感じなのかしら
一般的な知名度は無いが、自由なソフトウェアやオープンソース・ソフトウェアの開発で数十年に渡り活躍してきたような大ベテランが、昔なら大目に見られていたような社会性の欠落が災いしてプロジェクトを逐われる、というのをいくつか見かけたが、時代の変化をしみじみ感じるなあ
いわばオープンソースにおける無法者、カウボーイの時代の終焉だな。基本的には良いことだと思うけど、ああいう変人奇人だったから金にもならないのにああいうコードがこつこつ書けた、というのは否定できないとも思うんだけどな。でもやるんだよ精神だな（わらい
俺は我ながら割と社会性があるというか妥協できる性格でつくづく良かったな（わらい 妥協できない人はうらやましいとも思うけど、生きづらいね
RMSがOSFから追い出されたり、リーナスが暴言を控えるようになったりみたいな話。
懸念するのは、強い個性と技術力と執念による一点突破のブレイクスルーが起きづらくなるのではという点。
革新的なソフトウェアは社会性が欠落した狂人が作ってきた事例が多く、社会性を備えた（良くも悪くも）協調性の高いエンジニアに革新性のあるソフトウェアが作れるのか？ については疑問がある。
ソフトウェア開発は未だ職人技の側面を強く残しているので、凡庸なエンジニアをどれほど集めても意味がない事は現状否定できない。
ソフトウェア開発にポリコレを求めた結果、「異能」と言ってもよいエンジニア達の能力と成果をスポイルするのであれば、人類の進歩を妨げるという点でポリコレは明確に不要で害悪である。
モダンなダイアグラム記述言語ということらしい。PlantUMLやMermaidの亜種という感じか。
AWSは、ローカルマシン上にLinuxコンテナのランタイム、ビルドツール、コマンドラインツールなど一式を簡単にインストールし、コンテナを用いた開発環境を開始できるソフトウェア「Finch」をオープンソースで公開しました。
現時点ではIntelプロセッサもしくはAppleシリコン搭載のMacにのみ対応しますが、今後WindowsやLinuxにも対応する予定です。
今回、AWSがオープンソースとして公開した「Finch」は、こうしたコンテナを用いた開発環境をオープンソースのソフトウェア群を組み合わせることで簡単に構築し、コマンドラインから利用できるようにしたものです。Docker Desktopによる簡単な環境構築を代替し得るものと言えます。
具体的には、macOS上にLinux仮想マシンを構築する「Lima」、Limaの中にデフォルトで含まれているコンテナランタイムのcontainerd、ビルドツールの「BuildKit」、Dockerを用いなくともDockerコマンドのようにコマンドラインからcontainerd経由でコンテナを操作できる「nerdctl」（nerdctlのnerdはcontainerdのnerd）などが用いられ、FinchによってmacOSの上に簡単にコンテナ環境が構築されます。
これによりmacOS上でコマンドラインからコンテナのビルド、ラン、リポジトリへのプッシュ、プルなどが可能になるわけです。
Docker Desktopの立場がどんどん悪くなっていくな。
コメントは背景から書く
要約変数を使う
説明変数を使う
モジュールに切り出す
早期リターンする
横断的関心事はAOPで外出しに
不変型（immutable）を使う
カプセル化
レガシーコードを隠蔽する
凝集度と結合度
継承は基本的に使わない
無理に共通化しない
Dependency Injection（DI）
Dependency Inversion Principle(DIP)
ジェネリクスを使う
アーキテクチャーを参考にする
自動生成に頼る
我々の業界で管理画面とか管理ツールと呼ばれるやつを自動生成してくれるOSSらしい。
React/Next.jsベースのフロントエンドに加えて、DBのスキーマを自動的に読み込んでいい感じのコードを生成してくれる模様。
RalisやLaravelみたいなサーバサイドのフルスタックフレームワークを殲滅できたりするだろうか？
私がAndroidに見切りをつけている理由、それはまずOSバージョン問題です。Google謹製以外の端末は長くて2年、下手するとたった1年でサポートが打ち切られます。セキュリティ問題はそのまま放置。10歩譲って数万円の端末なら諦めも炊きますが、10万円近い、あるいはそらより高価な端末のサポートが
これでは、あまりにお粗末です。古いOSバージョンが残り続けている市場では、アプリ開発にもその制約を受けます。未だに物理的な戻るボタンに対応しなければなりません。また多種多様な液晶に加え、遅延のでかいサウンド再生端末もあり、開発サイドとしては最大公約数的な仕様で制作になります。
あと、期待した Android Auto は、Google と一部のメーカーにしか全ての API を公開せず、はっきり言えばつまらない対応に留まっています。今は少しずつ公開しているそうですが、なぜそんな出し惜しみのような事をしているのか。モノがクルマだけに…というのなら、自社制作アプリも同じ事が言えます。
結局、突き詰めていくと Andoird 端末が、というよりも、Google の思想が気に入らなくなったと思っています。だったら、割り切って閉じた環境に徹している Apple 端末の方がマシと現在は思っています。これなら全ては純正端末です。
最近は Apple も多種多様にはなっていますが、Google のそれとは比較になりません。結果、iOS 対応アプリの方がより洗練された実装になります。
以上が私の感想です。
元々スマホは3-4万円ぐらいの価格設定の商品として想定されていたように思える。高級機が5-6万ぐらいみたいな。
で、それを2-3年で次々乗り換えていくような消費スタイルを前提にサービスが設計されていたように感じる。
Googleアカウントに全てを統合して新しい端末でもスムーズにデータ移行ができるなんてのはその象徴。
ところが、様々な理由（半導体不足、端末の高性能化要求、ニーズの多様化etc...）で端末自体が高価格化した結果、元々想定していたものとは違うものになりつつあるというのが問題の元凶とでもいうか。
そんな消費スタイルの想定自体に問題があるだろという議論も当然あるのだが。
Javaの
1. 1ファイルにpublic classは一つ
2. public classのクラス名がファイル名
という制約、英断やけどめちゃくちゃすばらしい秩序だと思う。
「自分の代わりに書いてくれてた続き」を追加ｗ
3. パッケージ名とディレクトリ名が対応可能
4. パッケージ名とFQDNが対応可能
というのも加えてくだされ
#フォロー外から失礼いたしました
これは本当にそう思う。JavaやPHPをやっていた人がPythonやGoでまず戸惑うのはここじゃないだろうか。
ただ、PythonやGoにおいてはクラスや構造体は主役ではないという事情も大きい。
JavaやPHPは言語仕様やフレームワークの制約でまずクラスを定義する必要がある（ことが多い）が、PythonやGoは関数が主役となるスタイル。
なので、Javaのようにクラスを接頭辞（あるいは名前空間）と見なすことができない。
そこで、接頭辞（あるいは名前空間）の役割をファイルに担わせている。
前提とするスタイルの違いが言語設計に現れているということだな。
科学とは何かに定見はないですが、学問とは何かについて「これはないな」と思うのは、特定の文献を読まないことが推奨されたり、読むことが推奨されてる特定の文献について「正しい解釈」が検証不可能な過程で決まったりしていることですかね。信仰や運動と学問を区別する大事なポイントかと思います。
要するに禁書や聖典が存在するかどうかですね。
ソフトウェア・エンジニアリングの界隈には「聖典」扱いされる本もあれば、「禁書」扱いされる本もある（勿論、本気で言っているわけではないが）。
エンジニアリングは科学的・学術的であるべきだが、一方で実務上の問題解決手段でもあるので、思想（問題の捉え方）や啓蒙活動/運動など宗教的な問題に近しい性格を帯びることが多く見られるのが面白い。
そう考えると、ソフトウェア・エンジニアリングはまだまだ科学の域には到達しないのでなかろうか。
2010年くらい以降にできた言語、go、rust、kotlin、swiftがあって、kotlin、swiftはJava、objective-cを引き継ぐためにクラスがあるけど、しがらみなく作られたgo、rustにはクラスがない、というのが、オブジェクト指向やめようぜ論の答えなんだよな
「オブジェクト指向をやめよう」ではなく「継承をやめよう」だと思うのだが。
ユーザー定義型とメソッド（レシーバ）はあるので、データと操作をまとめて扱う方のオブジェクト指向はがっつり残っている。
まぁ、そういう事言うと「オブジェクト指向の定義とは〜」みたいな話に発展して最高に不毛なので近寄らない方がよい。
アメリカのテックの構図は基本的にリストラくらったら速攻国外退去しないといけないH1-B勢が死にものぐるいでシステムの根幹を支え、その取り巻きに何かスタバでESG語ってそうなᶠᶸᶜᵏer WASP文系達が群がるというのが基本構図でございます。
かなしい
前に総研大の先生方と話した時に，昆虫は脳も凄く小さいし，眼も人間と比べたら殆ど見えてないけど，移動物体の回避も平気でこなすし，蝶に至っては大陸横断するのもいると聞いて，汎用AIとか言う前に昆虫がどうやって異常に少ない計算で，実世界で適応的に振る舞えているのか考えた方がいいと思った．
GPUやビックデータでどうこうみたいなのは明らかに方向性としておかしいし，極端に非効率なことをやってるんだろうなと思う．スケールするかどうかとかそういう問題ではなく，根本からおかしなことやってるんじゃないかという．これは，福島邦彦先生も同じようなことをIEEE CISの講演で仰っていた．
これは確かにそうかも。
SQLiteの最新版となるバージョン3.40がリリースされました。本バージョンからSQLiteのソースコードがWebAssembly版の「SQLite3 WASM/JS」へのコンパイルをサポートし、配布される公式のバイナリにLinux版、Windows版、Mac OS X版、Android版などと共に「SQLite3 WASM/JS」が含まれるようになりました。
ドキュメントによると、今回のSQLite 3.40のSQLite WASM/JSはパブリックベータとしてリリースされ、コミュニティーのフィードバックを待って3.41で暫定的にAPIが安定版となるとのこと。
スタートアップの従業員が「ハードコアに」働くのは、ストックオプションを行使してFIREするか、なにか価値があると思えることに全力投球するからであって、億万長者を更にリッチにすることではない。
しかし彼が今経営しているのはTwitterである。Twitterは火星行きのロケットではない。更にひどいことにスタートアップでもなく、横暴なビリオネアによって気まぐれにレイオフされる、単なる「ハードコアな」プライベートカンパニーだ。
個人的見解としては、Twitterが今すぐ全面的に使えなくなることはないとは思う。Twitterはすでにmac miniでホストされるモノリシックなrailsアプリケーションではなく、高度に分割されたマイクロサービスの集合であり、これまでのSREの遺産もある。
ただ、ゆっくりと不具合が増え、イーロン・マスクの気まぐれはうまく行かず、時々落ちるようになり、長期のダウンタイムが発生した時に人々が見放す、という形で死んでいくのではないだろうか。あるいはセキュリティインシデントが起こる可能性もある。
すべての死がそうであるように、サービスの死もまた予測不可能だ。その日は急激に訪れ、明日かもしれないし、ずっと先に訪れ、緩慢なものかもしれない。ともあれ、イーロン・マスクが自らの行動を改め（彼のエゴを粉々にして）、何かを変えない限りは、それは確実に訪れるのだろう。
Twitterのシステムに関する今後の展望については同感である。
人々がサービスから離れるかについては、現状だと代替サービスが無いように見えるのと、Twitterの基本機能（書き込みとタイムライン閲覧）さえそれなりに機能しているなら、大半のユーザーにとっては別サービスに移行する強い動機は無さそうに思える。
Twitterのユーザー数は2億人以上らしいので、広告を出稿する企業にとってもそのユーザーベースは引き続き魅力的であり続けるだろう。
であるならば、Twitterにとって最善の戦略は最小のコストでシステムを動かし続けることになるので、アメリカ国内でエンジニアを雇うよりインドやベトナムにアウトソースを進める方が合理的、ということになるのかもしれない。
その辺は時間が経てば分かることだろう。
「Manifest V3」は新しい拡張機能の仕様で、APIの簡素化と統合、セキュリティとプライバシー保護の強化、モバイルプラットフォームへの対応改善などのメリットがある。「Firefox」だけでなく、「Google Chrome」や「Microsoft Edge」などでもサポートされる。
一方、MV3に関しては広告ブロッカーなどの拡張機能が開発しにくくなるのではないかとの懸念もある。これは「Chrome」や「Edge」が「Web Request」のブロックに代え、「Declarative Net Request」（DNR）と呼ばれる仕組みを導入したため。「Web Request」による通信を拡張機能が自由にブロックできてしまうと、拡張機能が何をしているのかがユーザーにわかりにくく、万が一の悪用を防ぐのも難しい。しかし、あらかじめ（Declarative：宣言的に）ブロックルールを登録しておくDNRならば透明性が高く、拡張機能からユーザーデータを保護するのが容易で、パフォーマンスの最適化もWebブラウザー側で行えるというのがその理由だ。
しかし、「Firefox」では広告ブロッカーなどの拡張機能にも配慮してか「Web Request」のブロックが引き続きサポートされる。とはいえ、DNRのメリットも少なくないので、将来的にDNR互換の機能を実装する予定。
Twitterのコア開発者が辞めたのでTwitter終了←まちがい
Twitterのコア開発者が辞めたので代わりの開発者を雇わないと数年で終了←せいかい
ソフトウェアは腐りますけど、だからといってメンテナンスしないと1日で腐り果てるほど脆くないんですよ。そのせいでメンテナンスせずに数年経って腐り文字数
腐り果てたソフトウェア資産をなんとか再構築するお仕事がごくまれに飛んできて死ぬんですけど。
開発者が辞めてノータイムで破綻するシステムだとしたら、その開発者をクビにするのはやはり正しい判断だったとしか言いようがない。
今後数ヶ月〜数年掛けて色々手を加えていくにつれて歪みは出てくるだろうけど、そこら辺は新しく雇ったエンジニアで再実装すればいいしそれぐらいのキャッシュはあるだろな。
というわけで、Twitterが終了云々というのは願望の類でしかないのだろう。
Browser Rendering APIを用いることで、開発者は自分でヘッドレスブラウザやPuppeteerのインストールや運用などをすることなく、Cloudflareのデータセンター上で実行されているヘッドレスブラウザのプロセスとPuppeteerをCloudflare WorkersのAPI経由で呼び出せます。
そのため、Webブラウザ上に表示される画面のスクリーンショットを定期的に取得してメールをするプログラムや、Webアプリケーションの自動テストのためのプログラムなど、Webブラウザの操作を自動化することで可能になるさまざまなアプリケーションをすぐ実行できるようになります。
しゅごい
いい話だ。
「立身出世し続けなければならない」というプレッシャーを掛け続けられるの本当だるいんだよな。
Metaが10年間にわたり開発・使用してきたソースコード管理システム「Sapling」がオープンソース化されました。Git互換で基本的なコマンドは類似しており、すべてのコマンドがシンプルで使いやすいように設計されているとのこと。Saplingは2022年11月15日から一般向けに公開されています。
SaplingはもともとMeta(Facebook)が社内向けの大規模なモノリシックリポジトリ(モノレポ)をスケールアップするために取り組み始めたプロジェクトでした。Metaで使われるような大規模リポジトリの管理は一般的なソースコード管理システムでは難しく、リポジトリの分割も機動性の観点から現実的ではなかったそうです。そのため、フリーソフトウェアであるバージョン管理システム「Mercurial」の拡張としてSaplingをスタートさせ、独自のシステムへと急速に成長させていったとのこと。
逆に言うと、大規模なモノレポを使い倒しているプロジェクト以外ではgitに対する優位性は無さそうな感じだろうか。
すべてのIT企業は肝に命じてもらいたい。
仕事が忙しくて無理する状況になってしまうのは避けられないこともある。
でもそのときにエンジニアが「なにくそ！」と頑張れるのは、社長や執行役員含め会社としてのチームメンバーが「いい人」だった場合に限るからな。
「嫌な奴」だと、
「まー、あんなクソどものために無理して頑張ることないよね」と最後の踏ん張りが効かなくなる。
会社の成長は大いに結構。
だが、実際に手を動かすのは感情が乗った人間。
会社と労働者は、ただの契約で繋がった赤の他人。
他人のために命を張る筋合いはそもそもないんです。
良い人たちがいる案件だと、むっちゃ忙しい時期に何を思うか。
「チームのみんな（もしくは特定の誰か）のためにガチでやってやんぜ！」となるんです。
システムのユーザーや株主のためじゃない。
会社の評価のためでもなく金のためでもじゃない。
一緒に頑張る仲間のために頑張るんです。
これがわかってない企業が多すぎる。
今まで17案件くらい関わってきましたが、そう思わせた案件は2件だけです。
ソフトウェア開発って案外感情労働の側面が強いものなのだ。
アメリカ国家安全保障局（NSA：National Security Agency）は、ソフトウェアのメモリ安全性に関するガイダンス「Software Memory Safety」を、11月10日（現地時間）にリリースした。
同ガイダンスは、近年のサイバーセキュリティ脅威の多くに利用されている、ソフトウェアのメモリ安全性の悪用を防ぐことを目的としており、組織におけるソフトウェアの開発にあたっては、可能な限りメモリ安全なプログラミング言語を使用するとともに、コンパイラのオプション、ツールのオプション、OS構成といったコードの安全性を高める対策を施すことで、保護を強化することを推奨している。
メモリ安全でないプログラミング言語としては、一般的に使用されているCやC++を挙げており、これらのプログラミング言語はメモリ管理において高い自由度と柔軟性を提供する一方で、メモリ参照が安全に行われているかどうかのチェックはプログラマに大きく依存していると指摘する。
同ガイダンスでは、メモリ安全なプログラミング言語の一例として、C#、Go、Java、Ruby、Rust、Swiftなどを挙げる。[...]
GUIでDockerコンテナやKubernetesの操作を可能にするオープンソースの「Podman Desktop」がリリースされたことをRed Hatが発表しました。Windows、Mac、Linuxに対応します。
Docker Desktop、将来的には消える可能性高そうだな。
現場の話をすると、プログラミング力のない人の要件定義はそもそもプログラミング力を活かした設計にしないんよ。
例えば縄文人に要件定義させてもガラスのコップを使いたいとか絶対に言い出さないんだよ。作る技術ないし、活用の仕方も分からないし、作らせる話すら出来ない
いくらかアルゴリズムをやった人間が要件定義するとその部分が難しくて作れる人が居ないみたいな事にもなりがちなのでアルゴリズム任せれる部隊とかあるなら欲しい
私の経験上、頭の良い人の書いたコードは凄く汚すぎてなにを書いてるのか分からないか、抽象度が高すぎてどこになにがあるのか分からないかの二択。どちらにせよ他人がメンテナンスできなくなる問題があります。
私はそこまで頭が良くないので自分がメンテナンスできる複雑さでコードを書くようにしています。
これはあるある。
コードが汚かったり、抽象度が高すぎてよくわからんことになるのは、頭のいい人はそういうコードでもワーキングメモリの広さでゴリ押しできるからなのだが、ワーキングメモリの広さは個人差が大きい上に見た目からはわからないのが難点である。
しかも加齢で機能低下する機能の筆頭。
ワーキングメモリに優しいコードの書き方はSLAP原則などが参考になるだろうか。
OpenTelemetry調べてみるか
確かに明快で筋が通っている。
まず第一に、Musk は、Twitter をメディア企業からエンジニアリング企業へと変質させようとしているんじゃないかと考えています。これは、「どの部署がレイオフ対象になったか」から見えてくることです。TechCrunch の記事によれば、米国でレイオフ対象になった主要なチームは、アクセシビリティ、機械学習倫理 (META: ML Ethics, Transparency & Accountability)、人権、キュレーション、PR (Comms)、SRE (Site Reliability Eng) などです。一方で Home Timelines や Health Eng など Twitter のコア機能の開発側チームや Trust & Safety、あるいは Account Integrity まわりのオペレーションなどは、米国ではチーム単位で丸ごとなくなるといったことは起こっていないようです（インドなどの海外オフィスでは、「オフィスごと解雇」のようなことが起こっているようですが）。[...]
ここには、「読者に何が起こっているのかを知らせる」ためのニュースアプリとしてのミッションではなく、「自由な発信と議論が行われる脱集権的なプラットフォームを作る」という、「発信側」に重きをおいたミッションが透けて見えます。
だから、今後の方向性として、「広告モデルからの完全な脱却」と、「より脱集権的なあり方」の模索があることは間違いありません。まずは Blue Check など現在 Elon が試しているようなビジネスモデルの新たな形を模索しながら、Twitter のコア機能の開発に注力するような形になるでしょう。Twitter そのものによる AT Protocol の採用もありうるかもしれません。Jack はそもそも Twitter が会社であることが間違いであるという思想の持ち主ですが、Elon は会社として存続させ、ある程度のところで再度上場することを目論んでいます。もし「発信側」に重きを置いたミッションを持った、エンジニアリング企業としての Twitter が成功するのなら、Elon が思い描いた通りになるでしょう。それがどれくらい可能なのか、Elon がこれをうまく実行できているのか、は別の議論です。
SREを解雇するのは大丈夫なのか？ という疑問はある。
昔は何処にでもガンガン売ってたのにどうしてこうなったんだろ？
技術的負債が問題と言っているが 本丸は文化的負債では
技術選定が合理性ではなくエンジニアの個人的お気持ちや「次の転職」に向けた箔付けのためで、それを制御できないマネジメントや組織統制に本質的な問題があるケースはよく見る。
まぁ、その辺の化かし合いは人間社会の常なので仕方無い面もあるけれど。
SEOハックが常態化した結果、Googleの検索結果の信頼性が低下、結局は同じ興味を持った人々のトレンドを追えるSNSの方が相対的なS/N比はマシじゃね？ ってなるの、まぁWEBの進化の方向性としてはそんなもんかという感はある。
次世代の半導体の開発競争が世界的に激しくなる中、トヨタ自動車やソニーグループ、NTTなど日本の主要な企業8社が、先端半導体の国産化に向けた新会社を共同で設立したことが明らかになりました。経済安全保障上、重要性が増す先端半導体の5年後の量産化を目指すことにしています。
悪いことじゃないと思うけど、また奇妙な日本企業ムーブして全てをオジャンにする不安が拭えない。
最新版 (バージョン2.3.0) のみおふぉんダイアルアプリにおいて、起動時にクラッシュするケースが見られるという。
IIJによると、原因はアプリプログラムの不具合とされ、現在は対応作業中としている。
上記事象が発生しているユーザーは、改善までの間は端末標準搭載の電話アプリを利用することが推奨されている。タイプAを利用中であれば、電話番号の先頭に0037691を付与することで、割引通話を利用できる。
なんか起動時にエラー吐いて終了すると思ったら普通に不具合だったのか。
俺も含めてだけど、
経験豊富でマトモなエンジニアは質問する時
「～～端的な質問～～、
何を気にしてるかというと～～質問に至った経緯や、想定される懸念事項～～」
って言う構文をよく使うんよね。
これも一つの「結論から述べろ」の亜種で、
なんであっても「端的な事実」を先に利き手に渡してやり、
ディテールはその補足として後から説明したほうが解り易い。
という事。
ダメな奴は最初からディテールを説明し始めて、
話がどこを向いているのかベクトルも定まらないまま延々ダラダラ喋る。
適当な情報工学の教科書でも持ってれば十分な気がするので自分も受験してないな。
正確には一度受験しようと申し込みはしたけど、当日起きれなくて断念したのだけど。
あと、社会人は記憶力で勝負する意味はあまり無いと思っていて、情報工学の教科書が手元にあっていつでも参照できるなら知識的な面はそれで十分なのではと思っている。
実はコンピュータを無駄に光らせる歴史はかなり古く，黎明期から計算機について無知な役人を説得するためにコンピュータを意味なく光らせることは行われてそうだ，
「光らせることは行われてたそうだ．」と書きたかった．ENIACに飾り電球があったという話です．
そういう目的もあるし、「光っているべき部品が光っていない」ことで故障を検知できるという実用上の目的もあった。
飾り電球というより、通電ランプみたいなイメージか。
結局、要件を高い精度でまとめる事はできないので、小さなプロトタイプから始めましょうというのは定番の助言なのに、何故か人間はいきなり巨大プロジェクトを立ち上げて大火傷することをやめる事ができない。
クエリに Datalog を使用し、埋め込み可能で、グラフ データとアルゴリズムに重点を置いた、汎用のトランザクション リレーショナル データベースです。
- クエリ言語として Datalog を使用するリレーショナル データベース
- 再帰クエリ、(安全な) 集計による再帰、複雑なグラフ操作とアルゴリズムを表現できる
- Datalog とシームレスに統合する効率的な全グラフ アルゴリズムの固定ルール
- 組み込み関数と集計の豊富なセット
- 任意のプログラミング言語から、またはスタンドアロン プログラムとして簡単に使用できます。
- Python、NodeJS、および Java 用のすぐに使用できるバインディングを使用して、埋め込み可能
- 単一の実行可能なスタンドアロン サーバー、展開と実行が簡単
- Jupyter ノートブックの統合は、DataScience エコシステムとうまく連携します
- モダンでクリーン、柔軟な構文、有益なエラー メッセージ
SQLの替わりにDatalogなるクエリ言語を採用したリレーショナルデータベースということらしい。
Datalogの表現力や機能がSQLより優れているぞということみたい。
興味はあるが、SQLが使えないのはアプリケーションのバックエンドとしてかなり大きなハンデになってしまう予感があるな。
そう考えると、設計書要らない！！ よりは設計書 as Code のほうが筋がいいかもしれない。インフラすらコードにできるのに設計書がコードにできない道理もないし、ステート変化の記述とか明らかに静的検証向きだから型システムの恩恵を受けたいしコードなら実装と自然に協調できる（？）
クライアントとサーバーという異なる場所のコードをつなぐものとしてAPIがありAPIの定義はコード化されている昨今、これを延長していけば目的のものが得られないかな（？）
そもそもプログラミング作業の成果物はソースコードではなく、実行ファイルのバイナリやコンテナイメージなので。
ソースコードこそが設計書なのだ。
マーティン・ファウラーもそう言ってる（権威論証）。
次に、VBを開発言語として採用しちゃう業界の問題。
上記のような業界は、どうしてか悪い日系IT企業の悪いところ全部盛りになってしまっているんですよね。
- コードに変更加えたら、変更前のコードはコメントアウトして、コメントに日付書け。バージョン管理？なんですかそれ
- 一つの画面のコードは一つのファイルにしろ。OOP？クラス設計？デザインパターン？横文字むずかしいね
- グローバル変数！参照渡し！副作用たっぷりメソッド！単一責任原則？DRY？カプセル化？変更容易性？マネジメントの話ですか
自分が最初にアサインされたプロジェクトの環境が良すぎたっていうのはあります。左記のプロジェクトは技術検証っていう名目の自社開発で、かつチームのメンバーが、プログラミングに対してそこそこ意識が高い人達だったので、新入社員だった僕が「いいコードとはこういうコード」を学ぶには絶好の環境でした。実際、コードレビューも充実していましたし、自分の直属の先輩も設計やプログラミング手法といった抽象的な観点をたくさん提供してくれました。だからVBに対して、特に悪い印象は抱いていなかったのですが……。
この秋からアサインされたプロジェクトは、もうやばいです。上記のとおりです。ドキュメントなんてあるわけないし、頼みのコメントは' 変更 2000.01.01 XX. T.Yamadaみてえな。いらん、そのコメントは。'☆ ここにコメント ← あと謎に☆つける文化。なんだこれ。
それはもう、一日が経つのがおそいおそい。自社開発期は毎日アレコレ勉強して、調べ物して、試行錯誤して…だったのであっという間でしたが、今は前任者が残したクソコード（ドキュメントなし）と8時間にらめっこです。
とはいえ、アサインされてしまったものは仕方がないし、二ヶ月というお約束までついているので、むしろ「バッド・ノウハウのお勉強」だと思って最近は業務に就いています（先輩の受け売り）。このページにも書いたようなフラストレーションが、きっといつかの品質向上につながってくれるでしょう。つなげるのは僕だけど。
20年前から全く進歩してない開発現場が未だに存在するのシンプルに戦慄するな。
寿命の長いシステムをメンテナンスしているSIerがニッチに過剰適応して生きた化石になるというのは、それこそ20年前から見た光景だが、そこに若者をアサインするのは犯罪的である。老人達がきちんと最後まで看取るべきだろう。
プログラミング言語の覇権が定期的に入れ替わる理由は、あるプログラミング言語のニーズが高まると質の悪いエンジニアが大量に流入してきてとんでもない技術的負債を作り上げるので、新しい言語を学ぶスキルやモチベーションのあるエンジニアが別の言語に脱出を敢行するためである。
VBという言語が悪いのではなく、それしかできない・進歩しないエンジニアが悪いということであるな。
本当に例外を使うべきか考える
ビジネスロジックにおけるエラーは「例外」ではないはず、とまず考えたい。たとえば、ユーザーが変な値を送信してきたときにそれを不正としてエラーを返すのは、例外的ではなく想定内のはず。別の側面だと、例外は制御構造から大域脱出するので、多用するとコードを読むときの負荷を高めうる。
モデル層で適切にビジネスロジックを書く
ビジネスロジックに関するエラーをコントローラで処理するようになることが問題の原因だと書いた。ビジネスロジックに関するエラー処理をモデル層でやるためには、RailsのActive Recordのモデル（つまり、アクティブレコードパターンに基づいたDBのテーブルに対応しているクラス）だけではなく、必要に応じてふつうのクラスを作るようにする。そして、そのなかでエラー処理をやる。Railsならプレーンなクラスでもいいし、コントローラやビューで使えるようにするならActive Model (ActiveModel::Model)を使ってもよい。
このようなクラスをうまく作るためには、リソースだけではなくアプリケーションにおけるイベントもモデルとして抽出したり、ユースケースを見出してクラスにする必要がある。
政府は、マイナンバーカード交付時に入れる透明ケースの配布廃止を検討している。ケースに入れると、個人番号が隠れる仕組みになっているが、番号が知られただけでは悪用されないからだ。配布廃止により、マイナカードに対する正しい理解を促す。
マイナカードを紛失した場合、コールセンターに連絡して、第三者による悪用を止める必要がある。ただ、マイナカードには顔写真が付いており、利用には本人確認が必要になる。インターネットで使う場合も、事前に設定した暗証番号を入力しなければならない。
個人番号は、必要な場合を除き、他人に教えないよう定めている。総務省によると、個人番号を他人に見られることを心配する声もあって、交付開始時からケースを配っていたという。政府関係者は「金庫で厳重に保管する人もいるが、その必要もない」と話している。
なんだかなぁ
エンジニアに知識として足りないのは自分達が作っている商品としての成果物にかかるコストが人件費も含めていくらかかるという具体的な感覚と、自分達が顧客と考えている市場規模、そしてそこからいくら取れるのかという部分、そして顧客からお金を貰って自分達はモノを作ってるという意識だと思う。
顧客から作り手が正しいと思う対価を貰う為には顧客にその価値の正当性を伝える必要があるのは商売としての根本部分であってここは今の所大きな変化はない。価値を提示できそれが妥当だと判断されれば顧客はお金を出すし、提示できなければ正しく価値提示をできる所に流れる。世の中はシンプルだ。
事にソフトウェアエンジニアが自分達の仕事が作ってみなければ価値を伝える事ができないというのであればそういうビジネスモデルを作っていくしかない。ただその場合は作り手の企業としては相応のリスクを伴う。そりゃそうだ。相手からしたら自分達の希望の物が最後までその価格が見えないんだから。
そんな状態では相手は作り手側にお金を最初から渡すなんて事はできない。永遠に増額を要求する可能性がある企業に対してお金を払うなんて話は当然出す側の企業内で簡単に通らない。結果それなりのものをそれなりの時間と価格で提供できるという企業にお金は落ちていく。
もしソフトウェアに違いがあるとすればそれは色んな業界で作っている顧客への提示のサンプルがリッチだと言うだけである。その一方でそのサンプルを作る為のコストは当然高くなる。しかし顧客はサンプルを見て依頼するか決めるのであればそこのお金はサンプルを作る企業持ちになる。そりゃそうだ。
お金を払う側は当然いくつもの会社に依頼をかけて最終的に適切だと顧客側が思う企業にお金を落とす。その為にはでもサンプルだけでは当然ダメで、それはあくまでも一部。実際は全体像も費用も全部見積もられてそれとセットで初めて顧客は期待値を満たしているかどうかの価値判断をする。
そういう観点で考えた場合、コードは顧客に提示する図面にはあたらないよねと個人的には思う。コードは顧客に提示した所で理解されないから。ビジネスで考えたらコード自体に価値はない。フロントエンドのサンプルを作る道具でしかない。
そしてサンプルも顧客にとって全体を把握する道具にはならない。ソフトウェアはUXだけ見ればわかるものではないから。結局の所、コードは図面にならないと言っている人は顧客を獲得する為の観点で、コードが図面でビルドが組み立てと言っている人達は顧客から仕事の受注後の話をしているのかなと思う。
どちらにしても、ソフトウェアも何だかの方法で顧客に対して正当な対価であると納得させる方法は必要でもし受注の前にサンプルだけを作って見せると言う手段だけでいくなら正直双方ハイリスクな商談なのであまり好まれないだろうなと思う。規模の大きい案件なら尚更そうだよねと思う今日この頃です。
そういう意味では最近のソフトウェアエンジニアのマジョリティはITソフトウェアエンジニアって事で、Webベースかスマホなどのフロントエンドがあるからそういう思想になるのかもなぁと思う。組み込み系だと物理UX、基幹系だとそこは本質じゃないのでサンプルって簡単じゃないんだよなぁ。
サイボウズのマネジメントについて書かれた「最軽量のマネジメント」を読んだ時に「社員がやりたい事を決めれるなら、（相対的に）不人気プロジェクトに人間をアサインする時はどうしているのだろう？」という疑問があったのだが、結局あんまり上手く回らなかったのだろうか。
DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。
・デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
・変更のリードタイム - commit から本番環境稼働までの所要時間
・変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
・サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
短いコードのほうが読みやすい傾向はあります。しかしながら、 短くて誤読しやすいコードよりは、長いけど誤読しないコードのほうが可読性が高いです。 今回はその話をします。
ヨドバシのクラウドは余剰リソースができたら是非国産クラウドとして、Yodobashi Rental Platform - YRPとして売り出してほしいし、政府に選定されてほしい
YRP...うっ、頭が...
侵入経路が気になる案件
久しぶりに炎上案件の火消しに入って数週間。本日なんとか無事に役員報告を終え一息つく
自分がPMのプロジェクトは燃えないので(過信)、炎上対応は相当久しぶりだったけどなかなかスリリングではあった
思うところもいくつかあったので、つらつらと書いてみる
◼️引き継がれた資料
アサイン時、消えた前任者が残した資料をまず読んでみた。どの資料も同じ特徴があって、クライアント名を書き換えればそのまま他社でも使える内容だった(=汎用的な内容しかない)
フレームワークはとっかかりでしかなくて、そこからが勝負なのに見事に逃げていた。議論が滑るわけだ
◼️クライアントとの空気
まずは参加だけでも、と言われ同席した会議では、クライアントから自社メンバーがずっと詰められていた。期待値を全く理解してない、損害賠償ものだ、など怒号が飛び交う。なんと自社メンバー側も反論してキレてる。詰めと言い訳な時間使われ本題に入らず時間だけが過ぎていた
◼️残されたスタッフ
飛んだのはシニマネだったため、スタッフはそのまま残っていた。これ幸いと成果物について質問すると、内容について全然答えられない。話を聞くと、与えられたスケルトンの通りに作っただけだと。自分が書いている資料の内容を理解しないまま手を動かしていた
こうなったのにはきっと要因がいろいろあって、前任者も不慣れな中で頑張ってたとは思うんだけど、とにかく誰も頭を動かしてないのが一番気になった。本番リリースが迫ってるのに、ふわふわ資料と空中戦と不毛な会議に時間を使ってて誰もおかしいと思わないのかと
ということで建て直しスタート。まずはチームのスタッフから。「明日本番稼働になっても大丈夫なように」をキーワードに、これから作るものはすべてもう後続はないこと、解像度高く具体化しないと持たないことを伝えつつ、間違っててもいいからまず答えを出すまで頭を絞ってほしいことを懇願
イメージが沸いていない作業については徹底的にトランスファー。上流だけの経験者や、設計開発だけ強くて本番リリースのイメージがついてないメンバーも多い。自身の経験や事例資料を多く使い、各工程でのやるべきことの解像度をとにかく高めて、考える材料を提供しまくる
参考事例も、これまでのPJ状況もかき集め、全く進んでいなかった全ての成果物を数日で作り上げた。仮説も多いが、これなら本番は迎えられるだろうと言えるくらいの資料ができた
上流系の案件で、開始前にまず最終報告の骨子を作ってしまうってのがあるけど、それに近い。ようやくスタートに立った
あとはクライアントとの討議。「明日本番になっても」という気持ちで作ったこと、一緒に明日本番の気持ちで考えてほしいこと、文句があったら後でいくらでも謝るので、会議では中身の議論に集中してほしいことを懇願
誰も詰めてこなかった
前向きな意見や参考情報をたくさんくれた
討議は課長、部長、本部長…と、遠回りなようでも徐々に拡大しながら進めていった。しっかり意見を聞き、間違ってたところは素直に謝り、意見・支援を求められたら担当範囲から少しくらい出てても全力対応した
クライアント側から相談を受けることが多くなり、討議を進めるほど味方が増えてきた
また、このころにはもう、スタッフへの指示だしは殆どしてなかった。する余裕が無かったというのもあるけど、みんな会議内容を基に互いに議論し、考え抜いたものを持ってきてくれた。自分は打合せの前にざっと読んで軽く手直しすればよかった。ちゃんと答えを出してくれていた
そして今日、役員報告を迎えることができた。本部長以下は全員味方してくれた。役員からもお褒めの言葉をいただけた
まだ課題は残ってるし、作業的にはこれからが佳境だけど、なんとかなりそうな気もしている。周りに恵まれた所もあるけど、少しは自分を誉めてもいいかなと思ってる。今日は飲むぞー！
フロントエンド界隈はいつまで戦国時代やってるんだ感はある。
むしろuseなんてのはReactをむしろ簡単にしていると思う。「Reactコンポーネントよ外でPromiseを用意すればよしなにやってくれるよ」ということだから。
変にコンポーネントにフェッチの責任持たせてuseEffectとかやっていた頃がむしろ古くて複雑な仕組みに見える（？）
個人的にはReactはライブラリだという説をまだ捨てていないので、Reactを何でもやってくれるフレームワークだと思うと振り回されるように思うかもしれないなとは感じている（？）
スーパーエンジニアが内製ミドルウェアを開発したものの、スーパーエンジニアはその実績を土産に転職していき、ロクにメンテされずに負債となった内製ミドルウェアだけが残る現象、名前あるのかな
きちんとメンテされている内製ツールや内製ミドルウェアもたくさんあるし、内製ミドルウェアそのものを否定する気持ちはないです。意思決定の時は、目の前の課題を解決できるかだけじゃなくて、中長期的に新しい問題がどう生まれうるか、それにどう対処するか考えるのが大事ですよね…
悩ましい問題である
Unihertzは31日、3型ディスプレイ搭載スマートフォン「Jelly 2E」を発表した。実売価格は169.99ドル(約2万5,276円)。日本では販売しないことを明言している。
2021年に発表した「Jelly 2」の廉価モデル。SoCにMediaTek Helio A22 MT6761(4コア、2GHz)を採用し、メモリ4GB、64GBストレージを搭載。GPSの測位方式はBeidou/GlonassにGalileoを追加した。OSはAndroid 12。またJelly 2は日本で販売するバージョンのみFeliCaに対応していたが、本機ではNFCも非搭載となっている。
画面解像度については明らかにしていない(Jelly 2は854×480ドット)。バッテリ容量は2,000mAh。デュアルSIM対応。指紋センサーや赤外線ポートも搭載している。
本体サイズと重量は不明(Jelly 2は49.4×95×16.5mm、110g)。
こういう方向性のデバイスもっと増えて欲しいのだが。
Tech-Verseは、LINEとヤフーが合同で開催する技術カンファレンスです。
これまで両社がそれぞれ開催していたLINE DEVELOPER DAYとYahoo! JAPAN Tech Conferenceが1つになりました。
LINE・ヤフーの両社CTOによるOpening Sessionに始まり、
1日目
Data / AI、Infrastructure、Security、Blockchain
2日目
Server Side、UX / Design、Mobile App、Web Front-end、Process & Environment
と、9つの技術領域を2日間に分け、合計87のセッション（プレゼンテーション・パネルディスカッション）を通じ、これまで各社の開発・研究が積み重ねてきた挑戦や得られた知見、そして現在活用している最先端の技術などを具体的にお伝えします。
開催日：
11月17日（木）11:30開始、19:00頃終了予定
11月18日（金）11:00開始、19:00頃終了予定
開催形式：
LINE LIVEによるライブストリーミング配信となり、全セッションについて日本語、英語、韓国語の3カ国語で配信を行います。
参加費用：無料
視聴方法：事前登録不要で、本サイトからそのまま視聴可能です。
アーカイブ配信あるのかな？
情シスを含むエンジニアが月10万くらいで副業としてやっているシステム構築や開発、SI が受託すると100万くらいすると考えると、マクロで見ると IT 全体の価値を安売りしてしまってるのでは、ということを最近考えている
市場原理に逆らってカルテル化するよりは遥かにマシだし、そのようにしてSI業界は腐ったので、まぁ。
設計において、すべての決定について仔細に「なぜ、そうしたか？」を言えるべきなのだけど、これを上手く言語化できない人は多い。「このプロジェクトでは以前からそうしているから」「そうするのが当たり前だと思っていた」などなど、本当に理解してないまま「設計という作業」を進めている人もいれば、上手く自分の行為を言語化できないだけの人もいる。
また、必ずしも自分が設計したことについて説明する場面ばかりとも限らない。既に存在する設計から「なぜ」を類推するしかない場面もある。他人のコードを読み取るときに、振る舞いだけでなく、「なぜそうしたのか？」が分からないと、その後にどんな改修を加えれば適切になるのかは分からないからだ。「振る舞い」と「根拠」を同時に読み取る必要性が出てくる場面が多々ある。
だからこそ、設計の「why」を言語化するために、そもそも「なぜ？」が言えること、それを表現するテクニックを持っている人は設計における強い人と認識される。
「何故そうしたの？」が攻撃と見なされることもあり、実に面倒である。
SQLiteの公式Webサイトに、SQLite3をWebAssembly化した「SQLite3 WASM/JS」プロジェクトのページが公開されました。
これまでさまざまなWebAssembly版SQLiteの試みが行われてきたなかで、初めてSQLiteの正式なサブプロジェクトとして開発されるWebAssembly版SQLiteになります。
AWS App RunnerはCloud Runに対応したサービスって感じか。
AWS + Goで何かしらのAPIを作りたいなら、もうこれでいいんじゃねぇの感ある。
これまでのソフトウェア工学は主として開発の効率化や品質の向上に重点を置き、論理的な考え方や経験、データに裏付けられた様々な手法やプラクティスを積み重ねてきました。しかしビジネスや社会形成上の価値創造が求められるDigital Transformation (DX)時代では、様々な人々に寄り添う考え方や、新たな社会を構想する捉え方をソフトウェアの企画や開発、運用の中心へと組み入れることの重要性を増すと考えられます。
そのような時代に活躍するエンジニアには必要とされるものは、「アジャイルなマインドと振る舞い」を身に着け、「知・情・意を意識して価値駆動の考え方でプロジェクトや組織内活動に取り組む」ことであり、それが成果につながるだけでなく、自分のエンジニア人生も充実し、社会への貢献にもつながるということを私たちは固く信じています。
この信念のもとで、SE4BS（Software Engineering for Business and Society） のコミュニティを立ち上げました。当コミュニティはSE4BSの3つの原則に基づき、ソフトウェア開発の考え方やプラクティスの整理体系化し、価値を軸として開発を進める価値駆動プロセスを例示し、世の中に広めてまいります。
SurrealDBというRust製データベースを知ったので紹介します。このデータベースはすごいです。リレーショナル、ドキュメント、グラフ、あらゆる種類のデータ構造を扱うことができ、かつインメモリ、単一ノード、分散環境、全てで動かすことができます。さらにHTTPやWebSocketによるアクセスと柔軟なユーザ認証、認可機能とがDB本体に内包されており、ブラウザから直に接続するWebDBとしても使えます。とにかくなんでもできる夢のデータベースといった感じです。
機能を挙げていたら多くなりすぎたので、特に面白い部分を挙げます。
- 配列やオブジェクトをネストした複雑なデータ構造を持てるのに、レコードリンクという機能によりリレーションに対応していてしかもSQLやMongoDBより簡潔にクエリが書ける。
- スキーマレスで各レコードには任意のフィールドを持てるが、必要ならスキーマを定義することもできる。さらに各フィールドの値に式を使って制約を設けることも可能。
- DB本体にHTTPでの接続機能やユーザ認証・認可機能が含まれており、ブラウザから直接接続するWebDBとしても使える。さらにWebSocketで接続すれば別の接続からのDBの更新を即座に反映できるリアルタイムなDBにもなる。
- 組み込み関数が豊富でクエリ内でHTTPリクエストを行うことすら可能、かつ自分でJavaScriptを使って関数を定義することも可能であり、バックエンドの機能をDB内に取り込むことができる。
- 単一ノードはもちろん分散した複数ノードで動かすことも可能。さらにインメモリでも動く。
強すぎないか
誰にもやると宣言しないで密かに行動して結果を持ってくる人がいたりするんですけど（現職ではない）、これは本人の本来の仕事が遅れる上に労力の調整が効かなくなり、ついでに周囲の仕事も奪うので絶対にやめてほしい。迷惑しかかけない。
誰が何してるか分からない職場とか怖すぎて働けない
密かに行動して結果だけ出す的なのに憧れる時期があるのは理解するが、チームで仕事してる時はひたすら迷惑でしかないのが悲しい。
エンジニア界隈でもたまに見かけるが、思春期を上手く消化できなかったイキりエンジニアがやりがちな行為である。