Carousel by Dropbox: 遅延のない動きを実現する工夫

約3年前 | 1 point

Dropboxは、先週iOS、Android向けに写真管理アプリCarouselを発表しました。開発にあたり、まず目標になったのは、デバイスのローカルに保存された写真を閲覧する仕組みのアプリと比べて、パフォーマンスが劣らないこと。その取り組みが同社のエンジニアブログで紹介しています。ポイントとしては、ユーザのアクションを妨げないスムーズさを実現すること。

1) 解決すべき問題点

クラウドに保存された写真を閲覧するCarouselにおいて、まず問題になったのは、

  1. 写真タブにおいて、ユーザのアクションをサーバと同期させる際に、HTTPSリクエストを待機した状態が起きる。例えば、写真をシェアする場合、このような画面になる。写真を削除する場合も同様。ネットワークの接続がよくなければ、後でユーザは再トライする必要がでる。

  2. Dropboxにアップしてない写真、つまりデバイスのローカルにしかない写真の閲覧...

アプリがすたれていくという論点

約3年前 | 2 comments | 3 points

ここ最近、「モバイルではアプリが圧倒的にトラッフィクを占めてきていて、ウェブが劣勢。」という記事が日米いずれでも話題になってますが、Chris Dixonがブログで下記の問題提起をしたように、モバイルでウェブが復権してほしいと思っている開発者はそれなりにいるかと。

もっとも恐ろしいのが、理由を言わず、もしくは根拠なしにアプリがリジェクトされること。(例えば、AppleはBitcoin関連のアプリを全てリジェクトしている。)我々は、ウェブのオープンなアーキテクチャのおかげで素晴らしい実験の場を享受してきた。創業時点では物議をかもしたスタートアップはたくさんあったが、もしAOLなどの当時のゲートキーパー的な事業者がウェブをコントロールし、開発者がGoogle / YouTube / eBay / Paypal / Wikipedia / Twitter /...

責任であることと、そうでないことの境界線

約3年前 | 1 point

net awards 2014のConference Talk of the YearにノミネートされているMike Monteiro (Mule Design Studio) のWebstock 2013での講演 "How designers destroyed the world." です。デザイナーの責任というテーマなのですが、どの仕事をする上にも共通するちょっと重たい話しです。

まず取り上げているのは、2012年10月にWall Street Journalに掲載された記事

ある大学生が、Facebookのプライバシー設定を工夫して、自分がゲイであることがわかる情報を、Facebookでもつながっている父親から閲覧できない状態にしていた。ところが、その大学生が所属していたコーラスグループのFacebookページの管理者が、...

クラウド各社の値下げ合戦

約3年前 | 1 point

各社が競うように値下げしているニュースには気づいていましたが、中身はチェックしてませんでした。そのうち誰かがまとめてくれるだろうと思ったら、Adrian Cockcroftが詳細解説したブログをあげてました。まとめのところだけを紹介します。もし誤ってる情報があればご指摘ください。

  • AWSユーザは、古いm1, m2, c1, c2から、新しいm3, r3,c3のインスタンスに移行し、Intelの最新CPUのパッフォーマンスをより安い価格で享受すべき。
  • AWSのm1シリーズを対象にしたクラウドのベンチマークやコスト比較をするのは不適切。
  • AWSとGoogleのインスタンス単価は、基本的には同様のスペックで同じ価格帯になる。
  • Microsoftは最新のIntel CPUを採用してないようで、AWSの古いインスタンスに価格を合わせている。
  • IBM Softlayerの価格は依然高め。...

エンジニアのベストプラクティスを非エンジニアチームで活かす

約3年前 | 1 point

Jeff SzczepanskiはStack Overflowのマネタイゼーションの責任者。エンジニア転じて、営業の組織の長になった人物。

「営業というのは科学というよりは芸術。コンピュータ相手じゃなくて、人間を相手にしているからね。」

「営業が結果を重視するのは、計測しやすく公平な指標だから。どうなるか予想したりプロセスをうまく管理するのは難しいんだよ。」

という話しに違和感を抱き、「誰かが決めた営業戦略に従って営業マンは盲目的に数字の達成だけを求めてひたすら実行する。」という従来の営業手法は、

自分で手を汚してコーディングしない「アーキテクト」と呼ばれる人が仕様書をまとめ、下々のエンジニアが決められた通りにコーディングするウォーターフォール型のソフトウェア開発

と似ているのではないかと気づきます。

また、営業マンが目標を達成できなかった時に、

「お客さんごとに色々状況が違って。。」

「...

JavaとNode.jsとエンタープライズIT

約3年前 | 3 comments | 1 point

IBMのDejan GlozicはかつてJavaがデビューして間もない時期に、後にEclipseに進化するJFaceを書いた人物。Node.jsとエンタープライズIT市場の関係について、

