サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
gfx.hatenablog.com
ES modulesにexport defaultってのがあるんですが、default exportのexport対象に名前が必須でないため、IDEによるコード補完と相性が悪いです。 他のところはどうしてるのかなと思って調べてみると、GoogleのTypeScript Style Guide では禁止されてました(v1.0.0, 2019/07 現在)。 https://github.com/google/gts/blob/v1.0.0/tslint.json#L40 ("no-default-export": true) TypeScript compiler coding guidelineには特に言及はないみたいですね。 https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines そもそもexport defaultは
Zlib | Node.js v9.2.0 Documentation Note that all zlib APIs except those that are explicitly synchronous use libuv's threadpool, which can have surprising and negative performance implications for some applications. スレッドプール数は UV_THREADPOOL_SIZE 環境変数で変えられて、ドキュメント によてばデフォルトは4とのことです。なお同期メソッドの場合はスレッドは使われないとあります。また fs や crypto の一部のメソッドも同様にworker threadで実行されるようです。 考えてみればCPUバウンドなzlibを単に非同期にするのは意味がないわけですが
三行まとめ Cライブラリzopfliをwasmにビルドして npmjs.com にリリースしてみた wasmはポータブルなバイナリで、ネイティブコードと比較して半分程度の性能を期待できる emscriptenは N-API と比べると出来ることが少なすぎるのが課題 背景 WebAssembly *1 の評価のために、Cで書かれたzlib互換の圧縮ライブラリ google/zopfli をemscriptenでwasmにビルドしてリリースしてみました。 評価だけでなくリリースまでしたのは、zopfliのnodejs native addonである node-zopfli をしばしばインストールできないことがあるという問題があってそれを解決したかったからです。nodejsのnative addonはnode-gypというビルドツールを使うことが多いようですが、これはPython 2.x などn
PlantUML、便利ですよね。はてなブログでも使いたいですよね。ということでやってみました。 まずエントリの最後にこのスニペットを置きます: <script> var a = Array.from(document.querySelectorAll("pre.code")); a.forEach(function (pre) { if (pre.attributes['data-lang'].value) return; var xhr = new XMLHttpRequest(); xhr.open("POST", "https://plantuml-service.herokuapp.com/svg"); xhr.onload = function () { if (xhr.status === 200 && pre instanceof HTMLPreElement) { pre.
github.com AssemblyScriptという、TypeScriptのサブセットでありWebAssemblyにコンパイルできる言語があります。 ※ WebAssemblyについては WebAssembly の基礎 - nmi.jp などをどうぞ TSのサブセットとはいえ、WebAssemblyにコンパイルしやすくするために若干互換性がない部分もあります。たとえば、 || や && といった演算子の結果はJSだと左辺ないし右辺の値ですが、ASの場合はboolになります。 とはいえ assembly.d.ts のおかげで普通にvscodeで開発できるので、生のWebAssemblyを書くよりはだいぶマシでしょう。 標準ライブラリは std/ 以下をみるといくらか定義されていて、たとえばstring.tsをみると文字列操作の様子がわかります。 https://github.com/As
スギャブロエックス(id:sugyan, id:kazeburo, id:gfx) で予選に出場して2日目2位でした。去年は予選敗退だったので2年ぶりの本戦出場です。 バランスの良い良問で大変楽しかったです。ISUCON運営チームに於かれましては大変おつかれさまでした&ありがとうございました。 isucon.net スギャブロエックスのスコア推移: repo: https://github.com/gfx/isucon7-qualify 言語 採用言語はnodejsでした。もともとはPerl界隈で知り合った3人ですが、最近だれも現役でPerlを書いておらず、go, ruby あたりでやるか〜みたいな話を最初していました。途中でnodejs実装が追加されることになったので、nodejsにしたい!と希望してこうなりました。 スギャブロエックスがnodejsだと…— Ryuta Kamizono
sprocketsを使っているアセットは半ば自動的にgzip圧縮版ファイルが用意されるのでそれをnginxのgzip_staticなどでサーブすればいいわけですが、JSのビルドをwebpck化したときにそういえばgzipされたファイルを用意しなくなったなと。それでもまあ、nginxが圧縮はしてくれますが、nginx自身が行うon-the-flyよりも事前に時間をかけて圧縮するほうが圧縮効率はいいので、やらない手はありません。 というわけでcompression-webpack-pluginです。これはデフォルトだとgzip圧縮しますが、圧縮ルーチンをカスタマイズできるのでnode-zopfli *1を使うこともできます。こんな感じに: const CompressionPlugin = require("compression-webpack-plugin"); const zopfli
gitter.im Markdown自体の仕様については、CommonMarkに期待しているので commonmark.org でよい CommonMarkに収まらない拡張を日本語で議論できる場所がほしい ルビや数式など サービス間で(ある程度)互換性があることはMarkdownの大きな価値なので、その議論ができるといいと思っている ビジネス的には競合だったりするもあると思うが、そこで差別化してもユーザーにとってメリットはないと思うので という感じです。 8月にMarkdown Nightをやったら思いのほか反響があったので、それをうけてコミュニティの必要性を感じたというのもあります。 Markdown Night 2017 Summer - connpass Markdown Night 2017 Summer という勉強会が開かれました - Mercari Engineering Bl
yarnpkg v1.0から、 package.json の engines sectionのバージョンチェックが厳密になりました。これにより新しいnodejsやyarnpkgを試すのが面倒になります。 これにメリットを感じない場合は無効化しましょう。 具体的には、 ~/.yarnrc に ignore-engines true を書き足すと、 --ignore-engines が指定されたのと同じになりバージョンチェックが無視されます。 echo "ignore-engines true" >> ~/.yarnrc
あるいは私がDefinitelyTyped (DT) が失敗だと思っている理由、です。 DefinitelyTypedは明確に失敗だと思っているので、あれを避けるのはそんなに難しくないかなと。まず (1) anyを認めて「型がなくてもいいや」という気持ちでいく (2) 中央repoは作らずそれぞれのgemに対して型定義パッチをおくりつける でなんとかなるっしょ。— FUJI Goro (@__gfx__) September 19, 2017 あたりが話の発端です。 DTについては以前いまいちイケてない理由を書いたことがあります。 TypeScriptのDefinitelyTypedは「ダメでもともと、うまく使えればラッキー」くらいの距離感がよい - Islands in the byte stream この時の話を一言でまとめると「ライブラリの作者ではない第三者がメンテしていることが多く
github.com Promise.prototype.finally が stage-3 になって、 ES polyfill集である core-js にも v2.5.0 で追加されたので、babel-runtime などを使っている場合はcore-jsのバージョンを上げるだけで finally を使えるようになってます。 しかし、TypeScriptの場合は型情報が必要なので、core-jsのアップデートだけでなく、次のnpm moduleを使って型情報の追加が必要になります。 www.npmjs.com TypeScript compiler (確認したのはv2.5.2) 的には、package.jsonに追加(して当然npm installなりyarnpkg installなりする)だけで利用可能になるようです。 ただし、RubyMine (v2017.2.3) はそれだけだと解釈
作業メモとして。なお、 CommonMark ≒ GitHub Flavored Markdown くらいの感覚で書いてます(実際にはGFMはCommonMark + いくつかの独自拡張)。 http://commonmark.org/ https://github.github.com/gfm/ 膠着語分かち書きしない言語におけるスペースで区切られないトークンとインライン記法について 膠着語というのは、日本語や中国語のように単語と単語の間にスペースをいれないタイプの言語です。 膠着語は分かち書きしない言語のことではありませんでした…。素直に「分かち書きしない言語」というのがよさそうです。 CommonMarkは分かち書きしなくてもそれなりに動くように定義されていますが、エッジケースではまだ思った通りに動かないということがあるようです。 ひとつ仕様のバグっぽいのをみつけたので起票しましたが
The Maskarade project · GitHub 最近イマイチAndroidの活動ができてないんですが、Androidライブラリのメンテを諦めたわけではなくて、たとえばOrmaとかはまだやりたいことがいくつかあるのでやるつもりはあります。一方で、ちゃんと新しいメンテナがいたほうがいいなーというプロジェクトもあって、とりあえず私のメンテする気のあるなしに関わらずユーザーがいそうなAndroidライブラリを全部まとめて maskarade(マスカレード)というorganizationに移すことにしました。 何故これが必要なのかというと、新しくオーナーシップをもったメンテナを受け入れられる体制にするためにorgが必要だからです。GitHubは個人アカウントにあるリポジトリのオーナーシップをコラボレータに渡すことはできないんですよね。なので、オーナーシップを誰かに渡したいときは (1)
builderscon tokyo 2017 - Aug 3, 4, 5 2017 いろいろな分野の人がいて非常に刺激になりました。来年はなにかネタを持っていきたい。 あと名札がリバーシブルなのよかった。なお一人ひとりにユニークなQRコードを発行するのはバリアブル印刷というそうです。 builderscon の名札、リバーシブルなのめっちゃ良かったのでこれがスタンダードになってほしい。 pic.twitter.com/qSrO5DYCuR— FUJI Goro (@__gfx__) August 6, 2017 印象に残ったトークについて感想など。 横山光輝三国志 全文検索システム 最高に面白いサービスなのでぜひコンテンツの権利者と仲良くしてサービス化してほしいところ! 技術的にもわりと参考になりました。 OCRはGoogle CVが曹操級で手書き文字もそこそこいける 誤検出したテキストは
Malicious packages in npm. Here’s what to do | Ivan Akulov’s blog People found malicious packages in npm that work like real ones, are named similarly real ones, but collect and send your process environment to a third-party server when you install them 訳: 悪意のあるパッケージがnpmで発見された。それらは、実際のパッケージによく似た名前で同じように動くが、パッケージのインストール時にプロセスの環境変数を外部のサーバに送信する。 発見されたパッケージの一覧は元エントリをどうぞ。このようなマルウェアである偽パッケージの一例をあげると、 ba
便利なソフトウェアを定期的に掘り起こすぞ活動です。 ghq は「GitHub repoのclone先を統一することでいろいろ便利にできるコマンド」で、github repoのclone先を、カレントディレクトリに依存せず ~/.ghq/github.com/$owner/$repo/ にします。 使い方: ghq get -p --shallow $URL peco は、テキストのリストをgrepしてそれに対してなにかコマンドを起動するみたいなやつで、ほかのツールと組み合わせて使います。 ghq + peco .zshrc などにエイリアスを作っておきます。 alias g='cd $(ghq list --full-path | peco)' alias b='hub browse $(ghq list | peco | cut -d "/" -f 2,3)' alias v='code
github.com Railsのcontrollerで違和感があるのって actionのinputに params というインスタンスメソッド経由でアクセスすること しかも params はviewからアクセスできる! actionのoutputが controller のインスタンス変数への代入であること しかもそのインスタンス変数はviewからアクセスできる! というところだと思うんですよ。 なぜなら我々は「メソッドの引数でinputを受け取りメソッドの戻り値をoutputとすべし」ということを是としてコードを書いてるわけじゃないですか。リーダブルコードを読むまでもなく、変数のスコープは狭ければ狭いほどメンテナンスしやすいリーダブルなコードだというベストプラクティスを正しいものとしてコードを書いているわけじゃないですか。 そういうベストプラクティスに真っ向から反しているのが現在のRa
カッとなって作りました。後悔はしてません。 github.com /entries/:id を生成するためにRailsのviewで entry_path(42) などとしますが、それをTypeScriptからも Routes.entryPath(42) などとして使えるようにするためのgemです。 READMEにあるように rake task を定義して適当なパスに routes.ts を生成するという想定です。sprocketsには対応してません。 Rails URL heplersのJSへのエクスポートというとrailsware/js-routes があって、これをずっと使っていてしばらくは十分だったのですが、js-routesの生成するコードには型情報がありません。フロントエンドのコードベースをTypeScript化したいまとなっては、開発中にしばしばtypoして実行時エラーになるの
RubyMine 2017.1 Help :: Using Annotations にあるとおりなんですが、 local variables: # @type [String] my_var = magic_method # @type my_var [String] my_var = magic_method # @type [String] my_var my_var = magic_method # @type [String] my_var Add some documentation here my_var = magic_method block parameters: method_with_block do # @type [String] param1 # @type [Range] param2 | param1, param2 | # some code... end
Kibelaは次のようにいくつかmarkdownを拡張しています。 PlantUML記法に対応しました - Kibela Blog 記事の外部共有とLaTeX記法による数式表示に対応しました - Kibela Blog そして、今後もそういう拡張は増えていくと思われます。 PlantUML KibelaのPlantUML記法はこういうやつです。 ```plantuml Bob -> Alice : hello Alice -> Bob : Go Away ``` GitLabも同じ構文でPlantUMLをサポートしていますね。 PlantUML & GitLab - GitLab Documentation crowiも最近PlantUML記法をサポートしはじめましたね。構文はKibelaとおなじです。 Support PlantUML by sotarok · Pull Request
自前でTypeScript型定義ファイル(dts)を用意していないJSライブラリのための型定義ファイル集があります。 https://github.com/DefinitelyTyped/DefinitelyTyped npmで @types/react みたいなのがそうです。 これは便利なものですが、ライブラリ作者ではない第三者が作っていることがほとんど(作者にやる気があればライブラリ本体で管理するほうが圧倒的によいので!)なので、型定義が間違ってることが普通にあります。 直近だと、 @types/react-intl の型定義が間違っているので、これを導入するとコンパイルが通らなくなるみたいな事情がありました。 一応PRは送りましたが、これがマージされても別に使う必要ないんじゃないかと思ってます。 https://github.com/DefinitelyTyped/Definitel
とある分散バッチシステムでdigdagを導入してみています。 www.digdag.io スケジューラ機能などは使っておらず、タスクを良い感じに並列実行するためのmakeよりちょっと便利なツール、くらいの感じで使ってます。 digdagは下記のようにloopなどを _parallel: true を指定するだけで並列実行できるのがいいですね。 timezone: UTC +repeat: loop>: 3 _parallel: true _do: +run: sh>: "echo ${i}" +teardown: echo>: finish ${session_time} ところで、このこの並列実行数を制御する方法がわからなかったのでコマンドラインオプションで渡せるようにpull-requestしました。 digdag v0.9.13 からたぶん使えます。 add --max-task-t
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に(=多くのケースではエディタで)typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
devcenter.heroku.com Herokuのreview-appsはたとえHerokuを使っていなくても非常に便利なものですが、PR削除時にS3やElasticsearchなど外部にホストしているリソースを掃除する方法がありませんでした。 ところが、最近は pr-predestroy hookが実装されたようで、外部リソースの掃除ができるようになったみたいですね。 ますます便利になりありがたい!
一部のプロジェクトでmitamae (itamae on mruby) を使ってるんですが、自分が書いているときはともかく他人が書いているmiamaeでrecipeのロードエラーが発生すると、mruby-ioレベルでもmitamaeレベルでもファイル名を出力してくれなくてこれはデバッグできないぞという状態でした。 問題は2つのレイヤーであって、 mruby-io がopenの失敗時にファイル名を出力しない mitamaeのロガーは読み込んだレシピを実行するときはログを吐くが、ロードの前あるいは失敗時の処理がない 低レイヤーのmruby-ioはopenは失敗時にファイ名名を出力すべきだし、miamaeレイヤーでもレシピの読み込みは非常に重要なのでもっと詳細にログに出してほしいところです。なおmitamaeレベルでのレシピ読み込みエラーはopen由来とも限らないので、どちらか一方ではなく両方の
公式ドキュメントにありました。一言でまとめると、Android Oのpreviewが出た現在においても「Android N (API version 24)と同水準」となっています。 Use Java 8 language features | Android Studio Android Studio 2.4 preview 4 (およびそれが要求するツールチェイン)の段階では、 desugar と呼ばれるツール(実体はAndroid Gradle PluginのTransform APIによるbytecode weaving tool)によって、一度javacでコンパイルしたバイトコードのJava8の言語機能(lambda, repating annotationsなど)をJava6水準のバイトコードに変換し、それをdxコマンドでdexにコンパイルするというプロセスを経るようです。この
今更感ありますがReact Reduxを導入したの所感をメモしておきます。 github.com ざっとみてこれなら自分でも再実装できそうだなという印象 いままではreact-micro-container でfluxしてた cf. 小さいReactアプリケーションのためのライブラリ書いた - Qiita 新規Railsアプリに小さく導入するReact // Speaker Deck React Reduxにすると、個々のreact componentをfluxフレームワークに依存しない形で設計できる これに対して react-micro-container はcontainerに制御されることを意識した設計になる(=containerとcomponentで設計が異なる) React ReduxなしでReactを初めてRect Reduxを導入するのは簡単だし、あとから別のflux実装にす
『Androidを支える技術 I』 ~ 60fpsを達成するモダンなGUIシステム ~ 『Androidを支える技術 II』 ~ 真のマルチタスクに挑んだモバイルOSの心臓部 ~ これらを著者の有野さん よりご恵贈いただきました。ありがとうございます。 始めて知る内容も多かったのですが、既に知っていることでも著者の意見が反映されているのを読むと、いくつものモバイルOSを見てきたハッカーからみるとこう見えるのか!という新鮮な面白さがありました。 IとIIのテーマは独立しているので、どちらから読んでもいいと思います。 以下個人的に面白かった章をピックアップします。 I の見どころ §1: ActivityThread.java にあるAndroidアプリのエントリポイント public static void main(String[] args) の役割 ActivityTheadはデバッグ
MathJax というのはLaTeXなどで書いた数式を美しく描画するための処理系です。 なおこのエントリは MathJax v2.7.0 を対象にしています。 www.mathjax.org まず前提として、ほとんどのケースではMathJaxをconfigパラメータを与えてロードするだけで自動的にtypeset *1 が行われます。 この自動typesetは、HTML中のすべての要素に対してただ一度だけ行われるので、content editableでウェブエディタを実装しているケースやリアルタイムプレビューとの相性が非常に悪いのです。つまりcontent editable中のLaTeX記法は置き換えるべきではないのに置き換えてしまうし、プレビューが更新されてもtypesetされないのでこちらはLaTeX記法が処理されません。 そこで細かくMathJaxを制御する必要があるのですが、これがな
次のページ
このページを最初にブックマークしてみませんか?
『Islands in the byte stream』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く