Mac の日本語入力ソース選択に Ctrl + Space を取られて Eclipse のコンテンツ・アシストが効かなかったときのメモ
Homebrew で MySQL のバージョンを指定してインストール
Homebrew で MySQL の古いバージョンをインストールしたときのメモ。
複数のバージョンをインストールするようなことは考慮していないので注意。
書くこと
- 環境
- やったこと
やったこと
インストールしたいバージョンがあるか確認
インストールしたい MySQL のバージョンがあるかを brew search で確認。
[shrimp]$ brew search mysql ==> Searching local taps... automysqlbackup mysql-cluster mysql-sandbox mysql@5.5 mysql mysql-connector-c mysql-search-replace mysql@5.6 mysql++ mysql-connector-c++ mysql-utilities mysqltuner ==> Searching taps on GitHub... caskroom/cask/mysql-connector-python caskroom/cask/mysql-shell caskroom/cask/sqlpro-for-mysql caskroom/cask/mysql-utilities caskroom/cask/navicat-for-mysql ==> Searching blacklisted, migrated and deleted formulae...
ここでは MySQL の 5.5 と 5.6 の Formula があるので、5.6 をインストールしてみる。
brew install する
brew search で確認したバージョンを指定して brew install する。
[shrimp]$ brew install mysql@5.6 ==> Downloading https://homebrew.bintray.com/bottles/mysql@5.6-5.6.37.sierra.bottle.tar.gz ######################################################################## 100.0% ==> Pouring mysql@5.6-5.6.37.sierra.bottle.tar.gz ==> Caveats A "/etc/my.cnf" from another install may interfere with a Homebrew-built server starting up correctly. MySQL is configured to only allow connections from localhost by default To connect: mysql -uroot This formula is keg-only, which means it was not symlinked into /usr/local, because this is an alternate version of another formula. If you need to have this software first in your PATH run: echo 'export PATH="/usr/local/opt/mysql@5.6/bin:$PATH"' >> ~/.zshrc For compilers to find this software you may need to set: LDFLAGS: -L/usr/local/opt/mysql@5.6/lib CPPFLAGS: -I/usr/local/opt/mysql@5.6/include To have launchd start mysql@5.6 now and restart at login: brew services start mysql@5.6 Or, if you don't want/need a background service you can just run: /usr/local/opt/mysql@5.6/bin/mysql.server start ==> Summary 🍺 /usr/local/Cellar/mysql@5.6/5.6.37: 345 files, 154.2MB
バージョンを確認
brew install でも出力されているけど、一応確認しておく。
[shrimp]$ /usr/local/opt/mysql@5.6/bin/mysql --version /usr/local/opt/mysql@5.6/bin/mysql Ver 14.14 Distrib 5.6.37, for osx10.12 (x86_64) using EditLine wrapper
あとは必要な初期設定をしていく。
Mac のファンクションキーを標準的なファンクションキーとして使う
新しい Mac を使い始めてファンクションキーのデフォルト動作がなじまなかったときのメモ。
Mac のファンクションキーのデフォルト動作
Apple サポート によると、Mac のファンクションキーのデフォルト動作は以下のようになっています。
デフォルトでは、これらのキーのいずれかを押すと、そのキーに印字されている記号が表す特殊な機能が実行されます。たとえば、スピーカーのマークが印字されているキーを押すと、音量を調整できます。
これらのキーを標準的なファンクションキーとして使う場合は、「fn」キー (通常、キーボードの左下にあります) を押しながらファンクションキーを押します。たとえば、「fn + F10」キー (スピーカーアイコンが刻印されているキー) を押すと、消音の入／切が切り替わるのではなく、「F10」キーに割り当てられた機能が実行されます。
個人的には後者の動きのほうがなじむので、そのように設定します。
やったこと
Apple サポート に書かれているとおりにするだけです。
1. Apple メニューの「システム環境設定」を選択します。
2.「キーボード」をクリックします。
3.「キーボード」タブがハイライトされていない場合は、クリックします。
4.「F1、F2 などのすべてのキーを標準のファンクションキーとして使用」を選択します。
参考にしたページ
Slack 俺俺チートシート
Slack を使い始めて便利だなと感じたショートカットキーをメモ。
今のところはナビゲーションとファイル・スニペット関連のショートカットのみ。
書くこと
- 環境
- よく使うショートカットキー
- 参考にしたページ
- ToDo
よく使うショートカットキー
ナビゲーション
| キー | アクション |
|---|---|
| Command + / | ショートカットキー一覧を表示 |
| Command + K | クイックスイッチャー |
| Option + ↑ | 前のチャンネルや DM に移動 |
| Option + ↓ | 次のチャンネルや DM に移動 |
| Option + Shift + ↑ | 前の未読のチャンネルや DM に移動 |
| Option + Shift + ↓ | 次の未読のチャンネルや DM に移動 |
| Command + [ | 前のチャンネルや DM に戻る |
| Command + ] | 次のチャンネルや DM に進む |
| ↑ | メッセージの入力エリアにフォーカスがあるときに↑キーで自分の最後のメッセージへ移動 & 編集 |
表示関連
| キー | アクション |
|---|---|
| Command + + | ズームイン |
| Command + - | ズームアウト |
| fn + ↑ | スクロールアップ |
| fn + ↓ | スクロールダウン |
ToDo
- スラッシュコマンドを使ってみる
- ナビゲーション以外のショートカットキーを使ってみる
TDDBC Tokyo 2017-09 に参加してきました #tddbc
TDDBC Tokyo 2017-09 - connpass に参加することができたのでメモ。
TDDBC ってなに？
TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。
実際に参加してみた感想としては、以下の要素がギュッと詰まった濃厚なイベントでした。
- 座学
- 実践
- ペアプログラミング
- コードレビュー
- 意見・情報交換会
個人的には、ペアプログラミングを組み込んでいるのが素晴らしいと思いました。何事もそうですが、実践では座学どおりに進むことはめったになく、少なからず失敗しながら身につけていきます。1人よりも学習効果が高いペアプログラミングを組み込んだのは、2時間という限られた時間のなかで一定以上の成果を得るためのベストプラクティスかもしれません *1
基調講演
せとあず (Twitter ID: @setoazusa) さん
TDD のエッセンスがギュッと詰まったフルスペック感漂う重量級の講演でした！ スライドを見るだけでも大いに勉強になると思いましたが、熱いトークを聞くことができたのは参加した人の特権じゃないでしょうか :)
ペアプロデモ
ペアプロデモをFizzBuzzで#tddbc pic.twitter.com/IG8NpnPIcu
— すーくん (@su_kun_1899) 2017年9月30日
ペアプログラミング実践の前に、YASUI Tsutomu (Twitter ID: @yattom) さんと よこち (Twitter ID: @chiiia12) さんによる、ペアプログラミングしながらテスト駆動開発するデモンストレーションがありました。
参加者はテスト駆動開発の経験がないのはもちろん、ペアプログラミングの経験もない人が多いです *2 そこで、実際にテスト駆動開発 + ペアプログラミングをライブで見ることができるのは、TDDBC に参加する大きなメリットだと感じました。特に引っかかることもなく淡々と進むのですが、とても丁寧かつ原則に忠実で、すごく分かりやすかったです。
ペアプロ
ペアプロのお題は セマンティック・バージョニング でした。
自分たちのペアは、ざっくりと相談して以下のような戦略をとることにしました。
- テスト駆動開発を体験することを一義的な目標にする
- 意見やアドバイスはためらわず言う
- 今やる演習問題だけに集中する (先の演習問題は見ない)
- 詰まったらペア交代 (第2ラウンドは5分のタイムボックスに変更)
第1ラウンドは、お互いの呼吸やベースとなるスキル・好みが分からずかなり苦戦した印象です。しかし、第2ラウンドでは第1ラウンドの経験が生き、お互いの呼吸が分かってくるにつれてリズムがよくなっていくのを感じることができました :)
また、「今やる演習問題だけに集中する (先の演習問題は見ない)」という戦略のおかげで、ついつい考えすぎてしまう落とし穴にはまることもなく、目の前のことに集中できたのは良かったと思います。特に、当初は「2.0.1a とかあるかもしれないし、バージョンはとりあえず文字列型で持っておこ〜」としていたのが、問題3で「ゼロ、または正の整数です」となったところで整数型として保持するように変更したときなど、「テスト書いておいてよかったよね〜」と、2人でニヤニヤしちゃいました。
コードレビュー
各ラウンド2ペア ✕ 2ラウンド = 4ペアがコードと戦略、実際の進み方を話して、他の参加者や TA さんがそれをレビューしました。
プログラミング言語やフレームワークによって観点や戦略がまったく異なるものになってしまうのはもちろんですが、*3 同じプログラミング言語でもまったく異なる戦略で進めているペアもおり、「こんないいやり方もあるんだなあ」と知見を広められるのは、とてもよい体験でした。
懇親会
懇親会！ピザだ！#tddbc pic.twitter.com/LruYf33MbK
— すーくん (@su_kun_1899) 2017年9月30日
メインスケジュールが終わったあとは懇親会へ。
.@gaopin1534 さんのLT！ #tddbc pic.twitter.com/2sHYEKMebl
— Yotaro TAKAHASHI (@PoohSunny) 2017年9月30日
恒例 (らしいです) の LT 大会がすごい盛り上がりでした。個人的には、主催者の1人である PoohSunny (Twitter ID: @PoohSunny) さんがガチのマサカリ勢だと知ることができたのが大きな収穫でした。以後、態度にはよりいっそう気をつけたいと思います。
感想
参加者のレベルが高い
TDDBC Tokyo 2017-09 https://t.co/WZh4lVFnut #tddbc
— いきすぎステーキ (@a_suenami) 2017年8月26日
参加者一覧にbootする必要のない方々が見えるぞ
参加された方のレベルがすごく高かったです。ガチでレベルが高すぎて「本当に新兵？」「むしろ教官側では……」と感じることも何度となくありました。
まとめ
本当に久しぶりとなる勉強会への参加でしたが、朝の受付から懇親会までフルに楽しかったです！
自分はまだブートしたてですが、少なくとも前に進むキッカケをいただくことができたので、今後は新兵以外の形で TDDBC に関わっていくことを考えてみたいな、と思いました。
みなさんお疲れ様でした！！！ #tddbc pic.twitter.com/ftomcuBZsL
— Yotaro TAKAHASHI (@PoohSunny) 2017年9月30日
1人で始めた職場での改善活動1年間を振り返ってみたメモ
職場で勝手にやっている改善活動のメモを取り出してから1年たったので振り返ってみたメモ。
書くこと
- 実際にやったこと
- 変わったこと
- 一番大きく変わったこと
- まとめ
実際にやったこと
メモはハッシュタグ #俺俺改善活動 を付けて Twitter へツイートしていました。*1
今月の #俺俺改善活動．構成管理のブランチポリシーを整理してドキュメント化した．普段は見ないものだけど，ブランチ開発経験のない人が入ってきたときは効果すごいある
— えび🦐 (@ebc_2in2crc) 2016年7月28日
今月の #俺俺改善活動．高コストな上に誤りが混入しやすい機能をエンドツーエンドでテストできるようにした．テストは自動化されているから CI に組み込めるし，安心して修正できるようになった(*'▽'*)
— えび🦐 (@ebc_2in2crc) 2016年7月28日
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年9月30日
・テストの25%を占めていたスローテストの実行時間→実質0に
・大量の不良 XML を発見→更生させる
・鬼長い手順書を自動化→手順書レスに
・ふりかえり活動開始の根回し→活動許可ゲット
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年10月31日
・ふりかえり導入 (継続させたい！
・巨大コミットしてた人のコミットがすごく小さくなってきた
・他の現場に移った人が SVN な現場に Mercrial 導入 (DVCS 意味ねーし！と言っていたのに…ﾎﾛﾘ
・新人くんとの間に薄氷の信頼を築く←new!
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年11月30日
・DSL 作って XML 地獄を焼き払う
・書いてて良かったツールリファレンス
・お隣のプロジェクトにビルドと CI 導入
・新人くんとの信頼関係が少し進展
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年12月28日
・イテレーションふりかえり定着
・ヘルププロジェクトに CI 導入
・↑最初から計画してたからCI 自体は5分で載せられた
・新人くんがすごい成長率
・他プロジェクトがヘルププロジェクト DSL を導入検討中
・新人くんとの別れ ← new!
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年1月27日
・定期的に勉強会を開催することをチームで決めた
・みんながふりかえりの時間を楽しみにしていることが分かった
・ヘルププロジェクト DSL をお隣のチームが導入
・↑に合わせてマニュアル書いた
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年2月28日
・ステージング環境へのデプロイ自動化
・定期的な勉強会開催スタート
・ふりかえりが順調に根付いている
・神クラス四天王に第2撃
ちょっと物足りないな…(´・ω・`)
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年3月30日
・神クラス四天王の一角を崩した (並の中ボスくらいになった
・リリースレトロスペクティブ初開催
・全員が次回開催を要望
・Excel 変更履歴シートの撲滅
・チームメンバーが Vim をインストール←new!
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年4月28日
・タスクボード運用開始
・チームメンバー2人が Vimmer に٩(๑❛ᴗ❛๑)۶
・ふりかえりファシリテーター持ち回り開始
・社内プログラミングパズル開催←面白かった！
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年5月26日
・2人目のファシリテーターがデビュー
・品管さんにいろいろと控えてもらえるようになった
・突発作業が多すぎるので見積もりに利用できるように実績記録開始
・「リファクタリング？なにそれ美味しいの？」状態だったメンバーがいまや興味津々．今度勉強会することに
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年6月26日
・ふりかえり発でリファクタリングワークショップ開催
・"リファクタリングすげーいい" とのメンバーの声が！
・神 Excel をキリングしたぜｳｪｰｲww → それは余の細胞一つにすぎぬ…ﾌｧｯ!?
・↑その後，完全撃破(๑•̀ㅂ•́)و✧
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年7月31日
・知見共有会がほぼ定期的になった
・関係の深いシステムのエキスパートを招いて勉強会←すごく好評だった
・ペアプロハンズオン2回目開催
・残業とかないわーが完全に定着
変わったこと
- ふりかえりが定着した
- 勉強会が定着した
- 必要を感じたら知見共有会を突発的に開催
- 自動化 > 手順書 > なんとなくの口伝、が定着
一番大きく変わったこと
1人で始めた活動ですが、今はもうそんな雰囲気はなく、チームメンバー全員で改善活動をしている、というのが実態です。
改善そのものもですが、やっぱり、チームメンバーも少しずつ変わっていきました。なので、これが契機！というものはなかなかありませんが、その中でもふりかえりはインパクトが強かったようです。
特に、ふりかえりは自分を含めたチームメンバーに大きな影響を与えたと思います。
2週間ごとのふりかえりでは、「計画どおりに行かないのはなにが原因か」「ならば、なにをどのように変えていけばよいか」という雰囲気と意識が生まれました。そして、それを繰り返していくうちに、問題を個人のものとするのではなくチーム全体の問題として共有し、みんなで解決していこうという雰囲気が定着しました。「自分はスキルがないから…」という人も「自分にできることはないか？」と動いてくれるようになり、逆に「スキルがない人はちょっと黙ってて」と言っていた人 *2 が他の人の意見を求めるようになったりと…人によって程度は違いますが、それでも、ちょっと1年前からは考えられないくらい、メンバー全員が変わりました。もちろん、自分自身もです。
まとめ
改善活動に明確なゴールはないと思っています。なぜなら、ある目標を達成したとしても、翌日になってみるとそれが新たなスタートラインになっている、そう感じるからです。
改善活動に対するチームの今のスタンスは、「ときにはダレたりするかもしれないけど、できるだけペースを守ろう」「少しずつ進めていこう」です。というのは、急激な改善を行うと一時的には大きな成果が出るけれども、そう遠くないうちに無理が利かなくなり、息切れしてしまうことをみんなが実感しているので。このスタンスは今後もどんどん変わっていくかもしれませんが、今はこれがチームの共通理解となっています。
1年間を振り返ってみて、これからも改善活動を続けていきたい、そう思っています。
Java で -server オプションを付けたら4割近くも速くなったメモ
Java で -server オプションを付けたら4割近くも速くなったときのメモ。
動機
ログファイル中の XML をパースして XPath で抜き出す調査用のツールを使っていたのですが、本番機 / ステージング機と開発機で実行速度に大きな差がありました。本番機・ステージング機・開発機はハードウェアのスペックからしてまったく違うとはいえ、同じログファイルに対して実行したときの TAT が2倍以上違うとかもザラにあり、少し調べてみました。
開発機では Client VM が使われていた
開発機の OS が 32bit Windows のため、デフォルトで Client VM が使われていたのが原因でした。java コマンドに -server オプションを指定して Server VM で実行するようにしたところ、TAT が4割近くも短くなりました。ちょっとしたツールだしあまり変わらないだろうと思っていたのですが、全く変わるものなんですね。
大雑把な計測結果をメモしておきます。
# Client VM で実行 PS >1..10 | foreach { Measure-Command { java -client Hoge }} | measure -Average TotalMilliseconds Count : 10 Average : 32756.72687 Sum : Maximum : Minimum : Property : TotalMilliseconds # Server VM で実行 PS >1..10 | foreach { Measure-Command { java -server Hoge }} | measure -Average TotalMilliseconds Count : 10 Average : 24059.97238 Sum : Maximum : Minimum : Property : TotalMilliseconds
ユースケースを元にキャッシュ化
Server VM を使うことで相当に速くなったのですが、使っていたツールの使われ方には以下のような偏りがあったので、
XML のパースと XPath での抜き出しは初回のみ行い、以後はそのキャッシュに対して「ごく一部」を適用するようにしてみました。
# 事前にパースしてキャッシュしておき、それを使うようにする PS >1..10 | foreach { Measure-Command { java -client -Dcache=enable Hoge }} | measure -Average TotalMilliseconds Count : 10 Average : 2667.87865 Sum : Maximum : Minimum : Property : TotalMilliseconds
圧倒的に速いですね。桁が1つ減りました。ちなみに、キャッシュからの検索には PowerShell の Get-Content と Where-Object を使っているのですが、grep コマンドに置き換えたらミリ秒で終わるようになりました。本番機・ステージング機で grep コマンドが使えないのが残念ですが、Get-Content と Where-Object を使う版でも2, 3秒で終わるのでまあいいかな、というところです。
