はてなブックマーク

2024年4月1日より id:moznion の所属が以下の通り変更となります。 旧: 株式会社ソラコム 新: ソフトバンク株式会社 (SB Intuitions株式会社出向) 以上となります。 引き続きよろしくお願い申し上げます。 ソラコムには大体6年半くらいいて、実際数えきれないほどたくさんのものを作り、たくさんのものを直し、たくさんのとりくみをしました。なおかつ最後の2年はUSのシアトル駐在で働いていたということもあり非常に貴重な体験となりました。あと在米中にCTO Technical Advisorという迫力のあるタイトルがついたりもしました。 僕がソラコムに入った日はちょうどKDDIがソラコムを買収した2017年9月1日で、そして先日2024年3月26日にソラコムがIPOを成し、ちょうどそのタイミングで退職するということとなり、つまり上場と共に去る男と相成りました。これはソラコム

GitHub Actionsで或るworkflowが終わったら別のworkflowを動かす、みたいなことをやりたくなった時にちまちまハマったのでメモとして残します。 workflow_run で呼び出されたworkflowで前workflowのステータスを取る これはハマったことというか「こうやれば良い」という話なんですが、 on: workflow_run: workflows: - check types: - completed jobs: ... みたいに書いておくと check workflowが完了した時にこのworkflowが呼び出されるのですが、この時 check の成否は関係無く呼び出されます。 従って、check が完了した時にのみ実行したい時には以下のようにステータスチェックを入れる必要があります。 on: workflow_run: workflows: - che

yapcjapan.org 2023年3月19日に開催されたYAPC::Kyoto 2023に参加してきました。もう2週間も前の話になるんですね......USに戻ってきてから色々あり、すっかりブログを書くのが遅くなってしまいました。 YAPC::Kyotoの様々な感想については「にゃんこ酒場.fm」で id:papix、id:karupanerura さんら運営の方々と喋ったPodcastが公開されているので是非お聴きくださいませ！ nyanco-sakaba-fm.hatenablog.com 面白かったトーク ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス id:tarao さんの発表。Fireworqが発表されたあたりって、スケーラビリティが高くなおかつ複数の言語から良い感じで使えるジョブキューのプロダクトについて「何使えば良いんだろうねえ」っ

たとえば 2023111 という日付が登場した時、これは 20230111 とも 20231101 とも解釈がされうるということです。 にわかには信じがたい出来事ですが太古のコードを眺めているとそういうことがあります。大変ですね。これが生きるということと言うこともできるはずです。まあ俺が書いたコードじゃないし...... というわけでひとまず被害状況としてどういう日付が影響を受けるかサクっと確認してみましょう。ふつうに手で検証してもわかる話ではありますが、今日は街に雪が降ったのと元のコードがRubyだったのでRubyで書いて確認しました。 #!/usr/bin/env ruby # coding: utf-8 require 'date' dict = {} d = Date.new(2023, 1, 1) for day in 0..364 yyyymd = (d + day).strf

YAPC::Kyoto 2023の採択トークが決まったようですね。面白そうなトークが沢山あってすごいですね。 blog.yapcjapan.org 僕のトークが採択されていない......というのはトリックで、今回は畏れ多くもゲストスピーカーとして招待されましたので、そちらの枠でお話しします。 blog.yapcjapan.org 何を話すかは実際まだ100%は固まってはいないのですが、仮決めとしては「ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す」というタイトルでお話できれば良いかなと思案しているところです。 技術的負債なのではなく、貧乏だから廃墟に住み続けているのだという正しい認識が必要— moznion (@moznion) November 29, 2022 つまりはこういうことです。どういうことだ？ それはそう

