フロントエンドカンファレンス北海道でお話ししたスライドです Proposal: https://fortee.jp/frontend-conf-hokkaido-2024/proposal/ebd98e0a-241c-4443-aa98-300af113b40d # URL YouTube…
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
こんにちは、MLBお兄さんこと松村です。 昨年の MLB 全体ドラフト1位のポール・スキーンズ投手がメジャーデビューしました。予想通りの豪速球でした。 2024年4月29日についにテクニカルプレビューが開始となった GitHub Copilot Workspace ですが、ゴールデンウィーク中に私のアカウントでも利用可能となっていたため、試してみたことを書いていきます。 利用開始まで この記事を書いている時点では、 GitHub Copilot Workspace の利用には待機リスト (Waitlist) への登録が必要であり、その通過を待つ必要があります。 そのため GitHub Copilot Workspace を利用したい方は、こちらから登録を行いましょう。 githubnext.com ゼロからアプリを作ってみる 今回は練習として私がコードを書くこと無く、 C# の簡単なアプリ
インタビューと文章: 榎並紀行(やじろべえ) 写真: 関口佳代(撮影/本多康司)古くからの別荘地として知られる軽井沢。別荘というと富裕層など特別な人が持つものというイメージがありますが、近年の軽井沢では、そのような限られた人だけではなく、さまざまな人がコンパクトな家を建てるケースも増えているといいます。また、軽井沢の家を本宅として定住する、デュアルライフの拠点として長く滞在するなど、従来の「別荘族」とは異なるライフスタイルも生まれている模様。 建築家・福岡みほさんも軽井沢の豊かな森に魅せられ、6年前、地元の愛媛から拠点を移しました。現在は、軽井沢や東京、瀬戸内などで多拠点生活を送りながら、「森の家」をつくり続けています。 「軽井沢の森の中にいると、五感が蘇ってくる」という福岡さんに、軽井沢の好きなところや自然の中で暮らす魅力、また、森の家づくりにおいて大切にしている点などを伺いました。 福
公開日 2024/06/26更新日 2024/07/25モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 ご好評頂いているアーキテクチャ特集の第三弾となる今回は、BtoB SaaSを提供する企業10社にご協力頂き、技術選定のこだわりや今後の展望をご寄稿いただきました。アーキテクチャを通して、各社の事業特性や設計思想にも触れられる内容となっております。※ご紹介は企業名のアルファベット順となっております 株式会社あしたのチーム あしたのチームは「誰もが "ワクワク" 働ける世界を創る」をビジョンに掲げ、人事評価制度の構築・運用・クラウド化で "人と組織の成長" を支援しています。今回は、2024年4月にリリースされた同社の新サービス:パフォーマンスマネジメントプラットフォーム『Cateras™』のアーキテクチャについてご説明します。 アーキテクチャ選択の背
この記事は、株式会社カオナビ Advent Calendar 2023の2日目です。 カオナビでは2022年9月からArchitectural Decision Record(以下ADR)を導入開始しました。本記事ではADRを導入し実際に一年間運用して見た経過をご報告しつつ、導入のポイントや注意点について紹介します。 ADRをなぜ導入したのか? まずADRについて簡単に説明すると、「アーキテクチャー設計の記録をドキュメントとして残すこと」 です。Michael Nygardのブログ記事が初出のようです。 ソフトウェア開発を行っていく間には、途中で様々な設計決定をする必要があります。例えばウェブアプリケーションであれば、データベースはMySQLにしようとか、キャッシュはRedisを使おうとかという実行環境の決定の話から、実際のプログラムの基本構造といったところまで様々です。 この設計決定は、
本稿はNext.js v15.0.0-rc.0時点の情報を元に執筆しており、PPRはさらにexperimentalな機能です。v15.0.0のリリース時や、PPRがstableな機能として提供される際には機能の一部が変更されてる可能性がありますので、ご注意下さい。 Partial Pre-Rendering(以降PPR)はNext.js v14.0で発表された、SSRやSSGにならぶ新たなレンダリングモデルです。 PPRは前述の通り開発中の機能で、v15のRC版にてexperimentalフラグを有効にすることで利用することができます。ppr: trueとすれば全部のページが対象となり、ppr: "incremental"とすればexport const experimental_ppr = trueを設定したRouteのみがPPRの対象となります。 // next.config.mjs
はじめに AWS Step Functionsを利用し、音声ファイルがS3バケットに保存されるたびにAmazon Transcribeで文字起こしを行い、文字起こし内容をメール送信する方法を紹介します。 今回構築する構成は以下の通りです。 処理の流れは以下の通りです。 音声ファイル(WAV)をS3バケットにアップロードする アップロードをトリガーにEventBridgeからStep Functionsステートマシンを起動する 音声ファイルからAmazon Transcribeで文字起こしし、文字起こした内容をAmazon SNSでメール送信する この構成を構築するきっかけは、以前執筆した「Amazon Connectでエージェントの介在がない場合でも電話中の発話を録音する」記事の構成に、録音ファイルに対して文字起こしとメール通知機能を追加する必要が生じたためです。 執筆した記事の構成図は以
概要 本記事は、スクラムを管理するアプリケーションをクリーンアーキテクチャの考え方で実装し、WebからもCLIからも動かせるようにしたという実践を紹介するものです。学習のための個人開発で作成したサンプルアプリケーションの設計と実装を適宜紹介することで、クリーンアーキテクチャに対する理解を深めることが目的です。 モチベーション なぜ現代の開発現場で定着しているクリーンアーキテクチャのアプリを手元で実装してみようと思ったかというと、私自身Webエンジニアとして働く中で、クリーンアーキテクチャの実践例は入出力をWebに限定したものばかりだったからです。 しかし、「詳細に依存せず抽象に依存すること」と唱えるクリーンアーキテクチャにとって、Webはただの詳細です。そこで、入力元、出力先を問わないアプリケーションはどのような書き味になるのか、自分で確かめてみたくなりました。 例えば、「ドメイン層は独立
はじめに CastingONEでバックエンドエンジニアをやっている清水です。 この記事ではクリーンアーキテクチャについて学んだけど具体的にどのように実装すれば良いのかという悩みがあったので実装例をまとめてみた記事になります。 クリーンアーキテクチャで実装されたサンプル実装のうちGitHubのスター数が多いリポジトリをピックアップして、設計内容を紹介していきます。 具体的にどこにどんな実装をするべきなのかも含めて紹介していきます。 処理を一部省略して紹介するため実際の処理内容を確認したい場合はGitHubでご確認お願いします。 クリーンアーキテクチャとは クリーンアーキテクチャは、ソフトウェア設計の原則を適用して、依存性の方向性を逆転させ、ビジネスロジックから詳細(フレームワークやデータベース)を分離するアーキテクチャパターンです。これにより、テストしやすく、メンテナンス性が高く、柔軟性のあ
ログラスの龍島(@hryushm)です。最近は秋に備えて干し芋を作る練習をする日々を過ごしています。 ログラスではオニオンアーキテクチャを採用してしてDDDを実践しています。直近プロダクトのスケールによってデータのレポーティング、集計処理のパフォーマンス劣化の問題が顕在化、早急な対応を迫られる事態となっていました。その対応としてRDBMS(PostgreSQL)からDWH(BigQuery)へ一部のクエリを移行しました。オニオンアーキテクチャの恩恵で移行が比較的容易であり、実装自体は1ヶ月というスピードで終えることで顧客に素早く価値提供できたため、実例として記事にしたいと思います。 オニオンアーキテクチャと利点 オニオンアーキテクチャ自体の説明は多数の記事があるため省きますが、弊社松岡の記事が理解しやすいと思います。 記事中にあるレイヤードアーキテクチャと比較した時に肝となる、依存性逆転の
はじめに この記事は、業務でフロントエンドのディレクトリ設計思想を変更した際の作業をまとめた記事です📕 それなりの規模のプロジェクトでの移行作業のため、通期のリリースサイクルに影響が出にくいようにリファクタリングを進めてきました。そこでの進め方や感想も含めてお伝えできればと思います。 前提 6年ほど運用しているReact Nativeのプロジェクトでの移行作業のお話です。 従来のディレクトリ設計思想はAtomic Designを採用していました。しかし、organismsのコンポーネントが300個近くにも及び、プロジェクトの規模が大きくなるにつれて様々な課題が浮き彫りになりました。これを機に設計思想の移行を決めました。 Layer型のAtomic DesignからFeature型のディレクトリ構造に移行していこうと思います😌 参考: ソフトウェアアーキテクチャの基礎 なぜ移行したか な
AWS については利用していないのでよくわからない。あくまで Erlang/OTP で書かれたミドルウェアのリプレイス事例として感想を雑に書く。ちなみに、現地で発表を聞いている。 一般的な感想 自分のような AWS 素人が見てもわかりやすいシンプルなシステムになっていた HTTP/2 を利用した独自プロトコルでの双方向通信が気になる TCP/IP を利用した大量の常時接続は本当に大変だとおもう カーネルパラメーターチューニング! 少ないリソースで、たくさんの接続を担う ゴールが素晴らしい デプロイの自動化を GitHub Actions でやってるのやっぱりいい 負荷試験にて1億台の接続を維持した状態で挙動が問題ないことを確認 最高 Graviton ベースの Fargate の活用 Go であれば arm64 向けバイナリがサクッと生成されるのは良い Erlang/OTP から Go へ
こんにちは。メルカリ ハロのSoftware Engineer (Engineering Head)の@napoliです。連載:Mercari Hallo, world! -メルカリ ハロ 開発の裏側-の2回目を担当させていただきます。 2024年3月上旬にメルカリ ハロという新しいサービスが公開されました。メルカリ ハロは好きな時間に最短1時間から働ける「空き時間おしごとアプリ」です。 この記事ではメルカリ ハロを作るにあたり、どういった技術スタックやアーキテクチャを選定したのか、さらにその背景と意思決定をご紹介したいと思います。 この記事で得られること メルカリ ハロで採用されている技術スタックやアーキテクチャの全体像 その意思決定の理由とプロセス これから新規サービスを立ち上げるうえでのヒント 主な技術スタック メルカリ ハロで利用されている主な技術スタックは以下のとおりです。 バッ
米カリフォルニア州ロサンゼルスで公開された応急仮設住宅(2024年1月31日撮影)。(c)Frederic J. BROWN / AFP 【2月1日 AFP】米カリフォルニア州ロサンゼルスで1月31日、路上生活者の利用を想定して開発された応急仮設住宅が公開された。同州では近年、ホームレス問題が深刻化している。 この仮設住宅は、ギャビン・ニューサム(Gavin Newsom)州知事が推し進めるホームレス問題対策計画の一環として開発された。知事主導で行われたコンペで優勝したパレットシェルター(Pallet Shelter)社が手掛けた。 6.5平米のタイプとトイレやシンクなどが完備された11平米の2タイプがある。州内の主要都市に設置するため、今後、計1200戸が製造される予定だ。(c)AFP
本書はITエンジニアからアーキテクトを目指す方や、アーキテクトになったばかりで知識に不安がある方のために、アーキテクチャ構築の基本をいちから体系的に解説した本です。 「アーキテクチャとは何か」という原点から説明しているので、自分の今の知識や認識が正しいのかもチェックしながら学ぶことができます。 著者の米久保剛さんは、企業向けシステムのアーキテクチャ構築を手がけるITアーキテクト。本書は米久保さんが「筆者が若手だった頃にこんな本があればもっと効果的に学習を行えただろう」という知識を詰め込んだ1冊となっています。 アーキテクトの役割からアーキテクチャの設計と実装についてや、ソフトウェア設計とテストなどソフトウェアエンジニアリングに関しても解説しているので、アーキテクトに必要な幅広い知識が身につきます。 刊行記念イベントも開催されますので、こちらもぜひチェックしてみてください(本記事後半に掲載)
ジャンプTOON アプリチームの國師です。 5 月にサービスを開始した 「ジャンプTOON」 は、Flutter を採用し Android, iOS, iPadOS 向けのアプリを提供しています。 本記事では、ジャンプTOON モバイルアプリの開発で採用している技術スタックやプロジェクト構成、開発手法を紹介します。 目次 SDK・ツール管理 プロジェクト管理・タスクランナー CI・CD ディレクトリ構成 テーマ管理 ルーティング アセット管理 状態管理 サーバ通信 Lint テスト UI カタログ Web Preview PDR SDK・ツール管理 Flutter の SDK バージョン管理には、Flutter 以外の SDK やツールもまとめて管理できる asdf を採用しています。 Flutter の開発者界隈では FVM も人気ですが、次の点から、アプリチームに限らず開発チーム全体で
成果 最終的に、Cloud Run のコストが$6/day前後から$1/day前後に! ちなみに、Cloud Tasks は1ヶ月あたり最初の100万回のオペレーションまで無料なので余裕で収まっています。 モチベーション 今回リプレイスを検討したシステムは軽量な非同期処理が大半で、もともと絶対に Sidekiq でないと困るということが少なかった Sidekiq は Redis をポーリングしてジョブを取得する方式なので、Cloud Run で実行するには min-instances を1以上にしなければいけない 何もジョブがない状態が続いてインスタンスが0になると起こしてくれる人がいないので... 絶対に Sidekiq でないと困らないなら Cloud Tasksにして、非同期処理がない時は寝ていても良いようにしたい => コストダウン! Pub/Sub との比較検討もしましたが今回は
ここ数年「デザインシステム」はIT業界を中心に流行語になっていますが、どうにも「〜システム」と呼んでしまっていることと、実際にそれが指している概念がはっきりしないが故に、私にとっては積極的に使いたくない語になってしまっています。皆さんが「デザインシステム」の語で言及しているものは、本当に同じ概念を指しているのでしょうか? 定義にあたってみる「デザインシステム」「Design system」の言葉の定義を軽く調べてみました。 とりあえずWikipedia(英語)にはこのように書かれています。 デザインシステムは、任意のアプリケーションを組み立てるのに用いる再利用可能なコンポーネントと標準規約の集まりです。デザインシステムは、モバイルアプリケーションやWebサイトなどデジタルプロダクトのデザインと開発をサポートします。パターン、コンポーネントライブラリ、デザイン言語、スタイルガイド、コード化さ
会社で複数の新規事業を立ち上げる機運が高まったことをきっかけに社内向けUIライブラリを開発し、限定公開して利用を始めました。 本記事ではReactで社内向けUIライブラリを開発・ビルド・公開・布教するためのアレコレを共有します。 以下のような話題について知りたい方に特に読んでほしいです。 Private Packageの作り方、配布の方法のイメージがつかない方 CommonJSとES Modules、今はどちらでビルドするのがいいのか知りたい方 ライブラリの作り方について網羅的に知りたい方 前提 利用側のアプリケーションはNext.js固定を前提とする Tailwind CSSを内部的には利用する 利用側のアプリケーションはパフォーマンス(Lighthouseスコア)重視することが多い 社内の様々なレベルのエンジニアがContributeする可能性がある 端的に言うと、社内のプライベートリ
At Airplane, we collect observability data from our own systems as well as remote “agents” that are running in our customers’ infrastructure. The associated outputs, which include the standard “three pillars of observability” (logs, metrics, and traces) are essential for us to monitor our infrastructure and also help customers debug problems in theirs. Over the last year, we’ve made a concerted ef
レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。以前、SAGAやEventStormingについて記述すると宣言していたのですが、実際のところ私が書くよりもよっぽど良い日本語の書籍や記事がでていて、もう書く必要もないと思っていたのですが、今回機会をいただいたので約4年ぶりに”マイクロサービスとメッセージングのなぜ"の希望編を書くことになりました。今回の記事ではSAGAやEventStormingの詳細は書かないのですが、私がイベントやメッセージングが必要と考えるに至った危機感や希望を共有します。そうした意味ではむしろ原点ともいえる内容になっています。なお今回記事にはとりわけ個人的な経験や意見が多く含まれますので、事前に異論は認めることにします。 以前の記事はこちら: 「マイクロサービスとメッセージングのなぜ [概要編]」 「マイクロサービスと
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く