お客様各位 2020年6月15日策定 株式会社ヌーラボ カスタマーハラスメントへの対応に関する方針 ■方針作成の背景 私たち株式会社ヌーラボは、チームのコラボレーションを促進し働くを楽しくするツール「Backlog (バックログ)」「Cacoo (カクー)」「Typetalk (タイプトーク)」を開発、提供する会社です。昨今の働き方改革やテレワークの導入推進による「働き方の多様化」を受け入れるための1つの手段として、弊社の提供するようなツールの導入を行う企業が増加しており、現在たくさんのお客様よりお問い合わせをいただいております。 しかし、改正労働施策総合推進法（通称：パワハラ防止法）に則って考えた際、ハラスメントと断定されるような言動をとるお客さまが、ごく僅かですが見受けられることも事実です。われわれサービス提供をしている者もお客様と同じ感情を持つ「人」です。その点をご考慮いただくために

こんにちは。Cacoo チームの木村（@cohhei）です。Cacoo チームでは、 Kubernetes によるアーキテクチャの microservices 化に取り組んでいます。今回は私たち Cacoo チームが microservices 化によって解決しようとしている課題と取り組みの内容、その成果についてご紹介します。 この記事では以下の内容を含みます。 Cacoo の開発チームがどんな課題を抱えていたか 何故 microservices の道を選んだか どんな技術を選んだか microservices 化してどうだったか 現状の課題 課題：古いフレームワークとモノリシックなアプリケーション Cacoo は2009年にベータ版がリリースされた歴史のあるプロダクトで、モノリシックなアプリケーション上ですべての機能が実行されていました。 そのため、それぞれのコードの依存関係を十分に理解

Typetalk チームフロントエンドエンジニアの岡藤（@johnykei）です。先日 Typetalk Webサイトリニューアルに伴い、フロントエンドの技術を jQuery から React + styled-components に刷新しました。本記事では、React を用いた Web サイト制作についてお伝えします。 はじめに タイトルにもあるように、僕は今まで JavaScript を書く必要がある時は使い慣れた jQuery を使っていました。 フロントエンドエンジニアという肩書きではありますが、フロントエンドエンジニアという職種は幅広く、僕はどちらかというとページやUIのスタイリングが主な業務で、普段 JavaScript を書く頻度もそんなに高くありませんでした。 最近海外ではそのような業種の人をフロントエンドデザイナーと呼ぶ動きも出てきていますが、jQuery しか使ってい

以下の3コマンド、これだけでプロジェクトに必要な開発環境ができあがる。そんな環境を Docker で作ってみませんか？ $ git clone https://github.com/dataich/sample-docker.git $ cd sample-docker $ docker-compose up こんにちは、Typetalkチームのエンジニアの吉田です！ 新しいエンジニアがチームに入ってきてまずやることは、DBやWebサーバなどの開発環境を構築することでしょう（9月に新しい人がチームに入ります、やったね！）。 Typetalkチームでも以前はREADMEに記述された手順に従って、開発者が個別に構築していました。その際READMEに書かれたミドルウェアのバージョンが古かったり、実は手順そのものが変わっていたりすることもあり、ハマることもありました。また、複数のプロジェクトで違う

【WebAssembly初心者必読】バイナリコードを使って「 WebAssembly 」の基礎を徹底解説してみた！ WebAssembly はウェブ上での利用に適した軽量でポータブルなデータフォーマットです。ゲームなどの実行速度が求められる分野で使えるように、JavaScript よりも読み込み速度や実行速度を早くすることを念頭に設計されています。それを実現するために、WebAssembly では機械語のようなバイナリコードをブラウザ上で使うようにしています。 JavaScript の生みの親であるブレンダン・アイクが 2015 年 6 月に WebAssemblyを発表してから 2 年が経ち、多くのブラウザで使えるような状況が整いつつあります。 そこで、この記事では WebAssembly のバイナリコードを使ったサンプルのコードを通して、WebAssembly を簡単に紹介したいと思い

こんにちは。Typetalkチームの永江です。今回は4月にリリースした、BacklogとTypetalkの連携機能である「Backlogカード」の実装の際に行った クリックジャッキング対策 について説明します。 Backlogカードとは Backlogカードは、Typetalkのトピック内にBacklogの課題やコメントをカード形式にして表示する機能です。Backlogの課題キーや課題のURLを貼り付けるだけで、以下の画像のように表示できます（※詳しいご利用方法についてはこちらの「Typetalkのトピック上で課題の詳細を見られる Backlogカード をリリースしました！」をご参照ください）。 Backlogカードの実装は、TypetalkからBacklogに用意した埋め込み用の課題ページを<iframe>で表示するというものです。このような実装にしたのは、もともとBacklogに<if

