僕は本来、人前に出て積極的に話そうとは思わないし、目立たずにおとなしく引きこもっていたいみたいな気持ちがある。潔癖な部分もあるので、プレゼンスばかり高くて技術力がないような中身が無い人間になりたくないし、そうなったら死ぬしか無い、みたいな気持ちもある。それなのに何故、ものすごく技術力があるわけではない自分が対外発表をするのか。 それは元はと言えば対外発表をするような側に行かないとエンジニアとして生き残れないのではないかという危機感があったからです。 Shibuya.pmの衝撃 初めて参加したShibuya.pmは#10だった。その頃の僕は一企業のよくある何でも屋の1人システム担当であり、開発のメインは前担当者から引き継いだレガシーASPだった。そしてつぶしの効く技術を習得したいと思いPerlを学び始めた頃だった。そしてPerlがそこそこ書けると手応えを感じ始めているところだった。 ところが

当サイトをFediverseに対応させました。 @songmu.jp@songmu.jp でMastodonなどでリモートフォローできます。 やったことは、 このブログがFediverseに対応しました というtyageさんのエントリーをそのままなぞっただけです。このエントリーはh-cardのサイトトップへの掲出に関する説明が書き漏れていそうでしたが、それも実施しました。 当サイトは静的サイトであり、付随機能は外部サービスに頼りたいと考えている。例えば、コメント機能はDisqusを使っている。Fediverseに関しても何かそういうサービスがないかと思っていたが、Bridge Fedというサービスがあり、上記のエントリー内で懇切丁寧に解説されていたので導入は比較的簡単で、作業時間は小一時間でできた。大まかな手順は以下。 Bridgy Fed というサービスを利用してサイトをFedivers

ヘンリーでVP of Engineeringを務めるSongmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023 、11日目の記事です。 はてなブログとblogsync はてなブログにはAtomPub APIという、はてなブログをAPIで操作できる機能があります。これは実は結構古くからある機能で、2013年にリリースされています。当時のはてなインターン生によるもので、moznionさん、krrrrさんが担当されたようです。歴史を感じますね。 そのAtomPub APIを利用し、はてなブログを管理するためのCLIツールとして、当時はてな社のチーフエンジニアで現CTOのmotemenさんが「個人で」開発したGo製のOSSがblogsyncです。これは2014年にリリースされています。社員が自社サービスのユーザーであり、社員が趣味の個人開発でそのサービス利用のため

突然何を言い出すのかという話ですが、対話相手にコミュニケーション能力を求める醜さについて書きたくなったので書きます。 僕はオタクだったしスクールカーストで言うと下の方を彷徨ってきた。地元でもいろいろあって浮いていた。新卒時の就活も散々だった。なので、コミュ力がないことは自覚しているし、だからこそ「コミュニケーション能力」という言葉には警戒心があります。 比較的マイノリティであったことが多かった経験上分かったのは、相手とコミュニケーションが取りづらいな、と思うときは、そもそもプロトコルが異なる、ということです。 これは、話している自然言語が違うようなものだと考えるとわかりやすい。例えば、自分が日本語しか話せず、相手がロシア語しか話せないのであれば、まともなコミュニケーションが成り立たないのは明らかです。そして、その時に、日本語が話せない相手にコミュ力がないと思うような人はいないでしょう。 そ

もうだいぶ前になってしまいましたが、3月に京都でYAPC::Kyotoに参加してきました。 YAPC::Kyotoは運営の皆さま、本当にお疲れ様でした。コロナ渦で運営の継続には色々苦労があったかと思います。そんな中、世間的にコロナ明けの雰囲気になってきている中、ちょうど先陣を切るような形でオフラインイベントが開催できて、大きな盛り上がりを見せたのは、皆様の苦労が報われたようにも思いました。旧交も温められたし、それだけではなく、学生支援制度などのお陰で、若い人も参加していて交流が盛り上がってよかったです。 思えば、2019年のYAPC::Tokyoのときに僕がベストトーク賞を受賞した勢いで、懇親会の最後にで胴上げされた後に、無責任に「次は京都でやるぞ!」と、勝手に宣言したのが実現した形でした。JPAにも禄に関わっていないのに(当時は一応末席で参加することもあった)。とはいえ、懇親会で @__

