About on It's okay to be weird

開発環境現状確認 2026

Sat, 17 Jan 2026 04:20:00 +0900

なんか流行ってるっぽいので、開発環境を整えるのがそれなりに好きな僕も乗っかってみます。

マシン・OS

しばらくmacOSのみを使い続けています。いつからかは忘れてしまうぐらい使ってますが多分10年ぐらい？
Linuxも興味があって、古いThinkPadを買ってUbuntuを入れてみたりもしたのですが、会社で支給されるマシンがMacBookなので、子育てで忙しい今、両方を使いこなすのは学習コストをかけられないということでMacBookを使っています。特に不満はありません。
最近プライベートでM5 MacBook Proを買いました（M1 MacBook Airから買い替え）。スペースブラックかっこいい。

エディタ

機能の充実具合から、勝手にJetBrainsアンバサダーを自称するほどJetBrains IDEsが好きで使っていましたが、AIコーディングの波が来た時にVS Code系に乗り換えました。
ただJetBrains IDEsに比べて不満は多い（特にRubyだとRubyMineは強力）ので、Claude CodeやCodexなどのCLIツールが全盛の今、補助ツールとしてJetBrains IDEsをまた使ってみてもいいんじゃないかと思い始めています。とはいえVS Codeは無料なのがでかい…。
キーボードショートカットの使い分けをしたくないので、何かしらに統一したいとは思っています。

コーディングエージェント

レビュー・デバッグなどはCodex、実装はClaude Codeと使い分けてます。
プランはCodexでやることが多かったのですが、Thariq式をやってみて、Claude Codeにやらせてみるのも良さそうとなっています。
それぞれ得意・不得意がある感覚がするので、何か一つにこだわるということはやらないようにしています。
Cursorも使っていますが、色々契約してて出費がすごいことになるので、プライベートではいったん契約を打ち切っています。

ターミナルエミュレータ

Ghosttyがメインです。Ghosttyはひょんなことから日本語翻訳チームに入れてもらったりしています。
ネイティブUIが美しいし、サクサク動くので良いですね。開発も活発です。僕はコンフィグ3行で済んでます。

あとはlaisoさんと同じようにエージェントCLIツール専用に別アプリでWezTermを入れています。それを縦置き外部ディスプレイ1台に専用で割り当てています（もう1台の横置きディスプレイ、MacBookと合わせてトリプルモニタ）。
チャットが長くなりがちなので、縦に置いています。4並列以上とかするなら横置きの方が良いのかもしれません。

ターミナルマルチプレクサ

tmuxをずっと使っています。Zellijも使ってみたのですが、tmuxの方がミニマルな感じがあって、ウィンドウを数字キーで選べたり、キーボードでテキストをコピーしやすいのがあって戻ってきました（その辺はアップデートやプラグインなりでもう出来たりしそうですが）。
プロジェクトごとにGhosttyのタブを切り、backend、frontendみたいな括りでウィンドウを分けて使ってる感じです。
エージェントCLIツールのオーケストレーションみたいなところでの使いこなしが足りないので、その辺をもっと使いこなしていきたいと思っています。

シェル

zshです。fishを使っていた時期もありましたが、bashとの互換性があるのがやっぱ良くて戻ってきました。プロンプトはStarshipを使っています。

CLIツール

この辺りを愛用しています:

gh
ghq
git-wt
fzf
mise

ランチャー

Raycastを使っています。Karabiner-Elementsで右commandキーにハイパーキーを設定して、右commandキー + アルファベットでアプリがシュッと起動するような設定をしています。あとはクリップボード履歴、スニペット、ウィンドウマネジメントあたりをよく使います。絵文字検索も何気に便利 😄

フォント

UDEV Gothic 35NFを使っています。フォントに強いこだわりは特にないので満足しています。

ブラウザ

Firefoxがメインです。最近のAI機能の件とか色々ありますが、総合的に満足度が高いです。Orionを試したりしましたが、自分には機能的に不足していました。Kagiとか頑張って欲しいですけどね。Ladybirdが気になってます。

ノートテイキング

Obsidianを使っています。ローカルファーストなアプリなのでClaude Codeなりと相性がいいのが今は本当に強いです。
Notionをデータベース用途で併用していたのですが、Basesの登場とともにClaude Codeの力も借りてObsidianに統合してしまいました。移行もClaude Codeで楽ちんでした。

キーボード・ポインティングデバイス

MacBookのものを使っています。ミニマルなのがいいのと、プログラミングのうちタイピングする時間が占める割合は意外と少ないからという理屈であまりこだわりがなかったのですが、チャットする機会が増えたのでそうも言ってられなくなってきました。

最後に

僕の開発環境はこんなとこでした（久々にブログを書いた…）。あと言えることとして、どれもそんなにカスタマイズはせず、なるべくデフォルトに寄せるような設計で環境構築をしています。 M5 MacBook Proを買った時も一から構築したのですが、そんなに苦労せず移行できました。

Claude Codeで生成した「動く」OSSのフレームワークを公開せずに捨てた話

Sun, 03 Aug 2025 16:15:00 +0900

Agentic coding全盛のいま、それを無視するにはいけないご時世ですが、僕はそれに関して作る人間として好きな部分と好きじゃない部分があり、モヤっとした感覚があります。
そういった感覚を示す一例をこれからお話します。

作ろうと思ったフレームワーク

GoにはBubble Teaという大変使いやすいTUIフレームワークがあるのですが、Rubyには僕が知る限りそれに相当するものがありません。作りたいRubyのTUIツールがあったのにさっと作れずにいました。

そこで、そもそもないなら作ればいいじゃない、そして、自分だけの力じゃ無理そうだけど、Claude Codeの力を借りればもしかしたら作れたりするんじゃないかと思いました。

プロジェクトの構成

そうして実際に作り始めました。
プロジェクトの構成はVS Codeでプロジェクトのルートに、bubbleteaのリポジトリをクローンしたものと、今回作るフレームワークのリポジトリをぶら下げるというものです。

この構成で、Claude Codeと僕にまずbubbleteaのソースを学ばせて作っていくことにしました。
ここでモヤっとポイントその1なのですが、Claude Codeはソースをさらっとだいたい分かった気になったようですが、僕は吐き出された解説を読んでも半分ぐらいの理解でした。まぁここで全ての詳細を理解してもしょうがないと進むことにしました。

作っていく

まずはプランモードでbubbleteaを真似してミニマムなものから徐々に重ねていくように作ってくれと伝えて計画してもらいます。なかなか良さそうな計画ができたので進めていきます。

Claude Codeはテストプログラムやテストを書きながらガンガン機能を追加してくれます。たまに詰まりますが、お手本があると賢くなるという評判通り、「bubbleteaではどうなってるか参考にして」と言うと軌道修正できます。

そんなこんなで「動く」TUIフレームワークができあがってきたので、ターミナルのエキスパート、Rubyのエキスパートsubagentsにレビューしてもらいます。様々な問題が指摘され、本体の手を動かすくんによって修正されました。モヤッとポイントその2です: 完全に僕は蚊帳の外じゃん。

最終的には自分の作りたかったRuby TUIツールを実現できるまでになりました。自分では実現できなかったことが1〜2週間という短期間で実現できました。

めでたしめでたし…？

公開しないという選択

さて、どこまで作り込んでこのプロジェクトをOSSとして公開するかなぁと考えた時にふと立ち止まりました。

湧き上がるモヤり…。

…そして、いきなりですがプロジェクトを捨てることにしました。

オーナーシップの意識が欠けるという問題

何がこのプロジェクトを捨てる決定をさせたか。一番はオーナーシップの意識が欠けてしまうという問題です。

このプロジェクトをOSSとして公開する以上、何かしらのPRが飛んでくる可能性もあるわけです。しかし、Claude Codeに任せきりで作ったコードへの提案にオーナーであるはずの僕は答えることができません。そのレビューすらもClaudeに任せるのでしょうか？そんなのOSSと呼んでいいのか僕には判断がつきません。

では生成されたコードを1から10まで全部理解できてればいいじゃないかとも言えると思います。
しかし、自分で書いたコードなら当たり前のはずなのに、agent任せに生成されたコードは全て理解する気はなんとなく起きないのです。

また、うまく指示した結果として成果物が出来上がったのだからそれでいいじゃないかと言えるかもしれませんが、それもなんだかなぁという感覚です。

まとめ

以上、agentic codingをやっていてのモヤりを紹介しました。

特に今回は僕が明るくないターミナルという題材でagent任せな部分が大きかったというのはあると思います。

皆さんはこのようなモヤりに遭遇したことはあるでしょうか？
もし克服できているという人がいたらぜひ克服方法を教えてほしいです。

Ruby on RailsとParklifeで静的サイトを構築する

Mon, 28 Jul 2025 16:50:00 +0900

この記事ではRuby on Railsで静的サイトを構築する方法を紹介します。Parklifeというツールの力を借ります。

Parklifeとは

Parklife とは、公式サイトの言葉を借りると下記のようなツールです:

Parklife is a Ruby library to render a Rack app (Rails/Sinatra/etc) to a static build ready to be served by GitHub Pages, Netlify, S3, Vercel, or any other server.

要するにRailsなどのRackアプリを静的ビルドできますよーというものです。

僕はBen SheldonさんのLiving Parklife with Rails, coming from Jekyll | Island94.orgという記事を読んでこのツールの存在を知りました。
仕事でもRails書いてるし、個人サイトもRailsで書けるなら書いてみるかーとなったところ、Hugoで書いていたサイトをうまくすんなり移行させることができました。

やること

やることは単純で、普通にRailsアプリを書いて、コントローラーとビューに吐き出させたものをParklifeにコマンドでクロールさせてビルドするだけです。
ParklifeにはGitHub Pages用のGitHub Actionsのワークフローの生成機能もついているので楽ちんです。

書くのはRailsアプリそのものなので、モデルやヘルパーは思いのままです。また、テストもいつもと同じ感覚で書けます。
僕の場合は主にMarkdownのポストをHTML出力するブログ用のMVCをkramdown-parser-gfmやfront_matter_parserなどを使って書きました。
今は主にブログぐらいしかないですが、もっと色んなページで充実させてみたいと思わせてくれています。

参考になる記事とリポジトリ

サイトを構築するにあたって、Ben Sheldonさんの先ほどのブログ記事と彼のサイトのリポジトリが超参考になりました。
下手にサンプルコードを用意するより、このリポジトリを見て自分なりにアレンジしてみるとうまくいくと思います。

まとめ

皆さんもこの記事を読んで興味を持っていただけたら、Railsで静的サイトを作ってみてはいかがでしょうか。 Happy railing!

Rubyプログラムの対話型デバッグのこれまでとこれから

Fri, 13 Dec 2024 05:30:00 +0900

はじめに

この記事はSmartHR Advent Calendar 2024 シリーズ1の13日目です。『Rubyプログラムの対話型デバッグのこれまでとこれから』と題して書きます。

この話を書こうと思ったのにはきっかけがあります。プロダクト開発中に見つけた問題を修正して初めてRuby on Railsにコントリビュートしました！〜「OSSやっていきの集い」活動報告〜 - SmartHR Tech Blogという会社のテックブログを執筆中に、「binding.pryを使ってブレークポイントを設定しました」と書いていたところ、レビューで同僚に「binding.pryは使っていなくて使ったのはbinding.irbですよ」と指摘されました。

そういやこの辺りのRubyプログラムの対話型デバッグに使えるツール群についてよく分かっていないなということに気づいたので、調べるついでにまとめてみようというのが発端になって書いた記事です。

注意として、Web上の情報を元に書いたもので、僕自身の経験に基づいて書いた記事ではないですし、書いていることに間違いがあるかもしれません。その場合は指摘していただけると嬉しいです。

Rubyプログラムの対話型デバッグに関わるツール郡

まずはRubyプログラムの対話型デバッグに関わるツールにどのようなものがあって、どのように使われているのか調べてみることにしました。

どのようなものがあるかとしては、このような形にまとめられそうです:

対話型コンソールとして、主に2つがある
- Ruby標準のIRB
- サードパーティのPry
デバッガーとして、主に3つある
- Ruby標準のdebug.gem
- サードパーティのByebug
- サードパーティのdebase

そして、binding.irb や binding.pry などの行をプログラム中に挟んで、その行でデバッグコンソールを開くやり方が広く行われています。

Rubyプログラムの対話型デバッグのこれまでとこれから

では現状はどうなっているかというと、古くからサードパーティのPry + Byebug（pry-byebug）を組み合わせた対話型デバッグが主流でしたが、Ruby 3.1ぐらいにかけてIRBに不足していたPryの機能がIRBに取り込まれ、更にdebug.gemの登場により、両方ともRuby標準であるIRBとdebug.gemを組み合わせるやり方が勢いを見せているようです。
なお、ここまで名前が登場しなかったdebaseはRubyMineで使われています。

このIRBとdebug.gemと現状については、それぞれのコントリビューターの記事を読んでみると理解が進むと思います。

IRBについては実際にPryのヘビーユーザーでもありIRBへ機能を持ち込んだ本人でもあるk0kubunさんがその進化を語っています:
Pryはもう古い、時代はIRB - k0kubun’s blog

この記事から、Pryだけにあった機能がIRBに取り込まれていった様子が分かるかと思います。

