_ tDiary 5.0.13 にアップデートした。

29の日を迎えていたので、tDiaryがリリースされており、早速バージョンアップしてみた。
今回はじめにリリースされた5.0.12には、assetsパイプラインの変更があり、それに絡んだ致命的なバグがあり、CSSやJSなどにアクセスすると500エラーになってしまった。

• support extentions (cf.tdiary-contrib) assets paths again by tdtds · Pull Request #767 · tdiary/tdiary-core

で、それが治ったというので、アップデートした。

近況

今年に入ってからはてなダイアリーで書くようになってしまったので、こっちには何も書いてない。
捨てる気にはならないし、どう使い分けていこうかな。

_ 2018年の振り返り

今年はあんまり日記を書いてなかったけど、今年のまとめを書いて終わりにしよう。

書き物

• Chart.js でインタラクティブなチャートを作る方法 - Qiita
• SQL Server の一時テーブルをNode.jsから使う時の注意点 - Qiita
• とにかくfrozon_string_literal をぶっ込みまくる - Qiita
• BasicObjectで雑なテンプレートエンジンみたいなものを作る - Qiita
• テーブルに適用されているインデックスとそのカラムを調べる方法 - Qiita
• Laravel でインデックスを作成、削除する - Qiita
• 真面目な人を本気にさせる方法 – Tatsuya Sato – Medium
• 「Azureで学ぶ 実践Kubernetes」に参加してきた。 #aajp – Tatsuya Sato – Medium
• DevOpsから受ける違和感 – Tatsuya Sato – Medium
• Visual Studio Live Shareを少し試したら期待した未来だった。 – Tatsuya Sato – Medium
• ゆっくりAPIにリクエストを投げる仕組みをDurable Functionで作った。 – Tatsuya Sato – Medium
• SQL Server 2017を使ったLaravelアプリをCircleCI上でテストする。 – Tatsuya Sato – Medium
• Japan Azure User Group 8周年イベントで話してきた。 – Tatsuya Sato – Medium
• Serverless OpenHackに行ってきた。 #openhack #serverless – Tatsuya Sato – Medium
• モブプロを始めてから一度消えたけど形を変えて戻ってきたプラクティス達 – Tatsuya Sato – Medium

書いた内容は、だいたい今の仕事の中で、ハマったところや取り組んだことを主軸に細かく外に出せるものを出していってみた。あとは、個人的にもんもんと感じていることをまとめてみて、他の人達がどう反応してくれるか試してみた。
最初は、技術的なことはQiitaに書くようにしていた。しかし、以前はKobitoでメモのように書き溜めてから、清書するようにしていたのが、それができなくなってしまったので書きづらかった。ということで、最近ちらほら見る
Mediumで書いてみることも試してみた。QiitaはGoogle Analyticsが使えるけど、Mediumは独自の計測機能があるけど追いづらかったりするので、一長一短で難しかった。結局、tDiaryに戻りそうということで、これを書いている。

講演

今年は2回、外で発表する機会をもらえた。

実況パワフルモブプログラミング 感想戦 #devsumi - Satoryu's Diary(2018-02-16)

これは発表ではなく、見せられる限り最大限の普段やっていることをやっただけなんですが、たくさんの方々に来ていただけて驚きました。
参加していただいた中から実際にモブを始める切っ掛けとなっていたら幸いです。TwitterやFacebookでたくさん反響を頂いて、自分たちのこのやり方に対してもよりいっそう自信を持つことができました。とても感謝しています。

Japan Azure User Group 8周年イベントで話してきた。 – Tatsuya Sato – Medium

今やっているB2Bサービスもサービスインしてから1年が経ち、振り返ってみると、当初は想像していなかったアーキテクチャ変更を何度もしました。それについて、まとめてみたのがこの発表です。
最近教えてもらったのですが、日本企業の中でパブリッククラウドを導入しようとするところで初動が遅くなる原因の1つが、「予めアーキテクチャを固定しよう」とする傾向があるため、だそうです。Azureに限らずパブリッククラウドは、そういった変更を柔軟にかつ迅速に始められるところに利点があるはずなので、ガンガン使い倒していけば良いと思っています。この発表が、そういったところで悩んでいる方々が「とりあえずやってみるか」のノリで動きだす切っ掛けになれば幸いです。
そういえば、ログミーさんに書き起こしされたしていただいたので、当日の雰囲気と一緒にご参照ください。

• PoCからプロダクションまで　Azureが支えたPHPアプリケーション開発の舞台裏 - ログミーTech

お仕事

