これまでは1989年に登場したIntelの486プロセッサもサポートされていたのですが、次期Linuxカーネルでサポートが打ち切られるかもしれません。
コンシューマ用のWindowsでは2000年のWindows Meを最後にサポートが打ち切られたものの、Linuxカーネルは486プロセッサのサポートを継続中です。
しかしながら、Linuxカーネルの創始者であるリーナス・トーバルズ氏は最近、486プロセッサのサポートを打ち切りたいとメーリングリストに投稿しました。
486プロセッサを使っている人には長期にわたってメンテナンスが継続されるLTS版のLinuxカーネルの使用を求め、Linuxカーネル6.2で486プロセッサのサポートを打ち切りたいとのことです。
486プロセッサの先代である386プロセッサのサポートは2012年に終了しています。
今のところメーリングリスト上ではサポートを打ち切っても問題ないという意見が出ており、特殊用途をのぞいて486プロセッサを使い続けている人も少ないでしょうから、この提案が実行に移される可能性は十分にあるでしょう。
世界の覇権を握る Webpack がほぼたった一人の作者によってメンテされ続けていたという事実、だいぶ怖すぎるな……（OSS って一人プロジェクト多いよね）
世界の命運、割とソフトウェア界隈だと一人の才能ある人間に託されがちな印象ある
かの Axios も今アクティブなメンテナは1人〜2人？くらいみたいだし、超著名 OSS なのにメンテ体制がかなり脆弱……（1人メンテナ OSS 多すぎる問題）
とはいえ、プログラミングサポートツールぐらいの規模のアプリケーションだとそもそも人手が必要なく、作者のアイデアor設計デザイン勝負みたいなところがあるので、ある程度育ったらバグ取りと次期メジャーバージョンの構想を考えるぐらいしかやることが無いので外野が参入する余地が少ないってのはある。
Wbpackに限らず、大抵はプラグインを作れる構造にするのでエコシステムを作る人々はプラグインを作り、コア開発者はコア機能に専念みたいな分業ができるのでなおさらメンテナは少数になっていく。
CI/CDの処理内容や結果に基づく処理をプログラマブルにやりたいというモチベーションは理解できなくもないけど、そこまで強いニーズがあるか？ というと何とも言えないような
LINEは10月24日、同社のクリエイティブ制作部門「LINE CRATIVE CENTER」において日本語のコーポレートフォント「LINE Seed JP」を開発したと発表した。収録文字数は平仮名と片仮名、漢字、数字、記号で計9354字。同社のWebサイトから無料でダウンロードでき、フォントの有料販売以外の商用利用が可能という。
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。
この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。
ITの待遇が良くなった結果、空前のエンジニアブームが発生していて最近は興味も適性もないけど勉強が得意な子が情報系学部に殺到する現象が発生し、興味も適性もある将来有望な子が入れなくなってきてる。
同時に勉強のできる子にとってエンジニアに適性がなくても情報系学部に行く価値は高いです。エンジニアにならなくても情報工学の知識があってエンジニアと会話ができる企画職などは市場価値が非常に高いからです。このように分野の掛け算をすると希少性が高くなり若くして高年収になります。
勉強のできる秀才が高収入を求めて流入するとその業界や企業が終わってしまうのが日本の習わしではある。
有名どころではSONYがそうだろうか。
SONYに限らず、家電・銀行・造船etc...その時々で高収入が見込める業界に秀才が流入し、管理職となってリスクを避けるようになり業界・企業が硬直化し、製品の魅力が無くなり、海外にシェアを奪われるというパターン。
IT業界（というかエンジニア）は元々蔑まれていた側で、そういう人々が業界の風潮に反逆してここまでエンジニアの待遇を改善してきた歴史がある。
後進により良い待遇を渡すことはできたが、その後進達はその更に後輩に同じだけのものを残せるのだろうか。
まぁ、現状日本のIT企業が世界をリードしている分野は無いので失うものはないじゃろという意見は一理ある。
加えて、ITエンジニアは独立・企業が簡単な仕事なので硬直化した組織が気に喰わなくなったらさっさと出ていけるという点で、業界の風通しや柔軟性を維持しやすいという希望があるかもしれない。
「最新技術触れられる！」的なのは福利厚生みたいなものなので。
現在進行系で経済的価値を生み出しているシステムを適切にメンテナンスできるドメイン特化のエンジニアの方が市場価値が高いのは冷静に考えなくても当然。
Reactに似ているけど、Reactとは別のアプローチを模索しているQwikなるフレームワークの紹介
ブラウザ自動化のAPIなんてあったのか
プロダクトは顧客の課題解決に役立っていますか？役に立つかどうか、役に立っているかどうかをどうやって確かめていますか？
いま開発している機能は誰にとってどう役に立ちますか？なぜ開発することになりましたか？
どれくらい頻繁に顧客に対してリリースしていますか？その頻度はどうやって決まっていますか？
自分たちの仕事のやり方を改善していますか？最近改善したいちばん大きな問題を教えてください
チームは楽しく充実した仕事をしていますか？回答の根拠も教えてください
GAFA予備校がGoogle Mapsを作っていたら
研究員「ブラウザで直感的に使える地図作りました！」
上司「地図？他にあるよね？新規性は？収益モデルは？」
研究員「Ajaxで…収益はAPI利用料とか、商店広告とか…」
上司「既存技術で遊んでるようにしか見えないな。収支回るの？」
研究員「・・・」
研究員「あの…できれば最初は現状のベータ版で一般公開して、反応を見ながら改良していけば、Ajaxはもっと発展性があると思うのですが…」
上司「？ベータ版で公開？なんで？運用担当にどう説明するの？気が早いんじゃない？まずはサービス承認会議通すこと考えないと」
研究員「・・・」
研究員「承認会議通すにはどうすれば」
上司「これが開催規定、開発規模で承認レベル違うから。関連部に根回ししておいて」
研究員「あの、開発規模は、今後の開発コストも含む…？」
上司「当然。分割決裁はガバナンス的にNGだよ」
研究員「まだこの先は不確定なのですが」
上司「じゃダメだね」
GAFA予備校に限らず、日本の大手と呼ばれるところの人々、難癖付けたり重箱の隅を突付くのが「仕事」だと信じてそうな人が多かった印象。
それぐらいしか創意工夫の余地が無いという説すき
「育児で勉強時間がとれない」という話がプログラマー界隈でバズってるの、人類の普遍的な悩みではあるけど、昔から「プログラマーは死ぬまで勉強しないと終わり」と口酸っぱく言われてた事と、それで良しとするコミュニティ全体の風潮がそもそも持続可能な物ではなかった、という事だよな〜と思ってる
Fleetはローカルで実行されるコードエディタとして起動します。Language ServerおよびIntelliJ IDEAをベースとしたCode Engineと連携することで、スマート補完、リファクタリング、ナビゲーション、実行とデバッグ、ターミナル、プラグインなど、IDEとしての機能も備えています。
Fleetは分散アーキテクチャで構成されているため、ソースコードやLanguage Serverの置き場所をリモートマシンやサーバ上のDockerコンテナ、そしてJetBrainsが提供するサービス「Space」などに展開することができます。この構成ではローカルマシンの性能に依存することなくバックエンドの機能を利用できると共に、他のユーザーとのコラボレーション機能も利用可能になります。
これはあまり大声では言えないのですが、「過剰なアーキテクチャは自分の頭の良さが実証されていくようで気持ちいい」のだ。
要はエゴが満たされる快感で脳がガンギマリしているということ。
そのエゴを超えることがエンジニアの通過儀礼なのだが、その試練を越えられない者は非常に多い。
Go言語で実装されたPHPアプリケーションサーバらしい
アーキテクチャを検討するときに意外と重要なのがメンバーの開発ツールの「使える状態にある」機能で、例えばファイラー中心なのかランチャー中心なのかでも変わってくるし、特に気にするのはinterfaceから実装を検索する機能が使えているかどうか。これが使えないでDIPらへんを取り入れるとつらい
ファイラー＝ツリー状に表示したりするやつ、の意で使ってしまった
interfaceから実装に飛べるならクリーンアーキテクチャなどでありがちなDIPした上で実装が離れたところに置かれていてもストレスなく追っていけるけど、飛べないなら近いディレクトリ（implディレクトリみたいなやつ）に置かないと編集を要する箇所が追いづらくてつらかったりする
ファイルやパッケージの命名も、どの情報で関連するものを抽出して探すのかで適切なものが変わってくる。
「一ヶ月後にシステムが必要です。何日で作れますか？」
A「作ってみなきゃわかりませんね。まずは見積もりのために3日間ください」
B「汚いコードでいいなら10日で作れますね」
C「過去に似た案件やってるから3週間ですね」
D「デモなら半日でお見せできます」
あなたなら、誰に発注する？
とりあえずDにデモを作らせて、それをベースにAに発注するのが安牌な予感
米Microsoftは10月7日（現地時間）、「Visual Studio Code」v1.72をリリースした。併せて「Remote Development」拡張機能に含まれる拡張機能2種の名称を変更したこともアナウンスされている。
「Remote Development」パックには「Remote - WSL」と「Remote - Containers」という拡張機能が含まれており、それぞれ「Windows Subsystem for Linux」（WSL）やDockerコンテナーに接続できる。しかし、WSLディストリビューションやDockerコンテナーはローカルPC上で運用することも多く、「リモート」という名前はなじまないという声が多く寄せられていたようだ。
そこで、より機能が明確になるように命名変更が行われることになった。
Remote - WSL→WSL
Remote - Containers→Dev Containers
変更されたのは名前のみで、拡張機能の識別子や「Visual Studio Marketplace」のリンクは変わらないので、開発チームは「不都合はないはずだ」としている。
Unity公式が提供するゲームのプログラミングパターンをまとめたリポジトリ
Google には、全言語および全プロジェクトをカバーする広範なエンジニアリングの慣行があります。 ここにあるドキュメントは私達が長年の経験からさまざまなベストプラクティスを蓄積してきたことを表しています。 この知識がオープンソースプロジェクトや他の組織の利益になることを願って、私達は可能ならそれを誰にでも利用できるように公開します。
Moore's Law Is Deadによると、NVIDIA RTX 4090 Tiは現行の市場環境にはあまりに強力すぎるため、投入が見送られているとのこと。また、Moore's Law Is Deadが信頼できる情報筋として紹介した内部関係者は、「Titan Adaはテスト中にブレーカーが落ちたり、電源や本体を溶かしてしまうほど高温になったため、キャンセルされた」と話しました。
伝えられるところによると、NVIDIA RTX 4090 Tiの消費電力は600～700Wで、電力の供給には16ピンPCIeコネクターを2つ使用するとのこと。NVIDIA RTX 4090の消費電力が450Wであることを踏まえると、いかに大量の電力を消費するかが分かります。
また厚みも4スロット分と巨大で、通常のように「マザーボードにグラフィックボードを装着する」のではなく、「グラフィックボードの側面にマザーボードを取り付ける」必要があると評されています。
やべーやつだ
こっちはアーカイブを見ることにする
コードを書かないための思考
- 目的にあっているかを判断する
- 既存のシステムを使ってできないかを判断する
- ミニマムにできる方法を考える
- 「資産化」できる方法を考える
A collection of code snippets to help you optimize your web projects.
Web プロジェクトの最適化に役立つコード スニペットのコレクション
TL で見かけた
「工業で復興した日本は、なまじ理数系に強い人材が多かったので、1980 年代のメカ系エレキ系のエンジニアが容易にプログラマに転身できてしまい、結果、プログラマは独自の報酬体系の構築に失敗した」
という説、割と説得力を感じるので、その観点で過去を調べ始めている次第。
1980年代だとApple IIIとかPC-8001とかの時代か。
確かにその時代のコンピュータはソフトウェアだけでなく、ハードウェアの知識も要求された時代だからメカ系・エレキ系のエンジニアのバックボーンを持つ人が多かったのだろうとは思うが。
実際、ハード屋の方が偉い・ソフトはハードのオマケという時代でもあったので、ハード屋の下位互換的な扱いだったのかもしれないな。
一切に身に覚えがないのにいきなりアカウント永久凍結 → 運営とやりとりしても梨の礫 → 弁護士雇って内容証明で即復旧、という流れだった模様。
ちなみに、弁護士費用は
手付金： 66,000円
成果報酬（Twitterアカウントの凍結解除）： 55,000円
の、 計121,000円 でした。
めちゃくちゃ高いようにも思いますが、このTwitterアカウントはぼくのここ13年のすべてを記録した媒体であり、それだけTwitterにはお金を払う価値があると思い、お支払いすることにしました。その結果アカウントが戻ってきてよかったです。
長期に渡って蓄積したデータが一瞬で消滅する苦しみは理解できる。
やはりSNSに限らずWEBサービスは適度な距離を置いて利用する方がよさそうである。
2022年 09月 30日
平素は、エキサイト翻訳をご愛顧いただき、誠にありがとうございます。
このたび、エキサイト翻訳につきまして、2022年10月31日（月）をもちましてサービスを終了させていただくこととなりました。
サービス開始から多くのお客様のご愛顧をいただき、誠にありがとうございました。
ご利用いただいておりました、お客様には申し訳ございませんが、何卒ご理解くださいますよう、お願い申し上げます。
提供終了サービス：エキサイト翻訳
サービス終了日：2022年10月31日（月）
エキサイト翻訳サービス終了するのか
変更意図が要求に沿っているか
- そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。
- 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。
モデリングが妥当か
- モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。
- わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。
- 仕事にあったインタフェースになっているか。テストを書いたときに素直なコードになっていると望ましい。例外の取り扱いや、アウトプット先を変えたときに無理なく使えそうか、とかも考える。
実装が妥当か
- プロダクションでの性能が意識されているか。逆に無意味に性能を追ってコードが読みづらくなっていないか。
- アルゴリズムに誤りがないか。とくに外部・外界とのやりとりを伴う場合、エッジケースがテストされているか。
- 異常が発生したときにデバッグ・調査しやすいか。エラー（ログ）に必要な情報が含まれているか。
- 既存のコードが今回の意図に合わせて変更されているか。
読み手の負荷が高くないか
- コメントが書かれているか。ドキュメントやドキュメントへのリンクがあるか。
- 読みづらいコードになっていないか。やむなくそうなっている場合はコメントがあるか。Pull Request のコメントで補足される場合があるけど、そういうときはコメントに書いてもらうようにする。
- 議論の最中で出てきた未来の仕事が TODO とか FIXME となってコメントに残されているか。
- この言語では/チームでは/プロダクトではしない書き方がないか。このへんは完全に知識の問題で、逆に教えてもらうチャンスでもある。機械がやってくれてもいいところ。
このコードで何故ジェネレータになるのかよくわからんなぁ
人「プログラムは実行してみれば良くて，『案ずるより産むが安し』です。」
私「機械学習の人々がこう思っているので，うちの大学のコンピュータは電気代が年間9億円かかっています。」
低レベルの人がめちゃくちゃ頑張って設置当時のエコ性能を世界一にしたのに，上で動かす人が富豪プログラミングするんですよね。
高速化の文脈ではよく見る構図なのです。
やっぱ原発再稼働は必須だわ
トヨタ自動車は10月7日、クルマ向けネットワークサービス「T-Connect」ユーザーのメールアドレスと「お客様管理番号」、29万6019件が漏えいした可能性があると発表した。
原因は2017年12月にT-Connectユーザーサイトの開発委託先企業が、取り扱い規則に反してソースコードの一部を誤って公開設定のままGitHubアカウントにアップロードしたこと。その後、5年にわたって第三者がソースコードの一部にアクセスできる状態で放置されていた。ソースコードにはデータサーバへのアクセスキーが含まれ、これを利用するとサーバに保管しているメールアドレスやお客様管理番号にアクセスできたという。
トヨタは9月15日にGitHub上のソースコードの一部を確認し、同日中に非公開化。17日にはデータサーバのアクセスキーを変更している。
以前、NTTデータのソースコードをGitHubに公開した提督がいたな。
Winny がなぜ YouTube になれなかったのか、というのを考えるとぶっちゃけ「カネがなかった」というところが一番でかいよなあ
YouTube はカネがあるから削除人も雇用できたし、著作物を見つける技術も開発できたし
何故そうなるのかわからない。
WinnyとYoutubeは全く異なる性格のサービス/テクノロジーだと思うのだが。
デジタルコンテンツの流通ネットワークという面に関しても、Winnyにはオフィシャルな運営実態を持つ何者かはいなかった（P2Pネットワークなのだから当然）ので、そもそもカネの問題云々では無かったはず。
Winnyがデジタルコンテンツの流通ネットワークになれなかったのは、著作権権利者が流通をコントロールができない・権利者に利益が還元されない構造だったので本気で潰されてしまったというだけの話だろう。
結局、ストリーミング配信が覇権を獲ったのは権利者が流通をコントロールできること、それにともなう課金システムを構築できるという側面がが大きく、WinnyがYoutubeになる世界線は最初から無かったように思う。
- 選択肢を網羅できているか
- 機能要件を深く理解して観点を出せているか
- 非機能要件も考慮できているか
- 開発工数や拡張性を考慮できているか
- 要件や工数のmust/wantと選択肢に対する評価が正しいか
UbuntuのSnapくん、もう少し熟れてほしい感はある
なお、期待されていたRustの導入はLinux 6.0では見送られたが、Linusは「ZDnet」のインタビューで「（Rustの導入は）よほど何かが起こらないかぎり、Linux 6.1になる」と答えており、次のLinux 6.1でサポートされる可能性は高い。LinusはすでにLinux 6.1のマージウィンドウをオープンしており、いよいよ”Rust in Linux”に向けて本格的な動きが始まりそうだ。
tRPCとはなんぞや
おぉ、コテコテのExcelワープロフォーマットだ
リモートになると偶発的な雑談や会話による信頼関係の醸成は非常に難しくなるし偏りが生じるので、総当たり1on1で狙って信頼関係醸成をしていたけど、さらにそれをシステム化して人が増えても毎週ランダムで組み合わせが設定されて1on1ができるようになって、どんどん研究所のプロセスが洗練されてる
一見雑談であっても、それが計画的にチームワークや生産性を高める取り組みで、その設計や実践がチームにとって非常に価値がある仕事なので、今年から研究所では1)研究開発力、2)技術に基づいた影響力、に加えて、3)チームビルディング(for the team)の３つの柱を同様のスケールの評価軸にしています。
チームビルディングと名づけるとまだしも、チームの雰囲気や各メンバーのメンタル面でのサポートを自然にやっている人は、それが人柄のように見られて適切に評価されにくかったりする。そこで、その取り組みをちゃんと言語化して明確に評価軸にすることにした。
メンタル面の取り組みをチームでやれるように業務プロセスに組み込むことで、リモートワークの時代においてはインクルージョンとエンゲージメントを上げることが明確にチームの生産性に繋がることを確信できたし、なによりチームが積極的に支え合ってチームをよくする雰囲気は働きがいを向上させる。
この辺りの話は以下の資料にまとめています。もう少し研究所で実践したら、その話もまとめて公開します。感謝すべきは、組織・人事的な取り組みを研究して評価し、ちゃんと論文化していてるIBMやMSの人事部門ですね。この辺りの情報を知れば知るほど、世界的企業の底力に驚愕するばかりです。
さくらインターネット研究所合宿の発表資料です。裁量あるチームの必要性やそのためのチーム設計、評価制度などについてのあり方について各種論文から分析し、今必要なチームのポイントをまとめてみました / VUCAワールドから紐解く組織や評価制度の変遷と再設計
オブジェクト指向系のデザインパターンに対応する関数型プログラミングのパターン、イディオムの説明
ダブリンで開催された「Open Source Summit Europe」で、筆者はChainguardの最高経営責任者（CEO）で創設者のDan Lorenc氏に、「アンディストリビューション」とはどういう意味なのかを尋ねた。Lorenc氏は、「われわれが『アンディストリビューション』という用語を使っているのは、それが技術的に正しいからだ。コンテナー内には、Linux以外のすべてのものがある。したがって、たとえLinuxをベースとしていても、それをLinuxディストリビューションと呼ぶのは適切ではない」と説明してくれた。
ほとんどの人がLinuxコンテナーと呼んでいるものは、「ハードウェア上で起動し、コンテナーランタイムを利用可能にするディストリビューションだ。そうしたディストリビューションの中で最もユーザーが多いのは、おそらくAlpineだろう。Wolfiはそれと正反対のものだ。Wolfiにはディストリビューションがない。最小限の構成であり、パッケージマネージャーさえ含まれていない」とLorenc氏は続けた。コンテナー化されたアプリケーションを実行するのに必要最低限のものだけを備えている。
Lorenc氏は、この新しい異なるLinuxを作成するために、「われわれは、Alpineチームに在籍していたメンバーを大勢起用した」と述べ、「しかし、Alpineはコンテナー用に設計されたものではなく、元々、ルーターやファームウェアなどを想定して設計されたものだ。Alpineがコンテナーにとって魅力的だったのは、適切なサイズとセキュリティを備えていたからだ」とした。Wolfiはセキュリティのために、ミニマリスト的なアプローチを極限まで追求している。
Lorenc氏は、「依存関係を可能な限り最小限に抑えることで、イメージの監査、更新、および転送を簡素化したり、潜在的な攻撃対象領域を減らしたりすることが重要だと考えている。Wolfi（最も小さくて柔軟なタコにちなんで名付けられた） は、これらのコンテナー化された環境を最大限に活用し、なおかつセキュリティも最大化できるように、一から設計されている」と説明した。
Linuxカーネルをベースに何かしらのカスタマイズを加えてパッケージ化したものなら、それは「Linuxディストリビューション」なのでは？
ディストリビューションではない、とする理由がよくわからないな。
WTH is an Undistro?
If you made it this far and have been asking yourself what the heck we mean by undistro – you’re in luck. We refer to Wolfi as an undistro because it is not a full Linux distribution designed to run on bare-metal, but a stripped-down one designed for the cloud-native era. Most notably, we don’t include a Linux kernel, instead relying on the environment (such as the container runtime) to provide this.
WTH は Undistro ですか?
ここまで来て、undistro とは一体何を意味するのか自問自答しているなら、あなたは幸運です。 Wolfi は、ベアメタルで実行するように設計された完全な Linux ディストリビューションではなく、クラウドネイティブ時代に向けて設計された機能を取り除いたディストリビューションであるため、アンディストリビューションと呼んでいます。 最も注目すべき点は、Linux カーネルを含めず、代わりに環境 (コンテナー ランタイムなど) に依存してこれを提供することです。
We refer to Wolfi as an undistro because it is not a full Linux distribution designed to run on bare-metal, but a stripped-down one designed for the cloud-native era. Most notably, we don’t include a Linux kernel, instead relying on the environment (such as the container runtime) to provide this.
Wolfi は、ベアメタルで実行するように設計された完全な Linux ディストリビューションではなく、クラウドネイティブ時代に向けて設計された機能を取り除いたディストリビューションであるため、アンディストリビューションと呼んでいます。 最も注目すべき点は、Linux カーネルを含めず、代わりに環境 (コンテナー ランタイムなど) に依存してこれを提供することです。
コンテナでの実行に特化して、諸々のハードウェアサポートを切り捨ててるという感じか？
カーネルを含めないというのはベースイメージに含めないという意味だろうか？
納税に関するファイルをメールでやりとりするのはちょっと嫌なので、メールで受け付けないのは別にいいのだけども。
ファイル提出用のファイルサーバ（アップローダ）的なものを整備して欲しいとは思う。
まぁ、税務署に限らず役所全般そうだけども。
Facebook「たぶん動くと思うからリリースしようぜ！」
Google「たぶん撤退するけどリリースしようぜ！」
Twitter「本番環境しか無いからリリースするしかねえ…」
草生える
HTMLを隠蔽したウェブフロントエンドのコーディングはぜんぜん流行らないし、HTML/CSSは比較的触れる人は多いのに、SQLはなぜそうではなく、ORMをありがたがる人が多いのか、SQLが今のHTMLみたいになるにはどんなツールがあればいいのか、というのを考えるのは楽しい
ウェブ的に発展した世界線があれば、JSXのようなコード直接埋め込み記述だったり、babel+browserlist とかcssのprefixer のような互換性吸収層が発達していたのかもしれない
個人的にはORMに否定派ではあるのだが。
SQLというDSLを介するのが気持ち悪いという感覚は理解できる。
ひとつのプログラミング言語で完結したいという欲求はエンジニア的にはそれなりに自然な発想ではある。
「AIが普及すれば人間は単純作業から解放されて創造的な活動に集中できる」って言われてきたのに、真っ先にクリエイティブな領域がAIに代替されてくのは衝撃だよな。もしかしたらテクノロジーが入り込めない泥臭い人間的な仕事だけが生き残っていくのかもしれない。
金をかける価値が無い、もとい投資に対する費用対効果が薄い領域（家内制手工業みたいな）だけ人間に残された仕事になり、その少ない仕事を巡って人々は争うようになるのだ。
というか、機械学習/強化学習が世間に認知され始めた時点でそれはずっと指摘されてた。
二郎店員「ニンニクいれますか」
私「ヤサイアブラマシニンニクカラメ; select * from users」
二郎店員「はい、小豚ラーメンと顧客リストになります」
草
「まず、僕なりに『強い開発組織って何だろう？』って考えてみたんです。その結果、『ビジネスの課題を投げたら、それを解決できる良いプロダクトが返ってくるチーム』だと定義しました。
開発のスピードも大事かもしれませんが、それ以上にどうすれば課題を解決できるかを考え、使い勝手や仕様を細かいところまでよく考え抜いたプロダクトを出せることが重要だろう、と」
「若い頃は結構こだわりがありました。『技術的に面白いことがやりたい』とか『とがった人たちと働きたい』とか。
でも自分の中に知識や経験が蓄積されてくると、この知見を世の中にフィードバックしたいという思いも芽生えてきた。
30歳過ぎになる頃には、良いプロダクトやサービスを作るための方法論を体系化し、開発で苦労している会社に自分のノウハウを提供すれば喜んでもらえるんじゃないかと考えるようになりました。
実際にいろいろな会社からアドバイスを求められ、フリーランスで技術顧問をするように。僕自身のこだわりで働く場所や環境を選ぶというよりは、『自分を必要としてくれる人たちがいるなら、そこで頑張ってみよう』という感じに変わったんです。
一番まずいのは、学習を止めてしまったにもかかわらず、過去のアナロジーで今の技術を分かった気になることです。『これは昔のあの技術と同じだね』 とか、自分で自分を欺くかのように、分かったふりをする。その慢心が日々の仕事で間違いを生み、間違った意志決定につながってしまう。
中国ではITエンジニアの退職年齢があまりに早い。俗に言う「プログラマー35歳定年説」があるようで、さまざまな体験談を見るに「その歳でまだ（プログラマーを）やっているのか」という社内チーム内の空気と日本と比べて解雇が容易な環境、若いスタッフに置き換えることで人件費を抑えたい経営の意向により、いや応なく退職に追いやられるケースがよくある。
中国のプログラマーに関する調査結果「2021中国程序員薪資和生活現状調査報告」によると、22～24歳のITエンジニアは11.2％、25～29歳は42.5％、30～34歳は31.8％、そして35歳以上は9.4％と激減する。中国の大手IT企業に就職すれば高収入なので、多くの若者がITエンジニアを目指している。しかし、ずっとその仕事を続けるのは、ITエンジニアになる以上に難しい。
それでは、ITエンジニアを解雇されたらどうするかというと、それまでに稼ぐだけ稼いで、その資金を元手に投資や起業をするというのが中国での正攻法だ。それができなければゴミ収集員やマンション管理人、配達ドライバー、家政婦などしかないと言われており、インターネットでは「配達員をやってみたら運動にもなって案外楽しかった」という体験記がある。これは、中国のネット論壇で「正能量」と呼ばれるあらゆる事象に対して前向きな解釈を良しとする考え方が流行していることが背景にあるためで、実際に楽しいかというとそうでない人も結構いるだろう。
20年前の日本みたいだな
ソフトウェア開発の複雑さに立ち向かうための方法に「#ドメイン駆動設計」があります。近年、「 #マイクロサービスアーキテクチャ 」や「 #アジャイル開発 」を利用した俊敏性のある開発が注目されており、それらのベースとなる考え方がドメイン駆動設計に含まれています。ドメイン駆動設計は古くからある考え方ですが、そういった背景によりエンジニアの必須知識として再び注目が高まっています。
今回のセッションでは #エリック・エヴァンス のドメイン駆動設計の第 3 部をピックアップして、開発しやすいコードを書いたり、そのための設計をしたりする方法について、スペシャルゲストに『 #現場で役立つシステム設計の原則 』の著者の増田さんをお招きしてお話しします。開発者が開発しにくい設計になるとどんどん変更しにくいレガシーなシステムになってしまいます ! 変更しやすい設計にするための大切な考え方を一緒に学んでいきましょう !
この論文で暗に主張しているのは、現在のAIに関する大規模なプロジェクトのほとんどは人間レベルという目標に決して到達できないという点だ。
LeCun氏は、9月に入って米ZDNetが実施した「Zoom」でのインタビューの際、現時点で最も成功しているディープラーニング（DL）の研究手法の多くを非常に懐疑的に見ていることを明らかにした。
コンピューター科学分野のノーベル賞に相当する「ACM A. M. チューリング賞」を受賞したこともあるLeCun氏はZDNetに対し、同業者らの研究について「必要だが十分ではないと思う」と述べた。
DenoとSlackは、Slackが発表した新しいプラットフォーム基盤にDenoが採用されたことを明らかにしました。
Slackの新しいプラットフォームとは、Slackの機能をユーザーが拡張するBotなどの、いわゆるSlackアプリケーションのための開発と実行を実現するものです。
これまでは、Slackが用意したAPIを呼び出すプログラムを実行する場合、Slackアプリケーションのデベロッパー自身がそのプログラムを実行する環境をSlackの外部、例えばAWS Lambdaなどに用意する必要がありました。
Slackの新しいプラットフォームによって、Slack自身がこの実行環境と開発環境を提供することになります。これによりSlackアプリケーションの開発と運用はこれまでよりも簡単で柔軟なものになることが期待されます。
これらの機能を備えた新しいプラットフォームの基盤となっているのがDenoです。CLIもDenoがベース、SDKはTypeScriptで書かれており、SlackアプリケーションもTypeScriptで開発できます。
SlackはCLIも含めたDenoの使いやすさ、V8をベースとした高速性、そして高いセキュリティを評価し採用を決めたとしています。
DenoにとってもSlackという超大型のサービスのアプリケーション基盤に採用されたことは、Node.jsやBunなどとの競合に対する差別化とさらなる普及に向けて、そしてDenoの開発元であるDeno Landのビジネスにとっても、大きな前進になることは間違いないでしょう。
一般社団法人「DeFi協会」（東京都中央区）が解散していたことが、9月22日付の官報で明らかになった。同協会はDeFi（分散型金融）の普及やビジネス環境の整備を目的に、2021年6月30日に設立されたが、1年余りで活動を終了する。
代表の田上智裕氏は7月20日に、著書「いちばんやさしいWeb3の教本 人気講師が教えるNFT、DAO、DeFiが織りなす新世界」（インプレス刊）を発行。しかし、内容に誤りがあるとの批判が相次ぎ、出版停止・回収になった。
田上氏は8月1日に一連の騒動についてTwitterで「深くお詫び申し上げます」と謝罪。「また応援していただける取り組みができるように、改めて一から勉強し直します」と話していた。
味噌が付いたからリセットか