Backlog インフラ担当の松浦です。正式リリースから今年で 11 年目を迎えたBacklogは、昨年2016年末に新しいユーザーインターフェース（以下UI）へ大幅にリニューアルしました。開発メンバーが新しいUIの開発を進める裏側では、さらに運用しやすくするために、粛々とインフラの改善を実施していました。今回はその改善内容の一部である EC2-Classic から EC2-VPC に移行したときの内容をご紹介します。 EC2-Classic と EC2-VPC の違いに関してはこちらをご参照ください EC2-Classic から EC2-VPC へ移行した理由 ヌーラボのサービスは全て AWS で運用されています。私自身、昔から AWS を使っていたこともあり、古い環境では EC2-Classic 利用していました。EC2-Classic で運用していて、不便に感じていた点を以下に挙げま

帰省していた妻と子供を迎えに羽田空港まで行ったのに、下の子がまったく嬉しそうじゃなくてガッカリな中村です、こんにちは。 今日は、S3にMavenインハウスリポジトリを構築して、3つのビルドツール（Maven/Gradle/sbt）から扱うための設定を紹介します。 S3にリポジトリ構築するに至った背景 まず、実際の設定内容を紹介する前に、なぜS3上にリポジトリ構築しようとしたのかと、そのメリットを簡単に説明します。 MavenもしくはJavaベースの言語を利用していた場合、インハウスリポジトリを構築すると色々便利だということは、WEB+DB PRESS Vol.39の記事中でも紹介しています。私達も、今までは社内サーバ上にMavenリポジトリを構築していましたのですが、社内サーバのメンテナンスコストも馬鹿にならなくなり、もっとメンテナンスコストを減らせるものに移行しようと決断しました。 メン

Photo via Visual hunt ヌーラボアカウントではつい先日、Amazon RDS for MySQL から Amazon Aurora へと移行しました。ここでは、その経緯と実際に実施した作業を簡単にご紹介させていただきます。 移行の経緯 ヌーラボアカウントは Backlog や Cacoo、Typetalk といったヌーラボのサービスへの認証機能を提供しています。もし認証機能が使えないとすべてのサービスを利用できなくなってしまいます。そのため、ヌーラボアカウントには常に認証機能を提供し続けられるような、高いアベイラビリティが求められています。 ヌーラボアカウントではこれまで RDS for MySQL を利用していましたので、MySQL 互換を掲げる Amazon Aurora は、リリースされたときから移行の可能性を検討をしてきました。Aurora のメリットについては

本の中の似顔絵が似ているので、社内チャットのアイコンもこれにしたらどう？と言われた中村です、こんにちは。 「現場のインフラ屋が教える インフラエンジニアになるための教科書」という本を執筆してて、つい先日（2016年6月24日）発売となったので、簡単にその内容と執筆環境の裏側を紹介します。 書籍の紹介 メインターゲットは、2〜3年目のインフラエンジニアです。仕事にもちょっと慣れてきて余裕も出てきた頃に、今後生き残るために何をどうしていくかの指針となるような本です。 その中で、私は「第6章 DevOps時代に求められるスキル」を担当しました。 6.1 インフラエンジニアを取り巻く環境 6.2 Infrastructure as Code（コードとしてのインフラ） 6.3 システム開発における3つのプラクティス 6.4 DevOpsを支えるプラクティス・ツール 私はもともとアプリエンジニアなので

Photo via Visual hunt Backlog の一部のスペースにて Amazon Aurora へと移行しました。ここでは、その経緯と実際に実施した作業を簡単にご紹介させていただきます。 移行の経緯 昨年末データベース障害が発生しユーザー様には多大なご迷惑をお掛けしてしまいました。 Backlog には Terraform をどう使っているかを紹介したブログ にあるように複数の運用環境があります。 その各々の環境の構築時期によって EC2 上で自前運用していた MySQL もあれば、RDS for MySQL もある、といった統一されていない状況でした。また EC2 上ではまだ MySQL 5.1 も稼働していました。 移行を検討するにあたり、優先したのは障害時の復旧が素早く出来ることと、少しでも運用の管理コストを下げることでした。Backlog のサーバは 100 台以上で

工夫したこと リソースの分離をファイル単位で行い、使い回しができるように配慮した Backlogチーム以外でも利用できるようになるべくAWSリソース単位でファイルを分割しておき組み合わせるだけでリソースが構成できるように配慮しました。 ファイル構成例を記載していますがterraform applyを実行したときに全ファイル読み込んですべてのリソースを作成してくれます。 depends_on設定をしておくと各リソースの依存関係を制御できすべてのリソースをいっきに作成することが可能です。 . ├── config.tf ├── terraform.tfstate ├── terraform.tfstate.backup ├── user_data │   └── api.tpl ├── variables.tf ├── vpc-db-instance.tf ├── vpc-db-subnet-

