1つのテストタスクの履歴

しばらく前、ハブラーの空きスペースをめくって、私は空いている「Python Backend Developer」に出会った。 その中で、オフィスの場所が私を最も賄briしました-それは家の近くにあり、私は応答を書きました。 答えはすぐに、テストタスクを完了する準備ができているかどうかという質問になりました。 私は彼らが彼を私に送ってくれると思うと答えた。 割り当てられた手紙は2週間消えていました。



そのため、5月の休日の直前に、テストタスクで答えが返ってきました。 仕事は簡単に思えましたが、2週間後に何らかの理由で新しい仕事を見つけるラッシュが終わり、休日が来るので、一般的なコミュニケーションを断念することにしました。 しかし、同じ日に病気になりました。 それはすべての結果を伴う非常に深刻な鼻水です。 そして翌日、私はこのテストタスクを取り上げて、その結果を確認することにしました。 これが私の話です。



その割り当てのテキストは次のとおりです。

任意のWebフレームワーク（できれば最もよく知っているもの）を使用して小さなWebアプリケーションを作成する必要があります。 レイアウトは重要ではありません。バックエンド、コードの設計、ささいなことに集中してください。



実際、アプリケーションは1ページで構成する必要がありますが、必要に応じて複数のページに分割することもできます（個別のダウンロードフォーム）。

必要な要素-写真アップロードフォームと、アップロードされた写真のリストを含むテーブル。 承認はオプションです。



ダウンロードフォーム：

写真名を入力するためのテキストボックス

ファイル選択



表：

写真のプレビュー（写真（サムネイル）の小さなコピーを作成する必要があります。また、このプレビューは、プレビューをクリックすると開く元の/フルイメージへのリンクである必要があります）

写真の名前（ユーザーがアップロード時に指定する）

カメラのメーカーとモデル（EXIFがある場合）

ファイルサイズ

写真作成日（EXIFから）

写真のアップロード日

削除ボタン



要件：

既存の写真を保存しないでください。 重複ファイルを確認し、検出された場合はエラーを返します。

ダウンロードしたファイルがイメージかどうかを確認し、イメージでない場合はエラーを出します。 （EXIFデータ検証を検証として使用しないでください）

1年以上前に作成された写真の保存を許可しないでください（写真がEXIFから作成された日付を確認してください）。

EXIFで写真を作成する日付がない場合は、エラーを与えてファイルを追加しないでください。

そのため、TornadoはPythonのWebフレームワークとして選択されました。私は長い間、これに精通していました。 複数のバックエンドサーバーを上げるため、バランサーとスーパーバイザーが必要です。 当初、私はHAProxyをバランサーと考えていましたが、NGINXが写真をうまく配信できることを思いつきました。 その結果、当初、アーキテクチャは次のように思えました。NGINXは接続のバランスを取り、ディスクから静的に分散します。4台のTornadoサーバーがリクエストを処理し、Redisがバックエンドを同期します。



入ってくる画像を分析し、サムネイルを作成する負担はトルネードにかかった。 割り当てでは、どの形式をサポートする必要があるかが示されていないため、TIFFおよびJPEG形式に言及しているWikipediaでEXIFの説明を探しました。 それだけであれば、事態はそれほど悪くありません。Python用Pillowライブラリは、フォーマットとEXIFメタデータの両方をサポートしています。 ただし、微妙な違いがあります。TIFF画像はブラウザで開かれません。 これにより、ブラウザーで元のファイルを開くことができなくなるため、これらの画像をJPEGにトランスコードし、受信したEXIFファイルとともにデータを追加保存して、テーブルに表示するために必要なすべての情報を復元することにしました。



テーブル自体をRedisに保存します。 また、Redisはメモリに完全にロードされており、緊急停止が発生した場合、最新のデータベースの変更を復元する可能性は高くありませんが、非常に多くのイメージの説明に対応でき、長期間続くと思います。 また、緊急の場合、JPEGファイルのメタデータから欠落している情報を復元できます。



JPEGメタデータソリューションは美しく見えました。PillowはEXIFをJPEGに保存できますが、メタデータ自体は既にバイナリ形式になっているはずです。 つまり、Pillowは辞書の形でメタデータを生成しますが、辞書からメタデータまで何もできません。 Gexiv2ライブラリが見つかりました。これはメタデータでも機能しますが、そのインストールにはスキルが必要でした。



ソースからGexiv2を何度もビルドしようとすると、ライブラリが見つからないというエラーが発生しました。 そのようなライブラリを探して、Ubuntu用のこのライブラリのインストールパッケージに出会いました。 しかし、ここで問題が発生しました。 pyenvを介してシステムにPythonをインストールし、virtualenvからスクリプトを実行しようとしましたが、この場合、インストールされたGexiv2システムは利用できません。 このトピックではタンバリンとの特定のダンスがありますが、Gexiv2で1時間過ごした後、virtualenvを放棄してシステムPython 2.7.6を使用することにしました。



