BAR ノスタルジアにいってきた

retty.me

森見登美彦のアニメ有頂天家族の朱硝子のモデルになったお店…ということで行ってきたのだがめちゃくちゃ良かった。

のむぞ!

ぼくはお酒がほとんど飲めなくてあまり飲みにいくことがない。 なのでバーとかに行ってみたいけど敢えていくのはなーとあまり縁がなかった…という前提がまずある。

そんな折にふと三条近くで昼ごはんを探していたときに良さげな雰囲気のお店を発見、それがBARノスタルジアだった。 たまたま気になったのでメモを取ろうと店名で検索したところ有頂天家族のモデルになったお店だということが判明しこの度凸ったという経緯だったりする。 有頂天家族のモデルになっていなかったらもしかしたら行ってないかもしれないのでこれもご縁ということでしょうか。

有頂天家族の朱硝子のモデルになったお店に来たぞ、うおー!

一番お気に入りなのが偽電気ブラン(飲みやすい…という点ではそのあとに飲んだ「下鴨弥三郎」のほうが圧倒的に飲みやすかった)で、非常に気に入った。

偽電気ブラン飲むぞ!

弁天さまだー!

下鴨弥三郎頼んだら狸鍋にされててウケる。

弁天飲むぞ!(これでラスト)

そんな感じで聖地巡礼していたら店員さんが気を利かせて森見登美彦が直筆サインしたメニューを持ってきてくれて写真いかがですか?と来たもんだ。

森見登美彦直筆サインのメニュー出してもらえた、めっちゃ嬉しいんですけどおおおおおお!!!

ということでお酒も美味しかったのだけどそれ以上に雰囲気と気遣いが嬉しいお店でした。 お酒のおつまみとして頼んだイチジクとベリーのドライフルーツもほどよく甘みが凝縮されていてとてもお酒と相性が良かった。

純粋にもう一度行きたいなと思えるよいお店でした。 普段あまりお酒を飲まないのでお酒の良し悪しはわからんが非常に楽しめました、三条からわりあい近いので交通の便が良いという意味でもいいですね。

snobby-fmはじめました。

やったこと

houka-go-projects.github.io

去年末宣言したとおりpodcastやるぞ!という話をしてましたがこの度ようやくiTunes Storeに登録できました 🎉 現在ep0からep.2まで収録しており、今後も継続的にやっていきたいなと思ってます。

わかったこと

podcastの一人語り難しい。 特に話しながら考えていたりするので矛盾する発言をしていても気づきにくかったりするし、自分の考え以上のものが出てこないのでいまいち会話にならずつまらない。 特にアフターショーが難しくてアニメとかゲームの話をしようとするとどうやってもネタバレをどう避けるか?みたいな話しになるのだがそれを考え始めるとクソみたいな感想しか出なくてつらい。

収録現場を用意するのが難しい。 外部の音が入りにくい無音な環境というのが難しい、いまは深夜に周りが寝静まった時間帯くらいに収録しているがそれでもノイズというか外の音が入ってしまう。

トピックの切り替えが下手すぎる。 rebuildfmのmiyagawaさんとかめちゃくちゃ自然に会話を切り替えててすごい。 今後この部分はSE入れるとかで切り替わったよ!というのを明示的にしたい、口頭で「じゃあ次!」とか人類がやるべきことでないと思う。

次やること

podcastやはりクソエモみたいなマネジメントや書評レビューやブログエントリの感想をひたすら喋っててもあんまり楽しくないし面白くないのでは?と思っているのでTechな話を最低でも3割くらいは喋れるようにしていきたい。

まとめ:

ゲスト収録してみたいと思いつつも準備とかが大変そうで自分のモチベーションが保てなさそうという問題をどうにかしたい。 どうでもいい情報ですがartwork画像はぱくたそから良さげな画像を使わせてもらってます、感謝。

OSS コードリーディングでわかったこと

概要:

Githubに上がっているOSSやライブラリなんかのコードをできるだけ読むようにしてわかったことや得られたもののログ。

発端:

多分具体的な行動に移るきっかけになったのはRails Developers Meetup 2017から。 そこで紹介されたブログのコミットログを読むようになった。

y-yagi.hatenablog.com

あとKyoto.rbのSlackに参加しているのだけどそこにRailsのコミットログを流す rails_commit というチャンネルがあってそこにjoinした影響も少なからずあるかも。

