はじめに 先日、海外向けに運用していた個人ブログがDDoS攻撃を受けてしまいました。 こういったサイバー攻撃は、企業に対して行われるものという先入観がありました。 しかし、調べてみると、最近では個人ブログも標的になってきていると報告があがっていました。 CloudFrontとS3で作成する静的サイトが人気になっており、特にCloudFrontの危険性について紹介したいと思います。 DDoS攻撃って？ ざっくり説明すると、ウェブサイトやサーバーに対して過剰なアクセスやデータを送付するサイバー攻撃です。 インフラストラクチャーレイヤー攻撃(レイヤー3、4)とアプリケーションレイヤー攻撃(レイヤー6、7)の２つに分類されます。 ご指摘を頂きましたので、訂正いたします。 厳密には、EDoS攻撃でした。 AWS Shield Standard AWSを利用した場合、defaultでAWS Shiel

この記事は Python Advent Calendar 2019 の 19 日目の記事です。 🐍 あらすじ Python のパッケージ管理。特にここ数年で新しいツールが多く出たこともあり、一体何を使うべきなのか、少し調べただけでは分からないと思います。本記事では、新しめの管理ツールを独断と偏見で比較します。著者は Poetry 信者なのでバイアスが掛かっているので悪しからず。 本記事で書いていること Pipenv、Poetry、Pyflow の違いと使い方 本記事で書いていないこと Pyenv、Venv、Virtualenv などの既存ツールの説明 著者の環境は以下の通り。 Ubuntu 18.04 Python 3.8.0 Pipenv 2018.11.26 Poetry 1.0.0 Pyflow 0.2.1 特に Poetry と Pyflow は開発途中なので、本記事の内容と違う

はじめに 仕事の品質を高める上で、知見のある方にレビューをしてもらうプロセスは欠かせません。 ただこのレビュー、やり方や意見の伝え方によっては、期待した効果が得られなかったり、ネガティブな効果を生み出しかねません。そうした結果、レビューという行為自体が開催されにくくなることは、チームにとって非常にマイナスです。 全員のレビューへの期待を整えておくために、レビューの心構えや望ましい運営方法などを、レビューに関わる全ての人が共通認識化しておくことは、非常に重要だと考えています。 今回、このレビューを効果的に進めるポイントをまとめた、とても良い資料を見つけたのでご紹介します。 レビュープロセス - AWS Well-Architected フレームワーク この資料をおすすめしたい方 エンジニアに限らず、仕事で他者の成果物をレビューをする人、および他者からレビューを受ける人（そう考えると、仕事をす

📡観測範囲 Paiza転職およびGreenを使用 2021年秋～2022年夏に、提示年収400万～のレンジで、フロントエンド／フルスタックエンジニア／クロスプラットフォーム系アプリエンジニア枠で募集かけてる（かけてた）会社 ビジネス形態としてはSES/受託開発/自社サービスと幅広く 業務分野も医療系/建築系/不動産系/金融系/エンタメ系/その他諸々とこちらも幅広く 日本全国対象 面談だけで40社超えてるので求人に目を通したのは60社ぐらいは行ってるのでないかと思います。 またほぼ全部、スカウトメール経由で転職活動を行ったため、自分の技術スタックによるバイアスが入ってます。（RubyよりPHPの方が多い等） 偏りが大きいのでIT業界全体の現況などと口が裂けても言えませんが、逆にあんま表沙汰にならないようなベンチャー、中小零細、レガシー企業、非IT企業のIT部門採用等、色々見てきたので印象深

PythonやJavaScriptに慣れている人ならやってしまいがちのエラーですね。printfの書式と違います。これをコンパイル、実行をすると私の環境では以下のようなエラーが吐かれました。 a.c:3:12: warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *' [-Wint-conversion] printf(1 + 2); ^~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:170:36: note: passing argument to par

最近ソーダストリームを買い、炭酸水を飲むのにはまってます。機械学習エンジニアの@yktm31です。 以前に「AWS Lake Formationでデータレイク体験！」という記事を書いてみて、データ基盤アーキテクチャに興味が湧いてきました。 データレイクハウスは、「データウェアハウス」と「データレイク」を統合したようなアーキテクチャで、 2020年にDatabricks社により提唱され、新しいデータ基盤アーキテクチャとして注目されているようです。 www.databricks.com そこで今回、「データレイクハウス」について調べてみたことをまとめてみたいと思います。 なぜデータレイクハウスが注目されているのか？ データウェアハウスの特徴・課題 データレイクの特徴・課題 データレイクハウスの特徴 データレイクハウスのアーキテクチャ Azure Azure Synapse Analyticsを

本当に良いものかどうかは、時間が経たないと分からない。 だから今になって2021年に買って良かったものを紹介する。 Amazonブラックフライデーはこれを買え。 1年が経過した 去年こんな記事を書いた。 本当に良いものは、使い続けることができるものである。そう考えているので「今年買ってよかったもの」が紹介されるこの時期に、あえて「去年買ったもの」を紹介したわけだ。 今年も同じである。今回は2021年に買って良かったものを紹介する。 CO2モニター まずは単体で記事にしたCO2モニターである。 カスタム (CUSTOM) CO2モニター CO2-mini カスタム(Custom)Amazon 細かい話は記事を読んでもらいたいが、人は二酸化炭素濃度が高いと生産性が落ち、さらに高くなると健康への影響も出る。適正値の目安としては以下を参考にすると良い。 400 ppm：外気の二酸化炭素濃度がだいた

はじめに 最近、技術書で「良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方」という本に出会いました。 自分に足りていなかった設計の考え方についてかなり勉強になりました。 本当に良かったので内容を忘れないようにQiitaに書き残そうと思います。またこれを機にアウトプットの習慣化ができればいいなと思っています。 動くプログラムは割と誰にだって書けると思いますが、良い構造へ改善するためのアプローチを知っている人は世の中に少ないのではないかと思います。 その少数派、価値の高いレイヤーに参加できる入門書が本書だと思いました。 その中でもまずは「名前設計」について執筆していきたいと思います。 目次 意味不明な命名 命名は省略を避けよう 変数の使いわましを避けよう 名前設計を怠ったプログラムの末路 参考文献 意味不明な命名

ぶどうをレンジでチンするとこの世の終わりのようなプラズマが発火する理由がやっと判明2022.11.23 20:35510,990 Ryan F. Mandelbaum - Gizmodo US ［原文］ （ satomi ） 2019年2月26日の記事を編集して再掲載しています。 偶然の一致。 電子レンジに絶対入れてはいけないものと言えば、たまごとぶどう。たまごは爆発しますし、ぶどうはテスラコイルみたいな厳かな光を発し、｢こ、これは…｣と呆然としているとボッと燃えたりします。畑のぶどうなのに。 この奇妙な現象にまじめに取り組む論文が月曜、カナダから高名な科学誌に発表され、たいへん注目を呼んでいます。序文にはこうあり… ぶどうの球体2個を電子レンジにかけるとプラズマが発光する現象は今や全人類の知るところとなっている。 これで終わりにしてやるぜ、という本気度がうかがえます。さっそく研究班に取材

加藤公一（はむかず） @hamukazu Kimikazu Kato, ソフトバンク株式会社。博士（情報理工学）。修士は数学（代数幾何学）。にゃーんと鳴く狂犬と呼ばれている。DMは全員に開放中。 著書「機械学習のエッセンス」：bit.ly/mlessence 、監修「機械学習図鑑」bit.ly/mlzukan linkedin.com/in/kimikazukato

