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

2016-12-04

builderscon tokyo 2016に行ってきた #builderscon

カンファレンス

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

ちなみに、

急いで来たのに飲み物禁止で喉の渇きがやばい #builderscon
— 総務省指定泰子(アローラのすがた) (@taiko19xx) 2016年12月3日

という会場でした。
正確に言うと、レッドブルの会場なのでレッドブルと水は飲み放題(！)でそれ以外は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に入れると、関数経由で日の出と日の入りの時間取れるという知識も合わせて。
薬事法にひっかかるタレ
- パワーワード感ヤバいし週明けから使っていきたい。
- 書かなくてもいい気もするけど、いわゆる「コードの秘伝のタレ」の事
置き場所とか記述場所がバラバラなのは完全に闇という感じしかない。
- なるべくスクリプトの中に書くというのは真似したい。
- 奥が深いとも言いそうだけど、こんな奥の深さは望んでないんだよなぁ...

薬事法に引っかかりそうなタレって言葉使っていきたい #builderscon
— 総務省指定泰子(アローラのすがた) (@taiko19xx) 2016年12月3日

大事なことなので。

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言語に限った話のようだったけど、考え方自体はどこでも活かせそう。
どこでどう使うかはよく考えなければならないけど...。

Bluetooth キーボードの作りかた

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

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

懇親会

f:id:taiko19xx:20161203235250j:plain

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

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

まとめ

ちょー楽しかった！お疲れさまでした！ #builderscon
— 総務省指定泰子(アローラのすがた) (@taiko19xx) 2016年12月3日

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

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

2016-01-18

Go言語入門記(その2)

勉強

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

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

以下感想です。

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

2016-01-11

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

勉強

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

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

作者: 古川昇
出版社/メーカー: シーアンドアール研究所
発売日: 2015/07/17
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

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

やりたいこと

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に頼らず、タイマー処理とかも内部で完結させられればという感じです。

チラシの裏の書き置き

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

#phpcondo2017 "PHPカンファレンス北海道出張版(仮) PHPオフ会"に遊びに行ってきたので発表してきた

#builderscon tokyo 2017(Day 2) に行ってきたメモ

#builderscon tokyo 2017(Day 1) に行ってきたメモ＆初LTで発表してみた

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