プレイブック -プラットフォームの選択-

プロジェクトの早い段階で、使用するプラットフォームを決めなければなりません。

どのプラットフォームを使うかは、ユーザの問題を解決するためのアイデアに左右されます。例えば、ユーザが現場の建設作業員なら、モバイルまたはタブレットのインタフェースが最適な選択かもしれません。

ユーザにとって何が最適かを考えた後は、自分たちに最適なツールを考えます。

  • 強力なコミュニティがあるオープンソースのツール
  • 自分たちが幸せになれるツール
  • 制作とイテレーションを素早く行うのに役立つツール

Webアプリ

Ruby on RailsWebアプリは一般的によく使われているので、私たちの経験によれば、早く市場に出せる傾向があり、所有の総コストが低くなります。あるRailsアプリのコードベースは、他のRailsアプリのコードベースに非常に似ています。また、アジャイルとRubyのコミュニティは強く重なり合っており、これは、Rubyの開発者が(何よりも)、テストを書き、オブジェクト指向設計を使用し、コードの繰り返しを避ける傾向にあることを意味します。

私たちがRailsに贈ることのできる最大の賛辞は、私たちが2005年に、Railsに会社の将来を賭けて実際に資金援助を行い、今も生き残っているということかもしれません。

その見返りとして、私たちはコミュニティへの自分たちの貢献、特に、オープンソースライブラリGIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTSの記事を誇りに思っています。

Rubyの他に、私たちはオープンソースソフトウェアと、HTML、CSS、JavaScript、UNIX、VimやPostgresなどのWeb標準を使用しています。その理由は、これらが次の特徴を備えているからです。

  • 高品質である
  • ベンダーの固定化を防ぐことができる
  • コンポーネントを切り替える柔軟性を与えられる
  • 多くのデバイスで機能する
  • 実践によりテストされている
  • 多くの人から見てバグがほとんどない

Ruby on Railsには、次のようなセキュリティ攻撃に対抗するためのプログラマの負担を軽減する特徴があります。

  • クロスサイトスクリプティング(XSS)
  • クロスサイトリクエストフォージェリ(CSRF)
  • SQLインジェクション
  • ヘッダインジェクション
  • ログ内のセンシティブデータ

Railsは、セキュリティに関して正しく行動するために役立ちますが、それでも、努力し、知識を身につけ、包括的なテストをする必要があります。詳細情報については、Ruby on Rails Security Guideを参照してください。

私たちは、Internet Explorer 9.0+および、Firefox、Chrome、Safariの最新バージョンに対応しています。Internet Explorer 6、7、8には対応していませんが、これらのバージョンのユーザに対しては、アップグレード方法についての丁寧なメッセージが表示されます。これらのバージョンのブラウザは市場シェアを失いつつあり、またセキュリティの問題を抱えているので、デザイン・開発・.対応に非常に時間がかかります。

モバイルデバイスでは、iOS Safari 7.1+、Android Browser 4.4+および、Chrome for Androidの最新バージョンに対応しています。

限定的な特殊ケースでは、旧バージョンのInternet Explorerへの対応が必要であることが、ユーザ人口統計から分かります。そのバージョンに対応するための追加の時間と費用を計画するために、このような特殊ケースは早期に特定しなければなりません。

モバイルアプリ

ここで言う”モバイル”とは、ユーザについて述べているのであって、デバイスのことを言っているわけではありません。

モバイルアプリケーションのデザインを考える際には、全てこの枠内で考えなければなりません。すると、以下のような疑問が生じます。

  • 彼らは動いているのか?
  • カウチソファでくつろいでいるのか?
  • 指はどのくらい器用なのか?

まずは、最も利便性の高いプラットフォームから始めましょう。もしそのデバイスにカメラや予定表、アドレス帳などが必要ならば、iPhoneやiPadのアプリのような”ネイティブ”なアプリを選択するのが正しいと言えるでしょう。

他の製品、とりわけ、テキストやイメージ、ビデオやランディングページのような、コンテンツのみから成る製品に関しては、モバイルWebアプリを用いることには妥当性があります。それは、以下のような理由からです。

  • 最新のスマートフォンは全て、HTMLをレンダリングできる
  • BourbonNeatによって”レスポンシブ”なデザインの実装が容易になる
  • 製作とイテレーションを素早く行える
  • 新しいバージョンを、一日に何度でもデプロイできる

私たちのモバイルの開発者は、Objective-Cや、もっと最近のSwiftといったプログラム言語、CocoaのようなiOSのフレームワークについての専門知識を備えています。