結論:

具体的にいくつかのメリットがあったと感じている。

  1. コミットの粒度とコミットログの良い書き方
  2. コードのベストプラクティスな書き方
  3. 英語を読もう/書こうという気持ち

ちょうどRailsチュートリアルを始めた影響やチェリー本を読んだ経緯などもあって「やってみるか」という軽い気持ちで始めたがそこそこ続いている。 軽い気持ちで始めた割にはそこそこいい感じだなと思っている、具体的な効果に関してはまだまだ出ていないというのが結論。

ただコミットログを見るのは文字を覚えるためのドリルのようなものだと思っているので焦らず今後も続けていこうかなと思っている。 なにより綺麗なコードを日々見続けるので汚いコードを読んで頭を悩ませる…みたいな無駄な時間を減らせるんじゃないかと考えている。

コミットの粒度とコミットログの良い書き方

ぼくが日頃読むようにしているコードは多くがrubyrails、そしてvue。あるいはGolangだ。 だからなのか、非常に細かいコミットの粒度のPRを目にする。 多くのPRのコミット数が1〜5くらいで変更されたファイルに関してはほぼスクロールしなくてもいいくらいのコード量。

Railsなどのような利用者が多いOSSにおいて粒度の大きなPRというのは害悪だと思うので非常に納得がある。 鑑みるに自分のコードのPRはまだまだ巨大だなと感じており、改善すべき点だと改めて認識した。

ところで、どのPRだったのか覚えていないのだけどrubyrailsのPRにとあるメソッドの返す値を変えたPRがあった。 そのコミットログに変更前と変更後の期待値が書いてあり、レビュアーにとって非常に助かるコミットログで真似していきたいなという学びがあった。 いままで他人の書いたコミットログで感心したことがあまりなかったのだけどこの件では大いに感心した。

これは業務で行うコミットの場合多くがコンテクストが取れている前提であるためだと思う。 OSSのような多種多様なバックボーンがある場合コミットログにbefore/afterな期待値が書かれているほうがレビュアーの普段が少ないということだろうと思う。 ただこの工夫は業務でも活かせるものだと思うので今後リファクタリングなどで期待値を変える場合に真似していく。

コードのベストプラクティスな書き方

読んでいるコードの多くがいままで携わってきたPHPではなくRuby/Rails、Vue、golangだからだと思うのだが その言語におけるベストプラクティスなコードの書き方というのが少しずつ自分の中に浸透している気がしている。 慣れない言語を書いていて「Aとも書けるがBとも書ける、どちらのほうが良い書き方なのか?」というのが気になることがある。

慣れ親しんだ言語であるとある程度経験則だったり、他のエンジニアのひとが書いたブログを読んでいて知識として知っているパターンが多い。 仕事などのプロダクトのコードの場合は既存のコードがどうなっているのか?を調べることである程度傾向がつかめることがある。

ところが学習時にそれらのコードをどう書けばいいのか?というのはなかなか判断しにくいものがある。 特にRubyRailsはそのあたりの書き方がよくわからないケースが多い。

そんなときにGithubにガンガンコミットしているような第一線級のエンジニアが書いているコードというのは非常に有効な参考になるなと思った。 実際にはまだコードを読んでいたことで書き方の指標が出来たとは思っていないのだがジャブのように後々効いてくるんじゃないかなと最近感じている。 あと綺麗なコード、一読するだけで何をしているコードかわかるというのが具体的にどういうことか?という点においても非常に有用だなと思う。

英語を読もう/書こうという気持ち

当たり前だがOSSの多くは英語でissueやPRが書かれている。 タイトルをみても何書いてるかわからない、コメントをみてもわからない…だとかなりつらい。

その点Githubはよく出来ているなと思うのだがやりたいことがissueにかかれており、その解決策としてのコードと一緒にPRが出されているのでなんとなく「こういうことがしたいのかな?」と思ったときに英語の読解に自信がなくてもコードを見たときにやりたいことが伝われば英語の読解に対する補強になると最近感じるようになった。

特に生きている英語を使ってやり取りがされているので教科書でよくみかける「私はジョンです、彼女はミカです」といった お前はそれを日常会話でいうことが現実的にあり得るのか?みたいな英語じゃないし、 issueのdescriptionは仕方がないがタイトルやコメントは比較的短い英語であるので苦手意識を少しずつ減らしていけそうだなと思っている。