debug.gemについてはRuby 3.1での導入時に笹田さんが書かれたブログがあります:
Ruby 3.1 の debug.gem を自慢したい - クックパッド開発者ブログ

Stan LoさんによるByebugとの比較記事もあります:
Ruby: byebugからruby/debugへの移行ガイド（翻訳）｜TechRacho by BPS株式会社

この2つの記事から、Byebugの開発が鈍る一方で、debug.gemがとても充実していっている様子が分かるかと思います。

また、Ruby on Railsだとどうかというと、debug.gemはRails 7からデフォルトのデバッガーになっており、Rails GuidesでもDebugging with the debug Gemというセクションがあり、debug.gemの binding.break を使う方法が紹介されています。

このように見てみると、IRBとdebug.gemが本当の意味でも標準になっていっているように見えます。

余談として、個人的なところだと、この組み合わせで、bidning.irb と binding.break という2つのブレークポイント、irb と rdbg という2つのモードを、どのように使い分ければ良いのかまだあまり分かっていません。お互いにコマンドを通じて行き来できるような作りになっていて、相互に持っていない機能を持っているというところまでは理解できています。この辺は実際に使いながら身につけていきたいなと思いました。

Kaigi on Rails 2024に参加した

Tue, 29 Oct 2024 13:35:00 +0900

2024/10/25(金)、10/26(土)の2日間に渡って東京の有明で行われたKaigi on Rails 2024に参加した。

去年はオンラインでの視聴だったので、今回が福岡からの初めてのオフライン参加だった。講演も交流もとても充実していて、自分にとって総合的に学びと楽しみがとても満足度高く得られたカンファレンスとなった。
スタッフの皆様、登壇者の皆様、交流してくださった皆様に感謝。

どれも素晴らしい体験だったけど、その中から抜粋して振り返っていきたい。

Palkanさん

まずはPalkan（@palkan_tula）さんの基調講演「Rails Way, or the highway」、いやー本当に良かった。

というのも、僕の所属するSmartHRでは、彼の『Layered Design for Ruby on Rails Application』の読書会をイベントの直前にやるというのを僕が企画して、参加者5人で読み上げてきたところだった。
参加した皆が良い本と言っていて、今回の基調講演も期待が高まっていたのだけど、直近ではWASM関連のお話をされていたので、今回もそのお話になるかなと思っていたら、がっつりと本でもテーマのRails Wayとその拡張のお話だったので、「あ〜読書会やって良かった」となった。

Rails Wayという哲学を解釈し、どう拡張していくかというRailsに10年以上向き合ってきた彼だからこそできる講演になっていて、感激するとともに、改めて奥の深いフレームワークだなと思った。

そしてPalkanさんにはイベントの1週間前に「会社で読書会をやりました！本はとても良かったです！時間があるならイベントでお話させてください！」とDMしたら「親切な言葉をありがとう！話しましょう！」と言ってくれていた。
いつ声をかけようとドキドキしながらイベントに参加していたところ、懇親会で声をかけようとなり、同僚の英語話者の@NivekReetsの助けを借りて少しの間お話することができた。とてもフレンドリーに言葉に耳を傾けてくれて嬉しかった。「講演中の介入より抽出という言葉が特に印象に残しました」というのを伝えたかったんだけど、「介入」の英訳が出てこなかったりしてうまく伝えられず、TOEIC 960なんてこんなものだよというのを痛く味わった。英語をfluentに喋れるようになりて〜。

というわけでPalkanさんの講演と彼との交流が僕のKaigi on Rails 2024ではハイライトだったように思う。

講演のスライド: [Kaigi on Rails 2024] Rails Way, or the highway - Speaker Deck

ワークショップ: Rackを理解しRailsアプリケーション開発の足腰を鍛えよう

お昼休みは2日に渡ってRackを学ぶ「ワークショップ: Rackを理解しRailsアプリケーション開発の足腰を鍛えよう」 by @hogelogさんに参加。

ちょうどPalkanさんの本でRackの話が出ていて、会社の人に「Rackを学ぶのに良いリソースってありますかねぇ」などと聞いていたのでタイムリーだった。

短い時間の中、お弁当をかきこんでの参加だったのだけど、RackアプリケーションからRackサーバーの作り方まで短い時間で学べ、Rackと少し仲良くなれたワークショップだった。
Railsアプリケーションの裏でこんなものが動いているのだし、その上で成り立ってるんだなぁという気持ちになれた。

hogelogさんやTAの方々、ありがとうございました！

ワークショップの資料: hogelog/kaigionrails-2024-rack-workshop: Rack workshop at Kaigi on Rails 2024

RailsのPull requestsのレビューの時に私が考えていること

@yahondaさんの講演「RailsのPull requestsのレビューの時に私が考えていること」、これも良かった。

最近、同僚と共に初めてrails/railsにコントリビュートしたりしたこともあって興味をもって聞いた。Railsの話ではあるものの、タイトルが大事であったり、そこにユーザーストーリーはあるかといった話は、社内外含めて他のリポジトリのPull requestにも、果てはプロダクト開発全般にも応用できるものだと思った。

講演のスライド: RailsのPull requestsのレビューの時に私が考えていること - Speaker Deck

Rubyで型を扱うためのRBSの概要とRailsプロジェクトへの痛みのない導入方法

Fri, 08 Dec 2023 08:48:00 +0900

この記事の概要

これはSmartHR Advent Calendar 2023シリーズ 1の8日目の記事です。

この記事では、Rubyで型を扱うための基盤であるRBSについて、いくつかのリソースを参照しながら、説明および、既存のRuby on Railsプロジェクトに恩恵だけに預かる形での導入方法を紹介します。

sinsokuさんのRailsアプリと型検査というスライドを見て、そんな形で型定義の導入ができるのか、となったことがきっかけで試してみたことです。ありがとうございます。

RBSとは

RBSを含めたRubyの静的解析機能周りについてはRuby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログに短くまとまっています。
これによると、RBSはその言語を主体とした4種類からなる「型を扱うための基盤」と言えるようです。

また、RBS単体については、RBSのコミッターであるPockeさんがRubyWorld Conference 2023で講演したRBS Tutorialに15分でよくまとまっています。

かいつまんでまとめると、以下のような感じです:

RBSのファイル（.rbs）はRubyのファイル（.rb）からは完全に分離されている
- TypeScriptの.jsと.d.tsと似た感じ
Rubyと構文が違う
- SorbetはRubyのコードで型を書くのでそこは違う
RBSの環境は.rbsファイルしか参照しない
構文はこちら: https://github.com/ruby/rbs/blob/master/docs/syntax.md

この講演では後半でRBSの小さな始め方についても触れられているので、興味のある方はぜひ動画を観てみてください。

実際に既存のRuby on Railsプロジェクトに導入する

RBSが何なのかぼんやり分かったところで、さっそく既存のRuby on Railsプロジェクトに導入してみましょう。

ここではRBSに対応した静的型検査ツールであるSteepを利用して、Visual Studio Codeでの主に補完機能の強化を行うことを目標にします。
Steepは型違反のチェック機能なども持っていますが、ここでは無視します。また、自作コードに型定義を追加することはせず、既存のgem周りの型の定義だけ取得することにします。これらは対応するのにそれなりの工数がかかるであろうためです。

冒頭で挙げたsinsokuさんのスライドと、そちらで紹介されていたRailsプロジェクトへの「頑張らない型導入」のすすめ - メドピア開発者ブログを存分に参考にします。

Steepをセットアップ

まずはSteepをセットアップします。

Steepはこのようなものです（引用）:

Steep は、Ruby の静的型検査器です。RBS を使って、伝統的な漸進的型付けによる型検査を行うことができます。単に型エラーを検出できるだけではなく、LSP を実装しているので、エディタ上での型エラー表示、補完、ドキュメント表示なども実装されています。

Ruby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログより。

Gemfileに以下のように :development グループに追記します:

group :development do
 gem "steep", require: false
end

bundle install を実行します。
bundle exec steep init を実行します。
Steepfile がプロジェクトトップディレクトリに出来るので、以下のように書き換えます:

サイトをHugoで作り直しました

Sat, 02 Dec 2023 08:25:00 +0900

Astroで作っていたこのサイトを、HTML/CSSだけで書いてブログははてなブログにリンクする形にしたのですが、期待していたアクセス数の伸びはそんなになく、「やっぱ自分のローカルにデータが残るのいいよなぁ、記事も見る人が見てくれればいいや」ということで、またSSGに戻すことを検討しました。

Astroを使っていたときは、バージョンアップの頻度が高くてDependabotで更新する作業が面倒だったのですが、Hugoならそんなにバージョンアップ頻度も高くなさそうということで（Go好きだし）思い切って移行しました。

テーマを使ったら使ったでそれがまたメンテの対象になりそうなので、レイアウトなどは自前で作りました。

あっちにいったりこっちにいったりしてますが、今回はしばらくいじらなくて済むことを期待しています。

『Eloquent Ruby』でRubyistになるための文化を吸収できた気がする

Sat, 23 Sep 2023 11:10:09 +0900

『Eloquent Ruby』というRuss OlsenによるRubyについての本を読みました。
https://www.amazon.co.jp/dp/0321584104

僕の所属するSmartHRではRubyをメインのバックエンド言語としており、もっとRubyについて知りたかったのと、redditなどでおすすめの本としてよく挙がっていたというのが読むに至った動機です。
2011年出版の本であり、ターゲットRubyバージョンは1.9と古いですが、今でも十分に役立つことが多く書いてありました。

著者のRuss Olsenは他にDesign Patterns in Rubyなども書いています。
https://www.amazon.co.jp/dp/0321490452

本の構成

構成としては、以下の通りです:

PART I: The Basics
PART II: Classes, Modules, and Blocks
PART III: Metaprogramming
PART IV: Pulling It All Together

PART Iでは、Rubyの基本的な書き方や、制御構造、コレクション、文字列、正規表現、シンボル、オブジェクト、ダック・タイピング、テストについて書かれています。

PART IIでは、クラスについて、演算子のオーバーライドや特異メソッドの使い方。また、モジュールについて、名前空間としての使い方と、ミックスインとしての使い方。そして、ブロックについて、イテレートでの使い方と、「execute around」での使い方と、あとで実行するための使い方について書かれています。

PART IIIでは、メタプログラミング的なところで、フックについて。また、method_missingについて、柔軟なエラーハンドリングに使う場合と、委譲に使う場合と、柔軟なAPIを作る場合について。そして、モンキーパッチや、自身やサブクラスを変更するクラスの作成方法について書かれています。

PART IVでは、内部DSLや外部DSLの作り方、Gemの作り方、Ruby実装について書かれています。

各章は、それぞれのトピックについて、全体を通してドキュメントを扱うプログラムをメインにコードも交えて説明し、In the Wildというコーナーで、RailsなどのgemやRubyビルトインコードでその章で紹介したトピックが実際にどのように使われているかを書き、Staying Out of Troubleというコーナーでトラブルを避けるためのtipsを紹介し、最後にWrapping Upというコーナーでまとめるという構成になっています。

感想

良いRubyプログラムを書くにはどうすればいいかということから始まり、privateなメソッドも send を使えば呼ぶことができたり、クラスがオープンであることなど、プログラマーが責任を負うことを重視しているといった、Rubyの哲学まで知れた気がしてとても良い本でした。
前書きで、Rubyを使いこなすには言語の構文といった基礎だけでなく、文化を吸収することが大事ということが書かれていました。この本を読むことで、Rubyの文化を知り、Rubyを使いこなすにあたってどのような姿勢で取り組めばいいかが少しつかめたような気がします。
あとは、In the Wildというコーナーが特に面白かったです。魔法のように使わせてもらっているgemやRuby自体も、当たり前だけど1つ1つあの手この手を使って人の手で書かれているのだなぁと再認識しました。

今後も必要な時に参照して、良いRubyのコードを書く一助になってくれる気がしています。良い本でした。

子育てをしながらのスキルアップに対する焦りと向き合うために決めたこと

Sat, 23 Sep 2023 11:10:09 +0900

僕は昨年1月に結婚した妻と、昨年7月に生まれた子どもの3人で暮らしている。

子育てが始まると時間が無くなるとはよく言うものの、本当にそうだというのを、子が1歳を過ぎた今も痛いほど実感している。
平日は仕事と家事をこなしたあとは疲れで何もやる気が起こらないし、休日は買い物やら子どもの世話やらであっという間に終わっていく。

時間が無くなることで、自分の中で特に問題になったのが、スキルアップを満足にできていないという焦りが生まれてくることだ。
休日に家族の相手をしていても、「あ〜あれもこれもまだまだ覚えることがたくさんあるのにやばいなぁ」とかそんな考えが頭を支配したまま過ごしてしまったりする。

しかし、これって学習ができていないことを家族のせいにしていないかということに気がついた。
そもそも独身時代に学習に打ち込めていたかというと怪しい気がする。
こんな心理状態になっているのは自分にとっても家族にとっても何も良くないと思った。

