チラシの裏の書き置き

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

Go言語入門記(その2)

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

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

以下感想です。

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

Go言語入門記(その1?)

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

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

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

 

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

やりたいこと

  • 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/jsonjson.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)など
    • 既存のエコシステムに乗っかるために
    • 手元のツールを作るのにも最適
  • JavaScriptHaskellも適材適所で

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

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

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

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

github.com

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

yapcasia.org

www.slideshare.net

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

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

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

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

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

Docker3兄弟について〜そして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日間でした。
また同じような機会があれば、自分のためにも参加したいです。
(スタッフ側とか・・・)

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

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

(2015/08/24:世界展開する大規模ウェブサービスのデプロイを支える技術のスライドが公開されたので追加しました。)

初参加です。 毎年行こう行こうと思って忘れていたのですが、今年はチケット発売にすぐ気付けたので即座に購入しました。

噂によるとブログに書くまでがYAPCらしいので、それに従ってとりあえず1日目の簡単な感想をぼちぼち書きます。

メリークリスマス!

yapcasia.org

Perlのパパ、ラリー・ウォールの基調講演。
個人的には、「Perl6はクリスマスに出す(って言ったらしい)」→「いつのクリスマスとは言ってないぞ」→「βを誕生日に、正式版を今年のクリスマスに出したい」→「バスに轢かれなければ・・・」の流れがツボでした。
指輪物語とかホビットの冒険になぞらえていたり、スタートレックとか42の話題も出ていたので、この辺の話が理解できていればもっと楽しめたような気がします。

J.R.R.トールキンホビットの冒険の後に15年かけて指輪物語を書いたそうですが、Perl6もPerl5(2000年)から15年かけて作った、という事でなぞらえていたようです。
出ていた話では、「Perl6のコミュニティには(指輪物語でいうと)エルフやトロールのようにいろんな種族がいて、みんなそれぞれ意見は違うけど、それでも仲良く出来た方が良い」「お互いを好きでいてください」というのが印象的でした。

ちなみに、同時通訳の人が最高で非常に聞きやすかったです。

世界展開する大規模ウェブサービスのデプロイを支える技術

yapcasia.org

speakerdeck.com

Miiverseのデプロイやバージョン管理の話です。お世話になっております。
通して聞いてみると、かなり泥臭い運用をしている(しようとしている)んだな〜という感じでした。

リポジトリ同期の新システムというのでどんなもんかと思ったら、Gitで行うコマンドを自動化している感じだったり、デプロイは(現状)Capistrano2+Gitだったり、DB反映やコマンドの実行は手作業・・・という運用のようです。
Gitコマンドの自動化は「gitコマンドしか実行していないので安全」という事なので、確かに変な事するよりはコマンドに全部任せた方が動作は保証されるよな・・・と思いました。(何かあったらキャッシュ消してやり直すのあたりもかなり泥臭かったですw)

デプロイは、Cap2+GitからConsul+Stretcher移行を検証しているようでした。 (CodeDeployが無かった時期に作られたそうな)
これにより、Gitの負荷を考えなくてよくなったり並列実行できたりリポジトリに成果物が無いので肥大化が防げたり・・・といいことづくしらしいです。
台数が多くなればなるほど有利らしく、100台を対象にしたデプロイでかなりの差が出ていました。
大体デプロイ対象が30台を越えるとそろそろgit pullの負荷がボトルネックになってくるので、そうなればConsul+Stretcherを検討しても良いのではないかとの事でした。

TBD

yapcasia.org

今度はRubyのパパ、Matzのセッション。 直前までタイトルがTBDだったので本当に何を話すのやらと思ったら、(色々と小ネタはありましたが)Rubyの反省と新言語Streemの話でした。

RubyPerlの置き換えを目指して最初は作り始めたが、その結果Perlの影響があまりにも大きくなりすぎた、との事。
Lispの影響も受けているようで、その中で似たようなものなのに動きが異なってくるのでややこしいものがあり、「区別せず、全部同じで良かったのではないか」とも。

Streemは200行の動かないプロトタイプを公開したらバズってしまい、「動かないものは無視される」はずのOSS界の常識を覆すMatz伝説(自分で言ってた)となったようです。 仕様もシンプルでデータ構造もシンプル(シンプルすぎるみたいなのも見かけましたが)なので、ちょっとした処理をサクサクっと作ってしまうのに良いものになりそうです。 小規模データ解析やシンプルなWebサービスを作れるため、応用範囲が広いのではないかと仰っていました。かなり期待しています。

