ポエムです。 自分の今の立場としては「Elm の人」ということになってるんだけど、どういう変遷でここまできて今どういうスタンスなのかっていうのはあんまり話す機会がない。だから整理のために考えてることを書いていくよ、というのがこの記事の趣旨。 非 Web の立場から そもそも自分は「Web 系」の出身ではない。新卒入社したワークスでは ERP パッケージを提供するのに画面を Web 技術で作ってるというだけで、別に SEO の順位を競ったり広告をどうという話ではないし、瞬時に画面が表示されないと離脱率が〜という話でもない。ただ、画面はとにかく複雑で設定項目とががうじゃうじゃある。 あと、学生時代に PC に触れたのが Windows で「黒画面なにそれ美味しいの？」くらいに GUI に染まりきってたというのがある。工学系の研究を効率化するために C# で GUI を作ってたら、なんかソフトウ

この記事はElm Advent Calendar 2016 の4日目です。 会社で書かせてもらってるElm製アプリが10000行を超えたので、現時点で個人的にこれはと思うベストプラクティスを実際のソース付きで書いてみる。 github.com （アプリについての情報は機会があれば） 1.必ずスタイルガイドに従う 行数が増える傾向にあるが、かなり読みやすくなるので絶対に従った方が良い。 Style Guide 関連コミット （let...in中に空行を挿入している） 2.データ構造にタプルを使わない 例えばマウスの位置などをタプルで(Int, Int)のように書きたくなる。しかし後悔するのでやめた方が良い。 -- 微妙 calculateX : Model -> Int calculateX model = let (x, y) = model.position in max 0 x --

ブラウザ上に Context Menu を実装するときに何を参考にすればいいのかわからなかったので、自分用にメモ。 見た目 Win10 - Chrome Win10 - Firefox Win10 - Edge Win10 - Desktop Mac - Browsers/Desktop Google Spreadsheet 位置 クリックした位置からメニューが出る方向と、はみ出したときに画面内に収める方法。 環境 デフォルト方向 左右はみ出し 上下はみ出し Win10 Desktop 左下 シフト 反転 Win10 Chrome 右下 シフト 反転 Win10 Firefox 右下 シフト 反転 Win10 Edge 右下 反転 反転 Mac Desktop/Browsers 右下 反転 シフト Google Spreadsheet 右下 反転 反転

elm-conf 2016 アメリカ、セントルイスにて。 以下、終わった後に記憶を頼りに書き起こした雑極まりないメモ。 雰囲気 写真は休憩中だから人少ないけど。 トーク Keynote: Code is the easy part (by Evan Czaplicki) コードを書くのは一番簡単な部分。言語設計として何を書くかが問題。 Pythonは最初の５年ほぼプライベートで、ドキュメントが整うのには１０年かかった。Elmはまだ４年。 要求を一つずつコードで実装して解決することはしない。数ある要求を集めてパターンを見つける。そのためにたくさんのフィードバックが欲しい。 0.18に向けて今取り組んでるのがデバッガー。モデルの状態を全部記憶できるし、状態を保存してリロードできたりする。あとサーバーサイドレンダリングとか。細々したタスクは今はあえて無視してる。 Beyond Hello Wor

ElmでHTMLパーサを作った。 github.com せっかくなので、ライブラリ制作に着手してから公開するまでのプロセスを書いてみる。Elm 開発の雰囲気を伝えるのが目的なので、特定のトピックが知りたい方はQiitaへどうぞ。（コードが沢山あるけど試してないので動かないかも。あと、途中でテストライブラリをアップデートしたりして実際に踏んだプロセスと違うし、コードも所々違うんだけど、それは無視して最短・最適のパスを踏んだことにする。） 経緯 Excel（とか他の表計算ソフト）からクリップボードにコピーしてWebアプリに貼り付けようとしたところ、フォーマットがHTMLだったのでパースしてデータを取り出したかった。ここで問題発生。 ElmにHTMLパーサが無いだと。。— Yosuke Torii / ジンジャー (@jinjor) August 30, 2016 別にJSでパースしてElm側に

言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。

CSS in JS(Elm)方式で、:hoverが出来ない問題を解決した。 github.com ElmだけどJavaScriptでもたぶん出来る。 使い方 通常、次のように書いている部分を li [] [ text "Hello" ] 次のように書く。 hover [("background", "#456")] li [] [ text "Hello" ] すると、ホバー時のみ追加のスタイルが適用される。 仕組み onmouseenterとonmouseleaveの２属性にスクリプトを自動的に突っ込む。 onmouseenter時に、元々DOMに付与されていたスタイルをdata-hover-style-nameに退避して、ホバー時のスタイルを適用する（キーはキャメルケースに変換する）。onmouseleave時に退避していたスタイルを元に戻す。自分の要素しかいじっていないので、Virt