昨年から引き続きB2Bサービスを担当している。9月あたりで一旦契約が切れちゃうんだろうなぁ、と思っていたけどそれが続いて、さらに更新していただけて来年3月までは継続していただけることになった。今のお客さんがもうちょい達成感を得られるところまで伴走できればいいな。
それに加えて今年は、新卒研修という一番大きな仕事があった。いただいている金額という話ではなく、教える立場だったはずだけど、色々と学ぶことが多かった。特に、「自分の経験が未知のことへの挑戦を狭めていることもある」というのは、個人的に大きかった。
そんな彼らのことは、Regional Scrum Gathering Tokyo 2019 にて話が聞けるらしいから、乞うご期待ですね【PR】

• Regional Scrum Gathering Tokyo 2019 - 学習する／Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー | ConfEngine - Conference Platform

技術的な面では、相変わらずAzureやPHP、Laravelをメインとしている。
今年は、開発だけでなく、お客さんから分析の依頼もあったので、SQLで集計したり、Application Insightsで利用状況を見えるようにしたりといったこともやった。
MVPの推薦をいただいたので、頑張って書かないと…

推し事

さ学においては、今年は第1四半期は希望した公演、イベントに参加でき、推しの卒業を見届けられたので非常に良かった。卒業式は行けただけでも奇跡なのに、貴賓席の真後ろという良席。DVDにもばっちり写れたので良い記念にもなりました。お渡し会も当選し、これまでの感謝の気持ちをお伝えできて感無量でした。今年度もそろそろ卒業に向けて準備しないと。

一方、でBABYMETALにおいては、ギターの神の急逝とYUIMETAL脱退という辛い出来事があった。今年は外典と称しダークサイドというテーマで、衣装やら体制やらがだいぶ変わってしまった。とはいえ例年通りにWOLRD TOURの日本公演には行ったのだけど、やはりこれまでとは良い意味でも悪い意味でも違うBABYMETALを見て、複雑な気持ち。WOLRD TOUR以降、キツネ様からは何のお告げも出ていないので、例年どおりであれば4月までは何の動きも無しかな…

読書

• 中小企業診断士FOCUSテキスト「運営管理」を（途中まで）読んだ。 - Satoryu's Diary(2018-01-21)
• 旅猫リポートを読んだ。 - Satoryu's Diary(2018-01-26)
• エンジニアのためのデザイン思考入門を読んだ。 - Satoryu's Diary(2018-02-05)
• カイゼン・ジャーニーを読んだ。 - Satoryu's Diary(2018-03-02)
• 「Adaptive Code 〜 C#実践開発手法」を読んだ。 - Satoryu's Diary(2018-08-16)
• 『組織にいながら、自由に働く。 仕事の不安が「夢中」に変わる「加減乗除（+-×÷）の法則」』を読んだ。 - Satoryu's Diary(2018-08-19)
• 「きみの友だち」を読んだ。 - Satoryu's Diary(2018-10-12)
• リーンスタートアップを読んだ。 - Satoryu's Diary(2018-11-26)
• リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) | Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典 |本 | 通販 | Amazon

あとは図書館で借りて、掻い摘んで読んだ本とか合わせるともうちょい増えるかな。読み進めるのが遅くて、通勤の電車の中がメインの読書時間なんだけど、月に1冊ずつくらいは消化してたんではないだろうか。最初にスタートダッシュして、後はノロノロと読んでいた気がするけども。
誕生日にたくさん良い本を頂いたので、当面買う必要が無い。ちなみに今はカスタマーサクセスを読んでいます。
あと、今のマネジメントの源流ってなんだろうと気になって、科学的管理法と、勧められて五輪書 を借りてしまい積読状態。

プライベートな開発

今年はあんまりプライベートな開発ができてなかった。
仕事で使っているLaravelについて勉強がてらに、簡単なサンプルコードのようなものを書いたりはしたけれど、外に出して継続して開発していこうというものは作れなかった。
上に書いたQiitaの記事などのためにサンプルのプロジェクトをいくつかは作った。
そういえば、とある社内OSSの開発者とかメンテナが皆さんご卒業されてしまったようなので、あれを勝手にいじくり回すのもどうしたものかと悩みどころ。
クライアントサイドの開発がこれまで苦手だったので、それを克服しようと11月ころからVue.jsを触りだしている。チュートリアルをガシガシやるのも飽きてしまうので、実際にアプリを作りながら勉強するように切り替えた。これまで自分が欲しいと思っていたTwitterクライアントをネタにちまちまと作っている。

まとめ

なんだかんだで、色々と新しいことをやらせてもらえた一年でした。
仕事のあとに疲れて直前でキャンセルすることが多く、外の勉強会にあまり出れなかった。来年は新しい繋がりとか知らないことを仕入れるために、もうちょい外に出ていこうかな。

来年一発目は、Regional Scrum Gathering Tokyo 2019の当日スタッフと、Scrum Fest Osaka 2019 で発表する機会をいただけたので、声をかけてくれたら嬉しいです*1。
あと、新しいお仕事も探していかないといけないので、色々頑張ろう。