1月から株式会社ヘンリーに入社しました。ヘンリーは「社会課題を解決し続け、より良いセカイを創る」というミッションを掲げ、現在はHenryというレセコン一体型クラウド電子カルテサービスを主力として医療DXに取り組んでいるスタートアップです。 https://corp.henry-app.jp/ ヘンリーのことはあまり知らなかったのですが、ずっと一緒に働きたいと思っていたエンジニアの一人である縣さんが所属しており、今回私が転職活動を始めたのを彼が早々に察知して誘ってくれたのがきっかけです。 彼と話したところ、開発に色々課題は抱えつつも前向きに、楽しそうに働いていると感じたのが印象的でした。ナイスガイな彼がそれくらい魅力を感じているのであれば、良いチームで面白い社会課題を解いているだろうなと。 その後、2週間で様々なポジションの7名とお話しました。どの方もモチベーション高く、顧客や事業やプロダク

12月末でLaunchableを退職します。実際には11月30日が業務最終日で12月は求職活動をしていました。幸い12月中に転職先を決めることができ、1月から次の会社で働きます。次の会社は年明けにお知らせします。 求職活動中は多くの方や会社から連絡をいただき本当にありがたかったです。全てにお返事をすることができず申し訳ありませんが、直接お知らせできなかった方にはこちらでお知らせとなることをご了承ください。 以上でお知らせは終わりで、以降は単なる中年男性のしょうもない独白です。 退職は非常に残念で、Launchableでまだまだやりたいことはあり、これからというところでもあったのですが、言ってしまえば西海岸外資の洗礼を受けたということです。 今回の僕の挑戦はあっけなく終りを迎え、ほろ苦い体験となりました。とはいえ間違いなく良い経験にはなりました。Launchableの事業は引き続き応援してい

tl;dr GitHubのリリースノート自動生成のAPIを用いてkeep a changelog形式のCHANGELOG.mdを出力するツールを作った https://github.com/Songmu/gh2changelog gh2changelog -all -unreleased とかで出力 細かいオプションはヘルプ等を参照のこと ghchに引数体系は近いです 本題 GitHubには、リリースノートを自動生成する機能がある。これは、リリース間でマージされたpull requestのタイトルを一覧し、リリース項目としてGitHub Releases上に出力してくれるものです。リポジトリ上に.github/release.yml設定ファイルを配置すれば、pull requestの作者やラベルを元にグルーピングしたり非表示にするといった出力内容のカスタマイズもできる。 このあたりの実際の

常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr

カッコつけたタイトルを付けてしまった。中二っぽい。 強がりと言うか、自分に言い聞かせている部分もあるのだと思う。 有り体に言うと、新しい環境にまだ苦しんでいて、上手く動けていない。こんなことを書くと同僚に心配されてしまいそうだが、同僚には現状を伝えていて、その上で信頼してくれているとも感じている。会社に不満があるわけではなくて満足している。 少し精神的に参っていたので、今週前半は少し休ませてもらった。これは休んだほうが良いな、と思ってyoshioriさんに相談したところ、こちらから休みについては何も言わずとも「休んだほうが良いよ」と言ってくれた。話が早くてありがたかった。 現状意識していることや感じていることについて書き留めておく。 成果を完璧に出せてはいないが淡々とやる 現状、社内では成果目標を定めて、達成度を振り返るというのを毎月やっているが、1月に関しては100%をつけることができた

タイトルの通り。なんとなく自分のサイトを自分で運用したいと思っている。それはWebエンジニアとしてのポートフォリオ的な側面もあるし、それに加えて、自分の書いた文章を自分の管理下におきたい欲求があるのだと思う。 サブブログを、はてなブログに持っていますが(https://blog.song.mu)、これもまた、コンテンツはblogsync を使って管理しています。 このサイトはもともとVPS上のNginxから静的配信されており、 VPS上のgit bareリポジトリに直接push post-receive Hook で riji を呼び出してサイト再構築 という結構カッコいいフローを組んでいて 、これがなかなか気に入っていた。以下のような点が良かった。 国内のVPSへのgitリポジトリへのpushはかなり早い GitHubへのpushに少し引っかかりを感じるレベル とはいえコンマ数秒程度の違

最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日本でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果

Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな

tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で

tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,

「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証

追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST

2020年1月5日追記: v1リリースしました https://songmu.jp/riji/entry/2020-01-05-ghq-v1.html https://github.com/motemen/ghq 最近のghqの状況と、v1リリースに向けた非互換変更などのアナウンスです。現状の最新のv0.17.4を前提に書きます。 ghq.<url>.root 設定により細やかにclone先を設定可能に 例えば、gitconfig上に以下のように設定すれば、デフォルトでは"~/src/hobby" に、仕事用は"~/src/work"にcloneされます。 [ghq] root = ~/src/hobby [ghq "https://github.com/myorg"] root = ~/src/work [ghq "https://myvcs.example.com"] root = ~

RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_

6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに本日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社