JavaScript で クラスベースの設計より関数指向の実装を薦める理由 + GraphQL について
最初に: 「Functional Programming 最高!」という話ではないです
JSは通信やストレージに保存するデータの扱いの関係で、JSONにシリアライズできることが至上命題になるケースが多いので、クラスベースの設計で自身に副作用を起こすメソッドより、イミュータブルな T => T なstatic methodとして切り離しておくと扱いやすいケースが多い
— 現場の声 (@mizchi) 2016年9月6日
複雑なオブジェクトのシリアライズは簡単だけど、逆にシリアライズされたオブジェクトからビルダを構築するのが難しいので、JSONの構造体自身とは別に独立して独立したメソッドとしてビルダが切り離されている方が扱いやすい
— 現場の声 (@mizchi) 2016年9月6日
一応コンストラクタ名を保存してシリアライズ/復元する方法はあって、RPGツクールMVのコードを読むとそういう感じになっていた。
— 現場の声 (@mizchi) 2016年9月6日
HTTPやWebSocketでJSONを構造体を投げ合う / サーバーサイドでMongo環境である / クライアントサイドでIndexedDbで保存する / 出力形式としてJSON フォーマットを持っている、などがJSONシリアライズを強く意識する環境で、とくに通信
— 現場の声 (@mizchi) 2016年9月6日
そういうドメイン的な都合とは別に、イミュータブルな構造体の変換(T -> T)の関数をインスタンスの実装から分離するといいよね、というのはモダンな言語でも流行りのアプローチなので、実際にはthisが第一引数へ、副作用の代わりに同じ型のインスタンス返す、というそれだけの話
— 現場の声 (@mizchi) 2016年9月6日
JSで immutable-js 使わなくても、強い心で副作用を起こさない、というアプローチを取ることは可能です。今なら object literal shorthand があるので const next = {…prev, foo: 1} と書けて記法的にもそこまで辛くはない
— 現場の声 (@mizchi) 2016年9月6日
こういうのもある https://t.co/MReB2a2NLf
— 現場の声 (@mizchi) 2016年9月6日
GraphQL について
mizchi さんに GraphQL(実装ではなく、仕様とコンセプト)について評してほしいの気持ち
— 21話 (@KOBA789) 2016年9月6日
GraphQL ちゃんと掘ってないけどクエリがだいたいJSONなんだからJSONでよかったやろと思っちゃいる。アレのせいでクラサバにパーサが必要になってだるい。サーバーはいいけどサイズ絞りたいクライアントはなーという。たぶんbabelみたいなプリプロで変換できるけど。
— 現場の声 (@mizchi) 2016年9月6日
GraphQL、コンセプト的にREST APIと対立するというかREST APIの否定感が強くて、クライアント本位なら別にいいけどREST倒すほどのものかというと厳しいのではという感じがある
— 現場の声 (@mizchi) 2016年9月6日
@Quramy なんとなくやってそうな気がしましたが、やっぱやってるんすねー
— 現場の声 (@mizchi) 2016年9月6日
JSONでクエリ書けばいいやん!ってのはやっぱ思っててコード中インラインでクエリ書くのは静的解析辛いだろうしシンタックスハイライトとかエディタ側でし辛い(できないとは言わないがだるい)
— 現場の声 (@mizchi) 2016年9月6日
Mongoのクエリは書きやすかったという話です(Mongoがよかったという話ではない)
— 現場の声 (@mizchi) 2016年9月6日
要約するとGraphQLは目的に対して独自構文まで持ちだしたのはやり過ぎなのとREST倒すだけのメリットを提示できてない、という感じですあとグラフデータベース的な側面はFacebookみたいなソーシャルグラフを扱ってないとあんまり生きないのでは、という気持ちもある
— 現場の声 (@mizchi) 2016年9月6日
OLE開発記(2)
Tree of Savior のオープンβで進捗に悪影響がありましたが、最初の熱が醒めたので、どうにかなります。なると思う、たぶん…
何もしてないわけではなく、色々作ってはいた。
OLEという名前について
OutLineEditorの略のつもりだったが、Windowsにそういう仕様があって、というツッコミが多かった。全く知らなかった。
OLEとは|Object Linking and Embedding - 意味/定義/解説/説明 : IT用語辞典
元々ole(仮)なので、名前を変えることには抵抗はないけど、まだ名前が思い浮かばないので、とりあえずこのままで。。
Markdownコンパイラの実装
色々と文法を拡張したり出力をコントロールするのに、自前のコンパイラを持っておくと便利と思って、remark をベースに実装した。
数式プレビューしたり、キャレット位置でコンパイル先とスクロール位置を同期する仕組みを作ったりしている。textlint の組み込みもできる。
スクロールの最適化
フォーカスが当たった瞬間にwysiwygのエディタを有効化した場合、下押しっぱなしで高速に移動したい場合に突っかかりまくって邪魔だったので、編集に入るまでは雑に pre につっこむ感じにしてみた。
正直やや違和感ある。特定の分量を超えたら、でコントロールしてもいいかもしれない。
タイトル
元々シート(編集単位)は記事名の情報を持っていたが、中身と独立してシート名が存在するのが実体と乖離して嫌な気がしたので、inline-yaml記法(独自記法ではなくgithub flavored markdownの仕様の一部)でtitleプロパティを埋め込んだらそれを表示するようにした。タイトルを持たない場合は、文頭をtruncateして表示する。
編集に入ったときに titel: < ここ
の部分にcaret移動したい。他のメタ情報もここに書けるようにする。
タイトル名の同期
このためにファイルツリーの部分更新の仕組みを入れた。 編集する度にタイトルが編集されてないか監視してるが、入力の度に監視しているので、コスト的にあまりおいしくない気がしている。あとで入力まとめて最終入力から 1s ぐらいにイベントを束ねる。
シート結合/並び替え
同階層で複数選択してcmd+shift+j でシートを結合できるようにした。 cmd+shift+↑↓で並びを変更できるようにした。
複数階層にまたがった記事の結合パターン、なにが正しいのな何もわからない(ヒューリスティックも思いつかない)ので、とりあえず禁止しておくことにする。
次やること
- グループに出力に含むかの設定を持たせる
- グループに出力時の階層設定を持たせる(headingの数をずらす)
- 出力(仮)
- シート検索
- グループごとの階層コントロール
- リビジョン機能を作るか検討
リビジョン機能
シート単位で特定の状態のスナップショット作って、あとで現在の状態と比較できるようにしておきたい、と思いついてはいるが、ぶっちゃけ他にやることも多いので後回し。
リリース目標
出力機能の仕様がまだ決まってないので、DBスキーマを変更する可能性が高く、まだまだβテストやるのは厳しい。出力機能の仕様が固まったら安定しそう。まず機能面を固めて、スキーマが決まったらデザインのブラッシュアップする、予定。
とりあえずDBのdump機能とマイグレーションがあればどうにかなるっちゃなるんだけどなー。
同調圧力、その再生産
皆が面白いと思うものを面白いと思えないから、面白くない、と言うと「水を差すつまらないやつ」とか「斜に構えて気取ってる」みたいな扱いされるんだけど、こっちは本当に面白く無いと思っているわけで、その可能性を検討できない人は、同質的なコミュニティだけで生きてきた幸せなやつなんだな、と思う。
「嫌なら見るな」という言葉も嫌いで、まあ僕は見ないんだけど、結果としてそういうものに囲まれて生きることになるので、「政治的なアクション」として、否定的な見解を発していくのは必要なことだとも思っている。たとえそれが自分に通じる範囲にしか響かなくても、僕が快適にしたい領域はそこなので。
たとえばシンゴジラは僕も見てよかったと思ってるけど、国威発揚的な演出はクッセーと思ってて、嫌いな人いるだろうなって思うし、絶賛以外許さんという連中はまさに多数派の同調圧力の発露なので、個人的な嫌悪の対象にある。
僕が18まで無理矢理通わされた「教会」は、一般的な価値観を否定することによって同調圧力を強固にする仕組みになってて、あれに18年も拘束されたのは人生における一番の無駄だったし、結果として「同調圧力を生産する仕組み」に対する憎悪に囚われてしまった。
そういう諸々から、LGBTの生きづらさの感覚は多少共感するものはある。生理的には、受け付けないけど。
ダイエット三ヶ月目 72.6kg => 69.0kg (三ヶ月で-10kg)
進捗
- 1ヶ月目: -4.2kg
- 2ヶ月目: -2.2kg
- 3ヶ月目: -3.6kg
身長169cm/69kg, BMI24.16, 25を切ったので「肥満」域を脱した。
ダイエット進捗 69kg です pic.twitter.com/eEeIsradHH
— 現場の声 (@mizchi) September 1, 2016
エロゲの主人公みたいな髪型になってる
— 現場の声 (@mizchi) September 1, 2016
だいぶ昔に「このエロゲをやれ!エロゲの最高傑作で、人生変わるから!」と近所の熱心なお兄さんにKanonとAir勧められてプレーしたんだけど、面白かったけどこれが最高傑作なら他はやんなくていいやとなって、エロゲの道には進まなかった
— 現場の声 (@mizchi) September 1, 2016
今思えば、Kanon/Airよりも、近所のエロゲの布教に熱心なお兄さん、という存在のほうがエモいな
— 現場の声 (@mizchi) September 1, 2016
脱線した。まあ今更顔出し気にしてもしょうがないんですが。(なおこの発言をするとアレをエロゲ扱いするなおじさんが湧いてくるところまでは把握済みです)
振り返って
毎年ではあるんだけど、夏場で体調崩していて、特に低気圧が近寄ったり離れたりで、頭が破壊されていて、ジムに行くチャンスがほとんどなかった。週3.5のペースで行ってたのが週1.5回になってるので、来月は頻度を戻したい。体重とは別に代謝も上げないとリバウンドする。
とはいえ、体重は1ヶ月目に相当するぐらい落ちていて、原因は2ヶ月目は推測したとおりホメオスタシスが発動していたのと、3ヶ月目の途中から主食をザバスのプロテインダイエットに切り替えた結果だと思う。豆乳で割って飲むと結構おいしいのと、そこそこ腹持ちするので、食欲が収まり、精神的に良い。
(アフィ貼ろうと思ったが、今までの記事がアフィ記事だと思われたくないので貼らないことにする)
プロテインを豆乳に溶かしてシェイクするだけというお手軽満腹リソースなので、これはダイエットやめても続けていきたい。あと、うまい(大事)
結果
会う人会う人に痩せたねーと言われる。
腹の肉が目に見えてつまみやすくなった。むしろ下腹部がなんかずっとスースーする感じがある。 腹の肉はいいとして、皮が若干余ってる気がする。80kgのとき三段腹になってた部分が、まだ三段になるんだけど、押し出されてるのが皮だけって感じ。
「100kgの巨漢が-40kgダイエット!」みたいな衝撃的な写真で見たほどではないが、まあ3ヶ月で痩せたら皮は余るか。まだ大丈夫だけどあと5kgぐらい減らすと顕著になりそう。
痩せて体調が良くなったとかそういうのはない。上述したとおり8月はだいたい体調崩してたので…。ただ、肩こりが多少低減されてきた気がする。
今後
今度またインタビュー記事でるんですが、あれは72kgのときにとったやつなんで、察してください。
169cm/69kg という状態、まだまだ平均を上回っていて、痩せられる余地があり、精神的にも余裕があるので、あと2ヶ月ぐらい続けたい。
とはいえ社長(yaotti)にとあるお詫びに中華をおごる約束してしまってるので、一回の中華でどんだけ太るか測れそう。腹一杯に楊の汁なし担々麺くいてえな。
OLE開発記(1)
昨日のブログでそれなりに注目が集まったので、開発メモ的なことを書いていくことにする。 OLE = OutLine Editor です。たぶんこのまま開発コードになる。リリース時にオシャレネームつける可能性はある。
昨日やったこと
- ゴミ箱に全部削除ボタンを実装
- D&Dでアイテムとアイテムの隙間にドロップして挿入したいよね〜という内なる声に従って D&D 改良中。これ単純に難しい。実装できるか不明で後回しのがいいかも。
- ブログ書いてベータテスター集めた。
ベータテスト開始の目標は10月頭としたい。
最悪DBスキーマさえ決まれば、ベータテストはできる。データワイプやらずに済むよう、スキーマとマイグレーションの仕組みをきっちり決めたい。
ベータテスター集まった
10人集まった。ありがとうございます。 ベータテストにあの結城浩先生が参加してくださるということで、プレッシャーがヤバイ。
要望
- textlintの組み込み
- 一行当たりの最大文字数とかこれでいけそう
- ワードカウント
- 行数表示
- Scrivener のコルクボード表示
- 数式/図
- mdbook
- markdown以外の構文対応(Re:Viewとか?)
- 扱いやすい中間状態の出力(とはなんだろうな)
- 縦書き出力
予想以上にScrivenerのコルクボード表示の需要が高い。 全部やるとは限らないが、やりやすいのから検討していく。textlint は最初からやるつもりだった。
縦書きの組版は地獄なので、雑にやれるところまでやって、深入りしない方向で。
競合調査
- Scrivener
- Ulysses
- Quiver
- Atom
- Tree2
- OmniOutliner
この辺を研究しろとのこと
今後
今日OBT開始の Tree of Savior に進捗吸われないように気をつける
本を書くためのアウトラインエディタを作ってる
少し前からアウトラインエディタを作ってる。
こんなの
(画面は開発中のものです)
ファイルツリー
複数シート同時編集
ファイルツリーUIというのをスクラッチで初めて作ってみたんだけど、「当然こう動いて欲しいよな」というヒューリスティックな挙動をたくさん作るハメになってて学びがある。
なぜ作ったか
技術書を書いて Kindle Direct Publishing で販売しようと思って、Macで売れてるアウトラインエディタを一通り試したんだけど、惜しい物が多くて、個人的にしっくり馴染むものがなかった。なので、技術書を書く前に、自分が本を書くために必要なツールを作るところから始めることにした。
作家・藤井太洋に聞く 「小説を書くためのツール、Scrivener」 - DOTPLACE を読んで、その辺のアプリに対する感覚を自分でも意識して作ってる。Scrivener は wysysig なんで自分にとって論外。
エンジニアとして5年経って、個人でアプリを最初から最後まで作って販売した経験がないので、将来の選択肢を考えるのに経験を積んでおきたいというのがあった。あと仕事でElectronアプリ作って経験値溜まってるので、ホットなうちにその経験値を金に変換しておきたい。
Electronアプリを Windows に出す場合、どこに出せばいいんだろうか。
どういう機能を持ってるか
進捗
Done
- プロジェクト管理
- ファイルツリー
- 右クリックで操作
- キーバインド
- ゴミ箱
これから
- デザイン面のブラッシュアップ
- 出力/プレビューのブラッシュアップ
- 画像管理/埋め込み
配布形態
有料アプリ。どういう配布形態にするか決めてないけど、とりあえず最初はApp Storeで販売するのを目標にする。価格は1800円ぐらいの予定。たぶん変わる。
品質面で売り物にならないと判断したら、OSSにする。
どういうターゲットを想定しているか
- 長いドキュメントを書く人全般
- 技術書を書く人
- 小説を書く人
- ブロガーみたいな細かいドキュメントをたくさん書く人
リリーススケジュール
- 基礎機能の実装(もうちょいで終わり)
- 設計の見直し: 長期的にメンテできる構成か
- デザイン面のブラッシュアップ
- このアプリで本を一冊書く
- 修正
- βテスト
- フィードバック反映
今年中に出せたらいいなぁ。 βテスター募集してるので、興味ある人は Twitter @mizchi まで。
追記
ベータテスター10人集まったので募集締めきりました。引き返せなくなったぞ!
JavaScript の難しさとは何か
JSの学習コスト高いかという問題、言語のコア自体はシンプルだが細かい == とかのハマりどころが多いのと、言語機能自体がシンプルすぎてエコシステムを理解してモジュールを扱うところに辿り着くのが大変、という問題に分類できる
— 現場の声 (@mizchi) 2016年8月15日
jQueryの学習コストは、DOMはツリーなんだよという概念の獲得と DOM API の抽象サブセットを覚えるというだけで、2016年現在は jQueryによるUI設計論(ここが高まるとBackboneとかその辺)みたいなものに手を出す必要がないなら、そんなでもないんだろうな
— 現場の声 (@mizchi) 2016年8月15日
Reactが難しいと言われる場合、仮想DOMという概念がやや難しい、というか非常にCS的なアルゴリズムとデータ構造が背景にあって、その上で単純なトップレベルAPIとアルゴリズムを理解してないと扱いづらいライフサイクルイベント、という感じだから、アルゴリズムを知らずに使うのは厳しい
— 現場の声 (@mizchi) 2016年8月15日
Reactが難しい、がFluxを指してる場合、それはGUI設計の難しさを指してることが多いので、単純に プリミティブなDOM/jQuery とパラダイムが違いすぎる問題であって、ここは逆にAndroid/iOS出身の人のほうがすんなり馴染むっぽいのを結構見た
— 現場の声 (@mizchi) 2016年8月15日
document.innerHTML を毎フレーム書き換えてハンドラを再定義すれば、それは Flux とやってることは一緒なんだよな。さすがに厳しいけど。
— 現場の声 (@mizchi) 2016年8月15日
あとは、JSメインって人は少なくて、いろんな言語を背景に持った人がごった煮でコミュニティとして統一感がない問題とか、ユーザー層が広いせいで習熟度が低いサンプルコードにぶち当たってしまう確率が高い問題とか(Java/PHPも同じ)、エコシステムの代謝が早すぎてすぐコード腐るとか
— 現場の声 (@mizchi) 2016年8月15日
言語としては難しい概念を持ってないし、難しさの本質がブラウザ特有ではないGUI設計そのものと結びついて、将来的に腐る知識が減ったのは喜ばしいことだが、ブラウザの事情とか、エコシステムの些事に振り回されるのが本質的じゃないよね、という辛さ、わかる
— 現場の声 (@mizchi) 2016年8月15日