ウェブエンジニアチーム紹介

2018年07月10日
区分
introduce
報告者:
nakamura

はじめまして。nakamura と申します。 5月に入社して以来、2ヶ月が経ちました。 ブログ初投稿です! どうぞよろしくお願いいたします。

アクトインディではウェブエンジニアとして採用されましたが、3年弱のブランク期間があり、現在、日々努力中です。 今はDockerなどを勉強しています。

前職は、まったくエンジニアとは関係ない業種だったのですが、前々職では、RailsでECサイトの構築・運用を行っていました。その頃の良い思い出が忘れられず、ウェブ開発にもう一度携わりたいと思い、再び開発にチャンレンジできることになりました。ありがたやー。

前々職では、ECサイトの構築・運用を行なっていましたがほぼ1人で開発を行なっていたので、チーム開発というものにはあまり慣れていません。

そこで、わずか2ヶ月あまりですが、僕がJoinしたウェブエンジニアチームがどのような体制で日々の業務を行なっているか紹介したいと思います。

チーム紹介

まず、アクトインディの制作チームは、現在、以下のようなグループに分かれて開発を行なっています。

  • ディレクターチーム(4名)
  • デザイナーチーム(4名)
  • アプリエンジニアチーム(3名)
  • 情報システムチーム(1名)
  • ウェブエンジニアチーム(8名)

基本的には、ディレクターチームが文字通り、サービスの改善点や仕様などを決め、Redmineにタスクを切り出します。 そして、僕のいるウェブチームは、そのチケットを元に、Githubでソースを管理し、コードレビューを行い、チケット駆動開発をベースにサービスの開発・改善を行うのが主な業務になります。

また、Slackを全社的にコミュニケーションツールとして使用していますが、ウェブチームでは、毎朝10分程度のミーティングを行い、チーム内での情報共有、チームとしての一体感を保てるよう工夫しています。 その他にも、週1でエンジニア全体ミーティング、隔週で1 on 1を行うなど、日々の業務を効率よく行なっていけるよう試行錯誤しています。

このあたりは、多くの自社サービスを運用している企業さんたちとあまり大差はないのかもしれません。 しかしながら、1人で開発を行なっていた僕にとっては、とても新鮮でした。 特にコードレビューに関しては、指摘を受けることでたくさんのことを学ぶことができます。 とてもありがたいです。

それと、弊社では、リモートでの作業も一部認められるているので、人によってはとても働きやすい環境なのではないでしょうか? あ、あと、オフィスには懸垂用のトレーニングマシンも完備されているので、筋肉系エンジニアの方にもぴったりかもしれません。

The IT Crowd

最後に、唐突ですが、前々職でイギリスにいたころによくみていたおすすめのドラマを紹介します。 「The IT Crowd

IT業界にいるひとは、「あるあるネタ」が出てくるのできっと楽しめると思います。 日本語版もあるみたいですが、ぜひ、英語版も楽しんでみてください。 めっちゃ笑えます。

アクトインディでは、一緒に働いてくれるウェブエンジニアを募集しております。 興味のある方はぜひお越しください!

Infrastructure as Code のススメ

2018年06月27日
区分
infra
報告者:
yamamoto

インフラエンジニアの yamamoto と申します。通称“ヤマカズ”です。
会社のブログにはでかでかと出してもらったのですが、こちらのブログは初参戦だったりしますw
どうぞよろしくお願いいたします。

アクトインディではインフラエンジニア(SRE)として、いこーよや各種プロダクト、社内システムなどのインフラ環境・開発パイプライン等を構築管理しています。

実はインフラ関連は20年以上前からやってて、これまでも社内サーバーやアプライアンスの設定などをしていました。
一時期、Web開発の方でフロントやバックエンドをやっていたのでインフラから離れていたのですが、再びインフラに戻りました。
やっぱり機械いじりが好きなんですね……

筋トレ必須!?職人芸エンジニア=インフラ

昔はサーバーは全て物理マシンでやってて、マシンを大量に積んでセットアップするとか、マシンをかついで移動するとか、ITなのに肉体労働という意味不明な業界でした。
その後アプライアンスが進歩したり、仮想化やクラウド、コンテナ化でどんどん効率化が進み、少なくともマシンを並べなくてよくなったので、なんとなくITっぽくなりましたね。

また今までは、サーバーを構築するのに手順書を書いて、それに基づいてゴリゴリセットアップしていましたし、職人が目利きと手作業で作る「インフラは一点物」という世界でした。

IaCのメリット・デメリット

しかし数年前、Infrastructure as Code (IaC) という概念が出てきました。文字通り、インフラ構築の手順をコードにしてしまおう、という流れです。

