https://ukyo.dev/ Recent content on ukyo.dev Hugo -- gohugo.io ja-JP Fri, 19 Jun 2020 04:57:26 +0900 https://ukyo.dev/post/emscripten-webpack/ Fri, 19 Jun 2020 04:57:26 +0900 https://ukyo.dev/post/emscripten-webpack/ lz4.jsをブラウザで動かす検証。yarn add lz4-asmなどでライブラリを準備して次のようなコードを書く。 import lz4init from "lz4-asm"; (async () => { const { lz4js: lz4 } = await lz4init(); const x = lz4.compress(new Uint8Array([1, 2, 3, 4, 5, 6, 7, 8])); console.log(lz4.decompress(x)); })(); これをWebpackするだけなら問題なくできる。多少の設定は必要ですが。 const path = require("path"); module.exports = { entry: "./src/index.js", output: { filename: "bundle.js", path: path.resolve(__dirname, "dist"), }, node: { fs: "empty", // node.jsではfs使うがブラウザでは使わないのでemptyにしておく }, }; ただ、これだと動作しない。このbundle.jsがwasmを読み込むときfetchしてくるだけなので404になる。単純に要求されたパスにwasmを置くば直る。この場合、dist/_lz4.wasmに置けばok。 ライブラリとしては微妙じゃない? ただライブラリとして使いたいだけなのにnode_modulesに潜ってwasm引っ張ってくるというのはめんどくさいね。動かないんですけどーっていうIssueが投げられそう。まぁ、これはimport("hoge.wasm")みたいな書き方ができるようになったら解決できるかな。 https://ukyo.dev/post/emscripten-1.39.17/ Wed, 17 Jun 2020 04:52:04 +0900 https://ukyo.dev/post/emscripten-1.39.17/ もう自分が作ったかどうかも忘れていたlz4.jsというレポジトリにPRがきた。 なんかgulpにしてwasmにしてモダンにしたぞっていう内容でありがてーという感じなのですが、コードレビューしたら動かねーのでこれとこれとこれを修正してくださいというやりとりをしてなんとかマージした。最近のemscriptenこんなかんじなんだとおもった。そのあと、どうせだからGithub ActionsでCIとnpmへのpublishを自動化しちゃったりもした。 最近のEmscriptenはけっこう便利 昔のemscriptenだとランタイムが準備できました、みたいなのはコールバック置いてごにょってた記憶なのだが、最近のemscriptenで $ emcc 色々 -s 'EXPORT_NAME="lz4init"' -s WASM=1 -s WASM_ASYNC_COMPILATION=1 というかんじでコンパイルしてやると、lz4init関数が初期化されたemscriptenのPromise<Module>を返すようになる。これ便利。 あとは、node.jsの環境なら使う側がnpm installするだけでwasm使われているかどうかは気にすることなくライブラリとして使えるようになってたのも地味に便利。ブラウザ環境だけちょっとは要検証かなー(どっちかというとWebpackの対応具合なのかな?)。 Github Actions Marketplaceにわりとなんでもある emscriptenが絡んでくるとなるとビルドが面倒そうだな、Dockerでごにょごにょしてみたいなことしなきゃいけない?と思ったのですが、Github Marketplaceを探せば同じ問題を解決するためのActionが大抵はあるっぽい。 今回は https://github.com/marketplace/actions/setup-emscripten-toolchain を使ってみた。特に問題なくemscriptenが使えるようになったのでヨシ! これに限らず、定期的にlighthouseの結果をslackに投稿したかったらlighthouse、slackで検索してちょっと組み合わせればそれっぽいのがすぐできちゃうでしょう。 世の中は色々良くなってきてる 久しぶりにemscriptenに触ってすごい進化してた。Github Actionsもエコシステムがすごく充実してたことを実感できた。なんというか、楽な世の中になったよ。 https://ukyo.dev/post/osi-teck-book-2019/ Sat, 14 Dec 2019 04:10:51 +0900 https://ukyo.dev/post/osi-teck-book-2019/ 完全に遅れたのですが、【推し祭り】技術書典で出会った良書 Advent Calendar 2019 - Adventarの12日目の投稿です。推しの技術書典で見つけた同人誌はよくわかるLaTeX小説です。 たしか技術書典2で買ったはず。 コンセプトとしてはLaTeXでの小説組版とか周辺のテクニックを紹介する本です。 小説書かないけど?と思うでしょうが、この本で紹介されているテクニックは、小説だけに限らず技術書などの文章系の同人誌に使えます。 LaTeXをバックエンドとして使っているシステムでは特に有効だと感じました。 例えば、「第4章 画像の扱い」と「第5章 印刷所入稿」あたりは多分万人(同人誌を書く人)に参考になるし、知識として普通に面白いです。 この本自体が綺麗なので参考になるというのもポイントです。 ひとまず同人誌一回作ってみて次は印刷にも多少こだわってみたいなという人にオススメな一冊です! https://ukyo.dev/post/shimaya-factory-tour/ Tue, 01 Oct 2019 06:42:04 +0900 https://ukyo.dev/post/shimaya-factory-tour/ 2019年9月28日に、技術書同人誌博覧会、しまや出版さん主催の町工場を見学しよう！印刷所見学ツアーに参加しました。印刷所でなにやってるかとか、普通に生活していたら一生知ることはないので、これは本当に貴重な機会でした。ありがとうございました。 全体の流れとしては、オフセット印刷、オンデマンド印刷、製本の工程を見学し、最後に質疑応答をしました (※一応、覚えてる限りのことは書きましたが、一部忘れているかも)。 オフセット印刷 オフセット印刷は、アルミで作った版(アルミ以外もあるらしい)にインクをつけて、ゴムに転写、それをもう一回紙に転写し直す印刷方法です。 アルミ版の表面には水分が付く部分とそうでない部分が存在し、水分がついた部分はインクを弾くので印刷できるとのこと。 実際のアルミ版は以下。距離のせいか、目視では何が書いてあるのかあまりわかりません(裏という可能性はある)。 カラー用の印刷機。CMYKごとにアルミ版を用意して、重ねるように印刷します。すごい精密な技術ですね。 しまや出版さんは線数と色の再現度にこだわっていて、 普通の出版物だと線数が175のところ、300で印刷し、さらに300線(難しいらしい)でJapan Colorという認証制度にも合格しているそうです。 モノクロ用の印刷機。主に本文に使用します。B5だと片面8Pの両面で印刷するようです。見た感じだと片面を一気に印刷したあとに裏面を印刷しているようでした。 実際に動いているところをみましたが、速すぎました。 特殊なインク用の印刷機。基本のCMYK以外の色や、匂いのするインクなどの特殊なインクを使う場合はこれを使うそうです。 職人が使う機械という雰囲気が漂っています。 紙をカットする工程があったんですが、写真がぼやけてたので割愛。ギロチンみたいな刃で紙の束が豆腐のように切れていたということだけ書いておきます。 オンデマンド印刷 オンデマンド印刷機はトナーを使って印刷するタイプの印刷機で、コピー機の親玉のような存在です(マンションが買える)。 巨大なトナー。まさに業務用といった感じです。 蛍光色と白色のトナーのサンプルです。トナーの厚みを利用して、黒の上に白をのせてから他の色をのせると色が黒ずまないで綺麗に印刷されます。 蛍光に関しても厚みがあるぶんオフセットよりも蛍光っぽくなるのでは思われます(ちょっと聞きそびれました)。 蛍光の使い所はかなり難しいですが、黒の上に白をのせる表現は割とある気がするので表紙オンデマンドはアリですね。 オンデマンド印刷機その2。社長こだわりの木目調ラッピングがしてあります。 トナー入れ。分かりづらいですが下にもあります。順番を変えることで色を置く順番を変更できるそうです。 PP加工機。表紙をラップする機械です。場所的に、オンデマンド印刷した本はこれでやっているということでしょうか。 ポスターを印刷している印刷機。A1サイズのポスターを印刷できます。縦のサイズは融通がきくそうで、等身大ポスターとかもやろうと思えばできるそうです。 ギリギリ個人で買える値段です。 製本 まずは、かんたんにレクチャーしていただきました。 本文裁断 丁合 表紙くるみ(バインダー) 三方断裁(化粧断裁) という流れで製本をするそうです。絵が丁寧だ。 本文裁断はスキップして、丁合工程から見学しました。 丁合機。ページを順番に並べて、1冊分ずつまとめます。1.5秒くらいで1冊できてました。 表紙くるみをする機械。本文の背表紙にのりをつけて表紙と合体させます。これも凄まじいスピードで動きます。 本文の背表紙にのりをつけるとき、そのままだとつるつるでのりがなじまないそうで、背表紙をざらざらさせます。 図では1番左の状態で、これをミーリングと呼ぶそうです。ざらざら+溝がついています。 次に、溝が埋まるようにラフニングのりというものを塗ります。とりあえず背表紙が繋がります。 その上に背のりを塗って表紙と合体させることでいわゆる本の形になります。 三方断裁。上下と開く側の余計な部分を切り落とします。これもまた豆腐のように切れます。 通常の製本だとこれで完成みたいです。 型抜きするやつ(機械撮り忘れた)。猫のうちわにも使えますが、おもに表紙のセパレーション加工やトムソン加工などで使用するようです。 中綴じ製本機。スペース的にコスパよさそうです。おまけ本などによく利用されるそうです。 おまけ本以外だと、フルカラーイラスト本だとノド部分まで見れるので使っている人が多い印象です。 質疑応答 会社の説明や自慢ポイントや質疑応答など。カラーマネジメントすごい話はここで聞きました。質疑応答についてはぶっちゃけ話多かったですね(つまり書けない)。 以下は社長がコミケに参加した話の場面のスライド。社員の方も同人誌を作っているそうで、同人誌作る側の気持ち(ほんと心折れそうになる!)をわかっているというのは心強いです。 印刷会社ならではのクラウドファンディングもしているようです。 まとめ 改めて貴重な機会、ありがとうございました。工場見学としても面白く、同人誌を作る立場としても役立つ知識を得ることができました。 こだわろうと思えば商業出版以上のクオリティの印刷物を作れるのが同人誌の強みだと思いました。 あと、しまや出版公式YouTubeチャンネルから印刷工程のダイジェストがみれるようなのでチェックしてみてください。 愉快なCMもみれます。 https://www.youtube.com/user/ShimayaTokyo https://ukyo.dev/post/ng8-webworker/ Fri, 24 May 2019 19:06:23 +0900 https://ukyo.dev/post/ng8-webworker/ Angular8のCLIのgenerateコマンドからWebWorkerを作成することができるようになりました。 ng generate webWorker で、Workerのコードとビルド用の設定を吐き出してくれます。 $ ng new worker-app ... $ cd worker-app $ ng g webWorker hello CREATE tsconfig.worker.json (212 bytes) CREATE src/app/hello.worker.ts (157 bytes) UPDATE tsconfig.app.json (236 bytes) UPDATE angular.json (3614 bytes) 生成されたコードの中身は次のようになります。 /// <reference lib="webworker" /> addEventListener('message', ({ data }) => { const response = `worker response to ${data}`; postMessage(response); }); これをAppComponentから使ってみます。 import { Component, OnInit } from "@angular/core"; const worker = new Worker("./hello.worker", { type: "module" }); @Component({ selector: "app-root", templateUrl: ". https://ukyo.dev/post/assemblyscript-performance/ Thu, 25 Apr 2019 14:55:54 +0900 https://ukyo.dev/post/assemblyscript-performance/ ちょっとだけ触りました。AssemblyScriptはTypeScriptの記法で書いたものがwasmに変換できるというもので、 書き味はTypeScriptユーザーならば問題ないです。ただし、結構素直に変換されるので書き方によっては露骨に速度が変わります。 ちょっと試した感じだと、以下の3点を意識して書くとわりと良いパフォーマンスを得られました。 @inline の検討 以下のように関数に @inline デコレータをつけるとインライン展開されます。関数呼び出しのコストが減ります。逆にwasmコードが肥大化するのでそこはトレードオフです。 @inline function square (x: i32): i32 { return x * x; } load, storeの最適化 公式wikiのMemory access セクションに書いてあるのですが、第2引数(store は第3引数)に constantOffset を指定できます。あるポインタから定数分だけずらしてメモリアクセスしたい場合は使うと速くなります(i32.const x、i32.add分お得)。ちなみに、コンパイル時解決なので変数はだめです。 let r = load<u8>(p, 0); let g = load<u8>(p, 1); let b = load<u8>(p, 2); let a = load<u8>(p, 3); なるべく型キャストしない 当然ですが型キャストしないほうが速いです。例えば、 let x = load<u32>(p1) as f32; let y = load<u32>(p2) as f32; if (x === y) return; // ここに結構ひっかかるとする // . https://ukyo.dev/post/hello-netlify/ Sun, 24 Feb 2019 21:01:00 +0900 https://ukyo.dev/post/hello-netlify/ Netlifyに移行してます(途中)。記事をhugoで生成してGithubに置いてNetlify連携という感じで。 export class Netlify { constructor() { console.log("hello"); } }