何か着ていればいいよ

ソフトウェア技術者の日常や技術の話を書こうと思います。

『CI/CD Test Night #1』2018/11/7 の参加レポート

ちょっと時間が空いてしまいましたがこちらのイベントへブログ枠で参加しました。 そのレポートです。

testnight.connpass.com

参加目的

CI/CD 関連の知識をアップデートするために参加しました。
自分はJenkinsでのCI環境、CD環境は比較的多く構築してきました（いわゆるJenkinsおじさんでした）がここ数年は業務的に遠ざかっており「自分は浦島状態なはず…。」と思っていました。
特に、マイクロサービス時代のCI/CDって具体的にみんなどうやっているのだろうか？というのを常々思っていて、
そんなおり、connpassの新着で見かけたこのイベントに参加した次第です。

以下講演内容

講演内容と自分の感想です。

Keynote - Bitrise CTO Viktor Benei：

概要

Bitrise というios/android アプリ向けCI/CDのsaas のお話。

CTOと開発者さんという組み合わせで、プロダクトの開発経緯や今の機能について細かく発表してくれました。
自分がサーバーサイドエンジニアということもあってBitriseは初耳だったのですが最近のプロダクトはUIがわかりやすいですね。
もともとの開発経緯が自分たちの問題を解決するために作り始めたものだというのがエンジニア的に良いなぁと思えるポイントでした。

発表内容の感想
  • Bitriseは出自が自分たちの問題解決のためのツールということでアプリ開発者が困りそうなところを細かくサポートしているという印象
  • アプリのCIに関しては色々よしなにやってくれる。オーソドックスな構成でアプリをどんどん出したいようなスタートアップにとっては非常に楽で早く価値を出せそう。個人開発者にも有用に見える
  • チャック・ノリスは鉄板ネタ
  • 日本市場を比較的意識しているらしい。（そんなメリットあるのかな？）
発表内容以外の感想
  • 同時通訳さんすごい
    • でもブログ枠じゃなければ自分でヒアリングしたかった
    • 技術について知っている人かな？スムーズな技術用語の選択ができてすごい
    • Bitriseの二人（ハンガーの方かな？）は丁寧な英語で話してくれてたので好印象（でも、同時はつらいっしょって思った。凄い！）

LT

Hisashi Iguchi：「Bitrise の社内提供へ」

speakerdeck.com

DeNAさんでのBitrise導入経緯を説明してくれました。
自分の感想としては先見の明感がある、導入経緯でGithub EnterpriseとはVPNで連携しているあたりおもしろかったです。

qmihara：「bitcode を有効にしたアプリでも dSYM のアップロードを自動化する」

speakerdeck.com

アプリ開発者のみなさんが面倒だと思っているbitcodeをあれこれする部分をBitriseでいい感じにする話。
（申し訳ないけど、アプリ開発者じゃない自分には何言っているかわからない点が多くてメモが出来なかった・・・。）

otrikun：「ゼロからはじめない方がいい iOSアプリのビルドシステム構築」

[資料がみつかりませんでした。]

iOS アプリのビルドシステムを作った話。
結構つらみのある内容でJenkinsでCI環境を無理くり作った過去の自分の体験も蘇ってきました…。

発表以外の感想

ココらへんで「もしかして、このイベントアプリ開発者向けのものだった？当たり前のようにアプリ開発話をしている・・・。」と思い始める…。

kishikawa katsumi：「Track Everything -すべてをGitHub/Bitriseで追跡可能にする-」

speakerdeck.com

CI/CDを単なる自動化ではなく、追跡可能性という観点で有効活用している話。
とはいえ、色々自動化していてすごい（小並感）

ホリエ：「Workflow、どう組んでいますか？」

speakerdeck.com

"Android Test全書"を書いたよという宣伝でしたｗ
というのは冗談で宣伝もはさみつつ、CI/CD のworkfolow の設計についての話
こういった部分で設計として落とし込むのは新鮮で（試行錯誤しながらワークフローを決めることが多くトライ・エラーの積み重ね結果だと思っていた。）個人的には非常に響くものが有りました。
（アプリ寄りの話が畑違い過ぎて理解できず、追いつかなかっただけという事情もあるかもです…。他の発表者さんすいません。）

miyajan：「サイボウズの CI/CD 事情 ～Jenkins おじさんは CircleCI おじさんにしんかした！～」

www.slideshare.net

Jenkinsおじさんのツラミが「分かるわ～」となる話。
自社の事情と似ていたので、サイボウズさんも同じ感じなんだなーって思いました。（中身ない感想…。）

Ryo Sakaguchi：「Wantedly Peopleのアプリのリリースワークフロー」

speakerdeck.com

リリースワークフローの話。
ココらへんベストプラクティスってどうなんだろう？って個人的に気になる話だったので他社事例は非常に参考になりました。特に「リリースタスクの自動化は進める -> でも全部自動化はしない」というバランス感覚は大事ですよね。「ほんとそれ！」って思いました。

懇親会

お話した方がやはりアプリ側のCI/CDの方で、面白い話を聞けたのですが、やはりアプリとサーバーサイドでは結構違うのだなぁという違いを感じる部分も多く4年ほど前にデスクトップアプリケーションのCI環境を構築していたのが今は昔なのだとまざまざと実感しました。

まとめ

スマホ向けアプリ開発にもCI/CDの波は来ておりosバージョンの差異やios/andoroidの差異という大変な部分をフォローしようというのは以前から引き続きの部分。そんなかBitriseは非常に便利そうで可能性を感じるプロダクトでした。
こういう勉強会に来ると「アプリ作ってみようかなぁ」なんて思ってしまいますね。

最後に、この勉強会のスタッフさんは非常に丁寧に対応いただき感じが良かったです。ありがとうございました。
DeNAさん提供の会場も（来場は３度目でしたが）綺麗でテンション上がりました。

考える作業と考えない作業

ポエム 仕事

通勤中にぼんやり考えたこと

仕事をしていて、"あまり考えず"する作業と"よく考えて"すべき作業があったりします。 それぞれ、どんなものかなーって考えていた内容をつらつらと。

"あまり考えず"する作業

これにあてはまるっぽい作業を羅列してみます。

  • ルーチンワーク系
  • 詳細な指示が出ている作業
  • 議事録などの記録系のドキュメント

"よく考えて" すべき作業

  • 未知の部分のある作業
  • あいまい・ざっくり指示のでている作業
  • 調査系のドキュメント

もっと色々あるかもしれないけど、最近自分がおもっている類型にあてはまる形だとこのようなものらです。

で、自分も含めて人*1はどんな作業も"あまり考えず"する作業として始め、 途中で『あれ？これはまずいぞ。』となったり、後から『あー、ちゃんと考えて進めれば良かった』とあれこれ失敗してその作業を"よく考えて"すべき作業だったのだと学習するわけです。

でも、失敗を生かしているという観点では良いことですが失敗しないならもっと良いのでは？と考えてみると。 なんでも、"よく考えて"する作業として始めるのが良いのではないかな？というのが最近の自分の考え方です。

でも、これやると"よく考えて"進めるので始動が遅くなるんですよね。 で、拙速を求めるような場面では良くないことかもしれません。ただ、それって本当にベンチャーなスタートアップの最初期くらいじゃないのかな？と。 さすがにそういう場面でなんでも"よく考えて"とは出来ないかもしれないけど、大概の場面で"よく考えて"する作業にしておくと、だんだん考えるスピードがあがったり 習慣づいて"よく考えて"する作業が"あまり考えず"する作業とそんなに大差ない始動時間で出来たりしそうだなという感覚にかれこれ10数年仕事をしてきてやっと感じられたりしています。

*1:特に自分にあてはまるのだけど、他にも同じような感じの人をちらほらみかけるのでちょっとだけ範囲を広めてみた

