taisablog

taisa's engineer blog

関連記事

PHPによるDBUnit超入門

例えば簡単なWebサービスでMVCのフレームワークを使っていてビジネスロジックを書く用にコントローラとモデルの間にサービス層を追加して開発している場合、コントローラやサービスはモックを駆使しながらテストを書いていくことができます。ただ、例えばフレームワークをバージョンアップしたい、PHPをバージョンアップしたいなどの場合に既存のモデル層に影響がないかをテストで確認したいなんてことがあります。そのような場合には、DBUnitを導入してみてもいいかもしれません。ということで本記事ではPHPによるDBUnitの使い方を書いてみます。 事前情報 今phpunit/dbunitをインストールしようとすると以下の文言が出力されます。詳しくはこちらのissueに書いてありますが、どうもSebastianさんはdbunitのメンテナンスをやめるようです。ただそれを受けてforkしたプロジェクトが出てきているようなので大丈夫かと思います。今回はSebastianさんの純正dbunitを使っています。 Package phpunit/dbunit is abandoned, you should avoid using it. No replacement was suggested また、DBUnitに関する詳しい情報はマニュアルにありますのでご確認ください。https://phpunit.de/manual/6.5/ja/database.html#database.implementing-getdataset 作成したサンプルプロジェクト 今回は、dbunitの確認だけをしたいので、dietcakeのmessage-boardというサンプルプロジェクトを利用しました。今回作成したDBUnit用のサンプルプロジェクトは GitHub からダウンロードして確認できます。 git clone git@github.com:taisa831/phpunit-dbunit-sample.git cd phpunit-dbunit-sample composer install # mysqlサーバを立て`app/config/sql/board.sql`を実行する(SQLは下記に記載しています) # テスト実行 ./vendor/bin/phpunit PHPUnit 7.5.8 by Sebastian Bergmann and contributors. ….. 5 / 5 (100%) Time: 207 ms, Memory: 4.00 MB OK (5 tests, 14 assertions) アプリ用のDDLです。開発用DBとは違うのでboard_dbunitというテーブル名にしています。 — — — Create database — CREATE DATABASE IF NOT EXISTS board_dbunit; GRANT SELECT, INSERT, UPDATE, DELETE ON board.* TO board_root@localhost IDENTIFIED BY ‘board_root’; FLUSH PRIVILEGES; — — Create tables — USE board_dbunit; CREATE TABLE IF NOT EXISTS thread ( id INT UNSIGNED …

Python Bottleのソースを読む テンプレート編

前回に続きPythonの軽量WebフレームワークBottleのソースを読む テンプレート編 Class Hierarchy ここの部分 Bottleのテンプレートについて Bottleのテンプレートは、Simple、Cheetah、Jinja2、Makoの4種類があり、BaseTemplateを継承しているPythonのテンプレートの種類(参考)http://www.cmscom.jp/blog/af0ga8 テンプレートの使い方 テンプレートの拡張子には以下が利用できる extensions = [‘tpl’, ‘html’, ‘thtml’, ‘stpl’] 例えばjinja2を使う場合は以下のように呼び出すことができる(jinja2をpip installする必要あり) @route(‘/’) def jinja2(): name = ‘text’ return jinja2_template(‘jinja2’, name=name) view {{ name }} テンプレート呼び出しの処理をみてみる 各テンプレートは以下のように設定されている。 functools.partialにfunc templateが渡されている mako_template = functools.partial(template, template_adapter=MakoTemplate) cheetah_template = functools.partial(template, template_adapter=CheetahTemplate) jinja2_template = functools.partial(template, template_adapter=Jinja2Template) jinja2_templateが呼ばれた時の処理 *argsにはjinja2が、**kwargsにはtemplate_adapter=Jinja2Templateが渡される def template(*args, **kwargs): 引数からjinja2テンプレート名を取得 tpl = args[0] if args else None Jinja2Templateを取得 adapter = kwargs.pop(‘template_adapter’, SimpleTemplate) テンプレートパスをlookup(パスは./views/か./) lookup = kwargs.pop(‘template_lookup’, TEMPLATE_PATH) Jinja2Templateをインスタンス化 TEMPLATES[tplid] = adapter(name=tpl, lookup=lookup, **settings) BaseTemplateのコンストラクタの最後のprepareでJinja2Templateのprepareが呼ばれる self.prepare(**self.settings) ここではじめてjinja2がimportされる from jinja2 import Environment, FunctionLoader テンプレートのrenderメソッドにてレンダリングしviewを返す return TEMPLATES[tplid].render(kwargs) BottleのテンプレートはBaseTemplateを継承しprepareとrenderを実装することで使える仕組みになっている def prepare(self, **options): “”” Run preparations (parsing, caching, …). It should be possible …

