Scrum Boot Camp OSAKA in June 2018に参加しました
イベントの大まかな流れ
- アイスブレイク・イントロダクション
- スクラム概要説明
- スクラムイベント(スプリント、プロダクトバックログ作成・見積もり、振り返り)それぞれを体験するワークショップ
- QAタイム・クロージング
- ビアバッシュ
という流れで朝9:30-夜20:00ぐらいまでの長丁場でした。 本記事では、後述しますが、体験および気づきが重要だと感じたので、個々のワークショップ詳細については、本記事では触れません。
良かったこと
- 講師陣が実際に現場でスクラムを実践している方々というのもあって、説明の仕方やワークショップのファシリテートも上手いなと感じた
- ランチやビアバッシュ代込みとは言え、コミュニティイベントとしては少々高額な参加費であったが、参加者も本当にスクラムを学びに来ている人が多く、熱量も大きかった
- ワークショップを通じて、実際にスクラムイベントを体験できたことが一番大きかった。座学や自分の少ない経験から理解しているつもりではあったが、実際に人を集めチームを組んでやってみると、思いの外上手くいかないこともあり、気付きや学びが多かった。
- カンバン形式のQAタイムがあり、ビアバッシュまでに全部のQAを解決させる取り組みは良かった。中々聞きたい人が捕まらなかったり、人は酒を飲むとテキトーなことを言いがちなので。
請負とスクラム
QAタイムを通じて、実際に自分がもやもやし感じていたところをぶつけさせてもらった。
明確な成果物を定義できないので、契約としてはふわふわな納品物でOKとする、というか自分の現場もそうしていた。 しかし、受託脳としては、そういった場合に顧客に提供するものとしては人月としての労働量になるのでは、という謎の力が働いていた。 結果として、稼働時間を加味したベロシティや見積もりの算出となっていき、顧客向けの数字イジりにパワーを割く羽目になったし、それなりの見通しの精度を実現できた一方で、開発現場も稼働の呪縛により疲弊もしていた。
人によっては雰囲気伝わっていたし、ピンときてない人もいるという反応であり、こんな悩みに時間を割いてスマンなという気持ちであった。
色々なアドバイスや意見を頂いた結果、POとなる顧客には、スクラムおよび現場の実情に対する理解を得てもらいつつ、現場がシンドくならないような進め方を模索しないといけないな、という納得に落ち着いた。 具体的な解決に落ちてないやん、というツッコミもあるが、現状はスクラムもしていないでの、共感を得てもらったこと、考え方を示してもらっただけでも十分かと思っています。
おわりに
自身が今後スクラム開発に関わる予定は未定だが、改めてスクラムに対する考えが整理でき、また、今の現場にも何かフィードバックができることがないか考えてみようという気持ちになれた。
参加者はソフトウェア開発関係者が多かったようですが、特に開発の知識は必要もなく、開発以外の現場にも十分に適用できることだと思うので、次回開催されていればオススメです。
ビアバッシュ後の懇親会まで楽しむことができ、充実した一日となり、スタッフの方々ありがとうございました。
今回のイベント後以降も困ったことがあれば隔週開催のスクラム道関西オープンジャムに来てくれ、だそうです。
Buildrootのドキュメント斜め読み Chaper8
Chapter 8. Buildrootの使い方
8.1 make tips
他章のものを記載する
| コマンド | 内容 |
|---|---|
| make help | サブコマンド(target)を表示する |
| make V=1 |
makeで実行されるコマンドの表示 |
| make list-defconfigs | 各ボード用に利用可能なmenuconfigを表示する |
| make clean | 対象アーキテクチャやツールチェイン変更時に使用する |
| make ckean all | 再フルビルド実施 |
| make manual | docs/manualに生成されるマニュアルの生成 |
| make manual-clean | マニュアルのクリア |
| make distclean | ターゲットのクリア |
| make |
パッケージの削除 |
| make source | dlフォルダ配下からオフラインビルドする |
| make O= |
outputフォルダを指定する |
| make graph-depends | 依存関係のグラフを生成する |
8.2 フルビルドし直すタイミング
下記でも必ず必要ではないユーザが適宜判断し実行する * アーキテクチャが変わったとき * ツールチェイン設定変更 * 依存するライブラリ追加する * パッケージのサブオプション変更時 * RFSのスケルトン変更時
8.3 パッケージの再ビルドについて
- パッケージの削除は再フルビルドするしかない
- stagingとか関連する場合
- 単体で削除可能なら
output/buildから削除するかmake <package>-dircleanでもよい output/build/<package>-<version>/配下にビルド状態を管理するスタンプファイルstamp_<step-name>を生成する
8.4. Offline builds
8.5. Building out-of-tree
(makeのサブコマンドのであるため省略)
8.6. 環境変数
(関連する項目で見るため省略)
8.7. 効果的なファイルシステムの扱い方
sparseファイルについて(よくわからん)
8.8. パッケージの依存関係をグラフ化する
*make graph-depends
* output/graphs/graph-depends.pdfに生成される
* Graphvizを入れる必要がある
* apt install graphviz
* システムがでかくなると見づらいのでmake <pkg>-graph-dependsでパッケージ単位で出力するともできる
* PDF以外のフォーマットでも出力可能
* BR2_GRAPH_OUT=svg make graph-depends
* BR2_GRAPH_DEPS_OPTS環境変数で制御を変更可能
ビルド時間のグラフ化
- どのパッケージのビルドに時間がかかっているかを可視化することができる
make graph-build- python-matplotlibを入れる必要がある
- 数種類のファイルが生成される
- build.hist-build.pdf
- 各パッケージごとにかかった時間がビルド実行順にヒストグラムになる
- build.hist-duration.pdf
- ビルド時間がかかった順のヒストグラフ
- build.hist-name.pdf
- ファイル名順のヒストグラフ
- build.pie-packages.pdf
- ビルド時間の円グラフ
- build.pie-steps.pdf
- ビルド行程ごとの円グラフ
- 出力フォーマットは変えれる
BR2_GRAPH_OUT=png make graph-build
8.10. パッケージごとのファイルシステムサイズのグラフ化
- 各パッケージのファイルがRFS中に占める割合をグラフ化
- 生成される
file-size-stats.csvを利用して、ビルドごとの比較をすることができる **utils/size-stats-compare -h
8.11. Eclipseインテグレーション
使わないので省略
8.12. 応用
8.12.1. ツールチェインをBuildRoot外で使う
output/host/bin/をPATHに追加するなりする
8.12.2. Buildrootでgdbを使う
設定でgdbserverを有効にするなりすれば使える
8.12.3. Buildrootでccacheを使う
省略
8.12.4. ダウンロードしたパッケージの配置先
BR2_DL_DIRで指定できる
8.12.5. パッケージ単位でのmakeサブコマンド
make <package>-<target>
8.12.6. Using Buildroot during development
<pkg>_OVERRIDE_SRCDIRでパッケージに対してファイルを追加できる
調査はだいぶ前に終わってたけど、しばらく体調を崩していてかけなかった
ここまでの情報でだいたいBuildrootにおけるシステム構築方法を確認することができ、以降はBuildroot自身に変更を加えて独自パッケージ追加するといったこととなるので、ドキュメント斜め読みとしてはここまでかな。
Buildrootのドキュメント斜め読み Chaper6~7
Chapter 6. Buildroot 設定
- 設定の詳細は
make *confing内で確認できる
6.1. クロスコンパイルツールチェイン
- ２種類のツールチェインに分類される
- Buildroot toolchain
- ツールチェインからビルドする
- pros:Buildrootとの連携が柔軟
- cons:設定を変更するとフルビルドが必要
- External toolchain
- Linaroなどのベンダーのツールチェインを利用する
- pros:有る程度信頼性があり、ビルド時間も短くなる
- cons:不具合があるとベンダー依存になる
6.2. /dev 管理
configuration, /dev management で/devの構成を変更できる
- 静的なDeviceTableファイル
- 古典的な方法
- デバイスファイルを予め生成したものを/devに配置しておく
BR2_ROOTFS_STATIC_DEVICE_TABLEにDeviceTableファイルを指定できる
- devtmpfs
- devtmpfs + mdev
devtmpfs + eudev
- mdevより複雑で柔軟な管理制御ができる
initシステムにsystemdを選択するとudevになる
6.3. init システム
System configuration, Init systemから以下３つのInitシステムを選択することができる
- Busybox
- Buildrootのデフォルト
- ベーシックなinitプログラム
/etc/inittabを読み込む- フォーマットは一般的(symtemV)なものと少し異なるのため、https://git.busybox.net/busybox/tree/examples/inittab を参考にすること
- 主に行うのは
/etc/init.d/rcSやgettyの起動
- systemV
- 多くのデスクトップLinuxで使用されてきた伝統的なinitプログラム
/etc/inittabを読み込む
- systemd
- 次世代のinitプログラム
- より複雑な制御ができる
Chapter 7. 他コンポーネントの設定
- busyboxやLinuxKernelなどの設定ファイルがある場合は
BR2_PACKAGE_BUSYBOX_CONFIG.やBR2_LINUX_KERNEL_USE_CUSTOM_CONFIGといったパラメータに指定することができる- 指定しなければデフォルトの設定が適用される
- 設定は
make busybox-menuconfigとかで変更できる
現状は軽量な組み込み最小構成のLinuxシステムを想定した起動や/dev管理となってるような雰囲気。
ぼちぼちLinuxの知識が必要だったのと次章はmakeコマンドtipsが多いのでここまで。
Buildrootのドキュメント斜め読み Chaper1~5
Rapi上でカスタマイズしたLinux動かしたい気持ちがあったけど、自前でカーネルビルドからRootfs作成までやるのが面倒だと思って中々手をつけれていなかったのですが、Buildrootなるツールがあったので、それを試している最中。
Buildroot - Making Embedded Linux Easy
現状、ドキュメント通りにRaspi3向けのSDカードイメージを焼いて起動させるとことまでいった進捗
buildeootイメージのラズパイ3と昨日届いたタッチディスプレイがつながったので、週末の準備は終了。
— STC (@stc1988) 2017年9月13日
ぅてか、初期設定のビルドのイメージだと5秒でログインまで行くな。軽い〜〜 pic.twitter.com/RSAIX7BrdF
とりあえずドキュメントを見ながら色々試していくかー、という感じですが、どこまで読んだか忘れしまうで、自分が気になった点をつらつらとメモしていこうと思う。
実際に試してみた結果も差し込むなりしていきたい。
Chapter 1. はじめに
- Buildrootは組み込みLinux用環境をビルドするための一連のプロセスを実現するツール
- 様座なボード向けのデフォルト設定を提供している
Chapter 2. システム要件
- Linux上で動作するように作られている
- 実施に必要なパッケージは別途入れてくれ(必要パッケージについては省略
Chapter 3. Buildroot入手
- ３ヶ月ごとにtarball形式でリリースされる(http://buildroot.org/downloads/
- 最新リリースでのBuildroot環境を生成するためのVagrantFileを使用すると便利
実際にvagrantで環境構築したので、依存パッケージとかも何も考えずに先工程を実施できた
Chapter 4. クイックスタート
- 通常ユーザ権限で実行できる(sudo不要
- 最初にコンフィグレーションをするためのツールがいくつのインターフェイスで提供されている
**
make menuconfigなどをBuildrootのディレクトリで実行 - コンフィグ情報は
.configファイルに生成される makeでビルド実行make -jNは使用しないこと。代わりにBR2_JLEVEL optionを使用する。- ビルド結果は
outputディレクトリ配下に生成される
Chapter 5. コミュニティ
- (省略)
今回は触りの部分まで。 ここからはは起動周りの話やmakeコマンドの使い方、開発者向けの独自パッケージ追加？など。
Google Data Studioで体重測定結果をいい感じに可視化する
ことのキッカケ
今まで使っていたWifi対応体重計を販売していたWithingsがNokiaに買収された。
それにともない、Webのダッシュボードアプリをはじめ、スマートフォン用のアプリも「Nokia Health Mate」というアプリに一新した。
が、しかし、今まで使えた機能が使えなくなったりと、評判が悪い。
特定の製品やサービスに頼ってると、今回のような急な買収等により使い勝手が悪くなったり、最悪データが見れなくなるケースもあるので、出来れば生のデータを手元に保持して扱えるようにしておきたい。
そこで、貧者のデータベースであるところでおなじみ??のGoogle Spreadsheet と、それを使って良い感じにデータ可視化をできるGoogle Data Studioを使うことにした。
データの取得
IFTTTのWithingsインテグレーションを使って、これから体重計では測ったデータは、指定したSpreadsheetに追記するようにする。
で、これまで計測したデータだが、Nokia Healthのウェブ版やアプリからのエクスポート方法が見つからないかと思ったが、ググると以下ページのリンクからエクスポートができた
エクスポートしたzipファイルには数個のcsvファイルが含まれるが、今回はweight.csvをSpreadsheetに取り込んだ。
日付のフォーマットが2017-07-14 15:22:54となっているが、IFFFから通知される日付はJuly 03, 2017 at 07:40AMといった書式となっているので、IFTTTのフォーマットに会うようにTime::Pieceモジュールを使ってサクッと変換をした。
Spreadsheetは、以下のような平凡なフォーマットとなった。
[余談]iOSヘルスケアのデータエクスポート
iOSのヘルスケアアプリの生データもぶっこ抜きたいなー、と思っていたら、普通に自分のデータ表示のページからデータの書き出しが行える。 書き出し先にiCloudDriveが指定できるのでマジで便利だ。
出力したzipファイルを展開するとxmlファイルが２つ入っていたが少々問題が発生した。
iPhoneのヘルスケアで取得している歩数やらのデータをPC上に持っていきたいが、書き出ししても全然データ入ってないやん
— STC (@stc1988) 2017年7月12日
IOS10.3 ヘルスケアデータを書き出す、でデータが取り出せない | 公式 Apple サポートコミュニティ https://t.co/NxiW8rfrOA 設定言語の問題らしく、英語に変更して書き出したらいけた。
— STC (@stc1988) 2017年7月12日
90MBほどのXMLファイルをどうやって処理するか。
— STC (@stc1988) 2017年7月12日
データはXMLだけど、データ構造としての価値はあまり無さそうなので、素直に行単位でGrepするのが手っ取り早い気がする。
Google Data Studioで表示する
新しいレポートを作成し、データソースに先程作成したSpreadsheetを指定する
Spreadsheetの１列がデータ表示のための１フィールドとして認識されている。
既存のフィールドを利用した追加のフィールドもデータソース側を弄ることなく、数式を書いたりして柔軟に追加ができる。
今回は、
- 測定回数として、
データの件数 - 体脂肪率として、
体脂肪量 / 体重
をフィールドとして追加した。
後は、フィールドを指定しながら、グラフやスコアボードを配置していく。
時系列データは、毎日のデータが無いとガタガタのグラフになるので、「スタイル->欠落データ->線形補間」をしておくとよい。
各データ表示は期間を柔軟に指定ができ、現在と直前の期間の差分もすぐに表示できるので、可視化する作業が気持ちいい。
テンプレートも真似しつつ、以下のような形となった。
今後はデータソースをもっと増やしていき、自分の状態を測るダッシュボードとして拡充していきたい。
YAPC::Fukuoka 2017 HAKATA行ってきました
前回のKANSAIはスタッフとして参加し、今回は一般参加者として行ってきました。
前日
有給を取り、朝一で新大阪〜博多へ新幹線で移動。
JTBで、ひかり・こだま指定席限定で半値でいけるプランがあったので、安く行けた。
マリンワールド
朝一でついてやることもなかったので、駅メモついでにマリンワールドという水族館へ行ってきた。 ちょうど、その日はとても暑かったので涼しく過ごせた。
イルカが空を飛んでいる。 pic.twitter.com/3PiPruE9yH
— STC (@stc1988) 2017年6月30日
やはり、ペンギン🐧は可愛い😍
全然野菜
場所や時間を勘違いしながらも汗だくでペパポさんに行くと関西の顔なじみ達と合流した。
songmuさんの「Mackerelのプラグインの容量を削減した話」が良かった。 GO言語はシングルバイナリで配布出来る一方、ファイルサイズにオーバーヘッドができやすいので、バイナリ数が増えると容量的に厳しいという問題に対して、１つのバイナリにして、呼び出し引数で実行されるプログラムを切り替えるという、古き良きBusybox的なアプローチで解決していた。
言われてみれば、あーなるほどだが、発想と言うか引き出しの広さの重要性に気付かされた。
前夜祭
チケットを確保し忘れたので、参加できず。 TLでも前夜祭、懇親会チケット難民が確認できたので、「みんな、チケットお買い求めはお早めに！！」とスタッフ経験者的にも思いました（自戒
よって前夜祭会場隣で🍣を食べて帰りました。
I'm at 立食いすし屋の魚 x 3 in Chuo-Ku, Fukuoka, Fukuoka https://t.co/9D5rmPnfZm
— STC (@stc1988) 2017年6月30日
当日
福岡LINEさん、広い！キレイ！オシャレ！といった感じで、少ないカンファレンス参加経験ながらも一番良い会場だったと思う。 腰痛持ち＆飽き性としては、メイン会場が広々してたので、カフェのドリンク片手に立ち見したり、ソファーでゆったり見たりと、終始空間的にリラックスできたのが良かった。
トークの方ですが、最近少しWEBを触り始めた程度のレベルなので、全般的に難しい内容であったが、特にmoznionさんのエラーメッセージの話は面白かった。
YAPC::Fukuoka Hakata 2017にてWeb Application Good Error Messageというタイトルで話してきました - その手の平は尻もつかめるさ
エラーメッセージをレベルに分類しつつ、開発者・利用者に対してどう提示すべきかみたいなこと、今の業務では全く手をつけれていないので、参考にしていきたい。
あとは、同じ関西でPerl入学式のサポーターをしていらっしゃるtomchaさんのトークも素晴らしかった。
自分が今こうやってYAPCに参加しているのもPerl入学式に出会い、社外のエンジニアの知り合いも増え、自分の活動範囲が広がっていった結果だと思うので、コミュニティや自ら行動していくことの大切さが染みた。
スペシャルセッションは、福岡のIT企業が集まってディスカッションをしていたが、実際に福岡という街は良い街だという印象も受けるし、技術コミュニティの規模は東京に比べたらまだまだ小さいけど、これから盛り上げていくんだいう勢いが感じられた。
一方で、自分が今働いている関西は、それなりエンジニアの数もいて、素晴らしい人も多いけど、この先はどうなるのか？みたいな不安を感じることがあった。KANSAIでは温故知新というテーマにエンジニアの掘り起こしを狙ったけど、これから先の関西は？みたいな話はなかったので。
クロージングでは、ノベルティに入っていたサイリウムをみんなで振るという謎のイベントがあったが、妙な一体感が生まれた気がしたので趣があった。
懇親会
TLでは見かけるけど、直接お話をしたことがなかった人と話す機会があったりと、YAPC行くたびに顔見知りが増えていくのはよいなーと改めて感じた。 二次会でいったお店では、ラーソーメンなるものが旨く、博多の夜は最高に楽しかった。
まとめ
全体を通してとても快適にすごくことができ、会場提供のLINE様のホスピタリティやスタッフの方々の尽力のお陰様で、ありがとうございました！！という気持ちでいっぱいです。
次回は、沖縄・恩納村です。 yapcjapan.org
行ければ初沖縄となるので楽しみです！！