読者です 読者をやめる 読者になる 読者になる

GitHub Kaigiに参加してきました! #githubkaigi

概要

GitHub KaigiはGitHub User Group主催のイベント。
募集開始時には、500人定員であっという間に埋まった中、なんとか参加できました。
http://githubkaigi.org/
http://githubkaigi.doorkeeper.jp/events/11081

タイムテーブル

1:30 to 1:40 @naoya Hello, Github Kaigi
1:40 to 2:10 @hirocaster Github実践入門 ─ Pull Request による開発の変革 (仮)
2:15 to 2:45 @shibayu36 はてなブログの開発フローと Github (仮)
2:50 to 3:20 @amatsuda OSSGitHub (仮)
3:25 to 4:05 @cobyism How Github Works
4:05 to 4:35 おやつ休憩
4:35 to 4:55 @inao Githubで雑誌記事を作る (仮)
5:00 to 5:30 @nathansobo Atom, the Programmable Text Editor
5:35 to 6:05 @yuku-t Qiita で人気の Git & GitHub ノウハウ(仮)
6:10 to 7:00 @miyagawa Rebuild.fm Live
7:05 to 7:45 LT x 8
7:45 to 7:50 kanpai

詳細

Github実践入門 ─ Pull Request による開発の変革 (仮)

Speaker : @hirocaster さん

mixi, github, ruby, server-side, agile

Presentation document

Note

はてなブログの開発フローと Github (仮)

Speaker : @shiba_yu36 さん

はてなブログチームのエンジニア

Presentation document

Note
  • チームは、5人エンジニア、2人デザイナー
  • ブランチ運用の活用方法:master, develop, feature branch1,2...
  • GitHub タスク管理.
    • Before: Redmineでタスク管理。GitHubでレビュー目的。両ツールを見なきゃいけなくて面倒。
    • After: GitHubのIssues/PullRequest に統合。開発者/効率アップ。
    • その後の課題:チームの重要度がわからない。優先度/締め切り/アサインが不明瞭。
    • 解決策:GitHub x カンバン(重要なものをピックアップ)
    • マネージャー :朝会 x カンバン / 開発者:朝会 x GitHub/Issues
  • pull request
    • 課題:pull requestのレビューのフローと促進/ステータス管理がまだまだな状態に。
    • 解決策:レビュー状態ラベル/レビュー依頼,レビュー中,レビュー完了 、レビュータイム(IRCbotで告知する)を明示的に導入。
  • リリース
    • リリース全ては全部自動化できてない。リリースチェック用のテンプレートを導入。
    • git-pr-release を作っている。

OSSGitHub (仮)

Speaker : @amatsuda さん

Rails, Ruby, kaminari => 4000 stars 越えました!

Presentation document

Note
  • ソーシャルコーディングの世界
    • プログラマーにとって一番大事なものを共有するプラットフォームができた。
    • コミッターじゃなくても今はだれでもコミットできる世界。
  • OSS and me
    • 自分の仕事上の問題を解決する手段
    • しょうがないから直しているの延長線上の話。
  • WEB + DB Vol.50 特集2 / 神Git エントリが。
  • rubyプラグイン
  • RailsGithub
    • 唯一の神は、DHH
    • コミットを良しとするためのとりくみ。公式URLでコミット貢献度のランキングを導入している。
    • Rails Contributors - All time
  • Ruby
    • 唯一の神は、Matz
    • なぜGHに移行しないのか? 自由なswの開発プロセスが特定企業のプロダクトに依存するのは。
    • Railsの文化とは逆。コミットは少なめ。
    • リアルなコミュニティ:asakusa.rb
  • kaminari
    • GitHub上のコミュニティ活動、リアル上のコミュニティ活動は、両軸でやり続けていきたい。
    • GitHubで会って、実際に本人とFaceToFaceで話しているときが楽しい。
    • ドキュメントをちゃんとして、みんなから読んでもらえるようにするのが、とても重要。
    • アイコンは、画像と本人が一致するのが望ましい。
  • とにかくcodeを書くしかない。
    • プレゼンスをあげるためには。草をいっぱい生やすしかない。あちら側とこちら側の境目がない世界。
  • ソーシャルコードは人間賛歌。人間讃歌は“勇気”の讃歌ッ!!

How Github Works

Speaker : @cobism さん

GitHub, Inc.
coby@github.com

Presentation document

