(Babel 5における)ES6のモジュールを解説してみた - uehaj's blog
警告 以下でのモジュールの説明はトランスパイラであるBabel 5,6で動作を確認した振舞いについての記述です。2015年11月現時点で、ECMAScriptのモジュール仕様策定範囲は、本来の全体範囲のまだ一部であるとのことです。その状況でのBabelの実装は、良く言えば先行的、悪く言えば将来そのままである保証はなく、現時点でも他のES2015をサポートする処理系との間での相互運用の保証はありません。また、現時点でBabelのモジュール機能を使うこと自体にリスクがあるという意見もあります。CommonJS側からBabelが生成したモジュールをCommon JSモジュールとして読み込もうとしたときの互換の問題として、Babel5で可能だったことがBabel6では利用不可になる、といったことも起きているようです。 そこらへんを含めて解説されているこちらの資料が参考になります。 (2015/11
elmでやってみるシリーズ7: elm-htmlでTwitter Bootstrapを適用 - uehaj's blog
Elmでやってみるシリーズ7: elm-htmlでTwitter Bootstrapを適用。 つい先日、「Blazing Fast HTML」と銘打って、elm-htmlライブラリが公開されました。これはElmでDOMツリーを構築・更新するための低レベルライブラリであり、Virtual DOMという技術を使っているので非常に画面更新速度が速いそうです。SPA(Single Page Application)ではDOMの更新速度が重要になりますが、Elmは純粋関数型・イミュータブルデータなのでそのことを利用してさらに効率良く実装できるそうな。 従来、ElmはCSSとの連携はあまり重視されておらず、「ElmはCanvasを使ったアニメーションが得意」とされてきましたが、現代的な見た目のHTMLベースのアプリも自在に開発できるようになる、という道筋の第一歩なわけです。まだ未成熟ですがね。 個人的
HATEOASって何だ? - uehaj's blog
Grails 2.3のRest機能のドキュメントを読んでいたら、拡張の一つとして「8.1.7 Hypermedia as the Engine of Application State」というのが書いてあって、調べると面白かったので、この資料(REST: From GET to HATEOAS)を読んだだけでの、私の理解する限りのメモを記しておきます。 一言でいうと、HATEOASとは、Restfulパターンを拡張するアーキテクチャパターンで、Restful原則に対する追加的な制約。どういうものかというと、HTMLアプリの画面遷移を抽象化した、状態遷移を表現するRestful API(=Restful WebアプリのWebインターフェース)を設計するための具体的な方法論になってる。 もちろんGrailsに特化したものではなく、Restと同じレベルのWebアプリケーション一般概念でありRes
HaskellにおけるIOモナドとSTモナドの関係 - uehaj's blog
HaskellにおけるIOモナド(IO a型)とSTモナド(ST s a型)について整理してみました。 IOの定義から知るST IOモナドの考え方についての原論文に相当する「Lazy Functional State Threads」においては、IOの定義は newtype IO a = ST RealWorld aのようにST型を直接使用して定義されるものとして説明されています。ただ、「IO inside」によれば、GHCのライブラリ実装においてIO aの定義は newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))だそうで直接STを使ってはいません。後者のは正格タプル非ボックス化タプルを使ってます(知らん!)。 まあ、Haskell仕様ではIO aと関数仕様が定義されているだけで=の右側は実装依存というわけなの
モナドはなぜHaskellでしか積極的に使われていないのか? - uehaj's blog
(Haskellな日々になってるな…。) モナドというものがあり、Haskellで有名ですが、実際には、Java8のOptional、ScalaのOptionやfor内包表記などでは使用されています。ScalazというScalaのライブラリや、monadlogieというGroovyのライブラリでも使われています。 とはいえ、一般に、Haskellでのように積極的には使われていないというのが公平な見かたでしょう*1。Haskellでは本当にいろんなものがモナド化されています。入出力(IO)、状態、失敗するかもしれない計算(Maybe、Either)、非決定計算、継続、パーサ(モナディックパーサ)、リーダ、ライタ、etc.etc……。 なぜこのような差が生じるのでしょうか? その前に、まず押さえておくべきことは、モナドは非常に汎用的な機能だということです。数学的定義はともかく、機能的に言うと、
IOはいかにして命令書(アクション)であるのか：(たぶん)解決編 - uehaj's blog
えー、先日「IOはいかにして命令書(アクション)であるのか」という記事を書きましたが、その疑問は「IO inside」を読んだところすべて氷解したのでご報告します*1。 要するに、 type IO a = RealWorld -> (a, RealWorld)です。おしまい*2。 id:nobsunさんやid:kazu-yamamotoさんが指摘していてくれたことは今おそえばおそらくこれでした。IO aは値ではなく関数なわけです。代数型データ構造(Hoge Int)みたいな表記に惑わされてコンテナだと見誤ったのが、誤解の元。 関数型がファーストクラスな言語では任意の計算が任意に遅延評価できるのだから「遅延評価仮説」は成り立たないし、この意味での副作用の除去*3の理由として持ち出す必要はありません。すみません。 純粋だから何なのさ！ ではいかなる意味で、副作用除去（というより無いと言い張るた
内部から見たVert.xとNode.jsとの比較 - uehaj's blog
socket.ioがJavaやGrailsから扱えるかを調べている関係でvert.xを調べていて興味深かったので、こちらにあるVert.xの記事を翻訳してみました。JGGUG G*Workshopにおける杉浦さんのVert.x資料もお奨めです。 Vert.xは急速に発達つつあるサーバ・フレームワークです。 世にあまたあるサーバ・フレームワークのいずれもが、多様なプロトコルをサポートし、高速であることが特長であると主張していますが、Vert.xはそれらよりも一歩抜きん出ています。例えば、Vert.xは、サーバサイドのネットワーク環境の確立と操作も対象としています。言いかえれば、Vert.xは、単一サーバ上のデーモン実行だけでなく、クラスタリング環境での複数サーバデーモンの実行を考慮しているのです。 したがって、Vert.xを調査するにあたっては、どのように高性能を実現しているかだけではなく、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
