今年の1月から新規立ち上げの開発部署でチームリーダーをやっていて、色々と「俺の考えた最強の開発手法」的なものを試しているのだけれど、その一環で、日本語でなく英語でコミットメッセージやソースコードのコメントを書くという開発ルールを導入してみた。 その結果、メリットよりもデメリットが大きいことが判明して、チームとして英語で書くのをやめにしたので、その振り返りを書きたい。 英語でコメントを書くメリット Web開発の世界でグローバルな共通語として機能している 日本語入力に切り替える必要がないので、タイピング効率が良い 文法的に日本語よりもロジカルに書きやすい GitHub CopilotやChatGPTのような生成AIのツールとの相性が良い RuboCopのRSpec/ContextWordingのように、英語利用を前提としたルールを提供しているLinterがある 当初このような点をメリットとして

最近やたらと絶賛されているMarkdownメモアプリのObsidianを使ってみたら、なるほど、これは便利だ、という感じなので、使い勝手について書きたい。 ちょっとしたメモの整理に便利 仕事でも日常生活でも、わざわざ文章にまとめて公開する程ではない、ちょっとした思いつきやToDoのようなものをメモしたいときがある。そんなとき、私は今まで仕事ではSlack、プライベートではTwitterの自分宛てのDMを使ってメモを管理していた。 ToDoの管理量を最小限にして、すぐに行動に移して消化する、という点ではセルフDMでのメモ管理もあながち悪くなかったのだけれど、如何せん機能が貧弱すぎた。TwitterのDMではメッセージの編集すらできない。 そんなちょっとしたメモの管理先として、Obsidianは圧倒的に便利だ。 関心ごとにファイルを分けて、見出しを付けるだけでも随分と整理された感じになるし、後

Google Analyticsで2023年7月1日からUAの計測ができなくなり、GA4への移行が必須になるということで、個人で開発している短歌投稿サイトUtakataもGA4に移行したのだけれど、移行した途端にページビューの値が極端に減少してしまうという事態に遭遇した。結論から言うと、RailsのTurbo利用のサイトで正しく計測するために、UAのときとは異なるイベント送信が必要という原因だったのだけれど、関連ワードでググっても（Turboの利用者数が少なすぎるのか）解決記事の類が出てこなかったので、この問題の解決方法を書いておく。 UA時代のTurbo対策 UA時代からTurbo利用でページビューを正しく測定するには一工夫必要だった。 上のような形でturbo:loadをeventをトリガーにgtag関数を実行しないと正しくページビューが計測されない。 GA4でのTurbo対策 GA4

6年前にほぼ全財産の500万円で日本株の個別投資を始めたけれど、その結果は最大で100万円以上の損失を抱える大失敗に終わった。 退場がちらつく中、思い切って米国株インデックス投資に切り替えたところ、徐々に損失が補填され、今月になって評価額ベースでトータルプラマイゼロの500万円のラインまで戻すことができた。これまでの経緯を振り返りつつ、日本株個別投資の難しさと、米国株インデックス投資を行う具体的な方法について書きたい。 日本株個別投資の難しさ そもそもの話として、インデックス投資が個別投資に対して優位性があるというのは有名な話で、ましてや素人が個別株投資を行って長期的にインデックス投資よりも優れた成績を出すのは非常に難しい。とは言え、インデックス投資にはロマンや賭け事としてのゲーム性がないのもまた事実だ。当時の私は自分だけは上手くいくはずという、この上なく見通しの甘い期待を抱きながら日本株

前回の記事で書いたように、個人的にChatGPTに相談することは、既にGoogle検索と同じくらい生活の中で当たり前の行為になっている。このまるで魔法のような応答を見せるツールを使っていて、感じたことが色々とあるので、書いておきたい。 知的探求のツールとしての使い方にこれまでと大きな違いがある訳ではない 方法序説 (岩波文庫) 作者:デカルト,谷川 多佳子岩波書店Amazon わたしは、それまで自分の精神のなかに入っていたすべては、夢の幻想と同じように真でないと仮定しよう、と決めた。しかしそのすぐ後で、次のことに気がついた。すなわち、このようにすべてを偽と考えようとする間も、そう考えているこのわたしは必然的に何ものかでなければならない、と。そして「わたしは考える、ゆえにわたしは存在する〔ワレ惟ウ、故ニワレ在リ〕」というこの真理は、懐疑論者たちのどんな途方もない想定といえども揺るがしえないほ

