千葉市生涯学習センターでschooを利用してきた

千葉市生涯学習センターでschooを利用してきたので、レポート書きます。
結論から言うと、自分のPC,自分のアカウントでschooの録画授業を受けられて、かなり良いという感想です。
最近敷地内にドトールが出店して、コーヒーブレイクもできるようになったので、千葉市民は活用してみるといいと思います。

schooとは

  • IT系を中心とした明日から仕事に使えるスキルが身につく学習動画を提供」しているWebサービス(サイトから引用)
  • ユーザ区分は3種類。
    • 無料の「オープン学生」
    • 月額980円の「プレミアム学生」
    • 月額1980円の「プレミアムプラス学生」
  • この文章書いてる人はオープン学生でございます。
  • 授業は2種類。
    • 生放送
    • 録画授業
  • 1授業は60分とか120分とかで、複数回の授業で1講座が構成されていたりする。ここら辺は講座によるっぽい。
  • オープン学生は生放送は見放題、録画授業はチケット1枚につき1授業受けられる。チケットは1か月に1枚もらえるとかそんな感じだった気がする。
  • ニコニコ動画のプレミアム会員になるとニコ生のタイムシフト視聴ができるようになるとか、そんなのに近いイメージ。

千葉市生涯学習センターとは

千葉市生涯学習センターでのschoo利用

受付

受付は地下1階なので、とりあえず地下1階に行く。建物の1階には「schooを利用したい人は地下1階まで」的な貼り紙はないので、ここ覚えておいてください。
schooのポスターは貼ってあるんですけどね。なんだかな。。。
受付に行ってschoo利用したい旨伝えて身分証見せると、利用方法を説明してくれます。
ここでちょっと驚いたんですが、なんと生涯学習センターでは、自分のノートPCを持ち込んで,自分のアカウントを使ってschooを受講できるそうです。
千葉市生涯学習センターのプレスには「生涯学習センター地下1階「マルチメディア体験ブース」に設置してあるパソコンから」とあったので、手ぶらで行ったのですが、自分のノートPC使えるとは。これでかいですよね。いいですよね。
で、手ぶらで行った私はどうしたかというと、貸し出してもらったiPad Proでschooを利用しました。iPad Pro使ったの初めてですよ。でけぇよiPad Pro。まさかこんなタイミングで使う機会が訪れるとは。ちゃんとキーボードといい感じのヘッドホンも貸し出してくれました。

利用場所

利用場所は受付近くのブラウジングカフェって名前のエリアのみということでした。
ブラウジングカフェは4人掛けテーブル×2、カウンター席7席くらいの空間で、WIFI, 電源がありました。ありがたや〜。
平日の午後行ったら、ブラウジングカフェの利用者は自分入れて4人でした。休日は満席になったりするのかな?わからん。 あとどうでもいいけど、椅子が長時間は座れねえなコレって感じの椅子でした。

schoo利用

自分のアカウントでログインすると、普段「オープン学生」と表示されているところに「ビジネスプラン」と表示されていて、普通に録画授業が好きなだけ受講できました。
生涯学習センター用のアカウント作るみたいな作業が一切不要で、普段使っているのと同じ感じで、録画授業を受講できるのはすごい良かったです。

まとめ

千葉市生涯学習センターでschooを利用してきました。今回は自分のノートPC持って行かなかったので,貸し出してもらったiPad Proを使いましたが、それでも自分のアカウントを使って、いつもと同じように録画授業を受講できるのはすごい良かったです。
お役所の提供するサービスだから、どうせ使いづらいんでしょって思って期待しないで行ったんですがね。いい意味で予想を裏切られました。千葉市民で良かったって思いましたね。次回は自分のノートPC持っていこうと思います。

Microservices Meetup vol.2参加レポート

2016年8月9日、株式会社FiNCで開催されたMicroservices Meetup vol.2に参加してきた。
Microservicesってバズワードになっているわりに、これまで実践している人の話って聞いたことがなかったのだけれど、この勉強会では実践している人たちの話をたっぷり聴けて、本当に勉強になった。参加してよかった。
当日のメモを公開する。

「マイクロサービスとSREの役割」by 鈴木さん@kenjiszk (株式会社FiNC)

  • マネージャー。

What is Microservices?

What is SRE?

  • Googleを発端として、インフラの人が名乗りだした。
  • 新規にやること以外はこの部署がやりますよ、みたいなイメージ。
  • SREが独立しがち。

Microservices x SRE

  • サーバの種類が多い
  • Microserviceは増える
  • SREネックになるのでは?
  • Microserviceにすると、Railsとか一個一個対応しなくちゃいけなくて辛い。
  • 1マイクロサービスに1SRE張るのも現実的じゃないしなー。