コードにしてしまえばそれがそのまま手順書になりますし、同じ構成のサーバーをいくつも立ち上げられます。
また、クラウドや仮想サーバー等と親和性が高く、APIを叩くことでサーバーを立ち上げ、そのままログインしてOS以上のセットアップも続けて行うことができます。

当初はシェルスクリプトなどで実現していましたが、べき等性(何度実行しても同じ結果になる性質)を考慮するとコードが肥大化してしまいがちなので、それを考慮したツールも数多く登場してきました。

IaCにするメリットは、明らかにデメリットを上回ります。
メリットとしては、

  • コード化することで手順書代わりになる
  • コード化することで同じサーバー構成で何度でも作れる
  • コード化することで作業が楽になる
  • コード化することで同じ作業が誰でもできる

逆にデメリットは

  • コードに書き起こさなければならない
  • コードをミスると致命的な不具合が出る
  • 設定を試しながら調整する場合やりにくい

とありますが、最初はサーバーをいじりながら試し、そこからコードに起こすという方法でカバーできます。

IaC のススメ

私も古い人間なもので「インフラは職人技」みたいな気分がなかなか抜けなかったのですが、一度体験してしまうとこれはもう、ゾクゾクするほどたまらなく面白い!
逆に昔からインフラやってる人ほど、脳汁大放出なぐらい興奮できます。

とっつきにくいところも多々あるかと思いますが、まだIaCを体験していないインフラエンジニアの方は、ダマされたと思って今すぐ体験してみてください。
手近なところでは「Vagrant」を使えばスクラップアンドビルドし放題ですし、OSレベルからいじりたい場合は「Ansible」はお手軽で導入も簡単です。
環境レベルだと「docker」を使えば、1台のサーバー上にいくつでも何度でもWordPress環境が作れてしまいます。

さいごに

アクトインディでは、Infrastructure as Code を鋭意推進しております。
興味のある方はぜひお越しください!

Charlesでレンダリングブロックを調査してみた

2018年06月22日
区分
tool
報告者:
ohata

こんにちは ohataです。

2018/3/1に入社して、早3ヶ月経ちました。

わずか3ヶ月ですが、オフィス移転、15周年記念など会社として インパクトの大きい行事に参加させてもらいました。
(オフィスめちゃ広くなった!)

さてオフィス移転と同時にホームページがリニューアルされたのですが 表示に時間がかかっていたので、ちょっと調べて見ました。

遅い原因

サイトが重い場合はリソースの容量が関係するパターンが多いですが、 開発ツールのTimelineを見た感じ容量による影響ではなく、どこかの処理で レンダリングブロックが発生しているようでした。

しかも本番でしか発生していない、WEBあるある状態です。

調査1

大抵はjs絡みが多いのですが、念のため切り分けを行ってみます。

  1. Safari - [開発ツール]-[javascriptを無効にする]
    • レンダリング遅いまま
  2. Safari - [開発ツール]-[スタイルを無効にする]
    • レンダリング速くなった

今回はCSSが原因のようでした

調査2

対象css全部をwebコンソールで調べていくのも、ちょっと辛かったので、 前にネイティブアプリ開発をやっていた際に利用していた [Charles]を使って調べて見ました。

Charlesとは

CharlesはDebugging Proxyツールです。
※ WindowsにはFreeで、Fiddlerという素敵なツールがありますね

Proxy設定

Charles をProxyとして動作させます

  1. Charlesを立ち上げる
  2. [help] - [local Ip address] を開く
  3. en0 に表示されているIP Addressを macのproxyに設定する
  4. [Proxy]-[Record setting]-[include]に調査したいURLを設定する

ここまでがProxy設定です

cssのレスポンスを書き換える

今回はレンダリングブロックしているCSSを特定するのが目的なので、cssの処理を一度全部無効化して、 1個ずつ有効化していく事にしました。

  1. レンダリング対象を特定するために処理を無効化するように、
    空のファイルを作成します
    touch empty.css
    
  2. [Tools]-[Map local]に対象のリソースと書き換え先のファイル[empty.css]を指定します ※ XMLでimportできるので今回はimportして見ました
<?xml version='1.0' encoding='UTF-8' ?>
<?charles serialisation-version='2.0' ?>
<mapLocal>
  <toolEnabled>true</toolEnabled>
  <mappings>
    <mapLocalMapping>
      <sourceLocation>
        <path>/wp-content/themes/agent_tcd033/style.css?ver=4.9.6</path>
      </sourceLocation>
      <dest>/Users/ohata.kenji/empty.css</dest>
      <enabled>false</enabled>
      <caseSensitive>true</caseSensitive>
    </mapLocalMapping>