自分が(IBMのミドルウェアツールとの連携という)問題を解決するように頼まれたのはJavaがまだ2年しか経ってないとき、そして、Eclipseプラットフォームをつくる膨大な作業もJavaベースで、それはJavaが生まれて4年たったとき。…当時の人々はJavaに対して懐疑的であったけど、それでも、Javaを進化させ、疑念を解消するために直すべきことは何でも直すという勢いが止まることはなかった。エンタープライズITの世界には、やんちゃであった子供時代を忘れてしまい、口うるさく注意するようになった親のような人たちがいるようだけど、...かつて恐れを抱かず前に進んだように、...

Spotifyのエンジニアカルチャー

約3年前 | 1 point

Spotifyのエンジニア組織については、「Scaling Agile @ Spotify を読み直す」で詳しく紹介しましたが、Squadと呼ばれる、自律的に働く機能開発単位の小さなチーム構成が特徴です。今回は13分12秒の短いビデオで、そのエンジニアカルチャーがよくまとめられてます。

1) Alignment + Autonomy

戦略に沿った方向性の一致と自律性の維持を両方実現する。リーダーの役割は、「どの問題が解決されるべきで、その理由は何故か。」をコミュニケートする。Squadは協力して、実際にどうexecutionしてその問題を解決するかを任されている。

2) Internal open source

各Squadは自律的に仕事しているものの、社内でソースコードは公開されているので、依存先の他のSquadのコードにもプルリクエストするカルチャーがある。同僚のレビューをへて、...

前任者が悪いのかもしれないけれど

約3年前 | 1 point

自分は最初に手がける立上げ仕事がほとんどだったので、他人のタスクを引継ぐよりは、次の方にバトンタッチすることが多かったと思います。右も左もわからない状況から始める立上げ仕事は、楽しいけれど、前に進めるだけでそれはそれで大変。なので、引継ぐときは「頑張ったね。」と自分に言ってあげたいというのが本音。とはいえ、引継いだ人が後から見れば、相当アラい仕事ぶりに思えたでしょう。大成功してないプロジェクトについては全て、批判は甘んじて受け入れるべきなのかもしれません。

Shamoon Siddiquiはブログで、安易に前任者の責任にする危険性について語っています。

新しく採用した後任のエンジニアが入社後数日で、「このライブラリはアップデートすべき。」「JIRAを再整理しましょう。」「やばいバグを見つけました。」「なんでこのフレームワークを採用したの?」「どうしてDBはこれを使ってるの?」「...

高負荷データ処理の各社の事例

約3年前 | 1 point

Hakka LabsのFounderのPete Soderlingが、「何でもBig Dataと称する風潮は行き過ぎだが、処理すべきデータが増えてきているのは確か。」として、データ処理プロセスでの各社の取り組みを紹介しています。

Stripe

HDFSには、JSONやBSONなど多様なフォーマットのデータを送っている。Thriftとでロジカルな構造を定義し、Parquetでディスクに保存するフォーマットを決めている。複雑なバッチ処理のツールとして利用しているTwitterのScaldingフレームワークとの相性もよい。

次のポイントは分析クエリを高速化するための非正規化処理。Scaldingでほとんどのjoin処理をし、Thriftのスキーマを用意する。同時に、IPアドレスのジオコーディング、ユーザエージェントstringの解析、抜けている値の整理などをする。その結果、...

リスクだと思うほどリスクの高いことはない

約3年前 | 2 points

Hacker SchoolのNicholas Bergson-Shilcockが2011年のブログで、Sam Altmanからもらったアドバイスについて語っています。

nothing is ever as risky as you think it is. (リスクだと思うことほどリスクが高いことはない。)

リスクにつまずいて失敗すると「リスクを把握できてなかった。見過ごした。」と後から厳しい評価を受けます。また逆に、「こんなことになる可能性があるからやめておけ。あんなことになる可能性があるからやめておけ。」と自称 "経験"から老害的な批判をすることで、良い提案の芽をつぶしてしまうこともありえます。本当にどれくらいのリスクなのか、得ることができるメリットと比較してどうなのか、冷静に判断しなくてはいけません。

このアドバイスは、リスクをあまり考えるなということではなく、...

Ruby RoguesメンバとiOSエンジニアのAPI議論

約3年前 | 1 point

iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。

1) Follow Conventions

はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持してconventionにすること。誰が定義するにしろ一貫性が大事。

2) Don't Be Clever

人はとかく賢さを誇示したくなるものだが、ものすごく凝った仕様にすると物事が複雑になる。APIをつくるときはとにかくシンプルにすること。利用者の希望は、...

Angular 2.0

約3年前 | 1 point

クライアントサイドの JavaScript フレームワークである AngularJS の公式ブログで Angular 2.0 の実装が始まったことがアナウンスされ、設計に関しての考え方、なぜ変更しようとしているか、詳細な変更点などについて述べてられています。Angular のもともと持っている特徴もおさえつつ説明されているので、Angular の復習にも良さそうです。

Angular 2 は mobile apps のためのフレームワーク (デスクトップにも利用できる)。data-binding、extensible (拡張可能な) HTML、テストのしやすさの重視については変わらない。

Angular 2 のすべての design docs は Google Drive で公開されている。このドキュメントでは、我々のアプローチの概要や設計方針が、個々の設計へのリンクとともに示されている...