はてなブックマーク

Webエンジニアの森脇です。LCLでは、以前より「Capybara + PhantomJS」でE2Eテストを行っていましたが、「Puppeteer + Headless Chrome」へ変更しました。 元々は、軽くPuppeteerを触ってみるだけのつもりでしたが、できが良く本格的にE2Eテストへ導入することにしました。 本記事では、変更の経緯や、PuppeteerでE2Eテストを実装する上でのTIPSを紹介します。なお、Capybara + PhantomJSを利用したE2Eテストは、以下の記事でご紹介しております。 techblog.lclco.com 変更の経緯 PhantomJSは古めのWebkitをベースにしているため、一部のCSSがうまく適用されず、Headless Chromeへ移行を以前より考えていました。そんな中、PhantomJSの開発が終了したこともあり、移行すること

モバイルアプリエンジニアの山下（@yamshta）です。 先日、エンジニアチームでの勉強会にてターミナルを題材としたハンズオンを行いました。 techblog.lclco.com 今回はその際に共有した業務効率を上げるためのターミナル環境構築について紹介します。 以下に心当たりのある方は一緒に構築していきましょう。 ターミナルがモノクロ ターミナルをいい感じにしたいけどよくわからない ターミナルにこだわりが無い iTerm2 まずはじめにプリインストールされているターミナルとはお別れをします。 ターミナルアプリには、便利な機能が含まれている『iTerm2』を使うのがオススメです。こだわりが無い人こそ、とりあえずこれを使っておきましょう。 iTerm2 - macOS Terminal Replacement 上記のページからダウンロードして、解凍したものをApplicationフォルダに移

Webエンジニアの森脇です。 Railsアプリケーションで採用しているDB設計（スキーマ定義）について紹介します。 ※ Railsでは当たり前もの、Railsに依存していない内容も含んでいます。 前提 環境違えば、採用するルールも異なると思いますので、まずは弊社で利用している環境を記載します。 DBはPostgreSQL 9.x 開発言語は、Rails 4.x,5.xを利用 命名ルール Railsの規約に沿う命名を採用しています。DB設計にこだわりがあるメンバーにとっては、異論があるルールもあるのですが、アプリケーション開発の生産性も考慮しRailsの規約に寄り添うのがよいと判断をしました。 テーブル 動詞は使用せず、名詞とする 複数形とする 1:n のテーブル名は「単数形_複数形」 とする n:n のテーブル名は「複数形_複数形」とする カラム カラム名にテーブル名のprefixは付与し

1日のスケジュールを可視化してタスク消化率の最適化を図る モバイルアプリエンジニアの山下です。 今年からGoogleカレンダーにその日のタスクを予定として登録しています。 これにより、以下のメリットがあります。 日毎に消化したタスクを後から見返せる イベント・MTGや勤怠管理と一緒に予定を管理できる 他の人にスケジュールを共有できる 加えて、LCLでは始業の際に朝会で行うようなスケジュールの共有をチャット上で行っており、スケジュール内容をフォーマットに沿って投稿するようにGASを使って自動化しています。 techblog.lclco.com これらのメリットから始めた当初は満足していたのですが、運用から5ヶ月を経ちいくつかの問題が出てきました。 タスク消化時間を集計しづらい 同じタスクを分割して登録する必要がある 予定と作業時間の差分がみえなくなる 作業ノイズがわからない より詳しく落とし

モバイルアプリエンジニアの山下です。 LCLでは業務や情報収集の中で定期的な作業を行う際にGoogle Apps Script（以下、GAS）を利用した自動化をしています。 GASとは、クラウド上でスクリプトを実行できるサービスです。スプレッドシートをはじめ、Googleが提供している色々なサービスと連携することができます。 又、外部のサービスでも提供されているAPIを利用して操作することができるため幅広い用途で使えます。 そして、今回は以下の3つの活用方法を紹介したいと思います。 Gmailの本文から値を取得してスプレッドシートに書き込む Google CalendarのスケジュールをChatWorkに投稿する 毎朝、前日分のRSSをChatWorkに投稿する Gmailの本文から値を取得してスプレッドシートに書き込む この操作は、Fabricのデイリーサマリーを集計するスクリプトで扱っ