まとめ:

先日会社でも「最近GithubOSSなコードを読むようにしていて、なかなかいいぞ!」といった主旨の発言をしたのだが せっかくなので文章ログとしても残しておこうと思った。

以前からOSSに貢献しようぜ!という話しは各所で聞いていたのだけどまずはコードを読むところから入っていくのでもいいんじゃないかなと思う。 結果、そこでなにか問題があればissueなりPRなりを出していけばいいしなにより美しいコードを読むのは勉強になるがそれ以上にワクワクするものがある。

まずは趣味としてのコードリーディングから入るのも悪くないんじゃないかなとおじさんは思いましたまる

〄!〄!〄!

タイトルは幼女戦記のLos!Los!Los!のパクり。

まとめ:

2017/05 にジョインした株式会社シーズ を 2018/04/30で〄ます、最終出社日は4/13。

www.seeds-std.co.jp

2018/05/01 からは株式会社トマルバでサーバーサイドエンジニア(アプリケーションエンジニア)として働くことになります。

www.tomaruba.me

いままではPHPエンジニアでしたが今後はRailsエンジニアになります、ヨチヨチRubistとしてよろしくどうぞ。

会社自体がスタートアップなのでサーバーサイドメインで開発することになると思いますが 多分フロントエンドやスマートフォンアプリなんかのコードもある程度読んだり書いたりすることになりそう。

他にもDockerメンテナンスしたりCI回せるように環境整えたりとか…横断的なことができそう、そういうところにワクワクしている。

〄理由:

〄理由書いても誰も幸せにならないの割愛。

詳細を聞きたいかたはぼくを飲みに誘ってください。 お酒は飲めないですが代わりにご飯をめちゃ食べます、よろしこ。

転職した理由:

いろいろ理由はあるんだけど大きく分けると↓な感じ。 他にもいろいろあるけど書く量がすごいことになりそうなので箇条書きでサラッと。

  • 成長できそうな環境
  • 働き方を自分たちで作っていける
  • 自社サービス(受託開発はぼくには致命的に向いてなかった)
  • シェアリングエコノミーなサービスに対して興味があった
  • リモートワークできる

これから

周りのメンバーがみんな優秀なのでド底辺からやっていくぞ!という気持ちでいる。 元々転職前に副業で働いていて自分がまだまだ技術的に不足しているという状況なので成長が実感できて楽しい。

一方で「基本はオフィスで仕事すべきだと考えているが、特定の曜日に週1でリモートワークがしたい」というぼくの要望を採用してくれたりと環境面でも自分たちがよいと思える方向性に変えていくのを許してくれる空気があり、非常に心地よい。

とにかくスタートアップらしく、ガンガン変えてガンガンPDCA回していくぞ!という環境が自分にとって良い環境だと思っていてその辺が魅力的だと感じている。 まだまだこれからいろいろと変わっていく途上だと思うのでまずは期待されているバリューに見合う働きをしていく。

最後に

実は昨年末 #しがないラジオ にゲスト出演した際に転職するかどうか迷っていたという経緯があったりなんかした。

現職に対する不満だとかはまーやっぱりあるんだけどそれを辞める人間がどうこういっても仕方ないなって気持ちのときにカイゼンジャーニーを読んでいろいろ考えたけども結局ぼくは転職するという選択肢を取った。

新しくジョインする会社のメンバーでぼくと同じくらいのプログラミング歴(だいたい10年くらい)で大学生(今年新卒で別の会社にジョインする)がゴリゴリコード書いて、 ガンガンcommitしているのを目の当たりにして「こりゃうかうかしてられんぞ!」みたいなヒリヒリとした緊張感とモチベーションがあって次の職場に対する期待値が非常に高まっている。

ぼくたちはこういう新世代と今後闘わねばならぬのだ!と思い、恐ろしい反面頼もしいと感じていてすごく刺激的な職場だと感じている。

相対的に若いメンバーが多いので、期待の若手にまずは追いつくのが当面の目標。 しばらくして開発が落ち着いたらチームビルディングとかコーチングあたりに噛ませてもらいたいなーと思ってるけどまだまだ先の話かな。