そこで、家族と過ごす時間は目の前の家族と全力で向き合う時間にし、学習は独りになれる時間だけに集中して行うことにしようと決めた。
平日朝、妻子を送り出してからリモートワークの始業時間まで1時間ある。そこを学習時間にする。
今は疲れで始業まで二度寝してしまったりしているので、まずは運動などで体力をつけて疲れに打ち勝てるようにし、その時間を学習に充てる。
スキルアップに天井はないのだから、無限に時間があったとて、それでも足りないと思うのが心情だろう。継続すれば毎日1時間でも、やがては積み上がっていく。それで十分じゃないか。

子育てというたいへんな幸せを過ごす中で、スキルアップとどう向き合うかは難しいところだけど、僕はこのように、学習する時間はここだけというのを決めて、それだけできれば十分というように、考えることを減らすことにした。
子育てもスキルアップも丁度良く楽しく頑張っていけたらと思う。

『Atomic Habits』を読んで運動の習慣を身につけられそうな気分になった

Sun, 13 Aug 2023 11:33:51 +0900

僕は妻と1歳の子と3人で暮らしています。
子育てをしながら毎日を生きていると、疲れて機嫌が良くない状態になってしまったり、仕事以外のことをやる余裕がなくなったりということが続いてしまいます。
これは体力が無いことも一つの要因ではないかと、体力をつけるために運動をしなければと思いつつ、運動をするための体力がなくて、いつまでも体力がつかないという悪循環に陥ってしまっています。

そんな自分を変えたくて、運動習慣をどうにかして身につけたいと、習慣に関する本として度々名前が挙がっていた『Atomic Habits』（邦題: 『ジェームズ・クリアー式複利で伸びる1つの習慣』）を読んでみたのでした。
https://www.amazon.co.jp/dp/4775942158

本の紹介

この本では、まずどんな人になろうとするのかが大事と語られています。例えば、読書をすることではなく、読書家になることが目標、マラソンを走ることではなく、ランナーになることが目標といった具合です。
そして、習慣によってあなたは習慣そのものになるのだと言っています。

また、習慣には4つのステップがあると言っています。

きっかけ (Cue)
欲求 (Craving)
反応 (Response)
報酬 (Reward)

なんかよく似たものを見たことがあるなぁと思ったら、Courseraの『Learning How to Learn』で知った習慣の4つの要素でした。こちらはCue（きっかけ）、Routine（決まりごと）、Reward（報酬）、Belief（確信）とされていてちょっと違いますね。
https://tkykhk.hatenablog.com/entry/2016/07/03/175252

それはさておき、さらに、良い習慣を作るための4つの法則を紹介しています。

分かりやすくする (Make It Obvious)
魅力的にする (Make It Attractive)
簡単にする (Make It Easy)
満足感のあるものにする (Make It Satisfying)

具体的な適用方法の例を順に紹介します。

分かりやすくするための1例として、「いつ、どこで、〜をする」といったように決めておくことがあります。
魅力的にするための1例として、やりたい（want to）行動を、しなければならない（need to）、つまり習慣化したい行動に結びつけることがあります。
簡単にするための1例として、2分ルールという、とりあえず2分だけやるといったルールに従うことがあります。
満足感のあるものにするための1例として、即時の報酬を自分に与えるようにすることがあります。

基本的には、この習慣の4ステップと、4つの法則について、様々な実験のデータなどを根拠として説明していく本です。
どこかで聞いたことのある話も多分にありつつ、習慣を身につけられそうな気分にはさせてくれました。

本を読んで実践していく

ただ、頭で理解しただけじゃだめだと思い、じゃぁ運動習慣を身につけるためにどうやっていく？というのを考えてみました。

まず、何を習慣化させるかというところですが、Fit Boxing 2をやっていこうと思います。酷暑の中、室外で運動するのは厳しく、家の中でなら費用もかからず、すぐ習慣化を始められそうな気がするからです。

次に、4つの法則に基づいて行動設定をしてみます。

「分かりやすくする」ために、朝、妻子を見送ったら、帰ってきてすぐ始めることにします。
「魅力的にする」ために、運動をして初めて、学習をしていいことにします（学習がwant toって自分ながら偉いなと思いつつ）。
「簡単にする」ために、ゲームのおすすめ1セッション時間である38分より短く、28分から始めます。また、毎日とは言わず、まずは週3日からスタートします。
「満足感のあるものにする」ために、エクササイズが終わったら、報酬としてお気に入りの味のプロテインをゴクッと飲むことにします。そのあとのシャワーも報酬に入れてしまいます。

ここまで書いて、最初から目標を高く持ちがちだったので、特に「簡単にする」ことで、なんだか続けていけるような気がしてきました。

まとめ

この本では冒頭で、重要なのはゴールの設定ではなくシステムであると言っています。
システムは設定したつもりになれたので、家族の幸せのためにも、あとは朝に拳を振っている姿を続けていこうと思います。

近況 - SmartHR入社とか

Sat, 03 Jun 2023 14:20:00 +0900

ここのところブログをあまり書けてなかったので近況でも書いてみる。

GMOペパボ退社

2019年9月から約3年半所属したGMOペパボを退社した。

30代半ばにして正社員経験がなく技術的な経験も浅かった僕を雇ってくれた、とても懐の深い会社だと思う。
ホスティングという広く深い世界で、様々な技術や知識を得ることができた。
ペパボで大切にしている3つのことのうち、特に「みんなと仲良くすること」という点について実践できたように思う。なぜか鹿児島のメンバーと特に仲良くさせてもらったりもした。
ペパボのエンジニアは皆レベルが高く、エンジニアとしても人としてもロールモデルと言えるような人に出会えたのもとても大きかった。

3年半、本当に充実していた。ペパボが今後の自分の中での基準になっていくことだろうと思う。

SmartHR入社

色々と考えた上で転職活動した結果、縁があって2023年4月にSmartHRに入社した。

オリエンテーションがとても充実していて、色んなグループの色んな背景や活動を頭にインプットすることができ、会社がどうやって動いているのかを初めから知ることができた。
開発面ではスクラムが取り入れらており、僕はアジャイルから未経験なので、色々と本を読んだりして、そのキャッチアップを行っている。
クロスファンクショナルが推進されていることもあり（クロスファンクショナルという言葉の定義が今も自分の中でフワッとしてはいるものの）、フロントエンドを触ってみたりもしている。

40歳も遠くない今、これから数年のがんばりが今後のキャリアに大きく影響するだろうと思うところもあり、しっかりやっていこうと考えている。

妻が復職、子が保育園入園

SmartHR入社と同じ4月から妻が復職し、子が保育園に入園した。

妻の出社が早いため、夫婦とも6時に起きて、妻が準備をする間、朝ご飯を作ったりといった朝の生活に変わった。
子は早速、保育園で風邪をもらってきて家族みんなに感染ったり、突発性発疹が出て治ったかと思いきやまた別の発疹が出たりと洗礼を浴びた。

なかなか学習の時間が取れない生活なので、工夫していく必要がありそうというのを感じている。

これから

今後はひとまず、仕事で使っているRuby、Ruby on Rails、React、Next.jsといった技術に熟達したい。チュートリアルを読みつつ、サンドボックス的なWebアプリケーションを自作して、手を動かしながら覚えていきたいと思っている。

一方で、今年の抱負などでもずっとやりたいと言っている数学は、残念ではあるがしばらくやれなさそう。
単純に時間がない。色々やりたいけど子育てしている以上、選択の必要がある。

というわけで、家族との時間を大事にしつつ、研鑽を小さくコツコツ重ねていきたい。

単一NotionページをScrapboxページ用テキストに変換するNode.jsツール、notion2sbを作った

Tue, 10 Jan 2023 21:00:00 +0900

最近はGoのCLIツールを作ったり、学んだりするのが一番楽しいと思う今日この頃なのですが、ふとNode.jsとTypeScriptでもCLIツールを作れないかと思い立ちました。

何かネタはないかな〜と思っているうち、そういえばScrapboxもNotionもよく使うのだけど、Scrapbox→Notionの記事などはあっても、逆のNotion→Scrapboxのものはあまり無いなぁと気づいたのでした。

そこで出来たのがnpmパッケージとして公開した、notion2sbというツールです。

何をするツール？

名前はpastakさんのmd2sbにならっています。
md2sbはMarkdownをScrapboxテキストにエンコードするツールですが、md2sbがMarkdown→Scrapboxなら、notion2sbはNotion→Scrapboxというわけです。

そして、実際のところ、名前だけでなく、ほとんどの処理をmd2sbに委譲しています。
どういうことかというと、READMEにも書いていますが、notion2sbがやっているのは、NotionからMarkdownとしてエクスポートされた単一ファイルを、md2sb互換のものに変換し、md2sbにそれを渡しているというものです。
具体的には、Notionの数式記法などは、そのままmd2sbに渡すとエンコードされないため、notion2sbにて事前変換を行っています。

それに加えて、ページ中の画像を抽出し、shokaiさんのgyazo-apiを利用してGyazoにアップロードし、画像リンクをGyazoのURLに置換するということも行っています。
そのおかげで、Notionのページに貼ってあった画像を、そのまま変換されたScrapboxのページでも表示することが可能となります。

この通り、やっていることとしてはそんなに大きくないツールです。実際、行数としても100行程度です。

何を学べたか

このツールの作成を通じて、何を学べたか書いてみます。

慣れないTypeScriptを、WebStormに怒られつつ、型を付けながら書いて学ぶことが出来た。
Node.jsでのCLIツールの作り方の初歩を覚えた。
tsconfig.jsonなどを調整し、モジュールを、古いものも含めて、互換性を保ちながらインポートする方法を学んだ。
npmパッケージの公開の仕方が分かった（やってみるとめちゃ簡単！）。
NotionやScrapboxのテキスト形式をより知ることが出来た。
Gyazo APIの挙動を知ることが出来た。

けっこう学べましたね。こんな小さなツールでも、実際に手を動かすと色々なことが学べるという良い例かもしれません。

今後どうしたいか

さて、この小さなツールですが、まだまだ未完成なので、次のようなことをやっていきたいです。

md2sb互換のMarkdownに変換しきれていない部分も多い（リストなどのブロックが空ブロックを挟まずに連続していると乱れる、など）ため、改善したい。
複数ページ変換機能
- 単一ページにしか対応していないため、ゴソッと複数ページをバルクで変換する機能も追加したい。具体的には、インポートしやすいようにScrapbox用のJSONファイルに変換することになりそう。
- 変換したページへのリンクを維持したまま繋げられるようにする。
- 複数ページを変換する際に、ページ名が被った時の処理を考える。

まとめ

というわけで、notion2sbの紹介と、その作成を通じて思ったことを書いてみました。

アイデアを形にするまで、それほど時間はかかりませんでしたが、洗練度を上げることにこそプログラミングの本質があるのかもしれないという意味で言えば、まだまだ未完成なものだと思います。

機会があれば、改善を重ねていきたいです。

2023年抱負 - 家族第一に、数学と機械学習をやる

Tue, 03 Jan 2023 11:51:00 +0900

子と過ごす初正月、家族に囲まれてとても幸せに満ちていたなーと思いつつ、恒例の年初抱負を書いてみる。

技術

機械学習

昨年はMidjourneyやChatGPTが世に出たりすることで、AIが飛躍的な進歩を遂げた年だったように思う。
流れに置いていかれて、その辺りの領域をブラックボックスにしたままでは、自身のキャリアとしても、技術の利用者としても危険だと思い、今年は機械学習を真剣にやっていくことにした。

去年の抱負から言い続けていることではあるが、今年は本気度を上げて取り組んでいきたい。

数学

そのためにも、まずは数学をやる。

僕は高校を1年で中退していて、20代半ばで受けた高等学校卒業程度認定試験も英語だけ受験して取得した。そのため、まずは高校数学からと思っている。Long long journeyではあるがやっていきたい。

手始めに長岡の教科書をやり終えるところから（今は数学IIの途中）。
AIの第一人者であるAndrew Ng先生が関わるMathematics for Machine Learning and Data Science Specializationという、まさに自分のためのようなコースが1月にリリースされるようなので、それもやっていきたい。

家族

今は何よりも家族の幸せを優先にしたいと思っている。去年、子が生まれたことで、ますますその思いが強くなった。
今年の4月には妻が仕事に復帰し、子が保育園に入る予定なので、できる限り家事を協力的にやっていく。
学習にかけられる時間は少なくなるだろうから、技術は流行りのあれこれに手を出すのではなく、ファンダメンタルなものをやっていくことになるかもしれない。

まとめ

今年はこんな感じになりそうだろうか。やる事としては、かなり絞った形となる。

去年もやる事は最小限にと書いていたが、その方針は変わらないだろう。
家族の幸せを第一に、毎日の小さな喜びを大事にしながら、楽しく過ごせていけたらいいなと思っている。

2022年振り返り

Thu, 29 Dec 2022 14:33:00 +0900

今年も恒例の年の振り返りをする。

2022年抱負 - 数学と機械学習、楽器をやっていくに書いたことを中心に振り返っていく。

技術

数学

やろうと思ったものの、長岡先生の授業が聞ける高校数学の教科書の数学I+Aを終えて、少し数学IIを進めるに留まった。
時間が取れなかったり、他に優先したことがあったりで、なかなか時間が取れなかった。

機械学習

全くやれていない。まぁ、そもそも前段として数学をやる必要があるので当然ではある。今年はAIが飛躍的な進歩を遂げたと言っても良い年だったので来年こそはやる。