Gexiv2はファイル内のEXIFを正常に編集しますが、メモリ内のデータを使用するとタイトになります。 また、基本的にファイルに2回アクセスしたくありませんでした。1回目はJPEGの記録用、2回目は同じメタデータファイルへの書き込み用です。 何が私を待っているのか分かりませんでした。 そして、次のことが待っていました-Gexiv2のドキュメントには、EXV、CR2、CRWなどのサポートされている形式がリストされていました。 そのため、Pillowはダウンロード可能な画像を読み取るタスクに対処できなくなりました。 そこでImageMagickを見つけました。Pythonに対応するアダプターはWandです。



ワンドは有望に見えました-多くのフォーマットのサポート、EXIFの読み取り、比較的簡単なインストール。 しかし、JPEGをメタデータとともに保存するには、Pillowが必要です。 しばらく過ごした後、Pillowでメタデータを編集するのに役立つpiexifライブラリを見つけることができたのは幸運でしたが、1つの問題が少なくなりました。 数時間過ごした後、座ってプログラムできます。



アルゴリズムは単純で、ワンドはメモリから画像をロードし、EXIFデータを提供し、ワンドはRGBバッファーを提供し、そのmd5ハッシュを考慮して重複をチェックし、バッファーをJPEGに変換してメタデータとともに保存し、サムネイルを保存します。 もちろん、それに応じてRedisのデータを更新します。 確認する必要があります。 ただし、メタデータを使用してインターネット上で画像を検索することや、新しいものであっても問題です。 そして、EXIFデータを適切に編集するプログラムを探すのに多くの時間を費やしました。



これで、最初のJPEGサンプルの準備ができました。ダウンロードしてください。 次に、2番目のサンプル、サイズが7MBのCR2ファイルを示しますが、いくつかの驚きがありました。 最初の-ワンドはバッファからそれを読み取ることができませんでした。ソースファイルの拡張子の形式のフォーマットヒントが必要でした。 しかし、ここに問題があります。ライブラリは一時ファイルを見つけられないと書いています。 再度検索すると、ufrawユーティリティをインストールする必要があり、ファイルが読み取られました。 11秒で。 そして、元の画像よりもノイズのようなものがJPEGで落ちました。



最初は、Wandに罪を犯しました。画像をRGBバッファーに不正に変換しているように見えましたが、電卓を実行すると、バッファーが必要なサイズのちょうど2倍であることがわかりました。つまり、チャネルは8ビットではなく16ビットを占めています。 やれやれ、1行ですべてが機能します。 しかし、長いファイルのダウンロードをどうするか？ 4つのサーバーが存在する場合でも、同じ数の大きなCR2ファイルにより、サービスが利用できなくなります。



最初の日は、システムのインストール、さまざまなライブラリの検索とインストール、主題分野の調査にかなりの時間を費やしましたが、最終的には150行のコードしか書きませんでした。 そして最終的に、テストタスクは失敗しました-アプリケーションの結果は受け入れられませんでした。 病気の体が休息を求めた。



2日目に、リクエスト中に画像の処理を拒否し、NGINXに画像を割り当て、バックエンドにサーバーを1つだけ残し、画像を処理する3つのスクリプトを実行することにしました。



NGINXモジュールのUploadモジュールを構築することから始めましたが、もちろん役に立ちません。 しばらく手探りして、作者がそれを放棄したことに気付きました。このモジュールは最新バージョンでは動作しません。 さて、大丈夫-Tornadoサーバーに着信ファイルをディスクに保存させてください。 さらに、実際に新しい画像処理スクリプトにコピーアンドペーストします。 スーパーバイザーとNGINXを構成し、インストールスクリプトを完了します。 そしてそれは動作します。



マイナスの点：画像をダウンロードした後、ユーザーはダウンロードステータスのページを開きます。画像が表に表示されるまでに時間がかかります。純粋なRGBデータのハッシュを中止する必要があり、ファイル全体がハッシュされて重複をチェックします。 エラーが発生した場合、ダウンロード結果は1日間保存されます。



最終的に、比較的低い負荷で、このアプリケーションは安定して動作し、多くのコアを備えた強力なサーバーで、良いパフォーマンスについて話すことができると信じています。 残念ながら、このテストタスクのほとんどはライブラリの検索と管理で満たされ、プログラミングはほとんど行われていません。 雇用主がこの仕事で知りたかったことは、私にはあまり明確ではありません。 EXIFデータを取得するために独自のライブラリを作成する必要があるかもしれませんか？ そして、そのようなテストタスクを小さく呼び出すことはできません。8時間以上が経過しました。 サポートされている画像形式の詳細を導入するタスクを大幅に簡素化し、アプリケーションの使用目的の詳細を説明します。



ソースはgithubで表示できます。 そして、私は病気になり続けます。