チラシの裏の書き置き

技術的な話をするブログのタイトルじゃない気がする

GPSログを蓄積する仕組みをAPi Gateway+Lambda+DynamoDBで構築した

AWS 勉強

つい最近GPSロガー的なのを作りましたが、毎回毎回SFTPで接続するなどしてログを取り出すのも面倒なのでDynamoDBに蓄積するようにします。

blog.taiko19xx.net

単純な蓄積だけでも良かったのですが、それではあまり面白くないので、セッションID的なのを生成するAPIも一緒に作っています。
「クライアントで勝手に生成すればよくね？」という感じですが、AWSのサービス間連携における練習も兼ねているのでなるべくサーバサイドで完結するようにします。
今はやりのサーバレス！

続きを読む

builderscon tokyo 2016に行ってきた #builderscon

カンファレンス

ブログを書くまでがbuildersconらしいので。

ちなみに、

という会場でした。
正確に言うと、レッドブルの会場なのでレッドブルと水は飲み放題(！)でそれ以外はNG。理由は察して...。

聞いていたもの

  • Opening
  • OSSはWindowsで動いてこそ楽しい
  • php.iniについて知る
  • Open Beer Serverの理論とその実装
  • C 言語で行う Web フロントエンドプログラミング
  • Simulating old computers using Arduino microcontrollers.
  • 「片手間JavaScripter」にも知ってほしい、Vue.jsで実現するMVVMパターン、Fluxアーキテクチャとの距離
  • そろそろプログラマーもFPGAを触ってみよう！
  • Docker swarm mode などで作る PaaS モドキとその悲しみ
  • 世の中の困り事はだいたいGoのコード自動生成で解決する
  • Bluetooth キーボードの作りかた

よく見ると聞きすぎのような気もするけど、今後どんな話が出てくるか参考になったのでこれで良かったかもしれません。
Open Beer Serverみたいな話はお腹いっぱいって言ってましたけど。

簡単な感想

スライドは気付いたら追加するかもしれないししないかもしれない。

Opening

  • そんな気はしてたけど、早速来年の予定が発表されてた。

2017.tokyo.builderscon.io

  • 8/3～5のの2.5d(多分1日目が前夜祭かな...？)という話だったので、行けるよう努力したい。
    • まだまだ先だけど
  • 終わった後にスケジュール見返して、まだ8ヵ月近くあるし、ハードの勉強でもして何かネタ仕込もうかしらみたいな気持ちになった。

OSSはWindowsで動いてこそ楽しい

Big Sky :: builderscon 2016 で登壇してきました。

  • Windows迫害の歴史は結構あるあるな感じで聞いていた。
    • 特異点が多いせいでWindows移植は縛りプレイ...。
    • 特異がある方が少数派なので、そっちが合わせるしかないのは確かに仕方ないと思った。
  • 動かないから楽しい
  • ifdefの森になるはずの所で、プラットフォームの差異を吸収してくれるGo言語すごい。Windowsにやさしい。
  • mattnウェア最強。
  • 最後vimで動画再生する話になってて、何のセッションだかわからなかった。(Go言語とは一言も言ってないけど)
  • vimで動画再生とかとんでもない変態だなーと思いました。

php.iniについて知る

  • 後方互換性も含めて200個以上あるphp.iniの設定には18年も歴史あるのすごい。
  • 書き切れないくらいphp.iniに関する知見がものすごい溜まった。
    • php.iniを覚えるのはバリュー
    • スライドも確かに実践よりの内容だったので、設定する事はめになった人には是非見てもらいたい。
    • 自分でもあとで見直したい。
  • 「date.timezoneがデフォルトでセットしてないの辛い」みたいな質問をしたら「色々指向錯誤したけど、無理なのでちゃんとセットしよう」という解答を頂いた。
    • サーバの座標をphp.iniに入れると、関数経由で日の出と日の入りの時間取れるという知識も合わせて。
  • 薬事法にひっかかるタレ
    • パワーワード感ヤバいし週明けから使っていきたい。
    • 書かなくてもいい気もするけど、いわゆる「コードの秘伝のタレ」の事
  • 置き場所とか記述場所がバラバラなのは完全に闇という感じしかない。
    • なるべくスクリプトの中に書くというのは真似したい。
    • 奥が深いとも言いそうだけど、こんな奥の深さは望んでないんだよなぁ...

