だいぶブラウザのみで仕事ができるようになってきた。ブラウザだからこそ効率よくすすめれるところもあるので、まとめたい。
2014年10月20日月曜日
Herokuを使うという腹ぎめ
●PHPという存在
ケータイ公式サイトから始まって、ソシャゲの会社がボコボコでるところまで、PHPばっかりだったんですね。PHPの何がいいかって言うと、Apacheとの結合がしっかりしていた。Apacheのプロセスをしっかり管理していれば、PHPもついでに管理できる。Webサーバとアプリケーションサーバが別れてないから、ノードが減る。ノードが減るから故障管理も減る。
デプロイなんて言葉も、PHPを使ってる人にしたら、それファイルのコピーじゃないですかって話。
phpmyadminもWordPressもPHP。ロリポップにコピーするだけで動いてくれる。まぁ便利。
ロリポップで始めてアクセスが増えたら、ちゃんとしたサーバに載せ替えればいい。
大きい方のスケールも、APC使えば、Apacheのメモリの中にPHPのコンパイル結果が入るから爆速。相当気になんない。でも事情が変わってきた。
・Rubyのバージョンが安定してきた&バージョン共存のためのソリューションがしっかりしてきた
・Apacheのスタンダードが崩れてきた(のでPHPの相対的優位性が崩れてきた)
・CDNとの連携とかすごく楽
・PaaSを使うという腹ぎめとほぼ同じ
・PaaSは、小規模から大規模までシームレスに「アプリ構築のみ」に集中できるというのがメリット
●PHP+ロリポップ→PaaS
という時代の流れ。PHPだとファイルコピーするだけでどこでも動くってメリットって、クラウドになるとぐっと薄れる。PaaSでも小さく初めてシームレスに大きく育てることができる。
対応すると書いてはいるが、必要となる知識の量が全然違う。Herokuを使うのはRoRとGitの知識が必要で、htmlにphpタグを埋めたものをFTPでアップしていた人がすんなり以降出来るとも思えない。そこは課題。
●セキュリティやらレギュレーションがどうたらこーたら
最悪発注元から、herokuやだって言われたり、AWSやだって言われたり、クラウドやだって言われたら、専用サーバにRubyで作りなおせばいいっちゃぁいい。PaaSのメリットが享受できないだけで、大したマイナスではない。
ケータイ公式サイトから始まって、ソシャゲの会社がボコボコでるところまで、PHPばっかりだったんですね。PHPの何がいいかって言うと、Apacheとの結合がしっかりしていた。Apacheのプロセスをしっかり管理していれば、PHPもついでに管理できる。Webサーバとアプリケーションサーバが別れてないから、ノードが減る。ノードが減るから故障管理も減る。
デプロイなんて言葉も、PHPを使ってる人にしたら、それファイルのコピーじゃないですかって話。
phpmyadminもWordPressもPHP。ロリポップにコピーするだけで動いてくれる。まぁ便利。
ロリポップで始めてアクセスが増えたら、ちゃんとしたサーバに載せ替えればいい。
大きい方のスケールも、APC使えば、Apacheのメモリの中にPHPのコンパイル結果が入るから爆速。相当気になんない。でも事情が変わってきた。
●外部環境の変化
・Rubyが速くなってきた・Rubyのバージョンが安定してきた&バージョン共存のためのソリューションがしっかりしてきた
・Apacheのスタンダードが崩れてきた(のでPHPの相対的優位性が崩れてきた)
●Herokuを使うとこれがいい
・AWSからゼロから構成しなくていい・CDNとの連携とかすごく楽
・PaaSを使うという腹ぎめとほぼ同じ
・PaaSは、小規模から大規模までシームレスに「アプリ構築のみ」に集中できるというのがメリット
●herokuの競合と比べるとこれがいい
- GoogleAppEngineと比べると
- GAEはGAEでしか動かないフレームワーク他にもってけない。
- Windows Azureと比べると
- Windows Azureは、.netフレームワークをベースに作っているので、開発環境がVisualStudioを想定している。(プレーンテキストエディタでも理屈の上では開発できるはずだが、情報が少ない)Macで.net開発は全くイメージつかない。
- つまりherokuは「ロックインされないPaaS」と言える。
●PHP+ロリポップ→PaaS
という時代の流れ。PHPだとファイルコピーするだけでどこでも動くってメリットって、クラウドになるとぐっと薄れる。PaaSでも小さく初めてシームレスに大きく育てることができる。
対応すると書いてはいるが、必要となる知識の量が全然違う。Herokuを使うのはRoRとGitの知識が必要で、htmlにphpタグを埋めたものをFTPでアップしていた人がすんなり以降出来るとも思えない。そこは課題。
●セキュリティやらレギュレーションがどうたらこーたら
最悪発注元から、herokuやだって言われたり、AWSやだって言われたり、クラウドやだって言われたら、専用サーバにRubyで作りなおせばいいっちゃぁいい。PaaSのメリットが享受できないだけで、大したマイナスではない。
2014年7月20日日曜日
2014年6月16日月曜日
カレンダーの同期あれこれ
なんらかのアプリで予定表ができたのなら、それをGoogleカレンダーやiCloudのカレンダーに取り込みたいよね。
●icalの取り込み
メリット:手軽
デメリット:スマホだと、icalファイルの取り込みに対応しておらず、一度GoogleカレンダーのPC版に移動する必要がある。
●招待メールの送信
メリット:招待を受けてからの導線がシンプル(たぶん)
デメリット:一つずつしかできない
●インテントを利用
メリット:導線が最短
デメリット:一件ずつしかできない。スマホしばり。
●GoogleカレンダーAPIを使う
メリット:一括で操作可能、相手に渡した後も修正が可能
デメリット:ユーザに認証してもうらうのがちょっと手間
●icalの取り込み
メリット:手軽
デメリット:スマホだと、icalファイルの取り込みに対応しておらず、一度GoogleカレンダーのPC版に移動する必要がある。
●招待メールの送信
メリット:招待を受けてからの導線がシンプル(たぶん)
デメリット:一つずつしかできない
●インテントを利用
メリット:導線が最短
デメリット:一件ずつしかできない。スマホしばり。
●GoogleカレンダーAPIを使う
メリット:一括で操作可能、相手に渡した後も修正が可能
デメリット:ユーザに認証してもうらうのがちょっと手間
「シリアライズ」目的のORマッパーがあってもいいじゃない
ORマッパーでやりたいことって、その名の通り、オブジェクトとRDBを対応付けたいだけったりする。拡張性があった方がいいのだけれど、やりたいことしては「シリアライズ」に近い。
そしてシリアライズってデータ構造丸出しで、いわゆる「カプセル化」ってことは優先度が低い。
そんなわけでシリアライザーとしてお手軽につかえて、拡張しようと思えば拡張できるというORマッパーを自作してみた。オブジェクトとRDBというよりも配列とDBという組み合わせ。
そしてシリアライズってデータ構造丸出しで、いわゆる「カプセル化」ってことは優先度が低い。
そんなわけでシリアライザーとしてお手軽につかえて、拡張しようと思えば拡張できるというORマッパーを自作してみた。オブジェクトとRDBというよりも配列とDBという組み合わせ。
2014年6月15日日曜日
UXって何よ?
UXってあれこれ言われているけど、どれもイマイチしっくり来ない。ユーザーインターフェースの改善だけじゃなくて、ユーザエクスペリエンスだよとは言うが、スコープが広くなった分、考える幅が増えている。だから定義しにくい。
登録:
投稿 (Atom)