タグ

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

  • マネージャのいない組織に進化する現実と幻想 - ワザノバ | wazanova

    マネージャのいない組織へのチャレンジについては、一昨年から話題になっていますが、ここにきてかなり論点が絞られてきていると思います。 1) 非同期 & 可視化が進む GitHubなどのツールに親しむエンジニアが、進捗が可視化され、非同期で仕事を進めることに先に慣れてきたが、SlackのようなコミュニケーションツールやTrelloなどのタスク管理ツールの浸透で、非エンジニアにもじわじわその理解が進んでいく。 2) マネージャの役割が変わる 上記1) が進むことで、進捗を報告させて情報を集約、また逆に、全社 / 業界の情報をフィルタリングして伝えるという、情報操作ハブとしてのマネージャの役割はかなり減る。情報の透明性があがることで、情報を握っていることがマネージャのパワーの源泉である時代が終わる。 プロジェクトの進捗 / 開発のクオリティ / 売上 / 評価とフィードバック / メンバの士気の向

  • エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova

    https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿

  • 努力とセンスの関係と優秀なプログラマー - ワザノバ | wazanova

    http://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers/answer/Jeff-Darcy? 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 スポーツにしろ、勉強にしろ、仕事にしろ、何をやるにもその特定の分野でトップ1%人は尊敬するほどすごいのですが、人が長く続けつつ努力をしてきたことが垣間見えるので、なぜ優秀なのかというのが理解できる範囲。ただし、そのさらにトップ10%、いわゆる世の中でその分野のトップ0.1%の人というのは、すごすぎて、どうしてそうなれるのかが分からないと実感することがあります。議論している時に、数歩先の真理を理路整然と突然読み取って指摘されるような、驚くようなセンスを見せつけられる経験を数

  • 「失敗を活かす」を実現する仕組みづくり - ワザノバ | wazanova

    http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem(個人批判をしない建設的な障害の振返りミーティング)というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが

  • シングルページアプリづくりのJavaScriptフレームワーク比較 - ワザノバ | wazanova

    http://blog.andyet.com/2014/08/13/opinionated-rundown-of-js-frameworks 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 開発言語やフレームワークの比較は、参考になるところはありつつも、その結果、不愉快な気分になる人がいるわけですが、それを懸念して、「(これを読んだ人は、他人の)意見を読んでいるだけだと思い返してほしい。貴方にどうすべきだと言ってるのではなく、自分にもしくはチームのために何がよいかは自分で判断すべきこと。」と前置きして、Henrik Joretegが、JavaScriptフレームワークについて私見をシェアしています。 反対意見も併記しようと思ったのですが、TwitterやHNでの反応がまだないようなので、注目すべきコメ

  • 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チームに渡すだけ。ある意

  • Rubyのパフォーマンス計測ツール - ワザノバ | wazanova

    https://www.youtube.com/watch?v=cOaVIeX6qGg 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 42分前 Aaron Quintは、オンライン/オフラインで招待状やお祝いのカードを送るサービスであるPaperless PostのCTOです。GoRuCo 2014で、お薦めのRubyアプリのパフォーマンス計測ツールを紹介してくれてます。 評価の基準としては、 Specificity (Sp): アウトプットの内容がどれだけ詳細か。 Impact (Im): Probe Effectのレベル。計測が意図しないシステムの振る舞いにつながる可能性のある影響度合い。この数値が大きいと番環境では使えない。 Difficulty of Operator Use (Op): ツールのセッ

  • 何でもデバッグできるようになるスキル - ワザノバ | wazanova

    https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ(apt, yum, gem等)レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい

  • Rails: SOAアプリの結合テスト - ワザノバ | wazanova

    http://www.bignerdranch.com/blog/testing-rails-service-oriented-architecture/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Big Nerd RanchのブログでTravis Douceが、remote_factory_girl と remote_database_cleaner を利用したSOAアプリの結合テストについて紹介しています。 まず、DBをもたないクライアントアプリが、user table を持つホームアプリにHTTPリクエストを投げ、JASONリクエストが返ってくるパターンを例としてあげてます。(概念図) よく見かけるのが、 1) クライアントアプリからホームアプリへのHTTPリクエストをスタブする。 2)

  • Rails wayにどこまで従うべきかという議論 - ワザノバ | wazanova

    http://andrzejonsoftware.blogspot.com/2014/04/be-careful-with-rails-way.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 「RailsでInteractorをうまく利用する」と「DHHとのピンポン」で紹介した議論をうけて立ち上がったサイト( http://www.dhh-ping-pong.com/ )で、DHHに挑戦するコードのピンポンが行われてます。 最初に取り上げられたAndrzej Krzywdaとのやりとりは、こちら。Andrzejのリファクタリングについてのオリジナルのブログはこちら。 また、Andrzejは最新のブログの投稿で、その比較について解説しています。 自分はコードとRailフレームワークとの関係をな

  • モバイルAPIデザインのまとめ - ワザノバ | wazanova

    Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアAPI議論」で紹介しました。)とEtsyのPaul Wrightの講演のポイントをまとめてくれています。 1) スピード ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。 2) RESTが常にベストとは限らない 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ

  • Ruby RoguesメンバとiOSエンジニアのAPI議論 - ワザノバ | wazanova

    http://rubyrogues.com/147-rr-apis-that-dont-suck-with-michele-titolo/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。 1) Follow Conventions はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持し

  • RailsでInteractorをうまく利用する - ワザノバ | wazanova

    http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors 3 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 飲み会アレンジサイトGrouperが、同社のエンジニアブログで、規模の大きなRailsアプリをパフォーマンスよくつくるときの工夫を提案をしてますが、それに対してRailsのクリエーターのDHH (Basecamp / 37 Signals) が厳しいコメントを残しています。 1) Grouperの提案 問題意識 Railsは、コードベースが千行を超えると、テストスイートが遅くなりがちで、フレームワークのロードタイムが増える。 よくあるのは、ビジネスロジックのほとんどがActiveRecord /m

  • 検索エンジンLuceneの歴史とこれから - ワザノバ | wazanova

    http://www.youtube.com/watch?v=5444z-L2V2A 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 Luceneのオリジナルの開発者であるDoug Cutting(ClouderaのChief Architectと Apache Software FoundationのDirectorを兼務)が、Luceneの歴史と今後の展開を紹介しています。 検索サイトExciteに勤務していた1997年に開発開始。当時新しくでてきたJavaを使ってみたかった & ネットバブルが弾けるのが不安で何かかたちに残るものをつくっておきたかった。2000年にオープンソースとして提供。Solrは2006年、Solr Cloudが2012年。昨年にはHadoopプラットフォームの検索エンジンに

  • 給与をあげるベストな仕組みの解がない - ワザノバ | wazanova

    https://saastr.quora.com/By-The-Time-You-Give-Them-a-Raise-They%E2%80%99re-Already-Out-The-Door 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 1) 意義のあるチャレンジングな仕事をすること、2) 刺激をもらえる優秀な仲間と仕事ができることは、3) 高い給与をもらえることよりも優先度が高いという意見に100%賛同していますが、今日は1) 2)のことはさておき、3) の給与、特に昇給の話しをしたいと思います。 原文 は、EchoSignのFounderであったJason M. Lemkinが、優秀なメンバに会社に残ってもらうために心がけていたことを紹介しています。 #1. By The Time You Gi

  • AngularJSとRails4を組み合わせる - ワザノバ | wazanova

    https://shellycloud.com/blog/2013/10/how-to-integrate-angularjs-with-rails-4 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 Railsアプリのホスティングサービスを提供しているShelly Cloudがブログで、フロントでAngularJS、バックエンドでRails 4を採用するときの留意点について、まとめています。使用しているコードサンプルはこちらになります。 1) Building a JSON API in Rails RailsAPIをいちから作ってみる。angularjs-rails-resourceのようなライブラリを使うときは詳細が違ってくるが、考え方は概ね同じ。 Routing namespace :api

  • Stack Overflowのアーキテクチャ - ワザノバ | wazanova

    http://www.youtube.com/watch?v=OGi8FT2j8hE1 comment | 0 pointsドイツのハンブルグで開催されたDeveloper Conference 2013で、Stack Overflowのアーキテクチャが紹介されてます。 Stack Overflowのネットワークは、110 Q&Aサイト、430万ユーザ、質問760万件、回答1360万件、月間5億6千万ページビュー サーバ25台: ウェブサーバ11台(内9台でほぼトラフィックさばく)、ロードバランサ1台 (+ 予備1台)、DBノード4台、アプリサーバ3台、検索サーバ3台(Elasticsearch)、Redisサーバ2台(キャッシュ、メッセージング) 毎秒質問が投稿されているので、トップページには都度最新の質問を掲載するように更新はできないが、ユーザの回答パターン、質問閲覧パターン、好みのタ

  • [その1] Ruby 2.0のガベージコレクタを使いこなす - ワザノバ | wazanova

    http://samsaffron.com/archive/2013/11/22/demystifying-the-ruby-gc Ruby 2.1のガベージコレクタ (GC) については、「RubyPythonの違いからガベージコレクタを理解する [その1] [その2] 」で取り上げましたが、今回は、DiscourseのSam SaffronがまとめているRuby 2.0のGCを利用するにあたっての学びを紹介します。 1) Heaps of heaps MRIはヒープにRVALUEとして知られているオブジェクトをもつ。各ヒープは約16KB。RVALUE構造体は、マシンのアーキテクチャによって異なる量のメモリを消費する。x64マシンでは40 byte、x32マシンではサブアーキテクチャー次第で20 byteから24 byte。RVALUEはマジカルなC構造体で、Rubyの様々なローレベル

  • 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としてよく知られるとおり、人間が良

  • 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は当然揃っていて、ウェルカムランチをへて、必ず初日に番アップまで経験できるような仕組みになってたと記憶してます。事業の成功を担保するためのせっかくの新戦力なので、優先順位は