トップ 最新 追記

2019-05-01 [長年日記]

_ なんかいろいろうまくいかなかった

terser 3.16.0問題でbuildコケてた

しばらく前に環境作って production build はせずに development mode でだけ使ってた手元のプロジェクトで build したら見事に動かなくてハマった。

terser/CHANGELOG.md at master · terser-js/terser

関係するライブラリをバンバン upgrade したらなんとかなった。

import と ESModule でトラブルの、まだ当分続きそうな気がするなぁ。

webpackに詳しくならずに開発中のコードをWireless Isolation環境 + 実機で確認する

  • production buildでHTMLまで吐き出す
  • serveでhttp serveする ( http-server でもよい )
  • localhostへtunnelする
参考

iOS 12.2でFullscreen API対応はpartialだった

試してみようと思ったのはコレだったんだけど、何もうまくいきませんでした。

Tags: JavaScript

2019-05-02 [長年日記]

_ tunnel serviceちょっと調べてみた

基本的には localhost を internet に公開するのに ngrok を使ってるんだけど、ふと気になって他のものも調べてみた。

独自の ngrok コマンドで tunnel を作る。random な URI が自動で振られるが、課金すると domain を固定できる。

もうずいぶん長いことサービスしてる。以前は存在しなかった Inspector をブラウザで開くと request / response の状態を確認できる。

ssh の remote forward サーバ。ssh が分かってないと使えない。

localhost 以外にも tunnel できるのは分かるけど、sign up なしで使えるし鍵を使うと custom domain も使える。なんだこれ。

OpenVPN を使った tunnel を作ってくれるサービス。OpenVPN が分かってないと使えない。

Chrome 拡張から tunnel を作れる。コマンドラインが苦手な人にはよいかも。free plan はないみたい。

Webhook に絞るとこんなのもある。個人的には汎用の tunnel でよさそうではあるけど、Webhook 開発に都合のよいものがいろいろあるのかも。

Tags: Net HTTP

2019-05-03 [長年日記]

_ 『技術者のためのテクニカルライティング入門講座』を読んだ

読んだので感想とともに紹介をば。

技術者のためのテクニカルライティング入門講座

AmazonアソシエイトアカウントがゴミクズすぎてBANされたのでそのままリンク貼るお。

対象

タイトルの通りテクニカルなドキュメントをこれから書き始めなきゃいけない人向け。主に業務になって初めて、日本語のドキュメントをたくさん書かなくてはいけなくなったけれど、何から始めればよいのかよく分からない人向け。

文字も大きく、全体的な体裁が比較的ポップめなので個人的にはあんまり好みじゃないんだけど、内容と対象とはマッチしていると思う。

総評

  • ライティングについて「初歩的な部分」からコンパクトに紹介されていてよい
  • 前半は基本、後半は実例で、実例はユーザーマニュアル、提案書、障害報告書、社外メール文というのも扱いやすい

ライティングというと鉄板ネタとして「作文技術」「文章作法」系があるんだけど、もっと実用に寄っていてかつある程度汎用的なワークフローの中に落とし込めるかという意味では、物足りなかったり、不必要に詳細だったりして、紹介しやすい本があまりないなーと感じていた。

簡単に言うと普通の人は論文や本のようにボリュームのあるものを「読んでもらえる」機会はほとんどない。コンパクトでかつ大切なことが必要十分に伝わるように書くことを求められる。また業務の場合、提出先があり、多くの場合は事前にレビューがある。

これまで自分は主に『ドキュメントハックス』を紹介するようにしていたんだけど、さすがに古くなってきていたのと、こちらの方が横書きで図表も豊富なので、まさに「今」に即しているように見える。今後はこれをまずテキストとして紹介していこうと思う。

使えそうな部分

  • まずは 1 から 3 章がやはり基本
  • 4章はやや伝統的なビジネス文書のルールに近い。押さえておくと「何か」とやりやすくなる
  • 5章以降は実践編*1
  • ドキュメントレビュー時に使う『リーダブルコード』のような位置付けで使うとよさそう
Tags: Book

*1 障害報告とか、原因も特定してねーし対策にもなってねーぞ、みたいな報告見ると萎え萎えなのでみんな気をつけてね


2019-05-28 [長年日記]

_ VueとTime Travel Debuggingについて分かったことと、それでもEventのLogが欲しい気がする話

Time Travel Debuggingってなんだっけ

Vuexを用いた開発プロジェクト用にガイドラインを作成した話 - Qiita

を読んで、

最終的にチーム内で合意に至ったのは「パフォーマンスが懸念されるなどの特別な理由がない限り、原則として全ての状態をVuexのStoreで管理する」という方針です。

この決定に至った理由としては以下が挙げられます。

  • Time Travel Debuggingが可能になるため、デバッグがしやすくなる
  • テストがしやすくなる
  • 複数人による開発の中で状態管理に一貫性が生まれる

というくだりを読んで、あれ、Time Travel って Vuex 使わないとできないんだっけ? と思って確認してみた。

試してみた

Vue DevTools 5.0.0 で確認(なぜか 5.1.0 がうまく動かなかった)

Vue DevTools 上の Vuex タブで mutations の履歴を取得できる。この mutation は record された単なる events と違い、実際の変更の記録であり、以下の3つの操作を行える。

  • export
  • import
  • commit all

ということで、「手元で起きたことを他の環境に持って行って」再検証することができる。

これが Time Travel Debug.

あーこれ Event Sourcing の話にも通じるのか。

Eventとの違い

Vue DevTools 上では Event も record できるのだけど、Event は単なる Event であり、record はできるが replay はできない。

これは Event はどこで起きるかもその結果を受けて何を行うかも自由なので replay の難易度が高いということかな? Vuex Store への「変更」に関しては確実な操作(ユーザーの操作ではないけど)の記録であり、Vuex Store 上で replay することは Event をそのまま replay するより難しくない気がする。component が正しく Vuex の state の変化に対して Reactive に動作すればこれで十分である。

雑感

各 component のレベルで data の変更に対して Time Travel できるとより便利っぽい。でもそれができれば先のガイドラインの判断基準がなくなっちゃうのか。

それとは別に Event の export くらいはできるようになってほしいんだけどなぁ…。思わん?