「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア - Findy Engineer Lab
日本におけるテスト駆動開発の著名人といえば誰か？ この問いを投げかけられたとき、多くのエンジニアが思い浮かべる人物がいます。ITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さんです。和田さんは日本のテスト駆動開発の第一人者として、長年、この分野の実践や講演・執筆などの普及活動を続けてきました。 こう書くと、読者のなかには「和田さんはもともとテストが好きだったから、テスト駆動開発の第一人者になれたのでは」と思われた方もいるかもしれません。しかし、その答えはNOです。むしろ和田さんは、テストが嫌いなエンジニアだったといいます。ある出来事をきっかけとして、嫌いだったテストを好きになれる方法を見つけたのです。 読者の方々にも「自分には○○なんて向いていない」という印象を抱いている技術領域があるかもしれません。ですが、そんな領域にこそ、あなたの新たな可能性が詰まっているかもしれ
OpenAPIでAPIドキュメントを初めて作るときに読む資料
OpenAPIを使ってAPIドキュメントを初めて作るときに参考になった資料をまとめました。 最初に読む資料 Swagger ではない OpenAPI Specification 3.0 による API サーバー開発 OpenAPIとはなんぞや？すこし前に話題になったSwaggerとの違いは？どのように書いていけば良い？などをざっくり頭に入れられる資料です。 スキーマファースト開発のためのOpenAPI（Swagger）設計規約 ざっくり記法が分かる記事です。OpenAPIはyamlファイルでの記述が基本ですが、後述する Stoplight Stadio というGUIエディターを使うと、比較的楽に作成管理ができます。 エラーレスポンス OpenAPIというよりAPIそのもののエラーレスポンスの設計思想についてです。 REST API Error Handling Best Practices
チーム全員が知っててほしい抽象化のこと - LIVESENSE ENGINEER BLOG
はじめまして。転職会議ユニットでエンジニアをしている狩野です。 元々PHPerでしたが、最近はRuby(Rails)やReactを触ったりして楽しくやっています。 今回は、中堅エンジニア*1が最近受けた質問とそれに対する回答を、今までのシステム開発で得た知見と併せてブログを書きたいと思います。 はじめに 最近、若手のエンジニアから「クラスとかメソッドってどう分けるんですか？」という質問を受けました。 私は「実世界をそのまま表現するだけですよ。」と答えました。 真面目に答えたのですが、若手エンジニアには全く伝わっていないようでした*2。 良い機会なので、実世界の抽象化について少し掘り下げて書いてみたいと思います。 システムとは？ 基本的に、システムは「あるドメインを体系的に表現した仕組み」です。 システム開発*3とは、それを作る行為になります。 「ドメイン」とは全体の中に定義される一部の領域
技術的負債が紛らわしいので改善対象となる設計不備に名前をつけたい - Tbpgr Blog
システム開発に関するお仕事をしていれば、よく耳にするであろう「技術的負債」という言葉。 色々と認識が揃いにくいことや、可燃性があることで有名です。 そこで、認識の揃いにくさの理由、話題が可燃性であることの理由を踏まえた上で、よりよい名前はないだろうかという話につなげたいと思います。 なぜ「技術的負債」の認識はずれやすいか？ 技術的負債は Ward Cunningham が作ったメタファです。 何らかの業務上の利益を得るために一時的に好ましくない設計を 意図的に 選び、それを負債として考えます。 負債には利子があり、それはどんどん膨らんでいくのでいつか返済する必要があります。 こういった内容を開発者ではない経営者などのステークホルダーに伝えるための表現として存在する言葉です。 その上で、さらに議論は進み 意図的ではない 設計上の不備かそうではないかの区別には意味がないのではないか、という説が
新しいソフトウエア開発手法
マーチン・フォウラー チーフサイエンティスト , ThoughtWorks 過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。 開発手法ゼロから、重量級の手法へ、そして「ライトな」手法へ 予見的手法 対 適応的手法 デザインとモノ作りを分割する だいたい仕様を予見できたことがない 予測は絶対に不可能なんだろうか? 予見不可能なプ
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
Martin Fowler's Bliki (ja)
ここは、Martin Fowler's Blikiの日本語翻訳サイトです。Martin Fowler氏本人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。 API design / agile / agile adoption / agile history / application architecture / application integration / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv
タベリー | とある仕様書 – Yamotty – Medium
グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。 仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。 そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。 この環境では議論のすべてが口
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
Pelletkachels.nl
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
エンタープライズ・アーキテクチャの選択について - JavaDay Tokyo 2015
2015/4/8に行われたJavaDay Tokyo 2015での講演「エンタープライズ・アーキテクチャの選択」の講演資料です。Read less
Storage Class Memory - 急がば回れ、選ぶなら近道
ACMの2016 Jan.の会報の記事に上がっていたので、面白かったのでちょっとまとめておきます。 http://cacm.acm.org/magazines/2016/1/195724-non-volatile-storage/abstract 前提として、SCM（Storage Class Memory）について書いておくと、いわゆる不揮発性メモリー(Non-Volatile memory)で、次世代の主流になるだろうとは言われています。DRAMまでのレイテンシーは出ていないので、DRAMのリプレースにはならないと思われる（のが今の常識）ですが、ストレージとしては最速で、一般にDiskの1000倍（3桁）は速い。が、値段は30倍と言われていますね。 ・ハイライトハイライトは以下 ・The aged-old assumption that I/O is slow and computat
YAPCでおもしろ発表してきた - hitode909の日記
YAPCでおもしろ発表してきた． はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話． speakerdeck.com なぜか大人気発表みたいになってて，会場満員で，すみませんこんなところに来ていただいてすみませんというかんじだった． 紹介した本はこちら．予約投稿で仕込んであって，発表終わったら，こちらから買ってくださいとかやろうと思ってたけど，すっかり忘れてた． YAPCの発表で紹介した本 - hitode909の日記 質問たくさんいただいて，よいかんじにおさまったと思う． 「難しくて挫折するという問題がありますよね」「歯を食い縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は？」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE
クックパッドの課金を支える技術 - クックパッド開発者ブログ
こんにちは、技術部の大石です。開発基盤グループで課金システムの担当をしています。 インターネットサービスの決済・課金システムの開発や運用は、サービスの根幹を支えるために正確性と機能性を満たさなくてはなりません。また同時に、価格や料金体系、決済手段のバリエーションでユーザーに利便性を提供する必要もあります。「堅牢性」「信頼性」と「柔軟性」「開発スピード」という相反する要素の両立が求められます。 その結果、決済・課金システムは適切な設計や運用を意識しないと複雑になってしまいがちです。 課金システムの開発、運用でよくある問題 複数の決済方法を同じサービスの上で共存させる難しさ 例えば、最初にクレジットカード決済を導入して、その後にコンビニ決済、キャリア決済やアプリ内決済と決済方法が増えていくことはよくあることです。 最初の導入の際にクレジットカード決済への設計だけでなく、その後に増えていく決済を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
質とスピード / Quality and Speed
アプリ アーキテクチャ ガイド | Android Developers
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
これからの Microservices
