補足: 2025/02/21 クラスベースでも、Stateパターンを適用し、StateをDiscriminated Unionとして表現することで今回の問題を解決できます。つまり、クラスを利用することに問題があるわけではありません。この記事では、TypeScriptではあえてクラスを利用しなくても状態遷移を表現できることを紹介します。記事を一部修正し、Stateパターンをクラスによって実現する方法を追記しています。 背景 サーバサイド実装での状態管理の重要性 サーバサイドのビジネスロジックでは、エンティティ（注文、決済、在庫、タクシー配車リクエストなど）が複数の状態を行き来しながら進行します。 たとえば、タクシー配車アプリでは、配車リクエストが「呼び出し（Waiting）」「迎車中（EnRoute）」「乗車中（InTrip）」「完了（Completed）」といった状態を経て処理が進み、キャ
はじめに こんにちは。Builtoという会社で代表 & エンジニアをしている冨田です。 私たちはマネジメントとタスク管理を圧倒的にサポートするAIエージェントを開発しています。 開発にもAIをフル活用しており、そこで得られた知見を共有したいと思います。 具体的には、経験3年以上の現役ソフトウェアエンジニア（生成AIのない時代からコードを書いてきた方々）をターゲットに、本番運用レベルの大規模コードベースでもCursorを活用しコーディング時間を 1/3〜1/5 に縮めている手法をお伝えします。 仕様策定やアプリの機能にもLLMをフル活用していますが、今回は実装にフォーカスします！ （なお本記事は中級者以上向けのため、まだCursorに触れたことがない方はまず別の記事を参考にして、使ってみてください） なぜこの記事を書いたか 現職エンジニアが本当に使いこなす手法を共有したい すでに共有されてい
Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ
やっと一区切りついたので書きますが 半月ほど前に突然Yahoo!IDが停止されて、それに紐づいているeBookJapanの電子書籍1000冊超が利用できなくなるという事態になり、消費者センターにも相談しながら何度も問い合わせて解決した件について、備忘録兼ねて ID停止の理由は「長期間利用がない」だったが、何ならその日の昼まで普通にYahooモバゲーで遊んでいたし、eBJの方でも３ヶ月前に購入していたので全く身に覚えもなく 仕方なくエラーの出るログイン画面のヘルプから問い合わせるも、「復旧はできない」と露骨なテンプレ返信 ウォレットにも登録していたはずなので身分証UPと共にID照会をすると、今回停止されたのとは別のIDは生きているという返信…そもそもそっちは聞いてないけど、登録情報が同じで照会された模様 何ならそっちの方が放置してたしメールBOXも死んでた 現に数年前に「長期間利用がないため
妻のがん治療を続けてきたが、どの治療も効果を上げることができず、先月から自宅で終末期の緩和ケアを行っていた。 訪問看護の助けを借りながらも、落ち着かない日々が続いていたが、とうとうその時が来たようだ。 妻とは二人暮らしで、お互いの家族とは遠距離に住んでいるため、すっかり疎遠になっている。 妻ががんと診断されてからは、毎回診療に付き添い、できる限りの支えを続けてきた。 しかし、治療の甲斐なくがんの進行を抑えることができず、病状が急激に悪化して入院。その後、自宅で緩和ケアを行うことになった。 自分は毎日、家事と妻の介護をこなしながら、訪問看護師の対応や手伝いに追われる日々を送っていた。 毎日数回、看護師が来るという生活は思いのほか慌ただしく、自分も妻も十分に休むことができず、心身ともにしんどい日々だった。 それでも、クリスマスには少し奮発して豪華な食事とケーキを楽しみ、年末は年越しそばを作り、
https://anond.hatelabo.jp/20250105165945 上の記事を読んで、ドワンゴの中の人として糸柳で思い出したこと、彼を雇ったドワンゴがどんな会社だったのかを書いてみようと思う。 糸柳を雇ったのは、ドワンゴのエンジニアのトップだったS君だ。ここでは鉄男（仮名）と呼ぶことにする。 糸柳を雇う少し前、僕は鉄男を叱責したことがある。「お前は自分の使いやすい人間しか採用してない。だからてめえは小物なんだ。自分にない能力をもった奴を採用しろ」みたいなことを言った。 鉄男は中卒だ。そう、ドワンゴのエンジニアのトップは中卒だった。いや、鉄男だけでなく、ドワンゴの幹部エンジニアの半分以上は中卒、あるいは高卒だった。 これは当たり前で、当時のドワンゴは天才エンジニアみたいなやつがゴロゴロいる職場だった。同じ天才エンジニアなら、高校も大学も行かずにずっとプログラミングをやっている中
Firebase と添い遂げる Advent Calendar 2024、6日目です。 はい！3日くらい遅れていますが、ISUCONがあったんだから仕方ないよね。 Firebase 使うならレイヤードアーキテクチャをやりたいよね 1日目の記事 にも書いたが、Firebase を技術選定する時はいつか卒業する前提で選ばれるというケースがある。 特に開発リソースのないチームは Firebase でビジネスを始めるのは合理的であり、その結果会社が成長したらお金にモノ言わせて好き放題なんでもできる環境を使うというのも合理的だと思う。 そしてそこまで見据えたエンジニアはきっと Firebase をいつか卒業する前提でアーキテクチャを考えるだろう。 その場合、アプリケーションのアーキテクチャとしてはレイヤードアーキテクチャが採用されると思う。 つまり Cloud Functions for Fireb
Nuxt.js で開発されていたAI受診相談ユビーのフロントエンドを Next.js で作り直しました。 まだまだ仮説検証を繰り返すフェーズのスタートアップのため、機能開発を止めて一気に置き換えることはできず、機能ごとに少しずつ置き換えてリリースをしました。結果、5人のプロダクト開発チームによる機能開発と並走して、全体の移行を1人で1ヶ月の短期間で終わらせることができたので、その意思決定や過程、工夫を紹介します。 移行前の課題 まず前提として、移行前の Nuxt.js による実装は 2018 年に立ち上がったもので、当時 toC の Web サービスを持っていなかった Ubie が ほぼ 1 人の小さいチームで PoC 的に作り始めたものでした。また、当時の Next.js は今ほど多機能ではないプレーンなフレームワークでした。 これらを踏まえて、当時の状況で MVP を最速で作るための技
生活保護を抜けた。抜けれた。 体調崩して、生活がままならなくなって。症状検索して病院行っても診断つかなくて、そのうち動けなくなって働けなくなった。 自分が生活保護を受けることになるなんてちっとも思ってなかった。 親は助けてくれない、ガスも電気も止まってる。家賃も大家さんに頭を下げて待ってもらってた。 明日食べるものにも困ってる、そんな状態で申請した生活保護だった。 生活保護を受けて医療費がかからなくなって、病院行ってやっと診断ついて。数年かけて治療した。 完治じゃないけど、お薬飲んで上手に病気と付き合っていきましょうね。みたいな状態。 生活保護を受けてるなんて誰にも言えなかった。私が生活保護を受けてるのを知ってるのは家族ぐらい。 友人たちには病気して今フリーターなんだー超貧乏だよーて言ってた。本当は生活保護受けてるって気付いてる友人もいると思う。何も聞かずにいてくれてすごく感謝してる。変わ
DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパターンです。 よく依存性の逆転・DIと一緒に語られますが、くまぎさんがおっしゃる通り余計にインターフェースを切るのはイケてないと感じます。また、DI抜きにしても、リポトリパターン由来の様々な問題（N＋1やバルクアップデート、管理画面用のメソッド生やしたくなる問題など）に対する解決策として提示さ
2023年は「Cloud Run を触って覚える」をテーマとした ひとりアドベントカレンダー を開催しており、Cloud Run のさまざまな機能や Cloud Run でよく使う構成などをご紹介しています。 最終日、25日目は Cloud Run を中心としたサーバーレス アーキテクチャをいくつか紹介します。2023年にちなんで23個のアーキテクチャを用意しました。 Cloud Run の概要は「gihyo.jp」で解説していますので、こちらもぜひご覧ください。 Web アプリケーション + API の 3-Tier 構成 (SPA) Web アプリケーション + API の 3-Tier 構成 (SPA) SPA (Single Page Application) がフロントになり、バックエンドの API サーバーとして Cloud Run を使用するアーキテクチャです。SPA は N
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分はこれまでメンバーレベルのポジションとしてしか働いたことがありません。 ただ、自分と比較して必ずしも技術的に優れているわけではない同僚がインパクトの大きい仕事をしたり、上司やマネージャーの信頼を得たりしていくのを見た経験から、 自分がよりインパクトの大きい仕事をしていくためにはどのような部分が足りていないのかを考えるために、色々と調べたり、考えたり、まとめたりしてみました。 シニアなエンジニアについて ここでは、グレードの高いエンジニアや抽象度の高い仕事を日常的に行っているエンジニアをシニアなエンジニアと呼ぶことにします。 シニアな
仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」
死のうとしていましたが踏みとどまりました。以下の文章は死ぬ直前に投稿しようと思っていたエントリから生きたまま公開するのがはばかられる箇所を一部修正したものだ。錯乱状態で書いたので全くまとまりはない。 一ヶ月くらい本気で死のうと考えていて、色々準備してあとは実行するだけという状態で何日もグズグズしていた。ネット上にある自殺して失敗した人や自殺遺族の人の文章を読み漁ったりしていた。 結局、考えれば考えるほど死んで意識が無になるという恐怖に打ち勝つことが出来なかった。あと一番身近にいる人がショックで狂ってしまうのが辛いなと思った。 一旦は落ち着いたが、今後どうするかは未定。 ------------------------以下遺書だったもの---------------------- この文章をみなさんが読んでいる頃は私はもうこの世にはいないだろう。 これはそういう文章だ。 内容は私が死ぬという
村上隆氏と左派論客の斎藤幸平氏がReHacQ(高橋弘樹氏が運営するチャンネル)で対談している動画が4連続で上がっていてすべて見た。 ※以下敬称略 結論から言うとこの動画で村上隆が何をやろうとしているのかよくわかったので彼への嫌悪感はすべて消えた。 1動画40分近くあるので見るのは大変だと思うが興味深く見れたので余裕がある人は見てほしい。 一応言っておくとこれはあくまで私の個人的見解なのでその点には注意してほしい。 ざっくり動画の流れを説明すると斎藤幸平が布施英利と対談した際に村上隆が嫌いと悪口を言ったので、村上隆がYoutube？にコメントを書きそれを見てチャンネル運営者の高橋弘樹が対談に誘ったという流れのようだ。 ※斎藤幸平氏はマルキストなので拝金的に見える村上氏の行為があまり好きではない 現在京都で開催中のもののけ展の展示内容を村上隆が斎藤・高橋、両氏に説明しつつ最後に対談という流れに
発売から30年を記念し、『アメリカンバトルドーム』が令和に復活！！ 本体色やステッカーデザインなどを含めて、当時の仕様を完全再現しています。 遊び方は超カンタン！ 中央から転がってくるボールをフリッパーではじいて相手のゴールにシュート！！ 超エキサイティングなアクションゲームです。 当時遊んだ方はもちろん、まだ遊んだことのない方も この機会にぜひお楽しみください！！ ------------------------------------------------------------------------------------------------ 【セット内容】 ・本体ベース…1個 ・フリッパー…4個 ・ドームトップ…1個 ・ドームトップベース…1個 ・ドームトップ支柱…2個 ・センターホール…1個 ・反射板…4個 ・ネット…1個 ・ベル…4個 ・S字型スピン…4個 ・カラーボー
SIerでマネージャーまで出世し、いくつかのスタートアップでEMやCTOを経験してる。 この増田には本当にごめんねと思ったので初投稿。 https://anond.hatelabo.jp/20240728023355 エンジニアもビジネスだとか、生成AIだとか、本当つまらないよね。俺もそう思ってるよ。 でもさ、CEOや株主や役員達が言うんだよ。 ビジネス成果も禄に出してなければ、OSSで活躍している訳でもない、コミュニケーションがちょっと得意なその辺のスタートアップのCTOとかに、ビジネスイベントや飲み屋でそう言われてさ。 「これからは生成AIだ」とか「エンジニアにもビジネス意識を植え付けよう」って。「評価や採用も技術発信もそうしよう」「その方が儲かるぞ」って。 JTCがコンサルに弱いのと同じでさ、エンジニア業界で評価されていないキラキラCTOみたいな人でもさ、なんか不思議な力で言われてそ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