Microservicesのようなものを考えた際、Goで書かれたコンポーネントがHTTP(S)を使って他のコンポーネントと通信するという場合があると思います。 その「他のコンポーネント」がAWS NLBの配下にある時、GoのHTTPクライアントがTCPコネクションを使い回す場合があり、その状況においては特定のNLB配下のインスタンスにしかリクエストを割り振らない挙動をするという話題です。 NLB プロトコル、ソースIP、ソースポート、宛先IP、宛先ポート、そしてTCPシーケンス番号に基いてフローハッシュアルゴリズムを用いて割り振り先のインスタンスを選択するようになっています。 ref: For TCP traffic, the load balancer selects a target using a flow hash algorithm based on the protocol,

GoのIP Routing Tableの実装について調べてみたところ、だいたいOSのRouting Tableを操作する系のライブラリがヒットし *1、そうではなくユーザー側コードでRouting Table相当の実装・処理をしたい時に使えそうなライブラリがパッと見当たらなかったのでそれを書いたという次第です。 さて、GoでシンプルなRouting Table実装を書くのは実に簡単で、以下のように書くだけでほぼ期待通りに動くと思います。 type RouteEntry struct { Destination net.IPNet Gateway net.IP NwInterface string Metric int } routes := map[string]RouteEntry{} // ここでroutesにrouteを登録する // `target net.IP` がrouting

dependabotだとかrenovateだとかを使ってライブラリのバージョンアップのpull requestを自動的に送ってもらう、というような機構を利用されている方が多いと思います。 常にこれらのpull requestに目を光らせておいて常に取り込み続けるというのが理想的な形・そうあるべきだとは思うのですが、ふと気を抜くとバージョンアップのpull requestが溜まっていき、pull request自身も改訂に改訂を重ねている......みたいなことが起きがちではないでしょうか。 そういった折、誰も結果を見もしないCI (i.e. GitHub Actions) だけが回り続けているのを見て「このチェックは『ライブラリアップグレード業』をやる時に手動で回せばコンピューティングリソースの削減になるのでは？」と思い、それを試したという次第です。 この記事では例として、renovate