対策案

  • 業務開発チームに任せてみる

SRE育ててみた

  • 注意すべきは、セキュリティなど、SREの本質的な部分はSREで守らないといけない。

「SRECon 2016 Wrap Up」by 坂本さん@takus (スマートニュース株式会社)

  • druid.io

SmartNews

  • バイルに特化
  • スマニューには半年に1回海外の空気に触れさせる制度がある。

SRECon

  • Freedom & Responsibility
  • Netflixでは開発者に、サービスぶっ壊せるくらいの権限を与えている。
  • ぶっ壊されたらどうするの?=>開発者は変なツール使わない。 SREが作った、安全なツールがいけているから、何も言わなくてもそれ使う。

社内PaaS作った

  • 社内の課題を見つける
  • プロトタイプを作る
  • 最初の顧客を見つける

障害に現実感を持ってもらう

  • めったに起きないことに時間を割きにくい
  • 計画的にぶっ壊す。
  • Chaos Engineering
  • この辺り、うまくゲーミフィケーションの設定しようぜ。 - 障害発生時にbotにコメントしておくと、botがレポートにまとめてくれる。

SRE should be a Enabler, SRE should not be a Servant

「マイクロにしすぎた結果がこれだよ!」by 榎本さん@mosa_siru (株式会社Gunosy)

KDDIと連携して作ったニュースパスの話

  • コンポーネント分けて、権限ガチガチに分けた。
  • セキュリティグループ見れば

  • OpsWorksはラーメントッピング感覚でサーバ作れる

  • 全体構成が複雑

  • 開発が遅い
  • 障害時の調査範囲が広い ボトルネックの把握が難しい
  • オーバーヘッドが大きい 余ったリソースを融通しあえない
  • 共通部分がしんどい
  • 内部APIのIF変更が辛い モノリシックの辛さをレイヤーを変えて味わっているような感覚。。。
  • 統合管理画面がやばい

良かったこと

  • 影響範囲は局所化できた。
  • メンバー追加のハードルが低い。
  • 今のところデメリット多いけど、人が増えたら再評価されるかも。

「Microservicesの実際と対策」by 大谷さん@shot6 (株式会社 ファーストリテイリング)

  • AWSで働いてたら、作りたくなった。
  • ヘキサゴン
  • Queue, Database, Notification, File, REST, View
  • AWSの機能フル活用している
  • マルチクラウドは辛いので、どっちかに寄せたいという気持ちがある。
  • APIはSwagger。
  • elasticsearch。logstashをbeatsに置き換えたい。
  • MESOSPHERE。
  • KONG。
  • マイクロサービスは技術重要じゃない、組織、体制の話。
  • 並行開発しないなら効果出ない。
  • マイクロサービスは要件に十分な複雑さがない限りペイしない。
  • モノリシックの方が絶対的に安い。
  • CRUDAPI全部作る、いやいややりすぎでしょ、はあるある。
  • ZIPKIN。Twitterが作っているツールがある。
  • Microservicesのテスト難しい。

ウェルネスタイム

  • HIIT(High- intensity interval training)
  • タバタトレーニング
  • 椅子にお尻をちょんとつけるスクワットを20秒やって、10秒休む。これを8セット。計4分。
  • これで1時間の有酸素運動と同じ効果。

「より良いAPIを作るために」by 相川さん@awakia (ウォンテッドリー株式会社)

  • 綺麗なAPI速習会
  • Wontedlyは生まれた時からHerokuだった。
  • WebはAngular, Reactでできるだけシングルページアプリにして、API通信する。
  • BFF(Backends for Frontends)
  • SEOの問題で、Nodeがいいと思っている。
  • FacebookAPI力入れている。
  • eager loadみたいな形で作っている。
  • APIのバージョンはヘッダに入れる。
  • apig。みんながCRUDAPI全部作るの!?と言っていたところ、DBのスキーマ情報から作るようにした。

まとめ

Infrastructure as CodeやImmutable Infrastructureは、基本実践したほうがメリットがあるので、頑張って実践しよう、という感じで盛り上がっていたと思う。
それに比べるとMicroservicesを実践する/しないをしっかり見極めないと、メリット出なそうと思った。
理解しきれていない部分も多かったが、Microservices実践している人の話を聞けて、Microservicesが単なるバズワードから現実感のあるものになった気がして、本当にモチベーション上がった。 togetherはここ

CSVで吐かれるリソース情報をelasticsearch, kibanaでグラフ化する

CSVで吐かれるリソース情報を週次でグラフ化する必要があったんだけど、毎週Excel開いてグラフ作るのはだるいので、ログ可視化周りでデファクトスタンダードになっているっぽいelasticsearch, kibanaでグラフ化することにした。

