タグ

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

  • React CanvasによるモバイルブラウザのUI改善とそれが起きる必然 - ワザノバ | wazanova

    http://engineering.flipboard.com/2015/02/mobile-web/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 ものごとが進化すると、利用するユーザの満足度はあがるので、それを用意する作業量はツールの改善に従って最終的には減っていくのか? スマホが登場して、アプリ上でのスワイプなどの直感的にできる操作や表現の幅が広がり、またディスプレイも改善。では、プロダクトをつくる側がそれに慣れてくると、作業量が減るのか?いや、現実は逆。同じことを実現する作業量は減っても、トータルでは減らない。ブラウザとアプリにまたがって、双方のメリットを取り込もうと、もっとレベルの高いUIを目指した競争が続いています。 David BellonaがTwitter Universityでの

    tarchan
    tarchan 2015/02/23
    >ジェボンズの法則
  • マネージャのいない組織に進化する現実と幻想 - ワザノバ | wazanova

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

  • React Nativeがスマホアプリのフロント開発を変えるのか - ワザノバ | wazanova

    Reactは当初、「Huge step backwards(これではメンテできなくて、かえって大きく後退してしまっている。)」「Rethink established best practives(皆が積み上げてきたベストプラクティスを変えようとしている。)」と揶揄されたりもしましたが、最近は他のJavaScriptフレームワークにもその思想の一部が反映されるようになって、メインストリームに近づきつつあるようです。 さて今回Facebookが、React Nativeを発表 & オープンソースとして公開して話題になっていますが、Tom Occhinoは React.js Conf 2015のキーノートスピーチで、「一度書けば、どのプラットフォームでもうまく動作する。」ではなく、「一度覚えれば、どのプラットフォーム向けにも書けるようになる。」ものであることを強調しています。 同社の開発メンバ

  • Googleのテスト自動化の進化 - ワザノバ | wazanova

    https://www.youtube.com/watch?v=6ZvCU0dht50 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Google Test Automation Conferenceが今年はSeattleで開催されたようです。その中で興味深いと感じた話題をいくつか拾ってみました。 1) 成長を続けるGoogle 会社の規模が大きくなり、歴史を重ねてくると、何事も非効率になりがちですが、Ankit Mehtaが紹介してくれた数字によると、Googleの開発ペースは依然として右肩あがりのようです。 コードのコミットは、1日3万チェックイン。約3秒に1回。グラフを目測した限りでは昨年から約20%増。 リリース数もこの1年でほぼ倍増。 2) テストクローラーを利用してのモバイル実機テストの

    tarchan
    tarchan 2014/11/07
    >アプリの開発者はテストスクリプトを書く必要がなく、Appurifyが保有する数百モデル数千台の実機の上で、テストクローラーがアプリ上を動的にクリックしながら巡回してくれる。その結果を自動的に録画されたビデオ、
  • Squareの内部APIの仕組み - ワザノバ | wazanova

    http://corner.squareup.com/2014/09/squares-api.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 SOAにおけるサービス間のコミュニケーションについては、CODE CLIMATEにおいて、Protocol Buffers vs JSONという比較が取り上げられていて、「ブラウザやJavaScriptが直接データを利用しないケース、特に内部サービス間のコミュニケーションにはProtocol Buffersの方が向いているのでは。」と紹介されています。 せっかく整合性のあるデータ構造を用意しても、サービス間のデータのやり取りの際に苦労させられることが多い。Protocol BuffersならProtoフォーマットにしてエンコーディングするだけで、意図す

    tarchan
    tarchan 2014/09/08
    >ProtobとPilgrimはオープンソースとして提供されています。
  • アプリがすたれていくという論点 - ワザノバ | wazanova

    http://tech.fortune.cnn.com/2014/04/10/evernote-ceo-apps-will-become-obsolete/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 ここ最近、「モバイルではアプリが圧倒的にトラッフィクを占めてきていて、ウェブが劣勢。」という記事が日米いずれでも話題になってますが、Chris Dixonがブログで下記の問題提起をしたように、モバイルでウェブが復権してほしいと思っている開発者はそれなりにいるかと。 もっとも恐ろしいのが、理由を言わず、もしくは根拠なしにアプリがリジェクトされること。(例えば、AppleはBitcoin関連のアプリを全てリジェクトしている。)我々は、ウェブのオープンなアーキテクチャのおかげで素晴らしい実験の場を享受して

    tarchan
    tarchan 2014/04/17
    >長いセッション時間のコンピュータは、ファイルやDBのあるパワフルなソフトがぴったり。モバイル電話だと2分程度のやりとりを前提としたアプリが向いている。
  • エンジニアのベストプラクティスを非エンジニアチームで活かす - ワザノバ | wazanova

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

  • 前任者が悪いのかもしれないけれど - ワザノバ | wazanova

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

    tarchan
    tarchan 2014/04/01
    “過去を批判する短期間のヒーローになるのでなく、いつでも適切な判断ができるチームプレーヤーになり、長期のヒーローになろう。”
  • 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のルールを定義する必要が生じた場合は、一貫性を維持し

    tarchan
    tarchan 2014/03/23
    >SQL DBのシェルのようなAPI、つまりデータをどう保存しているかを反映させたAPIでなく、どのようにAPIが使われるのかを考慮してAPIをつくるべき。
  • GitHub の ATOM が CoffeeScript で書かれているのはどうなの? - ワザノバ | wazanova

    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 をすぐに使うほぼ完璧な機会なのに、という問題提起があり、それについて議論があったようです。 前提として、GitHubJavaScript Styleguide に 新たに JS を書く時は CoffeeScript で書くこと 新たに .js ファイルを追加することは避けること と書かれていて、GitHub の中の人としては

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

    tarchan
    tarchan 2013/11/22
    >インフォーマルな会話を共有するためのアイデア(オフィス内を巡回して社内の雰囲気をiPadで中継する機器とか、チャットルーレットのように社内のランダムな人とビデオチャットをして社内の知り合いを増やすとか)
  • Twitter: 大きなトラフィックに耐えうるアーキテクチャーへの変更 - ワザノバ | wazanova.jp

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

  • スケール可能なTwitterの負荷テストの仕組み [GTAC 2013] - ワザノバ | wazanova.jp

    [Video] http://www.youtube.com/watch?v=99RABfKNfcY [Slide] http://goo.gl/9VY2b TwitterのJames Waldropが、オープンソースのロードジェネレータライブラリlagoと、スケールが可能な負荷テストの仕組みについてGTAC (Google Test Automation Conference) 2013で語ってます。Twitterには番トラフィックの一部を利用したテストもありますが、講演ではテスト環境でのロードジェネレータを話題にしてます。 FacebookからTwitter転職し、lagoをつくった理由は、 ありあわせのツールをもってきて使ってもだめで、エンジニアであれば何か開発しないと他のエンジニアから尊敬されない。 Scalaで書いてみたかった。 既存のロードジェネレータはどれも役に立たない

    tarchan
    tarchan 2013/10/03
    >Twitterではlagoのおかげで、新しい開発エンジニアも30分ほどで負荷テストが書けるようになる。
  • GoogleのCIとテスト自動化の取り組み [GTAC 2013] - ワザノバ | wazanova.jp

    [Video] http://www.youtube.com/watch?v=nyOHJ4GR4iU [Slide] http://goo.gl/76Ggf Google Test Automation Conference 2013のキーノートスピーチで、GoogleのAri Shamashが同社のCIツール & 自動化されたテストプロセスを紹介しています。 [最初の前置きが13分。GoogleのCIの紹介の内容ではないので割愛。お話としては面白いのでVideo見てみてください。] エンジニア1,5000+人が5,000プロジェクトにアサインされている 1億行のコード。50%が毎月更新。 1日当たり5,500+件がサブミッションされ、1億件以上のテストケースが実行されている。 Googleのクラウドテストシステムは多機能。ビルド作成、特定のターゲットをテストでき、テストカバレッジ計算、依

    tarchan
    tarchan 2013/10/03
    >オフィスのモニターにダッシュボードが表示さえており、開発が進捗するにつれてテストカバレッジ率があがっている担当者はグリーンで表示される。グリーンのステータスになろうというポジティブな競争が組織の中で
  • できるエンジニアだけで組織をつくる - ワザノバ | wazanova.jp

    http://www.slideshare.net/bcantrill/surge2013 上記のスライドは、JoyentのSVP, EngineeringであるBryan Cantrillがエンジニア組織のあるべき姿ついてまとめたものです。BryanはSun Microsystems出身で、同社がOracleに買収されたのを受けて、2010年にJoyentに移ったという経歴。Joyentはクラウドサービスの会社ですが、Node.jsのスポンサー企業として知られ、Node.jsの中心人物であるIssac Schlueterなどフルタイムでオープンソース開発に従事する社員がいます。昨年、Greylock, Intel CapitalなどからSeries Dラウンドで$85Mの資金を調達してますので、投資家からは上場を期待されていると思われます。 彼の意見としては、 [モチベーションをあげるポ

    tarchan
    tarchan 2013/10/03
    >これからの会社体はオープンソースをビジネスに取り込むことを当然のようにやっていかないと、Joyentのような会社との採用競争には勝てないでしょうから、見習うべき基本形だとも言えるかと。
  • 1