Ayo.js とは 「Node.js の fork です。」と言ってもまだできたばかりで正直このタイミングで記事にしてもまだ語ることはそんなに多くないです。 ただし、JavaScript界隈が騒ぎになりかけていることは確かです。日本でも発言が増えてきたので自分なりにまとめて今時点での話をしようと思います。 ちなみに読み方は好きに読んでくれ、と言われてます。 「アイ・オー」でもいいし、「エイ・ヨー」でも良いとのことです。ネーミング的には昔あった io.js fork騒動を想起させるネーミングになってます。もしも io.js についてご存じない方もいるのであれば、こちらをご参照ください。 yosuke-furukawa.hatenablog.com Ayo.js の目的 https://github.com/ayojs/ayo/blob/zkat/values/VALUES.md ここを見ると

2016年になってから色んなソフトウェアエンジニアの人と話してきて、その中で3人から聞いた例え話、格言、小噺が面白かったので、僕の中だけで留めておかずに開放しておく。 息継ぎをするには『まず息を吐く』という例え話 水泳で息継ぎをするなら『まず息を吐きなさい』と教わるらしい。これは息を吐かずにどこかで息を貯めてしまうと、ちゃんと息を吸えないという事を意味してる。息を吐くと苦しくなって顔は絶対に水面に出る。 これと同じことがソフトウェアの学習にも言える。 つまりまずアウトプットする、なんでも良い。作ったものをGitHubに公開するとか、発表するとか、ブログやQiitaに書くとか。ちゃんとアウトプットしたものはフィードバックがあり、そのフィードバックを受ける(PRやissue, 質問, マサカリ etc)、どんどん吐き出していくと吸わないとネタがなくなるので、吸い込むためにまたインプットする。

前書き このエントリーは Recruit Engineers Advent Calendar の 1日目の記事です。 www.adventar.org リクルートテクノロジーズのフロントエンド開発 リクルートテクノロジーズではいくつもの並行するタスクが走っていて、プラットフォーム基盤と呼ばれる基盤技術開発とインフラソリューションと呼ばれるインフラ開発、後はアプリケーション開発支援などのタスクが存在します。 アプリケーション開発支援の中でもウェブフロントエンド開発は目下のところ重要タスクとされており、色んなやり方をトライアルしています。 基本的には、 React Redux Node.js という組み合わせでフロントエンド開発をしています。 主には以前 ubb.jp というイベントで発表したこの資料に記載されている内容でやっていますが、諸々補足します。 リッチなウェブアプリケーションを作るた

現在開発中のシステムにリアルタイムな処理があり、そこで socket.io を使おうかなと思ってて、そういう折にタイムリーにもこの辺りの記事がタイムラインで出てきたのでメモ代わりに自分の意見を残しておく。 blog.jxck.io qiita.com socket.io が提供してくれているもの 「ブラウザとサーバ間のプロトコル」という観点で見ると socket.io は WebSocket を基本として繋がらなかった時に XHR Long Polling や polling といった形式の代替手段を提供してくれるもの、という位置づけ。 一方で「ライブラリ」という観点で見ると socket.io はリアルタイムアプリケーションを作る際に必要になる処理をまとめて実装し、クライアントとサーバ間での EventEmitter として抽象化してくれているもの、という風になる。 もう少し噛み砕いて言

さて、とうとう皆さん待望の Node.js v6.0 がリリースされました！次のLTS候補です。LTSになるのは2016年の10月からの予定です。v6 の LTS 期間は明示化されてないですが、ルールに照らし合わせれば、LTSになってから 2年半がサポート期間なので、おそらく 2019年4月まではサポートされます。 Node v6.0.0 (Current) | Node.js Node.js v6.0 の主な変更点 ES2015 support の改善 module load性能の改善 Buffer API の new Buffer() コンストラクタの廃止 (セキュリティ上の理由から) ES2015 support の改善 やっぱりこれが一番大きな変化ですね。 node.green を見てもらえればわかるかもしれませんが、 ES2015 のサポートがこれまでは 58% だったのが 96

この週末にこの話を書こうと思っていたのですが、筆不精なもので土日を普通に過ごしてしまいました。 さて、表題の通りDeNAを卒業することになりました。 今回は技術的な話ではなく、単純にライフステージの変化の話なので気にならない人は読み飛ばしてください。 DeNAに入社したのは3年半前 yosuke-furukawa.hatenablog.com だいぶ昔の記事ですね。この時は同年代や年下の若いエンジニア達がメキメキと力をつけていく中で「なんとかしなければ」という焦燥感で常に何かしらをウォッチしつつ、新しい技術があれば飛びついて調べ、アウトプットする、というようなことをやってました。（今でもアンテナは張っているつもりです） そんな折に DeNA に誘われて入社できたのは非常にラッキーだったと思っています。新しい技術を積極的に採用しつつも、ある程度冷静かつ成熟した判断をしている部分があり、しかも

