Flutterのjson_serializableで無限ループになったら

おきまりの flutter pub run build_runner build を叩くと、エンドレスにビルドが走って終わらなくなった・・・。@JsonSerializable アノテーション以外のファイルまで見に行ってる。widget_test.dart を見に行くアホがおるかい。

英語でググってみたところ、このissueがあった。

github.com

どうやら、analyzer というFlutter内部で利用されるライブラリのバグのようで、0.39.17 → 0.39.14 にダウングレードしたら、ビルドできました...

ダウングレードするには、pubspec.yamlにこの記述を加筆するだけ。

dependency_overrides:
  analyzer: '0.39.14'

追記 2020.9.17

analyzer 0.40.2 で修正されたようです。めでたしめでたし。

Vue.jsでは親子関係の画面をネストされたルーティングで対応する

router.vuejs.org

例えば、お申し込みフォームが複数の画面に分かれているが、「1つの画面操作」として捉えて、データを管理したい場合等。

const router = new VueRouter({
  routes: [
    { path: '/user/:id', component: User,
      children: [
        {
          // /user/:id/profile がマッチした時に
          // UserProfile は User の <router-view> 内部で描画されます
          path: 'profile',
          component: UserProfile
        },
        {
          // /user/:id/posts がマッチした時に
          // UserPosts は User の <router-view> 内部で描画されます
          path: 'posts',
          component: UserPosts
        }
      ]
    }
  ]
})

chilren属性を使うだけ。便利。

TypeScriptのUNION型、これ便利なのか・・・

let a: string | number;

a = 'Hello';  // OK
a = 123;      // OK
a = true;     // NG

//取る時はこう
if(typeof a === "string") {
}
else if(typeof a === 'number') {
}

typeofで型を指定すれば、型推論により、自分の欲しい型でゲットできる。UNION型は便利だと結構もてはやされているけど、戻り値がUNIONだった時が非常に面倒...

ExpressというNode.jsのWAFがあるけど、request.query.hoge ってやった時に、hogeがstring/string[]/undefinedの可能性があるよね〜あるよね〜みたいな話になってだるすぎる。配列で返ってくる前提ならflaskみたいにrequest.getlistっていう関数にしてほしい。

ENUMのイケてるやつ、引数の型指定として使うのはわかるど、関数の戻り値でこっちが空気読んで戻り値の型を指定して取る行為に時間を取られるの、僕は嫌い。

Vue.js + TypeScript、なかなかおもしろいです

７月からそういうお仕事をやっている。

色んなUIを作るライブラリが豊富で、コンポーネントをたくさん作っておけば、色んな案件に流用できるだろうなぁ。クールなUIが爆速で作れる時代になってきた。ありがてぇ。UI開発が一番面倒だからなあ。

kintoneでもvueをサポートする手順が公開されているし、今年はVue.jsをちゃんと使えるようになるお

developer.cybozu.io

Flutter楽しいれす

前職の兼ね合いで、一緒になって作りたいサービスを5月から合間見て作っております。

それにはスマホのネイティブアプリが必要だったので、Flutterで作り始めているのですが、これはすごいっすね。ありがとうFlutterを作ってくれたネ申エンジニア。儲かったら334ドルはコミュニティに寄付したい。

初めてiPhoneアプリ+SwiftとAndroidでアプリを作った時、ひとりで全部組んだせいもあって、だいたい半年かかった。Flutterで作ったら概ね3週間で実装できた。スマホアプリを作ったことがなくてゼロベースでやったとしても、1ヶ月半もあればできたと思う。

Flutterだと生産性があがるいくつかの理由

当たり前だけど、iOS / Androidのアプリが１つのコードに共通化できる。そんなことが可能になる時代になるなんて思ってなかった。Flutterのエンジンがどういう理屈かわからないけど、Flutterで実装すると、Xcode / Android Studioのプロジェクト形式にコードを書き出してくれる。Flutterのコアはコードジェネレーターなのだ。コードが共通化できることで、車輪の再発明がなくなった。使用するライブラリのメンテナンスコストが下がった。iOSとAndroidで別々に管理しなくて良くなったからだ。

状態管理も楽になった。Androidの場合はActivityやFragmentのライフサイクルに気を使ったりして面倒だったり、iOSもViewdidLoad/ Appear系の関数をうまく使って状態管理をしていた(そういうコードを書いてしまったのだ)が、Flutterになると原則「StatelessWidget + Provider」でやっていけるので、コードの記述量も減った。