map_local_settings
スクリーンショットのように

  • [location] に書き換えたいリソース
  • [local path]に書き換え後のリソース
    が反映されます

  1. この状態でサイトにアクセスすると cssのレスポンスを empty.cssの内容をブラウザに返してくれます
  2. チェックボックスで書き換えする/しないがすぐ適用できるので、1つづつ有効にして 重くなっているcssを特定していきます。
  3. 重くなっている cssを特定できたら、そのcssをダウンロードしてきて、書き換え先のファイルに適用します
    (スクリーンショットの[update.css])
  4. あとは[update.css]をコメントアウトしたり、書き換えたりすれば、原因と改修方法が本番で確認できます

    最終的には css内で呼び出しているリソースが重くレンダリングが ブロックされていたという事がわかりました。
    css内の呼び出しリソースが開発ツールのTimelineに表示されなかったので、 現状が把握できなかった場合は一つの手だと思います。
    特にデバッグする際に開発環境を作らなくてもいいのが楽です

思った事

今回いろいろな調査をしていく中で、デザイナーさんと一緒にガガッと勧められたのがよかったです。 会社が大きくないというのもあるかもしれませんが、職種の責任範囲ではなくプロダクト目線で一緒に 動けるのは改めてやりやすいと思いました。

textlint に乗り換えました

2017年12月27日
区分
tool
報告者:
morishita

このポストはactindi Advent Calendar 2017で 突発的に穴が開きそうになったとき用の記事として用意していたものです。 無事、使うことなくアドベントカレンダーは終了しましたが、そのままお蔵入りにするのも 何なので私の今年最後のポストにしようと思います。

文章のチェックどうしてますか?

まとまった文章を書く時に、表記のゆらぎやスペルミスをなくすためにチェックツールがほしい。

昔、Microsoft Wordを使っていたときには校正ツールのお世話になっていましたが、 マークダウンでしかほとんど文章を書くことがなくなったので、Wordは使わなくなりました。 でも、ニーズがなくなったわけではないので、そのために最近までRedPenを使っていました。

今後はRedpenをやめてtextlintを使うことにしました。

乗り換えの理由

乗り換えの理由は次のとおりです。

RedPenに比べてチェックが速い

RedPenはJavaで実装されているので、実行時にVMの起動に時間がかかります。 そのオーバヘッドが使っていて辛い。サーバとして起動しっぱなしにすると速いのだろうと思うのですが、それはそれで面倒。 nodeで動作するtextlintではそのようなオーバーヘッドは感じません。

Atomプラグインを導入するとAtomのlinterに表示される

RedPenにもAtomプラグインがあります(redpen - Atom package)。 このプラグインはコマンドパレットから実行するか、 ファイルの保存時にチェックしてくれるのですが、独自のインタフェースで表示されます。 一方、textlint ではAtom標準のlinterに結果が表示され、文中にも結果がわかりやすく表示されます。 どのルールに引っかかっているのかも表示されるので、ルールを緩和したい場合にも便利でした。 このプラグインの使い勝手の良さが一番の決め手でした。

設定がいろいろプラグインとして揃っている

この手のツールは設定項目がたくさんあって、どう設定するかが大変なのですが、 標準的な設定が textlint のプラグインとして多数公開されています。

それらをいくつか導入して私好みのを設定を作ることができました。

インストール

私は文章を書くときにはAtomエディタをよく使うので、Atomエディタのプラグインで使う前提での手順です。textlint 自体はnodeモジュールでCLIも用意されています。

事前準備

次のものをインストールします。詳細は割愛します。

textlint のインストール

今後設定していく場所になるので、適当なところにディレクトリを作って、textlint をインストールします。 私は $HOME/.textlint にインストールしました。 他の場所にインストールする場合、以降、読み替えて下さい。

$ mkdir $HOME/.textlint
$ cd $HOME/.textlint
$ npm init -y
$ npm instsll -S textlint
$ touch .textlintrc

.textlintrc は後に設定します。

Atomプラグインをインストール

プラグインのインストールは次のコマンドでも、Atomの設定画面でもどちらで良いです。

$ apm install linter-textlint

Atom の設定で textlint の設定を開き次を設定します。

  • textlint Rules Dir: $HOME/.textlint/node_modules
  • .textlintrc Path: $HOME/.textlint/.textlintrc

textlint の設定

続いて、textlintのルールの設定です。

プラグインのインストール

先程作った $HOME/.textlint に移動して、プラグインをインストールします。 私は次のプラグインを使っています。

コマンドにすると次の通りです。

$ cd $HOME/.textlint
$ npm install -S textlint-rule-preset-ja-spacing textlint-rule-preset-ja-technical-writing textlint-rule-date-weekday-mismatch textlint-rule-spellcheck-tech-word

.textlintrc の設定

preset系のプラグインはインストールするだけで有効になるようです。 それ以外は設定ファイルで有効にします。

私は次の設定で使っています。 preset系のプラグインで、デフォルト適用される幾つかのルールを false にして緩和しています。

