タグ

ブックマーク / wazanova.jp (11)

  • 良いProduct Managerと良いTech Lead - ワザノバ | wazanova

    http://engineering.foursquare.com/2014/01/30/good-tech-lead-bad-tech-lead/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 A16ZのBen Horowitzが、1996年にNetscapeのDirector of Product Managementだったころに、「Good Product Manager, Bad Product Manager」という名エントリーを残しています。また、これに倣って、FoursquareのJason Liszkaが、「Good Tech Lead, Bad Tech Lead」をまとめています。 自分達のあるべき姿を律するため、かつ、悪い手にならないようにという自戒の意味をこめて、気に入った

  • コードを引継いでどこから手をつけるか - ワザノバ | wazanova

    http://www.se-radio.net/2009/11/episode-148-software-archaeology-with-dave-thomas/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 他人から引継いだコードを把握するのにどこから着手するかというテーマで、たまたまいくつかのエントリーを見かけました。「コードを読み切れないほど膨大にある。」「前任者、経緯のわかる人がいる/いない。」「ドキュメントがある/ない。」など様々な事情が想定されますが、全部まとめて主な声を拾ってみました。 謙虚な姿勢で臨むこと。そのコードベースがわかりづらいのは、書き方が悪いコードだからかもしれないが、自分がその専門領域の知識がなかったり、ベースにあるアルゴリズムが当に複雑な場合もありうる。それを、全

  • LivingSocial: SOAのテストとmockの工夫 - ワザノバ | wazanova

    https://techblog.livingsocial.com/blog/2014/08/26/soa-series-part-5-testing-apps-with-service-dependencies/ 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約3時間前 LivingSocialのRailsアプリSOAシリーズの5回目として、サービス指向アーキテクチャにおけるテストのあり方についての話。 まずは、アプリ間のサービスコールを全てmock/stubしたり、逆に依存関係を常にそのまま利用するのではなく、1回だけコールする手法を推薦しています。 テスト対象のコードは、依存するサービスに一度だけコール & レスポンスを記録し、その後の実行ではリプレイを利用する。 メリット ネットワークコールが一度で済むの

  • Dockerのメリットと可能性 - ワザノバ | wazanova

    https://www.youtube.com/watch?v=mVN7aTqr550 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Code ClimateのBryan HelmkampのRedDotRuby 2014での講演です。ビデオの前半の30分は、Docker + Rubyアプリのユースケースの場合の、概要/ツール紹介/デモです。ここでは、後半に語られているDockerのバリューについて、まとめてみます。 デリバリーの単位 Rubyエンジニアとして、デリバリーするときの単位という概念が今まではなかった(が、Dockerで実現できた)。かつて、JRubyでしばらく開発していたときがあって、その際は、jarファイルの中身がなんであれ、テストして問題なければ、DevOpsチームに渡すだけ。ある意

  • よいデザインチームのつくり方 - ワザノバ | wazanova

    http://joshuasortino.com/journal/how-to-hire-a-designer-and-build-a-design-team 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 DisqusやTeespringのデザインチームの立上げを指揮してきたJoshua Sortinoが、デザイナーの採用とチームづくりのポイントについてまとめています。「よいプロダクトを生み出す組織づくり」という意味では、他のポジションに共通する話しもあって興味深いです。 採用全般についてのアドバイス サービスづくりに情熱を燃やす人がベストな社員になる。正しいマインドセットがあれば、スキルは追いつく。 問題解決指向が強いが特定のスキルが弱い人の方が、そのスキルはあるが問題を解決しようというマインドセッ

    yutaka_kinjyo
    yutaka_kinjyo 2014/08/15
    “サービスづくりに情熱を燃やす人がベストな社員になる。正しいマインドセットがあれば、スキルは追いつく”
  • エンジニアチームでブランドを築く - ワザノバ | wazanova

    https://medium.com/on-startups/1feed0155749 2 comments | 1 point | by WazanovaNews ■ comment by Jshiike | 約5時間前 Nis Fromeのこのブログは示唆に富むものでした。 NisのチームがNew Yorkでハッカソンに参加したときのこと。慣れないテクノロジーに苦闘して、進捗が見えなくなってきた深夜3時、メール配信サービスのSendGridのエンジニア達が会場にやってきて、参加者に声をかけながら部屋をまわりはじめる。SendGridのDeveloper EvangelistであるMike Swiftから、「何か手伝える?」と言われた際に、SendGridのAPIを使ってるわけではなかったので、一旦は断る。しかし、彼は矢継ぎ早に質問を重ねてきて、Nisのチームがどのようなテクノロジー

  • Stack Overflow: 技術的負債の必然性 - ワザノバ | wazanova

    http://marcgravell.blogspot.co.uk/2014/04/technical-debt-case-study-tags.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約22時間前 Stack ExchangeのエンジニアであるMarc Gravellがブログで、Stack Overflowのタグ検索のパフォーマンスをあげるために一時的に対応した迂回策を、時間をかけて修正していった経緯を紹介しています。「あまり褒められたやり方ではないけど、その時点ではそうするのがベストだった。」という負債はあるよねという話しです。 Step 0 : 背景 Stack Overflowでは、質問に紐づいたタグを検索(“{a} and {b} and {c}”, “{d} or {e}”, “{f

  • Quora: 新しい社員の迎え方について - ワザノバ | wazanova.jp

    http://www.quora.com/Quora-company/What-is-the-on-boarding-process-for-new-engineers-at-Quora スタートアップだと新しい社員を採用したときに、面接までで手一杯で、受け入れ態勢を当日までに用意するのが大変だったりします。「xxさんは今週から入社じゃない?」と気づき、大慌てでPCやソフトの準備をすることもままありました。そして間に合わないという失態もしました。。 数年前の話しですが、Quoraはまだ創業間もないのに、新しい社員を迎え入れる体制がしっかりしていて、エンジニアは、ロゴ入りグッズもらって、hardware/softwareは当然揃っていて、ウェルカムランチをへて、必ず初日に番アップまで経験できるような仕組みになってたと記憶してます。事業の成功を担保するためのせっかくの新戦力なので、優先順位は

  • Githubの組織が成長する過程で変えたことと変えなかったこと - ワザノバ | wazanova

    GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良

  • GitHub: ストレスをうまく減らしているのがキモなんだと思った - ワザノバ | wazanova

    http://zachholman.com/posts/github-communication/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 ほうれんそう(報告/相談/連絡)って正直面倒ですよね? もちろん自分も大人ですから、仕事におけるタイミングよい細かなコミュニケーションの大切さは理解してます。だから職場では頑張ってやりました。折をみてメンバ全員を集めて話しもしました。1 on 1のミーティングもやりました。そしてメンバにもまわりとのコミュニケーションを積極的にとるように期待しました。 けど、子供のときに朝8時半に学校に行かなくてはいけなかったときと音では変わってないと思います。やらざるを得ないからやるということ。やはりストレスです。 GitHubのコミュニケーション伝導師のZach Ho

  • RailsのRESTful APIをテストで理解する - ワザノバ | wazanova

    http://www.commandercoriander.net/blog/2014/01/04/test-driving-a-json-api-in-rails1 comment | 0 pointsPivotal LabsのEno ComptonがRailsでJSON APIをテスト形式で理解できるように紹介してくれてます。「Railsアプリをてがけると、いずれ、シングルページアプリ、モバイルクライアントのためにRESTful APIが必要になるだろうから練習用に。」ということで、コードはGithubで公開されています。 GET /movies POST /movies GET /movies/:id PUT /movies/:id DELETE /movies/:id 上記のrouteをサポートするために、Railsアプリ + RSpec + FactoryGirlを用意したら、

  • 1