インターン生の村田です！

はじめまして、慶應義塾大学2(3)年の村田正之です。

2016年4月から株式会社Cluexでエンジニアとしてインターンをしております。 よろしくお願いします。あと、上のカッコはあまり気にしないでください。

株式会社Cluexで働く前

Cluexにジョインするまでは所属していた学生団体の活動に多くの時間を割いていました。大学と深い関係もありその歴史は10年以上という、学生団体としては比較的しっかりとした方だったと思います。そこではビジネスコンテストの運営、もう少し堅い言葉を使ってしまうとインキュベーション活動をしておりまして、最終的にはその代の副代表も務めておりました。

当時はあまり意識していなかったですが、その学生団体では本当にたくさんのことを勉強させていただきました。 リーンスタートアップやデザイン思考といったアイデアやビジネスの創造においての基本的な概念を学ぶことができましたし、僅かではありますが、マネジメントや組織の形成の仕方、ファシリテーションと言った汎用的な能力も身につけることができました。 ファシリテーションなどの能力はエンジニアと無縁に見えることもあるかもしれませんが、チームで開発をしていく上では非常に大切な能力の一つであり、現在でも活かされている場面が多いと思います。 そのようなことを学ばせていただけたという意味で、現在でもその学生団体には感謝を忘れることはできません。 しかし活動期間がありましたので、活動終了後は特別に打ち込むものもなく普通の学生生活を送っていました。

株式会社Cluexのインターンに応募したきっかけ

その学生団体のビジネスコンテストを運営していく中で、ものづくりができる人の強さを目の当たりにしてきました。　特に能力の高いエンジニアを抱えているチームはアイデアにとどまらず素早く行動に移すことができるため、短期間でピボットを繰り返していることがとても衝撃的でした。　

実はそのあたりから密かに、「エンジニアってかっこいいなあ」という憧れを抱き始めました。

そこで密かにプログラミングの本を購入して独学で勉強を始めました。 ただ、自分はエンジニアのコミュニティに属していなかったので、チャレンジしても誰にも相談できないまま解決できないということが何度か続き、結局挫折してしまいました。 そうしている中で、「もしプログラミングを学ぶなら優秀なエンジニアがいてスピード感のある環境に身を置きたい」と思いインターンを探していたところCluexというスタートアップを発見して応募しました。

当時は初心者でも受け入れてくれたので面接の応募をしたのですが、面接に行った際にサービスとプログラミングが大好きな人たちが働いている様子を見て、「ここでエンジニアとして働きたい！！」と感化されてしまいました。

いまやっていることと将来やりたいこと

Cluexでは2つのチームに分かれて開発を進めております。 1つがWebAppTeam、もう1つがNativeAppTeam(iOS)です。 私は前者のWebAppTeamでRubyonRailsを使って開発を進めています。 インフラ周りはまだほとんど触っていませんが、フロントエンドとバックエンドについてガリガリ書いています。

休みの日は業務以外のプログラミングを楽しんでいます。 最近はRubyのメタプログラミングを勉強してるので、今週の日曜日は有名なgemの中身を読んでみようと思ってます。

今後はもっとミドルウェア周りを色々遊んでみたり、サーバーもいじっていきたいです。 あとハードにも興味があるので将来的にはソフトだけではなくて、ハード側も勉強したいと思っています。 ただ今から他の言語に浮気してもうまくいきそうにはないので、まずは我慢してじっくりRubyとRailsに慣れていこうと思います。

Cluexではエンジニアの方を募集しています！

エンジニアリングと同時にビジネスマンとして成長したい、スタートアップで働いてみたい、もうレガシーな環境で余計な苦労しをたくないといった方など、 興味がある方はご連絡下さい。 https://www.wantedly.com/projects/60136

規律あるcssを運営するにあたって

こんにちは、エンジニアの井戸田です。

弊社ではmamanokoという子育てママさんのための情報サイトを運営しており、Ruby on Railsで実装しています。 今回はmamanokoで実装されているのcssの構成についてお話ししたいと思います。 mamanokoではSMACSSというcssの設計手法や、BEMというフロントエンド設計手法を弊社なりにカスタマイズして使用しています。

フロント面の開発環境は下記のようになっております。

SCSS
Slim
CoffeeScript

まずは本来のSMACSS、BEMについて説明します。

SMACSS

SMACSSとは、 Scalable and Modular Architecture CSS の略で スマックス と読みます。CSSの設計手法で１つであり、 Base(ベース) 、 Layout(レイアウト) 、 Module(モジュール) 、 State(ステート) 、 Theme(テーマ) の５つのルールに分け、それぞれのルールや記述規約が決められているのが特徴です。

smacssで設計する目的

SMACSSを導入することによって、コードの量が減り、CSSの弱点であった下記のことが解決されます。

  • 保守性を高める
  • メンテナンス性を高める
  • デザインを統一することで、ユーザー体験の一貫性を高める

5つのルール

Base - ベースルール

要素そのもののスタイルを定義します。 セレクタを使ってスタイルを変更する場所であるので、idやclassは使用できません。

body {
  background-color: #fff;
  color: #000;
}

a {
  &:hover {
    color: inherit;
  }
}

Layout - レイアウトルール

ページのエリア分けを定義します。 header , footer などよく id 指定するユニークな要素がLayoutに該当すると思います。 Module や state との区別のため l- というprefixをつけるのが特徴です。このようにすることで、他のルールと区別ができ、管理がしやすくなります。

.l-header {
  height: 48px;
  background-color: #fff;
}

.l-footer {
  background-color: #fff;
  border-top: 1px solid #000;
}

Module - モジュールルール

その名前の通り再利用可能なスタイルを定義します。 ページデザインのcssを書くにあたって、ほとんどがここに定義されると思います。 どこにおいても再利用できるように独立させておきます。

