http://www.sitepoint.com/go-rubyists-ii/1 comment | 0 pointsGlenn Goodrichが、Rubyプログラマー向けにGo言語のinterfaceとWeb.goを紹介しています。1回目はまずは、interfaceから。 The Fallacy of Inheritance 継承は些細な修正も実装が面倒になり、コードが複雑になる可能性があります。例えば、Horseクラスと二つのサブクラス、GallopingHorseとSadHorseがあったとします。（その二つはステートの違いだけでなく、まったく性格の違うサブクラスかもしれません。）sadな雰囲気で、gallopをしているhorseがいる場合はどうするか？それぞれのクラスである振る舞いがロックアップされることになるかもしれません。また、type間の関係を考慮しなくてはいけなくなるの

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を用意したら、

http://matt.aimonetti.net/posts/2013/11/30/sharing-rails-sessions-with-non-ruby-apps/1 comment | 0 pointsSpliceのFounderのMatt Aimonettiが、Railsアプリとセッションが共有できる仕組みをGoアプリ用に提供しています。他の言語への移植にも利用できるようです。 RailsとGoのアプリでセッションを共有、具体的には、認証されたRailsのユーザがGoで書かれたエンドポイントにJavaScript APIでコールすることを試してみた。まとめると、 実現可能。こちらのGoパッケージを参照されたし。 Rails 4.0以降にアップグレードすべし。 Railsのセキュリティには批判があるが、最近のソリューションではエキスパートが工夫をこらしている。 RailsはRub

http://cs.txstate.edu/~br02/cs1428/ShortStoryForEngineers.htm1 comment | 0 points 8億円と2千円のソリューション 歯磨き粉工場の生産ラインから空の箱が出荷されてしまうことがあった。生産ラインの現場は、「100%の確率で歯磨き粉をタイミングよく箱に入れることはできない。」という見解。顧客に相当迷惑をかけるということの重大さゆえ、CEOが対策を練る。幹部社員を集めたが、エンジニア部門は手一杯のため、外部の開発会社に発注して解決してもらうことにした。 予算の手配、RFP作成、外注先の選定、と通常のプロセスをたどり、6ヶ月と8億円かけて最新のソリューションを投入。歯磨き粉の箱が想定よりも軽い場合は、警告音とフラッシュライトとともに生産ラインが止まる仕組み。現場の社員が空箱をどけて、ラインの再稼働のボタンを押す。 ほど

http://calendar.perfplanet.com/2013/the-runtime-performance-checklist/1 comment | 0 pointsGoogle ChromeチームのPaul Lewisが、ページ読み込み後、つまりユーザが閲覧する際の、UIレスポンス、スクロール、アニメーションなどサイトパフォーマンスについてまとめています。 まずは60fpsのパフォーマンスを達成する。よって、16ms以上かかるフレームは全て問題とみなす。 1. Large invalidations of layout and styles エレメントでのクラスの変更やJavaScript/CSS transition/CSS animationで直接エレメントのスタイルを変更すると、ブラウザはレンダリングツリーの一部もしくは全部を無効にしてしまう。最悪のケースでは、ドキュ

https://blog.twitter.com/2013/cocoaspdy-spdy-for-ios-os-x1 comment | 0 pointsChromeとFirefoxで利用できるSPDYプロトコルは、HTTP/2.0のベースになりますが、今回TwitterをそれをiOSアプリに提供できるCocoaSPDYをオープンソースで提供しています。こちらとこちらのグラフにあるように、概ね30%スピードアップできるようです。 HTTPをスピードアップするために、SPDYが改善しているポイントは、 TCPコネクションを介して一度に一つのリクエストを送るのではなくて、SPDYは一つのTCPセッションで複数のリクエストを送信し、レスポンスを任意の順番で扱うことができる。 SPDYはリクエストヘッダーおよびレスポンスヘッダーを圧縮できる。ヘッダー同士は、重複するテキストデータがあり、かなり似た

http://firstround.com/article/Evernotes-CTO-on-Your-Biggest-Security-Worries-From-Three-Employees-to-300 セキュリティは本当に大事だけど、会社が小さいうちにものすごいコストをかけた対策はできないので、段階的にやっていくことになるのが典型的なパターンだと思いますが、「では、具体的にどの段階で何をやるのか？」について、EvernoteのCTOであるDave EngbergがFirst Round CTO Summitで自らの考えを紹介しています。 まず、原則として、「導入しようとしてるセキュリティの対策が、守ろうとしていることのリスクよりも低いときだけ、実行する。」こと。会社が小さいときは失うもののリスクも小さいので、対策もおおげさなものでなくということになるが、Tech Crunchに最初

