お金、それも給料の話は、あさましい、ということになっている。婚活パーティーでもなければ隣の席の人間がいくら貰っているか堂々と聞くこともできない。 かつてGoogleで、自分の給料を全社員が見られる共有スプレッドシートに書き込み、公開を促した女性が現れてとんでもない騒ぎになったことがある。その行為の是非はともかく、不透明さによって守られていた上層部の平和は破られ、結果として彼女が社内で干される原因にもなったようだ。 このように給料の周りには、常に不透明な霧があって、その秘密は厳然と守られている。一方で、物価が上昇し、新卒の初任給が30万に達し、ボーナス平均が100万を超えたなどというニュースが連日報道されていて、先月のアフィリエイト収入が240円で、4月から素寒貧の無職になることが決定しているこのブログの主としては、気が気でない。 今こそ、私たちは給料の話をしなくてはならないのかもしれない。

インタビューと文章： 榎並紀行（やじろべえ）　写真: 関口佳代 イタリア生まれ、日本在住歴18年のマッシミリアーノ・スガイさん。フードライター・エッセイストとして日本の食の魅力を発信するマッシさんが現在暮らすのは、石川県の金沢市です。 24歳で来日後、大阪、名古屋、東京と大都市での暮らしを経て、定住先に選んだ金沢。人、食、そして「まったりとした雰囲気」に魅せられ、気づけば離れがたい場所になっていたといいます。 何年いても飽きることがないという金沢での暮らしについて、マッシさんに語ってもらいました。 きっかけは『ドラゴンボール』と井原西鶴。イタリアの少年が日本に恋するまで ── イタリア・ピエモンテ州で生まれたマッシさんが、日本に興味を持たれたきっかけは何だったのでしょうか？ マッシミリアーノ・スガイさん（以下、マッシ）：最初の接点は、イタリアのローカルテレビ局で放送されていた日本のアニメで

よ〜んです。 個人的に、AWS上で何かを動かすときは、 Step Functions で実現可能？LambdaECS（Fargate）大体こんな感じの思想で選んでいます。 で、とりあえずECSを選択すると立ちはだかるのがALB、ALBは時間課金＋通信料がかかります。 個人的な用途なのに、毎月15 USD以上の固定費は正直つらい…… タスクを使う時だけ起動にしても、ALBは起動しっぱなしなので、節約の恩恵がめちゃくちゃ薄いです。 ということで、今回は API Gateway HTTP API をロードバランサーっぽく使ってECSを動かしてみます。 やりたいことはざっくり以下です。 API Gateway → VPC Link → Cloud Map（Service Discovery） → ECS（Fargate）この構成自体は、2020年にAWSアーキテクチャブログで公開された記事をベース

あけましておめでとうございます！ 駅伝企画 第四区走者の みにせら (minisera) です。 普段は顧客体験チーム（CRE）でサーバーサイドエンジニアをやっています。 上ちょ（@psnzbss） から受け取ったタスキを持って走り抜けます！よろしければ前記事もどうぞ。 blog.smartbank.co.jp この記事ではクレジットカード番号（PAN: Primary Account Number）がシステム内に紛れ込むのを検出・防止する仕組みについてお話しします。「カード番号っぽい文字列」を見つけ出すアルゴリズムをGoで実装し、大量の誤検知と格闘した経験から、段階的にリリースしていく中で得られた知見を共有できればと思います。 なぜクレジットカード番号の検出が必要なのか 想定されるリスク クレジットカード番号検出の技術解説 1. 正規表現による候補抽出 2. 正規化 3. Luhnアルゴ