私たちは、TitaniumやPhoneGapのプロジェクトは手がけていません。それは、次のような理由からです。

  • 費用: 弊社のデザイナーにとって、iOSとAndroidの両方に対応したプラットフォームを同時にデザインすることは負担となります。画面サイズや解像度、縦横比、期待されるユーザインターフェースのパターンが異なれば、異なるデザインソリューションが求められます。
  • アップグレード版への早期のアクセス: Titaniumなどのサードパーティのアプリは、AppleのNDAなどにより、コーディングを行おうとしても、iOSの新バージョンが一般向けにリリースされるまで待機を強いられます。Appleが推奨するやり方に従えば、何か月も早く、新バージョンにアクセスすることができ、新機能をいち早く使って、私たちのアプリがより新しいと感じてもらえるように工夫することができます。新バージョンの新しい処理方法を使ってみることができるので、コードの行数や時間を節約できるのです。
  • 品質: Appceleratorが提供するのは、Adobe AirやAdobe Flaseのような従来のクロスプラットフォーム技術と同じように、最小公分母的なユーザエクスペリエンスです。”ネイティブ”なコードにコンパイルされるかどうかは分かりませんが、いずれにせよ、”ネイティブ”な感覚を実現することはほとんどできません。

プログラミング言語

私たちがよく使う言語は次のようなものです。

  • Ruby: サーバ側における選択
  • CoffeeScript: クライアント側における選択
  • Swift: iOSアプリ向けの言語

“サーバ側”とは、アプリケーションのホスティング会社によって提供されるサーバ上で実行するコードという意味です。”クライアント側”とは、ユーザのWebブラウザで実行するコードという意味です。

フレームワーク

Ruby on RailsやNode.js、その他のライブラリなどのフレームワークでは、開発者がRubyやJavaScriptなど、ベースとなっている言語の知識を備えていることが前提となります。

私たちがよく使用するフレームワークの例は次のようなものです。

  • Ruby on Rails
  • jQuery
  • Angular.js
  • Ember.js
  • iOS Core Data

フレームワークとは、プログラミング言語において、特定のタスクを簡単に実行できるようにしてくれるライブラリです。家屋の骨組みのように、プログラミングを始める時には必ずそこにあって、プログラムに構造とサポートを提供してくれるのです。

途中でフレームワークを変更するのは困難な場合があります。Railsに特化したコードが多く含まれていればいる程、後からDjangoに変更するのは難しくなるでしょう。この場合の対処として賢明なのは、”初めから書き直す”です。

データベース

データを正しく保存し記憶させておくために私たちが使用しているのが、PostgreSQL(通常は”Postgres”と呼ばれています)です。

これは、30年に渡ってオープンソースとして使われている、とても評価の高いデータベースで、ドキュメンテーションやホスティングプロバイダ、またSQL標準を熟知している開発者から厚い信頼を受けています。

最近では、NoSQLと呼ばれるデータベースが人気を集めてきています。これは”not only SQL”の略として解釈されおり、この異なるタイプのデータベースを開発するのには、多大な労力が注がれました。これはしばしば、教育機関や産業界でのリサーチといった異なるケースで使用されています。

私たちが最も頻繁に使用するNoSQLが、Redisです。アクティビティフィード、タグ、バックグランドジョブ、セッション、トークン、カウンターといった、一時的な膨大な量の読み書きデータを保存するのに使用しています。

Redisはシンプルで信頼性のあるオープンソースデータベースです。パフォーマンスも高く、その予測にも信頼がおけます。異なるデータ設定を柔軟に具現化することもできますが、私たちは主に小規模なデータ構造に対して使用しており、重い画像、ビデオ、テキストドキュメントなどには使用しません。

Redisデータベース上に製品をホストするには、通常Redis to Goを使用しています。

ライセンス

プロプライエタリライセンスとは対照的に、オープンソースプログラムのソースコードは、レビュー、改変、再配布が可能です。ソースコードに対して、何が出来て何が出来ないかは、オープンソースライセンスによって異なります。

オープンソースライセンスは、パーミッシブ型とコピーレフト型に分類することができます。

パーミッシブ型の例:

コピーレフト型のライセンスの例としては、General Publicライセンス (GPL)が挙げられます。

どちらのライセンスにも目的があります。例えば、ソフトウェアに対する著作権保持者の明確化、ユーザに対するコピーや改変、再配布の許可、(修正が加えられていない)ソフトウェアが提供することになるかもしれない潜在的な保証からの著作権保持者の保護、任意で課せられるいくつかの制限などです。

パーミッシブ型では、プログラムの改変、再配布が可能なことに加え、販売することもできます。著作権保持者からの制限や明確な承諾なしに、他のプログラムに埋め込んだり、リンクを張ったりすることができるのです。

コピーレフト型で可能なのは、同じライセンスを所持する他のコードと一緒にコードにリンクを張ったり、配布したりすることだけです。また、同じライセンス下であれば、改変を強要することも可能です。
GPLに改変を行った場合は、それもGPLとする必要があります。

コピーレフト型ではないライセンスは、派生著作物をオープンソースとして公開するように強要することはありません。

また、いくつかのソフトウェアは、パーミッシブ型、コピーレフト型の両方のライセンス下でリリースされることがあります。開発者は、二重ライセンスのコードを使用することによって、よりニーズに合ったライセンスを適用することが可能になるのです。

私たちが使うほとんどのソフトウェアが、パーミッシブ型のライセンスを所持しています。

  • PostgreSQL、PostgreSQLライセンス (BSDベース)
  • Redis、BSD
  • Riby (MRI)、Rubyライセンス (BSDベース)
  • Ruby on Rails、MIT
  • jQuery、Dual MITとGPL