それでは、良いお年を！

_ tDiaryを5.0.11に、ruby 2.6.0 にアップデートした。 #tdiary #ruby

今年最後の肉の日にtDiaryが出て、その前にrubyも2.6がリリースされたので、早速アップデートした。
相変わらず、HerokuとTravis CIは最新バージョンをリリース後すぐに利用可能だったので、素晴らしすぎる。

参考

• tDiary.org - tDiary-5.0.11 リリース
• Ruby 2.6.0 Released

_ tdiary-redis-cache にconnection_pool を適用してみる。 #tdiary

以前、tdiary-redis-cache を設定してみたところ、記事を公開した直後に接続クライアント数がサーバーの上限を超えてしまい、エラーになることが何度かあった。
その時利用していたのがHeroku Redisの無料版なので使って、接続クライアント数の上限が20と低かったので、あっさりとそれを超えてしまった。

ということで、接続数をうまいこと制御できないかと思って、connection_pool を入れてみることにした。
需要があるように思えなかったので、一旦、forkしたgem として使ってみることにする。

もし欲しそうな人がいたらGitHub上でコメントとかIssueを書いてくれるとありがたいな。

• Use connection_pool to run tdiary wtih Redis limited maxclients · satoryu/tdiary-cache-redis@257c9e5
• tdiary/tdiary-cache-redis: redis adapter for tDiary
• connection_pool | RubyGems.org | your community gem host

_ リーンスタートアップを読んだ。

リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす [ エリック・リース ] 価格：1944円（税込、送料無料) (2018/11/26時点) 楽天で購入

だいぶ前にRUNNING LEAN を読んだのだけど、その時はリーンのことをよくわからずに読んでいたので、全然印象に残っていなかった。インタビューしながらキャンパスを埋めながら、事業とかプロダクトを作っていく方法だと思いこんでたと思う。
ということで、ちゃんと原典（？）を読んでおこうと思ったのが、読む切っ掛け。

この本でのリーンは事業とプロダクトを無駄なく作るための方法として、トヨタのリーン生産方式を参考に考え出されたもの。単に考えただけでなく、著者のエリック・リースが自身で経営してきたスタートアップやコンサルティングとしてサポートした中で考え出されている。
「無駄なく作る方法」というよりも、「無駄であることに早く気づくための方法」の方が正しいかもしれない。前者だと、予め徹底的に考えて無駄を失くそうとするやり方を含んでしまう。この本は、事業やプロダクト開発のために今一番知りたい事実を検証するために必要なことを考えて実践することを最重要視している。作ったものが無駄になることよりも、何の学びもなく無駄に時間を費やす事の方がより無駄という考え方だと思う。

この本が出たのが2012年なので、今はきっともっと知見が出てるのではないかと思う。
その一つが逆説のスタートアップ思考なんだろうな。だいぶ前に読んだ本なので、また読んでみよう。

参考

• RUNNING　LEAN 実践リーンスタートアップ （THE　LEAN　SERIES） [ アッシュ・マウリャ ]
• 逆説のスタートアップ思考 （中公新書ラクレ） [ 馬田隆明 ]

_ Rakuten Hackathon 2018 Pre event に行ってきた。 #rakutentech #rakuten_tech

毎年恒例のお騒がせイベントRakuten Technology Conferenceは今年もあるようです。
今年は実行委員がまるっと入れ替わったようで内容も真新しくなっているらしい。
その一つとして、ハッカソンイベントを併設するそうで、試しに事前イベントに行ってみた。
参加者は、途中から来た人を含めて、20名くらい。だいたいが大学生、スタートアップのCEOと3名ほど楽天社員。日本語話せるのが自分含めて3人くらいという、グローバルな雰囲気だった。

ハッカソンのサイトを見ると、スケジュールとどうやらRakuten RapidAPIを作ってなにかするということくらいしかわからない。
この事前イベントで、詳細の説明があった。

スケジュール

10/20（土）からカンファレンス当日10/27（土）までに以下のようなイベントを実施予定。
どうやら現時点（2018/10/14 20:30）で掲載されている情報は最新版では無いそうで、後日更新してくれるらしい。

• 10/20（土）参加必須
  • 個人で参加した人のための、チーム作りとチームビルディング
  • 各スポンサー企業から提供していただけるサービスや技術についてのワークショップ
  • ハッカソン
• 10/21（日）
  • ハッカソン
• 10/24（水）
  • 18:00 からハッカソン会場を提供
• 10/26（金）
  • 事前審査
  • 懇親会
• 10/27（土）
  • 事前審査を通過したチームによる3分のピッチとデモ

大まかな流れはこんな感じ。

審査及び審査基準