手順は次の通り。

  1. elasticsearch, kibana環境を準備する
  2. リソース情報CSVをBulk API対応のJSONに変換する
  3. リソース情報JSONをelasticsearchにバルクインポートする
  4. kibanaでインポート結果を確認する
  5. kibanaでグラフを作成する

1. elasticsearch, kibana環境を準備する

環境構築は切り出してこっちに書いた。

2. リソース情報CSVをBulk API対応のJSONに変換する

今回、リソース情報CSVとして適当に作成したダミーファイルは以下の通り 日付はelasticsearchのDate型にあわせないといけない。 最初作ったダミーファイルの日付は「DD-MM-YYYY」の形式だったんだけど、これだとelasticsearchが日付と認識してくれなかった。

# memory.csv
Date,memory
2015-01-01,10
2015-01-02,11
2015-01-03,12
2015-01-04,13
2015-01-05,14
2015-01-06,15
2015-01-07,16
2015-01-08,17
2015-01-09,18
2015-01-10,19
2015-01-11,20
2015-01-12,21
2015-01-13,22
2015-01-14,23
2015-01-15,24
2015-01-16,25
2015-01-17,26
2015-01-18,27
2015-01-19,28
2015-01-20,29
2015-01-21,30
2015-01-22,31
2015-01-23,32
2015-01-24,33
2015-01-25,34
2015-01-26,35
2015-01-27,36
2015-01-28,37
2015-01-29,38
2015-01-30,39
2015-01-31,40
2015-02-01,41
2015-02-02,42
2015-02-03,43
2015-02-04,44
2015-02-05,45
2015-02-06,46
2015-02-07,46
2015-02-08,46
2015-02-09,46
2015-02-10,46
2015-02-11,46
2015-02-12,46
2015-02-13,46
2015-02-14,46
2015-02-15,46
2015-02-16,46
2015-02-17,46
2015-02-18,46
2015-02-19,46
2015-02-20,46
2015-02-21,46
2015-02-22,46
2015-02-23,46
2015-02-24,46
2015-02-25,46
2015-02-26,46
2015-02-27,46
2015-02-28,46
2015-03-01,46
2015-03-02,46
2015-03-03,46
2015-03-04,46
2015-03-05,46
2015-03-06,46
2015-03-07,46
2015-03-08,46
2015-03-09,46
2015-03-10,46
2015-03-11,46
2015-03-12,46
2015-03-13,46
2015-03-14,46
2015-03-15,46
2015-03-16,46
2015-03-17,46
2015-03-18,46
2015-03-19,46
2015-03-20,46
2015-03-21,46
2015-03-22,46
2015-03-23,46
2015-03-24,46
2015-03-25,46
2015-03-26,46
2015-03-27,46
2015-03-28,46
2015-03-29,46
2015-03-30,46
2015-03-31,46
2015-04-01,46

これをBulk API対応のJSONに変換する。 ポイントは、普通に変換するだけだと数値が文字列に変換されてしまう(""がついちゃう)ので、数値だったら数値として変換する必要があるということ。 Qiitaに掲載のスクリプトを参考に、以下の通りスクリプトを作成した。

参考

以下のコマンドを実行してmemory.csvをmemory.jsonに変換する。

cat memory.csv | ./csv2esjson.rb > memory.json

こんな感じになるはず。memoryの値に""がないので、数値として変換されているのがわかる。

"index":{"_index":"test","_type":"type1","_id":"bc171ba7-cffa-4b47-a763-1071c758e59b"}}
{"Date":"2015-01-01","memory":10}
{"index":{"_index":"test","_type":"type1","_id":"ddb85e8e-4933-4579-8aff-05073e14f201"}}
{"Date":"2015-01-02","memory":11}
{"index":{"_index":"test","_type":"type1","_id":"c9053988-cffe-47af-9bd0-82ee664dd047"}}
{"Date":"2015-01-03","memory":12}

3. リソース情報JSONをelasticsearchにバルクインポートする

curl -s -XPOST localhost:9200/_bulk --data-binary @memory.json

4. kibanaでインポート結果を確認する

http://localhost:5601にアクセスすると「Configure an index pattern」という画面になる。
「Index contains time-based events」にチェックした上で、「Index name or pattern」に「test」と入力する。
testはjsonの_indexで指定した値。うまくいっていれば、ちょっと待つと「Create」というボタンが表示される。
「Time-field name」には「Date」と表示されているはず。
ここに何も表示されていなかったら、それは日付型の指定がうまくいっていないということだと思う。
「Create」を押す。Fieldsで、「Date」のtypeが「date」, 「memory」のtypeが「number」になっていることを確認する。

