/note/tech

DIP(依存性逆転の原則)を守っていない話

MEMO:

読みやすいドキュメントを書くために今日からできる7つのこと

MEMO:

reasonset/mozcdict-ext

概要

本ツール群は Mozc-UT (Mozcdic-UT) を失ったことによる損失を埋めるための「緊急避難」として使うために作られた。

本ツール群はMozc外部のリソースからMozcシステム辞書を構築する。 これをMozcに組み込んでビルドすることにより、Mozcの語彙力を増加させることができる。

本ソフトウェアにそのようにして生成された辞書は 含まない 。 また、 Mozc本体も含まない 。

このようなソフトウェアにするのはいくつか理由があるが、まず本ソフトウェアが、東風フォント事件におけるさざなみゴシックのような「緊急避難」であることを理解してほしい。 つまり、何年かかるかは分からないが、安定した開発が行われる、優れたかな漢字変換ソフトウェア及び辞書が誕生するまでの「つなぎ」である。

その意味で「つなぎ」として機能しやすいようにこのようなソフトウェアにした。 これは、Mozc以外のソフトウェアからもMozcシステム辞書からの変換とすることで利用しやすいようにし、かな漢字変換ソフトウェアの発展を促す意味もある。

Mozcdic-UTとの大きな違いは以下になる

  • オープンなプロジェクトであり、ライセンスがGPL v3である
  • ソフトウェアは辞書生成のためのツールであり、生成された辞書ではない
  • Mozcdic-UTは一般名詞のみを対象とするが、Mozcdict-EXTは品詞を制限しない

おぉー

EUの「チャット規制法」でLinuxなどのオープンソースOSが違法化してしまう可能性大

欧州議会では、メールやチャットサービスの提供者に通信内容の監視を義務付ける「チャット規制法」が議論されています。このチャット規制法について「規制対象がオープンソースOSのパッケージ管理システムにも及んでおり、既存のOSが違法状態になる可能性がある」という懸念が指摘されています。

チャット規制法は2022年5月に欧州議会に提出された法案で、メールやチャットサービスの提供者に対して「通信内容の常時監視」「年齢確認の実施」などを義務付けることを目的としています。この法案では通信暗号化の有無に関係なく通信内容を監視することが求められるため、「プライバシーの侵害につながる」「虚偽の報告による誤審のリスクが高まる」といった理由から法案に反対する声も多く寄せられています。

チャット規制法の問題点は、「法案の規制範囲が広すぎる」という点にもあります。法案ではメールやチャットサービスの提供者だけでなく、アプリケーション配布プラットフォーム(software application stores)も規制対象となっており、該当プラットフォームにも年齢確認や年齢制限を義務付けています。

EUも中国みたいになってきたな。

Twitter、APIを有料化へ 無料提供は9日で終了 「詳細は来週発表する」

米Twitterは2月2日、Twitter APIの無料提供を9日で終了すると発表した。対象になるのはバージョン1.1、2の両方で、代わりに有料版を提供するとしている。同社の開発チームのTwitterアカウント(@TwitterDev)が明らかにした。

サードパーティーのアプリやサービスを滅ぼしたい感じなのだろうか。

月額2600円で使える有料版「ChatGPT Plus」がついに登場

ChatGPT PlusはChatGPTのパイロットサブスクリプションプランで、月額20ドルで利用でき、サブスクライバーは以下のメリットを享受できるとのこと。

・ピーク時でもChatGPTへの一般的なアクセスが可能

・応答時間の短縮

・新機能とアップデートへの優先アクセス

ただし、記事作成時点ではChatGPT Plusはアメリカのユーザーのみ利用可能で、利用希望のユーザーは以下のウェイティングリストに参加すればOK。ウェイティングリストからユーザーを招待するプロセスは今後数週間のうちにスタートし、その後、アメリカ以外の国と地域へのアクセスサポートも拡大していく予定です。

おぉー

【第1回・前編】 エンジニア和田卓人の今を形作る技術

あとで読む

KDDIのクラウド障害、完全復旧には2週間以上かかる可能性【訂正あり】

1月28日午前4時ごろから約80時間にわたって障害が発生しているKDDIのクラウドサービス「KDDI クラウドプラットフォームサービス」。同社は31日、完全復旧に2週間以上かかる可能性があると明らかにした。

障害は「jp2-east05」ゾーン(リージョンを構成するサーバ群の単位)の一部サーバでストレージが故障したことで発生した。ただし、原因はハードウェアではなくソフトウェアの問題という。

確かにこの様では国産のガバメントクラウドなんて厳しいのかもしれんな。

「3年前に戻れるなら、同じ意思決定はしない」マネージャーをなくしたサイボウズから学ぶ、フラット型組織...

3年前、「kintone」や「Garoon」などを手掛けるサイボウズの開発本部が発した「マネージャーをなくす」宣言。多くのエンジニアを抱える大所帯で、業界でも先駆けとなる組織階層の撤廃は、大きな驚きをもって受け止められました。職能ごとに整理された組織から、プロダクトごとにアジャイルで開発できる組織へ——そんな方針のもと、フラットな組織づくりへと舵を切ったのです。

マネージャーポジションをなくした結果、採用や給与評価、健康管理など難易度の高いタスクが組織運営チームに一気に集中したんです。(中略)結果、わずか6名で約200名のピープルマネジメント業務をこなす状況になってしまいました。

2022年の始めに組織改善プロジェクトを立ち上げて、まず一度サイボウズにあるべきマネジメントの形について責任者を集めて考え直しました。話し合う中で出てきたのが、1人がマネジメントできるメンバーの数は、せいぜい5〜8人程度だということ。となると、200人の組織には、できれば40名くらいマネージャーが必要な計算になります。そこで、階層型のマネジメント組織をつくることに舵を切りました。

データベースドキュメント生成コマンド tbls 更新情報(Mermaid対応 / schema.json / tbls outの強化)

人気のJavaScriptバンドルツール「webpack」の開発はなぜ終わり、後継として「Turbopack」の開発が...

ところが、このwebpackの開発は事実上終了しており、開発者は現在Next.jsの開発企業であるVercelに移籍して、後継となるTurbopackの開発に取りかかっています。

Tobias氏はブログの中で、webpackは10年前のニーズを念頭に開発されたものだったと振り返ります。

もはやwebpackの後方互換性を維持しながら、webpackを進化させていくのは困難だったと説明が続きます。

webpackはNode.jsを基盤としたJavaScriptで開発されています。しかしJavaScriptベースのアプリケーションはCPUインテンシブな処理においてマルチプロセッサ搭載マシンの能力を十分に引き出すことは困難であるとTobias氏は指摘します(おそらく大量のモジュールの依存関係を解決する処理がCPUインテンシブなのだと思われます) 。

アーキテクチャは差分だけをビルドすることで効率的なビルドが可能になるインクリメンタルビルドには適しておらず、プラグインが何でも出来るようになっていてwebpackへの依存が大きく、それゆえに後方互換性のために大きな変更が難しく、キャッシュの無効化はセンシティブで影響が大きく、キャッシュのルックアップコストが大きいためモジュール数が増えるとそのコストがばかにならなくなってくる、といった指摘が続き、前述のようにこのままでは大きな変更は難しかったと説明。

式年遷宮みたいなもんか。

移行しやすければ何でもいいけど。

常駐している協力会社社員の気持ち

他社に常駐する形だと、どんなに知識を得て、信頼を得ても、現場の社員以上の責任も権限も得られないのがわかるだろうか。私自身は、何回かの「協力会社社員」の経験を経て、30代半ばで元請側に行くことになる。

結局は、主役になれない、責任を持てない、と言うことに対する課題は、転職でしか解決できない。人を送り出している会社が、自分で責任を持つ事業を行うことって、かなり難しいこと。商売の根本から違うためだが、この辺りの差は今回は述べない。

SESとか下請けやってる企業の問題はここに集約されてしまう。

エンジニア個人としては会社のビジネスそのものを変革するのはハードルが高すぎるので、自社で本物のビジネスをやってる会社に転職してしまうのが一番良い。

SESや下請けを取っ掛かりにして、転職でステップアップしていく人生スゴロクも楽しいものだ。

ChatGPTを筆頭に信じられないレベルでAIが進化しているが「なぜAIがこんなにも『急激に』質が良くなったか...

量が質に転換するというのは何事にもあるものなのだな。

ゼロランタイムのミニマルな静的サイトジェネレーター『dodai』の開発と JSX First な世界観について

