React始めましたよよよー
React始めたので雑にどうやってやっているか書き残しておく。
WebStormいいぞ！！
とりあえずWebStorm入れて書き始めてます。
補完がめっちゃ聞くのですごく助かる。
とりあえずReact Tutorialやってみる
さてさて、Reactやるかーと言ってもどこから始めて良いのかよくわからないので、とりあえずReact Tutorialやってみた。
何も考えずにとにかく書いて動かしてみた。
英語なので解説でよくわからない部分はこっち見た。
あーなんとなくこんな感じかーという印象。とりあえずこれをまず動かしてみるのが良さそう。
React、Virtual DOM、Fluxについて詳しい人の話を聴いてみる
数年前にmozaic.fmで@mizchiがReactやVirtual DOMについて話していたのを思い出したので聴いてみた。
うん、これはとても聴いて良かった。
どこかのドキュメントを頑張って端から読むよりもまずはこれを数回聴いてみる方と良い。
Reactと一緒によく語られるVirtual DOMやFluxについて、何がブレイクスルーでどんな役割のものなのかをさくっと理解できた。
RebuildでもReact、Flux、Reduxについて話されていたので合わせて聴くと良い。
Fluxやってみる
WEB+DB PRESS Vol.87でnaoyaさんがFluxについて書いてたので、それを元にFluxやってみた。
Fluxはアーキテクチャなのでそれを元に色んな実装があるらしいのですが、WEB+DBではFlux実装のFluxxorを使った題材になってます。
データが一方通行へ流れるようにするアーキテクチャが特徴のFluxについてなんとなく理解できた。
また、まずはReactだけで書いて、次にReact + Fluxxorで書くという流れなのも良かった。
さらに自分で簡単な題材を元にReactで書いて、次にReact + Fluxxorという流れをやってみれば慣れる気がする。
まとめ
React面白いなー。Fluxも面白い。Reduxもやってみよう。
書いたものはここに置いてある。
shinobu.apk #3 を7月にやりたいぞ！という気持ちだけ書いておく #shinobuapk
そろそろshinobu.apk #3をやりたくなったので、7月にやりたいぞ！やるぞ！という気持ちだけ書いておく。
@kgmyshin 7月やりたいっすねー
— shinobu.apk (@operandoOS) 2016年6月18日
今までよりもっと雑な感じでやりたい
そう、今までより雑な感じでやりたいです。
おい、人集めるのに雑にやるのか？あぁ？って感じですがいい意味で雑ってことで。
shinobu.apkは雑を極める
— shinobu.apk (@operandoOS) 2016年6月18日
@kgmyshin じゃそれで
— shinobu.apk (@operandoOS) 2016年6月18日
じゃそれで
ちなみに、ちょっと色々次はやりたいこともあり、忍だけにミスドでも用意しようかなーとか。ハイコンテクストですねー。
shinobu.apkでミスドを出すという新しい試みを思いついたぞ。
— shinobu.apk (@operandoOS) 2016年6月18日
とてもハイコンテクストだ。
なんぞや、shinobu.apkとは？
興味あれば以下とか見てください。
まとめ
現場からは以上です。
技術の幅を広げようと思う話
そろそろいい年頃なので技術の幅を広げたいと思っている今日このごろ。
とはいえ、フルスタックになるのかい？？という話ではなく。
漠然と「技術の幅を広げるぞい！！」と意気込んでもきっと何も始まらないので、ちょっと別のアプローチを取ってみた。
技術Stackの幅を広げたい時、例えば自分が入りたいと思っている会社の求人とか見てみてどんな技術を扱ってるのか、どんな技術を持ってる人が欲しいのかというのは調べてみるのはありだと思う。
— shinobu.apk (@operandoOS) 2016年6月17日
会社に技術Stackを合わせろって話ではないけどね。
— shinobu.apk (@operandoOS) 2016年6月17日
あくまで技術Stackの幅を広げたい時の一つのhintにはなる。
というわけで、この会社いいなーとかこのサービスいいなーと思ってる会社の採用情報を見て、どんな技術を持ってる人が欲しいのか、今どんな技術を使っているのか調べてみた。
調べてみると意外とこれは面白いし、技術の幅を広げる際にどの技術を取り組んでみようかなーという一つのヒントになる。
技術の幅を広げないと...と漠然と考えている私と同じような人がいたら、まずはこれを試してほしい。
kyobashi.dex #3で「Gradle PluginとCIと俺」の話をしてきた #kyobashidex
kyobashi.dex #3 で 「Gradle PluginとCIと俺」という話をしてきましたー。
主に最近仕事とかで新規にCI環境の構築をしたりして遊んでて、gradle-slack-pluginを使ったGradle Task + CI + Slackへの通知という仕組みを構築してみた！という話をしてきた。
ちなみに、今回発表した内容はGradleを使う開発ならAndroidじゃなくても仕組みは導入できる。
サーバサイドJava等でGradleを使っている場合でも適用可能だと思う。
Gradle PluginとCIと俺
文字起こしはGithubにも置いてあります。
資料内で紹介していることはだいたい以下のSample Projectにまとまってます。 仕組み自体はCIサービスといくつかのGradle Pluginを組み合わせる感じで実現しているので、Libraryみたいなさっくり導入できるものではありませんが難しくはないです！
めっちゃ雑ではありますがREADMEに同じ環境を構築するまでの手順をざっくり書いておきました。
gradle-slack-plugin + gradle-versions-plugin + CI
発表内でも紹介している中で特に「gradle-slack-plugin + gradle-versions-plugin + CI」という構成が気に入っている。
これで何ができるのかを簡単に言うと「CI上で使っているライブラリの新しいバージョンがあるかどうかをCheckして、その結果をSlackに通知する」って感じ。
以下のような感じでCI上で実行した結果がSlackに通知される。
GithubにあげてるSample Projectを見ればわかるのだが、そんな難しいことはしてない。
Gradle Pluginの設定 + CIの設定 くらいの手順でだいたい構築できる。
自分はTravis CIを使ってるので設定方法はQiita等を調べれば色々見つかるし、Gradle Pluginの設定は使うやつのREADMEを見れはわかる。
Travis CIの設定がだるかったらsecret以外はSample Projectの.travis.ymlをパクってもいい。
これを発展させて、ライブラリを新しいバージョンへ上げるPull RequestなどをCIから自動的にできるようになるとさらに素晴らしいかも。
ちなみに、gradle-slack-pluginはoriginalを自分がforkして魔改造してるやつの方が使いやすいと思うのでオススメ！
可能性は無限大
結局これはgradle-slack-pluginの仕組みを使って、特定のGradle Taskの出力結果をSlackに通知しているだけの話なので、可能性は無限大だ。
例えば以下のようなこともできる。
- dexcount-gradle-pluginでメソッド数カウントして通知する
- gradle-android-apk-size-pluginでapkのサイズ調べて通知する
- gradle-zundokokiyoshi-pluginでズンドコ キ・ヨ・シ！した結果を通知する
色んなGradle PluginのTaskとgradle-slack-pluginを組み合わせるだけなので、構築も簡単、可能性は無限大！という素晴らしい世界だ。
誰かが素晴らしいGradle Pluginを作って、さらに素晴らしい構成を作ってくれることを期待してるし、自分も色んな構成で試行錯誤していく。
結局何が大事なのか
色々構成してCI上で行った結果を自分たちが日々チェックする環境へ通知してあげることはわりと簡単にできる。
その日々チェックするということだ大事だと思ってる。
CIと掛け合わせることで、日々チェックしたいことが自動で通知される仕組みが整うのでいい。
その結果を見て実際に何かをするかどうかは別として、自然な形で自動的に通知され、ふと思った時に確認できるということを大事にしたかったので、今回話したような構成を考えてみた。
まとめ
kyobashi.dexはいいぞ！
Android Nで増えるはずなSystem Serviceを雑に見てみた
Android Mと比較して、Android Nから増えるSystem Serviceを雑に見てみた。
Nと言ってもPreview 2のNなので、もしかしたらさらに増えるかもしれないし、増えないかもしれない。多分減ることはないと思う。
あと、端末の状態によっても取得できるSystem Serviceの一覧が変わってくる？？みたいなことがもしあった場合、この結果は必ずしも正しいとは限らないのでそこら辺すまないね...。
System Serviceの一覧を取得する
System Serviceを洗い出すのはdumpsysを使えば一発。
adb shell dumpsys -l
上のコマンドを実行すれば端末で動いているSystem Serviceの一覧が取得できる。
んじゃ、このコマンドをAndroid Mが入ったNexus 5とAndroid N Preview 2が入ったNexus 5Xに実行し、出力結果を比較してみる。
Android Nで増えるSystem Serviceはこいつら
以下の19個が増えるかもしれないSystem Service。
※ 動いてないSystem Serviceはないはず！という前提で。あったごめんね...
AtCmdFwd android.hardware.fingerprint.IFingerprintDaemon cneservice connectivity_metrics_logger contexthub_service hardware_properties ims inputflinger media.codec media.drm media.extractor network_time_update_service otadexopt persistent_data_block qti.ims.connectionmanagerservice recovery shortcut soundtrigger vendor.qcom.PeripheralManager
それぞれが何を担うSystem Serviceなのかはおいおい調べるとして、まー結構増えるな。
しかもぱっと見で何が何をするのかよくわからないものが多い...。
うーん、Androidが肥大化していって、System Serviceが増え続けることは果たしていいのだろうか...。
System Serviceをどこかのバージョンでいきなり切り捨てるとなると、わりと影響範囲が広いがそろそろ棚卸ししてもいい時期だと思うんだが。
実際にDumpした内容はここのRepositoryに置いた。
追記 というかごめん...
冷静にDiffを眺めてたら「android.hardware.fingerprint.IFingerprintDaemon」とかはNから増えるSystem Serviceじゃなさそう。
比較する対象の端末が違うからHWも違うので、そこら辺でSystem Serviceの違いも出てきそうな予感。
ということで、今度Android Mが入ったNexus 5XとAndroid N Preview2が入ったNexus 5Xでdumpsysの比較をしてみます。
雑に適当な結果を出して申し訳ない！！
