Kick Out the World

技術的なメモとかポエムを書きます。

Scrum Boot Camp OSAKA in June 2018に参加しました

scrumdo-kansai.connpass.com

イベントの大まかな流れ
  1. アイスブレイク・イントロダクション
  2. スクラム概要説明
  3. スクラムイベント(スプリント、プロダクトバックログ作成・見積もり、振り返り)それぞれを体験するワークショップ
  4. QAタイム・クロージング
  5. ビアバッシュ

という流れで朝9:30-夜20:00ぐらいまでの長丁場でした。 本記事では、後述しますが、体験および気づきが重要だと感じたので、個々のワークショップ詳細については、本記事では触れません。

良かったこと
  • 講師陣が実際に現場でスクラムを実践している方々というのもあって、説明の仕方やワークショップのファシリテートも上手いなと感じた
  • ランチやビアバッシュ代込みとは言え、コミュニティイベントとしては少々高額な参加費であったが、参加者も本当にスクラムを学びに来ている人が多く、熱量も大きかった
  • ワークショップを通じて、実際にスクラムイベントを体験できたことが一番大きかった。座学や自分の少ない経験から理解しているつもりではあったが、実際に人を集めチームを組んでやってみると、思いの外上手くいかないこともあり、気付きや学びが多かった。
  • カンバン形式のQAタイムがあり、ビアバッシュまでに全部のQAを解決させる取り組みは良かった。中々聞きたい人が捕まらなかったり、人は酒を飲むとテキトーなことを言いがちなので。
請負とスクラム

QAタイムを通じて、実際に自分がもやもやし感じていたところをぶつけさせてもらった。

明確な成果物を定義できないので、契約としてはふわふわな納品物でOKとする、というか自分の現場もそうしていた。 しかし、受託脳としては、そういった場合に顧客に提供するものとしては人月としての労働量になるのでは、という謎の力が働いていた。 結果として、稼働時間を加味したベロシティや見積もりの算出となっていき、顧客向けの数字イジりにパワーを割く羽目になったし、それなりの見通しの精度を実現できた一方で、開発現場も稼働の呪縛により疲弊もしていた。

人によっては雰囲気伝わっていたし、ピンときてない人もいるという反応であり、こんな悩みに時間を割いてスマンなという気持ちであった。

色々なアドバイスや意見を頂いた結果、POとなる顧客には、スクラムおよび現場の実情に対する理解を得てもらいつつ、現場がシンドくならないような進め方を模索しないといけないな、という納得に落ち着いた。 具体的な解決に落ちてないやん、というツッコミもあるが、現状はスクラムもしていないでの、共感を得てもらったこと、考え方を示してもらっただけでも十分かと思っています。

おわりに

自身が今後スクラム開発に関わる予定は未定だが、改めてスクラムに対する考えが整理でき、また、今の現場にも何かフィードバックができることがないか考えてみようという気持ちになれた。

参加者はソフトウェア開発関係者が多かったようですが、特に開発の知識は必要もなく、開発以外の現場にも十分に適用できることだと思うので、次回開催されていればオススメです。

ビアバッシュ後の懇親会まで楽しむことができ、充実した一日となり、スタッフの方々ありがとうございました。

今回のイベント後以降も困ったことがあれば隔週開催のスクラム道関西オープンジャムに来てくれ、だそうです。

scrumdo-kansai.connpass.com

自分とスクラム開発について

Scrum Boot Camp OSAKA in June 2018に参加しましたブログを書こうと思い、 序章として「自分とスクラム開発」についての振り返りを書こうとしたら、やたら長くなり、イベント参加ブログどこいったんや状態になりそうなので、分離しておく。


続きを読む

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 -dirclean パッケージの削除
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. クロスコンパイルツールチェイン

  • 2種類のツールチェインに分類される
  • 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
    • Buildrootでの推奨
    • 2.6.32から導入された仮想ファイルシステム
    • /devにマウントされ、デバイス追加削除に応じて自動的にデバイスファイルを生成削除する
    • CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNTカーネルコンフィグが必要
  • devtmpfs + mdev
  • devtmpfs + eudev

    • mdevより複雑で柔軟な管理制御ができる
  • initシステムにsystemdを選択するとudevになる

6.3. init システム

