独自ドメインのメールアドレスを使うようにした - その手の平は尻もつかめるさ
2021年の記事とは思えないタイトルですが、そのようにしたのです。 特定のメールサービスが提供するメールアドレスに依存していると、そのメールサービスからBANされた際に人権を維持できない可能性があります。というのも仮にメールアドレスが凍結すると、そのアドレスをアカウントのidentifierとして登録しているサービスを巻き込んでしまい大惨事が起きてしまいます。 プレッパーじみた危機意識ではありますが、そのような気持ちになったのでこのたび独自ドメインでメールアドレスを払い出し、それを使うようにしてみました。 しかし自前でpostfixを運用する……みたいなことは断固やりたくなかったので、今回はさくらのメールボックスを利用して、元々保有していたドメインのサブドメインを使ったメールアドレスを払い出し、そこに送られてくる全てのメールをGmailへと転送するという構成を取りました。 メールボックスに
特定のユーザーのイベントによるGitHub ActionsのActionを保留状態にしておき、後で手動実行できるようにする - その手の平は尻もつかめるさ
dependabotだとかrenovateだとかを使ってライブラリのバージョンアップのpull requestを自動的に送ってもらう、というような機構を利用されている方が多いと思います。 常にこれらのpull requestに目を光らせておいて常に取り込み続けるというのが理想的な形・そうあるべきだとは思うのですが、ふと気を抜くとバージョンアップのpull requestが溜まっていき、pull request自身も改訂に改訂を重ねている......みたいなことが起きがちではないでしょうか。 そういった折、誰も結果を見もしないCI (i.e. GitHub Actions) だけが回り続けているのを見て「このチェックは『ライブラリアップグレード業』をやる時に手動で回せばコンピューティングリソースの削減になるのでは？」と思い、それを試したという次第です。 この記事では例として、renovate
API越しでタイムスタンプをやりとりする時のフォーマットをどうするべきか - その手の平は尻もつかめるさ
APIのリクエストにせよレスポンスにせよ、タイムスタンプを利用するというのはよくある話です。 この時、そのタイムスタンプのフォーマットをどうするのが良いのかという話題です。IDLを使って縛るというというのは良い考えだと思いますが、IDLを使うにせよフォーマットについては決めなくてはならないので。 1. 文字列を使う これあんま良くないと思うんですよね……というのも、とあるAPIを触っている時に「タイムスタンプはRFC3339です」というフィールドがあったんですけれどRFC3339ではないフォーマットで返却されたり受け入れられたりしたのであまり信用ができない…… まあフォーマットが不正というのは極端な例かもしれないですが、仮にフォーマットが不正だと多くの場合 strptime() や time.Parse() なんかの時刻文字列のparserが正しく動かず (良いケースだとエラーが上がる、悪
古いaws/aws-lambda-goでAWS Lambdaのcontainer image runtimeを使うと刺さる - その手の平は尻もつかめるさ
具体的に言うと、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
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
管理画面まわりの事情，負の UI/UX について - その手の平は尻もつかめるさ
管理画面を作ってると，「みだりに押されたくはないが，かといって無いと不便」みたいなボタン (或いはそれ以外の何か) を画面上に置きたくなる時があると思う． 例えばバッチで行うような処理を (なんらかの事情で) 即時実行するボタンのようなやつ．こういったボタンは便利だけれど，無闇に押されるとシステムに対する負荷が上がり，サービスの提供に悪影響を及ぼす場合があるのでなるべく押しにくくあるべきだと思う． そういった，おもてなしを目的とはせず，むしろ或る操作に対する敷居を高くするための，謂わば負の UI・負の UX をどうするべきかを軽く考えたのでここに記す． 警告を出す 例えばこの画像のような感じ． こうして注意を喚起することで精神に注意を促すくことで，みだりな利用を抑制するという方法．ボタンを赤くすることで危険な処理であることも表している． 加えてボタンが押された時に念を押すための confi
Servlet 3.0 から導入された multipart 関連の処理を Tomcat で有効にする術について - その手の平は尻もつかめるさ
servlet 3.0 の multipart 関連処理を有効にする方法 - blog.64p.org これの関連なんですが． こういう設定をしておかないと，HttpServletRequest#getPart() や HttpServletRequest#getParts() が null を返してきてマジ意味わからん！！！！ みたいな感じのキレるが発生いたします． ところで，Tomcat で multipart 関連の処理を有効にする方法としては 1. web.xml に設定を書く 2. Servlet クラスに対して @MultipartConfig アノテーションで設定する 3. context.xml か Tomcat/conf/server.xml に設定を書く の3つがあるようです． 1の方法は上のtokuhiromさんのエントリにあるように書いてやれば良いです． <serv
情報共有システム (Wiki みたいなやつ) に求めること - その手の平は尻もつかめるさ
いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて，気に食わないところを twitter にガーッと書いたんだけど，さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので，僕の思う情報共有システムに求めることをここでまとめておくことにする． エディタが腐ってない これは本当に重要で，エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし，起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある．さもなくば Wiki は廃墟と化す． WYSIWYG なエディタを利用するのは難しいと思っていて，本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) の
Javaで空いているポート番号を取ってきたい - その手の平は尻もつかめるさ
Javaで空いてるポート番号取ってきたかったんで，以下のように書いたらポート番号取れて便利でした． int port; try (Socket socket = new Socket()) { socket.bind(null); port = socket.getLocalPort(); } ドキュメントによると，Socket#bind()の引数にnullを渡すと「アドレスがnullの場合は、システムにより一時的なポートと有効なローカル・アドレスが選択されてソケットがバインドされます」とのことなので，それを使ってbindしてポート番号を取得してからそのSocketをcloseすればそのポートが空くので空きポートが取れる，という寸法です． try-with-resources使うとcloseのし忘れとかが無くなって便利ですね，便利！ [追記] @moznion https://t.co/C
Goでforkしたいとかgoroutine IDが欲しいとか言わない - その手の平は尻もつかめるさ
golangでforkってどうやるんだ— 単位落としました (@moznion) 2014, 9月 14 @moznion できねぇよ— Daisuke Maki (@lestrrat) 2014, 9月 14 @moznion 外部プロセスの起動、ならできる。— Daisuke Maki (@lestrrat) 2014, 9月 14 @moznion でもforkしたい、という考え（設計）を改めるのが先です。— Daisuke Maki (@lestrrat) 2014, 9月 14 @lestrrat なんということだ……— 単位落としました (@moznion) 2014, 9月 14 forkはできないとのこと— 単位落としました (@moznion) 2014, 9月 14 考えを改めている— 単位落としました (@moznion) 2014, 9月 14 特定のgorouti
ページャNight 1ページ目という勉強会やりました - その手の平は尻もつかめるさ
そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前
「UNIXという考え方」を読んだ - その手の平は尻もつかめるさ
「UNIXという考え方」をAmazonのwish listに入れていたらid:kenjiskywalkerさんが贈ってくださったので読みました．お陰でUNIXという考え方を学べました．ありがとうございます！ 本書では一貫して「プログラムを小さく作る」という事と「1つのプログラムには単一のことだけを上手くやらせる」という事について言及されています． プログラムを小さく作るということによって，そのプログラムはコンピュータのリソースに対して優しくなり，なおかつ巨大なプログラムと比較して人間が理解するのが簡単になるので保守がしやすくなり，かつ他の部品と組み合わせやすくなるという論旨です． プログラムを小さく作ると，必然的にそのプログラムは多くの責務を負えなくなる為，自然とプログラムは単一の機能のみを持つようになります．従ってこれら2つの考え方は対になっていると言えるでしょう． 本書で言われている「
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本語で DDD について雑に話せる Slack チームができたぞ！！！！ - その手の平は尻もつかめるさ