またクラスの書き方は モジュール名-サブクラス の順番で書きます。

.article
  p.article-title タイトル
. article {
  background-color: #fff;
  border: 1px solid #000;

  &-title {
    color: #000;
  }
}

State - ステートルール

状態によってデザインを上書きする時に定義します。 !important を使用してのデザインの変更は避けましょう。 !important を使用することで醜いコードになってしまいます。 ステートルールはモジュール名を付けてあげると、クラス名で被ることはないと思います。

.is-item-active
.is-item-hidden

Theme - テーマルール

テーマルールを使用する機会は少ないです。 他言語対応時、英語や中国語など言語で標準のフォントサイズでは小さい場合があるので、そのような場合にテーマルールを使用することもあります。 theme- というprefixをつけるのが特徴です。

BEM

BEMとは Block , Element , Modifier の頭文字を取ったもので、 ベム と読みます。 コンポーネント化のためのclss命名規則です。

BEMで設計する目的

BEMを導入することによって、パーツごとにclass名を完全に独立したものとできるので、下記のことが解決されます。

  • 再利用性を高める
  • 拡張性を高める
  • 開発の生産性とメンテナンス性を高める

BEMの規約

  • Block
    • 文字通りブロック（塊）。構成のルートとなる要素です。
  • Element
    • Blockに所属する子要素。必ずBlockの中でのみ存在し、単体では使用してはいけません。
  • Modifier
    • 元となるBlock又はElementから変化した状態を示すものです。

上記の元に下記の規約が定められています。

  • BlockやElementで２つ以上の単語の場合はハイフン１つ(-)
  • Modifierで２つ以上の単語の場合はアンダースコア１つ(_)
  • BockとElementはアンダースコアを２個(__)
  • Block又はElementとModifierはハイフンを２個(--)
.articles-list
  .articles-list__item
    .artiles-list__item__title
      | タイトル

  .articles-list__item--state_small
    ・
    ・
    ・

弊社のSMACSSとBEMの構成

まず弊社ではマルチクラス設計を採用しています。 マルチクラス設計とは、HTMLに複数のclassを書いて、スタイルを当てる設計のことです。 マルチクラスを採用することにより、冗長な記述が減り、保守性の向上につながります。

例) ピンクのボタン(.button-pink)と、緑(.button-green)のボタンを定義

/ good

.button {
  padding: 12px 20px;
  background-color: #fd8280;
  border: 1px solid #fd6360;
  border-radius: 2px;
  color: #fff;
  
  &-pink {
    background-color: #fd8280;
    border: 1px solid #fd6360;
  }
  
  &-green {
    background-color: #3de933;
    border: 1px solid #0ce400;
  }
}

/ bad
.button { 
  &-pink {
    padding: 12px 20px;
    background-color: #fd8280;
    border: 1px solid #fd6360;
    border-radius: 2px;
    color: #fff;
  }
  
  &-green {
    padding: 12px 20px;
    background-color: #3de933;
    border: 1px solid #0ce400;
    border-radius: 2px;
    color: #fff;
  }
}

SMACSS

本来では5つのルールに分けるのですが、弊社では７つのルールに分けて使用しています。
smacssでは、ほとんどのスタイルが module に定義されると思うのですが、 module をもっと細かいルールに分けることによって、fatになってしまいがちの module を防いでいます。

  • Base
    本来のSMACSSと同じで、要素そのもののスタイルを定義します。
    セレクタを使ってスタイルを変更する場所であるので、idやclassは使用できません。
a {
  color: #000;
}
  • Component
    component に書くものなのですが、 見出し 部分や ボタン など、どこのページでも使い回す要素をここで定義します。そのため、グローバルなクラス名を付ける必要があります。
    現在のmamanokoでは見出し部分のクラス名は .heading 、ボタン部分のクラス名は .button と付けています。
.heading {
  border-bottom: 1px solid #000;
  padding: 0 8px;
  margin: 0 0 10px
}
  • Module
    moduleも使い回す要素を定義します。componentとの違いとして、グローバルなclass名をつけない要素を定義するということです。主にグローバルなクラス名ではない要素のほどんどが、ここに定義されます。

ユーザページのアバター画像及び、ユーザーネームを表示するヘッダーのcssを作成する場合

.userHeader {
  padding: 20px;
  background-color: #fff;
  
  &_image {
    width: 80px;
    height: 80px;
  }
  
  &_name {
    font-size: 80%;
  }
}

  • Layout
    本来のSMACSSと同じで、header , footer などよく id 指定するユニークな要素のものを記述し、 l- というprefixを付けて他のルールと区別するようにしています。

  • Patch
    使い回しをしない、特定のcssを定義するルールです。現在ではcontroller名ごとにファイルを分けをしており、ファイル内ではactionごとにcssを変更するようにしています。このようにすることによって、特定のページだけcssが変更することができるのを加えて、componentやmoduleのcssを打ち消すことができます。 但し patchを使いすぎると、醜いコードになってしまうので注意が必要です。

.users_controller {
  .edit_action {
    .heading {
      font-size: 80%;
    }
  }
}
  • Lib
    mixinなどの関数や、colorコードを変数で定義するルールです。
    mixinなどの関数を１ファイルにまとめておくことで、保守性を高め、メンテナンスがしやすくなると思います。 またcolorコードを変数で定義することにより、他のルールでcolorコードを設定する場合に、定義した変数を使うので、保守性、メンテナンス性を高めるのはもちろん、ユーザー体験の一貫性を高める効果があると思います。

現在mamanokoではここに定義されたcolorコードの変数を使い、色を濃くするにはscssの関数である darken や、色を薄くするには独自に関数を作成したものを使用しています。

@mixin rounded-s {
  border-radius: 2px;
}

