読者です 読者をやめる 読者になる 読者になる

astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

nginx + ngx_mruby でSSL証明書の動的読み込みを実現して、作業がとても楽になった話

nginx

こんにちは。並河(@namikawa)です。

随分と寒くなってきたんで、そろそろ銀座界隈のオススメのラーメン屋の紹介でもしようと思・・・うわなにをするやめくぁwせdrftgyふじこlp;

・・・はい。今日は、ちょっと前にやった nginx + ngx_mrubySSL証明書の動的読み込みを実現して、作業がとっても楽になったワンって話をしようと思います。

前提の話

弊社では、転職ナビという400近く存在する多くのドメインを持つサイトがあり、そのSSL処理をフロントの nginx で行なっています。

過去、そのバーチャルホストの設定がドメインごとにベタ書きされていた経緯があり、その辺の共通化・書き直しを少しずつやっていて、正規表現や環境変数を駆使することで、随分と設定は共通化できたりするのですが、どうにもならなかったのがSSL証明書の設定である、

  • ssl_certificate
  • ssl_certificate_key

の2項目です。色々とドキュメントを読んだのですが、これらの設定値には変数が使えないんですよね。 さて、どうしたものか。と色々と調べていたら、

どうやら、この2つのいずれかのモジュールを組み込むことで、動的に設定値を生成できるらしいということを知りました。

個人的には、Ruby の方が近しい存在ではあるので、ちょっと ngx_mruby を使って、動きを試してみました。

ngx_mruby モジュールを組み込んだ nginx パッケージを作る

弊社では、サーバのOS・ディストリビューションに Ubuntu を使っているので、 それ用の nginx パッケージを作成します。パッケージの作成については、以下の手順で行いました。

(尚、8月初旬にやった作業なので、バージョン関連の記載が古いと思うので、お試しの際は現行のバージョンにあわせてくださいませ。)

# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

# cat /proc/version
Linux version 4.4.0-31-generic (buildd@lgw01-16) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016

ちなみに、動作を確認した環境は上記な感じのサーバとなります。

# apt-get update
# apt-get install git build-essential devscripts ruby rake bison libssl-dev libxslt-dev libgd-dev libgeoip-dev libperl-dev

まずは、パッケージDBをアップデートして、必要なパッケージをインストールします。

# wget -qO - http://nginx.org/keys/nginx_signing.key | apt-key add -
# echo 'deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx' >> /etc/apt/sources.list
# echo 'deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx' >> /etc/apt/sources.list

nginx 公式のリポジトリを追加。

# apt-get update

# cd /usr/local/src
# apt-get build-dep -y nginx="1.11.3"
# apt-get source nginx="1.11.3"

パッケージビルドを行うための準備と、source パッケージを持ってきます。

# git clone --branch v1.18.2 --depth 1 https://github.com/matsumoto-r/ngx_mruby.git

# cd /usr/local/src/ngx_mruby
# ./configure --with-ngx-src-root=/usr/local/src/nginx-1.11.3
# make build_mruby
# make generate_gems_config

ngx_mruby を git リポジトリから持ってきて、ビルドします。

# cd /usr/local/src/nginx-1.11.3
# vim debian/rules

nginx のディレクトリに移り、vim 等で rules ファイルを編集します。

--add-module=/usr/local/src/ngx_mruby \
--add-module=/usr/local/src/ngx_mruby/dependence/ngx_devel_kit \

ファイルを開いて、 COMMON_CONFIGURE_ARGS の部分に上記の2行を追記します。

# dpkg-buildpackage -r -uc -b

ここまでで準備は完了。で、パッケージビルドします。

