並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 497件

新着順 人気順

マイクロサービスの検索結果121 - 160 件 / 497件

  • マイクロサービスに次に来るかもしれない言葉について - arclamp

    2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て

      マイクロサービスに次に来るかもしれない言葉について - arclamp
    • https://twitter.com/at_sushi_/status/1592673880313057280

        https://twitter.com/at_sushi_/status/1592673880313057280
      • ソフトウェア設計の Why & What & How | Wantedly Engineer Blog

        こんにちは、開発チームのアーキテクトをやっている竹野(@Altech)です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して

          ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
        • ソフトウェア設計のトレードオフと誤り

          「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設計、時刻の扱い、データローカリティのようなシステム寄りの話題、またライブラリの選択、分散システムの一貫性と原子性、バージョニングのようなより抽象度の高い内容まで、さまざまなシチュエーションにおけるトレードオフの実態と、その失敗例をとり上げます。 本書は日々のプログラミングにおける解決策のヒントを得るだけでなく、より幅広い設計上の知見を広める上でも役に立つでしょう。 正誤表 ここで紹介する正誤表には、書籍発行

            ソフトウェア設計のトレードオフと誤り
          • 【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly(ギークリー) IT・Web・ゲーム業界専門の人材紹介会社

            『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD(Domain-Driven Design)を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め

            • アプリケーションにおけるデータ不整合との戦い - blog.syfm

              これは Aizu Advent Calendar 2019 の 15 日目の記事です。14 日目は uzimaru0000 さん、16 日目は kacky__917 さんです。 はじめに 世の中には日々たくさんの価値ある Web サービスが生まれていますが、その価値を正しく提供するにはアプリケーションが正しく動かなければなりません。 たとえばアプリケーションは適切なユーザに適切なリソースを提供しなければならず、エラーを返す際は十分に定義された仕様に沿って返し、UI 側ではユーザに適切なメッセージを表示しなければなりません。 実際のところ、これらを厳密に実現するのは非常に困難ですが、アプリケーションにはこれら以上に複雑な問題が常につきまといます。 現在の Web アプリケーションはほとんどが分散システムの一形態です。例えばクライアントとサーバや、サーバとデータベースがネットワークを介して接続

                アプリケーションにおけるデータ不整合との戦い - blog.syfm
              • SREやクラウドエンジニアが読むと良さげな本まとめ - Qiita

                一年半ぐらい前にアプリケーションエンジニアからSREにコンバートした筆者が、いま役に立ってるなぁっていう本を紹介します。アプリケーションコードを書いてるときは下のレイヤの技術に興味なかったんですが、改めて勉強してみると楽しいです。 コンピュータシステム クラウド全盛とはいえ、コンピュータの仕組みはおさえておくと役立ちます。コレ系の本はわりと小難しいものが多いですが、個人的に楽しく読めた本を紹介します。 Raspberry Piで学ぶコンピュータアーキテクチャ Raspberry Piと銘打たれてますが、コンピュータアーキテクチャの歴史的な背景も踏まえて解説されています。プロセッサ・メモリ・ストレージ・ネットワーク・OS・プログラミングなど、コンピュータ単体の基本的な知識を学べます。 歴史をあわせて知ることができるため、知的好奇心がおおいに刺激され、楽しく読むことができます。この本が難しく感

                  SREやクラウドエンジニアが読むと良さげな本まとめ - Qiita
                • Treasure Data を退職しました - k0kubun's blog

                  約5年5か月働いたTreasure Dataを7/22に退職した。7/25からShopifyに入社し、RustでJITコンパイラを開発してRubyを高速化する仕事をする。 仕事としてやりたい分野が変わってきて自分は今回転職したけど、とても良い会社なので、この記事がTreasure Data (以下TD) で働くことに興味がある人の参考になれば良いと思っている。*1 5年勤続記念にいただいたトロフィー やっていたこと APIチーム 元々TDにはJavaで分散システムを書きたくて入社したのだが、TD入社前に特にそういう経験があるわけでもなく主にRailsをやっていたこともあり、Railsでプラットフォームを開発するチームに入った。基盤開発をやりたいと思いながらサービス開発者として最初働き、後に基盤開発チームにジョインするみたいな過去の経験があったので、今回もそういう感じでいけると考えていた。実

                    Treasure Data を退職しました - k0kubun's blog
                  • Herokuの代替サービス30選、使ってみた参考記事リンク付き - Qiita

                    先日Herokuの完全有償化が発表されて以降、蜘蛛の子を散らすようにHerokuからの脱出が図られています。 そんなわけで概ねHerokuの代替となりそうな無料サービスを紹介していきます。 ほとんどの代替サービスは完全無料というわけではなく、機能の少ない無料プランと高機能の有料プランが存在します。 有料化前のHerokuと同じということですね。 各サービスについて、実際に使ってみたという参考記事を貼っておくので、実際の使い勝手等はそちらを参照してください(他力本願) Qiita内に使ってみた記事が見つからなかったサービスは、日本では人気がないのだろうということで選外にしました。 また概要は、各サービスの説明やドキュメントに記載されているものです。 代替サービス一覧 FLy Flyはグローバルなアプリケーション配布プラットフォームです。 Turbokuを使えばHerokuアプリをFly.io

                      Herokuの代替サービス30選、使ってみた参考記事リンク付き - Qiita
                    • 株式会社メルペイを退職します: 柴田 芳樹 (Yoshiki Shibata)

                      2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。 週4日勤務「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました(週4日勤務で働くことに関して、入社前に合意してもらっていました)。10月からの会社では、週4日勤務の雇用契約で働きます。 初めてのウェブサービス開発富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に

                        株式会社メルペイを退職します: 柴田 芳樹 (Yoshiki Shibata)
                      • スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services

                        AWS Startup ブログ スタートアップのためのコンテナ入門 – Kubernetes 編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 「スタートアップのためのコンテナ入門 – 導入編」「スタートアップためのコンテナ入門 – AWS Fargate 編」という記事を公開してきましたが、Kubernetes に興味があるスタートアップも多いのではないでしょうか。今回は Kubernetes にフォーカスしてお話しします。 なお Kubernetes 以前に、「そろそろコンテナやった方がいいか?」「なんとなく使い始めたけれどこれでいいのか?」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。 目次 Kub

                          スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services
                        • マイクロサービス化は本当に難しい

                          はじめに この記事は、AEON Advent Calendar 2023の21日目です🎉 イオンスマートテクノロジー株式会社(通称AST)のCTO室TechLeadチームの@t0doroki_takaです。弊社ではSREチームの発信に勢いがありますが、アプリケーションレイヤーよりの話題も積極的に発信していければと思います。 自分の敗戦の振り返り 以前、大規模ECシステムのリプレース案件に関わった時(そして敗戦したとき)の振り返りです。 今回取り上げるケーススタディは、システム全体(連係するシステム含む)としては段階的移行ではありましたが、主ターゲットとなるシステムは、全EC機能を包括する大規模なシステムで、それをフルスクラッチでリプレースするものでした。 巨大なモノリス構造であったため、マイクロサービスアーキテクチャに移行することで、サービス提供のアジリティを確保することが目的の一つでし

                            マイクロサービス化は本当に難しい
                          • 任天堂:新しい汎用ゲームサーバーを Google Kubernetes Engine、Cloud Spanner などを駆使して構築 | Google Cloud 公式ブログ

                            任天堂:新しい汎用ゲームサーバーを Google Kubernetes Engine、Cloud Spanner などを駆使して構築 世界中で愛好されている任天堂株式会社(以下、任天堂)の家庭用ゲーム機「Nintendo Switch」。そのオンライン マルチプレイを担う汎用ゲームサーバーの動作基盤に新たに Google Cloud が採用されました。多くのユーザーとの通信を処理しなければならないこの仕組みを、なぜ Google Cloud 上に構築したのか。どのような工夫を施すことで、安定性・可用性と運用負担の軽減を両立させたのか。構築に携わったエンジニアのお二人に話を伺いました。 利用しているサービス: Google Kubernetes Engine、Agones、Anthos Service Mesh、Cloud Spanner、Cloud Load Balancing、Cloud

                              任天堂:新しい汎用ゲームサーバーを Google Kubernetes Engine、Cloud Spanner などを駆使して構築 | Google Cloud 公式ブログ
                            • 単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ

                              はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう! 単体(unit)テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを

                                単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ
                              • 老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦! 出前館の改善について和田卓人さんが聞いた - はてなニュース

                                新型コロナウイルスの影響下で、食の宅配などO2O(Online to Offline)サービスが好調です。なかでも有名漫才師を起用したテレビCMも話題となった出前館は、2020年8月期の連結決算で利用者数が前期比で31%増、売上高も前期比で54.6%増となりました(ただし広告展開やシステム投資などの先行投資により営業利益は赤字となっています)。 この背景に、株式会社出前館とLINE株式会社が2020年3月に締結した資本業務提携があります。LINEが出前館の経営に参画し、広告だけでなくサービスの提携も進んでいます。2020年11月には「出前館」アプリがLINEアカウントと連携し、出前館のOEMだったLINEデリマは12月にサービス統合されました。 ただしLINEでは、出前館を「LINE」アプリの関連サービスではなく、独立したO2O事業として継続的に成長させたい。そのためLINEのエンジニアを

                                  老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦! 出前館の改善について和田卓人さんが聞いた - はてなニュース
                                • モダンなテストレベル設計(ユニットテスト~システムテスト等をどう設計するか)の原則 - 千里霧中

                                  プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 (Vモデルが必須と明言しているわけではなく、極端な例ですが)例え

                                    モダンなテストレベル設計(ユニットテスト~システムテスト等をどう設計するか)の原則 - 千里霧中
                                  • サーバーレスの次はなんなんだ

                                    はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい!」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください! メガクラウドと特化型クラウド/ハイパーバイザーのSoC化/ライセンスとクラウドベンダー/イベント駆動型API/LLM時代のAIペアプロ力/生活必需品としてのGPU・NPU/Passkey/ウェブアクセシビリティ/リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS(Function-as-a-Ser

                                      サーバーレスの次はなんなんだ
                                    • 5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる

                                      はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、

                                        5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
                                      • よりよくわかる認証と認可 | DevelopersIO

                                        少し早いですが、メリークリスマス!事業開発部の早川です。 早いもので、入社して 1 ヶ月半が経ちました。 現在は、 prismatix の理解を深めながら、導入支援を行っています。 今回はその中から、認証 / 認可についてお伝えします。 と言っても、これまでに同僚達が書いた分かりやすい記事がありますので、これらのガイダンスの形で、整理していきたいと思います。 ジョインしました 以来、初めての記事となりますドキドキ 目標 本記事をご覧いただいた後、こちらのスライドを何となく理解できる気がすることを目標とします。 本スライドに関するブログ記事はこちらです。 AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay 目的 まず、認証 / 認可を学ぶ理由を考えてみました。 近年、様々なサービスが API を通じてつながり、より便利

                                          よりよくわかる認証と認可 | DevelopersIO
                                        • 作者冥利に尽きる - ゆーすけべー日記

                                          会社の朝会で話す番が回ってくる。 メンバーが入れ違いで自己紹介をするんだけど、 それに加えて「自分なりのこだわり」みたいなことを話す流れになっている。 自分の場合、つくってきたもの紹介とそれから学んだこと、みたいなのはどうだろうか。 結局こういうキーワードが出た。 作者冥利に尽きる。 今まで原動力になっていたのは、 プロダクトを使ってもらって嬉しい反応をもらうことだ。 なので「もしよろしければ、みなさんも(一緒に、じゃなくてもいいけど)作者冥利に尽きる体験をしましょう」 という流れにしようかと。上からだけど、まぁありでしょう。 で、作者冥利に尽きるにはどうすればいいか。メモを残す。 つくってきたもの いわゆる「個人開発」というものをやってきた。 特にWebサービスをたくさんつくってきた。数えたらエロ含めて70個、除いて48個だった。 以下のスライドで全部網羅してある。 僕がつくった 70個

                                            作者冥利に尽きる - ゆーすけべー日記
                                          • Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開

                                            Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開 Googleは分散アプリケーションの開発とデプロイを容易にするフレームワーク「Service Weaver」をオープンソースで公開しました。 Introducing Service Weaver! Service Weaver is an open source framework for building and deploying distributed applications. It allows you to write your application as a modular monolith and deploy as a set of microservices. Learn more → https://t.co/XmnVALYXNC pic

                                              Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開
                                            • ソフトウェアアーキテクチャ入門

                                              はじめに 今回の記事では、ソフトウェアアーキテクチャの入門的な内容を解説する。 対象とする読者 ソフトウェアアーキテクチャを勉強するエンジニア アーキテクチャに関して全くわからない初心者 タイトルで気になったひと ソフトウェアアーキテクチャとは? ソフトウェアのアーキテクチャは、システムの主要なコンポーネント、それらの関係(構造)、およびそれらがどのように相互作用するかを記述する。ソフトウェアのアーキテクチャとデザインには、品質属性、人間のダイナミクス、デザイン、IT環境など、多種多様な寄与要因が含まれる。アーキテクチャは、品質、保守性、パフォーマンス等のような全体的な成功に影響を与える重要な決定を含む。 ソフトウェアアーキテクチャの主な目的は、アプリケーションの構造に影響を与える要件を特定することだ。良好なアーキテクチャは、技術的な解決策を構築する際のビジネスリスクを削減し、ビジネス要件

                                                ソフトウェアアーキテクチャ入門
                                              • みんなの銀行:日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現 | Google Cloud Blog

                                                みんなの銀行:日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現 2021 年 5 月にサービス提供を開始した「みんなの銀行」は、デジタル ネイティブ世代をターゲットとしたスマートフォン専業銀行。金融にまつわる煩わしさを排除し、ゼロベースでこれからの銀行に求められる機能を開発・提供していくと打ち出しています。そんな同行の大きな技術的トピックの 1 つが、勘定系システムにパブリッククラウドを採用したこと。これはもちろん国内初*の試みです。ここではサービス開始後の手応えをシステム構築をリードしてきた皆さんにお伺いしました。 利用している Google Cloud ソリューション: Google Cloud Databases、Stream Analytics 利用している Google Cloud

                                                  みんなの銀行:日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現 | Google Cloud Blog
                                                • 弁護士ドットコムサービスでモノリスをマイクロサービス化しようとして失敗した原因を振り返る - 弁護士ドットコム株式会社 Creators’ blog

                                                  初めまして。弁護士ドットコム株式会社でエンジニアをやっている井出です。 弊社は 2022 年 2 月から Creator's Blog を始めております。 その記念すべき最初の記事として 弁護士ドットコムサービスのビジネスと共にみるマイクロサービスの進化 を投稿いたしました。 こちらの記事で弊社がマイクロサービス化に挑戦したこと、その後の課題をどう解決していったかについて分かりやすくまとめられておりますので、ぜひ一読してから今回の記事を読んでみていただければと思います。 さて、上記記事内でも触れられているとおりマイクロサービス化プロジェクトである Gavel プロジェクトでは様々な課題が出てきました。 今回はその中の 1 つである、 ビジネス分析が不十分で一部のサービス境界が想定と異なり、開発速度が低下 について、何をどう間違え、なぜ開発速度が低下したのかについて振り返ります。 もしこれか

                                                    弁護士ドットコムサービスでモノリスをマイクロサービス化しようとして失敗した原因を振り返る - 弁護士ドットコム株式会社 Creators’ blog
                                                  • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

                                                    公開日 2024/05/28更新日 2024/07/25注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女

                                                      注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
                                                    • アルパカ証券 技術ノート|アルパカ証券の裏側 - はじめに

                                                      こんにちは。shirou(@r_rudi) と申します。アーキテクトという名の雑用係をしています。 Alpaca Japanでは、2021年8月に「アルパカ証券」という証券サービスをはじめました。 この一連の文章は、アルパカ証券の裏側のシステムやその開発体制などについて述べたものです。なるべく証券分野に限らず説明していく予定ですので、証券サービスを立ち上げようとしている人たちにはもちろん、それ以外の方にも参考にしていただけるような文章を目指したいと思っています。 アルパカ証券とはアルパカ証券の詳細はホームページをご覧ください。また、第一種金融商品取引業者登録完了時のプレスリリースにも、「アルパカ証券」サービスの特徴が記載されています。 全体設計方針まず最初に、アルパカ証券を構成するシステムの全体設計方針について説明します。 マイクロサービス vs モノリシック設計は2018年中頃ぐらいから

                                                        アルパカ証券 技術ノート|アルパカ証券の裏側 - はじめに
                                                      • マスタリングAPIアーキテクチャ

                                                        この10年の間に、ソフトウェア開発を行う方法は大きく変容しました。作業に依存関係が生じるモノリシックなアーキテクチャから、APIによるマイクロサービスアーキテクチャが主役となりつつあります。一度構築すれば終わりではなく、変化とスピード、生産性の向上に対応するため、APIの設計、構築、運用、変更に関するニーズはますます高まっています。 本書は、モダンなAPI駆動型アーキテクチャについて解説する書籍です。既存のモノリシックアーキテクチャから、どのようにAPI駆動型のシステムへ発展させていくかを、カンファレンスシステムを例に、具体的なケーススタディを通してわかりやすく解説しています。REST APIの基礎から、最適な設計、構築、運用、バージョン管理、およびテスト方法まで、API設計と改善の全体像をしっかり学ぶことができます。また、APIゲートウェイ、サービスメッシュなどの技術を用いて、外部トラフ

                                                          マスタリングAPIアーキテクチャ
                                                        • ZOZOTOWNのWebホーム画面をNext.jsでリプレイスして得た知見 - ZOZO TECH BLOG

                                                          はじめに ZOZOTOWN開発本部の武井と申します。ZOZOTOWNのフロントエンドリプレイスプロジェクトを主に担当しております。ZOZO DEVELOPERS BLOG でも「ZOZOのリプレイスプロジェクトで得られる唯一無二の経験。大規模サービスを進化させるやりがいとは」というインタビュー記事を掲載しておりますので、もしよろしければこちらも併せてご覧ください。 さて、本題です。現在ZOZOTOWNではオンプレミスかつ、モノリスだった既存システムをマイクロサービスAPIに責務を分割したり、インフラをクラウドに移行したりしています。しかし、いわゆるWebのUIを構築するためのシステムは現在も既存システムに新機能開発や機能改修を行なっており、リプレイスに着手できていませんでした。 そこで、まずホーム画面から段階的にリプレイスすべく設計・開発を昨年から行ない、無事リリースできました。ZOZOT

                                                            ZOZOTOWNのWebホーム画面をNext.jsでリプレイスして得た知見 - ZOZO TECH BLOG
                                                          • すぐに役に立つものはすぐに陳腐化してしまうから方法ではなく設計の本を読む - API Design Patterns の読書感想文 - じゃあ、おうちで学べる

                                                            あなたがさっきまで読んでいた技術的に役立つ記事は、10年後も使えるでしょうか?ほとんどの場合でいいえ はじめに 短期的に効果的な手法や知識は、ソフトウェア開発の分野において、急速に価値を失う傾向があります。この現象は、私たちが何を重点的に学ぶべきかを示唆しています。最も重要なのは、第一に基本的な原理・原則、そして第二に方法論です。特定の状況にのみ適用可能な知識や即座に結果を出すテクニックは、長期的には有用性を失う可能性が高いです。これは、技術や手法が時間とともに進化し、変化していくためです。 learning.oreilly.com 「API Design Patterns」は、このような考え方を体現した書籍です。しかも480 ページもあります。本書は単なる手法の列挙ではなく、Web APIデザインの根幹をなす原則と哲学を探求しています。著者のJJ Geewax氏は、APIを「コンピュータ

                                                              すぐに役に立つものはすぐに陳腐化してしまうから方法ではなく設計の本を読む - API Design Patterns の読書感想文 - じゃあ、おうちで学べる
                                                            • サーブレットを「JavaでのWebアプリケーションの基礎」として最初に勉強させるのをやめてあげてほしい - きしだのHatena

                                                              研修がはじまるという画像でサーブレットJSPの本が並んでて、サーブレットを最初に勉強させるのをやめてあげてほしいと思った話。 オブジェクト指向もそうなんだけど、現状で使わなくなっているにもかかわらず情報更新がされずオブジェクト指向やサーブレットJSPが教えられ続け本が売り続けられるという現状がある。 でももうさすがに変わってほしさ。 ただ、JSPはそこまで悪くないので、サーブレットで話を進める。(ただし、サーブレットが動かない環境ではJSPは動かない) 使われていない まず、いまの案件の多くがSpring / Spring Bootになってて、サーブレットをさわるということは少ない。 2020年のJetBrainsの調査ではこんな感じ https://blog.jetbrains.com/ja/idea/2020/10/a-picture-of-java-in-2020-ja/ 2021年

                                                                サーブレットを「JavaでのWebアプリケーションの基礎」として最初に勉強させるのをやめてあげてほしい - きしだのHatena
                                                              • Production Ready GraphQLはGraphQLを採用するなら必ず読んでおきたい良書

                                                                タイトルのとおりです。この本を読まずにGraphQLについての記事を書いたりしツイートしてたのが恥ずかしいくらいに良質なプラクティスが記載されています。GraphQLを採用して悩むことのほとんどはこの本に書いてあるくらいな印象で、この本を読むと効率よくGraphQLを使った開発の品質を向上できると思います。 どんな人が書いた本なのか 著者はMarc-André Girouxという方で、GitHubとShopifyに勤務しGraphQL APIを開発する仕事をしていたと書籍に書いてあります。GraphQLをやってる人ならこの時点でもう刺さったかもしれませんが、どちらの企業もGraphQLを採用していることで有名です。GraphQLスキーマを設計する上でGitHubやShopifyのスキーマや記事を参考にする方も多いのではないでしょうか。その両方で働いてたという時点で納得の説得力です。Grap

                                                                  Production Ready GraphQLはGraphQLを採用するなら必ず読んでおきたい良書
                                                                • Only My Rails Way

                                                                  これは何 「Rails Wayに沿って〜」とはReview欄などでよく言われるが、定義が人によってぶれている気がするので俺のRails Wayを示した記事です。 もはや本来のモノとは別物かも知れませんが、俺はこういう観点でRailsをみて、コードを書いているよ、ということを知ってもらう意味でもこの記事を公開することにしました。 前提として、「数人以上のチームでプロダクトを実際に開発して運用する」場合の自分のスタンスを示したものです。(私も仕事では独自DSLは書きませんが自由研究用途なら自分も独自DSLを書いたりします。) それでは、いってみましょう。 Model層 データベースの操作およびビジネスロジックを記述する。 テーブルの属性は原則NOT NULLにするべき。どうしても要件上NULLを許容しなければならない場合のみNULLを許容する。 Controllerからparamsを無思考で渡

                                                                    Only My Rails Way
                                                                  • モノリス分割はこうやる!「How to break a Monolith into Microservices」を読んだ - kakakakakku blog

                                                                    研修中に「マイクロサービス」の解説をしていると,たまに「モノリス分割」に関する質問が出てディスカッションをすることがある.当然ながら万能な分割アプローチはないけど,例えば DDD (Domain-driven design) などのアプローチを選択するなど,選択肢はいろいろある.そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ. 具体的には以下の「計8種類」のアプローチが紹介されている.原著を翻訳するのではなく,あくまで個人的なメモとしてまとめる.なお,日本語も個人的に載せているため,参考程度にしてもらればと! Warm Up with a Simple and Fairly Decoupled Capability(シンプルかつ分離された機能で準

                                                                      モノリス分割はこうやる!「How to break a Monolith into Microservices」を読んだ - kakakakakku blog
                                                                    • 2021年サーバーサイドのエンジニアが使ってよかったもの10選 - KAYAC engineers' blog

                                                                      こんにちは! Tech KAYAC Advent Calendar 2021 7日目を担当する荒賀(@ken39arg) です。 カヤックのエンジニアブログには2008年にPHPを使ったガラケー関連の記事を書いたのが最初になります。 それから10年以上たち、ガラケーも弊社でのPHPのプロジェクトもほぼなくなり、メンバーもかなり入れ替わり、私自身も20代だったのがついに40歳になりました。そんな私にとってこのアドベントカレンダーは私は今でもここにいるよというPingのような役割になっているため、年に一度若者に混じってアドベントカレンダーに参加しております。 例年ですと、趣味のマラソンなどに関する実績も書いているのですが、昨年同様、今年も続くコロナ禍により多くの大会が中止となったためこちらに関しては特に特記すべき実績はありません。ただ2020年に走るはずだった東京マラソンは権利は移行を続けてお

                                                                        2021年サーバーサイドのエンジニアが使ってよかったもの10選 - KAYAC engineers' blog
                                                                      • 「象・死んだ魚・嘔吐」をやってみた振り返り - JX通信社エンジニアブログ

                                                                        こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法(原題: The Airbnb Story)の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう?ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。

                                                                          「象・死んだ魚・嘔吐」をやってみた振り返り - JX通信社エンジニアブログ
                                                                        • クリーンアーキテクチャの功罪

                                                                          クリーンアーキテクチャというと設計における銀の弾丸のように扱われていて、クリーンアーキテクチャを導入するという記事をよく見ます。しかし自分の経験だとクリーンアーキテクチャで書かれているのにもかかわらず開発効率が落ちているという事が多く、いつでも使っておけばいいというものではないと思っています。 最近目にしたクリーンアーキテクチャに対する批判 本筋ではないので詳細は省きますが、あるとき[1][2]にUncle Bobの著書であるCleanシリーズへの批判をXで見ました。 ここで一番載せたかったものが今見つけられないのですが、以下のようなポストがありました。 書籍クリーンアーキテクチャに書いてある内容を抜きにして起こった現象だけを見るとマイナスの方が多い このポストが自分の感じていることを端的に表現できているように感じました。書籍クリーンアーキテクチャの内容を悪いと思いませんが、その影響により

                                                                            クリーンアーキテクチャの功罪
                                                                          • GPTが出した回答の確からしさを見えるようにしてみる - Taste of Tech Topics

                                                                            皆さんこんにちは。データサイエンティストチームYAMALEXのSsk1029Takashiです。 YAMALEXは Acroquest 社内で発足した、会社の未来の技術を創る、機械学習がメインテーマのデータサイエンスチームです。 この記事はGPTでチャットボットを作ってみるシリーズ第3弾です。 第1弾と第2弾もぜひご覧ください。 acro-engineer.hatenablog.com acro-engineer.hatenablog.com 第1弾では、GPTになるべく正確な回答をさせるために、回答の情報を持つ文書を検索し、それをもとに回答を生成するという内容を試しました。 文書をもとに回答を生成することで比較的正確な回答を取得することができました。 ただし、この回答も必ずしも正確な回答とは限らないので、どれくらい信頼していいのかを自動で判定する仕組みが欲しくなります。 今回は第1弾のシ

                                                                              GPTが出した回答の確からしさを見えるようにしてみる - Taste of Tech Topics
                                                                            • マイクロサービス時代のセッション管理 - Retty Tech Blog

                                                                              この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、

                                                                                マイクロサービス時代のセッション管理 - Retty Tech Blog
                                                                              • 技術書は気に入った一節を見つけるだけでいい

                                                                                ということで、私の例をいくつか出してみようと思います。 モノリスからマイクロサービスへ マイクロサービス・アーキテクチャの著者による、モノリスからの移行をガイドするような雰囲気のするこの本ですが、この本は第6章「終わり」にから、この一節です: 他人の事例から学ぶべき教訓があるのは事実だが、自分のコンテキストでうまく機能するアプローチを見つけるには、時間をかけなければならない。 これはあらゆるプラクティスに言えることで、私は事あるごとに「スクラムをそのまま導入するのは無駄だ」とか「守破離っていうやつは苦手だ」とか言い続けているんですが、それはつまり、先人のプラクティスは様々な状況(コンテキスト)があるなかで成功した事例であり、コンテキストが異なる現場に持ち込んでもうまく機能するかは未知なのです。なので、そのプラクティスが前提としているコンテキストとソリューションを理解しつつ、自分たちのコンテ

                                                                                  技術書は気に入った一節を見つけるだけでいい
                                                                                • 簡単にオリジナルChatGPTアプリが作れる『GPTs』で、ドット絵生成チャットを作成 - Taste of Tech Topics

                                                                                  こんにちは、安部です。 11月なのに暑かったり寒かったしますが、皆様いかがお過ごしでしょうか。 さて、先日のOpenAI DevDay、大変な盛り上がりでしたね。 様々な新機能が公開され、GPT関連がさらなるパワーアップを遂げました。 DevDayは基本的に開発者向けのイベントですが、一般ユーザ向けの新機能も公開されました。 それがGPTsです。 今回は、GPTsが使えるようになったので試してみたいと思います。 GPTsとは GPTsとは、GPT Builderを使ってノーコードで簡単にChatGPTをカスタマイズできるサービスで、今のところ有料ユーザのみが使用できます。 ChatGPTは特定タスク向けのサービスではありませんが、精度の良い回答をもらおうと思ったらプロンプトを工夫したり事前情報をたくさん与えないといけなかったりしますよね? GPTsは、あらかじめ特定の目的を持たせたChat

                                                                                    簡単にオリジナルChatGPTアプリが作れる『GPTs』で、ドット絵生成チャットを作成 - Taste of Tech Topics