ミニマルを指向するという点はとても興味深い。

astro.jsにも興味はあるのだが。

【山田祥平のRe:config.sys】いつまで続くノートパソコンの時代

個人的にはスマホにモバイルディスプレイとキーボードを付けて作業できるようになって欲しさある(現時点でも一応できるけど)。

あるいはラズパイサイズのSBCをいい感じに持ち歩くとか。

docker としての asdf ― あるいは、なぜ私は anyenv から乗り換えたか

asdf を使えば、任意のディレクトリに紐づく言語のバージョンを指定でき、そのディレクトリに移動したタイミングで、当該のバージョンへの PATH を自動で通すことができます。

一方で、WEB フロントエンドやモバイルアプリなど、本番環境で docker を利用しないシチュエーションというのも存在します。そのような場面でも、各開発者間の環境差分をなくすという観点から、 開発環境として docker を利用するメリットがあります。一方で、ディスク I/O が遅いといったパフォーマンスなどのデメリットが存在するのもまた事実です。 特に iOS アプリ開発に関しては、macOS の docker image が公式に存在しないことから、開発を docker 上で行うことは困難を極めると言っていいでしょう。

そのデメリットがメリットを上回ったと判断される時、ローカル開発環境としては docker を利用せず、各開発者の PC 上で環境を用意する運用となります。 その場合、リポジトリの README などに言語やツールのバージョンを記載し、各開発者がそのバージョンをインストールするよう求められることになりますが、asdf を利用すれば、asdf install などのコマンドで全てのツールを一度にインストールすることができます。

ふーむ

Dockerが使えるならDockerを使えばよさそう。

文中でも触れられてるように、Docker Imageが存在しないMac系の開発の場合は有益っぽい。

「わかりやすさ」を デザインする情報アーキテクチャ必修入門

停滞感のある、いわゆる「中小企業っぽさ」の正体は何か。

これは私見ですので、異論のある方もいると思いますが、あえて断定します。

「中小企業っぽさ」とは「すぐに目に見えて売り上げのあがること」にしかお金をかけない(かけられない)会社のカルチャーのことです。

規模や文化、ワンマン社長か否か、キャッシュリッチかどうか、そういった話とは全く関係がありません。

「で、それってすぐに儲かるの?」

というセリフが出る経営者のもとで育つカルチャーが、その本質です。

いくら社員が多く、こぎれいな会社であっても、「すぐにリターンを求める姿勢」が顕著だと、必然的にこういう会社からは、「小さくまとまって停滞している雰囲気」が醸し出されます。

特に、上でいうところの「中小企業っぽい会社」は、人への投資をほとんどしません。

直接のリターンが見えないですし、いつ将来に不安を抱いた社員が辞めるかわからないからです。

IT企業だとSESで人材の手配師に安住しちゃう会社だとか、「今いる人員でできる仕事」に全振りしちゃう会社だろうか。

まぁ、「儲かってればいいんだよ」という理屈は分からないでもないけど、10年後も会社が存在している保証のない時代で会社と運命共同体をやるのは中々難しい。

「良い会社」を見つければ将来安泰という時代でもないので、エンジニアは常に転職できるよう準備しておく・定期的に転職することでスキルが停滞しないようにするなどした方が結局は無難だろう。

CTO から見た,なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか

スタートアップは金が無いので(エンジニアとしてはレベルの低い)創業者がコードを書いたり、知り合いのフリーランスに頼んだりするので、保守性の観点が抜け落ちた設計になりがち。

そりゃまぁ、そうなんだが。

ロシアのGoogleこと「Yandex」の40GB超のGitリポジトリが漏えい

大規模データベースのリーク情報やハッキングツールなどを提供する場として人気のサイバー犯罪フォーラムBreachForums上で、borderline2023というユーザーがYandexの40GB超のGitリポジトリをリークしたと主張しています。

YandexのGitリポジトリをリークしたのはborderline2023というユーザーで、「リポジトリのみ、データなし、44.71GB。スパム対策ルールを除いてほぼ完全にコピーしました。2022年7月に私がダウンロードしたものです」と投稿しています。この投稿に対して、BreachForumsユーザーからは「かなり素敵に見える」「多くの興味深いツールがある」などのコメントが寄せられています。

根こそぎやられてて草

キレイなコードが会社を潰す

キレイなコードが会社を潰す

壊滅状態なプロジェクトをチェックさせていただく機会があるのですが・・・

そこにあるのは○○○なテクニックを思う存分にふるった俺が考えたキレイなコードの残骸です。簡単なことを面倒くさく難しく書いた、ちょっと弄るとバグがでるコードです

@MotoyasuYamada

保守性の低いコードはキレイなコードとは言わないんだよなぁ

人間と同レベルでプログラミングができるAI「AlphaCode」、DeepMindが開発

DeepMind Technologiesは、コード生成人工知能(AI)の「AlphaCode」を開発。 AlphaCodeはプログラミングコンテストでほぼ中央値となる成績を収め、人間と同レベルのコーディングスキルを持つことを示した。2022年2月2日の公式ブログで発表されていたが、このたび12月8日に、AlphaCodeについての論文が『Science』に掲載され、表紙を飾った。

AlphaCodeは競技プログラミング向けに作られたシステムだ。競技プログラミングでは、批判的思考、論理、アルゴリズム、コーディング、自然言語理解を組み合わせて、予期せぬ問題に対する解決策を創出することが必要となる。予期せぬ問題に解決策を見出すのは、従来の機械学習コミュニティにおいては難しい課題だった。

おっ

とりあえずは競技プログラミング領域か。

早く職業プログラマの仕事を奪って欲しい。

本来システム開発は分かってる人間が一人でやる方が効率がいい。

しかし、一人ではこなせる作業量に限界があるので「仕方なく」チームで開発している。

将来的に人間の代わりにプログラミングできるAIが登場するなら、一人のエンジニアの能力をいくらでもスケールアップさせる事ができるようになるので、開発効率は途轍もなく向上することになるだろう。

社内システムを外注する際のポイント

■ 私分かりませんから全てお願いしますは止めろ

コンサルも込なら良いが大体は要件定義からだ。つまりお前らは要求定義は出来ている前提だ。なんも分からないから経営層や現場との橋渡しのみなら邪魔だから今すぐSE名乗るの止めて仕事辞めて田舎で畑耕せ。

■ 自社の業務は理解しておけ

AccessやFilemakerで弄れる程度でSE名乗るならせめて自社業務の流れや種類は把握しておけ。何聞いても現場に確認しますじゃ時間かかるんだよ。なんなら分かるんだ?別に業務フロー寄越せとか言ってないぞ。

■ 要求を理解しておけ

割とマジで自分が経営層から何をシステム化してほしいのか分かってない奴が多い。体感5割以上。最近じゃインボイス対応。インボイス対応してください言われて現状や影響箇所は何をしたいか聞いたら「さぁ?」って言う。じゃ、何しにきた。挙句に「そのやり方も提案するのがシステム会社でしょ!」とキレる役職者まで。コンサルは契約に入ってないんだけどな。ちなみに別の会社でシステムのお偉いさんしてたとか言ってたがExcel方眼紙使ってたので速攻無能確定。おまけに技術も知識もアップデート出来てないし平気で偽装派遣みたいなこと言ってくる。前の職場どんなとこだよ

■ マウント取るな

クラウドとか言語とかアーキテクチャとかフロントエンドもバックエンドも何も知らないなら勉強しろとも言わないが分かった風の口聞いてググった程度の知識でマウント取るな。むしろ都度説明求めろ。

■ 悪魔の証明させるな

ランニングやイニシャルコストの話で妥当かどうかをこっちに証明させるな。お前らで判断しろ。少なくともボッタクっては居ない。あと逆に原価厨みたいに人件費等々無視した計算もすんな。人はタダじゃない。

■ 業務時間外に連絡すんな

小売りとかだと土日もやってたりするけど対応ほしけりゃ契約時に言え。割り増すから。電話やメールでなくて後日文句言うな。あと平日業務時間外にZoomとかやるな。金寄越せ。

■ 感情論とか止めろ

要件漏れとかあってこっちがリスケ等を要求しても承知しないでキレたり三顧の礼したりするの止めろ。そのバカみたいな時間を社内調整に回せ。夜の22時とかに泣きながらZoomでお願いしに来るな。不動産営業にでも転職しろ。

■ ちゃんと確認しろ