5. kibanaでグラフを作成する

「Discover」タブを押す。「No results found」と表示されるが、それは表示範囲が直近15分だから。
右上の「Last 15 minutes」を変更するとグラフが表示されるはず。
その後は「Visualize」タブを押して、任意のグラフを作成する。 スケールの変更もGUIで簡単にできるし、ここは問題ないと思う。

elasticsearch, kibana環境をDockerでさくっと準備する

環境情報

  • Docker for Mac Version1.12.0-beta21

Docker Image取得

公式のイメージが提供されているので、それを使う。

docker pull elasticsearch
docker pull kibana

コンテナ起動

いくつかブログ見た感じ、これでいいらしい。

docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 elasticsearch
docker run -d --name kibana --link elasticsearch:es -e ELASTICSEARCH_URL=http://es:9200 -p 5601:5601 kibana

確認

下記ページにアクセスして、「Status: Green」になっていればよい。

http://localhost:5601/status

プロジェクトが縦割りか見分ける方法

自分なりに納得感のある「プロジェクトが縦割りか見分ける方法」を思いついたので、日記に残しておきます。

まず本文を読むにあたっての前提を記載します。

  • 本文章では「縦割りなプロジェクト」の対義語を「一体感のあるプロジェクト」としています。
  • 本文章ではある1つのシステムやサービスを開発する集団のことを「プロジェクト」、プロジェクト内で役割によって分かれた集団のことを「チーム」と記載します。

イメージとしては、プロジェクトは○○更改プロジェクト、チームはA業務チーム、B業務チーム、基盤チームといった感じです。

この前提で「プロジェクトが縦割りか見分ける方法」を述べると、「プロジェクトが縦割りか見分ける方法」それは「チームをまたがる技術的な課題の解決策をわくわく感を持って議論できるかどうか」です。
一体感のあるプロジェクトは、チームをまたがる技術的な課題の解決策をわくわく感を持って議論できますが、
縦割りなプロジェクトは、チームをまたがる技術的な課題の解決策をわくわく感を持って議論することはできないと考えます。

何故こう考えたかということ、チームをまたがる技術的な課題の解決策を議論するというのは、本来的にはエンジニアにとってわくわくする楽しいことだと思うからです。
エンジニアの方であれば、ある技術的な課題を「こういう技術があれば課題は解決するのに」「その技術ってこうやったら実装できるんじゃない?」「あ、それならできそう、チャチャッとやってみるか」といった感じで、楽しく議論したことがあると思います。
一体感のあるプロジェクトであれば、議論した内容がプロジェクトに本当に必要ということになれば、チーム間で作業の優先度勘案した上で、プロジェクトとして課題を解決するためのアクションを取れると思うんですよ。

縦割りなプロジェクトというのは、このチーム間の調整ができないのだと思います。
だから、本来的には楽しい技術的な課題のディスカッションの場が、作業の押し付け合いのような様相を呈してしまうのだと思います。

明らかにまとまってないんですが、今思っていることの骨子は書けたので、とりあえず文章を公開しようと思います。
また何か考えたら書きます。

このページはtoggleボタンのサンプルページです

要素の表示・非表示を切り換える、それがtoggleボタンです。
この機能を使って、画像の切替も実現可能です。
なお、説明と画像は一切関係がありません。

toggle_brother

toggle_brother

yaml.erbをyamlに変換するスクリプト

yaml内で変数を使いたかったので、erbと組み合わせて実現した。
個人的な備忘録として書き残しておく。

早速だがyaml.erbをyamlに変換するスクリプトは以下の通り。ファイル名はymlerb2yml.rbとする。

require 'erb'
require 'yaml'

# VARIABLE DEFINITION
var1 = 'bbb'
var2 = 'ddd'

# FORMAT TRANSLATION
yml_erb = ARGF.read()
ruby_data_type = ERB.new(yml_erb).result(binding)
yml = YAML.load(ruby_data_type)
puts yml.to_yaml()

動作確認には以下のyaml.erbを用いる。ファイル名はtest.yml.erbとする。

- aaa
- <%= var1 %>
- ccc_<%= var2 %>: eee

実行結果は以下の通り。

# ruby ymlerb2yml.rb test.yml.erb 
---
- aaa
- bbb
- ccc_ddd: eee

ワンライナーでやると以下の通り。

# ruby -r erb -r yaml -e "var1 = 'bbb'; var2 = 'ddd'; puts YAML.load(ERB.new(File.open('test.yml.erb').read).result(binding)).to_yaml()"
---
- aaa
- bbb
- ccc_ddd: eee

こんな感じでやりたかったことやれたっぽい。