現職の在籍は4月末までだけど最終出社が4/13なのでそれ以降は週休7日(仮)になるので温泉旅行とかリフレッシュ期間に当てたいなと思ってる。 というわけで今後も京都でやっていくぞ!という感じで頑張ります。

おまけ:

今期アニメはヴァイオレットエヴァーガーデンが最高だな!って感じ。 からかい上手の高木さんで癒され、ダーリンインザフランキスで02の可愛さとかっこよさに骨抜きにされている。

3月後半にスパロボX、戦場のヴァルキュリア4を購入予定で大変(ゲームで)忙しいことが予想されるなか天地無用!GXPの新刊が出たりするので時間が足りない。

誰か精神と時の部屋用意してくれ〜。

カイゼンジャーニー たった1人からはじめて、「越境」するチームをつくるまで

昨日から読んでるがめっちゃいい話しなのでいまのうちに書いておく。 感想はまた後日。

この本は「いまの会社やめようかな…」と考えている人や「うまくチームが回ってないな」と感じている人向け。 どこかで聞いたことがあるようなどう改善していくのか、またその仕組みを取り入れる目的や目指す地点が丁寧に書かれている。

ストーリー仕立てで進行するため「あるある〜」という感じでスラスラ読めていく。 いまのチームや会社で働いている人に対してはないが組織やマネジメントなどで不満があるという人には是非一読してほしい。

そこから何を感じるか、どう動くかは個々人毎に違うだろうけども、その際の1つのガイドブックとしてカイゼンジャーニーはよい手助けをしてくれるだろう。 なお、↑ではアフィリエイトリンクを貼っているが現在出版元の翔泳社では電子書籍半額セールを行っている。

www.shoeisha.co.jp

期限が2/21までということなのでぼくの中では異例であるが読んでいる最中に書籍紹介をさせてもらった。 どうせならぼくのアフィリエイトリンクから購入してほしいがちょっと興味ある程度の本だからなーと躊躇しているかたは翔泳社さんの半額セールを利用するといいんじゃないかな! っていうか発売日に半額セール対象になるってどういうことだよ!!!

…失礼、電子書籍版を定価で買った負け犬の遠吠えでした。

ということを昨晩Twitterに #しがないラジオ のハッシュタグつきで連投してしまったのでブログに書いてます、はい。

とりあえずパーソナリティーのガミさんは買ってくれたらしいので、「よっしゃ!」という感じです。 きっと読み終わったらpodcast内で紹介してくれるやろー!とか雑な感想です。

RubyKaigi 2018のSuper Early Birdに申し込んだ

rubykaigi.org

多分日本で一番有名なカンファレンスなんじゃないかと思うが初RubyKaigiのSuper Early Bird枠が買えそうだったので思い切って買ってみた……ところ買えてしまった。 ということでよちよちRubistsだけど参加することになった、あったことある人やTwitterとかで知ってまっせ!というひと気軽に声かけてくだされ〜(知り合いがほぼいないので)

1月のやっていきログ

先月は中盤くらいまでいいペースだったけど後半に体調不良で一気にペースダウンしてしまった。優先順位の設定とかやろうかな…。

昨年末、やっていくぞ!という思いを新たにしたところ、さっそくフラグを回収してしまいました。 どうしてこうなった…。

やったこと:

やり残していること:

できなかった原因:

1月中旬くらいまでは遅れ気味だがそこそこのペース配分でいろいろ進められていたと思っている。 問題はそれ以降から月末まで体調を崩し気味だったこと。

早く治そうと早めに寝たりしていたのだが一向に回復しなかったせいでインプットに当てる時間やアウトプットに当てる時間がほぼなくなってしまった。 それどころか完全に体調を崩して熱がでて何日も寝込んでしまった。

これによって大幅に計画が狂った。

リカバリー:

とりあえずまずはRailsチュートリアルを最優先でやっている。 これは1月中旬まではインプットが順調だったため、2月は多少インプットを減らしても挽回できそうだなと思っているから。 なのでやり残していることを「Railsチュートリアル写経」→「Go言語でチャットアプリ作る」→「テスト駆動開発読む&写経」で考えている。

テスト駆動開発Rubyでやっていきたいと思っているがGo言語でもいいかもしれない。

最後に

ゼノブレイド2が全然終わってくれなくて非常に時間的制約が厳しい。