皆さんこんにちは。今日はFrog Advent Calendarの11日目という事で、私が普段職場で行っている作業とその開発環境についてお話ししたいと思います。

1.普段の作業

1.1.サービス概要

この場で具体的には申し上げられませんが、扱っているサービスは動画のストリーミング配信とそのダウンロードサービスになります。
扱っているサイトは多数あり、ショッピングカートを使った動画の単品課金や会員制の月額課金の両方を合わせたサイトもあります。

1.2. サイト用フロントエンド

これらサイトの主な機能は、ログインから作品のリスティングと詳細ページの表示です。
月額課金にせよ単品課金にせよ、作品のリスティングと実際にサービスを受けるページへの導線は必要不可欠です。
ログイン・ログアウトの管理によって非会員・会員の区別、また会員でもステータスに応じたサイトの表示切り替えが必要です。
実際のサービスである動画のストリーミング再生とダウンロードをサイト上からユーザが行える様にしなければなりません。

ストリーミングはHLSプロトコルを使用し、ライブ配信ではなくVOD(Video On Demand)方式になります。
ストリーミングはいかにスムーズに再生できるかが重要なので、複数画質の動画ファイルを用意しアダプティブストリーミングに対応しています。
ダウンロードファイルはストリーミングファイル程画質の制約を受けませんので、より高画質の動画を提供できます。

ログイン管理にはセッションではなくクッキーによるトークンを用いたユーザ認証方式を採用しています。
HLSストリーミングの実装にはJWPlayerとvideojsを使用しています。
ストリーミングサーバにはAdobeのAMSサーバを使用しています。

1.3. 管理者用バックエンド

上記サイトはすべて管理者ページ(CMS)が前提になります。管理者ページのから作品を登録し、指定した公開日に作品がサイト上に新着として表示されることになります。
サイト上に表示される動的データはすべてこの管理者ページからDBに登録されることになります。
管理者ページではデータの更新系処理(登録・更新・削除)を繰り返すので、データの整合性を保たなければなりません。
特に、定価・割引価格の設定から売上額の集計などはより正確な処理が必要になります。
また、管理者権限によってできる処理とできない処理を明確に分けなければなりません。
管理者は公開前に登録データや必要なリソース(画像・動画ファイル等)の最終確認をします。
ストリーミングの再生確認も行い、途中で途切れていないか、間違ったファイルがアップされてないかなどもチェックします。
最後に、最高権限の管理者によって承認登録が行われます。

フロントエンド側ではデータの読み出しが多く、更新系処理はユーザアクション(レビューコメント投稿、イイね、お気に入り、デフォルト設定)によって行われますが、
DBにアクセスする処理としてはシステム全体のごく一部にしか過ぎないので、バックエンドの管理者ページの方がより多くの手間がかかります。

管理者ページにはリソースの自動生成の機能があります。作品の動画ファイルがアップロードされてからの自動検知、そしてエンコード、正常終了完了チェック、そのステータスの更新。
画像についても一枚のファイルからの複数サイズへの出力も行います。これらはサーバ側でのスクリプトの定期実行(クロンジョブ)によって実現されています。
プログラミングの目的は人手で繰り返しできる処理を自動化する為にあります。

1.4. サイト用バックエンド

上述の管理者システムからのデータやリソースを前提としてフロントエンドのサイトが初めて成り立つわけですが、
フロントエンドサイトはまたそれ専用のバックエンドによっても支えられています。
サイト用バックエンドは、シングルサーバで運用できる小規模なサイトと複数のサーバを使用した大規模なサイトでは難易度が格段に異なります。
後者の場合、負荷分散を意識して処理の目的に応じた専用のサーバを用意することになります(ウェブサーバ、DBサーバ、画像サーバ、動画認証サーバ、ストリーミングサーバなど)。
また、動的なページ出力でのDBアクセスはレスポンスまでの処理が多くなるので、如何にキャッシュを用いてパフォーマンスを向上させるかを考える必要があります。
これにはサーバのwgetコマンドとリライト機能を使った物理的なキャッシュの生成をすることで実現できます。また、キャッシュをいかに容易に削除・再生成できるかも重要な点になります。
サーバによってドメインが分かれている場合、常にクロスドメインへのアクセス(CORS)を意識しないといけません。
これは特にHLSストリーミングを行う場合に必要不可欠な理解となってきます。