要件定義書、設計書、テスト仕様書、その他いろいろ作って会社で確認してもらってるよね。読め。だいたい書いてある。仕様漏れとかでこっちが記載してる言って読んでないってキレるな。あとどこの企業も読んでないとか言うな。ちゃんとしてるとこは読んでる。

■ アジャイル開発を何だと思ってる

大体馬鹿なユーザー企業はアジャイル開発何も知らないくせに「要件定義要らない、数週間で出来る、ドキュメントも要らない、仕様変更簡単」と思ってる節がある。なぜか最初にアジャイル開発で~とか言ってくることも。何もできないならウォーターフォールの方が数倍マシだぞ。アジャイル開発だとお前の役割重要になるんだぞ。ちゃんと管理出来るんか?だいたい動き出してからウォーターフォールの動き求めてきたりするw

ちゃんと要求まとめて要件定義から参加して受入まで出来たり、アジャイル開発ができるユーザー企業の社内SEなんて日本の中小企業の1割にしかいないと思っているので、自信ない人は是非パッケージに頼るかもっとたくさんお金払って全部お任せにしてください。

どっちも無理なら退職して熊本に出来る半導体工場で地道に半導体製造の職員として働けば?

ニトリの社内SEニュース見て思ったので書いてみた。自分は取り組みとしては良いと思う。

【考察】テストコードのきれいな書き方

Skeb、12月の大規模障害は「Heroku障害ではない」「完全に解決」 詳細は触れず

クリエイターに有償でイラストなどを発注できるサービス「Skeb」を提供するスケブ(東京都千代田区)は1月23日、2022年12月に発生した障害について「セールスフォース・ジャパン担当者との協議を経て、完全に解決した」と発表した。原因がクラウドサービス「Heroku」の障害でないことを確認したという。

Skebでは12月23日から24日にかけて障害が発生。当時の発表では、原因はHerokuのアカウントにあったとしていた。ただし詳細に不明点があり、解決後も問題の経緯を探っていたという。

スケブによれば、セールスフォース・ジャパンは障害の解決後、12月28日にスケブを訪問。原因がHerokuの障害ではないことを確認した他、セールスフォース・ジャパンが当時把握していた状況について説明を受けたという。その後協議を経て、1月23日に問題の解決に至ったとしている。ただし障害が起きた実際の原因については説明していない。

障害ではないが、納得できる(あるいは一定の合意に達する)理由で、それ自体は非公開ってどういう話なんだろうか。

ストライキでも起きてたのか?

ストレージ周りの制約をぜんぶリポジトリ層に閉じ込められる、モデルのレイヤーはそういうのとは無縁...

ストレージ周りの制約をぜんぶリポジトリ層に閉じ込められる、モデルのレイヤーはそういうのとは無縁でいられるというナイーブなオブジェクト指向感覚。データ量がすごい少ない規模のコーディングしかしたことない、とかでなければそういう考えのままでいられることはない気がするのよな。

@shibu_jp

大規模になればなるほどデータの移動とかフィルタリングとかがボトルネックになるので、データ中心の設計になっていくよね。あとはクラウドネイティブ。うまくスケールするための設計とかも、データ中心設計が必要。RDBを活かすのもNoSQLを活かすのもデータ中心設計が必要。

@shibu_jp

僕は国内で完結するサービスしかやったことないけど、プラネットスケールになると結果整合性をいかに担保するか、みたいな勝負になってやはりデータ中心になるはず。

@shibu_jp

「パフォーマンスのためにシャーディングとか考え出すと、ソフトウェアに対する変更要求はどでかくて大変ですよねーーー」みたいな話を今日ちょうどお客さんと雑談してきたところである。

@shibu_jp

例えば、AWSのAuroraを使ったシステム。今からやろうとしている操作が全部読み込み操作なのか、そうじゃないかで、リードレプリカ側につなぐかプライマリに繋ぐべきかが決まる。リポジトリ層1つで全部隠蔽して解決するには、これから起こる未来のコードを知らないといけないわけだ。

@shibu_jp

少なくとも、リポジトリ層に全部隠蔽できる設計手法は、どう背伸びしても、シャーディングが必要な規模には不可能というわけだ。NoSQL使う場合も、検索条件が増えたりするのに弱いのでそれを踏まえた事前設計が必要でそうでないなら、主キーでデータ取ってくる程度のクエリーしか無理なんじゃないかな

@shibu_jp

MEMO:

実践イミュータブルデータモデル — NEWTポイント機能の設計

世の中は〇と△と□でできている~テクニカルライターのためのイラストテクニック~

テクニカルライターよ概念図を描くのです 〜テクニカルライターのためのイラストテクニック2〜

図解系の本を何冊か読んでみたけど、結局ピンと来なかったんだよな。

詳細にこだわり過ぎていたのかもしれん。

画像生成AIを実際に触ってみた結果、結構大きい副作用があり『手にした魔剣に自由意志をすべて奪われる...

完全フルハンドメイドを目指していたはずが、なんか鋳造とかで同じ品質のものが大量生産できてしまう事に気付いてしまった時のやるせなさみたいなのは分かる。

まぁ、それはもう仕方無いので受け入れていくしかない。

システム開発もいずれはそうなるだろうが、それならそれで別にいい。

エヴァのMAGIシステムをGPT3で作ってみた

MAGIシステムは草

米中貿易戦争の余波。グーグル、Androidを「RISC-V」に対応させる方針

Googleは、Androidがオープンソースライセンスで提供・開発が進められているアーキテクチャのRISC-Vをサポートすることを宣言しました。Ars-Technicaが伝えました。

AndroidのエンジニアリングディレクターであるLars Bergstrom氏は、RISC-Vのサミットにて、AndroidがRISC-Vに対応するためのロードマップを公開。正式なサポートは今後数年かかるとしていますが、同氏はRISC-VがArmと同等のプラットフォームになることを望んでいるとしました。

また、同サイトは「Armは不安定なビジネスパートナーである」としています。スマートフォンのCPUのアーキテクチャはArmが掌握していますが、Armを所有するSoftBankが、非常に大きな影響力を持つNVIDIAにArmを売却しようとし、最終的に競争阻害などの理由により断念しています。その後も、自らの大口顧客であるQualcommとその子会社のNuviaに対し訴訟を起こすなど、かなり後ろ暗いニュースが続いています。

くわえて、Armそのものは英国企業、そして親企業のSoftBankはもちろん日本企業なのですが、米国の輸出法が適用され、Huaweiに対する輸出制裁に巻き込まれたことも。反面、RISC-Vはカリフォルニア大学から始まったオープンソースプロジェクトで、米国の輸出法の対象にはなりません。

RISC-VのメンバーにはIntelやGoogle、Qualcommなどが名を連ね、同時にアリババやテンセント、ZTEなど中国企業も参加しており、この状態で米中貿易戦争において、RISC-Vの存在がどちらか一方に有利に働くことがないことを主張しています。

ふむ。

いずれにしてもソフトバンクはろくでもない。

『ドメイン駆動設計』の解説記事を書きました

重視したこと

  • 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える
  • 全体像を伝えるための図や表を多めにした(ソースコードの例は少ない)
  • 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』(以下『ドメイン駆動設計』)の説明を中心にした
  • ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務知識の解説を多めにした
  • マイクロサービスなど分散アーキテクチャとドメイン駆動設計の関係など、新しめの内容を盛り込んだ

GYAO! サービス終了のお知らせ

いつもご利用いただき、ありがとうございます。

誠に勝手ながら、「GYAO!」「GYAO!ストア」「トレンドニュース」は、2023年3月31日(金)午後5時をもちまして、すべてのサービスを終了いたします。

(終了時刻は、状況により前後する場合がありますので予めご了承ください。)

各サービスをお楽しみいただいているお客様には、多大なご迷惑とご不便をおかけすることとなり、誠に申し訳ございません。何とぞご理解くださいますようお願いいたします。

また、サービス開始より多くのお客様にご支持いただきましたことに、運営チーム一同、深く御礼申し上げます。

サービス終了まで短い期間ではございますが、「GYAO!」「GYAO!ストア」「トレンドニュース」を引き続きお楽しみいただけますと幸いです。

Gyaoサービス終了か

スターリンク、もはや光回線と変わらない価格まで値下げされる

SpaceX社が提供している衛星通信ネットワークサービス「Starlink(スターリンク)」が、2023年1月13日に突然の大幅値下げを実施しました。

