GitHub Codespaces 雑感
GitHub Codespacesをちょっと試した。 初期導入時にハマりどころも多いけど、真面目に設定しておけば、普通にCodespacesの環境だけで開発することは十分できそうだなと感じた。リポジトリ単位で環境を用意するのが基本で、多くのリポジトリに対して毎日のようにレビューをしたりPull Requestを出したり、みたいな開発フローには綺麗にはまらないと思うけど、普通に仕事で単一のリポジトリに対してだけ作業する用途であれば上手くはまると思う。Zoomで会議しながら重い処理を実行していても影響が無いのは良かった。Zoomで会議しながら重い処理を回すべきではないという意見もある。 Codespacesの利用の流れ Codepsacesを利用するときの流れについて。まず、予め .devcontainer/devcontainer.json を配置したリポジトリを用意しておく。Codespa
リリースの自動化
最近は下記のようにライブラリ等のリリースを自動化している。 バージョンを入力するとPull Requestを生成 Mergeするとリリース ラベルの管理 前回のリリース以降にMergeされたPull Requestからリリースノートが自動生成されてほしい。このとき、Keep a Changelogの形式を参考に、変更点が以下の7種類に分類されてほしい。 add change deprecate fix remove security other そこで、Pull Requestに予めラベルを付けておくことで、どの節に分類するかを決定させる。またこのようなラベリングの習慣を設けることで、各Pull Requestの粒度の是正もねらう。ラベルを利用したリリースノート自動生成機能自体はGitHubが備えているので、.github/release.ymlでそのラベルを使う旨を指定すれば良い。 この
Ruby用VSCode拡張: vscode-ruby-light
Ruby向けに、vscode-ruby-lightというVSCode拡張をつくっています。この拡張は、利用者に特にRubyのインストール要求することなく、シンタックスハイライトやカーソル操作など、VSCode標準の機能よりちょっと良い編集体験を提供しようという目的の拡張です。 最初は「メソッドやブロックをもう少し上手く選択できるようにしたい」というモチベーションで調べ始めたのですが、気付けば色々な機能を持つVSCode拡張が出来上がっていました。この記事では、幾つかの機能を紹介しながら、関連する話を書いていこうと思います。 Selection Range VSCodeにはExpand Selectionというコマンドがあり、選択範囲を拡大したり狭くしたりできます。このコマンドには、例えばWindowsであればデフォルトでShift + Alt + →にショートカットキーが割り当てられていま
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
サロメ椅子 百万点見本市
おすすめの椅子のまとめ。 私の椅子、ですわ 壱百満天原サロメさんによる疲れにくい椅子を募集するツイートに寄せられたリプライと引用を読み、紹介されていた椅子を幾つかのカテゴリに分け、言及数の多かったブランド順に整理してみました。 オフィスチェア ハーマンミラー - アーロンチェア ハーマンミラー - エンボディチェア ハーマンミラー - セイルチェア オカムラ - シルフィー オカムラ - コンテッサII オカムラ - バロン オカムラ - CG-M エルゴヒューマン - プロ エルゴヒューマン - ベーシック エルゴヒューマン - WINcase イトーキ - サリダ YL9 イトーキ - エフチェア イトーキ - カシコチェア イトーキ - アクトチェア Steelcase - ジェスチャー Steelcase - リープ コクヨ - ing コクヨ - Duora ウチダ - パルスチ
『Sustainable Web Development with Ruby on Rails』を読んだ
David Bryant Copelandさんが書いた、Railsについてのこだわりの詰まった本。 takahasimさんも『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思うと言っていたように、面白い。これまでRailsを使ってきた中で、楽しいこともつらいことも沢山あったんだろう。そういうことが感じ取れるような話が展開されている。 幾つかの気になった話題を拾い上げて、自分の感想を述べていきたい。気になる話題は100個ぐらいあるが、がんばって10個ぐらいに留めたい。 Don’t Create Custom Actions, Create More Resources Railsが提供する7種類のアクション名以外使うな、必要なら新しくリソースをつくれ、という主張。つまりDHHはどのようにRailsのコントロー
ストレスレストーキョーで作業
ストレスレストーキョーというリクライニングチェアを、作業用に使っている。 温泉施設や宿泊施設などによく、リクライニングチェアやマッサージチェアが置かれていると思う。これに座ると体力が回復する。使用感としては、あれに近い。 この椅子は座っているだけでHPが徐々に回復していくので、これで作業しているとほぼHPが減ることがない。例えば10秒あたり400のダメージを受ける作業をしていても、この椅子に座っていると10秒あたり600ぐらい自動回復していくので、何時間作業しても倒れることはない。 リクライニングチェアを作業に使うために、幾つか工夫している点がある。 画面の位置が適切になるように、ディスプレイアームを使って調整している。色々と試した結果、湾曲ワイドディスプレイを上下に並べる配置に落ち着いた。ディスプレイアームについては『エルゴトロン LX デュアル』 という記事にも書いている。手前方向にデ
RubyのDockerイメージでよく使う環境変数
Ruby向けのDockerイメージで使いがちな環境変数について整理する。 GEM_HOME RubyGemsに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば gem install foo を実行すると、この環境変数で指定したディレクトリにfoo gemがインストールされる。 Dockerでありがちな作戦として、/gem のような適当なパスにデータボリュームをマウントしておいて、そこにGemを永続化させておくというのがある。このときGEM_HOMEを /gem に指定しておくと、gem install bundler を実行したときそこにBundlerがインストールされ、更に /gem/bin/bundle も用意される。 BUNDLE_PATH Bundlerに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば bundle i
Bring Up My Post
ソフトウェア開発などでバージョンを上げるときによく "bump version" のように "bump" という語彙が使われるんだけど、これって "Bring Up My Post" の頭字語だったんだ。 つまり、みんなコミットメッセージで「バージョンage」とか言っていたのか。急に在りし日のインターネットに引き戻された感覚だ。 ちなみに、このように完成形の語ありきでつくられた逆頭字語をバクロニム (backronym; bacronym) というらしい。再帰的な頭字語である GNU (GNU's Not Unix) や PHP (PHP: Hypertext Preprocessor) もバクロニムの範疇に入るみたいだ。 『バクロニム - Wikipedia』
Rustでサイトを再実装
このサイト r7kamura.com の実装言語をRubyからRustに変えてみた。 アプリケーションの概観 このサイトには、大別すると次の6種類のルーティングパターンがある。 GET / トップページ GET /articles/:article_id 記事ページ GET /feed.xml RSSフィード GET /links リンク集 GET /sitemap.txt サイトマップ (Google Search Console等が利用する) GET /* その他の静的ファイル (CSSや画像など) Rubyの実装では、適当なRackアプリケーション + rack-captureという構成で、Webアプリケーションとして実装しつつGitHub Pagesのために静的ファイルも吐き出せるという仕組みになっていた。 Rustの実装もほぼ同じで、適当なHTTPサーバー + 適当なHTTPクラ
docker composeのserviceをグループ化
docker composeではserviceごとにprofilesという属性を指定できて、起動時にこれを指定することで関連する一連のserviceだけを起動させられる。 どういうシーンで使えるのか。例えばとあるRailsアプリでは、一部の開発者はMySQLやRedisなどのデータストアだけdocker composeで起動して開発し、他の開発者は加えてRubyもdocker composeで起動して開発している。osxfsが遅すぎて、ファイルへの読み書きが頻発する処理がmacOSのDockerでは使い物にならないからだが、この話は今回どうでもいい。さてこのとき、データストア用のserviceに適当な名前のprofileを割り当てておくことで、個々のserviceの名前を逐一指定しなくても起動でき、将来の変更にも強くなって嬉しい。 # profile導入前 docker compose u
『天穂のサクナヒメ』をやった
『天穂のサクナヒメ』というゲームをやった。 ジャンルは、一言で言うと、和風稲作シミュレーション&アクションRPG。主人公は豊穣神と武神の娘という設定で、稲作パートと2Dアクションパートを並行して進めていくことになる。 ネットの評判では稲作パートの話題をよく見かけるが、アクション要素もかなり楽しめた。一方を進めないと次第に他方も進めなくなってくるという調子で、上手いこと出来ている。若干格ゲーに近い操作感なのもシビアで良い印象だった。 初めての田植え このゲームは、最初から正解を示すようなことはしてくれない。むしろ、まずは失敗を体験させてから、徐々に「これは本当はこうやると良かった」と身を持って味わわせるような設計になっていると思う。最初はその辺がフラストレーションに感じることもあるのだけど、慣れてくるとその試行錯誤のサイクルを回すのも気持ち良くなってくる。 幾度目かの田植え とはいえ失敗する
rack-ok
rack-okというGemをつくった。 概要 何かというと、GET /healthに対して200 OKを返すだけのRackミドルウェア。冗談みたいなプログラムだけど、今更Rackの世界に入門してハローワールドしたかった訳ではなくて、ロードバランサーからのヘルスチェックに応答させるために、こういう実装が必要になる機会がそれなりにある。 背景 Railsアプリとかだと、こういうのは（適切なという意味ではなく雑なという意味で）適当なコントローラで実装されたりするのだけど、機能てんこ盛りのコントローラで200を返すだけの処理をやるのはどうにも無駄が多い。それに、ヘルスチェックはHTTPでリクエストが飛んでくるので、SSL対応用の機能を有効化しようとするとヘルスチェック用のエンドポイントだけ確認対象から除外する必要が出てきたりする。Rackミドルウェアだと、その辺の問題が解決できる。 ヘルスチェック
サメを支える技術 第2版
大きなサメのぬいぐるみの購入方法について。 背景 最近サメの人気が高まっているのか、サメのぬいぐるみについてよく質問されるようになった。Gawr Guraさんの影響が大きいのかもしれない。つい先日質問してきた人は、サメ好きの友達にプレゼントするつもりらしい。いい友達だ。これまでこういう質問に対しては昔書いたサメを支える技術を紹介していたが、情報が古くなってきたので、この機会に新たに書き直すことにした。 サメの配信を見るサメ 購入方法 2020年10月25日現在では、この大きなサメのぬいぐるみはchumbuddy.comから購入できる。2015年にはamazon.comでも購入できたので、自分はここから購入したのだけど、今は取り扱っていないようだ。惜しいことだ。 chumbuddy.comでは、わた入りザメとわた無しザメが売られている。 体積が増えるので海外からの配送が大変そう 出所不明のわ
Rails 設計 最強
自分が目指したいRailsアプリの形とは何か、ということについて考えていた。 常日頃から考えていたRailsアプリでの不満をこの議論に合流させた結果、「Rubyを書くときに当たり前にやるようなことを、Railsアプリを書くときでも当たり前のようにやる」というところが肝で、自分が目指したいRailsアプリの形はその先にあるのではないか、と一旦結論付けてみることにした。 「普通にRubyでコードを書くときはやらないけど、Railsだったらこう書く」という何かが存在していることが、さまざまな失敗の原因をつくっていると思う。 RubyとRailsが地続きに繋がっていないというか、どこかで断絶があり、そこから筋の悪い設計が生まれている ―あるいは持ち込めるはずの良い設計を持ち込めていない― のではないか、という話。 実際にはどの辺りが気になっているのか？という例を挙げると、氷山の一角を指摘するだけな
最近のRails関係の仕事内容
RubyやRailsのアップグレードを主なマイルストーンとしつつ全体的に開発体験を良くしていくというタイプの仕事を請けることが多いのですが、仕事を依頼する側の視点に立ってみると「実際のところ業務に参加するとどういうことが行われるのか？」というのがやはり気になると思います。 実際、最近の打ち合わせでもその手の不安について相談されることがあったので、ここ1ヶ月でそれ系の仕事で出したPull Requestを元に、実際に何をやっていたかの例を挙げてみたいと思います。 開発環境構築手順や説明方法の改善 荒れたRuboCopの改善 .rubocop.ymlからTargetRailsVersionを取り除く DEPRECATION WARNING対応いろいろ 既存のメソッドと名前が被っているスコープを別名に変更 RSpecのpositional-argumentsを置換 activerecord-im
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