Note
  • 自発性、透明性、柔軟性
  • リモートがデフォルト
    • デフォルトだからこそリモートが最も良い状態であるべき
    • sync <=> async
    • informal <=> formal
    • いくつかのツールを使うことで解決する.例えば、Chat
  • Hubot
    • Hubotを経由して、Deploy, CI/Builds
    • ChatOpsが別チームでワークしている
    • 会話の中心にツールをもってワークするようにする。
  • とはいえ直接会うことが大事。
    • Summits(全員あつまった会議)
    • Product minisummits / Team minisummits / Onboarding
    • 信頼関係を。
    • Video Chats.
    • 会話でのショートカットは利用しないようにしてほしい。
    • リモートを得意にするためにも。
    • Everything should have an URL.
    • あなたの言葉を人間の言葉のように話す
    • その上で絵文字は、とても素晴らしい!
  • Be patient.
  • Iteration is always the keys.
  • 組織の人の数でどんどんやりかたは異なってく。

Githubで雑誌記事を作る (仮)

Speaker : @inao さん

WEB+DB Press 編集長

Note
  • md2inaoは、md2indesign
  • Adobe InDesign
  • GitHubで何が変わったか?
    • 進捗状況が、見える化された
    • メール使わずにIssue /Pull Requestによりメールを使わなくなった
  • Git / GitHubの習得
    • 「はじめてのGit」特集Vol.50
    • 知りたければ書いてもらえればいいじゃないメソッド
  • 注意点
    • GitHub プライベートリポジトリは用意いただく必要がある
    • あくまで私の場合のお話、人によって抵抗ある人もいる。
  • ぜひ読む人、か、書く人になってほしい

Atom, the Programmable Text Editor

Speaker : @nathansobo さん

atom developer
nathansobo (Nathan Sobo) · GitHub

Presentation document

https://www.dropbox.com/s/utaud80bk5egse3/Atom%20%E2%80%93%20GitHub%20Kaigi_jp.pdf
※公開されたら、差し替える

Note

入門書には載ってないGit & GitHub Tips ( Qiita で人気の Git & GitHub ノウハウ(仮))

Speaker : @yuku-t さん

CTO @ Increments

Presentation document

Note
  • Qiitaに載っていた、GitHub Cheat Sheetにも載ってない、入門Gitにも載っていないTipsの紹介
    • git diff-highlight は、知らないと損している.
    • そもそもgit fsckとは?
    • GitHutとReviewの話
      • hub browse :
      • hub pull-request : current branchをプルリクエストしてくれる
    • git rebase -i --autosquash
      • fixupとautosquashの違い
      • fixup : コミットメッセージを修正しない。
      • autosquash コミットメッセージを修正できる
    • レビューはローカルで(個人的にはですが)
      • GitHubのWebViewが遅いから。
      • 個人的にはtig推し。
  • 開発 & レビュー 状況のデモ

Rebuild.fm Live

Speaker : @miyagawa さん、@naoya_ito さん

http://rebuild.fm/

Note

LT x 8

  1. @kenchan 新たなるソーシャルコーディング時代の幕開け => Idobata の紹介。
  2. @sota0805 Git・Githubに隠された便利な機能 => GitHubチートシートのオススメの紹介。
  3. @pnsk GitHub@Ameba (仮) => schacon/git-media · GitHub に期待 ! もう巨大なデータをgitignoreしなくていい! ~git-mediaの使い方~ - 3度の飯と最新技術
  4. @pwim Using GitHub to get a better job
  5. @uribo GitHubで行うreproducible research => 再現可能な研究では、objectivity,clearly,properlyでは重要視している。Ten Simple Rules for Effective Computational Research。
  6. @sakatam Hubot レビュアーおみくじ => 開発体制をスケールするためにコードレビューを必須に。コードの属人化が課題に。ランダムにアサインできない。Hubotのおみくじでやらされ感を緩和。
  7. @yunico-jp 本当は怖くない!デザイナーがGitを大好きになった♡5つの理由(仮)=> デザイナー視点でgitでやっていることを理解デキるまでの話。苦手意識がなくなることでなくなる。本当は怖くない!デザイナーがGitを大好きになった♡5つの理由 | nanapi TechBlog
  8. @taea pplog.net の作り方( ˘ω˘) => pplog - ゆるふわインターネットにポエムを刻もう。ゆるふわチーム開発について。

kanpai(beerbash)