@mixin rounded-m {
  border-radius: 4px;
}
$base-color: #000;
$primary-color: #ff828c;
  • Vendor
    外部ライブラリのcssを書き換えるルールです。現在mamanokoではBootstrapを使用しているのですが、デフォルトでcssが定義されており、うちのサイトにあったデザインにするためcssを書き換えています。

BEM

本来のBEMでは上記でも書いたようなルールがあります。

- BlockやElementで２つ以上の単語の場合はハイフン１つ(-)
- Modifierで２つ以上の単語の場合はアンダースコア１つ(_)
- BockとElementはアンダースコアを２個(__)
- Block又はElementとModifierはハイフンを２個(--)

BEMの本来の形のまま実行してしまうと、下記のようなデメリットがあります。

  • クラス名が冗長になってしまうので、コーディング量が増える
  • 深くネストした要素はクラス名が複雑になってしまう

このデメリットを防ぐために、弊社では独自のルールを制定しています。

弊社のルール

  • BlockとElement又はModiferとElementの区切りはアンダースコアを１つ( _ )
/ good
.block_element
.block-modifier_element

/ bad
.block__element
.block--modifier__element
  • BlockとModifier又はElementとModifierの区切りはハイフンを１つ( _ )
/ good
.block-modifier
.block_element-modifier

/ bad
.block--modifier
.block__element--modifier
  • BlockやElement, Modifierが２つ以上の単語で表す場合キャメルケースを使用する
/ good
.articlesList
  .articlesList_container

/ bad
.articles-list
  .articles-list__container
  • ElementのElementは記述しなくて良い
/ good
.articlesList
  .articlesList_container
    .articlesList_title
    
/ bad
.articlesList
  .articlesList_container
    .articlesList_container_title

いかがでしょうか？ SMACSSのルールをより細分化、BEMを冗長性を防ぐためハイフンや、アンダースコアを省略することで、より使いやすくなると思います。 最初は慣れないと思いますが、慣れてこれば簡単に要素のcssを検索することができるのではないでしょうか。

最後まで読んでいただきありがとうございました。

はじめまして、エンジニアの神山です！！

はじめまして、神山奎吾です。2016年4月から株式会社Cluexでエンジニアとして働いております。よろしくお願いします。

株式会社Cluexで働く前

2016年4月に私は新卒としてCluexにジョインしたのですが、それまでは別の会社で営業をしておりました。そこは大学4年次の4月に内定を頂いたところで、それから大学生ながらも働かせて頂きました。会社規模はCluexとほとんど変わらないスタートアップ企業でした。なぜ営業を選んだのかというと、当時からエンジニアに興味を持っていたのですが、「知識・経験がゼロの状態から始めるのなら営業でいいや」という安易な考えでした。またエンジニアを志した理由もただ興味があるだけで、そもそも将来にやりたいことすら曖昧でした。自分でやりたいと思った事業を創ること、また自分で引っ張る、時に起業できるぐらいの実力者になれたらいいなといった感じでした。

入社して最初の1,2か月はテレアポで新規クライアントの開拓をしてました。毎日200件近く電話をしておりました。しかも最初の2週間くらいはまったくアポが取れずすべて断られ続け、精神的にとても辛く苦しい思いをしました。あまりにもできなかったのが悔しく、休みを利用してテレアポの派遣に登録しテレアポのプロたちの会話術を必死に聞いて真似しておりました。そしてようやくその次の日からアポが取れるようになりました。アポが取れた時に同僚の方々に拍手喝采して頂き、このときの嬉しさは今でも忘れることが出来ません。 今振り返るとこのとき逃げずに挑戦し続けた経験が自分を精神的にかなり強くしてくれたと思います。またダメだった状態から50件に1件ぐらいの割合でアポがとれるようになると仕事がとても好きになり、強い自信を持つことができました。

テレアポの次は実際に広告を運用しており、当月の売り上げを先月の1.25倍にするというノルマのもと働いておりました。この仕事で毎月に一定額以上の利益を出す大変さを学ぶとともに、有限な時間をいかに有効的に使うかを意識して働いておりました。この仕事もハードでしたが、なんとかノルマを達成し続けることができました。このときに努力と根性と少しのクレバーさがあれば人間何でもできると気づきました。

株式会社Cluexに入社したきっかけ

入社して半年ぐらいしたときに、自分は将来何がしたいのか、どのような働き方をしたいのか考えるようになりました。そもそもなぜスタートアップ企業で働いているのかというと、爆速で実力をつけられる一番の環境だったからであり、なぜ実力を付けたいのかというと、実力があれば仕事に困ることもないどころか多種多様な仕事を良い条件でできる、本当の意味での安定が手に入る、また自分の好きな仕事を好きなようにできる、時に旅に出たりなど自由気ままに生きていけると考えていたからでした。 またなぜエンジニアに興味を持ったのかというと、昔から自分はものづくりが好きであり、仕事を楽しみたいとしたらエンジニアが一番なのかなと思ったことでした。欲を言えば自分の代名詞となる世界的なサービスを作りたいと思っておりました。またパソコンやインターネットに興味があり、FacebookやAppleに憧れておりました。理想は自分が0の状態からコードを書いたものを、事業として大きくスケールアップさせ、そのサービスが語られるときに自分の名前もセットで語られることです。

そして当時働いていた会社が上場を考えており、もし本当に究極のなりたい自分になるのなら、今エンジニアを目指すべきだと考え、会社をやめることにしました。社会人の基礎や営業のやり方を学ばせて頂き、公私共に大変お世話になっていたので、自己都合で辞めたことは大変申し訳なく感じております。

