ついに、やり手の社員が自分の業務を全部整理してベンダーとRPA化して完全に自動化した後に異動になり、後任者は「全部自動で出来上がる業務」としか引き継ぎされておらず業務の中身は誰も知らないブラックボックスになるという事態を観測した
新しい業務が発生したらどうするのか、現在の業務の正しさは誰が保証するのか。本当に前任者を異動させてよかったのか？
ITシステムは常に抽象化を目指すものであるが、抽象化されたインターフェイス越しにはドメイン知識を理解することはできないのだ。
金額、数量、日付を使った計算判断ロジックは、値オブジェクトにカプセル化するのは、もっとも基本的な定石パターン。
応用パターンとしては、始点・終点、下限・上限の二つの値を持つ範囲を表現する値オブジェクトが役に立つことも多い。
マスターデータから定数やEnum的ものを自動生成する時の話
突然ですが、Reactを使用する際、コンポネントのロジックや状態が増えてきたとき、みなさんはどうされてるでしょうか。
関数コンポネントでは、一般にcustom hooksとしてまとめて切り出すことが多く行われていると思います。
今回の記事では、useState/useRef + custom hooksという単位で切り出すのではなく、 クロージャを使いロジックや状態をコンポネントの外に持たせるようにリファクタリングすることで、コードの見通しが良くなる、という事例を紹介します。
Reactを使用していると、useStateやuseRef、useReducer、useEffectなどを使用しcustom hooksを活用してコードを書く場面が多いと思います。
もちろん、custom hooksで簡単に解決できるものも多くありますが、記事で取り上げたようにプレーンな関数・クロージャにロジックをまとめ、hooksを使ってReactとの繋ぎ込みを行うことも検討すると良いと思います。
マイクロソフトは現在開催中の開発者向けイベント「Microsoft Build 2022」で、Arm64ネイティブなVisual Studio Codeや.NET、Windows Subsystem for Linuxなどを投入することを明らかにしました。
投入予定として発表されたのは以下のソフトウェアです。
- フル機能のVisual Studio 2022
- Visual Studio Code
- Visual C++
- .NET 6
- 旧.NET Framework
- Windows Terminal
- Windows Subsystem for Linux
- Windows Subsystem for Android
以下のオープンソースについてもArm64ネイティブ化の作業をしているとのこと。
- OpenJDK
- Python
- LLVM
- Node.js
- Git
おぉー
ctxパッケージは2014年12月19日にアップロードされた「ctx 0.1.2」を最後にアップロードされていない。このパッケージはPythonのdictオブジェクトのサブクラスであるCtxを提供するもので、基本的に2014年12月19日を最後に開発が終了したとみられる。
しかし、このパッケージは最近不可解な動きを見せたという。2022年5月21日に同じものに置き換えられ、その後さらにバージョンアップが行われている。ctx 0.1.2が新しいctx 0.1.2へ置き換えられ、そのあとで0.2.2と0.2.6が公開されている。そして、この動きのうち、置き換えられた0.1.2と更新された0.2.6には次のような不可解な機能が追加されていたと指摘されている。
- 置き換えられた0.1.2：ディクショナリ作成時にAWSアクセスキー、コンピュータ名、AWSシークレットアクセスキーを取得しようとするコードを追加
- 0.2.6 ：すべての環境変数を取得してBase64でエンコードし攻撃者の影響下にあるWebサーバにデータを転送しようとするコードを追加
元々のパッケージのメンテナのドメインの有効期限がすでに切れており、サイバー犯罪者は同じドメインを2022年5月14日に登録。このドメイン名を使ってパスワードリセットのメールを送信して、アカウントの乗っ取りを完了させたものとみられている。
kowai
まぁでも、Python で小規模なデータ解析したり Flask でちょっとしたサーバを書いたり Jupyter Notebook でコード書いたりする範疇だと GIL って影響しないからなぁ。そういう人達がターゲットなのであれば、ロックしないでも使えるというのは、パフォーマンスを犠牲にして得たメリットの1つなのでは。
ビッグデータ解析とかは最初に作られた時はターゲットにしてなかったわけだし、しゃーないというところはある
昔、DDDのいう「ドメイン」をどう捉えれば良いかよくわからなかったので、仲間内では「業務」と翻訳していたのを思い出しました。コア業務と汎用業務、担当部署と伝票で、大体説明できてしまいます。
新しいアイデアは新しい名前をつけた方が良いと思うけど、「今までやってきたこと」に対して新しい名前を与えるのは誤解を招く可能性があるのかなあとか。
「伝票のやりとりが多い」のが密結合です。「隣の部署に問い合わせしないといけない」のは凝縮されていないことを示唆している。複数部署にまたがる同期が必要なら、それはサービスを跨いだトランザクションの存在です。程度のことだと思うんだけどなー。
伝票の「注文数量」を書き込むときに、あらかじめ「注文数量伝票」に数字「10」を埋め込んで、それを「注文数量」に書き込む必要があるとしたら、不必要に結合度が高い。何らかの事情で「注文数量クラス」を作ったとしても、それを外部にインタフェースとして公開すべきかはよく考えましょう。
Linuxが動作するコインサイズのワンチップコンピュータ。
LinuxはOpenWrtという組み込み用途向けディストリビューション。
ちょうどVOICEVOXの環境構築しようとしていたので助かる
Service Objectよりconcernを使うべきらしいが、RoR固有の話っぽそう。
自分の場合、Service（最近はUsecaseと呼称することが多い）層はドメイン層のファサード（あるいはエントリーポイント）という認識で、アプリケーション層とドメイン層を明示的に分離する為に設置する感覚が強い。
ドメイン層とアプリケーション層が分離されているいことは、ドメイン層のユニットテストが容易という利点で十分ペイするので、あえて取り除きたいとは思わない。
Service層を作るとドメインモデル貧血症になりがちというのは実際その通りで、愚直にトランザクションスクリプトを書けてしまう問題は付きまとう。
とはいえ、そういうコードを書く者はどの道Controllerにみっちりとトランザクションスクリプトを書いてくるので、結局はレビューで解消すべき問題ではある。
このように定義済みの用語に対して独自解釈をオーバーライドしていくのはちょっとどうかと思う。ドメイン固有型はエンティティや値オブジェクトから構成されうるけれど、Pythonのdictのようにドメイン固有型でない値オブジェクトという反例があるため、値オブジェクトはドメイン固有型の一種とは限らない。部分集合ではなく直交した概念である。
確かに造語病めいた独自定義用語が増えてくる「何言ってんだこいつ？」という感じになるのでよくない。
一方で、新しい概念や観念はやはり既存の用語を侵食するものでもあるので、中々難しい問題である。
まぁ、プログラマなのだからきちんと名前空間を付ければいいのかもしれないが（「ワイ考案の値オブジェクト」的な）。
プロジェクトが炎上する
↓
頭数だけ増やせばいいと思って素人同然のやつを前線に送り込む
↓
リーダークラスが複数脱落
↓
なんかよくわからない偉い人が出てきて現場の指揮をとりだす
こういうデスマーチ、ITの現場でもあったなあと、ロシアを見て思い出した。
マイクロソフトは、JavaScriptで2Dや3Dモデルを高速に扱えるライブラリ「Babylon.js」の最新版「Babylon.js 5.0」正式版をリリースしました。
Babylon.js 5.0の最大の新機能はWebGPUにフル対応したことです。
現在、JavaScriptを用いた2次元や3次元の高速なグラフィックスの描画を行うWeb標準として「WebGL」が広く使われており、Babylon.jsはこのWebGLを扱えるJavaScriptライブラリとして知られていました。
Babylon.js 5.0でフル対応となった「WebGPU」はWebGLよりも新しいWeb標準です。軽量でGPUの能力を最大限に発揮しやすくなっているため、より高速なグラフィックス処理などが期待できます。Babylon.js 5.0ではこのWebGPUを抽象化してより使いやすくしています。
また、Babylon.js 5.0では、IonicやReactNative、Electron、Babylon Nativeなどのネイティブアプリケーション開発用のフレームワークを用いることで、Webブラウザだけでなく、WindowsやMacのデスクトップアプリケーション、iOS、Androidのモバイルアプリケーションなどネイティブアプリケーションの開発も可能なクロスプラットフォーム対応になっています。
こんなのあったのか
VPSで動かすならこういうのもありなのかもしれない。
Joel先生（元Excel開発責任者）のExcel講座
コマンド体系がユーザーフレンドリーなHTTPクライアント（WEB/Desktpo版も開発中）らしい。
React風のAPIを持ちつつ、仮想DOMを使わないJavaScriptライブラリとのこと。
cloudflareやNetlify、Vercelがスポンサードしてる辺り、中々有望株なのかもしれない。
ローカルでの開発やテスト向けの為の実験的プロジェクトとされている。
確かにTemporalのワーカーをテストする為にCassandraのクラスタを設定するのは正直ダルいという話はある。
お、メッセージキューもあるのか
PythonからGILが無くなるかもしれないのか。
技術的負債 (technical debt) は、ソフトウェア開発の用語で、手早い解決策を選択することで生じた潜在的な手直しのコストを指す。技術的盆栽 (technical bonsai) は、完成した技術を鑑賞し、また完成度の向上のために手直しを加える趣味を指す。技術的負債とは特に関係はない。定義はいま考えた。
著名な技術的盆栽として TeX が挙げられる。数十年に渡ってメンテナンスが続けられており、きわめて完成度が高く、新たなバグを発見すると高額の賞金が得られることでも知られている。
秀丸エディタもまた技術的盆栽性が高い。古くから存在するソフトウェアだが、今もなお改良が加えられ続けている。秀丸エディタの特徴的な点は、開発者がソフトウェア使用料で生活しているところである。高い価値を持つ技術的盆栽の開発に成功すれば、静かにそれを鑑賞し、心穏やかに細かな改良を加える生活を送ることができる。
技術的盆栽と向き合う暮らしは、多くのコンピュータ技術者が憧れるものであろう。
実際のところ、技術的な進展の速い領域（たとえばエーアイ研究）ではひとつの盆栽にじっくり向き合うのは難しい。新しい品種を試行錯誤しながらギリギリ育て上げ、すぐ出荷してまた別の品種を… という取り組み方になりやすい。これはエキサイティングではあるが、心穏やかな暮らしとはいえない。もう少し資産の蓄積を意識しても良いのではないか、と時々思っている。
CDNベンダのCloudflareは、同社のCDNエッジ上にSQLiteベースのRDBサーバ機能を提供する新サービス「Cloudflare D1」を発表しました。同社にとって初めてのデータベースサービスです。
Cloudflare D1では、同社のCDNネットワークを用いて自動的にユーザーの近接エッジにデータベースのリードレプリカを作成し、プライマリとなっているCloudflare D1データベースに対するアップデートをレプリケートします。レプリカの作成やレプリケートはCloudflareが自動的に最適化し実行してくれます。
READはよいとして、WRITEの整合性はどうやって確保するんだろう？
一旦やっていけるポジションを確立してしまえば、別に世の中の流れに合わせる必要はないということがよくわかる。
日本のソフトウェア開発がいまいちパッとしないの、世界は既に「ソフトウェアをどれだけ高速に変更・改良し続けるか」に全力で投資しているのに、日本は未だに「ソフトウェアも最初にドカンと開発投資して後はそのまま使う」発想が（少なくともスーツの）前提にあるからじゃないかなあ…
#TEST_Study
とはいえ、ソフトウェア以外の資産はそういうものだし、全ての企業が継続的な開発に投資できるわけではないという現実もある。
Docker Extensionsは、手軽にDockerコンテナ環境を導入し、GUIで統合管理できるDocker Desktopに対して機能追加を可能にするものです。
いわゆるアプリストア的な機能を備えたマーケットプレイスからさまざまな種類のDocker Extensionsが提供され、クリックして導入するだけで機能追加が行えるようになっています。
ふーむ。
本日 Cloudflare は Cloudflare Workers のランタイムを Apache License, Version 2.0 でオープンソースにするとの発表がありました。これにより開発者はロックインされることなく書くことができます。
Cloudflare Workers は Cloudflare が提供する、以下のような特徴を備える高パフォーマンスなエッジ コンピューティング環境です。
- 自動的なスケーリング
- 数分でグローバルへデプロイ
- コールドスタート無しで処理を実行可能
- JavaScript, Rust, C, C++ で処理を記述
コンピューティングだけでなく、グローバルに分散する強力なデータベース/ストレージ環境も備えており総合的なエッジ開発プラットフォームとなっています。
- Workers KV：結果整合性の高速なキーバリューストア
- Durable Objects：強い整合性のデータベース
- R2 Storage：Amazon S3 互換の高速で信頼できるオブジェクトストレージ
Workers だけでなく多彩なデータベース/ストレージも備えているため、フォレスター・リサーチ社の調査によるとエッジ開発プラットフォームの分野で Cloudflare はリーダーに選出されています。strategy と current offerring で共に最も優れていると最高の評価がされています。
しゅごい
CUPID原則:
- Composable: plays well with others
- Unix philosophy: does one thing well
- Predictable: does what you expect
- Idiomatic: feels natural
- Domain-based: the solution domain models the problem domain in language and structure
- 構成可能：他のコンポーネントと構成可能
- Unix哲学： 1つのことをうまくやる
- 予測可能：利用者の予想を裏切らない（驚き最小化原則）
- 慣用句：自然に感じる命名
- ドメインベース：ソリューションドメインは、対象ドメインを言語と構造で表現する
前述の通り、PyScriptはWebAssembly化された代表的なPythonインタプリタ実装である「Pyodide」（パイオダイドと発音されているようです）を用いて開発されています。
PyodideはMozillaが2018年に開発を開始したプロジェクトで、Pythonのリファレンス実装であるCPythonのソースコードに最小限の変更を行い、EmscriptenでWebAssemblyへコンパイルできるようにすることで、WebブラウザなどのWebAssembly実行環境上で事実上標準と同じPythonインタプリタが実行できることを目指しているプロジェクトです。
やっぱりWebAssemblyだったか
処理系がWebAssemblyを生成さえできればどんな言語でもブラウザで実行可能なのであれば、もうTypeScriptが直接WebAssemblyを生成する世界の方がシンプルでエレガントなのではなかろうか。
これって定期的に更新してるのか
エンジニアとして得られる経験値を考えると、新卒で大企業の事業会社に入っても細々した事はベンダーがやってくれちゃうから、10,20年同じ大企業にいたら、市場価値のないただ威張りながら指示するだけのエンジニアもどきが出来上がりそう…
なのでそういう人々は「重要なのはマネジメント能力、実際に手を動かすのは下請けの仕事」と嘯くことでメンタルを守るのだ
①トランザクションスクリプトパターンが悪で②ドメインモデルパターンが善という読み方したらあかんよ。方法論はコンテキスト依存なので。Twitterのような非機能優先で機能的にはそこまで複雑でない場合ハイトラフィックな要件だと②が難しくて①が選択肢になることがあるんです。
善悪固定で方法論を考えるとその場の状況(コンテキスト)に合わせた意思決定ができなくなります。善と悪、プラスとマイナスは、前提が変わると簡単にひっくり返ります。二項対立といって、哲学の分野でもこれは有名な話なんです。固定的な正しさがないと言われています。
まぁほとんどのユースケースにおいて性能はそこまで問われないと考えると②が妥当なケースが多いでしょう。ですが、視野を狭めたくないのであれば、こういう観点をもっておくことをお勧めします。
なのでほとんどのケースではドメインモデルパターンは有用。一方でトランザクションスクリプトパターンが無用かというと、そこまで言い切れないという話になりますね。つまり0/1で簡単に線引きできる問題ではないということです。僕はそう考えています。
全く以てその通りなのだが、しかしその域まで達するのは意外と難しい。
ある意味悟りみたいなものなので、新しい技術を知って「この技術・方法論を使いたい！」となってる時はそれに執着してしまうもの。
日本の人件費が安すぎるのは主に飲食などサービス業の文脈で指摘されるけど、IT業界でも弊害があって、人が安いとシステムで自動化するより人を使った方が安上がりなので技術革新が阻害されてしまうんだ。人件費が安すぎると成長が止まってしまうのはこういう理由。
とりあえず人海戦術に頼ってみたりとかね
あるプロジェクトでPRにもらったコメントに対応する新コミットを追加したら「コミットログが汚くなるから一つに纏めて」と言われ、のちに別の所で一つに纏めたら「差分がわからなくなるからレビュー反映用コミット作って」と言われ、単に方針が違うだけと理解つつ渋い顔になったことがある皆さん
開発の流儀が書いたドキュメントがしっかりしているプロジェクトでも、こういうところはわりと明文化されていなかったりする。こういうときは他の人のレビューを眺めるとわかりやすいです
割とそういう部分でやる気削がれたりするタイプ
そういえば5年前のQiitaあたりまでは「WebシステムにORMなんて不要。ビジネスロジックはストアドにやらすべき」と主張する人がいた記憶があるから、ストアドおじさんはまだあなたの隣にいるかもしれません
そんなこと言ってたの当時でもあの人ひとりだけでしょ。
Reactで見た目が同じなだけのコンポーネントを共通化してると突然別物になって死ぬ経験が多すぎたので、最近はもうcssごとコピペしてる
これは本当にそう。
レガシーな業務コードは基本的に学びが薄く、長期的に関わると能力面へ影響はあまり良くないことが多い。
一方で会社として必要だからあえてやっている側面もあるけど、知っている限りそれが給料に反映されることは（やめようこの話）
「レガシーコードで触るのがツラい」と「ガンガン利益を上げるプロダクト」は普通に両立するので。
Clue とは何か？
マイクロサービスにあったらいいなという機能をまとめたライブラリです。
複数のパッケージから構成されています。Goa に限らずマイクロサービスでの利用を想定して書かれています（が、Goa ではこれを積極的に利用したいという風に見えます）。
ふむふむ
自分はFirestoreでReadクエリが1日に3-4万回、Writeクエリが1万回程度の小規模なサイトを管理しているけど無料枠の範囲内なのでDBのコストは月¥5になってる(¥5て)
Writeが1万回/日なら突然のスパイクが起きない限りはSQLiteで良いじゃん感あるが。
まぁ、Cloud FunctionやCloud Runを使ってるとSQLiteを採用できないというのは分かる。
デメリットとしてはマネージドサービスではないのでDBサーバーのメンテナンスを自分で行う必要がある。
これは自分的には「コスト削減できるけどメンテナンス時間10倍になる」方法だと認識しているので避けてる。
DBサーバのメンテナンスでメンテナンス時間10倍の根拠が分からなかった
メモ:
僕が一番技術顧問で入りたくない組織は、プロダクトや組織を見ずに技術だけしか見てないエンジニアがリードを取っている組織です。このタイプは基本人の話を聞かないので、顧問を入れたところで何も変わらないし、下を入れても組織化出来ないのでプロダクトも停滞したままです。
確かにこれはかなり厳しいことになりがち
理想的にはそうあるべきなんだけど、問題意識やスキルレベルが噛み合わないと何だかよくわからないゴミ情報しか生成されないので、正直微妙。
むしろ、積極的に捨てられる（廃棄可能性）コードやシステムに全振りした方が楽になるかもしれない。
「僕のかんがえた最強のOS」を作らずに、「技術負債だらけのどうにかこうにかUNIXとして使える最低限動くモノ」を完成させて良いタイミングでリリースしたことが、Linuxの成功理由と言われてます。技術選定にこのセンスがないと確実に事業はコケます
もっと重要なことは、リーナスがその後30年近くLinuxを放り出さずに面倒見続けているということ。
その信頼感がLinuxに投資してもいいかもという判断を生んだ。
POCで適当なプロトタイプを作って満足して去っていくエンジニアの皆さんは本当に反省して。
これからはPHPやRubyをやめてRustやGoにしないと採用が難しいという都市伝説を信じて切り替えたところ、やりたがりのワナビーは来るけど、バリバリの経験者は応募がなく、採用がより難航したという話を聞きました。Twitterの一部の声の大きな話は気をつけてください
自分の会社に必要な人材は「最先端の技術をキャッチアップしてエンジニア組織をグレードアップさせる人材」なのか「単なるソルジャー」なのかを理解して求人を出さない人事・経営陣が無能案件では？
「システム開発は多重下請け構造が当然」、「コード書く人は単価が安い」、「プログラマは35歳で引退すべき」はセットで語られる概念ですけど、そういう世界があるのは（日本で主流なのも）知ってるけど、それが世界のすべてのように語られるのもイラッとしますね。
たしかに。
ただ一方で「キラキラエンジニア！」「好きな技術で遊ぼう！」「圧倒的成長！」みたいな界隈もウンザリしてきた。
NHK広報局に確認したところ、「Firefox」など、上記3ブラウザ以外での動作はもともと確認しておらず、推奨ブラウザには加えていなかったという。「NHKプラスにおいて一定数のユーザーがFirefoxを利用している可能性があることや、5月23日以降に予定している設備更新に伴い、Firefoxでは動画が完全に再生できなくなることから、お知らせを掲載した」（NHK広報局）としている。
有料動画配信サービスだと再生できなかったり、何か不具合があるとサポートへのクレームが激増（しかも大半がめっちゃ感じ悪い文章）するので、敢えてシェアが数％のブラウザの為に検証・サポートコスト（サポートチームの精神的負担）を割きたくないという発想は理解できる。
go-lang製のAPIゲートウェイ。
KrakenDがLuraProjectという名前に変わって、Linux Foundation傘下に入ったもの、という事らしい。
なので中身はKrakenDと言える。
Not KubernetisなPaasらしい。
Freeプランが存在していて、512 MB RAM/1 GB Diskが利用可能。CPUは共有。
とりあえずコンテナをデプロイすればいい感じにスケーリングしてくれる仕組みなのだろうか。
日立製作所に入社した友達と飲み会した時、自分が“日立語録”を覚えたてだったこともあり、何かあるたびに「追加でビール注文させて頂きたく」「生ビール、拝承」とか言い続けてたら2度と飲み会してくれなくなった。
これはウザいｗ
goqueryは、Go標準のnet/htmlパッケージとCSSセレクタライブラリのcascadiaがベースになっており、jQueryっぽく書くことができます。
へぇー
Temporalの競合みたいなイメージだろうか。
開発も活発だが、将来的な伸び代はTemporalの方がありそうな気がしないでもない。
TemporalはCadenceのフォークという位置付けらしい（なので特別な思い入れがないのであればTemporalを使えばよさそう）
見た感じシンプルでとっつきやすそうだけど、すでに更新はなくメンテナンスモードみたいな感じか。
DXソフト、いくら脱Excel脱Fax叫んでも、それぞれが独自の形式で市場を独占しようとするせいで結局唯一互換性のあるソフトがExcelか、最悪FAXになるという
とはいえ、どのようなデータが必要か？ の合意が取れないとオープンフォーマット化しても意味が無いというのはあるのだが。
なので、ExcelかJSONが出力できればええやろという感じになる。
僕は記憶力が良い方ではないし頭の回転も良くない。そんな自分でも理解が簡単なコード、安全に扱えるクラスを作りたいと思って設計の道に進んだ、というのはあると思う。もし僕がなまじ記憶力が良くて頭の回転が良かったら設計になんか頼ってなくて、難解なコード書いて悦に浸ってたと思う。
体力や頭の回転でなんとかするの、当人は脳汁出て気持ちいいんだろうけど、後から引き継ぐハメになった人は地獄である。
これを書いたお前が責任持って死ぬまでメンテナンスしろやと言いたくなった事多数である。
我、プログラミング言語やライブラリ、ミドルウェア系はセマンティックバージョンでいいと思うけど、SasSとして提供してるアプリケーションなんかは日付とか整数の連番でいいんじゃねと思う派閥。
SaaSなんかはユーザー側にバージョンアップしないという選択肢は原則無いので、メジャーバージョン・マイナーバージョンを通知する意味が無い。
それならむしろリリース日をバージョンとした方がわかりやすいのでは？ 感ある（ver20220426-1みたいな）。
Quarto® is an open-source scientific and technical publishing system built on Pandoc
・Create dynamic content with Python, R, Julia, and Observable.
・Author documents as plain text markdown or Jupyter notebooks.
・Publish high-quality articles, reports, presentations, websites, blogs, and books in HTML, PDF, MS Word, ePub, and more.
・Author with scientific markdown, including equations, citations, crossrefs, figure panels, callouts, advanced layout, and mor e.
Google翻訳:
Quarto®は、Pandoc上に構築されたオープンソースの科学技術出版システムです。
・Python、R、Julia、およびObservableを使用して動的コンテンツを作成します。
・ドキュメントをプレーンテキストのマークダウンまたはJupyterノートブックとして作成します。
・高品質の記事、レポート、プレゼンテーション、Webサイト、ブログ、および書籍をHTML、PDF、MS Word、ePubなどで公開します。
・方程式、引用、相互参照、図のパネル、コールアウト、高度なレイアウトなどを含む、科学的なマークダウンを作成します。
parent_idを持つデータから階層構造を作るというよくあるお題で、↓の回答がめっちゃシンプルでよかった
推奨ディレクトリ構成
<myproduct>
├── go.mod
├── go.sum
├── <env.go> <- package <myproduct>
├── <github.go> <- package <myproduct>
├── <slack.go> <- package <myproduct>
├── <myapp-1>
│ └── main.go <- package main
└── <myapp-2>
└── main.go <- package main
大量のバッチ処理の依存関係を分かりやすく整理するため Airflow や JP1 のようなワークフローエンジンを Go 言語で開発しました。
タスク同士の依存関係を YAML 形式で表現し、ブラウザ上でグラフとして可視化できます。Airflow を導入するのは厳しいが、大量の cron ジョブをなんとかしたい、というケースにおすすめです。
レビューはエンジニアの好き嫌いとか最近興味がある技術とかなどの思いの丈を語る為に提供されたしゃべり場ではなく、成果物の品質が基準に達しているかを確認する場という事が分かっていない人がホント多いなというが最近の感想。
この手のレビュアはひたすら自分の好みを語るけど、じゃあその指摘を反映させないと成果物は要件を満たせないのかというと大体そんな事はない。その指摘はどの品質要件に紐づくのかと聞くと大概明確な回答はない。代わりに”今のままでも問題はないけど…こうした方がよりいいって話”と言ったりする。
別にこれらの指摘は純粋な技術議論として変な話ではない。ただ場が違うだけなのだ。これは要は技術を議論して組み立てる場と出来た物が適切に出来ているかを判断する場というのがきちんとそのチームで定義できていない事に尽きる。事前に指摘をしたくても場がない為レビューの場が使われてしまう。
ただこの手の指摘はプロジェクト運用からすると正直進行の障害になるのも現実であるので、事前にこれらナレッジワーカーの意見を吸い上げて合意形成を事前に取る場が必要になる。その為に場を作るのはいいんだけどナレッジワーカーは基本俗にいう”つよつよエンジニア”が多いのでその運用が難しい。
書面レビューなどを使ってある程度抑制する手段もあるんだけど、これをやるとそのナレッジワーカーのチームや組織への不満度が高まる。何故かというと、この手のエンジニアは技術的な指摘がただしたいだけではなく、【自分の言葉で相手と直接対話して議論をして意見を反映させたい】のだ。
要は、以下の環境を彼らは欲している。
・技術的に語る題材が既にある
・自分で準備は必要がない
・ある程度のオーディエンス
・直接意見が言える
・指摘をしても問題のない場
これに今一番近似する場がレビューの場なのだ。書いてて思ったけどすげーわがままだなこれ。
この手の語りたいナレッジワーカーエンジニアのモチベ維持と彼らから有効な指摘を貰う為にはこれだけのコストを払う必要があるって話になる。おまけにクリティカルな指摘が来るかは運次第。そしてそれが反映されていないと"指摘したのにあいつらわかってない"とモチベが下がるリスクもある。
プロジェクト運営側からすると、本当にこれ払う対価があるのかなと思ってたりもする。なのでこの場に用意する事に対しては消極的である。ただレビューの場で暴発されても困るし。モチベを下げられても困る。なんかうまい方法ないかなぁとは思うけどなかなか見つからない。困ったもんだという話でした。
技術で遊べるのも福利厚生として必要な側面である一方、「今、それを、ここで、議論する意味は本当にあるのか...？」みたいなことをされると温度感が一致してないと即座に辞めたくなるというのはある。