タグ

ブックマーク / qiita.com/hirokidaichi (12)

  • いちいちシェルコマンド思い出せないので、ChatGPTで自然言語からスクリプトを生成するツールつくった - Qiita

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

    いちいちシェルコマンド思い出せないので、ChatGPTで自然言語からスクリプトを生成するツールつくった - Qiita
  • 開発生産性について議論する前に知っておきたいこと - Qiita

    はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「

    開発生産性について議論する前に知っておきたいこと - Qiita
  • 開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiita

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

    開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiita
    sasasin_net
    sasasin_net 2020/06/04
    会社のGitHubリポジトリ全部食わせて、リポジトリ毎と、CSV全部マージで出してみた。製品チーム毎や職能チーム毎でも出してみようと思って、リポジトリ数に心が折れたw
  • エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita

    記事は、Engineering Manager Advent Calenderの1日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ

    エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
    sasasin_net
    sasasin_net 2019/12/01
    読んだことない本が大漁
  • 100名に聞いた!エンジニアリングマネージャーの給与と責務の実態調査 - Qiita

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

    100名に聞いた!エンジニアリングマネージャーの給与と責務の実態調査 - Qiita
    sasasin_net
    sasasin_net 2019/02/26
    権限と責務の歪み
  • 日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ? 「ウォーターフォールよりもアジャイルのほうがいいのか?」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日アジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと

    日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
  • なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明

    なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
    sasasin_net
    sasasin_net 2018/12/25
    尊い
  • 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita

    権力格差が大きい国の文化圏では、権威勾配が大きくなります。また、個人主義であるほど自己主張がしやすくなるため、意見が生まれやすくなります。男性主義的であると、女性から男性への意見をしづらいと感じる社会であることを意味しています。また、不確実性忌避の傾向が高い国では新しいことや常識の外にあることを受容する力が弱くなり権威勾配が大きくなる傾向があります。 文化的権力格差 Q. あなたの職場では職位を尊称として使うか?たとえば、「〜〜部長」「〜〜課長」など。年少の同僚を「〜〜くん」や呼び捨てするなどの傾向はあるか? Q. あなたの職場では上長の発言に疑義があっても明確な理由がなければ、反論すべきでないという風土があるか? Q. あなたの職場では年齢が若い人は年齢が上の人の意見に反論すべきでないという風土があるか? 年齢や権威に対してものが言えなくなる文化が強い場合、実際の職位の乖離を大きな権威勾

    心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita
  • 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita

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

    2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
  • 片手間のJavaScriptから脱出するためにこれからのWebエンジニアが理解すべきこと - Qiita

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

    片手間のJavaScriptから脱出するためにこれからのWebエンジニアが理解すべきこと - Qiita
  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
  • MVCの流れを簡単にまとめてみる - Qiita [キータ]

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

    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • 1