ちょっと最近Fallout4でサンクチュアリを開発するのに忙しすぎてOSS界隈の仕事サボってしまっていたので、31日にして書かないといけない記事が2つほど残っていることに気づきました。 なので、一個をこの場で投下しておきます。 手短に言うと、electronicaというworkshopperを作りました。 github.com $ npm install electronica -g $ electronicaで起動します。最初はHello Electron から始まり、最終的に小さなブラウザを作るくらいまでの事をやります。 残念ながら、verifyは動かないので、終わったたら自己判断で次のexerciseをやらないといけないので、まだNodeSchoolで使えるまでは行かないのですが、暇な冬休みにやってみてください。 僕はこの冬休みにはverifyがちゃんと動くようにします。 では次の記

※ 追記： id:TokyoIncidents さん"補足"の誤字修正しました、ありがとうございます!! これからYeomanに関して説明していきます。 Yeoman自体が何者なのかよくわかっていない人も多いと思います。また、ある程度Yeomanの概要は知っているので、generatorの作り方が知りたい、という方もいると思います。今回は三部構成で、yeomanを使う話、yeomanのgeneratorを作る話、最後にyeomanのAPIに関して説明していきます。今回は第一部のyeomanを使う話について説明します。 Yeomanとは Google社が作成した総合開発ツール群です、「ヨーマン」と呼びます。公式サイトには MODERN WORKFLOWS FOR MODERN WEBAPPS (モダンWEBアプリケーションのためのモダンワークフロー) と記述されています。 Yeomanを使う

さて、JSON5についての紹介です、みんなjsonを使って色んなリソースを表現すると思いますが、jsonって色々と不便ですよね。 よく挙げられるjsonの不満： ケツカンマが使えない コメントが入れられない keyに必ずquoteが必要 などなど。 この手の話はよくあるんですが、これは仕様で決まってしまっていることなのでどうしようもないです。 この手の話が出る度に色んな解決策があります。jsonじゃなくてyaml使おうとか、csonいいよ、とか、jsonでparseできなかったらevalしてjavascriptオブジェクトにしちゃおうとか。 んで、もう一つの解決策として、JSON5っていうYet AnotherなJSON形式があるわけです。 これ使うと普通のJSONはJSONとしても読み込めるし、上にある、コメントやケツカンマ、ダブルクオートの問題も解決されます。どうしてもコメント入れたい

Gruntについて最新の気持ち ::ハブろぐ 上記のブログエントリを読んで非常に今自分が感じていることと共通点を感じました。 Gruntに対する最新の気持ちでは2つの問題提起がされてました。 1. Gruntfile.jsが長すぎる(700行とか) 2. そもそも全部gruntでやらなきゃいけないのか 1.に関しては色んな解決手段があります、ブログの筆者も解決されているようですし、この件に関しては次回のMaintainable Gruntfile.jsで触れます。 最初は2.に関しての、全部gruntでやらなきゃいけないんだっけ、という疑問に関してです。 僕も同じ思いをしてたので、同調してブログを書きます。 gruntについて 言わずと知れたタスクランナーですね、gruntを使うとjavascriptのminifyやmeta cssのコンパイルといったフロントエンドにありがちな作業を自動化

年末にDocker触ってて、これをうまく活かせば、副作用を無視した使い捨てのテスト環境が作れるんじゃねーかな、という意識が高まったのですが、手を付けられずにうにゃうにゃしてました。 そうこうする内に yahooのデベロッパーの方からJenkins with Dockerというタイトルの発表があり、ほぼ僕のやりたい事のベースができていたので、これをforkして、travis.yml parserや若干のバグフィックスを入れてもう少しだけTravisに近づけてみました。 ちなみにこれは 社内 Immutable Infrastructure ハッカソンした時の成果物です。 Immutable Infrastructure Hackathon at :D を開催したら、configspec の敷居が高いのでコミッタになっていました - sonots:blog 今回の成果物に関して、詳しくはここを

自分が退職エントリを書くことになる、というのは一年前、このブログを初めた時には考えもしなかった。この数ヶ月間、いくつか考えることがあったので、自分のためにも残しておく。 今回のエントリは多分めちゃくちゃ長いです。 最後にまとめがあるので、そこを見るだけでもいいと思います。 バックグラウンド的な まず、今の会社、富士ゼロックスに入社が決まった時から「この会社に一生勤めよう」とか、「安定したメーカーに就職できたからこれで安泰だ」とかは全く思っていなかった。 せっかくエンジニアになったのだから、「ユーザーの生活・働き方が変わるようなイノベーティブな製品を作りたい」という思いを持ち、それを叶えようと思っていた。 富士ゼロックスに勤めると、プリンター、コピー機だけじゃなくて、ソフトウェア含めて色んなモノを開発しているから自分の視野の拡大できるだろうし、富士ゼロックスにはFXPALっていうソフトウェア