プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう

背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること

オフショアに限った話ではありませんが、海外のエンジニアと仕事をする機会がどんどん増えていると思います。私もベトナムのラボ型開発会社さんと2年ほどプロダクトを開発しています。 最初はどうなることやらという感でしたが、やってみると案外問題なく回るものでした。ベトナムの方の気質やエンジニアという職種自体がリモートワーク向きなのもよかったと思います。 以下、プロジェクトを円滑にすすめるために気をつけていることやTIPSをまとめます。提携や関係づくりの参考にしていただければと思います 何はともあれ英語 ベトナム語⇔通訳⇔日本語でのコミュニケーションは通訳が入ったとしても難しいです。英語でコミュニケーションが取れるエンジニアしかいない提携先を選ぶのがよいと思います。TOEIC990点でペラペラ喋れる必要はありません。私も高校3年が英語力ピークだったと思います（典型的日本人）。 使う表現は中3レベルで全

ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える

・海外向けUI設計でカスタマージャーニーマップにお世話になった話 ・継続的に定点観測していたらプロダクト自体に色々応用できた話 ・デザインとかUXって魔法の言葉？ こんにちは、渋谷のIT企業で何でも屋をしているinamolyです。 このエントリーは「UX Tokyo Advent Calendar 2015」の1日目として投稿しています。 昨年から自社のクラウドホスティングや海外展開まわりでリサーチしたり、プロトタイプしたり、そしてプロダクトオーナー的な側面も強くなってきた昨今です。 今日は数年前からプロダクトをより良くするために利用しているいくつかのフレームワークの中から、カスタマージャーニーマップ（以降ジャーニーマップ）について、自身の経験交えてご紹介が出来たらと思っています。 海外向けUI設計こそジャーニーマップかも 昨年から今年にかけて、海外向けプロダクトのコンパネUI設計を行って

概要 お願いした作業の進捗を聞くときには「進捗どうですか？」より「困ってますか？」と聞くほうが何倍も捗るよ、というお話。 タイトルの2015倍は冗談です。念のため。 「進捗どうですか？」はダメです あけましておめでとうございます。ところで皆さん進捗どうですか? ・・・いやー、流行りましたね。 この「進捗どうですか？」はtwitter上で使うと「最近どうよ、忙しいの？」程度の挨拶で面白みがあるのですが、実際に仕事で使うとなんのいいこともないと思うのです。 質問攻め いいことがないと思う理由は、「進捗どうですか？」は質問攻めになりやすいと思うからです。「進捗どうですか？」の先に待っているやりとりはだいたいこんな感じです。 「進捗どうですか？」 「進捗ダメです。」 「どこがダメなの？」 「単体テストが遅れています」 「どれくらい遅れてるの？」 「えーと・・・、0.5日分くらいです」 「項目数でい

はじめに これは ドリコムAdvent Calendar 3日目の記事です。 2日目はonkさんによるMountable Engine だらけの Rails アプリ開発です。 ID:@arihhです。 今はソーシャルゲームのチームでサーバーサイドのエンジニアをやっております。 ブラウザベースのソーシャルゲームからiOS、Android向けのいわゆるネイティブアプリにシフトし、社内のチームもより大規模にそして数が多くなってきました。 自身のチームでもいろいろとチーム開発のプラクティスを試してきたわけですが、その中でもとくに評判が高かったお菓子神社を3年以上運用してきたノウハウについて書かせて頂きます。 お菓子神社とは？ 会社内にお菓子を置くことで人が集まり、そこでコミュニケーションが生まれるというモノです。 システムとしては賽銭箱にお金を入れ、好きなお菓子をもっていっていいという形をとってい

本当は、"JSON-LDとXML"というタイトルにしようと思ったが、XMLは語るにはあまりに広い世界で恐ろしいし、詳しい先生方が多い領域なので、JSON-LD だけを書くことにした、そんなエントリーです。 （もっとも、Linked Data 初心者であることは確かですので、誤りが有れば、ご指摘下さい） 追記 2014/08/27： メトロのオープンデータ活用コンテストが、JSON-LDなのに気をよくして、配列について追記しました。 みんな大好きJSON ですが、JSONでは、複雑なデータを記述できません。端的に言うと、XMLのように、XML Namespaceを使って、スキーマを使った意味づけができません。これでは、意味づけが曖昧になって、利用に制限が生じるので、何とかしよう、というのが JSON-LD です。 W3C の仕様 http://www.w3.org/TR/json-ld/ W

