ローカルの開発環境、開発コードの結合環境、商用環境など、1つのプロジェクトで環境ごとに複数のRequirements Fileを使いたいケースがあると思います。そんなときはファイルを分割しましょう。 …とこないだ知ったことをメモります。 手順 Requirements Fileの保存用ディレクトリを作る 環境別のRequirements Fileを保存するためにディレクトリを作成します。

既に12月22日ですが、このエントリーは、Node.js Advent Calendar 2014の13日目のエントリーです。 いや私が書くの遅れたわけじゃないですけど…(言い訳)、ちょうどタイムリーなネタがあるので、先日リリースされたNode-v0.10.34で発生した（現在も継続している）問題について携わった経緯を自分の目線で書いてみます。 追記：日本時間の12/24にNode-v0.10.35がリリースされました。 http://blog.nodejs.org/2014/12/23/node-v0-10-35-stable/ 本記事の不具合も修正されています。 1. Node-v0.10.34リリース直後にissue発生 先週12/17にNode v0.10.34 (Stable)がリリースされました。10月中旬にPOODLE騒ぎでOpenSSLに対応した Node-v0.10.33

この記事はLinux Advent Calendar 2014の5日目の記事です。 Linuxカーネルのシステムコールをhookしたい場合にどうやるかという話です。試したカーネルは3.18.0-rc6です。 まずシステムコールですが、これはテーブルで管理されていて、各要素はNR_システムコール名（NR_closeとか）という形でインデックスを指定してアクセスできます。 そしてこのテーブルはsys_call_tableという名前です。System.mapを見ると以下のような感じで見つけられると思います。 masami@kerntest:~$ grep sys_call_table /boot/System.map-3.18.0-rc6-ktest ffffffff81601600 R sys_call_table ffffffff8160cf80 R ia32_sys_call_table

僕はcoffeescriptは人類がプログラミングにおいて堕落するために手に入れた最高のゆるふわ文法だと思っていて、これを殺すわけにはいかない、という気持ちがある。で、es6/typed annotationが跋扈するこの時代にふさわしいものに改造されないといけないとも思っている。最近だと、正直coffeescript方面のイノベーションはあんまりない。 そういうわけで、ちょっと前までtyped-coffee-scriptを作ってたんだけど、現状ある種の問題を迎えていて、開発が半年ほど止まっている。それをどうするかということを考えた結果、別の型付きaltjsに乗りゃいいじゃん、という発想に至った。 altjs on altjsってどうなの、っていう問題もあるが、基本的にflowtypeもtypescriptもes6~以降との標準化追従する方向性であり、そう大きな問題になることはない、と認識

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

今回はReact.jsとも関わりがあるFluxについて紹介したいと思います。 Flux is Architecture ↑の図はfacebookのfluxのリポジトリにあるものですが、Fluxは上記のようなArchitectureの名称です。facebook/fluxのrepositoryに行ってもらうとわかるのですが、実装としてはDispatcherの部分があるだけです。 Unidirectional data flow 先ほどの図を見てもらうとわかる通り、Fluxではアプリケーションの複雑さをなくすため、データの流れを一方向にします。 そのため全体の処理の流れはわかりやすくなりますが、Angular.jsなどで書くときに比べて冗長に感じることもあるかと思います。 しかしながら単純なデータの流れを作ることで、ある程度の規模になってアプリケーションが複雑化してもデータやイベントの流れがスパ

JavaScriptフレームワークがMVCであろうがMVVMであろうがMVPであろうがこういったことを議論するよりもまずは手を動かそうというのはとても理解できる話だと思います。作っているときに各モジュールをどう構造化するかが悩むことがありますが、その時に「こうやれば効率がいい」というものを見極めることも重要と思います。 MVC vs MVVM vs MVP. What a controversial topic that many developers can spend… 特にエンタープライズでは小川充(HTML5Experts.jp コントリビュータ)氏や酒巻瑞穂(HTML5Experts.jp コントリビュータ)氏が考えている通り、各モジュールをどのように構造化し開発ライフサイクルを運用するかが必要となります。こうした意味合いにおいて「Flux」という考え方が参考になるのではと思い資