はじめに かつての私は、深夜2時にベッドの中で転職サイトを開いていた。 開いて、求人を眺めて、閉じて、また開く。そういうことを繰り返していた。辞めたいのか、と聞かれると困った。会社の限界が見えたのか。自分の天井が見えたのか。それとも、隣の芝生の青さに目が眩んでいただけなのか。たぶん、全部だった。たぶん、どれでもなかった。 今は、転職を考えていない。 これは「今の会社が最高だから」という話ではない。どんな会社にも良い面と悪い面がある。不満がゼロになることはない。ただ、深夜に転職サイトを開く衝動は、いつの間にか消えた。何が変わったのか。環境が変わったのか、自分が変わったのか。たぶん、両方だ。 「エンジニアは転職で年収が上がる」「成長できる環境に身を置け」——そんな言葉がタイムラインに流れてくる。転職エージェントからのスカウトメールは週に何通も届く。カジュアル面談のお誘い。年収アップの可能性。も

はじめに 「論理削除？deleted_atカラム追加すればいいでしょ」この一言から始まる地獄を、何度見てきただろうか。 最初は簡単に見える。カラムを1つ追加するだけ。しかし、その「簡単さ」こそが罠だ。 論理削除は技術的負債の温床だ。WHERE句への条件追加忘れ、認知コストの増大、テストの複雑化、パフォーマンス劣化。すべては「最初にドメインを考えなかった」ツケである。 しかし現実として、サービスを運用していくと論理削除が必要になる場面は確実に訪れる。 論理削除の本質は、「このレコードは存在するが、存在しないことにしてほしい」という矛盾だ。この矛盾を解消するか、受け入れて安全に管理するか。本記事ではその両方のアプローチを解説する。 なお、私はDBのスペシャリストではないので、ここで紹介する方法が唯一の正解というわけではない。あくまで一つのアプローチとして参考にしてほしい。データベース設計は文脈

Rails Tokyo Meetup 02 登壇資料。

Colab Conf 2025 Winter 2025/12/13 15:10~15:35 @ B会場 株式会社estie 取締役CTO 岩成達哉 Nari (@tiwanari)

これは はてなエンジニア Advent Calendar 2025、10日目の記事です。 onishiアドベントカレンダー2025、10日目でもあります。 生成AIによるコーディングが大きく進化した2025年。普段は人事部長などをしているため、あまりコードを書かないのですが、ある程度自律的に開発をしてくれるAIはそういった人こそ便利に使えるのではないでしょうか。 というわけで、「なるべくAIだけでどこまでできるか」をテーマにいくつか遊んだ様子をお届けします。動作環境を必要としない、ブラウザで動くゲームを題材にし、紹介したコードは全て GitHub の public リポジトリに置いてます。 ちなみに本記事に実用性は全くありませんので先に注意しておきます。 3つのAIで実装対決 共通指示と結果 評価 同時開発 3つのAIで順番に開発 単一のプロンプトで開発を進める 褒め合うAI 完成したもの

この記事は、whywaita Advent Calendar 2025 8日目のエントリ記事です。 whywaita Advent Calendar 10周年ということで、自分もwhywaitaとの出会いと10年という節目を掛けて何か書きたいと考えたのですが、うまいネタが思いつかず。とはいえ、whywaitaと出会ったきっかけがお祭り的な技術イベントだったので、今回は技術イベントの「お祭り性」について語っていきます。 思い返すと、技術コミュニティとの出会いは、いつもお祭りのようでした。見知らぬ人と技術の話で盛り上がり、気づいたらとんでもない深い時間になっていた懇親会。準備段階から当日まで、ワクワクしながら作り上げた勉強会。あの空気感こそが、私をエンジニアとして成長させてくれた原動力でもありました。 そんな私が最近読んで、考えさせられた記事があります。 はじめに Sakutaroさんが書かれ

古いメインフレームをクレーンで約36mの高さまで吊り上げ、そこから投下。落下地点には爆薬が置いてあり、落ちていったメインフレームはそのまま大爆発──米AWSは12月2日（現地時間）、こんな映像を公開した。

