サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
前置き 手前味噌ながら、弊社は高い開発生産性を評価され、Findy Team+ Award 2024, 2025 を2年連続で受賞した。華やかな受賞理由の裏側には様々な要因があるが、その中でも技術的な側面としてひっそりと、開発者が直接触れる作業領域に対して強く作用させていた力学のひとつが、本記事にて紹介する 「DRY との向き合い方(=境界設計)」 である。 「最短距離」で走るつもりが、最速で消耗戦へ 早期のプロダクト開発では「まずはスピードを最優先」という判断がしばしば下される。 だが、短期効率だけを信じて場当たり的な共通化、とりわけ 「誤った DRY」 を積み重ねると、ほんの1ヶ月後には、その短期効率こそが最大の足かせになって返ってくる。 初速を上げたつもりが、気づけば境界が溶けたコードベースのメンテに追われ、「本当にやりたい開発」に時間を使えなくなっていく。開発効率は時間とともに自然
11月25日、海外のサイエンス系メディアPsyPostが「A mathematical ceiling limits generativeAI to amateur-levelcreativity」と題した記事を公開し、話題を呼んでいる。この記事では、生成AIの創造性に数学的な上限が存在し、人間のアマチュアレベルを超えられないという理論的な分析について詳しく紹介されている。 11月25日、海外のサイエンス系メディアPsyPostが「A mathematical ceiling limits generativeAI to amateur-levelcreativity」と題した記事を公開し、話題を呼んでいる。この記事では、生成AIの創造性に数学的な上限が存在し、人間のアマチュアレベルを超えられないという理論的な分析について詳しく紹介されている。 以下に、その内容を紹介する。 生成A
複雑性はなぜ破綻するのか？ 計算量と認知負荷から読み解く、ソフトウェアの限界について考えました。 これは、情報過多時代の「過学習」にも通じるテーマです。 私たちの脳がどこで飽和し、どこから理解が追いつかなくなるのか..その構造を知ることは、エンジニアリングだけでなくリスキリングの土台にもなりうると思っています。 はじめに ソフトウェア開発には、「複雑性が問題を生む」 という常識があります。 なぜ複雑になると破綻するのか どこから複雑と呼べるのか どの瞬間に人の理解が追いつかなくなるのか技術負債は、なぜ突然「手がつけられない」段階まで膨張するのか ソフトウェアの複雑性を・・ という3つのレンズで読み解いてみました。 ポイントは、「複雑なコード」 ではなく、「複雑さ自体の本質」 を扱うことです。 1. 複雑性とは「計算量の爆発」を人間が受け止められなくなる現象 ソフトウェアの複雑性は、しばし
ここは、Martin Fowler'sBlikiの日本語翻訳サイトです。Martin Fowler氏本人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。API design / agile / agile adoption / agile history / application architecture / application integration / bad things /build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv
最近のAI技術の進化は目まぐるしいですよね。ChatGPTをはじめとする生成AIが私たちの生活に浸透する中、Googleが新たな技術「拡散コーディング」を用いたAIモデル「Gemini Diffusion」を発表し、話題になっています。 今日はこの最新の「拡散コーディング」技術とGemini Diffusionについて、わかりやすく解説していきますね。これまでのAIとどこが違うのか、どんなすごいことができるのか、一緒に見ていきましょう！ Gemini Diffusion誕生！これは何が新しいの？Google DeepMindが2025年5月20日、開発者向けイベント「Google I/O 2025」で「Gemini Diffusion」を発表しました。これは通常の言語モデルとはまったく異なるアプローチで動作する、最先端のテキスト拡散モデルなんです。 従来のAIモデルとの決定的な違い従来の言
Platform Team/Core Unit の村上です。 Repro は分散メッセージングシステムである Kafka を用いたイベント駆動アーキテクチャで構築されています。 私が所属している Core Unit は、Repro のコアとなる基盤を支えているチームであり、Kafka のストリームアプリケーションを日常的に扱っています。 私は Repro に入ってから Kafka のストリームアプリケーションを触るようになりましたが、一般的な WebAPI や Worker アプリケーションの実装とは異なるマインドセットが求められると感じます。 その中で特に重要だと考えているのが Kafka のパーティションに関する理解です。 Kafka のパーティションは分散処理を扱う上で重要な概念であり、ここの理解が浅いまま実装を進めていくと、後になってトラブルに見舞われることがあります。私自身 K
最近もっぱら Roo から Claude Code をメインに移しているが、その界隈の進歩は今までの変化とは明らかに質が違うという感覚がある。それを今の時点で言語化しておきたい。 最初にいっておくと、自分はシンギュラリティ論自体には否定派というか、シンギュラリティが来たところで世の中の問題の大多数が解決されるとは思っていない。(特にレイ・カーツワイルは典型的なフェイク野郎だと思っている) 実現したところで、そんなものかになるという程度の話だと思っている。実現したところで、シンギュラリティ万能論者はゴールをずらし続けることで否定するだろう。終末論はいつもそうだ。 という前置きの上で、今確実に転換期を迎えているAI とプログラミングの話をしたい。 特異点があるとしたら、今はその瀬戸際。 tl;dr Claude Code は Claude Code によって 90%が開発されている その改善
サンプルプロジェクト 構成 イベント駆動と CQRS を意識した、レイヤードアーキテクチャをベースとしたヘキサゴナルアーキテクチャになります。 各層について レイヤードアーキテクチャをベースに、以下の4層に分けています。 プレゼンテーション層: ソフトウェアの入出力を担当 アプリケーション層: ソフトウェアのユースケースを担当 ドメイン層: ドメイン知識を元にしたビジネスのルールや制約、プロセスを担当 インフラストラクチャー層:技術的関心ごとの全般を担当 ディレクトリ構成domain/ # ドメイン層 models/ ## ドメインモデルを格納 services/ ## ドメインサービスを格納 application/ # アプリケーション層 use-cases/ ## ユースケースインプットポートを格納 interactors/ ## コマンドにあたるユースケースの実装クラスを格納
パンダとおくだが、Web業界の当たり前を「これって本当にそうだっけ？」と問い直すラジオを配信しています はじめに 昨年末にこんなツイートをしたら、ちょっとバズってしまいました。aaa https://x.com/Panda_Program/status/1864333831886786971 色々コメントを頂くことで考えを深めてブログを書きますと言っていて、まだ着手していなかったのでざっと書くことにします。ただ、今日はクリーンアーキテクチャが対象です。 簡単に自己紹介をすると、私は現職でフルスタックエンジニアをしています。また、「バックエンドのためのフロントエンド入門」 というテーマで登壇をしたり、自分のエンジニア人生を変えた書籍リストにクリーンアーキテクチャを挙げており、TypeScript でクリーンアーキテクチャを実践する という記事では Web からでも CLI からでも動かせるア
PayPayの6年の歴史の中で、私たちは急速な成長を遂げてきました。現在、6700万人以上のユーザーにサービスを提供し、日々数百万件の決済を処理しています。しかし、これを成功させるためには、トラフィックと信頼性の要求を満たすための技術的な挑戦が伴います。 PayPayは設立当初からJavaとNodeJSを採用しており、これらの技術は非常にうまく機能してきました。しかし、成長に伴いサービスをスケールアップする必要が生じ、これによりKubernetesクラスターでのCPUとメモリの使用量が増加しました。これにはサーバーコストの増加が伴います。2023年末、私たちはコアサービスでのトラフィックをより効率的に処理する方法を模索し始め、GraalVMやGo、Rustなどさまざまな技術を調査しました。Rustは、その優れたパフォーマンスとメモリの安全性が保証されていることから、PayPayの多くのユ
はじめに こんにちは。BEENOSのがれっとです。AWS上にアプリケーションを構築する際、一般的なのはECS + RDSという組み合わせです。私も社内システムをそのような形で構築しました。 しかし、使わないときにもインスタンスが動き続けてしまうため、大量のトラフィックを捌かないアプリケーションにおいてはコストが見合わないものとなってしまいます。 そこで、ECS + RDSという構成からLambda + EFSの構成に社内システムを移行して、コスト削減した話を紹介します。 前提 以下の構成のアプリケーションを移行しました。Blitz.js 内部に下記を使用 PrismaNext.js PostgreSQL テーブル数は12 (_prisma_migrationsテーブルを含めて13)AWS 構成図 移行前 移行後 リレーショナルデータベースを用いることが必須のアプリケーションを構築す
2024.11.05「追記１：問題編」を追加しました！ 2024.11.06「追記２：回答編」を追加しました！ 2024.11.06 [補足]を追加しました！ 前提LaravelはWordPressからステップアップしたい人に丁度フィットしたような作りになっており、オンプレ前提であり、MVC構成の簡単なSSR（サーバーサイドレンダリング）を推しています。WordPressの次のステップと捉えると納得できますし、小さなアプリを簡単に作るには丁度良いと思います。 しかし、これで大きなサービスを作ろうとすると途端に崩壊します。 基本的にドキュメント通りに作成すると画面とインターフェースが密結合し、サービスとしてのインターフェースが固まらない状態になります。 結果的に私が関わったプロジェクトは全て密結合で触れない状態に陥っていました… たぶん日本中、いや世界中がこうなってると思います。 決して
エンジニア採用の状況は地域によって大きく異なる 最近視聴した2つのコンテンツが、同じソフトウェアエンジニア採用の話題を取り扱っているにもかかわらず、その内容が両極端で非常に興味深かった。 ひとつは「エンジニア採用必勝法・これだけでわかるDevRel入門」という動画で、もうひとつは「最近カナダで就職したエンジニアと一緒に北米就活の攻略法を語る」というポッドキャストのエピソードだ。エンジニア市場と企業の採用戦略は地域や業界によって異なるが、ここで話されている東京と北米（バンクーバー）では顕著な違いが見られる。 東京を中心とする日本ではテック企業間での人材獲得競争が激しく、特にエンジニアが不足しているため、採用広報の役割の重要性が増し、DevRelといった呼び名で施策が実行されている。 一方、カナダでは、永住権を持たない外国人労働者が職を得るハードルが高く、求職者の競争が激しい現状が実際
このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。 ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。 全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。 内容としてはRailsアプリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