{
  "rules": {
    "preset-ja-spacing": {
      "ja-space-between-half-and-full-width" : false
    },
    "preset-ja-technical-writing": {
      "ja-no-weak-phrase" : false,
      "no-exclamation-question-mark" : false
    },
    "date-weekday-mismatch" : true,
    "spellcheck-tech-word" : true
  }
}

チェック結果

atom-textlint 上のスクリーンショットのようにエラーがあればlinterにリストアップされます。 エラーの箇所にも印が付き、マウスオーバーするとどのチェックでエラーなのかが表示されます。

最後に

アクトインディでは、エンジニアを募集 しています。少しでもご興味があれば、いちど話だけでもしてみませんか。

HTTP/HTTPS判定をnginx側で判定するようにしました

2017年12月25日
区分
Rails
報告者:
endo

こんにちは、endoです。

いこーよのHTTP/HTTPS判定をアプリケーション側から、nginxで行うようにしました。

rails5へのアップデート作業の途中経過報告に書いていたことを実現しました。

理由としては、下記の通りです。

  • アプリケーション側で行うより、ALB/nginx側で行う方がコンピュータに優しい
  • rails5のupdate作業中にssl_requirementのメンテナンスをなくしたかった

対応としては、下記のことに注意しないといけません。

  • HTTPSリダイレクト
    • 一部HTTPでもアクセス可能
  • ALBのhealth check対応

HTTPSリダイレクト

いこーよはALBでHTTPS判定を行っているので、その前提でお話しします。

ALBは暗号化処理を終わらせた状態で後続のリクエストを流してくれます。

user    →    ALB    →    nginx    →    rails
      暗号化       暗号解除(平文)

ALBは暗号化処理を解除した証にヘッダーにX-Forwarded-Protoをhttpsという値をつけてくれています。

nginxは$http_x_forwarded_protohttpsかどうかを判定すれよくなります。

httpアクセスの場合は、ALBはヘッダーにX-Forwarded-Protoをつけてこないので、それを利用します。

ALBはヘッダーにX-Forwarded-Protoをつけてこないので、それを利用します。

location / {
  ...

  if ($http_x_forwarded_proto != https) {
    return 301 https://$host$request_uri;
  }

  ...
}

これでHTTPSのリダイレクトは可能になりました。

一部HTTPでもアクセス可能

こちらは特定のURLの場合の設定をnginx側に書きます。


location /foo {
  try_files $uri @app;
}

try_filesでそのまま通常の設定に送ります。

ALBのhealth check対応

health checkをHTTPS通信で行うと暗号を解除しないといけなくなるのでHTTP通信で行います。

ここで気をつけないといけないことです

  • health checkはHTTP
  • health check以外はHTTPS
location /bar {
  # ヘルスチェックはHTTP通信を許可する
  if ($http_user_agent ~ "ELB-HealthChecker") {
      proxy_pass http://app_server;
      break;
  }

  # HTTP通信の場合は、HTTPSにリダイレクトする
  if ($http_x_forwarded_proto != https) {
      return 301 https://$host$request_uri;
  }
  try_files $uri @app;
}

User AgentでALBかどうかを判定します。

リリース時の対応

nginxの設定を反映すれば完了です。

いこーよはマルチAZなので、アクセスを片方に寄せてnginxを起動することもできるのですが、若干めんどくさいですね。

nginxはプロセスで設定を「反映する前」と「反映後」を共存できるので,それを利用して反映します。

sudo /opt/nginx/sbin/nginx -t←設定ファイルを確認する

sudo kill -USR2 `cat /var/run/nginx.pid`←設定後のプロセスを立ち上げてくれて、反映前のプロセスと共存します。
sudo kill -WINCH `cat /var/run/nginx.pid.oldbin`←反映前のworkerプロセスを終了する
sudo kill -QUIT `cat /var/run/nginx.pid.oldbin`←反映前のプロセスを終了する

これでリリースは終了です。

唯一の懸念点は、health checkのUser Agentが変更されたら、health checkでサーバーが落ちていきます。

こんなことがあるのかは、わからないですが、現象さえわかっていれば対応は取れます。

以上です。

補足

ステージングでhealth check対応かどうかを調べていたときの方法です。


curl 'http://staging.net/foo' -H 'User-Agent: ELB-HealthChecker'

curlコマンドのUser Agentを入れて確かめていきました。

参考

無停止でnginxを手動upgradeする

 | 

技師部隊からの
お知らせ

【求人】エンジニア募集しています。

本頁の来客数
八十七万千百七十六名以上(計測停止中)

メンバー一覧

アクトインディ技師部隊員名簿

アクトインディ技師部元隊員

アクトインディへ

カテゴリー

アクトインディ

aaaa