その後、2月の終盤ごろにCluexに声をかけて頂きました。最初は社歴がとても短く人数もごく少数の会社なので、未経験のエンジニアとして採用されたとして自分の希望通りに働けるのか、未経験を育てるだけの余裕や教育方針があるのか、悪い意味での何でも屋になるのではないかという不安もありました。しかし話を聞いてみると、エンジニアのリーダーが私と同じく営業上がりで未経験ながらもエンジニアに転職した方であったり、そもそもエンジニアとして経験が豊富な方がいらっしゃったりして、当初の不安は感じませんでした。また人と人の距離がとても近く団結力があり、しかも全員がやる気に満ちており凄く魅力的な会社だなと思いました。 それから何回かCluexに足を運んでいたのですが、メンバー全員が毎日朝から晩まで働いていて、しかもそれを当たり前のように笑って仕事をしているという環境がとても羨ましく、自分もここで働きたい、ここなら爆速で実力を付けられると思い、Cluexで働きたいと強く思うようになりました。また社員の皆さんにも歓迎していただけまして、3月中旬にジョインが決まりました。

いまやっていることと将来やりたいこと

現在、Ruby on Railsにて開発しております。4月1日にRoRのチュートリアルを始めたので3ヶ月と少し経ちます。当時は何もかもがわからない状態でした。プログラミング自体が初めてで、ターミナルって何？どうやって動いているの？みたいな状態でした。 入社してからはいままで休むことなくパソコンのキーを叩いております。というのも寝てる時間以外常に仕事のことを考えております。仕事が楽しくて楽しくて仕方がない状態です。現在入社して3ヶ月目ですが、出来ることが格段に広がりました（勿論、知識が足りてないところは大いにありますが…）。最近はReactをガシガシ書いており、Reactを書いている時間が日々の楽しみになっております。 また、最近はWebアプリケーションチームとして、少人数のチームが構成され、チームを意識した働き方をしております。この会社に入って個々人で開発していた日々から、本格的にチームとして動くようになり、この先、皆で何かを成し遂げたいと思うようになりました。また会社的にもまず上場をさせるという目標があるので、その時が楽しみでなりません。その場面に立ち会ったときには、自分も会社の重要な軸になっているようにより一層の努力を重ねるつもりです。

将来的には、全世界の人々に楽しんで頂けるようなサービスを作りたいと考えています。年齢や性別、言語や文化関係なく、その時一瞬でも幸せを感じて頂けるサービスを作りたいと考えております。自分は大学時代ずっとマジックをやっており、その時にマジックは全世界の人に平等に驚き、またちょっとした幸せを与えられることを知りました。それをITサービスにできたら、上記の目標に一歩近づけるかなと思います。 私の好きな言葉に、「無駄とユーモアが人を幸せにする」という言葉があります。例えば、カロリーが高いけど、美味しいケーキを食べたとき、またしょうもないジョークにも関わらず、なんか疲れが吹き飛んだ時とか、一見あまり価値のなさそうなことに人は幸せを感じ、それらが積み重なってその人の大きな幸せになっていくのだと強く感じます。もし自分が世界の人々を少しでも幸せにできたら、それだけで自分の生きた意味になるのかなと思います。

Cluexではエンジニアの方を募集しています！

エンジニアリングと同時にビジネスマンとして成長したい、スタートアップで働いてみたい、もうレガシーな環境で余計な苦労しをたくないといった方など、 興味がある方はご連絡下さい。 https://www.wantedly.com/projects/60136

初めまして、エンジニアの高橋です！

はじめまして。 Cluexでエンジニアをしています、高橋佳弥と申します。 今回は自己紹介の記事を書かせてもらいます。

実は昨年の12月にcluexにジョインしたのですが、ブログを書け書けと言われつつ そっぽ向いてひたすらコード書いていたらこのタイミングでの自己紹介となりました。

エンジニアとしての暦は今年で5年目くらいになります。今年で24歳になります。 もともと数学ができないので私文の大学に入ったのですが、それからphpとMySQLをメインとして独学で学び、 その後web系の言語を一通り使えるようになってからは、個人でお仕事をいただいたり、スタートアップで仕事をしたりしていました。 学校で習ったり、スクールで学んだりといったことが全くなかったので、常にぶっつけ本番で技術のキャッチアップをしていった感じです。

Cluexに入ったきっかけ

きっかけは、代表の大濱から連絡をもらって、「エンジニア足りないんだけど！」という一言から始まり、 結果としてそのまま入った感じなんですが、もともと代表の大濱と知り合いでして かつては共通の知人と3人で6畳一間に住んでいたこともありました。

でも知り合いだからと言って、おいそれと入社を決めるということってなかなか珍しいかと思います。 日本において創業された会社は、10年間のうちにそのほとんどが消えて無くなると言われてますが、 流れの早いweb業界において新しいサービス作ってそれをしっかりと伸ばしていくことって本当に難しいなと個人的には思っています。 とはいえ、その組織の人間がしっかりとした戦闘能力を身につけていれば、どんな事業でもしっかり伸ばしていくことができると思います。 Cluexはそういう意味では組織として大濱もそれ以外のメンバーにも惹かれるところがあり、そこで入社を決めました。

何をやっているのか

入社してからしばらくはRailsでの開発がメインでした。そもそも初めてRailsを触るのがここに入ってからだったんすが、あれやこれやバグ潰したり新しい機能作ったりしてるうちに気付いたら社内で講義をするようになっていました。個人的にはphpもう触りたくないってくらいにRailsは楽でいいなーと思ってます。

先月はインフラ関連のことをもっぱらやっていました。サーバーのリプレイスから始まり、チューニングしたり、生ログ解析の基盤を作ったりといった感じです。また追ってブログ記事にしようと思います。インフラはインフラでアプリケーションよりもさらに深いところで色々なことができるのでめっちゃ面白いなって思います。ホワイトハッカー目指して引き続き頑張ります。