http://samsaffron.com/archive/2013/11/22/demystifying-the-ruby-gc Ruby 2.1のガベージコレクタ (GC) については、「RubyとPythonの違いからガベージコレクタを理解する [その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の様々なローレベル

https://medium.com/p/6e80a46572c7 メンバが増えると自分一人では全部できなくなり、あらゆることがチームに委譲されていくようになりますが、逆に人数が少ないと全体に目が届いてしまうので、リーダーが全ての意思決定をしてしまうことがあると思います。GitHubやValveなど数百人単位の会社が自己管理型の組織運営に取り組んでいる事例を紹介してきましたが、もっと組織が小さいと自律的に動くチームに自然になるかというとそうではなくて、スタートアップからあまり時間がたってない時点で、自己管理型の組織になる芽をつんでしまう可能性があります。と言っている自分も、10人くらいだと全てを決めたくなる衝動にかられる（笑）と思うので、自戒の意味をこめて。 スポーツチーム運営サイトを提供しているBluefieldsの場合、社員7名になった時点での仕事の進め方は、 ２週間のスプリント単位で

http://blog.ycombinator.com/announcing-the-safe-a-replacement-for-convertible-notes 「Web/スマホエンジニアのためにクオリティの高い開発ノウハウがたまる場」をつくりたくてワザノバを始めたという経緯があったので、サイトの趣旨とちょっと違うかなと思い、ワザノバで起業の話しは今まであまり取り上げてきませんでした。しかし、今日は休日なのでちょっと違った話題をということと、Ycombinatorの発表した"Safe"が、手法としてはけっして目新しいものではないですが、エンジニアが起業する環境を整えるという視点から意義のあるものだと思ったのであえて書きます。 起業して一番やらなくてはいけないのは、サービスを磨くこと。当たり前のことですが、現実はそれ以外にやらねばいけないことがあるので、なかなか100%の時間を使えない

https://www.facebook.com/publications/514128035341603/ 1日500件、3,000ファイルに及ぶ本番アップ フロントエンドのコードは1050万行、内850万行がPHP 開発エンジニア1,000名とリリースエンジニア3名 QAやテスターは存在しない 自分でプロジェクトを選ぶ & 自己責任のカルチャーが強い。 1/3のファイルが一人のエンジニア、1/4が二人のエンジニアでメンテされている。 フロントエンドの本番コードベースは一つのものを共有 日常業務ではローカルのgitを利用。本番アップ可能になれば、中央のレポジトリにマージして、それからSubversion（過去の経緯で使っている。）にコミットする 同じエンジニアがコードをコミットする間隔は中央値で10時間 本番にプッシュする前に、担当エンジニア自身でのユニットテストを終え、同僚によるコード

http://blog.gopheracademy.com/day-02-go-1.2-performance-improvements Gopher Academyがブログで、Go 1.2 のパフォーマンス改善点をまとめています。 1) 8kb stack segments goroutineはデフォルトで4,096 bytesのstack segmentsが割り当てられているが、繰り返しのある、もしくは長いcall chain（ほとんどのencoding/*パッケージはこれに当てはまる。）のstack splittingやstack straddlingのある内部ループを含むコードは、パフォーマンスが落ちることで知られていた。10月がRuss Coxが、この値を倍の8kにすることを提案。前提となるJsonEncoderのベンチマークが安定しないという問題があったが、Go 1のベンチマー

http://engineering.zillow.com/the-search-for-mobile-app-test-automation/不動産価格サイトのZillowが、エンジニアブログで、モバイルアプリのテスト自動化のソリューションを比較検討した経緯を紹介してます。 1) 背景 モバイル向けのテストツールを２年半探したが、Robotiumフレームワーク(Android)は1ヶ月ももたずに使えなくなったので、テストケースを定期的に実行するチャンスがなかった。次にKIF (iOS) は、アプリと直接つながったObjective-Cのコードを書かなくてはいけなかったので断念。XcodeのInstrumentsは、ワークしたものの、メンテしきれなくなった。 2) Robotium Drawbacks テストケースごとにコンパイルする必要があった。ANt, pomファイルのメンテナンス。J

