初めてのシステムと日記

システムも日記も初めてです。

Netatmo Weather Station + Hubot + Chatwork で室内環境を通知する仕組みを作った

背景

オフィスで仕事中、夕方ぐらいになると頭がぼぉーっとしたり、空気悪いと感じる事がしばしばありました。なのでオフィスの室温や湿度、その他もろもろ計れる、ついでに業務で利用しているChatworkで通知されるといいなぁと常々思っていました。

そこで調べた所、下記の記事が参考になったのでこれのChatwork版を試してみました。 qiita.com

 

購入

Netatmo Weather Station

室内・室外の温度や湿度、CO2濃度などを測定でき、その結果はクラウド上に蓄積されます。蓄積された結果はアプリやPC、API経由で確認する事ができる代物です。

お値段はそれなりにするので、購入する際には各者への相談が必須です。

 

Hubot

Hubot自体やインストール方法についてはググればすぐ分かると思うので割愛します。

私はnpm install yo generator-hubotで必要なツールをインストールし、yo hubotでぱぱっとbotを作成しました。

 

Hubot + Chatwork

github.com

hubot-chatworkというアダプターがすでにあるのでこれをインストールします。

$ cd /projects/to/hubot
$ npm i hubot-chatwork --save

Chatwork APIを叩く事になるため、環境変数にChatworkのAPI情報を記述します。

私はなるべく環境変数は1ファイルで管理したかったため、bin/hubotに記述しました。

#!/bin/sh

set -e

npm install
export PATH="node_modules/.bin:node_modules/hubot/node_modules/.bin:$PATH"

// この3行を追記
export HUBOT_CHATWORK_TOKEN=xxxxxx // APIアクセストークン
export HUBOT_CHATWORK_ROOMS=xxxxxx // 通知先ルームID
export HUBOT_CHATWORK_API_RATE=800 // 1時間当たりのAPIリクエスト数

exec node_modules/.bin/hubot --name "bot" "$@"

HUBOT_CHATWORK_API_RATEに関しては、Chatwork APIに5分あたり100回までのリクエストの制限があるため、1200以下の数値にするのが妥当なようです。

あとはbot名を指定してコマンドを実行すればOKです。

$ bin/hubot -a chatwork -n bot

 

Netatmo

www.npmjs.com

Netatmo APIを利用するためのパッケージが公式にあるため、これを利用します。

$ npm install netatmo

また、APIを利用するにあたり以下の情報が必要になります。

  • client_id
  • client_secret
  • username
  • password
    • Netatmoのアカウント情報
  • device_id

device_idはアプリケーションから確認が出来なかったため、直接APIを叩いて確認しました。

var netatmo = require('netatmo');
 
var auth = {
  "client_id":     "xxxxxx",
  "client_secret": "xxxxxx",
  "username":      "xxxxx",
  "password":      "xxxxx",
};

var api = new netatmo(auth);
api.getDevicelist(function(err, devices, modules) {
  console.log(devices);
});

レスポンス内の_idがdevice_idになります。

 

Hubot + Netatmo + Chatwork

  • Chatworkの特定のワードをトリガーにして処理を行うHubotスクリプトを作成・実行
  • Netatmo APIから室内環境情報を取得
  • 取得した情報をChatworkに通知

上記を行うためのHubotのスクリプトが以下になります。

曜日の日本語表記をしたかったためmomentを利用してます、これも必要であればnpmでインストールしてください。

https://github.com/bossato/hubot/blob/master/scripts/netatmo.coffee

Netatmo = require('netatmo')
moment  = require('moment')

config =
  client_id:     process.env.NETATMO_CILIENT_ID
  client_secret: process.env.NETATMO_CILIENT_SECRET
  username:      process.env.NETATMO_USERNAME
  password:      process.env.NETATMO_PASSWORD

types = [
  "Temperature"
  "CO2"
  "Humidity"
  "Pressure"
  "Noise"
]

options =
  device_id: process.env.NETATMO_DEVICE_ID
  scale:     "max"
  date_end:  "last"
  type:      types

moment.lang 'ja', {
  weekdays:      ["日曜日", "月曜日", "火曜日", "水曜日", "木曜日", "金曜日", "土曜日"],
  weekdaysShort: ["日", "月", "火", "水", "木", "金", "土"]
}

module.exports = (robot) ->
  netatmo_api = undefined

  robot.respond /(CO2|二酸化炭素|空気悪い|換気)/i, (msg) ->
    unless netatmo_api
      netatmo_api = new Netatmo config

    netatmo_api.getMeasure options, (err, measure) ->
      response    = measure[0]['value'][0]
      temperature = response[0]
      co2         = response[1]
      humidity    = response[2]
      pressure    = response[3]
      noise       = response[4]

      measure_time   = moment.unix(measure[0]['beg_time']).format("YYYY年MM月DD日(ddd) HH:mm:ss ")
      message = "#{measure_time}に測定した室内環境(dance)\n"
      message += "[info]"
      message += "温度:#{temperature}度\n"
      message += "湿度:#{humidity}%\n"
      message += "CO2:#{co2}ppm\n"
      message += "気圧:#{pressure}hPa\n"
      message += "騒音:#{noise}dB\n"
      message += "[/info]"
      if co2 > 1000
        message += "\n空気が悪いので換気しましょう!オフィスのCO2濃度は1000ppmが目安です!"

      return msg.send message

process.envでは設定した環境変数を呼ぶ事が可能です。ここではbin/hubotでNetatmoAPIに必要な情報を追記したのでそれを呼び出しています。

robot.respondbotを特定のワードで呼んだら処理が実行されるようにしています。あとはNetatmoAPI経由で取得した室内環境情報を整形し、Chatworkに通知しています。

試してみる

f:id:boss_sato:20160201113820p:plain

(dance)

 