Beerbashをピザを囲んでビールを。ピザは一瞬ではけました( ˘ω˘)
GitHub, Incの方やSpeakerの方たちと導入/導入後の話できてよかった。

まとめ

  • 今回のイベントを開催してくださったGithub会議スタッフの方々ありがとうございました!
  • GitHubのポロシャツほしかったw
  • 目的忘れずに現場にGitHubを入れる方向にもっていきたい。それで現場で既に導入している人たちの課題を踏まえて、導入段階〜充分に活用できている段階までこの半期中になんとかしたい。
  • GitHubでコード書く習慣つけなきゃなと。草を生やさねばといい意味での危機感持てたのでコード触る時間を意図的に作る。
  • 現場のチームのベストなやり方は、それぞれ違うので改善は常につづけていきたい。改善促進のために、個人的にはレトロスペクティブとしてKPTの定期開催を継続していきたいなと。
  • Rebuild.fmを周りのエンジニアに勧めて拡散させる。
  • 昨日はGoConference 2014 springにも参加しましたが、今日のGitHub Kaigiもかなりアツいカンファレンスで、アツい土日でした!

JAWS DAYS 2014 参加まとめ

3/15(土)にJAWS DAYS 2014に参加してきた。
1週間経過してしまったが、自分自身、発表内容を思い出して、自分向けに整理しておきたい、という欲求のために、参加したセッションや印象に残ったセッション内容を書き起こしておく。

JAWS DAYS 2014の概要

JAWS DAYS 2014 の概要については、About | JAWS DAYS 2014 に記載されているJAWS DAYS 2014の開催趣旨は次の通り。

このたび我々は、全国レベルで AWS ユーザーの交流ができるべく、JAWS-UG全国規模のイベントを開催することにいたしました。

このイベントが、参加される皆さんにとって何かしら現状から「一歩前へ」進むキッカケとなって欲しい、そう想いこのテーマに決定しました。

当日のタイムテーブルは下記リンクから。

参加したセッション詳細( 順不同 )

参加したセッションや、特に印象に残ったセッションを順不同で覚書きとともに書き起こしていく。

Immutable Infrastracture

Speaker

@naoya_ito さん

発表内容

JAWS DAYS 2014、Immutable Infrastructure について - naoyaのはてなダイアリー

Immutable Infrastructure の概要と、現在における導入状況や抱える課題についての紹介。

Infrastructure as Code の本質

アプリケーション開発のワークフローをインフラに持ち込める

  • 自動化は、Infrastructure as Code の要素の1つでしかない。
  • インフラの状態を、コードにできる。

-> コードにできると、バージョン管理できる。gitで管理できる
-> バージョン管理できる。gitで管理できる
-> インフラ状態をコードとしてレビューできる。暗黙知形式知にできる
-> コードがあると、インフラについてもテストを行うことができる
-> severspec が利用できる
-> コード/テストコードがあれば、CIもできるでしょ?
-> Travis CI / AWS / Vagrant でできる

Imuutable Infrasruture の課題
  • Logical View ( pass cloud_front )
  • ステートフルなサーバ
    • ストレージ/ キャッシュ / DBの永続化されているもの.
    • アプリケーションのログ/アクセスログは、1箇所にまとめましょう! fluentdつかったり、外に。
  • 既存インフラの一部を動的に。

クックパッドのデプロイとオートスケール

Speaker

@mirakui さん

発表内容

cookpad社におけるデプロイとスケールさせるための事例の紹介。
満席でリアルタイムで聞けなかったorz

Benchmarking on AWS

Speaker

Robert Barnes さん

発表内容

  • CARBS というキーワードについて
    • Choose the best benchmark を。
    • Analysis -> 最適な意味とはなんですか?まずは分析して。
    • Run enough - 十分な量のテストを行うこと
    • Baseleine - 何が良い結果のベースをひくこと
    • Samples - 全ての結果について結果をきく.

Infrastructure as Code

Speaker

@sawanoboly さん

発表内容

  • サーバ構成の変更手順書は、現状やっているワークフローによって成り立っている
    • 理解できるのは人間だけ
    • これは鉄板のワークフロー
    • このワークフローを何が何に置き換えることができる
  • 今までのワークフローのなんの置き換えで、chef/serverspeceでやろうとしていくのかを把握していくことが大事!
  • 現状のワークフローに追加することは、余計な作業をフローに追加するだけでは、ただ単に作業を増やすだけ。
  • 「Chef 活用ガイド - コードではじめる構成管理」書籍 を買いましょう。
  • Apache ZooKeeper - Home を使ってみる.

