タグ

architectureに関するmoronbeeのブックマーク (15)

  • MacBookPro M2MAXを買った|shi3z

    MacBookAir M1を愛用していた。 軽くて小さくて高性能。まさに相棒。好きだった。いまでも好きだけれども。 しかし、3年前にMBAを買った時には全く想定していない使い方をするようになった。なぜかWebサービスを作る日々に戻ってしまったのである。 これも、ChatGPTとか使うと恐ろしくはかどる。 SublimeTextちゃんを長年愛用してきたが、GPT4との接続性を考えるとVSCodeに変更せざるを得ない。ファイラー付いてた方が便利だし。 Webサービスに限らず、何らかのフロントエンドを含むものを作る時の大原則は、画面がでかいということである。 次の問題は、ストレージだった。 MBAのストレージは2TB。これでもとうじは積めるだけ積んでいた。 今もMBAは2TBが限界じゃないかな。 しかし2TBが埋まってしまった。 僕は職業柄、UberEats配達員のとき以外は講演とかをすることが

    MacBookPro M2MAXを買った|shi3z
    moronbee
    moronbee 2023/03/19
    単純にPC買い替えた話かと思ったら、xPUアーキテクチャやビジネス特許、今後の予想までありとても興味深い内容だった
  • 変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ!」という答えはない。 プログラミング言語や、フレー

    変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
    moronbee
    moronbee 2019/01/03
    これは良いテキスト(と先生)。自分も同じ感覚 // Webアプリ層の設計の話→その後の生存コストに効いてくる。ただ、ビジネスが生み出す利益orコスト効果とは別の話(ここ注意)
  • マイクロサービスアーキテクチャとそれを支える技術 | さくらのナレッジ

    最近では「マイクロサービス」と呼ばれる、機能毎に細かくサービスを分割して開発や運用を行うアーキテクチャの採用例が増えている。記事ではこのマイクロサービスアーキテクチャや、それに使われる技術について紹介する。 マイクロサービスとは 近年、ITシステムの開発・運用において「Microservice(マイクロサービス)」というアーキテクチャを採用する例が増えている。マイクロサービスアーキテクチャは、簡単に言えばサービスを構成する各要素を「マイクロサービス」と呼ばれる独立した小さなコンポーネントとして実装するという手法で、2011年ごろから提唱されているものだ。 マイクロサービスについては、2014年に公開された「Microservices」という文書が有名だ(有志による日語訳)。また、さくらのナレッジでも2015年に紹介されている。マイクロサービスの詳しい思想についてはこれら記事を参照してほ

    マイクロサービスアーキテクチャとそれを支える技術 | さくらのナレッジ
  • クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた - Qiita

    はじめに クリーンアーキテクチャの書籍を読んだので、実際にクリーンアーキテクチャの考え方を採用したREST APIGO言語で実装してみた。 ↓↓↓↓ソースコード↓↓↓↓ https://github.com/yoshinorihisakawa/sample-api-hoop/tree/develop この記事ではクリーンアーキテクチャの説明というよりかは、実装ベースの実践的な内容にしている。 対象読者 ・クリーンアーキテクチャで実装されたソースコードを理解したい人 ・クリーンアーキテクチャの右下の図がよくわからない人 ・アーキテクチャについて勉強を始めた初心者 クリーンアーキテクチャとは? クリーンアーキテクチャとは、8th Light, Inc.のブログ記事で提案されている。 一言で言うと、依存関係をコントロールし持続可能なソフトウェアを実現するための体系的な手法である。 ※ DIやD

    クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた - Qiita
  • 進化的アーキテクチャ

    現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。書は、そうしたアーキテクチャを「進化的アーキテクチャ」と名付け、その構築に必要な考え方や技術、実践方法などについて解説するものです。 ThoughtWorksの3人のスペシャリストから現代のソフトウェアアーキテクトに向けられた書は、絶え間ない変化を支える進化的アーキテクチャを構築するために必要なすべてを提供する実践的なガイドです。 書への推薦の言葉 訳者まえがき マーチン・ファウラーによる序文 はじめに 1章 ソフトウ

    進化的アーキテクチャ
  • microservicesに分割する際に注意するべき5つのこと - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくこと

    microservicesに分割する際に注意するべき5つのこと - Qiita
  • サービス分割とデータ統合アーキテクチャに関する考察 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、freeeエンジニアをしている@yebiharaです。 この記事はfreee Engineers Advent Calendar 2015の22日目です。 皆さんの中には「マイクロサービスアーキテクチャ」という言葉を聞いたことがある方も多いと思います。 James LewisとMartin Fowlerによるブログ記事 Microservices(日語訳)により、急激に広まった感のあるこの言葉ですが、マイクロサービスそのものについて書き始めると長くなり過ぎてしまうので、この記事では触れません。 さて、freeeのアーキテ

    サービス分割とデータ統合アーキテクチャに関する考察 - Qiita
  • 【登壇資料】目的別、サーバーレスアーキテクチャの教科書!これのときはこう!【アーキテクチャ20連発】 #cm_osaka | DevelopersIO

    大阪でサーバーレスの話をしてきました クラスメソッドの開発を知る!大阪勉強会 第7回 これから始めるサーバーレス!〜最新サービス使いこなし術〜で スピーカーとして登壇しました。参加率が非常に高く、多くの方にご参加いただきました。誠にありがとうございました! 記事では、勉強会でお話しした「目的別、サーバーレスアーキテクチャの教科書!これのときはこう!」の発表資料を公開します。 発表資料 内容 セッションでは、これからサーバーレスを始める人向けに、サーバーレスとは何か?という話から、具体的にどのようなアーキテクチャを構築するのか?というお話しをさせていただきました。 サーバーレスアーキテクチャパターン セッションでは、サーバーレスアーキテクチャのパターンを20種類ご紹介しました。サーバーレスと言えるアーキテクチャは20種類では語りきれないほど沢山ありますが、今回は独断と偏見で選んでみまし

    【登壇資料】目的別、サーバーレスアーキテクチャの教科書!これのときはこう!【アーキテクチャ20連発】 #cm_osaka | DevelopersIO
  • Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD

    あるシステムを、1人のユーザから1100万人以上にスケーリングするにはどのようにすれば良いのでしょうか。Amazonのウェブサービスソリューションアーキテクトである Joel Williams が AWS re: Invent 2015 Scaling Up to Your First 10 Million Users でスケーリング方法について素晴らしいプレゼンをしています。 AWS上級者のユーザには適さないプレゼンですが、AWS初心者やクラウド初心者、Amazonが次々と送り出す新機能の流れについていけていない人が始めるには素晴らしい内容だと思います。 おおよその見当は付いていると思いますが、このプレゼンはAmazonによって提供されているため、どの問題についても解決策として提案されているものは全てAmazonのサービスになります。amazonのプラットフォームの役割は、印象深く、分か

    Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD
  • Firebaseを使ったサーバーレスWebアプリケーション開発 (ServerlessConfセッション紹介) - yoshidashingo

    セクションナイン の 吉田真吾(@yoshidashingo)です。 第3弾はフロントエンド開発者であるきはるさんです。 プロフィール 名前:佐々木季羽る Kiharu Sasaki 会社名:freelance, Section-9 職種:Frontend Developer SIerで通信系システムの開発に携わった後、コンサルティング会社にて金融系エンタープライズシステムを担当。フリーランスとして独立後は、Webアプリケーション開発を中心に活動中。流しのフロントエンドエンジニア。Section-9メンバー。 Quick Chat ---- ServerlessConf Tokyoでのセッション概要を教えてください Firebaseは、Googleが提供しているバックエンドサービスです。 アプリケーションに必要なサーバー、DBの構築や運用が不要なのはもちろん、データに連動してREST AP

    Firebaseを使ったサーバーレスWebアプリケーション開発 (ServerlessConfセッション紹介) - yoshidashingo
  • 建築エコノミスト 森山高至『新国立競技場の工事費が下がらない理由』

    昨年、連載いたしました「新国立競技場をめぐる議論について」なのですが、 この問題が広く世間で建築工学や建築文化をめぐる問題の共有につながれば 望です。 思いのほか多くの方々に読んでいただいたみたいで、 いろいろとご質問などもいただきまして、ありがとうございました。 新国立競技場の建設コンペをめぐる議論について 1(ザハはイラク出身の建築家) 新国立競技場の建設コンペをめぐる議論について 2(アンビルドアーキテクトと磯崎新) 新国立競技場の建設コンペをめぐる議論について 3(新国立競技場コンペ応募資格) 新国立競技場の建設コンペをめぐる議論について 4(ザハの仕事と今の国立競技場) 新国立競技場の建設コンペをめぐる議論について 5(建築と哲学の諸問題) 新国立競技場の建設コンペをめぐる議論について 6(新国立の募集要項と大きさ) 新国立競技場の建設コンペをめぐる議論について 7(脱構築とは

    建築エコノミスト 森山高至『新国立競技場の工事費が下がらない理由』
    moronbee
    moronbee 2014/01/07
    "現在はまだ設計図も出来ておらず、工事予定のゼネコンも未定です" // なら変えようぜー。
  • モバツイ、2つのスマホへのチャレンジ「モバツイtouchとsmart」

    モバツイは、2つのアプローチでスマートフォン時代にチャレンジすることにしました。 一つは、Androidアプリの「モバツイtouch」です。ツイッタークライアント P3の開発者であるlynmockさんによる作品です。 P3はJavaで作られたデスクトップクライアントですが、去年だったか一昨年だったか、twitterのイベントで会った時に、JavaGUIでアプリを作れる人はレアなので、絶対にAndroidは勉強すべき!ということを力説したことを覚えています。 まだモバツイのAndroid版を一緒に作ることになるとはその頃はつゆ知らず、という頃でしたが、その後、モバツイブランドでクライアントを一緒に作ることになりました。 明らかに他社に比べて後発なのは否めず、かつ偉大なクライアントが何個もあるので大変なのは承知の上で、でも諦めずに頑張ります。 lynmock先生が強く力説していた「酔っぱらっ

    moronbee
    moronbee 2011/11/11
    サーバー側リソースを効果的に活用して、快適さをアップすると同時にスケールさせる。Cloud Adaptedな例。
  • Evernoteのアーキテクチャ概要 - nokunoの日記

    みなさん、Evernoteは使っていますか? Evernoteは「全てを記憶する」が合言葉のメモアプリで、クラウド上にデータを保存してWin/Mac/iPhone/Webから共通のデータにアクセスしたり同期したりできるのが特徴の便利なサービスです。開発元はシリコンバレーの会社ですが、日人のユーザも非常に多いそうで、Evernoteの使い方についての記事は日語でも星の数ほどありますのでここでは触れません。 今回は、そのEvernoteの裏側のシステム概要を解説する記事が今月開設されたばかりの技術ブログに公開されていましたので、翻訳してみました。Architectural Digest | Evernote Tech Blog はじめにこのブログの手始めとして、Evernoteの構築について大雑把な概要を述べる。ここではそれぞれのコンポーネントの詳細に踏み込むことはしない。それらについての

  • 目標値の5倍速い! 爆速「arrowhead」を生み出した富士通の技術と発想のヒミツ

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 富士通が東京証券取引所に納入した株式売買システム「arrowhead(アローヘッド)」は、2010年1月4日の稼働以来、現在までの約3カ月間、トラブルなく運用されている。 arrowheadは、注文応答時間や情報配信スピードの高速化を実現し、注文、約定、注文板などの取引情報を、異なるサーバ上で三重化して処理するなど、高速性と信頼性を兼ね備えた「世界最高水準の取引所システム」と位置づけられているものだ。 富士通では、arrowheadについて「金融テクノロジの高度化などを背景に、個人投資家のオンライン取引の普及や、証券会社や機関投資家によるアルゴリズム取引など、新たな取引が広がりをみせている。こうした市場環境や取引形態の変化のなかで、注文

    目標値の5倍速い! 爆速「arrowhead」を生み出した富士通の技術と発想のヒミツ
    moronbee
    moronbee 2010/04/06
    インメモリで3層を3重化、Failover、UDP。
  • Webアプリ開発における「内部APIモデル」 - Tous Les Jours 攻防記

    前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは2つあります。 (1)言語やフレームワークの選択自由度が上がる 現在運

    Webアプリ開発における「内部APIモデル」 - Tous Les Jours 攻防記
    moronbee
    moronbee 2009/01/29
    バックエンドをapi化する場合の4つのポイント
  • 1
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy