こんにちは。サーバーサイドやっております(@o0h_)です。
マイホームヒーロー、どんどん盛り上がっていきますね・・！この後どうなるでしょう。
コネヒトでは自由なソフトェアへの貢献活動に取り組んでいるメンバーも多いのですが、年末くらいから社内でもソフトウェアの開発を進めるなどしておりました。
そして、やっとこさ「最低限公開できる形にはなったかな〜」というとこまで進んだ次第です。
ということで、本日はそんなOSSのご紹介をしたいと思います。
CakePHP3用の、Sentryプラグインです。
packagist.org
あけましておめでとうございます！からもう2ヵ月が経ちました。
最近はあまり新しい漫画を読んでいなかったのですが、ザ・ファブルに手を出し始めました！
サーバー側開発をやっております金城 (o0h_)です。
弊社ではWebApplicationは主にCakePHPを用いて開発を行っていますが、次期バージョンである3.6のベータ版がリリースされました。(おめでとうございます！🎉)
そんなCakePHP 3.6.0-beta1について、予習をかねて覗いて見たいと思います。
続きを読む
こんにちは！Androidエンジニアの富田です。先日、Connehito Marché #1〜Android市〜という勉強会を開催しましたので、そのLT内容を簡単にですがレポートさせていただきます！今回は、「Androidに関することなら何でも発表してOKです！」というテーマで、みなさんの新鮮なネタ（ナレッジやノウハウ）をおすそ分けしていただきました！
katsutomuさんのおすそ分け！
CDC Testingとは、コンシューマドリブンコントラクトテストと呼ばれています。マイクロサービスのテスト手法の一つでサービス間の連携が壊れていないことをテストできます。ConsumerとProviderという登場人物がいて、ConsumerをAndroidクライアント、Providerをサーバサイドと表現してその実行サンプルのデモがありました。
kikuchyさんのおすそ分け！
Android Lintのバグに遭遇。kotlin.collection.Map#forEachが、java.util.Map#forEachと勘違いされる影響でAndroid Lintに怒られるので、Google Issue Trackerデビューをしてバグを直してもらいました。
futaboooさんのおすそ分け！
本を読んだ後に記録したい！でも読書管理するためのWeb版読書メーターはあるけど、Androidアプリがない...自分でAndroidアプリを作ってGoogle Playストアに公開しました！
tummyさんのおすそ分け！
AACのLiveDataとViewModelがめっちゃいいよ！LiveDataとViewModelの組み合わせについての紹介でした。
Observer#onChangedの引数は、@Nullableから@NonNullになる予定jyeganさんのおすそ分け！
Firebase Cloud Functionsを使ってみたお話。Flamingo社ではエンジニアが二人しかおらず、Firebase Cloud Functionsの利用についての紹介でした。
Yoshihisaさんのおすそ分け！
APIを叩くAndroidアプリではOkHttp、Retrofit、ReactiveX(Rx)を使うとコールバック地獄に陥りやすい。Coroutineを用いてコールバックから脱したい...こんな感じで書きたい！
try { val info = api.getInfo() } catch (e: Exception) { Toast.makeText(this, e.toString(), Toast.LENGTH_LONG).show() }
coroutines-core、coroutines-androidを導入すれば、kotlin.coroutines=enableは不要retrofit2-kotlin-coroutines-experimental-adapterを使うと良い富田のおすそ分け！
Android版ママリのPRレビューの指摘からKotlin改善のヒントをもらい、それを基に初めてKotlinのIssueを投げて受理されました。
コネヒトで初の社外勉強会でしたが、LT（知ってる）枠、オーディエンス（知りたい）枠のご参加のみなさんや運営に協力してくださった方々のおかげで無事開催できました！ありがとうございました！！Connehito Marché はAndroidのテーマだけではなく、いろいろなテーマで継続的に開催していきますので、ご興味があれば立ち寄ってみてください！
CTOの島田(@tatsushim)です。 先日「X-Tech JAWS 【第2回】~9割のX-Techと1割の優しさで切り拓く未来~」に登壇させていただきました。 xtechjaws.doorkeeper.jp 約100名の参加者が集まり、他の方の発表もとても面白かったです！
私の発表資料はこちらにアップロードさせていただきました。
ぜひ以下をご覧いただければと思います。
X-Tech JAWSでは会場アンケートをとっていて、登壇するとその発表に対しての感想をいただけます。
発表者としてフィードバックをいただけるのはとても嬉しい仕組みですね。
以下のようなお声をいただき、とても嬉しかったです！
発表資料でも触れましたが、2018年は「インフラエンジニアの仕事をなくす」をテーマにコンテナ・インフラ技術を「チームで育てる」ものにして自分たちの仕事をなくすところまでやり切りたいと思います。
X-Tech JAWS運営の皆様、会場にお越しいただいた皆様、有難うございました！
以上、島田(@tatsushim)がお送りしました！
おはようございます。こんにちは。こんばんは。
Good morning. Good afternoon. Good evening.
最近毎日Mr.Childrenの「here comes my love」を聴いているサーバーサイドエンジニアの @itosho です。
今日は勉強会のお知らせをさせていただきます。はい、宣伝です。
「なんだ、宣伝か（そっ閉じ）」と思ったそこのあなた！そう、あなたですよ！
取り立てて有益な情報は提供出来ないかもしれませんが、これも何かの縁だと思って最後まで読んでいただけると幸いです。
一言で言うと 2月1日、木曜日、19時から白金高輪にあるコネヒトのオフィスで、Androidの勉強会 を開催します！
勉強会の詳細については、下記のconnpassのページをご覧いただければと思いますが、せっかくなのでここでは、勉強会のタイトルにもある「Connehito Marché」（コネヒトマルシェ）に込めた想いについて、少しお話させていただければと思います。
タイトルにもある通りConnehito Marchéは、みんなの「知りたい」「知ってる」をおすそ分け！をコンセプトにした参加者が主役の勉強会です。
勉強会をマルシェ（市場）に見立てて、新鮮なネタ（ナレッジやノウハウ）を提供したり、仕入れたりしながら、みんなが和気あいあいと交流出来る活気に満ちた勉強会を目指しています。
ですので、基本的にはLT（Lightning Talks）を勉強会のメインコンテンツとし、参加者の方には普段の業務などで得た学びや苦労をみんなに「おすそ分け」していただきたいと考えています。
そして、また「おすそ分け」された人がまた誰かに「おすそ分け」をすることで、コミュニティが循環していけばいいな、なんてことも考えています。
ちなみに元々は、弊社サーバーサイドエンジニアの金城発案の元、チームのナレッジ共有の場として、お昼休みを利用しながら、社内LTという形で行っていたのですが、このたび、もっとたくさんの人と交流したいと考え、オープンな場として開催することになりました。*1
はい、そのテーマに興味がある方でしたら、誰でもOKです！初心者の方も大歓迎ですし、LTの内容も仕事じゃないけど「趣味でこんなことやってます〜」といった内容でも構いません。個人的には、勉強会は話を聴くだけではなく、発表もしたほうが得るものは多いと思っているので、LT枠の方が増えると嬉しいなと思っています。
「こんなの誰でも知ってるだろうし、大したことないだろうなぁ」と思うことでも、あなたの「知ってる」を「知りたい」人は必ずいると思うので、ちょっとでも「LTしてみようかな…」と思った方は、是非LT枠でのご参加をお待ちしています。LT未経験でも全く問題ありません。むしろ、このマルシェをLTの練習に使ってください！*2
とは言え、いきなりLTなんて「怖いよおおお」「無理いいい」って方もいらっしゃると思うので、そういう方は無理せずオーディエンス枠で参加してください。一番寂しいのは人気のないマルシェなので、仕事帰りに「お、やってるやってる」みたいなテンションで、ふらっと気軽に寄っていただければと思います。
いえ、テーマは毎回変えます。まだ未定ですが今後は、iOS、Webのフロントエンド、サーバーサイド（アプリケーションレイヤー）、インフラ領域のテーマでも開催させていただく予定です。頻度も検討中ですが、最低でも四半期に1回くらいのペースでやっていきたいと考えています。
…とここまで読んで「やっぱり有益な情報ねぇじゃねぇか！」と思ったそこのあなた！勉強会当日はきっと有益な情報だらけだと思うので、是非Connehito Marchéへの参加をお待ちしております！
あけましておめでとうございます！
サーバーサイドやってます金城(@o0h)です。
年末年始は毎年恒例の「ヘルシング全巻読み直し」をしていました。カッコいいですね・・
![[まとめ買い] HELLSING（ヤングキングコミックス）](https://images-fe.ssl-images-amazon.com/images/I/61k0jzXRbjL._SL160_.jpg "[まとめ買い] HELLSING（ヤングキングコミックス）")
弊社ではPhanを用いた静的解析を行っております。
今回は、「多分、これが最も1番の最速さでPhanを試す方法になるんじゃないかな？」というお話をいたします。
cf) リファクタリング対象を選ぶ戦略を決めよう - コネヒト開発者ブログ
*1:この記事を書き始めてから見つけたのですが、まさに「コマンドを使う」感覚でPhanを丸ごと実行できる！！というユーザー体験だと思います。すごい。。 → コマンド実行環境としてのDocker // Speaker Deck
本記事はコネヒト Advent Calendar 2017の25日目、つまり、最後のエントリーになります。
メリークリスマス！そして、宮崎あおいさんご結婚おめでとうございます！サーバーサイドエンジニアの @itosho です。
ここまで続いてきたアドベントカレンダーもいよいよフィナーレということで、今日は来年の抱負というかこれからのことを書いてみたいと思います。 あんまり技術的な話は出てこないと思いますが、1mmでも誰かに刺さるといいなぁ…と願いながら書きます。
僕は昔から個人ではなくチームが成長するために何をするべきか、もしくは組織の中で各人が有機的にワークするにはどうすればいいかを考えたり、実践したりするのが好きなのですが、ここ最近、気に入っているキーワードのひとつに「アンチフラジャイル」という言葉があります。
ご存知の方もいるかもしれませんが、最初にアンチフラジャイルという言葉の意味について簡単に説明させていただきます。
そもそも、アンチフラジャイルという言葉自体は技術用語ではなく、著書『ブラック・スワン』で有名なNassim Talebさんが考えた造語です。日本では『反脆弱性』というタイトルで書籍が出版されており、分野としては行動経済学に位置づけられているのですが、他の分野でも有効な考えとして広く注目を集めており、ソフトウェアの世界では、特にマイクロサービスやDevOpsの文脈で使われることが多いようです。
また、アンチフラジャイルを理解するためには、まず、フラジャイル・ロバスト・レジリエンスという言葉を知っておく必要があります。
フラジャイルとは、一回の大きな変化で大きな損を生み出すものとして定義されています。 例えば、杜撰な計画をしたウォーターフォール型の開発は、一度大きなトラブルがあると、大きな手戻り（＝損）が発生してしまうため、フラジャイルであると言えるでしょう。
そう言えば、Every Little Thingさんの歌にも同じタイトル（発音が違うけど）の曲があると思いますが、だいたいそんな感じです。
ロバストとは、フラジャイルの逆で、大きな変化を受けても、大きな損を出さないものとして定義されています。 先程の例で言うと、しっかりと計画を練られたウォーターフォール型の開発はロバストであると言えます。また、職業で言うと、サラリーマンはフラジャイルで医者はロバストに分類されるようです。 ただし、ロバストの欠点として、想定していない突発的な事態には対処出来ないことが挙げられます。
レジリエンスとは、ロバストを更に発展させた考えで、変化に強く、回復力が高いという意味を持ちます。 開発モデルで言うと、アジャイル開発はまさにレジリエンス的な考えを反映したものだと思います。 また、突発的な事態が発生しても、被害を最小限に留められるようにすることもレジリエンス的な考えで、具体的にはサーキットブレイカーの仕組みやBCP対策などがこれに当たります。
そして、お待たせしましたアンチフラジャイルの登場です。アンチフラジャイルの特徴を一言で言うと、アンチフラジャイルは変化に対して、損ではなく利益を生みます。
これまではレジリエンスなシステムであることが良いとされてきましたが、アンチフラジャイルは更にそれを推し進めたのが考えになります。 例えば、これまでは「障害をどう防ぐか」について腐心してきた方が多いと思いますが、「障害は起きる」という前提で動くのが、アンチフラジャイルの基本的な考えになります。
Netflixではいち早くこの概念を導入して、本番環境でわざと障害を起こしたり、Chaos Engineeringの原則を導入したりすることで、変化や障害に対処出来る強いシステムを作り上げることに成功にしています。
失敗から学ぶ、という表現では陳腐過ぎるとは思いますが、アンチフラジャイルは失敗を重ねることで、より強くなっていくものであり、この考え方はソフトウェア工学やアーキテクチャ論に留まらず、もっと会社や組織、チームマネジメント的な分野にも応用出来るのはではないかと僕は考えています。*1
例えば、チームの成長を止めない方法の一つとして、離職率を下げることが挙げられます。これは当然と言えば当然で、チームが成長するには経験や学び（ラーニング）の蓄積が必要だからです。*2
また、チームは一朝一夕には強くならないので、それを向上させるには小さな成功体験を積み重ねる必要があります。そうすることで、チーム力は徐々に強化されていきます。 加えて、各人が組織として有機的に動けるようするために開発プロセスやフローなどのルールを整備することも大切でしょう。
では、本当にそれだけで良いのでしょうか？
もちろん、離職率を下げることは会社としてとても大切なことですし、一度成功した起業家がそうではない起業家よりも次に成功する確率が高い*3というデータがあるように、成功体験を得ることは重要です。 また、組織が急速に大きくなっていくフェーズでは、大なり小なりルールを整備しないと日々の業務が破綻する可能性があります。
しかし、どうしたって、離職者を0にすることは出来ません。*4 幸いにも、現状コネヒトの離職率はかなり低い状態ですが、1年後どうなっているかは分かりません。もしかしたら、iOSエンジニアがある日突然、全員無人島に行ってしまうかもしれません。そうなって欲しくはないですが、その可能性は0ではありません。その時、これまで通り次の日から業務を続けることが出来るでしょうか？
業界にパラダイムシフトが起きて、これまでの常識が通用しなくなった時、今までの成功体験は本当に役に立つのでしょうか？ どんなにルールを整備しても、いずれルールは破られます。何故なら、ルールは破られるために存在するからです。*5 また、ルールの中に生きていると、ルール外のことが起きた時に対処出来なくなったり、ルールの外側にある変化に気付きにくくなったりしてしまう危険性もあります。
目まぐるしく変化するこの不確実な世界で闘うためには従来のレジリエンス的な考え方だけではなく、アンチフラジャイルな考え方をチームに取り入れていくことが、この先を生きのびるためのひとつの方法なのではないかと僕は思います。
とは言え、アンチフラジャイルなチームになることは容易ではありません。 アンチフラジャイルなチームになるためには、前提としてレジリエンスなチームでなければなりませんし、そもそも、レジリエンスなチームに辿り着くにも相当な努力が必要です。
しかし、諦めたらそこで試合終了です。
少しでもアンチフラジャイルに近づくために、最近、僕が意識していることは以下の3つです。
言葉にしてみると、至極当たり前のことばかりかもしれませんが、いきなりスーパーマンにはなれないので、まずは自分に出来ることから地道にはじめていくしかないのかなと思っています。
今回参考にさせていただいたアンチフラジャイルの世界という記事の中にアンチフラジャイルのメタファーとして、ドラゴンボールのサイヤ人が登場するのですが、個人的に秀逸な例えだと思っていて、スーパーサイヤ人が集まったチームが出来たら…と想像するだけでわくわくします…！
繰り返しになりますが、アンチフラジャイルなチームをつくることは容易ではありません。しかし、アンチフラジャイルなチームになろうすること、少なくともその態度を示すことがアンチフラジャイルへ繋がる第一歩なのだと僕は考えています。
ここまでお付き合いいただきありがとうございました。
長文を書き散らした挙句、結論めいたものもなく恐縮ですが、来年はここに書いたことを意識しながら、サービスをもっと大きく出来るよう、より一層頑張っていく所存でございます。 とは言え、頑張り続けるにはエネルギーが必要なので、素敵なメンバーとわいわい働くことでエネルギーをもらいながら、愉しく頑張っていければ最高ですし、その頑張った成果をまた来年のアドベントカレンダーで報告出来ればもっと最高だなと思っています。
それではよいお年を！
めっちゃたくさんお世話になりました。
*1:そもそも、最初にこの概念を利用したと言われる元NetflixのAriel Tseitlinさんもアンチフラジャイルな組織というタイトルの記事を書いています。
*2:ラーニングの蓄積の重要性については、伊藤直也さんの開発組織マネジメントのコツに要点がまとめられています。
*3:DHHさんがいることで有名な37signals（現Basecamp）の書籍である『小さなチーム、大きな仕事――働き方の新スタンダード』の 「失敗から学ぶこと」は過大評価されている の章より引用
*4:出来ることと言えば、せめてネガティブな理由でなくポジティブな理由で去って行くことくらいでしょうか…。
*5:これは極論かもしれませんが、そういう側面もあるかと思います。
