最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

スタートアップブームの「終わりの始まり」は、VC のファンドサイズが小さくなり始めることだと考えています。それを契機に悪循環が始まるからです。 理屈はこうです。 ファンドサイズが小さくなると、スタートアップが調達できる資金も小さくなります。そうすると、大きな挑戦ができなくなり、大きな事業や成果も出づらくなります。するとさらにファンドサイズも投資も減って、スタートアップが挑戦できる事業の規模感も小さくなり、小さな事業しか目指せなくなります。 こうした悪循環が起こり始めると、エコシステムは縮小均衡へと向かっていくことになるでしょう。 今、日本のスタートアップエコシステムは、そうした悪循環に入る瀬戸際の場所にいるように思います。 そうした危機感を共有したく本記事を書いています。 リターンが返せる見込みが薄くなってきた 毎年 1.8 兆円のリターンが必要 現状は総リターンが 1 兆円に達していない

はじめに 様々な曲の楽譜をデータとして扱えたら楽しそうだと思いませんか？ かといって手動で入力するのも大変です。どこかでダウンロードできると嬉しい… 調べてみたところ、クラシック音楽の楽譜データの多くがCC Zeroライセンスで公開されていることが分かりました。この記事では、 好きな曲の楽譜データを検索・ダウンロードする方法 楽譜データのファイル形式・解析方法 Pythonを使って楽譜データをプログラム中の配列として取り込む方法 取り込んだ楽譜データをグラフで可視化する方法 を紹介しています。 目次 はじめに MusicXMLファイルのダウンロード MusicXMLファイルの展開 拡張子を.mxlから.zipに変更 解凍 確認 MusicXMLの内容 どこが重要か パートリスト パート 1. <measure number="1" width="***">：小節 2. <attribute

多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん

プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく２つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その２つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命

Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio

私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや

絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の

とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。（口頭で何時？と聞かれたら14時と答えるかもしれないけれど） つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題

イントロダクション みなさまお疲れ様です、次世代システム研究室のY.Tです。 Pythonを駆使して金融ビッグデータと格闘する日々をすごしています。 最近はめっきり気温が下がって、さすがに冬らしくなってきましたが、皆様はいかがお過ごしですか？ 私の方ですが年末は、帰宅後に正月飾りのデプロイや、もち米を炊いてお餅のビルドに忙しく取り組んでいました。 特にお餅は、もち米を炊くときの水加減がうまく行ったみたいでして、正月中予定のクオリティチェックやクロスレビューが楽しみです。 (追記:2018/01/09) お餅おいしかったです。ホームベーカリーを使っても、おいしいお餅が作れることを確認できました。 さて、今回のブログエントリーのテーマは、なんと「AIによる自動プログラミング」です。 昨今はどこのメディアでも、AIが人間の仕事をどんどん出来るようになると盛んに記事が掲載されています。 コンピュー

なぜ令和にもなって動的型付け言語を使うのか シフトレフトという概念が生まれたのは二十年以上も前のはずだ。 それにもかかわらず動かしてみるまで答え合わせもできない言語で開発をするという発想自体がどうかしている。 同じ動的型付けといってもJavaScriptはブラウザという事情があるし、型の表現力に優れたTypeScriptがあるからまだよい。 しかし、Pythonはどうだ。他にいくらでも選択肢があるなかで、サーバーサイドにわざわざ選定する言語ではなかろう。 貧弱な型ヒント、しかも書いたところで大した効用もない。 使っている外部ライブラリにひとつでも型ヒントがクソなものがあれば即座に破綻する。 型というガードレールもシートベルトもなしで糞を撒き散らしながらする開発にはうんざりだ。 シンタックスもキモい 動的型付けもさることながら、シンタックスもキモい。とにかく思考を妨げる語順になっている。 m

ブラウザ業界は LLM（Large language Models 大規模言語モデル）機能を統合するというトレンドを避けるわけにはいかないようですが、Vivaldi は、この機能には本質的な問題が存在していることをユーザーに喚起したいと思います。 ChatGPT が 1 年数か月前に公に登場し、今もなお注目を浴びています。それ以来、多くの分野において、人間がするいくつかのことを ChatGPT に代替させようとしたり、疑問に思ったことに対する答えを見つけるのに役立てたりしようというトレンドの波が一気に高まりました。 ウェブブラウザ業界でも、何かにつけて LLM 機能を統合しようとするブラウザが複数見られます。 しかし、未来の構築という名目の元に行っているとしても、機能の明らかな欠陥を全く考慮していないように思われます。例えば、LLM 自体は文章要約エンジンや会話パートナーとしては全く適して

独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。 今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹

２人の間で秘密の暗号通信を行うには、まず最初に２人だけが知っている共通のキーワード〜鍵を取り交わす必要がある。 しかし、２人が遠く離れていて、盗聴の危険性のあるインターネットでしか通信できないとしたら、 どうやって最初の鍵を取り交わすことができるか？ この難問を解決するアルゴリズムとして「ディフィー・ヘルマン鍵共有」が知られています。 >> wikipedia:ディフィー・ヘルマン鍵共有 あからさまに盗聴されている通信路だけを使って、２人だけの秘密を共有する・・・ そんな一見不可能に思える離れ業を、どのようにして実現するのでしょうか？ ディフィー・ヘルマン鍵共有（以下、ＤＨ法と略）の基本となる考え方は、以下の図から出発します。 いま、アリスとボブの２人が、２人だけの秘密の数字を共有したかったとしましょう。 まず、アリスが数字Ａを、ボブが数字Ｂを決めて、お互いに交換します。 そして、お互いに

シカゴ大学の研究チームがAIによる画像学習を防止するツール「Nightshade」を開発しています。Nightshadeを用いて画像を処理すると画像の見た目を大きく変えずにAIによる学習を阻害することが可能とのことです。 [2310.13828] Prompt-Specific Poisoning Attacks on Text-to-Image Generative Models https://arxiv.org/abs/2310.13828 Meet Nightshade, the new tool allowing artists to 'poison' AI models | VentureBeat https://venturebeat.com/ai/meet-nightshade-the-new-tool-allowing-artists-to-poison-ai-model

こんにちは、ヌーラボTypetalkチームの伊藤です。 本記事はブログリレーの7/26分になります。 植物の観察日記をつけたことがありますか？ 皆さんは、植物の観察日記をつけたことがありますか？ 夏休みになると宿題として課される、アレです。 私はいままで一度もこの課題をやり遂げられたことがありません。私の夏休みは常に「植物の観察日記をやり遂げられなかった」という悔しさで幕を閉じます。 20年以上経った現在でも、夏がくると思い出します。このままでは夏を心から楽しむことができません。そこで、この夏をかけて自身のトラウマを克服すべく、植物の観察日記にリベンジすることにしました。 なぜやりとげられないのか？ 私なりにやり遂げられない原因を考えました。 毎日の水やりが面倒くなってしまう 植物の絵を描くのがストレス 途中で飽きてしまう これらは、私自身の問題に繋がります。 “毎日コツコツ” “決まった