最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
静的サイトジェネレータ「Astro 3.0」正式リリース。JavaScriptなしでSPAのようなアニメーションの画面遷移など新機能
静的サイトジェネレータ「Astro 3.0」正式リリース。JavaScriptなしでSPAのようなアニメーションの画面遷移など新機能 オープンソースで開発されている静的サイトジェネレータ「Astro」の最新バージョンとなる「Astro 3.0」が正式にリリースされました。 Astro 3.0 is out now! 30% faster and more powerful than ever. View Transitions, Image Optimization, JSX Fast Refresh, and so much more. https://t.co/vOi44246Hg — Astro (@astrodotbuild) August 30, 2023 Astroは、ReactやVue、Svelte、Alpine.js、TypeScriptなどのさまざまなフレームワークやライ
PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra
この記事は「Funds Advent Calendar 2022」21日目の記事です。 ファンズ株式会社 CTO の若松と申します。 今年も例年通り Twitter の運用は三日坊主となり、 note についても筆を断ったまま2022年を終わりを迎えようとしていたところ、アドベントカレンダーの時期が来ていました。 せっかくの機会ではあるので、以前から漠然と思っていた考えを整理してみたいと思い、この記事では財務諸表を読み解く概念的な考え方を使い、技術的負債について読み解いてみることにしました。 ソフトウェア開発上の概念である"技術的負債"ファンズは、貸付ファンドのオンラインマーケット「Funds」を通じて、個人投資家には着実な資産運用の機会を提供しつつ、企業に対しては借入によるファイナンスの機会を提供しています。そのような事業業態の性質上、コーポレートファイナンス的な考えに触れる機会も一般的
文章でリストを表示（少し詳細あり） fix: バグ修正 既存の機能の問題を修正する場合に使用します。 hotfix: 緊急対応 稼働中のシステムのバグ修正など、緊急性が高い修正を行う場合に使用します。 add: ファイルや機能の追加 新しいファイルや機能を追加する場合に使用します。 feat: 新機能・新規ファイル追加 新しい機能やファイルを追加する場合に使用します。 update: 機能修正 既存の機能に問題がなく、ただし修正を加えたい場合に使用します。 change: 仕様変更による機能修正 仕様変更により、既存の機能に修正を加えた場合に使用します。 clean・refactor: リファクタリング コードを修正し、改善する場合に使用します。 improve: コードの改善 コードの改善をする場合に使用します。 disable: 機能の無効化 機能を一時的に無効にする場合に使用します。
リファクタリングはエンジニアの福利厚生であり管理指標への影響はほとんどないんでは - きしだのHatena
おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。 工数としてはコード管理費みたいな感じで乗せるのがよさそう。 まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。 なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。 ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性か
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
Googleのソフトウェアエンジニアリング
Googleの現役ソフトウェアエンジニアたちが、超大規模ソフトウェアの開発と保守を長期的に支えてきたGoogle社内の多様なベストプラクティスを、文化、プロセス、ツールの側面からこの一冊に凝縮。時間と変化、規模と成長、トレードオフとコストという3つの基本原理に沿って、コードを持続可能にする方法論を紐解きます。「謙虚、尊敬、信頼」、心理的安全性、ダイバーシティとインクルージョンなど公正を重んじる文化から、コードレビューやテスト構成法など人間の行動を規定するプロセス、継続的インテグレーションや大規模変更システムなど変化への対応を支援する自動化ツールの基盤技術まで、Googleが試行錯誤を経て獲得した教訓を余すところなく紹介しています。経済学、心理学、マネジメント論などを背景にした人間への深い洞察をふまえ、データ駆動かつトレードオフから導かれる、定量的かつ定性的な決定プロセスも解説。Google
歴史・年表でみるAWS全サービス一覧 －アナウンス日、General Availability(GA)、AWSサービス概要のまとめ－ - NRIネットコムBlog
小西秀和です。 Amazon Web Services(AWS)に関する情報や魅力を様々な観点から記事にしてみていますが、技術史が好きなこともあって今回はAWSサービスの発表の歴史を年表でまとめました。 AWSからもWhat's Newとして公式アナウンスは発表されていますが、アナウンス日、GA日(一般提供開始日)、サービス名、サービス概要といった情報に圧縮して時系列でAWSサービス一覧を一枚もので確認できる記事が今まで欲しかったので自分で作成してみることにしました。 AWS全サービスの歴史年表の作成方法 AWS全サービスの歴史年表の対象となるAWSサービスは次の手順で選定しました。 AWSサービス・製品一覧「Cloud Products(英語版)」にあるサービスのうち「～ on AWS」といったサードパーティー製品がメインとなるサービスを除いたリストを作成 AWSサービス・製品一覧に記載
2000年代オブジェクト指向は絶対の正義だった。つまり僕は洗脳を経験している - レベルエンター山本大のブログ
私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ
Sansanは10月25日、テストコードについての研修資料を無料公開した。4月に実施した新卒の技術研修で使った資料の一部で、入社2年目の社員が作成。Pythonのテストフレームワーク「pytest」でのテストコードの書き方や、VSCodeでのテスト方法などを解説している。 同社はテストコードの便利な点として「実行確認しやすい」「リファクタリングや修正後に実行結果や振る舞いが変わっていないことを確認できる」「コードの挙動が理解しやすい」を挙げる。テストコードの重要性を理解し、テストコードを活用できるようになることを目的に研修を行ったとしている。 関連記事 新卒向け「統計学の基礎」100ページ超 SaaS企業が無料で資料公開 ブレインパッドが、新卒研修で使った統計学の学習資料を公開した。統計学の基礎を解説したもので、ページ数は100ページ超。スライド公開サービス「Speakerdeck」から無
Webエンジニアとして個人的に大事だと思ってる、ノウハウ・心構えについて【前編】｜Offers Tech Blog
はじめに こんにちは！Offers を運営している株式会社 overflow の バックエンドエンジニアの takkun7171 です。 エルデンリングをクリアして、Apex のランクを再開したところ、 初のソロダイヤを達成しますた。齢 40 過ぎのオッサンでも、やればできるんだから！！w さて、技術ブログなんですが、今回は技術というよりも Web エンジニアとして個人的に大事だと思ってる、ノウハウ・心構えについて 書いてみようかなと考えてます。 初心者向けというわけではないのですが、 4 月ですし、新人エンジニアの方も増えるということで 初心者の方にも読んで頂きたいです。 そこそこ分量があるので、前後編に分けて、 前編はハードスキル中心、後編はソフトスキル中心で書いてみます。 後編の記事 自分はマネージャーでも CTO でもなく一介のエンジニアでしかありませんが、 Web エンジニア歴は
技術blogのリンクを投げたらChatGPTが要約して、いい感じに整形してチャンネル投稿してくれるbotを社内Slackに生やしたら捗った話
こんにちは、株式会社シグマアイのエンジニアの@k_muroです。 今回の記事は最近導入した「技術blogを良い感じに共有してくれるSlack bot」のご紹介を。 はじめに 技術の進化は止まらない。(真面目な話、AI系の進捗がマジですごいて全然追えない) 毎日のように新しい技術、フレームワーク、ライブラリ、ツールが生まれています。そんな中でエンジニアとして働いていると、この情報の波に疲れを感じること、ありませんか？ ありますよね？(脅迫) 実際私もその一人で、この小さな疲れが積み重なって大きなストレスとなることに気づきました。 「新しい技術情報、追いつけるかな？」 「あのブログ記事、後で読もうと思ってたのに、どこいったっけ？」 「チーム全員が同じ情報を持ってるか心配だな。」 そんな日常の疑問や不安から逃れるための一歩として、私はあるSlack botを開発しました。このbotは、送られた技
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
はじめに 1年半ほどObsidianというノートアプリを使い、Qiitaにも記事を３つほど公開をしていました。 効率的に成長するためのデジタルノート術(Obsidian x Zettelkasten(LYT Framework)) コーディングのようにノートを取る技術 がんばらないObsidianノート術 確かにNotionやEvernoteとは違う感覚のノートアプリであり、双方向リンクを利用したグラフで繋げていくノートに当時は感動を覚えました。 その反面、Obsidianを百パーセント有効に活用できていたかと聞かれると「はい」と答えることは難しいと感じています。がんばらないObsidianノート術の記事はまさにその一角であり、Obsidianの拡張性と自由度に翻弄されてしまわないように書いた記事です。 1年半を通して紆余曲折した中、先日新しいツールとの出会いがあり、自分に合うツールを見つ
こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開
2020年12月7日に更新 最近の事情 UIWebViewの完全廃止 UIWebViewはiOS8以降に非推奨になっていたが新規アプリの申請を終了する予定でした。2020年末以降に延長した。今のところ未定となった。 WKWebViewに移行しなければいけない。依存しているライブラリに組み込まれている可能性があるので、今一度確認した方がいいだろう。iOS15では完全に使えずに実行時にクラッシュになるかもしれない。 developer.apple.com Apple Push Notification Serviceのアップデート 古いプッシュ通知の方法が使えなくなる。2021年3月31日に延期になりました。新しいプッシュ通知の方法を使うように切り替える必要がある。 developer.apple.com Xcode12でのビルドが必須 2021年4月末からXcode12でのビルドする必要があ
「自動テストとテスト駆動開発、その全体像」を執筆しました（Software Design 2022年3月号） - t-wadaのブログ
【更新】寄稿した記事が Web に公開されました 技術評論社様のご厚意により、 Software Design 2022年3月号に寄稿した「自動テストとテスト駆動開発、その全体像」が gihyo.jp にて公開されました。誠にありがとうございます！ gihyo.jp はじめに 2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。第1章では、混同されることの多い自動テスト関係の概念を自動テスト、テストファースト、テスト駆動開発（TDD: Test-Driven Development）の3つの段階に分け、それぞれの効果や注意点を包括的に整理整頓しています。 ソフトウェアデザイン 2022年3月号 作者:大竹 章裕,瀬戸口 聡,庄司 勝哉,光成 滋生,
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） - outsider reflex
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « 「同調圧力は忌むべきものだ」と思考停止していたことに気付いた話 Main 「なぜMozillaはXULアドオンを廃止したのか？」に寄せられていた反応を見て、「甘い……甘すぎる……」と思って、W3C信者時代からの価値観に行き着いた話 » なぜMozillaはXULアドオンを廃止したのか？（翻訳） - Aug 22, 2020 （原著：David Teller, 2020年8月20日、CC BY-NC 4.0で公開されている内容の全訳。Qiitaにもクロスポストしています。） 要約：Firefoxはかつて、XUL
マイクロソフト、Javaの開発環境をまるごとインストールしてくれる「Visual Studio Code Installer for Java」公開。VSCode、JDK、テストランナー、デバッガ、依存関係ビューア、IntelliCodeなど
マイクロソフト、Javaの開発環境をまるごとインストールしてくれる「Visual Studio Code Installer for Java」公開。VSCode、JDK、テストランナー、デバッガ、依存関係ビューア、IntelliCodeなど マイクロソフトは、Windows上にJavaの開発環境をまるごとインストールしてくれるツール「Visual Studio Code Installer for Java」をリリースしました。 「Visual Studio Code Installer for Java」は、コードエディタのVisual Studio Codeを中心に、Javaの実行環境、テストランナー、デバッガ、依存関係ビューア、コード補完をしてくれるIntelliCodeなど、Javaアプリケーションの開発を支援するツール群を一括してインストールしてくれるというもの。含まれているも
本編開始は 19:05 からです こちらのイベントのYoutubeLive配信のアーカイブです https://tddbc.connpass.com/event/183044/ チャプター 0:00:00 準備開始 0:19:05 講演開始 0:41:55 ライブコーディング開始 0:57:20 プログラミング開始 1:02:00 最初の RED ？ 1:19:00 fake it 1:26:50 最初のリファクタリングおわり 1:36:40 質問タイム 1:51:20 5の倍数に着手 1:53:40 前半のデモのまとめ 1:55:20 質問タイム2回目 1:56:45 リリースから3年後の世界（テストをメンテナンスしやすくする） 2:14:20 テストの構造化とリファクタリングの説明
はじめに みなさん形式手法をご存知でしょうか？ 名前くらいは聞いたことあるけどいまいち何かわからないという方が多いのではないでしょうか。 その通りです。形式手法はアカデミアではそれなりに研究されているものの、 一般の（特にWeb系）ソフトウェア開発者が携わることはなかなかないのではないかと思います。 この記事ではソフトウェア開発に形式手法が導入されないのはなぜなのかを考察します。 この記事ではアジャイルソフトウェア開発において形式手法を導入する際のハードルについて考察します。 追記 本記事について、「形式手法は流行っていない」というのは正確ではないのではないかという指摘をいただきました。組み込み系や社会インフラ系等バグを絶対に出せないシステム開発では形式手法がよく使われているそうです。 ちょっと古いデータですが活用事例です。 誤解を招く紹介となっていたことをお詫びします。 さらに追記 ku
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
時雨堂は何をしている会社なのか
大変反省したので、何をやっていて、どんな会社なのか書いていきます。知ってもらうためにも定期的に更新していければ思っています。 まとめ零細企業リアルタイムな音声と映像を扱うミドルウェア製品を作って売ってるミドルウェアのクラウド版を作って売っているサブスクリプションモデルの積み上げ型OSS 重視何をやってるのか時雨堂はミドルウェアソフトウェアをパッケージとして開発、販売しています。最近は「リアルタイムな音声と映像、データの配信」に特化したミドルウェアがメインです。 現在の主力製品は WebRTC SFU Sora (以降 Sora)という本来は P2P で利用する WebRTC を、クライアント・サーバー方式で利用するソフトウェアを1 から開発して、販売しています。売上のほとんどはこの製品関連になります。 製品はサブスクリプションを採用しており、 3 ヶ月、6 ヶ月、 12 ヶ月単位で Sor
本記事はドメイン駆動設計(DDD) Advent Calendar 2021 25日目の記事です。 「もっとビジネス変化に耐えられる設計を目指したい」「ただデータをやりとりするだけなのに複雑化してしまうのを防ぎたい」 様々な動機からドメイン駆動設計に入門しようとする方がいると思います。 自分もエンジニアとして働きはじめて、「どうしてすぐに変更しにくくなってしまうのか」「より柔軟な設計にするにはどうすればよいか」と悩むことが多くなり、良い設計手法を探って出会ったのがドメイン駆動設計でした。 最初はドメイン駆動設計関連の本ばかりを読んでいたのですが、途中から「これってドメイン駆動設計というよりはオブジェクト指向の話では？」とオブジェクト指向に興味を移し、さらに「より変化に強いプロダクト開発するにはチームから変化させないとまずいのでは？」とアジャイル開発に興味が移りました。 本記事では、ドメイン
大規模リファクタリングの極意
iOSDC 2021 での登壇資料となります。 登壇内容 https://www.youtube.com/watch?v=yWO47AFkDls 以下、スライド内に登場するリンク一覧です。 MoT Teck Talk vol.3 「タクシー配車ならではの技術が盛りだくさん！iOSアプリの開発現場」 https://www.youtube.com/watch?v=KwaMV7-uMdI 不要なコードを検知して PR にコメントする Danger プラグイン https://github.com/imairi/danger-detect_unused_definition xcode-select の自動切り替えツール https://github.com/klaaspieter/chxcode RIBs アーキテクチャのボイラープレート自動生成 + 依存解決ツール https://githu
こわくないTypeScript〜Mapped TypeもConditional Typeも使いこなせ〜 - uhyo/blog
TypeScriptの型システムは、ユニオン型を始めとする様々な機能を持っているのが特徴的です。 その中でも、mapped typesとconditional typesは高度な機能として知られています。 ところが、その機能の膨大さゆえ、全てを使いこなす必要はない、TypeScriptの複雑な機能を無闇に使うべきではないという言説はたびたび現れます。 そのときに槍玉に上がりやすいのがmapped typesとconditional typesなのです。 筆者は、これらの機能は使えるだけ使い倒すべきであるという考えを持っています。 主張の根幹には、高度な型を使えばより正確にインターフェースを記述することができること、そして正確なインターフェースは使いやすさや正確な型推論結果に貢献することがあります。 正確なインターフェースや型推論結果は、コードの理解速度や開発効率を促進します。 これらは型シ
必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす
0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み｜ハイクラス転職・求人情報サイト AMBI（アンビ）
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み 大規模なソフトウェア開発においてモノリシックかマイクロサービスかというアーキテクチャの議論がありますが、近年は第3の選択肢としてモジュラモノリスが話題になっています。いったんマイクロサービス化に舵を切りながら現在はモジュラモノリスに取り組むアソビューの考え方や進め方について、VPoEの兼平大資（disc99）さんによる寄稿です。 アソビューでは、現在の事業状況にマッチしていることや過去の経緯から、モジュラモノリスを中心としたアーキテクチャを採用しています。 今回は、なぜその選択をし、どのように実現しているかを紹介します。 記事の前半では、アソビューが提供する事業や、アーキテクチャに対する考え方、開発組織の歩みなどを説明します。 中盤以降は、アソビューにおけるモジュラモノリスへの取
業務アプリケーション開発にGoを採用する理由
この記事は MICIN Advent Calendar 2022 の24日目の記事です。 前回は熊沢さんの２つの新規事業立ち上げで経験したタイプ別MVP検証の進め方でした。 はじめに 本記事では、業務アプリケーションのバックエンドとしてGoを採用することによるメリットを、実際の業務経験を振り返りつつ考察してみます。 近年では多くの企業でGoが採用されています。その採用理由は、「並行処理をたくさん行いたいから」「学習コストが低いから」「フットプリントが小さくコンテナベースのプラットフォームに向いてるから」「Googleが使ってるから」「高速だから」といったところが挙げられるんじゃないでしょうか。 一方で、単なるモノリスなAPIとしてGoを選ぶ必要はないんじゃないのか、といった声もよく聞きます。「初期フェーズはスピード重視でRuby on Railsが最強だ」「枯れた技術であるJava + S
テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
以前noteに書いた記事からの転載 エクスポートできないので、定期的に少しずつ転載していきます。 いつかちゃんとしたスライドに書き起こしたいとおもいつつ、まだ手がついていないけど、この記事に書いている「プログラミングは、コードと、データと、改修の歴史の3つの要素が絡み合う」を分解していきたい。 コードと、データは本質的には不可分だし、その結びつきを分解できないように密に結合させているのが、改修の歴史なんだ よく「データの寿命はコードよりも長い」と言われるけど、受け継がれたデータは、当たり前だけどそれが作られた当時のコードに強い影響を受けていて、不可分だし、暗黙のうちにコードの特性を引き継いでいる。 つまり、例え直接的にはコードが無くなったとしても、コードの影響が無くなるわけではない。 そして、それらの蓄積が歴史となって、全体を形作っていくんだ。 だから、データとコードの寿命は同じくらい長い
最近の開発者が最も好むドキュメント形式を挙げるとしたら断然マークダウンになるでしょう。マークダウンは、GitHub、GitLab、Bitbucketなど、タスクやイシュー管理に対応するほとんどのサービスにおいて、基本のドキュメント形式として使用されています。また、IntelliJ、VSCode、Vim、Emacsなど、ほぼすべてのテキスト編集ツールでも、プラグインを通じてマークダウン文書の強調構文やプレビュー機能を使用することができます。 TOAST UI Editorはここからさらに一歩進んで、マークダウンエディターとウィジウィグエディターを統合した形式のインターフェースを提供しています。ウィジウィグエディターを使用すると、テーブルなどの複雑な文法をより直感的に簡単に編集することができ、マークダウンに慣れていないユーザーでもマークダウン基盤の文書を簡単に編集できます。特に、開発者と非開発
「偉大な書籍は偉大な出だしで始まる。ケント・ベック著『テスト駆動開発』(2003, 2017)はこう始まります。 「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。 」 テスト駆動開発エバンジェリストとして活躍している、和田卓人さん(t_wada)の講演より引用 セミナー講師やアジャイルコーチの立場で、私もTDDを教えることがよくあります。そんなときはこの言葉を意識しつつ、TDDはあくまでスキル、手法のひとつに過ぎず、本当に求めるべきは動作するきれいなコードなのだと、伝えるようにしています。そのことを説明する補助として、こんな図を作りました。 絵を描いてみて気づいたのですが、「動作する(Works)」には2つの側面があります。書いたコードが、書いたつもりの通りに動くこと(Verification)と、期待に応えて働き実際に役立つこと
はじめに 対象イベント 読み方、使い方 Remote Code Execution(RCE) 親ディレクトリ指定によるopen_basedirのバイパス PHP-FPMのTCPソケット接続によるopen_basedirとdisable_functionsのバイパス JavaのRuntime.execでシェルを実行 Cross-Site Scripting(XSS) nginx環境でHTTPステータスコードが操作できる場合にCSPヘッダーを無効化 GoogleのClosureLibraryサニタイザーのXSS脆弱性 WebのProxy機能を介したService Workerの登録 括弧を使わないXSS /記号を使用せずに遷移先URLを指定 SOME(Same Origin Method Execution)を利用してdocument.writeを順次実行 SQL Injection MySQ
Learn Go with Tests: テスト駆動開発を体験しながら Go を学ぼう - kakakakakku blog
TDD（テスト駆動開発）を体験しながら Go を学べる学習コンテンツ「Learn Go with Tests」を紹介する❗️全てのコンテンツを実施してみて，非常に良かったのでまとめることにした💡 Go に入門できる TDD のサイクル (Red / Green / Refactor) を体験できる コンテンツは "35種類" もある 無料で学べる GitBook (GitHub) に公開されている 日本語対応 英語版 📚 quii.gitbook.io 日本語版 📚 andmorefine.gitbook.io コンテンツ一覧 なんと「35種類」もコンテンツがある❗️ Go fundamentals 🚢 21種類 Install Go（Go をインストールする） Hello, world（Hello, World） Integers（整数） Iteration（反復、繰り返し） A
はじめに HTML＋CSSコーディングにおける制作者の思考や判断、アプローチ、コード化に至るまでの流れなどを分解し、コードの状態なども含めてそれぞれを短い言葉で言語化しました。 以下のような効果が期待できます。 HTMLとCSSを使っておこなってきた事を客観視・再認識できる 始原的な動機を把握することで、手法を別の視点で捉えられるようになる 認識合わせや熟練度確認に利用し、制作時のコミュニケーションを円滑にする 場合によっては、ぼんやりと捉えていたことや、詰まりやすかったポイントなどがハッキリと認識できるようになるかもしれません。 言語化の概要 まずは、全体像が分かる概要図を掲載します。 この記事は、以下のステップと各項目について順に説明するものになります。 前提事項・環境について 言語化するにあたって前提となる考え方や環境について記載します。 HTMLとCSSの役割 HTML → データ
Qiita公式が新人プログラマ応援のイベントをやっているようなので便乗して参加してみました。 ポエム成分などを多く含みますのでご注意ください。過去のQiita公式の発表や先日のガイドライン改定に目を通してみてとりあえずはこういった記事も大丈夫そうとは判断しておりますが、もし怒られたら削除するか別のところに記事を引っ越しいたします（はてブコメントなどで「こんな記事Qiitaに書くんじゃない」とご指摘いただきそうで戦々恐々としながら書いています）。 本記事で触れること 長く現役でいるために大切な睡眠・運動・食生活などのこと。 習慣化のこと。 勉強のこと。 今までどのくらいエンジニアをしてきたか 私自身はエンジニアのお仕事は10年くらいです。高校生のころ辺りから少しはHTMLやjsのコードを書いていたのでコードを書いてきた期間としてそこからカウントすると17年くらいでしょうか。デザインの学校を出
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDDはゆるく実践しても大丈夫 - 千里霧中
20年でソフトウェア開発の景色はどのぐらい変わったのか？ - Qiita
財務諸表というフレームワークで考えるソフトウェア開発と技術的負債｜Yoshinobu Wakamatsu
Gitのコミットメッセージの先頭につけた方が良い単語リスト(prefix集) - Qiita
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
新卒向け「テストコード」の研修資料 Sansanが無料公開 Python上でのテスト方法を解説
知的・技術的進歩のスピードを限界まで加速するノートアプリ『Heptabase』 - Qiita
決済チームがテストコードを書く際に気を付けていること - UPSIDER Techblog
更新できなければ淘汰されるiOSアプリ - いつもあさって
TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
形式手法はなぜ流行っていないのか - Qiita
僕が考える「良いコード」 - give IT a try
ドメイン駆動設計からオブジェクト指向、そしてアジャイル開発まで。関連書籍練り歩きのススメ
チームトポロジー を読んだ - 下林明正のブログ
プログラミングを難しくする要素って何だろう - Magnolia Tech
新しいマークダウンパーサーが必要な理由 | NHN Cloud Meetup
テスト駆動開発(TDD)のゴール「動作するきれいなコード」について考えてみる - やっとむでぽん
【2020年】CTF Web問題の攻撃手法まとめ - こんとろーるしーこんとろーるぶい
HTML+CSSコーディングの言語化 - Qiita
エンジニアとして長く現役で生き残るために - Qiita