Go

本を『The Go Programming Language』、『エキスパートたちのGo言語』、『実用 Go言語』、『Powerful Command-Line Applications in Go』と読んだりと、結果的に昨年に続き一番力を入れた技術となった。
ただ、目立ったアウトプットを残せていないのは課題。もっと課題を発見し、形にする力をつけていきたい。

趣味

楽器

全くもってやれていない。まぁ、結婚したり子どもが生まれたりで、今は厳しい感じではある。でも、いつかは教室に通ったりバンドを組んだりということをやりたい。

XR

持っていたMeta Quest 2は売り払ってしまった。こちらについても、結婚して子どもが生まれて、家でヘッドセットをつけるのがこっ恥ずかしいというのがあった。よっぽど今後流れが来ない限り、おそらくもう手を出すことはないかなぁという感じ。
メタバース的なものだと、タッチポイントがXRである必要もあんま無いのかなぁとか思ったりしている。そもそも既存のMMORPGなんかだって立派なメタバースなんじゃないかとか。

まとめ

今年の抱負では、まとめとして、

やることは最小限に、あまり根を詰めずに余裕のある豊かな日々を送れたらと思っている。

と書いていたが、結婚と、子どもが生まれたことにより、やることを最小限にするのは必然の結果となり、根を詰めないというところは重要になってきたと思う。
豊かな日々は送れたので、そういう意味では達成出来たのかなという感じ。

まぁ、とにもかくにも子どもができたというのはとてつもなく大きなイベントであったし、それに尽きた年だったと思う。
大きな苦労もあったが、大きな幸せもあった。改めて妻や支えてくれる方々に感謝。

その子育てもだいぶ慣れてきたので、来年はもっと余裕のある年になるかもしれないと思っている。

ではでは

それでは、今年もお世話になりました。来年もどうぞよろしくお願いいたします。
みなさま良いお年を！

ブログをAstroに移行した

Wed, 21 Dec 2022 19:45:00 +0900

個人的に尊敬しているRyosuke IWANAGAさんによるブログ記事、カナダで自分の会社を作ってみた - As a Futurist…で見かけたAstro（公式サイトによるとall-in-one web framework）が気になったので、Gatsbyからガッと移行してみたら簡単に移行できました。

記述も楽だし、サイトは速いし、Vercelでのデプロイも一瞬だし、いい感じです。
Gatsbyは自分のブログには少しオーバースペックな感じでした。

デザインは公式のBlog | Astroテーマほぼそのままですが、読むのにフォーカスできていい感じになったかなと思ってます。

ではでは、これからもこのブログをどうぞよろしくお願いします。

書籍『Powerful Command-Line Applications in Go』でGoによるCLIツール作成のための「パワー！」をもらった

Wed, 21 Dec 2022 15:57:00 +0900

この記事は🎅GMOペパボエンジニア Advent Calendar 2022の21日目の記事です。

まず始めに: GoとCLIツールの相性の良さ

Goの主な用途にCLIツールを書くというのがあると思います。

シングルバイナリにコンパイルされることや、クロスコンパイルが容易なことから、kubernetes/kubectlやhashicorp/terraformといった広く使われているCLIツールもGoで作成されています。

私も、tommy6073/takolabelという、GitHubのlabelsを複数のリポジトリに跨って操作できるツールを作成したりしました（このツールが生まれた経緯についてはこちら: 初めてのGo製CLIツール作成、初めてのOSS公開に込められた物語）。

特に、Goで作成されたCLIツールのユーザーとして思うのは、依存関係を気にすることなく、バイナリ1発で実行できるというのが本当に強力だということです。

そして『Powerful Command-Line Applications in Go』と出会った

さて、そんなこんなで、GoでのCLIツール作成技術を上げたいなと思っていたところ、redditのr/golangでこんなポストを発見しました:

Is there a practical Golang entry point for experienced programmers? : golang

PythonによるAutomate the Boring Stuff with Pythonに相当するGoの本はないかとの質問ポストでしたが、それに対するコメントの中にPowerful Command-Line Applications in Go: Build Fast and Maintainable Toolsが紹介されていたのです。

発売時点ではRed HatでAutomation Consultantとして働いているRicardo Gerardiによる本とのことで良さそうと思い、早速買ってみて読んだところ、これが実際にとてもとても良い本だったのでした。

この本では、実際に動くCLIツールを、サンプルコードと共にテストを書きながら学びます。
そのトピックは、ファイル、プロセス、REST API、インタラクティブなターミナルツール、SQLデータベースと広範囲です。そのことから、CLIツールに留まらず、Goでテスタブルな良いコードを書く方法を学ぶのにもうってつけです。

この記事では、その中から特に役に立つと思ったtipsを何個かご紹介します。気になった方は是非本を買ってみてください。

標準出力のテストにはio.Writerを使う

標準出力のテストってしづらいですよね。そこがio.Writerの出番です。
テストしたい関数の引数に、io.Writerを指定し、実際の実行ではos.Stdoutを使い、テストではbytes.Bufferなどにキャプチャさせて比較させるのです。

ずいぶんと既知の方法ではありますが、実際に動くCLIツールの例をもって教えてくれるので、頭にスッと入ってきます。

余談ですが、こういう時にGoの美しいインターフェイスの設計を思い知らされます。

パッケージを適切に分ける

なんでもかんでもmainパッケージに突っ込む、というのは避け、外部から利用できるような形でパッケージを分けます。
そうすることで、ローカルで使っていたものをWeb APIのモデルとしても再利用させるといったことができます。

自分自身がユーザーだとしても、責務の境界線を敷いたりといったことに役に立つはずです。

Repositoryパターンを使う

Repositoryパターンにより、データソースを簡単に切り替えられるようにします。

操作系を、インタフェースのメソッドとして定義し、実際の操作はインメモリやSQLのものとして実装させるのです。これにより、テストもしやすくなります。

これもずいぶんと既知の方法ですが、繰り返しになるものの、実際に動くCLIツールで示してくれるので、とても解りやすいです。

統合テストは実APIなりを叩く方法もある

結合テストをどう書くか、というところはけっこうな悩みどころだと思います。
モックを使うと実際のAPIに追従できなかったりという問題が起こる可能性がありますし、実際のAPIを叩くと実環境に影響がでる可能性があります。

そこで、この本では、build constraintsを使い、統合テストファイルにtagを付与した上で、通常のテストでは実行されないようにし、-tagsオプションを使って散発的に実行するようにしています。

ゲームのタイムアタック、シューティングゲーム、プログラミングにおける最適化の共通点

Sun, 13 Nov 2022 15:41:00 +0900

僕は現在はソフトウェアエンジニアとして働いていますが、定職に就く前は働かずにゲームをとことん遊んでいました。

その中でも特に遊んだのが海外ゲーム、そしてシューティングゲーム（海外では「Shoot ’em up」と呼ばれます）です。
海外ゲームについては普通に遊ぶのはもちろんですが、いかに早くクリアするかということをしていました。いわゆるタイムアタック（海外では「Speedrun」と呼ばれます）というものです。

これらのこととプログラミングは全く関係ないようですが、プログラミングをしている中で、時々、これらのことでやってたことじゃないか、と思う場面があります。

抽象化できる共通点があるのではないかと思い、この記事で言語化を試みてみます。

遊んでいたゲームの種類

どういうゲームを遊んでいたかという文脈が大事になってくると思うので、説明をします。

海外ゲーム

海外ゲームについては、特にFPSやRPGを遊んでいました。それぞれの代表作のうち、シングルプレイヤーのもので僕が遊んでいた頃で言うと、Half-Lifeシリーズ、Diabloシリーズといったところでしょうか。タイムアタックがどのようなものかというのは動画を見ていただくと分かると思います。 ※3D酔いというものがあるので、苦手な方は注意をお願いします。
今はVRに注力するJohn Carmackも主要な開発者であるQuakeというゲームのものです。
https://www.youtube.com/watch?v=hcareEsIXHM

どうでしょう。極めて無駄のない動きじゃないでしょうか。

シューティングゲーム

シューティングゲームとなると、どういうゲームか馴染みのない方もいると思うので、ご紹介します。先祖はインベーダーゲームとかになるのでしょうか。どういった様子かは動画を見ていただいたほうが早いと思います。
僕も大好きだった、難易度が最高級に高いと言われている怒首領蜂大往生の動画をご紹介します。
下記リンクは「2周目」という、同じステージを難易度を大幅に上げて臨む場面からスタートします。
https://youtu.be/VIELWhnLicY?t=1201

どうでしょう。鬼のような難易度じゃないでしょうか。

共通点

では、タイムアタック、シューティングゲーム、プログラミングにおける最適化の3つに共通するものとは何でしょうか。
それらについて、1つずつ見ていきたいと思います。

1つ目の共通点「観察」

まず、1つ目は「観察」です。

タイムアタックでは、ステージがどのような構成になっているか、敵キャラクターがどのような動きをし、どのような攻撃をしてくるか、どこにアイテムがあるか、などを観察します。
シューティングゲームも同様です。敵キャラクターがどのような動きをし、どのような弾を撃ってくるか、などを何回も何回も何回もプレイすることで観察します。

では、プログラミングにおける最適化はどうでしょうか。こちらも、どのような処理が行われていて、どこにボトルネックがあるかを観察します。「観測」という言葉のほうがこの世界では一般的ですかね。

プログラミングではリバースエンジニアリングという言葉がありますが、タイムアタックやシューティングゲームにおいても、ただ観察するだけではなく、時にはゲームの実装まで予想しながら分析をすることもあります。

2つ目の共通点「試行」

2つ目は「試行」です。

タイムアタックでは、このジャンプやアクションでショートカットが可能か、このアイテムは取らずとも十分に進行させることが可能か、といったことを試します。
シューティングゲームでは、どの順番で敵を倒すのが安全か、どのようにコンボを繋げば点数が高くなるか、といったことを試します。
どちらも、何百、何千、何万、いや何百万といった試行になるかもしれません。

プログラミングでは、仮説や実証に基づき小さな単位で変更を行います。小さな単位で行うのは差分を細かくチェックするためで、タイムアタックでもシューティングゲームでも同じですね。

3つ目の共通点「評価」

3つ目は「評価」です。

タイムアタックでは、試行した結果、それによりどれだけのタイムが削られたか、Aを選んでBを捨てた結果、それ以降の流れはどうなるかといったことを評価します。
シューティングゲームでは、動きのパターンを決めたことでどれだけ楽になったか、点数が実際に上がったか、といったことを評価します。

プログラミングでは、実行速度やリソースの消費が改善されたかどうかを評価します。

この観察→試行→評価という流れは、ゲームかプログラミングかでサイクルは違えど、改善のためにひたすらループを回すものとなります。

4つ目の共通点「結合」

最後が「結合」です。このフェーズで、これまでの3つが実際に機能するかどうかチェックすることになります。

タイムアタックでは、それぞれのステージで決めた動きが全体としてのタイムの削減に繋がるかを、通してチェックします。
シューティングゲームでは、1ステージ目では低スコアに終わる動きでも、2ステージ以降ではトータルで高くならないか、といったことをチェックします。

プログラミングでは、結合テストなどを行い、1つのコンポーネントの変更が他に影響を与えていないか、トータルではパフォーマンスが下がっていないかといったことをチェックします。

最後に

ここまで、ゲームのタイムアタック、シューティングゲーム、プログラミングの最適化における共通点を書いてみました。

勢いで雑に書いてみた文章ですが、他にこれらのことを経験した方なら、もしかしたら「うんうん」と頷いていただけるかもしれないですね。
共通しているのは根気いるよね〜というところでしょうか。
書いていて思ったのですが、もっと広く一般化できるものなのかもしれませんね。

最後に一言、「最適化 is fun」

数学を一生の趣味にしてみる

Mon, 05 Sep 2022 08:25:00 +0900

子どもが生まれて勉強に取れる時間も必然と少なくなったので、勉強することを絞る必要があるのだが、何をやろうかと思った時に数学をやっていこうとなった。

きっかけとしては、アルゴリズムとデータ構造みたいな基礎的な技術を身に着けるのが長期的に見て役に立つのではないかと思い、問題解決力を鍛える！アルゴリズムとデータ構造を読み始めたところ、序盤に極限の式が出てきて読み取れず、やっぱ数学やった方がいいなとなったことがある。

前から、競プロや機械学習をやりたいが、数学力不足を感じていたというのも大きい。
2016年のプログラマーとして社会人になったけど高校数学を1から独学しているという記事にも書いたが、高校を1年で中退しているので、単純に数学コンプレックスみたいなものを持っているというのもある。

そこで考えたのが、数学を一生の趣味にするのもいいんじゃないかと。
詰将棋を解くような感覚で数学の問題を解いていく。
『虚数の情緒』や『オイラーの贈物』といった読み物の楽しみにも事欠かない。

業務力向上には直接的にはほとんど結びつかないとは思うのだが、業務に関することは業務中に覚えてしまえばいいし、長期的に見れば数学の応用が必要になる場面が来て、やがて実を結ぶかもしれない。

