pytest でテストケース毎に DB を自動的に初期化して、テスト開発体験を向上させる - SalesNow Tech Blog
概要 Web バックエンドのテストコードを書く場合、その多くは DB に依存していることが多いです。 DB 関連のテストは、テストデータの準備やテストケース毎の DB 処理化を適切に行うことが重要ですが、手間がかかる場合あるため、Mock で擬似的にテストしてしまうことも多いかと思います。 ただ、Mock を使ったテストは本質的な問題を検知できない意味のないテストになってしまう可能性があり、可能な限り DB の Mock を行わずに、実際の DB を使用してテストすることが望ましいと考えています。 本記事では、pytest、sqlalchemy、PostgreSQL を使った場合に、テストケース毎に DB を簡単に初期化しつつ、テストケース毎の前提データ登録も簡単うことでテスト開発体験を向上させる方法を紹介します。 前提環境 本記事では、以下の環境を前提として説明いたします。 python
Python(pytest)でテスト書くならfixture,conftest,parametrizeを理解すると世界が一気に変わる
Python(pytest)でテスト書くならfixture,conftest,parametrizeを理解すると世界が一気に変わる 概要 Pythonのテストライブラリといえばpytestが一般的です。 Python標準のuniitestとは異なり、クラスベースではなく関数ベースでテストコードを記述することが一般的ですが、fixture,conftest,parametrizeを理解すると一気に世界が変わり、テスト体験が圧倒的に向上するため、これらの実装方法を紹介します。 リポジトリ 本記事の説明に使用しているサンプルのテスト実装は、以下のリポジトリです。 想定読者 PythonやGitの基本的な使い方を理解している方を想定しているため、基本的な用語説明は省略しています。 環境 エンジニアの利用率の高いmacOSを前提として説明していますので、その他の環境の方は随時読み替えてください。 開
ChatGPTで個人情報漏えい OpenAIが原因と対策を説明
米OpenAIは3月24日（現地時間）、20日にChatGPTを短時間オフラインにした理由を説明した。ユーザーに別のユーザーの氏名、メールアドレス、住所、クレジットカード番号の下4桁、カードの有効期限が表示される問題があったためオフラインにし、バグを修正したという。 個人情報が漏えいしたのは、有料版「ChatGPT Plus」の会員の約1.2％で、影響を受けた可能性のある全員に連絡したという。 この問題と同時に、一部のユーザーに別のユーザーのチャット履歴が表示されてしまう問題も発生していた。 ChatGPTのチャット履歴は、画面の左側にあるサイドバーに表示され、クリックするとチャットの続きを再開できるようになっている。このサイドバーに他人のプロンプトが表示されていた。 OpenAIによると、バグは修正され、「数時間分を除いて、チャット履歴を復元できた」という。 チャット履歴と個人データが他
『仕事ではじめる機械学習』＆『前処理大全』著者対談（Part 1）
今回より4回を予定して、書籍『仕事ではじめる機械学習』著者の有賀康顕さん、『前処理大全』著者の本橋智光さんの対談をお届けいたします。ひょんなことから実現した今回の対談、今話題の機械学習を中心に、さまざまな角度からのお話しが飛び出します。まずはお二人の著書の話題から… 書籍の評判と執筆の苦労 （名刺交換をするお二人…） 有賀： そうか、CTOですもんね。 本橋： CTOと言ってもエンジニアは僕入れて4人ですけどねｗ 有賀： よくあるスタートアップのCTOって最初のエンジニアで、みたいな感じで。だから4人いるんだったら、ハイアリングがもうできるようになったという。 本橋： でも、いまAndroidエンジニアがいないから僕Androidアプリ書いてますよｗ もう少しすると入社する予定ですけれど。 有賀： スタートアップのCTOはできることは何でもやるということで。いやあ。ご活躍されていて。 本橋
マイクロソフト、次期SQL Serverとなる「SQL Server 2017」発表。DBMS内でTensorFlowやCNTKなどのディープラーニングを実行可能に
SQL Server 2017ではグラフオブジェクト対応、過去の処理から学んで自己チューニングするAdaptive Query Processing、SQLクエリにPythonやRを組み込めるなどの新機能を備えています。Windows版とDocker対応を含むLinux版が同時にリリース予定です。リリース時期は未定。 グラフオブジェクトとクエリに対応したことで、ソーシャルネットワークの分析やIoTネットワークのモデリングなど、これまでのリレーショナルデータベースでは困難だった処理が容易になります。 ストアドプロシージャでディープラーニングを実行可能に 新機能のなかでも最大の特徴は、SQLクエリにPythonを組み込むことが可能になり、ストアドプロシージャのなかでTensorFlowやCNTKといったディープラーニングライブラリが実行可能になったことです。 マイクロソフトはSQL Serve
二千万レコードあるテーブルへのalterをサービスを止めずに流す | All Your Bugs Are Belong To Ass
※このエントリはMySQL Casual Advent Calendar 2015の5日目のエントリです。 openark-kit というものについて ここまで読んでわかった方は、この先を読む必要はありません。 openark-kitとは、mysqlの運用に便利なツールキットを14個あつめたソフトウェアパッケージです。 Shlomi Noachという方がPythonで開発しており、少なくとも2009年に発表されているようです。 2015-12-05時点での最新版は196.1となっており、.tar.gz および .deb で配布されております。 このエントリを書いた背景事情 そもそも僕自身、50を超えるクラスタ化されたmysqlノードと一緒に業務生活を送っております。 ところが、システムが非常に古くさい構成のため、合計レコード数が2億から3億程度ある垂直分割されたテーブルに対しALTERを投
O/Rマッパーによるトラブルを未然に防ぐ
2. copyright © 2014 kuwata-lab.com all rights reserved まえがき 現在、アプリケーション開発の現場では O/R Mapper (ORM) が普及しています。今後 も ORM を使った開発は、増えることはあっても減ることはないでしょう。 しかし ORM は、アプリケーション開発者にとっては便利でも、DB 管理者 (DBA) か らみたらトラブルの種でもあります。それが特にパフォーマンスに関する問題であるこ とが多いため、開発者と DBA が対立することも珍しくありません。 とはいえ、ORM による問題はすでに解決策が用意されている場合があります。本当の 問題は、すでに存在する解決策があまり知られていないことではないでしょうか。 そこで本発表では、ORM によってどのような問題が起こりやすいか、どう解決・予防 すればいいか、そして ORM
Mackerelで採用している技術一覧とその紹介 - Hatena Developer Blog
こんにちは。Songmuです。 この記事ははてなエンジニアアドベントカレンダーの3日目です。 昨日、Hatena Engineer Seminar #3を開催いたしました。何より参加率が高かったことに感激したのですが、その分少し窮屈な思いをさせてしまったかもしれないのは申し訳なかったです。多数のご参加本当にありがとうございました。 セミナーではMackerel overviewという話をさせてもらったのですが、そこでお話したMackerelで採用している技術について説明します。 Mackerelとは？ 今年の9月17日にリリースしたはてな謹製のサーバー管理・監視ツールです。 数多くのサーバーを運用しているはてなは、これまでサーバー管理ツールを内製してきたのですが、そのノウハウを活かし、サービス用に新たに一から作ったサービスになります。 また、はてなの既存サービスとは性質が異なるため、技術選
データのためのGit（およびGithub） | オープンデータとオープンガバメントを推進する Open Knowledge Japan
（訳注：この記事は本家OKFn.org記事の日本語訳です） データのために「バージョン管理」を行う能力は重要な関心事です。様々な選択肢がありますが、最も魅力的なもののひとつは、Git やMercurial のように、コード用の既存ツールを再利用することです。この投稿では、私たちが暫くの間使用してとても効果的だということが分かったツールを利用する、データの格納とバージョン管理のための単純な「データ・パターン」について記述しています。 序章 行われた変更を格納し、それを他の人と共有する、データのバージョンとリビジョンを管理する能力、とりわけ分散的な手法は（オープン）データ・コミュニティにとって大きな便益となるでしょう。私はその理由を以前（こちらの初期の記事を参照）議論しましたが要約すると： 効率的な分散型の共同作業が可能です。私のデータセットを取り出し、変更し、それを再び私と（同時に他の人とも
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
Google App Engine / Python 上での開発で最初から知ってればよかった、ってことをいくつか - Masatomo Nakano Blog
ここ数ヶ月、Google App Engine/Pythonを使い、初めてちょっとしたものを作ってみているのだけど、開発初期から知っておけばよかったなー、と思うノウハウ/tips的なものをずらずらと書いてみる。 基本的な環境設定は、 以前書いた まま。 0. 公式ドキュメントを良く読む 言うまでもなく、だけど、 マニュアル はもちろん、 この辺 の下の読み物も、流し読みだけでもしておいたほうがいい。 datastoreとmodel的なところ 1. key nameを使いこなす key nameは、レコードの作成時に指定できる(RDBでいう)primary keyの別名みたいなもの。primary key自体は自動的で作成されるので開発者が指定できるのはkey nameだけ。 key nameをうまく使うことで、datastoreを使いやすくすることができる。特にdatastore上で"un
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jupyter(Python)とBigQueryによるデータ分析基盤のDevOps #pyconjp // Speaker Deck