そして今月からはIOSチームに移りました。 正しくは「立ち上げた」って感じなんですが、いよいよ社内でチームを分けて、それぞれwebとアプリ専業で開発を進めていくようになります。 それに伴い僕もIOSアプリの開発をメインに進めながら、たまにインフラ周りをいじったりしたいなと思います。

目まぐるしく色々とやることが日々変わっていって忙しい感じはありますが、 今まで伸びてるサービスの中で開発に携わることがなかったので、そういう意味では自分が開発してるサービスが伸びているのでめちゃめちゃ楽しいです。

今後やっていきたいこと

チーム全体としてさらに強くなっていきたいなと思ってます。 社内でよく言っているんですが、コードがかけるエンジニアならいくらでもいると思うんですね。 でも世の中にはその上をいく優秀だと言われるエンジニアがいて、そういう人たちと普通のエンジニアとの違いはなんなのかって最近よく考えています。

そもそも何を持って優秀とするかは意見が別れるところだと思うんですが、 技術的な知識が豊富であるとか、綺麗にコードがかけたり、 それを色々なところへアウトプットしていたり、 エンジニアとしてサービスをグロースさせることができたりなどといったことがあげられると思います。

さらに会社で働くエンジニアでいえば社内で用意されている開発環境や開発メンバーもとても影響すると思います。 他にも色々な要素があると思うんですが、エンジニアがエンジニアとして着実に力をつけていける環境づくりをしていきたいなと思っています。 もちろん事業としてもしっかり伸ばしていきます。

簡単ですが自己紹介でした！

Cluexではエンジニアの方を募集しています！

色々な言語を身につけていきたい、スタートアップで働いてみたい、もうレガシーな環境で余計な苦労したくないといった方など、 興味がある方はご連絡くださいませ。 https://www.wantedly.com/projects/60136

AWS Lambdaを使用して、AWS利用料金のお知らせをSlackに届くようにしてみた

AWS Lambda

AWS Lambdaを使用して、AWS利用料金のお知らせをSlackに届くようにしてみた

エンジニアの志村です。 先日AWS Summit Tokyo2016に2日間行ってきました。

今サミットではLambdaを用いたサーバレスアーキテクチャ、またKinesisを利用したリアルタイムストリーミング解析の話題が中心でした。 Lambdaは少々前から興味があったにも関わらず、実務で使用したことが無かったのでタイトルのようなものを実装してみました。 リクルートさんがやっていたのを真似て、今回は、Lambdaのcloudwatch-alarm-to-slack-pythonというBlueprintを使用し、Pythonにて実装しています。

サーバーワークスさんのブログを参考にさせて頂きました。 blog.serverworks.co.jp

ゴール

下記のような通知を、毎日朝10時にSlackに流すようにします。 f:id:cluex-developers:20160611112826p:plain

やること

下記のような流れで実装を進めていきます。

  1. Slack APIのIncoming Webhooksの設定
  2. IAMのKMSを用いてIncomig WebhooksのURLを暗号化
  3. cloudwatch-alarm-to-slack-pythonというBlueprintを使用し、Lambdaファンクションを作成
  4. Lambdaで作成したロールにCloudwatchに対する権限を付与
  5. Lambdaが起動するトリガーを設定

Slack APIのIncoming Webhooksの設定

ではSlackの設定から行いましょう。

  1. Slackのメニューから「App & Integrations」を選択します。 f:id:cluex-developers:20160611103351p:plain

  2. 下記のように「Incoming Webhooks」を入力し、選択します。 f:id:cluex-developers:20160611114126p:plain

  3. 自分の所属しているチームが表示されているので、該当チームの「Configure」を選択します。 f:id:cluex-developers:20160611103642p:plain

  4. 「Add Configration」を選択します。 f:id:cluex-developers:20160611103804p:plain

  5. 投稿したいチャンネルを選択します。 f:id:cluex-developers:20160611103908p:plain

  6. Webhook URLが必要になるので控えておきましょう。ついでにemojiも設定しちゃいましょう！（僕らはお金のemojiを設定しています） f:id:cluex-developers:20160611104319p:plain

IAMのKMSを用いてWebhook URLを暗号化する

上記で取得したURLですが、そのままLambda Functionに貼り付けて使用するのはセキュリティ上好ましくないですよね。 なのでKMSを用いて、暗号化した状態で使用しましょう。

  1. AWSコンソールからIAMを選択 f:id:cluex-developers:20160611104531p:plain

  2. 左下に「暗号化キー」という項目があるので選択

f:id:cluex-developers:20160611104802p:plain

  1. エイリアスを入力します。 f:id:cluex-developers:20160611104930p:plain

  2. キー管理アクセス許可の定義は環境やルールに従って決めて下さい。

  3. キーポリシーのプレビューで確認をし、「完了」を押す

  4. 下記コマンドを使用し、暗号化を行う（AWS CLIが必要になります。）

$ aws kms encrypt --key-id alias/先ほど設定したエイリアス --plaintext "先ほど取得したWebhook URL"

上記を実行すると、暗号化されたURLとARNというものが表示されます。こちらは Lambda Functionで使用するのでコピーしておきましょう。

cloudwatch-alarm-to-slack-pythonというBlueprintを使用し、Lambdaファンクションを作成

さて、いよいよLambdaの方に入っていきます！

  1. 「バージニア北部」リージョンを選択 f:id:cluex-developers:20160611105232p:plain

  2. AWSコンソールからLambdaを選択 f:id:cluex-developers:20160611105322p:plain

  3. Create Functionを選択 f:id:cluex-developers:20160611105458p:plain

  4. 「Select blueprint」という画面が出てくるので「cloudwatch-alarm-to-slack-python」というBlueprintを選択 f:id:cluex-developers:20160611105700p:plain

  5. Configure Event Sourcesはスキップ（後で設定します）

  6. Lambda Functionのページに飛びます。ENCRYPTED_URLには先ほど暗号化したURLを、SLACK_CHANNELにはIncoming Webhookで設定したチャンネルを入力しましょう。