TL;DR zig ccを使うと色々と簡単、特にstatic linkをする場合はハマりにくく楽なので、使える場合は使うと良さそうです。 zig cc自体、gccやclangのdrop-in replacementを目的として出来たCコンパイラなので多くの場合はそのままポンと乗せ替えができそうですが、環境によっては色々な事情もあるでしょうし本記事ではgccを使う方法についても記します。 前提 zig init-libで吐き出されるコード (src/main.zig) を使います。 const std = @import("std"); const testing = std.testing; export fn add(a: i32, b: i32) i32 { return a + b; } test "basic add functionality" { try testing.exp

APIのリクエストにせよレスポンスにせよ、タイムスタンプを利用するというのはよくある話です。 この時、そのタイムスタンプのフォーマットをどうするのが良いのかという話題です。IDLを使って縛るというというのは良い考えだと思いますが、IDLを使うにせよフォーマットについては決めなくてはならないので。 1. 文字列を使う これあんま良くないと思うんですよね……というのも、とあるAPIを触っている時に「タイムスタンプはRFC3339です」というフィールドがあったんですけれどRFC3339ではないフォーマットで返却されたり受け入れられたりしたのであまり信用ができない…… まあフォーマットが不正というのは極端な例かもしれないですが、仮にフォーマットが不正だと多くの場合 strptime() や time.Parse() なんかの時刻文字列のparserが正しく動かず (良いケースだとエラーが上がる、悪

[追記] 実行中のシェルスクリプトをchattr(1)を使ってimmutableにするというのはどうか - その手の平は尻もつかめるさ 調べてみたけどこれが良さそう <a href="https://stackoverflow.com/a/3399850/1921216" target="_blank" rel="noopener nofollow">https://stackoverflow.com/a/3399850/1921216</a>2022/01/02 17:02 b.hatena.ne.jp このブックマークコメントで指摘されましたが、immutableにするまでもなくこのラッパースクリプトを噛ませると良さそう。 #!/bin/bash # usage: # sh-run.sh script-you-want-to-run.sh args... set -ue file="$

具体的に言うと、aws/[email protected]よりも前のバージョンでAWS Lambdaのcontainer image runtimeを使うとハンドラが呼び出されず、タイムアウトするまで刺さります。 例えば以下のような非常に簡単なLambda Functionをデプロイした時、 package main import ( "context" "fmt" "github.com/aws/aws-lambda-go/events" "github.com/aws/aws-lambda-go/lambda" ) func handler(ctx context.Context, event events.DynamoDBEvent) error { fmt.Println("CALLED") return nil } func main() { lambda.Start(h

こんにちは、株式会社ソラコムでソフトウェア等のエンジニアをやっているmoznionです。 普段ブログには書かない所属を宣言するのはなぜか。それはこれが株式会社ソラコム Advent Calendar 2021 17日目の記事だからです。というわけで記事が書かれます。 前日のアドベントカレンダー16日目は @0x6b さんによる soratun を改造して AWS Lambda から簡単に SORACOM Arc を使ってみました でした。そして本記事もSORACOM Arcの記事になります。連チャンしていて景気が良いですね。 表題の通り、SORACOM ArcをESP32のArduinoで動かすためのライブラリであるsoracom-arc-esp32-arduinoをご紹介します。 SORACOM Arcというサービスはザックリ説明すると「WireGuardを使ってデバイスとSORACOM

Go Genericsがどんなもんか試してみたかったので、これを使ってOptionの実装を書いてみました。 github.com 基本的な使い方としてはSynopsisを読んでもらえばわかると思いますが、ユーティリティとしては IsSome() IsNone() Take() TakeOr() TakeOrElse() Filter() Map() MapOr() Zip() ZipWith() Unzip() UnzipWith() あたりを取り揃えております。examplesも併せてご覧いただくとおおよその使い方の雰囲気が掴めると思います。 利用のためにはまだunstableな最新版 (go1.18) を使う必要があるので、gotipとかを使って新しい処理系を引っぱってくる必要があります。 で、GoのGenericsを使ってみた感想としてdefault valueとかconstrain

表題の通り、MySQLのJSON Data Typeの値に対しては、明示的なキャスト無しに BETWEEN, IN(), GREATEST() そして LEAST() を使ってはいけません。 MySQLむずかしい pic.twitter.com/YKoadLbaG2— すぎゃーん💯 (@sugyan) 2021年9月7日 本記事はこれに係る話題で、id:sugyan さんに Slack で相談を受けて「僕もそれハマったことあるな」と調べたところ以下のドキュメントに辿りつきました。 dev.mysql.com これはMySQL 8.0のJSON Data Typeに関するドキュメントですが、このドキュメントの Comparison and Ordering of JSON Values というセクションに The following comparison operators and fun

www.docker.com Docker Desktopがここ最近活発に開発されているというか、かなり見た目がオシャレになってきてて「ヤル気あるな〜」と思って眺めていたのですが、なるほど有料化するということなのですね。 Docker Desktop remains free for personal use, education, non-commercial open source projects, and small businesses (fewer than 250 employees AND less than $10M USD in annual revenue). Commercial use of Docker Desktop in larger enterprises (more than 250 employees OR more than $10 million

2021年の記事とは思えないタイトルですが、そのようにしたのです。 特定のメールサービスが提供するメールアドレスに依存していると、そのメールサービスからBANされた際に人権を維持できない可能性があります。というのも仮にメールアドレスが凍結すると、そのアドレスをアカウントのidentifierとして登録しているサービスを巻き込んでしまい大惨事が起きてしまいます。 プレッパーじみた危機意識ではありますが、そのような気持ちになったのでこのたび独自ドメインでメールアドレスを払い出し、それを使うようにしてみました。 しかし自前でpostfixを運用する……みたいなことは断固やりたくなかったので、今回はさくらのメールボックスを利用して、元々保有していたドメインのサブドメインを使ったメールアドレスを払い出し、そこに送られてくる全てのメールをGmailへと転送するという構成を取りました。 メールボックスに

こんにちは。id:moznionと申します。Hachioji.pmというIT技術コミュニティに所属しています。 本記事はPerl Advent Calendar 2020の記事として記述されています。前日の記事は@mihyaeru21さんのGitHub Actions で Perl を動かすときのテンプレートでした。 Hachioji.pmという名前からわかるように、ここは元来はPerlを書く人が多かったコミュニティなのですが、時代の推移によりPerlを書く人は徐々に少なくなりつつあります。かく言う私自身も、かつてはPerlでそこそこ大規模なWebアプリケーションを書いて糊口を凌いでいましたが、ここ最近は仕事で (というかそこそこ規模の大きなコードを) Perlを書いたことは久しくありません。 Perl Advent Calendarなのになにを突然不敬なことを言い出すのかという感じですが

An English article is here: https://dev.to/moznion/released-radius-rs-2e1o タイトルの通り、AAA (Authentication, Authorization and Accounting) のためのデファクト・スタンダードなプロトコルであるところのRADIUSのサーバー・クライアント実装をRustで書きました。 github.com また、crates.io にもpublishしてあります: https://crates.io/crates/radius このRADIUS実装の特徴としてはtokioを使用することで非同期 (async/await) ネイティヴな実装になっていることが挙げられます。 また、RADIUSのgolang実装であるところのlayeh/radiusを参考にして、FreeRADIUSのdic

ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

pprof って go のやつでしょ？　node のプロファイルが取れるわけ無いやろ，と僕も思っていたんですが以下のライブラリを使うことで取れることがわかりました． github.com 使い方については Using the Profiler に書いてあるとおりで，アプリケーション側に const profile = await pprof.time.profile({ durationMillis: 10000, // time in milliseconds for which to // collect profile. }); const buf = await pprof.encode(profile); fs.writeFile('wall.pb.gz', buf, (err) => { if (err) throw err; }); という風に書いてあげるとwall time

github.com 今日 (2020-09-24) の時点では「ローカル環境」で動かす方法については記載がある一方で，何らかのリモートの環境に「本番」っぽく動かす方法についての記載が無いので，それを AWS 上に構築するためのメモを記します． 競技用 application のデプロイ isucon.net これを見る限り，参加者側の環境は以下の通り: アリババクラウドさんの ecs.sn1ne.large を採用しました。 CPUは2コア (Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz)、メモリは4GBの、オーバーコミットのないインスタンスです。ネットワーク帯域も100Mbpsです。 ただし、今回のアプリケーションではメモリに全ての切らない環境を再現するために、Linuxにはメモリを1GBしか認識させていません。CPUは2コアで、メモリ1GBの環境

かつて Kyoto.なんか #4 で発表した話題ですけれども: moznion.hatenadiary.com これはもうやってません！！！（正確に言うと運用している組織内ではリタイアメントの段階に入っています） 今はCodeBuildを単体で使っています． かつての AWS CodeBuild は ビルド結果の通知が貧弱 Trigger が貧弱 (pull-requestに引っ掛けてビルドタスクを回す，みたいな機能が微妙だった) ビルド履歴の一覧性が貧弱 という感じだったので，その不便さを補うために Jenkins を挟んで運用していましたが，今やこれらのペインポイントはほぼ解決しており*1 CodeBuild を単体で使っても充分に快適な開発体験が得られます． むしろ今となっては Jenkins という部品を間に挟んでしまうとシステムの複雑度が上がってとっつきにくくなってしまいますし，

English article is here: Released go-json-ice: a code generator of JSON marshaler for tinygo - moznion's tech blog tinygo では encoding/json を import するとコンパイルできなくなるという問題があり *1，なんらかの struct を JSON に marshal したい時に使える de facto な方法が無いように見えました．これに関しては例えば以下のような issue が立っています: github.com github.com つまり tinygo 上で任意の struct を JSON にしたい時は「手で気を付けてシリアル化する」しか方法がなかったわけですが，まあそれだと何かと不便だったので表題の通り json-ice という encodi