no image

2016年の振り返り

2017年になってもう3ヶ月が過ぎようとしているけど、今年初投稿なので今更ながら2016年の振り返りをする。 2016年前半 2016年前半はWeb業界に来て初めてWebサービスの受託開発をした。5年前にSIerからWeb業界に来て以来初めての受託開発だった。プロジェクト前半は若手エンジニア2人いたが、色々な都合により後半は自分1人になりそこからは1人最後までやることになった。 SIerにいた頃、小さめのプロジェクトであれば自分一人でやることはあったが、今回のような大きめのプロジェクトで0→1のサービス開発をマネージメントしながら開発するというのは初めてだった。ローンチ後は何事もなく稼働しているのでよくやったと思えたもののWebサービスの受託開発の難しさを思い知った。 Laravelについて 開発はPHP+Laravelを使った。初めて使ったフレームワークだったが、日本語ドキュメントがしっかりしているのでほぼそれだけで開発を進めることができた。 https://readouble.com/laravel/5.1/ja/installation.html 主なプラグインは以下を使った。 laravel-debugbar laravel-ide-helper Intellij Laravel-Plugin 2016年後半 サービス開発に戻り、戻ってからは主に以下のことをやった。 決済システム導入 CI環境の再整備 ステージング環境の整備と追加 PHPUnit+Phakeによるユニットテストの本格導入 サーバのオートスケール 決済システム導入 これは、受託開発が都合により伸びた為、設計までして他のメンバーに引き継ぐすることになってしまったが、その後、また引き継ぎ開発を進めていった。「決済」といったシステムを扱ったことで良い経験ができたように思う。 CI環境の再整備 サービスの拡大、人の入れ替わり、増加により以前自分で立てたJenkinsのCI環境が整備されずひどい状況になりつつあったので整備した。Jenkins2へのバージョンアップもこのタイミングで行った。 ステージング環境の整備と追加 人員に対してステージング環境があきらかに枯渇していたので再整備と追加をした。具体的にはシステムだけでなく運用者もリリース前テストで利用する為、ステージング環境利用待ちのようなものが発生している状況だった。また、いくつかのサービスがつながっていることもあり環境がブラックボックス化していたのを再構築しドキュメント化しつつ環境を増やした。テスト環境大事。 PHPUnit+Phakeによるユニットテストの本格導入 UnitTestも以前は書くよう推奨していたが形骸化している状況だった。また、新卒メンバーが入ってそもそもテストが書けないメンバーもいる状況だった。これに対して、ハンズオンを開催しある程度書けるところまで持っていき、それ以降はプロダクト開発時にフォローするという形で最終的にはメンバー全員が必ずUnitTestを書くというところまで持っていくことができた。また、テストが増える従って、修正時の確認コストが減り品質が上がってきている実感が得られた。 サーバのオートスケール アクセスが増え、ときに突発的に高負荷が来るという事象が増えてきて、その度にサーバをたて、デプロイスクリプトに新しいサーバを追加しデプロイするということをやっていた。それもいい加減面倒だし事前アナウンスがなければ対応ができないので、常にS3に最新ソースを配置しておき、あとは負荷検知により自動的にサーバを増やすという仕組みを導入した。 社外活動とアウトプット 2015年末に子供が生まれたことと2016年の前半の受託開発に忙殺されたことで全くできなかった。2017年は落ち着いて来たこともあり活動を増やす予定。 まとめ 2016年後半の取り組みに関しては、2017年から始めるスクラムの取り組みの為の下準備という意味合いもあり、テストや環境系の整備をメインに行った。これにより2017年からの取り組みをスムーズに始められたと思う。

Python Bottleのソースを読む リクエスト・レスポンス編

