スリーシェイクの吉田です。 今回のテーマは、ズバリ「クラウドネイティブ時代の歩き方と2025年のエンジニアの生存戦略」です！ そろそろ来年のことを考え始めるにあたって、この1年間（2023年から2024年にかけて）を振り返ってみたときに、自分自身もエンジニアリングをしている中で、一番インパクトが大きかったのは、やっぱり生成AIの登場だったと思ったんです。 しかも、生成AIってすごいなって言う流れが去年あったけれども、もう今に至っては、生成AIを使って何かしらエンジニアリングをするっていうのが割と当たり前になりつつあるとことを実感しました。 皆さんも、便利だなと思いながら、どんどん開発の生産性を上げるために生成AIを活用しているっていう認識だと思うんですが、ふと立ち止まった時に、これを進めていった結果、僕たちエンジニアっていうのは、どういうキャリアをどのようにこう作っていくことがいいんだろう

「無限の猿定理」とは、無限の時間があれば、キーボードをランダムに叩く猿が、シェイクスピアの全作品など、どんな文章でも偶然に打ち出せるという思考実験をいう。有限の長さのテキストにおいて、ランダムな入力でも、無限の時間があれば目的のテキストが必ず出現するという数学的な確率の考え方である。 研究チームは、この「無限の猿の定理」を現実的な条件下（有限の時間と有限の個体数の猿で確率計算）で検証することにした。 現在地球上に生息する約20万頭のチンパンジーを対象に、英語のアルファベットと一般的な句読点を含む30個のキーを持つキーボードを使用すると仮定し、各個体が1秒間に1文字をタイプするという条件で計算を行った。また、宇宙の寿命を10^100年と想定し、数学的分析を実施した。 研究結果は、次のようになった。 例えば、チンパンジーが「Bananas」という簡単な単語を偶然に書き上げるには、約2.2×10

「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な

※本記事は筆者RyotaKが英語で執筆した記事を、弊社セキュリティエンジニアShion1305が日本語に翻訳したものになります。 はじめに こんにちは、Flatt SecurityでセキュリティエンジニアをしているRyotaK(@ryotkak)です。 2023年にPortSwigger社のJames Kettle氏は、同社の記事でSingle-packet attackという新しい攻撃手法を提案しました。これはネットワークのジッター値に関係なくレースコンディションを悪用できるというものです。 Smashing the state machine: the true potential of web race conditionsより引用 最近私は、同時に約10,000件のリクエストを送信することで安定して成立するレースコンディションを発見し、Single-packet attackを適用

僕が触り始めた頃のウェブフロントエンド開発はデバッガーもなく、ダイナミックHTMLと呼ばれて文字をチカチカさせたりするようなものでした。IE6という超安定ブラウザが出てきたり（Netscape 4.xも7.xも不安定だった）その後jQueryが登場したときは、天使が降臨したように思えたものです。 そこから長い年月が経ち、ウェブフロントエンドの比重が大きくなるにつれ、フロントエンドのコードはどんどん複雑化しました。OpenAPIなどのコードジェネレータなども普及した結果、通信というものが隠され、イベントの中でawaitや.then()で呼ばれる何か、みたいな理解をしているメンバーも今後増えていくのではないかという懸念があります。 現在ではウェブフロントエンド開発はReactやVueといったフレームワーク上で行われ、イベントというのはそのフレームワークの提供するライフサイクルイベントに対応付け

マネージャーは「面倒なことをやってくれる人」なのか 最近マネージャーな方を「面倒なことをやってくれる人」として認識されていることがあります マネージャー自身が「そう思っていますーハハハ」と言っていることもありますし、「マネージャーって開発に関係のない面倒なことをやる役割でしょ？」って言われることもあります なんなら「面倒なことはマネージャーが全部やるからさ」とメンバーに言っている場に居合わせたこともあります マネージャーは「面倒なことをやってくれる人」なのでしょうか 「面倒なことをやってくれる人」と思われる背景と影響 「面倒なことをやってくれる人」として扱われているマネージャーの共通点を自分なりにまとめたところ、自身の業務を明示していないのではないかな？と思いました 自身がやっている業務を自身で説明できない or しないため、その専門性やキャリアを示すことができない状態です 結果としてメン

複数人に必ずやってほしいタスクがある時、『そのタスクが終わったら各自抜けるSlackチャネル』を作る運用にすると楽。最近試験的に"月の勤怠を提出したら抜けるチャネル"を Zapier で自動作成するようにしたので雑に書いておく。 Zapier はこんな感じで組んで、毎月1日10時になったら前月分の勤怠提出を促すための #tmp-kintai-YYYYMM チャネルを作成してメンバーを招待する。 で、11時、15時、19時に自動でリマインドし続けるだけ。若干無駄に Action を消費する Zap になっているので改善すべきだとは思う。 毎月ちゃんと提出してくれる人にはうざったいだけなので、そういう人は自動招待の対象から外していっている。だんだんと対象人数が減ってきているので、最終的にはこの仕組み自体が不要になればいいと思う。あと、欲を言えばこういうしつこく強制力のつよいリマインド機能自体は