Code for Japan の関です。 この記事は、Civic Tech (シビックテック)をテーマにした、「Civic Tech Advent Calendar」企画の第一弾です。 これからクリスマスまで、様々な人が様々な記事を日替わりでお届けします。 他の記事は http://qiita.com/advent-calendar/2013/civictech の一覧から見れるようになっており、日ごとに記事が増えていく予定です。 さて、いきなりハードルあげるのも後続が大変なので、初回は軽い記事から書いていきたいと思います。（実は記事を書く時間が無いだけだったりして・・） Civic Tech（シビックテック） とは何か まず、そもそも Civic Tech とは何なのか。直訳すると「市民テクノロジー」ですが、言ってみれば、地域課題解決の為の技術です。 より詳しい話については、Code f

となり、圧倒的に Web ビジネスがホットな転職先であることが分かります。Web ビジネスでの中途採用は、「IT企業から」と同じ「Webビジネス企業から」の両方。IT企業から流れ込んでいるのかと思ったら、「Webビジネスを渡り歩く」人も増えてきているのでしょう。 逆に、IT企業では、同じIT企業からの転職が圧倒的。（Webビジネス企業からの逆流は少ない）もしくは、ここに数字は出てこないが社内配置転換、が多いと推察されています。 アジャイル開発 p.106 から始まる節では、アジャイル開発における人材像について記述されています。欧米ですでに主流になっている手法だが、日本でも採用が増加傾向にあり、IPAのセミナーでのアンケートでは、2013年にはじめて「すべてのプロジェクトで適用している」もしくは「ほとんどのプロジェクトで適用している」の参加者割合が半数を超えた回があったそうです。 ただし、別

はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

前案件でBEMチックな書き方をして、あまりのクラス名の長さに キィェエエエ！！ってなった後で、 CodeGridさんでSMACSSについてのステキ記事を見つけたのでメモ。 ※以下、CodeGridさんの記事に書いてることを、自分が後で見るようにプチ要約したものです。 本記事をまだ読んだことが無い人はここよりも、本記事の方をじっくり読むのをお勧めします。 SMACSSによるCSSの設計 - ベースとレイアウト | CodeGrid CSSカテゴライズ 5つにカテゴライズして、それに準じた名前を付ける 1.ベース 2.レイアウト 3.モジュール 4.状態（ステート） 5.テーマ 1.ベースルール サイト全体で要素そのもののデフォルトスタイル

この夏Google Analyticsが新しくなるって知ってた？Universal Analyticsを予習しようJavaScriptGoogleAnalytics 意外と認知度が低い感じですが、Google Analyticsがそろそろ新しくなりますよ！ 現在パブリックベータとして提供されているUniversal Analyticsが 予定では 7月中 に正式リリースになります。つまり今月！ 世の中見渡していると非エンジニアなウェブマスター向けの紹介記事が多い印象なので、ここではJavaScriptのインタフェースがどう変わったか、それを使ってエンジニアはどういうことができるようになるか、みたいな、よりエンジニア向けの話題を中心に書いてみたいと思います。 ソースは公式ドキュメントなので、より詳しく知りたい方はそちらを参照してください。 簡単なまとめ Universal Analytics

オバマ大統領の再選に大きく寄与したことで大きな注目を集めているA/Bテスト。A/Bテストを導入した、することを検討している、という開発現場も多いのではないだろうか。 そんな中、Web上で次のような議論を見つけた。 20 lines of code that will beat A/B testing every time Why multi-armed bandit algorithm is not “better” than A/B testing 一言でまとめると「A/Bテストよりバンディットアルゴリズムの方がすごいよ」「いやいやA/Bテストの方がすごいし」ということだ。 で、バンディットアルゴリズムとは一体何者なのか？ そこでBandit Algorithms for Website Optimization (O'REILLY)を読んでみた。その結果分かったことを踏まえてざっくりと