そんなわけで、まずは高校数学の勉強を進めており、長岡の教科書の数学I・Aを終えた。
教科書を読んだだけでは身についた気がしないので、問題集をやろうと数学I・A 入門問題精講を始めた。定番のチャート式はボリュームが大きすぎる感があるのでこちらを選んだ。著者のツイートで社会人にも勧められていたのがけっこう決め手になった。「はじめに」の中で、公式や定理を丸暗記するのではなく、その過程で身につける「考え方」が大事であり、魚を与えるのではなく、釣りの仕方を教えるという話をしているのも良い。
これと並行して基礎問題精講もやっていく予定。

今は妻子が起きる前の朝6時に起きて、1時間を勉強に充てている。
これから続く数学の旅でどこまで行けてどんな景色が見れるのか、楽しみだ。

お子がもうすぐ生まれる予定なのでルーチンを見直した

Sat, 23 Apr 2022 09:40:00 +0900

あと数ヶ月で初めての子どもが生まれる予定だ。自分の過去を振り返ると奇跡に近いことだなぁと思う。ここまで繋いでくれた色んな人に感謝。

さて、そうなると使える時間がかなり変わってくるだろうから、それに備えてルーチンを見直した。

まず、体力と精神面での健康が大事になってくるだろうから、運動をしっかりやっていく。
朝の出勤前の30分程度の散歩は継続できているので、あとはそれにプラスしてSwitchでのエクササイズをやる。
リングフィットアドベンチャーとFit Boxing 2の両方をやってみたけど、短時間で済むし、クリアという目標があるリングフィットアドベンチャーを中心にひとまずやっていこうと思う。

夜に風呂をわかすタイミングをキューにしてやろうとしていたのだけど、夕食を食べた後は1日の疲れでどうしてもダラダラしてしまい、気力がわかず習慣化できなかったので、朝やることにする。
ただ、朝は出勤前の勉強時間に充てているのでどうしようかと考えていたところ、妻に日ごとに勉強と運動を交互にすればいいんじゃないとアドバイスをいただけた。

というわけで、朝のルーチンとして、月・水・金は勉強、火・木は運動って感じにしようと思う。土日は朝たっぷり時間があるので、両方やる感じ。

勉強の内訳としては、平日は数学、土日は技術という感じ。数学は1年ぐらいで高校3年の範囲を終わらせようかとも思っていたけど、焦らずのんびりやっていこうと思う。

こんな感じで設定してみたが、思った通りにいかないことが多くなるとは思う。
そんな時でも、1度きりの生活をどうせなら楽しんで過ごしていきたい。

『Clean Coder』を読んだ ― ボブおじさんに学ぶプロの職業倫理

Sun, 03 Apr 2022 11:03:00 +0900

ソフトウェア・エキスパートであるRobert C. Martinことボブおじさんによる『Clean Coder』を読みました。

「Clean Coder プロフェッショナルプログラマへの道」

この本の原著がリリースされたのは2011年と結構前なのですが、具体的なプログラミング手法などではなく、プログラマーの働き方について書かれた本なので、今でも十分に読む価値はあると思いました。

序章で以下のように書いてある通り、本書は各章でボブおじさんの失敗談が書かれたあと、それを受けてプロはどうあるべきかが書かれているという構成をとっています。

本書は、私の間違いの一覧であり、これまでの悪事の記録であり、私と同じ道を歩まないための指針であると考えていただきたい

プロ意識とは自分で責任を取ることに他ならず、コミットメントを安易にしないことや、言う必要がある場面ではノーと言うことなどの重要性が説かれています。

特に印象的だったのがプロの労働倫理として、雇用主のために働く週40時間とは別に、自分のキャリアを強化する週20時間を作ろうと書いてあることです。会社で働く時間とは別に学習する時間をそれだけ用意するということです。
これは賛否両論ある意見だと思いますが、本当のプロになるにはそれだけの覚悟が必要なのだということなのだと思います。
ここのところ向上心がそれほど持てず、ぬるま湯に浸かりつつあった自分にはハッとさせられる考え方でした。

他にも目次にある通り、コーディング、テスト駆動開発、練習といったコーディングについての話や、受け入れテスト、テスト戦略といったテストについての話、時間管理、見積もり、プレッシャー、協力、指導・徒弟制度・職人気質といった仕事全般の話について広範囲に書かれています。特にPERTといった見積もりについての話は失敗しがちなので参考になりました。

ボブおじさんの半世紀近い経験を元にしたプログラマーとして働くことのエッセンスが込められた本でした。
僕も一人のプロであるということを忘れず、日々の行動を見直していこうと思いました。

2022-02 振り返り

Sun, 06 Mar 2022 13:39:00 +0900

2022年2月の振り返り。まだフォーマットが定まってないので適当に。

技術

Go 周り

Effective Go
Go Code Review Comments
Go Test Comments
Practical Go: Real world advice for writing maintainable Go programs
エキスパートたちのGo言語

この辺りを読んだ。

Go はシンプルな言語とはいえ、やはり良いコードを書くには色々と覚えることがあるなと思った。
Effective Go みたいに公式のプラクティス集がまとまっているのは有難い。

機械学習

Kaggle Learn - Intro to Machine Learning
Kaggle Learn - Intermediate Machine Learning
Coursera - Machine Learning

Kaggle の 30 Days of ML というチュートリアル集をやって、Coursera の Andrew Ng 先生の Machine Learning を少し進めたが、機械学習に行くまでに最低限の数学をちゃんとやっておきたいなとなってストップした。

しばらくは機械学習には触れずに数学をやっていこうと思う。

数学

長岡先生の授業が聞ける高校数学の教科書
Khan Academy

高校数学レベルの数学を学ぶにはどれが良いのかなぁと色々探った結果 Khan Academy をやっていたのだけど、同じことを違う動画で何度も説明したり、途中の計算が丁寧すぎたりとちょっと退屈だったので、 reddit などで評判の良かった Serge Lang の Basic Mathematics という本で学んでいくことにした。

2022-01 振り返り

Sat, 05 Feb 2022 13:38:00 +0900

振り返りは大切ということで、今月から月単位での振り返りをやってみる。日記を書くのは続けるのが難しそうだが、月ペースなら楽そうってのがある。
学生時代はブログで勉強の振り返りをやっていたのだが、これからは勉強以外も含めた総合的な振り返りをやっていこうと思う。

というわけで振り返る。

読んだ本

The Go Programming Language

去年6月に読み始めて、“8. Goroutines and Channels” まで読んでいたのだが、長いこと積まれていて気持ち悪かったので、エイヤとそこから最後まで読み通した。

この本はCSチックで骨太な本で、全部理解しようとするとかなり腰を据えて取り組む必要があるので、8章からは、後で「あそこに書いてあったな」ぐらいのインデックスを貼る意味でほとんど見出しだけ追うみたいな読み方をした。こういう読み方はあまりしてこなかったのだが、じっくり読んでも結局内容を忘れることが多いので、このような必要ドリブンな読み方もしていきたいと思う。

インターフェイスについての詳細など、Goを真に理解する上で大事なことが書かれている本ではありそうなので、腕を上げた後でまた読み返したいと思う。

長岡先生の授業が聞ける高校数学の教科書

今年は数学をやっていくぞということで開始。数学1 第1章数と式を終えたところまで40ページ進めた。

このペースだと数学Cまで全て終えるまでに2年ぐらいかかってしまうので、もっとペースを上げていこうと思う。
この教材は音声講義が入っている本で、とても興味深い話が聞けるのだが、全部聴いていると時間がかかるし、既に一度4年ほど前に数Cの途中まで進めてはいるので、音声講義は本を読んだだけで理解できなかったところだけ聴くようにする。

早く高校数学を終わらせて最終目標の機械学習に進みたいと思っている。が、積み上げる学問なので、慌てずじっくり理解していく。

趣味・娯楽

映画

『レディ・バード』、『サイダーのように言葉が湧き上がる』、『浅草キッド』、『朝が来る』を観た。

『レディ・バード』は難しい時期の女子高生の成長物語。前々から観たかったのだけど、母との絆などとても良かった。女性視点だとまた違って見えるのだろうなぁ。

『浅草キッド』も人情溢れる良い映画だった。あまり昔は良かったというのは好きではないのだけど、その時代を一生懸命に生きた人たちがいたのだなぁと心揺さぶられた。

ベース

楽器をやるとなったら毎日練習したりしていたのだが、色々やることがある中でなかなか厳しいので、楽器は緩く週末だけやる感じにすることにした。

BassBuzzというサイトのBeginner to Badassを進めている。
これも1回途中まで進めていて、以前はModule 10まで終えていたので、ざっと復習をしていてModule 07まで終えたところ。
まずはこのコースをしっかり終えて、色々曲を覚えていきたい。

ゲーム

Oculus Quest 2でHalf-Life: Alyxを遊んでいる。弾が少ないゲームで操作も慣れないのでなかなか難しい。これを遊ぶと他のVRゲームが遊べなくなるとさえ言われるゲームなので、じっくり楽しんでクリアしたい。

まとめと今後

結婚したり、年初だったりと、気づいたら終わっていたという感じの月だった。

2月はもっと落ち着くと思うので、数学にどっぷり取り組んでいきたい。
引き続きGoのスキルも上げたいので『Effective Go』、『Go Code Review Comments』、『エキスパートたちのGo言語』、『Go言語による並行処理』と読んでいく。
同僚に刺激を受けてKaggleを始めたのでそちらも進めていく。

やってくぞー。

結婚しました

Tue, 11 Jan 2022 08:40:00 +0900

このたび、2022年1月11日に福岡市中央区役所に婚姻届を提出し、結婚しました。

コロナの状況下で出会い、お付き合いしてきて、制限もある中、工夫して2人で楽しい時間を過ごしてきました。
お互い波長が合い、何でも楽しめるタイプで、うまい具合に特徴を補いあえており、恋人でありながら深い親友でもあるような関係を築けてきました。良く2人で言うのが、出会うずっと前から知り合っていたような気がするよね、ということです。

プロポーズは糸島市の2人の思い出のレストランで食事したあと、桜井二見ヶ浦の夫婦岩の駐車場の車中で、福山雅治の『家族になろうよ』をかけながら行いました。

長期の引きこもりという暗黒時代を過ごした自分が、こうやって人生を共にする相手を得られたのは、支えてくれた家族や、行くところ行くところで世話をしてくださる方々に恵まれたおかげです。
これがスタートではありますが、まずは関わってくださった全ての方々に深く感謝を申し上げます。

いや〜自分が結婚なんて、不思議なものですね。

例のアレ、置いておくので宜しければお願いします。
https://www.amazon.jp/hz/wishlist/ls/25ZQGW68CX9DF

2022年抱負 - 数学と機械学習、楽器をやっていく

Sat, 01 Jan 2022 11:40:00 +0900

紅白の藤井風さん、とても良かったなーと思いつつ、恒例の年初抱負を書いてみる。

技術

今年は私生活が忙しくなりそうなので、プライベートの時間でやる技術は思い切って絞ってみる。

新規にやること

数学

プログラマーとして社会人になったけど高校数学を1から独学しているを書いた時に勉強して以来、約4年半ぶりのチャレンジ。前回は長岡の教科書2+Bを終えたところで止まってしまったので、最低限高校数学までは履修したい。海外の教材も選択肢に入れて勉強していきたい。

機械学習

何のために数学を学ぶかというとこれ。
仕事を通じてある程度Webアプリケーション周辺のプログラミングは慣れてきた感があって（もちろんまだまだな部分がとても多いのだけど）、何か新しいことにチャレンジしてみたいと思ったというのが動機。
その時に思いついた技術として、ブロックチェーン、XR、機械学習があった。
ブロックチェーンはまだ自分の頭では本当に実用的なのか判断が難しく様子を見たいと思い、XRはまずコンシューマーとして遊んでみたいと思った。
最後に残った機械学習は既に十分に実用されていて、これからも必要になる技術だろうと見たのでやってみることにした。 Kaggleみたいなコンテストがあり、ゲーム的に学ぶこともできそうと思ったのも理由。極めるのが難しそうなのも難しい物好きな自分には合っていそう。
これをどう仕事に活かすかとかは考えてないが、知的好奇心頼りに進めていくつもりだ。

引き続き

Go

去年は自分の中でGoの年と言って良かったと思う。引き続き業界全体としても、自分の周りでも、主要な言語として使われていくであろうから、1.18のキャッチアップや並行処理の勉強などやっていこうと思う。

その他

あとは業務効率化をミッションの1つにしているチームに所属していることもあり、Slackの新機能がかなり気になっているため、そこに使用される技術であるTypeScriptとDenoも追っていきたいと思っている。

趣味

楽器

楽器をやっていきたい。紅白の藤井風さんを観て改めて思った。
色々やっていきたいが、昨年末のサカナクションのライブで間近に見た草刈愛美さんがかっこよかったので、まずはベースにしようと思っている。
去年ストラトを思い切って買ったが眠らせてしまっているので、ギターもやっていきたいところ。ギター1本で人前で披露できるのはとても良いので、弾き語りできるようにもなりたい。となると高い声が苦手なのでボイトレも必要そう。
コロナの状況しだいで教室にも通ってみたいと思っている。何かの教室に通うという体験はしばらくやってないので良いのではという期待から。島村楽器だと年1でホールでの発表の機会があるとのことなので気になっている。

XR