何よりも嬉しいのは、豊富なWidgetがあること、ビューがコードで書けること。iOSのStoryboardや、Androidのlayout_xx.xmlとか面倒くさいだけだったな・・・と噛み締める。iOSの場合は、共通化したいViewはxibファイルを作って、親となるViewControllerでaddSubviewしてからのイベントハンドリングはdelegeteかまして任意の誰かにイベントハンドラを実装させて・・・みたいなコードを頑張って書いたが、Flutterの場合はWidget作って返すだけ。カスタムセルとかレイアウトもGridからColumn/Row、スクロールなども簡素化できた。ネストが深くなるけどね。状態が変更されたらWidgetがリビルドされることで、モデルのデータに沿ったビューが簡単に実装できるのも良い。

ネイティブだと、ビューの癖が強いのも生産性を下げる一因だったんだと思いました。iOSのUITableViewとかは、複数のオーバーライドしないといけなかったり、セルをカスタムする場合はカスタムセルのXib作って、AutoLayoutで制約与えて(これから解放されたのもでかい)... そうなんですよ、iOSってビューを作るのがだるいんですよ。Flutterになって、ビューを作るのが楽しくなった。全部コードで組めるからだと思う。

Flutterが重くなるとすればビルドしまくることなんだろうな... あまり想像できないけど。

リーチ一発Flutterでいけるか？

いけると思う。XCodeで開発したことがなくても、FlutterのWidgetのライフサイクルや、BuildContextの思想などをある程度理解できれば良い。AndroidやiOSのビューのライフサイクルに熟知しないと作れないことはないかな。問題があるとしたら、Flutterでジェネレートしたネイティブのコードに対する修正が必要な場合だけど、よっぽどのことがない限りないと思う...

今後スマホのネイティブアプリを新規に作るとしたら、Flutterが良いですよ。はい。

jqueryでappendした要素に対するイベントが必要なら、onを使おう

当たり前だけど、appendで後からつけた要素にはイベントは付与されない。onloadで指定してそのままだからね。

が、jqueryのon関数を使うことで、動的にイベントをバインドしてくれる。あざーす。

だめなやつ

$('.img_cancel_btn').click(function() {
    $(this).closest("div").remove();
});

ナイスなやつ

$(document).on("click",".img_cancel_btn", function() {
    $(this).closest("div").remove();
});

要件定義はアートなのでは

要件定義が死ぬとシステム開発無理、なので要件定義重要。それはそうなんだけど、上手くやるには人類には難しすぎた。要件定義はアートなのではなかろうか。再現性に乏しく、経験値や個々人のアンテナの感度によって、成果がブレる。それに、クライアントにも左右される。要件定義の支援に入っても、そこで揉める。

真っ白いキャンパスがあって、そこにシステムを使った理想の世界的なものを書くわけだけど、そこにフォーマットや方法論が与えられたとしても、とりあえず何か作ったほうが100倍響くわ。ダラダラとそんなことを思ってたら、「SIやりてぇな〜」って気持ちが強くなってきちゃった。IT企画という翼をさずけたら、プログラミング経験が乏しくても、やっていけるもの。

SIとなると、SaaSじゃだめでPaaSが必要になる。そうなると、中小企業でも担げるのはkintoneしかない。安いし、拡張性高いし、運営は盤石だし、国産だし。あ●としすてむずとか高すぎて無理。サーバー立ててオンプレで入れるみたいなのも、ユーザー目線では重たく見えるだろう。

kintoneはリリース当初はこれは無理だろと思って横目に見ていてたんだけど、昨年から使ってみると「もうこれでいい、80点なら音速で出来る」と確信。それを100点にしようとしたらイニシャル10倍になりますけど、やりますかって。

kintoneでもなんでもそうだけど、辛いのは在庫の引き落としのように、裏でデータ連携をしないといけないロジック。入力値格納以外のロジックの数が多ければ多いほど、複雑になる。入力値格納以外のビジネスロジックが必要な場合、結局そこでトランザクションが入ってプログラミングしなくちゃいけないし、RDBに入れたいならばCDataとか使って、SQLゴリゴリ書けばいいだけだ。

クラウドの時代になってXaaSが増えれば増えるけど、結局SIが必要になる。導入企業の業務課題は千差万別だから、その隙間を埋めるのはSI以外の方法が存在しない。業務系のようなお金をかけたくないがデータが流れる仕組みはちゃんと作りたい領域において、kintoneのようなPaaSを使って、周辺システムはETL/API連携などでうまいこと組み合わせて、プログラミングの楽しさをプログラミング・レスで提供するSIerって、やっべーすげー面白そう。

www.joyzo.co.jp

Facebookで流れてきたけど、2010年から専業ってすごい。その頃はAccess以下のものだったはずなのにね。でも、後追いするSIerがすげー少ない気がする。ネット上では、個人ベースの発信かエバンジェリストというステマの声しか拾えない。多分、使いこなせないんだよね。使い方を体系立てて教えてないから。おれ、それ教えられるしSIもできるんで、そっちやるわ。

この他に実はもう1個挑戦したいものがあって。ECなんだけどね。あー楽しい。事業計画練るぞ〜。