タグ

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

  • Spotify: iOSのビルド作業時間を短縮する - ワザノバ | wazanova.jp

    http://labs.spotify.com/2013/11/04/shaving-off-time-from-the-ios-edit-build-test-cycle/ Spotifyのブログで、iOSのビルド作業において、XCodeが実行する間の待ち時間を短縮する取組みを紹介しています。 1) 背景 ソースコードをいじった後、XCodeでRunボタンを押してからシミュレータで結果を確認できるまでの時間は、自宅のiMacで平均82秒かかっていた。コマンドラインで確認したところ、linkingで29秒、dSYMファイルの生成で25秒。SpotifyのiOSクライアントのコードベースはかなり大きく、linkerが2,000のオブジェクトファイルをまとめる必要があるので、おそらく取組みがいがあると判断。 2) dSYM file generation dSYMは、OSXの初期、linker

    lesamoureuses
    lesamoureuses 2016/05/08
    warning出てたから気になったけど開発の時はなくていいのか “dSYM bundleは本番リリースには有用だが、開発時点ではなくてもよい”
  • APIの後方互換性を保つ工夫 - ワザノバ | wazanova

    Stripeの決済サービスの成長は、APIが使いやすいというエンジニアの間での評判がかなり寄与したと記憶しています。 同社のAPIは現在、 エンドポイント: 106 バージョン: 65 APIクライアント: 6 ユーザ企業を煩わせることなく後方互換性をしっかり担保したいという方針を守るための工夫を、Amber Fengが紹介してくれています。 1) ユーザが利用するバージョン情報の把握 ユーザ企業が最初にAPIコールをしたときのバージョン情報をStripe側で保管している。それ以降、ユーザ企業はバージョンのことを意識することなく、最初のバージョンのAPIを利用し続けることができるようにしている。ユーザ企業側でバージョンの変更をしたい場合は、ダッシュボードでの設定や、リクエストヘッダーに情報を付加することで可能。 2) バージョンと機能の整合性 YAMLファイルでバージョンとその振舞いの情報

    lesamoureuses
    lesamoureuses 2014/10/11
    "APIロジックを経由してレスポンスが用意作成されると、最後にレスポンス互換性のフィルターが適用され、ユーザの該当するバージョンの最新のかたちにレスポンスを変換"
  • 動的に価格を変えるアルゴリズム - ワザノバ | wazanova

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

    lesamoureuses
    lesamoureuses 2014/05/10
    こういうのは時間を買ってる感じがして好き "最初は値上がり率を受け入れるか、あきらめるかという二択したユーザに与えていなかったが、現在は、「混雑がすぎて平常価格に戻ったら通知する。」という機能をつけた"
  • Carousel by Dropbox: 遅延のない動きを実現する工夫 - ワザノバ | wazanova

    Dropboxは先週iOS、Android向けに発表した写真管理アプリCarouselを発表しました。Carouselの開発にあたり、がまずチャレンジすべき目標は、デバイスのローカルに保存された写真を閲覧するギャラリーアプリにパフォーマンスが劣らないようにすること。その取り組みを同社のエンジニアブログで紹介しています。ポイントとしては、ユーザのアクションを邪魔しないこと。 1) 解決すべき問題点 クラウドに保存された写真を閲覧するCarouselにおいて、まず問題になったのは、 写真タブにおいて、ユーザのアクションをサーバと同期させる際に、HTTPSリクエストが待機した状態が起きる。例えば、写真をシェアする場合、このような画面になる。写真を削除する場合も同様。ネットワークの接続がよくなければ、後でユーザは再トライする必要がでる。 Dropboxにアップしてない写真、つまりデバイスのローカル

    lesamoureuses
    lesamoureuses 2014/04/24
    “コンフリクトを避けるために(例えば、同じ写真がユーザのDropboxに複数回追加されないように)、同じハッシュを保持した最初のサーバ側の写真がアップロードのオペレーションを完了し、LUIDを取得することにする”
  • モバイル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コールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ

    lesamoureuses
    lesamoureuses 2014/04/17
    “ルールは、「1スクリーン、1 APIコール、1 セーブ、1 APIコール」”
  • リモートワークには東京がよいのではないかと思った - ワザノバ | wazanova

    http://www.amazon.com/Remote-Office-Required-Jason-Fried/dp/0804137501 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 「リモートワーカーになってみて感じてること」で紹介した37 Singnals のDHHの最新作「Remote: Office Not Required」の日語版がでて、ちょっと話題にのぼってるようですが、東京のスタートアップがリモートワークを成功させるのに向いているのではないかとふと思いました。 リモートで仕事をする際に、オフィシャルな情報の共有はそれほど問題にはならないですが、カルチャーの浸透や日常の何気ない会話のような非オフィシャルの情報共有が、会社を一つにまとめるには重要と言われてます。そこで、 GitHu

    lesamoureuses
    lesamoureuses 2014/02/11
    ミーティング密に詰め込むのは切り替え辛くて効率悪い気がするなぁ
  • 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としてよく知られるとおり、人間が良

    lesamoureuses
    lesamoureuses 2013/11/20
    “153のチャットルームがある。全てのチャットルームに参加するわけでなく、個人単位で選択して参加することで適宜最適化できるので、一時的なものも含めて積極的にルームをつくるようにしている。”
  • 規模の大きい本番システムをGo言語で書き直した感想 - ワザノバ | wazanova.jp

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

    lesamoureuses
    lesamoureuses 2013/11/12
    “Goで苦労していること”
  • Groupon: 単一のRailsアプリから複数のNode.jsアプリへの移行 - ワザノバ | wazanova.jp

    https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/ Grouponのビジネス自体はかつての盛り上がりはないですが、シンプルなRailsアプリが、事業の成長 & グローバル化に従って、アーキテクチャを変えていった過程をエンジニアブログで紹介してるので、参考になればと。 1) まとめ Grouponは、Railsのシングルコードベースを独立した20個のNode.jsアプリにアーキテクチャを変更した。 ページの読み込み時間が概ね50%改善。これはテクノロジーの効果とコードの書き直しでwebページが軽くなったのとの相乗効果。 同じトラッフィクに対してハードウェアが削減できた。 チーム間の依存関係が少なくなったので、新機能リリースのペースが早くなった 同じ機能を複数の国にそれぞれ導入するような冗長さが

    lesamoureuses
    lesamoureuses 2013/11/01
    小さいサービスに分けていくのはいい
  • AngularJSの設計思想 [Google I/O 2013] - ワザノバ | wazanova.jp

    [Video] https://www.youtube.com/watch?v=HCR7i5F5L8c AngularJSのHype (盛り上がり感)があるようなので、GoogleのMisko HeveryとBrad GreenがGoogle I/O 2013でAngularJSの設計思想について語っているのを紹介します。 アプリ開発は、雛形構文(ボイラープレート)を利用しながらデータをブラウザとDBの間でやりとりさせるのが中心で、気づいてみると同じ雛形構文を書く作業をかなり繰り返している。コードを書いてる時間よりもコードを読んでいる方に時間がとられることも多い。この雛形構文を使った作業を極力減らして、アプリに付加価値をもたらすコーディング作業だけを抽出したいと思った。 コーディング作業が効率的になる構造が欲しかった。 フレームワークにテストを組み込むが、フレームワーク自身をきっちりテスト

    lesamoureuses
    lesamoureuses 2013/10/20
    へぇ “3人で6ヶ月携わり、17,000行のコードを書いたが進捗が悪かった。当時、余暇の時間でつくっていたAngularJSを使えば2週間で書き直せると提案し、実際は3週間1,500行で全てを書き直したことで認められた。”
  • 1