技術のところでも触れたが、XRの可能性を探ってくために色々触れてみたい。Quest 2は昨年末に買った。まずはValve Indexを買ったのにすぐ売っ払って未クリアのHalf-Life: Alyxをクリアしたい。

まとめ

こんな感じだろうか。
やることは最小限に、あまり根を詰めずに余裕のある豊かな日々を送れたらと思っている。

いい年にしていくぞ。

2021年振り返り

Fri, 31 Dec 2021 16:41:00 +0900

恒例の年の振り返りをする。なお2016年から続けているようだ。けっこう続いている。

抱負の振り返りから。
2021年抱負に書いたことを振り返っていく。

技術

TypeScript
React
Next.js
Docker / Kubernetes
Go (余裕あったら)

結果的には余裕あったらとしていたGoを一番書いた年だった。業務で主に書いた言語だったし、個人的にも初めて自身のOSSプロダクトをリリースしたりした。
DockerとKubernetesについては同僚のakht氏とちょろっとやったが中途半端に終わった。
TypeScriptはほとんど触らなかった。ReactやNext.jsといったフロントエンド技術にも触れることはほとんどなかった。

仕事

等級上げる

半期ごとの評価なのだけど、上半期に上げることは叶わず、現在下半期の評価待ちとなっている。

色々

毎月1記事のペースでブログを書く

数えたらこの記事を含めずに丁度12記事書いていた。ということで達成。

お気に入りのキーボードを見つける

REALFORCEなど試したものの、家の机のスペースの関係などでMacBookの内蔵キーボードに戻ってしまった。M1になってからはバタフライではなくなったことで余計に気にならなくなった。
ただ分離キーボードの方が肩に良いということを聞くので、まだ探すのを止めたわけではない。けど沼っぽくて足を踏み入れないでおこうという気持ちが強い。

ギターで弾ける曲を5曲増やす

他にもやることがたくさんある中、中途半端にできない性格のせいで楽器は全くやらないと決めてしまった。ただ音楽ってそういうものじゃ無い気もするので、気が向いた時にジャガジャガやるのもありかと思ったりして、来年は再開しようと思っている。

お金周りの勉強（貯金以外の資産運用の手段を増やす）

これはちょこちょこ始めている。手始めにふるさと納税はやった。忙しくて手を出せなかったけど、来年はつみたてNISAを始めてみようかと思っているところ。

体重を理想体重まで減らす

4月ごろまで順調に減っていたのだが、5月ごろから順調に増えてプラマイゼロになってしまった。来年はちゃんと運動して痩せたい。

健康に気をつける

人生で初めて受けた人間ドックの結果はあまり良くなかった。ここも来年はもう少し頑張る。

周りの人を大事にする

これは仕事、私生活含めてけっこうできたのではと思っている。そもそも交友関係の少ない方だし、少ない人を深く大事にする方が自分には合っているようだ。

まとめとして、

前年はインプットの年にしたので今年はアウトプットやっていく。

と書いていたのだが、Fukuoka.goでは登壇できたし、OSSプロダクトを出したりして、十分アウトプットをやっていけたのではと思っている。

あとは個人ブログに移行したりISUCONに出たりが大きなイベントだったように思う。

ここでは詳しく書けないが、業務と私生活の両方とも精一杯やって、個人的には人生で一番頑張ったし、一番充実していた1年だったように思う。大変なご時世ではあるものの、その中で工夫して楽しく過ごすことができた。丑年36歳、年男Man of the yearとして十分な1年を送ることができた。

こうやって充実した日々を過ごせたのも関わってくださった周りの方々のおかげである。
いつもありがとうございます。今年もお世話になりました。良いお年を。

初めてのGo製CLIツール作成、初めてのOSS公開に込められた物語

Wed, 15 Dec 2021 08:00:00 +0900

この記事はGMOペパボエンジニア Advent Calendar 2021の15日目の記事です。

昨日はToshifumi Tsutsumiさんの入社から一年、ペパボはどうですか？に答えるでした。
ペパボにいるとインプット、アウトプットが出来てる方々の集まりで本当に刺激的ですよね。…そして、評価資料がんばりましょう。

さて、今回、記事にするのは掲題の2つの「初めて」についてと、作成したGo製CLIツールの紹介です。
2つの「初めて」とは、1つ目はGo製CLIツールを自分で作成したこと、2つ目はそれをOSSとして公開したことです。

What is takolabel

まず、そのGo製CLIツールについて紹介します。

tommy6073/takolabel
https://github.com/tommy6073/takolabel

名前はtakolabelと言って、GitHubのマスコットであるOctocatがタコとネコの合体であることから（割と安易に）takoを、ラベルを操作するツールなのでlabelを取って、takolabelと名付けました。
後になって英語圏の人に伝わりにくいかもと少し後悔していたりもしますが、Kubernetesなんて名前のソフトウェアがあるぐらいなので良いかなと思ったりしています。

このツールが何をやってくれるか短く言うと、「複数のGitHubリポジトリに渡ってのラベル操作」です。
例えば、A、B、Cというリポジトリがあって、X、Y、Zというラベルをそれぞれのリポジトリに一括で作成したい、といった時にそれを実現してくれるというものです。YAMLにリポジトリとラベルを指定して操作します。GitHub Enterprise Serverにも対応しています。

ここでは、なぜそのようなツールが必要になったかについて説明します。

ツールが生まれたきっかけ

このツールが生まれたきっかけとしては、私が所属しているGMOペパボホスティング事業部 ISR (Internal System Reliability) チームにて、運用業務のコスト可視化というタスクがありました。
前提として、GMOペパボホスティング事業部では全パートナーが割り当てたタスクをGitHub Issues上で議論や過程を記録しながら進行させるのが基本になっています。そういうことから、コストを可視化するためにはIssue上で分類や消費時間を記録すれば計測できるのではないかとチームで話し合われました。
その結果、サービスや用途ごとに異なる複数のリポジトリにGitHub Issuesに計測用の分類、消費時間を表すラベルを貼った上で、Google Sheetsにエクスポート、それをさらにGoogle Data Studioに取り込みレポートを作成するという仕組みを実現しました（こちらについては別に改めて紹介できたらなと思っています）。
その過程の、GitHub Issuesにラベルを貼るという作業を手動で行うのは大変なので、それを自動化するために生まれたものです。
最終的には、思った通りにラベルを複数のリポジトリに一括で作成することができ、ツールとしての役目を無事果たすことができました。

Goについて

なぜこのツールにGoを選んだかということについては色々とありますが、ホスティング事業部として今後バックエンドを中心に採用していく言語であること、実行ファイルがシングルバイナリであることからCLIツールとして適していること、個人的に学んでみたい言語のリストに入っていたこと、が挙げられます。

結果として、ツールの作成を通じてDXとして非常に満足のいくものがありました。
まずは言語の売りである簡潔性がとにかく素晴らしいです。学習にかかる時間がかなり少なかったですし、覚えることが少ない分、コードも読みやすく仕上げることができます。
良く言及されるエラーハンドリングも個人的には何も苦ではない感じです。
IDEとの親和性も高く、ツールチェインについてもシンプルで、言語としての完成度の高さを嫌というほど実感しています。

そういうわけで、これから自分で書いていくプログラムで採用していくことも増えていくだろうなと思っています。CLIツール以外でも使ってみたいですね。
色んな言語を使ったり学んできて、使う言語にこだわりのない方なのですが、この言語については惚れてしまいました。

あとはGoルーチンを使った並行処理の強みについてはまだ活かせていないので、その辺りも勉強していきたいと思っています。

OSSとして

2つ目の初であるOSSとしてですが、こちらは主に2人の会社の先輩に助力をいただきました。

まずは、Fukuoka.go#17での発表でも触れましたが、CIフレンドリーなDBドキュメントツールであるtblsを代表プロダクトに持つk1lowに、環境変数の命名や設定ファイルの書き方といった点を中心に、様々なアドバイスをいただけました。このプロダクトを社内Slackで公開した時に、「え、めちゃいい！」と言っていただけたこと、非常に嬉しかったです。

次に、チームの先輩である、お手軽にTLS証明書の情報を引けるcertを作ったgenkiroidには設計のアドバイスをいただきました。現在のコードの状態を見て、自分ならこうするという例を提示していただき、責務の分離や構造体の定義、関数とメソッドの使い分けといったことを教えていただきました。仕事上でもいつも的確な意見をいただけていて、私の中でロールモデルな存在です。

お2人とも貴重なプライベートの時間を使ってプロダクトを見ていただいた上で助言をいただけて、最高の福利厚生だなと思っています。いや〜ほんとありがたいです。この場を借りてお礼させていただきます。

takolabelのこれから

そんなtakolabelですが、現在のところ必要ドリブンで、ラベルの作成、削除、空にする、という3つの操作ができるにとどまっています。これからも操作を拡張したり、使いやすくしたり、リファクタリングしていけたらと思っています。

もちろんPull Requestsもお待ちしております！

まとめ

この記事を通じて、1つの小さなプロダクトにも、物語があるのだということを感じ取っていただけたらなと思います。
そして、Goで書くことも、自身のOSSを持つことも、自分次第でなんとでもなることだと分かり、挑戦して良かったなと思っています。こうしてAdvent Calendarのネタにもなっていることですしね。

Who’s next?

さて、明日のGMOペパボエンジニア Advent Calendar 2021の16日目の担当はAkihito Ikedaです。
彼はISUCON11でISUCONに初参加した時の盟友です。何を書いてくれるんでしょうね。楽しみです。

2021年冬季休暇にやりたいこととか近況とか

Wed, 17 Nov 2021 07:42:00 +0900

ここのところ仕事もプライベートも忙しくてなかなかプライベートな時間でスキルアップをできていない。ただ1年中突っ走る生活もしたくないので、プライベートなスキルアップは余裕のある時でいいかなと思っている。仕事を通じて十分スキルアップさせてもらっているということもあり。
人生で何を大事にするかなんて問いも浮かんだりしている。その辺については前にも少し書いた。

それはさておき、少し気が早いが冬季休暇にやりたいことをNotionページに書き出していっている。
まずやりたいこととしてはGatsby Starter Blogほぼデフォルトのこのブログをもっと充実させたいのが一つ。そして、開発しているGo製OSS takolabelを改善すること。あとは密かに狙っているghへのコントリビュート。そして遊びでは今のMicrosoftが出してRTS界の重鎮Relicが開発したということで興味を持って購入したAge of Empires IVをプレイすること。
休みって毎回あっという間に終わってやりたいことの20%もできずに終わるのだけど、無為に過ごすよりはある程度目標を立てておいた方が有意義に過ごせるだろうなと。

2021年もカウントダウンが始まってきた。このままいい年にしたいものである。

Vimを始めとして環境を見直してみた

Sat, 18 Sep 2021 16:01:00 +0900

僕は開発環境にはJetBrains IDEsを使って、その他のテキスト編集にはVimを使ったりVisual Studio Codeを使ったりといったことをやっているのだけど、ふと使う道具を少なくしようとVisual Studio Codeは使わずに、がっつりした開発以外のテキスト編集やスクリプト作成などにはVimを使おうと思い立った。高機能なVisual Studio Codeを単なるテキストエディターとしか使えておらず、Vimはカスタマイズや操作を組み立てるのが楽しかったり、ターミナルから抜け出さなくて良いというのが理由。

それでまずは6年前に読んだ実践Vim（の英語改訂版）を読み返した。プラグインの機能はほとんど使用せずに様々な操作が可能なことを教えてくれるこの本はVim wayを知る上で本当にいい本だと思う。新たな学びもあったけど、ふとした時に出てくる自信のない操作も多い（マクロとか）。

あとはVimを使った開発の動画を観たりした。良かったのはこの2本: tmuxとvimによる開発作業フロー (動画) | 週休７日で働きたい、【解説】開発ライブ実況 #1 (Vim / Go) 編 by メルペイ Architect チーム Backend エンジニア #mercari_codecast | メルカリエンジニアリング。特にメルカリの方のやつは作業が速すぎてRTSのプロゲーマーを観ているようだった。

んでそのままの勢いに実践Vimと同じ著者が書いたVim 8とNeovimについてのModern Vimを買って読んだ。といっても “Craft Your Development Environment” と副題がついているように、開発環境向けの機能やプラグインの紹介が多く、僕の利用目的とは合わない感じだったのでそういうプラグインもあるんだな、Neovimにはそういう機能があるのねー、程度にざっと読んだ。

動画を観た影響もあり、Vimで開発もやってしまったらかっこいいなーと思いつつ、カスタマイズや操作の修練も行き過ぎるとけっこうダルいなと思ってしまったし、JetBrainsのAll Products Packにお金を納めたばかりだったので一本化はやめることにした。

そして出来上がったVimの環境なのだけど、とりあえずNeovimにcoc.nvimを入れてLSPによる恩恵に預かることにはしたのだけど、コンフィグやプラグインはかなりミニマルな構成にした。昔入れたプラグインやキーバインドも使ってないものはごっそり捨てた（dotfilesはこちら）。

あとはtmuxについてtmux 2を読み返したけどそんなに発見が無くて十分使いこなせてる感を感じたあと、Tao of tmuxをざっと読んだり、fzfを使った便利なコマンド無いかなーと探したり（結局使いたいと思うものは増えなかった）といったことをやっていた。

