A-Listers

140字に収まらない海外テックネタヘッドライン

投稿者アーカイブ

チームプロジェクトが失敗する前にメンバーの合意書を作っておく

leave a comment »

back-of-a-napkin

スタートアップのビジネスが成功(または失敗)するにつれて問題となってくる、創業メンバーの利益の取り分や意思決定の方法などを記載したAgreement(合意書)を、5つの質問に回答するだけで作成できるBack of a Napkinというサイトが公開されました。

以下の5つの質問に回答すると必要事項が記載されたPDFファイルがダウンロードでき、あとはメンバーがそれぞれ署名をすればAgreementができあがる、というものです。

  1. チームメンバーの名前
  2. チームが開発しようとするもの(aかanで始まる1文)
  3. プロジェクトが利益を生んだ場合の各メンバーの取り分
  4. 意思決定の方法(誰かが決定権を持つか、完全に合議制とするか、など)
  5. プロジェクトが失敗した時にどうするか(ブランドや成果物の扱い)

このサイトがあれば弁護士へ相談する必要がなくなるといった性格のものではありませんが、こういった取り決めなしに複数人でスタートしたプロジェクトは、成功しても失敗しても厄介な問題を抱えることになりかねませんから、「最初の段階でどんなことを取り決めておくべきか」を意識させるという点では有用かもしれません。

via http://thenextweb.com/entrepreneur/2013/12/14/back-napkin-aims-get-basics-building-startup-way/

Written by junya

2013/12/15 at 21:02

カテゴリー: Uncategorized

Tagged with

綺麗な設計を身に付けるためのSandi Metzルール

with 6 comments

スクリーンショット_2013_05_20_9_54
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。

このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。

そのルールは以下の通りです。

  1. クラス内のコードが100行を超えてはならない
  2. メソッド内のコードが5行を超えてはならない
  3. 4つより多い引数をメソッドに渡すようにしてはならない(ハッシュによるオプションもパラメーターとみなす)
  4. コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる
    • ビューは1つのインスタンス変数を参照し、そのオブジェクトに対するメッセージ送信のみを行うことができる(@object.collaborator.valueは許可されない)

項目は少ないですが、方向性としてはThoughtworksアンソロジーという書籍で紹介されていた「オブジェクト指向エクササイズ」に通じるものがあります(あちらはJavaが主な対象でした)。

4つのルールとは別に、このルールを破ってもよい場合として、

  • 適切な理由があると考えられる場合
  • ペアプログラミングのパートナーやコードレビュアーが許可した場合

がルール0として挙げられています。

thoughtbotでは実際のプロジェクトにこのルールを適用してみたそうで、以下のような知見が得られたようです。

  • ルール1 クラス内のコードが100行を超えてはならない
    • Single Responsibility Principle(単一責任の原則)を徹底するようになる
    • テストも100行以内に収めることを心がけたことで、1つのファイルで多くの機能をテストしすぎていたものを、よりフォーカスの定まった個別のテストに分割できた
  • ルール2 メソッド内のコードが5行を超えてはならない
    • メソッドを5行に収めるために、elseelsif「if〜else〜elsif〜end」のようにelseとelsifを合わせて使うことを避けるようになった(コメントで誤訳のご指摘をいただきましたので修正します。原文の意図は、if〜else〜endやif〜elsif〜endは使うけども、それらの組み合わせは5行を超えてしまうので使わない、ということのようです)
    • 条件分岐で1行を使うのではなく、適切な名前のついたプライベートメソッドを作ってそれを呼ぶようになった
    • コード片をプライベートメソッドとして抽出することで、命名が行われ、説明としても役立つようになった
  • ルール3 4つより多い引数をメソッドに渡すようにしてはならない(ハッシュによるオプションもパラメーターとみなす)
    • Railsのビューヘルパーメソッドはとても多くの引数を要求するため、よい解決法が見つからない場合は、ルール0に立ち返り引数をそのままとした

ルール4については、実際のコードを例に詳しく説明がされています。

ルール4を適用すると、1つのコントローラーが1つのオブジェクトだけをビューに引き渡すように設計することになりますが、実際のプロジェクトでは必ずしも1つのコントローラーが1つのものを表示するとは限りません。

例えば、「トップページにアクティビティフィードと通知の数を表示する」といったようなケースも頻繁にありえます。thoughtbotではこのようなケースにFacadeパターンを適用し、アクティビティフィードと通知の数を内包したダッシュボードクラスを定義することで、コントローラーとビュー間のやり取りを単純化させることにしたようです。

詳細は、実際のコード例を見れば一目瞭然だと思いますので、ぜひ元のブログ記事も参照してみてください。

Written by junya

2013/05/20 at 11:56

カテゴリー: Uncategorized

Tagged with ,

37signalsはベータサーバーを本番環境のデータベースに接続している