この記事は はてなエンジニア Advent Calendar 2025 の 4 日目の記事です. id:susisu です. TypeScript の never 型がたいへん奥ゆかしいので見ていってください. 基礎編 まずは never 型がどういったものなのかを見てみましょう. 値のない型として 例えば number 型に対しては 42, 3.14, NaN など , string 型に対しては "", "Hello" などのように, 一般的な型にはその型が付けられる値が存在します. 一方で never 型にはそういった値が存在しません (こういった型は一般にボトム型などと呼ばれたりします). never 型の変数には何を代入しようとしてもエラーになります. const x: never = 42; // エラー undefined や null も「値が存在しない」と説明されることが

間違っています。JSONは仕様が簡潔で融通が利かないところがメリットであり、ケツカンマやコメントを許容しないこともそれに一役買っています。ケツカンマやコメントが欲しければYAMLを使いましょう。YAMLはJSONのスーパーセットなので、JSONにケツカンマやコメントをつければYAMLとして読むことは出来ます。 JSONとYAMLにはそれぞれに良さがあり、それぞれの良さを他方に求めると、その価値を毀損します。言ってしまえば、JSONはシンプルでありYAMLはイージーなのです。 参考: Simple Made Easy JSONはシンプル ご存知の通り、JSONはルールや覚えることが少ない反面、表現力に乏しいです。結果として人間にも機械にも比較的優しいシリアライゼーションフォーマットとして優れています。「ひとつのことをうまくやる」です。必ず1行に圧縮できる強みもあり、ログフォーマットとしても使

「ウォークスルー改札」という言葉が鉄道改札機の世界でホットトピックとなりつつある。現在、東日本旅客鉄道（JR東日本）が上越新幹線の長岡駅と新潟駅の間で顔認証改札機の実証実験を行っているが、文字通り“手ぶら”で改札を通過可能な仕組みは、従来の改札機が提供してきた“タッチ”から、“タッチしない”への時代への転換点となるのだろうか。 そんなウォークスルー改札が複数参考出展されていた、11月末に幕張メッセで開催されていた鉄道技術展での展示内容を紹介したい。 ミリ波を使ったウォークスルー改札は従来のSuicaがそのまま利用可能 鉄道技術展のJR東日本ブースで展示されていたのは「ミリ波」を使ったウォークスルー改札機だ。JR東日本では数年前からミリ波を使った改札機の開発を進めており、実際に展示会等で紹介されたこともある。今回は同社ならびに、日本無線（JRC）とソニーの3社の座組で開発が進められ、参考展示

「何者にもなれないお前たちへ」はどこに着地したか2011年のアニメ『輪るピングドラム』に登場するキーフレーズは「きっと何者にもなれないお前たちに告げる」、である。この挑発的で、まるで現代社会からの宣告のような言葉は、放送から十数年を経た今もなお、私たちの中に巣食う根源的な欲望を鮮やかに抉り出している。それは、「何者かになりたい」という、あまりにも切実で、達成が困難な渇望がある。 「何者か」とは、単なる夢や目標を超えた、存在証明にほかならない。自己の存在が社会から認められ、埋没せず、特定の価値をもって受け入れられたという社会承認を指す。 とりわけ、自己表現や創作活動を志す人々にとって、この承認への渇望は、癒やし難くそして、同時に止むことなく自己を傷つけ続ける毒でもある。創造的なエネルギーの源泉ともなる一方で、それが得られない時の焦燥感や、社会の評価に振り回される。表現者を縛り付ける檻ともなり

AIのせいか年をとったせいか、おそらくその両方で、ビジネスのやり方が変わって、ふんわりした話にばかり関わっている。 「生成AIを使って暗黙知化したプロセスを形式知化して、御社のサプライチェーンをオプティマイズして、セールスをグロースさせます」とか「エンジニア間のスキルギャップをスクラムによってファシリテリテーションして御社のデベロップメント課題をイシュー化します」とか、なんだかそういった感じの話に関わっているのだ。 こういうふんわりした案件は、会議で何を発言しても面映ゆくなるというか、口に出せば出すほど脳が痒くなってくるような感覚があって、結局お前達の求めているものは売り上げと人員整理によるコストカットであって、もっと言えば人間の求めるものは不老と美食とセックスなんだから、そうはっきりと言え、と会議室の真ん中で叫びたくなってくるのを必死でこらえているのだった。 以前は、私の仕事はこんなでは