「新言語の余地はいつでもある」「環境の変化は新言語を生む」という最後の方の言葉が印象的でした。

Perlで学ぼう!文系プログラマのための、知識ゼロからのデータ構造と計算量

yapcasia.org

speakerdeck.com

恥ずかしながらデータ構造やら計算量についてあまり理解できてない部分があったので、そこを補うために。
と、思ったのですが、入った時点で超満員・・・何とか後ろに陣取ったものの、スライドが見えず中盤からは聞く事に徹していました><

スライドにほぼ全てが凝縮されているので、これ見れば大体は理解できるのではないかと思いますが・・・やっぱり解説とセットで聞きたかった・・・。
Cのポインタ回りは長年の謎でしたが、分かりやすい説明のおかげでかなり解消されました。
録画配信ありになってるので、それに期待しましょう。

Electron: Building desktop apps with web technologies

yapcasia.org

AtomVisual Studio Codeで使われているElectronの話でした。どちらかというと概要や作り方簡単なデモが中心。
どんな感じでWeb技術が通常のプログラムのような振る舞いになっているのか気になっていたので、関係者の方直々のお話を聞けて良かったです。大まかな流れはざっくりと掴めました。
既存のnpmの遺産が活かせるので移植が楽だったり、ライブラリを駆使する事でデスクトップアプリ顔負けのものがすぐ作れるという所が長所のようです。

デモで使われていたアプリはこの2つでした。

今の所はテキストエディタ中心的なイメージですが、ロボットやらVideoGameEditorやら色んな物に使われているので、まだまだ活躍の場は広がりそうです。

esa.io - 趣味から育てたWebサービスで生きていく

yapcasia.org

speakerdeck.com

esa.ioの作ったきっかけから育て方、その方針について。
個人的には今日のベストトークでした。「自分のやりたいことをやって、それで生活できて、それで回りの人を幸せに」したいです(\( ⁰⊖⁰)/) 。
ちなみに、きっかけが意外と単純で「試用期間切れたから作ろう」というものでした。

話の中で最初と最後に「いろいろ試すのが大事」と話されていたので、本当に大事そうです。
自分で何か作ろうとした場合に、「これ作ろう」→「もうあるやん・・・」という発想になって結局何もしないという場合がよくあるので、「あろうが無かろうがとりあえず作ってみた方が良いな」と思わせてくれる内容でした。
楽しさやモチベーションの維持の方法も色々ありましたが、「楽しさやモチベーションはあくまで生まれた結果なので、それを生み出す可能性のものをする」という所が共通している感じを受けました。
Bungfixタイムアタックや、フィードバック駆動開発とリリースノート駆動開発がかなり興味があります。

それにしても、「責任をもって真剣に開発する意思表示」をするために運営会社を作ってしかも副業で運営していたって相当な覚悟が無いと挑めないはずなので、かなりチャレンジャーだなとも思いました。

(そういえばステッカーくれるみたいな話をしてた気がするんですが、いただくのをすっかり忘れてました。)

懇親会

タダでご飯食べられるなーと思って乗り込んだんですけど、良く考えたら「パーティーメンバーがいません。」になりそうだなーとか思ったり思わなかったり。
結果的にそんな事は無かったので良かったです。ご飯もデザートもおいしかった。

ステッカー

スポンサー様のありがたいステッカーを色々頂いたので、ぺたぺたと貼り付けました。
(Azure以外は今日頂いたものです)

f:id:taiko19xx:20150821235723j:plain

自分を売る。
ここまできたらもう少し貼りたい。

その他

  • 無線LAN環境が最高
  • 何か名前書くのがあったらしく、ネームプレートに何も入れてなかったのは凡ミス。懇親会になって名刺入れた
  • お弁当もおいしかったです
  • MBPの電源が死にそうだったので、どこかで確保したかった
  • "採用目的"が頭から離れない

という事で

2日目もがんばるぞい!

中古で開発用ノートを買った

中古でThinkPad X201を買いました。開発用です。

届いた

23,000円ぐらいでCore i5(第一世代)と4GBメモリを積んでいるので中々お得な感じです。VT-xもVT-dもあるので、VagrantやDockerも使えます。多少の傷やキーボードライトの電球が切れてるらしいのですが、問題ありません。

OSはWin7Proが入ってましたが、全部消してUbuntuを。特にドライバを別途入れなくても完全に動作するのが嬉しいです。

せっかく指紋認証が付いているので使えるように

唯一指紋認証がデフォルトだと使えないので、使えるように。 必要なのは、fingerprint-gui

$ sudo add-apt-repository ppa:fingerprint/fingerprint-gui