はじめに 先日、海外向けに運用していた個人ブログがDDoS攻撃を受けてしまいました。 こういったサイバー攻撃は、企業に対して行われるものという先入観がありました。 しかし、調べてみると、最近では個人ブログも標的になってきていると報告があがっていました。 CloudFrontとS3で作成する静的サイトが人気になっており、特にCloudFrontの危険性について紹介したいと思います。 DDoS攻撃って？ ざっくり説明すると、ウェブサイトやサーバーに対して過剰なアクセスやデータを送付するサイバー攻撃です。 インフラストラクチャーレイヤー攻撃(レイヤー3、4)とアプリケーションレイヤー攻撃(レイヤー6、7)の２つに分類されます。 ご指摘を頂きましたので、訂正いたします。 厳密には、EDoS攻撃でした。 AWS Shield Standard AWSを利用した場合、defaultでAWS Shiel

PythonやJavaScriptに慣れている人ならやってしまいがちのエラーですね。printfの書式と違います。これをコンパイル、実行をすると私の環境では以下のようなエラーが吐かれました。 a.c:3:12: warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *' [-Wint-conversion] printf(1 + 2); ^~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:170:36: note: passing argument to par

// let 論駁可能パターン = 値 else { never型を返す処理 }; let Ok(val) = reqwest::get(url).await else { return }; このコードの意味としてはreqwest::get(url).awaitがOk(結果)を返してきたらvalに束縛し、ダメだったら関数を抜ける、になります。 if-let式 let-else文の詳細を説明する前に、まずはRustのif-let式について説明いたします。 Rustは式指向言語のためifも標準で式になっています。よく他言語では三項演算子使用で宗教戦争が起きていますが「if"式"があれば争いなんて起きないのに...(ﾄｵｲﾒ」といつも思っています。

JavaにおけるNPE(Null Pointer Exception)は「nullのオブジェクトを使おうとしてるぞ」という例外です。例えばmyNote.getLines()という文はコンパイル時にエラーを出しません。ただ、myNote==nullの時にnull.getLines()を実行することになり「nullにgetLines()なんてメソッドはない」という原因でNPEが投げられます。 Javaの参照型オブジェクトは全てnullが入りうるのですが、それを利用すると例外が出ます。危ない。「null安全」という言葉があるくらいですから、丁重に扱うべきでしょう。 nullを安全に扱う方法や仕組みは色々ありますが主にOptionalを使った方法をメモします。(本記事はJava SE 8を念頭に置いて書かれています。) やってしまいがちなミス 「いたる所にnullが入りうるからnullチェックをし

表題の件について私見を述べていきます。あくまでも私見です。 そもそもエディタや IDE 固有の設定ファイルをリポジトリに入れるべきなのか 個人的には用法をしっかりと守った上でなら入れてしまって良いと思っています。 入れたところで他のエディタや IDE の害になるわけではないですし、ファイルサイズも知れたものなのであまりデメリットはないように思います。 逆に入れないことでチームメンバーが各々似たような設定をローカルで書くことになってしまうのは労力の無駄です。 特に同じエディタ・IDE を使用している人が多いチームではなるべく設定ファイルを共有してしまった方が良いのではないでしょうか。 エディタ・IDE 設定をリポジトリに入れるときに守るべき原則 基本的には「チームの利益になるものだけを入れろ」ということになるかと思います。 「個人のための設定は入れるな」と言い換えることもできます。 他の開発

正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、

📡観測範囲 Paiza転職およびGreenを使用 2021年秋～2022年夏に、提示年収400万～のレンジで、フロントエンド／フルスタックエンジニア／クロスプラットフォーム系アプリエンジニア枠で募集かけてる（かけてた）会社 ビジネス形態としてはSES/受託開発/自社サービスと幅広く 業務分野も医療系/建築系/不動産系/金融系/エンタメ系/その他諸々とこちらも幅広く 日本全国対象 面談だけで40社超えてるので求人に目を通したのは60社ぐらいは行ってるのでないかと思います。 またほぼ全部、スカウトメール経由で転職活動を行ったため、自分の技術スタックによるバイアスが入ってます。（RubyよりPHPの方が多い等） 偏りが大きいのでIT業界全体の現況などと口が裂けても言えませんが、逆にあんま表沙汰にならないようなベンチャー、中小零細、レガシー企業、非IT企業のIT部門採用等、色々見てきたので印象深

Go Conference mini 2022 Autumn IN SENDAI の登壇資料です。

この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事

例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根本的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。本当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ

例外処理とは 例外処理とは、想定内のエラー（例外）が起きた時に、その内容に応じて実行される処理のことです。 なぜ、例外処理が必要なのかを説明すると、もしプログラムに適切な例外処理が実装されていない場合、プログラム実行中にエラーが発生してしまうと、意図しない構造のデータが保存されたり、異常終了してしまう事態を招きます。また、その時に発生したエラーを調査するのに時間がかかってしまいます。 ですが、適切な例外処理を実装していれば、データを整合性を保つ事ができ、簡単にかつデバッグしやすい信頼性の高いコードを組むことができます。もし例外が起きてしまっても原因の調査がしやすくなります。 このように、アプリケーションを作成するにあたって適切な例外処理の設計をすることは重要なポイントになります。 例外（エラー）を分類 例外（エラー）と一言で表現していますが、例外（エラー）には複数に分類する事ができます。そ

チェインソーマン最終回とアニメ化と第2部が発表ありましたね。なおアニメは「お住まいの地域ではご覧になれません」ので悲しいです。 本記事では、例外に関しての設計指針を記述したいと思います。 例外の歴史 多くのプログラミング言語でサポートされている「例外」は、構造化例外処理（SEH-Structured Error Handling）などと呼ばれるプログラミング言語の機構です。 以下のような特徴を持っていると思います。 関数などのスコープを超えて大域脱出の処理が可能 実行時のコンテキスト（スタックトレース）を持てる catch句のようなハンドラを持って処理する キャッチ・非キャッチ例外のような種類があるものもある 例外のない言語 それ以前での例外処理はどうだったか？というと、大まかに分けて2種類です エラーコードで区別する グローバルエラーオブジェクトを持つ 1は、言語仕様によってさらに以下の

Gunosy Tech Lab リサーチインターンの北田 (@shunk031)です。 深層学習の論文を読んでいるときに著者実装が公開されている旨を見ると嬉しい気持ちになりますよね。 いざ公開レポジトリに飛んだ瞬間その嬉しさは無となることが多いですが、くじけずにやっていきたいです。 著者実装のrequirements.txtをベースにpythonモジュールをインストールするとよく見るやつ こちらの記事は Gunosy Advent Calendar 2020 6日目の記事です。昨日は @625 さんの goで作るfirehoseのデータ変換lambda でした。 tech.gunosy.io その実験、再現できますか？ リサーチインターンでは主にGunosyのデータを使った研究をしています。 特に私は深層学習による広告クリエイティブの評価や運用支援に焦点を当てて取り組んでいます*1。 深層

This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

設計ナイト2020 https://kichijojipm.connpass.com/event/191220/ に参加してきたので、そのときのレポート 正直、設計に関して疎くて内容の 1 割くらいしか分からなかったのでメモ程度です。 かとじゅんさん発表 資料 https://speakerdeck.com/j5ik2o/event-sourcingwojie-shuo-suru 今日は、分散システムの設計パターンの話をします。 CQRS の話 DDD によるクエリサイドのペインについて クエリ要件を満たすことでリポジトリが複雑になる レスポンス用 DTO をリポジトリで組み立てるため、N + 1 クエリが発生しやすい ドメインオブジェクトから DTO への変換が非効率 ※これらのペインを飲み込めるのであれば、CQRS を採用する必要はない。 CQRS とは リポジトリがステートを書くので

