アジャイルプラクティスマップはアジャイル開発においてよく使われるプラクティスを鉄道の路線図の形式でまとめたものです。単なる用語集とは違い、二次元で視覚的にプラクティスの位置づけを理解することができます。またアジャイル開発で用いられる各種手法の関連性をつかむことができます。 過去にも、Agile Alliance からアジャイルプラクティスの地下鉄地図（Subway Map to Agile Practices）が公開されるなど、多くの路線図形式のマップが存在しますので、このサイトはさながら Yet Another Agile Practices Map ということになります。 Agile Studio の識者たちにより、過去の歴史を踏まえたアジャイルのトリビアとも呼ぶべき豆知識も充実させました。 マップでは、「手法」を路線で、「プラクティス」を駅で示しています。プラクティスによっては、いく
先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を
Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob
Update Oct 2019: Storybook Docs now allows you to write Markdown/MDX to generate styleguides directly from Storybook. Take a peek if you’re on the fence about which tool to choose. If you’re looking for UI component tools chances are you’ve stumbled across Storybook and Styleguidist. On the surface, both have similar features and are used by teams around the world. It can be tough to pick the righ
こんにちは、Wantedly の Infrastructure Team で Engineer をしている南（@south37）です。 先日、gRPC 関連で2つのブログを書きました。「gRPC Internal」では、ドキュメントやコードを読み解くなかで見えてきた「gRPC の設計と内部実装」についてブログを書きました。「Real World Performance of gRPC」では、Wantedly で実際に gRPC を利用することで達成できたパフォーマンス改善についてブログを書きました。 こんにちは、Wantedly の Infrastructure Team で Engineer をしている南（@south37 ）です。 今日は、WANTEDLY TECH BOOK 6 から「gRPC Internal」という章を抜粋して Blog にします。 「WANTEDLY TECH
ハッカーズチャンプルー2019（ http://hackers-champloo.org/2019 ）の発表資料です
/***************************************** { Fintan } 先進技術・ノウハウを駆使して、新しい社会の活力を創造し、人々の笑顔を増やしていく。 *****************************************/ /****************************************** { Fintanと鮭 } Fintan（フィンタン）は、ケルト神話に登場する知恵の鮭の名前です。 食べれば世界のあらゆる知恵を得ることができるとされており、これを食べた主人公はその知恵を使ってあらゆる難題を解決したと言われています。 利用者が、システム開発のあらゆる知恵を得られるようにという思いを込めて、Fintan（フィンタン）と名付けました。 ******************************************
要約 ヘッドレス Chrome は Chrome 59 でリリースされています。これは、ヘッドレス環境で Chrome ブラウザを実行する方法です。つまり、Chrome なしで Chrome を実行することになります。Chromium と Blink レンダリング エンジンが提供する最新のウェブ プラットフォーム機能をすべてコマンドラインにもたらします。 なぜこれが有用なのでしょうか？ ヘッドレス ブラウザは、可視 UI シェルが必要ない自動テストやサーバー環境に最適なツールです。たとえば、実際のウェブページに対してテストを実行したり、その PDF を作成したり、ブラウザが URL をレンダリングする方法を確認したりできます。 ヘッドレスの開始（CLI） ヘッドレス モードを開始する最も簡単な方法は、コマンドラインから Chrome バイナリを開くことです。Chrome 59 以降がインス
Electronとは？ Electronは JavaScript、HTML、CSS を使ってデスクトップアプリケーションを作ることができる ライブラリ です。作ったアプリケーションはMac、Windows、Linuxで動かせます。 次は： なぜ重要？ 定義： JavaScript、HTML、CSS はWeb用の言語で、Webサイトの基本的な構成要素です。Chromeなどのブラウザは、コードをふだん目にするグラフィックに変えて表示します。 Electronはライブラリです Electronはコードですが、再利用でき、自分で書き起こす必要がありません。ユーザはその上にプロジェクトを構成します。 参考資料 Apps built on Electron Electron API Demos （Electronで何ができるかをみてください） なぜ重要？ 一般に、デスクトップアプリケーションは各オペレ
私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが（ make install 、 make deploy ）、中には説明が必要なものもあります（ make run-dev 、 make restart-api ）。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI（コマンドラインインタフェース）を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか？ それを実現するのは、実はとても簡単です。まずは各ターゲッ
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
icGrep: The Modern Grep Replacement Building off the Parabix transform representation of text as well as the highly-regarded LLVM compiler infrastructure, icGrep is the modern replacement for the venerable grep utility, offering fundamentally parallel and consistently high-performance search as well as broad support for Unicode regular expressions. icGrep embodies a completely new algorithmic appr
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2
＜前編のあらすじと中編のお話＞ 夏の訪れを感じさせる某日、大のお寿司好きであり、ゲーム好きでもある、伊藤直也氏（以下「naoya」）が、本企画の最終回にゲストとして招待したのは、『株式会社ドワンゴ』の川上量生氏（以下「川上」）。普段から大のゲーム仲間でもあり、親交の深い二人の話は、過去の『ドワンゴ』を振り返る話から、アニメ業界とIT業界の話まで、多彩に展開されます。そして、話はいよいよ川上氏が考えるモノづくりの根幹の部分に迫っていくのであった―― ⇒【前編】の記事はこちら — naoya：エンジニアが自分の好きな言語を使うのにあれこれそれっぽい理由を捻り出すという話が出ましたけど、スクラムやDDDの導入に際しても、やっぱりそんな感じだったんですか？ — 川上：うん。もちろんスクラムやDDDが言っていることは正しいんですよ。でも、それを前提に開発をすべきというみんなのこだわりはなんなのか、っ
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