最近ChatGPTに月額20ドルの課金をして、GPT-4を使っている。Webアプリケーション開発の仕事で、情報漏洩の観点から、業務情報をインプットに一切含めない範囲で使っているけれど、それでも明らかに知的生産性や技術の学習効率に、これまでの世界観が変わるほどの違いを感じているので、有効に使えるユースケースの紹介と、便利に活用する方法について書きたい。 有効なユースケース 業務で有効性を確信したユースケースと、応答例を紹介したい。これらのユースケースは、特にプロンプトの工夫なく、自然な日本語のやりとりで活用できる。 プラクティスの相談 特定のプラクティスのメリット・デメリットの整理や、どうしてそうするのかの理解の深堀りに使える。 実装方法の相談 一定以上メジャーな言語やライブラリの実装方法を相談すると、かなり込み入った要件でも、サンプルコードを示して解説してくれる。エラーメッセージを入力する

Railsで開発環境のデータを追加するrails db:seedコマンドの中身で、Rails 6で追加されたupsert_allメソッドを使うと、後から何度でも上書き更新できるコマンドにできて便利な印象があるので、実装例をサラッと書いておきたい。 seedsをCSVで用意する データの形式は何でも良いのだけれど、RDBのレコードに対応するデータはCSV形式で書くのが直感的で扱いやすい印象があるので、今回はCSVで登録する方式とする。db/seedsディレクトリ下に、"#{テーブル名}.csv"の命名ルールでCSVファイルを作成し、ヘッダーにカラム名の形式で登録する。 seeds.rbでupsert_allで更新する CSVの中身を、upsert_allの引数に指定できるhashの配列に変換する。upsert_allではcreated_atとupdated_atも指定する必要があるので、現在

2021年の10月に東京から奈良に転居して1年以上が経つ。一般に、地方移住してみた結果の紹介記事のようなものは、外交的でアクティブな人が書くようなイメージがあるけれど、内向的で出不精な私もかなり楽しく暮らせているので、感じているメリットとデメリットを書きたい。 奈良移住の背景 妻の大学が奈良女で私も大学が関西だったので、学生時代に奈良でよく遊んだ経験があり、また、個人的に奈良の史跡が好きで、一人で奈良を散策する機会も多かったため、夫婦で奈良への印象が非常に良く、いつか奈良に移住したいねというようなことを話していた。その意向を会社のCTOとの1 on 1 Mtgで伝えたところ、すぐに会社の承認フローを通してもらえて、意外なほどアッサリと奈良への転居が可能になった。 奈良の中心部の近鉄奈良駅のすぐ近くに引っ越して来て、私はフルリモートでWeb系エンジニアの仕事をしていて、妻は医療系の現場の仕事

ヨッピーさんとはてなブックマーク（以下はてブ）ユーザーが揉めたのを発端として、はてブユーザーのマナーの悪さについて議論が起きている。この点については私も一家言あるので書いておきたい。 はてブコメントの何が不快か 上のブロガーの方々も語っているように、はてブのトップページなどに掲載されると極めて不快なコメントが大量につくというのは、多くのブロガーが経験していることだろう。 私も一昔前ははてブでも特に質の低いコメントが付きやすいフェミニズム / ジェンダー論関連の話題でよく記事を書いていたので、記事に不快なブコメが大量に付くという経験をしたことは多い。まずは個人的に感じている、ブコメが不快な理由についてまとめてみる。 論旨と関係ない内容で好き勝手に罵倒される不快さ まず前提として、文章を書いてインターネットに発表している人間としては、たとえネガティブなものでもフィードバックがあるというのはあり

