PagerDutyでJOBの異常終了を通知する - LCL Engineers' Blog
Webエンジニアの森脇です。 LCLでは、以下の記事でご紹介したように、PagerDutyを利用して障害通知を行っています。 techblog.lclco.com Webサービスの障害通知だけではなく、JOBが異常終了した場合の通知も行っているので、簡単に紹介します。 背景 LCLでは、ジョブスケジューラとしてKuroko2を利用しており、JOBが異常終了した場合にはSlackへ通知しています。 techblog.lclco.com JOBが異常終了するケースとして、 連携先のシステム側で一時的に問題が発生し、次のスケジュールで正常実行されれば問題ないもの 必ず手動でリカバリ必要なもの に分類できますが、後者の重要なエラー通知はSlackだと見逃す恐れや、対応が遅れる恐れがあるので、PagerDutyへ通知するようにしました。 実現方法 Integration Keyの取得 PagerDu
輪読会がうまく回りはじめた話 - LCL Engineers' Blog
モバイルアプリエンジニアの山下（@yamshta）です。 LCLでは今月から全社員を対象にしたフレックスタイム制のトライアル期間が始まりました。 エンジニアは以前からもフレックスに近い働き方が可能でしたが、いくつかの新しいルールが追加されました。 これまでの取り組みはこちらの記事でご紹介しています。 techblog.lclco.com この変更から勤務時間を柔軟に偏らせたり、早い時間からオフィスで勤務できるようになったため、私も仕事を早く切り上げた日は、個人アプリ開発や書籍購入制度で買ってもらった本の読書に充てられるようになりました。 techblog.lclco.com 前置きが長くなってしまいましたが、今回は上の記事でさらっと触れられている輪読会の取り組みについてもう少し詳しく紹介させていただこうと思います。 輪読会を実施する目的 LCLのエンジニアチームで共有している、輪読会の目的
E2EテストをPhantomJSから、Puppeteer + Headless Chromeへ移行しました - LCL Engineers' Blog
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の開発が終了したこともあり、移行すること
CSSのコンパイラをsass-railsからnode-sassへ変更しました - LCL Engineers' Blog
フロントエンドエンジニアの岡田です。 先日、LCLが運営する夜行バス比較なびのCSSコンパイラを、sass-railsからnode-sassへ変更しました。 今回は、Node.jsへの移行にあたってRailsとの連携をどうしたか、移行で起きた問題などについてまとめました。 node-sassとは sass-railsからnode-sassへ変更した理由 Sassをフロントエンドの管理下に置きたかった LibSassにするとコンパイル速度が早くなる Railsとnode-sassの役割分担 今回やらなかったこと ファイルのminifyのNode.jsへの移行 AutoprefixerのNode.jsへの移行 node-sass化に伴う変更点 Node.js package.json node-sassの他に使ったパッケージ SASS（SCSS） Rails アセットパイプライン マニフェスト
1日のスケジュールを可視化してタスク消化率の最適化を図る - LCL Engineers' Blog
1日のスケジュールを可視化してタスク消化率の最適化を図る モバイルアプリエンジニアの山下です。 今年からGoogleカレンダーにその日のタスクを予定として登録しています。 これにより、以下のメリットがあります。 日毎に消化したタスクを後から見返せる イベント・MTGや勤怠管理と一緒に予定を管理できる 他の人にスケジュールを共有できる 加えて、LCLでは始業の際に朝会で行うようなスケジュールの共有をチャット上で行っており、スケジュール内容をフォーマットに沿って投稿するようにGASを使って自動化しています。 techblog.lclco.com これらのメリットから始めた当初は満足していたのですが、運用から5ヶ月を経ちいくつかの問題が出てきました。 タスク消化時間を集計しづらい 同じタスクを分割して登録する必要がある 予定と作業時間の差分がみえなくなる 作業ノイズがわからない より詳しく落とし
がんばるタイム、止めました - LCL Engineers' Blog
フロントエンドエンジニアの岡田です。 LCLのエンジニアチームでは、2月から3ヶ月半ほど「がんばるタイム」を実施していましたが、少し前に止めました。 今回は、「がんばるタイム」導入の背景や、結果についてまとめました。 がんばるタイムとは トリンプ・インターナショナル・ジャパン株式会社が導入している、業務に集中する時間を設定する制度です。 以下のウェブサイトによると、おしゃべり、電話、立ち歩き、コピー、部下からの相談、さらに上司からの指示も全面的に禁止とのことです。 w-kawara.jp がんばるタイム導入の背景・目的 LCLでは、日々のコミュニケーションにチャットツールを使っています。 そのため、直接話しかけられて手が止まってしまう、ということはあまりありません。 ですが、チャットツールに未読件数のバッヂがつくたびにチェックをしてしまって集中できない、という声はありました。 そこで、チャ
LCLでの書籍購入制度の活用事例 - LCL Engineers' Blog
Webエンジニアの森脇です。 最近では、福利厚生として書籍購入制度がある会社も増えてきたと思いますが、LCLも例に漏れず書籍購入制度があります。技術情報はインターネットで十分だったりするので、最近は書籍を読まない方も多いかもしれませんが、LCLでは書籍購入制度が活発に利用されています。 今回は、簡単に制度を紹介したいと思います。 LCLの書籍購入制度 全額補助 金額、冊数に制限なし WEB+DB PRESSなどの雑誌は、定期購読 技術書だけではなく、ビジネス書など、少しでも業務に関連していれば何でも購入可能です。 購入申請の流れ 購入時は、以下のように、AmazonのURLをチャットワークで上長に申請をするだけです。 書籍貸出の運用 貸出の運用は、かなり原始的です。チャットワークに「書籍管理」グループがあり、チャットワークのタスクとして本のタイトルと期限を追加します。 期限が近くなると、通
ESLintを使用しているプロジェクトにPrettierを導入しました - LCL Engineers' Blog
フロントエンドエンジニアの田中です。 今回、プロジェクトにコードフォーマットのプラグインであるPrettierを導入しました。 元々、ESLintを使用してコードの品質担保をしていたのでPrettierとの競合が起きないよう設定も行いました。 Prettierとは Prettier はソースコードを整形してくれるコードフォーマットのプラグインで、以下のような特徴があります。 多くの言語に対応（ES6, JSX, TypeScript, CSS, SCSS …etc） ルールの設定が可能 ESLintとの連携が可能 導入の目的 下記に示している導入前の状況と課題を解決するべく、Prettierを導入して共通のコード整形の自動化、共有することが目的です。 状況 コードフォーマットをAtomエディタのプラグイン（Atom beautify）で行っている 課題 バックエンドエンジニアがAtomを立
ALBのログをEmbulk + BigQuery + Redashで可視化する - LCL Engineers' Blog
Webエンジニアの森脇です。 LCLでは、AWS ALBのアクセスログを分析し、各種KPIを定期的に確認しています。今回は、Embulk + BigQuery + Redashを利用してのログ分析の事例について紹介したいと思います。 概要 AWS ALBのアクセスログは、S3へ記録されます。S3へ記録されたログを、fluentd / Embulk を利用して Elasticsearch / BigQuery へ格納しています。 Elasticsearchは、短期的なログの解析を目的としており、Kibanaを使用して予期せぬアクセスが発生した場合の調査等に利用しています。ログは一定期間を過ぎると破棄しています。 BigQueryは、長期的なログの保存・解析を目的としており、ログは永続的に保存しています。 準備 以下の流れでやっていきます。 ALBのアクセスログを有効化する BigQueryテ
Zeplinを導入してデザイナーとエンジニアの連携をもっとスムーズに - LCL Engineers' Blog
フロントエンドエンジニアの岡田です。 LCLでは、デザイナーとエンジニアの連携をスムーズにするために、Zeplinを導入しました。 今回は、導入にあたって行ったことをまとめました。 デザイン＆コーディング体制 Zeplin導入前に使っていたツール Zeplinとは Zeplin導入の流れ インストール チームへの普及 最初はモブプロ方式の勉強会 みんなで触ってみる Chatworkにグループを作成 有料プラン契約 STARTERプランでできること その他のプランとの比較 Adobe Creative Cloud Extractと比べて良いところ テキスト情報・CSS情報がコピーできる デザインカンプへのコメントが簡単 透明にしてブラウザに重ねられる その他 課題 Photoshopのアートボードが必要 Zeplin内で表示の切り替えができない まとめ デザイン＆コーディング体制 LCLでは
自動タイムトラッキングツールのGTMを手動のTogglの結果と比較してみた - LCL Engineers' Blog
フロントエンドエンジニアの岡田です。 エンジニアは工数を出す機会が多いと思いますが、みなさんはどのようなツールを使っていますか？ 私は数年前から、Togglというツールを使って計測しています。 仕事を始める前にはボタンをポチッと押し、終わったらポチッと止める。 Togglの前に使っていたツールを合わせると5年以上このスタイルで仕事をしているため、今ではすっかり習慣になっています。 ただ、手動での計測は、以下のデメリットがあります。 押し忘れたり、止め忘れることもたまにある 突然話しかけられた時など、切り替えるのが面倒 そこで自動で計測ができる、GTMというツールを導入し、使い慣れたTogglと結果を比較してみました。 Togglとは GTM（Git Time Metric）とは GTM導入方法 インストール エディタプラグインのインストール 初期化 比較方法と集計手順 Toggl GTM
Embulkを利用して、AWS請求情報をRedashで可視化する - LCL Engineers' Blog
Webエンジニアの森脇です。 今更ながら、Embulkを使う必要がでてきたので、素振り兼ねてAWS請求情報(S3)をDBへ格納しRedashで可視化できるようにしました。 背景 AWSの費用は管理コンソールの「コストエクスプローラー」で確認できますが、コンソールへのログインはMFAを使用していることもあり、確認が面倒という課題がありました。（アクセス兼がないメンバーもいる） エンジニア全員に、気軽にAWSの費用感をつかんでもらうために、日々参照しているRedashで可視化することにしました。 構成 事前準備として、以下の設定を参考に、AWSの請求情報をS3に配信しておきます。 docs.aws.amazon.com Embulkを利用して、S3上のCSVをダウンロードし、DB(PostgreSQL)へロードします。DBのデータをRedashで参照する構成をとりました。 Embulkの実装
ChatWork Webhookを利用したデプロイフロー - LCL Engineers' Blog
Webエンジニアの森脇です。 LCLでは、ChatWork + Hubotを利用してデプロイをしていましたが、ChatWorkがWebhookに対応したため、Hubotを廃止しました。ChatWork Webhookを利用して、どのようなデプロイフローとなっているかを紹介します。 なお、Hubotを利用した構成は過去のブログに記載しています。 techblog.lclco.com 変更理由 Hubotを利用した構成でも、そこまで困ってはいなかったのですが、強いて言えば以下の理由があります。 Webhookではないため、特定のルームをChatwork APIでポーリングして発言のを検知する必要がある API呼び出し回数に制限があるため、ポーリング間隔を長くする必要があり、発言してからBotが反応するまでタイムラグがある 今後の拡張のため、慣れているRubyを使いたかった 構成 EC2上に、W
Varnish Grace Modeで非同期にキャッシュを更新する - LCL Engineers' Blog
Webエンジニアの森脇です。 先日、Inside Frontend というフロントエンドのイベントがあり、チームメンバーが参加しました。参加メンバーから日経新聞社様の「日経電子版を速くする」について共有をしてもらい、弊社でも活用できそうな点は、取り入れさせて頂くことにしました。 日経電子版を速くする / nikkei-inside-frontend - Speaker Deck 資料の中で、Fastlyの「キャッシュの非同期更新」について紹介されています。弊社では、FastlyではなくVarnishを利用していますが、VarnishのGrace Modeでも同等のことが実現可能のため、今回は簡単な検証を兼ねて紹介します。 LCLでのVarnish活用については、以下の記事で紹介しています。 techblog.lclco.com Grace Modeとは キャッシュ有効期間(TTLで設定され
Railsアプリケーションで採用しているDBスキーマ設計ガイドライン - LCL Engineers' Blog
Webエンジニアの森脇です。 Railsアプリケーションで採用しているDB設計（スキーマ定義）について紹介します。 ※ Railsでは当たり前もの、Railsに依存していない内容も含んでいます。 前提 環境違えば、採用するルールも異なると思いますので、まずは弊社で利用している環境を記載します。 DBはPostgreSQL 9.x 開発言語は、Rails 4.x,5.xを利用 命名ルール Railsの規約に沿う命名を採用しています。DB設計にこだわりがあるメンバーにとっては、異論があるルールもあるのですが、アプリケーション開発の生産性も考慮しRailsの規約に寄り添うのがよいと判断をしました。 テーブル 動詞は使用せず、名詞とする 複数形とする 1:n のテーブル名は「単数形_複数形」 とする n:n のテーブル名は「複数形_複数形」とする カラム カラム名にテーブル名のprefixは付与し
Dangerの指摘をChatWorkに流してリリースのミスを防ぐ - LCL Engineers' Blog
モバイルアプリエンジニアの山下です。 LCLでは作業中のPull Reqeustが誤マージされるのを防ぐため、Pull Requestのステータスをラベルで管理しています。 ラベルは「WIP」と「ready for release」の2つあり、マージするためには「ready for release」を付ける必要があります。 「ready for release」を付けられたPull RequestはChatWorkに通知され、開発部のメンバーへ周知されるようになっています。 今回はこの通知に先日導入したDangerの指摘を一緒に流し、指摘事項を全員が確認できるようにしてみました。 それでは実装例とGitHub Webhookの効率的なデバッグ方法を紹介していきます。 実装 GitHub Webhookで送られたJSONからDangerのコメントを取得して特定のルームに通知します。 今回は以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