leave a comment »

David Heinemeier Hansson氏(Railsの開発者。以下DHH)が37signalsのブログに公開したRunning beta in productionというエントリによると、同社ではBasecampの開発に使われる6つのベータサーバーがすべて単一の本番環境のデータベースを参照して動いているそうです。

DHH氏曰く、「自分がいいアイデアだと思ったものが本当にそうなのかを知るには、実際のデータを対象に自分たちが日々使ってみることが必要」とのこと。

Basecampでは新機能や改良の開発、技術的なアップグレードなどを継続的に行なっており、そのために同一の本番環境のデータベースを参照する6個の異なるベータサーバーが運用されています。通常、開発中の機能は開発用のデータベースと共に運用するのがセオリーだと思いますが、DHH氏は「実際の重要なデータとともに不満を感じながら使わないかぎりは、そういった機能をきちんと評価することは不可能だと気づいた」とのことで、このような構成になっているそうです。

最初は、実際にサービスの運用に使っているものとは物理的に異なるサーバーに本番のデータを複製しているのではないか、とも思ったのですが、コメント欄にて「All beta envs and production share the same prod database.」という37signalsスタッフのコメントがあるので、やはり実際にサービスで利用しているデータベースにベータサーバーを接続しているということで間違いないようです。

また、6つのベータサーバーをどのように使い分けるのかの手順はシンプルで、どのサーバーでどのブランチのコードを走らせているかは、開発者が適宜、開発用のチャットルームのタイトルに反映させているそうです。ブログエントリに掲載されたスクリーンショットでは、以下のようなルームタイトルになっていました。

  • staging: riakcs
  • beta: project_templates
  • b1: redis-resque-upgrade
  • b2: tags-mini
  • b3: bcx-ios-compose [reserved for bcx-ios]
  • b4: email-in-phone
  • b5: rails4

エントリではstagingの位置づけには触れられていませんが、それ以外のbetaからb5までのサーバーはすべて本番のデータベースに接続していると考えてよさそうです。

開発者は、ベータサーバーが必要なときはルームタイトルの「b1」の部分を「b1: redis-resque-upgrade」のようにサーバー名とブランチ名に書き換え、ベータサーバーでの作業が終わったら「b1: available」のように変えることで、シンプルに運用しているようです。

このようなスタイルの運用で気になるのが、データベースマイグレーション(スキーマの変更など)をどのように適用するか、というところだと思います。

それについてはコメント欄でいくつかやりとりがされていて、基本的には、

  • 本番データベースに接続されたステージング環境でマイグレーションのテストを行う
  • その後、それを本番環境にもロールアウトする

という運用のようですが、この際、ステージング環境が接続する本番データベースというのが、本番データベースの複製なのか実際に運用しているデータベースそのものなのかについては残念ながら言及がありませんでした。

個人的にはかなりアグレッシブな運用だと感じたのですが、データベースマイグレーションを注意深く行うようにすればアリなのかもしれませんね。

Written by junya

2012/09/21 at 12:00

退職理由は「転職先のモニターのほうが大きい」から?

with one comment

Workspace

Workspace

今や、いいエンジニアを雇うのに環境や待遇が重要なのは言うまでもないことで、「希望するマシンが支給される」とか「椅子はすべてアーロンチェア」といったフレーズは魅力的です。しかし、そんな華やかなフレーズの裏側に見え隠れする「社内のカルチャー」という本質を理解しないと、本当に素晴らしいエンジニアを惹き寄せることは難しいもの。

NingやVMware、Akamaiといった企業で働いた経験のあるJohn Josef “Sef” Kloningerさんは、Why Quit? Because They Have Bigger Monitorsというブログ記事で、自身の経験を以下のように紹介しています。

退職理由は「転職先のモニターのほうが大きい」から?

以前の職場での話。

私はエンジニアリングマネージャーで、人材確保に関して問題を抱えていた。チームのエンジニアが会社を辞めて、もっと小さい今風の会社に移ろうとしていたのだ。

以下は退職者面接での一幕。

私:なぜ辞めてしまうんだい?
彼:あっちにはもっと大きいモニターがあるんだ。
私:(疑わしそうに)冗談だろう?うちでも君にもっと大きいモニターを支給できるよ。
彼:僕だけじゃない。あっちでは全員が大きなモニターを使っているんだ。
私:それがそんなに重要なのかい?
彼:僕の作業時間というものを彼らがどれくらい重視しているかわかる。彼らにとっては、僕の網膜により多くのピクセルを詰め込むことは、余分な資金を費やすだけの価値があるってことさ。

今となっては、これがまったく真実であると理解できる。このように従業員を評価する職場では、設備投資を節約することと従業員の生産性(そして喜び)を比較して考える。最高のエンジニアは、職務のために最高のツールを与えられる。

