いちいちシェルコマンド思い出せないので、ChatGPTで自然言語からスクリプトを生成するツールつくったPythonOpenAIChatGPTlangchain はじめに ChatGPT APIが出たので早速さわってみました。せっかくなので何か便利なものをということで自分向けに使えそうなツールをつくっていたら 良いかんじに動作したのでご紹介します。 つくったものは、「ChatGPTを用いた自然言語によるシェルコマンドランチャー」です。百聞は一見にしかずと言うことでまずは動作するところをみてください。 概要 wannaコマンドは、ChatGPTを用いた自然言語によるシェルコマンドランチャーです。自然言語によって、bash scriptを生成し、名付けし、管理できます。 コマンドライン上での操作は簡単に多くのことを行うことができるため、非常に便利です。しかし、多くのコマンドやオプションの組み合わ

はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。 本稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、git logの

はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて

はじめに ソフトウェアエンジニアリングマネージャ（以下、EM）に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日本型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ（会社を変えても有効であると思える程度）が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ

はじめに 本稿は、拙書のエンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリングに関する参考となる書籍を企画意図とともにあげていく試みです。できる限り、専門書ではなく平易な文体の書籍を参考としてあげていきますので、このあたりを深掘りしたいなと思ったら、その箇所のみの参考書籍を併読していただけるとより理解が深まると思います。 Chapter 1　思考のリファクタリング 第１章は、「仕事」と「学力テスト」という２つの違いを論じながら、１６世紀から２０世紀初頭にいたるまでの科学哲学の歴史を辿っていくというのが「裏テーマ」となっています。そこから、「知識を得る」とは何かということを浮き彫りにし、それこそが<エンジニアリング>であると論じるということが本書を通じた論理展開の骨子です。 そのため、直接の参照ではありませんが、科学という概念が西洋社会でどのように生まれてきたのかとい

はじめに Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 本記事では、そのなかで触れている二人の人物がパーティのためにカレーを作るという話を紹介します。きっとどこかで見たことのあるコミュニケーションが繰り広げられていると思います。このカレー作りの寓話から、コミュニケーション能力の正体に迫っていきましょう。 パーティに来るみんなのためにカレーを作りましょう。そう言って、ボブとエバは2人でカレーを作り始めた。 ボブは、どんなカレー

デリゲーションポーカーを作った プランニングポーカーみたいに権限委譲を促進するカードゲーム、「デリゲーションポーカー」をいきおいでつくった。さらにLINEスタンプも作った。 カードゲーム販売ページ LINEスタンプ販売ページ デリゲーションポーカーの元ネタはこちら参照 権限と責任の話 経営者マインドが足りない！の欺瞞 よくネットで炎上しがちなひとが「経営者マインドが従業員に足りない！」というようなアメリカ人には大和魂がない！的なそりゃそうだろとしか言いようのない言説を口にします。 この表現はさておき、このような言説を口にしてしまう背景には何があるでしょうか。このような人はきっと自分の会社の従業員にもっといろんなことを任せていきたいと思っているのでしょう。 ところが、そのような期待値をしっかりと部下に対して伝えることができていないため、メンバーも自分自身の成長のタネがどこにあるかわからずに、

はじめに 最近は年を取ってきたのか、様々な人にマネジメントの考え方やソフトウェアアーキテクチャの設計についてのメンターリングをすることが多いのですが、その時に必要なのはやはり説得力です。僕は基本的には欲望に弱い人間なので、すぐに欲望のままに行動します。それは主に知識欲と食欲です。そのため、２０歳からどんどんと太っていき、才能がないと突破できないとされる１００kgの壁も悠々と突破するような人間ができあがりました。 すると不思議なもので、声が聞こえてくるのです。 「こいつ、マネジメントとかいってるけど、セルフマネジメントできておらんやんけ」 これは全くの幻聴なのですが、そういった幻聴を聴くくらいには心に内臓脂肪が溜まってきていました。 そんなタイミングと「胃痛を空腹と勘違いし回鍋肉を食べた結果、胃痛が加速する」という経験を経て、ちょっくらダイエットでもして見るかと考えるようになりました。 さて