その価格は、なななんと月額6,600円。もう一般的なプロバイダーと大差なくない!?

ある程度ユーザー数を獲得したら一気に値上げするのが目に見えてるのがなぁ

DDDの集約の決め方サンプル例を使って0から考える

ドメインモデリング、未だに思考の流れがよくわからないんだよな。

インプットとなるユースケース図から最終成果物のクラス図に至る流れが全然分からず困惑してしまう。

個人的にはユースケースからエンティティを検討→ER図に落とし込み→データ構造(DB)を確定→DBを元に集約やバリューオブジェクトを作成...の方がしっくりくる。

結局のところアプリケーションはデータの永続化が一番大きな関心ごとになるので。

途中形態のクラス図を見せられてもなぁ...感は否めない。

Mozcdic-UT関連の話

クロージャデザインパターンのメモ

Execute Around Method

Pluggable Behavior

Iterator Pattern

Dynamical Conditional Execution

Template Method Pattern

Loan Pattern

Command Design Pattern

Strategy Pattern

Factory Pattern

Method Combination

参考URL:

優秀な人だけどコミュニケーションスキルがイマイチというか口調が無意識に攻撃的な人の改善要望は辛すぎる

優秀な人だけどコミュニケーションスキルがイマイチというか口調が無意識に攻撃的な人の改善要望は辛すぎる。技術とか内容ではなくて人間の好き嫌いになってしまうし、お互いがお互いの言い分があるのだけどこういうパーソナリティの指摘はモチベに直結するので切り出し方も伝え方もホントしんどい。

@komitsubo

1分間マネージャーにあるような褒めてその後叱責、そしてフォローというセオリーな流れで行きたいけど、対象がキーメンバーだとフォローに失敗した時のリスクは組織の生産性に直結する。そしてそれが組織のキーメンバー同士の問題だと対処処理の失敗は許されない。カイジの鉄骨渡りくらいシンドイ。

@komitsubo

しかしどうして組織のキーメンバーはすぐに対立関係になってぶつかるのか。頂点には1人しか立てない訳でもないと思うのに。世界はやはり両雄並び立たずなのか。戦わないと生き残れないとか訳でも無かろうに。漫画的な展開はいらないので仲良くして欲しいですけど。無理なお願いしてないよね。トホホ。

@komitsubo

自分の縄張りをちゃんと確保できないと人は争うものなので、キーパーソンにはそいつをさっさと管理職にしてしまうのがよい。

医師とデザイン。なぜ医療現場は複雑なUIが好まれるのか?

医療関係に限らず、業務用アプリケーションというものは見栄えのいいUIより、情報を詰め込んだ実用一点張りのUIの方が好まれるものである。

空白を贅沢に使う「見せるデザイン」よりは情報をギチギチに配置したダッシュボードのようなUIの方が結局は選ばれる。

何故なら、一日の大半そのアプリケーションを使っているので嫌でも操作に習熟するし、日常的な作業で画面遷移やフォーカス移動を繰り返すのは地味に面倒なので、最初から全ての情報が露出している方が操作の手数が少なくて済む為、楽なのだ。

アジャイルとかいうクソみたいな開発

結論から言うと受発注の関係性でアジャイル開発やるのは完全に間違えてる

受注側が優秀だと発注側の意思決定の遅さにイライラするし

受注側が未熟だと発注側のイメージが具現化されない

第三者的に両方の場合に遭遇したんだが記録しておきたい

■ 受注側が優秀な場合

スプリントのスピードが速すぎて発注側の意思決定が間に合わない

評価用のボタンを作成するときにGood/BadにするかGood/Normal/Badにするかを決めるだけで2週間かかる

本来なら意思決定者がミーティングに出て欲しいが日本企業は権限委譲しない会社ばかりなので

最終決定は上役の偉い人になるが、そういう人はなかなか捕まらないので意思決定が遅くなる

「意思決定を早くしよう」ということでミーティング時間を10分に制限するとか意味不明なことをしてる

責任を下位の役職まで委譲しないとアジャイルは成り立たない

まぁなのでこういう組織にはアジャイルは向いていない

■ 受注側が未熟な場合

スプリントレビューを行うときに発注側が「こういう機能が欲しい」と言っても

受注側がそれを実現できる自信が無いとYesと言わない

もちろんその場ではTaskとして上げておいて「実際には出来ませんでした」っていうのを許容するのがアジャイルだと思うが

受発注の関係性があるとどうしてもネガティブなことはやりたがらない

はっきりとNoとは言わないが「ここのDBが」とか「このAPIが」とか予防線を張りまくる

結果としては制約が多すぎて

「これじゃぁExcelで良かったな」

っていうことになりがち

■ じゃぁウォーターフォールが良かったのか

当たり前だがウォーターフォールでの開発はとっくに時代遅れだし競争のスタートラインに立てない

逆に言うと競争が無い世界での開発ならウォーターフォールでいいだろう

そして日本企業はこれまで競争が無い分野でのソフトウェア開発ばかりに従事してた

護送船団方式で競争しないしそもそも内需で独占市場だったり

プラットフォーマーが競争しないように規制してたりして開発してきた

そんな企業がいきなりソフトウェアで競争をさせられて付け焼き刃のアジャイル開発をすることになるからおかしなことになる

日本企業はおとなしく機械だけ作って、だんだんと小さくなっていくしかないと思う

それは発注者・受注者共にレベルが低いのが問題であって、勝手に日本が〜とか主語を大きくしないでほしさがある。

あなたの遅延はどこから? SQLから! 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜

マルウェアが最初からインストールされているとんでもないAndroid TVデバイス「T95」がAmazonとAliExpressで販売中

AmazonやAliExpressでも販売されているAndroid TV搭載のセットトップボックス「T95」にマルウェアがプリインストールされていたという報告がGitHubに上げられています。マルウェアの正体は、Android端末を対象に感染を広げた「CopyCat」に似ているとのことです。

報告ページを作成したDesktopECHO氏は自身で開発したAndroid向けツールのPi-holeをテストするためにT95を購入したとのこと。しかし、このT95の中身が非常に大雑把なものであることがわかったそうです。Android 10はテストキーで署名されており、Google Pixel 2にちなんで「Wallye」と名付けられていたとのこと。さらにデバイスと通信するための多用途コマンドラインツールであるAndroid Debug BridgeがイーサネットとWi-Fi経由で広く開かれていることが判明。

そこで、実際にT95にPi-holeをインストールし、DNSを127.0.0.1に設定したところ、T95がアクティブなマルウェア用アドレスにアクセスしていたことが判明したそうです。

結果としてDesktopECHO氏は、T95内のマルウェアがやり取りしているC2サーバーのDNSを127.0.0.2に変更することで、マルウェアのアクティビティを監視しながらほぼ無力化することができたそうです。

中国製のAndroidタブレットやスマホを買いたくないのはこういうところなんだよな。

ファームウェアの時点でマルウェア仕込まれてたら一般ユーザーにはどうしようもできないし、工場出荷状態では問題なくてもファームウェアアップデートでマルウェア仕込まれる可能性もあるという。

スマホやタブレットは決済手段や個人情報と強く関連付けられるデバイスなので、少しでも不安のあるものは避けた方が無難である。

ポリモーフィック関連の解消 - 直和による表現

Webサーバー「Apache」にアメリカ先住民から名称変更の要請

オープンソースのWebサーバーソフトウェアとして知られる「Apache」を運営するApache Software Foundation(ASF)に、北アメリカ先住6部族の1つであるアパッチ族を念頭に「アメリカ先住民への敬意と独自の行動規範を守るため」として名称変更の要請が出されていることがわかりました。

この「Apache」という名称について、ASF設立メンバーのブライアン・ベーレンドルフ氏は「Apacheという名前にしたのは文化的流用などではなく、当時ローンチされたWebテクノロジーは『サイバー○○』や『スパイダー○○』といった名称ばかりで、もう少し興味深くてロマンティックな名称が欲しかったからです。ちょうどジェロニモとアパッチという部族の最期についてのドキュメンタリーを見たところで、彼らが西部、つまりアメリカ合衆国による侵略を受けて領土を手放した最後の部族だったという話で、私にとっては、我々がWebサーバープロジェクトで行っていることをロマンティックに表現しているように思えたのです」と語っています。

Natives in Techは、この「ロマンティックな表現」が「無知であると同時に不快なもの」と指摘し、ASFに対して「選んだ言葉に深く注意」し、名称を変更するように求めています。

