TDD Boot Camp(TDDBC) - FrontPageTDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。 各地のコミュニティの方々が中心となって、全国各地で行われています。
サバイバルTypeScriptのGPTsを作成・公開しました
サバイバルTypeScriptは有志で執筆を進めているTypeScriptのOSSドキュメントです。 今回、サバイバルTypeScriptのドキュメントをベースにTypeScriptに関する質問に答えてくれるGPTsを作成・公開しました✨ この記事ではGPTs公開の背景や作成手順、現状の課題などをまとめています。 GPTs公開の背景 LLMによるドキュメント検索は近い将来（既に？）一般的になると思い、サバイバルTypeScriptでも実験的にチャットボットでの情報アクセスを作成・公開しました。 ドキュメントの情報アクセスの課題 ドキュメントが多くなると、目次やサイトマップ、サイト内検索だけでは必要な情報にアクセスするのが困難になる。 チャットボットのメリット 雑な質問でも意図を汲んで、知りたい情報にアクセスしやすい 内容を要約して説明してくれるので、手軽に情報にアクセスできる 回答の信頼性
Microsoft Teamsで(Bot frameworkを使わずに)ボットを作るには
Microsoft Teamsの連携はSlackと比べると本当に使いづらい。 過去にQiitaで書いてたように、たとえばユーザメッセージを投稿するだけでも管理者の承認が必要だ。 今回は、Slackだと一瞬でできるボットユーザの作成がMicrosoft Teamsだとどのように達成できるかを書いてみる。 本当に骨が折れる。Microsoft Teams使いたくない。 そもそもボットが必要か？ たとえば GitHub ActionsからMicrosoft Teamsへデプロイ完了通知をしたい 定期リマインダーをMicrosoft Teamsへ表示したい とかそういう用途であれば、ボットではなくIncoming Webhookを使えばいい。（これならSlackのときと手間が大して変わらない） あるいは メンションされたら予め持っている答えを返すだけのbot アプリケーションのデプロイを受け付ける
ソフトウェア開発におけるクリエイティビティの最小化、認知負荷 - Runner in the High
前提としてクリエイティブな仕事は再現性が低い。しかし逆に言えば再現性があってはいけないものがクリエイティブであり、再現性がないからこそクリエイティブであると言える。アートのように非再現的なものはクリエイティブであり、再現性が低く刹那的な成果物であることに意味がある。 ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。 ここで言うクリエイティビティの有無とは本質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術
技術力のボトムライン、技術的負債 - Runner in the High
実際の現場に現れる負債とかクソコードとか呼ばれるものは、簡単にできるはずのものが何十にも不必要な複雑性でラップされた成果物（標準ライブラリ相当の実装を自前で全部書いていて、かつエッジケースでバグだらけ、とか）であることが多い。しかし一方で、そもそもの実現したいこと・あるべき仕様のレベルである程度複雑性が仕方ないケースに対して、最短ルートで立ち向かったものが技術的負債扱いになってしまうこともある。 かつて、某データフォーマットプロトコルで外部のアイデンティティプロバイダとデータ連携を行う機能を開発したことがあった。 さすがに1からRFCに沿って自分で全部作るのはおかしいに決まっているので、Githubで使えそうなOSSライブラリを探していたのだが、その際に見つけたものは90%は欲しい機能があるものの残り10%ほど必要な機能が足りていなかった。そこまで使えるなら、あとは自分らでフォークして足り
ChatGPT for Developer - Promptのチカラ
ChatGPT がアプリケーションに最初に組み込まれたのは GitHub Copilot かもしれません。ここでは、ChatGPT そのものと、GitHub Copilot の双方を使って、アプリケーション開発を爆速させ、品質を少しでも向上させ。そして、Developer の皆さんのスキルを上げていくための入り口として、機能の概要を取り上げます。 内容: - Promptだけで出来るコト: 業務で使うために抑えておくべきポイント。データ・変換・抽出 - PromptのEngineeringへの適用: 企画から要件定義、設計、実装、デプロイも。 - 開発の生産性と品質をあげるための戦略: Prompt自身の現在の能力、チーム開発に向けて サンプルのPrompt: https://github.com/dahatake/ChatGPT-Prompt-Sample-Japanese/tree/m
GitHub Actions で簡単にバージョン番号付きリリースとリリースノートを作成する方法
対象読者判定フロー 以下の質問にはいかいいえで答えてください。 Q1: GitHub を使用していますか？ はいの方→次の質問に進んでください。 いいえの方→対象外です。すみません。 Q2: ソースコードなどの変更は全てプルリクエストで行って（＝master/main 直コミットはしていない（多少ならOK））いますか？ はいの方→次の質問に進んでください。 いいえの方→まずはプルリクエストベースの開発に切り替えてみてはいかがでしょう？ その後で続きを読んでください。 Q3: リリースノートをちゃんと書いていますか？ はいの方→基本的に対象外です。継続して書いていって下さい。楽をしたいと思ってる場合は続きを読んでください。 いいえの方→あなたは対象読者です！ この記事を読んで、お手軽自動生成でも良いのでリリースノートを作成しましょう！ はじめに 公開しているソフトウエアにバージョン番号を付け
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
きれいなコードを書けという話について - Software Transactional Memo
前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪
たくさんセキュリティチェックシートを書いていて悟りが開けそうなので途中経過を書いてみる - Qiita
セキュリティチェックシートって大変ですよね 「契約締結目前で、今日もらったチェックシートを3日後までに出せば決まりです！」 「これNGだと契約できないんですけどなんとかならないですか？」 「（書いてもらったシートをレビュー中）え！？これOKじゃなくてNGですよ！？」 「書き始めたら8時間以上かかってるんですけどこれ無償対応なんですか・・・？」 っていうことありませんか！？ない！？良かったですね！！（血涙） ということで、結構セキュリティチェックシートで苦労しています。 過去にISMS認証を取得したときには「これでちょっとは楽になるな！よかった！」と思ったもんですが、 大きく楽になった感じはありません。 といっても、セキュリティチェックシートは次々来るので、なんとなく悟りが開けてきました。 ということで、道半ばではありますが、 そもそもセキュリティチェックシートってなんだっけ？ なんで苦労し
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)
Alistair Cockburn による Hexagonal architecture の翻訳です。PoEAAで言及されていることから、2002年ごろにはすでにC2 Wikiにページがあった模様。似たようなアーキテクチャである クリーンアーキテクチャ も翻訳したので参考にしてください。 この記事は著者から許可を得て公開しています。Thanks to Alistair Cockburn! 目次 パターン: Ports and Adapters (構造に関するパターン) 意図 動機 解決法の本質 構造 サンプルコード ステージ1: FIT アプリ 定数をモックデータベースとして ステージ2: UI アプリ 定数をモックデータベースとして ステージ3: (FITまたはUI) アプリ モックデータベース 応用ノート 左右の非対称性 ユースケースとアプリケーションの境界 ポートはいくつ? 既知の用
API テクニカルガイドブック - 政府CIOポータル
API テクニカルガイドブック β版 平成 29 年 8 月 1 日 内閣官房情報通信技術（ＩＴ）総合戦略室 1 【目次】 １ 経緯及び目的..............................................................................................................................................................3 ２ API 設計時の留意事項...........................................................................................................................................4 ２．１ URI 設計及びリクエ
au PAY、ポイント基盤を刷新 “脱COBOL”実現【訂正あり】
KDDIが、キャッシュレス決済サービス「au PAY」とポイントサービス「au Ponta ポイントプログラム」のシステム基盤を刷新し、データベースに「Oracle Database」などを導入したと、日本オラクルが3月1日に発表した。会員数の増加やキャッシュレス決済の浸透を踏まえ、可用性向上などを目指して移行したという。同時にコードをCOBOLからJavaに切り替えた。 同社は両サービスをオンプレミスで運用している。しかし会員数が増え、扱うデータ量が増えている他、新サービスの開発スピード向上が求められていることから刷新に踏み切ったという。Oracleのサービスを採用したのはJavaとの相性などが理由としている。 基盤の刷新に当たっては、データベースサービス「Oracle Database」やデータベース間の移行・同期をスムーズにする「Oracle GoldenGate」などを採用。新基盤
システム開発はなぜこうも｢失敗｣を繰り返すのか
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
機能は追加すればいいというものではない
みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上
システムの保守には修繕計画が必要という話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 ソフトウェア開発（特にWebアプリケーション開発）に携わっていると「レガシー」という表現をよく聞きます。でもよくよく考えてみると、ソフトウェアは放っておいても腐りませんし、錆びてしまうこともありません。しかし現実問題として、ソフトウェアは放っておくと否応なく「レガシー化」します。どうしてそうなってしまうのでしょうか。 （「レガシー」それ自体は悪い意味の言葉ではないはずですが、不思議とソフトウェア開発の文脈だとよくない意味合いの方が強くなってしまいますね…。） レガシー化する理由とその対策 動いているソフトウェア自体が変化しなくても、周りの環境が変化します。OSのバージョンが上がったり、その上で動いているミドルウェアが変わります。また、最近だとクラウド環境を利用することが多いので意識することが減りましたが、ハードウェアも新しいものがどんどん出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースらしくソフトウェアを設計する
