JQ Blog

Hybrid, Native, Responsive

Mobile Applicationの種類


1. Native Application
2. Hybrid Application
3. Responsive Web Application

Native Application

Native Appの開発でアプリはios, androidなどの特定のMobile Platformに合わせて作成することになり、一般的にはPlatform会社の開発道具を使用して作られます。他のPlatformにはコードの再使用はできません。

メリット

• 性能が高い（特にゲームの場合）
- グラフィックユーザーインターフェース、速度など
• デバイスの全ての機能を使える（センサー、カメラ、連絡先など）
• Appleのアップストア、GooglePlayなどの公開アップストアを通して配布

デメリット

• 開発者不足
• Platform別にそれぞれアプリを作るため費用を使う
• Platform別にコードベースを管理するため費用と時間を使う
• 長い開発期間
• 開発のかかる時間で各Platformのバージョンがそれぞれになる可能性がある
• 各アップストアの承認手順を待たなきゃいけないのでアプリの配布が遅くなる可能性がある

開発道具

• Apple: XCode
• Android: Android Studio, eclipse

Responsive

HTML 5, CSS, JSなどを使用して作るWeb Application。デバイスのブラウザーを通して接近できます。デバイスの機能を使用することが難しいです。

メリット

• 既存Web開発者を活用して作れる
• 費用が一番安い
• 一つのコードベースだけ管理する
• 早く編集、アップデートや配布が可能

デメリット

• インターフェースが標準Native Appと違う可能性がある
• マルチメディアの性能がよくない
• デバイスの機能を使うことが難しい

開発道具

HTML 5, JS, CSSを使ってWebを作ることに使用される全ての開発道具はResponsive Web Applicationを作ることができます。
• AngularJS - Googleが管理しているopen source web application framework
• Ember.js - open source javascript web application framework
• React - facebookが管理しているopen source javascript library
• JQuery - javascript library
• Bootstrap - Responsiveを優先するCSS framework

Hybrid Application

Hybrid ApplicationはResponsive AppをMobile Platformで実行するAppになります。ウェブ標準を使用するが最終アプリはデバイスでnative appで実行されます。Native AppとResponsive Appのメリットだけ合わせるように誕生した。

メリット

• ウェブ標準を使用して作る（APIやデバイスの機能に接近するためコーディングが必要
• 既存ウェブ開発者を活用して開発可能
• 早く編集、アップデートや配布が可能
• 各PlatformでNative Appで実行する

デメリット

• インターフェースが標準Native Appと違う可能性がある
• Native Appよりは性能がよくない
• 一般的にデバイスの全ての機能が使えるが新たな機能は少し時間がかかる
• Platformによってそれぞれ違うコードベースにしなきゃいけない

開発道具

• Apache Cordova - HTML 5, CSS, javascriptを使用しているResponsive Appを基盤にしてNative Appをbuildするopen source platform
• Adobe PhoneGap - Adobeが作ったApache Cordovaの変形
• Alpha Anywhere - Responsive Appを作ってそれをNative Appに配布するようにしてくれる開発環境
• Ionic Framework - AngularJSやCordovaと連携してResponsive Appを基盤にしてNative Appをbuildするユーザーインターフェース中心のframework

b#まとめ

参照

http://www.itworld.co.kr/news/95791

HAML & Slim

HAML (HTML Abstraction Markup Language)

インラインコードを使わなくてウェブHTML文書を記述することに使用するマークアップ言語です。PHPやASP、ほとんどのRubyOnRails Applicationで使用されています。コードが簡単になる長所がありますが、デザイナーやパブリッシャーとの協業が必要なプロジェクトには使用が難しくなる短所があります。

Gem HAMLのインストール

HAMLのGemをプロジェクトに追加します。Gemfileを開いて、 次のコードを「追加」します。

gem 'haml-rails'

そしてインストールします。

bundle install

これからHAMLを使えます！！

書き方

一番基本的な記法

(例)

!!!
%html{lang: "ja"}
  %head
    %meta{charset: "utf-8"}
  %body
    hello world!



<コード解説>

1.!!!
<!DOCTYPE html>を表す
2.%
タグの前に%を付けると<開始タグ>と<終了タグ>を表す。%html => <html></html>
3.インデントを必ず入れる
親子関係のタグは必ずインデントを入れて関係性を作る。
4.属性を入れる場合
Ruby風に{}とシンボルで書ける。
また、HTML風に書くなら「%html(lang=“ja”)」

こんなにもできます。

%div{id: "my-id"} Contents
%div{class: "my-class"} Contents