$ sudo apt-get update

$ sudo apt-get install libbsapi policykit-1-fingerprint-gui fingerprint-gui

でインストールして、

$ fingerprint-gui

で設定画面を呼び出し。

Fingerで指を選んで、Scan/Verifyで設定。それだけでログインとsudoとかsu時に指紋が使えるように。 非常に楽なのですが、Ubuntuソフトウェアセンターから入れた場合とか部分的に使えない場合があるのが悩ましい・・・。

Windowsでvagrant sshする

Vagrantの機能にvagrant sshするとその場で立ち上げたVMに入れるというのがあるのですが、Windowsだと標準で使えません。
TeraTermとか使って接続すればいいだけなのですが、ユーザー名とパスワード入れるのも面倒。

それならssh.exeにパス通せばいいじゃない!

sshを同梱しているようなソフトは無いと思いがちですが、Gitに搭載されているので、Gitのbinフォルダにパスを通すだけで使えるようになります。
Gitのインストール時に「Run Git and included Unix tools from the Windows Command Prompt」を選んでいる場合は通っていますが、
選んでいない場合は各自でパスを通す事になります。
自マシン(Win7 64bit)だとこの2箇所にパスが通っていました。

C:\Program Files (x86)\git\cmd;
C:\MinGW\msys\1.0\bin;

それぞれにssh.exeがあります。

後はコマンドプロンプトなりPowerShellssh -vってやって応答が返ってくれば設定完了です。

C:\> ssh -v
OpenSSH_5.4p1, OpenSSL 1.0.0 29 Mar 2010
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-I pkcs11] [-i identity_file]
[-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-W host:port] [-w local_tun[:remote_tun]]
[user@]hostname [command]

OpenSSH_5.4p1が入っているようです。
ここまで確認できれば、後はvagrant sshでお楽しみ下さい。

C:\vagrant> vagrant ssh
Last login: Fri Mar 14 05:05:51 2014 from 10.0.2.2
Welcome to your Vagrant-built virtual machine.
[vagrant@localhost ~]$

弱点として、コマンドプロンプトPowerShellも、文字エンコードがShift-JISのようで場合によっては文字化けしてしまいます・・・。
vagrant sshする時はデーモンの再起動とか設定変更なのであまり関係無い気はしますが、ここだけ注意です。

Vagrantのsynced_folderが超絶便利なんだけど、落とし穴があった件

最近、社内ではVagrantを使っています。最近のIT企業っぽくてかっこいい。

こんな環境です。

今まではSublimeTextからSFTPプラグインを使ってVagrantの仮想環境に転送していたけど、ある日VagrantFileを見てみると「config.vm.synced_folder」なる項目を発見。
どうやら、ローカルのフォルダと仮想環境のフォルダを同期してくれるらしいので使ってみるとこれまた便利。
わざわざSFTPで転送せずとも、そのままの状態で表示されるじゃん・・・!

ApacheのWebroot下のいくつかのフォルダを、/vagrant/source以下にマウントしたフォルダにシンボリックリンクさせるという手法を取って運用していました。
こんな感じで。

C:\~\project <--synced_folder--> /vagrant/source/~ <-- ln="" -s="" --=""> /var/www/~

ただし、この運用にはいくつかの落とし穴がありました。

静的ファイルが更新されない

CSSとかJavascriptとか、一部に編集を加えてもApacheから読み出した時に変っていなく、マウント先を直接viとかで見ていると変っている不思議な現象。
中身を全部消すと反映されるのですが・・・。

調べて見ると、VirtualBoxNFSに起因するバグだった模様。
Vagrantの共有フォルダをApache(Nginx)のDocumentRootに指定するとレスポンスがおかしくなる奇妙な現象の解決方法 #vagrant - OTメモ帳
EnableSendfile Offがコメントアウトされていたので、解除してApacheを再起動すると無事に反映されるようになっていました。
めでたし。

Apacheが起動しない

仮想マシンの起動時にApacheも一緒に立ち上がっているはずなのですが、何故か立ち上がってないという現象にも遭遇。
vagrant sshで接続して、$ sudo /etc/init.d/httpd startすると普通に起動するので、起動時にのみコケている模様。
エラーログを見ても原因がつかめなかったため、同時期に設定したシンボリックリンクの設定をやめ、Webroot以下のフォルダに直接synced_folderを設定する事でApacheが立ち上がるようになりましたが・・・原因は謎。

C:\~\project\~ <--synced_folder--> /var/www/~

とりあえず、無事に使えているのでよしとします。