Pythonの軽量WebフレームワークBottleのソースを読む リクエスト・レスポンス編   Class Hierarchy ここの部分 リクエスト受付からレスポンスまで 前回、サーバの立ち上げ時にルーティングが読み込まれるところまでを確認したので今回はリクエスト受付からレスポンスを返すまでを見てみる。 まずリクエストが来るとwsgiref/handlers.pyのrunが呼ばれ、Bottleの__call__が呼び出される wsgiref/handlers.py self.setup_environ() # リクエストを処理しレスポンスを取得する self.result = application(self.environ, self.start_response) # レスポンスを返す self.finish_response() bottle.py def __call__(self, environ, start_response): “”” Each instance of :class:’Bottle’ is a WSGI application. “”” return self.wsgi(environ, start_response) リクエストを処理する際に、LocalRequestのbindを呼び出しBaseRequestのコンストラクタにてenvironとLocalRequestをセットする。これでBaseRequestのラッパーからパラメータを取得可能になる。レスポンスも同様にLocalResponseのbindを呼び出す。 try: out = None environ[‘bottle.app’] = self request.bind(environ) response.bind() try: self.trigger_hook(‘before_request’) except HTTPResponse: return _e() # ここでリクエストの主処理を実行する out = _inner_handle() return out; finally: if isinstance(out, HTTPResponse): out.apply(response) self.trigger_hook(‘after_request’) BaseRequestのコンストラクタ self.environ = {} if environ is None else environ self.environ[‘bottle.request’] = self リクエスト情報は以下のように取得可能になる def index(): request.forms.get(‘test’) return ‘TOP’ LocalRequestは以下の通りマルチスレッドに対応している #: A thread-safe instance of :class:`LocalRequest`. If accessed from within a #: request …

PyCon JP 2017にスタッフとして参加してきた

ようやく落ち着いてきたのでだいぶ今更ながらPyCon JP 2017の参加レポートを書く PyCon JP 2017 in Tokyo | Sep 7th – Sep 10th はじめに まずはじめに、自分にとってのPyCon JPを簡単に振り返って見る。最初は2014年に一般参加者として参加したのがはじまりだった。そして翌年はじめてスタッフとしてジョインした。ただこの年は開催数日前にこどもが産まれ、当日の参加はできなかった。そしてその翌年の2016年は絶望的な業務の忙しさによりスタッフになることさえもできずに終わってしまった。そして今年、例年のような忙しさがありつつも無理やり時間を作ってスタッフとして準備・当日参加を果たすことができた。 スタッフとして スタッフとしては今年、2015年と同様にプログラムチームというチームで活動をした。プログラムチームはプログラムといってもPythonを書くわけではなく、スピーカーを募集したり当日のスケジュールを組んだりとカンファレンスのコンテンツを決めていくような活動がメイン。その中で今年はキーノート担当として活動した。今年のキーノートは海外1名・国内1名だったが、それぞれのスピーカーとコミュニケーションができたのは非常に有意義だった。また、今年やりきれなかったこととしては、システムも少し触ろうとしていたけどキャパオーバーにつき並行で進めることは全くできなかった。 参加者として 今年はスタッフとして参加したので、セッションのチェアマンをしたりともろもろやることがあったので基本セッションを見ることはできず、未だ動画でもみることもできておらず、セッションはまだほとんど聞けてないけど「Keynote」「スポンサーブース」、昼休憩にやった「メディア会議」「ジョブフェア」、「Youth Coder」「1日目のParty」「2日目の関係者パーティ」とセッション以外のところだけでもめちゃめちゃ楽しむことができた。特に1日目のPartyは食事豪華で酒の種類も多く、いろんな人と話しすることができてめちゃめちゃ楽しめた。気づけば2014年以降一度も参加できていなかったPyCon JPだったけど、スタッフをはじめて苦節3年、ようやく最初から最後まで参加することができて本当によかった。 来年は 来年はどこまでコミットできるかわからないけどもちろんスタッフとして参加するし、場所はまだ決まっていないけどPyCon APACも必ず参加しようと思う。もはや気づけばこのカンファレンスが1年間のモチベーションの1つにもなっていたりしてコミュニティってすげーとひしひしと感じている次第。 2014年一般参加した時の写真 (この時一緒に参加した人も翌年からスタッフになっている) 当日の写真は以下にまとめて沢山あがっているので大変ありがたい https://www.flickr.com/photos/pyconjp/albums/ 主にPyConについての話をしたPyLadies TokyoでLTした時のスライド