GitHub Actionsのmatrixを動的に生成してGoの最新安定バージョンでテストする | おそらくはそれさえも平凡な日々
Goのライブラリを提供している場合、Goの最新の安定バージョンでテストしたくなることがあるでしょう。具体的にはマイナーバージョンの直近2バージョン、今だと1.18と1.17です。GitHub Actions定義への記述は以下のようになるでしょう。 jobs: test: runs-on: ubuntu-latest strategy: matrix: go-version: ['1.17', '1.18'] steps: - uses: actions/setup-go@v3 with: go-version: ${{ matrix.go-version }} - run: go test ./... しかしこのようにベタに書いてしまうと、Goのバージョンが上がったときにチマチマ上げるのが地味にめんどくさい。なのでこれを動的に生成したい。 これは事前にGoの安定バージョン一覧を取得するjo
YAPC::Japan::Onlineのキーノートで「変化し続けるキャリアと変わらない原体験」という話をしました | おそらくはそれさえも平凡な日々
少し前なのですが、光栄なことにYAPC::Japan::Onlineでキーノートを担当させてもらい「変化し続けるキャリアと変わらない原体験」というタイトルでお話をさせてもらってきました。資料は単体としては粗があるのですが公開してしまいます。 https://junkyard.song.mu/slides/yapc-japan-online-2022/#0 自分のキャリアや行動原理を見直す良い機会にもなり、良い機会をいただけてありがたく思っています。ブラッシュアップして少し別の角度から別のイベントでお話したり、文章に起こしたりできると良いな、とも思っています。 ちなみに、開催数日前にブースターショットを打っていたにも関わらず、その直後にコロナに罹って寝込んでしまい、その関係もあってずるずると公開が伸びてしまいました。 今回はオンライン開催で、Discordの使い方など工夫が見られてよかったで
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
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のルート証明書のチェーンの証明書も指定すれば今で
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
Nature Remo作ってる会社のCTOになったのでみんな買ってくれよな！ | おそらくはそれさえも平凡な日々
6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに本日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社
Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい
`ghg` で GitHub Releasesから適切な実行ファイルを統一的に取得する | おそらくはそれさえも平凡な日々
https://github.com/Songmu/ghg tl;dr % ghg get motemen/ghq とかやれば、GitHub Releasesに上がった最新の実行ファイルを取得できる。 % $(ghg bin)/ghq とかで実行可能。 $(ghg bin) を $PATH に追加してもよい。 % ghg get Songmu/ghch@v0.0.1 とかでバージョン指定も可能。 本文 Goで書いたツールを提供する場合、クロスビルドしたものを GitHub Releasesに上げるのが定番となっています。 なぜ、 go get ではないのかというと go get の場合以下のような問題があるからです。 go get するにはGoの環境が必要 安定版ではなく、開発中の最新をビルドしてしまう ビルド情報などをバイナリに埋め込めない ただし、GitHub Releasesに上げる
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々
リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per
ISUCON5で優勝してきました | おそらくはそれさえも平凡な日々
毎回素晴らしいイベントを主催されているLINE株式会社様、毎回ホスピタリティあふれる運営に尽力されている@941さん、出題の@tagomorisさん@kamipoさん、その他協賛企業や運営スタッフの皆様に感謝申し上げます。 ということで、ISUCON5に出場し、優勝してきました。 ISUCON1の優勝チームの再結成で @fujwiara, @sugyanと僕というメンバー構成です。4年前のISUCON1の時にチーム名を「fujiwara組にしよう」と強く言ったのは実は僕で、そのまま僕が代表者として申し込んだのですが、まさかここまでfujiwara組ブランド(?)が定着するとは思いませんでした。今年もfujiwaraさんの力が大きい勝利ですが、僕も大分貢献できたと思います。 ということで当日を振り返ります。 お題 外部APIを叩くネタで驚いた。可能性は考えていましたが、まさか来るとは思ってい
#ISUCON 5の予選をトップ通過してきました | おそらくはそれさえも平凡な日々
雑に稼ぐにはPerlはサイコーだぜ tokuhirom 主催のLINE様、毎年ありがとうございます。GCP使いやすかったです、Google様もありがとうございました。 さて、いつもながらfujiwaraさんと組んで1位を取ると、つい自分がすごいと錯覚してしまいそうになるのですが、すごいのはfujiwawaさんであって「僕ではない」ということを強く意識しないといけない。 とはいえ、久しぶりにfujiwaraさんと組んで、自分がどれくらい戦えるのか楽しみだったのですが、以前優勝させてもらった時よりも自分としては大きな手応えがあり、僕もfujiwaraさんと組ませてもらって恥ずかしくないくらいの実力はあるなと思いました。 今年のISUCON予選は、とにかくやることが尽きず、ずっと手を動かしながら改善を続けられる楽しさがあって、疲れましたが充実した時間を過ごすことができました。最近仕事でコード書く
YAPC::Asia 2015に行ってきた | おそらくはそれさえも平凡な日々
スタッフの皆様お疲れ様でした。本当にありがとうございました。 最近妙に忙しいというか色々あって、直前まで頭がYAPCモードに切り替わらなくて「こんなことで最後のYAPCを楽しめるのか」とか変な心配もしてたんだけど、行ってみたら最高でした。ベストトーク賞を獲得したhitode909くん風に言うと「最高」。 登壇した 発表資料:Mackerel開発におけるScalaとGo、そしてPerl 朝の電車の中で発表資料を見返していたら、つながりがおかしいとことか書き足したいところとか見つかって会場ついてから発表開始ギリギリまで資料を修正してたら逆に緊張せずに話せてよかった。 2日目朝イチで強豪揃いの枠とはいえ、僕は一番小さい部屋だったので気楽にやろうとか思ってたら、満員御礼で立ち見が出るほど来ていただいて本当にありがたかった。トークの反応も概ね好評だったようで何よりです。 伝説に残るであろうYAPC:
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
ISUCON4ダメでした | おそらくはそれさえも平凡な日々
まずは、ISUCON4の主催・協賛・運営の皆様、素晴らしいイベントをありがとうございました。 ISUCON4ダメでした。こんな悔しく終わると思ってなかった。一応予選通過してそれなりに手応えがあったので、本戦もそれなりに健闘して戦えるのではないかと思ってたけど、その辺完全に甘くて、本戦に出られたちょっとした喜びも吹き飛びました。競技に溺れて本来のサービス運用者視点が抜け落ちていた事に反省しきりです。 何をやったかは、motemenのエントリに書いてありますが、最初にRedisを1台に固めてログの書き込みをRedisのリストにしたのがそれなりに効いたくらいですかね。多分最初に8000点超えをして暫定トップを取ったと思います。ここがクライマックスでここから全く改善しなかった。 Redisはレプリケーション構成にしようかとか@y_uukiに言われたし、他のチームのレポートを見てもそうしていたところ
ISUCON4予選でリモート体制で正攻法で4万2千点くらい出してきました | おそらくはそれさえも平凡な日々
タイトルのとおりです。最後は少しmemcachedを入れたりしましたが、それはそこまで効果はなかったので、PerlとNginxとMySQLだけの構成で4万点くらい出せたってことで、それなりの結果かと思っています。ただ、なんかレベルが上がり過ぎてて、予選通過が微妙ってことで社会は厳しい。 チームは元々、@sugyanと@typesterと「元fujiwara組」ってことで出ようかと思ってたんだけど、なんだかんだで実現せず、じゃあ、折角だからはてなの人と組もうと思い、id:motemenとid:wtatsuruと出場するつもりでした。しかし、wtatsuru先生がAWSのリブート祭りのために参加できなくなってしまったので、優秀な若手であるid:y_uukiをインフラ担当ということで入ってもらうことにした。 全員Mackerelに関わっているので、「マカレラーズ」というチーム名にした。結果として
お手軽InnoDBウォームアップを実現するMySQL::Warmerの話をGotanda.pm #2 でしてきました | おそらくはそれさえも平凡な日々
発表資料 Gotanda.pm #2 でMySQL::Warmerというモジュールの紹介をしたのですが、それをCPANizeしたのでエントリを書いています。 % cpanm MySQL::Warmer とすると、mysql-warmupというコマンドがインストールされ以下のようなコマンドを打つとウォームアップクエリがダラっと発行されます。--dry-runもあり、その場合、発行されるクエリが標準出力されます。 % mysql-warmup mydatabase -h db.example.com -u dbuser -p サービス投入前のDBのデータをメモリに乗っけてやるのに有用でしょう。 ウォームアップ戦略はkazuhoさんのMySQL のウォームアップ (InnoDB編)に基づいていますが一部適当です。突っ込みどころがあれば指摘いただければと思います。 ISUCONでも再起動かかった直
「エンジニアならリモートワークは簡単だ」と思ってはいけない | おそらくはそれさえも平凡な日々
「強いチームはオフィスを捨てる」を読んだ。「小さなチーム、大きな仕事」でもそうだったが、 とにかくやって見ろ。やれば分かるさ やらない理由がない というふうにガンガン煽っていくスタイルが小気味良い。 とは言えしっかりリモートワークのリスクについても述べられていて、リモートワークは難しいなと思わせる内容でもあった。特に、メンタル面を含めた健康リスクに関しては相当気を使わないといけないように感じた。 リモートワークを実現する上で大事なポイント 個人的に大事だと思ったのが以下の2点。 信頼 自由と規律 相手をとにかく信頼して、自由と裁量を与える。 信頼された側は信頼に応えようとする。ただ、自由を与えられた場合に上手くいかないことがある。そこで、決まりをお仕着せてしまうのではなくて、本人が規律を決めるようにする、それまで待つのが大事なのだろう、と感じた。 例えば、始業時間は会社が決めるのではなく、
今年のYAPC::Asia Tokyo #yapcasia | おそらくはそれさえも平凡な日々
今年も楽しかった。楽しみすぎて疲れました。運営の皆様、関係者の皆様、ありがとうございました。 2009年から6年連続参加。スピーカーは3年連続なので、半分はスピーカーとして参加させてもらっていることになります。 今年は発表の他にライブコーディングもさせてもらいました。発表資料は以下。 ライブコーディング〜Ya Perl for Perl Mongers (YAPCに来た人は皆Perl Mongerでは？) ライブコーディングは思ってた以上に人が集まってびっくりしました。ありがとうございました。 トークを聞きに来て下さった方もありがとうございました。 今年は折角メインホールを割り当ててもらったので、ベストスピーカー賞を狙っていたのですが、着にからめず残念です。受賞された皆様、おめでとうございました。 とは言え「ベストスピーカーの投票お願いします」と自信を持って言えたのは今年が初めてだったかな
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