吉祥寺.pm様主催の設計ナイト2020に参加してきました。 ついていけてない部分もあって全部覚えきれていませんが、これ以上忘れる前に書き留めておきます。 CQRS+Event Sourcing 最初はかとじゅんさんによる発表でCQRSとEvent Sourcingについての説明でした。資料は以下のリンクです。 https://speakerdeck.com/j5ik2o/event-sourcingwojie-shuo-suru まとめると以下のような内容でした。 CQRSは境界を引いてCとQを完全に分断しなければならないので、コストがかかる。 Event Sourcing無しでCQRSは難しい。 コストをペイできるほどの大規模なものや、耐障害性を求めないならやらないほうがいい。 かとじゅんさんが提示されていた現実解は私もよくやっていました。WEBサービスをベースに考えますが、そもそもクエ

サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDB、Amazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇

はじめに 本記事の読者対象 Python の開発環境・ツールをさらに覚えたい方 よりモダンに近い Python 環境が欲しい方 想定していない方 Python 自体がはじめての方 Python 上級者 説明すること・しないこと 説明する ツールのおおまかな説明 ツールを使用する理由・嬉しさ 参考になるドキュメント・URL 説明しない 具体的なコマンド 細かい文法 Modern Python 大学院で研究をするようになってから、かなりの時間 Python を書くようになりました。 なぜならば、研究で利用しやすいライブラリが豊富であり、かつ研究のようなイテレーションがはやいプロジェクトに対して非常に有効であるためです。 しかし、Python は短期的にコードを試して動作を変更できる分、安定した動作が難しくなってきます。 たとえば、C++などはコンパイルを通す必要があるため、設計をうまく考えて実

📌 はじめに Pythonで開発を行うにあたり、リンタやフォーマッタ、パッケージマネージャ等のツールの選定は非常に重要な問題です。一方で歴史的な経緯もあり、沢山の選択肢から何を選ぶべきか情報がまとまっていないように感じました。この記事では2021年9月時点でモダンと言えるであろう開発環境を紹介します。基本的にはシェアが高いこと、著名なパッケージで使用されていることを主な選定理由としており、また特定のエディタに依存しないことを前提とします。 本記事で紹介する内容は一つのテンプレートに近く、必要に応じてカスタマイズするもよし、そのまま使ってもよし、として参考になればと思います。(CI/CDについてはPythonとは独立した問題なので触れません。またドキュメント生成はSphinxを推しますが、必須ではないので今回は割愛します。) 📄 要約 "モダン"な開発環境を箇条で列挙すると下記の通りです

【2020年新人研修資料】 ナウでヤングなPython開発入門

はじめに 開発部の tasaki です。 6 月の記事（「Pythonのパッケージングのベストプラクティスについて考える2018」）では setuptools, pip, venv を使ったパッケージングのフローについて考えました。 techblog.asahi-net.co.jp 今回はモダンな開発用ツールチェーンを持つ他の言語（具体的には JavaScript (Node.js), Go, Rust あたりを意識）と似たような開発フローを Python において構築するにはどうすればよいかということを考えていきます。 はじめに 対象バージョン 備考 TL;DR （結論） pip と virtualenv の統合 (Pipenv) 概要 使い方 インストール Pipenv プロジェクトの新規作成 setup.py との併用 静的な型の検査 (mypy) 概要 設定例 使い方 Lintin

この記事は刺身たんぽぽ同好会 Advent Calendar 2021[1] 8日目 の記事です． 7日目はげんしくんの 刺身たんぽぽ同好会を支えるDiscord鯖について - 最近のRecent です． 9日目はおのだ氏の Live2D #1 下準備(予定) です． はじめに Python3.10 がリリースされてから数ヶ月が経ちました．そこで，Python3.10 から入った新機能や，あまり知られていないが[2]，知ってると便利な機能を紹介します．モダン Python を書いていきましょう． 型アノテーション 型アノテーション自体は Python3.5 からある機能[3]ですが，バージョンアップのたびに高機能になっています．Python3.10 では，| 演算子が型アノテーションに対しても使用できるようになりました． 使用例はこのような感じ

毎年恒例、Pythonの本と学び方のまとめ・2019年バージョンとなります. ※2021/1/11更新：2021年版あります ※2020/1/9更新：2020年版もあります, こちらもよろしくおねがいします！ ※ちなみに昨年版はこちら 改めましてこんにちは、Pythonと野球を仕事にしています、@shinyorke（Python歴おおよそ8年）ともうします. なお、Python その2 Advent Calendar 2018 12/24記事でもあります. このエントリーはそこそこ長いので、「最初の方をサクッと読んで、残りはつまみ読み」してもらえると良いかもです！*1 ※もちろん全部読んでも構いません！（それはそれで嬉しい） サクッとまとめると 入り口としての「独学プログラマー」は万人が読んだほうが良い名著 データ分析・解析やりたい人も、Webからやっておくと良いかも（特に前処理） Web

4/30 公開 5/1 増補改訂: 大幅加筆しました。 この記事では、2018年以降に実現可能になったモダンなPythonプロジェクトのはじめかたを整理して紹介します。 PythonにもPipenvという公式推奨の高機能なパッケージマネージャーが登場し、さらに2018年に入ってからの機能向上で、npmやyarnのような開発体験が得られるようになってきました。 私はここしばらくはフロントエンドやNode.jsに携わっていて、npmやyarnに慣れきっていたせいか、pipenv導入以前はvirtualenvやpipを組み合わせた開発が面倒で仕方なかったですが、Pipenv導入によって一変しました。 これからはPythonのプロジェクトがよりクリーンかつ簡単にはじめられるようになり、開発体験も向上するでしょう。 それでは、まずはPythonのインストールからです。 Pythonのインストール P