System configuration, Init systemから以下3つのInitシステムを選択することができる

  • Busybox
    • Buildrootのデフォルト
    • ベーシックなinitプログラム
    • /etc/inittabを読み込む
    • フォーマットは一般的(symtemV)なものと少し異なるのため、https://git.busybox.net/busybox/tree/examples/inittab を参考にすること
    • 主に行うのは/etc/init.d/rcSgettyの起動
  • 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カードイメージを焼いて起動させるとことまでいった進捗

とりあえずドキュメントを見ながら色々試していくかー、という感じですが、どこまで読んだか忘れしまうで、自分が気になった点をつらつらとメモしていこうと思う。

実際に試してみた結果も差し込むなりしていきたい。

The Buildroot user manual


Chapter 1. はじめに

  • Buildrootは組み込みLinux用環境をビルドするための一連のプロセスを実現するツール
  • 様座なボード向けのデフォルト設定を提供している

Chapter 2. システム要件

  • Linux上で動作するように作られている
  • 実施に必要なパッケージは別途入れてくれ(必要パッケージについては省略

Chapter 3. Buildroot入手

  • 3ヶ月ごとに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に買収された。

Withings is now Nokia

それにともない、Webのダッシュボードアプリをはじめ、スマートフォン用のアプリも「Nokia Health Mate」というアプリに一新した。

が、しかし、今まで使えた機能が使えなくなったりと、評判が悪い。

特定の製品やサービスに頼ってると、今回のような急な買収等により使い勝手が悪くなったり、最悪データが見れなくなるケースもあるので、出来れば生のデータを手元に保持して扱えるようにしておきたい。

そこで、貧者のデータベースであるところでおなじみ??のGoogle Spreadsheet と、それを使って良い感じにデータ可視化をできるGoogle Data Studioを使うことにした。

データの取得

IFTTTのWithingsインテグレーションを使って、これから体重計では測ったデータは、指定したSpreadsheetに追記するようにする。

で、これまで計測したデータだが、Nokia Healthのウェブ版やアプリからのエクスポート方法が見つからないかと思ったが、ググると以下ページのリンクからエクスポートができた

support.health.nokia.com

エクスポートしたzipファイルには数個のcsvファイルが含まれるが、今回はweight.csvをSpreadsheetに取り込んだ。

日付のフォーマットが2017-07-14 15:22:54となっているが、IFFFから通知される日付はJuly 03, 2017 at 07:40AMといった書式となっているので、IFTTTのフォーマットに会うようにTime::Pieceモジュールを使ってサクッと変換をした。

Spreadsheetは、以下のような平凡なフォーマットとなった。

f:id:stc1988:20170717203552p:plain

[余談]iOSヘルスケアのデータエクスポート

iOSのヘルスケアアプリの生データもぶっこ抜きたいなー、と思っていたら、普通に自分のデータ表示のページからデータの書き出しが行える。 書き出し先にiCloudDriveが指定できるのでマジで便利だ。

出力したzipファイルを展開するとxmlファイルが2つ入っていたが少々問題が発生した。

データはXMLだけど、データ構造としての価値はあまり無さそうなので、素直に行単位でGrepするのが手っ取り早い気がする。

Google Data Studioで表示する

新しいレポートを作成し、データソースに先程作成したSpreadsheetを指定する

f:id:stc1988:20170717204514p:plain

Spreadsheetの1列がデータ表示のための1フィールドとして認識されている。

既存のフィールドを利用した追加のフィールドもデータソース側を弄ることなく、数式を書いたりして柔軟に追加ができる。

今回は、

  • 測定回数として、データの件数
  • 体脂肪率として、体脂肪量 / 体重

をフィールドとして追加した。

後は、フィールドを指定しながら、グラフやスコアボードを配置していく。

時系列データは、毎日のデータが無いとガタガタのグラフになるので、「スタイル->欠落データ->線形補間」をしておくとよい。

各データ表示は期間を柔軟に指定ができ、現在と直前の期間の差分もすぐに表示できるので、可視化する作業が気持ちいい。

テンプレートも真似しつつ、以下のような形となった。

f:id:stc1988:20170717205402p:plain

今後はデータソースをもっと増やしていき、自分の状態を測るダッシュボードとして拡充していきたい。

YAPC::Fukuoka 2017 HAKATA行ってきました

前回のKANSAIはスタッフとして参加し、今回は一般参加者として行ってきました。

yapcjapan.org

前日

有給を取り、朝一で新大阪〜博多へ新幹線で移動。

JTBで、ひかり・こだま指定席限定で半値でいけるプランがあったので、安く行けた。

www.jtb.co.jp

マリンワールド

朝一でついてやることもなかったので、駅メモついでにマリンワールドという水族館へ行ってきた。 ちょうど、その日はとても暑かったので涼しく過ごせた。

やはり、ペンギン🐧は可愛い😍 f:id:stc1988:20170709121931j:plain

全然野菜

pepabo.connpass.com

場所や時間を勘違いしながらも汗だくでペパポさんに行くと関西の顔なじみ達と合流した。

songmuさんの「Mackerelのプラグインの容量を削減した話」が良かった。 GO言語はシングルバイナリで配布出来る一方、ファイルサイズにオーバーヘッドができやすいので、バイナリ数が増えると容量的に厳しいという問題に対して、1つのバイナリにして、呼び出し引数で実行されるプログラムを切り替えるという、古き良きBusybox的なアプローチで解決していた。

言われてみれば、あーなるほどだが、発想と言うか引き出しの広さの重要性に気付かされた。

前夜祭

チケットを確保し忘れたので、参加できず。 TLでも前夜祭、懇親会チケット難民が確認できたので、「みんな、チケットお買い求めはお早めに!!」とスタッフ経験者的にも思いました(自戒

よって前夜祭会場隣で🍣を食べて帰りました。

当日

f:id:stc1988:20170709123755j:plain

福岡LINEさん、広い!キレイ!オシャレ!といった感じで、少ないカンファレンス参加経験ながらも一番良い会場だったと思う。 腰痛持ち&飽き性としては、メイン会場が広々してたので、カフェのドリンク片手に立ち見したり、ソファーでゆったり見たりと、終始空間的にリラックスできたのが良かった。

トークの方ですが、最近少しWEBを触り始めた程度のレベルなので、全般的に難しい内容であったが、特にmoznionさんのエラーメッセージの話は面白かった。

YAPC::Fukuoka Hakata 2017にてWeb Application Good Error Messageというタイトルで話してきました - その手の平は尻もつかめるさ

エラーメッセージをレベルに分類しつつ、開発者・利用者に対してどう提示すべきかみたいなこと、今の業務では全く手をつけれていないので、参考にしていきたい。

あとは、同じ関西でPerl入学式のサポーターをしていらっしゃるtomchaさんのトークも素晴らしかった。

tomcha.hatenablog.jp

自分が今こうやってYAPCに参加しているのもPerl入学式に出会い、社外のエンジニアの知り合いも増え、自分の活動範囲が広がっていった結果だと思うので、コミュニティや自ら行動していくことの大切さが染みた。

スペシャルセッションは、福岡のIT企業が集まってディスカッションをしていたが、実際に福岡という街は良い街だという印象も受けるし、技術コミュニティの規模は東京に比べたらまだまだ小さいけど、これから盛り上げていくんだいう勢いが感じられた。

一方で、自分が今働いている関西は、それなりエンジニアの数もいて、素晴らしい人も多いけど、この先はどうなるのか?みたいな不安を感じることがあった。KANSAIでは温故知新というテーマにエンジニアの掘り起こしを狙ったけど、これから先の関西は?みたいな話はなかったので。

クロージングでは、ノベルティに入っていたサイリウムをみんなで振るという謎のイベントがあったが、妙な一体感が生まれた気がしたので趣があった。

懇親会

TLでは見かけるけど、直接お話をしたことがなかった人と話す機会があったりと、YAPC行くたびに顔見知りが増えていくのはよいなーと改めて感じた。 二次会でいったお店では、ラーソーメンなるものが旨く、博多の夜は最高に楽しかった。

f:id:stc1988:20170709131020j:plain

まとめ

全体を通してとても快適にすごくことができ、会場提供のLINE様のホスピタリティやスタッフの方々の尽力のお陰様で、ありがとうございました!!という気持ちでいっぱいです。

次回は、沖縄・恩納村です。 yapcjapan.org

行ければ初沖縄となるので楽しみです!!