LCLが運営しているWebサービスは、品質向上のために、複数のサービスやツールを利用しています。今回はそれらのサービス・ツールをまとめてご紹介します。 品質向上のためのプロセス それぞれのサービス・ツールは以下のタイミングで利用しています。 各サービス・ツールの紹介 各サービス・ツールについて、一つずつご紹介します。 なお、今回はコードレビューや手動テストについては取り上げません。 SideCI SideCIとは、コードレビューを自動化してくれるサービスです。GitHubのプルリクエストを自動で解析して指摘してくれます。 Ruby, PHP, JavaScript, CSS, Java, Python, Go, Swiftなどに対応しているようです（2018/02/15現在）。 詳細は以下の記事でご紹介しています。 techblog.lclco.com SideCIは、プルリクエストが作ら

Webエンジニアの古賀です。LCLでは、障害対応の強化の一つとして多機能な通知機能を持つPagerDutyを導入しました。 組織的な対応シフト・フローが組めるようになり、精神的にとても安心できるようになったので紹介させていただきます。 pagerduty.digitalstacks.net 導入前の課題 LCLでは、Mackerelを利用して各サーバの監視しており、障害が発生するとチャットでエンジニアへTO(メンション）で通知をしていました。 この運用方法では、以下のような問題がありました。 全エンジニアへの通知のため、早めに気づくエンジニアが固定の担当になりがち TO（メンション）の重要度が高く、通常のやりとりで使いづらい 通知は一度しかこないため、他のチャットで埋もれてしまい見逃す可能性がある チャットでの障害通知では限界が見えてきて、何かいいサービスはないか検討していたところPage

モバイルアプリエンジニアの山下（@yamshta）です。 今回は、AWSの以下のサービスを用いてコンテナデプロイ基盤の構築を試してみました。 CodePipeline CodeBuild ECR ECS Fargate AWSのドキュメントは丁寧で情報も豊富ですが、サービス毎に手順が書かれているため一連の流れをまとめました。CLIでの操作のみで手順を進めています。 なぜアプリエンジニアがデプロイ基盤を構築するのか 疑問に思った方もいらっしゃると思うので手短に書かせていただきます。 LCLのエンジニアチームはスペシャリスト集団というよりはゼネラリスト集団に近く、特定の技術に縛られない文化とそれを推奨する環境になっています。そのため、メインに扱う技術力も伸ばしながらも別の技術を習得することができます。 今回の経緯ですが、私個人としてはインフラには興味がありませんでした。しかし、Dockerは環

Webエンジニアの横塚です。 皆さんは情報共有ツールは利用しているでしょうか。 LCLエンジニアチームでは先日、以前から利用していたQiita:Teamからesa.ioに移行することにしました。 移行の背景と、実際に移行してみてどうだったかを簡単に紹介したいと思います。 teams.qiita.com docs.esa.io 移行しようと思った理由 Qiita:Teamは本来やりたかったwiki的な使い方にあまり合ってなかった LCLでは、システム仕様や、共有しておきたい知見、定例MTGの議事録などをQiita:Teamの記事に溜めてきました。記事には必ずタグ付けをしておき、関連記事はタグで検索できるようにしていました。しかし、記事が増えていくにつれ、その運用も限界を迎えていました。 記事が増えすぎた結果、タグが形骸化し、キーワード検索をするしかない状況になりました。 慣れている人はいいで

Webエンジニアの川辺です。 今回はNode.jsでGoogle スプレッドシートを操作する際に使用したnode-google-spreadsheetの紹介をしたいと思います。 使用したバージョン Node.js: 8.11.3 node-google-spreadsheet: 2.0.6 準備 コード上からGoogleスプレッドシートを操作するため、シートへアクセスを許可するための準備が必要です。それでは順を追って進めていきます。 1. プロジェクトを作成 アクセスを許可するための認証情報を作成するためにまずプロジェクトを作ります。 Google Developers Console にアクセスし「プロジェクトを作成」をクリックしブロジェクトを作成します。 プロジェクトを作成するとこの画面が表示されます。 もし、プロジェクトが複数ある場合は今回作成したプロジェクトに切り替えてください。

フロントエンドエンジニアの岡田です。 やる気がでない時の最良の方法は、「とりあえず始めてみる」ことだと聞いたことがあります。 今回は、やる気がでないときでもコマンドを1つ叩くだけで、ブランチ作成〜WIPプルリクエストまで作ってくれるように設定をしましたのでご紹介します。 WIPプルリクエストを作るまでにすること WIPプルリクエストを作るまでには、以下のことをしています。 masterをチェックアウト＆プル ブランチを作成 空のコミットを作成してプッシュ プルリクエストの作成 ラベルを付ける 手順が多い上に、私が普段使っているSourceTreeでは、3. の空のコミットが作れません。そのため、ターミナルで操作しなければならず、面倒でした。 そんな時に同じチームの人が教えてくれた以下の記事を試してみました。 qiita.com すごく便利です…！ これはぜひ使いたいと思い、さらに以下の機能

Webエンジニアの森脇です。 LCLでは、普段使わないテストサーバなど常時稼働が不要なEC2インスタンスは、必要に応じて手動で起動・停止する運用にしています。が、停止を忘れて起動したままになっているということが、時々発生してしまっています。 大した金額ではないですが無駄は無駄なので、AWS CLIの勉強会を兼ねて、停止忘れを防止する仕組みを作りました。 仕組みの概要 AWS CLIを利用して、常時稼働が不要なインスタンスのステータスを定期的に取得し、"起動中"であればチャットへ通知します。 手順 インスタンスへのタグの付与 常時稼働が不要なインスタンスを識別するために、対象インスタンスには「env = spot」というタグを付与しました。 稼働中のインスタンスを取得 AWS CLIで対象インスタンスで稼働中のインスタンスのみを抽出します。 aws ec2 describe-instance

モバイルアプリエンジニアの山下（@yamshta）です。 LCLでは今月から全社員を対象にしたフレックスタイム制のトライアル期間が始まりました。 エンジニアは以前からもフレックスに近い働き方が可能でしたが、いくつかの新しいルールが追加されました。 これまでの取り組みはこちらの記事でご紹介しています。 techblog.lclco.com この変更から勤務時間を柔軟に偏らせたり、早い時間からオフィスで勤務できるようになったため、私も仕事を早く切り上げた日は、個人アプリ開発や書籍購入制度で買ってもらった本の読書に充てられるようになりました。 techblog.lclco.com 前置きが長くなってしまいましたが、今回は上の記事でさらっと触れられている輪読会の取り組みについてもう少し詳しく紹介させていただこうと思います。 輪読会を実施する目的 LCLのエンジニアチームで共有している、輪読会の目的

モバイルアプリエンジニアの山下です。 LCLでは今年からエンジニアブログ編集部を立ち上げました。 現在はフロントエンド、バックエンド、モバイルアプリエンジニアの3人で活動しています。 今回は立ち上げから3ヶ月が経過したので、立ち上げた経緯とその効果を紹介したいと思います。 エンジニアブログを運営する目的 ブランディング向上 エンジニア界隈への貢献 ブログ駆動開発 去年までの課題 エンジニアブログ編集部の目的 会社の名前で記事を書くため、最低限の質の担保 継続的に記事を公開するために、強制力を持たせる 個人ではなく、組織的に記事の質を向上する エンジニアブログ編集部の活動内容 先週の記事の振り返り 参考ネタの共有 ネタ出し ネタ整理・次回ネタの設定 その他 効果 継続率 はてブ数 おわりに エンジニアブログを運営する目的 LCLでは以下の目的でエンジニアブログを運営しています。 ブランディン

Webエンジニアの森脇です。 LCLでは、AWS ALBのアクセスログを分析し、各種KPIを定期的に確認しています。今回は、Embulk + BigQuery + Redashを利用してのログ分析の事例について紹介したいと思います。 概要 AWS ALBのアクセスログは、S3へ記録されます。S3へ記録されたログを、fluentd / Embulk を利用して Elasticsearch / BigQuery へ格納しています。 Elasticsearchは、短期的なログの解析を目的としており、Kibanaを使用して予期せぬアクセスが発生した場合の調査等に利用しています。ログは一定期間を過ぎると破棄しています。 BigQueryは、長期的なログの保存・解析を目的としており、ログは永続的に保存しています。 準備 以下の流れでやっていきます。 ALBのアクセスログを有効化する BigQueryテ

モバイルアプリエンジニアの山下です。 先日の記事でも少し触れられていましたが、LCLでは先月からフレックスタイムがトライアル導入されました。 techblog.lclco.com 今回は、エンジニアメンバーへどのような使い方をしたかをアンケートで聞いてみたのでお届けしたいと思います。 フレックスタイムを導入済み、または検討している方やLCLに興味を持っていただけているエンジニアさんの参考になれば幸いです。 フレックスタイムのルール 以下のルールで運用されています。 07:00 ~ 21:00の間で勤務可能 コアタイムは10:00~15:00 1日の中でコアタイムは必ず勤務する 1ヶ月単位では月の所定労働時間を必ず勤務する 他にも仕事の進捗などに悪い影響が起きないように細かいルールが少しだけありますが、偏りなく利用すれば問題がないため割愛します。 このルールにより、以下のような働き方が可能に

最近は花粉を避けるためにMTGがある日以外はリモートワークにしています。 モバイルアプリエンジニアの山下（@yamshta）です。 今回は先月から個人的に使い始めた『Notion』の紹介をします！ Notionとは？ Google Docs、Evernote、Trello、GitHub Wikiを合体させたようなサービスです。 非常に多機能ですが、デザインはシンプルで精錬されています。 Markdownが使え、Emojiを見出しで表現できるところがエンジニアには親しみやすいです。 一番はじめにNotionを知ったのは、イケてるプロダクトツールとドキュメントツールを探している時で、機能の多さと日本語対応していないことからチームで使うにはハードルが高いと思い、試していませんでした。 しかし、最近このサービスを個人で利用している記事を読み、実際に触ってみたところ、整理好きの私にとって最強のツール

バックエンドエンジニアの横塚です。 Railsで中規模以上のサービスを運用していると、大量のレコードやcsvをバッチで処理したい場面などが出てくると思います。 当たり前のように意識できている人も多いかと思いますが、今回はおさらいの意味も込めてバッチで大量データを扱うときに気をつけていることをまとめていこうと思います！ 大量レコードに対して処理をするときはfind_eachやfind_in_batchesを使う DBからデータを取得してきて処理をしたい場合、eachで処理しようとすると対象データがすべてメモリに展開されてしまいますが、find_eachは1行ずつメモリに展開するため、レコード数を気にせず処理をすることができます。 User.each do |user| # なんか処理 end ↓ User.find_each do |user| # なんか処理 end また、find_in_

LCLで運営している「バスとりっぷ」というメディアに、キャッシュサーバとしてVarnishを導入しました。導入する上でハマった事・得たノウハウなどを書きたいと思います。 www.bushikaku.net Varnishとは Varnish は、リバースプロキシとして動作して、HTMLなどのキャッシュができます。 詳しくは、こちらの記事を参考にさせていただきました。 Varnish入門と仕組み 導入の背景・目的 「バスとりっぷ」は、Nginx + Unicorn ( Rails ) で構成しており、記事の閲覧中心のサイトなので、普段のサーバ負荷は大したことがありません。 ただし、Yahoo!ニュースからリンクを貼って頂いた時など急激にアクセスがある状況では、Webサーバの負荷が高くなり、レスポンスタイムも大きく落ちてしまっている状態でした。 元々の構成では、記事にアクセスされるたびに必ず

フロントエンド担当の岡田です。 ある程度の期間運用しているWebサイトの場合、CSSがカオスになりますよね。 ちょっとした修正が全体に影響してしまうのがCSSの怖いところです。 弊社でも、Sass化したり、共通のCSSを変更したりする度に主要ページを目視チェックしていました。 しかし目視チェックでは時間がかかりすぎますし、違いに気づけないこともあります。 そこで、BackstopJSを導入して、気軽にリファクタリングできる環境を作りました。 BackstopJSとは BackstopJSは、CSSのリグレッションテストを自動化します。 具体的には、変更前・変更後の2つの画面のスクリーンショットを撮り、その差分を表示します。 左から順にリファレンス（変更前）、テスト（変更後）、差分の順に並んでいます。 差分のあるパーツは、ピンク色に塗られるので一目瞭然です。 BackstopJSでできること

Webエンジニアの川辺です。 今回はChromeのデベロッパーツールでスマホ表示を維持したまま別タブに遷移するという、ちょっとした便利ワザを紹介しようと思います。 手順 command ＋ option ＋ Iキー（Windowsの場合はF12キー）でデベロッパーツールを開きます。 デベロッパーツールの右上の設定メニューから「Settings」を選択します。 下の方に「Auto-open DevTools for popups」という設定項目があるのでチェックを付けます。 これでページをリロードをすると設定が反映されるため、別タブへ遷移するリンクを開いても新しいタブでデベロッパーツールが開かれるようになりました。 まとめ 過去にUser Agent Switcher, URL sniffer で無理やりスマホ表示にしたり、Death To _blank で別タブを開かないようにしたりもしま

フロントエンドエンジニアの岡田です。 LCLでは、デザイナーとエンジニアの連携をスムーズにするために、Zeplinを導入しました。 今回は、導入にあたって行ったことをまとめました。 デザイン＆コーディング体制 Zeplin導入前に使っていたツール Zeplinとは Zeplin導入の流れ インストール チームへの普及 最初はモブプロ方式の勉強会 みんなで触ってみる Chatworkにグループを作成 有料プラン契約 STARTERプランでできること その他のプランとの比較 Adobe Creative Cloud Extractと比べて良いところ テキスト情報・CSS情報がコピーできる デザインカンプへのコメントが簡単 透明にしてブラウザに重ねられる その他 課題 Photoshopのアートボードが必要 Zeplin内で表示の切り替えができない まとめ デザイン＆コーディング体制 LCLでは

Webエンジニアの森脇です。 LCLでは、ChatWork + Hubotを利用してデプロイをしていましたが、ChatWorkがWebhookに対応したため、Hubotを廃止しました。ChatWork Webhookを利用して、どのようなデプロイフローとなっているかを紹介します。 なお、Hubotを利用した構成は過去のブログに記載しています。 techblog.lclco.com 変更理由 Hubotを利用した構成でも、そこまで困ってはいなかったのですが、強いて言えば以下の理由があります。 Webhookではないため、特定のルームをChatwork APIでポーリングして発言のを検知する必要がある API呼び出し回数に制限があるため、ポーリング間隔を長くする必要があり、発言してからBotが反応するまでタイムラグがある 今後の拡張のため、慣れているRubyを使いたかった 構成 EC2上に、W

コードレビューを自動化してくれるSideCIを導入しました。GitHubのプルリクエストを自動で解析して指摘してくれます。 主にRubyを使用しているのでRuboCopを筆頭に解析ツールが豊富に揃っているのは助かっています。 導入の経緯 もともとRuboCop, JSHint, ESLintは使用しており主にローカルで実行して個人個人で修正対応していました。 RuboCopはJenkinsのJOBを走らせていましたが、毎回リポジトリ全体に対して実行すると時間がかかっていたり、わざわざJenkinsの結果を確認する必要がありプルリクエストベースの開発プロセスから外れているためあまり効率が良いものではありませんでした。 そこで自前でやるよりサービスを利用したほうが開発にリソースを投入できるということもあり以前から気になっていたSideCIを導入してみることにしました。 導入してみて良かったとこ

こんにちは。バックエンドエンジニアの id:kasei-san です 最近は映画「リベリオン」を見たいのですが、配信しているサービスがTSUTAYAとU-NEXTしかなく、加入すべきか悩んでいます doga.hikakujoho.com 本日はHTTP キャッシュについて解説します 経緯 LCLではキャッシュサーバにVarnishを使用していますが、現在Fastlyへの移行を検討中です techblog.lclco.com 移行についての作業を任されたため、HTTP キャッシュについて勉強し直そうと思いこの記事を書きました! HTTPキャッシュとは そもそもHTTPキャッシュとは何でしょうか? HTTP上でのキャッシュについてのRFC RFC 7234 — HTTP/1.1: Caching （日本語訳） の序論によりますと... HTTP キャッシュ は、応答メッセージの局所的な格納域で

フロントエンドエンジニアの岡田です。 エンジニアは工数を出す機会が多いと思いますが、みなさんはどのようなツールを使っていますか？ 私は数年前から、Togglというツールを使って計測しています。 仕事を始める前にはボタンをポチッと押し、終わったらポチッと止める。 Togglの前に使っていたツールを合わせると5年以上このスタイルで仕事をしているため、今ではすっかり習慣になっています。 ただ、手動での計測は、以下のデメリットがあります。 押し忘れたり、止め忘れることもたまにある 突然話しかけられた時など、切り替えるのが面倒 そこで自動で計測ができる、GTMというツールを導入し、使い慣れたTogglと結果を比較してみました。 Togglとは GTM（Git Time Metric）とは GTM導入方法 インストール エディタプラグインのインストール 初期化 比較方法と集計手順 Toggl GTM