大きなモニターはそれをあらわすわかりやすいサインだ。

Kloningerさんは、優秀なエンジニアが惹かれる強いエンジニアリングカルチャーというものを「エンジニアが高く評価され、また重要とされている」ことと定義して、意味合いとしては以下のように説明しています。

  • 決定までのプロセス − どんなものをいつ誰が作るのかということについて、技術畑の人たちが提案することで決定がなされる
  • ソフトウェアを作り上げる技術に対するリスペクト − プロジェクトによっては期間の予測が難しいものもあるが、そういったものも受け入れられる必要がある
  • インフラストラクチャーへの理解 − メッセージキューのスケーリングやビルドシステム、バージョンコントロールなどの機能面とは関係のない作業が必要な場合に、その正当性を上司が理解している

こういったカルチャーを面接の場で引き出す・聞き出すことは双方にとって難しく、それは前述のエピソードでもうかがえます。

記事にはもう1つエピソードがあって、こちらは人によってはそれほど気にしないかもしれませんが、社内文化をうかがい知るという部分ではとても興味深い観点だと思います。

自分のメールアドレスを選べる?

エンジニアでない人々は、メールアドレスがどれくらい重要なのかということを正しく理解していないことがある。メールアドレスはオンラインでのアイデンティティなのだ。

厳格な命名規則(ファーストネームとラストネームの1文字目とか、もっとひどいのはラストネームとファーストネームの1文字目)は、エンジニアのハッピーさよりも画一性に価値を置いた職場であることを暗に示している。

それどころか、従業員に自身のことを「クールな個人」ではない「歯車」や「人的資源」のように感じさせてしまう素晴らしい方法ですらある。

(余談:Human Resources(人的資源)という言葉はやめよう。とても不快だ)

私のファーストネームは風変わりなので、この問題は個人的にも重要だ。もしあなたが sef@company.com を使わせてくれないのならば、それは私にとって大きなマイナス点となる。

エイリアスや、メンバーが1人しかないメーリングリストといったダサいもので誤魔化したりもしてはいけない。シェルプロンプトでどのように見えるか、whoami コマンドが何を返すのかが重要なのだ。

ということで、悪いカルチャーから生まれる悪いポリシーによって、あなたの組織が優秀なエンジニアにとって魅力的ではないポジションに位置することになってしまう、というお話でした。

日本でも、エンジニアだからこそ転職時に気になる社内文化の問題っていろいろあるような気がします。オフィス設備だけでなく、そういった部分にもっとフォーカスをあてた採用活動も増えていくといいですね。

via Why Quit? Because They Have Bigger Monitors | sef.kloninger.com

Written by junya

2012/05/18 at 14:18

カテゴリー: Uncategorized

Tagged with

Cloud.comというドメインはいくら?

with one comment

Citrix SystemsによるCloud.comの買収が発表されました。

Cloud.comはオープンソースのクラウドコンピューティングプラットフォーム CloudStackを開発・提供している企業です。もともとはVMOpsという社名でしたが、2010年5月にステルスモードを抜けるとともに社名をCloud.com, Inc.に変えて現在に至っています。

気になる買収額ですが、TechCrunchの推測によるとおよそ$200M〜$250M(2億ドル〜2億5000万ドル)あたりではないかとのこと。そのTechCrunchのエントリーでは「彼らが手に入れた一番の資産はcloud.comというドメインだ!」というジョークが真っ先にコメントされていて笑ってしまいましたが、実際のところ、cloud.comというのはかなり資産価値の高いドメインのような気がします。

「果たしてVMOpsはいくらでこのドメインを手に入れていたのか?」

少し気になったので調べてみたところ、ドメイン名業界向けの情報サイト Domain Name Wireに当時の記事がありました。

記事によると、もともとcloud.comというドメインはMeetupの共同創業者であるScott Heiferman氏が保有していたもので、それが2009年にオークションに出され、2010年2月17日にVMOpsへと所有者が書き換えられたそうです。なお、ドメインが登録されたのは2000年ですが、当時からHeiferman氏が保有していたのかは確認できませんでした。

気になる譲渡価格については「Heiferman氏との契約内容により、開示することはできない」と言われたそうです。ただ、ちょうどその時期にVMOpsが$17M(1700万ドル)の投資を受けていたことから、これがドメインの購入に向けたものだったのではないか?と推測されています。

当然、Citrix Systemsはドメイン名だけを目当てに買収したというわけではないでしょうが、資産にcloud.comというドメインが含まれていなければ評価額はもっと下がっていたであろうことを考えると、Cloud.comの思い切ったブランディング戦略はなかなか上手かったと思わざるをえません。

とはいえ、一番関心すべきなのはHeiferman氏の先見の明ですね。2007年のHeiferman氏のブログには以下のような一文もありました。

