並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 1021件

新着順 人気順

アーキテクチャの検索結果121 - 160 件 / 1021件

  • エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ

    みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識/運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ

      エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ
    • 改めて整理するアプリケーション設計の基本

      ●発表のアーカイブ動画はこちら:https://youtu.be/4rgGkoyUaZw ●発表の中で紹介しているUdemy講座:https://www.nextskill.co.jp/courses === プログラミングの基礎を学び、アプリケーション開発に実践的に関わり始めると、「MVC」「サービスクラス」「ドメインモデル」「クリーンアーキテクチャ」といった、よく分からない単語に遭遇します。 これはいわゆる「アプリケーションアーキテクチャ」という分野の話で、アプリケーション開発に関わり始めると、誰もが突き当たる壁の一つです。 今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの、基本的な用語の意味や関係性を整理します。 発表者が過去に書いた以下の記事を中心に、+α の内容を加えた発表になります。 ・「ビジネスロジック」とは何か、どう実装

        改めて整理するアプリケーション設計の基本
      • Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ

        この記事は第5回Webシステムアーキテクチャ研究会の予稿です。 はじめに Webサービスにおいては、スマートフォンの普及によるアクセス増加に対してスケーラビリティを持ち、個人向けだけでなく企業向けサービスの可用性の要求に耐えられるようなシステム設計が必要とされている。 さらに、Webサービスが人々の生活に浸透したために、Webサービス事業者はサービスを長期間運用することが当たり前となっている。 その間、新機能開発、ソフトウェアの実行効率化、セキュリティ向上などを目的に、システム管理者は自身が管理するソフトウェア群を更新しつづける必要がある。 このような多様な要求を満たすために、Webサービスを開発・運用するエンジニアには、OSやデータベース、ネットワーク、分散システム、プログラミング言語処理系などのコンピュータ工学における広範囲の基礎知識と、ミドルウェア、オペレーション自動化のためのソフト

          Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ
        • Instagramはどうやって3人のエンジニアで1400万人にサービスを提供できるシステムを組み上げたのか

          Instagramは2010年10月にサービスを開始後、2011年12月までのわずか1年間で1400万人に利用されるほど巨大なサービスに成長しました。こうしたスケールに対応できるシステムを組み上げたのはたった3人のエンジニアだったとのことで、どのように少人数でスケールするシステムを組み上げたのかについて、エキスパートエンジニアのレオナルド・クリードさんが解説しています。 How Instagram scaled to 14 million users with only 3 engineers https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million レオナルド・クリードさんは、Instagramが3人のエンジニアで安定して巨大なサービスを提供できた理由として、下記の3つの原則を守ったからだと述べています

            Instagramはどうやって3人のエンジニアで1400万人にサービスを提供できるシステムを組み上げたのか
          • ソフトウェアアーキテクチャを学ぶために - kawasima

            いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。

              ソフトウェアアーキテクチャを学ぶために - kawasima
            • プラットフォームの上でものを作るということ

              プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.

                プラットフォームの上でものを作るということ
              • 「Angular」「React」「Vue」の3大フレームワークに集約 ICSの代表が教える「フロントエンド技術」のトレンド

                「キャッチアップしておきたいウェブ制作の最前線」というテーマで、Vue.jsなどJavaScriptを駆使したユーザーインターフェイスの開発を主に担当してきた池田泰延氏が、Webのフロント周りの近年の技術的な動向を解説します。前半はフロントエンド技術のトレンドについて。 スピーカー自己紹介、『JavaScript コードレシピ集』を出版 池田泰延 氏(以下、池田):みなさんよろしくお願いします。ICSの話として、私と鹿野の2名で発表します。HTMLとかCSSとかJavaScriptとか、フロントエンドまわりの最新を説明していきたいと思います。では始めていきましょう! ます自己紹介します。ICSの池田と言います。株式会社ICSの代表をやっています。これはオフィスの写真でして、南麻布にあるのですが、こんなところで仕事をやっています。今はこの状況下なので、会社にはほとんど誰も行っていませんが、こ

                  「Angular」「React」「Vue」の3大フレームワークに集約 ICSの代表が教える「フロントエンド技術」のトレンド
                • 「Client と Server があるスマフォゲームを 開発するときに人類が考えておくべき、ほとんど全てのこと」をまとめる構想

                  「Client と Server があるスマフォゲームを 開発するときに人類が考えておくべき、ほとんど全てのこと」をまとめる構想 これは何 「Client と Server があるスマフォゲームを開発するときに人類が考えておくべき、ほとんど全てのこと」 をドキュメントとしてまとめようと思ったときに、何を書けばいいかをリストアップする場所 (構想を練る目的なので、不完全な内容です) のんびり更新予定 モチベーション 1. 仕事上の実利 職業柄、生きていくために Client / Server 実装があるスマフォゲーム を一定期間をかけてチームで開発することが多い ゲームのチーム開発は要素が多く、先立って考慮しておくべきことも多岐に渡る 「考慮しておくべきことリスト」 を用意しておくことで、考慮漏れによるミスや手戻りを減らす 初心者にとっては抜けていた知識の補完になり、中級者以上にとっても思考

                    「Client と Server があるスマフォゲームを 開発するときに人類が考えておくべき、ほとんど全てのこと」をまとめる構想
                  • 個人的なアプリケーション設計のバイブル3選 - Runner in the High

                    自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション

                      個人的なアプリケーション設計のバイブル3選 - Runner in the High
                    • メルカリWebのマイクロサービス化、その4年 | メルカリエンジニアリング

                      Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか

                        メルカリWebのマイクロサービス化、その4年 | メルカリエンジニアリング
                      • スクリプト言語を舐めてはいけない|shi3z|note

                        おれはハッカーだ。 なので、ハッカーではない人種と呑むのが苦手である。 たとえば「ITエンジニア」と自称するような人たちだ。 当然だが、ITエンジニアと自称する人はハッカーではない。 ITエンジニアと言う言葉はスコープが広すぎていちいち細かい説明を聞かなければならない。 これが厄介なところである。 あるとき、友達の家で飲み会をすると言われ、誰が来るの?と聞いたら知らないIT関連会社のエンジニアたちだという。 エンジニアと呑むと喧嘩しちゃうので断ったのだが、いろいろあっていくことになってしまった。 するとやっぱりこんなはなしをしていた。 「やっぱ私もRubyみたいなスクリプト言語なんか卒業してコンパイル言語やんなきゃ。処理速度がね…」 「コンパイル言語って?」 「TypeScriptとかJavaとかC#とか」 「それ、中間コード言語じゃねえか。なんの意味があるんだ。YARV知らないのか」 ま

                          スクリプト言語を舐めてはいけない|shi3z|note
                        • ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白

                          根本の問題意識 ソフトウェアの設計スキルはどのように獲得する(させる)ことが効果的であるのか ソフトウェアアーキテクチャの目的 そもそもソフトウェアアーキテクチャはどのような欲望を満たすための方法か ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するための必要な人材を最小限に抑えること である。 (CLEAN ARCHITECTURE) 「求められるシステムを構築・保守するための必要な人材を最小限に抑えたい」 => 構築容易性 と 保守容易性 を確保したい 構築容易性 「構築しやすさ」とは? ソフトウェアを構築するとはどういうことか ソフトウェアの2つの価値: 「振る舞い」と「構造」 振る舞い: 要件を満たすこと => いわゆる機能 構造: 振る舞いを簡単に変更できること => いわゆるアーキテクチャ 構築しやすさ=価値の生み出しやすさ 要件を満たしながら振る舞いを変更

                            ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白
                          • Smart UI パターンが再評価される世界 - id:onk のはてなブログ

                            設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ!!!— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ

                              Smart UI パターンが再評価される世界 - id:onk のはてなブログ
                            • This is The Entire Computer Science Curriculum in 1000 YouTube Videos

                              This is The Entire Computer Science Curriculum in 1000 YouTube Videos In this article, we are going to create an entire Computer Science curriculum using only YouTube videos. The Computer Science curriculum is going to cover every skill essential for a Computer Science Engineer that has expertise in Artificial Intelligence and its subfields, like: Machine Learning, Deep Learning, Computer Vision,

                                This is The Entire Computer Science Curriculum in 1000 YouTube Videos
                              • 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ | コーソルDatabaseエンジニアのBlog

                                Microsoft SQL ServerMySQLOracle DatabasePostgreSQLSolarWinds DPAデータベース運用主要RDBMS製品の比較 2022.09.01 渡部 亮太 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ Oracle ACE Proの渡部です。 主要なRDBMS製品についてアーキテクチャを比較します。 大枠を整理することが最大の目的です。細かい例外事項や拡張機能は適宜記載を割愛しています。 2022年9月時点の最新バージョンをベースに記載していますが、記載内容にバージョン依存は少ないはずです。 時間ができた時に随時追記予定です。 もし誤りを見つけた場合は、優しく教えていただけると嬉しいです。→ https://twitter.com/wrcsus4 or ryota.watabe at cosol dot

                                • 構成図を描く際に気をつけていること - NRIネットコムBlog

                                  こんにちは、越川です。 皆さんは構成図を描く機会ありますか? 僕の場合、内部のメンバーやお客様との議論の場で、構成図を描いて図解ベースで説明することが多いです。実際に描いてみると色々と考慮すべき点が多く、今回は自分なりに普段意識している点を言語化してみようと思います。 なぜ構成図を描くのか 構成図を描く際に意識している3つのこと 1. 導線 2. 引き算思考 1. 主役を決める 2. 読者を想定する 3. 高さや大きさを揃える さいごに なぜ構成図を描くのか 構成図のメリットは相手に伝えたいことをシンプルに伝えられる点だと思います。文章で書くと沢山書かなければいけないことが構成図を使うとスムーズに相手に伝わります。例えば、以下の文章を読んでみて下さい。 ユーザーはDNS登録されたFQDNへHTTPSアクセスする CloudFrontはBehaviorに指定されたALBにHTTPSリクエスト

                                    構成図を描く際に気をつけていること - NRIネットコムBlog
                                  • 人類はWeb会議に向いていないので、もっとMiroを活用すべき - Cloud Penguins

                                    Miro大好きjacopenです。エンタープライズなIT界隈ではおそらく日本でトップクラスにMiroを愛している自信がある。 さて今日はMiro Advent Calendar 2021の3日目。 今日は、人類がいかにWeb会議に不向きかという話と、そのギャップをMiroで埋めようという話。あとは自分が関わっているカンファレンスでMiroを使いまくっている話をする。 Web会議の8割はXX コロナ禍でだいぶ定着したWeb会議。でも、個人的には世の中のWeb会議の8割は上手くいっていないと思っている。数字に根拠はないけど。 何を持って上手くいっていないとするかだが、「対面の会議と比較して伝えられる度合いが低下している」とすると、8割くらいはそれに該当すると言っても過言ではないだろう。 何故そうなるかというと、基本的に人は言葉だけで物事を正確に伝えることはできないからだ。 人間の会話において、

                                      人類はWeb会議に向いていないので、もっとMiroを活用すべき - Cloud Penguins
                                    • Google純正の構成図作成ツールが登場したので早速使ってみた

                                      クラウドサービスでは大量の機能が多種多様に提供されており、簡単なアプリでも複数のサービスを組み合わせて利用することも珍しくありません。そうしたバックグラウンドのサービスを設計する際に役立つのがサービス間の構造を図に落とし込んだ「アーキテクチャ図」です。これまでもサードパーティーからさまざまなアーキテクチャ図作成ツールが提供されてきましたが、2022年2月17日にGoogleが自社クラウド向けの公式アーキテクチャ図作成ツールをリリースしたので、早速使い勝手を試してみました。 Google Cloud Developer Cheat Sheet https://googlecloudcheatsheet.withgoogle.com/architecture Introducing a Google Cloud architecture diagramming tool | Google Cl

                                        Google純正の構成図作成ツールが登場したので早速使ってみた
                                      • マイクロサービス設計原則: SOLIDではなくIDEALS

                                        キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte

                                          マイクロサービス設計原則: SOLIDではなくIDEALS
                                        • サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第一回〜べき等性 (冪等性/idempotency) ってなんだ!? - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

                                          そもそも、べき等性とは、どういうことを言うのでしょうか ? これは「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念です。 例えば、注文処理を考えます。画面インターフェースで、注文確定 / 送信ボタンを押すという操作で二度三度押してしまうユーザーがいます。これで同じ内容の注文が複数回登録されてしまったら問題です。こういったケースでは、画面側で連続して押せないような実装を追加したり (①)、サーバー側で同じ注文の処理であることを認識して適切に一つの処理と判断するようなこと (②) が必要です。 この例では、画面側の制御を入れたほうが簡単なように見えます。しかし、現実には画面とサーバーとの間のネットワークの問題や画面以外からの HTTP コールなどを考えると、このような重複リクエストが起こってしまうという可能性はゼロではありません。 このようなものへの対処として、サーバ

                                            サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第一回〜べき等性 (冪等性/idempotency) ってなんだ!? - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
                                          • AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

                                            これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス:ALB or ECS Service 共有 or 1環境毎 アクセスログ:ALB or WEBサーバー ECS / EKS デプロイ:Blue/Gr

                                              AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
                                            • ソフトウェアアーキテクチャの基礎: Software Architecture in a Nutshell

                                              『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2 での発表資料です https://timeedev.connpass.com/event/254336/ 動画: https://youtu.be/ydQ2xoc49Lc #Techmee

                                                ソフトウェアアーキテクチャの基礎: Software Architecture in a Nutshell
                                              • 30分でわかるデータ指向アプリケーションデザイン - Data Engineering Study #18

                                                600ページを超える書籍である「データ指向アプリケーションデザイン」の要点を最近の話題を交えながら解説します。 Data Engineering Study #18 の発表資料です プレゼンテーション https://www.youtube.com/watch?v=ZiKWXc0fSCw イベントURL https://forkwell.connpass.com/event/269125/ データ指向アプリケーションデザイン https://www.oreilly.co.jp/books/9784873118703/

                                                  30分でわかるデータ指向アプリケーションデザイン - Data Engineering Study #18
                                                • プログラミング上達したい人に繰り返し読んで欲しい4冊改訂版|erukiti

                                                  プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか(例えばリファクタリング第二版) の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 この

                                                    プログラミング上達したい人に繰り返し読んで欲しい4冊改訂版|erukiti
                                                  • ドメイン駆動設計に関する何か - 日々常々

                                                    2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも?くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

                                                      ドメイン駆動設計に関する何か - 日々常々
                                                    • Fleet へようこそ! | JetBrains のブログ

                                                      長年に渡り、皆さんから「JetBrains はいつ軽量エディターを作成する予定ですか?」と尋ねられてきました。 本日、Fleet を発表できることを大変嬉しく思っています。Fleet は単なる軽量のエディターではありません! 初めて Fleet を起動すると、構文ハイライト、単純なコード補完、そしてエディターに期待するものすべてが揃ったフル機能のエディターとして起動します。 でも、それだけではありません! Fleet は、スマート補完、リファクタリング、ナビゲーション、デバッグ、そして IDE に常に搭載されてきたものすべてが備わったフル機能の IDE でもあります。しかも、これらの機能はすべて、ボタンをクリックするだけで使用できます。 Fleet は新しいアーキテクチャとユーザーインターフェースで、ゼロから構築されました。 Fleet は一体なんであるのか、その詳細について説明しましょう

                                                        Fleet へようこそ! | JetBrains のブログ
                                                      • AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」

                                                        AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」(1/3 ページ) 8月23日に起きたクラウドサービス「AWS」(Amazon Web Services)の東京リージョンでの障害は、国内のさまざまなサービスに影響を及ぼした。 AWSが同日午後8時ごろに復旧するまで、モバイル決済サービス「PayPay」や、仮想通貨取引所「Zaif」、オンラインゲーム「アズールレーン」などで利用できない、もしくは利用しづらい状況が続いた。PCショップの「ドスパラ」はECサイトの不具合が長引き、翌日の24日には実店舗を臨時休業して対応に当たっていた。 AWSという1つのサービス障害が起きただけで、多くの企業やサービスに影響を及ぼしたため、「クラウドサービスはもろい」という論調も散見された。 しかし、インフラエンジニアたちからは違う意見が聞こえてくる

                                                          AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
                                                        • 2のべき乗サイズの配列は危ないという話 via 行列積 - elkurin’s blog

                                                          こんにちは。労働者です。とあるプログラムで学生さんの課題を添削していたら面白い話に出会いました。 僕は今、主に学部生向けのインターン研修的なプログラムでメンターなるものをやっています。メンターとしての仕事は、学生さんの課題へフィードバックを返し、Office Hourというセッションを毎週設けて質問受けやCSに関するトークを行うといった内容になっています。今回話題に取り上げるのはその中の課題の1つ、「行列積のプログラムを書いて時間を計測せよ」という何気ない話で、続く課題たちのいわば前座のようなものです。こういったところに沼は隠されているものですね。 担当している学生さんたちが細かい実験を行ってくれて以下のような疑問が提示されました。 「行列積の計算が N = 1024のときだけ N = 1023, 1025のときに比べて3倍遅いのはなぜ?」 配列のサイズが2のべき乗になるのは避けるべきとい

                                                            2のべき乗サイズの配列は危ないという話 via 行列積 - elkurin’s blog
                                                          • Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO

                                                            こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 最近調べものをしている中で見つけたドキュメントが良かったのでご紹介したいと思います。 先にまとめ Microsoft の RESTful Web API の設計 のドキュメントが API 設計を考える上で勉強になった 関連する クラウド アプリケーションのベスト プラクティス のドキュメントもアプリケーションを設計する際の指標として良さそう RESTful Web API の設計 最近 API 設計やパス設計について考える機会があったのですが、これという正解がなかったり、人によって思想やこだわりが違ったりして結構難しいなと感じていました。 そんな中で下記のドキュメントを見つけてひとつの指標として良いなと思ったのでご紹介します。 内容(項目) REST とは何か リソースを中心とした API 設計の整理 HTTP

                                                              Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO
                                                            • 画像認識の大革命。AI界で話題爆発中の「Vision Transformer」を解説! - Qiita

                                                              0. 忙しい方へ 完全に畳み込みとさようならしてSoTA達成したよ Vision Transformerの重要なことは次の3つだよ 画像パッチを単語のように扱うよ アーキテクチャはTransformerのエンコーダー部分だよ 巨大なデータセットJFT-300Mで事前学習するよ SoTAを上回る性能を約$\frac{1}{15}$の計算コストで得られたよ 事前学習データセットとモデルをさらに大きくすることでまだまだ性能向上する余地があるよ 1. Vision Transformerの解説 Vision Transformer(=ViT)の重要な部分は次の3つです。 入力画像 アーキテクチャ 事前学習とファインチューニング それぞれについて見ていきましょう。 1.1 入力画像 まず入力画像についてです。ViTはTransformerをベースとしたモデル(というより一部を丸々使っている)ですが、

                                                                画像認識の大革命。AI界で話題爆発中の「Vision Transformer」を解説! - Qiita
                                                              • 「スタディサプリ」が React Native から卒業するまで、あるいは技術的負債への感謝と敬意 - スタディサプリ Product Team Blog

                                                                こんにちは、Quipper iOS エンジニアの @manicmaniac です。 現在スタディサプリ iOS アプリ開発チームのエンジニアリングマネージャをしています。 今回はスタディサプリで長らく使われていた React Native のコードを Swift に書き換えた話をします。 実は React Native から Swift への置き換え自体は半年ほど前に完了していたのですが、ブログに記すのに時間がかかってしまいました。 スタディサプリにおける React Native の利用 Quipper では 2017年ごろから React Native を iOS / Android アプリ開発に利用し始め、スタディサプリでは 2018年3月ごろから徐々に React Native を iOS アプリケーション開発に導入していました。 iOS 版スタディサプリの、git から取り出した

                                                                  「スタディサプリ」が React Native から卒業するまで、あるいは技術的負債への感謝と敬意 - スタディサプリ Product Team Blog
                                                                • スタートアップのためのマイクロサービス入門 | Amazon Web Services

                                                                  AWS Startup ブログ スタートアップのためのマイクロサービス入門 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 以前「スタートアップのためのコンテナ入門 – Kubernetes 編」を出した際に記事内で、マイクロサービスやサービスメッシュにふれる機会がありました。今回は AWS でデベロッパーアドボケイトをしているトリ氏 (@toricls) にマイクロサービスについて記事を寄稿いただきました。 ※ 本記事は Software Design 2020年7月号 に掲載された「スタートアップのためのAWSテクノロジー講座 – マイクロサービスのあるべき姿と特徴を知る」からの転載、改修版です。 目次 マイクロサービスにはコンテナが必要なのか? サービスメッシュは本当に必要なのか? 「マイクロサービス」という言葉の功罪 マイクロサービスが必

                                                                    スタートアップのためのマイクロサービス入門 | Amazon Web Services
                                                                  • 最強データベース(RDB)設計とは?アンチパターンの見極め方法も - FLEXY(フレキシー)

                                                                    ※2020年6月に公開された記事です。 日本PostgreSQLユーザ会の理事を務める合同会社Have Fun Techを起業した曽根壮大(@soudai1025)と申します。元株式会社オミカレ副社長兼CTOです。直近では、『失敗から学ぶ RDBの正しい歩き方』を執筆しました。 今回はデータベースをテーマとして、魅力やMySQLとPostgreSQLの違い、アンチパターンの見極めなどの基礎知識に加え、勉強法などもご紹介します。 RDB関連の求人検索はこちら データベースを学ぶ魅力をエンジニア目線で考察 1.知識の費用対効果が高い エンジニアがデータベースを学ぶ利点という観点から言うと、データベースの特徴は寿命が長いことと私は考えています。 Webアプリケーションの界隈では1年単位でバージョンアップしたり流行っている言語が変わってしまうことがザラにありますが、データベースは10年、20年とい

                                                                      最強データベース(RDB)設計とは?アンチパターンの見極め方法も - FLEXY(フレキシー)
                                                                    • チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ

                                                                      はじめに現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン: チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの想

                                                                        チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ
                                                                      • 実はDDDってしっくりこないんです - タオルケット体操

                                                                        DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット(といいつつほぼ忘れかけている)なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用(採用できているとは言っていない)しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい

                                                                          実はDDDってしっくりこないんです - タオルケット体操
                                                                        • GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです

                                                                          You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

                                                                            GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです
                                                                          • マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい

                                                                            昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装(の予想) マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB(CLB)をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス(仮称)として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが

                                                                              マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい
                                                                            • GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL

                                                                              iCARE Dev Meetup 20 で発表した資料です #icare_meetup p.7,8,61 https://graphql.org/ p.18 https://twitter.com/a_suenami/status/1379270185207484417 p.33 [SQLQL - Qiita](https://qiita.com/yancya/items/4b7979d83cbf6af9b819) p.33 https://twitter.com/onk/status/912491093127598080 p.35 [【エンジニアブログ】ダイニーのエンジニアリング3カ条|dinii(ダイニー)公式|note](https://note.com/dinii/n/n9be778bd7da3) p.36 [Smart UI パターンが再評価される世界 - id:onk のはてな

                                                                                GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL
                                                                              • Flutterを始めた人に読んでもらいたい勉強手順

                                                                                対象となる読者 これからFlutterの勉強を始める人 ネットで断片的な情報を拾いながら勉強するのが苦手な人 FlutterというToolkitの根本理解を目指す人 英語が苦手、公式ドキュメントを読むのに挫折した人 対象でない読者 メンター等、周りに勉強の仕方を教えてくれる人がいる人(その人に従うのが一番です) Flutterにはあまり興味ないけどとにかくアプリは作りたい!という考えの人 とにかくアプリ作りたい!アプリの作り方教えて!精神の人 公式ドキュメントの内容やネットの情報を自ら吸収できる人 なぜこの記事を書いたのか Flutter初心者の方が迷子にならないような道しるべが必要だと思ったからです。 僕もFlutterを触り始めて4ヶ月の初心者ですが、まだ4ヶ月しか経っていないからこそ最初に躓いたことや、どういう勉強が役に立ったか記憶が鮮明に残っています。 まだFlutter初心者の目

                                                                                  Flutterを始めた人に読んでもらいたい勉強手順
                                                                                • PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳

                                                                                  質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場

                                                                                    PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