ちなみにidやclassは次のように書いても同じものが表示されます。divタグの場合のみ%divを省略することもできます。

#my-id Contents
.my-class Contents

これをHTMLで書くと、

<div id="my-id">
    Contents
</div>
<div class="my-class">
    Contents
</div>

こういうふうになります。

HTMLに記述されないコメント

次のように-#をつけて書いた文字列はHTMLには記述されません。

-# test comment


HTMLに残すコメント

HTMLに残すコメントはHAMLでは次のように書きます。

/ This is the peanutbutterjelly element

すると、

<!-- This is the peanutbutterjelly element -->


Rubyの変数を使う

HAML内ではRubyの変数を簡単に呼び出せます。

- text = "good"
- text2 = 'HAML'
%div{class: hoge}
    test message is #{text}
    = text2

これをHTMLに変換すると次のようになります。

<div class="good">
    test message is good
    HAML
</div>


Rubyのif文やcase文を埋め込む

Rubyのif文やcase文も埋め込むことが可能です。

%p
  - case 1
  - when 1
    = "1!"
  - when 2
    = "2?"
  - when 3
    = "3."


Rubyのブロックを使う

- (42...47).each do |i|
  %p= i
%p See, I can count!


Slim

SlimのgithubページにはSlimを “Slim は 不可解にならないように view の構文を本質的な部品まで減らすことを目指したテンプレート言語です。標準的な HTML テンプレートからどれだけのものが削除できるか確かめるところから始まりました。(<, >, 閉じタグなど) 多くの人が Slim に興味を持ったことで, 機能性は発展し, 柔軟な構文をもたらしました” と紹介しています。

Gem Slimのインストール

gem install slim

Slimの書き方

まず、HTMLとSlimを比べてみると、

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Jo's Training</title>
  </head>
  <body class="sample">
    <div id="contents">
      <h1>Sample File</h1>
      <img alt="sampleImage" src="http://www.jotraining.com/images/sampleImage.jpg" />
      <p>テキストテキストテキスト</p>
      <p>テキストテキストテキスト
        テキストテキストテキスト</p>
    </div>
  </body>
</html>

上記のようなHTMLは

doctype html
html
  head
    meta charset="utf-8"
    title Sample File
  body.sample
    #contents
      h1 Sample File
 
      img src="http://www.e2esound.com/images/yterajima.jpg" alt="yterajima"
 
      p テキストテキストテキスト
 
      p
        | テキストテキストテキスト
          テキストテキストテキスト

Slimではこういうふうに書けます。
Slimはインデントを用いてHTMLの入れ子を表現します。このインデントの深さは自由に決めることができます。

3つのポイント

1.通常のHTMLから <, >, /> を取り除く
2.doctype
3.テキストと | (パイプ)の扱い
4.コメント

通常のHTMLから<, >, />を取り除く

上記の例を見ると

<img alt="sampleImage" src="http://www.jotraining.com/images/sampleImage.jpg" />
 
img src="http://www.jotraining.com/images/sampleImage.jpg" alt="sampleImage"

doctype

上記のslimの1行目、doctype htmlはHTMLの<!DOCTYPE html>を表しています。

XML 宣言

doctype xml
  <?xml version="1.0" encoding="utf-8" ?>
 
doctype xml ISO-8859-1
  <?xml version="1.0" encoding="iso-8859-1" ?>

XHTML ドキュメントタイプ

doctype html
  <!DOCTYPE html>
 
doctype 5
  <!DOCTYPE html>
 
doctype 1.1
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
 
doctype strict
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 
doctype frameset
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
 
doctype mobile
  <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
    "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
 
doctype basic
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
    "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
 
doctype transitional
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

HTML 4 ドキュメントタイプ

doctype strict
  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
 
doctype frameset
  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
    "http://www.w3.org/TR/html4/frameset.dtd">
 
doctype transitional
  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">

コメント

Slimのコメントには変換後出力されるコメントとされないコメントの2種類があります。

HTMLに記述されないコメント

/ このコメントは変換後表示されない

HTMLに残すコメント

/! このコメントは変換後HTMLコメントになる
 
<!-- このコメントは変換後HTMLコメントになる -->

参照

http://morizyun.github.io/blog/beginner-rails-tutorial-haml/ http://qiita.com/watak676/items/525ad3d8a1297e3244e3 http://qiita.com/yterajima/items/53fd0387279510ff082a https://github.com/slim-template/slim/blob/master/README.jp.md

Asset-pipeline

Assetとは

