エンジニアに「自分たちのプロダクトをどうしたいですか？」って聞いた時に「こういう機能を作りたい」という意見が少なく、「ここのバグを直したい、リファクタリング・リアーキテクトをしたい、この技術を使いたい」という話ばかりでてくるようだと、まだチームとして未成熟なんだろうな、と感じる
これは、エンジニアのマインド的な話だけではなく、ちゃんとプロダクトのWhyが開発に共有されていないとか、内部品質を犠牲にしまくっているしわ寄せで、どうしてもそちらに目が向いてしまうとかそういう話が背景にあることも多い
「チームが」未成熟と書いたのはそういうことで、開発者がそういう方向に意識が向けられることを促すことが組織としてできているか。顧客と対話できないから顧客のことを想像できないのはそうだし、張り子の虎を必死こいて動かしている状況でプロダクト価値とか考えられないのはそう。
内部品質が低い環境はエンジニアのマインド成長を妨げる、という話なのかも知れない
AWS ODBC Driver for MySQLは、MySQLコミュニティが配布している純正のMySQL用ODBCドライバと置き換えて使える互換性を備えつつ、AWSでMySQLを利用する際により優れた機能と性能を実現できるように実装されています。
具体的には、Amazon Auroraにおけるフェイルオーバー時の再接続の高速化です。AWS ODBC Driver for MySQLはクラスタのトポロジーと各 データベースインスタンスがプライマリなのかレプリカなのかの役割のキャッシュを保持することで、接続先のデータベースインスタンスに障害が発生し、別のデータベースインスタンスへのフェイルオーバーが発生したときには、この情報を利用して接続を切り替えることで、DNSによる解決を待たずに高速に新しい接続に切り替えることができると説明されています。
またAWS Secret ManagerやAWS IAMなどによる認証にも対応しています。
今回の問題は突然発生したかのように思えますが、実は同じような問題が数ヶ月前にも発生し、DebianとRocky Linuxのユーザーが大きな影響を受けていたことがわかりました(Neowin)。
Hacker Newsによると今年の4月、CrowdStrikeのアップデートによって、市民技術ラボのすべてのDebian Linuxサーバーが同時にクラッシュし、起動できなくなる問題が発生していたとのこと。
アップデートが、最新の安定版Debianと互換性がなかったことが原因で、ラボのITチームは、CrowdStrikeを削除するとマシンが起動することを発見し、このインシデントを報告しています。
CrowdStrikeは1日後に問題を認めましたが、根本的な原因の分析に数週間かかり、分析の結果、Debian Linuxの設定がテストマトリックスに含まれていないことが判明したとのことです。
RockyLinuxでも9.4へアップグレードしたあと、カーネルのバグが原因でサーバーがクラッシュするという同様の問題が報告されています。CrowdStrikeのサポートはこの問題を認め、不十分なテストと異なるオペレーティングシステム間の互換性の問題への注意が不十分であったと説明しています。
致命的な問題が繰り返し発生していることは、CrowdStrikeのソフトウェア・アップデートとテストの手順について深刻な懸念を引き起こしており、同社の製品に依存している顧客にとっての潜在的なリスクが存在することを浮き彫りにしています。
<クラウドストライクの分析結果>
①C++で書かれたコードがぬるぽ
②その結果Windowsは即座にブルースクリーンを引き起こす
③プログラマがテストやチェックせずに本番環境へアップして強制配布でユーザーを地獄へ
④しかもそれがシステムドライバーゆえにWindows自身にはどうにもできない
「絵柄の真似は許さん」ってのは無理筋なんだよなー
絵柄なんてものを「個人のもの」にしちゃ文化が発展しないってのはもうわかりきった答えだからさ
それでもなお「人間はいいけど、機械に絵柄の真似はさせない」なんて言うなら
「速度に制限をかけろ」って言ってるも同然で
他のAIも全部制限かけなきゃおかしくなっちゃう
自動運転も半自動運転までだし、機械翻訳も人間並みに時間かかるし、AIチャットも実際に雇える人数分しかチャンネル開けない
それが「速度制限」だからね
日本時間7月19日午後1時以降、Windowsデバイスでブルースクリーン（BSoD）エラーが発生し、クラッシュしている報告が数多く寄せられている。地域を問わず、世界規模で発生しているようだ。
この問題は、「CrowdStrike Falcon Sensor」に含まれるドライバー「csagent.sys」によるもののようだ。CrowdStrike社より、問題の発生を認める技術アラートが発表されている。同社は解決に向けて取り組んでおり、詳細がわかり次第顧客と共有するとしている。
「CrowdStrike Falcon Sensor」は、クラウドベースの総合セキュリティソリューション「CrowdStrike Falcon」のエージェントアプリ。このソリューションは企業、政府をターゲットにしているため、個人が影響を受けることはあまりないだろう。
東京ガスの子会社が不正アクセスを受けて個人情報約416万人分が漏洩した可能性がある問題を巡り、侵入経路はVPN（仮想私設網）装置経由であったことが日経クロステックの取材で2024年7月18日までに分かった。現在は外部との接続を遮断するなど対策を講じた上で、被害範囲や原因などについて調査を進めている。2024年7月18日午前10時時点で情報の不正利用は確認されていないという。
不正アクセスを受けたのは、ガスや電力の営業を手掛ける東京ガスエンジニアリングソリューションズ（TGES）。2024年6月26日に、同社ネットワークへの不正アクセスを検知したという。同社は即日、外部との接続を遮断した上で専門機関による協力を受けて調査を進めたところ、特定のファイルサーバーへのアクセスに必要な従業員のIDとパスワードが複数窃取されていたことが、2024年7月9日に判明したという。
窃取されたIDとパスワードは、TGESが顧客情報を保管するファイルサーバーのほか、東京ガスが持つ法人顧客の情報を保管するファイルサーバーにもアクセス可能だった。ただ、実際に窃取したIDとパスワードを使ってサーバーにアクセスした形跡は見つかっていないという。
「何者かによるファイルの暗号化や身代金要求などはない」（東京ガス広報）といい、ランサムウエア（身代金要求型ウイルス）の可能性については否定した。侵入経路はTGESが持つVPN装置経由であることが分かっているが、脆弱性の有無などについては「セキュリティーの関係で回答は控える」（同）とした。
今回の不正アクセスに関しては、TGESへガスや水道などのインフラ情報管理システムの運用業務を委託している顧客に被害が及んでいる。TGESの顧客である神奈川県が2024年7月17日に、県営水道の顧客情報約3万7000件がTGESへの不正アクセスによって流出した可能性があると発表した。このほかTGESの顧客である金沢エナジーも同日、顧客情報が流出した可能性があると発表している。
[...]さらにTenstorrentは、2024年末に第2世代の多目的AIプロセッサを販売する準備をしているとのこと。記事作成時点では、AI向けチップ市場はNVIDIAによってほぼ支配されていますが、ケラー氏はNikkei Asiaに「NVIDIAがうまく対応していない市場はたくさんあります」と述べ、NVIDIAが目を向けていない分野でチャンスがあると考えています。
AIは現代社会のさまざまなシチュエーションで活用されていますが、NVIDIAのハイエンドGPUは2万～3万ドル(約310～470万円)に達するため、企業はより安価な代替品を探しています。Tenstorrentが狙っているのはこの層であり、同社のGalaxyシステムはNVIDIAのDGXシステムより3倍も効率的で、価格も33％安いと主張しています。
ケラー氏はTenstorrentのプロセッサが安い理由のひとつに、大量のデータを高速転送するための高帯域幅メモリ(HBM)を使用していない点を挙げています。HBMは生成AIチップの重要なコンポーネントであり、NVIDIA製品の成功においても大事な役割を果たしてきました。しかし、HBMはAIチップの膨大なエネルギー消費や高価格の原因になっているそうで、ケラー氏は「HBMを使用する人々でさえ、そのコストと構築のための設計時間に苦労しています」と述べ、HBMを使用しないと決定したとのこと。
一般的なAIチップセットでは、GPUはプロセスが実行されるたびにデータをメモリに送信しており、これにはHBMによる高速データ転送機能が必要です。しかし、Tenstorrentはこのデータ転送を大幅に減らすようにチップを設計し、HBMを使わないAIプロセッサを実現しました。
Tenstorrentが開発するAIプロセッサの特徴は、100個を超える各コアにそれぞれCPUが搭載されているという点です。各コアに搭載されたCPUがデータ処理の優先順位を決定することで全体的な効率が向上するほか、各コアが比較的独立しているため、コア数を調整することで幅広いアプリケーションに適応可能だとのこと。ケラー氏は、「現時点ではAIに最適なアプリケーションがどれほどのサイズになるのかわかりません。ですから、私たちの戦略は幅広い製品に適した技術を構築することです」と述べました。
多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。
そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。
※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとんどでした。
しかしながら、ソフトウェアというのは実装してみないとわからないことが多く、実装前に完成の形を予測するのは難しいものです。そのため、適切にソフトウェアを構築したいのであれば、事前に作成された設計に完全に従うことは求めず、実装にともなって変更が加わっていく前提にする必要があります。もし設計にたいして忠実に実装できて価値があるソフトウェアになることを保証したいのであれば、実装相当の検証作業が必要になるはずです。
けれども、上で書いたように設計というのは契約の一部であり作業指示です。そうなると、そのとおり忠実に作ることが前提であり、修正は例外という扱いになり「もし変更が必要になれば差し戻す」という感じになります。変更するには上位存在の承認が必要ということもあったりします。
その結果、多少の不備であればいびつな実装になろうとも従ったほうがマシとなり、大きな変更の必要性に気づいたとしてもそれを差し戻していたら作業開始が遅れるのでそのままにするということも起きかねません。
不備であれば差し戻すとしても、よりよいアイデアが浮かんだからといって、わざわざ差し戻すインセンティブはありません。ソフトウェアのアイデアは実装時に浮かびがちにもかかわらず。
また設計側でも、実装しながらの試行錯誤をしないのであれば実装確度の高い前例踏襲で無難なものになりがちで、やることにあわせた特別な設計は行われにくくなると思います。
実装者に創造的能力を期待せず裁量をもたせず責任をもたせず設計通りにやることを求めるということであれば、「PG」という職種は取り換え可能なコーダーということになりますね。
その結果、価値のあるソフトウェアを開発するというモチベーションは失われ、よいソフトウェアを作ることではなく、契約どおり仕様書どおり設計どおりプロジェクトを完了することが目的化します。
それは、「「実装者が設計を勝手に変えてはいけない」というのはダメでは」のようなことを書いたときに「勝手に変えるのはダメ」という反応がいくつかあったものが、それではよいソフトウェアにならないというものではなく、トラブルなく契約を遂行してビジネスをまわすためにダメという指摘であったことからも伺えます。
その設計では使えないソフトウェアになることがわかったとしても、実装者には責任がなく、むしろそれを指摘して設計やりなおしになると実装開始が遅れるものの納期は変わらなかったりするので、価値をうまないソフトウェアをそのままつくるほうがビジネス的に正しいという、モラルハザードのようなものも発生しがちです。
このように、多重下請け構造ではプロセス自体がソフトウェアの性質を反映してよいものを作れるようになっていないために、よりよくビジネスをまわすことがよりよいソフトウェアにつながっておらず、むしろちゃんとまわそうとすると いいソフトウェアを求めてはいけないビジネス形態になっていて、よりよいものを作ることにインセンティブが働かず、構造的にいいソフトウェアが作れなくなってると思います。
「進歩とは指数関数的なものだ」とはよく言うが、この指数関数は２つのパターンがある。
先へ進むほど段々と効能が下がっていくもの、たとえば何かの練習をしたとき最初は１時間２時間でグイグイ成長していたのがやがて１００時間鍛えてもプラトーが終わらなくなるようなタイプの指数関数。
反対に最初はあまり進まなかったものが途中からドンドン倍々ゲームにインフレしていく、バイバインのような加速度的な増加を起こす指数関数。
そして多くの進歩はこの二つの進化関数が重なりあっている。
つまり、ある部分においてはだんだんと効能が落ち、ある部分においては突然急加速が起きる。
今のAI絵師は一見すると加速的な指数関数が先に起きてから、減速気味な指数関数へと移行したようにも見える。
だが、私はそうは思わない。
今いる場所は単なる一時的なプラトーでしかなく、そのプラトーに滞在する間もAI進歩の倍々ゲームは物凄い勢いで進んでいて、堰が切られた直後に世界は全く別物へと変化するのだろうと。
その瞬間、今まで私のようなパソコンチョットツヨイが保有していた優位性は一気に消し飛ぶのだと思っている。
今でこそAIの活用さえも私のようなパソコンチョッツヨイこそが有利な土壌となっているが、こんなのは本当に今だけだろう。
インターネット黎明期においてパソコンオタクだけがネットの恩恵を受けていた時代があったが、今はもう小学生ですら簡単にスマートフォンでネットに接続できるわけだが、AIがそのレベルになる日が本当にもうすぐそこのようだ。
AIに読み込ませるプロンプトを吐き出すAIの開発が完了したとき、もうそこにあるのは「母国語さえ使えれば、パソコンで出来ることはなんでもAIにやらせられる時代」だ。
そうなったとき、色んな所から送られてきたバラバラの書式のエクセルをサクサクと変換するようなことでさえ「スゴーイ！」「ハヤーイ！」と言われていた我々マクロチョットデキルおじの黄金時代は完全に消えさるだろう。
問題はその時代において我々が何を売り物にして食べていけばいいのかということだ。
第二第三の武器があるならいいが、俺にはない。ないのだ。
この人生、いよいよ先がなくなってきたということである。
ヤバイなー。
どうやって食っていけばいいんだろう。
2年ちょっとくらい前まで、イラストで食っていた。
ただし、バリバリ企業と契約とかして1枚10万とか取っているプロイラストレーターではない。
ココナラとかSkebとかSKIMAとか、そういうコミッションサイトでフリゲーやTRPGやVtuber用の立ち絵イラストを1枚1万弱で売り捌いている、いわゆる「アマチュア底辺絵師」だった。
（そう呼ばれる層にいた、という意味で「底辺」という言葉をあえて使う）
でもよく考えてみたらなんのこっちゃない。起こったのは至極当然のこと。
「自分だけの絵を描く仕事」は奪われてない。消えたのは「クライアントの要望通りの画像を用意する仕事」だ。
技術の進歩によって、機械が「指示に合わせて画像を作る能力」を得たから私みたいな層の受けていた「指示に合わせて絵を描く依頼」は、「機械でもできる簡単な仕事」になったってだけの話である。
さて、AIに代替されたイラスト依頼の話をしているわけだから、
ここらで「依頼者側」としての話もさせてほしい。
私は絵を売る一方で、絵を買う側だった。
[...]
これがAIが出てきてどう変わったかと言う話をする。
結論から言えば、「依頼数は減ったが、使用額は同じ」
これまでは質が低くてもいいから枚数を優先して安い依頼を選んでいたのだが、細部に拘らないなら自分の絵のi2iで簡単にオリキャラのイラストを量産できるようになったから、そう言った画像を作るのはAIに任せて数ヶ月に1度しっかり吟味したイラストレーターさんに数万円の絵を頼んでいる。
絵の依頼って、大きく分けて2種類ある。
1つ目が、「誰でもいいから希望通りの画像を用意してくれ」というもの。
2つ目が、「この人のイラストがほしい」というもの。
1つ目はAIに代替された。AIの方が早くて安くて失敗してもノーダメで文句言わなくて権利関係面倒じゃなくて改変も加筆もし放題だから。ほんのちょっとのイラストスキルがあれば細部は簡単に修正できるし。
2つ目には影響がない。「その人」を求めるクライアントはLoRaがあろうがi2iができようが「その人」に頼むから。「その人の手描きである」という事実に、上で挙げたAIのメリット全部を凌駕する価値があるから。
問題は多分、1つ目の依頼しか貰えない立場なのに自分が売っているのは2つ目だと思い込んでいる絵師が多すぎることだ。
ボーナスタイムは終わってしまったのだ。
もう、対人スキルも、宣伝能力も、人脈も、自分をブランドにできるだけのイラストの実力もないアマチュアインターネット絵描きの絵が売れる時代は過ぎ去った。
思えば本来私程度の人間が、一時的とは言え絵で食えるだけの稼ぎを得られていたと言うのが奇跡だったのだ。
本当にいい夢だった。
IT技術者、そんなにプログラミングをやりたければ、趣味でやれば良いのよ。仕事にするのはプロジェクトマネジメントやコンサルやって、しこたま稼いで超富裕層になろうよ。
建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？という質問がブコメであって、似たような話もいくつか見かけたのですが、建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです。なのでソフトウェアでは自動化されています。
もしも業務システムの納品物が、バベッジの階差機関のような歯車を組み合わせた機械式の計算機で、ビル一棟分に歯車をつめこんで組み立てて納品するというようなことになれば、多重下請けで分業してビルドするのが最もよい方法ということになると思います。
追記
「継続的デリバリーのソフトウェア工学」では、「ソフトウェア開発を選んだ私たちがバカでない限り、私たちにとっての製造とは、ビルドボタンのクリックです」とあります。橋梁建設を例に、物理的な製造・生産との違いが説明されています。
論文執筆は、多くの研究者にとって時に苦痛を伴う作業です。英語を母語としない研究者にとっては特に、言語の壁が大きな障害となります。ChatGPTは、この障壁を一気に取り払ってくれます。翻訳、校正、要約作成—かつては数日を要したこれらの作業が、数分で完了する。その魅力は、抗いがたいものです。
特定の分野、特にコンピューターサイエンスや工学系の論文において、ChatGPT特有の言い回しや表現が急増しているという傾向があります。これは、多くの研究者が既にChatGPTを論文執筆に活用していることを示唆しています。
この傾向は非英語圏の研究者の間でより顕著とのことであり、言語の壁を越えるためのツールとして、ChatGPTは確かに強力です。しかし、それは同時に、学術論文の画一化、さらには研究の多様性の喪失につながる危険性を孕んでいます。
私たちは今、学術界の大きな転換点に立っています。AIによる支援は、確かに研究のスピードと効率を飛躍的に向上させる可能性を秘めています。しかし同時に、研究の本質ー独創性、批判的思考、そして何よりも人間の知性による深い洞察—を脅かす存在ともなり得ます。
この新しい時代において、私たち研究者には、これまで以上に高い倫理観と批判的思考力が求められています。AIを賢く活用しつつ、真の学術的価値を守り抜く、そのバランスを取ることこそが、現代の研究者に課せられた使命かもしれません。
ChatGPTがもたらす功罪：効率と倫理のジレンマ
ChatGPTの登場は、学術界に変革をもたらしています。しかし、この技術は、メリットとデメリットを併せ持つ諸刃の剣です。ここでは、その功罪を詳細に分析し、我々研究者が直面する倫理的ジレンマについて考察します。
メリット：効率化の誘惑
(1) 時間の節約：単純作業の自動化
- ChatGPTは、文献レビュー、要約作成、参考文献のフォーマット調整など、時間のかかる単純作業を驚異的なスピードで処理します。例えば、数百件の論文要約を数分で生成することも可能です。これにより、研究者は 本質的な研究活動により多くの時間を割くことができます。
(2) 言語の壁の低下：非英語圏研究者の支援
- 英語を母語としない研究者にとって、ChatGPTは 頼れるツールとなり得ます。文法の修正、適切な学術的表現の提案、さらには全文の翻訳まで、言語面でのサポートは極めて強力です。これにより、研究成果の国際的な公表が促進される可能性があります。
(3) 文章の洗練：文法的正確性の向上
- ChatGPTは、文法的に正確で読みやすい文章を生成する能力に長けています。この特性は、論文の可読性を高め、査読者や読者の理解を助けるポテンシャルを秘めています。
デメリット：学術の本質への脅威
(1) 正確性の欠如：ハルシネーションと出典捏造の危険性
- ChatGPTは時として、存在しない情報や事実と異なる内容を「ハルシネーション」として生成することがあります。さらに危険なのは、実在しない論文や著者を引用するケースです。これらは、学術的誠実性を根本から揺るがす重大な問題です。（筆者注：このあたりは対策すれば防げます）
(2) 独創性の喪失：既存の再構成に過ぎない文章生成
- ChatGPTの生成する文章は、既存の言葉の再構成に過ぎません。真に革新的なアイデアやパラダイムを変えるような概念を生み出すことは、現状のAIには不可能です。過度の依存は、学術界の知的停滞を招く恐れがあります。
(3) 倫理的問題：盗用、AI authorship、論文millsの横行
- AIが生成した文章をそのまま使用することは、盗用と見なされる可能性があります。（筆者注：参照なしに他の論文を引っ張ってくる可能性は少ないですがAIの書いた文章をそのまま使うこと自体には倫理的に問題があると思います）また、AI自体を著者として認めるべきではないという AI authorship の問題や、ChatGPTを使用して大量の低質な論文を生産する「論文量産工場」の出現など、新たな倫理的課題が浮上しています。
この連休はなんだかSIerについて考えることが多かったのですが、そういうことを考えると、なぜアメリカのソフトウェアが強いのかがわかってきた気がします。
[...]そうすると、アメリカのソフトウェアを開発している人は600万人ということになり、「なぜアメリカのソフトウェアは強いのか」の答えのひとつが「日本の4倍のIT人材がかかわってるから」であり、ではなぜアメリカ国内でもIT人材が増えたかというと、設計をそのままコードに置き換えればいいような付加価値の低い部分はアメリカの国外にだして、アメリカ国内では高付加価値のソフトウェアに集中した結果「稼げる産業」になったからというのがあるんではないかと思います。
プロパー社員が詳細設計書を書き、派遣の方がプログラムするという建前になっているけど、実は詳細設計書も優秀な派遣の方が書いていて、その人の派遣契約をうっかり終了してしまってめっちゃ困るという光景をその昔見たことがある気がする。
納品前に実装者が詳細設計書を書き直す、というのは良くある話な気がする。ちゃんと書き直すだけマシという説もある。
原則として:
- nil, nil はダメ。エラーでなければ何らかの値かオブジェクトを返そう
パターンとして:
- エラーの一種で「なかった」を返す
- ゼロ値や特別な値
- 結果のオブジェクトが「なかった」を表現する
- 結果と取り出すデータが別になっている
コピーコストが問題になる場合を除いては、基本的に値を返すべきです。
なるべく値型を使用したほうがいい理由の一つとして、コードの保守性の問題があります。
値型の場合、メンバへのアクセスがエラーを引き起こさないことはコンパイル時に確定しています。
しかし、ポインタの場合は参照先が存在するかどうかは実行時にしか分かりません。
つまり、アクセスする前にnilでないかどうかをチェックするか、関数がエラーを返していない場合にnilを返さないことを知っている上で取り扱わないと、panicを引き起こす可能性があります。
2024年7月13日の大吉祥寺.pmで発表した「古典ドメインモデリング(パターン)の解脱」のスライドログです。
それがAlways-Valid Domain Modelです。これはドメインモデル(の実装)は、必ずValidな状態でなければならない、Validな状態としてしか生成できないようにしようというものです。 すなわちビジネスロジック層みたいなものは、業務上Validなデータのみを扱うAlways-Valid Layerとして考えよう、というものです。
某62万行だか67万行のゲーム
どんなコーディングしてんのかと思ってghidraにかけてみたけど
・変数はほぼすべて静的に配置されてる
・たしかにCreateWindowAから始まるとか、素のWin32 APIを使ってて、スクラッチからっぽい
・起動時に画像や音楽などすべてのリソースをメモリーに読んでる
・VC++6のデバッグ用のmemsetだかのシグニチャが検出されました。スタックフレームを0xccでうめるコードとかはいっててデバッグ用コンパイルオプションのままで製品用プログラムが吐かれてる
・最適化オプションはoff
・なかみは静的配置されたフラグと即値をの比較分岐の嵐。いわゆる「データドリブン」ではない。プログラムの塊でできている。
・どこでもセーブ・ロードができるのはそういうフラグデータの静的な領域をそのままファイルに書き出してるから。これはこれで皮肉なしにすごい
・exeファイルのなかみはすっからかん。100MBをちょっと超えるサイズだが、zip圧縮すると3.2MBにまで縮まる。
・画像とサウンドはEXE外だが、たぶんマップとかはEXEプログラム内なんだろう。
通常のプログラマーは頭が悪いので「楽をするために苦労をする」性質があり、なるべくあとから修正が楽にできるようにとか、プログラムをどのようにすれば見通しが良く保守性に優れるコードになるかを考えてるが、フォ◯ンアイルの作者は天才なのでそんなことはしない
あまり深く考えることなしに、地道にプログラムを書き続けてできた作品であることがうかがわれる。普通の人はその前に悲鳴を上げてもっと効率の良い方法に逃げる。
プログラミングのセンスや技術は最悪だが、努力という点では他の追随を許さないのではないだろうか。
ちなみに、普通にゲームをプレイする人にとっては、プログラミングの苦労なんてのはめっちゃどうでもいい話なので、プログラム頑張ったんだよ！は普通はアピールポイントにはしない。
頭の悪い普通のプログラマーはもっと短くコードを書いてしまうので普通はアピールしないだけだ。
もうすちーむに返品しちゃったからわかんないよ……ゲーム自体はprotonでちゃんと動くんだが、いろいろやる気が起きなくて。申し訳ない
グラフィックの枚数だとかそういうのはまだ自慢になるが、ふつうはプログラムコード量を自慢するのはよくない。
プログラムコード量がおおいのは、それに見合った規模のプロジェクトでない限り、「私はプログラムを効率よくコンパクトに書く能力がありません」と言ってるのに等しいので。
中身がどうであれ、一作作り上げて完成まで持っていったのはすごいよ。低レベルな話だが、ワナビーの中には妄想だけして手を動かさずに結局何もできないやつばっかりなんだから。
大した事がないエンジニアが社内でスーパーエンジニアだと持て囃され、営業は「スーパーエンジニアは難解なことを言うし、コミュ力が低いからこの人の言う事が理解できないのは仕方がない」と、商材理解を諦める、と言う共犯関係を大昔見た事があります
「スーパーエンジニア」側も、自分の本当のスキルを誤魔化すために適当なことを言ってケムに巻く、というムーブをするようになるという
無能なエンジニアと無能な営業が共に生き残るための共犯関係
当時の僕は今以上に性格が悪かったので、その「スーパーエンジニア」の誤りを淡々と指摘することで、社内で技術者として一定の評価を得た、みたいな事がありました
PyCon JP 2022の発表資料。
イベント駆動アーキテクチャについて実用的なTipsを交えて解説していきます。普段は手続型のプログラミングに慣れている方が、設計パターンから非同期タスクの運用までを理解していただけるようお届けします。
Ladybird は、まったく新しいブラウザと Web エンジンです。Web 標準を第一に考えたアプローチを採用した Ladybird は、優れたパフォーマンス、安定性、セキュリティを備えた最新の Web のレンダリングを目指しています。
SerenityOS 趣味のオペレーティング システム プロジェクト用の HTML ビューアとして始まった Ladybird は、その後、Linux、macOS、その他の Unix 系システムをサポートするクロスプラットフォーム ブラウザに成長しました。
Ladybird は現在、鋭意開発中です。2026 年に早期導入者向けの最初のアルファ版リリースを予定しています。
アルファ版がリリースされたら使ってみるか
Cloud-native search engine for observability (logs, traces, and soon metrics!). An open-source alternative to Datadog, Elasticsearch, Loki, and Tempo.
可観測性 (ログ、トレース、そして近々メトリクスも) のためのクラウドネイティブ検索エンジン。Datadog、Elasticsearch、Loki、Tempo に代わるオープンソースの代替品です。
2024年9月中旬に正式リリースが予定されている統合デスクトップ環境「GNOME 47」では大型のアップデートがいくつも予定されており、今秋リリース予定の「Ubuntu 24.10」や「Fedora Linux 41」などメジャーディストリビューションへの搭載も予定されている。現在、リリースに向けて多くのプルリクエストのマージが進められているが、6月27日にはGNOME Shell/MutterともにX11サポートを無効にし、Waylandのみでデスクトップ環境を構築できるオプションがリリースされた。
GNOMEでは2022年にX11の依存関係をオプションにするためのイシューが立てられ、Waylandのみのデスクトップ環境を構築する動きが活発化していた。今回のプルリクエストのマージにより、GNOME Shell/MutterともにX11の依存関係を必要とすることなくビルドできるようになり、GNOME 47でのX11フリー環境が実現することになる。
https://anond.hatelabo.jp/20240625191650
競プロ出身者だけじゃなく、機械学習出身者も問題コードが多い
印象の問題ではなく実際に下記のようなコードが多い
念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある
■ 正常系しか意識していない
一番多いのはコレで異常系の動作を全く意識していない
入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない
「エラーが出たらとにかくtry-catchしてログ吐いて終わり」
ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる
「ここの処理でエラーログが出てるから対処よろしく」
「対処しました！（握りつぶし）」
とか滅茶苦茶多い
■ セキュリティに関する意識が低い
異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い
API作らせてもリクエストの内容を信用して実装するしサニタイズチェックもしない
サーバー作らせてもrootか共通ユーザーだけで運用するしファイル管理も滅茶苦茶
とにかく「目の前に与えられた課題を解く」だけのコードなので他のことに関する配慮が全く無い
■ 型定義しないし配慮しない
TypeScript使わせてもanyだらけだし、JavaとかだとObjectだらけ
うちはPythonでは型は使わないけど命名規則で担保してるのにそれもガン無視で実装する
結果としてできあがるのは
「一応、正常系では動いているけれど他の入力が来たときにどうなるか分からないし誰も修正できない」
っていうコード
最近はそういうコードはChatGPTにぶち込んで型付けて貰ったりするけど
8割ぐらいの確率でChatGPTも型付けできない状態になっててお手上げになる
■ コピペコードが異常に多い
ネット検索したコードのコピペ、ではなくて
自分で書いたコードのコピペがめっちゃ多い
全く同じ処理なのにメソッド化しないでコピペしてたり
一部の変数を切り出すだけでメソッド化できるのにコピペしてる
そりゃ動くし性能も変わらないけど後でバグがあったり変更するときにすげー困る
これもChatGPTにぶち込んで「共通的な処理をメソッド化して」って言うとやってくれるのでめっちゃ便利
■ 結果が出るだけでクソ遅い（機械学習出身者）
同じファイルをオンメモリに3回ぐらいロードしたり
ほぼ同じDBへの問い合わせが10回ぐらい走ってたり
クソ重いwhileループになってるメソッドをフレンドリーに何回も呼び出したり
とにかく「最終的に出来上がるものが良好であれば時間がかかっても構わない」的なコードが非常に多い
競プロ系はこういう人はあんまりいないんだが機械学習出身者はマジでこれ
彼らはデータを解析したり優秀なモデルを作るために頑張ってきたので継続的に処理負荷を減らす、みたいなことに意識が回ってくれない
「これはPoCですから」
とか言うんだけど誰でも分かるようなクソ遅いコード書いておいて
「ここの処理は時間かかります」
とかしれっと言ってくる
anond:20240624084844 を読んで思ったこと。2番目以降は正直良くわからないが、一点目についてはわかりみしかない。
うちはメガベンチャーで内製アプリの開発保守をしてるんだが、新卒で採った青(水色？)のエンジニアが連続でクソ野郎でめちゃくちゃしんどかった。
■ ◯色コーダーマウント
ちょくちょく自分は◯色コーダーだって主張してくる。
こっちはお前が学生時代に取った資格の話なんて興味ねえんだよ。
センター試験の点数自慢してる社会人いるか？いねえだろ。
評価されたければ与えられたタスク以上の成果を挙げろ。
資格自慢をしたければ、社会人にふさわしい資格を取れ。
お前のガクチカなんぞ知らん。
■ コードがゴミ
競プロエンジニアといっしょに仕事したことある人なら大体頷いてくれると思うんだが、彼らの書くコードは本当にひどい。
処理がどれだけ効率的だろうが、実務においてメンテナンサビリティの無いコードはゴミだということが理解できないらしい。
しかも彼らは「コードは短くて高速なのが善」という前提を頑なに信奉しているので、注意しても聞く耳を持たない。
実験でPython触ってましたくらいの理系プログラマの方が可塑性があってよっぽど有益だ。
■ 典型的ブリリアントジャーク
PRやSlackの文面がいちいちキツく、他のチームメンバーを萎縮させることもしばしば。
「そんなこともわからないんですか」って本当に言う(しかも文面が永久に残る場所で)やつ本当にいるんだ、って驚愕した。
しまいには自分の業務と全く関係のないリポジトリにゴミPRを投げて別の部署との間で一悶着起こす始末。
流石にこれについては上長経由で苦情が来たので、コミュニケーションに問題があるって人事評価で伝えることになった。
コイツらのせいであまりにも空気が悪くなり、部署全体のミッションとして「心理的安全性を高めよう」と書かざるを得ないところまで行った、といえば影響の大きさがわかるだろうか。
最終的に二人共インフラ系の部署に移ってくれて、俺等は内心ホッとしている。同じような経緯で追放された赤コーダー二人の下で、彼らの好む"競争的"環境をさぞ楽しんでいるに違いない。
■ 自律性のなさ
彼らは与えられたタスク以上の「余計なこと」をやらない。
これはまだタスクとして振られてはいないけど、間違いなく誰かがやらないといけない事だから自分の仕事にしてしまおう、みたいな気の利くムーブができない。
先見の明に欠けるというか、たぶん、彼らの中には「上から問題が与えられ、それをクリアできたら合格」という価値観が染み付いているのだろう。
もっと悲観的に捉えると、むしろ同僚を貶めれば相対的に自分の評価が上向くと思っているので、チームメンバーへの協力を積極的に回避しているのかもしれない。
不思議なのが、この子達、出身も大学も全然違うのに上記の問題行動は共通してたんだよね。
競技プログラミングが学生の人格を歪めているのか、元々歪んだやつが競技プログラミングにハマるのかわからないけど、何らかの相関はあると確信してる。
…とはいえ、もしかすると我々は彼らにとって役不足だったのかもしれない。競技プログラミング出身者を採って上手くハンドリングできてる事例があったら教えてほしい。
いずれにせよ、うちは全社的にエンジニア採用の時に競技プログラミング実績は加味しないという方針になった(実際のところはマイナス評価点になっているらしいが)ので、このような悲しいミスマッチはもう起こらないだろう。
既存のプッシュ通知システムは、XMPPサーバーである「ejabberd」を利用して、複数クラスタで構成。AWSのAmazon EC2やAmazon RDSなど、実績のある安定したサービスを採用していたという。
リプレイス後のシステムでは、ロードバランサーには「ELB（Elastic Load Balancing）」を、コンピューティングリソースにはサーバレスの「AWS Fargate（ECS on Fargate）」を、データベースには「DynamoDB」を採用した。
Nintendo Switchがプッシュ通知システムに接続する流れは次のとおりだ。まず、ID払い出しサービスにアクセスして、プッシュ通知システム用のIDを作成する。その後、接続先振り分けサービスへアクセスし、接続する常時接続サービスのURLを取得する。そして、常時接続サービスが、Nintendo SwitchとTCPコネクションを確立、長時間接続を維持する。接続中には、HTTP/2を利用した独自プロトコルで双方向通信する。
この常時接続サービスは、NLB（Network Load Balancer）とECSサービスをひとつのUnitとして、複数のUnitに分割されている。本サービスの性能要件は、“最大1億台の同時接続”に耐えうるスケーラビリティだ。
逆に、Nintendo Switchに通知が送られる流れは次のようになる。まずネットワークサービスが、プッシュ通知システムが用意する通知送信用APIを利用して通知を送信。正常に受け付けられた通知は、メッセージキューイングサービスである「Amazon SQS」に保存される。
そして通知振り分けサービスがSQSから通知を受け取り、DynamoDB上のセッション情報を用いて、対象のNintendo Switchが接続する常時接続サービスのFargateのタスクを特定して通知を送る。最後に、通知を受け取った常時接続サービスが、対象のNintendo Switchに対して通知を届ける。
「なぜ」を「WHY」以外の4W1Hに言い換えて質問します。
例文1
「なぜ進捗が予定よりも遅れているの？」
WHATを使う：「何が遅れの要因になっているの？」
WHENを使う：「いつのきっかけから遅れ始めたの？」
例文2
「なぜその仕様になったの？」
WHATを使う：「そのソリューションにした決め手は何だったの？」
HOWを使う：「どういう経緯でその仕様に至ったの？」
WHEREを使う：「どこか参考にした情報があったの？」
例文3
「なぜルールを破ったの？」
WHATを使う：「何があなたをルール破りにさせてしまったの？」
WHEREを使う：「ルールのどういうところが守りづらかったの？」
Googleは、超高速に評価できて移植性が高い、安全に実行できる式言語「Common Expression Language」（CEL）を発表しました。
[...]CELは正にこうした要件に対応した式言語となっており、Googleは次のような特徴があるとしています。
- ナノ秒からマイクロ秒程度の高速な評価に最適化されている
- C++、Java、Goでサポートされるスタックによるポータブル性
- 何千もの適合性テストにより、スタック間での一貫した動作を保証
- 言語の拡張とサブセットをサポート
AWSは2023年に似たような用途のためにポリシー言語「Cedar」をオープンソースで公開しています。
またCELは真（True）、偽（False）、エラー（Error）、不明（Unknown）の4値論理を備えていること、SQLにシームレスに変換できることも特徴と説明されています。
特に大量のデータに対してCELを適用する場合、1つ1つのデータにCELを評価するよりも、データベースにSQLクエリを投げて処理する方が高速になるケースが考えられるとして、SQLへの変換可能性は高性能な式言語の設計における重要な要素だったとのことです。
急ぐ必要は無いんだ。20年間、ドメインのことを考え続け、技術も学んで、少しずつ実践を続ければ、誰でも、素晴らしいプロダクトを作れるようになる。「明日から現場で使えること」を追い続けていたら、20年後も「明日から現場で使えること」を追っているだろう。
時間を味方に付ける。多くの人は、急ぎ過ぎることによって、時間を敵に回している。ちょっとやってはあきらめ、ちょっとやってはこれじゃ間に合わない、ダメだと嘆き。それを繰り返している。
Blind For Businessに、2024年2月29日に、Microsoftは日本でソフトウェアエンジニアを募集しているかと質問したユーザーに対して、日本マイクロソフトは、最近、エンジニアチームの80％をリストラし、現在20人足らずしか残っておらず、アカウント・エグゼクティブ、営業担当者、マーケティング・スペシャリストだと返信が付けられていました。
この小さなエンジニアチームは、例えばAzureを使ったシステム設計など、マイクロソフトに顧客を取り込むための対外的なコンサルタント業務のみを行っていて、基本的には技術的な売り手だそうです。
株式会社ドワンゴ（本社:東京都中央区、代表取締役社長:夏野剛）は、2024年6月8日付けのニコニコインフォで公表したとおり、6月8日早朝から当社が運営する「ニコニコ」のサービス全般を利用できない状態が続いております。本障害は、ランサムウェアを含む大規模なサイバー攻撃によるものであることが確認され、現在サービスの利用を一時的に停止し、被害状況の全容把握と復旧に向け、調査と対応を進めております。
当社は、サイバー攻撃を確認後、直ちに関連するサーバーをシャットダウンするなど緊急措置を実施するとともに、対策本部を立ち上げ、被害の全容解明、原因究明およびシステムの復旧対応に総力を上げて取り組んでおります。現時点までの調査で判明した内容および今後の対応について、以下の通りご報告いたします。
ユーザーの皆様、関係者の皆様に、多大なるご迷惑とご心配をおかけしておりますことを心より深くお詫び申し上げます。
わし詳細設計書書くのやだよ(￣･ω･￣)
細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ
改修コストを下げるための設計になってることは前提だけどね。
だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書いらないわけで…
必要に応じて状態遷移図とかシーケンスとか、ER図書くのは許されるけど、日本語の文章で書かれたドキュメントなんていらん。完了条件だけくれ。そこからテストコード起こして、それで機能を満たしているか検証する。これだよ。
「どの言語を使って開発してもらってもいいです」
「ほんとですか？じゃあPythonやGo、Rustあたりを使ってサクっと開発したいんですが」
「その、GoやRustっていうのはちょっと…」（※）
「え？どの言語でも良いって言ったじゃないですか？」
「言いましたけど、そのGoやRustを扱える技術者が集まらないんです」
「それって、どの言語でもいいわけじゃなくて、技術者を集めやすい言語の中で、どれでもいいのを選んでねってことですよね？」
「ええ、そうなります」
「ちなみに開発者を集めやすい言語というのは？」
「JavaやC#になりますね」
「・・・（選択肢が狭すぎる）」
という会話を最近したんだけど、残念すぎる。集めた技術者に覚えさせればいいじゃない。どの言語でもいいなんて言うから、そう思うじゃない。
（※）話した人自体が、そもそもRustのことをそもそもご存知じゃなかった。
固定スクロールをオンまたはオフにする
- Visual Studio のメニュー バーで、[ツール]>[オプション]>[テキスト エディター]>[全般] を選びます。
- [固定スクロール] セクションで、[Group the current scopes within a scrollable region of the editor window] (エディター ウィンドウのスクロール可能な領域内で現在のスコープをグループ化する) チェックボックスをオンにします。
アプリケーション全体のテストを書くには、外部リソースに依存する部分をレポジトリとして抽象化することが大切です。 アプリケーションから外部依存をレポジトリとして分離することでロジック自体のテストが書きやすくなります。 完全なクリーンアーキテクチャを採用していなくても、外部依存要素を抽象化し、テストを簡素化するという考え方は有効です。 レポジトリの実装のテストは、実際のリソースを用いるかエミュレーターを利用するかなど、状況に応じて適切な方法を選択していきましょう。
弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。
バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。
長年にわたりISOイメージ形式で配布してきた「Ubuntu日本語Remix」ですが、Ubuntu 24.04 LTSではリリースしないことに決定しましたのでお知らせします。
理由は以下の通りです。
- 新しいインストーラー採用に伴うカスタマイズ難易度の増加
- Ubuntu 24.04 LTSから新しいインストーラーが導入され、ISOイメージのファイル構成が変更されました。この変更により、ISOイメージをカスタマイズすることが難しくなりました。
- 多言語ライブ環境の非対応化
- Ubuntu 24.04 LTSの公式ISOイメージは英語以外のライブ環境に対応しておらず、日本語ライブ環境を実現するためには大きな変更が必要となりました。
Ubuntu日本語RemixのISOイメージの主な利点は、日本語ライブ環境が使えること、およびインターネット未接続状態でも日本語のデスクトップ環境をスムーズにセットアップできることでしたが、同様の対応をUbuntu 24.04 LTSで行うことは上記の理由で困難であるため、リリースをスキップする決断に至りました。
24.10以降のバージョンについても同様となる見込みですが、ISOイメージのカスタマイズ機能が提供されるなど状況の変化により再びUbuntu日本語Remixの配布を行うことになった場合は、改めてお知らせいたします。
Windows は I/O 関連の API はぜんぶ Windows Defender や 3rd party のために filter/hook でウィルススキャナとか噛ませるフレームワークみたいになってるはずなので、TeX に限らず小さなファイルたくさん I/O する処理は全部絶望的に遅いはず（git とかもそう
Windows でも TeXLive のアップグレード作業完了。動作確認で typeset したら、絶望的に遅かった（学部時代、よくこれでレポート作成してたな...）。これだと確かに Overleaf で良いわってなる。
なぜ TeX はここまで Windows との相性が悪いのか。
ReFS (Resilient File System) でフォーマットされる DevDrive とか作ってそっちでやる、とかやるしかなさそうで、公式に npm や pip や cargo のパッケージキャッシュの読み書きする場所を DevDrive に逃す方法まで案内されてる
あとは Windows Defender そのものを無効化するとかでも似た効果は得られるはずだけどさすがにそれは危険性が高すぎるので特定のファイルツリー配下でのみ無効化できる DevDrive をつくろうということで……（パーティション増やさなくても VHD のディスクイメージ作ってマウント、もできる
旨い小料理屋に行くと、なんでも旨いし、不味い店はなんでも不味い。旨い店の亭主は味覚がちゃんとしているから、不味いものなんて出せないんだな。ソフトウェア作りもこれと同じで、あれが出来てこれが出来ないということは、本当は無いのだろうと思っている。
世の中の一部の設計論は、とにかく味の素を振れ、みたいなことを言っている気がする。それが「設計原則」だそうだ。
最近、社内外からマネジメントの相談を受けることが多くなりました。
「どうすればマネージャーになれますか？」と「どうすればマネジメントができるようになりますか？」の2つが多いです。
結論、知らんし、わからん。です。
ただ、自分なりに2つの真理があります。
1. マネジメントに最も必要なスキルは胆力。
2. 人は、自分が受けたマネジメントしか他人にできない。
色々見えるようになってきてわかったのは、マネジメントの仕事っていうのは、定量的に見るとチームのKPIの達成ですが、実際にはその達成のためにこういう感じのことをする仕事のことなんだと思う。
放置できない問題であれば、首も手も突っ込んで自分で動かす。他人の失敗が原因だったとしても。
歪みのない完璧な状態はいつだってないって前提で歪みに正面から向き合ってなんとかする。歪みを嘆くだけにしない。
思い通りに他人が動いてくれたら奇跡くらいの気持ちで全体のバランスをとる。他人が思い通りに動くと思ってるのは娘（4歳）だけで十分。
間違ったときは、「ごめん、私が悪かった」って言う。しょうもないプライドは捨てる。
厳しいことちゃんと厳しく言う。言える距離感を保つ。
部下を守る。自分の立場や周りからどう評価されるかとかは後回し。
数字と正しい言葉で話す。それっぽい雰囲気でうやむやにしない。
最後に、「どうすればマネージャーになれますか？」と「どうすればマネジメントができるようになりますか？」の2つに答えて終わります。
どうすればマネージャーになれますか？
マネージャー = 役職（ラベル）であればアサインされたらなれます。
マネージャー = マネジメントの仕事をする人であればマネジメントができるようになればなれます。
どうすればマネジメントができるようになりますか？
あなたがなりたい姿のマネージャーと一緒に働くか、経験豊富なマネージャから学ぶ機会を持って、セルフフィードバックサイクルを続ければできるようになります。
（私は今でも師匠にサウナでよく相談します）
株式会社KADOKAWA（本社：東京都千代田区、取締役 代表執行役社長 CEO：夏野剛）は、現在当社グループの複数のウェブサイトが利用できない事象が発生していることをお知らせいたします。この原因として、現時点では、当社グループが利用しているサーバーに対して、外部からの不正なアクセスが行われたことによる可能性が高いと分析しております。
お客様、お取引先様をはじめ、関係先の皆様に多大なるご心配とご迷惑をおかけし、深くお詫び申し上げます。
本件について、影響を最小限にとどめるべく、システムの保護と復旧に向けて、現在対応を進めております。現時点で判明している内容について、以下の通りご報告いたします。
1. 経緯
6月8日（土）未明より、当社グループの複数のサーバーにアクセスできない障害が発生しました。この事実を受け、データ保全のため関連するサーバーを至急シャットダウンしました。同日中に社内で分析調査を実施した範囲においては、サイバー攻撃を受けた可能性が高いと認識しております。
2. 現在の状況
現在、調査・対応を進めておりますが、現時点で「ニコニコサービス」全般、「KADOKAWAオフィシャルサイト」、「エビテン（ebten）」などで影響が発生していることを確認しております。なお、情報漏洩の有無についても調査を進めております。
３. 今後の対応
今後、外部専門家や警察などの協力を得て調査を継続し、迅速に対応を進めてまいります。より正確な影響範囲を調査・特定し、お知らせすべき新たな事実が判明しましたら、改めてお知らせいたします。
以上