261

IT系のカンファレンスに参加した話などを書いています

CICD TestNightに行ってきた

CICD TestNightに参加した

CICDのハマりポイントとかあるあるとかを聞けることを期待して参加したが、今回はbitriseはいいぞ!という回だった。 CTOが来日してbitriseでこんなこともあんなこともできて、どれもOSSで作っているとのこと。 それと日本のコミュニティを大事にする〜のような話をしていた。多分(翻訳イヤホンは借りられなかったけど大体そのようなはず・・・)

あとはLT大会で、iOSのビルド自動化は手組みは辛いからサービスを使うべき、とか自動化することはたとえbuildだけでも履歴、再現性の意味がある。といった発表があった。

今の案件で自動化は buildしか利用できなさそうで意味あるかなと思っていただけにこの言葉を聞けたのは良かった。 できれば発表であったチャットボットみたいなものを利用したい

技術書典5にいってきた。次は本だしてみたい

最後のほうにちょろっと参加しただけだったけど面白かった。 見たことのない情報に触れられるのがこういうところへ参加する意義だと思う。自作キーボードにちっちゃいハンドスピナーつけてたりとか、法律の話とか ただ、欲しかったメルカリの本は売り切れてた

なので次は自分も本を出したい。紙でなくてもいいみたいなので PDFで。

内容はurlにアドレスを入力してenterキーを押してからbrowserに表示するまでの道筋

実際わかっていないのでは?と思って とりあえず書く内容の概要をざっと書き出してみた

  • ブラウザの url入力フィールドにurlを入力し、 enterを押す!
  • エンターの信号がキーボードからusbをとおして
  • ドライバがenterの値に変換
  • enterの入力がOSからchromeに伝わる(よくわかってなさすぎ)
  • url入力フィールドに入力があることを検知?
  • 入力文字を取得
  • 入力文字をパースする
  • プロトコルを判定(https, httpで判断?)
  • ipなのか文字(なんていうんだっけ->domain名)を判定
  • urlをdnsに問い合わせ
  • 問い合わせまでになにすんだろわからん
    • dnsって下からだっけ?
    • dnsに答えが帰るまで問い合わせ
    • dnsってツリー?
  • パケット作成、ドメイン名を乗せる
  • 名前解決したらipaddressを保持
  • dnsからipに変換し、 ipをパケットに分割
    • ethに送るまでってだれが担当する?OS? Driver?
  • ethを通ってサーバにリクエストを投げる
  • 帰ってきたレスポンスをうける
  • ボディを取得
  • ボディのパース
  • htmlをchromeのパーサに渡す
  • chromeでパーサからごにょる
  • chromeのレンダから出力

まったくわかってないことがわかったので まずはreal world httpを読んでみよう

想定している環境 OS linux ブラウザ chrome

Backlogの運用で行ったこと

Backlogでなるべく課題は担当者が管理してまわせるように しようと思った際に決めたこと

  • WBSに沿って課題を設定する
  • 担当者は設定したら基本的に変更しない
  • レビュワーを決めたらWikiに書いておく
  • 状態遷移の条件を決めたらWikiに書いておく
  • 仕様はWikiに書いておく
  • 子課題の設定は親課題担当者に任せる
  • 状態の変更は課題の担当者に任せる
  • gitのリポジトリは開発用、sandbox, stubを用意した

解説

WBSに沿って課題を設定する

ベースとなる課題はWBSに沿って作成し、 細かい課題は子課題として設定する方針にした。

担当者は設定したら基本的に変更しない

レビューするときにレビュワーを担当者に変更するというようなことはしない  あとは回答してほしいひとに担当者を変更するとかもしない。  ああいうことはチャットツールとか使ってやったほうが  早いと思わないのだろうか・・・・

レビュワーを決めたらWikiに書いておく

 忘れてしまうので

状態遷移の条件を決めたらWikiに書いておく

レビュー依頼したら処理済みに変更するなど  忘れてしまうので

仕様はWikiに書いておく

 忘れてしまうので  wordやらで管理は嫌なのでwikiに書くようにした  課題と紐づけたりできると便利なのになぁ 出来るらしい   https://backlog.com/ja/help/usersguide/markdown/userguide1760/#

子課題の設定は親課題担当者に任せる

 基本的な方針

 そうすることでリーダーが管理しなくて良くなる  

状態の変更は課題の担当者に任せる

 基本的な方針で、

 そうすることでリーダーが管理しなくて良くなる

gitのリポジトリは開発用、sandbox, stubを用意した

 開発用はいいとして、sandboxでアーキテクチャの検討や、gitに慣れていない人用  などの遊び場として用意した  stubはstubを用意する場所がほしかったくらいの理由

開発のスピードを改善するために検討していること

