ポール・グレアムによる「スケールしないことをしよう」後編 | POSTD
本エントリは 翻訳リクエスト より投稿いただきました。 ありがとうございます！リクエストまだまだお待ちしております！ 前編は こちら です 火を燃やし続ける 時に、わざと狭い市場に焦点を合わせるのがまさにスケールしないコツなのです。丸太を加える直前に火が最高に熱くなるよう、最初は穏やかに燃やし続けるようなものです。 Facebookはこれを実行しました。Facebookは当初はハーバードの学生向けのものでした。その形態では、たった数千人の潜在市場があっただけでしたが、学生たちは、Facebookは本当にためになると感じたので、極めて大勢の学生が登録をしました。Facebookがハーバードの学生に向けたものでなくなった後も、特定の大学の学生のために長い間残っていました。私がStartup Schoolでマーク・ザッカーバーグにインタビューした際に「各学校のために履修コースの一覧表を作成するの
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
不慣れなコードベースで短期間に生産性を高めるための7つの方法 | POSTD
新しい仕事やプロジェクトを始める時に、コードベースを一から作ることはめったにありませんよね。なじみのないコードと格闘するのは骨が折れますし、新たに取り込む情報の多さを考えると、気の遠くなる思いがします。Rubyを使っていた環境からNestoriaに移った私の場合は、新しいコードベースの学習に加えて、Perlまで勉強しなくてはならなかったため、二重の苦しみを味わいました。そんな私が、できるだけ短期間で生産性を上げるために使った7つの方法を紹介します。 謙虚になろう プログラミングと聞いて、真っ先に”謙虚さ”を思い浮かべる人はいないかもしれません。何しろ”傲慢”が プログラマの三大美徳 の1つに数えられているくらいですからね。そうは言っても、なじみのないレガシーコードに出くわしたら、あまりにも分からないことが多すぎて、何度もミスをしてしまう自分にきっと嫌気がさすでしょう。このような場合は、謙虚
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
有効期限切れになる前に！RakeタスクでSSL証明書を更新する方法 | POSTD
数週間前に、他の主要なサイトの証明書と一緒に StripeのSSL証明書が無効になりました 。 それらのサイト の証明書が有効期限切れになったわけではなく、認証局のルート証明書の有効期限が切れてしまったのです。これは起こってはならないことですが、他の恐ろしいことがそうであるように、起こってほしくないときにむしろ発生してしまうものです。 サービスプロバイダの証明書が有効期限切れになることに対しては、それを防ぐための対策として自分でできることはあまりありません。しかし、自分の証明書が有効期限切れになることに対しては前もって対策を立てることができます。大きなポイントとしては、スケジュールとプロセスを確立することです。 スケジュール これは簡単にできます。”SSL証明書をチェックする”というカレンダエントリが毎月自動更新されるように設定するだけです。そしてカレンダエントリが上がってきたら、自分のW
優れたエンジニアを採用できないワケ | POSTD
あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、
ポール・グレアムによる「スケールしないことをしよう」前編 | POSTD
本エントリは 翻訳リクエスト より投稿いただきました。 ありがとうございます！リクエストまだまだお待ちしております！ 後編 を公開しました 私たち、Y Combinatorがアドバイスする最も一般的なことの1つに、「スケールしないことをしよう」というのがあります。創業予備軍の多くが、スタートアップは上手くいくかいかないかのどちらかだと考えています。会社を立ち上げ、ものを提供する、そしてそれが良いものであれば、おのずと売れます。しかし、需要がなければ結果はその逆になります。 ^(1) とは言え、意外とスタートアップは上手くいくものです。なぜなら、創業者がそうさせるからです。自分たちの力だけで成長するスタートアップはほんの一握りかもしれませんが、大抵は後押しするような力が働きます。良い例が、車のエンジンをスタートさせる役目をするクランクです。エンジンがスタートしてしまえば、エンジンは回り続けま
専門職の移り変わり（つまりMozilla Labsの閉鎖） | POSTD
Pythonを去ることについての最後の投稿 から、私のキャリアはさらに変わりました。 今年の初めMozillaはLabsグループを閉鎖しました。これはちょっと 分かりにくい です。私たちは実際には何も閉鎖しませんでした。内部ではアナウンスしましたが外部へは全く不明瞭です。しかしMozilla Labsは明らかに閉鎖です。末期にまだLabsの一員だった人々のほとんどは Mozilla Foundation （Mozilla Corporationを所有する非営利の団体、税務は複雑です）へ異動しました。TogetherJS とHotdish を作るときのパートナーである Aaron は、再編成の混乱で去りました。またその過程で彼をGoogleに取られました。Labsの閉鎖で私も曖昧な状態に置かれましたが、子供ができたので（2014年4月23日生まれのWilla Blue Murphy Bick
テスト駆動開発（TDD）はもう終わっているのか？ Part 2 | POSTD
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
Unixツールを作成するためのヒント | POSTD
現代のプログラマを取り巻く世界には無数の方法で組み合わされた、たくさんのUnixツールがあふれています。優れたツールは開発環境とシームレスに統合されますが、そうでないツールは使うたびに不満がたまっていきます。また、優れたツールはあなたの想像力次第でどんなものにも適用できますが、そうでないツールはあなたの開発環境で動かすためだけでも、あの手この手の対策を講じなければならないことがよくあります。 “One thing well” misses the point: it should be “One thing well AND COMPOSES WELL” — marius eriksen (@marius) October 10, 2012 “一つのことだけうまくやればいい”という考えでは目標に到達しない。”うまくいったものを、うまく組み合わせる”ことまで考えるべきだ 良い設計に必要なもの
あなたは全部知っていますか？プログラミングの業界用語30選 | POSTD
Stack Overflowは、私が学習に役立ててきた多くのオンライン・コミュニティと同じように、自然と厳しくなってきました。第一にこれは、自己防衛機能です。子どもが初めて学校や託児所に入ると広大な世界にさらされて、 髄膜炎菌症を発症 して日々くしゃみやせきを繰り返しながら成長するのと同じような免疫システムです。常に好ましいことだとは言い難いですが、生き残るためには必要なプロセスなのです。 2年前に投稿された、下記の質問のことを考えてみてください。 あなたが新しく作ったプログラミングの業界用語は何ですか？ あなたが作り、あなたの周りで使われるようになった、プログラミングの用語は何ですか？（他の人が真似して使っているのを聞いた、など）あなた独自の言い方が、職場内でのみ使われていたり、インターネット上で幅広く普及していたりすることもあるでしょう。 独自のプログラミングの用語、単語、言い回しを太
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
Y combinatorのサム・アルトマンによる『ボードメンバー』 | POSTD
この5年ほどの間に、影響力の行使において、投資家から創設者への劇的なシフトが見られるようになりました。これは概ね歓迎すべきことですが、いくつかの重要な側面においては、悪影響を及ぼしています。主導権を握りたいという創設者の思いが適度に保たれているうちは問題ありませんが、それが行き過ぎると会社に損害を与えることになります。 多くの創設者（少なくとも私がこれまで話したことのある創設者の多く）は、一般的に社外取締役を迎えることには消極的です。現状では、投資家に対して取締役(ボードメンバー)のオファーを出さないことが、シリーズAを勝ち取るためには都合のいい方法です。投資家の中にはそのことを歓迎する人たちもいます。取締役になるよりも、小切手を切った後はビーチでのんびり過ごす方が楽に決まっていますからね。この流れはしばらく続きそうです。というのも、このような新しいタイプの投資家は、会社の意思決定に関与し
オンライン学習の未来 ー高校生にプログラミングを教えて知り得たこと | POSTD
学校で習うような物事をインターネット上で学ぶことは、将来的には不可避なことのように思えますが、 現状において、多くの人々はオンラインで効率的に学習をしているとは言い難いようです。 Sebastian Thrunも、数カ月前のFast Companyのインタビューでこのことを 認めています。 私はこの夏、高校生に教える傍らソフトウェアを作り、コンピュータがどの程度、人々の学習の役に立つかを検証してみました。 この投稿ではその夏について、つまり生徒がどのように学び、私が作ったソフトウェアがどの程度、 彼らの学習の役に立ったか、何がうまくいき、何がうまくいかなかったか、そして次に目指すべきところはどこなのか、 について書いていきたいと思います。 カリキュラム 今回の検証の実践の場として、 AP（アドバンスト・プレースメント：成績上位の高校生が受講可能な大学の科目）コンピュータサイエンス の講義を
Goを使い複雑性を回避する | POSTD
『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』 を書いたFred Brooksはその論文の中で、 偶有的な複雑性と本質的な複雑性 について重要な区別をしています。 本質的な複雑性 とは、問題特有の領域から生じる複雑性のことを指します。例えば、SMTPクライアントを作成しているディベロッパは、 RFC 5321 の核心の細かいところ全てに取り組む必要がありますが、これはSMTPクライアントの作業をする上で避けては通れないものです。これに対して 偶有的な複雑性 とは、私たちが自ら作り上げた問題から生じる複雑性のことを指します。 技術者としては、自らの選択で生じる偶有的な複雑性によって、余計な負担が増えないようにとても注意しなければなりませんよね。その意味では、言語の選択は偶有的な複雑性を軽減できる完璧な例と言えます。Webアプリケーションを書くのにアセンブリ言語を選びます
毎日文章を書くことのススメ | POSTD
私はDropbox内に”Write every day”という名前を付けたマークダウンファイルを入れています。2014年4月22日に作成したものです。それから5カ月経った今、ドキュメントのワード数は40,164ワードになりました。 4月に始めてから、少なくとも1日に250ワードの文章を書いた計算になります。確かに私は、毎日毎日、文章を書いてきました。 今では文章を書くことが私の日課となりました。自分の中での約束事にして、守るように決めた誇れる日課です。多産な文章家は私の書く文字数の少なさに笑ってしまうかもしれませんが、それは特に気にしません。誰しも出発点というものがあるのです。 文章を書く習慣をつけると決めたことは、今年一番の決断になりました。ここでは、私が毎日書き続けている理由について書いていきます。皆さんが私のように（そして私よりも）文章を書くことに意識を向けるきっかけになればうれしい
それでも独自のCSVを書くつもりですか？ | POSTD
一部誤訳の指摘があったため、修正しました！ご迷惑おかけして申し訳ございません！ あなたは自分でCSVを書いてみたいですか？ フィールドはコンマで区切り、行は改行で分けます。簡単ですよね。数行書けば勝手が分かるというものです。 でも、ちょっと待ってください。 フィールド内にコンマがある場合は？ ダブルクォート（”）で、該当のフィールドを囲みましょう。簡単ですね。 では、ダブルクォートで囲めるフィールドに例外はあるのでしょうか？ フィールド内にダブルクォートがある場合は？ フィールド内の各ダブルクォートに対して、ダブルクォートを二重化して適用しましょう。そうすれば元のダブルクォートをエスケープすることができます。 なお、二重化したダブルクォートと空フィールドを囲んでいるダブルクォート（ ...,"",... ）を勘違いしないように気を付けてください。 フィールド内に改行がある場合は？ その場合
Optimizelyを使ってクビになりかけたワケ ~統計学が苦手なマーケターへの薦め~ | POSTD
（訳者注: 検定手法について、この記事には一部内容が古い部分があります。Optimizelyは現在、両側検定を採用し、独自開発したより精度の高い統計手法(Stats Engine)でテスト結果を表示しています。Stats Engineに関する記事: 日本語 ・ 英語 ） 私たちがSumAllでA/Bテストを一斉にスタートさせて6ヶ月が経ち、あまりよくない結末を迎えました。それは勝算があるとした結果のほとんどが新規ユーザーの獲得改善にはつながらなかったことです。それどころか、私たちは失敗したのです。そして私の一番の責任はユーザー獲得の増加であるということを考えると、本当に最悪の状況でした。私にとっても、私のキャリアにとっても、そしてSumAllにとっても。 過去に A/BテストとWebサイト･パーソナライゼーションの会社 に勤めていた経験から（はっきり言うとMonetateはOptimize
リモートワークチーム用の究極のツールボックス：必須ツール15選 | POSTD
The Ultimate Toolbox for the Remote Team: 15 Tools You Can’t Live Without by Matt Boyd Sqwiggleの共同設業者で、熱心なリモートワーカー。他には執筆やドラム演奏も。コーヒー愛飲者。Twitter Sqwiggleは、リモートワークチームのための常時"繋ぎっぱなし"ビデオチャットアプリ。PCのカメラより定期的に作業の様子が共有され、呼び出しや同意の必要がなく、実際に話しかけるように1クリックですぐに会話が始めることができる。 リモートチームの一員である場合、適切なツールを見つけるのは難しいことがあります。企業文化の決定、進捗、生産性には欠かせません。ツールの選択次第で会社を作ることも壊すこともできるので、適切なツールを選んでいるか確認してください。 テクノロジーに意味はありません。大切なのは人々を信じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