# ll /usr/local/src/*.deb
-rw-r--r-- 1 root root  1222032 Aug  2 09:22 /usr/local/src/nginx_1.11.3-1~xenial_amd64.deb
-rw-r--r-- 1 root root 11912660 Aug  2 09:22 /usr/local/src/nginx-dbg_1.11.3-1~xenial_amd64.deb
-rw-r--r-- 1 root root    11620 Aug  2 09:22 /usr/local/src/nginx-module-geoip_1.11.3-1~xenial_amd64.deb
-rw-r--r-- 1 root root    14988 Aug  2 09:22 /usr/local/src/nginx-module-image-filter_1.11.3-1~xenial_amd64.deb
-rw-r--r-- 1 root root    91038 Aug  2 09:22 /usr/local/src/nginx-module-njs_1.11.3.0.1.0-1~xenial_amd64.deb
-rw-r--r-- 1 root root    24314 Aug  2 09:22 /usr/local/src/nginx-module-perl_1.11.3-1~xenial_amd64.deb
-rw-r--r-- 1 root root    13162 Aug  2 09:22 /usr/local/src/nginx-module-xslt_1.11.3-1~xenial_amd64.deb

はい、 nginx のパッケージ(.debファイル)が完成しました。

余談ですが、この ngx_mruby では openssl 1.0.2 以上が必要になるので、Ubuntu 16.04 以前では、別途 openssl 1.0.2 以上のインストールが必要になります。

パッケージインストール&設定

# deb -i /usr/local/src/nginx_1.11.3-1~xenial_amd64.deb

サクッとインストールしてしまった後は、 "/etc/nginx.conf" や "/etc/nginx/sites-*" あたりの設定ファイルの server ディレクティブに、

ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;

mruby_ssl_handshake_handler_code '
    ssl = Nginx::SSL.new
    ssl.certificate     = "/etc/nginx/ssl/#{ssl.servername}/#{ssl.servername}.crt"
    ssl.certificate_key = "/etc/nginx/ssl/#{ssl.servername}/#{ssl.servername}.key"
';

こんな感じで記載します。 SSL証明書を読み込む際に、mrubyがフックされるような仕組みなので、 ssl_certificatessl_certificate_key のファイルについては何でもOKです。 上記設定を記載後に、 nginx を起動(or 再起動)するだけで、動作確認できるかと思います。

もし何か問題があれば、 nginx のログを確認しましょう。よくあるというか私もひっかかったのは、SSL証明書のパーミッションの問題です。SSL証明書ファイルは、 nginx プロセスからでも読めるパーミッションにする必要があります。

実際に運用してみて

めちゃくちゃ作業が楽になりました。

実際にサイト(ドメイン)追加の際、他の設定は共通化しているので、SSL証明書を配置するだけです。CMS的な似たような(設定が同様な)ドメイン・サイトの運用をするユースケースでは、すごく有用だと思います。

今年の9月くらいから、3ヶ月ほど本番環境で運用していますが、特に大きな問題は出ておらず、安定して動いています。

作者の matsumotory さんの資料によると、「性能はngx_mrubyのhello worldベンチで10%減程度」とのことなので、ここが許容できる場合は、かなり良いモジュールですね。

今日はここまで。それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

デザイン採用担当はポートフォリオで何を見ているか、何が見えているか?

webデザイナー テキスト処理 デザイン 採用

f:id:astamuse:20161124110530j:plain

初めまして、こんにちは。白木と申します。デザイナーです。

前回、「広告費用を自動取得し100時間分の作業をなくす話 - astamuse Lab」を投稿した後、「白木さんはデザイナーですか?」という趣旨のツッコミを複数からいただきました。その節は大変ありがとうございました。

lab.astamuse.co.jp

私としてはデザイナーが問題解決手段の一つとしてコードを使えることは自然だと考えいます。しかしながら、のっけからその話題だったというのはミスリードでしたね。バランスを取り直すために今日はデザインの話をします。

お題は「デザイン採用担当はポートフォリオで何を見ているか、何が見えているか?」です。

本投稿の目的・狙い

いざポートフォリオを作るとなると悩む方も多数いらっしゃると思います。「どうやって作ればいいのだろう?」「何に気を付ければいいのだろう?」。そういった皆さんの参考になれば幸いです。

