261

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

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

gtest/gmockをVisual STudio 2012の環境でC言語で書くための環境構築

Visual Studio 2012でCを書くことになったので、googletest/googlemockの環境を構築した。 基本的なインストールなどはドキュメントにかかれているが、エラーがでて調べたことなどを記載しておく。

プロジェクトのプロパティからプリプロセッサの定義に _VARIADIC_MAX=10 を追加 Visual Studio 2012を使うときはこの対応が必要らしい http://srz-zumix.blogspot.jp/2012/03/visual-studio-11-beta-google-test.html

googletestでC言語を使う方法 extern "C"でincludeするヘッダを囲っておく。 http://futurismo.biz/archives/316

stackoverflowにも書いてあった。

mockの実際の使い方 https://qiita.com/necomeshi/items/f8dae4460bb6d0d7d7e7

ライブラリが古いのかマクロ名とかがちがっている?みたいだけど参考になった。

mrubyの研修に行った話

概要

先日twitterを見てたらこれに参加すると言っていた人がいたのでmrubyは前から興味があったので勢いで参加登録した

www.digitalfukuoka.jp

参加費6000円なのに10000のボードがもらえるというお得な?研修

内容は以下のような感じ

  • mrubyのビルド
  • マイコンボードにmrubyを書き込み
  • Lチカ
  • 温度測定
  • BLEで通信
  • 温度測定した結果をBLEで通信

感想

mrubyがrubyに対して軽量といっても200kbあって、小さいボードだとなかなか大変な模様。ラズパイとかになるともうpythonで いいじゃんとかになってしまう

あとはIotって結局組み込みなんでデータシート命、メカトロの知識が必須!という感じ

個人的にはバイナリにして実行できるところが魅力に見えた。 ruby使いたいけど、インストールするのは大事だなみたいないときに使ったりとか、cで長年やってきたところにmrubyを組み込んで効率化とかiot以外の方が使い勝手が良さそう。

その他

参加登録したのはいいけど、登録完了メール以降音沙汰が無いのは正直困った。ほんとに当日やるの?と不安に思ったものです。 あとアンケートとかも取ってなかった。その辺改善したほうがいいのでは・・