久しぶりすぎる更新

このブログも日記というよりもはや年記になっていて、やるやる詐欺、いや、書く書く詐欺になっているので、ここらへんでエントリー投入しときます。とは言っても、はてな記法もすっかり忘れているので、ひとまず手短なエントリーにしときます。

ここのところは、Android のポーティングやアプリ開発にシフトしているところです。ハードウェア系 (SoC とか) からは一旦離れて、組み込み LinuxC++Java の経験値を上げているところです。

Android のポーティングには、個人では BeagleBoard を使ってますが、最近、Kinect センサーを購入したので、Android + BeagleBoard + Kinect でちょっとまとめてみようかな、と思ってる次第です。ぼちぼちブログ書きのリハビリをしながら。

というわけで、久しぶりすぎる更新でした。

デブサミ2009 行きます


デブサミ2009ですが、2/12(木) に行く予定です。
デブサミはまだ行ったことないので楽しみ。
http://codezine.jp/devsumi/2009/


2009.02.01 追記

kissrobberさんから、デブサミ2009のセッションをじっくり選ぶサイトを
コメントしていただいたので、リンクはっておきます。
(kissrobberさんが作られているサイトのようです)
Do I like programming? - FC2 BLOG パスワード認証


セッション登録画面からセッション説明を確認するのが
デブサミのオリジナルサイトよりやりやすくなっています。
かゆいところに手が届く感じですね。

マインドマップ超入門 + レバレッジ勉強法


年齢を重ねるにつれて、自分で自由に使える時間が減ってきているのを実感していて
時々、自分のやり方を見直して改善しないとなぁ、と思ってます。


で、いままでマインドマップを使っていなかったのですが
今年は使っていこうと思い、さっそく、シゴトで使ってみたところ
なるほど、考えていることがイメージとして頭に浮かびやすくなりました。


マインドマップを始めるに当たって読んだのは
マインドマップ超入門、という本で
タイトルどおりに超入門できました。
これはもっと身につけたいぞ、と。


マインドマップ超入門 (トニー・ブザン天才養成講座)

マインドマップ超入門 (トニー・ブザン天才養成講座)



あと、年明けてすぐに、なにげに「レバレッジ勉強法」を読んでみました。
考えなくてもまわる仕組み、に、もっと意識的にならなければ、と思った次第です。
自分への投資は欠かせないなぁ。がんばらねば。


レバレッジ勉強法

レバレッジ勉強法

Joel on Software本と、あわせて読みたい

Joel on Softwareとあわせて読むとよいのでは?と思うものを書いておきます。
読書量は決して多くないですし、既にネット上でも言及されまくりの本ですが
未来の自分へのメモ書き、ということで。
組織の規模や特性によって、考えるべきこと、成すべきことの違いが
それぞれの本にあらわれていて面白いです。


スーパーエンジニアへの道―技術リーダーシップの人間学

スーパーエンジニアへの道―技術リーダーシップの人間学


ハッカーと画家 コンピュータ時代の創造者たち

ハッカーと画家 コンピュータ時代の創造者たち


Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

下っ端でも何かを成し遂げる方法 from 「Joel on Software」


今年にはいってから Joel on Softwareを読んで
先日書いたエントリーで、今年は射撃しながら前進 (15章に書かれている)を
引用しましたが、あと 1つ、とても心に残った章があったので
メモに残しておこうと思います。

第31章 下っ端でも何かを成し遂げる方法


たとえチームの中でたいした権限が与えられてない状況にあったとしても
自分のチームを下から改善する戦略、ということで
5つの戦略について書かれています。


戦略1: 実行あるのみ

個人が実行するだけでプロジェクトをずっと改善できることはたくさんある。
デイリービルドするサーバがないって?作ればいい。

「この仕組みがなくて効率悪いなぁ」とか思ってることがあるなら
どんどん自分で仕組みを作って改善していこう、ということです。
自分でやれることはやる、ですね。

戦略2: じわじわと広めていく

たとえば、あなたのチームでは誰もバグデータベースを使おうとしなかったとする。
そんなことは気にしないことだ。
あなた自身のバグトラッキングをただ続けていればいい。
(中略)
いつかは彼らもバグトラッキングの価値を理解し、
それを使い始めるだろう。

じわじわと、というところがポイントなんでしょうね。
良さを押し付けるのではなく、良さに気づかせる。
使おうと思わせる。

