Rails4.0のアプリをRails4.1に移行したときのメモ
先日、めでたくRails4.1がリリースされ、
新しい機能が追加されました(`・ω・´)
Ruby on Rails 4.1 Release Notes — Ruby on Rails Guides
いくつかの機能は自前で実装していたので、
公式に実装されたのは実にありがたいことです
そこで、早速私も手持ちの「Gagnrath」を4.1に対応させることに(`・ω・´)
- Gagnrath - ROGv : Forts Watching System
- source : https://github.com/parrot-studio/gagnrath
- sample site : http://ro.parrot-studio.com/rogvs
- Gagnrath(Viewer)
メジャーバージョンアップではないので、
app/ 以下のアプリ本体には影響がないと思われる一方、
新機能向けにconfigが修正されていることは予測できました
そこで、Gemfileで4.1を指定してUpgradeするのではなく、
“rails new”して新しいプロジェクトを作り、
差分を見ながら移行してみることに...φ(・ω・`)
実際にどう変わったかというのは、
以下のcommitを見てもらえばいいのですが、
大雑把に気づいた点だけメモしておきます
https://github.com/parrot-studio/gagnrath/commit/5b035a012cfa6c1092037b73c680cbcaa7e08de3
アプリケーションモジュール名の取り扱いが変更
config周りを呼び出す際、以前は「[アプリ名]::Application」を使っていました
これが「Rails.application」に統一されています
# 以前の形式 Gagnrath::Application.configure do # config.hoge = piyo end # 新しい形式 Rails.application.configure do # config.hoge = piyo end
結果的に、アプリ名は「config/application.rb」だけになっています
(元々あったものです)
module Gagnrath class Application < Rails::Application # ... end end
変更理由はわかりませんが、個人的には4.1の形式が好みです(`・ω・´)
secrets.yml の追加
元々、「config/initializers/secret_token.rb」にtokenの値が書かれていたのですが、
ソースを公開したり、開発環境と本番でtokenを分けたりするのに都合が悪かったので、
自前の設定ファイルに環境ごとのtokenを書けるようにしていました
それが公式に「secrets.yml」という形で追加されたため、そちらに移行しました
本番だとデフォルトでは環境変数から読み込む仕組みになっていますが、
おそらくheroku等を意識した記述だと思います
実際の運用では直に書いてしまっています(´-ω-)
database.yml の修正
共通設定をdefaultに切り出し、
各環境では差分だけ書く形式になっています
(書き方だけの変更で、YAMLに元々ある仕様を利用しています)
仕事のシステムでもこういう書き方をしていたのですが、
こっちの方が合理的ですよね(`・ω・´)
あと、PASSを環境変数から読み込むのがデフォルトになってますが、
おそらく(ry
migrationでschema.rbを更新しない設定が追加(動作未確認)
これは4.1からなのかわかりませんが、
今回の移行で初めて気づきました
# config/environments/production.rb Rails.application.configure do # Do not dump schema after migrations. config.active_record.dump_schema_after_migration = false end
仕事のシステムでリリース時にmigrationすると、
schema.rbが書き換わって次のリリース時に引っかかる*1のが面倒だったのですが、
この設定があれば避けられそうですね(`・ω・´)
*1: schema.rbもgitの管理下にある場合、書き換わると次のmergeで引っかかるんですよね・・・(´-ω-)
下書きをひっそりと共有するサイト「紙片」を公開しました
実は、結構前から知り合いに公開して運用していたのですが、
想定通り「使われている」ことが判明したので、
一般向けに公開いたします(´・ω・)っ
紙片 - 「みんなに見せるにはちょっと早い、でも見てほしい、そんなあなたへ。」
http://app.parrot-studio.com/shihen
基本は「編集用の合い言葉」を設定し、
ただひたすら「書く」だけです
編集をやめれば、そのうち文章は削除されます *1
保存は自動で行われますし、他のブラウザで編集を続けたいときは、
その「編集用URL」を開いて合い言葉で認証するだけです
誰かに見せたい場合は、「公開用の合い言葉」を設定し、
「公開用のURL」と一緒に伝えるだけです
コンセプト
「紙片」は「下書きを共有するための仕組み」です
Blogやサイトで何らかの文章を公開する場合、
たいていの方はどこかに「下書き」を書くと思います
私はこの文章の下書きをEvernoteに書いていますが、
「同期ができるテキストエディタ」として使っているので、
画像を貼り付けられるとか、そういう機能には一切期待していません
問題は、その下書きを「公開前に」「自分以外の誰かに」読んでもらいたい場合です
Evernoteにも共有機能はありますが、相手にも同じアプリを要求するのが面倒です
Blogで非公開に書く手もありますが、そのためにわざわざアカウントを取るのも面倒です
アップローダーは他の人にも読まれる可能性がありますし、
更新のたびにわざわざアップし直すのも面倒です
そもそも「下書き」なんて最終的には捨ててもいいわけですよ
どうせ公開するときにはさらに微調整を加えるわけですし、
下書きも残したいというのなら、それはもう「下書き」ではないわけで *2
どうせ「捨てる」文章なのだから、もっと簡単に共有できないか
面倒な管理がいらず、用が済んだら「忘れてもいい」、
そんなテキスト共有システムはないか
そう考えて「紙片」を作りました
実際、「想定ユーザ」として設定した友人は、
狙い通りに使ってくれているようなので、
こうして公開することにしたわけです
正直、あまり使われるとは思ってませんが、
「Gagnrath」同様、自分に都合がいい仕組みとして作ったので、
最悪自分とその周辺が使ってくれればいいかな・・・と
その他の使い方
元々のコンセプトは上記の通りですが、副次的な効果として、
「Webのどこかに書きたいが、不特定多数には見せたくない」
という文章を書くのにも使えます
愚痴をBlog等に書くと汚染されて都合が悪いですが、
かといって「Webのどこか」に書きたい、そんな欲求を満たすのにも使えます
どうしてもって場合は仲の良い誰かに見せることもできます *3
あとは、身内向けのイベント告知文を書いておいて、
公開用URLと合い言葉を伝えて見てもらうなんてのもできます
イベントが終わり、忘れた頃には消えています *4
「合い言葉」という表現
「紙片」では「パスワード」という言葉を一切使っていません
全て「合い言葉」で統一しています
「パスワード」という言葉から連想されるのは「英数字や記号」ですが、
「合い言葉」なら「日本語」を使うだろうと思ったからです
そもそも、何らかのパスワードをかける際に、
英数字や記号しか使えないというのは、古いシステムの都合や、
歴史的な経緯によるものでしかないのではと思ったのです
今の仕組みであれば、日本語で認証することも可能なはずで、
その実験的な意味合いを含んでいます
結果的に、他のシステムと「パスワードの共有」は起こりづらいと思います
もっとも、「アカウント」って概念も排除しているので、
「IDとパスワードの組」は一切存在しませんが
Developers Summit 2014 2日目 まとめ
1日目の続きです
Developers Summit 2014 1日目 まとめ - ぱろっと・すたじお
Developers Summit 2014:開発者のためのITカンファレンス
2日目は例の大雪でえらいことになり、
さすがに雅叙園前の急勾配は危ないだろうと、
Amazonさんの入っているビル経由で向かいました
エントランスももちろん綺麗なのですが、
度肝を抜かれたのは社食と思われるホールです
これが吹き抜けでびっくりするほど広いという(lll゚Д゚)
柱にはダンボーのイラストも描いてありましたが、
勝手に写真を撮るのもためらわれたので撮ってません
共用エリアから見えるので、一度見てみると面白いと思います
ただ、ビル内で相当迷いまして、
そもそもどこからどこまでが「入っていいエリア」なのかもわからず、
「THE・リア充」な雰囲気とあわせて混乱しましたΣ(゚Д゚;≡;゚д゚)
2つ目のセッションから参加で、他に人が少なかったのもあります
人がたくさんいれば後ろをついていけたのですが・・・
14-B-2 グリーを支えるデータ分析基盤の過去と現在
「ビッグデータ」という言葉がバズワード化してしまってあれですが、
真の意味で「大規模なデータをどう分析するか」のお話でした
ただまあ、正直ここまでの規模のデータ分析(システム)は、
よほどの大企業・・・それこそGREEやDeNAクラスでないと、
とても考えられないレベルだと思います(lll゚Д゚)
ただ、他のセッションでも頻繁に出てきた、
「Fluentd」は気になりました
アーキテクチャの説明を見ていただければわかると思いますが、
ログデータを構造的に扱うため、入出力を仲介するもの・・・と考えればいいでしょう
Ruby系WebアプリにおけるRackの立ち位置だと思います
データをJSONとして扱っているのもポイントで、
これにより構造的なログ解析が可能になっているわけです
うちのような普通の会社であっても、Fluentdは使えそうな気がするので、
今度提案してみようと思います...φ(・ω・`)
あと、Hadoop周りに関しては、あまりに規模が違いすぎて縁がないというか、
Hadoopの出始めの頃に買った本がまだ手つかずだったり・・・
技術的にどうって前に、そこまでのサーバリソースはなかなか用意できませんし
- 既存の構造
- 問題点
- データ分析するユーザが増えた
- エンジニアがデータを提供するのが難しく(人が限られる)
- 改善へ
- Treasure Data
- データ分析基盤
- ログから分析して改善
- Webサイトのアクセス改善を応用
- ジョブ管理
- 投げられた分析タスクを監視
- ログから分析して改善
- ログ解析
- ページ遷移(GoogleAnalyticsっぽいあれ)
- 離脱(ユーザ属性・プレイ時間など)
- クリック
- Chromeの拡張で画面にクリック分析データをオーバーレイ
- JSでクリックログを送信
- 分析ジョブ管理
- 社内一般ユーザにデータを解放 => 非効率なジョブが投げ込まれる
- ジョブの可視化
- 送信元の特定
- スロークエリの可視化と判定
- 強制kill
- 社内一般ユーザにデータを解放 => 非効率なジョブが投げ込まれる
- (以下、Hadoop周りの具体的な実装については割愛)
14-C-3 Web Platform 最前線 ~Web技術とアプリ開発のトレンド~
Slide : (not yet)
今年のデブサミで、自分にとって一番インパクトがあったというか、
パラダイムシフトを感じたのがこのセッションでした
資料が現時点で公開されていないのが残念です(´・ω・`)
いわゆる「WebOS」、さらにいえば「FirefoxOS」の話なのですが、
それが意味するところは「ブラウザOS」よりもはるかに大きくて、
「ソフトウェアとハードウェアの標準化」くらいのインパクトがあると思います
今までのOSにおいては、ハードウェアとのやり取りにデバイスドライバを使っており、
OSレベルで「API」としてハードウェアの機能を隠蔽していました
逆に言えば、OSレベルAPIの範囲でしか互換性を持たなかったのです*1
一方、現在W3Cが目指しているのは、
まさにその「ハードウェアレベルAPIの標準化」であり、
その現時点での実装が「FirefoxOS」なのです
ある意味、OSとアプリケーションが真の意味で分離されようとしており、
その技術としてHTML5とその周辺技術が存在しているわけです
OSやハードウェアを意識せずに、本当の意味でアプリが汎用化される可能性があります
かつてはJVMや.NETという形でバラバラに「マルチデバイス化」されていた概念を、
WebAPIという形で標準化しようとしているわけです
なので、おそらく「ブラウザOS」という表現は本質を捉えていません
もちろん、現時点ではまだパフォーマンスに問題があり、
機能もまだ揃っていません*2
ただ、WindowsやIEが今ではWeb標準に従っているように、
悪い意味で「昔のWindows化=断片化/独自仕様化」しているAndroid等も、
何年先かはともかく、後々追随してくる可能性はあるでしょう
このセッションを聞くまで、FirefoxOSについて、
「真にOSSのAndroid」くらいの認識でいましたが、
全然見ているものが違いすぎました(ノ´・ω・)ノミ(m´_ _)m
個人的に思ったのは、CやJavaで実装されている「Ruby」が、
JavaScript上で実装されたとすると、相当面白くなると思うんですけどね・・・
その鍵を握るのが「asm.js」だとは思いますが(´-ω-) *3
ということで、FirefoxOSが動く端末を手に入れたいと思ってますが、
海外から輸入ってのも面倒なのでどうしたものか・・・
- 背景
- 従来:OSごと / Webはサブセット扱い
- プラットフォーム依存
- 不透明な継続性性・再利用性
- 分断・実装依存
- "APIが標準化されていない"
- Web Platform
- マルチデバイス(言語やAPIの共通化)
- ベンダー非依存(持続性)
- ブラウザ上で動くアプリ
- ブラウザの開発にエンジニアリソースが割かれるように
- Firefox Apps / Chrome Apps -> ローカルAppと区別できない
- 例の「Flappy Bird」はFirefox Apps
- WebOS
- WebOSが各種デバイスへ
- 課題:機能不足・パフォーマンス不足・エコシステム
- デバイス系機能の標準化
- 例:バッテリー残量取得のAPI化
- FirefoxOSで実装 -> 他のOS
- 例:バッテリー残量取得のAPI化
- 大規模アプリでは遅い
- Webテクノロジー
- UNREAL Engine
- Webだけで3DゲームレベルもOK
- (デモがめちゃくちゃ綺麗で軽くびびる(lll゚Д゚) )
- Webだけで3DゲームレベルもOK
- AOTでロードタイムも軽減
- GCも軽減する手段がある
- デスクトップのリモート実行
- AmazonのGPUインスタンスで画面を描画
- 「赤いきつね」:赤いネクサス5にFirefoxOS
- (やりたいけど、お金が・・・(´-ω-) )
- OSが軽量なのでメモリを積まなくてもOK -> 安く売れる
- OSカーネルとブラウザが分離されている
- セキュリティパッチをブラウザレベルでできる
- パナソニックがスマートTVをFirefoxOSで
- 今後も端末やデバイスがいろいろ
14-C-4 DeNAにおけるゲーム以外の新規事業の立ち上げ方
DeNAは今でこそソーシャルゲーのイメージが強いですが、
元々はオークションや広告等、様々なカテゴリで事業を行っている会社です*4
とはいえ、今の主軸は間違いなくソーシャルゲーであり、
同時にソーシャルゲー自体がもはや微妙な立ち位置になっているため、
「次」を開拓するのは急務だと思います*5
そんな中でのこのセッションだったわけですが、
「事例」に寄っていて、非常に面白い内容でした(`・ω・´) b
ある意味では「今風」のやり方ではあるのですが、
そのバックボーンに「確立された技術」があるように見えましたし、
なによりとても「現実的」だと思います*6
- エンターテイメント事業本部
- 非ゲーム事業をやる
- ゲームの次の領域を探す
- マンガボックス
- Showroom
- アイドルのパフォーマンスを配信
- (文字列ではなく)アバターが視覚的にコメント
- UIでニコニコ等と差別化している
- etc...
- 一つの事業部で全部回している
- "やることが多い"
- 基本的な人員構成を揃えつつ、他の部署が全面的にバックアップしている
- DeNAのスクラム
- プロダクト
- みんなで必死に考える -> 作る -> 使われない
- ユーザにインタビュー -> ⚪︎⚪︎機能に需要が -> 作る -> 使われない
- "ニーズを検証する"
- 例1:チラシル
- 検証項目
- 暮らしの中で使ってもらえるか?
- 長期的に使ってもらえるか?
- 紙と同じように使ってほしい
- 練馬区限定でバイト募集 -> 社内に呼んで使ってもらう -> フィードバック
- 検証項目
- 例2:アプリゼミ
- 検証項目
- 長時間勉強して欲しい
- 長時間勉強するのに何が楽しいか?
- 親は子供が勉強しているかしりたいのか?
- 最小限のモックを作って親子に評価してもらう
- 検証項目
- 例3:peko -> USの大学生向け
- 検証項目
- 初対面でもコミュニケーションは成立する?
- 位置情報とか気にする?
- FBログインは使う?
- USの大学前でチラシを配ってテスター募集
- 2週間試してもらう
- ログを仕込んでおいて、何を使ったのかを調べる
- ヘビーユーザにインタビューもする
- アンケートだとFBログインを使いたいのは半分程度
- 実際に使わせると8割は使っている
- 定量化は重要
- 検証項目
- 企画の進め方
- プロデューサーとエンジニアが意思疎通して意思決定
- 9サービス中4サービスはエンジニアが立案
- 全ての意思決定にエンジニアが参加
- UserTesting,com
- リモートでアプリを使ってもらう
- 日本でも徐々に出てきている?
- アーキテクチャ
- 自社のデータセンター
- ソーシャルゲーで鍛えられたインフラ部隊
- たいがいのことは解決してくれる
- 必要ならAWSも
- ソーシャルゲーで鍛えられたインフラ部隊
- スケーラビリティ
- どんなにスモールスタートでも意識する
- インフラ基本構成
- (´・ω・)っ Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)
- 検討するところ
- DBの垂直分割 / 水平分割(シャーディング)
- 必要かはインフラチームと相談
- Baranモジュール
- インフラに特化した共通モジュール
- ノウハウの有効活用
- コミュニケーション
- ネイティブアプリ
- 通知
- 分析用のロギング
- ログの種類
- 広告
- リリースしても何も起こらない
- ほっといても30-40程度
- 広告を使ってユーザを流入させる
- FacebookAdやTwitterAdはお安い
- リリースしても何も起こらない
- FBAd
- キャラクター系 / 人物系 / アプリのUI系 -> どれが効果的か?
- アプリのUIを見せるのが一番クリック率高かった
- オフラインプロモーション in US
- バーで「ビールをおごるからアプリを入れて」
- キャラクター系 / 人物系 / アプリのUI系 -> どれが効果的か?
- 1年振り返って
- 余計なことを考えずにことに向かう
- フィードバックループ重要
- 銀の弾丸はない
14-A-6 Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所
Slide : http://www.slideshare.net/sifue/developers-summit-2014-play2scalaweb
えー・・・資料みてください、以上Σ(・ω・ノ)ノ
いや、あまりに高密度すぎて、Scalaの件あたりまではきっちり聞いていたのですが、
後半のスクラム周りは( ゚д゚)ポカーンと見ているしかなかったので・・・
この事例からもわかるのは、「フレームワークの作り直し」をする際に、
必要なのは「少人数のできる人"だけ"で構成されたチーム」ってことです
フレームワークができあがれば、多少の差を吸収できますが、
やはり基盤部分は「わかる人」が手を動かすのが最速である、ということです
今の「はてブ」だって、最初はnaoya氏が一人でベースを作ったわけで
ただ、後で個人的に思ったのは、ちょっとScalaにこだわりすぎかな・・・というところで
今の仕事をするまでは、私もそこまで考えてなかったと思いますが、
適切にサーバサイドAPIとViewが分離されていれば、
View側のアーキテクチャまでScalaである必要はないのではないかと
というのも、発表の中でScalaのテンプレートで引っかかっているという話があり、
わざわざGroovyまで使っているとのことですが、
それならいっそView部分だけPHPで実装する手もあったのでは
もちろん、PHPでは既存のアーキテクチャに引きずられるとか、
パフォーマンスの問題とかいろいろ背景はあったと思いますし、
そもそも、私ごときが何言ってるんだって話なんですが(´-ω-)
あと、DDD周りの話を見ていて思ったのが、
大規模なWebシステムは、もはやSIの領域と何ら変わりない、ということで
大規模化したシステムを滞りなく動かすノウハウという意味では、
どう考えてもエンタープライズ系が先行しているわけですが、
表面上のレイヤーが違うだけで、やってることは一緒になってます
その辺に気づいているWeb企業が、SIerの転職を歓迎していたりするわけで、
おそらくドワンゴもそういうフェーズに入ったってことでしょう*7
その他、細かいことは資料でみてください(´・ω・`)
ということで2日分をまとめてみました
やはり自分の中でインパクトがあったのは「FirefoxOS」です
別にフォクすけを愛しているからではないですよ(´・ω・)? *8
エンジニアってやっぱり怠惰なもので、「面倒なこと」はしたくないわけですよ
例えば、環境ごとに言語レベルでコードを書き換えるとか
その現時点での解が「Xamarin」等の開発環境であり、
未来における解がFirefoxOSが目指す「APIの標準化」なのだと思いました
前回の冒頭でも書きましたが、
「未来の話」はそれはそれで面白いし大事なのですが、
「今、何ができるか?」はより重要です
とりあえず、「私が今できること」は、FirefoxOS周りの情報収集ですかね・・・(´-ω-)
*2: とはいえ、Rubyだって当初は「こんな遅い言語は使えない」と言われていたそうですが、今は時代が変わり、むしろメインストリームの一角です
*3: どちらにせよ、何年も先の話でしょう。でもRuby界隈の人なら考えそうな話で・・・
*4: GREEに比べると、圧倒的に「手堅い」イメージがあります。でなければ球団とか持てません
*5: とはいえ、GREEやソーシャルゲーに特化してしまったWebゲーム会社に比べればはるかにましかと
*6: 後に出てくるニコニコの事例は、たしかに「ハイレベル」ではあるのですが、まだ「教科書通り」のレベルから大きく離れていないというか・・・(´-ω-)
*7: C++の有名人を雇用(?)したりもしているようですが・・・Σ(゚Д゚)ガーン
*8: Android版Firefoxのキャンペーンで当たったフォクすけぬいぐるみは、家宝として大事にしまってあります(*゚∀゚)=3
Developers Summit 2014 1日目 まとめ
2009年から参加してますので、今回が6回目のデブサミになります
Developers Summit 2014:開発者のためのITカンファレンス
今回のテーマは「Story」だったのですが、
これはとても大事なテーマだと思います
何かの技術を適用する際に、その意図や背景、適用すべき状況、
いわゆる「コンテキスト」がとても重要です
実際、今回の発表では、「こういう状況で使える」といったコンテキストの話や、
「現実にはこのように適用した」という事例などが多数ありました
正直、デブサミで聞いた話が、実際の業務で即座に生かせるかというと、
私を含め、たいていの方にとって相当敷居が高いと思います
でも、「今」適用できないとしても、「いつか」は可能かもしれません
だからこそ、「いつか」が具体的にどのタイミングなのかを知るのに、
適用に至るコンテキストやプロセスが重要なのだと思います
なお、どうでもいい話として、
今までは紙でメモを取ってBlogに起こしていたのですが、
今回からはiPad mini + Appleキーボードでデジタルにメモを取りました
基本的には問題なかったのですが、
不安定な膝の上での入力はやっぱり大変なのと、
メモが長くなってくるとEvernoteが落ちたりで、なかなか大変でした(´-ω-)
あと、Win/Mac/AndroidはATOKで統一しているのに、
iPadだけ違うので、のってきた時に限ってイライラしました
Evernoteとの同期機能もあったはずですし、
次に同じようなメモを書くことがあったら、
ATOK Padを買っておいてもいいかもしれません
http://www.justsystems.com/jp/products/atokpad_iphone/
さらにどうでもいい話として、
昨年まではメモそのまま+αの形式でまとめてましたが、
今回からは内容に対する感想とか気になる点を中心にまとめます
というのも、最近は講演の後すぐに資料が公開されるため、
不確かなメモに頼るより、そちらを見た方が間違いないからです*1
ある意味普通ではあるのですが、
せっかくデジタルメモを取るようにしたのに、
それを使わないという矛盾が・・・Σ(゚Д゚)ガーン
13-D-1 JavaからJavaScriptへ!HTML5適用から見えた次世代業務アプリケーション
エンタープライズ系の開発も今後HTML5になっていくというお話だったのですが・・・
おそらく、私が部屋を間違えたのだと思いますΣ(・ω・ノ)ノ
もちろん、業務系もHTML5になっていくという流れは間違いないと思います
だからといって、既存のやり方がもうダメってこともないはずです*2
現状でも、フロントエンドとバックエンドAPIは切り分けられている*3わけで、
フロントエンドがHTML5になったからといって、
バックエンドのJavaがすぐに変わるとは思えません
JavaにはJavaのメリットがあり、すぐにNode.js等に置き換わるわけでもなく、
HTML5を取り巻く技術環境にJavaが対応しない、というものでもないでしょう*4 *5
技術的概念と実装は必ずしも依存関係にあるものではありません
一番違和感があったのが、「NetbeansやEclipseを使わずGit」というお話です
「エディタ」と「バージョン管理システム」というカテゴリの違うツールを、
同じ文脈で比較されるのは違和感がありました
「JSPなんか捨てろ」という話もありましたが、これも実装手段の話でしかなく、
HTML5のコードをJSPで記述して出力してもいいはずです
「最新のツールや技術で開発していこう」ってメッセージはわかりますが、
「古いものを捨てていこう」には違和感があります
「マネージメント層」や「経営層」へのメッセージとしてはいいのでしょうけども、
「開発者」へのメッセージとしては違和感を感じた、ということです
なので、「部屋を間違えた」のかな・・・と (´-ω-)
13-B-2 グリーにおけるChef導入事例 ~既存の資産を活かし新しい技術を導入する~
エンタープライズ系の話は私には合わないと思ったので、
予定していたD-2からこちらに移りました
Blogで紹介されていた内容の詳細版とのことでした
グリーのインフラに Chef を導入した話 | GREE Engineers' Blog
最初からChefを使うと決めているケースはともかく、
普通は何か問題があるからインフラの一元管理を考え、
その手段の一つとしてChefを使うってことになると思います
実際、GREEでも最初は独自の管理システムを使っていたそうですが、
そこからChefにどう橋渡しし、共存しているかという、
現実的で参考になる事例だったと思います(`・ω・´) b
なお、資料があまりに良くできており、
そちらを見てもらえば全部けりがつくので、
メモ書きのまとめはしませぬ
13-B-3 社内システムの構造と設計、実装のはなし
実は、私の仕事はある意味「APIの整備」だったりするので、
この発表にはものすごく共感しました(`・ω・´) b
社内向けとしてもそうなのですが、Webサイトを運営している場合、
ユーザに提供するデータモデルと、社内に提供するデータモデルは紙一重だったりするので、
データ層でRESTfulなAPIを切っておいて、ビジネスロジック層で組み立てる、ということをしてます*6
しかも、View層とビジネスロジック層で言語そのものが違ったりしますが、
それでも問題なく動いてしまうのは、やはり「API」の力であり、
「REST」のすばらしさであり、「JSON」の柔軟性だと思います
発表にもありましたが、curlで気軽にテストできるってものすごい楽です
面倒な実装をAPIに閉じ込めておいて、
誰かに提供するときはcurlをsystemで読んでもらうとか簡略化もできますし
- Open Web
- OAuth
- WebAPIの制限(回数制限等)
- トラフィック/レスポンスタイム
- コストを誰が払う?
- 互換性の問題
- Close Web
- 社内サービス
- 機能>性能
- ライフサイクル長い
- 使えるうちは使ってしまう
- ターゲットユーザ=自分
- 問題点
- 情報と権限の分断
- 情報と機能が冗長
- 無駄が多い
- UXの欠如
- 作りが適当
- 「自動化」の障壁
- サーバごとに仕組みが違う
- 全部入りでアップデート不能
- "シンプルにしたい"
- 権限の分断を最小化
- 普通の会社なら権限はフラットで良い
- 参照は複数の方法を
- ブラウザ/API
- モジュール化
- 社内システムほど他システム連携を考えてAPI化
- APIが維持されていれば、裏側はどう変わっても構わない
- APIの互換性を保つ
- プロトコル
- テータ構造
- 意味的な一貫性(戻り値等)
- クライアント要件の普遍性・不変性
- "ドキュメントはどこかにいってしまう"
- 人の目でわかるフォーマット
- 運用できる=アップデートできる
- 人の目でアップデートの成否を確認可能
- パフォーマンスより容易さ
- 言語を超えられる疎結合
- 動くことが大事
- まず動かす
- 必要になったら作る
- 機能を切り刻む
- 修正を最小化
- 追加する機能を細切れにすす
- 組み合わせて実現する
- 将来の要件定義はそもそも難しい
- 社内システムで新しいものを試す
13-C-4 iOSにAndroid、百花繚乱モバイル開発環境を比較する
先ほどのレポートでも書いたように、私の得意分野も仕事も、
どちらかといえばバックエンドAPIです
とはいえ、フロントエンドがあってのバックエンドであり、
大きな会社ならともかく、小さな会社では両方セット担当ってのはよくあるはずです
なので、フロントエンドの情報にも興味があります
とはいえ、AndroidではJavaを書き、iOSではObjective-Cとか、
正直いちいち面倒なわけで、
一度に書けるって怠惰ですばらしいと思うのですよщ(゚Д゚щ)
このセッションで誠実だと思ったのは、
全て「自分が触れたことがあるもの」に限定されていたことです
なので、比較されていた情報も、深掘りされたものが多くて参考になりました
個人的には「Sencha Touch」と「Xamarin」に興味をもちました
Delphiは・・・興味はあるものの、C++とかは使えないので(´・ω・`)
あとはやはり「Unity 3D」ですか
ここではあまり書けないのですが、某延期しまくりのネットワーク専用3Dゲーが、
どうもUnityで動いているようで、やはりゲーム界隈だと今は主流なんじゃないかと *7
- うまいこと両対応させたい
- HTML5+JS
- LL+Framework
- Mono
- Xamarin
- Unity
- メリット
- Unityは事実上のデファクトスタンダード
- UnityはBoo(=Python)/JS(UnityScript)が使える
- デメリット
- おすすめ
- Xamarin:普通のアプリを作るには向いている(例:紅白アプリ)
- Unity:ゲーム
- 用途で使い分ける
- Native
- 最終的なおすすめ
- 一般的なアプリ:Xamarin(MSサポート) / Delphi
- エンターテイメント系:Unity3D
- 会社(ゲーム)ではUnityばかり
13-D-6 快適さはWebサービスの生命線!Webアプリのパフォーマンスを最高にするために心がけること
「Akamai」については皆さんご存じと思いますが、
サービスの概要について、もうちょっと突っ込んだ話がありました
HTMLそのものを書き換えたり、画像URLを書き換えたりと、
思っていた以上にドラスティックな仕組みになっているようですが、
ユーザからすると「同じように見えればいい」わけです
画像なんかも解像度を落とす等、相手の環境に合わせて自動選択・配信しているようですが、
さすがにそのレベルの仕組みを自前で汎用的に構築するのは難しいわけで、
その辺がお金をもらうポイントなんでしょう
- コンテンツをクライアントに表示させるまでの時間をいかに短縮するか?
- Tim Berners-Lee says:混雑が最大のWeb阻害要因になりうる
- MITで研究 => スピンアウトしてAkamai
- ルーティングのコントロールが難しい
- IXから1ホップでAkamaiのサーバにつながるようにサーバを配置している
- 最大風速21.6Tbps
- 1日のピーク10Tbps
- Walmartの論文
- コンテンツの表示が遅いほど注文に結びつかない
- but、サイトはどんどんリッチ化複雑化
- 「状況に応じて最適化する」
- AQUA Ion
- アクセラレーション
- 日本の回線は速い => キャッシュは効果が薄い
- それでも他の要因で速度を上げられる
2日目に続く・・・
*1: 決してメモを整理するのが面倒というわけでは・・・ないと・・・思ふ(´・ω・`)
*2: 「HTML5があればFlashはいらない」とじょぶずは言ってましたが、HTML5を捨ててネイティブにいったFBの事例もありますし、むしろAppleがどんどんプロプライエタリな方向に進んでいる気も・・・
*3: ・・・そうなんですね(´・ω・)?
*4: 実際、Java8は久々にJavaを触ろうかと思わせる、良い作りをしていると思います。既存仕様を生かしたまま、あれだけの変更を加えるのは大変だったでしょう
*5: そもそも、最近Scalaが人気だったりするわけで、ベターJavaの需要は十分にあるし、TwitterだってバックエンドはScalaです
*6: 昨年ちょっとだけ触れてます(´・ω・)っ http://parrot.hatenadiary.jp/entry/2013/09/03/112657
*7: そのゲーム、元々はPCゲーで長いこと評判だっただけに、クライアントの出来はいいのですが、ネットワークゲーが初めてということもあり、ネットワーク周りの設計が雑すぎたようで、クローズドβではあまりのひどさに閉口しました(´-ω-) 最新のテクニカルβはだいぶましになってましたが、ゲームとしてはまだ細かいところが見えてないのが難しいところで キャラ造形のクオリティは高いのですが・・・ さて、どのゲームでしょう?Σ(・ω・ノ)ノ
Middlemanで自サイトを再構築してみた
昨年後半あたりから仕事でさんざんもめたり、
年末にはプライベートが忙しかったりで、
最近まともに何かを作ってませんでした(´・ω・`)
・・・といいつつ、実は作ったものはあって、
個人的にこっそり使ってますが、
公開していいものか迷っていたりも
そもそも、最近は仕事がわりと忙しくて、
いい意味で「コードを書きたい欲」が発散されているので、
自分のプライベートな何かに注力する気分ではないというか・・・
そんなわけで、しばらく(コードを)公開するようなものがなかったのですが、
例によって「WEB+DB PRESS」を読んでいたところ、
naoya氏がMiddlemanについて解説してまして
Middleman: Hand-crafted frontend development
- 作者: WEB+DB PRESS編集部編,栗林健太郎,安詮院康広,山口良平,尾上忠輔,大川高志,坂本寛樹,青木峰郎,増井雄一郎,中島聡,江島健太郎,中島拓,柴田博志,伊藤直也,登尾徳誠,片桐崇,後藤秀宣,佐藤鉄平,近藤宇智朗,長野雅広,奥野幹也,渡邊恵太,A-Listers,家永英治,はまちや2,川添貴生,原田勝信,和島史典,城倉和孝,安達俊雄,Akira,川嶋賢一
- 出版社/メーカー: 技術評論社
- 発売日: 2013/12/21
- メディア: 大型本
- この商品を含むブログ (4件) を見る
SinatraやRailsでWebシステムを作る際、
HamlやSlimのようなツールを最近はよく使います*1が、
その辺を静的なサイトでも使えないか・・・という発想で作られたツールです
HamlもSlimも最終的な出力は「HTML」ですし、
CoffeeScriptもやはり「JavaScript」に変換されます
これを手でやるのはめんどいよね・・・ということです
とはいえ、プライベートでも仕事でも、
「静的なサイト構築」に関わることはほとんどなくて、
最低ラインでもSinatraだったりします(´・ω・`)
一方、プライベートで使いまくっている「Gagnrath」*2は、
Viewのコードがerbで書かれており、これをHamlやSlimに変えるとなると、
結構大がかりな修正になってしまいます
本当はBootstrap3対応のついでにやりたいのですが、
今普通に使えているツールですし、
試すものに対してコストがかかりすぎるというか(´-ω-)
そこで思いついたのが、「自サイトの再構築」です
(デザインそのものは何も変えてないのですが、
Bootstrapのバージョンを2から3に変えました)
見ていただければわかると思いますが、
作ったものやプレゼン資料が繰り返しで並んでまして、
前々から「どうにかならんか」と思っていたのです
DBを使うのはやりすぎだし、ファイルを読み込ませるにしても、
たかだか3ページの静的サイトを「システム化」するのは、
さすがにコストが大きすぎます
・・・と思っていたところに例の記事を読んだので、
3ページ程度なら試すにはちょうどいいだろうと、
Middleman+Slimで再構築してみました(´・ω・)っ
https://github.com/parrot-studio/potal
YAMLでデータを定義しておき、View側で動的に埋め込んだりとか、
layout側に制御を入れてボタンのデザインを変えたりとか、
プログラマ(特にRubyになじみのある方)なら便利かと
ただ、少なくとも「Middleman」に関していえば、
残念ながら今の仕事で使う機会はないと思います
Sinatra/Padrino/Railsを使うものばかりなので
Slimに関しては、今回のでなんとなく使い方がわかったので、
次の"個人的な開発"から使ってもいいかなと思いました(`・ω・´) b
「テストを書こうとすると、メソッドの粒度が洗練される」みたいに、
「Slim(やHaml)で書こうとすると、HTML/CSSの構造が洗練される」というか、
元がシンプルなコードだけに、構造自体もシンプルにしたくなるというか・・・
一方、仕事では既存画面との絡みがあったり、
私の担当はAPI等のバックエンド周りがほとんどで、
やはり使う機会はないと思います
フロントエンドは私より得意な人がいるので、
その人向けにAPI等を提供して、
「後はよろしく(`・ω・´)ノ」の方が早いもので・・・*3
何か話がずれてきましたが、Middlemanは
「プログラマっぽい人がプログラマっぽい発想で静的サイトを作る場合」に
便利なツールだと思いますので、機会があればお試しを