RailsにはJavaScriptやCSS、Imageなどの要素をアセットと呼びます。アセットはそれぞれに ‘app/assets/javascripts/'、 'app/assets/stylesheets/'、 'app/assets/images’ フォルダーで管理します。 Railsは基本的にJavaScriptとCSSの拡張言語のCoffeeScriptとSCSSを提供します。

Asset Pipelineとは

JavaScriptやCSS、Imageなどのアセットを最小化(minify)または圧縮して連結するフレイムワーク

Asset Pipelineの役割

1.アセットファイルのパスの管理
2.アセットのコンパイル
3.アセットの依存関係の整理

アセットファイルのパスの管理

Assetsの中のパスの管理をします。

/assets/javascript/user.js
/assets/stylesheet/user.css

というファイルを

/assets/user.js
/assets/user.css

のように1つのディレクトリで管理されているようにアクセスさせてくれます。

アセットのコンパイル

Javascript、CSSのかわりに、CoffeeScript、SCSSを使うことも多いと思います。browserはCoffeeScriptとSCSSを読めないのでCoffeeScriptとSCSSをJavaScriptとCSSにコンパイルしなきゃいけないです。このように、ファイルを適当な形式に変換してくれる機能をAsset Pipelineと言います。
必要となるgemは以下です。

gem  'sprockets' 
gem  'coffee_script' 
gem  'scss'


sprockets

Asset Pipelineの基盤の機能を提供してくれます。

coffee_script && scss

それぞれCoffeeScript、SCSSを使うためです。

アセットの依存関係の整理

Asset間の依存関係を整理します。このようにファイルの読み込みの順番を管理します。他のファイルに影響を与えないためにコメントアウトの形式で書きます。
app/assets/javascript/application.js

// = require jquery 
// = require jquery_ujs 
// = require_tree.

Railsのアプリケーションでは複数のCSS、Javascriptを1つのファイルにまとめて提供することが主流となっています。それは複数ファイルが存在すればリクエストの数が増えてページの読み込みが遅くなるからです。アプリケーションの内の依存関係をまとめて提供するための仲介になるファイルを「manifest file」と呼び、デフォルトでは application.js、application.css になります。

Asset Pipelineをコントロールする

develpment/productionの設定

設定は/config/environments/ファイルに書きます。

config.assets.js_compressor

Javascriptの圧縮ライブラリの設定。productionではuglifierというgemを利用しているが nilの設定にして無効にすることも出来る。 default設定 development: nil production: :uglifier

config.assets.css_compressor

CSSの圧縮ライブラリの設定。 default設定 development: nil production: :uglifier

config.assets.compile

動的にcompileするかの設定。trueだとprecompileしていないファイルを動的にコンパイルするのでproductionではfalseが良さそうです。 default設定 development: true production: false

config.assets.digest

pipelineを通した後のファイルにつく数字をつけるかどうかです。 default設定 development: false production: true

config.assets.debug

debugするかの設定。 default設定 development: true production: false

precompileの設定

config/initializers/asset.rb

# Precompile additional assets. 
# application.js, application.css, and all non-JS / CSS in app / assets folder are already added. 
# Rails.application.config.assets.precompile + = % w (search.js) 
Rails . application . config . assets . precompile  + =  % w (* .js * application.css)
cs

Asset Pipelineの流れ

production

例えば、下記設定の場合。
/config/environments/production.rb

config . assets . js_compressor  =  : uglifier 
config . assets . css_compressor  =  : sass 
config . assets . compile  =  false 
config . assets . digest  =  true 
# config.assets.debug = false

1.assetにあるソースコードをコンパイル(coffee -> js、 scss -> css)
2.コンパイルしたソースコードを合わせる (複数のファイルのコードをまとめる）
3.ファイルを圧縮する（uglifier、sass)
4.ファイルにダイジェストを付与する（ファイル名につくハッシュ)

これでブラウザに送られます。

development

例えば、下記設定の場合。

# config.assets.js_compressor = nil 
# config.assets.css_compressor = nil 
# config.assets.compile = true 
config . assets . digest  =  false 
config . assets . debug  =  true

1.assetにあるソースコードをコンパイル(coffee -> js、 scss -> css)

これだけでブラウザへ送られます。

参照

http://qiita.com/shizuma/items/1980bf885906c73238b6

REST

RESTとは

RESTとは

2000年 Roy Fieldingが博士学位請求論文でREST(Representational State Transfer)をソフトウェアアーキテクチャとして提案した後、OPEN APIを開発する基本としてすぐに広く使われることになりました。RESTはSOAPがサービス指向アーキテクチャなのとは異なり、リソース指向アーキテクチャ(ROA: Resource Oriented Architecture)ということでウェブサイトのコンテンツやDBなどを全て一つのリソースとして把握し、各リソースの固有なURI(Uniform Resource Identifier)を付与して該当のリソースに対するCRUD(Create, Read, Update, Delete)作業をHTTPの基本命令語のPOST, GET, PUT, DELETEを通して処理するものです。

