Python(pytest)でテスト書くならfixture,conftest,parametrizeを理解すると世界が一気に変わる
Python(pytest)でテスト書くならfixture,conftest,parametrizeを理解すると世界が一気に変わる 概要 Pythonのテストライブラリといえばpytestが一般的です。 Python標準のuniitestとは異なり、クラスベースではなく関数ベースでテストコードを記述することが一般的ですが、fixture,conftest,parametrizeを理解すると一気に世界が変わり、テスト体験が圧倒的に向上するため、これらの実装方法を紹介します。 リポジトリ 本記事の説明に使用しているサンプルのテスト実装は、以下のリポジトリです。 想定読者 PythonやGitの基本的な使い方を理解している方を想定しているため、基本的な用語説明は省略しています。 環境 エンジニアの利用率の高いmacOSを前提として説明していますので、その他の環境の方は随時読み替えてください。 開
Rust の DI を考える –– Part 2: Rust における DI の手法の整理 - paild tech blog
paild 社でお手伝いをしている yuki です。前回に引き続き Dependency Injection 略して DI の話題を書いていきたいと思います。今回は Rust における DI についていろいろと考えてみました。今回紹介する実装はかなり単純な例を用いたもので、この記事からさらにみなさんのアプリケーションの実装状況に合わせていくつか工夫は必要になるかもしれません。ただ、とっかかりとしては十分なものになっていると思うので、DI でお困りの方はぜひ参考にしてみてください。 今回実装したいアプリケーションのお題について 今回紹介する技法の種別について コンストラクタインジェクション 静的ディスパッチを用いたもの 動的ディスパッチを用いたもの 静的ディスパッチと動的ディスパッチの利点・欠点 shaku （DI コンテナ）を用いたインジェクション shaku の利点・欠点 余談: DI
Rust の DI を考える — Part 1: DI とは何だったか - paild tech blog
paild 社でお手伝いをしている yuki です。みなさんは Rust で DI をしようと思った際に困ったことはありませんか？この連載では、他のプログラミング言語で利用される DI パターンを参照しながら、Rust でそれを実装するためにはどのような工夫が必要かまでを検討します。中には Rust での実装が難しいパターンも出てくるかもしれません。その際は、なぜ難しいのかまでを検証します。 そこそこの規模のソフトウェアを実装するにあたって、ソフトウェアエンジニアが共通して利用する手法がいくつかあると思います。その中でも DI (Dependency Injection; 依存オブジェクト注入) は最もポピュラーな手法の一つであり、保守運用まできちんと耐えうるソフトウェアの設計をしたいとなったときに、まず真っ先に候補に上がる手法でしょう。 Rust ではこの DI をどのように行えばよいの
AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ
このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日本語訳になります。 オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください：石のない土地はなく、骨のない肉はありません。OSI（オープンソースイニシアチブ: オープンソースを促進することを目的とする組織）が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Pu
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
O/Rマッパーによるトラブルを未然に防ぐ
2. copyright © 2014 kuwata-lab.com all rights reserved まえがき 現在、アプリケーション開発の現場では O/R Mapper (ORM) が普及しています。今後 も ORM を使った開発は、増えることはあっても減ることはないでしょう。 しかし ORM は、アプリケーション開発者にとっては便利でも、DB 管理者 (DBA) か らみたらトラブルの種でもあります。それが特にパフォーマンスに関する問題であるこ とが多いため、開発者と DBA が対立することも珍しくありません。 とはいえ、ORM による問題はすでに解決策が用意されている場合があります。本当の 問題は、すでに存在する解決策があまり知られていないことではないでしょうか。 そこで本発表では、ORM によってどのような問題が起こりやすいか、どう解決・予防 すればいいか、そして ORM
データのためのGit（およびGithub） | オープンデータとオープンガバメントを推進する Open Knowledge Japan
（訳注：この記事は本家OKFn.org記事の日本語訳です） データのために「バージョン管理」を行う能力は重要な関心事です。様々な選択肢がありますが、最も魅力的なもののひとつは、Git やMercurial のように、コード用の既存ツールを再利用することです。この投稿では、私たちが暫くの間使用してとても効果的だということが分かったツールを利用する、データの格納とバージョン管理のための単純な「データ・パターン」について記述しています。 序章 行われた変更を格納し、それを他の人と共有する、データのバージョンとリビジョンを管理する能力、とりわけ分散的な手法は（オープン）データ・コミュニティにとって大きな便益となるでしょう。私はその理由を以前（こちらの初期の記事を参照）議論しましたが要約すると： 効率的な分散型の共同作業が可能です。私のデータセットを取り出し、変更し、それを再び私と（同時に他の人とも
間違いだらけのSQL識別子エスケープ
これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。 間違いだらけのSQL識別子エスケープ(本稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいか ということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。本稿に登場する人物と団
Database smells
1. Database Smells データベースの不吉な臭い ＠データベース・リファクタリング読書会 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、私自身 の見解であって、オラクル・コーポレーションの見解を必ず しも反映したものではありません。ご了承ください。 3. 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – Twitter: @nippondanji ● MySQL サポートエンジニア – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 – サポート一筋
いきあたりばったりのアーキテクチャと教訓
スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです（訳は前述の記事「データベースの間違った使い方10項目」から）。 Dynamic table creation（動的なテーブルの作成） Table as cache（テーブルをキャッシュとして使う） Table as queue（テーブルをキューとして使う） Table as log file（テーブルをログとして使う） Distributed Global Locking（分散したグローバルなロック）
データベースの間違った使い方10項目
一般的なシステムで広く利用されているリレーショナルデータベースですが、システムの進化と共にデータベースの構造も複雑になりがちです。RestMQの作者、Gleicon Moraes氏の公開したスライドがシステムが複雑化していく様子をわかりやすく説明した上で「アンチパターン」を提示していました。 それによるとデータベースのアンチパターンは以下の通り。 動的なテーブルの作成 テーブルをキャッシュとして使う テーブルをキューとして使う テーブルをログとして使う 分散したグローバルなロック ストアドプロシージャ 使われない項目 JOIN地獄 ORMによって繰り返されるクエリ 負荷のコントロール どれも理由があって採用されるデザインですが、確かに後に問題を引き起こした経験もあり耳が痛い感じですね。スライド内ではそれぞれの問題についての解決策としてMongoDBやRestMQなどの利用を進めています。「
リードスルー、ライトスルー、ライトビハインド・キャッシュおよびリフレッシュアヘッド
9 リードスルー、ライトスルー、ライトビハインド・キャッシュおよびリフレッシュアヘッド Coherenceでは、データベース、Webサービス、パッケージ化されたアプリケーション、ファイル・システムなど、任意のデータソースの透過的な読取りまたは書込みのキャッシングがサポートされていますが、一般的にはデータベースが最も一般的に使用されています。ここでは、任意のバックエンド・データソースのことを、簡単にデータベースと呼びます。効率的なキャッシュでは、集中的な読取り専用操作および読取り/書込み操作をサポートし、読取り/書込み操作の際には、キャッシュとデータベースは完全に同期化されている必要があります。これを実現するために、Coherenceではリードスルー、ライトスルー、リフレッシュアヘッドおよびライトビハインド・キャッシュをサポートします。 注意: パーティション（分散）およびニア・キャッシュ・
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching
RDBアンチパターン // Speaker Deck
PHPerに知ってほしいRDBの事 その3
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」