Jxck's OutPut (original) (raw)
“美しく且つ単純であるべきだと信じる数学者と、単純であるが美しくないと考える物理学者と、美しいが単純でないと感じる芸術家と、美しくもないし単純でもないという心境の工学者がいる”ろんりと集合 (via naoiwata)
新しいことを学ぶメリット
Node.js を学んだり、 2013 年に Go を学んだりしている中で、色々思うことについてつらつらと。
見直しもせずに書く。
ここでは面倒なので、それを新しいパラダイムと言うけど、
新しいパラダイムが出てきて、例えばそれがバズったりとかすると、
色々な人が入ってきて ML で発言する。
Node.js が出来てきた時、それがネットワーク・サーバ系を意識していたことにより、対比として今までそれをやっていた、人々が色々な知見を披露した。
別に Node.js 自体が使い物になるかどうかは別として、
そういう人たちの話が聞けることも、 Node.js を見ている中で得られる大事なものだったと思う。
従来の、スレッドモデルにはどういう問題があったか
プリフォークの本質はなんだったのか
コールバックは何をもたらすのか
シングルスレッドで何が嬉しいか
JS が選ばれたことの意味はなんなのか
Java はどうだったのか、 Ruby はどうだったのか
Erlang の何が凄かったのか
新しく Node がどうあるべきか、何を解決できるのか、
何を解決したいのか、新たな問題はなにか、
そういう話が始まって、そこで初めて
「歴史がどう辿ってきたのか」
をまるっと知ることができる。
これは、一つ重要なメリットだと思う。
なぜなら、その裏に流れている「全体的な流れ」を学ぶのは難しいから。
各言語をただ勉強していても、なかなかそれにはたどり着けない。
今は Go で、改めてジェネリックスの立ち位置や、プリコンパイルの是非
インタフェースの設計の話が出てきたりする。
DI とは何だったのか
メッセージパッシングの意味
標準パッケージは何を持つべきか
テストはどこまでサポートされるべきか
パッケージ管理はどうするべきか
Java や Scala はどう解決してきたのか
Node はどうだったのか
Erlang は何が凄かったのか(2回目)
Go にはまだまだ新しい問題があり、
そこを解決するためには、歴史からの知見が重要になる。
つまり、 Go の新しい問題を知ることで、
そこから歴史的に何が行われてきて、
何が問題として存在していたのかを知ることができる。
歴史を学ぶのは意外と難しいけど、
人があつまる新たなパラダイムは、
それを学べる機会としてもおもしろい。
使うか使わないかももちろん大事だし、
それが自分の抱えている問題を解決するかも重要だけど。
歴史を学ぶという視点でみれば、それはそれでお得かもしれない。
あと、それを繰り返していくと
「あーこの流れ昔もあったなぁ」みたいな直感が働くようになり、
俺の先輩エンジニア達が言っているのは、そういうことなんだろうと思う。
そこですかさず、その人達が「昔あったなぁ」と思う流れを聞いてみるのは面白い。
それにとどまらず、それを踏まえて「これからどうなっていくのか」を考えるのは、もっと面白い。
1 万日
よく 1 万時間やらないとどうこうって話があるけど、それとは別の話。
http://www.ideaxidea.com/archives/2013/07/jennifer_dewalt.html
プログラミングの初心者が 180 日連続で何か作って、アップしてるらしい。ちょっと覗いてみたら、どれも初心者が作ったにしてはレベルが高くて面白かった。
そんななかでこれをたまたまこんなのを見つけた。
http://jenniferdewalt.com/party_time.html
自分の誕生日を入れると、パーティータイムを教えてくれるもの。
なんとなく入れてみたら、下にこんなのが表示された。
Your 10,000th day was Mon Jul 29 2013
1万日記念日が、今日だったらしい。そういう記念日もあるんだね。
これに気づいたのが、ちょうど 1万日記念日の 1週間くらい前だったから、あまりの調度良さにびっくりした。
で、今日がせっかくの 1 万日記念日なわけだけど、別になんのイベントもない普通の一日を過ごして、家に帰ってきてなんとなくこのことを思い出したのでちょっと書きのこしてもいいかなと思った。
1 万日。あまり実感ないけど、まあそんだけ生きてきたんだなと。
一応大きな病気や怪我もなく、それなりに元気に生きてこれたんだから、特に親には感謝したいと思う。
親はそろそろ歳だ、でもまだ元気だ。それが純粋に嬉しいと、最近すごく思う。
このごろ実家に帰る機会も減ってるから、もう少し顔を出そうかな。めちゃくちゃ遠いわけでもないし。
振り返ってみると、なんかそれなりに色々やった気もする。紆余曲折あって、いつも数年前の自分では想像できないことをやってるって意味では、まあ世の中そう思い通りには行かないものなんだなと思いつつ。
今自分がいる業界に来ることも、数年前からすると想像できないことだったかも。
でもそれは全く後悔していない。
時には腑に落ちないものもあったし、嫌なことも上げきれないほどある。でも、そのぶん納得をしてやってきたこともあったと思うし、なんだかんだ得るものが多かったと思える。
そう考えると充実はしてたかも。
最近色々な場所に顔を出して、色々な人に会って話したりして、それが楽しいから、周りにも恵まれてるのかなと思ってる。
そうした人たちに大事なことを教わることができて、良い影響を沢山うけた。ありがたいと思う。
ここ数年は人生で一番勉強してる。それは、依然として楽しい。自分の強みと言えそうなものも、少しづつ身についてきたと思う。
色々な人に教えてもらい、時にはチャンスを頂いたりしながら、なんとか必死に食らいついてる感じ。最近は自分が学んできたことを返す機会もできたりして、そういう機会はやっぱり出来る限りのことをしたいと思ってる。
アウトプットとインプットのバランスは心がけてる。そしてアウトプットする人の元には自然と情報が集まることも学んだ。継続的なアウトプットは、継続的なインプットにつながる。このサイクルは自分なりのやり方もできてきたし、続けて行きたい。
一番面倒なのは、公私がわけにくくなってきたこと。これはこれからの課題になるかもしれない。
学ぶことは尽きない、それはこれからもずっと続くだろうし、それが嫌だとは思ったことはない。多分、楽しいんだと思う。幸せなことだ。
とはいっても、現状には悩む所も多い。環境は、言い訳にはしたくないと思ってる。でも個人での限界を感じることもある。そういう意味ではそろそろ新しいフェーズに挑戦したいなと思うところも。今の自分に満足してるかと言うとそうとも言い切れないし、かと言ってどうするかも定まってない部分がある。自分には何ができるのか。この辺も、見直すにはいい機会なのかなと思う。
生まれて、1万日たって至った自分はまだ未熟で未完成でしょうもない人間だったけど、少なくとも次の 1万日も、後悔しないように生きて行きたい。
自分のような未熟者を、育ててくれたり、目をかけてくれたり、心配してくれたりする全ての人に感謝をしながら。
2012/7/29 Jxck
Google で検索結果を直近 3ヶ月に絞る
小ネタなので、ひさびさにこっちに。
Google の検索結果の期間指定ができるのは結構前からですが、
この期間は
- 1時間
- 24時間
- 1週間
- 1ヶ月
- 1年
の選択肢しかない。
「欲しいのは 3ヶ月なんだよ！！」
と思うのは自分だけでしょうか？
(1ヶ月は近いし、1年は長い)
で、それをやるには検索結果の URL に
"&tbs=qdr:m3"
という文字列をつけるだけでできます。
ってのはあまり知られてないようなので。
詳しく言うと
&tbs=qdr
の後ろに
- 1時間 = :h
- 24時間 = :d
- 1週間 = :w
- 1ヶ月 = :m
- 1年 = :y
という感じ、その後ろに数字を加えることで :y2 (2年以内) みたいに調整できます。
3ヶ月以内、をブックマークレットにするなら
javascript:location.href += '&tbs=qdr:m3'
小ネタでした。
ここまでの HTTP 2.0 のまとめメモ
openssl でファイル暗号化
openssl コマンドって、直接叩いてファイルを暗号化できることをしらなかったのでメモ。
ちょっとファイルに鍵をかけたい場合に便利そう。
開発機なら大体 openssl-dev とか入れている気がするので、すぐ使えると思う。
ファイルの暗号化に使えるのは openssl enc コマンドで、そのヘルプは openssl enc help で見ることができる。
覚えておきたいのは以下のコマンド
-in 入力ファイル -out 出力ファイル -e encrypt(暗号化) -d decrypt(復号化)
暗号化方法は色々選べる。同じく help で確認できる。
いくつかあって、あまり詳しくはないけど -aes-256-cbc あたりを選んでおけば良さそう。
ファイルの暗号化はこう。
$ openssl enc -e -aes-256-cbc -in test.txt -out test.txt.enc
復号化はこう
$ openssl enc -d -aes-256-cbc -in test.txt.enc -out test.txt.dec
いずれもプロンプトからパスワードを入れればいい。
Socket.IO で RangeError: Maximum call stack size exceeded #nodejs_jp
Node.js v0.7 系から、 EventEmitter の変更が原因で、 Socket.IO が落ちるバグが発生しています。
具体的には Socket.IO@0.9.6(およびそれ以前) を node@0.7.8(及び 0.7.x 全般) で起動した後、ブラウザからアクセスしたら、下記のようなトレースを吐いて落ちます。
Jxck$ node server.js info - socket.io started
/../gist-2292777/node_modules/socket.io/lib/manager.js:0 (function (exports, require, module, __filename, __dirname) { /*! ^ RangeError: Maximum call stack size exceeded
上記を再現できるソースはこちら。なんでもないサーバ実装です。
https://gist.github.com/2292777
このバグの原因は、Node.js 本体の EventEmitter にあったこの修正です。
https://github.com/joyent/node/commit/78dc13fbf97e2e3003e6f3baacdd5ff60e8de3f7
これにより、Socket.IO サーバ内で無限ループな感じになって、スタックが食いちぎられます。
そして、対応する Socket.IO への修正はこちら。
https://github.com/LearnBoost/socket.io/commit/e1884859bcbb57daeb843421cc5b4b95bd914bd8
しかし、socket.io@0.9.6 リリースの直後にコミットされて、まだ socket.io@0.9.7 がリリースされていないため、
自分でリポジトリから直接 clone して使うか、 node@0.6 系で動かすしか方法が無いです。
おそらく、 socket.io@0.9.8 がリリースされれば治るとは思いますが、
node@0.7 系は unstable だということで、 node@0.6 系の stable の方を重視するような
意味合いのコメントがどっかにありました。そういわれればまあ仕方ないのですが、
とりあえずハマった方々バージョンを見なおしてみてください。
Socket.IO-Spec を翻訳しました。 #nodejs_jp
Socket.IO と WebSocket が混同されてることある。
Socket.IO は WebSocket の上位プロトコルを定義していて、
それは生の WebSocket とは違う。
で、その仕様はドキュメントとは別、
というか Socket.IO とは別のリポジトリで管理されていて、
以下にある。(たぶん、仕様は別で議論/管理したかったんだと思う。)
https://github.com/LearnBoost/socket.io-spec
で、これあまり表に出てないけど、結構重要だということで翻訳しました。
https://github.com/Jxck/socket.io-spec
これは Socket.IO を正しく理解し、使用するためには必須の知識です。
またを喋れれば、 Node.js じゃないクライアントも書けます。
翻訳ですが、あまり時間がかけられなかったのもあるけど、
なんか微妙に難しかった気が。。
翻訳でも日本語自体でもとにかく issue/pull request 歓迎です。
あと、これ大事だから本体のマニュアルにもう少し近づけてもいいんじゃないかなと思うので、
そのうち本家に相談してみようかなと思ってます。
ちなみに、やってる途中で見つけた typo を本家に pull req したら、
Guille に電光石火でマージされてビビったw
内容が簡単だとこんなに早いんだな。
WebSocket が開く未来を、多分開けてない俺達
今日こんなことを聞かれた。
https://twitter.com/#!/bluerabbit777jp/status/176982463040602112
@Jxck_ の考えるWebSocketで今後Webがどうなるか？聞きたいなぁーー
で、まあ素直に
@bluerabbit777jp むしろ俺が聞きたいですw
などと答えてしまったわけですが。。
これじゃあんまりにもあんまりにもなので少しだけ。
ずっと
「WebSocket できる事があまりにも多く、俺達はその可能性を10%も引き出せてないんじゃないかな」
とは漠然と思ってる。
文章を共有することを目的として、ステートレスでプルベースが基本だった Web を、
色んな目的からこれでもかってくらいいじって使いたおしてきたんだけど、
ステートフルでプッシュ可能な技術を手に入れて、
「これであれもできるし、これもできるし、世界変わるぜ！！」って走りだした割には、
チャットとかゲームとか、すでに出尽くしちゃったアイデアから離れられていない感。
個人的には管理系ツールあたりは美味しさがわかりやすいかなというのがあるので、
そのへんのツールは作ってみようかと思ってる。(tail -f ってリアルタイムだし)
リアルタイムで言えば、Wave とか個人的にはとても重要だったと思う。
あれも結局みんなあまり「使いこなせてなかった」よね。
逆にもう少し Wave が続けば、そこで色々試して遊んで
「あーリアルタイムだと、こんなこと出来るな」みたいな
発見や学習ができたと思うんだよね。
Wave を途中で止まらなければ、 Web の進化はもう少しはやかったかもね。
(みんなのパラダイムシフトを後押ししたかもって意味で)
足りてないのがアイデアなのか、技術者が実はパラダイムシフトできていないだけなのか、
そもそもそんなものみんなそこまで必要としてなかったのか。
あんまりよくわからないけど、このままだと「なんだかんだ使いこなせない時代」は少し続きそうな気がする。
まあ、でも Flash とかでは Push もずっとできてたんだから、期待しすぎなのかな。
あー、っていうか「その使いこなす」って何だよってことを聞かれてた気がしてきた。
使いこなせてないんでよくわかりません。