原文：http://npf.io/2014/10/why-everyone-hates-go/ 酔っぱらった勢いで訳出してるので、違ってたら修正リクエストください。 訳者の１行でわかるサマリ それって、Goのシンプルな言語哲学が、ML系言語好きのアイデンティティを挑発しちゃってるからじゃないの？ いや、実際みんなって訳じゃないんだろうけど。最近、なんてGoをみんなそんなに批判的なのかって言うquoraの質問が出たもんで。（わるい、普段はquoraへのリンクを張らないんだけど、それがこの記事のきっかけだからね。）この質問への回答を見るまえにもう、僕には、次みたいなことが書かれていることがわかってた： Goは70年代に立ち往生した言語だ Goは40年間に及ぶプログラミング言語研究の成果を無視してる Goはブルーカラーの凡夫のための言語だ Go使いはJava1.0で仕事しても大丈夫なんだろう。

はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だと思われる考え方やアプローチを抜粋して紹介するものです。言うまでもなくあらゆるコードベース、アーキテクチャにおいて有効なものとは限りませんので、各々の環境や状況から適切に判断してください。

はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指

はじめに 最近、こういった記事が世間をにぎわせている。こりゃエヴァの話なんてしてる場合じゃねぇ！と思ってさくっとこの辺の事情を理解するために必要なことをまとめてみる。 Railsが時代に合わなくなってきた Javascriptを使うのをやめろ：Railsの時代遅れ云々についての結論 昔ながらの「片手間に書くJavaScript」の限界 GoogleやTwitterでも実現できないのだから使うな問題 この話は、どの地点の何の話をしているのかよくわからないのです。現在ではかなりステップバック＆改善が行われ、Safari自体のクラッシュはアプリのクラッシュと比べて、あまり多いとは思いません。むしろ、一昔前に比べてかなり改善しているという認識です。iOSのバージョンが古いとかでなければ、現状でも十分ユーザビリティの改善につながっているでしょう。 しかし、この問題の結構大部分を占めているのは個人的に

まずはツールの紹介 昨今、注目を浴びているアプリケーションコンテナを作ったり管理したりできるDocker。 そろそろ中身も理解しておきたいところ。特に最近はlibcontainerというのができて、lxc依存すら切り離されているとの噂。 ただ、結構ソースコードの量も大きくなっているので（2014/4月現在 テストコード除いて70000行弱）、 さっと大まかに理解するためのツールを書いてみました。 このツールはgoのastからパッケージの間の依存関係を読んで、graphvizの解釈するdot言語に吐き出すツールです。 たとえば、最近話題のgo-xslateの全体像をつかもうと思ったら、 のようにすることで、 拡大 こんな感じにパッケージ間の依存関係を図示することができます。 これだけでも何となくどんな構造になってるかわかってきそうですね。 不安定性の表示 govizにはdot言語の出力の他に

はじめに 全国１億２０００万人のエヴァンゲリオンはわかるけど,JavaScriptはちょっと、、、な皆さんこんにちは。 JavaScriptのプログラミングは、エヴァンゲリオンよりは簡単なのですが、なぜかプログラマにしか浸透しません。 エヴァンゲリオンの諸概念を理解している方であれば、すでにJavaScriptプログラミングは理解していると言っても過言ではありません。 そのあたりをそういうことにして、本編にとりあえず行きましょう。 あわせて読みたい 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 1.地球とミックスイン まずは、エヴァンゲリオンの世界における地球をJavaScriptで表現してみたいと思います。 ここで登場するのはもちろんエヴァンゲリオン世界のトリックスター、ナディアと我らをつなぐものこと「第一始祖民族」ですよね。 彼らは隕石に「白き月」と「黒

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 この記事について この記事は、新人向けの研修内容を再編集してお送りします。 この記事の内

理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア

システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 最近、メンター制度として新入社員や若手のメンバーに対して、先輩をつけて相談事に乗ってあげたり、仕事のサポートをしたりといったような教育プログラムを組む企業が増えています。このメンターという役割は、ちょっとした訓練が必要だったりするのですが、このあたりの研修や訓練をせずにいきなり明日からメンターね！なんてことがままあります。

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