はてなブックマーク

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/aws-lambda-go@v1.18.0よりも前のバージョンで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

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なのになにを突然不敬なことを言い出すのかという感じですが

ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 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

maedama.hatenablog.com trapezoid.hatenablog.com 上記のブログには今から6年ほど前の当時の情報が記されていますが，Redis 4.0 RC3 以降の Slave (replica) の Expire は信用して良くなっているようです． Redis の公式ドキュメント (Replication – Redis) を参照すると， However note that writable replicas before version 4.0 were incapable of expiring keys with a time to live set. This means that if you use EXPIRE or other commands that set a maximum TTL for a key, the key will le

github.com 表題の通りリリースいたしました． これはなに Zabbix internal checks と呼ばれる Zabbix プロセスの状態を表現するメトリクスを定期的に収集し，Prometheus のメトリクスフォーマット (i.e. OpenMetrics) で export する Prometheus exporter です．愉快ですね．皆さんも愉快に思っていただけると嬉しいです． どんなときに使うの OpenMetrics を理解できる監視コンポーネントで Zabbix を監視する時 生きていると色々ありますね． 以上です，よろしくお願いします．最近の prometheus/client_golang はめちゃめちゃ便利で良いですね． よォZabbix……テメェは今まで自分が「監視する側」だと思って良い気になってたかもしれねェがよォ……これからはテメェも「監視される側

Javaの話題です． jackson-databind を使って JSON のデシリアライズを行っていて，数値を int にマッピングしている場合，その値が int (32bit) の取りうる値を超えた時の挙動が「バージョンによって異なって」います． 以下に挙げる挙動は 2.9.3 から 2.9.4 へのアップグレードで変更されています． jackson-databind-2.9.3 を利用している場合，値が int の範囲を超過するとその値を int にキャストしたもの *1 にデシリアライズされます． コード: https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.9.3/src/main/java/com/fasterxml/jackson/databind/util/TokenBuffer.jav

Raspberry Pi を Read-Only Root-FS にしておくと急にマシンがダウンした時でもファイルシステムが破損しにくくなります． もちろん書き込み内容は永続化されなくなりますが (書き込み内容は tmpfs にストアされるので rebootで揮発する)，得てして電プチなどの乱暴なオペレーションに晒されがちな Raspberry Pi にはそういった保護機構を入れておくと何かと良いことがあるかと思います． というわけでコレを使います: github.com この repository にあるツールを利用することで，Raspberry Pi をお手軽に Read-Only Root-FS にすることが可能です． 内部的には OverlayFS を利用しており，Write アクセスについては tmpfs に対して操作し， Read アクセスについては SD カードの Read-

要旨 どうやれば Zabbix API を使って所望の機能を実現できるかを調査する際には Zabbix が実際に呼んでいる SQL クエリを tcpdump で抜き出すと手っ取り早い． 内容 色々あってZabbixを使っているわけですが，この手のものを使っているとAPIを介して Active なアラート (Zabbixでいうとproblem) を取りたくなります． というわけで，Zabbix 4系でそれをやるにはどうしたら良いかということについて記すものです． problem.get [Zabbix Documentation 4.4] さてまずドキュメントを漁っていて使えそうに思えるのはこの辺でしょう． This method is for retrieving unresolved problems. などとそれっぽいことも書いています……がこのAPIだけ使っても駄目．なぜか Reso

github.com 書いたと言っても書いたのは3ヶ月近く前でした．リリース告知をしていないことに気づき，本記事にしている次第です。 何をやるツールかというと，以下の記事に書かれていることをいい感じにやるツールでして， aws.amazon.com 1. Userの accessKeyID, secretAccessKey および mfaSerial (MFA device ARN) を使って、STSのセッショントークンを取ってくる (これらの情報は初回実行時に設定可能で，rcファイルに保存される) 2. 取ってきたセッショントークンをAWSのcredfentialsファイルに適用する (適用せずにトークンだけ取ってくることもできる) というような動きをします．自動でcredentialsファイルを変更するというのがキーポイントですね．AWSのcredentialsファイルは通常のiniフ

github.com 表題の通りです．出オチのような名前です． 使い方やどういう挙動をするかという話題についてはREADME.mdのSynopsisをご覧いただければと思います．Javaのlombokをご存知の方はlombokの@Valueのような挙動をする，と言えばイメージしやすいでしょう． 基本的にはgo:generateと組み合わせて使うことになるだろうと思います． モチベーションとしてはREADME.mdのMotivationにも書きましたが，ザックリ言うと以下のような感じです: Structのフィールドをprivateかつimmutableに取り扱いたいことが多い フィールド (ないしはstruct) をimmutableに保つことについて，goでは基本的に「気をつける」しかないが，その際にはフィールドはprivateであるほうが嬉しい フィールドを破壊的に変更できる存在が絞られ

（TypeScriptに限らずJavaScriptでもだいたいこのような感じだと思いますが） 例えば以下のようなコードを書くと，出力としては {"body":{}} が得られます． const body = new Map<string, string>().set("foo", "bar"); console.log(JSON.stringify({body})); 本当は {"body": {"foo": "bar"}} のような構造がほしいところにこれでは困るわけですね． そこでどうするかと言うと Object.fromEntries() を利用すると良い: developer.mozilla.org 2019年11月現在だと比較的新しい機能ですね． const body = new Map<string, string>().set("foo", "bar"); console.l

技術書典7，SORAZINE技術組（く39D）*1 にて「ATコマンドかるた」を頒布いたします． techbookfest.org 「ATコマンドとはなにか？」という疑問については同時に頒布される SORAZINE 技術組 Vol.2019F 中の，おそらく今のところ日本で最も詳しいATコマンドの解説文章をご覧いただければと思いますが *2，その文中から抜粋しますと， AT コマンドは AT という文字列で始まる、モデムを制御したりするためのテキストベースのコマンド群です． というものです．ホラ，皆さん生きているとAT+COPSとかAT+CGDCONTとかよく見たり喋ったりするじゃないですか？　ソレのかるたを頒布するという話です． こんな感じ: これがATコマンドふだで…… これが機能ふだです． たのしい48種類のATコマンドのふだをご用意してございます！ (なお，コマンドふだと機能ふだは

表題の通りKyoto.なんか #5で話してきました．もうかれこれ3週くらい前の話なのですね……筆不精がたたっております． kyoto-nanka.connpass.com 内容としてはここ数年ElasticsearchをAWS上で運用しているのでそのアーキテクチャのご紹介という感じの発表をしたという次第です．現状上手いこと回っております． この発表の後にElasticの@johtaniさんからのメンションで，クラスタまたぎのレプリケーションがElasticsearch 6.7以降サポートされていることを教えていただきました．ありがとうございます！ 一応補足。6.7から有償機能だけど、クラスターまたいだレプリケーションあるんです。Elastic Cloudで使えたかはパッとは出てこないけど、、、 https://t.co/89om47nkSF— Jun Ohtani (@johtani) A

アプリケーションの設定ファイルと言えばjsonやyamlなんかで書くことが多いと思うんですが，最近はTypeScriptで設定ファイルを書いております．このような感じ: export interface ApplicationConfig { readonly listenPort: number; readonly timeout: number; readonly apiBaseUrl: string; readonly loggerOptions: LoggerOptions; } こういう感じで設定のinterfaceを定義しておいて export class ProductionConfig implements ApplicationConfig { readonly listenPort = 5963; readonly timeout = 5000; readonly ap