観客は作品を構成し、完璧にもでき、スポイルもできる 【この記事は本文無料となっています】 作品にとって、観客との関係は重要であり、常に悩ましい。 私は4年ほど前に宝塚の演出を辞めて以来、それまで自作を観てくれるのは主にヅカファンか団体観光客と層が固定化していたところから、それより多様な観客層に出会う機会が増えた。 結果、今もまだ混乱している。 私がこれまでと違うフィールドの俳優たちと仕事をした結果、その俳優たちが彼らの観客層と少し違う私の観客層に出会うことの難しさもあるのかもしれない。 今のところ、客席と舞台上がしっくりくる上演にまだ出会えていない気がする。 ある時、宝塚を辞めた後の私の作品に出てくれたパフォーマーに「今日はちょっと不調だった？」と言ったら、突然泣き出されたことがあった。「お客さんは"上田さんが"何してるか見にきてるだけで、私はただ消費されてるって感じて、やりにくくて…」

僕は「越境しよう」と言うやつが嫌いだ。 越境したがる人に限って自分の役割をきちんと達成できていないことが多い。まずは自分に期待されている役割を100%、120%、全うすること。これが一番前提にあるべきだ。 そもそも越境はしたくてするものでも、期待されてするものでもない。目的から逆算してアクションした結果として「越境してしまう」ものなのだ。越境すること自体を目的にするな。解決したい課題、目指したい理想状態、必要なアクションを整理することが最優先で、その結果越境しなくても良いならそれで良い。 というか越境なんてしなくてもいいものだ。越境せずに組織がまわるならそれが一番良い。みんながみんな自分の得意なことだけやっていればうまく進んでいくというのが理想的な環境ではないか。それができないから渋々越境して得意ではないことも頑張っていこうねということではないのか。越境を推進する前に、越境なんてしなくても

はじめに 「今日も、何もできなかった」。夜の部屋で、私はその言葉を呟く。また。今日も。 仕事をしなかったわけではない。むしろ一日中、何かをしていた。画面を見つめ、キーボードを叩き、メッセージを返し、タブを切り替え続けた。体は疲れている。目も疲れている。頭も疲れている。確かに疲労感はある。なのに、達成感がない。忙しかったのに、何も完了していない。この矛盾が、私を苦しめる。 朝、デスクに座った瞬間から、地獄が始まる。Slackを開くと未読の赤いバッジが十件以上浮かんでいる。「全部返信しなければ」。次にメールを開くと新着が三件ある。「これも返信しなければ」。GitHubのタブをクリックするとレビュー依頼が二件待っている。「これも見なければ」。そしてTwitterを開くとタイムラインに流れてくる技術記事のタイトルが目に入る。「これも読まなければ」。全部が重要に見え、全部をやらなければいけない気がす

はじめに どれだけ技術を学んでも、どれだけ正しいプロセスを知っていても、燃え尽きてしまったら意味がない。才能ある若者たちが最初は誰よりも速く理解して、誰よりも多くのコードを書いていたのに、数ヶ月後には姿を見せなくなる。「疲れた」と言って離れていく。 逆に、最初は遅くても数年経った今も黙々と学び続けている人たちがいる。彼らに共通しているのは、自分を大切に扱う習慣を持っていることだった。ちゃんと眠る。ちゃんと食べる。ちゃんと休む。そしてちゃんと掃除する。その中でも最も基本的な実践が、掃除だ。 在宅勤務を始めて六年目のある朝、ふと自分の部屋を見回した。 今、部屋は比較的綺麗だ。床に物は落ちていない。デスクの上も整理されている。技術書も本棚に並んでいる。窓を開けて空気を入れ替える習慣もついた。カーテンも開いていて、部屋の中は明るい。 30歳のエンジニア、独身。在宅勤務という働き方は自由をくれたはず