Goモジュールのキャッシュプロキシ「Go module mirror」をSourceHutがブロックへ

コードホスティングサービスであるSourceHutが、Gitサーバーからコードを取得しキャッシュするプロキシの「Go Module Mirror」がネットワーク帯域を使いすぎているという理由で2023年2月24日からブロックする予定であることを発表しました。

Googleが開発したプログラミング言語のGoはGitリポジトリからモジュールを取得しますが、これらのリクエストはそれぞれ「proxy.golang.org」にあるキャッシュプロキシ「Go Module Mirror」を通してルーティングされます。Go module mirrorがキャッシュを取得することでGoモジュールのダウンロードは高速化しますが、このGo Module Mirrorが定期的にオリジンのソースリポジトリからGoパッケージを取得してアップデートをチェックすることで、膨大なトラフィックが発生してしまう問題が報告されています。

Go Module Mirrorによるトラフィックは、SourceHutのホスティングサーバーであるgit.sr.htからの送信ネットワークトラフィックの約70%を占めており、1つのモジュールでGoogleから1日に4GiBものトラフィックが発生することもあるそうです。

GoのimportでリポジトリのURLを指定すれば自動的にライブラリを取得してくる仕様、こういう事態が起きないか不安だったけど、ついに現実化したか。

PyPIやnpmみたいに中央集権的なパッケージリポジトリであれば、基本的にはその言語のユーザーだけの問題であり、その運用やリソースにコストを集中すれば済む。

一方、GoのようにリポジトリのURLを直接指定できてしまうと、リポジトリをホスティングしているサイト側にコストを押し付ける形になってしまう。

特に昨今は当たり前のようにCI/CDを行う関係上、開発時はpushの度にライブラリのダウンロードが行われるので、以前と比較にならないほど大量のリクエストが発生する。

GitHubのように巨大資本がバックについているサービスならともかく、そこまで規模の大きくないホスティングサービスでは負担が大きいだろう。

Goのimportの仕様はGo言語ユーザーやコミュニティ以外のリソースにフリーライドする傲慢で邪悪な仕組みだと思う。

最近のウォーターフォール開発がうまくいってないと言っている人達は、実は大抵ちゃんとウォーターフォール...

最近のウォーターフォール開発がうまくいってないと言っている人達は、実は大抵ちゃんとウォーターフォール開発を学んでないし、そもそもウォーターフォール開発自体をやった事がない可能性あるな。とちょっと聞いてて思った。

@komitsubo

当人達は実体験はしてないけど、本やネットに書いてあるからとか、自分達がリスペクトしている人がそう言ってるとか、そういう伝聞で鵜呑みにしているのかもなぁとちょっと聞いてると思う。

@komitsubo

ここでいう”ちゃんと”というのは、V字プロセスをPMBOKやCMMIやISO規格などを読んで各フェーズでやる事や入出力を理解し、今回上手くいっていなかったフェーズを洗い出し、要求漏れが多かった変更改善プロセスを改善する、日程にCCPMを適用するなど環境に合わせてテーラリングしていくとかって話です。

@komitsubo

成功を定義しそれで結果を比較して成功の定義にならなかったものを対して、定義の問題か、実施プロセスの問題か、ヒトの問題か、環境の問題かなどを整理してそれぞれに対して改善期待値を決めて対応施策を考えて実施していく。このサイクルが回る事が大事であって開発手法の差異は付属でしかない。

@komitsubo

開発を進めるにおいて何かの手法がダメ、この手法は正解みたいな些末な二値的な話にならないようにするのが大切な事で、常にその状況に適合できるように”ちゃんと”とか抽象的な思考停止を避け具体的な地に足が付いた最適改善方法を見つけて進めていく事が大事。こういう人が増えるといいよね。ホント。

@komitsubo

NOTE:

システムの負荷の原因を切り分ける方法

  • ロードアベレージが高い
    • CPU使用率がほぼ100%
      • 「1. CPU使用率」
    • スワップが発生している
      • 「2. メモリ使用量」
    • スワップが発生していない
      • 「3. ディスクI/O」
  • ロードアベレージが低い
    • TCPコネクション数が多い
      • 「4. TCPコネクション」
    • TCPコネクション数が少ない
      • 他のホストを疑う

バンダイナムコグループのデータ戦略実現を支えるデータマネジメント

企画、要件定義、設計、実装を一気通貫でつなげて考えるシステム開発

tag:

プログラミングの方法論から考えるユニットテスト

昨今、テストピラミッドなどの側面からユニットテストの重要性が説かれていますが、クラス間が密に結合している等で適切なユニットテストを書くのが難しいという状況に陥ることは多いのではないでしょうか。そのような状況は、ユニットテストの解像度が低いために生まれると自分は考えます。

本記事では、防御的プログラミングと契約プログラミングという二種類のプログラミングの方法論を元にユニットテストを再考し、ユニットテストの解像度を高めることを目標とします。また、ユニットテストのより良い書き方を模索している人に本記事を読んでいただきたいです。

ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall

なんか最近は自分達の能力や実績を立証できていないのに自分達が開発において一番価値を持つものを...

なんか最近は自分達の能力や実績を立証できていないのに自分達が開発において一番価値を持つものを作ると思っていて、自分達がやりたくない事は周りがやるべき、自分達の価値創造の為に周りは頑張る、または奉仕をするのが当然みたいな論調のソフトウェアエンジニアが増えた気がする。

@komitsubo

周りが自分達にとっての快適な開発環境を用意するのは当然だし、進捗は周りが自分達がやってる内容から負担をかけずに知るべきだし、進捗等聞いて圧をかけるべきではないし、能力が足りない場合はそれを学ぶ時間を調整して確保すべきだし、文書等作りたくないものはやりたくないので我慢すべきだし。

@komitsubo

ビジネスのゴールや顧客への仕様は周りが用意すべきだし、ステークホルダーとの交渉は当然リーダーやマネジメントの仕事だし、コミットが未達でも自分達は頑張ったのだからその中でどうにか顧客を納得させるのは周りのやるべき事だし、コードをリファクタリングする時間も当然周りが確保すべきだし。

@komitsubo

規律等は創造性を狭めるから敢えて定義をしないと言って自分達を律するコミットはしないし、それで理解が足りない場合は説明責任ではく周りの知識不足が原因だし、成果の質で悪い場合の責任を取るのは周り、よい成果を受領は自分達の当然の権利。なんか書いててあれだけどホントよく見かける。

@komitsubo

GAFAなどがやっているから、成功している事例を聞いたなど自分達ではなく周りの成果は自分達の成果と同義的なアピールをしてたりする。客観的に見てみると正直昔も今もソフトウェアエンジニアが出している成果に劇的な大差はないのに、自分達を金の卵を生み出す鶏のように大事にせよと言う。

@komitsubo

自分達が価値を作るんだという心意気は全然いいし、そうあって欲しいけど劇的な成果を出した訳でもないのに待遇は1流にしてくれというのはおかしいと思ってる。だって変でしょ?売れてもないデビューすら怪しい漫画家が周りに人気漫画家みたいな要求するのは。そりゃ売れて貢献してから言えとなる。

@komitsubo

昔は社内など閉じたコミュニティで歪んだ自己評価が問題になって世間を見ろという話が多かったけど、今のソフトウェアエンジニアは社外だけど閉じたコミュニティで歪んだ自己評価が増えている気がする。ネットには自分の意見を肯定する都合の良い意見が溢れてるので自己評価が正しいのか判断が難しい。

@komitsubo

こういう極端なソフトウェアエンジニアカースト的な我儘を推奨するような現在の状況は正直どうなのかなと思ってる。自分もソフトウェアエンジニアだけどそんなにカースト作るほど価値作ってないよ。ホント。素晴らしいプロダクトができたってニュースがあったからってそれは自分達の成果じゃないよ。

@komitsubo

君ら本当に自分達の現在の立ち位置を見てる?と。自分達が大きい存在だと思っているかもしれないけど、それは本当に成果を出している人達の光を背にしているからできている影で実体ではないよ。自分達で光ろうとするのはいいけど他人の光でできた影で自分を大きく見せるのは悲しい話だよと思う訳です。

@komitsubo

ソフトウェアはハードウェアの上で動く付属品扱いされていた時代の人からすると今のソフトウェアエンジニアの立場の向上は嬉しいけど、実体の伴わない我儘や傲慢な態度の人が増えてくるのはホント周りの真面目なソフトウェアエンジニアの価値毀損にもなるので勘弁して欲しいと思う今日この頃です。