戦略3: 優れた人間を作り出す

できるようになりたいと思っていて、
なおかつその能力がある人々を見付け、
彼らをあなたの味方に付けるのだ。
(中略)
彼らを助けてやること。
彼らが学べるようにしてやること。

味方を見つけよう。そして支援しよう。

戦略4: 間抜けを無力化する

まずいコードを書く人への対処は
その人のコードをスクラッチから書き直そうとするのではなく
ただバグを報告し続けることで、動きを封じること、とのこと。
動きを封じられないように心がけないと、ですね><

戦略5: 邪魔を避ける

残念ながら、作業環境の変更は、どんな会社でもほとんど不可能だ。
長期リースであるために、CEOでさえ、それについては何もできないかもしれない。
(中略)
そのような環境から逃れる方法を探すこと。

人と作業時間をずらしたり、静かな場所を探したり。
自分もまわりがうるさくてどうにもならない、というときは
空いてる会議室を探して逃げ込む、とかの手は使ってますね。
避難できる場所を見つけておくとよいですね。

戦略6: かけがえのない存在になる

あなたが本当に優れた貢献者でなければ、
これらの戦略はどれも機能しない。

きちんと自分の成果を出しながらも
チームの改善につながることをせっせとやる、ということのよう。



それから最後に、

あなたは管理する立場にいなくとも、物事を改善することはできる。
しかしあなたは、シーザーの妻である必要がある。
疑惑を抱いてはならない。
そうでなければ敵を作るだけだろう。

で締めくくられています。
敵を作るだけに終わっては損ですよね。


チームがよくない、まったくやってらんねーよ、という場合でも
腐らず、まずは自分のできるところから実践して
チームを変えていけばよいのだと思います。
とにかく半径 1メートルから改善していけばよいのですね。
(本当に危険な状況で逃げたほうがいい、という場合は、逃げる必要がありますけどね)


Joel on Software

Joel on Software

抽象構文木のダンプ準備(代数的データ型の出力練習)


Verilogパーサで生成した抽象構文木のダンプ準備として
代数的データ型を出力するコードで感じをみてみました。


webで読むことのできる Real World Haskellベータ版の
JSONデータを操作する章を参考にしました。
Chapter 5. Writing a library: working with JSON data


いまは変更されて無くなっていますが
以前はこの章に forM_ を使ったサンプルがありました。
forM_ に慣れておきたいので、練習では使ってみています。

$ cat DumpTest.hs

module DumpTest where

import Control.Monad(forM_)

data Foo = FStr String
         | FInt Integer
         | FBool Bool
         | FNil
         | FObj [(String, Foo)]
         | FBar Bar
         deriving (Show)

data Bar = BStr String
         | BInt Integer
           deriving (Show)

printBar :: Bar -> IO ()
printBar (BStr s) = putStrLn $ show s
printBar (BInt i) = putStrLn $ show i

printValue :: Foo -> IO ()
printValue (FBar f) = printBar f
printValue (FStr s) = putStrLn $ show s
printValue (FInt i) = putStrLn $ show i
printValue (FBool True) = putStrLn "true"
printValue (FBool False) = putStrLn "false"
printValue FNil = putStrLn "nil"
printValue (FObj xs) = do
    putStr "{ "   
    case xs of
        [] -> putStrLn ""
        (p:ps) -> do putPair p
                     forM_ ps $ \q -> do putStr ", "
                                         putPair q
    putStrLn "}"
        where
            putPair (k, v) = do putStr $ show k
                                putStr ": "
                                printValue v

-- test data
dat :: Foo
dat = FObj ([("a", FInt 10), ("b", FStr "foo"),
            ("c", FNil), ("d", FBool True), ("e", FBool False),
            ("f", FBar (BStr "bar"))])


ghciで動作確認です。

$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.

Prelude> :l DumpTest
[1 of 1] Compiling DumpTest         ( DumpTest.hs, interpreted )
Ok, modules loaded: DumpTest.

*DumpTest> printValue dat
{ "a": 10
, "b": "foo"
, "c": nil
, "d": true
, "e": false
, "f": "bar"
}


あと、putStrとか putStrLnしているところを
ファイルI/O処理にしてファイルに書き出します。
というか JSONとか YAMLとかにしてしまえばよいかな?と思っていたり。