最終的なコードは下記のようになりました。

# -*- coding: utf-8 -*-

from __future__ import print_function

import boto3
import json
import logging
import datetime

from base64 import b64decode
from urllib2 import Request, urlopen, URLError, HTTPError


ENCRYPTED_HOOK_URL = '上記で暗号化したURL'
SLACK_CHANNEL = 'Slackのチャンネル'  # Enter the Slack channel to send a message to

HOOK_URL = "https://" + boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED_HOOK_URL))['Plaintext']

logger = logging.getLogger()
logger.setLevel(logging.INFO)

client = boto3.client('cloudwatch')


def lambda_handler(event, context):
    logger.info("Event: " + str(event))

    startDate = datetime.datetime.today() - datetime.timedelta(days = 1)

    response = client.get_metric_statistics (
        MetricName = 'EstimatedCharges',
        Namespace  = 'AWS/Billing',
        Period     = 86400,
        StartTime  = startDate,
        EndTime    = datetime.datetime.today(),
        Statistics = ['Maximum'],
        Dimensions = [
            {
                'Name': 'Currency',
                'Value': 'USD'
            }
        ]
    )

    maximum = response['Datapoints'][0]['Maximum']
    date    = response['Datapoints'][0]['Timestamp'].strftime('%Y年%m月%d日')

    slack_message = {
        'channel': SLACK_CHANNEL,
        'text': "%sまでのAWSの料金は、$%sです。" % (date, maximum)
    }

    req = Request(HOOK_URL, json.dumps(slack_message))
    try:
        response = urlopen(req)
        response.read()
        logger.info("Message posted to %s", slack_message['channel'])
    except HTTPError as e:
        logger.error("Request failed: %d %s", e.code, e.reason)
    except URLError as e:
        logger.error("Server connection failed: %s", e.reason)

※ # -*- coding: utf-8 -*-を宣言してあげないと、encodingのエラーが出て、lambdaが正しく動作しないので注意して下さい。

  1. Name, Descriptionを入力　Runtimeは今回Python2.7を選択 f:id:cluex-developers:20160611111009p:plain

  2. Cloudwatchから情報を得る権限が必要なので、Roleから「Basic execution role」を選択 f:id:cluex-developers:20160611111100p:plain

  3. IAMロールは「新しいIAMロールを作成」　好きなロール名を入力し、「許可」を選択 f:id:cluex-developers:20160611110638p:plain

  4. 他の値はそのままで良いので「Next」を選択

  5. 内容を確認し、「Create Function」を押す

Lambdaで作成したロールにCloudwatchに対する権限を付与

先ほどLambda内で作成したロールに対し、Cloudwatchの情報を得ることが出来る権限を付与する必要があります。

  1. AWSコンソールからIAMを選択 f:id:cluex-developers:20160611104531p:plain

  2. 「ロール」を選択

  3. 先ほど作成したロールを選択する f:id:cluex-developers:20160611111430p:plain

  4. 「ポリシーのアタッチ」をクリックし、「CloudWatchReadOnlyAccess」をアタッチ f:id:cluex-developers:20160611111634p:plain

Lambdaが起動するトリガーを設定

さて、いよいよ最後です！

  1. AWSコンソールからLambdaを選択 f:id:cluex-developers:20160611105322p:plain

  2. 先ほど作成したFunctionを選択

  3. 「Event Sources」タブをクリックし、「Add event source」を選択 f:id:cluex-developers:20160611111950p:plain

  4. Event source typeの選択画面が出る　今回は時間指定でSlack通知を行いたいので「CloudWatch Events - Schedule」を選択 f:id:cluex-developers:20160611112212p:plain

  5. 「Rule name」には好きな名前を、「Schedule expression」にcron式を入力 今回「毎日朝10時に通知をする」ので下記のような式になります。 ※ UTCで設定を行う必要があるので注意して下さい。 f:id:cluex-developers:20160611112532p:plain

cron式については下記を参照して下さい。 docs.aws.amazon.com

こんな感じです。あっさりと出来ました！ 初めてLambdaを使用しましたが、様々なイベントを感知して、AWSのサービスを自由に動かすことが出来るので工夫次第でもっと大きなことが出来そうです！

エンジニア・ディレクター陣含めて合宿に行ってきました！（エンジニア編）

こんにちは。エンジニアの志村です。 小川くんがブログ書いてくれたように、先月、弊社設立初となる開発合宿に行ってきました。 エンジニア：3名, ディレクター：3名で日光に行ってきました！ 今回は開発編ということで、その模様と、具体的な内容、反省等を書いていきたいなと思います。

開発合宿開催への経緯

多くの企業が開発合宿に関するブログを書いているのを拝見し、度々合宿行きましょう！という話は出ていたのですが、皆の日程や移行タスク等の理由から中々開催出来ていませんでした。 そのような中で色々な企業のブログを読んでいく内に一回やっておくのもいいだろうという社長の鶴の一声で合宿開催が決定しました。

志村: そういえば合宿ってやるんですか？ 高橋: え、合宿行きたい！

大濱: 1回やっとくのもいいかもね。行きましょう！

こんな感じです。軽い。

合宿までの事前準備

今回の手配は清水ディレクターがほとんどやってくれました。 本当何から何まですみません…

宿

開発合宿で必要なものを考えると

  • 延長コード
  • Wi-Fi（安定していてなるべく高速）
  • 6人が利用しても十分な広さがある会議室
  • 何時でも使用出来る会議室

上記のような感じでしょうか。 上記の条件が揃っている宿は中々探すのが難しいので、色々な企業さんが使用している宿をピックアップして今回の宿に決めました。