開発でスピードが遅いと感じることがあったときの解決方法を考えた。(実践できるかは別として

その1 資料がPDFやらexcelやらで共有するのをやめる

正直backlog使っているのにpdfとか作ってるより、wikiを作って 情報を共有したほうがいい。 なぜなら最新の資料はどこにあるか問題を解決できるから。 探す時間ほど無駄なものはない 更新した履歴を手で書いたりとかも無駄だし

その2 メールをやめる

メールは無駄の宝庫 まず宛先確認の無駄。 間違った宛先に送ると困るから、何回もチェックすることが無駄

丁寧に書かないと行けないという風潮が無駄 まずお疲れ様ですってみんな書いているけど そんなことを書いているのがそもそも無駄。 ひどいのだと短い文章に短いですが以上です。 なんてことを書いてくる人もいる。

チャットツールを使おう。

その3 進捗管理excelでする

backlog使ってるんだからそこで管理しましょう

まとめ いろいろ書いたけどどれも会社都合で改善できないってのが 多い気がする。 結局偉い人が変えていいよといってくれるの待ちでしかない のが歯がゆいところ

potetotips #50に行って来た

potetotips に行ってみたかったので行って来た。 発表内容が様々で面白い。ゲームをc++で作った話とか。サーバ側のオプションをいい感じに作るツールの話とか

今回はwantedlyさんのオフィスだったようだけど、9時以降の出口がわかりづらかった。たまたまいた参加者とどこですかねーとか言いながら出口を探した。

聞きながらメモってたこと。(敬称略

くぼで

  • diffutil
  • 2つの List の差分を計算するユーティリティー。
  • support library 27.1.0 => ListAdapter

kobayashi

どくぴー

  • 画面のキャプチャ
    • adb
    • logcat
  • R.id.content
  • Viewのキャプチャ
    • view getDrawingCacheでbitmapでとれる
    • ktxをつかってるならtoBitmapでいいぞ
    • mediaprojection API (API21~)

sourcery

  • diの自動生成ツール(swift

いずみん

  • prefarence
  • shared preferenceとか?
  • serverによるものは自前でoptionsってなまえ

西山

  • cinder
    • ゲーム開発フレームワーク
    • これを選んだ理由は学生がググれないところが良いからというのが面白かった。

もりぞー

  • 消費型課金
  • play billing library

wakwak

  • キーボードの切り替え
  • adb shell dumpsys activity top
  • messengerを参考にする
    • toAdjustResize
    • リサイズして表示してくれるやつ
    • toAdjustNothing
      • なんもしないが、高さも変わらなくなる

なかじじゃぱん

  • 同期したmarkdownメモを自作した話
  • 同期は辛み

takasy

  • ディープリンク
  • 通知の処理(activityを起動するとか
  • activityを透明化してfragmentを出す
  • taskStackBuilder

あぼーい

  • webviewのつらみ

発表一覧

https://github.com/potatotips/potatotips/wiki/potatotips-50

資料一覧

資料は全部あがるってわけじゃないのね。

potatotips.connpass.com

AndroidArchitectureComponent#3に行ってきた

AAC(AndroidArchitectureComponent)#3に参加してきました。

AACについて全4回の勉強会です。 応募者が多くて前2回は抽選で外れてました

  • .#1 はLifeCycle
  • .#2 はLiveData
  • .#3 はViewModel <-今ココ
  • .#4 はRoom

gdg-tokyo.connpass.com

何をやったかは資料が公開されているのでそちらを参照で。 正直難しいこと言われたらわからないだろうと思ってたけど基礎的なことをやるということで上がってた質問も

  • FragmentにActivityを割り当てるのはどうするのか
  • オブジェクトが再生成されたものか確認するにはどうするのがよいか

といったもので、恥ずかしながらなんというか、ならkotlinの基礎的なことを聞いてもいいだろと心理的なハードルが下がった。

正直基礎的なこと聞いたらいけないのかと緊張してたけどどうせ知らない人しかいないのだしバンバン質問すればよかった。

次も当たりますように!

DroidKaigi2018にいってきた話

DroidKaigiに今年も行ってきました。

今年からAndroidエンジニアになったので来年は登壇出来るよういろいろ頑張っていこうと思った。

雑感

毎回規模が大きくなっているDroidKaigi今回は1000人超えらしい でも参加した感じだと受付はスムーズだったし各セッションに参加した感じも去年と同じくらいの混み具合としか感じなかったな。

質問は別の場所でとして時間を取るようにしたのは良かったと思う。

翻訳はしてくれないので海外のスピーカーの話を聞きたければ英語が理解できる耳になるしかない。

参加したセッションはこちら

タイムテーブル | DroidKaigi 2018

Day1

Day2

  • Android Studio30分集中超絶技巧100選
  • Surviving a discontinuous world
  • アプリを成長させるためのログ取りとログ解析に必要なこと
  • Dagger2を活用してAndroid SDKの依存関係をクリーンにする
  • Android案件の見積もりに現れる要素、あるいは丁寧に埋設された地雷たち
  • gRPCとProtocol Buffersで作る、一味違う通信周り
  • HTTPS通信の基本からNetwork Security Configurationまで
  • コードで見るFlutterアプリの実装

Day1 まとめ

個人的によかったのは初めてのUnit Test最初行くのを迷ったけど 結局まだテストが書けていないのがやばいと感じて参加。 勢い良く説明されたあとハイ、書いてといわれて答えを見たりしながら書いていると段々わかってきた気になってくる。

MVPの改善話は少し後ろの方にいたらソースコードがまったく見えないのと理解が追いつかなかったから後で読んだり書いたりしようと思う。というかどのセッションもそうやらないのとぽわーっと忘れてしまいそう

Day2 まとめ

超絶技巧100選は本当に見てよかった。そういうのできるのかーっと思ってる間に30分が終わった。 ログ取りの話は聞いてて為になった。使うときがくるかはわからないけれど。。 午後は他も見たいというセッションが多くて困った。Twitterでもそういっている人が多かった。動画公開が待ち遠しい Dagger2の話は別にテストの話ではなかった。gRPCはこれからRESTではない通信周りが実装されることがあるかもと思ってきいてた。扱うサービスによってはgRPCでということも十分ありそうと感じた。NetworkSecurityConfigurationは普通設定しているものなの?? 最後にflutterは個人アプリで使うのもありなのでは??と思ったけど最新バージョンあたりだとビルド出来ないと行っている人がTweeterにいてβまでまってもいいかもなぁという感じ

よもやま

毎回公式アプリにコントリビュートしようとして出来てないけど、まだコントリビュートしたら取り込んでくれそうな気がする https://github.com/DroidKaigi/conference-app-2018/issues