Soft Skills の日本語訳本が出ていた！

キャリア 技術書 プログラマー

僕は昨年、@higeponさんのこの記事

d.hatena.ne.jp

から惹かれて英語版を半年かけて読んだわけですが
やはりその間に翻訳が進んでいたんですねー。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

いやー。いい本なんだけどアメリカ固有の話題も多かったので日本語版ではどうなっているのか気になるし。
どうやらMatzが解説書いてるっていうんで気になる。 でも、日本語版かったら負けな気がするけど、早くも負けそう。 Kindle版が出たらたぶん買います。

PHP BLT #4 に参加しました

PHP 勉強会

今回、まとめブログ枠で参加したこともあり、のエントリーです。

参加理由

正直、PHPの勉強会は今回が初めて。
JavaとRuby、EcmaScriptのコミュニティと同じなのか違うのか、一週間前くらいからワクワクしていました。

発表内容

PHP fukuokaの紹介

speakerdeck.com

ITSの話から入って急展開
ITSのツアー申し込みのPDFまで自動化 => 今後、Fax送信まで自動化したい

BLT

speakerdeck.com

最初何も喋らないので、何事かと思ったらPHPBLTのLine.botで始まりの挨拶から。 んで、詳しいところはよくわからないけどLineBot用のオレオレフレームワークを、某@uzullaさんに影響されて作ったとのこと。
本当に作るところが凄いですね。

wikiについての今昔物語

speakerdeck.com

Wikiは凄いね（例：PukiWiki, MediaWiki）。でも、wiki記法やデザインが残念。
そこで、ババーンと作ったよ！というお話。URIの話とか確かにwikiって先進的だったんだなと思えました。

僕とPHPの4年間

speakerdeck.com

初LTとのことでしたが、そうは思えない安定感で良い話を聞けました。
まとめると、4年に一度オリンピックイヤーに動くWebアプリを若かりし頃に作ったが、今度二度目の稼働日が来たよ。
そして、諸々アップグレードしたら過去の自分からの成長が感じられたという話。
なんだろう、自分の社会人１年目とか４年目とか思い出すと何が違うんだろう？というくらい違う。凄い。

実践DIコンテナ on Laravel

speakerdeck.com

正直、Java界出身でPHP歴半年ほどの自分が一番親近感を感じたのがこの話です。 DIの便利さや使い所はJavaとほとんど同じですね。*1

PSR-7 middle ware

ミドルウェアを自作する話
ちょっと、このエントリーを書いている段階では資料がない状況。 なかなか熱い話で、Javaだとサーブレットコンテナが担う役割の部分な気がしました。
告知： yapcっぽいカンファレンスをやる7.2/3

PHPカンファレンス北海道2016

speakerdeck.com

↑に行ってきた話。
全国PHPカンファレンス スタンプラリーとか楽しそう！

ソーシャルゲームの高負荷とかじゃない地味話。

資料が見当たらず
観葉植物を枯らすところから入る、順調な立ち上がり、からバッチの話へ。
PHPのバッチは自社も多いけど、正直他でもやっているとは意外でした。

PHPカンファレンス北海道に行ってきた

資料が見当たらず
前の方とかぶった・・・。ように見えて結構違う北海道話。

  • おすすめトーク

オンプレミスJenkinsを葬り去った

speakerdeck.com

去年、オンプレミスのJenkins社内に立てたばっかりなんで、「え？」ってなったけど・・・。
内容としてはJenkinsおじさんの老害化の話でした。

憂鬱なSQLのためのあれ

niconare.nicovideo.jp

PHPカンファレンス北海道でcomposerの話しした方
みんなPDO大好き、からの超展開でした。

STREAMで遊ぶ

speakerdeck.com

普段はcomposerの遅さと戦っているとのこと。
PHPのStreamってURIのスキームと密接絡んでいるようで、CやJavaのStreamとは結構概念が違うように思えました。
それ以外は、柔軟な言語はこんなこともできるだという新選感あり。