『ファイアーエムブレム エンゲージ』をストーリークリアまで遊んで非常に楽しめたのでレビューを書きたい。 駄作の予感しかしない事前印象 事前印象だと、以下のような観点で駄作の予感が強く、「それでもFEシリーズである以上やるしかないか」という後ろ向きな気持ちで購入していた。 マルスなどが出てくるクロスオーバー作品 クロスオーバー作品はシナリオや世界観が破綻しがちな印象 世界観・キャラクターが幼稚な印象で、特に魅力を感じられない ゲーム部分も「いかにも普通のFE」という凡庸な印象 実際に遊んでみて、正直シナリオやキャラクターの稚拙さについては事前印象そのままな部分もあったけれど、SRPGのストーリーマップ攻略部分の完成度が圧倒的に高く、SRPGファンとして心の底から楽しめるゲーム体験だったため、その魅力について書きたい。 「ストーリーマップだけのSRPG」として遊べるありがたさ 風花雪月、結局ス

イーロン・マスク体制のTwitterがあまりにも不安定すぎることもあり、私もMastodonを始めてみた。 Twitterのような大企業による開発・運用体制を持たない形態からして当たり前の話ではあるけれど、Mastodonの機能性はTwitterと比べて弱い。その一方で、シンプルな作りであるが故に、何かを投稿して、知らないユーザーからいいねが来るというような、SNSの原始的な体験を再発見できる感覚がある。 対してTwitterはどうか。増えないフォロワー。ミュート。ブロック。有料noteで煽動する論客への苛立ち。引用ツイートでのクソリプ。スペースでのどうしようもない暇人たちの集まり。インタラクティブな「つながり」を実現する機能が充実している一方で、承認欲求と内輪への関心に閉じて行く様に、何とも言えない行き詰まりのような感覚がある。 Twitterに限らず、「つながり」に関心が傾いたインター

Web系エンジニアとして働いていて、基礎的な部分の技術理解度が何よりも大事と感じているけれど、その一方で、最新の動向に詳しいのも一定強みになる印象だ。というのも、日常的に最新の技術動向をチェックするということをやっていないエンジニアの方が多く、毎日少しずつチェックするということをやっているだけでトレンドに対する理解度に差が出て来る。 この最新情報にキャッチアップするためのツールとして、私ははてなブックマークが圧倒的にお手軽かつ、目的に応じて柔軟に活用できると感じているため、その活用方法を紹介したい。 はてなブックマークでの情報収集方法 その方法は非常にシンプルで、ただ「タグ検索」をするだけだ。例えば上のリンク先では「JavaScript」のタグ検索で、50ブクマ以上されているエントリが、新着順に表示される。JavaScriptやフロントエンドについて、有益なエントリが表示されていることが分

ライスさんの記事を読んで、真っ当な批判で、支持できると思った。 その一方で、一般論として、こういった不誠実な議論を展開する論客や、その支持者に抗議することはなかなか難しいものがある。 まず、記事中でライスさんがされているような、特定界隈の攻撃のターゲットになることは、なかなかに耐え難いストレスを生むだろう。 また、このライスさんの記事に関するTwitterの反応を見れば分かるように、このレベルの事象についても、「どっちもどっち」的な相対化や、「からかい」や「いじめ」などの用語について、記事と無関係な文脈での一点突破の「論破」を試みる人間が多く、このような論客に言及すると、論客本人だけでなく、好き勝手に小理屈を展開する有象無象のユーザーの出現に苛立たしい思いをすることになりそうだ。 そのような中で、 というか、御田寺の行っているような「からかい」行為を許容しないというくらいの良心は、わたしに