ソフトウェアアーキテクチャとは

ソフトウェアコンポーネント、それらの外部特性、またそれらの相互関係から構成されます。また、この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもあります。ソフトウェアアーキテクチャの文書は開発依頼主とのコミュニケーションを容易にするもので、概要レベルの設計に関する早期の決定を促し、プロジェクト間でのコンポーネントとパターンの設計を再利用することを可能にします。

ROAとは

ウェブの全てのリソースをURIで表現し、構造的に連結してステートレスな方法で決まってあるメソッドだけを使用してリソースを運用するアーキテクチャ。

REST API

REST構造タイプに適するWeb APIをREST APIと言います。
RESTの設計原則に従って策定された‘REST API’を提供するウェブサビスを’RESTful’だと言えます。

REST APIの具現化例

Google API
Twitter API
Facebook API
。
。
。
今の時点には山ほどあると思います。

REST API情報提供方式

XML
JSON
RSS

RESTのメリット

1. わかりやすい

•　URIに規律があるため、みたら直ぐに何をしているのかがわかります
•　サービス内のリソースがURIで参照することが出来ます
•　参照URIでは、常に同じレスポンスが期待出来ます

2. 連携しやすい

•　新たな機能などにも対応しやすいです
•　RESTAPIを活用すればマッシュアップサービスがつくりやすいです
•　OpenAPIを簡単に提供できます
•　セッションを使わないのでそれぞれのリクエストに独立的です

RESTの原則

RESTを支持する人々は、ウェブのスケーラビリティと成長は、次に述べるような、いくつかのキーとなる設計原則の結果であると論じます。

ステートレスなクライアント/サーバプロトコル

HTTPの一つ一つが、そのリクエストを理解するために必要な全ての情報を含みます。そのため、クライアントもサーバも、メッセージ間におけるセッションの状態を記憶しておく必要がありません。ただし実際には、多くのHTTPベースのアプリケーションはクッキーやその他の仕掛けを使ってセッションの状態を管理しています (URLリライティングのような一部のセッション管理手法を使うシステムは、RESTful ではありません)。

すべての情報 (リソース) に適用できる「よく定義された操作」のセット

HTTP では操作 (メソッド) の小さなセットが定義されています。最も重要なのは “GET"、"POST"、"PUT"、"DELETE” であります。これらはデータ永続化に要求される CRUD と比較されることがあります。

リソースを一意に識別する「汎用的な構文」

RESTful なシステムでは、すべてのリソースは URI (Uniform Resource Identifier) で表される一意的な (ユニークな) アドレスを持ちます。

アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」

RESTシステムでは、多くの場合、HTML文書またはXML文書を使います。こうした文書に情報およびその他のリソースへのリンクを含めます。こうすることにより、あるRESTリソースから他のRESTリソースを参照したい場合は単にリンクを辿るだけでよい。レジストリなどの他の基盤的な機能を使う必要はありません。

URLの設計

ひと目でAPIと分かるようなURLにする

APIを利用する人がURLを見た時にAPIと分かるようなURLにするのが良いです。
例えは、ディレクトリに分ける場合と、サブドメインに切る場合があります。
http://example.com/api
http://api.example.com

URLにAPIのバージョンを含める

URLにAPIバージョンを含めるようにしたら管理もしやすいし、APIを使用する人がAPIのバージョンを選択しやすくなり、バージョンの切り分けも容易となるメリットが有ります。
http://api.example.com/1/article
http://api.example.com/v1/article/

URLに動詞を含めず、複数形の名詞のみで構成する

まず最初に好ましくないURLについて見てみると、
http://api.example.com/v1/createArticle
http://api.example.com/v1/article/create
http://api.example.com/v1/article/1/create
http://api.example.com/v1/article/createComment
http://api.example.com/v1/article/1/comment/1/create

上記のリソースに対して一意ではないという問題と、一つのリソースに対してCRUDの操作が必要になった場合にその操作の分だけURLが増えてしまう問題があります。

これを名詞のURLにすると、以下のようになります。

http://api.example.com/v1/articles
article全てを指す
http://api.example.com/v1/articles/1
articlesの中のID：1を指す
http://api.example.com/v1/articles/1/comments
articlesの 中のID:1についたcomment全てを指す
http://api.example.com/v1/articles/1/comments/1
articlesの中のID:1についたcommentsの中のID:1を指す

