並び順

ブックマーク数

期間指定

  • から
  • まで

361 - 381 件 / 381件

新着順 人気順

アーキテクチャの検索結果361 - 381 件 / 381件

  • 「レイヤードアーキテクチャを意識したPHPアプリケーションの構築」を発表しました

    2015/06/27 に開催された PHPカンファレンス福岡2015 にて、「レイヤードアーキテクチャを意識したPHPアプリケーションの構築」という発表をしてきました。 MVC フレームワーク(CakePHP / Laravel)で構築したアプリケーションをレイヤードを意識して改善したという内容です。参加いただいた皆さんの顔ぶれを見ると歴戦の勇者みたいな方ばかりでしたが、和やかな雰囲気でセッションを進めることができました。ご参加ありがとうございました。 発表資料 発表資料は以下です。 MVC にサービスレイヤを追加して、それぞれの役割を意識して作る。レイヤ間の依存を明確にする。サービス(ドメイン)を中心に考える。よく言われていることなのですが、実際に実践する中で、ハマりがちなことや実際に実践してきた中で感じたことを紹介しました。もちろん、これで ok ということはないので、今後取り組んでい

    • マイクロサービスアーキテクチャ向けにサービスメッシュを提供する「Istio」の概要と環境構築、トラフィックルーティング設定 | さくらのナレッジ

      Istio環境の構築 さて、続いては実際にIstioを利用できるクラスタ環境を構築していく流れを紹介していこう。 前提条件 Istioの利用には、まずコンテナエンジンとしてDockerが必要となる。また、対応するコンテナクラスタはKubernetes(バージョン1.9以降)もしくはNomad+サービスディスカバリツールConsul環境となっている。ただし、現時点ではNomadベースのクラスタでの利用は未テストというステータスのようだ。そのため今回は独自に構築したKubernetesベースのクラスタ上でIstioを利用する流れを説明する。 なお、IstioはKubernetesのServiceやPod、Deploymentといった機能と連携して動作するようになっている。そのため、利用にはKubernetesの知識が前提となる。本記事もKubernetesに関する知識がないと理解が難しい点があ

        マイクロサービスアーキテクチャ向けにサービスメッシュを提供する「Istio」の概要と環境構築、トラフィックルーティング設定 | さくらのナレッジ
      • CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance:梅田サロン中止のお詫び、およびアーキテクチャ変更についての技術詳細レポート

        先週末に予定されていたJTPA企画の梅田さん主催オンラインサロンですが、会場に多くの人が集まるにつれてLingrが重くなってしまうという事態に陥ってしまい、まるでイベントの体をなさないまま時間が過ぎてしまい、あえなく中止となってしまいました。 当イベントを楽しみにしていた皆様、そして梅田さんはじめJTPAスタッフの方々には、本当に申し訳なかったと思います。ここに改めてお詫び申し上げます。 Macworld 2007のときには180人を収容して何の問題もなく快適に使えていたので、「1000人はわからないけど、200人ぐらいなら大丈夫だろう」とたかをくくっていたのが間違いでした。 今回はその反省も含めて、内部で検証した技術情報をすべて公開し、どのような問題に直面し、どのように解決にあたっているのかをお伝えすることで、特に技術者の皆さんに役立つフィードバックにしたいと思います。 ■今回のアーキテ

        • 大量トランザクション処理に適したアーキテクチャ ― @IT

          大量トランザクションを処理するためには、アプリケーション・サーバを複数台並べて負荷分散する一方で、マルチプロセッサのDBサーバを採用しDB処理能力を確保するアーキテクチャが用いられることが多い。さらに高い処理能力が求められる場合には、DBの並列処理やオン・メモリ処理を併用するデザインもあるが、重要なことはスケーラビリティを確保するアーキテクチャ設計と、負荷を平準化する工夫である。

            大量トランザクション処理に適したアーキテクチャ ― @IT
          • Cloud Run で作るサーバーレス アーキテクチャ 23 連発 - これのときはこう!

            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

              Cloud Run で作るサーバーレス アーキテクチャ 23 連発 - これのときはこう!
            • 電子情報学特論:Chromiumのアーキテクチャを解き明かす

              電子情報学特論: Chromium のアーキテクチャを解き明かす 〜 EEIC の授業が生きるプロダクトの世界〜 Kentaro Hara 2020 April (๑>ᴗ<๑) * * * *

                電子情報学特論:Chromiumのアーキテクチャを解き明かす
              • エンタープライズ アプリケーションアーキテクチャパターンObject oriented selection

                  エンタープライズ アプリケーションアーキテクチャパターンObject oriented selection
                • Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes

                  [追記] 途中までは Node での複数プロセス起動、プロセス間通信等について書かれていますが、後半は自分が前回の記事 を書くにあたって自分が考えてたことを少し強引に広げて書いた個人的な妄想が多く含まれ、Node におけると言っときながら、後半は Node 関係ない感じになってしまいました。 正直まだ分かっていないことが多いです。変なところをどんどん指摘していただけるとむしろ嬉しいです。 Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes の続きです。 もともと何となく結論があって書き始めたんですが、書きながら色々調べているうちによくわからなくなりました。 まだまだ調べたらないことがわかったので、とりあえず今わかっているところまで書きます。 結局何がいいたいのかよくわからない感じかもしれないけど、ゴールは SSP のバックエンドの Nod

                    Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes
                  • GoとKinesis Data Firehoseで非同期の検索基盤を構築─モノリス化した「カオナビ」はアーキテクチャ改善にどう取り組み始めたか - はてなニュース

                    社員の個性・才能を発掘し、戦略人事を加速させるタレントマネジメントシステム「カオナビ」を提供する株式会社カオナビでは、SaaS移行にあわせてクラウドを全面的に採用し、インフラの自動化などにAWSのマネージドサービスを積極活用しています。とはいえ10年近い運用で、サービス開発におけるシステムのモノリス化が課題となってきました。 こういった全社的な課題は、2020年からCTOを務める松下雅和(@matsukaz)さんを中心にCTO室で対応しています。モノリスなシステムは、全体のモジュラモノリス化を前提に、とくにボトルネックとなる検索処理を非同期の基盤サービスとして切り出しています。 この検索基盤の設計と実装を通して、カオナビはシステムのアーキテクチャ改善をどのように進めようとしているのか。非同期である必要性や、デプロイの工夫、開発組織の文化まで含めて、CTO室の千葉峻秀さんとインフラグループの

                      GoとKinesis Data Firehoseで非同期の検索基盤を構築─モノリス化した「カオナビ」はアーキテクチャ改善にどう取り組み始めたか - はてなニュース
                    • Clubhouseを支えている技術とアーキテクチャ、セキュリティについて - LayerX Research

                      #LayerX_Newsletter 2021-02-19 TL;DR Clubhouseは極めてシンプルなアーキテクチャ 音声データはAgoraを、リアルタイム性の高い情報の扱い(ルームの中など)はPubNubを利用 音声データが暗号化されていないなどセキュリティ面での課題も多い Clubhouseは招待制の音声配信SNSで、2020年Aplha Exploration社が開発したこのサービスは、つながりがある人同士でラジオ放送のように自由に会話を楽しんだり、興味ある人はその会話を傍聴、さらには会話に飛び入り参加もできる特徴がある。2021年に入り世代・国籍・性別を問わず爆発的人気となっており、日本では2021年1月からスタートアップ界隈を中心に一気に話題が広がっている。また、テスラの創業者や有名人・著名人などが利用しはじめたことで大きな注目を浴びた。今回はClubhouseはどのような

                        Clubhouseを支えている技術とアーキテクチャ、セキュリティについて - LayerX Research
                      • ログイン・ログアウト機能をサーバレスアーキテクチャで実装する - Qiita

                        ※実運用では、登録日などの項目も持たせて、セッションタイムアウト時間も設けたほうが良いです。 Lambdaファンクション ログイン処理 入力値として、emailとパスワードを受け取ります。 ログインに成功すればセッションIDを返します。webシステムで使う場合はこのセッションIDをcookieに保存して引き回してあげましょう var aws = require("aws-sdk"); var doc = require('dynamodb-doc'); var crypto = require('crypto'); var dynamo = new doc.DynamoDB(); exports.handler = function(event, context) { if ( typeof event.email === 'undefined' || typeof event.passw

                          ログイン・ログアウト機能をサーバレスアーキテクチャで実装する - Qiita
                        • キャッシュによる状態管理のアーキテクチャ / Cache-based state management architecture

                          iOSDC Japan 2022 day2 https://fortee.jp/iosdc-japan-2022/proposal/a9d5b12e-6170-4f1c-be93-9412898523a0 正規化されたキャッシュによる実装例: https://github.com/rockname/MastodonNormalizedCacheSample

                            キャッシュによる状態管理のアーキテクチャ / Cache-based state management architecture
                          • Passenger アーキテクチャ概要 (koshigoe 仮訳)

                            典型的で孤立したWebアプリケーションは、いくつかのI/OチャネルからHTTPリクエストを受け入れ、内部でそれを処理し、HTTPレスポンスを出力し、それをクライアントに送り返します。これは、アプリケーションが終了を命令されるまで繰り返し行われます。 この事は、WebアプリケーションがHTTPを直接的に話す必然性がない事を意味します: WebアプリケーションはあるHTTPリクエストの何種類かの表現を受け入れる事を意味します。

                            • アーキテクチャの「なぜ?」を記録する!ADRってなんぞや? - Qiita

                              5月のThoughtWorksのTechnology RadarでもADOPTされたADRという手法について、面白かったので、ざっくり自分なりに調べたメモです。 Technology Radarでは以下のように述べられています。 多くのドキュメントは、読みやすいコードとテストに置き換えることができます。しかし、進化的アーキテクチャでは、将来のチームメンバーの利益と外部の監督のために、特定の設計上の決定を記録することが重要です。Lightweight Architecture Decision Recordsは、重要なアーキテクチャー決定を、そのコンテキストおよび結果と共に取り込むための技法です。これらの詳細は、WikiやWebサイトではなくソース管理に格納することをお勧めします。そうすれば、コードと同期したままのレコードを提供できるからです。ほとんどのプロジェクトでは、この手法を使いたくな

                                アーキテクチャの「なぜ?」を記録する!ADRってなんぞや? - Qiita
                              • IBM LAMP システムを調整する、第 1 回: LAMP アーキテクチャー・・ - Japan

                                IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

                                  IBM LAMP システムを調整する、第 1 回: LAMP アーキテクチャー・・ - Japan
                                • タベリーを支えるアーキテクチャ - Koichi Ishida blog

                                  目次 アーキテクチャ フロントエンド・バックエンドアーキテクチャ 分析アーキテクチャ レコメンデーションアーキテクチャ 最後に 「タベリー」は株式会社10Xが提供するパーソナルな献立を推薦するアプリです。iOSとAndroidとWebで提供しています。先日、プレスリリースで「オンライン注文機能リリース」と「2.5億円の第三者割当増資を実施したこと」をお知らせしました。献立作成、献立からの買い物リスト作成、買い物リストをネットスーパーで注文、料理を作るということがタベリー1つでできます。特にこの「オンライン注文機能」はいままでネットスーパーの商品を1つ1つ選択して注文していたものを、自動でカートに追加し注文できるのでとても便利です。 10Xではよりよいチームを目指しメンバーを募っています。エンジニアも募集しています。チームがどのように開発しているかは社長の矢本さんが書いた「10Xなプロダクト

                                    タベリーを支えるアーキテクチャ - Koichi Ishida blog
                                  • Vuex + DDD のアーキテクチャを考える - Techtouch Developers Blog

                                    フロントエンドエンジニアの国定です。 この記事では、TypeScript + Vue.js で開発しているフロントエンドに今年からドメイン駆動設計(DDD)を取り入れ始め、ひとまず設計が落ち着いてきたのでその経緯とアーキテクチャについて解説します。 課題 アーキテクチャ Domain Service Store(Vuex) UI(Vue.js) 軽量DDDに陥らないために まとめ 課題 Vuex(Store)の責務は、エラー判定などのドメインロジック・データの永続化・API の呼び出しなど、State 管理のほかにも多岐にわたっています。UI の改善や機能追加など変化の多いフロントエンドでは開発が進むにつれ Vue + Vuex のあちこちに同じ処理が散在してしまいます。 テックタッチでもメンテナンスを繰り返す度にコードの複雑さが増し、機能追加や修正に時間がかかるようになってきました。去年

                                      Vuex + DDD のアーキテクチャを考える - Techtouch Developers Blog
                                    • 大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント

                                      バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門(@IT) バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え

                                        大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント
                                      • Almin.js | JavaScriptアーキテクチャ

                                        autoscale: true Almin.js | JavaScriptアーキテクチャ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 中規模以上のJavaScript 設計が必要になる 正しい設計はない Bikeshed.js :bike: 人、目的、何を作るかによってアーキテクチャは異なる 前回の続き? How to work as a Team Read/Write Stack | JavaScriptアーキテクチャ 用語 設計の目的 中規模以上のウェブアプリ SPAというよりは、画面が複雑なElectronアプリのようなイメージ スケーラブル 人、機能追加、柔軟性、独立性 見た目が複雑ではないアーキテクチャ 書き方が特殊ではなく見て分かるもの 設計の目的 テストが自然に書ける パーツごとに無理なく

                                        • 負け組なモバイルWebは、これから本当に復活するのか?Googleが考える次のアーキテクチャ - ふろしき Blog

                                          Google I/O 2015でのセッション「The Next Generation Mobile Web(次世代のモバイルWeb)」がそこそこに激アツな気がしたのですが、予想に反し、あまり注目を集めていません。 わかります。大衆向けなメディアだと、AndroidやVR/AR、Google Photosのようなわかりやすいキーワードの方が注目されるでしょう。エンジニア向けメディアであっても、昨今のモバイル技術の状況を鑑みて、ネイティブアプリの方を扱いたいと感じるのが当然です。 先日、某懇親会で「え、モバイルをWebでやっているのですか?それ、完全に負け組じゃないですか」と言われ、そこまで印象が悪いものかと心を痛めました。負け組とか、Webがかわいそうじゃないか。 そんな状況というのもありまして、先日の「第58回HTML5とか勉強会」では、あえてGoogleらが考える「次世代モバイルWeb」

                                            負け組なモバイルWebは、これから本当に復活するのか?Googleが考える次のアーキテクチャ - ふろしき Blog
                                          • クラウド時代のアーキテクチャ設計

                                            The document discusses Amazon Web Services (AWS). It begins with an introduction and overview of key AWS services including Elastic Compute Cloud (EC2), Simple Storage Service (S3), Elastic Block Store (EBS), Relational Database Service (RDS), and availability zones. It then provides demonstrations of setting up EC2 instances, load balancing, auto scaling, virtual private clouds and RDS across ava

                                              クラウド時代のアーキテクチャ設計