はじめにこんにちは。Ubie のテクノロジープラットフォーム部で Web エンジニアをやっている highwide といいます。Ubie には今年の 10 月に入社しました。これは Ubie Tech Advent Calendar 2025 の 16 日目の記事です。さて、いきなり前職の話をするのですが、最後に所属していたチームで「最初は面食らったものの、最終的にめちゃくちゃ良かったなと思うチームの Working Agreement」として 「コードレビューの優先度をできるだけ高める」 というものがありました。当初は社内ドキュメントでこの慣習を紹介しようと思ったのですが、...

コードレビューの業務Tierを上げる

1月highwide.hatenablog.comsizu.me2月offers.connpass.com speakerdeck.comsizu.me3月highwide.hatenablog.com子育ての過酷さを示すエピソードなんですが、Spotifyにある「赤ちゃんが5分で寝付く睡眠音楽」というプレイリスト、5時間27分ある。— うちやま (@highwide) 2024年3月31日   sizu.me4月        この投稿をInstagramで見る            www.instagram.comこの交差点見るたび「神がネトラレてる」って思ってしまう pic.twitter.com/tW10vLKoWt— うちやま (@highwide) 2024年4月21日   5月        この投稿をInstagramで見る            www.instagram.com人が誰しも持っている「終点まで行ってみたい」という気持ちの発露は、4歳児の父を元町・中華街に連れていくことになるのだ。— うちやま (@highwide) 2024年5月12日   6月実は今「原稿を書く」ということに初挑戦してるのだけれど、普通にめちゃつらくて、これやってるみんな、あらためてすごいなって思った😇— うちやま (@highwide) 2024年6月29日   7月チームトポロジー チームトポロジー俺たち何？え？チームトポロジー— うちやま (@highwide) 2024年7月12日   8月gihyo.jpblog.studysapuri.jp        この投稿をInstagramで見る            www.instagram.com寂しいことに電車ブームが落ち着きつつある長男の中で怒涛の折り紙ブームが来ていて、日夜大人たちも製作に駆り出されている。これは僕が流行ってるから作った🦌 pic.twitter.com/oAXZaKcNwS— うちやま (@highwide) 2024年8月18日   9月次男くん、とうとうつかまらずの歩行一歩目を踏み出した— うちやま (@highwide) 2024年9月3日   10月        この投稿をInstagramで見る            www.instagram.com長男と桃鉄を初めてやってみた。当初は接待プレイかななんて思っていたけど、ビギナーズラックで目的地到達を繰り返す子供に、父は特急カードで貧乏神ぴったりなすりつけ、母はおならカードで目的地目の前でふっとばすなどの大人気ない大人の本気を見せつけたが、結局2人してボロ負けしたのだった。— うちやま (@highwide) 2024年10月4日   11月        この投稿をInstagramで見る            www.instagram.com次男くん、「いないいないばあ」を習得しはじめた。親がやると、負けじと「えうえう〜」と言いながら耳を隠して「ああ！」と言って手を下げてくる。1歳1ヶ月にして「あやされる側からあやす側へ」という意識の高さに父は慄いているよ。— うちやま (@highwide) 2024年11月4日   12月Oasis、チケット譲ってもらえることになってうれしすぎる。来年まで元気にLive Foreverしたい。— うちやま (@highwide) 2024年12月7日   blog.studysapuri.jp

2024年自分キュレーション

Web開発者たる自分が「プロダクトマネージャーのしごと」を読んでみて

2023年9月末に次男が生まれ、10月から育休を取ってもうじき4ヶ月になる。早い。長男が生まれたときは、転職直後かつコロナ禍になる前で、それほど休みを取らずに出勤を続けていて、産後1ヶ月は妻は実家で寝泊まりをしていた。(いま考えると、悪いことしたな…と思う。ようやく、そういうことに気づけるようになった)一方、今回に関しては、そもそも「次男の面倒を見つつ、長男も見なくてはいけない」という状況に家庭が置かれるので、会社に後押ししてもらったこともありしばらく育休を取ることにした。特に産後1ヶ月(産褥期と言う。すごい字面だ)は、体がボロボロになっている妻に休んでもらうべく、家事育児をなるべく引き受けた…つもり…だったのだけど、当然自分は授乳できないし、心身の負担を引き受けきった！と胸を張っては言えないかもしれない…とも振り返っている。次男は、当時の長男や世の多くの乳児たちと同じく、「抱っこしてるときは泣き止んでいても、横たわらせるとその瞬間から泣き始める」という傾向が強く、深夜に抱っこ対応した自分と、3時間ごとの授乳で疲労困憊になった妻で、日中は「お互い隙を見て寝る」を繰り返しているうちに1日が終わる…ということもままあった。当時は抱っこしたままできる娯楽として、タイムゾーンの違う同僚と深夜にhuddleを繋いだり、MTG Arenaをタブレットでやったり、ということをしていた。mtg-jp.comちなみにこのブログも途中までは子供を抱っこしたままスマホで書いた。1ヶ月ほどして、少しずつ妻の体力が戻ってきて家事育児を分担できるようになり、少し生まれた可処分時間を(妻に応援してもらいながら)Web開発のお手伝いをする副業にあて始めた。ohbaryeさんとの縁でSmartBankさんに声をかけてもらい、RailsやGoやReactに関する社員の方の手が届きにくいところなどを改善する業務をやっている。また、この記事でも言及いただいたが、ADRについての知識共有なども行った。blog.smartbank.co.jp当然、育休中にフルタイムで働くほどの余裕はないのだけれど、「週に何日か1日数時間程度」であれば、ある程度時間が確保できるようになった中、こうやって社会と繋がる機会が得られたのは精神の安寧に繋がっていると強く感じる。知っていることと知らないことの程よいバランスの中で知識をアップデートしたり成果を出したりするのは達成感に繋がるし、ロールを問わずカジュアルであたたかいコミュニケーションを取ってくれる雰囲気も心地良い。ちょうどこの仕事を始めたばかりの頃に、ファウンダーのyutaさんのスライドが話題になっていて、 speakerdeck.com特にCTOは本当にやるべきことにフォーカスするべきという趣旨での以下のページが特に心に残っていた。一方で、ある日、興味があったMTGに都合が合わず参加できなかったことを残念がるコメントを個人channel(times的なの)に書き込んだところ、ファウンダーのyutaさんが「お時間あうときにぜひ」とコメントしてくれた。CTOは、「PCの購入をするべきでなかった」と振り返りつつも「業務委託の自分のtimesをわざわざ見て、声をかけてくれるんだな」なんてところに会社の雰囲気を垣間見たような気がしたのだった。また、"MTG"の話が続くが、平日日中に行われた忘年会に参加させてもらい、二次会ではPdMやデザイナーの方らと、Magic the Gathering部の活動に混ぜてもらった。ここに来て、子供を抱っこしながらMTG Arenaでルールを覚えたのがコミュニケーションツールになるとは…！青黒フェアリー(?)の統率者デッキを貸していただき、"紙でやるMTG"の実績を解除したのだった。そんなわけで、SmartBankさんのお手伝いは、皆さんに助けられてとても楽しくやれているのだった。だからこそ、もっと成果を出したい...！と、そのように自分の可処分時間を積極的に副業にあてた結果、もともと育休中にやりたかったことがなかなかできないぞ...と気がついてしまった(当たり前だ)。そこでまずは、ちょっとずつ進めていた「ゼルダの伝説 ティアーズオブザキングダム」を泣く泣く祠や地下の探索はあきらめて、全クリした...。ちまちまとやっていたティアーズオブザキングダム、もうさすがにクリアしようかと思ってラスボス倒した。ずっとおもしろかった〜。めちゃくちゃ「ゼルダの伝説」だった。— うちやま (@highwide) 2023年11月19日   というわけで、ゲームはいったんお休みしようと、ゼルダに加えて、MTG ArenaやらFGOやらシャニマス/シャニソンやらも後ろ髪を引かれつつ封印している。ただ、同僚がある日「GGSTにエルフェルト実装されたよ！！」と連絡くれて、年末にわちゃわちゃと格ゲーをやる夜があったのは、とても楽しかった。そんな可処分時間の選択と集中を経て、最近はなるべくやりたかった学習に時間をあてようとしている。特に子供を寝かしつけしたあとの時間を使っている。ひとまず、RustでWebアプリを書く本をひととおりやったり、Webアプリ開発で学ぶ Rust言語入門作者:佐藤昭文秀和システムAmazonApp RouterになってからのNext.jsチュートリアルをやったり。nextjs.orgただでさえ時間ない中で自身の集中力のなさに悲観することもあるけれど、焦ってもしょうがないのでマイペースにやっていくことにしている。そんな集中力のなさをカバーすべく、デスク周りに最近投資してるのだけれど、その話は長くなりそうなので別に書くことにする。(たぶん)最後に子供の話に戻るが、この休暇の本分たる育児も、ときどき疲弊しつつも楽しんでいる。子供...かわいい...。次男は0歳の頃の長男に似ていて、最近は、あやすと笑うようになってくれた。泣いているときは、今でも反町隆史に助けられている。www.oricon.co.jp4歳の長男は電車好きに拍車がかかっていて、リビングに貼ったこの路線図を毎日食い入るように眺め、「都市部路線図１ デカ文字」 東京（関東、首都圏）【ポスターケース発送】【ふりがな付き鉄道路線図】 5歳～年配の方、ビジネスにも 書いて消せる路線図 全路線全駅掲載 A1サイズポスター岩崎デザイン企画Amazon休みのたびに「この路線に乗りたい！」「この駅に行きたい！」とアクティブに僕たちを外に連れ出してくれる。長男が「日暮里舎人ライナーに乗りたい！見沼代親水公園に行きたい！」というので、乗り慣れない路線の初めての公園にワクワクしながら家を出たが、要所要所で「やっぱり有楽町線に乗りたい」「小竹向原で乗り換えたい」「大江戸線に乗りたい」と言われた結果、光が丘公園にいる。だまされた…。— うちやま (@highwide) 2023年12月29日   今日はね、京葉線に乗りたい長男に葛西臨海公園に連れてきてもらった。これはhighwideも乗っていいエレベーター。 pic.twitter.com/6uBDsyKSoX— うちやま (@highwide) 2024年1月14日   そんなわけで、息災にやっております、のたよりでした。葛西臨海公園 - 1月の海は寒かった

次男が生まれてからの過ごし方あれこれ

「みてね」の「2023年1秒動画」は1/1に生成されるから今年の写真はさっさと現像してアップしないと！！と思い立ってなんとか終わらせてこんな時間。(22:37)誰が見ているというわけでもないこのインターネット僻地に、さくっと自己満足を兼ねた備忘録だけでも書いて今年の雑な振り返りとしたいと思う。仕事チーム異動した。GraphQL schema stichingによるマイクロサービスを扱うプロダクト開発チームから、プロダクトプラットフォームのチームへ。技術要素的には、React/GraphQL/TypeScriptを扱うことが減って、Goを扱うことが増えた。デブサミの登壇の機会があり、好評いただいたのがうれしかった。blog.studysapuri.jp家庭第二子となる次男が9月末に生まれた。生まれるまでは、"切迫早産直前につき自宅安静"との診断が妻にくだり、6月頃から家事や育児をできる限り自分で引き取るという動き方をしてきた。朝5時に起きて少しリモートワークして、それから子供を保育園に送る準備をして、保育園に送った後またリモートワークして、保育園にお迎えいった後はデリバリーフードサービスなどに頼りつつ、ご飯食べてお風呂入って子供寝かしつけて自分も寝て...みたいな生活だった。自分的にはなかなかに壮絶な日々だったが、その甲斐もあってか、第二子は元気に生まれてきてくれた。長男との絆も深まったように思うし、自分がこれまで妻に如何に助けてもらってたかを思い知らされた期間だった。第二子が生まれてからは育休を取っている。(ありがたい)2024年の3月頃まで取る予定。育休中は新たなことをやる機会にも恵まれている。また今度どこかで書くかも。その他子供の誕生に加えて、近親者の結婚や葬儀や大きな怪我などがあって、いろんなことがある年だった。マンションの契約をした。家探しも大変だったことを今更思い出した。まだ建てているので住むのはまだまだ先。Macbook Proを買い替えた。IntelのチップからM3へ。いえーい。子供が生まれた頃にMtG Arenaをやり始めた。...のだが、おもしろすぎて時間が溶けるので逆に今は少し距離を置いている。すごく好きだったはずのマンガ読むことが、少しずつできなくなっていることに気がつく。惰性で続巻を買うがちゃんと読めてない、みたいなシリーズがある。育休中の可処分時間の使い方を最近見直して、意識的に学習に時間を充てようとしている。なんか実を結んだり何かに繋がってほしい気もするが、そういう期待をするのもなんか違う気もするとりあえず、Rustの写経をしたり、Next.jsのキャッチアップをしたりするのは楽しい写真、相変わらず子供の写真ばかりだ。α7iii + SIGMA 35mm f2.0の組み合わせか、GR IIIxをずっと使っている。長男の鉄道好きに合わせて、いままで行かなかったところに行く機会になっているのは楽しい西武鉄道 玉川上水車両基地 クリスマスイベント良いお年を

2023年も残すはあと少し

2023年7月27日「Developers Summit 2023 Summer」にて「日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード」というタイトルで「ADR」について発表した資料です

日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード / Architectural Decision Records

大晦日〜〜〜〜！！！！というわけで2022年振り返ってみる。痩せた2022年の一番変化なので、はじめに書いてみた。年始から12kgくらい落ちている。なるべく筋肉を落とさないように体脂肪を落としたいというつもりで、食事と運動を頑張った。食事は、PFCバランスを気をつけて、あすけんで毎食記録を行っている。運動は、ジムに週2〜3行って胸・背中・脚の筋トレを行いつつ、週1〜2テニスやランニングで有酸素運動を行った。来年はもう少し体脂肪率を落としてから、今度は筋肉量を増やしたいなぁとうっすら考えている。2022/01/31 梅が咲いてた2022/02/10 雪が降った2022/03/28 桜と西武2000系仕事去年から携わっていたこのプロジェクトがリリースされた。prtimes.jp僕はRailsとApollo ServerをGraphQL schema stichingで繋いだバックエンドをメインに携わりつつ、強いフロントエンドメンバーのサポートを受けながらReactを書いたりしていた。4月にプロジェクト内でのチーム再編成があって、自律的に動ける職能横断チームでアレコレやる楽しさを感じている。この記事で触れている発表は、職場での働き方の雰囲気が垣間見えるものになっている。highwide.hatenablog.comGoogle Cloud PubSubを利用した新旧プラットフォームでのデータ同期や、GraphQLのFragment Collocationなど、扱った技術の定着を感じられた。なお、副業として携わっていたAutifyは4月末をもって辞めてしまった。子育てしながら無理なく携われる副業ないかなぁって感じである...。2022/04/16 秩父に旅行2022/05/20 家族でディズニーランド2022/06/25 同僚とテニス子育て子供は今月で3歳になった。かわいい。今年はどんどん言葉や知識が増えていき、意思疎通がどんどん取れるようになったのが楽しかった。電車好きの子供に合わせて自分も知識をつけていった結果、首都圏の車両の形式(っていう言い方でいいのか？「E235系」とか)がだいぶわかるようになった。プラレールもめちゃ楽しい。子供は漢字やアルファベットもおろか、ひらがなもろくに読めないけど首都圏各線のロゴマーク(青丸に「Z」で半蔵門線、とか)はすべてわかっている。すごい。2022/07/10 家族で西武園2022/08/22 山形に旅行2022/09/25 高麗川 曼珠沙華コンテンツ音楽は、haruka nakamuraとずっと真夜中でいいのにばかり聴いていた。あとはシャニマスサブスク解禁ありがたい。Podcastは、去年から聴いてるコテンラジオに加えて、ゆる言語学ラジオも聞き始めた。楽しい。マンガは、ルリドラゴンが良かったなぁ。ゲームは、去年に引き続きギルティギアストライブをよくやっていた。あと、FGOのメインストーリーが2年ぶりくらいに追いついた。あと、時間の無駄ってわかってるんだけど、ついついTikTokを見てしまう悪癖がついた...。2022/10/01 スカイツリー2022/11/07 富山旅行2022/12/07 有給とって寿司食べた来年も元気に楽しく過ごしたいですね！