リソースの関係性がひと目で分かるようにする

URLを見ただけで、リソースがどこに属しているか分かるようにするのがベストです。
例えば、記事に属するコメントを表す場合は以下のように書いてみます。
http://api.example.com/v1/articles/1/comments

アプリケーションや言語に依存する拡張子は含めない

URLの末尾に.htmlや.phpなど言語に関係した拡張子を付けないようにします。将来的にAPIの仕様変更で言語の変更などがあった場合に困ることになります。言語の拡張子がなければ、フレームワークや言語に縛られることがないので、様々な変更に対応ができます。

長くしすぎない

http://api.example.com/articles/128/comments/10/tags/10/......
のように不要に長いURLをしないことが良いです。

参照

http://wp.tech-style.info/archives/683#URL_8211_Cool_URI
http://karur4n.hatenablog.com/entry/read-webtechbook
https://ja.wikipedia.org/wiki/REST

Grape Gem

Grapeとは

Grape gemはruby用のREST-APIフレームワークです。簡単にRESTfulなAPIを開発するための単純なDSLを提供することによって、Railsとシナトラなどの既存のWebアプリケーションフレームワークを補完するために設計されています。

Grape gemの実装

Grape gemのインストール

まず、GemfileにGrapeを追加します。
Gemfile

gem 'grape'


bundle installをします。

bundle install


model追加

modelを追加してみます。

rails g model test_data name:string age:integer
 
rake db:migrate


application.rbの設定

application.rbに以下のように書き、apiのパスを設定します。
application.rb

config.paths.add File.join('app', 'api'), glob: File.join('**', '*.rb')
config.autoload_paths += Dir[Rails.root.join('app', 'api', '*')]


API作成

appフォルダーにapiフォルダーを追加します。 ここに二つのファイルを作ります。一つは実際にapiとして動くファイルで、もう一つはそのファイルをmountするファイルです。 下のように書いてみます。
api/user/data.rb

resource :user_data do
    desc "List all User"
    get do
        TestData.all
    end
end


api/api.rb

class API < Grape::API
  prefix 'api'
  version 'v1', using: :path
  mount User::Data
end
 


APIのルーティング追加

route.rbにルーティング追加します。
route.rb

mount API => '/'


それからrailsのserverを起動します。

rails server


タミナールに下のように入力してみます。

curl http://localhost:3000/api/v1/user_data.json


そうすると、databaseに何もないので 「[ ]」 しか出てこないです。
では、データーを入れてみましょう。
まずはdata.rbにソースコードを追加します。もっと楽にするようにヘルパーを書きます。

helpers do
    def user_params
      ActionController::Parameters.new(params).permit(:name, :age)
    end
 
    def set_user
        @user = TestData.find(params[:id])
    end
end


そして、下のようにcreateのコードを書きます。

desc "create a new user"
params do
  requires :name, type: String
  requires :age, type: Integer
end
post do
  TestData.create!(user_params)
end


タミナールにこう書くと、

curl http://localhost:3000/api/v1/user_data.json -d "name=Jo&age=30"


{"id":1,"name":"Jo","age":30,"created_at":"2016-07-26T07:15:11.212Z","updated_at":"2016-07-26T07:15:11.212Z"}

簡単にデーターベースに入れ込みます。
deleteとupdateも同じように作成します。

desc "delete an user"
params do
  requires :id, type: String
end
delete ':id' do
  set_user
  @user.destroy!
end
 
desc "update an user"
params do
  requires :id, type: String
end
put ':id' do
  set_user
  @user.update(user_params)
end


タミナールで実行してみると、

curl -X DELETE http://localhost:3000/api/v1/user_data/1.json
 
{"id":1,"name":"Jo","age":30,"created_at":"2016-07-26T05:11:16.608Z","updated_at":"2016-07-26T05:11:16.608Z"}


もう一度データーを作って

curl http://localhost:3000/api/v1/user_data.json -d "name=Jo&age=30"
 
{"id":2,"name":"Jo","age":30,"created_at":"2016-07-26T05:16:45.169Z","updated_at":"2016-07-26T05:16:45.169Z"}


curl -X PUT http://localhost:3000/api/v1/user_data/2.json -d "age=100"
 
true


showの部分はちょっと迷いましたけど、

desc "show an user"
params do
  requires :id, type: String
end
route_param :id do
  get do
     set_user
  end
end


こういうふうにGETをroute_paramに変えると簡単にできました。

First Post

a

a-1

a-1-1

abcd

a-2

a-2-1

abcd

b

b-1

b-1-1

abcd

b-2

b-2-1

abcd