GraphQLとMessagePackは相性がよさそう - Islands in the byte stream
MessagePackはJSONのようなデータをシリアライズできるbinary formatで、JavaScript実装である msgpack-javascriptを基準で考えると次のような特徴があります: JSONよりencodeもdecodeも少し速い かつ、streaming decodeができるので fetch() のresponseのdecodeの効率がとてもよい とはいえ実用上は「JSONより遅くない」ということのほうが重要ではある binaryを直接扱える これに対してJSONでbinaryを扱うときははbase64などでエンコードする必要がある timestamp型があり、デフォルトではJSのDateにマッピングされる Intl.DateTimeFormatへの入力としてならこれで必要十分 マッピングをあとから変えることはできる 特にバイナリを直接扱えるのはJSONとくらべ
プロジェクト固有のルールを指定できるLinterであるところのQuerlyがめちゃ便利 - Islands in the byte stream
https://github.com/soutaro/querly Rubyを構文解析したASTに対して独自DSLでパターンマッチ＆メッセージを出すツール プロジェクト固有の事情に配慮したLinterとして使える false positive 上等で注意喚起として使う たとえばKibelaの querly.yaml から一部抜粋するとこんな感じです。 rules: # ... - id: kibela.order_by_string pattern: - "order(:dstr:)" - "where(:dstr:)" - "find(:dstr:)" - "exists?(:dstr:)" message: "文字列によるSQL構築は本当に必要ですか？ SQL Injection を引き起こさないように気をつけてください。" - id: kibela.block_call patter
DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
JavaScript Quiz: (new Array(2)).map($ => 'hello') === ? - Islands in the byte stream
まあ、分かってしまえばなんということはないんですが、結構面食らいますね。 This sure isn't what I would have expected. pic.twitter.com/wNQ0CkycUn— Andy Hall (@fenomas) January 23, 2018 MDNにはちゃんと書いてありました。 Array.prototype.map() - JavaScript | MDN (callback) is not called for missing elements of the array (...) Due to the algorithm defined in the specification if the array which map was called upon is sparse, resulting array will also be
High Sierraには「アプリのリンクを踏んでもChromeの空白ページが開くだけ」というバグがあるっぽい - Islands in the byte stream
一時的な回避策ですが、このバグが発現する状態になったら「Chromeを再起動する」で回復するようです。このエントリを書いている時点でのmacOSの最新版は 10.13.2 (High Sierra) なので、以降のバージョンでは直ってるかもしれません。 ぼく自身はまだSierraのままなので伝聞です*1。ただTwitterのタイムラインで頻繁にこれ系の悩みを見かけて、そのたびに返信しているのでもっと知られるべきだなと思い、キーボードを叩くことにしました。 追記: Chromeのアップデートがきているときに起きやすいようですが、アップデートが来ていなくても起きるようです。 なんか、アップデートが降って来てる状態だと発生するぽいです— SHIBATA Hiroshi (@hsbt) December 19, 2017 これみんななってたのか。アップデートなくても起きるなあ。 / “High S
ES modulesのexport defaultは使わないほうがよい - Islands in the byte stream
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は
WebAssemblyをNodeJS Native Addonの配布形式として使う - Islands in the byte stream
三行まとめ 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
なぜTypeScript推しなのか - Islands in the byte stream
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に（＝多くのケースではエディタで）typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
新技術を学ぶ技術と三つの壁とDroidKaigi 2017 - Islands in the byte stream
こないだの@onkさんのスライドがとても良かったんですよ。 短期間で新技術を学ぶ技術 from Takafumi ONAKA 短時間といいつつ守破離の「離」までいくのに3年かかるといってて、高速道路なんてものはないんだなということがわかりますね。 とはいえ自分自身に照らし合わせてみてもそのとおりだなと思いました。ぼくもAndroidで対外的にアウトプットできるようになるまで3年くらいかかってますし。まあ、ぼくは新技術を学ぶのはわりと苦手なほうではあるんですが。 で、スライドにはないけど新しい技術を学ぶ際には大きな壁がいくつかあるなとあると思ってます。それを 意識して 乗り越えるための指標としてもこのスライドはよさそうだなと。 ついでなのでちょっと ぼくの感じる 三大壁をまとめてみました。まあ、壁を壁と感じない人もいると思いますけどね！ Lv.1 着手の壁 症状: 何の役に立つのかわからない
ライブラリのバージョニングのしかた - Islands in the byte stream
セマンティックバージョニングは守るとして、だいたいこんなポリシーでやってます。 0.0.1 - proof of concept / minimum viable product 0.1.0 - とりあえずリリースしてプロダクションに組み込んでみる 1.0.0 - プロダクションに組み込んだ 2.0.0 - セマンティックバージョニングに従うので、メジャーバージョンアップは機能ではなく単にAPI互換性を失うという印 あとは、alpha, beta, rcなどを接尾詞としてつけることもあります。 *-alpha - 開発中 *-beta - 安定してきた *-rc - release candidate. プロダクションに組み込んでもOK
PlantUML Web APIをSpark Framework + Kotlinなウェブアプリにしてみた - Islands in the byte stream
PlantUML を使うとき、 java -jar plantuml.jar だとほんの小さなダイアグラムの生成にも数秒かかってしまいます。ローカルではそれでいいかもしれませんが、ウェブアプリに組み込むのはちょっとイマイチですよね。 PlantUMLはJava製ツールなのでJavaのウェブアプリにしてしまえば高速になるはず、と思ってやってみました。 リポジトリ: https://github.com/gfx/plantuml-service ウェブアプリといってもパスが /svg/:source しかないような最小限のものです。 :source はPlantUML Text Encodingでエンコードされたソース、または生のPlantUMLソースです。特にキャッシュなどはしませんが、手元のMBAだと小さなダイアグラムの生成で70msほどになったので実用に耐えそうです。 PlantUMLは
公開用DockerイメージにAndroid SDKを含めるのはライセンス違反という話 - Islands in the byte stream
Android Software Development Kit License Agreementにこういう項目があります。 3.4 You may not use the SDK for any purpose not expressly permitted by the License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of
github.comのアカウントは仕事用と私用で分ける方がいいの？ - Islands in the byte stream
追記(2019/04/11): sonots氏がGitHubの方と相談しつつ設計した運用方法が公開されました。 全社的に会社用GitHubアカウントを廃止した件 - ZOZO Technologies TECH BLOG このガイドラインは今後のデファクトスタンダードになると思うのでtl;drを引用します。 個人で会社用と私用の2つの無料GitHubアカウントを持つことはGitHubの規約「非」準拠だった 会社用GitHubアカウントを廃止し私用GitHubアカウントを利用する規定に変更した セキュリティを担保するためGitHubのSSO機能を利用した GitHubの規約的には、おそらく「会社として会社用アカウントを pro版にする」「個人が身バレを防ぐために個人アカウントをpro版にして会社用アカウントを別途作る」などの運用も可能だとは思います。しかし、GitHubというサービス自体マル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