(I happen to believe in a Web OS [& I own cloud.com]. Funny how the social OS is now web OS.)

Written by junya

2011/07/13 at 08:00

カテゴリー: Uncategorized

Tagged with ,

「金持ちになるのではなく、豊かに暮らす」というライフスタイル

with 4 comments

Hacker Newsで、ベルギーの女性2人組によるDon’t be rich, Live rich(金持ちになるのではなく、豊かに暮らす)というプレゼンテーションが話題になっていました。

この2人は、WebデザイナーのIne Dehandschutterさんと、オンラインコミュニケーションのコンサルティングをしているCatherine Van Holderさん。サイトはnomadz.nu。2人はとくにお金持ちというわけではないけれど、様々なデザインのアパートメントに滞在しビンテージカーに乗りながら、2010年の間に南アフリカやタイ、アルゼンチンなど10カ国を旅してまわるというとても充実した生活を送ってきました。

2人はこの生活を一般的な毎月の収入だけでまかなっているそうですが、そのポイントは「働きながら」というところ。2人ともリモートで作業のできる仕事を持っているために、このようなスタイルで暮らすことができているというわけです。

これだけでは単に羨ましいだけの話で終わってしまいますが、このプレゼンテーションで2人は、普通の「テンプレート」な生活ではなく自分がどんなことをやりたいかを元に自分のライフスタイルをデザインしよう、と呼びかけていて、そのための心構えとアドバイスを紹介してくれています。

プレゼンテーションでは、2人のような暮らし方を始めるための4つのステップと気をつける点が解説されていますが、詳細はプレゼンテーションを見ていただくとして(とてもグラフィカルで端的なので英語が苦手な方でも読みやすいと思います)、ここでは気をつける点と役立つツールをいくつか抜粋しておきます。

  • 気をつける点
    • 言葉が通じないことによる不便さ(南アフリカでは簡単に友達ができたけど、タイとブラジルは言葉の壁があった)
    • いくつかの国はあなたが思っているものとは違う(アルゼンチンは物価が高騰している、週末に旅して回るには広すぎる)
    • ヘッドフォンは必須
    • 規律正しく働く必要がある(ブエノスアイレスにオフィスを持ったのでとても生産的に仕事ができた)
  • 役立つツール
    • iPhoneと現地の携帯電話番号、SIPソリューション(ベルギーの電話番号から旅先の電話番号への転送をする)
    • Skype(顧客との通話と画面共有)
    • Dropbox、Sugarsync、Nomadeskなどのファイル共有サービス
    • Backblazeなどのオンラインバックアップサービス
    • AirBNB.com
    • FacebookとTwitter

というわけで、羨ましい反面、いざ実践するには勇気がいるなあ…というお話でした。

でもやっぱり羨ましい。

via: Hacker News | Don’t be rich, Live rich

 

 

 

Written by junya

2011/06/28 at 08:00

カテゴリー: Uncategorized

Tagged with , ,

スタートアップをグーグルメソッドで始めてはならない

with 2 comments

スタートアップのビジネスモデルについて「グーグルメソッドで考えるのはやめよう」と呼びかける記事がスタートアップ向けブログメディア The Startup Foundryに掲載されていました。グーグルメソッドとはつまり、「今はまだ利益があがっていないけど、ユーザーが10万人に達しさえすれば広告で採算がとれるようになるはずだ!」という考え方。

Googleのビジネスモデルについては既にご存知の方も多いと思いますが、同ブログによれば、

  • Googleは実質的には、マーケットに入り込むために検索を利用している広告の会社である
  • 無料のサービスで注目を集め、実際の製品である広告をより効果的なものにしている

といった点で、Googleは多くのスタートアップとは異なるゲームをプレイしている、としています。

一方で、スタートアップ(特に自己資金によるブートストラップ・スタートアップ)は生き延びるためにキャッシュを必要としており、主力製品を無料で配りその分を規模で補うようなやり方はとても危険なので、盲目的にグーグルメソッドをなぞってはならない、と。

では、スタートアップはどうすればいいのか?という話なのですが、同ブログでは自社のサービスに「初日から課金する大胆さ」を持つように勧めています。このアプローチは一部のアントレプレナーたちからは敬遠されているようですが、

  • 自分のスタートアップが現実の価値を提供できると信じているのならば、ユーザーにお金を払ってもらおう
  • 無料で提供するという考えに怖気付いてはならない

だそうです。

Googleのモデルもスタートアップのモデルも理屈としては理解している人が多いと思いますが、いざ自分のサービスをローンチさせるという段階になってみると、なかなか冷静に判断できなくなるものなのでしょうか…。

via: It sucks to build a startup with the “Google Method” | The Startup Foundry

Written by junya

2011/06/14 at 08:00

カテゴリー: Uncategorized

Tagged with ,

%d人のブロガーが「いいね」をつけました。