スケジュール

合宿とは言え、遊んでいたのでは意味がありません。酒を飲みまくっても意味がありません。と何故か僕だけ大濱に念押しされたのできちんとタイムスケジュールを組みました。

概ね、下記のようなスケジュールを事前に立てました。 今回の合宿ですが、開発メインというよりも、ビジョンの再共有、また将来のキャリアパス等を考えたりと、コミュニケーション周りがメインになる合宿でした。

1日目

10:00 集合&出発（3時間程度で到着）
13:00 チェックイン
14:00 自由時間（5時間）
19:00 夕食
20:00 自由時間（4時間）

2日目

08:00 起床&飯
09:00 自由時間（3時間）
12:00 昼食
13:00 理念会議(6時間) 
19:00 夕食
20:00 UTAGE

3日目

08:00 起床&飯
11:00 チェックアウト&出発
15:00 東京着
16:00 オフィス業務

上記のスケジュールから開発に充てられる時間は下記のようになりました。

開発に充てられる時間

  • 1日目: 9時間
  • 2日目: 3時間
  • 合計: 12時間

と、開発合宿の中ではかなり時間が少ないですね。 というのも2日目の理念会議が今回のメインテーマになるからです。 会社として初の合宿なので、エンジニア・ディレクター双方にとって有用な合宿にしたいという理由でこのようなタイムスケジュールとなりました。

実際にやる内容

さて上記のように開発に充てられる時間は 12時間となりました。 この時間でやれることは結構限られてくるので、何をやるかは結構慎重に議論を重ねました。 今回の合宿において重要にしていたのは下記の3点です。

  1. 合宿中にやりきれる
  2. チーム一丸となって取り組める
  3. 改善した内容が見える化出来るもの

特に大切なのは1.かなと考えています。 というのも初の合宿なので、合宿中に何かを達成した！という感覚を皆に持ってもらいたかった為です。

テーマ決めですが、上記の条件を考慮したテーマをアドバイザーの露木さんから幾つか提示して頂きました。

テーマ案

  • Sentryのエラーをxxx%減らす
  • NewRelicのレスポンスタイムをxxx%早める
  • CoffeeScriptをES6化する
  • 開発環境をdockerにする
  • テストカバレッジをxxx%高める

上記のような案を出して頂きました。

この時点でのチームの課題はテストカバレッジでした。 今まで、旧サイトからの移行、またそれに伴う機能の拡充を急いだ結果、チーム全体としてテストに対する意識が低いのが前々から問題でした。 ちょこちょこは書いていたのですが、最低限のユニットテストのみでE2Eテストをほとんど書いていない状況…。 最近mamanokoも規模が大きくなってきており、目視だけで完全に動作を把握することが難しくなってきております。 その為、テストカバレッジのUPが急務でした。

ということで、 今回はテストカバレッジを95%に上げる！ というテーマに決定しました！

1日目

  • simplecovを使用し、現状どれくらいのテストカバレッジとなっているか調査。 → この時点で80％前後
  • 開発開始前に30分程度話し合い、どの部分を担当するか決める。その際に、自分が実装していない機能部分を割り当てることにしました。
  • テストごりごり書く。1日目は朝方5時まで3人で書き、どうにか92〜3%まで到達

f:id:cluex-developers:20160330215523j:plain

2日目

  • 95%もう少しだねと楽勝ムードが出てくる。
  • しかし、朝の時点で93%近くをウロウロ。
  • ここから上げるのがかなりキツかったです。テストの経験値が少なく皆悪戦苦闘…。
  • どうにか理念会議終了後に95%達成！！

f:id:cluex-developers:20160330220431p:plain

まとめ

上記のように紆余曲折ありながらも何とか、目標となる95%超を達成することが出来ました！ 現在でも97%前後をキープ出来ている状態です。

良かった点

  • 数値で目標設定出来るのが良かった
  • 合宿ならでは（？）のやってやるぞ感が楽しかった
  • たまには違うところでやると捗る
  • エンジニア同士は勿論だが、ディレクター陣とコミュニケーションを深くとれたのが非常に良かった
  • 割り込み等が無かったので集中して作業に取り組めた

問題点

  • 1日目飛ばしすぎて、2日目本当眠かった
  • 2泊3日は短かった。3泊出来るともっと出来ることが広がりそう
  • テストも良かったが、次回は新しい物をチームで作るというような取り組みも行いたい
  • 夕食時に酒飲むと眠気が半端なかったので次回は禁止でも良いかも…
  • 腰が…
  • 事前準備をもっとしておけばすぐに開発に取り掛かれた

エンジニア・ディレクター陣含めて合宿に行ってきました！in日光

こんにちは、人事兼ディレクターの小川です。

先日、社員・インターン生含めて6名で2泊3日の開発合宿に行って参りました！ f:id:cluex-developers:20160312215204j:plain たまたまネットサーフィンをしていた時に見つけた、某インターネット関連の大手企業さんにあやかって日光にあるペンション「はじめのいっぽ」さんにお邪魔してきました！その時の合宿の様子をレポートにしてみました。

なぜいったのか

今回の開発合宿では、ただコードを書くというものではなく、エンジニア・ディレクター陣含めて「理念会議」を行うことがメインでした。個人の課題、会社の課題をエンジニア・ディレクターの双方向から話しあい、お互いの思いや考えを共有しよう、というものです。

「理念会議」とは？

メンバーが将来目指すビジョン、今現在抱えている思いなどを共有する場を「理念会議」と名づけています。日頃話せないようなことを赤裸々に語ることにより、チーム全体の士気を高める場となっています。

さらに、この開発合宿の各チームの目標は以下の通りです。

  • ディレクター「サービスの改善点を洗いだす・洗いだした改善案をタスクまで落としこむ」
  • エンジニア「テストカバレッジ95%以上」