業務のRailsサーバーサイドのAPIリファクタ対応を通して得られた知見について、前回はService Objectについて書いたけれど、今回はREST API周りの手法について書きたい。 全体的にRails wayに沿って、実装者の恣意性による方針のブレを極力排した、見通しの良いリソースベースの設計を実現することを意識している。 REST APIのエンドポイント設計 CRUDの基本アクションの使用を優先し、適宜リソースを分割する コントローラが元々持っているRESTアクションやデフォルトの5つの機能にはないメソッドを付け加えたいと思ったら、いつだって新しいコントローラを作る。それだけでいいのです。 上の記事でDHHが述べているように、index、show、new、edit、create、update、destroyの基本アクションの利用を優先し、独自アクションの定義を避けることは、リソー

業務のRailsアプリのリファクタ対応の一環でService Objectを入れてみたところ、なかなか快適に使えている感触なので、RailsでのService Objectについて私なりに調べたことをまとめてみたい。アンチパターンとして批判されることも多いService Objectについて、どういった使い方をするとマズいのかも掘り下げてみる。 Service Objectが欲しくなるとき Rails標準のMVCで業務アプリケーションを実装して行くと、ビジネスロジックが複雑になるにつれて、ControllerまたはModelの処理が肥大化してつらい状態になりやすい。具体的には、 可読性が悪い テストが書きづらい Modelにメソッドが乱立し、そのModelがビジネス上どういう振る舞いを持つ概念なのか読み取りづらい これらの観点が挙げられるだろう。この問題を解決する手段の一つとして、 Ser

私が今所属している新規事業の部署で、日本の開発会社経由でベトナム人メンバー（開発エンジニア2名、QAエンジニア1名）に働いてもらっているのだけれど、私が転職してジョインした頃は随分といい加減な管理をしていて、成果物のクオリティも非常に残念な感じになっていたので、昨年の12月頃から私がチケット起票からコードレビューまでほぼ一人で担当する体制でテコ入れをすることになった。色々と苦労しつつ、今では一定以上のクオリティで効率良く開発できるところまで改善することができたので、オフショア開発の典型的なアンチパターンと思われる例や、オフショア開発の向き不向きについて感じたことを書きたい。 オフショア開発のアンチパターン 最低限の働きができないメンバーを放置してしまう オフショアの開発会社は、中堅レベルのエンジニアから、明らかにド素人なエンジニアまで、多様なスキル感のメンバーを抱えていて、各現場の温度感に

7月に配信された『ポケモンユナイト』に最近ハマっていて、ソロを中心に600戦以上プレイして最上位のマスターランクでレート1300以上、世界ランク3000位以内になるまでやり込んだ。 ポケモンユナイトの魅力 私はこれまでスプラトゥーンでエイムができず、スマブラで小ジャンプが安定しなかったりして初心者帯で負けまくって挫折するくらいアクシャン操作が下手なのだけれど、ポケモンユナイトはボタン操作が簡単な上に、攻略情報の理解度や状況判断の方がよりクリティカルなので、アクション操作が下手でも結果を出すことができた。この手の大規模な対人対戦ゲームで上位層でプレイできた経験がないのでなかなかの達成感がある。 私はポケモンユナイトの派生元の『League of Legends』も数年前に遊んでいてかなり楽しめたけれど、 1ゲームの時間が長い チャットで英語で罵倒される これらの要素がしんどいなと思って挫折し

赤字を垂れ流し続けるUtakata 3年間運用している個人サービスの短歌投稿サイトUtakataの運用費が毎月約2000円（Heroku毎月16$*1 + お名前.comドメイン維持費毎年約3000円）発生しているのだけれど、収益化の目処がまったく立っていない。 去年の12月から運用していたバナー広告を廃止しました。最低引き落とし金額に達せず、広告で発生した収益は0円という結果になります😂試運用の結果バナー広告はまったく無意味に利便性を下げるだけと判断し、廃止としました。— Utakata (@utakatanka) 2021年6月1日 一時期試験導入していたnendのバナー広告はほとんどクリックされず最低引き落とし可能額の3000円に到達できなかった。 Stripe Payment Linksのリリースを知る そんな中、コーディング不要で決済機能を導入できるStripe Payment