AWS クラウドデザインパターン for Enterprise

Speaker

発表内容

  • Cloud Design Pattern のエンタープライズ向けのパターンの紹介。
  • CDP設計ガイド ( Kindle版 ) 発売したので、買いましょう。
    • ※ 自分は、その場でポチって買ちゃいました。
  • Cloud computing guidelineをだしている。
    • AWS PCI Compliance Package。
    • AWSのセキュリティ基準を準拠している。

Immutable Infrastructure 時代の構成管理ツールSpecInfra

Speaker

@gosukenator さん

発表内容


serverspec について
構成管理ツール紹介
  • puppet
  • Chef
  • ANSIBLE
構成管理ツールの基本原則( ウェブオペレーション/ 5 章からの抜粋 )
  • 宣言的 ( なにをするものなのか? どうするものなのかを書かない. )
  • 抽象化 ( あなたのかわりに面倒をみてくれる
  • 冪等性 ( 状態が不定なので実行が必要かどうか判断 )
  • 収束化 ( 不定な状態を一定の状態に収束させる )
Imutableの文脈でみると
  • 冪等性、収束化が不要になってくる。
  • イメージを作る/ 再現可能な手順があるか? 次の2つの方法が使える。
SpecInfra について
  • 実行形式の差異 (ローカル/SSH/ WinRM等)

- configspecによる構成管理

  • OSの違い/実行形式の違いはSpecInfraが吸収してくれる

PASS, IASSの微妙な関係

Speaker

@stanaka さん

発表内容

※個人的に一番おもしろかったセッション

IaasとPaasの話
  • 実行環境の選択
    • Where?
    • Why ?
  • なぜ、EC2 + RDS の組み合わせ
    • なぜXXなんですか?
    • どういうメリットがあるんですか?
    • これらを論理的に説明出来る必要がある。
実行環境とDevOps 界隈
  • Orchestration
    • ツール例:Fabric/ Capistrano
    • 多数のサーバにデプロイする
    • 多数のサーバアクセス
  • Provisiong
    • ツール例:Chef/puppet/Ansible
    • 多数のサーバの構成管理
    • Infrastracture as Code
  • Immutable Infrastructure
    • Blue-Green Deployment
    • Stateless Server
Goal はどこになるのか?
  • IaaS上に、PaaS的ななにかを作っている?
    • Immutable Infrastructure
  • IaaS + DevOps => Private PaaS ? ?
PaaS VS (IaaS +DevOps)
  • PaaS 特性(一般的なはなし)
    • Pros - 簡単、DevOpsの人いらず
    • Cons - 線形にコストが上昇、柔軟性にかける
  • IaaS + DevOps の特性
    • Pros - 柔軟性、高コスト効率、システム限界が把握しやすい
    • Cons - DevOpsの人がいる
柔軟性とは・・
  • APモデルの自由度
    • work aroundはあんまり勧めではない
  • PaaSが前提とするAPモデルに引きずられる。
理想的な実行環境
  • 理想的なPaaS ( @stanaka さんとしての )
    • AP,DBがスケールする
    • リソースを効率的にマネジメント
    • きめ細かいこともできる
      • Auto-scaleやフェイルオーバーのポリシーなど.
  • stateless なもの
    • リバースプロキシ、apサーバ
  • stateful なもの
    • DBサーバ
リソースマネジメント を効率的に行うには
  • 高効率の追求
  • 自動化/省力あkの追求
  • 気の利いた挙動をしてほしい
それにむけてのリソースマネジメントの注目ツール

"技術的負債"を問いなおす

Speaker

@kentaro さん

発表内容

「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughts
※ 改めて今、抱えている技術的負債をなんとか返さねばと。。

まとめ

  • Immutable Infrastructureの日本国内での注目度の高さはかなりのもの。全てのセッションがほとんど立ち見。
  • サーバ構築する自動化するツールや手法は多くでてきているけど、最終的になにを目指したいのかっていうのは常に忘れずにおきたい。
  • その上で、今注目されている技術・ツールをめちゃくちゃ深堀りして追いかけてみたい。
  • AWSの勢いは止まらないと思うくらいコミュニティが活発でぜひともまたこの手のイベントに積極的に参加しときたい。
  • もろもろと刺激ありで楽しみつつも勉強できて良かった。JAWS DAYS 2014スタッフの方々に感謝!

JavaEE勉強会100回メモ

ついに第100回目。
自分が参加し始めたのは、メールをあさってみたら23回目が初めての参加だったみたい。
感慨深いです。
さらっと、覚えておきたいと思ったことをメモっておく。

Postion Papaper

最近の Java Framework について

Scala

Javaのanti patternについて

Enterprise Integration Pattern ( Autor : Gregor Hope ) :本編

Enterprise Integration Patterns - Integration Patterns Overview

Conversation patterns について

InfoQ(QCon) でGregor Hopeさんが話していた

Note

  • 自分の洋書に関する情報のアンテナがひくかったので、もっと情報仕入れる。
  • KindleMacで、amazon.com, amazon.co.jp の両方が簡単に切り替えて見れるようになってほしい。
  • また開発合宿したい(思いつきです)
  • 100回目に参加できてよかった。主催者の角田さん、はじめ、いつも参加してくれてる方々に改めて感謝な日だった。

Go言語 をインストール・設定までの覚書き

目的

Go言語を覚えてある程度使えるレベルにまでなるために、
学習時点での覚書きを残して。まずは、とっかかりとして、
インストールから簡単に動かせるまでを覚書きしておく。

開発環境

Mac OS X v10.9.1 ( Intel Core i5)
Go v1.2

インストール・設定

% cd /usr/local/src/
% wget https://go.googlecode.com/files/go1.2.darwin-amd64-osx10.8.tar.gz
% tar zxvf go1.2.darwin-amd64-osx10.8.tar.gz
% mv go /usr/local/go1.2
% ln -s /usr/local/go1.2 /usr/local/go

環境パスを.zshrcに予め読み込まれるように追記する。

% cd ~
% vi ~/.zshrc

追記する内容は次の通り。

export GOROOT=/usr/local/go
export PATH=$PATH:$GOROOT/bin

パス設定を反映して、goコマンドで、パスが通っていることを確認。

% source ~/.zshrc
% go
Go is a tool for managing Go source code.

Usage:

	go command [arguments]

The commands are:

    build       compile packages and dependencies
    clean       remove object files
    env         print Go environment information
    fix         run go tool fix on packages
    fmt         run gofmt on package sources
    get         download and install packages and dependencies
    install     compile and install packages and dependencies
    list        list packages
    run         compile and run Go program
    test        test packages
    tool        run specified go tool
    version     print Go version
    vet         run go tool vet on packages

Use "go help [command]" for more information about a command.

Additional help topics:

    c           calling between Go and C
    gopath      GOPATH environment variable
    importpath  import path syntax
    packages    description of package lists
    testflag    description of testing flags
    testfunc    description of testing functions

Use "go help [topic]" for more information about that topic.

動作確認

テスト用にhello worldをgoで書いてみる。
ファイル名は、hello.go

package main

import "fmt"

func main() {
     fmt.Printf("hello, world\n")
}

goのrunで実行する。

% go run hello.go
hello, world

開発環境を整える

Goでの開発を行いやすくするために、Go Code を利用する。
Go codeでの使い方tipsなどは、また別途で書くつもり。

開発環境のエディタは、Emacsを利用するため、まずは
シンタックスハイライトと自動補完できるように環境を整える。
How to Write Go Code - The Go Programming Language と、Screen cast を参考に進める。

Go Codeのインストール

まずは、$GOPATHを設定する。

% vi $HOME/.zshrc

環境パスを次のように修正。

export GOPATH=$HOME/Sandbox/golang/gocode
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin


Go Codeをダウンロードする。

% source $HOME/.zshrc
% go get -u github.com/nsf/gocode
% ls $GOPATH
bin/ src/


Go Codeで、さっき書いたhello.goをプロジェクトとして、installして
バイナリとして動かしてみる。

% mkdir -p $GOPATH/src/github.com/nsf/hello
% cp hello.go $GOPATH/src/github.com/nsf/hello/hello.go
% cd $GOPATH/src/github.com/nsf/hello/
% go install
% ls $GOPATH/bin
hello
% GOPATH/bin/hello
hello, world

Emacs/自動補完設定(go-autocomplete)

Emacsの前提の設定として、auto-compelete-modeがインストールされていること.
go-autocomplete.el ファイルを、emacsの設定ファイルを置いてある場所にコピーさせればok.

% cp $GOPATH/src/github.com/nsf/gocode/emacs/go-autocomplete.el $HOME/.emacs.d/elisp/.

設定ファイル(.emacs)に以下の記述を追記.

(require 'go-autocomplete)
(require 'auto-complete-config)

Emacs/シンタックスハイライト(go-mode)

goをインストールしたディレクトリのmisc/emacs配下にハイライト用のelispファイルが置いてあるのでコピーしてくる。
ちなみにgithubにもgo-mode.elはある.

% cp $GOROOT/misc/emacs/go-mode-load.el $HOME/.emacs.d/elisp/.
% cp $GOROOT/misc/emacs/go-mode.el $HOME/.emacs.d/elisp/.

設定ファイル(.emacs)に以下の記述を追記.

;; go-mode
(add-to-list 'load-path "go-mode-load.el" t)
(require 'go-mode-load)

まとめ

  • 環境設定でコード書きやすい状況にするのは重要。
  • まだまだ開発しやすい環境にする設定はあるようなので調整してみる。
  • gocodeを使うことでテストコードを書くこともできるのでその部分も深く触ってみる。
  • revel使ってサンプルつくるところまではもっていきたい。

JavaEE勉強会99回のメモ

毎月恒例のJavaEE勉強会
そこでの話で、自分が気になったことを時系列でメモしておく。

EIP読み合わせ (本題)

Chapter 8

Asynchronous Implementation with MSMQ
http://www.eaipatterns.com/ComposedMessagingMSMQ.html

Simle Queue

Amazon Simple Queue Service
http://aws.amazon.com/en/sqs/

IronMQ ( implemented by MQ )

http://www.iron.io/mq

Redis

Redisをはじめ,NoSQLやKVSは、簡単なQueueとしても役立てそう

Amazon Simple Queue Service

http://aws.amazon.com/jp/sqs/

次に読む予定の本

Security Patterns in Practice: Designing Secure Architectures Using Software Patterns

http://www.amazon.com/dp/B00DNZR8K4

番外(こういうのも出てるよ)

Note

  • 海外の著名エンジニアについての情報あんまり知らないので、海外で有名なエンジニア(著者など)の観点で情報を応用にする。
  • Go-langそろそろ計画たててやる。

2014年の目標/抱負

2014年の目標/抱負を書いて忘れないようにおく。
2014年からは、はてなダイアリーからはてなブログで書くことにした。

そもそも1年の最初に思いを新たにするために書くという位置付けというよりか、
今、自分がやりたいと思って取り組んでいる物事に対して、
1年に1回客観的に見直すための位置付けというのが近い感覚である。

仕事関連

全体

  • 是が非でも、国内で通用するWebサービスを、組織の成果として、作り上げ軌道に乗せる。

現場の開発プロセスについて

より現状のトレンドに、遅れをとらない形に改善する。エンジニアとして周りに自信を持って説明できるレベルにしたい。

  • Githubを用いた開発(コードレビューの仕組み化)
  • CIによるオートメーション化
  • TDDの文化の定着化、
  • インフラ構築/設定、監視設定の自動化

※正直、安定化しているものをそのまま維持して使うのは個人的に好きじゃないので。

ITスキル

確実にやっておきたいこととしては、次の通り。比較的に低レイヤー部分を中心に取り組みたい。1年に1言語習得を忠実にこなす。

  • Chef/Dcoker/Vagrant/Ansible によるインフラ構築/設定の自動化
  • Go言語

コミュニティ/勉強会/カンファレンス 関連

国内

  • 100名規模のカンファレンスで、LTの機会があれば積極的に参加。
  • JavaEE勉強会引き続き参加。開発合宿も年2回はやりたい。
  • 社外の勉強会でも発表経験を。

海外

  • 2014年こそはWWDCに参加。
  • Velocity, AWS summit, など今までに参加出来ていなかったカンファレンスも可能であれば。

情報発信(Output)

質の高いアウトプットを出すためには、量をこなす必要があると考えている。
また、自身のアウトプットから、よいインプットにつながるための循環を作っていきたい。

  • Twitter/Facebook ( 1 [post/day] )
  • ブログ書く(2 [posts/month] )
  • Githubに自作ライブラリ公開( 4 [source/year] )
  • SlideShareもしくはSpeakerDeck に発表資料公開 ( 4 [slides/year] )

語学(英語)

目的は、ビジネスシーンで英語を用いて物事を進めることにできるようになることである。
その実現のために、4つのカテゴリで取り組む。

Speaking

  • デイリーで、通勤時、ボキャビル/基本文法の反復トレーニングを実施。
  • Rarejobを継続(週2回は確実にこなす)
  • 外国人の方が集まる場所に月1で参加.

Writing

  • ひたすら英作文による反復トレーニングを。
  • 海外のメール, IRCのやりとりにも疑問があれば参加。

Reading

  • Webで調べるときは、原則英語を使う。
  • 技術書は、原則的に洋書を利用する(英語)。
  • ニュース/最新技術動向の記事は、英語のサイトを読む。
  • 分からないワードがあれば、都度、アプリAnkiに登録してひたすら復習。

Listening

  • 海外カンファレンス(GoogleIO, WWDC, QCon, など) 、TED、購読しているPodCastをスクリプトなしでも理解可能な状態なレベルに。
  • TOEICのスコア:800点。一般的に英語ができるとみなされる基準点。ただし、高いスコアを取ることを本目的としないように注意。(Reading/Listening)

私生活

  • 家族との時間を特に優先的に割り当てるようにする。
  • ジョギング 10km 週1回 ( ノルマ:40 [km/month] )
  • 体重は、現状をキープ。

以上、現時点で思いつくことを書いてみた。

個人のスキルにフォーカスして、狭い視点で取り組まないように、ひたすら視点の位置を、意識的に高くして、1日1日を大事に過ごして行きたい。

tmuxの導入方法

Linux(CentOS)で複数のターミナルを扱うためのアプリケーションのscreen を
これまで使っていたが、最近、ターミナルマルチプレクサtmux に
乗り換えたのでそのときのインストール手順をφ(..)メモメモ

tmuxインストール手順

tmuxをインストールする時には、最新版をインストールしたいなと思い、
ソースからインストールすることにした。そのために、必要となるライブラリを
事前にいれておく。

ncurses
$ wget http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.7.tar.gz
$ tar zxvf ncurses-5.7.tar.gz
$ cd ncurses-5.7
$ ./configure
$ make
$ make install
ncurses-devel
$ yum -y install ncurses-devel
libevent
$ wget http://downloads.sourceforge.net/project/levent/libevent/libevent-2.0/libevent-2.0.17-stable.tar.gz
$ tar zxvf libevent-2.0.17-stable.tar.gz
$ cd libevent-2.0.17-stable
$ ./configure
$ make
$ make install
tmux
$ wget http://downloads.sourceforge.net/project/tmux/tmux/tmux-1.6/tmux-1.6.tar.gz
$ tar zxvf tmux-1.6.tar.gz
$ cd tmux-1.6
$ ./configure
$ make
$ make install
$ echo /usr/local/lib >> /etc/ld.so.conf
$ ldconfig

起動確認をする。起動成功!これでひとまず乗り換え完了。

$ tmux

設定ファイルまわり

いろいろtmuxについて取り上げている情報を基に情報を収集してみた。
その結果、できた設定ファイルは、下の通り。screenのキーバインドになれていたこともあり、
デフォルトのプレフィックスは、C-b ではなく、C-t設定を変更した。
これで快適なターミナルライフが。

(~/.tmux.conf)
#prefix C-b -> C-tに
set-option -g prefix C-t

# 日本語環境なら今のところ必須。
set-window-option -g utf8 on

# ウィンドウ名が自動的に更新されないように
set-window-option -g automatic-rename off

#マウス操作対応
set-option -g mouse-select-pane on
set-option -g mouse-select-window on
set-option -g mouse-resize-pane on
set-option -g mode-mouse on
set-option -g mouse-utf8 on

#ステータスバーの外観の設定
set -g status-fg cyan
set -g status-bg black
set -g status-left-length 30
set -g status-left '#[fg=white,bg=black]#H#[fg=white]:#[fg=white][#S#[fg=white]][#[default]'
set -g status-right '#[fg=black,bg=cyan,bold] [%Y-%m-%d(%a) %H:%M]#[default]'

# window-status-current
setw -g window-status-current-fg black
setw -g window-status-current-bg cyan
setw -g window-status-current-attr bold#,underscore

# ペインのアクティブなウインドウの外観の設定
set -g pane-active-border-fg black
set -g pane-active-border-bg cyan

# prefix + r で設定ファイルを再読み込みできるように。
unbind r
bind   r source-file ~/.tmux.conf