@komitsubo

SlackのGitHubアカウントからプライベートコードリポジトリが盗み出されていたことが判明

うーむ

事例から学ぶ実例マッピングのやり方 / Example Mapping

Google、RISC-Vを最上位Androidアーキテクチャにすることを望む

インターネットは断片化されることを望んでいる

まじで今更感しかない

ウェブフロントに見る clean architecture の一例

さて、ここでクイズです。「Clean architecture とは、 controllers や use cases、entities というクラスを作って繋げるアーキテクチャのことだ、○か×か」。どっちでしょうか?

→ → → 正解は×です。 あの同心円は、あくまで clean architecture の一例として『Clean Acrhitecture』で紹介されたものです。

ストア層とコンポーネント層をわけるアーキテクチャには以下のメリットがあります。

  • ストア層の改修がコンポーネント層に影響しなくなる
  • コンポーネント側の変更もストア層に影響しない

あくまでレイヤー毎に独立していること、レイヤー間はインターフェイスやポート&アダプタで接続されること、フレームワークやミドルウェアに依存しない、みたいな観点もあってもよさそうだが。

最近はClean Architectureを採用することはデメリットの方が多い気がしていて、これあかん奴なのでは感が強い。

Clean Architecture本の説明は「私(著者)が本気を出せばここまでやるぞ」という話であって、あれがスタンダードな実装モデルというわけでは無いのだが、どうしても参考書通りにやりたがる人が多いせいで不要な複雑さを抱え込む事例が多い。

業務アプリケーション開発にGoを採用する理由

それ、要はマイクロフレームワークのメリットでは? 感が強い。

人手を集めるのに流行ってる言語を選ぶのは正しいけど、言語とフレームワークの区別ができてないのは問題に正しくフォーカスできていない感じがする。

Ubie は Go と Node.js の会社になります

Ubie では、創業当初から Server-Side Kotlin を推進してきましたが、全社的な技術選定を再度行い、これからは Go と Node.js を中心とすることにしました。

これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。

先達が色々好き勝手にやっていたけど、採用とかすごく手間だし技術スタックを統一するよって話かしら。

フロントエンドアーキテクチャの話: Resource Setの紹介

APIといえばWeb APIになった現在、ローカルAPIは専らライブラリと呼ばれる説

例えばこのエントリのタイトルではローカルAPIという言葉を使ったけど、埋め込みAPI、組み込みAPIという言い方も可能な気はして、そしてどれもしっくり来ない。シェアドライブラリを考えると埋め込みAPI / 組み込みAPIというのは不適切でローカルAPIが適切な気がするけど、違和感が大きい。

元々でいうと、アプリケーションプログラマがなんらかミドルウェアなどを使うための入り口というのはAPIで、SQLもAPIのひとつだったりした。 C.J.DateとCodd博士の「The relational and network approaches: Comparison of the application programming interfaces」ではSQLの前身であるDSLとネットワークデータベースでのデータ操作をAPIとして比較している。

「WikipediaをWikiと略すな」問題と同じで「Web APIをAPIと略すな」みたいなものだろうか。

個人的には、APIとは「OSの機能へアクセスする為にOSが提供するインターフェイス」という感覚があって、それこそが字義的にも機能的にもApplication Programming Interfaceなのだが。

その概念がミドルウェアやネットワーク越しのRPCに拡張・適用されてきた結果、APIという単語自体がメタファに昇華してしまった感がある。

組織と技術の両輪で開発を加速させるkintoneチームの取り組み

モジュラモノリスに関する部分もう少し深く聞きたかった

エンジニアリングマニフェストを刷新しました: クックパッドの開発者文化をあらわす3つの言葉

クックパッドのエンジニアリングマニフェストは、次の3項目からなります。

  1. 境界を越える (Beyond boundaries): 私たちは一人ひとりが高いリーダーシップを持った個人になるために、自分の能力の限界や、責任範囲に対する思い込みを乗り越えて成長していくエンジニアを目指します。
  2. 技術を楽しむことに責任を持つ (Responsible for enjoying technology): 私たちは一人ひとりが技術を楽しむ集団であることを目指します。困難な状況であっても、常に技術的な挑戦の機会を諦めません。一人ひとりに技術を楽しんでいる自分を目指す責任があります。
  3. 作ったもので語る (Speak with what you make): 私たちは動くものをすばやく生み出せる存在として価値を発揮します。また、作ったものを実際に触れることで得られる気づきを尊重します。

MMDは日本の3DCGを破壊してしまった (2022年度版)2022/08/16加筆

ふむふむ

規模感の違う脱レガシーで必要なこと

小さく進める(=ビッグバンリリースを避ける)は本当に大事

個人的docker composeおすすめtips6選

  • Docker image名やコンテナ名のプレフィックスをディレクトリ名から変更する
  • ヘルスチェックの設定
  • 依存関係の設定
  • サービス完了まで待機
  • サービスをグループ化

「Gitea」の開発者が離反、代替プロジェクト「Forgejo」を立ち上げ

Gitリポジトリマネージャ「Gitea」の開発チームを離れた一部のメンバーは、Giteaと代替可能なソフトウェア「Forgejo」を開発するプロジェクトを立ち上げたと12月15日(現地時間)に発表した。ForgejoはMITライセンスで公開しているオープンソース・ソフトウェアであり、現在「バージョン1.18.0-rc1-1」を公開している。

Forgejoの開発メンバーは新しいプロジェクトを立ち上げた理由として、Gitea側が利潤追求を目的に「Gitea Limited」という企業を発足させ、Giteaの管理権限をコミュニティに開発者から新しく発足させた企業に移したことを挙げている。開発者に対して事前の相談もなく企業を立ち上げ、疑問に思った開発者たちがまとめて公表した公開書簡に対しても返答がなかったという。公開書簡では、Giteaのドメイン名と商標類の帰属について尋ねている。

Gitea側は2022年10月25日に、Gitea Limitedを発足させることを発表している。Giteaを利用する企業の中でも、社内の規則などが邪魔をして、ソースコードで貢献することや、スポンサーになって貢献することができない企業があることを指摘し、このような企業が何らかの形でGiteaプロジェクトに貢献することを支援するためにGitea Limitedを発足させたと説明している。

GiteaはGitHub的なリポジトリ管理システム。

中国からGitHubへのアクセスが禁止された(いた?)事から中国国内でのGitHub代替サービスの基盤として資本が投下されたように記憶している。

その辺りでゴチャゴチャした話があったという事なのだろう。

Web APIを手作りする時代は終わった

これが適用できる状況が狭すぎるので流行らないだろうし、流行るべきではない技術だ。

これで手抜きできる作業量より、これの挙動を理解してメンテし続ける作業量とプロダクトへのロックインリスクを考えると、手を出すのは止めておくべきだろう。

簡単よりシンプルを選ぶという奴であるな。

もし「リーダブルコード」を弁護士が読んだら?

こうして見ていくだけでも、契約言語はプログラミングの歴史から大いに学ぶべきであると痛感します。 さらに悪いことに、高級言語と契約言語との大きな違いがあります。それは「契約言語は、全国民が完全理解できることがなぜか前提になっている」ことです。ビジネスの世界では、契約言語を通じてしか、他者と関わることができません。

例えば、外部サービスを利用するときには、利用規約に同意する必要があります。あれって、皆さんは本当に読めていますでしょうか? ぶっちゃけ、現状のものは弁護士である私ですら読む気にならないです。そのくせ「私たちは一切の損害賠償責任を負いません」だとか、明らかにアンフェアな条項がこっそり含まれていたりします。

ITエンジニア特化型Q&Aサイトteratailを 言語、DB、クラウドなど フルリプレイスした話

teratail、一時期リニューアルに失敗してボロカスだったけど最終的にリニューアル成功したという事なんだろうか。

ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0...

Dockerコンテナの技術を用いることで、プログラミング言語のランタイムやライブラリ、ミドルウェアなどの開発環境一式を比較的容易に導入することが可能になりました。

ただしDockerコンテナにもファイルシステムのオーバーヘッドなどがあり、Dockerコンテナ内の開発環境ではコンパイルなどに時間がかかってしまう場合があったと開発ツールベンダのJetpack Technologiesは自社の経験から指摘します。