http://blog.pop.co/post/67465239611/why-we-chose-api-first-development POPは、簡単にビジネス/アイデアをかたちにするために、1分でドメイン/スタートページ/メアドを用意できるサービスとのこと。彼らが、「APIファースト」で開発しようとした理由を紹介してます。 1) 将来APIを提供できるように 機能を追加する都度、APIが既に準備できているかたちになるので、将来APIを第三者に提供するときもスムーズ。 2) フロント/バックエンドの分離 バックエンドのテンプレートコードがフロントエンドのクライアントビューとやり取りしない仕様にすることで、将来の開発に負の資産を残さない。 3) スケーラビリティ フロント/バックエンドそれぞれを独立してスケールさせることができるので、将来的にメリットがでるはず。 4) 開発言語のバリア

http://www.youtube.com/watch?v=XHed2NGhg2g EvernoteのCEOのPhil Libinは、ロシア生まれのボストン育ち。Evernoteで初めてシリコンバレーに移ってきたという経歴。シリコンバレーの経営者というガツガツしたアグレッシブさはなくて、人の良いおじさんという表現がぴったりです。音楽家/チェスチャンピオン/博士号を複数もつ秀才などを排出した一族の中で、本人曰く特別な才能がある分野がなくて、スポーツも苦手だったが、コンピュータだけには熱中できたという子供時代。 大学時代に友人と創業したEngine5を、運良くネットバブル崩壊の直前の2000年頭に売却。その後創業したCoreStreetでの政府向けのセキュリティビジネスという分野は、実際にやってみたら、あまり面白くなかったと語ってます。その経験から、他の誰かのためのプロダクトでなく、自分のた

http://www.youtube.com/watch?v=Ms-8GcZXiDA PandoDailyのSarah Lacyのインタビューの中で、GitHubのCEOのTom Preston Wernerが、GitHubを創業するまでの半生を語ってます。かなりガッツな人生です。 1999年にサマーインターンとしてスタートアップでJavaで開発をしていて、そのまま誘われて大学をドロップアウト。 しかし、ほどなくドットコムバブルが弾けて、解雇される。クビになった仲間と３人でウェブ開発の会社を起業したが、ビジネスには素人だったため、まったくうまくいかず、他の２人は諦めてあっさり就職。Tomは一人で受託開発を続けるが、あまり稼げず、8枚のクレジットカードを駆使して、$50K (500万円) ほどの借金生活。それでも、結婚して、ローンで家を買って、さらに２番目のローンも組んで、クレカの借金の支払

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

http://rocksdb.org/ RocksDBは、FlashSSDメモリ/RAMに高速でアクセスできる組込み型の永続的key-valueデータストアです。LevelDBのうえに構築されていてCPUコアがたくさんあるサーバでスケーラブルに実行され、高速のストレージを効率的に利用し、IO-bound / in-memory / write-once な作業をサポートします。 （GoogleのLevelDBは「Hood.ie: “noBackend & Off-line first” という考え方」でもちょっと話題にでてました。） 利用用途としては遅延を避けたいケース、例えば、 ユーザの閲覧履歴やステータスを保持するアプリ 大きなデータにすぐにアクセスしなくてはいけないスパム検知アプリ リアルタイムでデータにアクセスするソーシャルグラフ検索のクエリ Hadoopデータのキャッシュに利用し

https://blog.twitter.com/2013/new-tweets-per-second-record-and-how 少し前、8月のTwitterエンジニアブログのエントリーですが、アーキテクチャー変更について触れているポストなので、取り上げてみます。 1) 背景 2010年のワールドカップ時点でのトラフィックがさばききれなかった時点での状況は、 200人のエンジニアが、単一のRailsのコードベースで大量のユーザとトラフィックに対応する構造であった。 MySQLのストレージシステムは、一つのマスタと一時的にシャーディングされるスレーブの構成で、読込み/書込みともにスループットの限界にきている箇所がでていた。 フロントエンドのRubyマシンは期待通りのトラフィックをさばけていなかったが、技術的な解決ではなく、サーバの追加でしのいでいた。 コードベースは、可読性とパフォーマン

http://matt-welsh.blogspot.com.au/2013/08/rewriting-large-production-system-in-go.html Go言語の４周年をテーマにしたgolang.orgのブログで紹介されていた、GoogleのMobile Web Performanceチームに所属するMatt Welshのブログです。大規模な本番システムの作り直しにGo言語を採用した経験を語っています。 1) 背景 C++のオリジナルのコードベースは問題なく作動していたが、何年も複数の目的の違うプロジェクトで共有されていたため、スピーディーに改修するのが難しくなっていた。（何のシステムなのか具体的に書いてないのは残念。。） イメージフォーマットをトランスコードするライブラリはC++で完璧に動作していたので、そのまま残し、それ以外を全てGo言語で書き直した。 元のコード