またポートフォリオというテーマを通して、デザインで留意すべきエッセンスを書ける範囲でまとめました。おそらくデザイン初心者~中級者の方にも参考になる点があると思います。まずは通読いただいてご自身の知識・経験と照らし合わせて技能の棚卸などにお役立ていただければと思います。

お断り事項

本稿は、誰かとの議論によって得られた結論ではないため、私見の色合いが強いです。これまで見てきた結構な量のポートフォリオと面接を踏まえた属人的価値観といっても差し支えないと思います。その点については予めご了承ください。また、思うところのすべてを書くことは選考管理上できません。従って公開して差し支えない範囲での話ということでご了承願います。

では本題に。

f:id:astamuse:20161124112813j:plain

デザインポートフォリオって?

そもそもポートフォリオとは何でしょうか?ひらたく言えば作品集です。その人が関わってきたプロジェクト、作ってきたものをプレゼンテーションするドキュメントです。ドキュメントという言葉の通り、その媒体としては紙(ないしはPDF)がいまだに主流ではありますが、最近ではWebポートフォリオも少数ながら見かけるようになりました。また、動画を用いたポートフォリオも十分に選択肢に入るような時代になりました。

採用担当者はポートフォリオをどう捉えているのだろうか

まず第一に担当者はポートフォリオをどう捉えているのかを考えてみたいと思います。 ポートフォリオに何を求めているのかと言い換えてもいいでしょう。

これについては概ね以下の側面があると思います。

情報として捉える

単なる「作品の紹介」という捉え方。

応募者がどういったプロジェクト経験があるか、そこでどんな役割を果たしたのか、どんな実務を行ったのかといった情報を伴ったドキュメントです。職務経歴書に近く、純然とした事実情報を伝える機能的な目的で、ポートフォリオの一番ミニマムな要件と言えます。

作品として捉える

次は「ポートフォリオ=作品」という捉え方。

これはポートフォリオの中の個別具体の作品と同じくらいに、ポートフォリオ自体が一つの作品であるという見かたです。 採用担当者にとっては数年前のプロジェクト情報もさることながら、今、目の前にあるポートフォリオの完成度という情報も判断材料になっています。すなわち、ポートフォリオのクオリティが今のその方の力量を表すという考え方ですね。

コミュニケーション機会として捉える

そして三つめはコミュニケーション機会という捉え方。

ちょっとわかりにくいのですが、採用担当者の考え方としては「この応募者はポートフォリオをコミュニケーション機会として捉えられているかな」ということです。

何にしてもそうですが、情報を届けるということは須らく工夫可能なコミュニケーションです。「ポートフォリオを見てもらう」というのも数少ない大事なコミュニケーション機会で、工夫可能なものです。相手が何を欲しているか、自分が何を伝えたいか、それはどのように伝えればスムーズかということを整理し、その上でどうすれば相手がもっと自分のことを知りたいと思ってもらえるかを工夫する。そういったコミュニケーション機会です。

少し余談ですが美術系・デザイン系学校では就活の時(つまり学生時代)にポートフォリオを作成します。自分の就職成功がかかっている重要な位置づけであるため尋常じゃないクオリティのポートフォリオとなることが多々あります。私も学生時代の友人や後輩のポートフォリオを見る機会がありましたが、本当によく考えられているものは「伝え方」「伝える情報」に無理や無駄がなく、それでいてそれを作った本人の魅力を十分に備えていました。「これを作った人はどういう人なんだろう」って思いたくなるような工夫がある。相当に考えたのだろうなぁ、と感動したのを覚えています。

ポートフォリオにはスタイルがある

一口にポートフォリオといっても人によってスタイルが様々です。先ほどご紹介した3側面によってスタイルを分類することもできますが、ここではもっと解りやすいスタイルの違いを2つだけ、その見え方も交えてご紹介します。ご自身のスタイルを再確認できるきっかけになればと。

スタイル事例1「ビジュアル控えめ + 説明多め」

このスタイルは一つの案件に対してやや小ぶりなキャプションが数枚載っており、説明はやや厚め(と言っても200文字もないですが)なことが多いです。一つのポートフォリオにたくさんの案件を掲載する傾向も強い。グラフィック・デザイン能力というよりも数(ないしはその多様さ)とロジカルさでカバーしているタイプ。