それでは、合宿の様子を振り返ってみたいと思います！

1日目

  • 10時:出発

f:id:cluex-developers:20160312191557j:plain

みんな朝から元気ですね。「社長の顔が凄いことになってる・・」初日の元気は合宿最終日まで持つのでしょうか？

  • 13時:チェックイン

f:id:cluex-developers:20160312191910j:plain

大手製薬会社の営業マンからエンジニアに転身した志村さん。日頃はムードメーカーとして場を盛り上げてくださっています！

  • 14時:作業タイム

f:id:cluex-developers:20160312190751j:plain

「あれ？黄昏れてる？」

ペンション内は、静かな環境で落ち着いて仕事に取り組むことができます。

1日目は、ディレクター陣は「よりユーザーにとって価値のあるサービスにするためには？」をテーマにして会議を行いました。より会議を質の高いものにするため、スマートフォンのUI/UXにテーマをセグメントしました。数値を元にページ単位のミクロ分析とサイト全体のマクロ分析の2つから徹底的に問題点を洗い出しました。洗い出されたデータを元に必要となる機能のみ具体的なタスクに落とし込んでいきました。

  • 20時:夕食

f:id:cluex-developers:20160312191252j:plain

一日目は「すき焼き」でした。ペンションの方の粋な図らいで大量のお肉を用意していただきました！

f:id:cluex-developers:20160312213443j:plain

メンバーと鍋を囲んで美味しく頂きました！

美味しいお肉ってボリューム感凄いんですよね。食べ過ぎました。。この後の仕事はかなり眠かったです。

  • 21時:作業タイム

f:id:cluex-developers:20160312192130j:plain

エンジニア陣は朝4時までテストカバレッジ95%を達成するべく必死に格闘していました。

2日目

  • 9時:作業タイム

f:id:cluex-developers:20160312213129j:plain

変な人がいる・・。 あまり寝ていないので、テンションがハイになっているみたいです。

ディレクターは各々が担当する業務を進めていました。エンジニア陣は引き続きテストカバレッジ95%に向けて黙々とパソコンに向かっています。

  • 14時:「理念会議」

f:id:cluex-developers:20160312213237j:plain

2日目の午後は、いよいよ理念会議です。今回の開発合宿の一番のテーマですね。

理念会議で行われた議題は主に2つです。

  1. 自己分析(個人の今の課題と、将来の目標)
  2. 会社の現状課題を話し合う

①自己分析(個人の今の課題と、将来の目標)

事前に準備してきた個人の課題や将来の目標をみんなの前で発表。その後でメンバーから発表した内容のフィードバックをもらいます。フィードバック中に普段では聞けない会話がいくつも出てきました。特に幼少期にどんな人間だったのか、という話になった時はメンバーの意外な一面を聞くことができました。

②の会社の現状課題を話し合う

今後の経営戦略などの話も出ましたが、会社の衛生面強化など日頃の一面を見直すキッカケの場になりました。それぞれが思う問題点を一度に聞くことができ、今後の仕事への取り組みがより一層引き締りました！

  • 20時:食事

f:id:cluex-developers:20160312213423j:plain

2日目は、「炭火焼き」でした。みんな満腹状態の中、社長は「食事を残すものは経営者になれん」という思いから残りの食材を食べつくしました。この後、強烈な眠気が襲ってきたのは言うまでもないですね。

3日目

  • 9時:仕事

f:id:cluex-developers:20160312213527j:plain

「おっ、イケメンポーズ？」

いよいよ合宿最終日です。ディレクターもエンジニアもラストスパートを掛けます！

  • 12時:チェックアウト

f:id:cluex-developers:20160312214355j:plain

3日間濃い時間を過ごすことができました。ちょっとお疲れ気味の方も・・？

f:id:cluex-developers:20160312213614j:plain

合宿の最後に日光東照宮へ観光にきました。

f:id:cluex-developers:20160312213625j:plain

翌日に筋肉痛の人間も・・

f:id:cluex-developers:20160312213721j:plain 記念写真

「見ざる、言わざる、聞かざる」のつもりがシャッタータイミングが合わず聞かざるだけに・・

終わってみて・・

f:id:cluex-developers:20160312214812j:plain

落ち着いた環境の中、会議などもスムーズに進んでいき充実した3日間でした。温泉に浸かって仕事以外の会話をすることもとてもよかったですね。温泉の時の写真もあるのですが、自主規制とさせていただきます。今回の合宿の目的であった「理念会議」はチームとしてより結束力を高めることになったのではないか、と感じています。日頃から業務の会話や雑談はされていると思いますが、中々自分の将来についての思いや考えを話すことは少ないのではないでしょうか？是非みなさまも「理念会議」、試してみてください。

長期の休みにはまた開発合宿を行いたいと思います。

以上です。 最後まで読んでいただき、ありがとうございました！

良かった点

  • 静かな環境で集中して仕事ができた
  • ペンションの方がおすすめの温泉を教えてくれたり、とてもあたたかみを感じれる
  • 環境が変わってリフレッシュしながら仕事に取り組めた
  • 料理が美味しい(炭火焼きおすすめです！)
  • アットホームな雰囲気でチーム全体として結束力が高まる
  • 会議のテーマを事前に決めたいたこと

問題点

  • 近くにコンビニがないので、車を使わないと移動ができない
  • 長時間イスに座っていると、腰が痛くなる
  • 2泊3日だとちょっと短い
  • 平常の業務を行ってしまい、達成感が少なかった(ディレクター陣)

次回に向けて

  • 1週間ほど時間をとって行いたい
  • 合宿が終わった翌日を休日にしたい
  • 近くにコンビニがあるところ
  • 昼に温泉に入らない
  • チームとして達成感のある作業があるといいかも