2022年近況

前職の同僚の @kiyotoyamaura に誘ってもらって、彼や彼の運営するコミュニティの方と「コンピューターシステムの理論と実装」の読書会を毎週行っている。www.oreilly.co.jp3月下旬から始まって、かれこれ半年ほどかけながら今は5章を読んでいる。ペースはゆっくりながらも、きちんと手を動かす時間を取りながら理解することを大事にしているので、自分にとってもとてもありがたい機会となっている。(特に自分はコンピューターサイエンスのバックボーンを持っていないので...)5章では、抽象化されたコンピューター理論としての万能チューリングマシンと、実用的なアーキテクチャであるノイマン型コンピューターの紹介があり、NANDから始まってひたすら具象的な実装を積み上げる本書が後者に寄っているのに対して、前者の概念を理解するにあたっては同じくO'Reillyの「アンダースタンディングコンピューテーション」に助けられた...といった話を読書会でしていた。www.oreilly.co.jpと、アンダースタンディングコンピューテーションの目次を眺めていたら「停止性問題」の単語が目に留まって、最近自分のタイムラインに「無限ループを検出したいという相談を受けた」というツイート*1が流れてきておもしろかったと紹介した。そのうえで、この「停止性問題」については前職の社内LTで発表したことを思い出し、当時の自分の資料を読み返してみると"勉強になるなぁ"と思ってしまったのだった。(身についていなかった、とも言う...)拙い資料ではあるし、今更ではあるけど、せっかくならuploadしておこうかなと思って、6年半の時を経てSpeaker Deckにuploadしてみた。 speakerdeck.com前職の社内勉強会「0x64物語」は毎回テーマ縛りでLTを行うという形式のもので、このときのテーマは「数」だった。*2読み返しても対角線論法のところ、ちゃんと説明できる気がしないぜ...。*1:https://twitter.com/kur/status/1566574932074852352*2:「0x64物語」については以前社外のイベントで発表も行った: https://speakerdeck.com/livesense/wen-hua-falserihuakutaringu

6年半前の「停止性問題」についてのLT資料をアップロードした

2016年2月16日にリブセンスの社内勉強会「0x64物語」で発表した資料です。毎回テーマを決めてLTを行うスタイルの勉強会で、このときのテーマは「数」でした。アップロードは2022年9月15日に行いました。

停止性問題と数 / Halting problem and number

久しぶりに社外で発表した...！ speakerdeck.comイベントのURLはこちら: https://www.meetup.com/ja-JP/graphql-tokyo/events/286913987/Youtube配信もアーカイブとして残っているらしい。発表に至る経緯としては、仕事でGraphQLスキーマの設計に向き合う時間が増えて「楽しいけど、いろいろ難しいﾅｧ」という気持ちを雑にツイートしてたら、イベント運営のまつしまさんに拾ってもらい、そのままLTとして発表させてもらうことにした。GraphQLのスキーマ設計、だいぶ慣れてきたような気もするし、まだまだ難しい感もある。この数ヶ月、スキル的に2歩進んで1歩下がるを繰り返してる感。— うちやま (@highwide) 2022年7月29日  GraphQL Tokyo で発表してみませんか！！！— Fumiaki MATSUSHIMA (@mtsmfm) 2022年7月30日  資料は業務で難しいなぁと思った悩みどころを一般化/抽象化して書いている。また、設計やデータモデリングがわりと好きな自分にとってこういったことを職能超えて議論できる今のチームはいいチームだなぁと改めて思った。発表後は懇親会があり、自分の発表に対する共感や質問などの反響があってうれしかった。こういうの久々で楽しいなぁと思った夏の終わりだった。最後に、関係ないけど今月行った山形(鶴岡)で撮った写真。夏っぽいので。加茂水族館から海を眺める

「GraphQL Tokyo #18」でGraphQLのスキーマ設計についてLTした

2022年8月31日にGraphQL TokyoでLTした資料です。

GraphQLスキーマ設計の悩みどころ/My concerns about GraphQL schema design

この記事は Rubyist近況[1] Advent Calendar 2021 - Adventar の14日の記事です。adventar.org昨日は @takeshinoda さんの 2021年12月現在の近況 ​でした。というわけで、近況を書くぞ！"Rubyist近況 Advent Calendar"に参加している自分についてうっ...子供が生まれてからは、オフライン/オンライン問わず、あまりRubyコミュニティに参加できていないのですが...。あまりRubyistっぽいことはできていないものの、後述するとおり仕事でも引き続きRubyを書いている。最近おもしろかったRuby小ネタとしては、Google Cloud PubSubのgemを使っていて、ドキュメントによって Pubsub か PubSub かの表記ゆれがあり、「お、これはドキュメントへのcontributeチャンスかな？」なんて思っていたら、どちらも使えるようになっていたこと。## Legacy generated client namespacePubsub = Cloud::PubSub unless const_defined? :Pubsubgithub.com所属転職をしたわけではないのだけれど、2019年に転職したQuipperが親会社であるリクルートに事業譲渡した結果、自分の所属企業が変わった。web.archive.org事業譲渡と転籍は2021/10/1だったのだが、すぐさま quipper.com のドメインから jp/ 以下のページが消された結果、上のお知らせも消えてしまっていたのはちょっと笑ってしまった。というわけで、web archiveのURLを貼っている。転籍以前と以後で、関わっているプロダクトや一緒に働いてる人は変わっていない。夏頃まではRails/Go/Reactあたりの技術要素を触ることが多く、そこでチーム異動があり、以後はRailsとApollo Server(TypeScript)をGraphQL schema stichingで繋いだマイクロサービスに携わっている。転籍によって、百数十名程度の企業から連結5万人近くの大企業の一員になったことで、さすがに文化/ツール/ルール等の面で戸惑うことは多い。たとえば人事労務や社内システムに関わることなどが徹底的に専門組織に集約されていて、なにかちょっとしたことをお願いするときも決まった手続きがあることに面食らった。モノリスと分散システムの対比のように、少しくらい別の領域に関わる処理について(良くも悪くも)知ったうえで処理を書ける前者と、徹底的に決まったプロトコル/ペイロードの型で通信を行う後者...みたいなアナロジーを組織において考えられそうだななんて思ったりした。副業6月からAutifyで副業をさせてもらっている。autify.com僕のTLでも(あるいは所属企業でも)利用している記事なんかを見かけるようになったが、そちらで言及されることの多いweb向けのテスト自動ツール開発ではなく、mobile向けのテスト自動ツール開発に携わらせてもらっている。基本的には、RailsとReactで管理画面のエンハンス開発を行うことが多い。子育てなどであまり時間をとれないこともあって申し訳ない気持ちになったりするのだが、本業と別の開発現場に身を置くことによる刺激は良いなぁと思ったりする。子育て子供は今年で2歳になる。(今週誕生日だ！)妻は、今年の4月から育休から仕事に復帰し、10月からフルタイム勤務に戻った。そんな状況で家事育児を分担する必然性が増す中、僕は本業/副業ともにフルリモートワークができるのでかなり助けられている感がある。たとえば、よくある平日の時間の使い方はこんな感じだ。妻僕6:00起床(子供に起こされる)出社準備&朝食作る6:45起床7:10出社子供に朝食食べさせる&自分も食べる子供の保育園準備&自分の準備8:25保育園へ9:00家事10:00頃業務スタート18:00保育園お迎え夕飯準備→子供に食べさせる19:00業務終了&夕飯終えた子供と風呂へ子供の着替えや歯磨き20:30寝かしつけ夕飯は子供と食べることもあれば、あとから大人だけで食べることもあるし、歯磨きや寝かしつけなどは交代でやったりしている。また、業務の時間も日によって前後したりする。僕はわりと夕方〜夜くらいから仕事のギアが上がることがもともと多くて、そんなゴールデンタイムに仕事がしづらくなったのはなかなか難しい。こんな感じで共働きでなかなか大変だなぁと思いつつ、やっぱり子供はかわいいし、日々学習し成長していく姿が興味の対象としておもしろい。11月には家族で軽井沢に旅行に行った。新幹線で行けば子供が喜ぶだろうかなんて目論見がうまくいったりしてうれしかった。軽井沢っぽくないけど駅前の公園で朝遊ばせる写真2021年になってから嗜んでる趣味とかテニスご多分に漏れず運動不足なのだけれども「お前はこれまでに止めたランニングの習慣の回数を覚えてるのか？」って感じなので、「頑張りたくないときでもやりたくなる運動」を習慣化しようと、学生時代から好きだったテニスをスクールに通ってやり始めた。学生時代からやっていたと言っても、本当に生来の運動音痴でとてもヘタクソなのだけど、自分がヘタクソでも楽しめるってのはやっぱり好きなんだなぁって思う。ラケットは当初高校時代に買った20年近く前のモデルを使っていて、さすがに古すぎるのと、今の自分に合っていない(当時も憧れで買ったので合ってなかった疑惑は多分にある...)ので、とうとう新しく自分のラケットを買っちゃった！今日！princetennis.jp格ゲーこれまた下手すぎるのが恥ずかしくてあまりTwitterなどには書いてなかったのだけど、格ゲーをやるようになった。ギルティギアストライヴとメルティブラッドをやっている。高校時代に友人らがギルティギアをゲーセンでやっていて、自分も家庭用ソフトを貸してもらって友人と対戦したりしたのだけど、全っ然うまくできなかった...というのがどうやら心残りだったらしい。ギルティギアの新作が今年出ると聞いて、アケコンまで買ってしまった。「アケコンで格ゲーをやる」という行為に憧れていたんだ...。やってみるとテニス同様、自分がヘタクソだと明らかにわかるのだけれど楽しい。そもそも、身体の精密性と反射神経という格ゲーに求められそうなスキルこそ、自分が生来のコンプレックスを抱えているところなのだけれど、なぜか楽しい。ギルティはラムレザルを使っていて、メルブラはノエルを使っている。ヘタクソでも相手してやっていいよって人がいたら"対よろ"です...。(というか、教えてほしい...)Youtubeラジオやバックグラウンドビデオ的に流しているようなことが多いのだが、今年になって明らかに再生している時間が増えている...。当初は格ゲーの動画なんかを見ていた(いまどき攻略サイトじゃなくて動画なんですね)のだけど、いつの間にかレコメンドされるようになったVtuberの切り抜きなんかを見ているうちに少しずつ沼に足を進めていってる気がしなくもない。ホロライブ6期生の風真いろはさん...とても良いですね...。GR IIIxえへっえへっ pic.twitter.com/6II8hQiI0M— うちやま (@highwide) 2021年10月1日  子供を連れて近所の公園に行くときなど、「一眼をぶらさげるまでもないが、いい写真はちゃんと撮りたい」と思うようなことが増えて買ってしまった。もともとの換算28mmという焦点距離はあんまり得意じゃないと思っていたけれど、40mmと聞くと楽しい。これもGRで撮っている。ひとりで昼から振れ幅をやっている pic.twitter.com/r5dKPYa38R— うちやま (@highwide) 2021年12月5日  子供が生まれたのとコロナ禍になったのとで出不精に磨きがかかって、最近は「撮影を目的としてどこかに行く」という機会が減ってしまったなぁと嘆息しつつ、こういう新しいギアが手に入るとやっぱり楽しいのだ。久しぶりに書き始めたら、ぶわーって誰得長文を書き連ねてしまった。(僕にありがち)来年がもっと良い年になることを願って、このエントリは終えようと思います！

2021年12月近況