プログラミングに関する格言みたいなのは昔から結構あって、例えばYAGNIみたいに日本でも十分浸透してるのは多いんだけど、やっぱり新しい概念はどんどん生まれていくので追いかけていると面白い。 というわけで、最近知った中でもっと日本でも言及されても良いと思ったやつを３つ紹介。 Simple Made Easy Rich Hickey（Clojure言語の作者）による講演(2011年)のタイトル。全文はここで読める。英語しんどくてPOSTDに投げたんだけど音沙汰がない。まだ全部見てないから和訳欲しい。 内容としては、みんな安易に「簡単」なものを選びがちだけど「シンプル」なものの方が価値あるぜ、というもの。曰く、「シンプル」は絶対的・客観的な指標だけど「簡単」は相対的・主観的なもの。例えば英語の話者にとってドイツ語は難しいが、それは自分にとって「遠い」存在であるだけで悪いものじゃない。 「慣れてい

最近Webフレームワーク周りで無駄に摩擦が生まれてるなー、と思うことを詩的に書いてみる。 そもそも何が作りたいのか 古くはjQueryから始まって、最近だとReact(+Redux)とかAngular2とか色々あるわけだけれども、そもそもそれらを使って作ろうとしてるものはみんな一緒なの？っていうのがあって、色んな話を聞いているとかみ合ってない感がすごい。以下の分類は別に細かくちゃんと定義しましょうとか言っているわけではなくて、「例えばこういうのがあるんじゃないの？」という一例。いま自分が関わっているのは主に３と４なので、その他で間違ってたら指摘して欲しいんだけど、この前提を共有していないために「複雑すぎる」とか言ってるんじゃないかという仮説がある。 1.Webサイト 基本的に静的なWebサイトで画面遷移するんだけど、ところどころ動きがあったりするのでフレームワークが必要。SEOが重要なので

追記 最新の感想も合わせてご覧ください。 jinjor-labo.hatenablog.com React界隈では結構前から「CSS in JS」と言って、雑に言うと「CSSはイケてないからJSでインラインスタイルを書いてしまえ」という話がある。（ちゃんと知りたい人はこちら） 自分も前々からCSSは変数が使えないとか名前が被るとか諸々イケてないのは同意してたんだけど、じゃあJSで書くのが良いかと言われたら「いや流石にロジック汚れるんじゃね？」とか「CSSの便利機能を捨てて平気なの？」とか色々と懐疑的だったんだけど、１～２か月書いてみたら想像以上に良かったので感想を書くことにした。 まず一番に主張したい部分を先に言うと、こう。 （誤解）JSのコードがスタイル記述で汚れる （正解）JSのコードがスタイル記述から解放される 前提 実際に書いたのはJavaScriptではなくElmなので以下は全て

（4/23 追記：はてブのコメントで指摘をいただいた箇所を直しました。ありがとうございます！） 最近またElmを触り始めているので小ネタを書きます。 このエントリで主張したいこと。 関数型言語でもオブジェクト指向の考え方は使える オブジェクト指向とは？ オブジェクト指向と言うと色んな意味を含んでいて、解釈の違いで論争になるのでまずは整理します。だいたい特徴として挙げられるのは以下でしょう。 カプセル化 継承 メッセージング どのオブジェクト指向に馴染んでいるかは開発者のバックグラウンドによって異なると思いますが、私はオブジェクト指向と言ったら圧倒的に「カプセル化」であって「役割分担」です。というわけで、以降はカプセル化の話です。 関数型言語とオブジェクト指向の代表としては、ElmとJavaScriptを例として取り上げます。Elmに馴染みのない方でも雰囲気は掴めると思います。 関数型言語は

TOEICのリスニング問題集をやっていて「ムキーッ！」となることありませんか？ 私は２つほどあります。１つは「ひとつの問題を繰り返して聞きたいのにファイルが分かれていない」こと、もう１つは「何を言ってるのかさっぱり分からない」ことです。そこで今回、１つめの問題を解決すべく、CD音源を複数の問題別に分割するWebアプリを作りました。 Wave Cutter for TOEIC®（Source） Chrome、Firefox、Edgeで動作確認済みですので、ぜひ遊んでみてください。 使い方 MP3ファイルを読ませると自動的に空白を判断して分割します 自動分割で上手くいかなかったところを手動で調整します 完了ボタンを押すとZIPファイルが手に入ります 2に関しては、出力予定のファイル名（左側）と波形データの内容（右側）を一致させるゲームだと思うと手っ取り早いです。 主な機能 波形の削除、分割、結