次に、サイト用バックエンドにとって重要なことは資産を流出させないということです。
不正なログインや権限以上のリソースへのアクセスを防止しなければなりません。ストリーミングであれダウンロードであれ、ユーザの動画ファイルにアクセスする動画認証が必須になります。
認証サーバへのAPIの呼び出しによってユーザの購入履歴やステータス(アクセスする権限)とアクセスする作品自体のステータス(公開されいるか、誰がアクセスできるものか)のチェックが行われます。

セキュリティーについて言及しておきます。使用者が割と限定される管理者ページと比べてフロントエンドサイトで最も気を付けなければならないことは不正アクセスです。
意図的か偶然かいたずらか興味本位かで、不正なデータがサーバ側に更新データとしてPOSTされてきます。これはサイトの見た目を大きく崩すものから、
最悪のケースでは顧客データを流出させ、DBの削除が行われることもあり得ます。
多くの場合、基本的なことをきちんとやることで防げます。つまり、入力チェックを不足なく正確に行うということです。
HTMLエスケープ、SQLエスケープを体系的に行います。PHPではPDOオブジェクトを使用したDBアクセスでリスクの軽減ができます。

2. 動作環境

2.1. LAMP

動作環境は基本的にはLAMP(CentOS/Aache/MySQL/PHP)です。
フレームワークは使わないようにしています。そしてフレームワークの使用には反対派です。
これは目的によって意見が分かれますが、数年以内に閉じる予定のウェブシステムであればフレームワークの導入も良いでしょう。
しかし、10年使うシステムを前提とした場合は、フレームワークが足かせになることがあります。
新しいフレームワークが出てきて、導入したフレームワークメンテナンスの終了され、使用者も減ることでネット上の情報も不足してきます。
また、システムの拡張に伴い、フレームワーク自体のハックを行わなければならなくなります。つまり、自由な拡張が疎外される事になります。

2.2. 私の行っている作業

上述の通り、サイトのフロントエンドとバックエンド、そして管理者サイトの開発・運用を行っています。
デザイナーがHTML/CSS/JS(jQueryでできる簡単な処理含む)で組んだものにDBデータを乗せて動的に表示できるようにする場合もあるし、
逆に動的に動くように作ったデモの状態のものにHTML/CSSのデザインを乗せてもらうことにあります。
HTML/CSSについてはデザイナーの方が専門でやっているのでより詳しいと思いますが、
プログラマでも当然基本的なことは理解していて、デザインの無い状態でレスポンシブな表示は実現できる状態ではいます。

バックエンドのコーディングでは多くのフレームワークが導入しているMVCモデルを用いたフォルダ構成を行い、メンテナンス性、可読性、拡張性を意識したコードを描くように心がけています。
コーディングは何を書くかよりも、どうファイルを分割・配置して管理していくかを深く考えています。
当然オブジェクト指向も理解した上でのプログラミングになり、多くのクラスファイルを作成しています。
一方で、シングルページのスクリプト系の処理も多く書いています。
例えば、自動動画エンコード、画像の自動リサイズ、キャッシュファイルの自動生成。逆に不要リソースの削除も行っています。
これらのスクリプトはPHPで記述し、それをシェルスクリプトで呼び出すようにしておき、定期実行ではそのシェルスクリプトを実行しています。
MySQLのDBについてはトランザクション処理も行っていて、クエリよりもむしろ、システムとしてどうデータを保持すべきかといったDB設計に主眼を置いています。

ウェブシステムを扱うにあたって、Apacheの基本的な設定は理解しておく必要があります。正規表現を使ったリライトも日常的に行っています。
各サーバへアクセスはSSHで行い、基本的なLinuxコマンドの操作も必要です。
またコマンドだけではなくLinuxのOSシステムの全体的な理解も必要で、特にファイルのPermissionについても正しく理解しておく必要があります。
バックエンドプログラマだからといってサーバの事は全く分からないという事ではなく、最低限の基礎的理解が必要です。

