追記: Apollo Boost は Apollo Client に統合される見込みのようです。Apollo Client 3.0 Roadmap · Issue #33 · apollographql/apollo-feature-requests · GitHub TypeScript用のGraphQL clientであるところの Apollo ですが、これのGet Startedなどのドキュメントでは apollo-boost というパッケージを使っています。 www.apollographql.com しかし、 apollo-boost はサンプルコードをシンプルにするための apollo-client などのラッパーと考えたほうがよく、プロダクションコードでは apollo-boost ではなく apollo-client および関連モジュールを直接使うほうがいいです。 以下理由

追記: Terser v3.10.11 でこの問題が修正されていることを確認しました。現在は collapse_vars: false というワークアラウンドは不要になりました。 webpackのproduction buildの話です。 Reactが悪いわけではないんですが、たまたま秘孔をつくコードがReactないし関連するReact v16に依存するライブラリにあったんでしょうね。 Reactをv16にアップグレードしたら webpack で production build ができなくなった pluginを着脱しながら調べた結果、 uglifyjs がクラッシュしていることがわかった uglifyjs は現在 オリジナル + 2つのforkがあり、すべてで再現する original: https://github.com/mishoo/UglifyJS fork 1: https:/

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 （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX

最近、Kibelaのtslint configの Rule: array-type を "generics" にしました: + "array-type": [ + true, + "generic" + ], 以前は特に指定しておらず、 T[] と Array<T> が混在してていて、それでよしとしていました。今でも、混在することによるデメリットは特にないと思っていいます。ただ、 Array<T> には一つだけメリットがあったのでこちらに統一することにしました。 autofixできるので、エディタ上では T[] と書いて保存時にtslintに Array<T> に直させるということができるため、導入のデメリットがないというのも大きいです。 さて Array<T> のメリットは、 ReadonlyArray<T> に直しやすいということです。 ReadonlyArray<T> は Array

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

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

KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に（＝多くのケースではエディタで）typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、

こないだの@onkさんのスライドがとても良かったんですよ。 短期間で新技術を学ぶ技術 from Takafumi ONAKA 短時間といいつつ守破離の「離」までいくのに3年かかるといってて、高速道路なんてものはないんだなということがわかりますね。 とはいえ自分自身に照らし合わせてみてもそのとおりだなと思いました。ぼくもAndroidで対外的にアウトプットできるようになるまで3年くらいかかってますし。まあ、ぼくは新技術を学ぶのはわりと苦手なほうではあるんですが。 で、スライドにはないけど新しい技術を学ぶ際には大きな壁がいくつかあるなとあると思ってます。それを 意識して 乗り越えるための指標としてもこのスライドはよさそうだなと。 ついでなのでちょっと ぼくの感じる 三大壁をまとめてみました。まあ、壁を壁と感じない人もいると思いますけどね！ Lv.1 着手の壁 症状: 何の役に立つのかわからない

Android Javaでは昔からAOSPのcoding style guidelineに則ったスタイルがとられることが多いようです。そのなかで、private fieldに "m" (member) や "s" (static member) などのプレフィクスをつけよ、というものがあります。 AOSP Java Code Style for Contributors  |  Android Open Source Project これはいわゆるハンガリアン記法の変種で、こういうやつですね。 class Recipe { private String mTitle; private List<String> mSteps; // ... } これについての態度はプロジェクトごとに様々ですが、たとえばクックパッド社のJavaのスタイルガイドでは明確に否定しています。 styleguide/