大事なことなので。

Open Beer Serverの理論とその実装

  • ビールサーバーエンジニアの知見を得た。
  • ハード面(というか回路)にあまり明るくなかったけど、スライドとか説明がが分かりやすかったのでよかった。
  • Mackerel最強
  • お掃除大変そうだなーと思って聞いてみたけど、専用のアタッチメントを買ってマネーパワーで解決しているらしい。
  • ビールサーバ構築に必要なパーツの値段が高い。トータル9万はあまり真似できないけど真似したい。

C 言語で行う Web フロントエンドプログラミング

  • 「CをコンパイルするとHTMLができる」からして常人向けではない感じしかしなかった。
    • 実行コマンドがemcc -o index.html hello.cだし...
  • デモで出てたのはこれ。
  • メインで紹介してた技術(asm.js/WebAssemblyについてはこの辺の記事がよさそうなので後で見返しておく。
  • パフォーマンスここに極まりという感じだけど、今の所ここまでやらないといけない場面には至ってないので参考程度かな...。
    • 来年あたりもしかしたら化けそうな気がする。

Simulating old computers using Arduino microcontrollers.

Simulating minicomputers on microcontrollers | Dave Cheney

  • PDP-11とApple IをArduinoでシミュレーションするというお話。
  • 何故か通訳があると思い込んでいたせいか、中身は6割ぐらいしか分からなかった気がするのが残念。
    • 時間作ってスライドと資料は見返してみたい。
  • 結構指向錯誤していく過程は見ていて大変そうでもあり、面白そうでもあった。
  • Apple IにはMOS 6502というMPUが61個積まれていたが、エミュレーション時にこれを2個しか使っていないという話は技術の進歩を感じた。
  • 趣味はたのしい、仕事はおもんない(意訳)

「片手間JavaScripter」にも知ってほしい、Vue.jsで実現するMVVMパターン、Fluxアーキテクチャとの距離

  • Vue.jsはあまり触っった事がなかったが、触りやすそうな気がするのでそのうち触りたい。
  • MVCとかMVVM、それらとFluxの関係性について再度考えさせられるいい機会だった。
    • 注意深く設計されたMVVCはFluxと同じになるというのははっとした。
  • 設計は大事だし、我々は注意深くないというのを肝に免じておきたい。

そろそろプログラマーもFPGAを触ってみよう！

qiita.com

  • FPGAの話はよく聞くけど、大枠について把握してなかったので良かった。
  • FPGAは大人の電子ブロック
  • ソフトも触ってハードも触る、何となくbuildersconっぽい発表のような感じがしました。
  • 業務に活かせる機会はあるかどうか分からないので、触るのであれば趣味で触ったほうがよさそう。
    • FPGAボードが欲しくなった
  • HDLは辛みしか無さそうだったけど、HLSのおかげで希望の光が見えた。

Docker swarm mode などで作る PaaS モドキとその悲しみ

# Docker Swarm Mode の話(タイトル変えた) - Diary

  • オレオレPaaSが数分で構築できるのは良さそう。
  • 問題が多かったりドキュメントが少ない(というかドキュメントに書いてない)らしいので、その辺を自力で何とか解決できる上級者向けという感じでした。

世の中の困り事はだいたいGoのコード自動生成で解決する

世の中の困り事はだいたいGoのコード自動生成で解決する

  • Go言語に限った話のようだったけど、考え方自体はどこでも活かせそう。
  • どこでどう使うかはよく考えなければならないけど...。

Bluetooth キーボードの作りかた

builderscon tokyo 2016 で「 Bluetooth キーボードの作りかた」を喋りました | tech - 氾濫原

  • 既製品が安いなら買った方が良いのは確かにその通りだった。
    • 自分の条件にあう物があれば、という条件つき。
    • 通して聞いてみると、時間も技術もお金もかなりかかりそうという所になった。特に技術面。
  • 確かに知見が貯まりそう。やってみたい。
    • いきなりフルキーボードは無謀なので、少ないキー数で何かを...。
  • OSSを使えば一通り作れるのはいい時代になったと思う。
  • あとはチャイナパワーもしゅっごい。
  • 関係無いけど、既製品のキーボードたたき割って無理矢理分割したのを思い出した。
  • ErgoDox(EZ)触ってみたい。

懇親会

f:id:taiko19xx:20161203235250j:plain

写真が今年最高にへたくそなので伝わるか分かりませんが、こんな料理が出ました。茶色い。

あと、色々レッドブルで割って飲んだけどほとんどレッドブルの味になってしまった。
少なくともウーロン茶は割ってはいけない(戒め)

まとめ

  • 自分が普段触れない分野の話を沢山聞けてよかった。
  • 色んな方面の知見が溜まりすぎてオーバーヒートしそうになった。
  • 同時に、知識が足りない部分があったのでその辺は今後以下にして取り込んでいくかが課題になりそう。
  • ハード面ももう少し勉強しておきたいですね。

という訳で、運営の皆さん、発表者の皆さんありがとうございました。
参加者の皆さんもお疲れさまでした。
次回も是非行きたいです。

Go言語入門記(その2)

勉強

前回の続き。というか形になったので上げてみるテスト。
何となくぼかしてたけど、要はチャットワークのAPIを使ってメッセージを取ってくるやつです。

それっぽくなったものはこちら。それなりにエラー処理も追加したけど、まだ適当感ある。

以下感想です。

  • 楽で良い
  • 型推論が付いてるのは心強い
  • deferが便利
  • JSONの扱いは大変
    • 空の時はstringだけど、そうでない場合は数字が入ってくるみたいなAPIがあるので、そこの扱いをどうするか
  • ビルドもまだそんなに遅くない
  • log.fatal()はログ出力もしつつos.Exit(1)的なのもしてくれるんだけど、その時点で終了するというのを忘れると大変そう
  • goroutineの出番は無かった

Go言語入門記(その１？)

勉強

とある企画を細々と進めていて、その中で「あるデータを定期的にCronで取ってKVSに突っ込む」みたいなスクリプトを作ることになっていました。
で、パパッとPHPで書こうかと思っていたのですが、丁度Go言語の入門本を入手したところだったので、せっかくなのでGoで書いてみる事に。

改訂2版 基礎からわかる Go言語

改訂2版 基礎からわかる Go言語

 

その過程でいろいろ発見とか躓きがあったので、そのメモです。その１ってなってるけど、続くかどうかは不明。

やりたいこと

  • GETでAPIにアクセス
  • JSONで帰ってくるので、キーのみ抽出
  • 上のキーと最初に取得したJSONを値とした組み合わせでKVS(redis)に突っ込む

今のところ

それぞれはまだ連結してなくて、それぞれ実現したい事を単独で試している感じ。
エラー処理は何も考えてなくて、ブランク識別子( _ )で見なかったことにしている。

GETによるアクセス

これは簡単でした。
APIはOAuthとかではなくヘッダにトークンを入れて認証する形式なので、Header.Setでセットする感じになりました。

package main

import (
  "fmt"
  "net/http"
  "io/ioutil"
)

func main() {
  var req, _ = http.NewRequest("GET", "エンドポイント", nil)
  req.Header.Set("X-Token", "トークン")

  var client = new(http.Client)
  var resp, _ = client.Do(req)
  defer resp.Body.Close()

  var byteArray, _ = ioutil.ReadAll(resp.Body)
  fmt.Println(string(byteArray))
}

一見難しそうだけど、実際に書いてみるとスラスラと書けるので非常に良い。

redisにSET/GETする

さすがに標準対応していないので、redigoを使用。レリゴー。
redisはVagrantにで構築した仮想環境内にあるので、別途アドレスを指定。

package main

import (
  "github.com/garyburd/redigo/redis"
  "fmt"
)

func main() {
  var conn, _ = redis.Dial("tcp", "192.168.33.100:6379")
  defer conn.Close()

  conn.Do("SET", "123", "aaatest")

  var str, _ = redis.String(conn.Do("GET", "123"))

  fmt.Printf("%#v\n", str)
}

ライブラリのおかげが、これも書きやすかった。

JSONのパース

一番困ったのがここ。
そもそもGoにおけるJSONの扱いは、わざわざJSONに対応した構造体を宣言しないといけないので面倒そうだなという感じでした。

考えることは皆同じのようで、いろいろ調べてみるとgo-simplejsonといういい感じのパッケージがありました。
基本的にはこれで良さそうなのですが、今回取得するのは次のような・・

[
  {
    "message_id": 1,
    "account": {
      "account_id": 123,
      "name": "Bob"
    },
    "body": "Hi there!"
  },
  {
    "message_id": 2,
    "account": {
      "account_id": 334,
      "name": "Mike"
    },
    "body": "Hello!"
  }
]

最初からキーなしの配列になっているJSONで、どうやらgo-simplejsonはこの形式が上手く取れないようでした。 (もしかしたら取れるのかもしれない)

なので、大人しくencoding/jsonのjson.Unmarshal()を使うことにしました。

Unmarshalもそのままだと上のようなJSONに対応してないので、ここを参考にパースしました。

package main

import (
    "encoding/json"
    "fmt"
)

const data = `
[
  {
    "message_id": 1,
    "account": {
      "account_id": 123,
      "name": "Bob"
    },
    "body": "Hi there!"
  },
  {
    "message_id": 2,
    "account": {
      "account_id": 334,
      "name": "Mike"
    },
    "body": "Hello!"
  }
]
`

type accountData struct {
  AccountID       int64 `json:"account_id"`
  Name            string `json:"name"`
}

type messageData struct {
  MessageId   int64 `json:"message_id"`
  Accont      accountData `json:"account"`
  Body        string `json:"body"`
}

type JsonData struct {
  Message []messageData
}

func main() {
    messageKey := make([]messageData, 0)
  json.Unmarshal([]byte(data), &messageKey)

  for _, value := range messageKey {
    fmt.Println(value.MessageId)
  }
}

JSON渡すだけでいい感じにしてくれるとシンプルになって有り難いのですが、まぁあまり深く考えないようにします。
郷に入っては郷に従えとはよく言ったものです。

これから

とりあえずは各処理をつなげて想定したものを形にするのが第一目標ということで。
最終的にはcronに頼らず、タイマー処理とかも内部で完結させられればという感じです。

YAPC::Asia Tokyo 2015(2日目)に行ってきた #yapcasia

カンファレンス

初参加で2日間参戦です。
無事閉幕しましたが、まだまだブログに書くまでがYAPCなので2日目の感想もぼちぼち書きます。

Mackerel開発におけるScalaとGo、そしてPerl

yapcasia.org

http://songmu.github.io/slides/yapc-asia2015/#0 (スライド)

Mackerelでは複数の言語を使い分けているので、どんな基準で使い分けているか、という内容。

  • Scala + Playをサーバサイド
    • がっちり作るものに向いているため
    • 何でもかんでも全部Scalaだとビルドしてデプロイまで20分かかり、大変なので使い分け
  • golangはmackerel-agentとmkrと、外部監視の仕組み
    • コマンドラインツールに向いているため
    • 大きすぎるものは思想的にマッチしてないし、書き捨てするようなものには向いていない
  • Perlはmackerel-agentのリリース自動化
    • どの環境にも大体入っているので、プロジェクトの脇役として
    • 普通にWebアプリケーションを作るパワーはある
  • Rubyはfluentdのプラグイン(fpluent-plugin-mackerel)など
    • 既存のエコシステムに乗っかるために
    • 手元のツールを作るのにも最適
  • JavaScriptやHaskellも適材適所で

という使い分けをしているようでした。

適材適所で使い分けるというのは良いのですが、言語数が多くなればなるほど言語毎に人が別れて属人化してしまいそうだなと思ったり。
同じような質問が質疑応答が出てきてその答えが、「みんな何でも書く」らしいです。はえー・・・。
とはいえやはり属人化しがちなので、ScalaやGoはレビューをしながら進めているそうで、知見が無い人がレビューをする事で知識が身についていくらしいです。
分かんなかったら勉強しよう、との事。

自動化機構は負債になりやすい、という話も出ていました。どんどん肥大化してやがてメンテ不能に・・・というのはありがちな話です。
それを防ぐためにはちゃんとテストを書いたり、責務を分けるというのが大事なようです。
1個のツールには1個の役割だけ持たせたり、最悪ローカルでは動かせるようにしておく必要があります。

あと、はてなブログの記事をgitで管理するblogsyncが紹介されたのですが、かなり便利そうでした。

github.com

NASA主催の世界最大級ハッカソンSpaceAppsを運営した話

yapcasia.org

www.slideshare.net

NASAが世界規模でやっているハッカソンについて、運営している中で出た知見を共有して頂きました。

やはり運営するとなるとかなり大変で、場所決め・会計などなど・・・考えなければいけない事がかなり多いです。会計は色んな要素が組み合わされるので特に大変そうです。
スポンサーは、ただ単に集めまくるというのも良くなく、「趣旨に賛同してくれるスポンサー」を集めるというのが重要で、もちろんそれに見合ったリターンをする必要もあり・・・。
また、無断キャンセルをいかに防ぐかというのも重要で、「無断欠席すると今後お断りする場合があります」と書いたら一定の効果が出たようです。

進め方の中では、コミュニケーションとドキュメントが重要と仰っていました。
コミュニケーション不足は様々問題の元だし、とはいえオンラインでは不十分。打ち合わせの間に雑談するとか空気感が大事なので、とりあえずご飯は行ったほうがいいみたいです。
ドキュメントはただ書くだけではなく、「頭の中のものを書き出す」というのを忘れずに。

お願いとして「5回に1回ぐらい運営側に回りましょう」との事でした。やってみたいな〜感はすごいあります。
仲間や居場所ができて、段取り力も養えて達成感味わえるらしいです。

あまり関係無いですが、冒頭に出たキーボードにプロジェクションマッピングしてるのかっこ良かったです。

Docker３兄弟について〜そして4兄弟へ〜

yapcasia.org

speakerdeck.com

Dockerのツールである、Docker Machine/Docker Compose/Docker Swarmの話。全部βらしいです。

最近はAWSとかでもDockerが使えるので、そこのサーバをDocker Machineで操作したり、複数のコンテナで構築されるサービスを1つのYAMLで定義してDocker Composeで構築管理したり、Docker Swarmでクラスタリングしたり・・・とDockerも簡単に色々できるようになってきたなーという印象でした。
しかも、やろうと思えばマルチクラウドでのクラスタリングもできるらしく、実現できればサービスが分散できるためかなり面白いのではないでしょうか。

最近、Windows/MacでDocker使うためのboot2dockerがDocker Toolboxというのに置き換わっていたのも初めて知りました。
この中にDocker Kitematicというのが内包されていて、GUIからDockerの操作ができる(バックエンドはVirtualBox)という嬉しいものになっていたので、boot2dockerよりかなり使いやすくなっていそうです。 (Kitematicが4人目の兄弟、という話だったような気がします)

まだDockerをあまり触れていないので、色々出そろってきた今がもう一度入門し直すチャンスなのではないかと思いました。

Adventures in Refactoring

yapcasia.org

GitHubの中の人による、リファクタリングをどうしているかという話。 かなりテクニカル(という予告があった)だったり、そこそこ早口で進んでいたので同時通訳大変だなーと思っていたのですが、代わり代わり頑張って頂けたようでこれもまた聞きやすかったです。

話では始めにリファクタリングの成功の基準が出てきましたが、こんな感じでした。

  1. コード数が減った
  2. コードカバレッジが上がった
  3. テストの表現性が増し、テストが何をしているか分かりやすくなったもの(オレオレルールらしい)
  4. パフォーマンスの向上
  5. 開発者がハッピーになったもの

これには若干思う所があって、コード数が減るのはもちろん良いけど、減らない場合もあるはずでそこはどうなんだろうという感じでした。 結果的にハッピーならそれで良い、という訳では無いはずなので、まだまだ検討する余地があるという所なのかもしれませんが・・・。

で、何故リファクタリングをするのか、というのはこんな感じ。

  1. 開発者がハッピーになるため
  2. 性能の向上のため
  3. 将来の作業に向けての自信を獲得するため
  4. 開発者の教育

(3)が重要で、新しく機能を追加する時などに既存のシステムについて恐怖心があると自信が無いという事になります。
過去の負債を返済する(paying off technical debt)ためにリファクタリングを行います。
開発者の教育というのもなるほどなーという感じで、システムのエッジの部分に目を行かせる事になるそうです。
振る舞いの変わらない所から触らせる(=リファクタリングさせる)事で教育にも繋がる、という感じです。

リファクタリングにおけるテクニックも紹介して頂きました。

  1. ちょこちょこハッピーを入れる(見つける？)
  2. スタイルガイドを得る
  3. 命名規則を整理する
  4. 使いやすい抽象化レイヤーを追加する
  5. 逆に、不要な抽象化レイヤーは取り除く

要するに整理整頓を欠かさず行う事で、改善に繋がるという事のようです。(そりゃそうかもしれませんが) (1)は、改善される事でコードが見やすくなったりネストが減って、泣きたくなるコードが減るのでハッピーになります！という事で。

まぁもちろんそんなリファクタリングにも落とし穴はあり・・・

  1. 既存のバグ
  2. パフォーマンスの変化
  3. リファクタリングの規模

に気を付けなければならないそうです。
既存のバグは重要な問題で、リファクタリング中にバグを直すべきでは無いと。挙動が変わるので、リファクタリングが原因かfixが原因か分からなくなります。
規模の問題は、大規模すぎるようなリファクタリングはリスクの元なので、細かく区切ってリファクタリングしましょうとの事でした。

質問も色々出ていて、メモしていた範囲ではこんな感じでした。

  • リファクタリング中に意見が分かれたらどうするか
    • スタイルガイドである程度解決されるので、後は話し合いで
  • 機能を追加するべきか、リファクタリングをするべきか迷ったらどうするか
  • デザインパターンは使っているか
    • 意識しすぎると「コードをテストに合わせてしまう」ので良くないので使っていない
    • 良いテストからコードが生まれるというのを意識する
  • テストもドキュメントも無いんだけどどうすれば良いか

この中で「素晴らしい仕事をしたら褒めよう」とも言っていました。褒めるのに🔪(:hocho:)を使うのが流行ってるらしいです。 (褒める時じゃなった気もする)

最初から最後まで、1年目〜2年目のようなエンジニアなりたての人が聞くとかなりためになる気がする内容でした。
スライド公開されないですかね・・・。

ソーシャルゲームにおける AWS 移行事例

yapcasia.org

speakerdeck.com

お題そのままですが、カヤックで運営しているソーシャルゲームをいかにしてオンプレからAWSに移行したか、という話。

中でも、RDS(MySQL)のタイムスタンプの問題は初耳でした。UTCに固定されてしまうため、移行元でJSTの運用をすると時間がずれてしまう場合があるとか。
また、MySQLの移行はかなり時間がかかるようで、いかに時間を短縮するか、というため色々探した結果、こんな資料があったようです。
dumpして再度importする機会がたまーにあるので、結構活用できそうでした。

他にも、Falloverの検証に手を焼いたり、証明書の問題もありと課題はそれなりにあったようです。
ここでもConsul+Stretcherの話が出てきて、移行後に採用したとの事なのでそこそこ盛り上がりつつあるんだなーと思いました。 あとは、レプリケーション可能なMemcached互換サーバのyrmcdsを移行のタイミングで使い始めたとの事。これも初耳でした。

移行作業の演習は、構築した本番でやって終わったらdropして・・・の繰り返しだったようなので、そんなもんでいいのかと思いました。 専用の環境立てたりするよりは楽ですし、確実に消せば良いのでそんなもんなのかもしれません。

辛いことをやめる！から始まる業務改善とInfrastructure as Code

yapcasia.org

www.slideshare.net

最終日というかYAPC最後のトークは、何をしようか迷った結果業務改善についての話を聞きに行きました。辛いことやめたい。 成功談だけではなく、そこに至るまでの経緯を詳しくご紹介頂いたのでかなり参考になりました。

何をするにもまず問題を理解する所から始め、ヒントを探したり現状とゴールのギャップ(goal-reality pairs)を把握する必要があるとの事。
人は変化を怖がるため、それを受け入れると良くなるというのを納得させる必要があるため、理解する必要があるようです。
しかもただ説明するだけでは良くなく、相手の立場に合わせてメリットを伝える必要もあります。

過程において重要な人(CTOとか)を巻き込んでトップダウンで行うのも効果的と仰っていました。
ボトムアップだと「お前の仕事だろ」と言われてしまうらしく・・・会社としての方針を統一でき、「付いていくように」と言って貰えるよう重要な人を巻き込む必要があります。この時に一緒に巻き込める仲間がいるとより進めやすくなるみたいです。
また、導入の間は少しでも動かなかったり「あれ？」という声がしたら即座に反応するというのも円滑に進めるために必要なステップのようです。
後はドキュメントを、導入中にあった問題と解決方もあわせてしっかり残したり、ハンズオンを何回も何回も繰り返しやって浸透させ、心の障壁を下げるのも重要です。

評価(効果測定)も忘れずに行います。 今回でた例だと3週間で開発して教育には3ヶ月かかったけど、作業に必要な時間が1/10になったのですぐに取り返せるレベルになったみたいです。 すると、結果的に残業も減って他の事も楽しめ、モチベーションも上がり・・・という良いサイクルが生まれそうです。 プログラミングによって生産性が上がった事で、プログラミングが楽しいというのを知ってもらえ、社内にプログラミング部が出来たとか。

ちゃんと調べてちゃんと変わるところを伝え、開発後の導入時のサポートは手厚く(特にハンズオン)行えば円滑に業務改善が進められそうです。 業務改善というと難しいイメージがありましたが、こうやって話を聞いてみるとシンプルだったな、と思いました。

クロージング

楽しい楽しいお祭り2日間も終わりの時が。
過去のYAPCを振り返ったり、今年の来場者数が発表されたり・・・。
ネットワークは常時100Mbps出てたしいので、CONBUの皆さんには足を向けて寝られません。

YAPCの名称は誰のものでも無いので、自由に使って貰って良いそうです。ありそうやな・・・。
他にも色んな所で色んな動きがあるらしいので、来年もまた何が起こるか期待しています。

お弁当

ランチセッションじゃないとお弁当貰えないと思ってる人たちがいたようで、あぶれた人は外へ食べに行き、その結果

との事なので

消化してきました。お弁当2個食べられるとか幸せです。
(ランチセッションに行きそびれたので尚更)

食べてるそばからどんどん無くなっていましたが、無事に無くなったようで安心しました。

その他

  • LTが面白すぎて腹筋が死んだ
  • 無限コーヒーは幸せ
  • 相変わらずMBPの電源はギリギリだった
  • ビックサイトは意外と遠い(仕方ない)
  • 同人誌買えなかった・・・

という訳で

f:id:taiko19xx:20150822175329j:plain

皆さんお疲れさまでした。楽しい2日間でした。
また同じような機会があれば、自分のためにも参加したいです。
(スタッフ側とか・・・)

壇上に立つような人になりたいなとも思える良い機会でしたので、そのモチベーションを持ち続けられたらなと思います。