Talked at CloudNative Days Tokyo 2020 #CNDT2020. Video available at https://event.cloudnativedays.jp/cndt2020/talks/30
こまけぇ話は置いておいて、BearerとSender-Constrainedの話がHTTP Cookieのところでも出てきたよというお話なのですが、ここを少し補足します。このBearer vs Sender-Constrainedという用語が一番出てくるのがOAuthの文脈です。 文字で読みたい2分間OAuth講座 : (1) The Basic Concepts (2) Bearer and Sender Constrained Tokens - r-weblife Bearer Token : 第1回で説明した地下鉄の切符のようなトークン。所持していれば使えるので、他の人が拾っても使えます。 Sender Constrained Token : 利用者を制限するトークン。飛行機の搭乗券のように、利用者が指定されている、制限されているもの。 概念はこんな感じですが、実装方法は色々なものが
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
TL;DR Goのerrorは外部エラーを表現するもので、利用者(ライブラリならアプリケーション開発者、アプリケーションならユーザー)に入力値や環境の不備を伝える目的で存在している 一方で、開発中のソフトウェアが思っていたのと違う挙動を示した場合、その調査にはソフトウェアの特性によって異なるツールを使い分ける必要があり、一筋縄では行かない 両者を分けて考えることで、よりよいエラーハンドリングへの議論が初めて進められると考える 背景 Goのerrorがスタックトレースを含まないことは度々Goの欠点として挙げられます。たしかに、一度作ってどこかにデプロイしたソフトウェアがバグっており、スタックトレースがないせいでその原因調査に手間取ったことは筆者も一度のみならず体験しています。 一方で、(しばしばベテランのプログラマから)エラーはノイズを含むべきではないと主張されることも少なくありません。 2
こんにちは、SWETのCI/CDチームに所属している幸田(@ponkio_o)です。 2024/03/26(火)に弊社オフィス(渋谷スクランブルスクア)とオンラインのハイブリッドで CI/CD Test Night #7 を開催しました。 本記事では、当日の発表スライドを紹介していきます。 参加者の反応 当日の様子はTogetterにまとめを作成しているので こちら からご覧いただけます! 当日の動画 YouTubeにて当日のアーカイブ動画を公開しています。 www.youtube.com 発表紹介 @ponkio_o「業務で役立つ…かもしれない?!GitHub Actions Tips 集」 最初の発表は私の「業務で役立つ…かもしれない?!GitHub Actions Tips集」でした。 speakerdeck.com GitHubとの相性がよく、便利なGitHub Actionsです
今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し
はじめにシステムの状態を的確に捉え、運用に必要なインサイトを継続的に得るための特性は「オブザーバビリティ」と呼ばれます。オブザーバビリティを実現することで、パフォーマンスのモニタリングやトラブルシューティングを効果的に行い、システムの信頼性を高めることができます。 この重要な特性を実現する上で、eBPFやbpftraceは強力なツールとなります。 本記事では、Goアプリケーションにおけるオブザーバビリティを実現するための一つの方法として、bpftraceを用いたトレースの手法を紹介します。 内容が多いため、目次を活用して段階的に読み進めることをお勧めします。 eBPFとbpftraceはじめに、eBPFとbpftraceについて簡単に説明します。 eBPFとはeBPF(Extended Berkeley Packet Filter)はLinuxカーネル内で動作する柔軟なプログラミングフレー
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
https://www.drumato.com/ja/posts/validating-admission-policy/ で触れたように、 google/celはシンプルで汎用性を持った言語仕様を持っており、 新しくなにかソフトウェアを作るときに、設定ファイルのインタフェースとしてとても良いのではないかと感じた。 今回はこのgoogle/celの仕様をもとに実装された https://github.com/google/cel-go を使い、 簡単なサンプルを動かしてみることにする。 1 本題ここでは、以下のようなJSONファイルに対してCELの条件式を記述し、 Goプログラム内でコンパイル、評価してtrueかfalseを出力する、ということをやってみる。 { "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "na
Go-MySQL-DriverでカスタムのDialをサポートしていたり圧縮プロトコルサポートのコードをレビューしていたりして、利用している Write() の実装が多様化してきたので、「Write(p)って Read(p)みたいに n が len(p) より小さい場合にループで続きを書き込まなくてい良いのは決まりがあったっけ?」と気になって確認してみました。 まず、 net.Conn の定義ではReadとWriteは次のようになっています。 // https://pkg.go.dev/net#Conn type Conn interface { // Read reads data from the connection. // Read can be made to time out and return an error after a fixed // time limit; see
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
DALL-Eより: Imagine a scene where the abstract concepts of Ruby programming and property-based testing blend harmoniously. Picture a large, glowing ruby crystal まいどお馴染み、作ってみたシリーズです。 今回は、RaaP(ラープ)というツールを作りました。RBS as a PropertyでRaaPです。 github.com RaaPはテスティングツールの一種で、RBSをそのままテストコードにみたてて実行してくれるツールです。 次のようなRBSがあったとして class Foo end class Bar def initialize: (foo: Foo) -> void def f2s: (Float) -> String end
2024-03-21 Findy TechBrew in 東京 https://findy.connpass.com/event/310772/
3/7〜9に中野セントラルパークカンファレンスで開催されたPHPerKaigi 2024に昨年から引き続きコアスタッフとして参加しました。 PHPerKaigi、楽しかった!!! 事前準備 パンフレット 機材レンタル スタッフブログ 動画チェック 当日 day0 (3/7) day1 (3/8) day2 (3/9) まとめ 事前準備 パンフレット PHPerKaigiでは参加者向けに配送するノベルティボックスにタイムテーブルやスポンサー紹介記事、寄稿者の方による技術記事などを載せたパンフレットを封入しており、今年もパンフの制作を担当しました。 デザイナーさんに依頼するのがギリギリになってしまったので、もう少し余裕を持って進めれば良かったなと反省しています。 PHPerKaigi 2023にコアスタッフとして參加しました - muno_92の日記 という昨年の反省を活かし、早めに動き始めた
こういうツイートを見た。 少し違う話だけど、 目に見えるものすぐ口に出す私もこれにうんうんと頷きつつ、逆に「今日の富士山はキレイだね」と隣で言われると一言目に「そうだね」を返せない。 「今日の富士山綺麗だね」 「どこが?」←これで反感買う。 私の予想する相手の答え例「雲が無くてハッキリ見えてる所が」 https://t.co/Q2BlshhAxZ— ふーてん丸 (@huutenenigma) 2024年3月15日 kwsk ってインターネットスラングの中では珍しく敵意の無いものだったんだな。 https://t.co/m7FCoezS9X— すあま (@suama13) 2024年3月15日 思考の過程を掘り下げたくて理由を聞く、というのはわりとよくあるコミュニケーション様式である。日常でもよく使うし、仕事では実際にそれを聞くのが大事なので、もっと使う(それはそうと、あくまでつねにニコニコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く