2.3. 私がやらない作業

複数人のチームとして仕事をするに当たって、越権行為をしないように注意しなければなりません。できることとやってよい事は別ということです。
私はプログラマなので当然デザインはできません。意見を言う事は勿論ありますが最終判断はデザイナーに委ねています。
サーバの管理につては専門のサーバエンジニアがいるので、特に各サーバの設定やメンテナンス、ネットワーク関連については彼らが行います。
許可なくサーバの設定に関する操作は当然禁止で、必要であれば作業依頼する事になります。
例えば、Apacheのバーチャルホストの追加や、ネットワーク上のサーバ同士のアクセス許可などになります。

その他にも、システムの機能によっては専門のチームが管理している場合もあります。
ログイン機能はユーザ認証サーバによってなされるので、私が行う作業はサイト上にログインURLを設定することと、ログイン後にはクッキーにあるユーザ認証トークンの存在をチェックすることになります。
また、決済についても、カートにアイテムを追加して、購入に至った場合はAPIを呼び出すところまでで、クレジットカード決済自体は別部署が管理しています。
ログインや決済はユーザの個人情報の漏洩につながる可能性があり、組織としては最優先で守られるべきデータなので、それ専門の部署で管理されています。

2.4.開発環境

上記の動画配信サービスをLAMP環境で提供するためにコードを書いているわですが、使用しているアプリは以下の通り。

Windows10

家でも職場でもWindowsを使っています。Macの良さは全く分かりません。デザイナではないのでフォントが美しく見える必要がなく、そもそもコマンドキーの配置が嫌いです。
LCDのノートPC使用で、デュアルモニターは使用していません。その必要性も感じていません。

Eclipse IDE

キャリアの始めはVB6とCOBOLでしたが、2年目の転職を機にJAVAに転向しました。それ以来Eclipse一本です。
特に不便はしていません。ファイル名検索、文字列検索も十分ですし、正規表現での検索もできます。特にF3キーでのファイル間の関数のジャンプ機能は便利です。

Firefox

デバッグにはFirefoxを使用しています。一般的にはすでにChrome使用の開発者の方が多いのかもしれませんが、昔からFF一本です、
これも特に不便していないので変えていません。とにかくキツネのロゴが気に入っています。
また、開発者ツール(Inspect Element)のNetworkタブはHTTPヘッダーを確認するのに重宝しています。

Filezilla

書いたコードは主にFilezillaを使用してアップロードしています。ローカルとサーバ上のディレクトリを固定して同時に移動できる機能があれば十分です。

Clibor

同僚に教えてもらいました。色々なIDやコードのコピペを繰り返し行うには便利です。
通常、Clipboardに記憶できるのは一つですが、このツールを使うとクリップボードの履歴を使用できるので便利です。

TeraTerm

サーバへのSSH接続に昔から使っています。Puttyを使っている人も多いと思いますが、TeraTermで特に不便は感じません。
特に、下矢印で接続したサーバの履歴リストからサーバを選択できるのは使い勝手が良いので使い続けています。

PhpMyAdmin

MySQLデータベースへのアクセスをブラウザから行うにはPhpMyAdminはとても便利です。

Excel

仕様変更でDBデータの更新を行う場合、複数の同じようなクエリを生成するのにとても便利です。
クエリ生成後はPhpMyAdminにコピペして実行することになります。

Slack

社内で使用しているチャットツールです。クリップボードに保存したスクショを直接ペーストできるのは便利だなと思います。

Notepad

立ち上がりが究極に早くて、ファイルを開いたり閉じたりを繰り返す私には便利です。
複数の作業を同時に行うことが多いので、メモしておかなければならないこと、すぐ後で伝達しなければいけない事を一時的にメモしておきます。
一日の作業を通じてタスク管理にも使用しています。

メール

これも業務用メールとは別に、日をまたぐ作業を管理するのに使用し提案す。細かいタスクメールを自分に送り、終わったものから消していってます。

BrowserStack

タブレットやモバイルのエミュレーターです。各機種の各ブラウザで動作確認ができるので便利です。