(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま

Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui

回答 (9件中の1件目) 質問に間違いがありますね。 2000個のコアが入ったGPUなんかありません。企業の広報は違った(間違った)方法で計算して数字を大きく見せています。 Radion 6900XTの本当のコア数(DCU)は、5120個ではなく、40個です。こちらでダイの写真を確認でき、4*5のコアが2グループあります。 各コア(DCU)には32レーンのSIMDユニットが4つあり、各コアには並列に動作する32 bitの浮動小数点演算ユニット(FMA)が128個あり、チップ全体としては32 bitのFMAが5120個同時に動きます。 Zen2とZen3のCPUコアはどちらも256...

Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ

Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか

はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は

Clean Architecture　達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか

Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す

本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部　イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2

Help us understand the problem. What is going on with this article?

言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的に成り立ってしまっているので、それ以上成長をする必要がないのです。 まあ、そういう生き方もありかな？って思うので、それでいいやって思う人は続きは読まなくてもいいかなって思います。 ここから先はエンジニアとして技術を伸ばすことが楽しい、ものを作ることが楽しい、

TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海

この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

おはよう人類。 インフラストラクチャーという言葉は、元々ラテン語に語源があり、inferus(下部の)という言葉とstructura(構造体)という二つの言葉を合成した言葉で、言葉の意味としても、社会構造の中で上部構造である政治基盤に対応する経済基盤としての使い方(主にマルクス経済学で用いられる)と、道路や橋だけででなく教育機関など公共性の高い社会基盤の意味で用いられる。特に、後者の意味が強いのだが、インフラストラクチャーの供給源というのは国や公共的な組織だけにとどまらず、電力会社や鉄道会社、金融機関のように私有なのだが、その性質上インフラストラクチャーとして扱われるものも多い。 こういった企業を(広い意味で)インフラ業と呼ぶことも多いのだが、その公共性の高さから私有にもかかわらず、その運営には様々な規制が加えられていることが多い。設立に免許や認可が必要で、運営に関しても一般の企業とは異な

先日書いた AWS の勉強方法をまとめた記事（AWSを学ぶ上でやってよかった勉強法５選 - log4ketancho）で、「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書きました。その中で、 今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで…… や 「２）簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。 というような利用料金が気になってしまう、、というコメントを幾つかいただきました。 この気持ちとても分かります！業務で使う分にはサーバー何台立てようが気になりませんが（は言い過ぎですがｗ）、個人でサービスを運営する場合はそうはい

TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。

改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か？何が正しくて何が間違っているか？も重要なのだが、それよりは、なぜそれが生まれたのか？何を解決しようとしたのか？どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか？を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M

TikTokは良い動画が一瞬でバズりやすい。それは例え、あなたの最初に投稿した動画だったとしても。これはYouTubeと対極的である。YouTubeでは無名の人がどんなに面白い動画を投稿しても、そもそも誰にも見てもらえない。YouTubeで毎日毎日面白い動画を投稿し、たまたま見てくれた人が読者登録してくれたりして、数ヶ月、半年と努力を継続しなければならない。 一言で表せば、YouTubeは「信用経済」「評価経済」時代のプラットフォームなのである。 たくさんの登録者数を持つYouTuberが強い。少ない登録者数しか持たないYouTuberは弱い。弱いYouTuberは、たくさん登録者数をゲットするまで、修行する。そういう世界だ。 一旦インフルエンサー級まで自分の信用や評価を蓄積することができれば、後は自由自在に動きやすい。他のYouTuberともコラボしやすいし、企業案件もどんどん舞い込んで

フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR

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

本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

やりたいこと（ユースケース）から利用パターンへ到達できるように、ユースケース主導で紹介。利用するサービスのすべての機能をを覚えなくてもやりたいこと/部分からスタートできます。実際、類似するアーキテクチャの実例が多くあることがわかります。 パターン別のテンプレートから始めてみよう!  チュートリアルで体感しよう! - いくつかのパターンはテンプレート/雛形から始めることができます。それぞれのパターンの「Template」「Sample」「Solution」のリンク先を参照ください。 - 実際に作って動かせるチュートリアルに「Tutorial」「Workshop」リンクからアクセスできます。ちょっとしたトライに費用が気にならないのもサーバーレスの良いところ。 - 各パターンの特性に合わせたエラーハンドリングの記事を拡充中。それぞれのパターンの「エラーハンドリング」リンクからご確認ください。 -

400万使ったFGOを辞めて約半年ほど経った。 この前別の記事で同じようなことを書いてる人がいて自分も書きたくなった。 スカスカシステムが出た辺りでやめたが、結局トータルで見ると400万以上使っていた。 FGOをやり始めたのはサービス開始当初で、リセマラで当時強キャラと言われてたヘラクレスが当たったからプレイしようと思った。 そもそもそこそこ生きていると自分の性格が分かってくるもんで、 自分は狭く深く、コンプ癖があり、熱くなって散財しやすいと一番スマホゲーをやっちゃいけないタイプの人間だって分かっていた。 まぁ強キャラ当たったしやるだけやるかなぁと思ったのが運の尽き。 最初から引きが良くてギルやオリオンが当たっちゃうわけだ。 そっから調子に乗って課金額がどんどん増えてって、 最初に課金した時から家計簿アプリで出費額を記録してたんだけど、 狂金時宝具5にした段階でこれまでの合計出費が20万超

FGOに約1年半で400万円程課金しました。 私は、課金で後悔することは無いと思っていました。事実、課金し続けている間、毎月十万、数十万が飛んでいっても、貯蓄が一切増えず減っていく一方でも、自分で稼いだお金だから自分の好きに使っていいと、一切後悔していませんでした。 けれど、今、自分の人生のステージが変わることになり、今後の人生を考えた時、この400万というまとまったお金を課金で失ってしまったことを、ひどく後悔しています。要するに、課金している間の私は、「課金を後悔しない」という考えを持っていたつもりで、その実何にも考えていなかったんです。お金の価値も、お金の使い方も、将来のことも、何にも考えてなかったんです。 箱ガチャでは毎回有給を取って寝る前も惜しんで周回して、欲しかった素材を目一杯集めました。 引き込まれるメインストーリーが好きでした。 けれど、今の私はメインストーリーもクリアせず、

Amazon Web Services ブログ Amazon DynamoDB がニーズに合うかどうかを判断し、移行を計画する方法 AWS CTO のワーナー・ヴォゲルスは、AWS の仕事は「企業の痛みを管理すること」だという冗談を言うことがよくあります。これは、AWS のお客様が直面する IT 面での課題の大半における本質を突く言葉です。「お客様に最大のメリットをもたらすことができるのはどこか」と呼び掛けるだけで、しばしばデータベースと関連するライセンス費用、パフォーマンスとスケーラビリティの管理、そして専門的なデータベース管理者の人件費に関する話し合いが始まります。Amazon DynamoDB などの完全マネージド型の NoSQL データベースサービスは、これらの課題に対応し、多くのメリットをもたらします。 このブログ記事では、お使いのアプリケーションに対するデータベースサービスの候

前巻のおさらい 前巻はDynamoDBのデータモデリングをする前に知っておいた方が良いDynamoDB自体の仕組みやデータ構造のお話でした。 marcy.hatenablog.com 今回は 今回はデータモデリングを行う際に必要なマインドセット、つまり「考え方」について書き記したいと思います。非常によく聞かれる「RDBとの考え方の違い」といった切り口で進めていきたいと思います。 RDBとはアプローチが真逆 RDBのデータモデリングをする場合、まず正規化されたデータのスキーマを決めることから始めると思います。慣れてくると律儀に第一正規化から始めずにいきなり第三正規形あたりから設計しだすことも多いと思います（私もそうです） そして、データのスキーマが決まってからそれに対してどのようにアクセスするか（＝SQL）をアプリケーションを設計する際に考えていくというのがRDBでの一般的なアプローチではな

この記事について 先日 DDD-Community-Jp の DDD Talk MeetUp #2 というイベントでトーク枠にて参加させて頂き Flyweight DDD というアーキテクチャスタイルの提案とする一つのスライドを発表させて頂きました。 https://speakerdeck.com/hirodragon112/ddddao-ru-nita-miqie-renaifang-hezeng-ru-2ceng-plus-cqs-akitekutiya-flyweight-ddd ただ、本稿はこのスライドの「内容」とは全く関係ありません。 本稿で取り上げたいのはこのタイトルに登場している CQSという単語についてです。 このスライドをきっかけにCQSとCQRSの違いについて自分なりに思考の整理を記載したいと思います。 CQS ? CQRS ? きっかけは twitter にて @j5

CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。 なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。 その前に松岡さんの記事について。 CQRSの領域ではモデルを完全に分ける 松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しな

PHPerKaigi2021のアンカンファレンスで使ったものです。 PHPカンファレンス仙台2019の再演です。

AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く

Evolutionary Architecture - Discovering Boundaries @DevTalks 24

レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。 最近はマイクロサービスでシステムを開発しているという話もよく聞くようになってきました。ではそこでメッセージング、そしてKafkaを使ってますでしょうか？マイクロサービスでは何故かRESTばかりが世の中に注目されてしまうことも多いために、今回はメッセージング推しの内容にしています。 マイクロサービスではメッセージングを用いたコマンドやイベントこそ中心であって不可欠です。マイクロサービスの中でメッセージングはどのように利用され、そしてなぜ必要なのでしょうか。今回は「マイクロサービスとメッセージングのなぜ [概要編]」と題してそれを概観していきます。 Kafkaの簡単なおさらい どこでメッセージングは利用されるのか？ RESTはお手軽な解決策？ なぜマイクロサービスにメッセージング(Kafka)が必

この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ

Flyweight DDD 軽量DDDを避けつつ軽量(Flyweight)にDDDを導入するためのアーキテクチャです。

過去に僕が失敗した代表例から今ならどう設計するか、という観点でお話します。中心になるトピックは以下です - 軽量DDDの功罪 - ドメインモデル貧血症対策 - 集約の境界定義の善し悪し

これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話（触ってみたレベルでなく実運用等を経たもの）についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ

本項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 本稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの本質とは何か？押さえておくべき、本当に重要だと考えている三つの事について、お話しします。 注意事項 さて本題に入る前に、少し注意

よく訓練されたアップル信者、都元です。最近DynamoDBづいております。DynamoDBについて全くご存知無い方は、まずは下記エントリーを読んで頂ければと思います。 Amazon RDSとの比較で学ぶDynamoDB 要するに、即時一貫性・操作の原子性・検索条件の自由度を犠牲にして、可用性と拡張性を手に入れたデータベースがDynamoDBであります。では具体的に、データの読み書きはどのように行うのでしょうか。 DynamoDBにおけるコンセプト DynamoDBには主に「table」「item（項目）」「attribute（属性）」という3つの概念が現れます。それに従属する概念として「キー」「インデックス」が出てきます。まずはこの辺りを整理していきましょう。 tableというのはみなさん分かりやすいでしょう。概ねRDBで言うところのテーブルに相当し、itemの集合体です。itemについて

よく訓練されたアップル信者、都元です。AWS上のシステム設計において、どんな時にRDSを選択するのか、そしてどんな時にDynamoDBを選択するのか。比較しながら見て行きたいと思います。 RDBとNoSQL ACIDなRDB 一昔前、一般的に「データベース」と言えば、多くはリレーショナルデータベース（RDB）のことを指していました。テーブルと呼ばれる「行とカラムで構成される二次元のデータ構造」に対して、SQLと呼ばれる強力なクエリ言語で操作を行い、データの一貫性（Consistency: どこから観測しても同じ値が得られること）や操作の原子性（Atomicity: 一連の操作を全て適用commitするか、全てキャンセルrollbackするかの二択として実現できること）を実現するモデルは、開発者を含むシステムの利用者にとって非常に理解しやすく、広く受け入れられて来ました。多くの方がご存知の通

バリデーションチェック、めんどくさいですよね。 最初はFormEncodeでやろうとしたのですが、「もうちょっと今っぽいやつないのかな……」と探したところ、とてもいい感じのライブラリがあったので、使い方をメモしておきます。ご参考になれば幸いです。 Cerberusとは GitHub - nicolaiarocci/cerberus: Lightweight, extensible data validation library for Python 英語読みで「サーベラス」でいいんでしょうか？　いわゆる「ケルベロス」のことで、「冥界の番犬」のようにデータの入り口を守る、というのが名前の由来のようです。厨ニっぽい かっこいいですね。 導入 # -*- coding: utf-8 -*- from cerberus import Validator import re from datetim

はじめに この資料はデータ検証用ライブラリ Cerberus のドキュメントを抄訳したものです。 コミュニティーで Hands-On を行うときの資料として作成したため、 Cerberus の変更履歴などについては触れていません。 また、ソースコードの例示と実行には、IPython を使っています。 $ ipython Python 3.9.7 | packaged by conda-forge | (default, Sep 29 2021, 19:23:19) Type 'copyright', 'credits' or 'license' for more information IPython 7.28.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: IPython の　%load コマンドでソースコー

サーバレスで開発がしたい！でもそもそもサーバレスで使われるサービス全然知らないな。。 そんな方もまだまだ多いのではないでしょうか。そこで今回はサーバレス開発でよく利用されるサービス、API Gateway、Lambda、DynamoDBをマネジメントコンソールから作成し、それぞれを簡単に連携させてみようと思います。 本記事も含め3回に分けて実施します。 初めてのサーバーレスアプリケーション開発 ～DynamoDBにテーブルを作成する～ 初めてのサーバーレスアプリケーション開発 ～LambdaでDynamoDBの値を取得する～ 初めてのサーバーレスアプリケーション開発 ～API GatewayからLambdaを呼び出す～ ↓追加しました。 初めてのサーバーレスアプリケーション開発 ～Serverless Framework を使ってAWSリソースをデプロイする～ 初めてのサーバーレスアプリケ

DevelopersIOは、AWS、iOS/Androidアプリ、ビッグデータ、Alexa等の最新技術情報からリモートワークや働き方に関する記事まで多彩なトピックを紹介するクラスメソッドのオウンドメディアです。

2020/01/20 Update: 本エントリの内容は2019年12月3日にアナウンスされた『Amazon RDS Proxy』のリリースにより完全に陳腐化しました。過去のアンチパターンがフィードバックをもとにした改善によってアンチパターンではなくなるという最高の事例です。 サーバーレス元年始まった！ 今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから. ・カスタムランタイムで実質どんな言語でも利用可能 ・VPC利用時のコールドスタート改善 ・Provisioned Concurrencyでスパイク対応も可能 ・RDS ProxyでRDBとの接続が現実的に これまで5年で受けたフィードバックがついに結実. 強い— Keisuke Nishitani (@Keisuke69) 2020年1月19日 RDS Proxyの詳細はこちらからどうぞ。まだプレビューですがぜひ試して

この記事は、LIFULL Advent Calendar 2017の2日目の記事です。 おはようございます。新UX開発部の二宮( @ninomiyt )です。 LIFULLではデータ解析や最適化の用途、もしくはAWS Lambda上の簡易ツール実装用途などでPythonがそれなりに普及してきました。数値計算寄りの（いわゆるデータサイエンティスト的な）メンバーも今はPythonを使うことが多く、コード量としては小規模なプロジェクトが多く、簡単なAPIやバッチ処理の実装までやってもらうこともあります。 そのレビューをやっていく中で、「これ使うともっと簡単に実装できるよね」っていうライブラリがいくつかまとまってきたので紹介します。 click コマンドラインパーサー用のライブラリで、デコレータを使って関数を簡単にCLI化できます。 標準ライブラリのargparseがありますが、clickではバリ

Amazon Web Serviceが提供する、SSD上に構築された高速でスケーラブルなNoSQLデータベース「Amazon DynamoDB」が、東京データセンターでも利用可能になりました。 DynamoDBは、単にNoSQLの持つ高いスケーラビリティを提供するだけではなく、一貫性の制御が可能で、必要なスループット性能も自由に設定できるなど、従来のNoSQLとは一線を画す高性能を、メンテナンスなどの管理の手間をまったく必要とせずに提供するサービスです（関連記事「Amazonクラウド、SSD上の新NoSQLデータベース「DynamoDB」を公開。性能をダイナミックに上げ下げ可能」）。 このDynamoDBの開発経緯や技術について、Amazonのバイスプレジデント兼最高技術責任者（CTO） ヴァーナー・ボーゲルズ（Werner Vogels）氏に、テレビ会議を通じてインタビューを行いました。

{"name": "佐藤", "age": 22, "edu-background": "Hoge University"}, {"name": "鈴木", "age": 24, "edu-background": "Fuga University", "foreign-lang": ["English", "Spanish"]}, {"name": "髙橋", "age": 25, "edu-background": "Fuga University", "foreign-lang": ["English"], "written-book": ["Intro to DB"]}, {"name": "田中", "age": 33, "edu-background": "Foo University", "written-book": ["Intro to Java", "Advanced

こんにちは、エンジニアの肥前です。この記事は Serverless Advent Calendar 2018 の13日目です。 また、HiCustomer Tech Blog の最初の記事でもあります。今後もチームで継続して得られた知見を書き溜めていく場にしたいなと思います。 さて、いわゆる ”サーバーレスアーキテクチャ” を採用してスタートアップのプロダクト開発を開始しておおよそ一年が経過しました。もちろん恩恵に預かっている部分、省力化できた点は多々あるのですが、今改めて振り返るとアンチパターンを踏んでいたり、このまま放置すると負債化しそうな箇所が見えてきています。失敗した話というのはなかなか表に出しづらいものではあるのですが、少しでもこれから取り組む方の助けになればと思い記事に残してみようと思います。サーバーレス界隈の方々にはあるあるネタだと思うのでご笑納ください。 前提となる構成 事

Amazon Web Services ブログ ZOZOTOWN のショッピングカート移行プロジェクトを支えた Amazon DynamoDB このブログでは、リレーショナルデータベース管理システム (RDBMS) のパフォーマンスの問題があった e コマースサイトのケーススタディと、Amazon DynamoDB がソリューションにどのように貢献したかを解説します。ZOZOTOWNには大規模な販売イベントがあり、サービスに何か問題が起きた時に対応するため、エンジニアがリアルタイムで監視を行なっていました。DynamoDB によって ZOZO はエンジニアリングのオーバーヘッドを 85.8% 削減できました。また、DynamoDB のベストプラクティスもいくつか紹介します。 この投稿は、日本有数のファッションオンライン取引サイトの1つであるZOZOTOWNのDynamoDB利用に焦点を当て

DynamoDBを利用するためのポイントをざっくりまとめた。 リンク集みたいな感じになっていますが、どこから手をつけて良いかわからない方は参考にしてみてください。 目次 DynamoDB概要 Amazon DynamoDB は、どのような規模でも信頼性が高いパフォーマンスを維持できる、非リレーショナルデータベースです。 完全マネージド型、マルチリージョン、マルチマスターのデータベースで、レイテンシーを 10 ミリ秒未満に維持でき、 組み込みのセキュリティ、バックアップと復元、インメモリキャッシュを利用できます。 Amazon DynamoDB DynamoDBの特徴 フルマネージドサービス データの格納と取得に特化（高度な最適化）されている 表結合など柔軟なクエリを発行するのは不得意 「値」とそれを取得するための「キー」だけを格納するというシンプルな機能を持った「Key-Valueストア」

サーバレスアーキテクチャを検討する際に、データベース層をどうするかはよく議論になります。リレーショナルデータベースに慣れている人は、なんとか RDS を採用できないか考えるのですが、現状は DB のコネクションプール問題などで RDS を用いるのはアンチパターンと言われています。 代替として用いられるのが NoSQL 型のデータベースである DynamoDB です。前述のような問題は発生せず、AWS でサーバレスなシステムを構築する際にデータベース層に採用されることが多いです。 しかし、これは私だけかもしれませんが、DynamoDBの（というよりも NoSQL 型データベースの？）設計に慣れていないこともあり、 「この要求・要件を実現するときに、どうテーブル設計すべき？」 「この設計で将来の機能拡張に耐えられるの？」 と不安になるシーンが多いです。特に後者が多く、これまでも「既に見えている

Serverless Web Hosting Strategy
For Modern Front-end Application

はじめに DynamoDBは上手く使えば非常に強力なDBMSですがRDBとの違いは大きく、「RDBの代わりにDynamoDBを使おう！」と深く考えずに提案/採用することが難しいことから、その理由についてみていきます。 DynaomoDBの難しさ DynamoDBの利点と表裏一体である、DynaomDBの主要な難しさについて順番に見ていきます。 1. 提供されているクエリモデルでできることが非常に限定されている DynamoDBは次の公式サイトに記載がある通り、どんな規模でも数msの一定のパフォーマンスを発揮でき、無尽蔵にスケールできるという特徴があります。 Fast, flexible NoSQL database service for single-digit millisecond performance at any scale この特性を上手く活用すると次の実例のように高可用性、

AWSはNoSQLデータベースサービスのDynamoDBが、SQLで操作可能になるSQL互換のクエリ言語「PartiQL」に対応したことを発表しました。 You now can use PartiQL (a SQL-compatible query language) to query, insert, update & delete table data in DynamoDB. PartiQL makes it easier for you to interact with DynamoDB & run queries in the AWS Management Console. https://t.co/qlRwzYZCPC pic.twitter.com/pVaX5xlEDu — DynamoDB (@dynamodb) November 23, 2020 DynamoDBはキーバ

AWS Dev Day Tokyo 2018の登壇資料です https://aws.amazon.com/jp/aws-devday-tokyo-2018/

動機など 最近、Serverlessの文脈からDynamoDBのテーブル設計の相談を受けることが多くなってきていて、Podcastでも話したけどけっこう図とかが無いと説明しづらい領域なので、まとまった資料がほしいなということでまとめてみる。 cloudinfra.audio どう考えても長編大作エントリ不可避なので気力が続けば第二巻以降に続きます…！（フィードバックが多いと頑張れるかも…！） 本巻の対象と前提知識 本巻はDynamoDBのデータモデリングにスコープを絞っています。DynamoDBおよびデータベースの一般用語などについての説明は省きます。 前提知識としては以下のようなものになるかと思います。 DynamoDBのサービスとしての概要や用語( WCU , RCU , GSI , LSI など)を知っている Hash TableやB-Tree(B+Tree)といったデータ構造がどん

Database Lounge Tokyo #6の発表資料です。 （参考URL） ・NewSQLのblog https://qiita.com/tzkoba/items/5316c6eac66510233115 https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f ・B-TreeとLSM-Tree https://docs.google.com/presentation/d/e/2PACX-1vSNk8RkQrVRm_BNZKYyz0sl1k7C6yjTfJIqfMDxnnka8f4pfpf6j2yuXvxvyVGnrzRERdAaxNbOU-CT/pub?start=false&loop=false&delayms=3000&slide=id.g4c1e3ed2c3_0_6 ・ConsistencyとIsolation https://f

この記事は、第2回ウェブシステムアーキテクチャ研究会の予稿です。 ウェブシステムをモニタリングするために、高可用性、高書き込みスケーラビリティ、メトリックの長期保存が可能な時系列データベースが求められている。 これらを実現するために、性能特性の異なる汎用Key-Value Store(以下KVS)を組み合わせ、透過的に問い合わせ可能な、ヘテロジニアス時系列データベースであるDiamondを開発した。 この記事では、Diamondを分散システムの観点で捉え、アーキテクチャ、データ構造、実装を紹介し、考察によりFuture Workを議論する。 1. はじめに 2. アーキテクチャ アーキテクチャ概要 動作フロー データ構造 KVSの機能要件 3. 実装 実装概要 KVS間のデータ移動 データ位置の解決 費用特性 4. 考察と今後の課題 Diamondの欠点 将来機能 5. まとめ スライド

Qiitaにも記事があります https://qiita.com/_kensh/items/2351096e6c3bf431ff6f サーバーレスでよく利用される Amazon DynamoDBですが、設計方針はRDBMSと違うとよく言われます。 アクセスパターンに従った、DynamoDBならではの設計の仕方を一緒に学んでみませんか？

Amazon DynamoDBは、RDSのようなインスタンスサイズによる課金モデルではなく、ストレージのデータ使用量とスループットを基にした課金モデルになっている。 インスタンスサイズによる課金モデルでないデータストア系サービスとして、他にはS3、Kinesisなどがある。 これらは、AWSの中でも、フルマネージドサービスと呼ばれる位置づけとなるサービスだ。 フルマネージドサービスは、ElastiCacheのようなそうでないものと比較し、AWSに最適化されていて、サービスとしてよくできていると感じている。 Mackerelの時系列データベースのスタックの一つとして、DynamoDBを採用している。 時系列データベースの開発は、コストとの戦いだったために、それなりにコスト知見が蓄積してきた。(時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ) (※ 以下は、2018

2019年6月20日追記： この度は、本ブログにて技術的に誤った記事を掲載したことをお詫び申し上げます。具体的には以下の通りです。 一方的にRDBがスケールしないという技術的根拠が薄い内容となっていました。 RDBとAmazon DynamoDB（以下、DynamoDB）/NoSQLデータベースを要件に応じて適切に選択するという内容になっていませんでした。また、本来考慮すべきアプリケーションの設計やデータアクセスパターンに言及しておらず、RDBのデメリットの部分にのみ焦点を当てる内容となっていました。 DynamoDBの具体的な活用やDynamoDBを使う上での注意点についても触れられていない不明瞭な記載でした。 当初の記事の目的としましては、特定のユースケースをサンプルとして、最適なデータベースを選択頂くことでした。近日中に正確な技術記事を掲載させて頂きます。 以下の内容は修正前の内容と

はじめに こんにちは。nari(fukubaka0825)と申します。 今回は、およそ3週間くらいで掲題の資格を取得しましたので、その経緯と勉強法などをまとめてみたいと思います。(勉強時間でいうと40時間くらい) ３週間でAWS認定ソリューションアーキテクト-アソシエイト-とったので、勉強法などまとめてみる｜Wano Group Developers Blog (こちらであげたものと同じ内容です） ※こちらは2019年3月13日受験時点での内容となります。ご了承ください。 前提 AWS業務未経験 自学でもほぼ未着手(EC2たてたことあるくらい) きっかけ そもそも業務で使いまくっている用語が分からなすぎる 私は、もともとSIの人間で、メインフレームの保守をしているレガシーな部署から、 転職してGoとAWSでの開発をするチームに2月からjoinしたところなんですが(寒暖差で風邪ひきそう) 「

Serverless Meetup Tokyo #11 での発表で使用したスライドです。 外部リンク: Serverless Meetup Tokyo #11 https://serverless.connpass.com/event/119559/ HiCustomer https://hicustomer.jp ServerlessなサービスのBlue/Greenデプロイメントの現実 | HiCustomer Tech Blog https://tech.hicustomer.jp/posts/blue-green-deployment-in-serverless/ サーバーレス失敗談 - テーブル設計編 | HiCustomer Tech Blog https://tech.hicustomer.jp/posts/serverless-fails/

Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R

ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝

こちらの記事は6 things I’ve learned in my first 6 months using serverlessの和訳になります。 サーバーレスの世界は適切なツールさえ見つければミドルレイヤーを省けるのでとても良いものです。 10月に行われたServerlessconfの後、自分の会社を全てサーバーレスにすることに決めました。最初の２ヶ月は　Python Flask appにLambdaを導入するのに必死でしたが、そのおかげでより良い方法を思いつきました。 そして６ヶ月後、私たちにとって４番目に大きいプロジェクトをサーバーレスでデプロイすることになったのです。以下の内容がデプロイするまでに私たちが学んだ教訓、意見です。 レッスン１　Pythonの使用は避けましょう Flaskは昔ながらのリクエスト、レスポンスのスタイルで、サーバーによって管理されるセッションがあるWeb

はじめに このツイートに結構反響があったので、雑になるがとにかく自分の考えをダンプする。もともと書いていた記事はうっかりやらかしてデータロストした、泣きたい。 話をわかりやすくするために、ALB+ECS（Fargate）を使ってWebAPIと対比して説明しているが現実はもっと複雑である。 引用リツイートをもらえた部分などについてもアンサーっぽいことも書いていく。 AWS利用費と人件費の話 AWS上にWebAPIを構築する際に、AWS利用費の削減をモチベーションとしてApiGW+Lambda構成が、採用されることがある。確かにAWS利用費は下がるがApiGW+Lambda構成を設計〜運用するためにはAWSに関する知識の中でもとくに専門的な知識が必要になる。こういった人材を雇用または外部へ発注し続けることは人件費に跳ね返ってくる。 ApiGW+LambdaがWebAPIのための構成として唯一無

Presented by: Tomoki Nishinaka, Yu Zhouxun PayPayの機能の一つとして2020年4月に新たにリリースされた通知サービスでは、スケーラビリティとパフォーマンスを重視し、数々のデータストアソリューションの中からDynamoDBを採用しました。通知センターの設計からリリースまでにおける検討プロセスや、DynamoDBを使った開発/運用手法、及びテーブル設計のtipsについてご紹介します。

※Read / Write のレスポンスタイムは大まかに計測した値のため適切な設定ができていない場合もあることをご了承ください MySQL 信頼と実績のあるRDBMS。新規タイトルの場合AWSではAurora、GCPではCloud SQLを利用することで運用の手間をある程度減らすことができる。分散システムではないため1クラスタでの書込性能には限界があり、ソーシャルゲームのように大規模なwrite処理がある用途では水平/垂直分割が必要になり、そのための設計とコーディングが煩雑になりがちである。またインスタンスのスケールアップ・ダウンで対応しきれない場合のクラスタの分割・統合のオペレーションは複雑なものになる。 スケールアップ・ダウンやnodeのメンテナンスなどでMaster nodeを切替える際には不通時間が発生してしまうため、安全のためゲーム自体をメンテナンス状態にする必要が発生する。 ※

2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを振り返ってみて、サーバーレスアーキテクチャとは何かを改めて考えてみる。 サーバーレスとの個人的関わり サーバーレスアーキテクチャという名を僕がはじめて耳にしたのはAWS Lambdaが登場した2015

AWS Lambdaの環境がどのようになっているか、ユーザが用意したLambdaファンクションがどんな感じで実行されるかってあたりを可能な限り詳しく説明したいと思います。 はじめに 大前提 コールドスタート/ウォームスタート コントロールプレーン/データプレーン アイソレーション AWS Lambdaのコンポーネント群 同期実行かつ初回呼び出し（コールドスタート）、もしくはスケーリング 同期実行かつ再利用（ウォームスタート） 非同期実行 スケールアップ エラーハンドリング リトライ その他 ネットワーク まとめ はじめに この投稿は2020年9月29日の21時から開催予定のイベント（ライブストリーミング）で話す内容です。 serverless-newworld.connpass.com もし間に合えば、かつ時間があればぜひライブ配信のほうにも参加ください。 （2020.09.30 upda

こんにちは！sakasegawaです！ ( https://twitter.com/gyakuse ) 今日は今流行のChatGPTについて紹介します！ ChatGPTとは OpenAIが開発するGPT-3(※)というめちゃくちゃすごい言語モデルをベースとしたチャットアプリです。 色んな質問にすぐ答えてくれます。 この記事ではさまざまな使い方を紹介します。 https://chat.openai.com/ ちなみにGPT-3関連では、noteの以下記事も便利なのでぜひ読んでみてください AIがコミットメッセージ自動生成！神ツール『auto-commit』『commit-autosuggestions』の紹介 ※正確にはGPT-3.5シリーズと呼ばれています ChatGPTの仕組みを考えながらプロンプトを作る手法はこちらに別途まとめています 文章 質問-応答 〜について教えて Wikiped

サッカー サッカー日本代表 「あれは“私たち”のシステムだ」元広島・ミキッチが語る森保監督の手腕とは？ 露骨な“手のひら返し”に「すべてが白か黒じゃない！」

この記事はNuco Advent Calendar 2022の1日目の記事です はじめに やる気を削ぐ会議術 会議（かいぎ）は、関係者が集まり、特定の目的（議題）に関して意見交換・審議し、合意・施策などの意思決定をすること、およびその物理的構成員の集まりを意味する。 会議 - Wikipedia 仕事でエンジニアリングを行う人々にとって会議という営みは不可欠である。 そもそも会社という複数の人々の共同体を会議なしで運営することが不可能であることから、当然職業エンジニアにとっても会議は避けられない。 システムの仕様決めのためのチーム内外での話し合い 非IT部門に対するサポートのための説明会 顧客に対する技術的なプレゼンテーション 上司との1on1 etc... 上記のように様々な目的で会議は日々開催される。 開発が仕事であるエンジニアにとっては会議そのものは間接的な業務であるから、会議そのも

ChatWithChatGPT.md 結城浩とChatGPTの対話 2022年12月2日 「質問」は結城浩の文章です。 「回答」はChatGPTの文章です。 質問 ChatGPTという対話するAIツールがあります。人間が質問を投げかけるとそれらしく対話して回答してくれるツールです。こういうツールに対してどんな質問を投げかけたらおもしろい対話になるでしょうかね。何かアイディアがあったら聞かせてください。具体的な質問を知りたいなあ。 回答 ChatGPTは自然言語処理能力が高いため、人間が自然に投げかける質問をそれらしく受け答えることができます。例えば、ニュースやスポーツに関する話題、人間の心理や行動、哲学的な問題、文化や歴史に関する話題など、様々なテーマについて対話することができます。また、ChatGPTを用いた対話は、人間のようなスムーズな会話のように進むことができますので、おもしろい対話

サッカーワールドカップカタール大会、グループEの日本は、1次リーグの第3戦でスペインと対戦し2対1で勝って1次リーグ2勝1敗とし、2大会連続の決勝トーナメント進出を決めました。 日本は決勝トーナメントの1回戦でグループFの2位のクロアチアと対戦します。試合開始は日本時間今月6日午前0時の予定です。また日本時間の3日に決勝トーナメントに進む16チームがすべて決まり、この結果、日本がクロアチアに勝った場合はブラジル対韓国の試合で勝利したチームと対戦することになりました。 ※試合経過の詳細、森保監督・選手の談話は記事後半にあります。 《試合結果》日本2-1スペイン コスタリカ2-4ドイツ 《グループE 最終結果》 順位　　　　　試合｜勝ち点｜得失｜総得点 １　日　本　　｜３｜　６　｜＋１｜　４ ２　スペイン　｜３｜　４　｜＋６｜　９ －－－－－－－－－－－－－－－－－－－ ３　ドイツ　　｜３｜　

言語実装 Advent Calendar 2022の１日目の記事として書いた。 Lisp Advent Calendar 2022でも枠が空いていたのでダブル投稿。 プログラミング言語を実装してみたい！と思ったらまずは簡単なLispインタプリタから始めるというのは一つの王道だと思う。 複雑な構文解析は要らず最低限の再帰下降法パーサで手に入る構文木を、そのまま再帰的な関数で実行していくtree walking評価器。メモリ確保もヒープにそのまま置いていって、メモリ解放は実装言語のGCに任せるなりプログラムの終了時までやらなかったり。そんなインタプリタを作る経験から得られるものは非常に大きく、どんなプログラマでも一回は試してみてもいいのではないか？と思っている。（個人的な感想です） そんな簡易Lispを実装してみて沼にハマってしまい、より精緻な言語処理系を作りたいと思ったとする。その時点で：

» 【衝撃】コメダ珈琲店のハンバーガーをアメリカ人に食べさせてみたら意外な事実判明！ アメリカにはアレがないってマジですか!? 特集 【衝撃】コメダ珈琲店のハンバーガーをアメリカ人に食べさせてみたら意外な事実判明！ アメリカにはアレがないってマジですか!? 中澤星児 2022年12月1日 ボリューミーなことで知られるコメダ珈琲店。一応、コーヒー屋を名乗っているが、想像を絶する爆盛りっぷりで「逆写真詐欺」とまで言われることも。 そんなコメダ珈琲店のハンバーガーをアメリカ人が食べたらどう思うのか？　気になったので、アメリカ人の男女に食べてもらい意見を聞いてみたところ衝撃の事実が判明したでござる。 ・やれんのか！コメダ！2022 パティが肉厚でバンズもふわっとボリューミー。なにより、マクドナルドの2倍くらいのサイズがあるコメダのハンバーガー。今回はスタンダードである「自慢のドミグラスバーガー」を

学生時代に友達と3人で深夜にドライブしていたときに起きた事件だけど。 ドライブの途中から後部座席でずーっと爆睡していた俺がふと目覚めると、根っからの車オタクのB君が運転初心者のA君に対して助手席からなにやら怒っていた。 「120出せ！！いいから出せよなにやってんだよ！！」 「制限速度50キロだぞ！」 とＡ君がイライラしながら返すとＢ君は 「バカお前、こんな夜中の幹線道路じゃ飛ばすのが当たり前なんだよ。せめて100出せ！！周りに迷惑するから！！」 と呆れて言った。 真に受けたＡ君がアクセルを踏み込み100くらい出したら、真後ろについて走ってたシャコタンのヤン車がすぐさまＦ１グランプリみたいな挙動で僕らの車をぶち抜き一瞬で真ん前を陣取って急ブレーキを踏んできた。 続けてそのヤン車がかっ飛ばして遠く先へ行ってしまったかと思うと、今度は真っ赤なブレーキランプを凄い速さで点滅させて急減速し、僕らを追

スーパーで198円くらいの冷凍パスタ買って食べたんだけど、旨すぎない？ ママーのカルボナーラの平麺のやつ。こんなのが198円で食べられるなんて、バグじゃないの？ そのあとスパ王のトマトニンニクのパスタも食べたけど、これも旨い。かなり。 冷凍パスタエグすぎる。 メーカーどこかなって思ったら、どっちも日清だった。どういうこと？ブランドが違うだけ？？ まあそれはどうでもいい。みんな、冷凍パスタ食べよう。スーパーなら200円でお釣りが来るぞ。 パスタ茹でてソースかけて食べるのもいいが、冷凍パスタならレンジで6分くらいだ。 じゃあ俺は今からボロネーゼ食べるから。みんなも気になったら食べてくれよな！

www.django-rest-framework.org Serializers Declaring Serializers（シリアライザを定義する） Serializing object（シリアライズする） Deserializing objects（デシリアライズする） Serializers Serializers は、Django の QuerySet や、モデルのインスタンスを、（dictのような）Pythonのネイティブなインスタンスに変換するライブラリです。Python のネイティブインスタンスに変換することで、そこから簡単に JSON や XML に変換できるようになります。 Serializers には、シリアライズだけでなく、デシリアライズの機能もあります。つなり、さまざまなインスタンスを、model や QuerySet に変換することもできます。 Django R