サービスが成長すると

  • PHPとrails ちょっと、ビール飲みすぎでトイレ行ってました。すいません あまり聞けなかった。

Word物語

資料見あたらず
福岡から来ました、真面目な方のPHPERさん
VAddyのマネージャーさん

  • レポート用Wordを自動生成
    • PHPword

まとめ

PHPの勉強会は初めてだったけど、ノリが結構javajaな感じでビビった。
年齢層は結構高め、なんとかんPHPコミュニティはC++やJavaが辿った道を進んでいるような印象 です。*2 ただ、居心地は良かったのでまた参加したいですね。
あわよくば、LT側の人間として。

*1:そういえばPHP界隈ではAOPとかないのかな?LLはそこは勝手に動的にコード書き換えろよという思想なのだろうか？

*2:良いも悪いも関係なく、なんとなく似てる印象ってだけ

Meguro.es #3に参加しました。

JavaScript 勉強会

こちらの勉強会に参加してきました。
第三回ですが、自分は二回目の参加です。

meguroes.connpass.com

会社から徒歩で目黒駅近辺なら行けるということが分かったのが最初の収穫ですね。
開始時間ギリギリになってしまいましたが、ドリコムさんの綺麗なミーティングスペースはとてもいい雰囲気でした。

なぜ勉強会に参加したのか。

普段、Webアプリケーションを作っている（部署にいる）ソフトウェアエンジニアなのですが、比較的周りのJavaScript熱が低いという印象。
ここは差別化のためにもJavaScript界隈の技術を取り入れて強みにできたら良いなという思いで参加しました。
あと、第一回の時に参加したのですが、いい感じのゆるさが気に入ったのもあります。

参加しての感想

勉強会の中身については、割愛。
思ったことをつらつらと。

jQuery辛い

完全にjQueryはオワコンになってしまっていて、過去の功績は認められつつも技術的負債の責任を押し付けられたかのようにDisの対象になっている。
というのは前回もうっすら感じたのですが、はっきりしてきたと思います。
自分自身、量は多くないもののjQueryの恩恵にはあずかっており悪いフレームワークとは思いませんが、技術の進歩により相対的にデメリットが表面化してきている点については流れの速さを感じてしまいます。

Reactのデファクト感

「Reactはみんなやっているから詳しい説明は省くね」みたいな話が随所にあり、React触ってもいないマンの自分は「え？Reactっていつの間にそんな存在になったんだろう？」というところ。
確かに、AngularとかBackboneとかに比べて目にする機会は多かったかも。
自分のように、情報感度が低い人間はこういう勉強会で人の話を聞いて初めてわかることも多いんだな。

サーバーサイドはRails

特に何も言わなきゃRailsっしょという雰囲気もひしひしと感じて、そういうコンテキストの人たちが集まりやすい勉強会だったんだけど、やっぱりな感あり。

うーん、並べるとここ最近の勉強会では同じような感想を抱いているようなきがする・・・。 今週はPHPの勉強会にも参加するので、文化の違いとか感じられたら楽しいかも。

遅読の自分を許すこと

ポエム 技術書

すべての元凶はこの本

Soft Skills: The Software Developer's Life Manual

Soft Skills: The Software Developer's Life Manual

最初の一章を読んだ段階で、これは凄い本だと。何があっても読み切ってやると心に誓ったのが事の発端でした。
さして、得意でもないのに洋書をこれだけ熱いパッションで読むことになった経緯と自己肯定をちょっと書き残しておきます。

きっかけは@higeponさんのこの記事

d.hatena.ne.jp

そこまで、絶賛なら読んでみようと軽い気持ちでkindle版を購入した行為が、この半年の自分の時間の使い方を左右するとは思いもしませんでした。

そんな"Soft Skills"の読書もかれこれ、去年の10月半ばから半年かけて読んでいていよいよ本文は読み終わり、付録も最終章にさしかかりました。
いやー長かった。
朝晩の通勤時間と昼休みと休日の隙間時間をかなりの割合で読書に割いてるつもりだけど、それで半年なので計り知れない。

