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 OSS と GitHub (仮)
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 による開発の変革 (仮)
Presentation document
Note
- GitHubを充分に活用することを目指す、そのためにはどうするか？
- コードをより良くする道具に近づけていくには。
- プルリクエストのコメント、フィードバックと改善案をセットで出してみる。
- そうすることで対話が生まれる。GitHubは、Conversation。
- 指摘するだけなら簡単。コードをより良くするにはどうすればいいかもセットで。それが充分に活用している姿。
- 「GitHub実践入門」ノウハウの例 - 9章6節 GitHub Flow について。
- なんでそうするのか？どういうことがおきるのか？
- 「GitHub実践入門」は、ガイドブックとして使うことを推奨。
- 「GitHubでつくる、たのしい開発現場」YAPC:ASIA Tokyo2013 | Act as Professional - hiroki.jp
- GitHubでつくる、たのしい開発現場 // Speaker Deck
- これ読んでおいてメソッドが使える！
- GitHubは目的ではなく手段。とはいえ、現場でGitHubは活用していく必要がある。
- そして、その先にあるものを考えていく必要がある
- その中で品質、効率はどんどん加速させていかなきゃいけない。
- GitHubKaigi資料公開「GitHub実践入門は活用するためのガイドブック」 | Act as Professional - hiroki.jp
はてなブログの開発フローと Github (仮)
Speaker : @shiba_yu36 さん
はてなブログチームのエンジニア
Presentation document
Note
- チームは、5人エンジニア、2人デザイナー
- ブランチ運用の活用方法：master, develop, feature branch1,2...
- GitHub タスク管理.
- pull request
- リリース
- リリース全ては全部自動化できてない。リリースチェック用のテンプレートを導入。
- git-pr-release を作っている。
OSS と GitHub (仮)
Presentation document
Note
- ソーシャルコーディングの世界
- プログラマーにとって一番大事なものを共有するプラットフォームができた。
- コミッターじゃなくても今はだれでもコミットできる世界。
- OSS and me
- 自分の仕事上の問題を解決する手段
- しょうがないから直しているの延長線上の話。
- WEB + DB Vol.50 特集2 / 神Git エントリが。
- rubyのプラグイン
- RailsのGithub
- 唯一の神は、DHH
- コミットを良しとするためのとりくみ。公式URLでコミット貢献度のランキングを導入している。
- Rails Contributors - All time
- Ruby
- kaminari
- とにかくcodeを書くしかない。
- プレゼンスをあげるためには。草をいっぱい生やすしかない。あちら側とこちら側の境目がない世界。
- ソーシャルコードは人間賛歌。人間讃歌は“勇気”の讃歌ッ！！
How Github Works
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 編集長
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
※公開されたら、差し替える
入門書には載ってない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とは?
- git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したい
- http://qiita.com/yoshiori/items/6da867aa6871be694996
- 誤ってgit stash clearした。% git stash apply
- 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 さん
Note
- 生Rebuild.fm。公開収録/記者会見方式。
- pull request 駆動開発
- GitHub.com とGitHub Enterpriseのソースが違う。何ヶ月くらいに1回くらいの頻度でマージする。
- F8 Hacker Way: Releasing and Optimizing Mobile Apps for the World
- rebuild.fm ep45
- ChatOpsの懸念点、availabilityが重要になる。Dependencyに偏る。
- ChatOps at GitHub // Speaker Deck
- Hubotの導入背景
- daily standupするときに。
- hubotのcron機能使ってみる。
- GitHub Issues
- Sqwiggle
- Remote workについて
- Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
LT x 8
- @kenchan 新たなるソーシャルコーディング時代の幕開け => Idobata の紹介。
- @sota0805 Git・Githubに隠された便利な機能 => GitHubのチートシートのオススメの紹介。
- @pnsk GitHub@Ameba (仮） => schacon/git-media · GitHub に期待 ! もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
- @pwim Using GitHub to get a better job
- @uribo GitHubで行うreproducible research => 再現可能な研究では、objectivity,clearly,properlyでは重要視している。Ten Simple Rules for Effective Computational Research。
- @sakatam Hubot レビュアーおみくじ => 開発体制をスケールするためにコードレビューを必須に。コードの属人化が課題に。ランダムにアサインできない。Hubotのおみくじでやらされ感を緩和。
- @yunico-jp 本当は怖くない！デザイナーがGitを大好きになった♡５つの理由（仮）=> デザイナー視点でgitでやっていることを理解デキるまでの話。苦手意識がなくなることでなくなる。本当は怖くない！デザイナーがGitを大好きになった♡５つの理由 | nanapi TechBlog
- @taea pplog.net の作り方( ˘ω˘) => pplog - ゆるふわインターネットにポエムを刻もう。ゆるふわチーム開発について。
kanpai(beerbash)
Beerbashをピザを囲んでビールを。ピザは一瞬ではけました( ˘ω˘)
GitHub, Incの方やSpeakerの方たちと導入/導入後の話できてよかった。
まとめ
- 今回のイベントを開催してくださったGithub会議スタッフの方々ありがとうございました！
- GitHubのポロシャツほしかったｗ
- 目的忘れずに現場に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 の要素の１つでしかない。
- インフラの状態を、コードにできる。
-> コードにできると、バージョン管理できる。gitで管理できる
-> バージョン管理できる。gitで管理できる
-> インフラ状態をコードとしてレビューできる。暗黙知を形式知にできる
-> コードがあると、インフラについてもテストを行うことができる
-> severspec が利用できる
-> コード/テストコードがあれば、CIもできるでしょ?
-> Travis CI / AWS / Vagrant でできる
Imuutable Infrasruture の課題
- Logical View ( pass cloud_front )
- ステートフルなサーバ
- ストレージ/ キャッシュ / DBの永続化されているもの.
- アプリケーションのログ/アクセスログは、1箇所にまとめましょう! fluentdつかったり、外に。
- 既存インフラの一部を動的に。
Benchmarking on AWS
Speaker
発表内容
- Performance 計測ツールに問題があるかもしれない。
- そのためにベンチマークするためのツールの紹介
- CARBS というキーワードについて
- Choose the best benchmark を。
- Analysis -> 最適な意味とはなんですか？まずは分析して。
- Run enough - 十分な量のテストを行うこと
- Baseleine - 何が良い結果のベースをひくこと
- Samples - 全ての結果について結果をきく.
Infrastructure as Code
Speaker
@sawanoboly さん
発表内容
- サーバ構成の変更手順書は、現状やっているワークフローによって成り立っている
- 理解できるのは人間だけ
- これは鉄板のワークフロー
- このワークフローを何が何に置き換えることができる
- 今までのワークフローのなんの置き換えで、chef/serverspeceでやろうとしていくのかを把握していくことが大事！
- 現状のワークフローに追加することは、余計な作業をフローに追加するだけでは、ただ単に作業を増やすだけ。
- 「Chef 活用ガイド - コードではじめる構成管理」書籍 を買いましょう。
- Apache ZooKeeper - Home を使ってみる.
Immutable Infrastructure 時代の構成管理ツールSpecInfra
Speaker
@gosukenator さん
発表内容
serverspec について
構成管理ツール紹介
- puppet
- Chef
- ANSIBLE
構成管理ツールの基本原則( ウェブオペレーション/ 5 章からの抜粋 )
- 宣言的 ( なにをするものなのか？ どうするものなのかを書かない. )
- 抽象化 ( あなたのかわりに面倒をみてくれる
- 冪等性 ( 状態が不定なので実行が必要かどうか判断 )
- 収束化 ( 不定な状態を一定の状態に収束させる )
Imutableの文脈でみると
- 冪等性、収束化が不要になってくる。
- イメージを作る/ 再現可能な手順があるか? 次の２つの方法が使える。
- シェルスクリプト
- Dockerfile
- この状況を踏まえて作成したのが
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 ? ?
- ★ The Twelve-Facotr App (Heroku ) サービスを運用しえ行くビジョン/考え方
- みんなでHerokuを作っているのかな？
PaaS VS (IaaS +DevOps)
柔軟性とは・・
- APモデルの自由度
- work aroundはあんまり勧めではない
- PaaSが前提とするAPモデルに引きずられる。
理想的な実行環境
- 理想的なPaaS ( @stanaka さんとしての )
- AP,DBがスケールする
- リソースを効率的にマネジメント
- きめ細かいこともできる
- Auto-scaleやフェイルオーバーのポリシーなど.
- stateless なもの
- リバースプロキシ、apサーバ
- stateful なもの
- DBサーバ
リソースマネジメント を効率的に行うには
- 高効率の追求
- 自動化/省力あkの追求
- 気の利いた挙動をしてほしい
それにむけてのリソースマネジメントの注目ツール
- Apache Mesos
- サーバクラスタ管理
- リソースをジョブに応じて割り当て
- Docker on Mesos
"技術的負債"を問いなおす
Speaker
@kentaro さん
発表内容
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughts
※ 改めて今、抱えている技術的負債をなんとか返さねばと。。
JavaEE勉強会100回メモ
ついに第100回目。
自分が参加し始めたのは、メールをあさってみたら23回目が初めての参加だったみたい。
感慨深いです。
さらっと、覚えておきたいと思ったことをメモっておく。
Postion Papaper
最近の Java Framework について
Scala
- Scala(フレームワークじゃないが、Play2との組み合わせの話が多かったので)
- Coursera の話もでてたのでメモ。Coursera.org
Javaのanti patternについて
Enterprise Integration Pattern ( Autor : Gregor Hope ) ：本編
Enterprise Integration Patterns - Integration Patterns Overview
Chap11 : System management
Camel / MessageHistory
ESB ( Enterprise Service Bus ) について
Conversation patterns について
InfoQ(QCon) でGregor Hopeさんが話していた
Slide / PDF (Gregor Hopeさんが公開していたPDF )
次の書籍（電子書籍、MEAPも可)
Security Patterns in Practice: Designing Secure Architectures Using Software Patterns
Taming Text
Seven Concurrency Models in Seven Weeks
Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications
AWS Cloud pattern
Note
- 自分の洋書に関する情報のアンテナがひくかったので、もっと情報仕入れる。
- Kindle がMacで、amazon.com, amazon.co.jp の両方が簡単に切り替えて見れるようになってほしい。
- また開発合宿したい（思いつきです）
- 100回目に参加できてよかった。主催者の角田さん、はじめ、いつも参加してくれてる方々に改めて感謝な日だった。
Go言語 をインストール・設定までの覚書き
目的
Go言語を覚えてある程度使えるレベルにまでなるために、
学習時点での覚書きを残して。まずは、とっかかりとして、
インストールから簡単に動かせるまでを覚書きしておく。
インストール・設定
% 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使ってサンプルつくるところまではもっていきたい。
参考URL
インストール/設定関連
Getting Started - The Go Programming Language
How to Write Go Code - The Go Programming Language
Goプログラミング言語のチュートリアル - golang.jp
An Introduction to Programming in Go
JavaEE勉強会99回のメモ
毎月恒例のJavaEE勉強会。
そこでの話で、自分が気になったことを時系列でメモしておく。
ポジションペーパー
Cousera/ Functional Programming
https://www.coursera.org/course/progfun
https://www.coursera.org/course/startup
EIP読み合わせ (本題)
Chapter 8
Asynchronous Implementation with MSMQ
http://www.eaipatterns.com/ComposedMessagingMSMQ.html
Chapter 11
RIEMANN ( implemented by Clojure )
Karaf
Camel/ Control Bus
Ward Chunningham( Engineer )
Rod Jonthson (Spring )
http://en.wikipedia.org/wiki/Rod_Johnson_(programmer)
https://twitter.com/springrod
REST in Practice
REST in Practice/ Authors
RESTful Web Services Cookbook: Solutions for Improving Scalability and Simplicity
http://www.amazon.com/dp/0596801688
http://shop.oreilly.com/product/9780596801694.do
TECHNOLOGY RADAR
Simle Queue
Amazon Simple Queue Service
http://aws.amazon.com/en/sqs/
IronMQ ( implemented by MQ )
Beanstalk
Redis
Redisをはじめ,NoSQLやKVSは、簡単なQueueとしても役立てそう
Amazon Simple Queue Service
次に読む予定の本
NoSQL Distilled
Security Patterns in Practice: Designing Secure Architectures Using Software Patterns
番外(こういうのも出てるよ)
seven concurrency model in seven weeks
http://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks
seven web frameworks in seven weeks
http://pragprog.com/book/7web/seven-web-frameworks-in-seven-weeks
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] )
語学(英語)
目的は、ビジネスシーンで英語を用いて物事を進めることにできるようになることである。
その実現のために、４つのカテゴリで取り組む。
Speaking
- デイリーで、通勤時、ボキャビル/基本文法の反復トレーニングを実施。
- Rarejobを継続(週2回は確実にこなす)
- 外国人の方が集まる場所に月1で参加.
Writing
- ひたすら英作文による反復トレーニングを。
- 海外のメール, IRCのやりとりにも疑問があれば参加。
Reading
- Webで調べるときは、原則英語を使う。
- 技術書は、原則的に洋書を利用する(英語)。
- ニュース/最新技術動向の記事は、英語のサイトを読む。
- 分からないワードがあれば、都度、アプリAnkiに登録してひたすら復習。
私生活
- 家族との時間を特に優先的に割り当てるようにする。
- ジョギング 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