試して思った事

  • 頭がぼぉーっとするのはCO2濃度のせいではなく単純に暑かっただけOrz
  • 空気がこもる感覚?はさすがに計測できそうにない
  • Netatmo Weather Stationには室外用もセットでついてくるけどほぼ使わない、むしろ室内用のみのセットを販売してほしい
  • 週間天気なども詳細に計測されているのでそれの通知もあると面白そう
  • オフィス導入するにはそれなりのパワーが必要(お値段的に

オフィス環境の改善はデスクやチェア、お菓子などが思いつきますが、こういう環境改善も重要です、健康に関わる事ですし。

受託開発でのプロダクティビティエンジニアに挑戦してみた

昨年夏頃から長期的なプロジェクトにアサインされ、そこでプロダクティビティエンジニアを意識して動いてみました。クライアント、他社さんなど社内外でのやり取りが多い中で、受託開発でプロダクティビティエンジニアとしてどう取り組んでみたか書いてみます。

プロダクティビティエンジニアとは

上記のブログで注目され、「方向>開発フロー>スキル」という順番での考え方をするエンジニアがプロダクティビティエンジニアになります。

エンジニアが効率的に実装できる環境を整えるエンジニア、と私は捉えています。

目指した背景

私のここ最近の意識として以下の2つがあります。

  • プロジェクトを効率的にまわして利益を出す
  • エンジニアが成長できる機会を作る

今までだとサーバサイドやフロントエンドのエンジニアとして実装がメインでした。ただ、実装フェーズ時には、

  • すでに方向や開発フローがほぼ固まっている
  • 上記を方針変更するのはコストがかかる
  • 自分の気になる技術を試しづらい

などからプロジェクトの効率化、エンジニアの成長の機会を増やすという実現をするには手が出しにくい状況でした。

その中で先ほどのブログを拝見し、またここ最近は業務的にも実装だけではなく要件定義や仕様調整をする事が増えてきたため、良い機会なのでプロダクティビティエンジニアを目指してみたという背景になります。

クライアント・他社との調整

今回のプロジェクトの座組は以下になります。受託開発の中では関わる会社さんが多く、特に技術面でのやり取りが多い座組でした。

  • クライアント
    • 私の会社:サーバサイド・フロントエンド
    • A社:インフラ
    • B社:デザイン・フロントエンド
    • C社:API提供

私が行った事は以下になります。

  • 要件定義フェーズから打ち合わせに参加
  • どういう事をやりたいかクライアントとの共有
  • 上記に対する技術的な判断やより良い方向の提案(主にコストや実装し易さの面で
  • ここはこの会社さんにお願いした方がよいなどのタスク調整
  • 他社とのAPI設計やデザインマージを考慮したHTMLの対応依頼などの調整

毎週定例という形で打ち合わせに参加していたため、コミュニケーションコストはそれなりにかかっています。ただ、要件定義や仕様調整 = 方向を決める段階で技術的な判断やタスク調整をする事で、その後のフロー検討や実装に生き、その後の無駄な調整コストを省く事が出来ました。ここにコストをかけたのは総合的に良かったと思います、クライアントからも評価頂けました。

また、色んな会社さんと関わると「こういうやり方もあるんだ。」と自分の考えにないやり方(方針、技術どちらも)に遭遇する事もたまにあり、開発フローの選択肢が広がったのは大きな収穫でした。

プロジェクトマネジャー(PM)・ディレクター(DR)との役割

エンジニアはPMやDRとの仕様調整をする機会はよくあると思いますが、なるべく実装に集中できる環境を実装を担当するエンジニアに提供したかったため、調整事項は私がなるべく受ける形で対応しました。

ここ最近、要件定義からエンジニアが参加するならPM、DRいらなくね?という話をたまに聞きます。これはプロジェクトによりけりかなと私は思います。

例えばキャンペーンサイトなどの1〜2ヶ月程度で終わるプロジェクトの場合、関わるメンバーが少ないため、こういう場合は下手にメンバー間のコミュニケーションコストを増やすよりも、自分で要件定義から実装まで一通り関わった方がコスト割けるので効率的だなと思います。(その代わり自分への責任やタスク量は必然的に多くなりますが

今回の場合、長期的なプロジェクト、関わる会社やメンバーが多かったため、明確に境界を設けたわけではないですが、以下のような担当になってたかなと思います。

  • 自分(エンジニア)
    • 他社との技術的調整
    • エンジニアとのプロジェクト運用の調整
      • GitHubのブランチ運用
      • GitHubのPRの粒度やWIP、レビューの方針について
      • RedmineGitHubのチケット運用
    • エンジニアとの実装方針の調整
      • コーディング規約
      • 設計方針(共通化できるのここだよねとか
      • テスト方針(ここの処理は複雑だから厚めにテスト書こうとか - PM、DRとの仕様調整
  • PM、DR
    • クライアント・他社との仕様調整
    • エンジニアとの仕様調整(主に私と

境界分けてしまうと変に意識してしまうため、ある程度緩く境界をもっておのおの調整するスタイルはやりやすさと効率さを感じました。また、人に依存してしまうという事も緩くする事で緩和できたかなと思います、特定の人への依存化はリスクが大きくプロジェクトとして一番やってはいけない事なので。

クライアントの要望と実装難易度とのバランス

今回、1つの反省点としてクライアントの要望を聞きすぎたために、一部機能で実装の難易度、処理の負荷が高い点がありました。

  • CMSで登録してサイト側に表示する機能
  • 必須ではなくかつチェックボックスを多用する複雑なフォーム項目がいくつもあった
    • この時点でDB設計が難しいものになる気配は感じた
  • 取得する際も各項目に対して複数の条件を指定せざる得なくなった
    • LEFT JOIN多用とWHERE句がカオスになる気配は感じた

その結果、

SELECT
    *
FROM
    table_1
LEFT JOIN
    table_2 ON table_1.id = table_2.id
・
・ // 5回ぐらいLEFT JOINした・・・
・
WHERE
    table_1.name = "test"
    AND
        table_2.age BETWEEN 1 AND 10
    AND
     ・
     ・ // WHEREが数十個できた・・・
     ・

私がこのSQLを作った時は人生で一番最悪になるSQL作ったと思いました。(汗

例えば必須項目にする、チェックボックスではなくラジオボタンにする、項目の組み合わせ条件をある程度絞るなどの仕様で調整していれば、もっとより良い実装には出来たと思います。

クライアントの要望と実装難易度はたまに反する場合があり、こういった場合はきちんと設計や実装を考慮して早めの方向転換、代替案を調整すべきだったというのが一番の反省点です。(クライアントの要望聞くと喜んでくれるので何とも悩ましいですが

テスト品質

プロジェクトによってはテスト品質報告書なるものを提出する場合があります。今回のプロジェクトでも提出しましたが、そこで課題が1つありました。フロントエンドのテスト品質についてです。

サーバサイドの場合は今まで以下の方針をテスト品質としていました。

  • サーバサイド処理全体のコード量算出
  • テストコード全体のコード量とテストケース数算出
  • 上記算出値からテスト密度を算出しそれをテスト品質とした

今回の場合、フロントエンドの処理が大半を占めていましたが、

  • フロントエンドのテストフレームワークは導入できてない
  • API通信、DOM操作など処理が多岐に渡るのでサーバサイドのようなテスト密度が計測しづらい

といった経緯もあり何をもって品質とすべきかと頭を悩ませました。

今回の場合は以下の方針で行い、テスト密度が低い部分は人によるテストで補っているという形で報告しました。

  • JSファイル全体のコード量算出
  • 主な処理がAPI通信だったのでAPI通信1つに対し以下のテストケースを算出
    • 正常系処理テスト1つ
    • 常系処理テスト3つ(レスポンスなし、404、500)
      • コードとしてはないが実装段階でエンジニアが行っていると想定した
  • 上記算出値からテスト密度を算出しそれをテスト品質とした

これでなんとか通りましたが、フロントエンドがメインになるのは要件定義フェーズで分かっていたため、早めの段階からテストフレームワークを導入していれば、実装とテスト両方の品質、作業効率がより良いものになったなと思いました。そして、ここはまさにプロダクティビティエンジニアがやるべき事だと感じました。

査定評価がしづらい

話は変わって思いっきりお金の話になりますが、査定も1つ課題かなと思います。

私は一応開発部エンジニアなので査定基準としては以下になります。

  • エンジニアスキル
    • サーバサイド
    • フロントエンド
    • インフラ etc
  • プロジェクト貢献度
  • その他

ただ、プロダクティビティエンジニアの場合、技術よりも方向や開発フローがメインになるため、エンジニアスキルが評価の軸になると査定ではなかなか評価が上がらない可能性があります。

イメージ的にはエンジニアとPM、DRの中間に近いポジションではあるので、それに対する評価基準をどうするかというのは今後議論が必要な点と感じました。(お金はたくさん欲しいので

まとめ

今回、プロダクティビティエンジニアを意識して取り組んでみました。私が行った事がプロダクティビティエンジニアになるのかというのは、正直やってみて何とも分からなかった、というのが正直な所です。最近になって出てきた職種ですし、言語化するのもなかなか難しいため、しばらくは手探り状態な感じで引き続き精進したいと考えてます。

ただ、今までとの一番の違いとしては、クライアント、他社さん、PM、DR、エンジニアと今回は多くの人との調整やコミュニケーションがありました。その中で自分にない考えややり方が数多くあり、そこは収穫でモチベーションにもつながりました。

そして何より皆で一丸となってものを作っている感覚を感じ、リリース時の達成感は今までで一番強かったです。

もしプロダクティビティエンジニアに興味がある方がこの記事を読んで参考になれれば幸いです。

「新卒エンジニア研修の改善の軌跡」という発表内容でLTした

毎年恒例の社内開発忘年会のLT大会にて、昨年から行っていた新卒エンジニア研修の改善の軌跡について発表しました。

発表経緯

昨年から行っていた新卒エンジニア研修の内容を外部公開した所、外部の方々に評価頂き、Gunosy砲も喰らったので(これ本当にアクセス数怖い)、今年はこのネタしかないかなという所でした。

それから、今まで研修を受けてきた新卒・中途エンジニアの子達にどうやって改善してきたかを知ってほしいのと、今後のエンジニア研修についてメッセージを伝えたかったというのもあります。

(昨年の開発忘年会にでなかったのでさすがに今年はやらなくてはという思いが一番ですが)

軌跡

2009年4月、私が新卒エンジニアで研修を受けて以来、まったく放置されていた状態でした。改善着手前の以下を見れば放置され具合が分かるかと思います。

  • バージョン管理がsvn
  • 物理サーバを一からセットアップする
  • サーバサイドの研修しかない
  • 使っているフレームワークが携帯電話時代ので古い

最終的には以下のように改修しました。

  • バージョン管理はGit + GitHubに移行
  • サーバはAWS
  • フロントエンド + サーバサイドの研修
  • フレームワークはトレンドのLaravelを採用

これ以外にも振り返りレビューの導入、OJTの強化などありますが、これらは一度に全て出来たわけではなく、研修を何回も繰り返し試行錯誤しながら辿り着いたものです。このあたりの内容はスライドに詳しく書いています。

以前の記事は結果しか書いていないため、凄くスムーズに改善できた印象があるかもですが、最初は失敗の連続でした。GitHubリポジトリが壊されたり、OJTのフォローが上手く出来ずキャリアステップに影響がでたり、技術ばかりで人にフォーカスした研修が出来ていなかったり。ただ、失敗と挑戦を繰り返す事でようやくまともな研修になったため、常に改善する意識は持ち続けて取り組むべきだと思います、何事もですが。

一番伝えたい事

研修を受けた人が、今度は研修を教える側になる流れを作るため、私は一旦研修からは外れました。ですが、まだまだ改善、調整したい事はあります。

  • 研修担当の研修コスト削減
    • PRレビュー、振り返りレビューなどのコストをどう削減するか
  • カリキュラムの充実化
    • 新しい技術をどういうフローでカリキュラムに取り入れるべきか
  • フルオンライン研修

私が今回のエンジニア研修の見直しで感じた事は、「技術の進化に合わせて研修も進化すべき」、という事です。

私が研修を受けた頃に比べ、WEBを取り巻く環境や技術はだいぶ変わりました。

エンジニアは技術に貪欲なため、新しい技術や注目されている技術があれば自分で試してみる職種です。これはエンジニアとして必要な事だと思いますが、それを新卒エンジニアや、中途で入ってきてまだ会社環境に慣れてないエンジニアに求めるのは酷だと思います。であればどうするべきか、そのために研修、OJTというものがあるはずです。

エンジニア研修は作ったら終わりではないです。技術の進化に合わせ、研修も常に進化し、新しいエンジニアを成長させるきっかけにならなければいけないと思います。そのためには、私が考えた研修が1、2年後には古いとなるようにならなければいけないと思います。

新しいものを取り込み、上手く研修を受ける側と教える側でサイクルを作れるようになれば、研修を任せられるのも楽しいものになると思います。

 

これで本年の開発ブログ記事は終わりになります。来年もマイペースに更新しますのでよろしくお願いします。

ISUCON予選2日目に初参加してきた #isucon

http://isucon.net/

ISUCONとは
お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。
過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。

ということでISUCON予選2日目に会社の後輩2人とチームを組んで初参加しました。

事前準備と決め毎

  • アーキテクチャ
  • 担当
    • DB・サーバサイドは私
    • インフラ、フロントエンド周りは後輩達
  • バージョン管理
    • もちろんGit
    • bitbucketのプライベートリポジトリ用意
    • チームアカウントで共通リポジトリ作成
    • 個人アカウントで上記フォークして作業を行う
    • 作業する際には課題を作成しログを残す
    • PRは必要に応じてレビューする
  • 本番反映フロー
    • 面倒なので本番環境で直接git pull origin masterする
  • コミュニケーション
    • オフラインで集まるので基本は口頭
    • 重要な事はChatworkで残す

当日開始前

  • 作業環境
    • 会社の会議室借りる
    • MBA + 縦型ディスプレイでのディアルディスプレイ
    • iPad Airも持ってきたけど結局使わなかった
    • プロジェクターと共有PCでやるべき事を常に表示
    • お菓子大量購入

開始してから12:00くらいまで

  • サーバ構築
    • 運営からAWSの$25クーポン貰えたので以下構成でインスタンス作成
      • 本番環境
      • 各自開発環境3台
  • リポジトリ構築
    • 本番環境の構築を先にしてもらい、bitbucketのチームリポジトリにpush
    • 各自の開発環境が準備出来たら、forkしたリポジトリをcloneして作業
  • スコア出し
    • ひとまず本番環境からデフォルト状態で叩いて1300くらい
  • ソースレビュー
    • プロジェクターにコード映しながら対応方針考える
    • 対応方針
      • Nginx化
      • 外部ファイルのキャッシュ化
      • SQLチューニング
      • MySQLのmy.cnf設定
    • (今思えば、DBのデータ件数が20万件くらいの時点でDB周りのチューニングを優先度低くすればよかった・・
  • 16:00に一旦対応した物でスコアだそうと決めて作業開始
  • ここまでは比較的順調

12:00から16:00くらいまで

  • sloq_query設置
    • long_query_time=1で設定したけど初期化のバルクインサートくらいしかのらない・・
    • long_query_time=0にしてmysqldumpslowコマンドで解析すべきだったと後に反省
  • my.cnf設定
    • 最大接続数周りを400にしたら200くらいスコアあがった
    • innodb周りのメモリを潤沢に振ったがほぼ効果でず、むしろスコア下がった
    • top見るとメモリよりCPUが喰っていたのであまり効果でない
  • Nginx化
    • 詳細な設定は後輩が対応したので把握してない
    • これでスコアが2000くらいになった
  • add index
    • ALTER TABLE login_log ADD INDEX (user_id, succeeded, ip);
    • 後輩が複合INDEXを貼った
    • これでスコアが4000くらいになった
  • フロントエンド
    • 後輩と2人でソース見た
    • JSもCSSもほぼ使ってなかったのでチューニングする所なし
    • 今回の課題はフロントエンド殺し・・

16:00時点でのスコア

  • 4030くらい
  • 他のチームがだいたい10000オーバーしていて何してるんだと疑問

16:00から17:30くらい

  • my.cnf設定引き続き
    • sort_buffer_sizeなどをチューニング
    • 200くらい上がったが思ってた以上のスコアでない・・
  • Nginxでのexpires、gzip対応
    • ヘルプに入ったがNginx初めて触ったので結局対応出来ず・・
  • アプリ
    • 複数回呼び出している処理を整理
  • この時点でベンチマークでworkload指定する事を知って発狂した

17:30時点でのスコア

  • 4200くらい
  • 万策尽きてきた
  • 会社から他に2チーム出場してるので物理的妨害しようとしたけど失格になりたくないと諦め

18:00まで

  • workloadを調整しながらベストなスコア算出
  • 最終的には4300くらい

良かった事

  • bitbucketのプライベートリポジトリ便利
    • 無料でほぼGitHub変わらず作業出来た
  • MBA + 縦型ディスプレイでの開発
    • 縦型ディスプレイの前にMBA置いて縦長なディアルディスプレイにしてみた
    • MBA:チャットや調査専用
    • 縦型ディスプレイ:ターミナル専用
    • 横置きでのディアルディスプレイより見る範囲が狭くなったので作業し易かった

f:id:boss_sato:20140929144414j:plain

※写真は実際の作業環境とは違うけどイメージ

反省点

  • Nginxのチューニング
    • 今回の課題はアプリチューニングよりいかに接続させないかが重要
    • Nginxをもっと勉強していればもっとスコア伸びた
  • 1つの事に固執過ぎた
    • 役割分担を決めた事で変にそれに固執過ぎてしまった
    • 早い段階で諦めて別の手段を考えるべきだった
  • アーキテクチャの選定
    • Redisなど、他のミドルウェアの知識が乏しく乗り換えができなかった
  • ネットワーク
  • SSHの設定
    • SSHもよく切れたので事前にクライアント側で設定すべきだった

まとめ

もともと軽いノリで参加したので順位に拘りはなかったですが、ここまで差をつけられるとさすがに悔しいものがあります。ただ、エンジニアで集まってわいわいしながら開発するのはとても楽しかったですね。次回はもっとミドルウェアや判断力を身につけてリベンジしたいと思います。

運営、参加者の皆様、お疲れ様でした。

「出張このべん:猫カフェ×Ejectユーザー会、奇跡のコラボハンズオン!ConoHa byGMO」に参加してきた

出張このべん:猫カフェ×Ejectユーザー会、奇跡のコラボハンズオン!ConoHa byGMO

猫カフェで勉強会、Raspberry Piが触れる、自宅のすぐ近く(歩いて3分くらい)、という事で参加してきました。

会場の様子

神奈川県川崎市にある、里親募集型猫カフェ、雑貨、ペットシッター 猫式

会場は猫式さん。最近プライベートで何回か行ってましたが、店員さんが非常に優しく雰囲気良く、猫達もたくさんいてとても元気です。休日でもお客さんは比較的少なめなので、ゆっくり猫と戯れたい方にはオススメです。(一般的な猫カフェって人が多いし、店員さんもちょっと冷たい印象があるので)

会場の様子は、

f:id:boss_sato:20140927200113j:plain

CD-ROMドライブに座ってる・・・

 

f:id:boss_sato:20140927200122j:plain

開始の拍手に隣にいた子猫がビックリする・・・

猫まっしぐら餌付けシステム

構成

ConoHa VPS + Raspberry Pi + Eject工作(今回はCR-ROMドライブと手作り餌付け箱)

  • ConoHa VPS:Eject実行用のWeb API
  • Raspberry Pi:Web APIの実行を取得してEjectするボーリング
  • Eject工作:上記からCD-ROMドライブをEjectして餌をだす

ConoHa VPS

  • Apacheを立ち上げ
  • ブラウザからボタンをクリックしてカウンターをアップ

Raspberry Pi

  • VPSをボーリング
  • カウンターを参照してアップしていればEject

Eject工作

  • こういう感じで餌付け箱を作成
  • CD-ROMドライブをEjectすると餌付け箱の蓋が開いて餌をだす
  • 再度Ejectして戻すと輪ゴムの力を借りて蓋が閉じて餌が止まる

ちょっとConoHa VPSでデフォルトがポート22しか空いてない等、トラブルがもろもろありましたが無事完成しました。

f:id:boss_sato:20140927200133j:plain

 

そして実装出来た頃には隣の子猫はお休みしてました。

f:id:boss_sato:20140927200129j:plain

 

肉球触りたい放題。

f:id:boss_sato:20140927200230j:plain

まとめ

Raspberry Pi、初めて触りましたがやはり小さいですね。最初見た時は使いこなせるか不安でしたが、一般的なサーバ同様に使えました。小ささを利用したEject工作はなかなか面白かったです。crontab仕込んだり、今回のようにWeb API連携すれば色々工作出来そうでwktkしました。

あと、一般的なハンズオンはみんなもくもくと作業するのでちょっと重たい空気ですが、今回は猫達が実装中も猫同士で遊んでたり、PCの上にのって邪魔してきたりなど、和やかな雰囲気でした。最近、ペットを飼う会社が増えてきつつあるのも納得出来ました。

今回はちょっと変わった形式の勉強会でしたが、こういう形式も増えていくといいかなと思います。そして明日はISUCON、初参加してきます。

新卒エンジニア研修の取り組みやカリキュラム

昨年夏頃から会社で開発部の研修担当になり、カリキュラムの全面見直し、開発研修の位置付けや運用方法などを考え、そして実践を今現在やっています。最近、開発研修やWEBエンジニアの教育についての記事が増えてきたなと感じたので私のブログでも書こうと思います。

背景

私の会社では新卒エンジニアが5年ぶりに入社しました。(ちなみに5年前の新卒エンジニアが私です。
つまり5年間、新卒エンジニアの開発研修をしてなかった事になります。
開発研修を担当するにあたり、まずは5年前の開発研修を確認しました。

  • サーバを一からセットアップ → AWSなどのクラウドがある今必要性を感じない
  • サーバサイド(Apache+PHP+MySQL)がメイン → サーバサイドだけでは今は通用しない
  • フロントエンドはHTMLで簡単なフォームを作るくらい → 今はCSS、JSは触れるくらいじゃないと
  • カリキュラムは社内Wikiで管理 → Markdown使いたいし課題などが管理しづらい

ということで案の定、現在のWEBエンジニアとしては物足りない、そしてメンテナンス性が低いものでした。
また、最近感じている事として以下の要素もWEBエンジニアで重要度が増しています。

  • 周りとのコミュニケーション
  • コスト・進捗管理
  • 要は技術以外の部分

アジャイルの普及もあり、単に設計・実装するだけではWEBエンジニアとしてはもう通用しないため、ここも開発研修に取り入れる必要がありました。

そのため、開発研修の全面的な改修をしていきました。

 

プロジェクトとのニーズの違いと開発研修の目的

改修にあたり、一番考えたのが開発研修後のプロジェクトアサイン。いざ新卒エンジニアをプロジェクトにアサインすると、よく担当のWEBエンジニアからこういう声を聞きます。

  • 必要な事を全然教えられてないじゃん
  • 技術の水準が低すぎる
  • プロジェクトやっても成長してくれないよ
  • 教えるのコストかかるんだけど etc

開発研修を終了しただけではまだ一人前のWEBエンジニアとは言えないため、こういう声がでるのは仕方のない事だと感じてます。(高望みしすぎだし面倒見てくれよとも思いますが)

そのため、私は開発研修が終わった段階では以下のWEBエンジニアになっている事を目的としました。

  • 業務や技術領域の変化に対応出来る
    • 基本的な所を幅広く底上げすることで変化に対応させる
    • 成長段階で特定の技術に拘らないようにする
  • 主体的に継続的に技術を取得出来る
    • 分からなかったら自分で調べて成長させる
    • 新しい技術を取り入れる姿勢を身に付けて成長させる
  • 技術以外(見積、コミュニケーションなど)も一定の水準に満たす
    • 自分でタスクやコストを管理する事で自発性を高める
    • プロジェクトで自ら他職種とコミュニケーションが出来るようにする

この目的はid:ryopekoさんがデブサミ2014で発表した新卒エンジニア研修の目的そのままです。自走するエンジニアというのは名言だと思いました。

私が思うに、どう頑張っても開発研修だけでは即戦力になるWEBエンジニアを育てるのは無理です。むしろプロジェクトを通して成長する方が重要だと思います。そのため、開発研修ではプロジェクトで自発的に成長するための土台作りをし、プロジェクトアサイン後にさらに成長させようと考えました。

また、開発研修が終わった後は基本的に研修担当のプロジェクトにアサインするようにしました。要はOJTまで含めて開発研修という形です。実装フロー、タスク・コスト管理、コミュニケーションの仕方などは、開発研修より他職種の方達と絡めるプロジェクトで経験した方が分かり易く、また新卒エンジニアをずっと見た人がOJTをやった方が何かと互いにやりやすいかなと思ったからです。

 

カリキュラムの改修

カリキュラムはほぼ一から改修しました。詳細はGitHubにて公開しています。

私が改修したポイントとしては以下です。

  • フロントエンド、サーバサイドを幅広くやらす
    • 新卒エンジニアに全体的な基礎知識を身に付けさせる
    • 新卒エンジニアに興味のある分野を見つけさせる
  • 課題図書を要所要所で読ませる
    • 内容によっては下手に社内で教えるより専門家の本に任せた方が分かり易い
    • 新卒エンジニアに技術書を読む文化を体験してもらう
    • 研修担当のコスト削減
  • 課題毎に工数を見積もってもらう
    • 新卒エンジニアにコスト意識を持ってもらう
    • 研修担当は速く課題を終わらせる事が目的ではないときちんとフォローする
  • 課題やソースなど全てGitHubにて管理
    • Markdownで書き易い
    • どこからでも閲覧、編集が可能
    • 研修の進捗が管理し易い

新卒エンジニア視点から見ると、なるべく幅広く基礎知識を身に付けさせ、また課題図書や工数見積など、WEBエンジニアの文化を体験して自発的に成長できる土台を作るようにしてみました。

カリキュラムや課題に関しては全てGitHubで管理するようにしました。研修担当からすると、普段使い慣れているGitHubの方がやりやすいですし、研修担当以外のWEBエンジニアもメンテナンスしやすく、コストも抑えられました。

 

開発研修の進め方

開発研修の進め方は以下の流れでやりました。

■事前準備(研修担当)

  • 新卒エンジニア1人毎にGitHubのアカウントと研修用のGitHubリポジトリを作成
  • 課題は上記リポジトリのIssueで全て管理
  • Chatworkで開発研修用チャットを作成
    • メンバーは必要最低限にする
    • 関係ないメンバーを入れると余計なレビューやコメントが入って課題のゴールがぶれる

■開発研修

  • 課題着手前に工数を時間単位で見積(新卒エンジニア)
  • 課題を進める(新卒エンジニア)
    • 調査系、または実装系でGitを学ぶ前まではIssueのコメント
    • Gitを学んだ後の実装系はPRを送る
  • 課題が終わったらChatworkで研修担当にTo(新卒エンジニア)
  • レビューをしFBがあればコメント、問題なければクローズ or マージ(研修担当)
  • レビュー中は次の課題をやり、前課題のFBがあればそちらを後でやる(新卒エンジニア)
  • 基本的にはMarkdownで全て書いてもらう(新卒エンジニア)

実際やってみて、全てGitHubでやって良かったなととても感じました。

  • レビューがとてもしやすい
    • コードの差分
    • Markdownの見やすさ
    • 実際のプロジェクトと同じように出来る
  • どこからでも確認、レビューが出来る
  • 開発研修を通して新卒エンジニアがGit、GitHub、ブランチ運用に慣れる
  • contributionsなどで状況がデータ・グラフ化されて把握し易い

また、研修用のGitHubリポジトリはあえてpublicにしました。この背景として、GitHubではたまにPRやIssueでリテラシーの低いコメントやネタ画像をちょくちょく見かけます(OpenTouryoProjectのこのPRとかはまさにリテラシーの低い例です)。人によってはこれは不快に感じますし、仕事としてやる以上無駄なコストです。恥ずかしくないWEBエンジニアになるためにも、リテラシーを意識させるためにあえてpublicにし、そこに関してもきちんと学ばさせる事が出来ました。

ただ、publicにしているため公開してはいけない情報(サーバ情報、社内特有の情報など)は書かないように意識させるのと、研修担当も入念にチェックする必要があります。そこはちょっと想定外のコストでしたが、リテラシーの意識を高めさせれた事を考えれば安いコストかなと思います。

 

工数見積のデータ化

今回、工数見積を新卒エンジニアにやってもらいましたが、その見積時間と実稼働時間をデータ化しました。このデータはGoogleドライブのスプレッドシートで管理し、研修担当が閲覧、編集出来るようにしています。

f:id:boss_sato:20140426200316p:plain

データ化すると現状の進み具合や成長具合等が分かり易くなりますし、この後に説明する振り返りレビューでも資料として貴重なものなりました。

 

振り返りレビュー

開発研修中、振り返りレビューというプチ面談のようなものを設けました。これもid:ryopekoさんの話を聞いてとても良さそうと思ったため取り入れてみました。

■概要

  • 週1で開催
  • 1人30分〜1時間
  • 研修担当と1on1で対面で行う
  • ミーティングルームなど周りに人がいない状況でやる
  • 研修担当が複数人いる場合は交代制
  • 振り返りレビューの内容もデータ化して研修担当内で共有
    • 今回はRedmineのチケットで管理
    • これも閲覧出来るメンバーは必要最低限に
  • 振り返りレビュー後は研修担当を集めてレビュー内容を共有
    • 開発研修の理解度、改善点などを共有してどう開発研修を進めるか考える

■振り返りレビューの内容

  • 今週の開発研修の振り返り
    • 課題のIssue、PRを1個1個確認
    • ちゃんと理解しているか「この単語の意味分かる?」など聞いて確認
    • こういったコマンドもある、load averageの適正値など、現場で学んだ知識を共有
    • 工数見積のデータを見せてきちんと出来ていると自信を付けさせる
  • 研修担当から見た新卒エンジニアの良かった点
    • どんなに細かい事でも良い点を共有
    • 開発研修以外の事でも拾う(遅刻していない、元気がよいなど
    • 良い所はどんどん伸びるよう工夫する
  • 研修担当から見た新卒エンジニアの改善点
    • これも細かい事でも改善点を共有(細か過ぎると逆にうざいので適度に
    • 新卒エンジニアが納得してないようであればちゃんとなぜ改善しなければいけないのか説明
      • 言葉だけではなくデータ化したものを見せる
      • 言葉で説明するにも具体例などを引き合いに出して説明する
      • 漠然とした説明はほぼ納得しないので(当たり前)ちゃんと研修担当は考える
    • 一気に改善させずゆっくり長い目で改善
  • 今までの振り返りレビューの改善点の見直し
    • 改善出来たかどうか確認する
    • 改善出来なかった場合は理由を聞いてみる
    • 改善されるまで何度も振り返って徐々に良くする
  • 新卒エンジニアからの今週の良かった事、質問、疑問点など
    • どういった所が成長し、どういった所が悪かったか自分で考えさせフォローする
    • 開発研修以外の不安な事や疑問な事も拾ってあげる
    • 開発研修をもっとこうした方がよいなどの研修担当への逆レビューもしてもらう
  • 雑談
    • 会社慣れた?とか1人暮らし大丈夫?みたいな
    • 雑談の中でも色々聞けてこういう子なんだなーと理解しやすくなる
    • 研修担当は雑談を入れる事で場を和ませる

この振り返りレビューも実践してとても良かったです。

  • 振り返る事で新卒エンジニアがきちんと理解しているかの確認が出来る
  • 新卒エンジニア自身の復習にもなる
  • 良い点をや改善点を明確にする事で新卒エンジニアの成長のきっかけになる
  • 新卒エンジニアから開発研修の改善点をタイムリーに聞けるので開発研修を改善し易い
  • 開発研修以外の事も定期的に相談出来る環境が作れた

新卒エンジニアは開発研修の進み具合や理解度、自分が本当にWEBエンジニアとしてやっていけるかなど心配事が多く、また社会人生活もなかなか慣れないなど最初は不安な事が多いです。そういった事を少しずつ解決していき、そこから成長するきっかけを作る意味ではこの振り返りレビューはとても価値のあるものでした。1on1で気軽に話せる環境はとても重要です。

改善点・反省点

順調かと思った開発研修ですが、もちろん改善・反省すべき点がありました。

  • 基本研修が終わってから開発研修をすべき
    • ここで言う基本研修はビジネスマナーや全職種で必要な事を教える研修の事
    • 今回の研修は午前:基本研修、午後:開発研修という形でいつの間にか決められてしまった
    • 基本研修でまだ学んでない事(工数見積、ツール等)を開発研修側で教えるケースが多々あった
    • 新卒エンジニアからしても同じ事を2度学ぶ無駄が発生した
    • 開発研修だけではなく会社全体の研修も把握する事でより良い研修になるはず
  • Git、GitHubを早い段階で学ばせるべき
    • カリキュラムでは簡単なHTMLファイルを作ってもらった後にGit・GitHubを学ぶ流れにした
    • HTMLファイルのレビュー段階で斧を投げる必要がでてきた
      • 元々は中途者向けに作ったカリキュラムを改善したのでハードルが高すぎた
    • GitHubのIssueのコメントだとレビューしんどい・・・
    • 今回はカリキュラムを急遽変更し先にGit、GitHubをやってもらった
    • 早い段階でバージョン管理を学ばせる事で研修担当のレビューコスト削減と新卒エンジニアの振り返り易さに繋がるはず
  • 想定よりも研修担当のコストがかかる
    • 当初は最大でも1日の1/3くらいのコストになると想定
    • 実際は工数管理、振り返りレビューなどもあり1/3以上かかっていた
    • 新卒エンジニアの質問になるべくタイムリーに答えたいため、自分のメインプロジェクトに集中しにくい状況だった
    • 開発研修中は研修担当はプロジェクトから外れる、もしくはレビュワーを増やす等するべき
  • 社員との交流の機会が少なかった
    • 開発研修中は研修担当以外のWEBエンジニアは研修内容を見ないよう制限した
      • メンバーが多くなると余計なレビューやコメントなどで開発研修がぶれる
      • ただそれによって新卒エンジニアと他WEBエンジニアの交流機会を減らしてしまった
    • 新卒エンジニアの休憩時間が社員と合わない
      • 基本研修で時間割が決まっていた事もあり、休憩時間を固定せざるえなかった
    • 定期的に新卒含めたランチ会など開いて交流の場を設ける事で機会を増やした

社員との交流に関しては振り返りレビューで新卒エンジニアからもあがりましたし、私もどうしようかなーと悩んでいた事でした。早くキャッチアップし改善すればもっと楽しい感じに出来たかなと一番反省しています。そういうキャッチアップをする機会としても振り返りレビューと会社・職種間との調整はするべきですね。

まとめ

開発研修の準備にはそれなりの期間を費やしてしまいましたが、私自身は上手く改善でき開発研修の土台が少なくとも出来たと手応えを感じています。また、新卒エンジニアや研修担当からもGitHubのコードレビューや振り返りレビューでの会話などが楽しいと聞けたので良い開発研修になったかなと思います。(本音かどうかは分からないですがw

もし開発研修を行う機会があれば、以下の3つを取り入れる事をオススメします。やりやすさ、楽しさが新卒エンジニア、研修担当共々とても良くなると思います。

 

  • GitHubでやる
  • データ化出来る事はデータ化する
  • 振り返りレビューを取り入れる

 

この記事が研修担当の方々の参考になれれば幸いです。

GitHub Kaigiに参加してきた #githubkaigi

GitHub Kaigi http://githubkaigi.org/

今日、サイバーエージェントさんで行われたGitHub Kaigiに参加してきました。その発表資料と内容のメモ書きになります。

 

@naoyaさん 「Hello, Github Kaigi」

  • GitHub Kaigiを開催した経緯
    • GitHubが浸透してきたので頃合い
  • 1000人くらいの事前アンケート結果
    • GitHubを使い始めたのはいつから
      • 2013年以降がほぼ
    • Pubilicリポジトリはどれくらい持っている
      • 5-10個ぐらいがほぼ
    • PRを受けた事がある
      • 40%弱
    • PRを送った事がある
      • 50%くらい
    • Privateリポジトリを持っている
      • 26%
    • GHEを使っている
      • 28%
    • Atomを使っている
      • 30%

 

@hirocasterさんGithub実践入門 ─ Pull Request による開発の変革 (仮)」

発表資料:GitHubKaigi Keynote

  • GitHubを利用した開発の世界を知る
    • ここでいう世界とは業務、仕事でGitHubがあるかないかの世界
    • GitHubの世界へようこそ
      • PRを利用した開発
        • 対話
        • フィードバッグ
        • コードレビュー
        • テスト
        • マージ
      • よくある世界
        • なんとなく変数名をつける
        • この変素名、適切じゃない気がする
        • とりあえず機能を完成させる
        • あとで適切な名前を思いついたら変更する
        • 「あとで」は一生こない
        • 他の人に目にも触れずに本番環境で稼働
      • GitHubのある世界
        • なんとなく変数名をつける
        • この変素名、適切じゃない気がする
        • とりあえず機能を完成させる
        • このことをGitHubに書いておく
        • 他の開発者がレビュー
        • 良い変数名 + α をフィードバッグ
        • コードに反映
    • これが2つの世界の差
      • 習慣(見る、読む、見られる、読まれる)
      • 機会(修正、拡張、学習)
      • 品質(2 eyes < over 4 eyes)
      • 心理(不安、安心、自信)
  • GitHubを利用|活用する違いを知る
    • 世界の中の差もある
      • GitHub
        • コードを管理する道具:使っているだけ
        • コードの価値を高める道具:活用している
      • PR
        • 差分を入れる:使っているだけ
        • 対話、設計、改善:活用している
      • コードレビュー
        • する、してもらう:活用している
    • 指摘 = 簡単、提案 = 難しい -コードをより良くすること
    • GitHubを導入すると
      • コードをレビューする
      • 行動を起こすキッカケをつくることができる
      • 良い所も悪い所も見れる = 現実
  • GitHub != 目的
    • GitHubの先にある物を獲得しなければいけない
    • 開発効率?品質?
    • ビジネスの成功?ソフトウェアの向上?

 

@shibayu36さんはてなブログチームの開発フローとGitHub

発表資料:はてなブログチームの開発フローとGitHub

  • はてなブログチームについて
    • はてなブログを開発
    • 5エンジニア、2デザイナー
    • 月に
      • 170 PR
      • 1281 commits
      • 45 releases
    • GHEで運営
      • 開発速度を保てている
      • GitHubでの開発フローの改善
    • 開発の流れ
      • Issueを登録
      • branch作成
        • master
        • develop
        • feature branch
      • 開発、レビュー
  • 開発フローの課題とその解決
    • タスク管理
      • 以前
        • Redmine(タスク管理)
        • GitHub(コードレビュー)
          • 開発者が両ツールを見る必要がある
          • コードとの連携も上手くいかない
          • 開発者の効率があがらない
      • GitHubをメインにしてみた
        • Issueとコードの連携
          • 開発者の効率はアップ
        • Issuesには優先度、締切などの仕組み少ない
        • 誰が何をやっているかが分からない
          • マネージャがチームの俯瞰を出来ない
      • GitHub + カンバン
        • チームの重要なもの、進行中などの管理はカンバン
        • Issue
          • 全てのタスク管理
        • カンバン
          • Issueの中で重要なものだけ追加
          • 朝会で確認
      • GitHubとタスク管理
        • Issuesをメインで開発者の効率化
        • カンバンで重要なものを管理
        • スクラムまでいかないゆるいタスク管理
    • レビュー
      • 以前
        • 個別にPRを送る
        • 気が向いたらPRを探してレビュー
        • PRの状態が分からない(のでレビューをためらう)
          • レビュー依頼中?
          • レビュー後の修正中?
          • レビュー終わってる?
        • レビューが消化されずPRの量がたまる
        • ベテランだけがレビューし続けるはめに
      • 解決案
        • レビュー状態ラベル
          • PRにラベル付け
          • レビュー依頼
          • レビュー中
          • レビュー完了
        • レビュータイム
          • ランチ後14:00
          • レビュー依頼をレビューする
          • IRC botで通知
    • リリース
      • 流れ
        • PRがどんどんマージされてどこかでリリース
      • デプロイ自体はコマンド一発(capstrano)
      • リリースに必要なもの
        • リリースして良いかの確認
        • 検証環境で最終確認
        • デプロイコマンドでデプロイ
      • 自動化が出来てない
        • マネージャ確認せずにリリース
          • 何がリリースされるか抜けかあった
        • 新人がリリースできない
      • デプロイ以外のサポートが出来ないか
        • リリース用のPR手順書を作成
          • developからmasterへのマージをリリースPR
          • リリース内容
          • リリース後のチェック内容
          • コマンド一発で作業出来る仕組みを作った
          • https://github.com/motemen/git-pr-release

 

@amatsudaさんOSSGitHub (仮)」

発表資料:OSS と GitHub

 

@cobyismさん 「How Github Works」

発表資料:How GitHub Works (GitHub Kaigi, Tokyo, 2014)

  • GitHubの中の人の仕事の仕方
  • 60%がリモートで仕事している
  • 一番重要なのは幸せを感じる事
    • 働きたいと思う企業を自分たちで構築する事
    • その他で起きる事は全て副作用
    • 幸せを持続するにはモチベーション
  • モチベーションの要素
    • 外発的意欲
      • お金
      • 食事
      • 家など
    • 内発的意欲
      • 柔軟性
      • 自主性
      • 透明性
    • 内発的意欲が幸せに重要
  • 信頼が必要
    • 信頼出来る人を雇う必要
    • 才能が全てではない
  • 自分にあった場所で自分の時間で働く
    • 必要な時に休暇を取る
    • リモート作業にも価値はある
    • リモートがデフォルトの働き方
  • 柔軟性は家族を持つ人には最高
  • リモートで作業する事も最高の経験である必要がある
    • 発想の転換が必要 = 行動の変化を必要
    • 全ての企業でリモートが上手くいくわけではない
    • リモート作業は未来である
  • 使用しているツール
  • 直接会う機会
    • 全社会議
    • 製品グループ会議
    • チーム会議
    • 新入社員研修
  • 必要とする信頼関係を築く
  • 働き方が非同期でも休み時間はとってもいい
  • 反復が成功への鍵
  • 上手く行くものは時間で変化する
  • Everything should have an URL

 

@inaoさんGitHubで雑誌・書籍を作る」

発表資料:GitHubで
雑誌・書籍を作る

  • 何を作っているか
  • どんな人と作っているか
    • 一流のエンジニアの人達
  • どのように作っているか
    • GitHubで原稿管理とやりとり
    • md2inaoで原稿テキストの変換
      • Markdownで書かれたテキストをinDesign形式に変換
    • Adobe inDesignで紙面レイアウト
  • GitHubをどう使っているか
    • ブランチモデル
      • 作業者がWIPなPRを送る
    • コミット
      • 特集1個で500くらい
      • 見出し単位でコミット
      • 意図を伝えたい変更はピンポイントでコミット
    • FB方法 ーPRの確認時にはGitHub上でコメント
      • テキスト上での校正はテキスト中にkakikomi
  • GitHubで何が変わったか
    • 進捗状況が見える化された
    • Issue/PRによりメールを使わなくなった
    • コミットメッセージで変更意図を伝え易くなった
    • 思い切った変更の提案が行い易くなった
  • 背景にある考え
    • 雑誌・書籍作りはソフトウェア開発に近づけた方がうまくいく
      • 著者さんのワークフローに近いから
      • 雑誌や書籍もソフトウェアだから
    • GitHubによる常時共有、バージョン課題管理
    • Markdownという書き慣れた記法

 

@nathansoboさんAtom, the Programmable Text Editor」

発表資料:Atom – GitHub Kaigi_jp

 

@yuku-tさん 「入門書には載ってない Git & GitHub Tips」

発表資料:入門書には載ってない Git & GitHub Tips

 

GitHubの働き方は本当に素晴らしいと思いました。リモート作業による柔軟性を持続しつつ、直接会う機会も作る、人にフォーカスしたモチベーションは羨ましい限りです。

あと、@inaoさんGitHubで雑誌・書籍を作るも興味深い内容でした。GitHubはどうしてもエンジニア、最近はデザイナーのツールというイメージでしたが、雑誌や書籍というソフトウェアでも通用し既存の問題を解決出来る仕組みは素晴らしいですね。こういう形で非エンジニアな方々にも浸透していくと面白いかなと思いました。