楽天のCIO、RapidAPIの開発リーダーや各スポンサー企業からの代表者により審査。
審査基準については、後日参加者宛に連絡するらしい。
ちらっと審査基準のリストのExcelファイルを見せてくれたけれど、「楽天のサービスを改善するもの」から「Goverment 2.0」などテーマは大きい。

10/26の事前審査で、各スポンサーやコミュニティスポンサーに入っている団体から来ているメンター*1の方々が審査するらしい。

テックカンファ当日にプレゼンできるのは最大15チーム。
おそらく15チーム分のセッションの枠があるから、そこまでしか入れられないってことなのかな。
もし参加チーム数が15チームより少なければ、事前審査しても全部当日のプレゼンはできるそうだ。この説明会の司会に言わせると「そのときの状況に依る」ってことらしい。

賞品

各スポンサー企業、楽天から受賞者に何かしら提供。
各社検討中ということかな？

成果物の扱い

このハッカソンで作成した成果物は、当然だけれど開発したチームのものとして扱われる、と言っていた。
当たり前だけれど、これははっきりしておかないと、作ったものが
Eventbriteで申し込んだ時に実は参加同意書的なチェックボックスがあったのかもしれないが、スルーしてしまったので覚えていない。

という感じだった。久しぶりに英語だけでバーっと話をされたので、抜けてたりするところもあるかもしれないが、たぶんハッカソンの運営から近々何かしら詳細が来るんじゃないかと思う。
今のサイト上の情報じゃ、怖くてエントリーしないし。

対策

ハッカソン自体は1日半くらいしか無いので、今のうちに準備できることはしておかなければいけないと思う。ということで思いついたことを書いてみる。

チーム

チームでエントリーすることが可能なので、さっさと周りに声をかけて、チームを作ってしまうのが有利になる。
ハッカソン当日に初対面の人と組むのは、なかなかハードルが高いだろう。というのは普段エンジニアとしてチーム開発したことある人ならすぐわかると思う。
ちなみに、この事前イベントで参加してる人同士でもう勝手にチーム作りが発生していた。

あと、万が一にも賞金を取った場合の取り分も合意しておいた方がいい。これでもめるケースもある。

開発

テーマは後日連絡が来るはずなので、その前に使う技術要素を固めておくといいだろう。
Rakuten RapidAPIは制約の1つなので、いまのうちにアカウントを作成して、サンプルコードを動かすのを試したほうが良さそう。
正直言って、使いやすいサービスとは言えないので、今のうちにハマりどころは解決しておくといいだろう。ちなみに、自分はMicrosoft Computer Vision APIを試しに使おうとしてみたけれど、Subscription に関するエラーが出てきて、それをどう対処したらいいのかで今ハマっている。これはMicrosoftさんに聞いたらいいのか、それともRapidAPIの中の人に聞いたらいいのか、なかなか難しいところである*2。
8,000ほどのAPIがRapidAPIで使えるようになっているので、ざざっとどんなものがあるのかを見ておくといいだろう。
ハッカソンのテーマはまだわからないけど、スポンサー企業からの受賞を狙うとして、ガッツリその企業が提供するAPIを使い倒すという手もあるかもしれない。

あとは開発言語や作るプロダクトをWebサービスにするのかモバイルアプリにするのか、デモのための実行環境等々をチームで決めておくといいのかな。

_ 「きみの友だち」を読んだ。

きみの友だち （新潮文庫） [ 重松清 ] 価格：723円（税込、送料無料) (2018/10/12時点) 楽天で購入

主人公の恵美が小中高校生の生活の中で「友達」にまつわる短編集。
普通の女の子だった恵美が、交通事故により松葉杖を必要とする体になってしまうことから、それまでの周囲の環境が一変し、それまでの「友達」の希薄さを感じ始める。それと同じ時期に、病気がちでほとんど学校に来れない由佳とあるきっかけから友達になる。性格がまるで違うけれど、ずっと二人で過ごしていく中で、本当の「友達」の意味を見つけていく。すべての話が恵美を主人公としたものではなく、同級生や恵美の弟、先輩や転校生などを主人公として、それぞれが持つ「友達」の意味と、恵美と由佳の「友達」の意味との違いが描かれている。それぞれの話は、どれも誰もが過去に少しは感じたことのあるような話だった。ちょっとした喧嘩から素直に謝れない状況や、誰とでも仲良くすることに気を取られて安心できなかったり、後輩に追い抜かれる先輩、など。それぞれの話で、「○○という立場（や人間関係）ならば、□□であるべきだ」といったような思い込みが出てくる。例えば、「友達ならいつも一緒にいるものだ」や「先輩なら後輩よりも優れてなければいけない」といったように。特に友達については、恵美が少しずつ明かしていく友達の意味がすごく印象に残る。
最後は悲しさと嬉しさの混ざった終わり方だけれど、美談っぽさがなくリアルな終わり方に感じた。