アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあら
Googleでは、世界各地のGoogler（Googleの社員）たちが毎週、トイレの壁に紙をたくさん貼り出していました。コードのテストに役立つヒントを週替わりで1枚の紙にまとめたものを、社員間で共有するためです。ある週はDI（依存性注入）を取り上げて様々な言語での簡単な使用例を示し、またある週はチームのコードベースのテストカバレッジを評価するために、ツールのセットアップ法を紹介するという具合です。“Testing on the Toilet（トイレの時間に考えるテスト）”と呼ばれるこの取り組みは、エンジニアがコードを書く上で役立つ情報を共有する方法として、奇抜で面白いものです。 ^(1) そしてGoogleのエンジニアリング文化の要となる強みもここに表れています。つまり、大勢のエンジニアに対して、一連のベストプラクティスを一貫した強硬な形で、効率よく普及させるということです。 私は大学を出
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 アジャイルな手法を使用して技術的負債を返済する David Laribee すべてのコードベースには、暗くて恐ろしい隠れた場所や小道があります。非常に脆弱なコード、回帰バグが発生するコード、および処理をたどろうとするとイライラしてしまうようなコードのことです。 Ward Cunningham は、コードの、変更が困難でエラーが発生しやすい部分を金銭的負債ににたとえて、みごとな隠喩を作りました。技術的負債があると、前に進んだり、利益を得たり、"黒字" の状態を維持したりすることができなくなります。現実世界と同様に、安い負債もあります。低リスクの金融商品よりも利率の低い負債です。また、負債をさらに増やしていく高利
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 コードを書き続けるためにやってること(by Voluntas) なんか流行っているので乗ってみます。 趣味コード 趣味とはいっても、暇つぶしだったり、流行りもののチュートリアルに触って「おれ新しい◯◯やってみたぜ」みたいなのは極力しないようにしてます。仕事で必要になった時に、仕事の時間の中で集中的に学ぶ方が学習効率が高いので、趣味時間の活用という意味ではもったいないですよね。幸い、まったく未知の基礎的な内容というのはほとんど出会わなくなってきて、新しい技術といっても、既存の知識を土台にして、軽く検索すればOKなことがほとんど。ということで、趣味といっても、将来の仕事で役に立ちそうな種となる可能性のあるものを作るように心がけています。実際に種になるかどうかは運次第なので、命中率に
テスト駆動開発（TDD）の一般化とGitHubの登場によって、機能追加の際にコードとテストを同時に実装する（そして、両者を一括してmasterにmergeする）という開発手法が一般化してきました。 しかし、「良いプログラム」の要素を構成するのは、コードとテストのみではありません。動作するコードと、その品質を担保するためのテストがあったとしても、適切なドキュメントがなければ、ユーザーはそのプログラムをどうやって使ったら良いかわかりません。 つまり、ユーザーに使いやすいプログラムを継続的に開発／提供しようと思うと、 コード テスト ドキュメント の３点セットを提供する必要があるのです注1。 今日のJSXが抱えている最大の課題は、ドキュメントが不足しているという点にあります。その原因は、「機能追加」の際にコードとテストのみを実装してmasterにmergeすることを繰り返す一方で、ドキュメントは
はじめまして。荻原といいます。グリーのプラットフォーム部門で、サーバーサイドのエンジニアをしています。 昨年末ぐらいまで業務の空き時間にテスト周りでごにょごにょと動いていたので、今日はそのことについて書かせて頂きます。 こんな人は読むと役に立つかもしれません。 レガシーなプロダクトになんとかして突破口を開きたい it の書き方で参考になりそうなものを探している Ruby でスマートフォンのブラウザ操作を自動化したい 経緯 こちらでも言及されている通り、サービスを運営している以上、時には技術的負債に向き合わなければなりません。GREEも歴史が長いプロダクトなので、日々コードをリリースしていく中でそういった問題に頭を抱える場面もありました。 技術的負債による副作用はたくさんありますが、どういう点に不安を感じていたのか、実際に開発の現場に立って感じたことをいくつか書いてみたいと思います
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
Jenkinsでつちかった、コードの互換性を保ちつつ様々な修正を加えていく技法を紹介します。Read less
はてなエンジニアブロガー祭りで「高速にドッグフードを食べる方法」という題で発表してきた． 箸でドッグフード食べるパフォーマンスの話ではなくて，もとはマイクロソフト用語である，Eat your own dog food，自社製品を使ってより良くしよう，みたいなほうの話．はてなブログ開発しながら毎日使うとか，思い付きで作ってるわけではなくて，事実や根拠にもとづいて作ってるとか，安全に作るための仕組みとか，そういう話． 普段の勉強会では僕は主に3分くらいのLTをしていて，20分も話したことなかった．資料ぜんぜんできなくて，Keynote見るだけで疲弊してた．急に長くていい話できるはずないと思って，LT5連発という形にして，ドッグフードにまつわる話を5個するという形にしたところ，なんとかなった． 東京では情報が氾濫してるから，京都でこんなのやってますとか言っても，東京では常識みたいな冷たい反応をさ
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
