オープンソースのWebサーバーソフトウェアとして知られる「Apache」を運営するApache Software Foundation(ASF)に、北アメリカ先住6部族の1つであるアパッチ族を念頭に「アメリカ先住民への敬意と独自の行動規範を守るため」として名称変更の要請が出されていることがわかりました。
この「Apache」という名称について、ASF設立メンバーのブライアン・ベーレンドルフ氏は「Apacheという名前にしたのは文化的流用などではなく、当時ローンチされたWebテクノロジーは『サイバー○○』や『スパイダー○○』といった名称ばかりで、もう少し興味深くてロマンティックな名称が欲しかったからです。ちょうどジェロニモとアパッチという部族の最期についてのドキュメンタリーを見たところで、彼らが西部、つまりアメリカ合衆国による侵略を受けて領土を手放した最後の部族だったという話で、私にとっては、我々がWebサーバープロジェクトで行っていることをロマンティックに表現しているように思えたのです」と語っています。
Natives in Techは、この「ロマンティックな表現」が「無知であると同時に不快なもの」と指摘し、ASFに対して「選んだ言葉に深く注意」し、名称を変更するように求めています。
コードホスティングサービスである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言語ユーザーやコミュニティ以外のリソースにフリーライドする傲慢で邪悪な仕組みだと思う。
最近のウォーターフォール開発がうまくいってないと言っている人達は、実は大抵ちゃんとウォーターフォール開発を学んでないし、そもそもウォーターフォール開発自体をやった事がない可能性あるな。とちょっと聞いてて思った。
当人達は実体験はしてないけど、本やネットに書いてあるからとか、自分達がリスペクトしている人がそう言ってるとか、そういう伝聞で鵜呑みにしているのかもなぁとちょっと聞いてると思う。
ここでいう”ちゃんと”というのは、V字プロセスをPMBOKやCMMIやISO規格などを読んで各フェーズでやる事や入出力を理解し、今回上手くいっていなかったフェーズを洗い出し、要求漏れが多かった変更改善プロセスを改善する、日程にCCPMを適用するなど環境に合わせてテーラリングしていくとかって話です。
成功を定義しそれで結果を比較して成功の定義にならなかったものを対して、定義の問題か、実施プロセスの問題か、ヒトの問題か、環境の問題かなどを整理してそれぞれに対して改善期待値を決めて対応施策を考えて実施していく。このサイクルが回る事が大事であって開発手法の差異は付属でしかない。
開発を進めるにおいて何かの手法がダメ、この手法は正解みたいな些末な二値的な話にならないようにするのが大切な事で、常にその状況に適合できるように”ちゃんと”とか抽象的な思考停止を避け具体的な地に足が付いた最適改善方法を見つけて進めていく事が大事。こういう人が増えるといいよね。ホント。
- ロードアベレージが高い
- CPU使用率がほぼ100%
- 「1. CPU使用率」
- スワップが発生している
- 「2. メモリ使用量」
- スワップが発生していない
- 「3. ディスクI/O」
- ロードアベレージが低い
- TCPコネクション数が多い
- 「4. TCPコネクション」
- TCPコネクション数が少ない
- 他のホストを疑う
昨今、テストピラミッドなどの側面からユニットテストの重要性が説かれていますが、クラス間が密に結合している等で適切なユニットテストを書くのが難しいという状況に陥ることは多いのではないでしょうか。そのような状況は、ユニットテストの解像度が低いために生まれると自分は考えます。
本記事では、防御的プログラミングと契約プログラミングという二種類のプログラミングの方法論を元にユニットテストを再考し、ユニットテストの解像度を高めることを目標とします。また、ユニットテストのより良い書き方を模索している人に本記事を読んでいただきたいです。
なんか最近は自分達の能力や実績を立証できていないのに自分達が開発において一番価値を持つものを作ると思っていて、自分達がやりたくない事は周りがやるべき、自分達の価値創造の為に周りは頑張る、または奉仕をするのが当然みたいな論調のソフトウェアエンジニアが増えた気がする。
周りが自分達にとっての快適な開発環境を用意するのは当然だし、進捗は周りが自分達がやってる内容から負担をかけずに知るべきだし、進捗等聞いて圧をかけるべきではないし、能力が足りない場合はそれを学ぶ時間を調整して確保すべきだし、文書等作りたくないものはやりたくないので我慢すべきだし。
ビジネスのゴールや顧客への仕様は周りが用意すべきだし、ステークホルダーとの交渉は当然リーダーやマネジメントの仕事だし、コミットが未達でも自分達は頑張ったのだからその中でどうにか顧客を納得させるのは周りのやるべき事だし、コードをリファクタリングする時間も当然周りが確保すべきだし。
規律等は創造性を狭めるから敢えて定義をしないと言って自分達を律するコミットはしないし、それで理解が足りない場合は説明責任ではく周りの知識不足が原因だし、成果の質で悪い場合の責任を取るのは周り、よい成果を受領は自分達の当然の権利。なんか書いててあれだけどホントよく見かける。
GAFAなどがやっているから、成功している事例を聞いたなど自分達ではなく周りの成果は自分達の成果と同義的なアピールをしてたりする。客観的に見てみると正直昔も今もソフトウェアエンジニアが出している成果に劇的な大差はないのに、自分達を金の卵を生み出す鶏のように大事にせよと言う。
自分達が価値を作るんだという心意気は全然いいし、そうあって欲しいけど劇的な成果を出した訳でもないのに待遇は1流にしてくれというのはおかしいと思ってる。だって変でしょ？売れてもないデビューすら怪しい漫画家が周りに人気漫画家みたいな要求するのは。そりゃ売れて貢献してから言えとなる。
昔は社内など閉じたコミュニティで歪んだ自己評価が問題になって世間を見ろという話が多かったけど、今のソフトウェアエンジニアは社外だけど閉じたコミュニティで歪んだ自己評価が増えている気がする。ネットには自分の意見を肯定する都合の良い意見が溢れてるので自己評価が正しいのか判断が難しい。
こういう極端なソフトウェアエンジニアカースト的な我儘を推奨するような現在の状況は正直どうなのかなと思ってる。自分もソフトウェアエンジニアだけどそんなにカースト作るほど価値作ってないよ。ホント。素晴らしいプロダクトができたってニュースがあったからってそれは自分達の成果じゃないよ。
君ら本当に自分達の現在の立ち位置を見てる？と。自分達が大きい存在だと思っているかもしれないけど、それは本当に成果を出している人達の光を背にしているからできている影で実体ではないよ。自分達で光ろうとするのはいいけど他人の光でできた影で自分を大きく見せるのは悲しい話だよと思う訳です。
ソフトウェアはハードウェアの上で動く付属品扱いされていた時代の人からすると今のソフトウェアエンジニアの立場の向上は嬉しいけど、実体の伴わない我儘や傲慢な態度の人が増えてくるのはホント周りの真面目なソフトウェアエンジニアの価値毀損にもなるので勘弁して欲しいと思う今日この頃です。
さて、ここでクイズです。「Clean architecture とは、 controllers や use cases、entities というクラスを作って繋げるアーキテクチャのことだ、○か×か」。どっちでしょうか?
→ → → 正解は×です。 あの同心円は、あくまで clean architecture の一例として『Clean Acrhitecture』で紹介されたものです。
ストア層とコンポーネント層をわけるアーキテクチャには以下のメリットがあります。
- ストア層の改修がコンポーネント層に影響しなくなる
- コンポーネント側の変更もストア層に影響しない
あくまでレイヤー毎に独立していること、レイヤー間はインターフェイスやポート＆アダプタで接続されること、フレームワークやミドルウェアに依存しない、みたいな観点もあってもよさそうだが。
最近はClean Architectureを採用することはデメリットの方が多い気がしていて、これあかん奴なのでは感が強い。
Clean Architecture本の説明は「私（著者）が本気を出せばここまでやるぞ」という話であって、あれがスタンダードな実装モデルというわけでは無いのだが、どうしても参考書通りにやりたがる人が多いせいで不要な複雑さを抱え込む事例が多い。
それ、要はマイクロフレームワークのメリットでは？ 感が強い。
人手を集めるのに流行ってる言語を選ぶのは正しいけど、言語とフレームワークの区別ができてないのは問題に正しくフォーカスできていない感じがする。
Ubie では、創業当初から Server-Side Kotlin を推進してきましたが、全社的な技術選定を再度行い、これからは Go と Node.js を中心とすることにしました。
これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。
先達が色々好き勝手にやっていたけど、採用とかすごく手間だし技術スタックを統一するよって話かしら。
例えばこのエントリのタイトルではローカル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という単語自体がメタファに昇華してしまった感がある。
モジュラモノリスに関する部分もう少し深く聞きたかった
クックパッドのエンジニアリングマニフェストは、次の3項目からなります。
- 境界を越える (Beyond boundaries): 私たちは一人ひとりが高いリーダーシップを持った個人になるために、自分の能力の限界や、責任範囲に対する思い込みを乗り越えて成長していくエンジニアを目指します。
- 技術を楽しむことに責任を持つ (Responsible for enjoying technology): 私たちは一人ひとりが技術を楽しむ集団であることを目指します。困難な状況であっても、常に技術的な挑戦の機会を諦めません。一人ひとりに技術を楽しんでいる自分を目指す責任があります。
- 作ったもので語る (Speak with what you make): 私たちは動くものをすばやく生み出せる存在として価値を発揮します。また、作ったものを実際に触れることで得られる気づきを尊重します。
- Docker image名やコンテナ名のプレフィックスをディレクトリ名から変更する
- ヘルスチェックの設定
- 依存関係の設定
- サービス完了まで待機
- サービスをグループ化
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代替サービスの基盤として資本が投下されたように記憶している。
その辺りでゴチャゴチャした話があったという事なのだろう。
これが適用できる状況が狭すぎるので流行らないだろうし、流行るべきではない技術だ。
これで手抜きできる作業量より、これの挙動を理解してメンテし続ける作業量とプロダクトへのロックインリスクを考えると、手を出すのは止めておくべきだろう。
簡単よりシンプルを選ぶという奴であるな。
こうして見ていくだけでも、契約言語はプログラミングの歴史から大いに学ぶべきであると痛感します。 さらに悪いことに、高級言語と契約言語との大きな違いがあります。それは「契約言語は、全国民が完全理解できることがなぜか前提になっている」ことです。ビジネスの世界では、契約言語を通じてしか、他者と関わることができません。
例えば、外部サービスを利用するときには、利用規約に同意する必要があります。あれって、皆さんは本当に読めていますでしょうか？ ぶっちゃけ、現状のものは弁護士である私ですら読む気にならないです。そのくせ「私たちは一切の損害賠償責任を負いません」だとか、明らかにアンフェアな条項がこっそり含まれていたりします。
teratail、一時期リニューアルに失敗してボロカスだったけど最終的にリニューアル成功したという事なんだろうか。
Dockerコンテナの技術を用いることで、プログラミング言語のランタイムやライブラリ、ミドルウェアなどの開発環境一式を比較的容易に導入することが可能になりました。
ただしDockerコンテナにもファイルシステムのオーバーヘッドなどがあり、Dockerコンテナ内の開発環境ではコンパイルなどに時間がかかってしまう場合があったと開発ツールベンダのJetpack Technologiesは自社の経験から指摘します。
そこで同社がオープンソースで開発しているのが「Devbox」です（ちなみにマイクロソフトによる仮想化された開発環境の「Dev box」とは名前は似ていますが別のものです）。
Devboxは、ローカル環境上に分離した環境を用意しそこで開発環境を構築可能にしつつ、Dockerコンテナのような仮想化技術を用いていないことが最大の特徴です。
このDevboxの基盤となっているのが、Linuxディストリビューション「NixOS」のパッケージマネジメントツール「Nix」です。
仮想環境やコンテナではなく、Pythonのvenvみたいなイメージなんだろうか？
- 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と記事のみとなってしまい、大きく混乱を招く事態となってしまいました。
- 今後メールマガジンの配信は外部のサービスの利用も検討してまいります。
失敗には寛容だが、無能には寛容ではない
実験への意欲と高い規律性
心理的に安全だが、残酷なほど率直である
コラボレーションと個人の意思決定、説明責任
フラットで強いリーダーシップ、オーナーシップ
「失敗に寛容」、「実験の推奨」、「心理的安全性が高い」。「コラボレーションが活発」、「フラットな文化」といった革新的でイノベーティブな企業文化は自由で楽しいことばかりでなく、厳しい責任が伴うことも認識しなければならない。また、これらの文化は均衡を保つのが難しく、不安定である、といったものです。
「失敗に寛容」、「実験の推奨」、「心理的安全性が高い」。「コラボレーションが活発」、「フラットな文化」といった革新的でイノベーティブな企業文化は、えてして自由で、のびのびとした、キラキラした部分に目がいちがちです。しかし実際これらをやろうとすると、リーダーだけでなく、メンバーにも高いレベルが求められる、とても厳しくハードな規律と強さがセットとなる文化であることが分かります。
- はじめに
- 開発生産性の議論はアイデンティティに届く刃である
- 「生産性」とはそもそもなにか
- 「開発生産性の議論」における混乱
- 開発生産性の3階層
- レベル1：仕事量の生産性
- レベル2:期待付加価値の生産性
- レベル3：実現付加価値の生産性
- 開発生産性の3階層とビジネスコミュニケーション
- 開発生産性におけるインプットは何か
- 労働人数
- 労働時間
- 開発人件費
- 総事業コスト
- どの部門までインプットを含めるべきか
- 開発生産性における「アウトプット」とは何か
- ソースコード量(SLoC:Source Lines of Code)
- プルリクエスト量
- デプロイ数とPR数
- コード品質の評価と健全化指標
- ファンクションポイント量
- ストーリーポイント量(ベロシティ）
- 期待付加価値のスコアリング
- RICE スコア
- 加重スコアリング
- North Star Metrics
- 売上(や粗利益額)
- 開発生産性が高くても”開発が早い”訳ではない
- リードタイムの種類 - デリバリのリードタイム - サイクルタイム - 開発のリードタイム - 意思決定からのリードタイム
- 「頻度が質に転化される」という考え方
- 開発生産性を超えて
力作だ
心理的安全性「ずいぶん中途半端ですね。こんな企画じゃターゲットの母数も狭いし、かといってニッチにも刺さらないし、開発してもあまり儲からないでしょうけど、僕の給料は成功した場合と同じだけ上がりますか? そうでないなら作りたくないですね」これが言えるか、言わずにコケて愚痴で済ませるか
「さすが、開発者の自分にはない視点で考えてある。これには賭ける価値があるぞ。考えた人も開発チームを信じて任せてくれてる」っていう尊敬し合えてる組織を作るとなると、言わないで自分の身を守るタイプの人は排除なんだよなー
健全な意味での殴り合い・マサカリの投げ合いができることが心理的安全性。
しかし、それは仕事にフルコミットする事を求められるわけで、全ての人がそうできるわけではない。
実際自分はソフトウェア開発は好きだけど、ベンチャースピリッツ的な「ビジョン！ミッション！バリュー！」みたいなノリは大嫌いだし、生活費が稼げれば十分なんで...のタイプで仕事にフルコミットするつもりはない。
それは別に悪いことだとは思っておらず、そういうのを求められる企業とはアンマッチというだけのことである。
他方、心理的安全性のことを「部下が上司に舐めた態度を取っても怒られないこと」や「他人が自分の機嫌を取ってくれること」みたいに考えてるパーソンもたまに観測するけど、それはまた別の意味で残念なのだわ。
Wardley Mapping
英国の研究者Simon Wardleyによって考案された戦略フレームワークで、状況認識と戦略サイクルに沿った動きに基づいてビジネス戦略を設計し、プロダクトを進化させるのに役立つもの。
バリューストリームを縦軸、製品開発のステージを横軸としたマップとなっていて、自分たちの製品のコンポーネントがどこに位置していて、市場環境から見てどうなっているかを俯瞰して見れるようになる。
ポインタが実は高価な理由
- ポインタが指す値にアクセスする際にnilかどうかのチェックが必ず入る
- ポインタがnilの場合、Goはpanic()をおこす必要があるため
- ポインタは動的メモリアロケーションの原因になりがち
- ポインタが指す値はヒープ領域に置かれがち（絶対ではないけど一般的に多い）
- ヒープ領域は確保にまとまったメモリの検索、解放にGCが必要になるので負荷が高い
- ポインタは参照の局所性が低くなりやすいため、CPUキャッシュが効きづらい
- 多くの場合、値のコピーはポインタを使用するオーバーヘッドよりもはるかに安価
- GoはDuff’s devicesという手法を用いてメモリコピーなどのよくある処理について非常に効率的なアセンブラコードを生成する
- x86アーキテクチャだと64バイト以下のオブジェクトであれば値のコピーとポインタのコピーはほぼ同じ
小さいオブジェクトのポインタ渡し
[...]値渡しでもポインタ渡しでもパフォーマンスに大きな違いがないことが確認できました。
関数に副作用がないことを示すためにも、小さな構造体は値渡しで渡すのが無難かと思います。
ポインタを返す関数
関数内部で生成した構造体をポインタ渡しで関数外部に渡してしまうと、コンパイラが変数の寿命を判断できなくなり、動的メモリアロケーションが起きてしまいます。
いろいろ書きましたが、ホットパスな処理以外では値渡しでもポインタ渡しでも処理全体へのパフォーマンスにほぼ変化はありません。時期尚早な最適化は開発スピードを下げてしまいます。ベンチマークを取ってみてボトルネックになっている処理が見つかった場合に、不必要なポインタ渡しがないかを探すことをおすすめします。
見抜けたところで転職（退職）を引き留めることはどうせできないんだから別に構わないのでは？ 感ある。
どうしても転職サイトからリファラを送りたくないというなら、GitHubに自分の書いた記事のまとめをアップしてそちら経由でアクセスさせる方が楽だと思う。
経営者の気分で考えて欲しいんだけど「サービスが社員をやっと養えるくらいに儲かっている」「競合他社とも争いが激しい」といった状態で「ソースコードが汚いから1から書き直させてください。書き直しに1年かかります。機能は変わりません」なんて言うエンジニアなんて狂人として見られるだけだよ。
まぁ、一理ある。
とはいえ、どこかで何とかしないと手に負えなくなるのがシステム開発なので、結局は式年遷宮が必要になる。
その決断は早ければ早い方が良い。
サーバーもBFFもフロントもライブラリのプラグインすらもクリーンアーキテクチャで書かれてて、それはさすがに思考停止に近いのではと思ってしまった
自分がまだ詳しいほうのフロントで言うと誤りに近いと思ってて、状態がクラス階層の奥にあることで変更検知がいびつになったり最近の動向はその真逆だし。そもそもドメインロジックは大抵フロントにないし。
言語やライブラリの風習をすべて無視して全部これで行くってのはまあ一つの戦略としてありなのかもしれないけど個人的には否定的だ😎
まあでもこういうのTwitterに放流するくらいで実際に議論する気があんまなくて、PoEAAもエヴァンス本も読んでないのでそのへんで殴りかかられるとなんも言えないし読む気もない
クリーンアーキテクチャの本質を反映したコードでなく、本で紹介された用語や図を全部もりでそのままコードにおとしこんだものは、うげーってなりますね
これはあるある。
「本に書かれていた事をちゃんとやりました！」 みたいな事言われると、受験勉強じゃねぇんだからよぉ...ってなってしまう。
「何故そうする必要があるのか？」「そうするとどういうメリットがあるのか？」「そうしないと生じるデメリットは？」ぐらいの質問に即答できないなら余計な事をしないでほしいという気持ちはある。
まぁ、ピカピカの技術やアーキテクチャは福利厚生みたいな側面もあるので一々言わないけども。
なんか昔にツイートしたけど、技術的負債を積みながら分かりやすい成果を生んで、その成果をアピールして転職した方が合理的という話があってな…
技術的負債のババ抜き。JOKERを握って低評価を受け止める人は…いや、これ以上はいけない…
新しい技術をとにかく導入して、一通り作ったらそれをアピールポイントに転職して年収アップ！ というのは業務経歴書駆動開発として忌み嫌われている。
新入社員は会社の上司や先輩とどのような関係を築きたいと思っているのだろうか。2021年～22年に入社した男女に聞いたところ、「叱られた後、必死で食らいつこうと思う」（59.2％）とした一方で、価値観が合わない上司・先輩に対しては「自分から歩み寄ろうとは思わない」（57.1％）と考えている人が多いことが、日本能率協会マネジメントセンター（東京都中央区）の調査で分かった。
「失敗すること」について、どのように考えている人が多いのだろうか。新入社員の7割は「失敗から学ぶことは多いので、恐れずに取り組むことが大切である」（72.7％）と回答している一方で、自身に仕事を任された際は「失敗したくないので、責任ある大きな仕事は任されたくない」（58.0％）と答えたのは半数を超えた。
そりゃまぁそうやろ
コード品質やレビュー効率が改善された結果、PR作成数が増えると思っていました。ですが、実際は逆でした。
PR数を増やそうとする（つまり、 PRサイズを小さくする）ことで、レビュー効率が改善され、コード品質も高まっていくのです。
スクラム開始以降は適切にタスク分割でき、PRサイズを小さくできていることが分かりました。しかし、実際にデータを見ると、1PRあたりの変更行数は200行くらいあります。
他社の取り組みを見ていると、「1PRの変更行数は100行以下」を目安とする会社が多いようです。さらなる生産性改善のため、まずはこの水準を目指したいと思います！！！
チケット分割においてかなり手応えは感じているものの、現状のやり方ではある程度限界も見えているので、他の打ち手も検討しています。
具体的な方法の一つとしては、「フィーチャーフラグを使ったトランクベース開発」に挑戦したいと思っています！
私のチームでは数千行におよぶ分析用SQLをリファクタリングして、保守性と生産性を両立する分析パイプラインに生まれ変わらせることができました。
この記事ではリファクタリングを通して確立した、分析用SQLを構造化するための4原則を紹介します。4原則を意識しながらSQLを書くことで、高凝集・疎結合な分析パイプラインを作ることができます。
- SQLを関数とみなす
- テーブルの意味を明確にする
- カラムからフラグを排除する
- レコードの単位を意識する
リファクタリング以前のアドホック集計は数千行にもおよぶ分析用SQLのコードをコピペして、一部を書き換えてからSQLを再実行するという流れでした。
このやり方だと、変更範囲の特定や変更の正しさの確認などにとてつもない時間と労力が取られていました。
そのため、1カ月に1人のアナリストがこなすことのできるアドホック集計は多くて2〜4件程度でした。
そして、アドホック集計の依頼に対して少なくとも5営業日以上の納期をもらっていました。
しかしリファクタリングの実施後は一人で5件〜7件程度のアドホック依頼をこなすこともできるようになりました。
基本的に部品化されたSQLの差し替えで対応可能なため、コード追加による機能変更で、変更による影響の範囲も限られているためレビューの工数も大幅に削減することができました。
その結果、今までレビューも含めると5営業日以上必要だったアドホックの分析依頼が、最短数時間で完了できるようになりました。
今回紹介した4原則はあくまで分析用SQLという最終的なユースケースがはっきりした集計分析用の分析パイプラインを構築する際のものです。
DWHやデータマートの構築など汎用的なデータソースを作成するためのデータパイプラインの構築には当てはまらない部分もあることはご注意ください。
なんで人工衛星開発で OS やら VM やらの技術が必要なんですかという疑問にお答えしておくと、打ち上げた後にもアップデートをしたい（これがほんとの On The Air）が、軌道上で文鎮になるとどうにもならんのでどうにか安全にやりたくて、Fault Isolation といえば OS や VM ですよねという感じです
20年掛けてjqueryの再実装をやっている感じがするのだが
未だにドメインモデリングがよくわからない勢。
クラス図中心の説明で本当に認識が揃うのか？という疑問がある。
シーケンス図やBPMLみたいにフローが無いと全然理解できないんだよなぁ
- SQL
- Cloudflare
- TypeScript
- Figma
- Meilisearch
さて本題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。本記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。
じゃあEMという役割っていらないのか、でいうと僕はそうは思っていないです。もっと小規模なフェーズだったり、技術も人事もプロジェクトマネジメントも全部出来る人がいるのだとしたら、その役割はあっても良いと思います。アカツキゲームスの場合は、なんとなくいろんなことをやる存在としてEMというポジションをおいていましたが、何をする人なんだっけを改めて言語化してみたら、上記の3つの役割に分解するのが妥当であるという結論に行き着きました。
サーバサイドで実行可能なJavaScriptランタイム「Bun」の最新バージョン「Bun v0.3.0」がリリースされました。
Bun v0.3.0での最大の改善点はメモリ使用量の減少です。前バージョンのBun 0.2.2と比較して3分の1から5分の1程度になったと説明されています。
1GB超→65MBはシンプルに凄いな
そしてどんな高邁な理想がポリシーに具現化していても、運用というやつがあるわけです。実際にそのポリシーが効力を発揮して、役に立っていなければ、TDDの考え方をよくお分かりの方であれば、テストに失敗するわけです。まず失敗させることも重要だし、それに対応して常にグリーン(正常)を確認する作業が一番重要で、それがなければ改善しても価値がない(コストだけがかかる)。なので、アタックしていただくことは重要だし、それに対して我々は適切な運用を生み出していけるわけだと思うんです。
[...]11月に行われたスクラムフェス札幌にて、ハラスメント行為の被害を受けている、というご報告をいただきまして、その対応を札幌実行委員の方で行いました。具体的には報告の方から詳しくご事情を聴き、また、どうしたらよいかを話し合うということをしています。また今回については直接ハラスメント行為の当事者(加害者側)の方にもコンタクトして、お話をさせていただきました。加害者側の方にハラスメントの認識はないと思われるので、本件は被害者側がそうとらえている、という事実をお伝えすることがまず解決や再発防止への一歩目になるのではないかと考えております。
謝罪については、基本的にお断りすることにしました。私が理解する限りで、以下ような意見があり、こうした結論に至っています。
- 実行委員およびスタッフに運用上の過失があったとは認めがたいこと。
- 「ともかく代表者が謝る」という行為ではアンチハラスメントの目標が達成できるとは思えないこと。
- (この点は単に実行委員の文化的背景に過ぎないので皆さんに同意を求めるものではないですが、) スクラムの重要な文化は、自己組織化・自己管理だと考えているので、それに照らしても、代表者等の謝罪、というのは適切な処置とは思えない。むしろ一般的には問題をうやむやにする行為に近いのではないだろうか、という気がかり。
今回のハラスメント行為のご報告について、一同、心を痛めております。また必要と考えられる対応も、実行委員の負担を考えながら、できる範囲で行ったつもりです。
報告者のプライバシー保護の観点から、個別の事象は公開しませんが、ポリシー運用に関する一般的な対応については議論を行い、各実行委員の代表者の方の同意をおおむねいただきました。
予想外の不誠実さにドン引きなのだが。
要約すると、
いや、運用が上手く行かないこともあるとか失敗がどうとかはどうでもいいし、言い訳だろう。
加害者に悪意があったかどうかも関係なく、社会通念に照らしてハラスメントであるかどうかを考えるのが筋だろ。
その上でハラスメントであるなら加害者に詫びを入れさせる、ハラスメントでないと考えるならその根拠を説明するみたいなムーブが必要。
運営が動揺するから〜とか負担が増えるから〜とか、我々に瑕疵は無かったんで〜みたいな保身的な話に終始しているに過ぎない。
運営も手弁当でやってるイベントではあるとは言え、流石にこれはレベルが低すぎるのではないか。
身内の「いい感じの空気感」を壊したくないからナァナァにやっているんじゃないのか。
スクラム大好きな人結局マイクロマネジメントと無意味な制度化大好きなパワハラ一歩手前みたいなのばっかだしそれが集まればああいう揉め事にもなるだろうという感じだな(つまりスクラム大嫌いです)
↓の件について
一方日本でも、スマホの自己修理は、権利として認められていくのだろうか。これには、かなりのハードルがある。
まず第1に、現行法では技適マークのあるスマートフォンなどを分解すると、改造とみなされて電波法違反となる可能性があることだ。たとえ分解前とまったく同じように組み立て直しても、一旦中を開けた以上、改造していないという証拠がない。また純正部品からサードパーティ製部品への交換は、改造とみなされる可能性は高い。電波法違反は非常に罪が重く、1年以下の懲役、または100万円以下の罰金が科せられる。
もう1つは、修理の難易度である。スマートフォンのパーツは、それぞれがかなり小さく、指でつまむと中まで指が入らないので、ほとんどはピンセット作業である。電源は切ってあっても、バッテリー自体は生きているため、触る場所に気をつけないとショートする恐れがある。また先端の尖ったピンセットでバッテリーの表面を傷付けるといった事になれば、リチウムイオン電池の安全性は大きく下がる。
一番大きなポイントは、日本はもはや十数万円の機器を毎年や2年ごとに買い換えられるほど、裕福な国ではくなったということである。スマホを買うときは、修理を前提で延長保証や修理保険に加入するというのが当たり前になってくるだろう。
加えてスマートフォンの進化も、2年程度ではたいして違わなくなってきている。筆者も今年Pixel 4aからPixel 6aに買い換えたが、それは下取り価格がなかなか良かったからであり、Pixel 4aが遅くてどうにもならなかったかというと、そういうわけでもない。カメラもこれ以上高画素になったらファイルが重たくなって、内部ストレージやクラウドバックアップ領域を圧迫することになり、メリットがない。ネット上で拡散される画像として、どのみちハンドリングのよい画素数にシュリンクされるだけだ。
10万超えの商品を毎年or2年ごとに買い換える人間がマジョリティだった時代は無かったと思うのだが。
高級スーツだってそんなサイクルで買う奴は裕福層ぐらいだろう。
高額商品を毎年買い換える人間は金持ちの道楽かそれにハマっているオタクとかでは。
趣味性の高い商品と日用品のスマホを並べるのは違う気がする。
相互に敬意をもつメンバーがあつまってスクラムが理想的な形で働いて一人一人のスキルやチームワークが改善していくみたいなシナリオ可能性としてはありえるんだろうけど現実的には成り立つことはないだろうと常に思ってます
綺麗な建前ぐらいは無いと現実と戦えないからね
具体的にオレに対して行われたのは以下2点です。
例の「コミュニケーションは難しい」の画像をDiscordのスタンプに設定され、チャットで文脈と関係なく頻繁に貼付される形で晒されたこ と
オレの預かり知らぬところで「滝さんの圧が強い件」という名前のテストチャンネルが勝手に作成され、オレを中傷するような話題で盛り上がっていたこと
オレはこれらの行為に対し、有体に言えばキレてスクラムフェス札幌運営に苦情を申し立てました。
なんかいもいってると思うけど、DBMSがデータベースエンジンの実装を隠して統一的にSQLで見せてくれてるのに、なんだってインピーダンスミスマッチで消耗してオブジェクト指向をやらにゃならんのだ（リレーショナルモデルでアプリケーション作りたくないからでは）
今日の問題意識としては、RDBとオブジェクト指向の間でマッピングできたとして、それをJSONを返すREST APIに公開したりしていて、何重にも違うデータモデルの間を変換するということに…
正直、2022年にもなってO/Rマッパーを採用しちゃう人は、私は物事を深く考えない（というか脳死している）エンジニアですと自己紹介しているに等しい（暴論）。
「技術的には可能です」みたいな台詞って、アイデア未満の思い付きレベルの雑談でしか言ったことないから、そんな深刻に考えたことないな。
やるにしても本格着手前の実現性調査みたいな段階で「これはダメですわ」ってなるし。
思い付きをゴリ押ししてくる人もいないわけでは無かったけど、そういう人は大抵すぐにいなくなったりするので実害もあまり無いというか。
コンサルとか上流工程専門みたいなやつかしら
安いタブレットによく使われてるSoCのイメージだったけど、台湾のメーカーだったのか。
- ボールを浮かさない
- 解散の目安をはっきりさせる
- 関連部署に伝達する、ただ騒ぐ
- 絶賛する＆なぐさめる
- ドキュメントを書く
- チケットを立てる
- 全然わからないと言う
- コードレビュー、しにくいことを伝える
- 他には？
- We are hiring
CUEを使用すると、外部システムに依存せずに全てをローカル環境で実行できるため、バリデーションや生成がすべてクライアントサイドで実行できます。Kubernetesエコシステムのツールやシステムはwebhookを代表とするサーバーサイドの通信を要求するものが少なくありませんが、これはフィードバックを遅くし、トライアンドエラーの制約になります。これらの特徴によって、シンプルな設定と発展的な設定、さらにはリソースのデプロイ方法といった、すべてのユースケースを満たすことができます。CUEは、KustomizeやHelmよりもはるかに表現力があるにも関わらず、中心的なパッケージは保守しやすくなっています。
最近スペックがチープな中華OEMタブレットが発売されることが増えてる気がする。
中国はロックダウンによって外出制限が掛かってる影響でタブレット需要が増加したと聞いたことがあるから、そこで余剰になった生産設備やパーツを使って安価なタブレットを業務用というラベルで売り出してるのだろうか？
この手の製品はソフトウェアにコストを掛けておらず、ほぼ素のAndroid OSということもあってAndroidアプリの開発マシンに適しているし、スペックのチープさからアプリのパフォーマンス検証に使えたりもする。
ドワンゴではniconicoの配信系サービスのバックエンドで利用するために、Frugalosという名前の分散オブジェクトストレージを開発しているのですが、この度OSSとして公開することとなりましたので、この場を借りて軽く紹介させて貰います。
これは「ニコニコはまだまだオンプレで行くぞ」という事なのだろうか。
6月に発生した尼崎市全市民46万人分の個人情報入りUSBメモリの紛失を巡って、尼崎市は11月28日、BIPROGY（ビプロジー、旧社名元日本ユニシス）に対し損害賠償請求を行うと発表した。尼崎市のイメージダウンにつながったことなどを理由としている。
尼崎市が設立した調査委員会は28日、調査報告書を発表。ビプロジーは市の承諾を得ずに委託業務先の再委託、再々委託を行っていたという。USBメモリの持ち出し時には、鍵付き金属ケースで運搬するよう定めていたが、ビプロジーは規定通りの対応をせず、管理が不適切だったとしている。
尼崎市ではビプロジーに対し、すでに18カ月間の入札参加停止措置を実施している。現在契約中の案件についても、準備が整い次第別の事業者へと切り替える方針だ。一連の対応に加え、紛失報道の直後から市への問い合わせや苦情が殺到し、通常業務に支障が出たことや、イメージダウンによって本来不要な経費などが発生したことを理由に、ビプロジーに対して損害賠償を求めるという。
再委託・再々委託とは要するに多重下請け構造なわけだが、是正されるのだろうか？
正直、GORMはもう使いたくねぇわ感ある。
単純なクエリならともかく、複雑なクエリになってくると「この学習コストに価値あるのか...？」という虚無が生えてくる。
個人開発ならgoquを使えばいいかな感はあるけど、チームにゴリ押しするのは少し無思慮な気はする。
というわけで、sqlcを使ってみるのはよさそう。