Excel2013のVBAでセルの文字列とワークシート名をマッピングさせるような処理を書いていたんだけれども、何故かエラーになった。 デバッグしてみたところ、単純にワークシート名が違っていた。
どうやらワークシート名はExcelの制限で31文字までしか指定できないらしい。 31文字目まででマッピングさせるような処理に修正。 （ちゃんとやるならその制限ありきでルールを見直すべきですね）
なお全角でも31文字のワークシート名は指定できたので、バイトではなく本当に文字数の制限みたい。
順に固める構造
ソフトウェアデザインパターンの源流になったらしい、建築家クリストファー・アレグザンダーのパターン・ランゲージ。
施工に関する項目に「208.順に固める構造」というものがある。
本を読んでないのでウソかもしれないが、どうも「独自の敷地や地域の微妙な条件に順応できるように、むしろ厳密でない流動的な計画案を作成すべきだ」ということらしい。
ソフトウェアより遥かに柔軟性で劣る（と思われる）建築の世界ですら、「計画のし過ぎ」をアンチパターンにしているとは、実に興味深いものである。
ユーザストーリーマッピングを読んだ。 #UserStoryMapping
この本は、ユーザーストーリーマッピングの勉強会に行ってきた時にワークショップで体験して、とてもいい！と思って読むことにした。
ユーザーストーリーマッピングはプロダクトの全体像を俯瞰でき、立場の異なる人々の共通理解を形成し、事業戦略から開発戦略までを結びつるための素晴らしい手法だと思います。
今すぐに5章を読みながら、誰かと一緒に試してみるといいですね！
銀の弾丸などない
もちろんユーザーストーリーマッピングを使ったからうまくいくわけではない。
筆者がその点もメッセージに込めていると思っていて、ユーザーストーリーマッピングですらも含めて手法はあくまでも手法でしかないとことが伝わってくる。
「こういう手法や事例があるよ、こうやるとうまくいくよ」
→でも手法なんてあくまでも手法に過ぎないからね！
という、何だか自分で上げて自分で落とすみたいな流れが基本。
例えばユーザーストーリーのテンプレートを紹介しておきながら、「テンプレートに縛られちゃダメだ！」みたいな。
じゃあどうすればいいのか、どうやればいいプロダクトが作れるかってことについては本質的なところを繰り返し語っている。
- 共通理解を作ることから始める
- ストーリーは書くものじゃない、語るもの。語りあわなくちゃ！
- 何をやらないかが重要！
- 僕らはたぶん間違っている
- 学ぶことが何より大切！
大きな気付き
この本を読み終わったあと、お風呂の中に入って思い返してたら、自分の中ですごく大きな気付きがあった。
そうか、プロダクト開発やサービス開発は学習を前提にやるということかと。
如何に学びを最大化するかを重視すべきなのかだと。
例えば人も物もお金も時間も十分にあったとして、それでも小さく作るのはなぜか？
なぜ「何をやらないか」が大切なのか？
その答えが言葉として自分の中で見つかったのが大きかった。
わかっている人からすれば当たり前なのかもしれないけど、この気付きを得られただけでも僕はこの本を読んだ価値があった。
おまけ：バケーションの写真
この本の中で共通理解を失わないために、記憶を呼び起こすものをちゃんと残しておくのが大切と語っている。
その比喩として「バケーションの写真」というのを使っており、それがとても気に入った。
バケーションの写真は何も知らない人が見たらただの写真だけれども、当事者にとっては記憶を呼び起こすものになる。 旅行の写真を見れば、色々な思い出が蘇ってくるように。
今までドキュメントを一生懸命書いてきたけれど、どうやら文字だけで完璧に情報を伝えるのは不可能なようだ。 だけどアイデアやストーリーは放っておくとすぐに蒸発してしまう。
だからストーリーを語り継げるようにバケーションの写真を作ろう。 これが、未来のドキュメントのあるべき姿なのかもしれない。
勉強会に行った時のブログ
Tweet
共通理解と同時に、共通言語を形成していくこと（ができる）も大切なことなのかも。#UserStoryMapping
— すーくん (@su_kun_1899) 2016年3月31日
変化に適応するとは、きちんと学習すること。
— すーくん (@su_kun_1899) 2016年4月2日
変化を前提にすると制約が変わってくる。
誰も正解なんて知らないし、正解すら変化していく。
面白い。#UserStoryMapping #気付き
ユーザーという言い方はやめる。
— すーくん (@su_kun_1899) 2016年4月2日
ユーザーが1人だけであることはまずない。
ちゃんと具体化して語らないと。すごく大事。共感する。#UserStoryMapping #共感
矛盾するニーズを持つ人々のために問題を解決しようとして誰も喜ばないソリューションになる#userstorymapping #それな
— すーくん (@su_kun_1899) 2016年4月11日
「無駄なものを作らない」っていうのは、コスト削減だとか生産性向上のためじゃない。
— すーくん (@su_kun_1899) 2016年4月19日
最も高い学習効果を得るためなんだ。
だから予算が潤沢にあろうが期間の制約がなかろうが、「最小限で最大限の成果が得られるものは何か」に取り組まなきゃいけないんだ。#UserStoryMapping
それだ！
— すーくん (@su_kun_1899) 2016年4月23日
"リリース後に加えた改良はもっとも価値がある"#UserStoryMapping
MySQLではIN句とサブクエリの組み合わせはインデックスが効かない #mysql
select * from がダメな理由
概要
select * from ~ のように、アスタリスクで取得項目を絞らないことが性能に悪影響を与えるのはなぜだろうか？
ワーキングメモリを無駄遣いする可能性
不要なカラムを大量に読み込んで処理する場合、その分余計なメモリを使用することになる。
ワーキングメモリが足りなくなった場合、例えば一時表やクイックソートを使う実行計画になる。
一時表であれば、当然一時表を作成し検索するためのIOが発生するのでそこが性能に悪影響を与える可能性は高い。
余分なIOが発生する可能性
本来インデックス領域アクセスだけで解決出来たものが、テーブルアクセスまで発生してしまうと、その無駄な読み込みが性能に悪影響を与えてしまう可能性がある。
最終的な取得項目や結合・検索条件が、インデックス領域のみで解決できるならそうすべきである。
（性能のネックになるのは基本的にIOなので。）
ちら裏
ある程度以上のデータ規模があるなら、やっぱりベタなSQLが書けるORマッパーの方がいいんじゃないかなぁー。
ただ複雑なSQLが必要とされたりする場合は、設計がイケてないか、RDBで保持するのが妥当でないデータな可能性が高いとのアドバイスも頂いた。
それはまったくもってその通りだと思う。
アウトプットする習慣
僕は何でもかんでもesa.ioにアウトプットしています。
- 業務で得た知見
- 誰かに教えてもらった技術
- 真面目なポエム
- どうでもいい話
- エトセトラ、エトセトラ
今日お昼行った時に、
「（アウトプットするのは）そういう人（性格）だからですか？それとも前の現場がそういう文化だったんですか？」
と聞かれて思ったこと。
僕はチームで仕事をしたい
- 自分が困っていれば助けてほしい
- あなたが困っていれば助けたい
- 自分の経験はチームの財産にしたい
- あなたの経験をチームの財産にしてほしい
- 自分が何を考えているか知ってほしい
- あなたが何を考えているか知りたい
僕はチームで仕事をしたい。
だからアウトプットする。
以前メール文化な現場にいたときの話。
使われていないRedmineがあった。
とても小さなことだったが、あれは間違いなく僕のキャリアハイライトだ。
HubotをHerokuにデプロイして、Slackと連携する
Hubot
基本は公式にならえばOK
https://hubot.github.com/docs/
Slack で Hubot を使えるようにする - Qiita
Heroku
Heroku Toolbeltをインストールはドットインストールを参照した
dotinstall.com
ssh鍵が無かったら作る
ssh-keygen
herokuでssh鍵が自動でアップロードされなかった
明示的にアップロードして対応
ID-Blogger: HerokuでSSH公開鍵(public key)を登録する方法(と削除して再登録する方法)
herokuデプロイ
https://hubot.github.com/docs/deploying/heroku/
herokは無料プランだと止まる
Heroku Schedulerを使う。
カード登録してないと、無料のアドオンも登録できなそう。
HubotをHerokuのFree dynoに対応させる | スペースマーケットブログ