最近、OSS関係でGitHubとかMLとかに顔を出していて、当然ながら会話は全部英語。 というわけで、英語を書くときに心がけていることを簡単に書く。 「英語が下手ですいません」とか前置きしない 読めば下手だって分かるから、わざわざ言う必要ない。これ言ってる人を見かけるとほぼ確実に日本人なんだけど、必要以上に卑屈なオーラを感じるので良くないと思っている。いくら日本人が英語苦手とは言え、英語圏の人は糞な英語に慣れてるから大体分かってくれるし、分からない場合はこういう意味かとレスが来るから、その都度説明すればいい。ただし後にも書くように礼儀は必要なので、甘え切って雑になるのはよろしくない。逆に丁寧に書けば懸命さが伝わり好印象。 あと、日本人以外にも非ネイティブは沢山居ると思うと結構気が楽。自分の感覚としては非ネイティブの書く英語ほど分かりやすい気がしていて、ネイティブの方が表現が小洒落てて時とし

やりたいこと いまいち上手く日本語に出来なかったので図解する。 コマンドラインツール等で、実行時に手元のファイルをテンプレートとして利用したり、静的ファイルをディレクトリごとコピったりしたいことが良くある。でもそのままExecutableにするとファイルが付いてこなくてどうしよう、と言う話。上の図で言うと、赤い矢印で示したファイル参照を実現したい。 .cabalファイルの記述 実行時に必要なファイルを.cabalファイルに記述する。Data-dir:に必要なディレクトリ、Data-files:にそのディレクトリ下のファイルを羅列する。この指定が曲者で拡張子がワイルドカードに出来ない。なので、/**/*とかにしたいのを我慢しつつ、拡張子をひとつずつ記述する。 foobar.cabal Data-dir: data Data-files: templates/*.html.tmpl templ

Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した

皆さん、そろそろElmやりましょう。 Elmって何なの？ Webブラウザで動くFRP(Functional Reactive Programming)言語です。 コンパイルするとHTMLやJavaScriptを吐き出します。 Elm 公式サイトに動くサンプルが大量にあるので見てみると面白いです。 どうして今やるの？ これまでElmと言えば、良くも悪くも理想を追求した言語で、一般的なWebの部品(HTML/CSS/JavaScript)と相性が悪く、「まぁちょっとCanvas使っておもちゃアプリでも作るかー」くらいが関の山だったのですが、最近になってその状況は一変しました。 HTMLライブラリのサポート Ajaxなど非同期タスクのサポート JavaScriptとAPIを通じて相互接続可能 エコシステムの登場 順序はちょっと忘れましたが、0.14とか0.15で色々出来るようになりました。 im

話の発端 サーバプッシュするリソースの関連付けを全部手動で書くのが面倒だから、動的に中身を読んで解決したい。 その時に、依存の深いところにあるものでも、リクエストのストリームを閉じずに待たないといけないという制約があった。 jinjor-labo.hatenablog.com というわけで、依存が深くてもなるべく早くコンテンツを返すためのアルゴリズムを考えた。形式的な説明が思いつかないので具体例を挙げる。 例１ index.htmlがstyle.cssを必要とし、style.cssがback.pngを必要としている。（階層の深さ:2） index.html <link rel="stylesheet" href="style.css"></link> style.css body { background: url("back.png"); } 最適なレスポンス順序 index.htmlに

タイトルの通りで、今ぶち当たっている問題を共有するのが目的。 図のように、あるHTMLを起点にして依存しているすべてのリソースに対して、再帰的にPUSH_PROMISEしたい。 PUSH_PROMISEはPROMISEであるため、サブリソース本体が起点となるリソースよりも早く返却される必要はない。つまり、ブラウザはサブリソースの返却にブロックされずに、先に目的のリソースの評価を開始できるというメリットがある。 再帰的なPUSH_PROMISEとは ただし、これを再帰的にやろうとした場合に問題が生じる。 実は、PUSH_PROMISEはクライアントからのリクエストにあたるストリームからしか発行できない。 だから、Stream 2からStream 4を生み出すのは無理。 そうすると、Stream 1からPUSH_PROMISEを発行しなければならないのだが、この時にStream 1が既に閉じら

そろそろRFCとして公表されるHTTP/2ですが、GoogleがHTTP/2を使ったRPCフレームワークを出してみたりとか、その界隈は大盛り上がりですね！ HTTP/2の目玉機能と言ったら、やっぱりPUSH_PROMISE！ PUSH_PROMISEと言えば、「index.htmlが必要だったらapp.jsとかstyle.cssも要るよね！」とサーバ側で勝手に判断して送りつける、というのが良くある説明なのだが、それを自動でやってくれるわけではないので、Node.jsサーバ用にライブラリを作ってみた。 jinjor/auto-push · GitHub npmにもpublishしたので、npm install auto-push可能。 やっていることは、レスポンスの直前にHTMLをパースして、必要そうなJavaScriptなりCSSなり画像なりをプッシュする。それだけ。 HTML Impor