13082012 work
事務局力のススメ。技術としては面白かったけど、これに頼ったジョブはどうなんだろうね。
「管理職を目指す行動指針」では管理職にするらなれない
評価制度に関しても
短期的な評価の積み上げが長期的な出世につながる人事評価メカニズムは、近視眼的な思考を促す。その結果、視野の狭い仕事だけで評価された人が管理職になって、経験不足で失敗することになる
と、客観的にみている。そういう状態で会社でうまくやるには事務局力をつけて裏方から仕事を動かすことを説く。まぁ、普通は転職と天秤に賭けるんだろうけど、本書は如何に頑張るかという内容なので、そういうことは書いてない。
13082012 life
小さく賭けることの利点は失敗を予測し、許容できることである。「素早く学ぶために素早く間違える」というのは探索的な研究においても重要だと思う。予測モデルつくるために境界がしりたいってのもあるしね
小さな賭けの原則
12082012 life
僕はFacebookが好きではなくて、というよりGoogle+派。
Google+がいいなぁと思う理由の一つにサークル機能があるが、そのサークル機能をつくったヒトの著作なので、面白かった。
色々SNSをつまんでいれば、なぜそういう設計になっているかとか理解できて楽しいし、おそかれ早かれ、企業の研究所もそういう仕組を取り入れなきゃならんだろうから、どういう設計にしよーかなーと色々考えるネタが脳内に投入されて楽しめる。
本書の主張は
ソーシャルネットワークは独立したグループが結びついて形成されている
であり、
社会の中には極端な影響力を持つ人物が存在し、情報の拡散には彼らが欠かせない
とは対立する考え方である。これはマルコム・グラッドウェルの「インフルエンサー」の話ですね。この発想は「世界がどのように動いているかという事実よりも、どのように動いて欲しいかという期待に基づいたものだ」と切り捨てている。神撃のバハムートなんかは実際どうだったのか気になる。
情報の拡散に関してはなかなかおもしろい考察だと思う。
ある情報が広く伝わるかどうかを左右する最も重要な条件は、影響力を持つ人物がいるか否かではなく、影響を受けやすい人物が十分に存在し、彼らが同じように影響を受けやすい人々とつながっているか否かである
放射脳系のヒトとかそんな感じかなぁ、あと津波の人情系のtweetが拡散した時も同じような構図だったかもしれない。影響を受けやすいってのは、内容とかによっても閾値が変化するだろうけど、脊髄反射レベルのretweetは「あーあれ系かー」ってなるしね。
まとめ
ソーシャルネットワークは目新しいものではなく、ソーシャルウェブは一時的な流行ではない
10章の結論に、これから数年でどうなりそうかというようなことが幾つか書いてあるのだけど、それは本を読めばいいと思う。
その他メモ
11082012 栃木
実家に戻っているので鬼怒グリーンパークの水上アスレチックに連れて行った。小学校低学年だと一周するのに1時間以上はかかるので、子どもはもちろん、親も疲れる。
僕は水に濡れていい靴じゃなかったのと、iphoneをポケットに入れてたので、ついて回る専門で。
これはやったけど、ロープは腕が辛い。というより、自分のイメージよりも身体が動かなくて凹む。
全部で30のアトラクションがあって、これは最後の方の丸太の橋だけど楽勝。最後のほうには他にロープの端が二種類くらいあって、そっちは難易度高め。
やり遂げた感。
夕方昼寝をしたので、夕食後花火をした。
なかなか楽しい一日だった。
MagitのRewritingがよく分からなかったので、色々触っていたらなんとなく理解したけどgit rebase -iとどこが違うんだろう？
ちなみに、M-x magit-statusを毎度叩くのも飽きたのでC-x gに割り当てました。
(global-set-key (kbd "C-x g") 'magit-status)
まずはl lでログリストを出して、修正の起点のコミットログでr b(begin)を押す。
すると、magit-statusでそれ以降のコミットログがpendingされたコミットになっているので、修正したい順番にAを押していく。きちんとコミットされるとpendingのステータスが*(未使用)から.(使用済み)に変わる。r .とかr *でも状態変更はできる。
これはgit rebase -iでコミットログの順番を変えるのとほとんど一緒だと思う。
まとめてコミットしたい場合はaをつかえばいいんだけど、コンフリクトしたりしてなんか挙動がいまいち掴みきれていない。
最初の方はなかなか思い通りにいかなくて最初からやり直したいことが多いが、そういう場合に破棄するのはr a(abort)でOK。
慣れるまではcloneしてテスト用のリポジトリで作業してみて、OKだったらもとのリポジトリで修正すんのがいいのかもしれない。
l hでReflogが出るのでAを押すとコミットが取り込まれる。
Git初心者が絶対に覚えておくべきコマンドをMagitでやるには。
通常コミットするときはステージに上った状態でcを押しコミットログのためのメッセージを編集した後C-c C-cします。
ここでC-c C-cではなくC-c C-aするとamandのための編集画面になります。
Amend: "yes" -- End of Magit header -- second commit # コミットログメッセージ
あらためてC-c C-cすればamendされます。
magit-statusしてステータス画面を出したあと、Headの行にカーソルをあわせてxを押す。
デフォルトは git reset HEAD^となります。
ログ画面でxを押すと対応するとこまでresetされます。
magitの場合、元サイトのようなミスは起こりにくいと思いますが。
magit-statusでr bを押すとrewriteがはじまるので、aとかAとか押したりして歴史の修正をしていく。
実際やってみたけど、ちょっとややこしいのでRewritingのセクションをきちんと読んだほうがいいのか。
あとでちゃんと理解しておこうっと。
10082012 git
GitとGitHubの入門的なハンズオンをやります。独りで一通り使えるようになることを目指す内容になっています。
既に枠は埋まっていますが、キャンセルがぼちぼち出ているので登録しておくといいかもしれません。懇親会のみの参加もおそらく可だと思います。
今回はweb系（デザイナー？）っぽい方々がちらほら参加されているのでちょっと楽しみですね。
10082012 Ti
色々はまったのでメモ。
参考
-Switch between Xcode 4.3 and other Xcode versions (Xcode 4.2 and lower)
アプリを実機に転送する際にfile not found error。.mobileprovisionファイルを該当する名前でエラーの出たディレクトリにコピーすることで解決。これは何がおかしいのかよくわからん。
プロビジョニングのとことかきちんと理解してなくて本のとおりになぞっただけなので、そのうちきちんと理解しないといけない。
実際に動かしてみた感じではjQuery Mobileよりもなめらかに動いて良い感じ。
08082012 work
ちょっと人情系入りすぎだけど、改善した後の短縮された時間をどう使うのかという認識が一致していないとうまくいかないというのは盲点だった。
たとえば導入した結果、従来と同じ量の製品をつくるのに要する時間が、一時間短縮できたとする。この短縮した１時間をどう使うのか。そこをはっきりさせておかないと、時間を短縮した意味がなくなる。
自分の場合、効率的に仕事をして、余った時間は「より高度なことにチャレンジするか、早く帰って家で新規な技術を試すかっていうこと」に突っ込むの当たり前じゃんって思ってたので。
単に時間労働って考えている人にとっては時間ギリギリまで引き伸ばすのは当然の事なので違和感を感じるのかと気づいた。思い返せば確かにグダグダ言ってるな。
事実は起きた瞬間に事実ではなくなり、見たものの主観に左右されてしまうからである。主観で書かれたものは、もはや事実ではない。
プロジェクトの報告もプロジェクト側から語られるものはそういう性格を帯びる。そういうのを客観的に眺めたくて色々チャレンジしているところ。
僕もホウレンソウのうち報告と連絡は無駄だと思っている。あんなのはコンピューターが定期的にレポートを出して、相談に時間を費やすべきであろう。
答えは、ひとつ。あくまでも「後工程」にとってムダかどうかである。
これはどうなんだろう。ちょっと悩んでいる。生産だとシーケンシャルだから、後工程ってのは直後の行程であることが多いだろう。多次元最適化とかやってる場合後工程ってのはデータが全部出揃ったとこのことなのだろうか？
失敗を貴重な体験と考えよう！
07082012 twitter-bootstrap
最近Twitter Bootstrapばかりいじっているので、カスタマイズのやりかたが非常にきになって仕方がない。LESS覚えないといけないけど、それはあんまり問題じゃなくて、アップデートに柔軟に対応できるような構成にしておくのが重要だったりする。
できるだけカスタマイズ性をあげつつ、一方で更新に対応するため、bootstrap自身はできるだけ触らないようにするにはどうしたらいいか探してたら、sofに2つほどやり方載っていた
Twitter Bootstrap Customization Best Practices
変数の設定とミックスインの設定をした後に独自の定義を施したlessを読み込んで上書きする。
// CSS Reset @import "reset.less"; // Core variables and mixins @import "variables.less"; // Modify this for custom colors, font-sizes, etc @import "mixins.less"; // Custom Addons @import "addon-file.less"; // <--- My custom LESS addon // Grid system and page structure @import "scaffolding.less"; ...
bootstrap.lessに手を入れちゃうので、更新するたびにこの一行を書きなおす可能性があるかも。あんまり気にならないのかもしれないが。
bootstrapは適当なディレクトリ(この場合はbootstrap)においておいて、bootstrap.lessとvariables.lessをコピーしてくる。bootstrap.lessはtheme.lessに名前を変える。
裏方ほどおいしい仕事はない!
小さく賭けろ！―世界を変えた人と組織の成功の秘密
ウェブはグループで進化する ソーシャルウェブ時代の情報伝達の鍵を握るのは「親しい仲間」
実用Git
入門Git
Titanium Mobile iPhone/Androidアプリ開発入門―JavaScriptだけで作る
「トヨタ流」現場の人づくり―トヨタ元生産調査部部長が明かす (B&Tブックス)/Website
theme.less
variables.less
/bootstrap
variables.lessは好き放題変更を加える。theme.lessの方は変更を加えたvaliables.lessをimportするようにして、残りはbootstrap/*.lessをimportするように修正を加える。
こうしておけば、bootstrap以下は常に安全に更新できる。
特にgit cloneしたtwitter-bootstrapの場合、git pullで安全に更新することができるのでこっちのほうがいいかもしれない。
今度つくるサイトはこの方法でやってみる。