見る側からするとグラフィックに自信ないのかなと思われやすいので、もしそうでなければ一枚だけでもいいので「渾身の一作」を入れておくと非常にバランスよく仕上がると思います。あと説明文が多くなってしまったら、ありきたりな記述はばっさり捨てて、エッセンス絞って書くなどの工夫をすると良いです

スタイル事例2「ビジュアル多め + 説明少なめ」

グラフィック・クリエイティブを得意としている方が好まれるやり方です。案件の象徴的なグラフィックを1ページに一個だけさらりと載せて、ワンラインで案件名を書いておしまい。あと余白を配置してすっきりと仕上げるという構成。制作プロダクションにいらっしゃった方が使える見せ方かなと思います。グラフィック得意でない方はやらない方がいいです。

非常に力強く、グラフィックについては申し分ないものが多いです。あとは応募先の会社の業務にそのグラフィック能力をどう転化しうるかを補足的に書くといいと思います。例えばWeb系の会社に応募するのであればWeb案件ものを必ず入れておくなど。DTP系の技能はどこでも重宝するので一つは盛り込んでおいて損はないと思います。

と、ちょっと極端なものを二つ紹介しましたが、載せるもののバランスや見せ方で採用者が窺い知ることはたくさんあります。あなたのポートフォリオを見たときに採用担当者がどう感じるかぜひ想像してみてください。もし客観的な意見を聞きたいのであればあなたが応募したい業界で働いている友人・知人に実際に見てもらうのが良いかと思います。

どんな説明を載せればいいか

次に説明文について整理します。ビジュアル押しのポートフォリオでなければ、だいたい案件ごとに説明を記載することになります。 しかし、実際に書き始めると何を書けばいいのかわからないこともあると思いますので少し噛み砕いていきましょう。

案件内容はベーシックな事項+メリハリ説明文

これは皆さんちゃんとお書きになっているので詳述は割愛します。概ね以下のようなことは基本項目としてさらりと書き、プラスで、どこに付加価値を盛り込もうとしたのかを書くのが良いかと思います。なお書くときは「端的にわかりやすく」を心がけてください。

  1. 案件背景
  2. ターゲットユーザー
  3. クライアントの要求(要件)
  4. 実施・リリース結果

ポートフォリオリオの中でもフィーチャーしたい案件の場合は200文字~くらい書き、それ以外の案件については200文字以下が目安です。繰り返しですが「端的にわかりやすく」。そのうえで魅力を感じさせるように書くと良いと思います。

プロジェクトの日付は絶対に忘れない

意外に無いことが多いのがこの情報です。そして無いと困るのもこれです。年代というのはデザインを評価するうえで一つの基準になります。当時のデザイン的流行、技術的に一般的に可能であった表現の幅、また、その方の年齢がいくつで経験はあったのか。採用担当者はそこも加味しています。これらの算定根拠が日付ですので、きっちり西暦から記載いただけるといいと思います。

担当領域や役割ははっきりと伝わるように

これも皆さんお書きになっていますね。一つ留意されたいのは「UI/UX」など社会通念がまだ確立されておらず、定義・解釈を恣意的にできてしまう場合は、タスク単位で領域を説明することです。面接の段になって「UI/UXって書いてあるけど何してたの?」と聞いた時に回答にばらつきがあり「それはボタンのデザインでは?」ということもあるので。大きく見せることが目的でポートフォリオを作るのでなく、情報としての齟齬をなくしよりミスマッチしないように作るとよいです。

なおNG例はこんな文章。

UI/UXデザイナーとしてユーザーの使いやすさを意識してワイヤーを設計しました。

これを読むと「あたりまえだろ!」となること請け合いです。「せっかくの文字数もったいない・・」と。もっと具体的な話を盛り込むとよいと思います。

全案件を掲載するのはやめよう