とりあえずVimの環境はスタートラインに立てたので、あとは必要に応じてカスタマイズしたり習熟していきたいと思う。というこの記事をNeovimで書いたのであった。

ISUCON11でISUCONに初参加した

Mon, 23 Aug 2021 08:54:00 +0900

ISUCON11に同僚の @akht_ikd と2人チーム「team”渇き”」として出場した。
結果としては58450点の58位で予選落ちだった。

詳細なレポートは @akht_ikd がブログに書いてくれたので個人としての感想などを。

まず、過去問などをやったり他の人がやったことを調べるにつれて、自分の思っていた以上に幅広く深い知識が要求されるコンテストだということが明らかになっていき、まだまだ知ることが無数にあるのだなということを痛感した。
また、近年は学生で上位に入る方々も多く、世の中には本当に優秀な人々がいるのだなぁということも知れた。

チームの面でいうと、ISUCONに出てみないかと声をかけたところ、即座にのってくれた @akht_ikd には本当に感謝している。
スクリプトを作ってくれたり、やることリストをまとめてくれたり、競技中の改善にしろ、かなり頼りっきりだった。今回楽しめるレベルで参加できたのは彼によるところが非常に大きい。本当にありがとうございます。

大会前は過去問をビデオ通話を繋ぎながら一日かけて一緒に解いたりして、部活みたいな面白さがあって良かった。
まだまだ自分自身のスキルは足りないが、こうやって一緒に行動を共にできる仲間がいることに感謝。

大会が終わった後の大会公式Discordでの感想戦の話なども分からないことが多かった。個人としては自分の足りなさをさらに実感する初参加となった。チームメイトに頼りっきりになってしまったことも反省している。
分からないことがドサッと来ると頭や手が動かなくなる癖があるので、物事を分解して各個撃破できるスキルをもっと身につけなければと思う。

渇きが増した大会だった。実力を今よりもっとつけて、来年もまた参加したい。

将来の生活の質より毎日の生活の質

Wed, 05 May 2021 19:26:00 +0900

この連休中、ずっと料理との付き合い方に向き合っていた。

去年の10月に初めての一人暮らしを始めて、最初の頃は楽しかった料理も、だんだんと面倒なものに思えてきて、特に夜の料理は仕事終わりで疲れている中、コードを書いたり勉強したりする気力や時間を奪う邪魔者になってしまっていた。
ついには料理を放棄して、朝シリアル、昼レトルト丼、夜冷凍弁当という全く料理をしない生活を数週間ほど続けていた。結果的に、因果関係は定かではないが、調子があまり良くない状態になっていた。

このままではまずいと思い、夜に料理をせずに栄養があって美味しいものを食べるということをテーマに、ホットクックをレンタルしてみたりと色々と策を練った。週末に副菜を作り置きして、朝にホットクックで夜に出来上がる予約調理をするという方法を考えたが、大量の作り置きがかえって負担となりあまり良いとは思えず、これといった解は出せずに時間だけが過ぎていった。

そんな時ふと、夜は勉強せずに料理をして、くつろぐだけの時間にしたらどうだろうか、という案が思い浮かんだ。それならば料理は邪魔者ではなく、むしろ楽しむものとして付き合うことができる。

そう考えるとなんだか途端に気が楽になった。更にそこから派生して、毎日の生活の質を落としてまでスキルアップに勤しんだ結果、将来にそれだけの価値のある生活が待っていると言えるのだろうか、と思えてきた。

僕はふと思い立って極端なことをやりがちな癖がある。自分を追い込めば何者かになれるのではないかと、他は捨て去って一本に集中してしまいたいと発作的に思うことがあるのだ。しかし結局それは持続可能なものでなく、調子をくずしたりして頓挫して続かないことが多い。以前に一流エンジニアなんて目指さなくていいのかもなんて記事を書いたことがあるが、その時も疲弊してしまったあとに書いたものだ。

将来の生活の質なんて約束されていないのだから、毎日の生活を思う存分楽しんで、毎日の生活の質を高めたほうがいいのではないか。そんな気持ちになってきた。

だからといって全くスキルアップの時間を無くすのではない。朝をスキルアップの時間にするのだ。毎晩早く寝て毎朝早く起きて、ベースの練習をして、運動して、無理のない範囲でスキルアップをやっていく。なんだかこれを書いているだけで、明日からが楽しみになってきた。

さて、連休が終わる。今夜は早速豚キムチを作って食べた。なかなか美味しかった。
明日からは同僚氏と朝活をやっていく予定だ。早起きしていいスタートを切っていきたい。毎日の生活の質を高めていくのだ。

個人Webアプリ作成という荒野に立った

Tue, 13 Apr 2021 23:14:00 +0900

const writeWebAppWithStrongWill = true; で宣言したとおり、Webアプリ作りに着手している。

技術スタックは所属するペパボホスティング事業部でこれから使っていくものに沿っていく方針。ひとまずTypeScriptとNext.jsを使うことは確定している。

アプリの肝となるノードを描画するUIが必要なので色々と検討した結果、https://github.com/wbkd/react-flow を使うことに決めた。この辺のライブラリー、ドキュメントがあまり充実していないので使いながら覚えていくしかなさそう。

ノードUIライブラリも決まったので、ひとまず npx create-next-app したあと、ESLintとPrettierを導入したところまで進めた。ルール多すぎてどう設定したらいいか分からん状態だったけど、そのことをTwitterでつぶやいたらアドバイスいただけて、ESLintとPrettierの共存方法が分かり、ESLintはrecommendedを使ってルールはあとから追加していく形で良さそうと分かった。

次はMaterial-UIを導入しようとしているのだけど、Next.jsのCustom AppやらCustom Documentが分からん、むしろNext.js何も分からん状態になっている。 ReactとNext.jsは半年ほど前に1回チュートリアルをやったのだけど、完全に忘れてしまっているのでもう1周しようと思い、ひとまずReactのチュートリアルを終えた。
モダンなReactの書き方を教えてくれるヘルシンキ大学の Full stack open もまた1周するか迷っているところ。

学習しながら作るの、体系的に学ぶ癖のある僕にはさじ加減が難しいのだけど、最初から全部を把握することは諦めたほうがいいだろうし、あまりチュートリアル煉獄には陥りたくないので、つまみ食いしながらアプリを作っていきたいと思う。

やってくぞー。

const writeWebAppWithStrongWill = true;

Tue, 06 Apr 2021 21:55:00 +0900

同僚たちと毎週夜にCode Completeの読書会をやっているのだけど、本編自体は早めに終わったあと、僕の「雑談いいですか？」という一言から、仕事とプライベートでやっていることについて色んな話をした。

その中で、GoやらTypeScriptやらLinuxやらサーバー運用やら、やりたいことがありすぎて何をやっていくべきか見失っているみたいな話をした時に、ずっと温めていたあるWebアプリの話をしたら、「それいいじゃないですか」と言ってもらえた。

自分でもなかなかのアイデアだとは思っていたけど、客観的にアイデアの段階で評価してもらえたので、これはやっていくしかないという気持ちになった。

作るとすればTypeScript + Next.jsで作ろうと思っているのだけど、業務の中でもTypeScriptはこれからやっていく必要がありそうだし、まずはこのWebアプリ作りにフォーカスして、必要ドリブンで学習しながら作っていこうと思う。

常時リモートワークの中で人と話す機会が少なくなっている中、人と話す中で自分の中に眠っているものを発見できたりと、やはり人と話すというのはいいものだなと思った。

毎日時間を作ってこの温めてきたWebアプリを作り上げていこうと思う。やり遂げるのだ。

Gatsbyをv3にアップグレードしてgatsby-blog-starterもアップグレードした

Thu, 11 Mar 2021 17:30:00 +0900

表題のとおりです。

https://okweird.net はGatsbyとgatsby-blog-starterをベースに構築しており、基本的にはGatsby公式移行ガイドに書かれていることをやっていけばGatsby v2からv3へのアップグレードができるのですが、それ以外の作業も必要だったのでログを残しておこうと思います。

作業ログ

$ npm install gatsby@latest

まずはメインであるGatsbyのアップグレードを行います。僕の場合、2.31.1 から 3.0.4 まで上がりました。

$ npm outdated

古い依存をリストします。僕の場合、結果はこのような感じでした。

Package Current Wanted Latest Location
gatsby-image 2.5.0 2.11.0 3.0.0 gatsby-starter-blog
gatsby-plugin-feed 2.7.0 2.13.1 3.0.0 gatsby-starter-blog
gatsby-plugin-google-gtag 2.6.0 2.8.0 3.0.0 gatsby-starter-blog
gatsby-plugin-manifest 2.6.1 2.12.1 3.0.0 gatsby-starter-blog
gatsby-plugin-offline 3.4.0 3.10.2 4.0.0 gatsby-starter-blog
gatsby-plugin-react-helmet 3.4.0 3.10.0 4.0.0 gatsby-starter-blog
gatsby-plugin-sharp 2.8.0 2.14.3 3.0.1 gatsby-starter-blog
gatsby-remark-copy-linked-files 2.4.0 2.10.0 3.0.0 gatsby-starter-blog
gatsby-remark-images 3.5.1 3.11.1 4.0.0 gatsby-starter-blog
gatsby-remark-prismjs 3.7.0 3.13.0 4.0.0 gatsby-starter-blog
gatsby-remark-responsive-iframe 2.5.0 2.11.0 3.0.0 gatsby-starter-blog
gatsby-remark-smartypants 2.4.0 2.10.0 3.0.0 gatsby-starter-blog
gatsby-source-filesystem 2.5.0 2.11.1 3.0.0 gatsby-starter-blog
gatsby-transformer-remark 2.10.0 2.16.1 3.0.0 gatsby-starter-blog
gatsby-transformer-sharp 2.6.0 2.12.1 3.0.0 gatsby-starter-blog
prismjs 1.22.0 1.23.0 1.23.0 gatsby-starter-blog
react 16.13.1 16.14.0 17.0.1 gatsby-starter-blog
react-dom 16.13.1 16.14.0 17.0.1 gatsby-starter-blog
react-helmet 5.2.1 5.2.1 6.1.0 gatsby-starter-blog
typeface-merriweather 0.0.72 0.0.72 1.1.13 gatsby-starter-blog
typeface-montserrat 0.0.75 0.0.75 1.1.13 gatsby-starter-blog

公式ガイドでは1つ1つ npm install {package}@latest するように書かれていますが、大変なので依存を最新にしてくれる npm-check-updates を使います。

僕が参加しているオンライン勉強グループ「きまべん」の近況とメンバー募集のお知らせ

Sat, 20 Feb 2021 16:15:00 +0900

僕が参加しているScrapboxを利用したオンライン勉強グループ「きまべん」の近況についてお知らせしておこうと思います。

これまで

以前僕のブログできまべんについて紹介したものとしては以下の記事があります:

そもそものきまべんが何かであるというのは1つ目の記事を見ていただくと分かりやすいかと思います。最近はSlackでのやりとりも活発になってきました。
また、2つ目の記事にあるように、日々の勉強とは別に、時折イベントを開催し、オンラインもくもく会をしたりといったことをやってきました。

それに加え、最近はReal World HTTP 第2版輪読会を1年弱に渡って行い、Real World HTTP 第2版を無事読了することができました。

これから

きまべん発足当時は、朝6:00〜9:00、夜20:00〜23:00という「決まった時間に勉強」が略の、ジャンルレスな勉強グループとして発足しましたが、最近定義が更新され、ソフトウェアエンジニアのための「きまぐれに勉強」するグループとなりました。
これは参加メンバーがほぼソフトウェアエンジニアのみであることと、勉強時間は各自自由に取っているという実体に即するための変更となります。

2021/02/23(火)からは第2回輪読会をエンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリングをテーマに行っていきます。
キックオフにて色々な候補が上がりましたが、一般的な知識が得られてチームに実際に適用できそうとのことからこの本に決定しました。

メンバー募集しています！

そんなきまべんですが、いつでもメンバーを募集しています。第2回輪読会に興味がある方や、勉強仲間が欲しいというソフトウェアエンジニアの方がいたら是非 @tommy6073 までお声がけください。その際はきまべんのはじめにページを読んでいただけると幸いです。

あなたも一緒にきまぐれに勉強しませんか？

僕がリモートワークをする上で工夫していることと『リモートワークの達人』

Sun, 10 Jan 2021 18:00:00 +0900

去年は自分の中でリモートワーク元年でした。世の中の流れ的にそうだったという方も多いのではないかと思います。

僕の所属するGMOペパボは新型コロナウイルスの感染拡大に備え、GMOインターネットグループ全体で2020/01/27からいち早く在宅勤務体制へと移行しました。

GMOインターネットグループ、新型コロナウィルスの感染拡大に備え在宅勤務体制へ移行 | GMOインターネット株式会社

この記事では約1年のリモートワーク通して僕が思うところを書いていきます。

リモートワークするうえで工夫していること

家だとなかなか気分の切り替えが難しいため、朝のルーティンを工夫しています。家事とか食事とかを省くとこんな感じでやってます:

