Deisは、Heroku的なワークフローを実現する Docker/CoreOSベースのPaaSです。オープンソースのプロジェクトですが、既にOpDemandが運営会社になっており、同社はこれまでに約2.5億円の資金調達も完了してます。フルタイムでオープンソース開発を担当する正社員の募集も始まって、最新バージョンは0.9.1という段階のようですので、これから本格的に立ち上がっていくのでしょうか。 Deisのクリエーターであり、OpDemandのFounderでもあるGabriel Monroyのが、dockdercon 2014でDeisのこれまでの進捗を紹介しています。 Deisは最初のマルチホストDocker PaaS。最初はPythonで書いていたが、最近はGoが中心。 フルタイム５名 + ~40名のコントリビューター すぐにプロトタイプをだしてコミュニティからのフィードバックをもらお

https://www.youtube.com/watch?v=-KFe5pGMFbo 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Uberは、配下のタクシーの乗車率を最大化して、かつ顧客の不満「タクシーがつかまらない!」「呼んだタクシーがくるのが遅い!」を下げるために、タクシーがつかまりづらい時間帯は動的に価格が上がる仕組みにして、需給バランスの最適化を計ってます。 最初はしばらく手動で値上がり率を入力して、データを蓄積。それからアルゴリズム化した。 都市ごとに係数は変えている。大きな都市では、空きタクシーの検索範囲は市全体でなく時間帯で適切なエリアだけをカバーするかたちに変えた。 最初はその時間に適用される値上がり率を、へりくだったお詫び的なテキストの中で表示していたが、請求されてから気づく酔

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コールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ

http://www.developingsales.com/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約6時間前 Jeff SzczepanskiはStack Overflowのマネタイゼーションの責任者。エンジニア転じて、営業の組織の長になった人物。 「営業というのは科学というよりは芸術。コンピュータ相手じゃなくて、人間を相手にしているからね。」 「営業が結果を重視するのは、計測しやすく公平な指標だから。どうなるか予想したりプロセスをうまく管理するのは難しいんだよ。」 という話しに違和感を抱き、「誰かが決めた営業戦略に従って営業マンは盲目的に数字の達成だけを求めてひたすら実行する。」という従来の営業手法は、 自分で手を汚してコーディングしない「アーキテクト」と呼ばれる人が仕様書をまとめ、下々のエンジニ

https://medium.com/p/506a06ae35ea 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 自分は最初に手がける立上げ仕事がほとんどだったので、他人のタスクを引継ぐよりは、次の方にバトンタッチすることが多かったと思います。右も左もわからない状況から始める立上げ仕事は、楽しいけれど、前に進めるだけでそれはそれで大変。なので、引継ぐときは「頑張ったね。」と自分に言ってあげたいというのが本音。とはいえ、引継いだ人が後から見れば、相当アラい仕事ぶりに思えたでしょう。大成功してないプロジェクトについては全て、批判は甘んじて受け入れるべきなのかもしれません。 Shamoon Siddiquiはブログで、安易に前任者の責任にする危険性について語っています。 新しく採用した後任のエンジニアが入

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のルールを定義する必要が生じた場合は、一貫性を維持し

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

http://labs.spotify.com/2014/02/28/how-to-shuffle-songs/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 SpotifyのLukáš Poláčekがプレイリストをシャッフルするロジックを改善した取り組みを紹介しています。 以前のロジック ランダムアルゴリズムには、Fisher-Yates shuffleを利用。 順次再生する曲を選ぶロジック同士には依存関係がなく、完全にランダムに選択される。よって、同じアーティストとの曲が連続して再生されることも可能性としてはある。 これはギャンブラーの誤謬と呼ばれる現象。例えば、コイントスで表が連続してでると、次は裏が出ると思いがちであるが、常に確率は1/2である。従前の結果が次の結果に影響を与えると考えてし

http://discuss.atom.io/t/why-coffeescript/131 2 comments | 2 points | by noto ■ comment by noto | 約1時間前 先日 GitHub が発表してエディタ ATOM のディスカッション・フォーラムでなぜ CoffeeScript で書かれていて、EcmaScript 6 (ES6) じゃないの? node.js/V8 を利用するデスクトップアプリケーションなら ES6 をすぐに使うほぼ完璧な機会なのに、という問題提起があり、それについて議論があったようです。 前提として、GitHub の JavaScript Styleguide に 新たに JS を書く時は CoffeeScript で書くこと 新たに .js ファイルを追加することは避けること と書かれていて、GitHub の中の人としては

[Podcast] http://5by5.tv/changelog/100 GoogleのRob PikeとAndrew GerrandがThe Changelog PodcastでGoプログラミングについてインタビューを受けてます。 Goは３年半前に最初にリリース。Cのようなローレベル言語とRubyやPythonのようなスクリプト言語と中間の位置づけ。C++のようい何でも機能があるものではなく、シンプルであることがコアバリューで一貫性がある言語。 使ってもらうとどれだけ生産的で早いが実感できる。先日のプロジェクトで全部のテストプログラミングが8ミリ秒で実行できた。プログラマにとって効率的だが、コンピュータにとっても効率的。 Rubyのように同じことをあらゆる書き方で実現できるのではなく、一つではなくてもある程度決まった書き方でロジカルに解決するのが、プログラマー間での共通の理解、コード