ポートフォリオにどれくらいの案件を載せればいいのか。この点についても言及しておきます。 おそらく採用担当者さんは以下の2点からポートフォリオには「全部は載せなくてよい」と考えている方が多いと思います。

  1. 作るのに時間かかりすぎる
  2. 採用担当者もそんなに見れない

全部を載せるために時間かけるなら、もっと伝えるところのクオリティを上げるほうがいいです

正直なところでは、全部載せたポートフォリオ見たら

  1. プレゼンテーションがうまくない
  2. コミュニケーションがうまくない
  3. 自分の能力がわかっていない(強みを理解していない)

と判断すると思います。過去の案件が少なく結果的に全部載せることになったなら話は別ですが。

バランスとしては一番の自信作案件を一点と、能力の深度を示す案件を2,3件、間口の広さを示す案件を2,3件かな、と思います(もちろんそれもご自身でよく考えて欲しいですが)。あとはプライベートで取り組んでいる学習成果を「参考」までに載せておく、と(意外に効果的かも)。

絶対に見えてしまっているところ

ここまでで「ああ、そういう風に見てるのね」というのがお解りいただけたかと思います(全てを話してないのであくまで部分的かと思いますが)。

以降は翻りまして「見えてしまっているところ」についてお話します。たいした驚きはないと思いますが「あ、やっぱり見えてる(見てる)のね」と再確認していただければ。

文字周りは当たり前に見えてしまっている

まずポートフォリオ見ているときにどうしても気になるのが文字です。弊社の場合は文字情報を扱うことが多い仕事ですから、そこへの配慮が欠けているとどうしても気になってしまいます。適切な文字の処理をしないと、読み手に不必要なノイズを与えます。

蛇足かもしれませんが、この点においてはやはり出版系ご出身の方や、制作プロダクションで紙モノをやられていた方が強いように見受けられます。しっかり組まれている。読みやすいのレベルを超えて、美しいと思わせる方も過去いらっしゃいました(願わくばそうなりたいものですね)。

ちなみにどんな点があるのか。以下、いくつかのケースを挙げました。 チェックリスト代わりに使ってみてください。

禁則処理ができているか

句読点などの約物(やくもの)や特定の文字が行頭・行末に出てこないようにすることを禁則処理といいます。これができてなかったら相当がっかりしちゃいます。デザイナーならそこは配慮しようよ、くらいの心持ちです。おそらくイラレがデフォルトで禁則かかっている?から大丈夫だとは思いますが、最終提出の前にもう一度確認してみてください。

f:id:astamuse:20161124125635g:plain

追い出し・追い込みはできているか

禁則処理とセットで意識する項目です。行頭に中途半端な文字がこないように調整することです。ここまで丁寧にできてる人は少ないので、そんなに気にしなくてもよかもしれません。それでも追い出し・追い込みをやってるのを見つけたときは「あ、いいな」って思います。

f:id:astamuse:20161124142345g:plain

文字揃えしているか

複数行にわたる説明文に対しては両端揃えているか。単純に一行の情報が複数箇条書きのようにならぶのであれば必要ないとも思います(ケースバイケースですが)。あと文字揃えという観点でいうと、インデントもチラ見します。例えばこういうケースです。

f:id:astamuse:20161124150402g:plain

ご覧のとおりコロン揃えるようにタブインデントすると綺麗ですね。

行送りに気を付けているか

複数行にまたがる説明文を用いる場合は行送りも自然に気になります。 行送りとは各行のベースライン間の高さを指すもので、「行間調整」といえばわかりやすいでしょうか。 例えば本文なら二分四分アキ(ニブシブアキ) =1.75%が美しいとされています。一方でタイトルテキストは二分四分では少し広いです。ベタ(1.00%)~四部アキ(1.25%)あたりで調整するのがよいかと。

ポートフォリオであればテキスト要素少ないでしょうから主にこの辺りを気にすることになるはずです。

  • タイトル
  • 説明文本文
  • 画像キャプション