じつはこの本を読んで2,3カ月で半分いくかどうかの時に自分の読む遅さにいい加減嫌気がさしていたんですね。
「俺はこの本にどれだけ人生の貴重な時間を費やしているんだ？」とか、技術ブログや技術書を紹介している記事を読んだりして
「この人若いのにこんなに本読んでるよ！それに比べて俺何なの？」みたいな焦りというか自分が読んでいる本そのものではない本質的ではないところでのよく分からないモチベーション低下に悩まされていたわけです。

でも、読んでよかったなと肯定的に今は思っています。
もちろん内容が良い本だったからという部分もありますが、比較的平易な英語で書かれているとはいえ技術者向けの洋書を読み切るというのは自分にとって初めてでとても自信になりました。
確かに、日本語の簡単な技術書を選べばこの期間で４，５冊読めたかもしれません*1
正直、アウトプットもおろそかになっていました。*2

でも、読んでよかった。読み切った。（まだ数ページのこってるけど）
時期も中途半端だけど、そんなことは関係ありません。というあふれんばかりのポジティブシンキンッでとりあえず終わっておこうと思います。*3

*1:それでも、読んでる人から比べれば少ないかな？

*2:この本にアウトプットすべしって書いてあるにもかかわらず

*3:この辺も本の影響

データベース設計時の正規化について忘れがちだけど大事なこと

ポエム 開発

これはDB設計ポエムです。
以下読むならポエムと割り切って斜め読み推奨です。

自分はこれまでDB設計を多少は経験してきました。
他人の設計を引き継いで追加設計:8割 新規に自分で設計:2割 というような割合で。

他人の設計にはほれぼれするようなものもあったけど、ほとんどは
「このクソ塊をどうしろというのだ…。」と嘆きながら引き継ぐという事態に陥っていました。
多分自分のDB設計を引き継いだ人も僕の設計を"f**k!"とか罵っていることでしょう。*1

で、そんなアンチパターンにまみれた仕事をこなす中で、これは気をつけたほうが良いなと気付いたこと。
よくあるDB設計に関する問題というか事前に共有しておくとよい前提を幾つか。

正規化はしろ！

最低限、第三正規形になっている必要がある。これは絶対！
ここが崩れていることも多いので本当に萎えるのだけどここは本当に出発点にしてボーダーラインだと思いますよマジで。

正規化崩しするなら理由・目的を必ず残す

ボイスコッド正規形から第三正規形へとパフォーマンス要件などのために正規化崩しすること*2とか稀によくあると思います。
でも、それには必ず厳密な正規化をしていない理由・目的の文書化とセットで残す。これも絶対！
でないと、DBのバージョンアップや他テーブルの変更で意味なくなった正規化崩しとかが無駄に残ります*3。
元々は色々理由があって、妥当なバランスだったものが「それって単に設計がクソなだけですよね」って感じに負債化してしまったりします。

正規化崩しするならKVSの利用を検討する

だいたい今の時代、正規化を崩してまでパフォーマンス要件をあげようとという場合、KVSを利用したほうがよほど効果が高い場合がある。

経緯をどうやって残すか？

DB定義書が良いと思います。
もっと具体的に言うとDB定義書の各テーブルの定義を書く所に"備考"的な欄を用意してそこに書く。
そうすれば、設計変更する際には必ず編集するし目にとまるはず。

というのをふと思い出したので書いてみました。
なんというか、同じ地雷を踏まないための覚書みたいなポエムでした。（おわり）

*1:歴史的経緯や諸々の都合。フリーハンドで設計できるわけでもなく、決して褒められた設計をしていない自覚はありました。

*2:具体例どうよ？って言われると自分が設計の主導している限りは正規化崩さないほうに倒すのがほとんどなので思い浮かばないけど…。

*3:このパターンでかなり困った。前任者がいないと本当にロストテクノロジーでブラックボックス負債となってやってられない