非エンジニア部門とRedmineで情報共有するためのTips
はじめに
こんばんは。 ishturkです。
タスク管理してますか？
弊社では開発部門のタスク管理に Redmine を活用しています。
今回は開発部門だけでなくCS（カスタマーサクセス）部門と一緒にRedmineを使うためのTipsです。
CS部門と開発部門の架け橋として
CS部門では、顧客管理ツールがあるので、Redmineはメインではありません。統合できれば素敵ですが、それはまた別な話。
なので、開発部門と連携する場合は RedmineをCSにも使ってもらっています。
CS ≠ エンジニア
ここで課題になるのが、CS部門はエンジニアでないということです。
リテラシーにばらつきがあるので、
- 大体こういうもんでしょ？
- こうなってるはずだ
みたいな感覚がありません。まぁエンジニアだからといってそうだとは（ry
だれとでも一緒に使えるようにするTips
弊社でうまくいったアイディアをいくつか紹介します
アバターをいれる
見た目がフレンドリーになるのでよいです。見た目でハードルを下げるのはとても大事なことです。
Gravatorに依存したくないので、ローカルアバタープラグインを使ってます。
どこになにを書いたらいいかひと目でわかるように
まずトラッカーを選択して優先度はこれで説明にはこれを書いて。。。。
説明する側もされる側も「うっ」 ってなります。
デフォルト設定
操作回数を減らします。そのために
- 専用のサブプロジェクトをつくる
- 専用のトラッカーをつくる
- プロジェクトのトラッカーをデフォルト設定して、なるべくそれしか使わない
トラッカーってなに？？ になる人が多いので、そもそも触らせないのが良いです。
テンプレートの活用
これがとても便利な機能なのでイチオシ。この記事で一番のおすすめです。
まずプラグインを入れます。
※テンプレートの説明はこのサイトがわかりやすかったです。
Redmineでチケットのテンプレートを設定する | CodeLab
テンプレートを作成します。トラッカーを指定できるので、適用したいトラッカーを選びましょう。先述しましたが、専用のトラッカーが良いです。
専用であれば、ここで、デフォルト値として設定することで、「新しいチケット」を選ぶと、テンプレートを選択するところまで一発で遷移します。
ここでもう一つの役割をもたせます。入力する人へのメッセージを記載します。
たとえば、下のように設定しています。
入力してくれてありがとう！ とか入れておくと良いといいですね。（今思いついたので採用します）
自分で悩ませない
Remineで悩んだらこの人に聞け！というのを強めにインプットしておきます。私がRedmineおじさんです！
- 悩む時間を短くする
- 嵌りどころを教えてもらえるので改善できる
後者がとても重要で、使い慣れているとなかなか気づかない落とし穴にハマってくれるので、なるほど！となるわけです。win-winですね。
終わりに
CS部門とRedmineで情報共有するためのTipsを紹介しました。まだまだ小ネタはあるので、またどこかで紹介したいと思います。
ハッピータスク管理！
おまけ
Photosynthでは一緒にはたらく仲間を募集しています！
ネットスピードをRaspberry PiとGASでメトリクスする
どもー、 id:kazuph1986 です。
この記事はAkerun Advent Calendar 2018の5日目の記事です（そんな気がするのです）。
今日は家のネットスピードがヤバすぎ(遅い)なので、実際にどれくらいの通信速度が出るかを収集してみました。
Setup
今回はこれを使います。環境はRaspberry Piを家の回線に有線接続してます。
CLI上でSpeedTestできる便利なやつです。
インストール
curl -Lo speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py chmod +x speedtest-cli
使い方はとっても簡単で特にオプションを付けずに叩けばOKです。
$ speedtest-cli Retrieving speedtest.net configuration... Testing from Softbank BB (126.199.26.185)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Love4Taylor (Tokyo) [3.36 km]: 50.447 ms Testing download speed................................................................................ Download: 6.70 Mbit/s Testing upload speed................................................................................................ Upload: 4.17 Mbit/s
うん、遅いですね。
以下のようにサーバーを指定して叩くことも可能です。
# 日本のサーバーを選択して… $ speedtest-cli --list | grep "Japan" # 番号を直接指定 $ speedtest-cli --server 15047 # 出力をシンプルにすることもできます $ speedtest-cli --server 15047 --simple Ping: 55.566 ms Download: 14.01 Mbit/s Upload: 4.17 Mbit/s
GasでAPIの作成
スプレッドシートを作成して、スクリプトエディタを開いて以下のように書きました。
function doPost(e){ if (e.parameter.net_speed_ping) { var data = [ new Date(), e.parameter.net_speed_ping, // ms e.parameter.net_speed_download, // mbps e.parameter.net_speed_upload // mbps ]; addData("home metrics net_speed", data); } return ContentService.createTextOutput("ok"); } function addData(sheetName, data){ var sheet = SpreadsheetApp.openById("＜YOUR_SPREADSHEET_ID＞").getSheetByName(sheetName); sheet.appendRow(data) }
このスクリプトのAPIとしての公開方法はこちらを御覧ください。
APIを叩く
Raspberry Pi上に以下のようなスクリプトを置いて叩いています。shellしか使ってないのでお手軽ですね。
#!/bin/bash # Ping: 35.752 ms # Download: 7.37 Mbits/s # Upload: 0.59 Mbits/s echo `date` start speed test speedtest-cli --server 15047 --simple | tee .net_speed.log net_speed_ping=$(cat .net_speed.log | cut -d' ' -f2 | awk 'NR==1') net_speed_download=$(cat .net_speed.log | cut -d' ' -f2 | awk 'NR==2') net_speed_upload=$(cat .net_speed.log | cut -d' ' -f2 | awk 'NR==3') url=https://script.google.com/macros/s/<YOUR_GAS_API_URL>/exec curl $url \ -XPOST \ -d net_speed_ping=$net_speed_ping \ -d net_speed_download=$net_speed_download \ -d net_speed_upload=$net_speed_upload echo `date` end speed test
あとは以下のようなcronを設置すれば完成です。
*/5 * * * * root /home/pi/post_net_speed.sh >> /var/log/syslog 2>&1
5分毎としました。
結果
以下のようにデータが溜まりはじめました。
グラフにするとこんな感じ。6日間くらいのデータです。わかりやすく山と谷が出てます。
ということで結果としては、一番ネットをいじりたい20時〜24時で1〜数Mbps程度に下がり、深夜帯に復活していき朝6時にピークの25Mbpsくらいの速度が出るという感じでした。 これだと朝に早起きして好きなことをした方が良さそうです。
まとめ
Raspberry PiとGASで簡単に家の回線スピードを可視化してみました。
結果的には、「まあみんな使う時間帯は遅くなるよね・・・」という感じで「わかっていた」という気持ちもあるのですが、 妻にこの実態を見せたことで「ネットもっと速くして」という感じで話が進み、現在導入中になってます。
やはり数字で語るのは効果的ですね。
ということで、Nuro契約しました（改善結果はまたどこかで上げます）。
ではでは。
Photosynthでは一緒にはたらく仲間を募集しています！
社内ツールアクセスのためにVPNではなくProxy Serverを構築する
どもー、 id:kazuph1986 です。
この記事はAkerun Advent Calendar 2018の3日目の記事です。
今日はサクッとEC2を利用してProxy Serverを構築した話です。
経緯
弊社では、エンジニアおよびカスタマーサポートのために社内ツールを構築・作成しており、社内外合わせた4, 5個程度を常時使いながら業務を行っています（作業内容がカニバっているものは統合のための開発も行っているので、減ったりもします）。
そしてそのすべてが社内からのIPでなければアクセスできないようになっているので、以前はどうしても社外からのアクセス必要な場合に、個人ごとにVPNの権限を渡していたのですが、そもそも社内ツールにアクセスはしたいが、社内ネットワークにつなぎたいわけではないので、権限を与えすぎという状況が生まれていました。またVPNの権限を渡せるのはある程度入社期間を経ていたり、一定以上のリテラシーがあるとCTOおよび上長から認められた人だけだったので、場合によっては特定の人に対して権限を付与することがずっとできないという状況も生まれていました。
つまりVPN（だけ）では適切な権限管理をすることができないので、融通を利かせることができる認証方式を求めていたわけでした。
解決
そこで、一定以上の強度で認証できかつ簡単な『古き良きProxy Server』を使って認証できる仕組みを構築しました。 これであれば接続毎に社内のネットワークに入る必要もありませんし、人毎に見た履歴がわかったり、見れるサイトも制限できるので、とても便利です。
またこれは今後やる予定ですが、Proxy Serverの全段にさらにAWSのCognitoなども挟むことで、さらに柔軟な権限管理も可能です。 現在はツールごとに個別にアカウント認証機能も開発していたのですが、それももしかしたら統一できるかもしれません。
これは便利。
ということで早速構築してみましょう。
1. EC2を構築する
適当なタイプのインスタンスを作ってください。
2. Squidをインストール
今回は弊社の超Web強いエンジニアのおすすめもありSquidを使ってみました。 最初「よくわからんのでnginxでよくね」って思ったのですが、毛嫌いせずに使ってみたらむしろProxyについてはSquidはすごい簡単だったので正解でした。
ちなみにここで言っているProxyはFoward Proxyです。
構築方法は以下。
sudo yum -y install squid sudo yum -y install httpd-tools systemctl status squid.service sudo systemctl enable squid.service sudo systemctl start squid.service
3. 設定
ファイルは /etc/squid/squid.conf です。
僕はこんな感じで編集しました。ホワイトリスト方式で、社内ツールだけアクセスできるようにしてます。whitelistの中身やmy_teamという単語、http_portは適当に変えてください。
http_access allow password whitelis によって、パスワード認証を通過しかつホワイトリストのURLのときだけアクセスを許可するようにしています。
+ # whitelist + acl whitelist dstdomain "/etc/squid/whitelist" + # auth + auth_param digest program /usr/lib64/squid/digest_file_auth /etc/squid/digest_auth + auth_param digest children 3 + # auth_param digest realm Proxy Web Server + auth_param digest realm my_team + auth_param digest nonce_garbage_interval 5 minutes + auth_param digest nonce_max_duration 30 minutes + auth_param digest nonce_max_count 50 + acl password proxy_auth REQUIRED + # whitelistの場合は以下 + http_access allow password whitelis + http_port <適当なポート番号> # And finally deny all other access to this proxy http_access deny all
/etc/squid/whitelist （グーグルとAWSはあとからアセット系のロードのために追加しました）
.yourapp.com .google.com .amazonaws.com .aws.amazon.com .cloudfront.net .amazonwebservices.com
設定後に再起動してください。
4. ユーザー登録
あとはユーザー登録します。
sudo htdigest /etc/squid/digest_auth my_team kazuph Adding user kazuph in realm my_team New password: Re-type new password:
以上で完了です。
5. logを確認する
sudo tail -f /var/log/squid/access.log
6. (おまけ)ユーザーを一括で登録する
ユーザー登録時にいちいちランダムに生成したパスワードを貼っ付けるのがめんどくさかったので、以下のように自動化しました。
setup
sudo yum install expect
script
proxy_pass.sh
#!/bin/bash digest_gen () { name=$1 pass=$2 expect -c " spawn sudo htdigest /etc/squid/digest_auth my_team $name expect \"New password:\" send \"$pass\n\" expect \"Re-type new password:\" send \"$pass\n\" expect \"$\" " } for name in $(cat list); do echo --START-- echo USERNAME $name pass=$(mkpasswd -l 20 -s 0) echo PASSWORD $pass digest_gen $name $pass echo $name $pass >> pwlist echo --DONE-- done
listは以下のような想定
taro.yamada jiro.sato santaro.suzuki
以上で構築完了です。
まとめ
やってみたら案外簡単だったので、むしろVPNを構築を考えているのであれば一考の価値ありです。 最初検索したらパスワードは平文でしか保存できないと出てきたのですが、んなわけあるかーい！って思ったらちゃんとハッシュ化されたパスワードで保存できました。 自分で一次情報を調べるって大事ですね。
途中で書いたように、今後はCognitoと連携するとめっちゃいい感じに権限管理ができると思うので、それについてもチャレンジしてみます（Elasticsearch構築のときに本当は試したんですけどね）。
ということで、今回はProxy Server構築をする話でした。
ではでは。
Photosynthでは一緒にはたらく仲間を募集しております！
チーム開発でC言語API仕様を共有するメソッド 〜 Doxygenのすすめ
こんばんは。 ishturk です。 この記事は Akerun Advent calendar 2日目の記事です。
Akreun の組み込み開発ではC言語がなかなかの割合を占めています。
過去にモジュール設計の話を
で書きました。どうモジュールを分けるかはとても重要な設計タームです。
背景
さて、モジュールをうまく分割できたらそれぞれ実装します。担当者は複数かもしれません。
この記事では、分けたモジュール間のAPI仕様をチーム間でどう共有したら捗るかの一例をご紹介します。
「API仕様をチーム間でどう共有したら捗るか」です。大事なことなので2回言いました（書きました）
何を解決するか
結論
いきなり結論です
Doxygen形式で公開ヘッダファイルにコメントを記載するのがいろいろな面でシンプルで良いです。
たぶん導入しようとして挫折したPMの方もいるんじゃないでしょうか。。。多分それは、がんばりすぎたのです。
Doxygen の紹介
Doxygen形式ってなんぞや？の方ももちろん多いと思いますのでざっくり解説します。
簡単に言うと
- 記法にそった書き方をするとソースファイル・ヘッダファイルからドキュメントを自動生成してくれるツール
です。具体的には、
- 関数の入力・出力引数と意味を明示できる
- 関数の戻り値の意味を列挙できる
- enumやstructのメンバにコメントできる
他にも
- モジュール間の依存関係を視覚化してくれる
- HTML、Latex、RTF などの形式で出力できる
などなど魅力的な機能もあります。
けっこうアチコチで使われていて、僕らがお世話になっている Nordic さんの SDK API 仕様書も Doxygenで生成されていました。
https://www.nordicsemi.com/DocLib/Content/SDK_Doc/nRF5_SDK/v15-0-0/index
API仕様をチーム間でどう共有したら捗るか
本題です。
ルールを決める
単純なルールを決めます。
他の人（モジュール）から呼ばれる関数には必ず定義のすぐ上にdoxygen形式でコメントを記載する。 使う相手に伝えたいこともdoxygen形式でコメントを記載する。
ルールはこれだけです。
やってみる
僕が推奨する最低限の内容はこんな感じです。
typedef enum { SUCCESS, ///< 成功 PARAM_ERROR, ///< パラメータエラー GENERAL_ERROR, ///< その他のエラー } HogeRet; /** * @brief ほげをdoする * @param a [in] ほげの値 * @param b [out] doした結果を格納するバッファのポインタ * @retval SUCCESS 問題なし * @retval GENREAL_ERROR エラー * @note リエントラント非対応 */ HogeRet hogedo(int a, int*b); void hikoukaifunc(int c);
書き方を解説します。
enum
///< メンバのコメント
enum や struct で説明が必要な場合は書きます。
関数
ちなみに @func（関数名を書くための記法） はコメントを全然ちがう場所に書く場合に使うのですが「必ず定義のすぐ上にdoxygen形式でコメントを記載する。」とルール化すれば不要な記法です。
/**
アスタリスク2つ以上が必須です。 （過去に僕はこれで一晩悩みました）
@brief 関数の説明
関数の説明を書きます。
@param 変数名 [in/out] 説明
型は不要です。変数名から自動で判断してくれます。
@retval 値
返し得る値のリストです。書いてないものは書かない。
@note コメント
こういう使い方しないでね〜という実装ってよくあると思うんです。ここに書く。
Doxygen によるドキュメントの生成
しません （ドヤッ
どういうこと？
ここで強調したいのが 「 API仕様をチーム間でどう共有したら捗るか」（3回目）が目的であることです。
なので、十分目的は達成しています。
doxygen形式で書くことをルール化したことで
- フォーマットを世の中で使われている方法に統一する（オレオレじゃないというのが重要
- 公開ヘッダに必ず残る = ヘッダを見れば仕様がわかる
- ドキュメントを別管理しないので仕様変更しやすい（実装者がdoxygenコメントも直せばOK
という旨味があります。
また、
- API仕様作成時点でヘッダができる ＝ スタブ実装が（ほぼ）不要
といういいこともありました。
なぜドキュメント化しないのか
ドキュメントを自動生成する運用まで設計しようとすると、ステークホルダーが増えるので、スタートしづらいと思います。ここで挫折しちゃうパターンがそこそこあるようで。
自動生成できる（はずな）ソースコードになっていれば、あとから生成することもできるので、まずはソースコードだけで運用してみてはいかがでしょうか。
実装する場合ってgrepしちゃうからドキュメント見ないんですよね。
もちろん、doxygen形式で記載していれば、doxygenコマンドをCIに組み込むだけです。その話はまたどこかで。
おわりに
API仕様をチーム間でどう共有したら捗るか をご紹介しました 。ミスコミュニケーションを撲滅して快適な組み込み開発をしましょう。
おまけ
Photosynthでは一緒にはたらく仲間を募集しております！
大きくなってきたIoTプロダクトのログ活用について 〜Amazon Elasticsearch Service篇〜
ども、id:kazuph1986 です。この記事は、Akerun Advent Calendar 2018の1日目の記事です。
今回は弊社のログの活用をするためにサクッとElasticsearchを導入して業務改善を行った話をします。
背景
弊社では利用関連のデータはすべてDBに保持しており、データをRails consoleやRedashを用いて確認・分析を行っております。
ですが、IoT機器自体のログをすべてDBに含めるのは（負荷・量・金銭コスト的に）無理があったため、そのままサーバーのログとして吐き出しているだけのものもあります。
弊社ではログの収集については、
- リアルタイムにCloudWatchLogsに送信
- 日次でS3に送信
しており、それぞれ
- 短期間の生ログの確認用
- 長期間の保存用
という分け方をしていました。
サポートのために弊社のカスタマーサポート（以下、CS）のメンバーと一緒にエンジニアが調査を行うことも多いのですが、このCloudWatchLogsの方のデータについては、クエリや集計の弱さ、AWS Conosleの権限の中にエンジニア以外が含まれてくる煩雑さ（IAM）等の理由により、そのままではCSメンバーには提供してませんでした。そのためエンジニアが調査作業のたびにCSから依頼を受け、AWSのconsoleを開きログの確認をせざるを得ない状況になっていました。
解決方法
そ・こ・で！どうしようと思っていた時にAWSのCloudwatchLogsがElasticsearchへの吐き出しに標準で対応していると知り、
「もしかして一瞬でできる？？」
と思いやってみたのでした。
結果的に1日くらいの工数で構築できたので、もし似たようなケースであれば、かなりおすすめです。 しかも僕はハマってしまったので1日でしたが、わかっていれば1, 2時間くらいで終わると思います。
はまりポイントは以下でした。最も時間がかかったのが地味に一番上のやつです。AWS力を上げないとなと思いました。
- デフォで生成されるvpc*********.comのURLがPrivate IPのを返却していると気づいてなかった（EC2のような感覚でネットワークパスを通そうとしてしまった）
- 弊社のログがLTSV形式だったのでLambda側のパースの処理でちょっと試行錯誤が必要だった
- Elasticsearch自体のindexの概念の学習コスト
それでは実際にやってみましょう！
1. Elasticsearchのインスタンスを立ち上げる
AWSは「Amazon Elasticsearch Service(以下、ES)」というフルマネージドなサービスを提供しています。 ESの画面に行ったら「新しいドメインの作成」からサクッと作成できます。
次の画面で、ドメイン名とESのバージョンの指定ができます。
次へを押すと、インスタンスタイプ等の設定画面に行きます。最初はt2系で立てたのですが、インスタンスのタイプ毎にストレージ上限が決まっているため、容量が必要になるたびに増やす必要があります。ただ一旦低いので立てておいて、あとからスケールアップするのは簡単だったので、お試しではt2でも問題ないかもしれません。ちなみにt2系はすべて35Gが上限です。
次にネットワーク構成を選択します。ほとんどの場合社内利用だと思いますので、VPCアクセスで問題ないと思います。
次に認証ですが、AWSのCognitoを挟むこともできますし、単にVPCでのアクセス制限もできます。今回は「IAM認証情報を使用した署名リクエストを要求しない」にしました。
これで必須のものを全部選択して、確認画面に行き、「確認」を押すことでインスタンスの生成がはじまります。
2. CloudWatchLogsとの連携
連携は非常に簡単です。ESへのストリーミングを開始を押し、
先程作成したESのクラスタとログの形式を指定します。 右下の「ストリーミングを開始」ボタンを押すと即刻連携がはじまります。
簡単ですね^^
3. (必要なら)Lambdaを編集する
上記まで完了するとLambdaの関数も自動で作成されます。 そうです、実は、連携と言って起きながら、AWSさんはそれを実現するためのLambdaを作成しているだけなのでした。
Lambdaですので、普通のソースを編集できます（JS）。
弊社ではログをLTSVで出力しているため、これをES様に変換するスクリプトに修正します。
100行目くらいにある buildSource を少し修正します。
function buildSource(message, extractedFields) { var log={}; // LTSVとしてパースする message .split(/\t/) .map(function(s) { var res = s.match(/(.+?):(.*?)$/); return [res[1], res[2]]; }).map(function(ary){ log[ary[0]] = ary[1] }); // 必要に応じて方を合わせる // 特にnumber型にしたいが、空となってしまう場合は代替の数字を用意する // ES側でindexの修正でも対応できるが、日次でindexを作り直す場合に戻ってしまうので、 // 出力側で注意する log['time'] = moment.parseZone(log['time'], 'DD:hh:mm:ss').toISOString(); log['size'] === '-' ? -1 : parseInt(log['size']) log['reqtime'] === '-' ? -1.0 : parseFloat(log['reqtime']) return log; ... }
型が合わないとES側で適切に検索・集計ができないので、おそらくここで試行錯誤することになります。 基本的に今回はストリームを想定しているので、過去分を間違って登録してしまった場合は、ES側のデータを全部吹っ飛ばすなどしてやり直しましょう。
逆に過去分を全部集計するような場合は、またS3＋Athenaが向いていると思うので、それは別途書きます。
4. ESのkibanaを見れるようにする
上記までがうまくいっていると、実際にESの方で可視化ができるようになります。 AWSで構築するESには最初からkibanaというビジュアライゼーションツールが入っているので、こちらを利用しましょう（AWSだからというかESについている）。
kibanaのURLもESの管理画面から確認できます。
ですが、冒頭言ったように、普通にこのvpc〜のURLをクリックしても、VPC内のPrivateなIPを返すため、会社などのPCからはそのままでは閲覧できません。 VPCに対してVPNを張るか、プロキシサーバーやLBを追加する必要があります。
弊社では、社内閲覧のために以下の2種類の方法を使っています。
- Route53 + ALBで見えるようにする
- プロキシサーバーを構築して見えるようにする
ALBを利用する方法については、クラスメソッドさんの記事が詳しいです。
本当の意味でPublicにするかは設定次第で、弊社では社内IPからのみ許可するようにALBのセキュリティグループを設定しています。
Route53にてわかりやすいドメインをつけることで、社内での利用がしやすくなっています。
またプロキシサーバーについてはsquidを用いてサクッと構築してます。 こちらについても、プロキシサーバー自体の記事を別日程で書く予定なので、そちらを待ちください。
というわけでこんな感じでKibanaが見れるようになるので、あとはKibanaのビジュアライゼーションツールによって様々なグラフが生成できます。 またAPIも充実しているので、IN/OUTで色々な用途に利用できそうです。
まとめ
DBにないログの情報を活用するためにESを構築する方法を紹介しました。 構築もAWSのUIに則って作業することで、半自動で構築が可能です。 すごい便利ですね。
実は、これをやるにあたり、目黒のAWS Loftにいるソリューションアーキテクトの方に相談に乗ってもらいました。 最初はAthenaでやるつもりで相談したら、ESの方法を紹介してもらい、そこまで便利そうならということで、ESを選択しましたが大正解でした。
こんな感じで、単に質問に答える以上に提案ももらえるのはありがたいことです。 東京にいるならサクッと相談できるLoftの利用は最高に便利です。AWSを利用しているのであれば誰でも入れますので、気軽に行ってみてくださいね！
それでは。
弊社ではデータ分析に興味があるWebエンジニアの方も募集しております。 詳しくを以下を御覧ください。
builderscon tokyo 2018 に登壇してきました
Photosynth 組み込みエンジニアの石井です。ブログの内容により肩書が変わります。
９月６〜８に慶応大学で開催されていた builderscon tokyo 2018 に弊社エンジニア３名登壇してきました。
また、Photosynthはスポンサーとしても関わらせていただいてます。技術大事にする会社ですね（どや
IoT開発の闇
※ 諸事情によりスライドは非公開です。雰囲気は @kazuph のブログ
builderscon tokyo 2018 で前夜祭とDay1のダブルで発表してきました - 僕のYak Shavingは終わらない
でお楽しみください
産業でガチ利用されるRaspberry Piの話
ハードウェアをE2Eテストできないなんて誰が言った？ - IoTのテストを自動化するメソッド 【前半】
ハードウェアをE2Eテストできないなんて誰が言った？ - IoTのテストを自動化するメソッド 【後半】
登壇・参加してみて
私は参加も含めて初めてだったのですが、登壇者、参加者の熱量の凄さにアテられました。みんな（もちろんいい意味で）なまら鼻息荒い。テーマが「知らなかった、を聞く」だけあって、広く深く技術に関わっていく心意気のある方ばかりでした。勉強会やカンファレンスの参加者って10%の能動的な人と90%の受動的な人で構成されていると思ってました（偏見）が、100%が能動的な人。
これだけのイベントで登壇させていただけたのはとてもとても光栄なことです。
主催者や運営スタッフ、スポンサー、参加社の皆様、本当にありがとうございます！また来年も参加します！
あと、ボク個人てきには Winで開発してた時代にめちゃめちゃお世話になった @kaoriya さんにあえたのが感動でした。
おまけ
Akerun Pro とツーショットの写真を撮っていただけたのであげておきます
おわりに
フォトシンスでは一緒にものづくりができるエンジニアを募集してます！！！