この辺りはDTPの基礎的な書籍に概ね書いてあるのでポートフォリオを作るときはぜひご一読ください。また普段読んでいる雑誌にも参考になる要素がたくさんあると思うのでぜひ研究してみてください。

トラッキング、カーニング、字詰め

綺麗にできてたらいいなぁと思います。特に括弧類と句読点はやってあるといいです。イラレはデフォルトのままで出すとがったがたでして、どうしても調整が必要なところです。

f:id:astamuse:20161124152527g:plain

英文と和文のフォントサイズ調整

和文フォントのなかで英文フォントをそのまま使う(「混色」する)と、どうしても英文字が小さく見えます。本文であれば気づきにくいですが、タイトルなどでこれをやるとかなり目につきます。混色を行う場合は英文字のサイズを少し上げて、ベースラインを下げるなどの調整を行います。毎回やるのが面倒という方は合成フォントを利用するのも手です(こちらもちょっと問題あるのですが・・)。

f:id:astamuse:20161124153648g:plain

色周りも見えています

色はそこまで詳しくないので観点が甘いかもしれませんが、下記のようなところは気になっちゃいます。

  1. 文字の色ってどう指定してる?(K=100なのか、K=80なのか、はたまたリッチブラックなのか)
  2. ハレーション起こしてない?
  3. 補色使えてる?
  4. 画面上の色比率どんな感じ?

色にもセオリーがあって、今ではWeb上でも情報は収集できます。ハレーションのようにマナー違反などはちょっと調べればすぐ出てきますので、そういう地雷を踏まないように気を付けましょう。

最後に

以上、お話できる範囲でのトピックを私なりにまとめてみました。 冒頭申し上げた通り、これからポートフォリオを作ろうとされている方の参考になれば幸いです。またこれを読んだ方のデザインの勉強のきっかけになればいいなと。

それにしても、ポートフォリオは作ろうと思って実際にできるまでそれなりに時間がかかります。いざ作ろうと思っても素材から採取せねばならないので手間なんですね。 そこでこれをご覧になられた方は、定期的に自分が関わってきたサービスなりプロダクトの写真やキャプション画像を保管しておくことを強くおすすめします。ポートフォリオ作ろうとおもったらそのサービスなくなってて(リニューアルされてて)キャプションとれないことが非常に多いですし、ポートフォリオ作る作らないにかかわらず過去の記録を残すと自分の成長を実感して前に進む原動力になるので。

そして、そのポートフォリオを持ってぜひ私たちの会社の選考を受けに来てください。 こんな偉そうに書いてますがまだまだ全然道半ばなので、一緒に成長してデザインのクオリティを上げてくれる仲間を心よりお待ちしております!

最近リニューアルした採用サイト↓ recruit.astamuse.co.jp

【資料公開】Cloudera World Tokyo 2016 で登壇しました。

こんにちは。アスタミューゼ開発・インフラ部の福田です。

11月8日に開催された Cloudera World Tokyo 2016 にて登壇させていただきました。

こちらが、当日の資料になります。

セッションについて

『HBaseで実現する大量の特許文書データを扱うためのアーキテクチャとベストプラクティス』

というタイトルで、

アスタミューゼでの取り組みのほんの一部ではありますが、astamuse.comで公開している 大量の特許文書データとその周辺を、Hadoop、HBaseの使用事例としてお話させていただきました。

今回、このような貴重な機会を下さったCloudera社の皆様、セッションを聴きに来て下さった皆様に心から感謝しております。

ありがとうございました。

Special Thanks To

  • イラストを使用させていただいたいらすとやさん
  • 最後にスライドのお化粧をしてくださったアスタミューゼデザイン部のMatsumotoさん
  • 渋皮栗のモンブランが売り切れでも嫌な顔一つせず相談にのってくださった並河さん
  • 発表の準備を厳しい目で支えてくださったアスタミューゼ開発メンバーの皆さん
  • MacBookを開いて長時間ひとりでぶつぶつ言う私をそっとしておいてくれたカフェの店員さん

ありがとうございました。

Copyright © astamuse company, ltd. all rights reserved.