勉強会の参加記録が滞っていたので本日二つ目の記事。
あおおにくん(@aooni_kun)さんとくれすとさんと、合わせて三人という、こぢんまりした感じで。
最初は大阪ドームそばのイオンのフードコートで開催予定だったのですが、ドームでライブがある日だったらしく、会場の開場?まで席が空きそうにない事態に。急遽上本町へ移動して、カフェでの開催となりました。
そういえば、阪神なんば線の新しい区間に乗ったの初めてでした。
あおおにくんさんも、くれすとさんも、ある程度Hackを嗜んでおられるようで、わたしは名前は聞いたことあるけど・・・程度の予習なしで行ったため、マンツーマンならぬツーメンズツーマンみたいな(聞いたことない)感じで、いろいろとHackの魅力を教えてもらいました。
最近わたしが書くコードは、ほとんどPHPとJavaScriptばかりで、あとは趣味でC++を少し(better cに少し毛が生えた程度)と、以前に仕事で.Net 2.0の頃までのVBとC#を書いていたという知識だったのですが、「PHPとC++とC#を足した」感じの言語だなと思いました。
PHPとJavaScriptを書いていて思うのは、やっぱり型は大事だなと。
PHP7でもその辺りは強化されますが、Hackはインタープリタではなくコンパイルして実行されるので、そのあたりの動きが厳密になっており、言語仕様の曖昧さによるハマリを極力無くそうとしている姿勢が感じられました。
PHPの「とりあえず書きゃ動くだろ」というのも入門としては便利だと思うのですが、HTMLの中にちょっと書いていた時代とは変わってしまったので・・・、PHPは広く使われすぎたんだ・・・。
いろいろ聞いたHackの魅力の中で、個人的好感度トップは、「システム内でファイルが混在可能」「コンストラクタの定義が楽」というあたりでしょうか。
Hackはファイル毎にPHPとHackが混ぜられるので、PHPのモジュールからHackを呼んだりその逆ができたりします。たまに言語自体を乗り換えてシステム全体をリライトした事例を聞いたりしますが、いやぁ大変だろうなぁと思います。混在可能な利点は、このようなときにモジュール単位で書き換えていけるということです。
Hackのチュートリアルがあるので、これはぜひ試してもらいたいです。
新しい言語と聞くと身構えてしまいますが、これのおかげで「Hack怖くないよ」と感じられるかと思います。
解いている途中で、なんかC++を書いている気分になって、PHPのlist関数が出てきたのにPHPだと頭が理解できませんでした。それぐらいに新鮮な感じで書けると思います。
(連想配列大好きっ子で、listをあまり使わないせいもある)
以前、HackのベースとなるHHVMが、まだHipHopPHPと呼ばれていた頃、PHPの速度に悩まされて自分でビルドしようとしたことがあるのですが、どうにもビルドできなくていろいろなモジュールを入れ替える羽目になり、入れ替えすぎてCentOSが動かなくなるという罠に陥りました。
名前も変わってかなり高速に進化しているようなので、ちょっと環境を作って乗り換えできるか試してみようかなと思います。
HHVMだと、使えるモジュールがまだ限られているというようなことを以前聞いたので、自前でビルドしたモジュールなんかが使えるのかどうかチャレンジしてみたい。
7月 25, 2015
elasticsearch勉強会へ参加 & elasticsearchについて雑感
7月13日に大阪のYahoo事務所でelasticsearchの勉強会へ参加してきました。
ブログを書いていなくて、これを書いているのは7月25日ともう2週間も経ちますが、つらつらと。
内容はelasticの中の人である @johtani さんの「Elasticsearchの紹介」
@takuya_a さんの「Elasticsearch での類似文書検索と More Like This API 詳解」
@5kozawa さんの「Elasticsearchを用いたはてなブックマークのトピック生成」
でした。
elasticsearchというと、よく聞くのがWebサーバのログをelasticsearchに放り込んで、kibanaで綺麗なグラフを描くというやつですが、今回の勉強会は本来?の使い方でもある検索に焦点を絞ったものでした。
わたしもelasticsearchは、趣味と仕事で少しだけ使っていますが、趣味の方はアクセス解析、仕事の方は全文検索で利用しています。
仕事でいろいろ試してみた限りでは、かなり検索の性能も良さそうでした。
現在、ふぁぼるっくで使っているPostgreSQLでもいろいろと不満点が溜まってきているので、いずれは別のデータベースに乗り換えたいなぁと思っています。
勉強会では、かなり検索に特化した使い方を紹介して貰えたので、たぶん何とかなるだろうなとは思うのですが、いろいろな制約からPostgreSQLの使い方がアクロバティックになっているので、その辺りが解決できるかどうかを調べていかないといけないなぁと。
現状の問題点と調べること
1.RDSでよく参照される最近のデータを保存、古いあまり参照されない古いデータを自宅サーバで保存。日次バッチでデータ移動している。
elasticsearchでも、複数ノードで手動リバランスができるらしいので、 「このデータ境界以前をこのサーバに保存しろ」ということができるかどうか。
2.全文検索はsphinxsearchを利用して、RDSからデータをコピーしている。全てのデータをインデックス化できないので、最近のデータだけ。
上の項目と関連して、特定のサーバだけで全文検索を生成できるかどうか。
3.数十億レコード(2TB)のデータを自宅サーバ一台で満足のいくパフォーマンスが出せるか。
ノード分割が前提となっていると、自宅サーバやEC2の台数で破産してしまう。
すべてはふぁぼるっくで収益が上がれば解決なのですが、そこまで行ってないのが難点ですね。
ブログを書いていなくて、これを書いているのは7月25日ともう2週間も経ちますが、つらつらと。
内容はelasticの中の人である @johtani さんの「Elasticsearchの紹介」
@takuya_a さんの「Elasticsearch での類似文書検索と More Like This API 詳解」
@5kozawa さんの「Elasticsearchを用いたはてなブックマークのトピック生成」
でした。
elasticsearchというと、よく聞くのがWebサーバのログをelasticsearchに放り込んで、kibanaで綺麗なグラフを描くというやつですが、今回の勉強会は本来?の使い方でもある検索に焦点を絞ったものでした。
わたしもelasticsearchは、趣味と仕事で少しだけ使っていますが、趣味の方はアクセス解析、仕事の方は全文検索で利用しています。
仕事でいろいろ試してみた限りでは、かなり検索の性能も良さそうでした。
現在、ふぁぼるっくで使っているPostgreSQLでもいろいろと不満点が溜まってきているので、いずれは別のデータベースに乗り換えたいなぁと思っています。
勉強会では、かなり検索に特化した使い方を紹介して貰えたので、たぶん何とかなるだろうなとは思うのですが、いろいろな制約からPostgreSQLの使い方がアクロバティックになっているので、その辺りが解決できるかどうかを調べていかないといけないなぁと。
現状の問題点と調べること
1.RDSでよく参照される最近のデータを保存、古いあまり参照されない古いデータを自宅サーバで保存。日次バッチでデータ移動している。
elasticsearchでも、複数ノードで手動リバランスができるらしいので、 「このデータ境界以前をこのサーバに保存しろ」ということができるかどうか。
2.全文検索はsphinxsearchを利用して、RDSからデータをコピーしている。全てのデータをインデックス化できないので、最近のデータだけ。
上の項目と関連して、特定のサーバだけで全文検索を生成できるかどうか。
3.数十億レコード(2TB)のデータを自宅サーバ一台で満足のいくパフォーマンスが出せるか。
ノード分割が前提となっていると、自宅サーバやEC2の台数で破産してしまう。
すべてはふぁぼるっくで収益が上がれば解決なのですが、そこまで行ってないのが難点ですね。
7月 16, 2015
通信の最適化について
ここ数日、携帯電話キャリアによる「通信の最適化」の話が広がっています。
わたしの考えとしては、 「キャリアの言い分はわかるが、やり方が不味いので反対」です。
この問題についての議論を追っていくと、大抵泥沼になっています。
いくつかの問題に分けることで整理ができると思います。
それぞれが、別々の問題を指して議論をするので、平行線になってしまうのです。
1.発端となった非可逆圧縮について。
利用者「データが元に戻せないなんて困る」
回線提供者「綺麗な富士山の写真が、とりあえず山の写真だと分かれば何も問題はない」
2.勝手に非可逆圧縮を適用したことについて。
利用者「聞いていない」
回線提供者「店で説明して同意したはず」
3.データの意味を理解して非可逆圧縮を行ったことについて。
利用者「通信の秘密を侵している」
回線提供者「店で説明したから問題ない」
2番と3番については、結局のところ店舗でのサービスが悪いというところにつきるのかと思います。
多くの「聞いていない」という声が上がった時点で、回線提供者は一端通信の最適化を中断し、店舗に対して再度教育を行い、説明を徹底させるべきです。
また聞いていない利用者が多いのなら、再度個別に連絡を取って了解を取り付けるべきかと思います。
「そんなコストは・・・」という声が聞こえてきそうですが、店舗の教育を怠ったツケでしょう。
店舗でキャリアが決めた説明事項をきちんと説明できているか、客のふりをして潜入調査とかしないものなのかな?と思いますが、性善説で動いた方がコストは掛からないですし、疑いたくない気持ちは分かります。しかし通信の最適化に限らず聞こえてくる店舗の契約トラブルを考えると、もうそんなことを言っていられないのではないかと思いました。
誠実な商売をして欲しいものです。
そして1番。
2番と3番で客が承諾した場合に、晴れて1番を実施してよいかと思います。
「富士山の写真が山みたいな形の画像になります」
個人的には嫌ですね。
でも、それでも良いという人もいるでしょう。そういう方は利用すればいいのです。
OperaのOperaTurboとか、Chromeのデータセーバーが同じ機能ですね。
ブラウジングが快適になることで、軽減されるストレスもあるかと思います。
「劣化するのが嫌」という意見に対して「音声も劣化しているのだから良いではないか」という意見をTwitterで見かけましたが、それは比較が違うかと思いました。
「夕焼けに照らされる富士山の綺麗な写真」が「どこかの山がオレンジ色に光っている」状態になるのは、JPEGという画像ファイルの意味を理解して劣化させるわけです。音声通信で特定の周波数をカットするのとは違って、意味を理解して劣化させるのですから、「単身赴任先から子供に電話をしたら桃太郎の話をせがまれて、何度も読んだことのあるお父さんは、暗記したお話を電話口で感情を込めて語った桃太郎の話」が「おばあさんが川で桃を拾ったら子供が出てきて、大きくなって鬼ヶ島へ行って鬼を退治しました」という要約しか子供には聞こえてこないわけです。
意味を理解して非可逆圧縮するというのは、こういうことです。
それを受け入れられる人は使えば良いかと思います。
繰り返しますが、きちんと顧客が了承した場合のみ、実施が可能です。
キャリアの帯域が足りなくなっていることは理解できます。一部の利用者によって、多くのリソースが割かれていることも理解できます。
しかし、それなら定額制などやめて、従量制にすれば良いのです。
そんなわたしは、定額制があったとしてもキャリアのパケット通信価格が高すぎて、MVNOでしかインターネットは使っていません。心情的に非可逆圧縮が嫌なので、キャリアが通信の最適化を続けるなら今後も使うことはないと思います。
MVNOでも実施しだしたら・・・、どこか1社ぐらいは非可逆圧縮を実施しない会社が残るでしょう。
「音声がクリア」 を売り文句にする通信会社があるぐらいですから、「画像が綺麗」を売り文句にする通信会社も出てくるでしょう。
例として挙げた「音声通信の内容を要約して送信」は、ある分野では希望があるかもしれませんね。
いつも同じ話か、話が脱線しまくって本題に進まない人との通話とか(笑)
わたしの考えとしては、 「キャリアの言い分はわかるが、やり方が不味いので反対」です。
この問題についての議論を追っていくと、大抵泥沼になっています。
いくつかの問題に分けることで整理ができると思います。
それぞれが、別々の問題を指して議論をするので、平行線になってしまうのです。
1.発端となった非可逆圧縮について。
利用者「データが元に戻せないなんて困る」
回線提供者「綺麗な富士山の写真が、とりあえず山の写真だと分かれば何も問題はない」
2.勝手に非可逆圧縮を適用したことについて。
利用者「聞いていない」
回線提供者「店で説明して同意したはず」
3.データの意味を理解して非可逆圧縮を行ったことについて。
利用者「通信の秘密を侵している」
回線提供者「店で説明したから問題ない」
2番と3番については、結局のところ店舗でのサービスが悪いというところにつきるのかと思います。
多くの「聞いていない」という声が上がった時点で、回線提供者は一端通信の最適化を中断し、店舗に対して再度教育を行い、説明を徹底させるべきです。
また聞いていない利用者が多いのなら、再度個別に連絡を取って了解を取り付けるべきかと思います。
「そんなコストは・・・」という声が聞こえてきそうですが、店舗の教育を怠ったツケでしょう。
店舗でキャリアが決めた説明事項をきちんと説明できているか、客のふりをして潜入調査とかしないものなのかな?と思いますが、性善説で動いた方がコストは掛からないですし、疑いたくない気持ちは分かります。しかし通信の最適化に限らず聞こえてくる店舗の契約トラブルを考えると、もうそんなことを言っていられないのではないかと思いました。
誠実な商売をして欲しいものです。
そして1番。
2番と3番で客が承諾した場合に、晴れて1番を実施してよいかと思います。
「富士山の写真が山みたいな形の画像になります」
個人的には嫌ですね。
でも、それでも良いという人もいるでしょう。そういう方は利用すればいいのです。
OperaのOperaTurboとか、Chromeのデータセーバーが同じ機能ですね。
ブラウジングが快適になることで、軽減されるストレスもあるかと思います。
「劣化するのが嫌」という意見に対して「音声も劣化しているのだから良いではないか」という意見をTwitterで見かけましたが、それは比較が違うかと思いました。
「夕焼けに照らされる富士山の綺麗な写真」が「どこかの山がオレンジ色に光っている」状態になるのは、JPEGという画像ファイルの意味を理解して劣化させるわけです。音声通信で特定の周波数をカットするのとは違って、意味を理解して劣化させるのですから、「単身赴任先から子供に電話をしたら桃太郎の話をせがまれて、何度も読んだことのあるお父さんは、暗記したお話を電話口で感情を込めて語った桃太郎の話」が「おばあさんが川で桃を拾ったら子供が出てきて、大きくなって鬼ヶ島へ行って鬼を退治しました」という要約しか子供には聞こえてこないわけです。
意味を理解して非可逆圧縮するというのは、こういうことです。
それを受け入れられる人は使えば良いかと思います。
繰り返しますが、きちんと顧客が了承した場合のみ、実施が可能です。
キャリアの帯域が足りなくなっていることは理解できます。一部の利用者によって、多くのリソースが割かれていることも理解できます。
しかし、それなら定額制などやめて、従量制にすれば良いのです。
そんなわたしは、定額制があったとしてもキャリアのパケット通信価格が高すぎて、MVNOでしかインターネットは使っていません。心情的に非可逆圧縮が嫌なので、キャリアが通信の最適化を続けるなら今後も使うことはないと思います。
MVNOでも実施しだしたら・・・、どこか1社ぐらいは非可逆圧縮を実施しない会社が残るでしょう。
「音声がクリア」 を売り文句にする通信会社があるぐらいですから、「画像が綺麗」を売り文句にする通信会社も出てくるでしょう。
例として挙げた「音声通信の内容を要約して送信」は、ある分野では希望があるかもしれませんね。
いつも同じ話か、話が脱線しまくって本題に進まない人との通話とか(笑)