そこで同社がオープンソースで開発しているのが「Devbox」です(ちなみにマイクロソフトによる仮想化された開発環境の「Dev box」とは名前は似ていますが別のものです)。

Devboxは、ローカル環境上に分離した環境を用意しそこで開発環境を構築可能にしつつ、Dockerコンテナのような仮想化技術を用いていないことが最大の特徴です。

このDevboxの基盤となっているのが、Linuxディストリビューション「NixOS」のパッケージマネジメントツール「Nix」です。

仮想環境やコンテナではなく、Pythonのvenvみたいなイメージなんだろうか?

【復旧】12月23日、24日に発生しました障害に関するご報告

  • Herokuの制限によって海外に設置されていたSkebのサーバが、移管によって日本国内に設置されることになりました。日本国内からのアクセスが大幅に高速化されます。
  • スケブ社ではエンジニアに対して開発環境の指定を行わず、各々がWindows、Mac、Ubuntuといった好みのOSを用いて開発しています。
  • どのような環境でも開発ができるように、Skebのすべてのシステムはオフラインの仮想環境で動作するコンテナイメージを作成しています。
  • 今回このコンテナイメージがあったことで、事前準備なく1日未満でHerokuから新しいクラウドサービスに問題なく移管することができました。
  • 今回の障害を受けて、深夜残業および休日出勤による法定割増賃金に加え「障害対応手当」という社内制度を新設しました。
  • 復旧に向けて夜間作業にあたっていたエンジニア4名に対し、1人あたり3万円のAmazonギフト券を夜間直ちに支給しました。
  • Skebでは月間約5億円の取引がございますが、今回の障害で1,500万円相当の取引の機会損失が発生しました。しかしながら、12月24日現在もHerokuから応答はなく、詳細な原因は判明しておりません。厚いサポートを謳うエンタープライズ契約を締結しているにも関わらず、このような対応は大変遺憾です。
  • Skebが利用不可能となる事例は、サービスリリース日である2018年11月30日に発生したアクセス過多による障害を除き、事実上今回が初めての大規模障害となりました。
  • クリスマスを目前に納品タイミングを調整されていたクリエイターの方々もいらっしゃいましたが、メールマガジンの配信システムも障害で停止していたことから、納品期限延長の告知がTwitterと記事のみとなってしまい、大きく混乱を招く事態となってしまいました。
  • 今後メールマガジンの配信は外部のサービスの利用も検討してまいります。

フラット、心理的安全性、失敗に寛容といった企業文化に対しての誤解

  1. 失敗には寛容だが、無能には寛容ではない

  2. 実験への意欲と高い規律性

  3. 心理的に安全だが、残酷なほど率直である

  4. コラボレーションと個人の意思決定、説明責任

  5. フラットで強いリーダーシップ、オーナーシップ

「失敗に寛容」、「実験の推奨」、「心理的安全性が高い」。「コラボレーションが活発」、「フラットな文化」といった革新的でイノベーティブな企業文化は自由で楽しいことばかりでなく、厳しい責任が伴うことも認識しなければならない。また、これらの文化は均衡を保つのが難しく、不安定である、といったものです。

「失敗に寛容」、「実験の推奨」、「心理的安全性が高い」。「コラボレーションが活発」、「フラットな文化」といった革新的でイノベーティブな企業文化は、えてして自由で、のびのびとした、キラキラした部分に目がいちがちです。しかし実際これらをやろうとすると、リーダーだけでなく、メンバーにも高いレベルが求められる、とても厳しくハードな規律と強さがセットとなる文化であることが分かります。

開発生産性について議論する前に知っておきたいこと

  • はじめに
  • 開発生産性の議論はアイデンティティに届く刃である
  • 「生産性」とはそもそもなにか
  • 「開発生産性の議論」における混乱
    • 開発生産性の3階層
      • レベル1:仕事量の生産性
      • レベル2:期待付加価値の生産性
      • レベル3:実現付加価値の生産性
    • 開発生産性の3階層とビジネスコミュニケーション
    • 開発生産性におけるインプットは何か
      • 労働人数
      • 労働時間
      • 開発人件費
      • 総事業コスト
    • どの部門までインプットを含めるべきか
    • 開発生産性における「アウトプット」とは何か
      • ソースコード量(SLoC:Source Lines of Code)
      • プルリクエスト量
      • デプロイ数とPR数
      • コード品質の評価と健全化指標
      • ファンクションポイント量
      • ストーリーポイント量(ベロシティ)
    • 期待付加価値のスコアリング
      • RICE スコア
      • 加重スコアリング
    • North Star Metrics
    • 売上(や粗利益額)
  • 開発生産性が高くても”開発が早い”訳ではない
  • リードタイムの種類 - デリバリのリードタイム - サイクルタイム - 開発のリードタイム - 意思決定からのリードタイム
  • 「頻度が質に転化される」という考え方
  • 開発生産性を超えて

力作だ

心理的安全性「ずいぶん中途半端ですね。こんな企画じゃターゲットの母数も狭いし、かといってニッチにも...

心理的安全性「ずいぶん中途半端ですね。こんな企画じゃターゲットの母数も狭いし、かといってニッチにも刺さらないし、開発してもあまり儲からないでしょうけど、僕の給料は成功した場合と同じだけ上がりますか? そうでないなら作りたくないですね」これが言えるか、言わずにコケて愚痴で済ませるか

@tanakahisateru

「さすが、開発者の自分にはない視点で考えてある。これには賭ける価値があるぞ。考えた人も開発チームを信じて任せてくれてる」っていう尊敬し合えてる組織を作るとなると、言わないで自分の身を守るタイプの人は排除なんだよなー

@tanakahisateru

健全な意味での殴り合い・マサカリの投げ合いができることが心理的安全性。

しかし、それは仕事にフルコミットする事を求められるわけで、全ての人がそうできるわけではない。

実際自分はソフトウェア開発は好きだけど、ベンチャースピリッツ的な「ビジョン!ミッション!バリュー!」みたいなノリは大嫌いだし、生活費が稼げれば十分なんで...のタイプで仕事にフルコミットするつもりはない。

それは別に悪いことだとは思っておらず、そういうのを求められる企業とはアンマッチというだけのことである。

他方、心理的安全性のことを「部下が上司に舐めた態度を取っても怒られないこと」や「他人が自分の機嫌を取ってくれること」みたいに考えてるパーソンもたまに観測するけど、それはまた別の意味で残念なのだわ。

変化に適応するソフトウェアアーキテクチャと組織構造への道程

Wardley Mapping

英国の研究者Simon Wardleyによって考案された戦略フレームワークで、状況認識と戦略サイクルに沿った動きに基づいてビジネス戦略を設計し、プロダクトを進化させるのに役立つもの。

バリューストリームを縦軸、製品開発のステージを横軸としたマップとなっていて、自分たちの製品のコンポーネントがどこに位置していて、市場環境から見てどうなっているかを俯瞰して見れるようになる。

Goのポインタ渡しは値渡しよりパフォーマンスが良いという誤解

ポインタが実は高価な理由

  • ポインタが指す値にアクセスする際にnilかどうかのチェックが必ず入る
    • ポインタがnilの場合、Goはpanic()をおこす必要があるため
  • ポインタは動的メモリアロケーションの原因になりがち
    • ポインタが指す値はヒープ領域に置かれがち(絶対ではないけど一般的に多い)
    • ヒープ領域は確保にまとまったメモリの検索、解放にGCが必要になるので負荷が高い
  • ポインタは参照の局所性が低くなりやすいため、CPUキャッシュが効きづらい
  • 多くの場合、値のコピーはポインタを使用するオーバーヘッドよりもはるかに安価
    • GoはDuff’s devicesという手法を用いてメモリコピーなどのよくある処理について非常に効率的なアセンブラコードを生成する
    • x86アーキテクチャだと64バイト以下のオブジェクトであれば値のコピーとポインタのコピーはほぼ同じ

小さいオブジェクトのポインタ渡し

[...]値渡しでもポインタ渡しでもパフォーマンスに大きな違いがないことが確認できました。

関数に副作用がないことを示すためにも、小さな構造体は値渡しで渡すのが無難かと思います。

ポインタを返す関数

関数内部で生成した構造体をポインタ渡しで関数外部に渡してしまうと、コンパイラが変数の寿命を判断できなくなり、動的メモリアロケーションが起きてしまいます。

