Linux Foundationは、HashiCorpのインフラ構成ツールであるTerraformをフォークしたプロジェクト「OpenTofu」のローンチを発表しました。
HashiCoprは今年（2023年）8月、それまでMozilla Public License v2.0（MPL2.0）のオープンソースライセンスで提供していたTerraformを含む同社製品のライセンスを、商用利用に制限があるBusiness Source License v1.1（BSL1.1）に変更すると発表しました。
参考：HashiCorp、全製品のライセンスを商用利用に制限があるBSLライセンスに変更すると発表
このライセンス変更に反発し、ライセンス変更前のTerraformをフォークしたプロジェクト「OpenTF」が9月初旬に立ち上がります。
しかし「OpenTF」の名称はHashiCorpの商標を侵害する懸念が残るとして、新たな名称の募集がGitHubのIssue「New name for the OpenTF project #296」として行われていました。
ここで「Tofu」はどうかという提案があり、Issueを見る限りほぼ満場一致の形でこの名称の採用が決定しました。
仕事をしているとたまに「〜していただけたら幸いです」「ご教示ください」といった言い回しに出くわすことがあります。所属している組織の文化によっては違和感を感じることなくスルーするでしょうし、仮に若干の違和感を感じたとしても「その人はそういう人なのだ」としてやはり流してしまう人が多いと思います。
しかし、私はわりとかなりの頻度で「それは望んでいる態度ではないのです」ということを伝えます。たとえば、「ありがとうございます。〜でいいと思います！あと、同僚なので『これでお願いします！』くらいのノリで行きたいです！」というような返信をしたりしています。言葉使いは信頼関係から来るシグナルなので、そこをきっかけにそもそも信頼関係を築けるようにしていくというのも並行してやりますが、それも含めて組織の前提を『社交儀礼としての糖衣を取り去り、相手を信頼してストレートな要求をしてもいい組織だ』という基本的な信頼へ置きたいというのを伝えていくようにしています。
言葉使いに遠慮があると、どうしてもマーケットやユーザーへのベストを考えたときに、周囲に対してタフな要求をするということの難易度が上がり、最短でマーケットへ価値を届けるというのが難しくなります。そこで
- 私たちの組織ではまず最短でマーケットへ価値を届けるのが一番重要なことで、同僚はそこに向けて一緒に困難へ取り組む仲間だというスタンスで居たい
- そのときに、遠慮や過剰な丁寧さは不要で、それよりも目の前の課題をどうクリアしていくかを率直に話せる関係性を大事にしましょう
という主旨を理解してもらうようにしています。
モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
すごく強い会社を見てて思うのは「一人当たりの粗利」「人件費」みたいなものに囚われない圧倒的な利益。むしろ全社員遊んでても利益がやってくる文化。そういう所の方がかえって社員が創造的な仕事をやりだして業績が伸びるという。
人件費削減やら一人当たりのパフォーマンスの追求やらやり始めた会社は、余裕を失くし保守的になり、ジリ貧になっていくのはよく見る。
なんかすごい事やってる会社というのは、そもそも「時流に乗ったビジネス」だとか「そう簡単には破綻しない強固な仕組みの上に乗っている」みたいな分厚い地盤があって、それを支える兵隊とその余剰リソースでひたすら研究や開発が行えるから俗に言うイノベーションを起こせるわけで。
今期の売上でアップアップしている会社はそもそもそんな浪費はできないというだけの話である。
ビジネスロジックが全てストアドプロシージャとして実装されていて、テストは実際に動かして確認するしかないが、テストデータは不足しているし、そもそもどうなれば充足したと言えるのか？ を誰も回答できないプロジェクトがあったが、当然の如く大炎上した後、打ち切りになっていた。
セキュリティつよつよ案件で特権ID管理システム使ったら、"ほぼ同時に接続すると他人とセッションが入れ替わる"という不具合に遭遇し問いあわせたら「仕様です」との回答。
富士通の住民票といい、もしかしてジャパニーズトラディショナルカンパニーって排他制御・ユニークIDの概念が無いのでは…？
技術が分かる人間がいない元請け＆技術力は無いが役員同士が仲良しの馴染みの下請けのタッグが仕事をして大変なことになってる事例は多々あるので、本当にそういう事はあるのかもしれない。
LPWA (Low Power Wide Area) の無線通信規格LoRa対応デバイス「Lo-Fi」がKickstarterに登場し、人気を集めている。 photo
Lo-Fiは、Wi-Fi／Bluetooth接続をサポートする無線通信モジュール「ESP32-S3-WROOM-1」とLoRaモジュールを搭載し、最大5km離れたデバイスとの通信が可能なデバイス。Wi-Fi接続により、IoTエコシステムとのシームレスな統合が可能。土壌の水分や温湿度をモニタリングするスマート農業や、空気や水の質、天候を監視する環境モニタリング、ホームオートメーションといったIoTアプリケーションの構築を支援する。
SIer（子請、孫請含む）から、ユーザー企業の情シス部門に転身するのは、いつぞやの人気ルートだった。けど、恐ろしいほどのリテラシーの低さや、事業部門の発言力を目の当たりにして闇堕ちする人が続出したんだよなあ。1年にユーザー側の担当者が4回変わったことがあるよ。表情が暗い人が多かった。
自社サービス提供してる企業に入ってみたらマーケと開発の発言力が圧倒的にマーケに掌握されていて、開発は使い勝手のいい社内下請けになってるってケースもよく見た。
開発も長期的視野を持つことを止めて脳死で目の前のタスクをこなす方が楽みたいなところもあったものだが。
とはいえ、自分自身も会社やプロダクトの未来に全く興味が無いので社内下請けの立場に特に不満は無かった。
エンジニアというものは気に喰わないことがあればスッと別の会社に流れればよいだけなので、企業戦略や組織に一々感情を動かす必要などないのだ。
考えてみればITエンジニアの歴史ってのは、北海道の開拓時代ととても似てる。過酷な作業を乗り越えて今の台地がある。今は素敵な場所だけど、開拓民の血と汗と涙があったから。
1970〜80年代生まれのITエンジニアの先達が「プログラマは所詮賤業。マネジメントこそ至高。お前もプログラミングなんてさっさと卒業してマネージャーになれ」というマネジメント至上主義の風潮に抗って、エンジニア（プログラマ）として価値を出し続けたからこそ、ITエンジニアに人権が付与され、転職市場でも「企業を選ぶ側」に立てるようになった事を忘れてはならない。
勿論、それを可能とする下地（高速ネット回線の普及、PC自体の高性能化、WEBサービスの爆発的普及etc）があったのは事実ではあるけれど。
謎に細かく指定されるエビデンスを誰が見ているか追跡したところ、
という結果を得たことがあった。
Modular社はPythonの高速なスーパーセットだと同社が位置づける新言語「Mojo」を、ローカル環境で実行可能にするコンパイラなどのツール群を公開しました。
Modular社は、コンパイラ基盤として広く使われているLLVM、Swift言語、GoogleがAI処理のために設計したCloud TPUなどの開発に関わってきたChris Lattner氏が共同創業者兼CEOを務める企業です。
その同社が5月に初めてMojoを発表した際に、MojoはAI処理を高速に実行するための言語だと説明しました。
MojoはPythonとの互換性によって既存のTensorFlowやPyTorchなどをそのまま利用可能。
そのうえで、より高速な処理を実現することで、AI処理の開発や実行のコスト削減などを実現するとしました。
へぇー
よく見ると普通に作ると復数のスライドに分割する内容を単純に一枚のスライドに集約しているだけのものも多い（一枚絵の資料は除く）。
ということは、最初は普通に作り、ある程度骨子が完成したらそれぞれの内容を一枚のスライドに移動させてくれば効率的にポンチ絵スライドを量産できそう。
はてブなどではポンチ絵を馬鹿にしている人も多いけど、一般企業の民は逆に神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っといったところでございます。はい、っといったところで、といったところでございます。はい？
何もしないけどとりあえず業務提携
仲が良いのでとりあえず業務提携
虚無に向かってとりあえず業務提携
大手育ちは上長の復唱しかできんのか
ワードプレスはじめましたとか、くそやばい
なんでみんなサウナそんなに好きなん？？
だれですか！？共有アカウントのパスワードを変えたのは！？んんん？
きみかわいいねー、仕事あげるかもしれないから、一回ホテル行こ。は？