子要素が親要素のmax-heightを超えてscrollするときにだけ表示するComponentを書きたかったので、ある要素の高さを取得したかった。useRef でDOMの要素を参照した上で、custom hook化してあげたらきれいにまとまったのでメモ。function useElementHeight<T extends HTMLElement>() {  const heightInspectedEl = useRef<T>(null);  const [height, setHeight] = useState(0);  useEffect((...

React + TypeScriptで要素の高さを取得するcustom hook

Next.jsのチュートリアルを一通りやってみた。nextjs.orgとても丁寧に作り込まれていて、chapterごとにクイズがあったり、読み進めると謎のポイントが溜まっていったりして、学習者を飽きさせないような工夫が凝らされていた。Next.jsのチュートリアル、TypeScript化までやって終わった。仕事で使ってみて〜という気になった。I just got 550 points✨ on https://t.co/EvsSzgB2AK @vercelより— うちやま (@highwide) 2021年5月2日  また、Next自体もすごく便利そうな技術だなぁという感想を持ち、仕事で触っているCreate React App製のReactアプリとの比較なんかに思いを馳せたりした。まだそんなに確信は持てていないけど、CRAでなんか作ろうとするなら、代わりにcreate-next-appでなんか作ってもいいんじゃないかってことをまず検討してみてもよさそうだなと思った。特にCRAが隠蔽していることを細かくチューニングしようとする気が(まずは)そんなにないんだったら、いっそのことNextに乗っかっちゃったほうがより便利になったりしないだろうか...？というのが僕の雑な初見での感想だ。フロントエンドのアプリケーションを運用するようになってみて、npmを細かく分ける文化のためか、それなりにDependencyをチマチマと上げる作業がRubyやGoのプロダクトに比べて大変だなぁという思いがあって、routing機能とかlink先のprefetchとか画像のresizeとかreact-helmetにあたる機能とかが裏側で全部入りになってるようなNextは、(SSG/SSRを欲してなかったとしても)一つの選択肢になったりしないかなって思ったりした。せっかくだし何か作るかと思って、自分のホームページを作り始めてみた。https://highwide.netまだ何もなくて、全然Next.js使う意味もないのだけど、意味もなく取ったままだったドメインに使いみちができて、なんだかうれしい。何かコンテンツを増やしたいという気持ちはある。コードはここに置いてある。github.comVercelにデプロイするのは超簡単だったし、無料のままカスタムドメインの設定までできてありがたかった。

Next.jsのチュートリアルをやってみて、"ホームページ" を作り始めてみた

タイトルのとおりなんだけれども...。ejectしていないcreate-react-app製のアプリケーションで音声を鳴らしたくなって、調べたり聞いたことのメモ書き。(というか、ほぼ5t111111さんに教えていただいたことを貼っているだけである...)思考の変遷あれ...音声を鳴らすためのmp3って普通にsrc/assets/に置いたうえで、importできるんだっけ...？Webpackのbuild対象にするには、それ用のloaderが必要...？ejectしていないアプリケーションってことはwebpack.config.jsを直接触れないけど、普通にaudioファイル扱える...？とりあえずimport書いてみたけどエラー出てimportできないっぽいな雑にググったら「まずejectしよう」みたいな記事出てくるんだけど...？(若干古い記事が多い)うーんでも、ここ見るとloadできそうなんだけどなぁ...。↓            // This loader doesn't use a "test" so it will catch all modules            // that fall through the other loaders.from: https://github.com/facebook/create-react-app/blob/2d1829eaf6ff1308da00720fa9984620dd0fb296/packages/react-scripts/config/webpack.config.js#L583-L584とかTwitterに書いてたら「普通に動く」っていう情報をいただいたちょっと気になったので試してみたら普通に動くようでしたよ。こういうことではない？ pic.twitter.com/WGc6L94oV5— WAKASUGI 5T111111 (@5t111111) 2021年4月4日  いただいたキャプチャを見てみると、global.d.tsで declare module "*.mp3"; としていることに気がついて、それについて聞いてみたことへの答え↓そうですね、こういうファイルには型定義がないので、こうやってambient moduleとして型をつけてやるのはよくやると思います！素のTSプロジェクトだと全部自分でやらないと怒られるけど、CRAだと画像とかは既に型情報があるようなので、その辺で混乱しやすいのかもしれませんhttps://t.co/J86GHkbbTp— WAKASUGI 5T111111 (@5t111111) 2021年4月4日  ここで、file-loader通したbuildの対象にできてるかっていう話と、moduleのimportができるかという話を混同していてエラーを見ていたことのだとわかった。勉強になった。というわけで、できたgithub.com↑ これは何かというと、会社のチームでモブプロするときにときどき使ってるツール(OSS化されている)「mobu」へのPR。これまではドライバー交代のタイミングでブラウザのnotificationが出てきたのだけど、結構見落とすことが多いので、交代のときに音が鳴るようにしたかったのだ。晴れてマージしてもらった。ここで使えるよ→ https://mobu-waiwai.netlify.app/ちなみに「mobu」を使ってモブプログラミングするときの話などは、同僚が会社ブログに書いている。quipper.hatenablog.comおわりにたいした話じゃないかなぁって思いつつも..."create-react-app mp3" とかでググるとejectしろみたいな記事が出てくるので書いてみたglobal.d.tsの話は自分にとっては知見だったのでメモしておきたかったという感じでした。

create-react-appで作ったアプリケーションはejectしなくても音を鳴らせる

UNIXという考え方―その設計思想と哲学作者:Mike Gancarz発売日: 2001/02/01メディア: 単行本モチベーション「ひとつのことをうまくやる」「小さいことはよいこと」「パイプでコマンドをつなぐ」といった、UNIX哲学とされるものはなんとなく聞きかじったことがあって、その哲学に心地よさを覚えながら名著とされる原典をスルーしているのはなんとなくの居心地の悪さがあったので読んでみた。年末年始にかけて業務が逼迫していてあんまり読書する心身の余裕がなく、先月末に無事リリースできて以降は大きく怠惰に振れていたので、リハビリがてら薄い本を読もうとした。感想積んでた「UNIXという考え方」読んだ。原著は1995年の刊行のようで、JavaやWin95登場前夜という感じかな。その時代を知る読み物としてもおもしろいし、よく言われるように、現役の価値観のオリジンなんだなぁとも思った。自分の足を撃ち抜くとか一つのことを複数のやり方で、とかはRubyっぽさもある。— うちやま (@highwide) 2021年2月27日  その時代を知る読み物として作中で登場するプログラミング言語はアセンブリ、C言語、シェルスクリプトで、本格志向のC言語ではなくてコンパイルがいらず移植性にも優れたシェルスクリプトを使おうといったことが繰り返し語られていた。じゃあJavaはいつ頃登場するんだっけ...？と思って調べたらJDK 1.0は1996年1月だった: Java - WikipediaWindows 95登場前夜ながらも、Windows NTの時点でマーケティングに大成功していたのかなんてこともあまり知らなかった。え、ちなみにLinuxは...？と思ったら、Linuxは「1997年ごろより商用目的への応用が注目され」という感じらしい: Linux - Wikipedia...といった自分が知らなかった時代における、当時の人たちの"常識的"とされた考え方や「UNIXという考え方」がなぜ新しかったのかといった背景を知るのは結構おもしろかった。「クリーンアーキテクチャ」を読んだときにボブおじさんの昔ばなしもなんだかんだ言って楽しめたことを思い出した。感覚的には「スティーブズ」を読んでいるときに近い。スティーブズ 1 (コルク)作者:うめ（小沢高広・妹尾朝子）,松永肇一発売日: 2018/02/16メディア: Kindle版現役で通じる価値観を学ぶ読み物として上述したような自分が知らなかった時代に書かれた"古典"ではありつつも、(よく言われているように)そこに書かれた価値観が現役で通じることに改めて驚いた。「スモール・イズ・ビューティフル」「ひとつのことをうまくやらせる」「部分の総和は全体よりも大きい」といった価値観はマイクロサービスにも通ずるし、「効率よりも移植性」において重要視される移植性については現代ではコンテナという手段を得るに至ったんだなぁということを思い浮かべながら読むことができた。「できるだけ早く試作を作成させる」については、(耳が痛い)言葉通りのことだけでなく、「人間には、三つのシステムしか作れない」という話がとても興味深かった。「三つのシステム」とは、特定の機能/領域が成熟するにつれて、それを担うシステムの変遷が起こるライフサイクルのような話だと理解している。第一のシステムは、「追いつめられた人間」が作る。追いつめられているので「『正しく』やっている時間などない」。そのコンセプトは革新的なので「人間の想像力を刺激」する。第二のシステムは、「第一のシステム」の成功に惹かれた専門家たちが作る。これまでの欠点を改善すべく「正しさ」を追求し「委員会」で設計する。結果、商業的な成功を納めることも多い一方で「ぜい肉がつき、遅い」「三つのうちで最悪のシステム」となる。第三のシステムは、「第二のシステムで『火傷』した人が作る」。「ようやく『正しく』やることができる時間が与えられ」、「オリジナルのコンセプトはそのまま残り」、「第一のシステムと第二のシステムの最良の特徴を組み合わせる」。ポイントは、どうすれば第三のシステムを作れるかというと「最初に他の二つのシステムを作るしかない」というのがおもしろい。だからこそ「できるだけ早く試作を作成させる」ということかと得心した。そのうえで、僕はこれを読んで、以前の職場で関わった...創業期に書かれた、「ひどい」と言わざるをえないがたしかに事業に売上をもたらしたコード1を嫌った人たちが書いた、過度な抽象化(あるいは間違った抽象化)が施された結果、見通しが悪い(と感じる)コードそれらを置き換えるべく、事業毀損しないようにポーティングしていくプロジェクトが発足という流れを思い出した。僕は3のプロジェクトに関わった。今振り返ると、あのとき作ったものが「第二のシステム」とみなされるべきものになってしまっている可能性は否定しないものの、少なくとも1と2については「第一のシステム」「第二のシステム」と称してよさそうに思う。「3」から関わった身からすると「『1』において、もっと『正しく』作れなかったのか」「『2』において、もう少し現実的で適切な設計はなかったのだろうか」とついつい考えてしまうこともあったが、それ以上にこれらの「システム」が生まれてしまうこと自体は否定せず、そのライフサイクルのスピードをもっと上げられないか考えるというのがよりUNIX哲学的だったかもしれない...なんて振り返りを今さらした。もっと早く読めばよかったという後悔同僚はこの本を「はやく読めば読むほどお得な名著」と評していたが、その意味がようやくわかったようにも思う。「ひとつのことをうまくやる」「小さいことはよいこと」などの哲学は、あまりにも普遍的になっていることで日常で触れる機会も多く、驚きはあまりなかった。もっとこの本にガツンと頭を殴られ、UNIX哲学に麻疹のようにかかってしまう頃に触れておくべきだったという後悔を少ししつつ、今も色褪せぬ価値観のオリジン(と言っていいのかな)に触れられたことを嬉しく思う。

「UNIXという考え方」を読んだ

今までこの手の振り返り記事はあまり書いたことなかったけど、今年はやってみようかなと大晦日の夕方に思い立って慌てて書いている。大きな変化があった年だが、淡々と個人的なことばかり書くつもり。仕事今年の10月で入社して1年になった。入社前に想像していたよりも悲しい別れが多い1年ではあったけど、それでもいい環境だなぁという気持ちは変わっておらず、継続して強い人の入社もあり、日々楽しく仕事をしている。正直言って去年(つまり入社しての数ヶ月)はあまりバリューを出せた気がしないのだが、少しずつ仕事に慣れてきて、新しいことをキャッチアップしたり自分の強みを発揮したり...といったことが徐々にできるようになってきたように思う。(とはいえ今でも「このままじゃヤバい感」はある)春以降、ほぼすべての業務を自宅からやるようになって、さすがに最初は集中できないとか、同僚とコミュニケーションを取るタイミングがわからず心寂しく思うとかあったけれど、だいぶ慣れてきた。そんな中で、わかりやすく新しい技術にたくさん触れることができた。graphql-rubyを利用したRailsをReact+TSのフロントから叩くような実装や、モノリスなRailsからGoによるマイクロサービス切り出しを行うような機会が得られた。Goによるマイクロサービス切り出しはもっぱらプロジェクトが佳境の状態にあり、年末はそれなりに時間をかけて実装を行っていて、ややハードワーク感はあれど「夕食を食べながらさっきまで書いていたコードを幻視して、洗い物後、仕事に戻ってPull Requestを仕上げる」みたいなのは、そんなに嫌いじゃないんだなと思ったりした。(もちろん、自分の裁量でやっている/それを強要されない/チームに心理的安全がある/そういった期間の終わりが見えている...といった前提の上で)仕事以外の技術の話後半は家庭や仕事の状況の変化によりあまりできなかったが、知人のお手伝いでRailsを書いて、TerraformでAWSに構築して、マークアップを書くためにTailwindを触ってみたり...といったことをやれた。あとは、5月頃に「りあクト！」の読書会をよちよち.rbの友人らとやったことが、自分のReact.jsの知識の定着につながったなぁという感覚がある。また、「クリーンアーキテクチャ」や「マイクロサービスパターン」を読んでブログを書いたりといったことも、あんまりいままで自分がやってこなかったことなので、よい経験になった。(本当はもうちょっとブログ書きたいなぁって思ってたのに、前述の環境の変化で一気に習慣をなくしてしまった。この記事書いてるのはちょっとリハビリ感もある)highwide.hatenablog.comhighwide.hatenablog.com料理前半はとにかくスパイスカレー作りにハマっていた。今でも作るのは好きなんだけど、さすがに毎週作っていた今年の前半はなにかに取り憑かれていたなぁとか思う。気まぐれにモーメント作ってみた。⚡️ "highwideの「スパイスカレーを作る」"https://t.co/Uvh6h4osku— うちやま (@highwide) 2020年6月23日  スパイスカレーを作る頻度が落ちたあとも、今年はいつになく自分でちょっとした料理を作ることが多かったなぁとは思う。リモートワークで自宅にいるし「妻が子供の離乳食を作って食べさせてくれているうちに自分たちの料理を作る」といった機会が多かった。とはいってもそんなに大層なものを作るわけではなくて...リュウジさんのバズレシピ を見て作ったり、メスティンを買ってベランダで米を炊いたり、ここをキャンプ地とする(ベランダ) pic.twitter.com/uhIU0nSVaj— うちやま (@highwide) 2020年8月22日  インスタントラーメンをちょっと豪華にしたり、インスタントラーメンをさっといい感じに作るスキルが上がっていくタイプの新しい生活様式。 pic.twitter.com/0Jn2rls2Rv— うちやま (@highwide) 2020年11月9日  フードロスになりそうな食材を買ってやりたい放題したり、刺身、しゃぶしゃぶ、塩漬け、炙り、漬け、カルパッチョにした。ちょっと頑張った。 pic.twitter.com/hbes7FnTNF— うちやま (@highwide) 2020年11月29日  ...といった感じだった。子育て昨年末に生まれた第一子の息子が1歳になった。毎月の月齢フォトを撮っていたのだが、見返すとやはり感慨深い。子育てをしてみて驚くことはたくさんあるけれど、何よりも驚くのは「子供って何かが突然できるようになるんだな」ということ。昨日まで寝返りができなかった、つかまり立ちができなかった、いただきますができなかった...そんな子供が突然今日できるようになる。誰かから手取り足取りやり方を教わったわけではないのに...というのがおもしろい。また、リモートワークしていることで、そういった「何かができる」瞬間にたくさん立ち会えたことがうれしかった。台所に入らないよう置いたウォーターサーバーの水につかまって調理を監視する様子写真そりゃそうだけど、近所で撮った写真が多かった。人様に迷惑かけないようにしつつペルセウス座流星群を強行軍で撮影に行けたのはよかったな。反面、天気を理由にネオワイズ彗星を諦めてしまったのは本当に心残り。レンズは以下の3本を買った(買ってしまった)SEL85F18(Sony 85mm f1.8)SIGMA 100-400mm DG DNSIGMA 35mm f2 DG DN来年のこと世の中が落ち着くことを心から願いつつ、妻の復職や子供の保育園入園(させてくれ...頼む...)といった大きな環境の変化を乗り越えて、家族の健康と自身の成長のために行動していきたい。

2020年個人的振り返り

マイクロサービスパターン［実践的システムデザインのためのコード解説］ impress top gearシリーズ作者:Chris Richardson,長尾高弘,樽澤広亨発売日: 2020/03/23メディア: Kindle版この本を読むまでの経緯クリーンアーキテクチャを読んだ記事でも書いたように、仕事でマイクロサービスの導入検討(どの粒度でサービス化するか、など)を行っていて、自分があまりにも「Railsでモノリスを作る」以外の選択肢について疎いと感じていたこれまた前のエントリにも書いたが、そんな中で上司の id:gohan_pan_gohan (何このはてなid....)もこの本を最近読んでいる旨を1on1にて話してくれて、自分も読むことにした一方で「クリーンアーキテクチャ」に書かれているような内容が前提となることも聞いていたので、先にクリーンアーキテクチャを読んでいたこの本について原著は「Microservices Patterns: With examples in Java」のタイトルで2018/11/27に出版されていて、日本語版は2020/3/23に出版された著者のサイトである https://microservices.io/ を基にしながら、架空のフードデリバリーサービス( Uber Eatsっぽい感じ)の設計/実装を検討してくいく「マイクロサービスにおける○○」がひたらすらの500ページ超のボリュームで語られていて、マイクロサービス設計/実装における勘所を体系的に学べる感想「マイクロサービスパターン」がおもしろすぎる。"自分が理解できるレベルの全然知らなかったこと"がめちゃくちゃ載っている。— うちやま (@highwide) 2020年8月28日  いま見返すと「理解できる」(理解できるとは言ってない)くらいに捉えてもらったほうがよさそうではある(逃げ腰)ただ、本当に笑っちゃうくらい知らないことが多かった。たとえば: サーガについてモノリスで実現できていたRDBMSのトランザクションをどうやってサービス分割後に担保するかというのは、読む前からの気になりどころだったのだが、これに対しては「サーガ」というテクニックが紹介される。(余談:redux-sagaのsagaってそういうこと...？)サーガは、1つのトランザクションでやりたかった処理が複数のサービスに散らばってしまった場合に、サービスごとのトランザクションを1つの「サーガ」という風に捉え、仮に個々の処理が失敗した場合は個々のサービスで「補償トランザクション」を実行することでロールバックするような仕組みと理解している。このとき、これらの個々のトランザクションをコーディネイトする責務をどこに持たせるかによって「コレオグラフィ」と「オーケストレーション」という2種類の作り方ができる。ただし、サーガはACID特性のうちIsolation(分離性)はサポートできないので、Lockなどの対処手法(countermeasure)を用いていく必要がある。microservices.io...と、やろうとしていることは理解できる(というか、わりと泥臭くやらなきゃいけないんだなという思いを新たにする)のだけれども、聞き馴染みのないキーワードによってそのパターンが既に一般化されていることを知る...というのがこの本で学べるおもしろさだった。たとえば: Transaction log tailingパターンについて非同期メッセージングやその一種であるPubSub自体は業務でも使われているシーンを見ていたり、その概念を理解しているつもりだったが、Transaction log tailingパターンというものには驚いた。この技術が解決したい問題は以下のようなものだメッセージのPublisherは「メッセージのPublishと、そのサービスのためのデータ保存とを、1つのTransactionの中で行いたい」(=メッセージ送信とDBの保存の部分成功/失敗を許容したくない)ケースがあるそのために、メッセージキューとしてDBに作成した「OUTBOX」というTABLEを利用することで、キューの更新とドメインモデルの保存をRDBMSトランザクションの中で行える、とうTransactional outboxパターン*1というものが存在するこのパターンを利用した場合、メッセージブローカーへのパブリッシュ自体は、OUTBOXテーブルの情報を取得するコンポーネントが必要になるシンプルにやるならばOUTBOXテーブルにSELECTクエリでポーリングするコンポーネントを用意すればいいが、場合によってはDBへのポーリングするコストが無視できないことがあるそこで、RDBMSが吐くトランザクションログ(コミットログ)をテーリングして、変更を検知し、メッセージブローカーへのパブリッシュを行う画像は micorservices.io - transaction-log-tailing より僕の直感からすると「ログ収集とかそういうレベルでなく、アプリケーションがRDMBSの吐くログに直接依存している...って大丈夫!?」って思ったりもしたのだが、世の中にはそれを実現するためのDebeziumやLinkedIn Databusといったツールが存在していることも紹介されている。さらにこの技術と相性がいいのが「CQRS」であると紹介されていて「えっCQRSってこの文脈で出てくるの？」といった驚きもあった。「マイクロサービス」と「分散システム」正直に言うと、上に挙げた技術やその他本書で紹介されているテクニックは、自分の日常業務にすぐさま取り入れたいと思う類のものだけでなく「そこまでやるの？」と感じるようなものも少なくない。ただ、これまで「マイクロサービス」という言葉を日常的に口にする中であんまり意識していなかったことだが、本書を通じて「Microservices」とは結局「分散システム」なのだということを肌身に感じることができた。「自分たちのWebサービスのためのマイクロサービスではそこまではやらなくていいでしょ」とコストパフォーマンスの天秤を眺めている傍らで、高度な分散システムに続く道のりが続いていることを意識できたのは、すごく良かったと思う。その上で、この本のスタンスも「はじめに」で書かれている通り本書はマイクロサービス宣言ではありません。本書は、パターンのコレクションを中心として構成されています。(中略)パターンのよいところは、ソリューションの利点を説明するだけでなく、ソリューションの欠点やソリューションをうまく実装するために対処しなければならない問題点なども明らかにするところです。とあるように、読み手に「分散システム全部盛り」をいついかなるときも要求するものではない。自分の当初のモチベーションを満たす上でも、現実の業務に当てはめるためのパターンを「API合成」「テスト」「デプロイ」「セキュリティ」等々の面から学ぶ事ができた。GraphQLやKubernetes/Istioといった業務に直結しそうな技術の詳細な紹介もあったりして、マイクロサービス時代のWebアプリケーション開発を総ざらいできる本、とも言うことができるかもしれない。その他の雑感サンプルコードがJavaで、著者の自作フレームワークが登場しがちなので、せっかくの実装例は目が滑りがちだった...。いざ自分が実装するときには読み返すことになるかもしれない。日本語版の出版は2020年だが、原著は2018年なので、紹介されているツールは既に別の技術に取って代われられているように思えることもあった。「マイクロサービス時代のWebアプリケーション開発を総ざらい」と上で書いたが、賞味期限が短い箇所もそれなりに多そう。各パートごとに紹介されるツールのNetflix率の高さよ...。よく知られるchaosmonkyが"壊してまわる"のは、こんな分散システムだったのかなという思いを馳せた。(思い出して追記) クリーンアーキテクチャを先に読んでたおかげで、こういう学びもあってうれしかった「クリーンアーキテクチャ」の次に「マイクロサービスパターン」を読み始めて「何か1つ修正したいときに、複数サービスを修正する必要があるのは設計が良くない」っていうのが閉鎖性共通の原則で説明できることがわかって、クラス/モジュールの話がサービスに適用できるじゃんとうれしくなった。— うちやま (@highwide) 2020年8月21日  *1:Transactional outbox

「マイクロサービスパターン」を読んだ

勤務先はこれまで「出社推奨」というスタンスだったが、コロナ禍になってからは徐々にリモートワーク前提の文化/制度/オフィスの設計がなされるようになり、3月頃からはほとんどの業務を自宅で行っている。*1昨年の10月に「子供が生まれる前に、お互いの実家により近くなり、間取りも広くなるような引っ越しをしよう」と決めて今の賃貸マンションを選んだ結果、幸いにも今は仕事部屋にあてがうことができる部屋が一室あり、僕はもっぱら平日の日中をそこで過ごしている。(去年の秋にはこんなに自宅で業務をすることになるとは思っていなかったので、本当に僥倖だった...)さて、そんな仕事部屋(かっこいいという理由で「書斎」と呼んでいるので、以後そう表記する)の環境についての話。8月が終わってだんだん涼しくなってきたので日中クーラーを切ることが増えてきた。書斎の窓はマンションの通路と面しているので、ミーティング等で発話するようなタイミングでは窓を開けておくことがはばかられる。そのうえで、最近のチームの働き方としてオンラインでのモブプログラミングをすることが頻繁にある。...というわけで、必然的に「クーラーをつけていない × 部屋を閉めきっている」という状況が増えてきた。その結果がこれ。今日仕事中に妙に疲れを感じて休憩とったら気絶するかのように椅子で寝落ちしちゃったんだけど、今思うと二酸化炭素濃度のせいな気がする。(クーラーつけてた部屋が寒くなってきたから、窓閉め切ったままクーラー消してた)— うちやま (@highwide) 2020年9月2日  なんでいきなり二酸化炭素濃度に当たりをつけているかというと、こういう記事もあるし、news.yahoo.co.jp前職のオフィスにおいてもそんなことが問題になっていて、Netatomoで計測して、Redashで可視化するということをやっていた人がいたから。上の記事にもあったけど、厚生労働省によると「二酸化炭素の含有率」は「100万分の1000以下（＝1000 ppm以下）」を基準としている。www.mhlw.go.jpというわけで、室内の二酸化炭素濃度を可視化して換気を促すような仕組みを導入したい〜〜と思って二酸化炭素濃度モニターを調べてみたのだけれども...IoT的な仕組みがないつまり、計測値を自分で都度目視しなければいけない「やべぇ...息苦しい...そういえば、二酸化炭素濃度は...？ウッ、この濃度なら30分前に換気すべきだった...」となりたくないというわけで閾値を超えたら通知を送ってほしい思ってたよりも結構お高いNetatomoは25,000円程度 単純な計器でも10,000円以上することがざらといった感じでで、どうしたものか悩んでいた。そこで、自宅で転がっていたRaspberry Pi 2を利用できないか考えてググったところ、先人たちの知恵が見つかった。dev.classmethod.jpqiita.commh-z19というセンサーをRaspberry Piに接続することで二酸化炭素濃度が取れそうだとわかる。センサーはAmazonで3000円程度、ということでポチッ。ただ、センサーが届いてみて、あれ？これRaspberry Pi接続するのに他の部品が必要なのでは...？とジャンパーケーブルやらピンヘッダーやらを買い足したうえ、最終的にはんだ付けしないといけないことに気がついて、はんだ付けキット一式までを買ってしまった😇*2そもそも名前がわからないと買えない、の図↓*3【だれかおしえてもらえませんか】二酸化炭素濃度を測るセンサーと、ジャンプワイヤーを買ったんですが、センサー側の穴とジャンプワイヤーのメスをいい感じに繋ぐためのこのアダプターって、なんていう名前か誰か教えてもらえませんか...？(探したいけど名前がわからない問題) pic.twitter.com/P7gUzQn7Pb— うちやま (@highwide) 2020年9月3日  で、なんとか接続がうまくいって、先ほどのQiitaの記事の方が作ったpipを利用してco2濃度が取得できるところまでできた、図↓とりあえずRaspberry Piで二酸化炭素を計測できるようにした... pic.twitter.com/GXPUt6l7pz— うちやま (@highwide) 2020年9月9日  最終的に、厚労省が基準にしている1000ppmを超えたら、家庭用のSlackに通知がいくようにしたかったのでちょっとしたスクリプトを書いた。github.comただまぁ、パブリックなコードにしたものの、これが本当に人様に見せられるようなコードではなく、最低なんだよな...という図↓今日書いたひどいコード...見て... pic.twitter.com/GUgYWDN4jC— うちやま (@highwide) 2020年9月12日  とはいえ、無事に閾値を超えたらSlack通知がされる仕組みは整えることができた。やったー！とりあえず今はセンサーがむき出し*1:ちなみにチームの人が、リモートワーク中の働き方の様子を会社のブログに書いてくれている。リモート環境でも同じように楽しくやりたい！（前編） 〜2020年度Coaching チームのリモートふん闘記〜 - Quipper Product Team Blogリモート環境でも同じように楽しくやりたい！（後編） 〜2020年度 Coaching チームのモブプログラミング、オンボーディング事情 〜 - Quipper Product Team Blog*2:以前自作キーボードを作ったときは、前職の同僚にはんだ付けキット一式借りた*3:画像は上に挙げたクラスメソッドさんのブログから

仕事部屋の二酸化炭素濃度をRaspberry Piで測定するようにした

タイトルのとおりなのだけど、仕事でちょっとハマった話。特定3種類の値だけを利用するフィールドを追加したくて、Railsのenumは使いつつ、DB上でもenumで型定義しておけば"固い"よなと思って、そういうテーブル定義をしようとした。このあたりは前職のMySQLのテーブル定義においてそういうカラムがよくあったので、まぁポスグレでもできるだろうという感覚で調べ始めた。軽く調べてみると、以下のような記事(翻訳もあった)があったり、naturaily.comRailsGuidesにも「Active Record と PostgreSQL」のページに「1.7 列挙型（enumrated type）」の記載があった。railsguides.jpenumの型定義自体は create_table などのDSLの中でできず、execute <<-SQL  CREATE TYPE article_status AS ENUM ('draft', 'published');SQLと、SQLを直接実行しているが、これがよく行われているやり方なのかなと理解した。自分もそのように書いてみて db:migrate と db:rollback が問題なく実行できることを確認したのだが、あとからschema.rbに以下のようなメッセージが生成されていることに気がついた。# Could not dump table #{TABLE名} because of following StandardError#   Unknown type #{enum用に定義したtype名} for column #{enumを使いたかったカラム名}というわけで、上に書いたようにRubyのDSLでPostgresのenumが定義できないために、schema.rbも生成できないと理解した。あとから気づいたが、close済のissueもあった。github.comschema.rb can't support a few database specific constructions. You need to change the format to sql if you want to use those features.とのことで、schema.rbでなくstructure.sqlを利用するようにしてあげれば、こういったmigration用のDSLで表現できないTABLE定義も利用できそうだ。もしstrucuture.sqlを生成したいのであれば、config.active_record.schema_format を :ruby ではなく :sql に変更すればよい。railsguides.jpただし言わずもがな、ActiveRecordの抽象をひっぺがして特定RDBMSへの依存を高めることにはなるので、プロジェクトでの利害は考えた方がよいと思う。

RailsのmigrationでPostgreSQLのenumを使おうとするとschema.rbが生成できない

7月超望遠レンズを買った妻「定額給付金でレンズを買うのはこの際いいとしましょう。私が心配なのは、あなたが『これは実質無料だったから』と言いながら、調子に乗って短期間のうちに次のレンズを購入するような、”レンズ購入癖”がつかないか、ということです」— うちやま (@highwide) 2020年6月26日  こんな話をした末に、SIGMA 100-400mm DG DNが生えてきた。我が家も定額給付金がとうとう届きましたー！！！ pic.twitter.com/qF3SQxbQ7Z— うちやま (@highwide) 2020年7月11日  これまで所持していたズームレンズは、常用しがちなTamron 28-75mm/f2.8と、もっぱら星撮り用のSIGMA 14-24mm/f2.8で、次はSIGMA 70-200mm/f2.8で大三元ツモか...なんて思ってたのだけど、なかなか出る気配がなく、「そもそも自分が撮りたい写真は200mmの先にあるのでは？」なんて謎のことを考え出していた矢先、70-200mm/f2.8をすっ飛ばして100-400mmが給付金価格で出てきたので飛びついてしまった。ちなみに「200mmの先にある撮りたい写真」は、圧縮効果の効いた風景写真や、近くの公園にときどき現れるカワセミ...あたりを考えていた。ご近所スナップ今年の7月は梅雨がなかなか開けず、コロナ禍での生活様式と相まって、晴れ間を狙って近所でスナップを撮るにとどまった。SEL50F18Fでの2枚。今回購入したSIGMA 100-400mm DG DNでの2枚。購入した望遠レンズは、おもしろいながらも使いこなすには至らなくて「望遠でf値が暗いレンズを使って絞り優先/ISOオートで撮ってると、こんなに簡単にISO上がっちゃうのか...」という点には今もまだ四苦八苦している。7月はそんな感じで天気にも恵まれなかったのだが、それを理由にネオワイズ彗星の撮影をあきらめてしまったのが今でも心残りで、毎日の天気をチェックしながら晴れた場所を狙って多少遠出すればよかったと思っている。8月基本的には7月と同様で、近隣での写真撮影をしていた。これはベランダから。月がきれいだったので、400mmで2分毎のインターバル撮影して、比較明合成。 #SIGMA pic.twitter.com/TOBkGldigC— うちやま (@highwide) 2020年8月2日  あとから、レイヤーの優先度が逆だったと気がついた。ペルセウス座流星群近隣で撮影をするも、ネオワイズ彗星を諦めた心残りからか別の天文ショーをなんとか見に行きたい気持ちが高まり、8/12の極大に合わせてペルセウス座流星群を撮りに行った。SCWで直前まで天気を確認していたところ、関東圏では房総半島の南端までいけば極大の頃に晴天となる可能性が見込めそうと考え、カーシェアの車で野島埼灯台まで行った。きてみた pic.twitter.com/7LuLThuVOK— うちやま (@highwide) 2020年8月12日  「極大の時間は、最大で1時間に30個ほど流星が見られる」といった前情報も目にしていたが、生憎、日没からの6時間ほで肉眼で確認できた流星が十数個程度だったと思う。また、流星が見えても、レンズを向けた先とは別の方向で「ぐぬぬ、あっち向けておけば...」なんてやきもきすることも多かった。ようやく今のは画角に入ったのでは？という流星があったとしても、撮影できた写真をディスプレイで確認しても写っておらず、首をひねりながら撮影を続け、0時頃に撤収した。流星群を狙って撮影したことは何度かあったものの、これまで流星の撮影に成功したことはなく、とはいえ、装備や知識の面で今回が一番充実していたのでそれなりに残念ではあったが、まぁ天の川は撮れたからいいとしよう...そんな考えで帰路についた。天の川。現地には流星群を見に来た人や同好の士たちが最終的には数十名ほど人がいたように思うのだが、感染リスクを下げるために適度に距離を取って岩場や通路に散っているのが、2020年の流星群らしい思い出と言えそうだ。なお、感染リスクを可能な限り下げようとすると、ろくに旅先にお金を落とせないんだなと感じた。(食事もコンビニで買って車で済ませた...)ところが、帰って撮影データをPCで確認してみると「流星撮れてるじゃん！！！」という嬉しい驚きがあった。今回、少しでも画角に流星を入れるべく14mmという超広角で撮影していたのだが、それだけ広い画角だと、現地でカメラのディスプレイでパッと見てもわからない程度の細い軌跡になっていたようだ。これは日没直後に撮れたので、いわゆるブルーモーメントに流れる流星となった。こちらはガスが出始めて、諦めて帰る間際に撮影できた。写真は全てSIGMA 14-24mm DG DN Artで撮影した。撮影準備/構図や画角/現像等々の面において、まだ工夫する余地はあると感じるが、ひとまず初めて流星のその軌跡を写真に収めることができて、すごく嬉しい。カワセミ昨日の夕方、とうとう近所の公園でカワセミを撮影できた。ただ、運動不足解消のための散歩の傍ら、ダメ元でカワセミがいないかと望遠レンズをリュックに忍ばせたものの、夕暮れどき日陰での野鳥の撮影はかなり厳しいものがあった。この写真はISO12800だ...。撮った写真を振り返りながら、そのときの状況や心境を言語化するのはなかなか楽しいことがわかった。世の中が落ち着いて、写欲が満たされるシーンともっとたくさん出会いたい。

ペルセウス座流星群など、7月〜8月に撮った写真

薄々気がついていたけれど、自分は、大小を問わず"失敗"することを嫌う気質があると、最近ハッキリと自覚できた。そして、これがWeb開発という領域において、致命的と思えるほどに悪癖になりうると気づきつつあって、向き合うためにここに書いてみようと思う。きっかけは、TerraformによるAWS Fargateの構築でうまくいかなかったことがあり、人に相談してみたところ「とりあえずタスクを手動で実行してみたらどうですか？」と言われ、「え、そんなことしていいんだっけ？」と臆してしまったことにある。彼から「いま失敗すると何か困ることあるんでしたっけ？」と言われて、確かに、まだそのプロダクトは本番環境で稼働しているわけではないので実害なんて出るわけないことに気がついた。こんなことわざわざ言語化するまでもないのだが、現代のWeb開発において、失敗することによって得られるエラーはフィードバックの宝庫だ。実際この件についても、細かく手動での実行を行い、そのエラーメッセージを見てのトライアンドエラーを繰り返すことで、なんとか不慣れな構築を行うことができた。解決のための技術的なアドバイスに加えて、「フィードバックを得るために"早く失敗すること"を心がけるべき」と助言をしてくれた彼には感謝してもしきれない。これ以降、くだらないことでも失敗を極度に嫌う自身の思考を省みることが増えた。料理やってて、レシピの工程を1つ飛ばしたことにあとから気がついただけで、必要以上に落ち込んだり。(別に味の違いはなかった)最近やってたゼノブレイド(RPG)、全滅によるデメリットがほぼない(最寄りのランドマークに戻されつつ、得られたアイテム/マネー/経験値は減らない)のに、ちょっとリスクある敵との戦闘はすごく消極的になってしまったり。そして、こういう自分に気がついては「これくらいの失敗を恐れるべきでない」なんて理性的に考えたりする。「失敗を恐れるべきでない」なんて手垢がついた言葉、こんなに自分が実践できていないだなんて思っていなかった。また、ただ失敗するだけじゃなくて「早く失敗する」というのがより大事で、それを実現するには技術が必要だというのも感じている。安全に早く失敗することには、リカバリが効くように影響を局所化しつつ、有効なフィードバックを得る方法を考える必要がある。たとえば、アプリケーションの設計は実際に運用してみないと良し悪しがわからないことが多いので、早く失敗するにはどの機能なら影響が小さいかどうすれば速やかに元の状態に戻せるか何の指標でフィードバックを得られるかどういった手段でフィードバックを得るかといったことに向き合うことになる。これらを考えることは、長期的にメンテナンス可能なアプリケーションを設計するのと同じくらい重要なことと感じる。こういった思考のクセみたいなものは一朝一夕では直せないとわかりつつ、こうやって言語化して向き合うことでもうちょっとマシになったらいいな。

自分にとって苦手だけどもっと訓練すべきと最近思ったこと: 「早く失敗する」

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘発売日: 2018/08/01メディア: Kindle版読み終えた。良い本だったと思う。この本を読んだモチベーションGoで書かれた簡素なレイヤードアーキテクチャによるマイクロサービスを会社で触る機会があったり、新たなサービスの切り出しを検討していたりして、Rails以外のサーバサイド設計についてもっと知見を深めたかった。そんな中で、上司との1on1で「マイクロサービスパターン」を紹介してもらい、その本を読む前段の読み物としてよさそうと感じた。「Design It!」を社内の読書会で読んでいて、アーキテクチャ関連の本をほかにも読みたかった。僕はこう読んだ例の"同心円状(玉ねぎ)のアーキテクチャ"(= "クリーンアーキテクチャ")の話以上に、その前提になっている「設計の原則」が重要に思えた。SOLID(単一責任の原則 / オープンクローズドの原則 / リスコフの置換原則 / インターフェイス分離の原則 / 依存関係逆転の原則) を、通しで学べるのがよかった。そのSOLIDの考え方を、コンポーネントレベルの議論に押し広げることで、より大きな粒度での設計を考える示唆が得られたこれらの考え方自体は"クリーンアーキテクチャ"を採用していなくても重要と感じる(たとえば、Railsでちょっと込み入ったことするときとか)同心円状の"クリーンアーキテクチャ"は、SOLIDを遵守するための1つのテクニック、という位置づけで捉えるのが自分にとってはちょうど良さそうに思えた。「設計の原則」での学び: たとえば"DIP"における気付き自分は"DIP"と"DI"を混同していたことに気がついた。「DIP: Dependency Inversion Principle」(依存関係逆転の原則)「DI: Dependency Injection」(依存性注入)DIはたとえば、以下のようなコードをclass Foo  def foo    bar = Bar.new(params)    bar.call  endendこのようにするようなテクニックと理解している。class Foo  def foo(something_like_bar)    something_like_bar.call  endendこれによって、Fooクラスは、自分が依存しているBarクラスの存在や、その生成の方法を知らずに済む。FooにBarという依存を注入した結果として、FooにBarFoo内でBarをnewするような"従来型の依存関係"に対する逆転をもたらす...つまり、"DI"は"DIP"のための手段だと理解できた。その上で、この考え方をクラス間の依存ではなく、マイクロサービス間の依存に適用できないかと考えて、社のチャットにあれこれ書いていたら同僚の @qsona から有益なツッコミをもらった。つまり、"DIP'が指す「従来型の依存関係の逆転」とは「"実体への依存"から"IFへの依存"への転換」という指摘だ。上の例のように「Barクラスという実体」ではなく「 call メソッドを呼べるIF」への依存への転換が、依存性の逆転を実現する。とすれば、マイクロサービスにおいても「サービス間で定めたIFを守っていさえすれば、対向サービスの実体を問わない」という考え方ができそうだ...。と、気がついたところで、それってわりと普通のマイクロサービス間の関係だな、あぁこれがサービスを疎結合にするマイクロサービスのメリットなのかぁ、って当たり前のことに思い至ったりした。同心円状の"クリーンアーキテクチャ"についてhttps://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg正直に言うと、これは本で語られるほど、いついかなるときも採用できるアーキテクチャではないのかなという印象を受けた。この本では、繰り返し、DBやWebフレームワークといった"詳細"についての決定を遅延した経験やそこで得られるメリットが語られる。(ちなみに、"詳細"は"detail"の訳語で、"detail"には"些細"というニュアンスが含まれる旨が書かれていた)ただそれは、現代のWeb開発においては必ずしも美談にならないのでは...という感想を抱いた。たとえば、yasaichiさんの以下のスライドでは、Hanami(クリーンアーキテクチャを採用したRubyのWebフレームワーク)とRailsを比較しながら、密結合の功罪について明晰に語っている。 speakerdeck.comあるいは、フロントエンドにおいても以下のエントリをきっかけにFirebaseを隠蔽すべきかという議論が盛り上がったことが記憶に新しい。blog.ojisan.ioこれらの議論は、現代のWeb開発においては"クリーンアーキテクチャ"が否定するような特定フレームワークやデータストアとの密結合を利用したいシーンがそれなりにあることを示唆している。スタートアップにおいて素早くトライアンドエラーを行いたいときなど、意図して密結合を選んだうえで初速を得る選択肢も持つ必要があると思えた。...何より、著者のアンクルボブ自身が以下のように語っている。「アーキテクチャ？御冗談を。これはスタートアップだぜ。アーキテクチャに時間をかけてる余裕はなかった。とにかくコードを書くんだ！コードがすべてだ！」-- Robert C. Martin, 角征典, 高木正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計(第VII部「付録」-「明確なコミュニケーション」)とはいえ言うまでもなく、"クリーンアーキテクチャ"を全否定したいわけではない。特に、業務ドメインのシステム化が主眼となるエンタープライズの現場においては、ステークスホルダーの意思決定やが遅延したり、各種の政治的判断に振り回されがちな中で、"些細/詳細"な意思決定を遅延できるアーキテクチャというのは大いに価値がありそうに思える。もちろん、Web事業開発においても、トライアンドエラーのフェーズを経て、ユースケースやオペレーションが安定しているシステム化したいドメインがある程度はっきり見えていて、かつ、それなりの規模になりそう。数年以上のスパンでの運用がもう見えているといった状況にはフィットしやすいだろうなと思う。この本との向き合い方本著のまとめにあたる「第34章 書き残したこと」は、(なぜか)主著者のアンクルボブではなく、Simon Brown氏が筆を執っているのだが、アンクルボブがこれまで書いてきたことを大筋認めながら、ややバランスを取るような発言も目立つ。使える選択肢は可能な限り残しておきたいが、理想に走りすぎてもいけない。チームの規模やメンバーのスキルやソリューションの複雑さ、そして時間と予算の制約などを考慮しよう。-- Robert C. Martin, 角征典, 高木正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計(第VI部「詳細」- 第34章「書き残したこと」-「まとめ：言い残したこと」)また、「訳者あとがき」でもこんな言葉があったりする。ビジネスドメインに関係のないことは「詳細」と割り切り、デリバリーの仕組みやフレームワークなどをすべて後回しにしようとする。おそらく異論のある方もいらっしゃるだろう。私もすっきりしていない。-- Robert C. Martin, 角征典, 高木正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計(「訳者あとがき」)何度もアンクルボブが言い方と持ち出すエピソードを変えながら力強く主張してきたことに対して、同じ本の中で別の人がこんな発言をする懐の広さに驚いた。そんな旨をツイートしていたら、t_wadaさんがレスをくれて、自分の感じていたこの本との向き合い方について見事に言い表してくれた。34章と訳者あとがきはポイント高いですよね。『Clean Architecture』はボブおじさんがドヤりつつ言っていることを鵜呑みにせず、散りばめられている良いエッセンスを吸収していく距離感が大事な本ですが、一冊の本の中でそれを実現しているバランス感が印象に残りますね。— Takuto Wada (@t_wada) 2020年8月8日  ...というわけで繰り返しにはなるが、僕はこの本をこう読んだ。結局、"クリーンアーキテクチャ" も適材適所で利用すべきその採用とトレードオフになるものを頭に置きながら「"クリーンアーキテクチャ"の採用」自体も適切に遅延したい一方で、下敷きになっている原則には、クラス/コンポーネント/サービスという相似形において、適用しやすい有効なテクニックが多い

「クリーンアーキテクチャ」をこう読んだ

Quipper社内の「ゆるいRuby LT会 Vol.1」でやった資料です。

About Rails ConnectionPool

このエントリで書いてないことRubocopというgem名についてこのエントリを読んでその点について議論したくなるかもしれないけど、筆者が書きたいわけではないことプロジェクトにRubocopを導入するかどうかこのエントリで書くことこのツイートに至った経緯と、その上での自分の考えを書く。「Rubocopを採用しない」と決めたプロジェクトなら「Rubocopが指摘することは(少なくともStyleレベルの話なら)人間が指摘するべきでない」って思ってたんだけど、結局この考え方に従う限りメンバーは「どういうことをRubocopが指摘するか」を知っている必要があるので、僕が理不尽なのかもしれない。— うちやま (@highwide) 2020年6月24日  現職での前提基本的にRubocopを採用しないプロジェクトが多い。理由はいくつかあるんだろうけれど、基本的にはこういう話なのかなって思っている。たとえばですが...「Rubyのように多彩な書き方を良しとする文化がある言語において、"さすがにこれは実害がある"という書き方を自然と避けられる程度に習熟したメンバーが集まったチームなので、画一的な書き方を強制されるよりは、個々人の書き味を優先したいから」だったらどうですか？— うちやま (@highwide) 2020年6月24日  あるいは「Rubocopが指摘するような事柄の中には画一的に決められるものだけでなく、都度どのような選択をとるべきか考えることに心血を注ぐべきだから」といった考え方があったという話も耳に挟んだ。これらのスタンスに対する自分の意見としては、これらの考え方は、基本的には自転車置き場の議論になりやすいCop、特にStyleやLayoutに対するものが多いと思っているそれらのCopを全てdisableにしたとしても、Rubocopで得られるものはそれなりにあるのではないか(SecurityやLintのCopなど)ただし「じゃあどのCopをdisableにして、どのCopをenableにするのか」のメンテや、メンバーの考え方のすり合わせにコストがかかるのは理解できるので、一律で導入しない選択も全否定しない特にOwnershipがあいまいになりがちな共通ライブラリであれば、関わる人数の多さからそのコストが大きくなってしまうことは想像に易い前職では厳し目のconfigによるRubocopに馴らされていたこともあり、導入したくないメンバーが多い現職に戸惑っていたのも正直な本音としてあるのだが、それでも導入するコスト/リターンと、導入しないそれとを勘案したときに、現状の結論に至っていることについての一定の理解はあったつもりだ。少なくとも、現状の採用していないプロジェクトに後から導入するコストは大きいだろうなと思っていた。(rubocop_todo.ymlみたいなテクニカルな解決ができる話というよりは、メンバーの心理的な話が大きい)というか、前職ではRubocopの推奨するStyleに異論唱えがちだったのは僕だったんだよな。本題: 今日あったことRailsで書かれたコードのちょっとした修正をするのに Time.current という書き方をした。 ActiveSupport::TimeWithZone を利用した現在時刻の取得だが、この書き方についてはほぼ手癖だったと言っていい。このPRにおいて、同僚から Time.zone.now に変更するCommit Suggestionをもらった。自分の理解ではこれらのメソッドは等価だと思っていたので、単なるStyleの違いをどちらかに揃えるよう指摘されたのか聞き返した。...いや、もっと正直に言います。「Rubocopを導入しない」ということは「Styleの違いを許容する」だと思っていたので「そういうことの指摘はしないでほしい」っていう態度を示しました。ごめんなさい。それに対する同僚からのレスとして、自分が入社する前に書かれた「時間に関する緩やかな指針」という社内ドキュメントを提示してもらった。曰く、Time.current は使わないようにした方がいいTime.currentは内部で「 Time.zone がなければ Time.now を使う」という挙動をとるRailsアプリケーションを書いている限り間違いは怒らないが、時間ほど重要なものであれば、念を入れるに越したことはないといったことが書いてあった。参考: https://github.com/rails/rails/blob/6a033a06855f0b7a407ff8edbfc9f9aa45527edc/activesupport/lib/active_support/core_ext/time/calculations.rb#L38-L40このことについて僕は知らなかったので、できる限り Time.zone.now を使うべきという指針は一理あるように思えた。(とはいえ、明らかにRailsってわかってるならどっちでもよいんじゃないかなって気持ちも、正直ちょっとはある)ただ、New Joinerが目につきにくい場所に"指針"があるのは望ましくないように思えるし、今後は自分も含めて Time.current って使われてるの見たら都度コメントしなきゃいけないのかな？みたいなことが頭をよぎって、当初は素直に受け入れにくかった。あるいは「だったらRubocop導入すればいいんじゃないかな」って気持ちになったのも事実なんだけど、冒頭書いたように、このエントリで「Rubocopを導入すべきか」を議論したいわけではない。今思えば、これは「Rubocop導入しないことで発生したコスト」なので、「このコストを払うくらいなら、Rubocop導入するコストを払ったほうがいい！」「なんなら、俺が頑張ってそのコストを引き受けるから導入しよう！」って言うんだったら誠実だよなーと思っている。はい、そのとおりですよね...↓ああ、でも想像すると、その次に出てくる言葉は「いやでもLinter入れるほどの話ではないよね」な気もしました。多彩さの保守というよりコスパの観点強めですが— アルミ軽量物干しシンプルタイプ (@terrierscript) 2020年6月24日  で、このツイートに至る「Rubocopを採用しない」と決めたプロジェクトなら「Rubocopが指摘することは(少なくともStyleレベルの話なら)人間が指摘するべきでない」って思ってたんだけど、結局この考え方に従う限りメンバーは「どういうことをRubocopが指摘するか」を知っている必要があるので、僕が理不尽なのかもしれない。— うちやま (@highwide) 2020年6月24日  たとえば、僕はなんとなく今回の件は「きっとCopでなんとかなるだろうな」っていう感覚があったから、それならRubocop使えばいいのではって考え方に走るのだが、指摘をしてくれた同僚は知らなかった。参考までに、rubocop-railsのこのCopで対応できる。https://docs.rubocop.org/rubocop-rails/cops_rails.html#railstimezoneもちろん「知ってるべき」という考えはあんまりなくて、どっちかというと Time.current の内部挙動について知ってた方がうれしい気がする。...というわけで結局、ここで長々と書いているのは「Rubocopを導入しない」ということは「Styleの違いを許容する」だと思っていたので「そういうことは指摘しないでほしい」っていう態度を示しました。についての反省文なのかもしれない。じゃあRubocopを導入しない世界ですべき振る舞いとは？自戒をこめて言語化してみる。前提として、実利のない(と各々が信じる)議論は避けるその上で、レビュアーやレビューイに「Rubocopがどんなことを指摘できるか」の知識を求めない結果として、自分がレビューされるときはRubocopのような指摘をもらうこともあるし、自分がレビューするときはRubocopがしてくれるような指摘をすることもある同じような指摘が何度か続いて、それらのコストとリターンが釣り合わないと思ったら、Rubocop導入を提言する別途コードガイドラインにしておきたい事項があるなら見えやすいところに置いておくというわけで、チームにそれなりの習熟度を必要とするんだけど、そこまで無理な世界だとは思わない。あと、このあたりについて他の人の考えを知れたらうれしいという気持ちもある。ちなみに社内の他の言語のプロジェクトではLinter(Formatter)が使われることが多い。js/tsのプロジェクトではESLint+Prettier、Goのプロジェクトではもちろんgofmt、Elixrプロジェクトではmix formatというものが使われているらしい。SwiftとKotlinはどうしてるんだろう。あと、Rubocopとは別のアプローチとして、Dangerってツールがあることを知った。(これは社内で使われている)danger.systems

Rubocopを導入しない世界ですべき振る舞い

2019/11/27に縁あってこちらのイベントでLTしてきたので、諸々のメモ。worc-meetup-20191127.peatix.com経緯以前、何回かTokyoWebCoffeeという、Web界隈のコーヒー好きが集まるMeetupに参加したことがあって、そこの中心的人物だった  @tetsuyaさんから発表の話を持ちかけてもらい、LT発表することにした。結局、今回の発表者はそのtetsuyaさんとTokyoWebCoffee主催者の @kozo002 さんと僕だったので、発表者3人は顔見知りって感じでやりやすかった。tokyoweb-coffee.connpass.com発表資料※ 今回の発表はかなりDEMOやスライド外の説明で補足しながらだったので、改めてこのブログで諸々書きたい今回の発表テーマについてSCAA Coffee Taster's Flavor Wheel↑こういうものがあって「コーヒーの味を表現するときに便利」くらいの雑な認識を僕は持っている。ちなみに、このFlavor Wheelについても、教えてもらったのはTokyoWebCoffeeのMeetupだったなと今思い出した。すごいコミュニティだ。ちなみにワインでも同様のものがあって、ワイン通らが言う「木の皮のような」とか「白い花のような」みたいなのも押さえられているらしい。で、このSCAA Coffee Taster's Flavor Wheelについては、前職のときに誰かがコーヒーを淹れたあと、「別に味覚にそれほど自信があるわけではないけれど私はこう感じました」みたいな話をワチャワチャとするときにおもしろかった記憶があり、このコミュニケーションをSlack上で楽にやれたらおもしろいかもしれないと考えた。作ったものこのgifのように、Slack上で、どんな味を感じたかFlavor Wheelの内側から順番に選択していくようなSlash Commandを作った。発表資料にもあるように、TypeScriptで作ったExpressをGlitch上でtscして動かすようにしている。構成ポイントは、最初のSlash Commandに対応するmessageを送ったあと、SelectBoxの中身やユーザーの選択内容がInteractiveに書き換えられているところで、これは動いているのを見ると得も言われぬ自己満足感を覚えることができる。Slash Commandについては、Slack公式が日本語で書いてくれていたチュートリアルが大変わかりやすかった。api.slack.comInteractive Messageについては、ドキュメントを見ながら手探りで実装をしていったが、当初は慣れないGlitchでのデバッグが難しかった。(というか、結局printデバッグばかりしていた)また、自身のTypeScriptの習熟になるように、ExpressをTypeScriptで書くようにやっていたのだが、迫りくる発表当日...という時間との戦いに心折れ、随分とAnyでごまかすようなコードになってしまった。とはいえ、それでも型検査によってバグの予防ができた感はあったので、体験としておもしろかった。今回の失敗複数人が投票できない仕組みになってしまった現職ではSlackの /vote コマンドや /polly コマンドがよく使われていて*1、正直言うとそれにインスパイアされたのだが、いつの間にか、複数人による「投票」のようなことができない仕組みにしてしまっていた。(誰か一人しか入力ができないのだ)ひとつのメッセージに対して、複数人が選択することで「highwideさんはシトラスっぽさを感じたよ」「うちやまさんはハチミツっぽさを感じたよ」「たかひろさんはスモーキーっぽさを感じたよ」って出てくると、コミュニケーションとしてはおもしろいと思ったのだが...。ひとりでSlackのコマンドを開発してると、第三者からどう見えるかどう操作できるかって、わかりにくいんだなって思った次第だ。SCAA Coffee Taster's Flavor Wheelのライセンスについての考慮不足www.scaa.org上のページにあるように、このFlavor WheelはCreative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0)となっている。Creative Commonsについて調べると「あなたがこの資料を リミックスし、改変し、あるいはこの資料をベースに新しい作品を作った場合、あなたは改変された資料を頒布してはなりません」とあり、今回実装したように「Flavor Wheelをプログラム上で取り扱えるようにする」というのが「改変」にあたるのではないかと(実装後に)気がつき、リポジトリをPublicにすることを見送っている。creativecommons.org失敗したとはいえ...普段あまり触ることのないExpressやGlitchなどを触ったり、SlackのAPIについてわかることが少し増えたり、そもそも久しぶりのLT発表ができたりと、楽しい機会になった。イベントについてみんなコーヒーについてのレベルが高い...。発表も懇親会めちゃくちゃおもしろかった。@katsumata_ryoさんが素敵な写真付きでレポートを書いているのでみてほしい。medium.com特に、プロなのだからレベルが違うのは当たり前のだが、LIGHT UP COFFEEの川野さんの論理と数値によってコーヒーを解き明かそうとするようなアプローチがとても印象に残っている。資料も後ほど公開されるようで、プロのノウハウがシェアされるのはありがたいなぁって思っている。*1: 突如チャット上に現れたVoteには「犯人はujihisa」というReactionがよくつけられている

「Engineer x Coffee Meetup! Vol.1｜ by WORC」でLTをした #worccoffeemeetup

2019/11/27 「Engineer x Coffee Meetup! Vol.1｜ by WORC」発表資料

How about today's coffee?

Summary2015年4月に入社し、だいたい4年半くらい勤務したリブセンスを退職します。2019年9月6日に最終出社日を迎え、今は有給消化期間中です。次は10月15日からQuipperにて、RailsとReactを書くソフトウェアエンジニアになる予定です。転職理由はマネージャーからプレイヤーに戻りたいっていうよくあるやつで、でもリブセンスは総じていい会社だったなぁって思っています。このエントリは「自身の退職やそれにあたっての胸中を、今誰かに伝えたい」というよりも、キャリアのチェックポイントでまとまった文章をとりあえずダンプしておこうという性質のものです。リブセンスで何をやったか/なぜ辞めるか2015/4/1に入社して、当初は企業の口コミ情報を提供する「転職会議」の開発に携わりました。SIer」でSEをやっていて、業務でほぼプログラミングをしたことがなかった自分にとって、初めて「プログラミングでお金を稼ぐ」経験になりました。Ruby/Railsの学習はしていたものの、やはり自身のスキルが業務レベルにないことを感じましたし、受託開発から事業会社へのマインドシフトという面でも当初は難しく思いました。いくつかの機能改善やグロースハック施策の企画/実装などをやった後、ビジネスモデルの刷新に向けた、新規サブシステムの開発に携わりました。RailsにおけるElasticsearchを利用した検索機能/indexing機能を実装したのが、自身のリブセンスの経験の中でも、特に腰を据えて技術に向き合えたいい経験だったなぁと思います。その後、2017年1月にアルバイト事業部に異動しました。ジョブセンス」という名前でしたが、リブランディングのために「マッハバイト」にリニューアルを行うこととなり、プロジェクトマネジメントと実装の面で携わりました。ガラケーサイトの閉鎖を決められたのが、数少ない「エンジニアに手放しで喜んでもらえる功績」かもしれません。そんなかたちで、徐々にマネジメント/ファシリテーション/コミュニケーションといった面で、評価してもらうことが増え、徐々にマネージャー寄りのキャリアにシフトしていきました。リングマネージャー」という立場で、制度の策定や組織運営、採用や1on1などを慣れない身ながらやるようになりました。単純にマネージャーからプレイヤーに戻るだけならば、リブセンスの中でそういうポジションを見つけることもできたと思いますし、上司やVPoEからそういった提案をいただくこともあったのですが、改めてプレイヤーとしての地力を高めるのであれば、4年半いた会社から環境を変えて新しい刺激に身を置きたいと考えて転職に至りました。リブセンスについて4年半いれば、いいところだけでなく改善すべきところも見えはしつつ、自分にとってはいい会社だったなぁと心から思います。ボドゲなどなど、この楽しい縁が続けばいいなぁって思います。また「改善すべきところも見えはしつつ」なんて偉そうな書き方をしましたが、そんな「改善すべきところ」を見つけた上で実際にボトムアップで改善行動を起こそうという人たちが多くいるのも好きなところでした。社内では「うなぎさん」って呼ばれていたこれは最後にやったテーマ縛りLT大会「0x64物語」で、 @dkatsura_bot がお疲れメッセージをQuineにしてくれた様子。転職活動について転職活動は、LAPRAS経由でのスカウトと、リファラルに頼りました。LAPRASは、Scoutyというサービス名だった頃に登録したのだけれども、登録したこと自体すっかり忘れていて、それでもGitHubやCONPASS等の活動履歴がスコアリングされた結果スカウトに繋がっているのだと気がついて驚きました。次の会社についてリクルートマーケティングパートナーズ傘下のQuipperにてスタディサプリの開発に携わる予定です。RailsとReactを書くポジションに就くことができました。Railsももっと知識を深めたいのですが、それ以上にReactやモダンフロントエンドに関しては業務未経験なので、有給消化期間中にAWS Loftに"出勤"してキャッチアップするなどしています。Quipperは入社前からTwitterでフォローさせてもらっていたような優秀な人たちが多かったので、これ以上ない「新しい刺激」になりそうです。ドキュメンテーション等が求められるので英語学習の必要もありそうです。とりあえず、瞬間英作文とduolingoを始めました...。残念なこととして、前オフィスから徒歩1分程度の距離なので、これからも目黒でランチ食べるのかぁという思いはあります。というわけでありがとうございました！！よろしくおねがいします！！

有給消化エントリ

状況ですMint60作ったぞかわいい...。しかもまだキートップの面で伸びしろがあるんだぜ...。ここまでのあらすじApple純正からHHKBへ現職に2015年に入社して初めてUS配列のMacを手に入れた。しばらくは内蔵キーボード/Apple純正キーボードを使っていたのだけど、そのうちHHKBが気になるようになった。で、そのタイミングで友人が安くHHKBを譲ってくださると言うので思わず手を上げた。ツイート探したら2016年12月だった。憧れのエンジニアである @5t111111 さんにHHKBを非常に安く売っていただくことになったのですが、その様子がこちらです。 pic.twitter.com/Ssx9vbmBe5— うちやま (@highwide) 2016年12月1日HHKBは今でも大好きなキーボードで、オフィスではこのとき譲ってもらったもの使っていて、家ではBluetoothのHHKBを買い足して使っていた。分離型キーボードへの憧れ現職入社のタイミングで「その方がかっこいいから」という理由でUS配列を選ぶあたりでお察しなんだけど、基本的にミーハーであることを自覚している...。というわけで、数年前から左右分離型キーボードが流行り始めたタイミングでは、HHKBに不満はないながらも、ちょっと気になる存在になっていた。ただそのときは、同僚にErgoDoxなど使わせてもらったものの、格子配列のキー配置になじめず導入は見送っていた。そんな中、mistelのBaroccoシリーズを知る。格子配列でない(このときは「row-staggered」なんて言葉を知らなかった)HHKBライクなデザインで、分離型。かっこいい。特にMD650Lの渋いデザインがすごく気になっていた。Mistel BAROCCO MD650L 分離式 メカニカルキーボード 英語配列 Cherry ML Switch ML1A 採用 アイボリー/グレー MD650L-LUSMGAB1出版社/メーカー: MiSTEL発売日: 2018/02/27メディア: Personal Computersこの商品を含むブログを見るただ、欲しい物の優先順位考えて、しばらく見送られる存在ではあった。見送りつつ、気になってる存在。当然、友人が使っていると気になってしまう。気になってたキーボードだ！！使ってる人の感想気になります！— うちやま (@highwide) 2019年6月24日そして沼へで、上のツイートのやり取りの中で「軸」の話になるんだけど、僕の「どの軸がどういうキータッチか...という感覚がない」ことに対してこんな指摘が入ったのだった。(聞こ…えますか…あなたの心に…今…直接語りかけています…とりあえず遊舎工房に行ってみては…どうでしょう…きっとあなたの軸が…見つかることでしょう…)— Katsumata Ryo (@katsumata_ryo) 2019年6月24日ただ、このときはまだ「遊舎工房」の名前は聞いたことがあったものの「キーボードを自作したい」とまでは思えていなかった。あんまり言語化された理由はなかったように思うんだけど、社内の自作キーボード部の人たちがだいたい格子配列のキーボードを作っていて「自作キーボード = 格子配列」っていう図式がいつのまにか脳内にあったからかもしれない。というわけで、勢い余ってこんなツイートをしてしまった。自作キーボード、興味ないわけじゃないし、左右分離型のものを使いたい欲もあるんだけど、いきなり左右分離+格子配列への移行コストはきつそうだと思っていて、左右分離+非格子配列の初心者向けキットがあるなら教えてくださいって感じです。(なのでMistelがほしい)— うちやま (@highwide) 2019年6月25日そこで教えてもらったのがMint60だった。(しかもお二人に教えてもらった)https://t.co/EI3v64L9Qpこういうのも— Takuya Matsumoto (@upinetree) 2019年6月25日どうぞ https://t.co/HFP2znVG45  https://t.co/JXUqK5p8zM— えむ。 (@takkanm) 2019年6月25日これは...完全に好みだぞ...。もう引き返せない...。(という自分に対しての納得感形成)ただ、自分は学校の「技術」の科目などでもはんだごてを使った経験もなかったので、とりあえず遊舎工房でmeishiキットを買ってみて、「自分が自作キーボードという行為を楽しめるか」という確認を兼ねる練習をしてみることにしたのだった。meishiQ: 自分が自作キーボードという行為を楽しめるかA: めちゃくちゃ楽しめたプロダクト愛が重めのmeishiキーボード完成した🎉 pic.twitter.com/wI9oWutTFD— うちやま (@highwide) 2019年7月4日作成にあたっては、職場の自作キーボード部に感謝するところも大きくて、はんだごて/コテ台/はんだ線/マスキングテープ/ニッパー/作業マット等々、めちゃくちゃ器具が揃ってたので、キット買いたての一番テンション高い状態から特に追加投資の手間などもなく、スルッと沼に入っていくことができた。借りました @micchiebear @asadaman09 pic.twitter.com/TiGPqtbGr8— うちやま (@highwide) 2019年7月1日キーは左から「画面ロック・前の曲・再生/停止・次の曲」に割り当てた。これは「オフィスで、トイレに行こうと立ち上がったあとに、画面ロックして曲停止する」みたいなユースケースにおいて普通にめちゃくちゃ便利だった。meishiのキー配列↓https://github.com/highwide/qmk_firmware/blob/highwide-settings/keyboards/meishi/keymaps/default/keymap.c#L20あとは、初めてやったはんだ付けも普通に楽しくて、下手なんだけどまたもっとやりたいなーっていう思いを抱くようになった。【半月前】皆様「自作キーボードいいよ」僕「meishiキーボードだけなら...」【meishiを作り終えると...】「また半田付けやりたい！」「フルキーのものが作りたい！」「Karabiner-Elementsに頼らないキー運用をしたい！」— うちやま (@highwide) 2019年7月11日Mint60というわけで、meishiを作り終えて早々に、当初の目的だったMint60に手を出してしまったのだった。キースイッチはGateronの静音赤軸を修飾キーに、静音茶軸を文字キーに使うことにした。キーキャップは遊舎工房の人には「Tai-Haoを想定して作られてる」と教えてもらったのだが、「せっかくなら自分なりのこだわりを見せたい」という初心者のくせに厄介なこじらせを見せて、一番文字の印字がかっこよく見えた「MDA Big Bang」を選んだ。※ あとから、自作キーボード界隈の人が集うDiscordで「Big BangはErgodox系統向けのセットなので、ANSIよりのMint60だとそういうやつ向けのBig Boneのほうがよかったかもしれません」といったことも教えてもらった(善意で教えてくださったものの、「内訳は見ていない」とのことで要確認だとは思う)で、昨夜作り終えて、冒頭の状況に至る。キートップ気に入ってないとこあるし、まだキーマップも改善したいんだけど、ひとまずはmint60完成したー！！！！借りてるはんだごて家まで持って帰った甲斐があった。ケースをねじ止めしてから、はんだ付け忘れた箇所やLEDの接触によるショートに気づいたのは反省点だな。 pic.twitter.com/yUJtPx6pi8— うちやま (@highwide) 2019年7月27日失敗したところめちゃくちゃ気に入ってるんだけど、やっぱり自作初心者ということもあって、失敗した点はいくつもある。キーキャップの配置。左手小指は当然Capslockなんて使わないのにちょうどいいキーがなくて代用してたり、キーキャップの規格がわかってなくて遊舎で買い足したパステルカラーのキーは高さが違ったり、右側の最下段の親指キーに至っては長さが足りなかったり。とはいえ、これは買い足せばなんとでもなるかな。(と言って、また沼にズブズブと...)ProMicroの"モゲ"防止にエポキシ接着剤を使ったんだけど、液の混合比率をミスって、イマイチ固まらないままはんだ付けしてしまった...。ネジ止めしてから、はんだ付けし忘れてるキースイッチにいくつも気づいた。会社のキーボード部にはテスターもあったから、ちゃんと使い方覚えて、早い段階で確認していけばよかったな。作り方の説明にも注意が書いてあったけど、LEDに基板側の端子が接触してショートしてた。(しかもケースに入れないと再現しなくて苦戦した)てか、LEDの保護テープ外すと接着面がでてきたけど、あれは保護テープ外さなくてよかったんだろうな。とはいえ、学びを得つつ、最終的にはきちんと実用に耐えそうなものができた(気がする)ので、初めてのフルキーボード制作としては個人的には大満足している。こだわり静音キースイッチを静音のものにしただけでなく、遊舎の店員さんに教えてもらったOリングというものを導入した。Qisan メカニカルキーボードに対応 耐用シリコン 防水性を付き　静音化リング（白色）出版社/メーカー: Qisanメディア: エレクトロニクスこの商品を含むブログを見るこれをキーキャップにはめこんでからキースイッチに挿すことで、打鍵におけるキーがよりマイルドになる。あれこれキースイッチを試してるうちに、自分は青軸のカチャカチャみたいな感じがそんなに好きじゃないことがわかってきたので、いっそのこと静音に振り切ることにした。キーマップこれは正直うまくいくかわかんないんだけど、いま時点のこだわりとして。自分は前職にいたときの「ソフトウェアエンジニア仕草なんもわからん」みたいな時分に教えてもらった「シェルでは矢印やEnterやTabキーを使うな。Ctrl + 文字キーでなんでもできるぞ！」という考えに影響を受けてしまっていて、C-f/n/b/pやC-a/eでカーソル移動して、C-[でesc、C-iでtab、C-h/u/k/wで文字削除して...みたいなキー入力をしている。で、MacOS使ってる限り、だいたいのソフトウェアで問題ないんだけど、たまにユーザーの「Ctrl + キー」を自らのプロダクト専用のショートカットキーとして奪っている不埒なサービスがあって(会社で使ってるServer版のJIRAとか)、そういうわけでKarabiner-elementsの「Emacs key bindings」をインストールしていた。で、自作キーボードならもっとハードウェア寄りのところでキーマップ設定ができるんだしと思い、普段Ctrlを打っている左手小指の修飾キーを「限りなくCtrlに近いレイヤ切り替えキー」として設定し、そのレイヤでは「Ctrl + f」の感覚で「→」が入力される...といったキーマップを書いてみた。(これならC-fとして入力されるのではなく「→」として入力されてるので、諸々のソフトウェアは奪えないはず、という判断)https://github.com/highwide/qmk_firmware/blob/highwide-settings/keyboards/mint60/keymaps/highwide/keymap.cまぁ、正直あれこれ試しながらブラッシュアップすることになると思うので、これはひとまずいま時点の考えを残しておくくらいの意味しかないかもしれない。いずれにせよ、早く慣れるほど使いこなしたい。というわけでMint60は主に会社で使っていきたいと思っている。会社と家でキーボードが変わることによるコンテキストスイッチが今から心配。(そして、それを言い訳にしてもう1基買っちゃうんじゃないかというのも心配)これ読んでくれた人も自キー沼にハマっていこう。

自作キーボード入門した

TokyuRuby会議13でLTをした。regional.rubykaigi.org発表資料↓TokyuRuby会議でLTをするのは3年ぶりだった。(過去の発表 => a-code-to-rhyme - Speaker Deck )"技術を酒の肴にする"感があって、本当に楽しい雰囲気で、大好きな勉強会だなぁ。改めて、運営の方、ありがとうございました。なぜ、今回LTをしようと思ったかというと、4/18〜20で福岡で行われたRubyKaigi2019に話は遡る。昨年の仙台に続いて参加したRubyKaigiだが、今年も本当に楽しかった。何が刺激だったって、初めて参加したRubyKaigi2015で語られていた「Ruby3」に向けた具体的な進捗を"すごい人達"がたくさん出していて、「はーすごい人達が出す進捗すごい」ってめちゃ思ったのだった。もちろん、Ruby 3に直接の関係がなくとも、Apple IIでRubyを動かす話や、SwitchでRubyを動かす話などもとてもワクワクしながら聞いた。やはり僕は、ああやって技術をオモチャにする人たちのことを尊敬し、おもしろく思うのだ。ただ、今年のRubyKaigiでは、ひとつ心残りがあった。屋台の焼きラーメンも、ひらおの天ぷらも、海鳴のとんこつラーメンも、ゴマサバも、新鮮なイカ刺しも、梅が枝餅も食べたのに心残りがあったというのは、繰り返しアナウンスされる「rubygems.orgの2FA設定をする」ということができなかったことだ。.@masarakki さんに三脚借りた pic.twitter.com/fSiVhj09fD— うちやま (@highwide) 2019年4月20日※ これは最後の"川"で飲んでたときに撮った夜景。詳細はこの記事などが詳しいのだが、今年rubygemsのアカウントに対して攻撃があり、対策として、開発者のアカウントにおいて2FAを設定する旨が求められていた。techracho.bpsinc.jp一方僕は、そのアナウンスがある度に、顔を伏せるようなバツが悪いような...そんな思いを抱いていて、gemもまともに作ったようなことがないのは、RubyKaigiにとって真に来てほしいRubyistじゃないのかな...みたいな、そんな思いを抱いたのだった。もちろん、作ったことない方もたくさんいたと思うし、自分以外のgemを作ったことがないRubyKaigi参加者に嫌な思いをさせたい気持ちは全然ないのだが、自分自身の開発者としてのキャリアみたいなものを省みるきっかけになったと思う。というわけで、gem作るぞーみたいな気持ちになった。折しも、TokyuRuby会議のCFPがあって、発表駆動でなんか作るのは性に合っているので、申し込んでみたら当選したので、冒頭の資料に至る。作ったgemはこちら。github.comあたりまえなんですけど、本当にrubygems.orgに載ってるんですね。rubygems.orgネタ自体は正直何年も前から持っていて、テーマ縛りでLTをやる社内勉強会「0x64物語」で利用していた次のテーマを選ぶための投票の仕組みを実装したに過ぎないし、コードベースも大したものではないのだが、それでもやっぱり作らなきゃわからないことがたくさんあるなぁと思ったのだった。たとえば、今すでに、このAPIイケてないなって思い始めていて「直すと後方互換なくなるんだけど、もし仮にまともに使ってくれる奇特な人がいてたら、どうパスを用意すべきだったんだろう」みたいなのは、OSSの利用者としてよく聞く話ではあるけれど、自分が作る側になってみて"心で理解した"みたいな感もある。あとは「Tokyuの発表終わったら、今度は全然別なもの作るぞー」って思ってたんだけど、あ、これはこれでメンテもしないといけないよな、みたいな話とか。とはいえ、今回こういうものを作った経験を今後も生かしていきたいし、これがまた何かのきっかけになればいいと思う。追記: もちろんrubygems.orgの2FAは設定しました💪

TokyuRuby会議13でLTをした。あるいはRubyKaigi2019に参加して。 #tqrk13

2019年6月29日に行われたTokyuRuby会議13でのLT発表資料です。この勉強会が、皆が持ち寄った食事や、発表されたLTの中から"最高"のものを投票で決めることをやっているので、それにかこつけて、IRV(Instant Runoff Voting)という投票手法を紹介しました。また、Rubyでその投票手法を実現するgem( https://github.com/highwide/irv )を実装したので、その紹介も行っています。

How to choose "best of the best"

よちよち.rbに久しぶりに参加した。yochiyochirb.doorkeeper.jp今日の回はjnchitoさんがゲストとして招かれていて、あれこれ質問できるという会だった。「昔からよちよち.rbに参加してくれてる人も是非」と言ってもらったので参加させてもらった。jnchitoさんといえば、今でもRSpecのまとめ記事やRubyの新しいバージョンのまとめ記事はよく拝見するし、自分がある程度RSpec書けるようになったのは、jnchitoさんらが翻訳された「Everyday Rails - RSpecによるRailsテスト入門」に支えられたところもあり、お話してみたいと思っていた。それもあって、最近職場で話して他の人の意見も聞いてみたいと思っていたことを、事前にアンケートフォームから質問として投げた。#yochiyochirb で伊藤淳一さんに「プライベートメソッドにどうしてもテスト書きたくなっちゃうときないですか？そういうときどうしますか？」という質問をしました。— うちやま (@highwide) 2019年3月3日もちろん「書くべきではない」という意見が支配的であることは知っている。ただし、原則として書くべきでないという前提の上で、それでも書きたくなるケースなどにどうやって対応するのかというのを聞いてみたかった。事前に、運営をやってくれていたyuki3738さんが、僕の質問を見て「コード例などあるとうれしい」という言葉をくれた。確かにそのとおりだなぁと思いつつ、そもそも、よちよち.rbに今メインで来ているプログラミングを始めたばかりの方にとっては、「原則として書くべきでない」といったことを前提にするのも不親切かと思い、それならと説明用のスライドを作った。今日は、それを使いながら質問をさせてもらった。(他の質問は、運営の方たちがつくった「質問まとめスライド」で済んでいたので、結果的に「自己顕示欲がすごい質問者」みたいになってしまった)作ってみて思ったが、特定ドメインにしか通用しないようなコードを避けつつ、自分の意図を反映させる、サンプルコードを書くというのは難しいなと気がついた。技術書とか書いてる人たちすごいなぁ。いただいたお答えとしては以下のような感じだった。伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。 #yochiyochirb— うちやま (@highwide) 2019年3月3日加えて「原則書かない方がいいんだから、それを緩和する方針はいずれにせよチームでコンセンサス形成することが大事」ともおっしゃっていたように思う。一方で、改めて考えると、自分はこういうスタンスだなぁと言語化できた。時間の中でうまく言語化できなかったけど、自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。 #yochiyochirb— うちやま (@highwide) March 3, 2019このツイートと同様のスタンスの方からリプライいただいたりもした。もちろん、質問しておいてjnchitoさんからもらった答えを否定したいわけではないし、今日の会でも「自分もpublicにしちゃった」という方はいたので、大事なのはおっしゃるように結局チームでのコンセンサス形成かなって感じもする。また、懇親会でお聞きした別の興味深かった意見としては「たとえ小さな処理でも、必ずclassに切り出す」というものだ。その方は、そもそも小さな処理をチェーンしやすくする interactor というgemを勧めていて、小さな処理でも都度classに切り出すことを躊躇していないと言っていた。github.comRailsなどに依存しない小さなgemでこういう仕組みを使うのはおもしろいと思った。改めて、今日の運営のyucao24hoursさん/yuki3738さん、会場提供のSansanさん、そしてjnchitoさん、ありがとうございました。--2019/3/4 0:43追記--Twitterでtakeshinoda氏とやりとりしていて、スライドのコードに、今回の主旨と関係ない意図せぬダメダメコードがあったことに気がついた...。スライド12ページ目こうなっていたところ、# データ加工といってもこの程度ならclass切り出さなくてもいいのでは?data  .group_by(&:first)  .sort  .map { |key, values| [values[0], values[1]] }意図してたのは、こう書くべきだった。processed_data = data                    .group_by(&:first)                    .sort                    .map { |key, values| [values[0], values[1]] }13ページ目も同様に、ここはdata = Hoge::DataAggregator.aggregateprocess_data(data)Hoge::S3Sender.send(processed_data)こうしたかった。data = Hoge::DataAggregator.aggregateprocessed_data = process_data(data)Hoge::S3Sender.send(processed_data)スライドを今から修正して上げ直すのはどうなんだ的な感じがするけど、主旨と関係ないところで混乱させるミスなので修正した。--2019/3/4 1:11追記--id:sinsoku さんが自分ならこうするというコードをご自身のブログにあげてくれていた。sinsoku.hatenablog.com

privateメソッドのテストについての考え方 #yochiyochirb

2019/3/3の「よちよち.rb 第143回 〜 jnchito さんと！Ruby・Rails での『困った』を解消しよう会〜」で質問するにあたって前提やコード例など出しながら質問するのに使ったスライドです。

A question about private method testing

同僚から「久しぶりに社内でLT大会をやろう」という話を年末にもらって、上のスライドを使って発表をした。今日の発表は、「DEMOと称して実際にコーヒーをドリップしながら、スライドはKeynoteをiPhoneからRemoteで操作して発表する」ということをやったらおもしろいかなと思ってやってみたのだけれど、今思うとちょっとかっこつけすぎてたかなと思う。AWS Iotボタン、気軽で楽しいなぁ。2500円はちょい高いと思うけど。ちなみに、デブサミで発表の機会をもらった、今まで運営していた社内LT大会はさすがに参加人数/発表人数が少なくなってきて、しばらくお休みしている。www.makuake.com↑これで手に入れたCODE COFFEE、今のところSwift→C→Javaときて、今回のRubyを開封した。Javaはおいしかった。Swiftはこのとおりである。CODE COFFEEの"Swift"をペーパードリップで淹れたんだけど、どう頑張ってもケミカルなリンゴフレーバーから逃れられなくて、鼻が近づくたびフフッて変な笑いが出る。— うちやま (@highwide) December 10, 2018ちなみに会社でのコーヒー文化についてはnoteにも書いた。https://days.livesense.co.jp/n/nf27834be8dccコーヒーを淹れること自体が好きなので、仕事中のリラックスになっている。

社内でコーヒー淹れる環境をちょっとだけ良くしたLTをした

2018/1/9にリブセンスの社内LT大会で発表した資料です。コーヒーを淹れたとき、AWS IoTボタンを押すことでRubyで書いたAWS Lambda Functionを起動して、Slackに通知を送るという内容について話しました。

A life-changing innovation for my work-style by IoT

というタイトルで記事を書くつもりだったが、先にこれを書いてしまった。https://days.livesense.co.jp/n/nef6eb6d712cfdays.livesense.co.jp社員の日常が伝わるような気楽な/気軽な情報のストックを作りたいという、創業者の"精度高い思いつき"に乗っかり、livesense daysというnote上のマガジンに記事を追加したかたちだ。桂さんの思いについては、詳しくはこれに書いてある。https://days.livesense.co.jp/n/n79fde29f398adays.livesense.co.jp僕は(悪い意味で)変にまじめなところがあり「"daysっぽさ"を重視して、肩肘張らないようにするぞ」という肩肘の張り方をしてしまったような気もする。ひとまず、noteでのマガジンはあれこれ手探りで手探りでやってみて、ある程度継続できそう/定着できそう/意味ありそうという感覚を持てたら正式な共有をするのだと思う。さて、京都の話だが、うちの会社では「採用イベントで遠方に行く際は前泊OK」ということになっていて(たぶん)、それを利用して前日の朝から京都に乗り込み、散々観光して写真を撮ったというかたちだ。採用イベントで学生の方と話すのは楽しいし、本当に自分が学生の頃に持っていなかった優秀さを感じられて刺激を覚えるのだが「25分×10コマの面談を行うのはしんどい」という揺るぎない本音もあり、バランスとるためにも遠方開催の場合は目一杯楽しむことにしている。(とはいえ、同様のプレゼンテーションを繰り返さなくてはいけない、学生の方が大変だろうなという思いはあり、本当に頭が下がる思いがある)祇園〜八坂やよいです pic.twitter.com/0PBNTyDF3e— うちやま (@highwide) 2018年10月13日嵐山を散策した。はい pic.twitter.com/CkTJC0qWFZ— うちやま (@highwide) 2018年10月13日予習として、Nasneに録画したっきりになっていたブラタモリの京都回を計6回分見るといったことを行ったので、地形や歴史について思いを馳せたりすることができた。

新卒採用イベントで京都に行った

気が向いたので久しぶりにブログを書いてみる。社会人1年目のときにNikon D7000を買って、それなりに写真が好きで、レンズもいくつか安いものを買い足したりしていたのだけど、とうとう去年くらいからフルサイズが欲しくなってきていた。当初はNikon D850を考えていたのだけど、ある日家電量販店で「憧れのカメラD850に、憧れの大三元24-70mm」という状態でディスプレイされてるのを見て、意気揚々と持ち上げたらその重さに辟易してしまい、それ以降、今後のカメラステップアップをどうやっていこうものかと考えていた。そんな中、今年の3月頃に、Sonyがミラーレスでフルサイズ一眼を出していて、評判もいいことを知った。また、今度出るモデル「α7iiiは、これまでの連射性能やバッテリーの持ちや操作系といった、不便な点を解消してきた間違いないモデル」といった評判を聞くにつれ、欲しい気持ちが高まった。おもむろにツイートしたら想像以上にバズった。「ほしいカメラがある…」って金融勤務の妻に打ち明けたところ、そのカメラでないといけない具体的な理由、今後のレンズ購入計画、その規格(Eマウント)におけるメーカーの戦略など確認された挙句「あなたの熱意はわかりました。次は資金計画についてお聞かせください。本日は以上です」って言われた。— うちやま (@highwide) 2018年3月14日その後、Spreadsheetに資金計画などを書き、晴れて妻の許しもらって、購入に至った。いい妻を持ちました pic.twitter.com/sCXLA0ad2i— うちやま (@highwide) 2018年3月25日その後、会社に支援してもらって、アメリカ ピッツバーグで行われたRailsConf 2018に行く機会があったりmade.livesense.co.jp仙台で行われたRubyKaigiに行く機会があったり、RubyKaigiお疲れ様でしたー！仙台、便利だし食べ物もおいしいし、本当に最高でした。ところで、この写真は今朝行ってきた山形の寺です。 pic.twitter.com/6v92LSjiiL— うちやま (@highwide) 2018年6月3日と、撮影のチャンスに恵まれた。当初はキットレンズ(f3.5-5.6 28-70mm)と撒き餌単焦点(f1.8 50mm)を手に入れて「高い買い物をしたのだし、しばらくはレンズを買い足さずに50mmという画角でいろいろな写真を撮り、うまくなろう」と思っていたのだが、人間とは恐ろしいもので、「旅行など再訪することが難しい場所に行くときに、任意の焦点距離をサッと選べないのは不便だし、そういうときに明るいズームレンズがあったほうが良い」というロジックで、キットレンズを売ってTamron A036(f2.8 28-75mm)を購入した。やはり明るいズームレンズは正義で、会社のブログ用写真を撮る名目で開発合宿にカメラを持っていき、75mmで人が発表している様子を撮影した後に、晴海埠頭に行って広角で夜景を撮るといったこともできた。三脚、無用の長物にならなくてよかった。raw現像は英語でdevelopなので、開発合宿でやることのひとつと言えます。 pic.twitter.com/d0uaJpwN6m— うちやま (@highwide) 2018年8月18日そんな感じで、僕がいい感じに写真沼に浸かっていると「俺も浸かってるよ」「俺も浸かりたい」などと言ってくれる仲間たちが現れはじめて、休日に数人で家電量販店に押し寄せて機材を一緒に購入してから街でスナップを撮るなどやっていて、楽しい。購入してからそろそろ半年になり、撮影枚数はだいたい8000枚くらいになった。ひとまずSynologyのNASにつっこんだうえで、バックアップとしてjpgとrawをPrime Photosに、観賞用にjpgを圧縮してGoogle photosにアップロードしているが、いい感じに自分の作品(と言えるレベルのものでものないのだが)のみをどこかに置いておきたいなとも考えている。ひとまず、500px に何枚かupしてみた。このへん引き続き模索しつつ、たまにブログにも写真など載せたいと思う。

写真にハマっている

「韻を踏むプログラムは書けるか」2016/5/29にTokyu Ruby Kaigi #10でLTしたものです

a-code-to-rhyme

9/4(金) - 9/6(日)で、よちよち.rbの開発合宿に行った。行き先マホロバマインズ三浦さん。弊社の開発合宿でも過去に使われたらしい。会議室あり / 温泉あり / 卓球場あり / 雀卓あり / 駅近し / コンビニ近し / 海近しって感じで、すごくよかった。よちよちの開発合宿について詳細はこちら -> Doorkeeperよちよちで開発合宿をやるのは、去年に引き続き2回目。去年は熱海の山喜旅館さん。ちなみに去年の開発合宿で僕が作ったのはこれ。highwide.hatenablog.com合宿では各自が自分の好きなことをやればいいということになっていて、みんな各々のことをやってた。タイムスケジュール1日目 時間    やったこと  - 20:10  会社でインターン生と飲んでた  20:30  品川駅集合  21:15 - 22:30 京急線ウィング号でトイレ我慢してた  23:00前  宿到着  23:00 - 2:30くらい  ハリガリとか厨二UNOとかニムトとかカードゲーム大会 ※ハリガリゲーム　ハリガリ　フルーツゲーム＜ＡＭＩＧＯ社　ドイツ＞出版社/メーカー: Amigo Spiel + Freizeit発売日: 1999/12メディア: おもちゃ＆ホビー購入: 2人 クリック: 5回この商品を含むブログ (1件) を見る2日目 時間  やったこと  6:30  奇跡的に目が覚めた  7:30くらい  朝食バイキングでとろろご飯食べた  9:00 - 12:00  設計についてあれこれ相談させてもらった  12:00 - 13:00  昼食 (牛丼) 13:00 - 13:30  卓球 (海に行ってる人もいた)  13:30 - 18:00  コード書いてた  18:00 - 19:00  夕食 (お重に入ったあれこれ)  19:00 - 21:30  話したり、お風呂入ったり  21:30 - 23:00  とみーさんとペアプロでテスト書く  23:00 - 3:00   厨二UNOとかニムトとかカードゲーム大会 ※厨二UNO (僕らが勝手にそう呼んでいる)Gods' Gambit~神々の一手~出版社/メーカー: アークライト発売日: 2014/06/14メディア: おもちゃ＆ホビーこの商品を含むブログを見る3日目 時間  やったこと  8:00  絶望的な起床  9:00 - 10:30  テスト書き上げる  10:30 - 12:00  各自成果発表して撤収  12:30  駅近くでマグロ丼  13:00前  帰りの京急線乗り込んだ つつがなく開発合宿終わった。 pic.twitter.com/nSWXmrc0kf— highwide (@highwide) 2015, 9月 6僕がやったこと最近とみーさん(@ta1kt0me)と shibaph というWebアプリを遊びで作っていて、そのコードを書いた。shibaphは、僕がGitHubのcontributions graphが好きなので、それ使ってタスク管理とかできたらおもしろいかなというアイデアで始まったもの。Rails4で書いてる。4月に転職してコードを書ける仕事に就けた喜びを噛みしめる一方で、仕事ってコード書くだけじゃないなって改めて思ったり、今の自分が価値発揮できるところがコード書くだけじゃなかったり、って感じだったので、合宿では「コード書くことに集中しよう」ってなんとなく決めてた。きっと仲いい人たちとみんなで合宿すると楽しくなったり、雑談も弾むだろうなと思いつつ、僕はあんまりマルチタスクの遂行が上手でないことを自覚しているので、「一つのことをうまくやる」精神で臨んだ。あとは、同僚が、プロコンの大会やハッカソンで2-3日ぶっ通しですごいコードをすごい量書いてすごい結果を収めているのを、すごいなぁと思っていたので、集中できる空間で集中してコード書くと、今の自分がどの程度できるのか確かめたかった。結果「上ででかいこと書いたわりに、めっちゃカードゲームしてんじゃんｗｗ」ってのはさておき、個人的には集中してコードが書けたと思ってるし、その一方で今の自分に書けるのはまだまだこんなもんかぁと思い知らされた気持ちもある。難しかったこと元々は、グラフをViewが描画しやすいように「ARモデルをValueとしたHashの、Array」っていう構造をControllerのprivateメソッドで作っていたのだが、呼び出すところでいちいちその構造を意識しなくてはいけないのがダルくて、呼び出され方をメソッド化した中間ClassをControllerで作ってViewに引き渡すようにした。その際の中間ClassってRailsのディレクトリのどこに配置すべき？とか結構悩んだ。(結局Modelに置いた)あと、「趣味プロジェクトなんだし使ったことない技術を使おう」と採用したminitestの書き方を調べるのにも時間がかかった。(RSpecが書けるとは言っていない)とはいえコード書くのも、みんなと話したり遊んだりするのも、楽しかった！ありがとうございましたーー！！！

よちよち.rb の開発合宿に行った #yochiyochirb

行ってきました。初カンファレンス。とても楽しかった。以下、観たやつとか。8/21(木) 前夜祭行けるかなって思ってたら行けなかった8/22(金) 1日目ビッグサイトの長いエスカレーター素敵だった。Merry Christmas (Larry Wall) ※敬称略Perl5とPerl6の関係は「ホビットの冒険」と「ロードオブザリング」の関係に近い。言語を作ることは物語を紡ぐことに似ているってなんか素敵だなと。中学生のときに観たロードオブザリングのことなんとなく覚えててすごく助かった。同時通訳すげーって思った。日常の言葉と、技術的用語と、トールキンの作品のことを正しく訳をわけるのほんとすごい。Perl6、リリースできそう、よくわかんないけどなんかすごそう。Perl6でのフィボナッチの書き方、ちょっと意味わかんなくておもしろかった。Effective ES6 (teppeis)    Effective ES6  from teppeis  とってもわかりやすくて、勉強になった。あーーー、ES6のことちゃんと知らなきゃな―って思いながら放置してたので、「スライドで説明してもらう」っていう受動的なスタイル取れるの大変ありがたかった。ES6素敵感やばいので、今のJavaScriptあんまり勉強したくないなとすら思ってしまった。この前、「え、素のjsにArray#each的なのないの!?」ってテンパったので、早くES6触りたい。「バベっていこうぜ」って印象的だった。TBD (matz)Matz「Rubyの一番悪い点はPerlの影響」！？ 次世代の言語の話も盛りだくさん #yapcasia #yapcasiaAtogetter.comPerl書けないし、参加前の時点で一番のお目当てのセッションだった。To Be Determined かと思いきや違った。-> Toward Brain-aware Design「Rubyの一番反省している点は、Perlの影響」めっちゃ笑った。一方で、質疑で「Rubyの99.8%はイケてる」的なこと言ってたのなんかいいなぁって思った。「今日はRubyの話は封印」 -> 「封印を解く」めっちゃ笑った。たぶんこのYAPCで一番笑った。ハードウェアの進化による言語の変遷とてもおもしろい。関数型が注目集めてるのもマルチコアとかでの並列化とか背景にあるし、いろいろ考えたい。Streemの考え方、やっとわかってきた。おもしろい。もっとシェルの考え方身につける必要あるなと思った。Conway's Law of Distributed Work (Casey West)リモートワークの話。CAP定理を組織にあてはめるっておもしろかった。「全員がオフィス通えるロケーションにいる」って中でリモートやる価値あるかどうかとか気になった。「リモートやりたいならまずは一週間とにかく試してみろ」的なの、やってみたい。Podcasting, Media for Web Engineer, and CPAN (yusukebe)    Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN  from Yusuke Wada Podcastのテクニカルな話ガッツリ！って感じだった意外と始めるコスト低いんだなとわかったエンジニアのYoutuber的な感ある。始めるのは簡単だけど、人集めるのと、継続するの大変そう。LTPHPの闇の話印象に残ってるうちのSlackにいる小野寺小咲さんと会話したいなと思った。株式会社ネコトーストラボさん覚えた。タイムテーブルの事情とか、満員だったりで聞き逃したので、あとで読むシリーズ    HTTP/2時代のウェブサイト設計  from Kazuho Oku     PietでLISP処理系を書くのは難しい  from Hideaki Nagamine     Yet Another Perl Cooking  from moznion こうやってまとめると、結局見たいのだらけだった感じだ。疲れたし、長くなったので、2日目はまた別途書きます。

YAPC::Asia行ってきた

以前、職場の人が、あるjsライブラリのGitHubリポジトリに「nodeだけじゃなくて、bowerでもinstallできるようにしてくれよー」(英語)っていうissueをカジュアルに立てていて、「気負わずにOSSにissue立てたりする姿勢尊敬しますー！」と言ったら、「Rubyのコミュニティとか参加してたら結構そういう人いるんじゃないですか？」と言われた。「初心者向けのコミュニティ(よちよち.rb)ということもあって、やっぱりハードル高く感じちゃいますね。今Railsにコントリビュートしてるのは僕が知ってる限りだと2人です(※)」 と答えると、「いや、Railsへのコントリビュートはレッドオーシャンなんで、もっと別のOSSをターゲットにしたほうがいいですよｗ」と言われたことがすごく心に残っていた。「なるほど、コントリビュート○貞を捧げるのはRails以外が良さそうだな」とそれ以降思っていて、期せずしてそのチャンスが今月2回もあったっていう話。※よちよちでRailsのコントリビュートしてるのは僕の知ってる限りだと @yuki3738 さんと @5t111111 さん。 新米エンジニアがRailsにコントリビュートした話 - スパイスな人生つくって学ぶプログラミング言語300近いはてブ数を集める、達人出版会から出ている「つくって学ぶプログラミング言語 RubyによるScheme処理系の実装」という本、実は前職の先輩が著者なので、わかんないことがあったら直接聞ける的安心感もあって、仲間内で読書会をやっていた。たまたま、読書会中に @katorie さんが「本のとおりに書いていると動かないかも」という箇所を発見し、「PR出しましたよー」って僕から直接伝えられるメリットもあるなと思い、自分が本のGitHubリポジトリにPRを出す流れとなった。とは言ってもコード的には、カンマを1つ消すだけなので1バイトの修正でしかない。Remove a needless comma by highwide · Pull Request #8 · ichusrlocalbin/scheme_in_rubygithub.comさらに言えば、リポジトリの管理者は知り合いなのであって、「初めて他人が管理するリポジトリにPR投げる」って意味では心理的ハードは最大限に低いはずなのだけれど、やっぱりPR送る瞬間はそれなりに緊張感があったｗそんな緊張とは裏腹にあっさりマージしていただいて、晴れて「つくって学ぶプログラミング言語 RubyによるScheme処理系の実装」のコントリビューター(と言っていいのだろうか??)になることができた。GitHubのContributions Graphには載った。autodoc仕事でRuby 1.9系のAPIをいい加減2.x系にしたいねって話があって、それにあたってドキュメンテーションを改めてきちんと行った上で、Ver. up後の動きを確認したいねってことになった。そこで、 r7kamura/autodoc が使えるかもって話になったものの、 autodocを bundle install したあとにテストが必ずErrorになる事態に陥った。当然最初はgemを疑う前に、自分たちのAPを疑ったものの、どう見てもautodoc内のラムダあたりでsyntax error吐いてるしなぁと思い至る。そこで試しに、vendor/bundle配下のautodoc gemを直接、 arrow記法が使われてたlambdaのsyntaxを -> から lambda に変えてみると動いた！むむ、これは本格的にgemのラムダ周りが怪しいのかもしれないと思って、ググってたらとうとうこんな情報を見つけた。Becareful with space in lambda rocket syntax between Ruby 1.9 and 2.0 - Ruby Journalruby-journal.comえええ〜、Ruby 1.9系と2.0系だと、 -> と引数の ( のあいだにスペースあると動かないの...マジで!?ここも、r7kamuraさん、日本人だし、(あちらは僕のこと知らないけど)僕はRebuild.fmでrubotyとか作ってる人だって知ってるし...って感じで多少心理的ハードルは低かったように思う。というわけで、7/27に出したPRを早々に7/28マージしていただいて、ご丁寧に CHANGELOG.md に thx @highwide とまで書いていただいた。(嬉しかった)Delete a space between arrow and args for Ruby 1.9 and 2.0. by highwide · Pull Request #32 · r7kamura/autodocgithub.comただし、こちらもスペース消すだけなので、1バイトの修正ｗそんなわけで結果的に、7月はOSS2つに、計2バイトのコントリビュートができたｗOSSのメンテナさん的に「逆に対応がめんどい」みたいなこともあるらしいと聞いてはいる。OSSにカジュアルな貢献ができるようになればいいとは思っている。蛇足autodocに出したPRがマージされた7/28が自分の誕生日で、ちょっといい誕生日になったなと思った。

すっごい小さなところからOSSにコントリビュートした

2015.2.16 (月)のSendagay.rb + よちよち.rb合同開催においての案内スライドです。