いろいろ書きましたが、ホットパスな処理以外では値渡しでもポインタ渡しでも処理全体へのパフォーマンスにほぼ変化はありません。時期尚早な最適化は開発スピードを下げてしまいます。ベンチマークを取ってみてボトルネックになっている処理が見つかった場合に、不必要なポインタ渡しがないかを探すことをおすすめします。

人事はテックブログを監視すれば社員の転職活動を見抜けるので、対策を考える

見抜けたところで転職(退職)を引き留めることはどうせできないんだから別に構わないのでは? 感ある。

どうしても転職サイトからリファラを送りたくないというなら、GitHubに自分の書いた記事のまとめをアップしてそちら経由でアクセスさせる方が楽だと思う。

経営者の気分で考えて欲しいんだけど「サービスが社員をやっと養えるくらいに儲かっている」「競合他社とも...

経営者の気分で考えて欲しいんだけど「サービスが社員をやっと養えるくらいに儲かっている」「競合他社とも争いが激しい」といった状態で「ソースコードが汚いから1から書き直させてください。書き直しに1年かかります。機能は変わりません」なんて言うエンジニアなんて狂人として見られるだけだよ。

@igz0

まぁ、一理ある。

とはいえ、どこかで何とかしないと手に負えなくなるのがシステム開発なので、結局は式年遷宮が必要になる。

その決断は早ければ早い方が良い。

ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる...

サーバーもBFFもフロントもライブラリのプラグインすらもクリーンアーキテクチャで書かれてて...

サーバーもBFFもフロントもライブラリのプラグインすらもクリーンアーキテクチャで書かれてて、それはさすがに思考停止に近いのではと思ってしまった

@adwd118

自分がまだ詳しいほうのフロントで言うと誤りに近いと思ってて、状態がクラス階層の奥にあることで変更検知がいびつになったり最近の動向はその真逆だし。そもそもドメインロジックは大抵フロントにないし。

@adwd118

言語やライブラリの風習をすべて無視して全部これで行くってのはまあ一つの戦略としてありなのかもしれないけど個人的には否定的だ😎

@adwd118

まあでもこういうのTwitterに放流するくらいで実際に議論する気があんまなくて、PoEAAもエヴァンス本も読んでないのでそのへんで殴りかかられるとなんも言えないし読む気もない

@adwd118

クリーンアーキテクチャの本質を反映したコードでなく、本で紹介された用語や図を全部もりでそのままコードにおとしこんだものは、うげーってなりますね

@ntaoo

これはあるある。

「本に書かれていた事をちゃんとやりました!」 みたいな事言われると、受験勉強じゃねぇんだからよぉ...ってなってしまう。

「何故そうする必要があるのか?」「そうするとどういうメリットがあるのか?」「そうしないと生じるデメリットは?」ぐらいの質問に即答できないなら余計な事をしないでほしいという気持ちはある。

まぁ、ピカピカの技術やアーキテクチャは福利厚生みたいな側面もあるので一々言わないけども。

なんか昔にツイートしたけど、技術的負債を積みながら分かりやすい成果を生んで、その成果を...

なんか昔にツイートしたけど、技術的負債を積みながら分かりやすい成果を生んで、その成果をアピールして転職した方が合理的という話があってな…

@sinsoku_listy

技術的負債のババ抜き。JOKERを握って低評価を受け止める人は…いや、これ以上はいけない…

@sinsoku_listy

新しい技術をとにかく導入して、一通り作ったらそれをアピールポイントに転職して年収アップ! というのは業務経歴書駆動開発として忌み嫌われている。

技術的負債は開発者体験を悪化させる

SOLID原則に従って行うリファクタリング実践

テストケースの具体的な代表値には2以外の一意の素数を使おう

モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた

長いので後で読む

推薦システムにおいて線形モデルがまだまだ有用な話

「考えが合わない上司とは距離をとる」6割 新入社員の考え方:挑戦よりも失敗回避

新入社員は会社の上司や先輩とどのような関係を築きたいと思っているのだろうか。2021年~22年に入社した男女に聞いたところ、「叱られた後、必死で食らいつこうと思う」(59.2%)とした一方で、価値観が合わない上司・先輩に対しては「自分から歩み寄ろうとは思わない」(57.1%)と考えている人が多いことが、日本能率協会マネジメントセンター(東京都中央区)の調査で分かった。

「失敗すること」について、どのように考えている人が多いのだろうか。新入社員の7割は「失敗から学ぶことは多いので、恐れずに取り組むことが大切である」(72.7%)と回答している一方で、自身に仕事を任された際は「失敗したくないので、責任ある大きな仕事は任されたくない」(58.0%)と答えたのは半数を超えた。

そりゃまぁそうやろ

今は、もう、動かない、その User-Agent 文字列

「コード品質?レビュー効率?いや、PR数だ!!!」

コード品質やレビュー効率が改善された結果、PR作成数が増えると思っていました。ですが、実際は逆でした。

PR数を増やそうとする(つまり、 PRサイズを小さくする)ことで、レビュー効率が改善され、コード品質も高まっていくのです。

スクラム開始以降は適切にタスク分割でき、PRサイズを小さくできていることが分かりました。しかし、実際にデータを見ると、1PRあたりの変更行数は200行くらいあります。

他社の取り組みを見ていると、「1PRの変更行数は100行以下」を目安とする会社が多いようです。さらなる生産性改善のため、まずはこの水準を目指したいと思います!!!

チケット分割においてかなり手応えは感じているものの、現状のやり方ではある程度限界も見えているので、他の打ち手も検討しています。

具体的な方法の一つとしては、「フィーチャーフラグを使ったトランクベース開発」に挑戦したいと思っています!

保守性と生産性を両立する分析用SQL構造化の4原則 〜 構造化プログラミングの考え方をSQLに適用する

私のチームでは数千行におよぶ分析用SQLをリファクタリングして、保守性と生産性を両立する分析パイプラインに生まれ変わらせることができました。

この記事ではリファクタリングを通して確立した、分析用SQLを構造化するための4原則を紹介します。4原則を意識しながらSQLを書くことで、高凝集・疎結合な分析パイプラインを作ることができます。

  1. SQLを関数とみなす
  2. テーブルの意味を明確にする
  3. カラムからフラグを排除する
  4. レコードの単位を意識する

リファクタリング以前のアドホック集計は数千行にもおよぶ分析用SQLのコードをコピペして、一部を書き換えてからSQLを再実行するという流れでした。

このやり方だと、変更範囲の特定や変更の正しさの確認などにとてつもない時間と労力が取られていました。

そのため、1カ月に1人のアナリストがこなすことのできるアドホック集計は多くて2〜4件程度でした。

そして、アドホック集計の依頼に対して少なくとも5営業日以上の納期をもらっていました。

しかしリファクタリングの実施後は一人で5件〜7件程度のアドホック依頼をこなすこともできるようになりました。

基本的に部品化されたSQLの差し替えで対応可能なため、コード追加による機能変更で、変更による影響の範囲も限られているためレビューの工数も大幅に削減することができました。

その結果、今までレビューも含めると5営業日以上必要だったアドホックの分析依頼が、最短数時間で完了できるようになりました。

今回紹介した4原則はあくまで分析用SQLという最終的なユースケースがはっきりした集計分析用の分析パイプラインを構築する際のものです。

DWHやデータマートの構築など汎用的なデータソースを作成するためのデータパイプラインの構築には当てはまらない部分もあることはご注意ください。

突撃! 隣のLinuxデスクトップ

自分も自宅ではメインマシンをUbuntuにしているけど、特に不満とか無いんだよなぁ

むしろ支給品のMacの方がキーバインドの違いで脳がバグるので使うのやめたい件。

エンジニアリングマネージャーが手懐けるべき荒ぶる四天王

なんで人工衛星開発で OS やら VM やらの技術が必要なんですかという疑問にお答えしておくと、打ち上げた後...

なんで人工衛星開発で OS やら VM やらの技術が必要なんですかという疑問にお答えしておくと、打ち上げた後にもアップデートをしたい(これがほんとの On The Air)が、軌道上で文鎮になるとどうにもならんのでどうにか安全にやりたくて、Fault Isolation といえば OS や VM ですよねという感じです

@KOBA789

エンジニアのスキルマップ・テックリードへの途

今までああ書いてたアレ、これから䛿こう書けそう

20年掛けてjqueryの再実装をやっている感じがするのだが

DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識

CUEでTerraformを書いてみる

少しずつCUEが普及している感じがある

システムの保守には修繕計画が必要という話

NEXT