最近、リモートワークなど柔軟な働き方に関する記事をよく見かけるようになり、関心の高さを感じています。特に女性は結婚や出産などライフステージの変化と仕事のバランスに悩むことも多く、リモートワークに興味がある方も多いのではないでしょうか？ 私は結婚を機に離島に引っ越し、今年の5月からリモートワークをはじめました。そこで、人口701人の小さな島でリモートワークをする話を書いてみたいと思います。（リモートワークだからではなく、島ならではの話も含まれていますが、そこはご了承ください。） どんな島に住んでいるの？ 九州本島から船で30分程度のところにある、大島という島に住んでいます。 島の周囲は15kmほどで、車だと30分で一周できるくらいです。2015年3月の時点で島の人口は701人です。1950年には2,200人くらいの人が住んでいたそうですが、若い人が働きに本土へ移ったので、今はお年寄りが多くな

サービス環境での事例も耳にすることが多くなった Docker ですが、皆さんの現場でも活用されてますでしょうか？ヌーラボでは2014年の夏にローンチした開発者向けのウェブサイトである Nulab Developers にて Docker を利用したブルーグリーン・デプロイメントを行っています。本エントリではサイト更新時のワークフローなども含めその全体像を紹介します。 ミドルウェアの構成 上図にあるとおり EC2 インスタンス上にブルーとグリーンの Docker コンテナを常時二つ上げており、同じインスタンス上に nginx がリバースプロキシとして動いています。ウェブサイトの構築には Drupal を利用しており、ブルーとグリーン環境内の Drupal が利用する MySQL のデータベースをおのおの用意しています。Docker のイメージは baseimage-docker に Apac

こんにちは、江口です。 2月21日(土)に「実戦での Scala 〜 6つの事例から知る Scala の勘所〜」をスマートニュース株式会社さんと共同で開催いたしましたので、その様子と発表内容を公開された資料とともに簡単に紹介します。 場所は渋谷にあるスマートニュースさんの新オフィスで行われました。Scalaへの注目度の高さもあってか、当日は広いスペースに用意された座席がほぼ満席という盛況具合でした。 ビズリーチの新サービスをScalaで作ってみた ～マイクロサービスの裏側 (株式会社ビズリーチ 竹添さん) 最初に、株式会社ビズリーチの竹添さんから、新サービスであるスタンバイという求人検索エンジンの開発についての発表が行われました。 サービス全体のアーキテクチャにマイクロサービスを採用し、各サービスの実装にはScalaを採用したというような内容でした。 Scalaを採用した理由として、並列処

CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障

米国において2014年10月14日に、安全な通信のために用いられるプロトコルの SSLv3 に深刻な設計上の問題があることが報告されました。 This POODLE Bites: Exploiting The SSL 3.0 Fallback (PDF ファイル、英語) CVE-2014-3566 (英語) この脆弱性を利用すると、悪意のある第三者が暗号化された通信の内容を盗聴することが可能となり、それによってご利用のサービスの情報が漏洩してしまう可能性があります。 ヌーラボでの対応状況 ヌーラボではこの情報を確認した直後よりその影響の甚大さから、弊社が提供する全サービス及び弊社運営のウェブサイトにおける影響範囲の調査を即座に開始し、対応を行っております。 弊社が管理しているサーバにて HTTPS の通信を提供しているものについては、SSLv3 を無効化する作業を行い、10月15日12時頃

私たちの元々の目的は「イミュータブルインフラストラクチャ」を構築する事ではなく、前編で紹介した課題を解決するための運用フローを構築することでした。それを開発のフェーズからコツコツと模索した結果として「イミュータブルインフラストラクチャー」に少しずつ近づいている、というのが正直なところです。

このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基本的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。

昨日は雪が舞う悪天候にも関わらず、大勢の方に NUCON にお越し頂きました。みなさま本当にありがとうございました！ 基調講演は元より各セッションも大盛況で、「どのセッションを見ればよいか悩んだ」「見れなかったほうのセッションの資料をみたい」といったお声もいただきましたので、以下に資料を公開いたしました。 テクニカルトラック 開発者がかたるヌーラボのコラボレーションサービス API 最前線 ( ヌーラボ 染田貴志、中原正二、後藤幸 ) 職人任せにしないインフラ構築/運用 ~ DevOps時代を生きぬくために ~ ( ヌーラボ 中村知成 ) 今どきのリアルタイムコラボレーションツールの作り方〜Backlog、Cacoo、Typetalkにおける実践例〜 ( ヌーラボ 縣俊貴 ) ジェネラルトラック ヌーラボサービスの利用事例 – Backlogを使ったオフショア開発 ( EVERRISE 古