「面白い」とは
よーいどん。
面白いもの。並べて共通点出す。
笑えるもの。好奇心をそそるもの。
繰り返したくなるものばかりが面白いとは限らない。
ひとりの場合も、複数の場合も。
つまり、面白いとは、直感的に、もしくは、知的に感覚されるもの。
一瞬でひとに前向きな感情を感覚せしめるもの。ただし劣化もする。
人によって基準のことなるもの。文化や環境に即し、文脈によっても変化するもの。
人に話したくなる、共有したくなるもの。世界を変えうるもの。
Google Trend先生はすごい
そのとき久々にGoogle Trend先生をさわって感動したのでメモします。
ちなみに、PHPの動向としては、
個人利用としては、CodeIgniter / CakePHPが良さそうかなというところでした。
〜調査時に判明したもろもろ〜
CodeIgniterが個人利用としてはおすすめで、
CakePHPは個人〜中規模利用にはおすすめ。
Cakeは、使いこなせないくらい拡張要素がある様子。
上記以外のYiiや、FuelPHPなどの比較的新生のフレームワークについて、
Google Trendで調査もふまえ確認したところ、
Yiiは中国、ロシアでメジャーなだけで、世界的な普及はまだ。
FuelPHPについても認知度はまだまだ低い模様でした。
ただし、FuelPHPはコミュニティが盛んとの情報も。
で、このときに参考にしたのが、以下のページです。
驚いたのは、国別*時系列で、トレンドが分かること。
あと、関連キーワード見ると、みんながどこで躓いているかわかるので
それも面白かったり。
例えば、cakephp は他と異なり "cakephp tutorial"が一番なので、
導入に踏み込む人が多い反面、その導入の困難さは相応にあることが読み取れます。
気になったら、いろいろ調べてみようと思います。
AKBのメンバーとかも調べたら面白そうですねw
おまけ
java優勢。全体的に、開発言語の検索量が減っています。
rubyがほんのりあがってますね。
oracle優勢。mysqlはその半数くらい。kvs系な話題はまだまだ定番では無いようですね。適用範囲も限定されているからですかね。
gitさんの勝利。なかなかの勢いで右肩上がりですね。
gitって、こんな昔からあったんですね。知らなかった。
Putty & Screen での画面のちらつき（ベル）の設定方法
Macユーザが多い中、私は会社の開発環境ではWindowsを使っています。
と、そこで開発用VMに Putty でつないで Screen 使って開発しているのですが、
最近目の疲れもあいまって、標準状態で恐らく発生する
画面の「ちらつき」が気になりました。
タブで候補表示したり、無駄にバックスペース長押ししたりするときになるやつです。
調べたところ、
/etc/screenrc もしくは ~/.screenrc 内の
vbell on を
vbell off に変更するのみ。
あとは、Putty 設定 ＞ 端末 ＞ベル で無効にすればOKです。
すぐにはもちろん適用されませんので、全部閉じてアクセスし直してください。
開発環境が若干向上！すてき。
PhoneGap での開発における システム構成について
今日もPhoneGapでのスマフォアプリ開発のメモを残します。
今回は、システム構成についてのメモです。
きっかけはこちら
super.loadUrl("任意のURL");
eclipse で開発中のAndroid - PhoneGapアプリ hogeActivity.javaにて
これで、普通にアプリ上で、webページ表示できてしまうではありませんか。
※本来は、index.htmlとか指定している箇所です。
当然のことなんですけど、感動しました。
というわけで、現在想定しているシステム構成は以下の通りです。
要件は、以下の2点。
・運用・更新の容易さ
・拡張余地
サーバーサイド：phpフレームワーク + iOSとAndroidでの表示の出し分け
クライアント：PhoneGap
サーバーについては、従量課金のAWS を使い、スモールスタートで行く予定です。
あとは、表示に際しては jqMini.jsを使おうかなと考えてます。
同ページ内にサンプルのソースもあるのですが、こんな手軽でヌルヌルいくならなかなか嬉しい代物。
- 追記
と思っていたのですが、開発予定のアプリにて
固有の表現をする予定がなく、またUI的には手軽に実現したいためjQueryMobileを使ってみようかと思います。
indexページからサーバーに取りにいくかは悩ましいところですね。
indexくらいは、ローカルファイルにアクセスさせて、通信環境悪いとこでの起動時に離脱されることを少しでも減らしたいですね。
とすると、ローカルのindex.htmlにアクセスさせつつ、中身は全部ajaxで取得させて、
「ロード中です。このアプリは通信を必要とします。hogehoge。」と記載するのもありですかね。
ひとまず、ここまで。
AndroidエミュレータでPCのlocalhostへアクセスするには
最近は、率先して知識入れて手動かしてるので、メモしたいことが山ほど。
良い傾向。
いい企画者であり、いいエンジニアでありたい。そのうち、いい経営者。
まあ、さておき、今回もちょろっとした気付きをメモします。
JQuery Mobileと、PhoneGapでのアプリ開発を始めたのですが、Android開発で一つはまったところがあるので記載します。
Androidのエミュレータ上から、PCのlocalhostにアクセスする方法についてです。
当初、http://localhost/hoge と指定していたのですが、これでは、not found でした。
次に、http://127.0.0.1/hoge と指定しても、これまた not found でした。
そこでググってみた結果、こちらのサイトにて同様の事項を扱っていました。
結論としては、10.0.0.2というIPが自動で割り当てられているようで、
http://10.0.0.2/hoge にてアクセスに成功しました。
あとは、jquery mobileのjsのあとに、phonegapのjsを追加することをお忘れなくという感じですね。
ちなみに、こちらの本を買ったのですが、JQuery Mobile + PhoneGap の記載もありいい感じです。
awk の素敵な how to サイト
今日は、思いっきり備忘録。
linux上でデータファイル扱う際にいっつも触るawkさん。
そして、なぜかいつも使い方をわすれてしまうawkさん。
毎回、ぐぐるnaosk8。
ということで、自分が良く使うやつを、例示のバリエーションと丁寧な説明で紹介してるサイトを発見。
The UNIX School
http://www.theunixschool.com/2012/06/awk-10-examples-to-group-data-in-csv-or.html
こんな学校があったとは。
たまに通ってみよっと。
MySQLでの検索効率の効率化 ~ 検索用テーブルの心得 ~
今日は仕事であったエピソードを綴ります。
テーマは、検索用テーブルの心得。
結論から言うと、joinの利用が困難な状況下で、両テーブルの情報を加味したレコードを抽出したければ、
両条件を満たすレコードのみを保持する検索用テーブルを用意することで、クエリ発行数や、検索効率の改善を図ることが出来るというものです。
キーポイントは、検索用テーブルを用意することで、物理削除が許されるので、検索効率が常に保たれることですね。
== この議論のスタート地点 ==
以前勤めていたところでは、クラサバな限定的で閉ざされたシステムに携わっており、
そこではOracleを使ってましたが、普通にviewを用意して、裏で好きにjoinしていたので、
条件に合致するレコードがなければそもそもレコードは表示されませんでした。
が、しかし、現在はwebアプリケーション開発に携わっており、データ量もアクセス数も膨大であり、かつ、DBの並列分散もされているので、
joinすることは現実的ではありません。
===================
では、ここからはちょっと詳しく。
以下のテーブルがあると仮定します。
table : table_1
column : user_id, group_id, ...
table : table_2
column : group_id, status, ...
ここで、user_id群 をもとに、そのユーザ達の属するgroupのうち、特定のstatusのレコードを「取得しなければならない」とき、
単純に上記2テーブルでがんばる場合、どんなにインデックスを丁寧にはっても、
手順1. table_1 から範囲指定でgroup_idを取得
手順2. そのgroup_id達をもとにtable_2で group_id に対して IN句でレコードを取得
手順3. クエリ発行元のソースコード上で、statusでフィルタ
手順4. もしフィルタ結果が0件の場合に、手順1からやり直し、対象のレコードを取得できるまで全レコードをなめる。
と、効率性の低い処理となります。これは、多少処理の順番を変えても、結局、積集合をもとめる処理なので、似た状況となります。
これを解消する方法として、極端な話、以下のテーブルを用意します。
table : table_3
column :guild_id
このテーブルへのCRUDは以下の通り。
C : table_1へユーザレコードが生成されるときに、そのユーザのgroup.statusが特定statusである場合にcreate
R : かつあい
U : かつあい
D : ソースコード上、対象レコードのgroup.statusが特定statusでなくなったことが判明した際。（ここは柔軟に）
こうすることで、このテーブルには、user_idにひも付き、かつ、statusが条件を満たすレコードのみが残るため、
検索精度は保たれ、クエリ発行数や検索効率の面で改善を図れます。
なかなか前提が限定される話でしたが、本日はこんな感じで。
ちなみに自分も勉強中の身で、身近なメンバーと相談した結果を記述しているだけなので、あくまで参考にする程度でお願いします。
また、更なる改善案があれば、ぜひともコメント頂ければと思います。
それでは。