朝散歩: 日光を浴びて生活のリズムを整えながら運動します。僕は近所の大濠公園を1周 (2km) しています。朝散歩はかなり調子良くなるので本当にオススメです。
コーヒーを淹れる: 朝の楽しみです。いい香りで今日も朝が来たと実感します。
ラジオ体操: 元国立スポーツ科学センター医学研究部研究員の中村格子さんも推奨している運動です。体を柔らかくしつつ気分転換のスイッチとなります。
部屋のシーリングライトを暖色から白色に切り替える: これも気分転換のスイッチとなります。
Perfumeのエレクトロ・ワールドをかけながら仕事スタート: ルーティンとして仕事始まりのモードを高めます。かける曲はマンネリ化しないよう不定期に変えていきます。

半分儀式化して仕事モードに切り替えています。逆にこんだけしないと気分が切り替わらないんですから働くって大変ですね。

個人的に在宅勤務で何が大変かというと仕事を始める前と昼休み休憩後の復帰だと感じます。
そのためなるべく出勤時間を揃えるようにしています。GMOペパボのエンジニアはフレックス制であり、勿体ない感じがするかもしれませんが、僕には決まった時間からの出勤が合っているようです。

あとは外に出ても恥ずかしくない格好に着替えています。ビデオ会議に映らない下半身だけスウェットといったことがないようにしています。

最近引っ越したのですが、仕事部屋とくつろぐ部屋をしっかり分けてもいます。

『リモートワークの達人』

改めてリモートワークの先駆者の考えを知ろうと、DHHの所属する37signals（現Basecamp）の2人が書いた『リモートワークの達人』を読みました。原著は2013年発売と古い本ですがこのご時世でベストセラーとなっているようですね。今読んでも十分通用する（というか時代が追いついた？）本だと思いました。

リモートワークがいかに素晴らしいかということだけではなく、アンチパターンを数多く紹介しながら、ただ導入すればいいものではないと現実的に書かれているのが印象的でした。
また、人によっては合わない人もあるのでただ一律に導入すればいいという類のものではないとも書かれています。

リモートワークだとサボるのではないかと考えがちですが、働く人を信頼することが大事なのだということを繰り返し説いています。ちなみに出社していればサボらないかというとそうではなく、大手百貨店のJCペニーではトラフィックの約30%がYouTubeの視聴に使われていたという調査結果もあるようです。

個人的に印象に残ったのは、アメリカの政府系機関は当時でも特許商標庁職員の85%、NASA職員の57%、環境保護庁職員の67%がリモートで働いているということです。この辺り、どうしても日本の現状と比べざるを得ません。

人柄が大事、文章力が大事といったことも書かれていますが、ここはかなり実感しています。リモートだからこそ表現に気をつけ、感謝の意を気軽に伝えるようにしています。

あとは毎項最後に挿し込まれる挿絵がその項をよく表現していてとても面白かったです。

余談ですが今となっては独自メールを持っているBasecampがGmailの使い方を説明しているのも時代を感じさせました。

まとめ

以上、リモートワークについて思うところを書いてみました。

試行錯誤が続く中かと思いますが、皆さんもこんなTipsがあるよといったことがあったら是非教えて下さい。

2021年抱負

Sat, 09 Jan 2021 16:59:00 +0900

今年も前年に引き続き箇条書きで。

技術

TypeScript
React
Next.js
Docker / Kubernetes
Go (余裕あったら)

仕事

等級上げる

色々

毎月1記事のペースでブログを書く
お気に入りのキーボードを見つける
ギターで弾ける曲を5曲増やす
お金周りの勉強（貯金以外の資産運用の手段を増やす）
体重を理想体重まで減らす
健康に気をつける
周りの人を大事にする

前年はインプットの年にしたので今年はアウトプットやっていく。

会社でOKRをやるようになったからか目標設定の意識も変わってきたなという感想。
個人的な目標なのでストレッチはあまりかけずゆるりと。

やっていくぞい。

PHPカンファレンス福岡2019に実行委員として参加しました！

Wed, 03 Jul 2019 09:00:00 +0900

PHPカンファレンス福岡2019に実行委員として参加しました。

完全に運営視点の話になりますので、参加者目線のブログは公式サイトにこれから掲載されていくものをご覧いただければと思います。

きっかけと役割

去年のPHPカンファレンス福岡2018では人生初となるLT登壇をさせていただきましたが、今年は実行委員として参加したいと思っていました。そんな折、OSS Gate Fukuokaにサポーターとして参加した際、実行委員長の@tsubakimoto_sさんとご一緒する機会があったため、参加したい旨を伝えたところ快諾していただき、参加することとなりました。

初めての参加なので、当日スタッフぐらいで軽く関わるようなイメージでしたが、結果的にはグッズの発注、当日の司会（スポンサー読み上げ、HASIGOホール）まで任せていただき、かなり深く関わらせていただきました。何度かイベントの運営には関わらせていただきましたが、200人を超える規模の運営は初めてで、とても貴重な経験となりました。

ここがすごいよ、PHPカンファレンス福岡運営

実行委員として関わって、ここがすごいと思った点をいくつか書いていきます。

ボランティアベース

実行委員ですが、基本的に全てボランティアでの参加です。日々の業務もある中、この規模のイベントの運営を自分の時間を削って行っている皆さんの姿に、自分も頑張らなくてはと刺激を受けながら関わりました。

当日までのやりとりはほぼオンラインで

デザインや発注、決めごとなどのやりとりはBacklogの課題ベースで行いました。Facebookのグループもそれを補助するように利用しました。

顔合わせは最初のキックオフとセッション採択会議、最後の詰め、前日準備の4回程度で、当日が初顔合わせという方もいました。オンラインだけでのコミュニケーションってどうしても難しさがあるので、これはすごいことだと思います。

当日もチームワーク抜群

当日はもっとピリピリするものと思っていましたが、そんなことはなく、和やかな雰囲気の中、進行しました。途中予期せぬ出来事がいくつか起こった時も、当日用Slackで共有して迅速に対応していました。チームワークは抜群でした。

嬉しかったこと

個人的に嬉しかったことを書いていきます。

スポンサー読み上げ

間違えがあってはならないとかなり緊張して迎えたスポンサー読み上げですが、ご好評だったようで何よりでした。

終わったあとハッシュタグを眺めてにやにやしていました。

（なお、僕のしゃべりがゆっくりだったのも原因か、開会式のあとの午前のスケジュールが5分押してしまったのは内緒です。ご迷惑おかけしました。）

みんなで練り上げたものが評価されると嬉しい

議論を重ねた結果、こうした方がいいのではないかと決まったことが、参加者の方の生の声で評価されると実行委員としては本当に嬉しかったです。

僕が関わったものの一例としては、ネームカードを去年の表面だけからタイムテーブルなどを印刷した裏面も加えた、というのがあったのですが、ご好評だったようです。

みんなで練り上げた甲斐があったなぁと思いました。

大変だったこと

大変だったこととしては、普段デジタル製品ばかり扱っているせいで、グッズの発注作業はなかなか慣れないことで苦労しました。

デザイナーの@torchrightさんに仕上げてもらったデザインを元に発注したのですが、業務であまり関わらないaiファイルなどを扱う必要があり、割と大変でした。金額が大きなものもやらせてもらったので責任も大きかったです。

あとは、袋詰め作業をしている時に、「あれ、エコバッグ足りない？」という声が上がった時は発注を担当していたので心臓が縮み上がりました（結局足りてました笑）。届いてみないと分からないアナログ製品の難しさを感じました。

謝意

改めて、このイベントを成功に導いてくださった、スポンサーの皆様、登壇者の皆様、参加者の皆様、誠にありがとうございます。そして実行委員の皆様、半年間、本当にお疲れ様でした。

また、一人として欠けては成り立たなかったことですが、この場を借りて、以下の方々に特に感謝の意を表したいと思います。心よりありがとうございます。

初めての参加にも関わらず快く受け入れてタスクを任せてくださった実行委員長の @tsubakimoto_sさん
「ここまで目が届くか！」というところまで気配りしていただいた@akase244さん
HASIGOホールの司会で柔軟にサポートしてくださった@youukkariさん

青春謳歌

余談ですが、僕は高校中退して引きこもり生活が長かったこともあり、青春と言える時代を過ごさずに30過ぎまで生きてきました。今回このようなイベントに関わることができ、いくつになっても青春って送れるものだなぁと思いました。大きな文化祭をやってる感覚というか。

30歳を迎えたPerfumeの3人が2018年カウントダウンライブで肩を組み合って「青春謳歌！」と叫んだのが僕は大好きなんですが、まさに自分は青春謳歌できてると感じました。まだまだ青春謳歌していきます！

最後に

さて、最後に。

去年も言いましたが、今年も言います。

PHPカンファレンス福岡最高！

PHPカンファレンス福岡2018で英語ネタのLT登壇してきた

Tue, 18 Jun 2019 09:00:00 +0900

2015年から今年で4回目を迎える、2018/06/16(土)に開催されたPHPカンファレンス福岡2018に参加してきました。僕にとって特別だったのは、ただ参加したというだけでなく、LTの登壇者として参加したということです。

今年の目標として、何らかのイベントで初めて登壇するということを掲げていたのですが、LTとはいえ、よりによってこのような大きなイベントを選んだのは我ながら頑張ったなと思います。

今回は登壇者視点の記事を書きます。参加者視点の記事は別に書こうと思っています。発表内容についてはあまり触れておらず、初登壇の体験記といった形です。

当日まで

当日に至るまで、実は色々あって、自分の能力のなさに自信を無くしたりして調子を崩し、参加する1ヶ月ぐらい前までは正直なところ辞退してしまおうかとも考えていました。しかし、会社の方々を始め色んな方の支えで何とか復帰して繋ぐことができ、当日に臨めました。改めて自分は周りの人に恵まれていると感じました。感謝しています。

登壇すると腹を決めましたが、資料作りは結局ズルズルと前日まで手をつけませんでした。かなり現実逃避しちゃっていました。

構想はまとまっていたものの、5分という時間で伝えたいことを凝縮しようとするとなかなか大変でした。色んなLTやスライドに関する記事を参考にし、ポストイットを使って話の流れを決めていったりしました。Keynoteの操作に慣れていないせいで、グラフを1つ作成するのに手こずって、本質的でないところで時間を浪費（プログラミングでもあるあるかも）してしまったりといったこともありましたが、1日を使い、資料はなんとか作り終えることができました。

いざ登壇

いよいよ当日を迎え、朝から緊張がじわじわと止まりませんでしたが、不思議と腹は据わっていてその緊張感を楽しめていました。大げさに言うと生きてる実感みたいなものを緊張から感じられて、これはステージに立つ側の特権だなぁと思いました。

そして、いざ自分の出番を迎え、壇上に立ち100人以上の観衆を前にすると、マイクを持つ左手の震えは止まらず、会場の反応を見る余裕もありませんでした。しかし、PHPカンファレンス福岡LT名物の5分を超えると鳴らされてしまうドラも鳴らされることなく、無事発表を終えることができました。（ Speaker Deckのスライド）

ステージを下り、Twitterのハッシュタグを覗いてみると、生の好意的な反応をいただいていて、思わずニヤニヤしてしまいました。大きな達成感がありました。

登壇を終えて

このTOEIC 960取れたネタ、スライドで言及した記事も2016年の記事ですし、くもキャストというPodcastに出演したときにも触れていただいたりと、かなり使いまわしていて、ウケはいいものの、そろそろこれに頼るのも止めたいなと思っていたりします。次にどこかで登壇する時はがっつり技術ネタでいきたいところです。

また、LTという短い時間だったので、おすすめコンテンツの具体的な利用方法までは紹介しきれませんでした。そのことについては別にブログ記事を書きたいなと思っています。

PHPカンファレンス福岡2018でのLT登壇、平成最後の年に自分がやった事として僕の人生に刻み込まれましたし、この規模のイベントで登壇できたことは大きな自信となりました。人間結局やるかやらないかの部分も大きいなと実感しました。

このような場を用意してくださった、スタッフの方々を始め、参加者の方々、コミュニティに感謝です。PHPカンファレンス福岡最高！

略歴

Mon, 01 Jan 0001 00:00:00 +0000

1985-2002 生誕から高校中退まで

福岡県福岡市で生誕 (1985/07/03)
高校を1年時に中退 (2002/03)

2002-2011 引きこもり

引きこもって海外ゲームを遊ぶ日々が長く続いた (2002-2010)
通信制高校に入学後、高校卒業程度認定試験に合格 (2011/10)

2012-2015 情報系専門学校

福岡市の情報系専門学校に入学 (2012/04)
基本情報技術者、応用情報技術者、情報セキュリティスペシャリストの資格を取得
情報系専門学校を卒業 (2015/03)

2015-2017 初社会人

専門学校のグループ企業に契約社員として入社 (2015/12)
専門学校のグループ企業を退社 (2017/02)

2017-2019 キャッチアップでアルバイト

株式会社キャッチアップにアシスタントエンジニアとして入社 (2017/10)
baserCMSのコミュニティ活動などに関わる
株式会社キャッチアップを退社 (2019/08)

2019-2023 GMOペパボで初正社員

GMOペパボ株式会社に入社 (2019/09)
ホスティング事業部でロリポップ！、ムームードメイン、ヘテムル、おさいぽ！といったサービスの開発、保守、運用に関わる
GMOペパボ株式会社を退社 (2023/03)

2023- SmartHR

株式会社SmartHRに入社 (2023/04)
現在に至る