Hatena::ブログ(Diary)

kei-os2007 against the machine!! このページをアンテナに追加 RSSフィード

2011-05-08

久しぶりすぎる更新

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

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

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

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

2010-05-30

[] ひさびさ更新

前回のエントリから、ずいぶんと期間が空きましたが、またぼちぼち書いていきます。

2009-01-28

[][] デブサミ2009 行きます


デブサミ2009ですが、2/12(木) に行く予定です。

デブサミはまだ行ったことないので楽しみ。

http://codezine.jp/devsumi/2009/



2009.02.01 追記

kissrobberさんから、デブサミ2009のセッションをじっくり選ぶサイトを

コメントしていただいたので、リンクはっておきます。

(kissrobberさんが作られているサイトのようです)

Do I like programming? - FC2 BLOG パスワード認証


セッション登録画面からセッション説明を確認するのが

デブサミのオリジナルサイトよりやりやすくなっています。

かゆいところに手が届く感じですね。

2009-01-18

[][] 下っ端でも何かを成し遂げる方法 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

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

Joel on Softwareとあわせて読むとよいのでは?と思うものを書いておきます。

読書量は決して多くないですし、既にネット上でも言及されまくりの本ですが

未来の自分へのメモ書き、ということで。

組織の規模や特性によって、考えるべきこと、成すべきことの違いが

それぞれの本にあらわれていて面白いです。


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

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


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

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


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

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

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


年齢を重ねるにつれて、自分で自由に使える時間が減ってきているのを実感していて

時々、自分のやり方を見直して改善しないとなぁ、と思ってます。


で、いままでマインドマップを使っていなかったのですが

今年は使っていこうと思い、さっそく、シゴトで使ってみたところ

なるほど、考えていることがイメージとして頭に浮かびやすくなりました。


マインドマップを始めるに当たって読んだのは

マインドマップ超入門、という本で

タイトルどおりに超入門できました。

これはもっと身につけたいぞ、と。


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

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



あと、年明けてすぐに、なにげに「レバレッジ勉強法」を読んでみました。

考えなくてもまわる仕組み、に、もっと意識的にならなければ、と思った次第です。

自分への投資は欠かせないなぁ。がんばらねば。


レバレッジ勉強法

レバレッジ勉強法

2009-01-06

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


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とかにしてしまえばよいかな?と思っていたり。

2009-01-04

[][][] Verilogパーサで抽象構文木を生成するようにした


Verilogファイルから、抽象構文木を生成できるようにしました。

処理できる構文はまだまだ限定的ですが。。


Haskell Parsecで直接扱うことのできない左再帰の構文を

再帰に変形している部分があるのですが (expression構文のところ)

ここをパースして右再帰に変形前の構造に戻して構文木を作る処理で

ちょっと頭がこんがらがりそうでしたが(こんがらがりました)。

(左再帰のところは、chainlとか chainl1をうまく使えばよいのかな??)



このブログを書いてる時点のソースコード

http://github.com/kei-os/vparsec/tree/ccd8e9ceea5794b7b64acc366725bd967f61aa08


データコンストラクタとかデータ型の名前に迷いがあったり

多相的な型を使えばパーサをもっと簡潔に書けるんじゃない?とか

いろいろ思うところはありますが、とにかく

Haskell慣れしながら改善していきたいと思います。


いまのところ、生成した抽象構文木を printで出力するしか

確認する方法を用意できていませんが

今後は、確認しやすい形式でダンプする仕組みを用意できればと思っています。

また、モジュールインスタンス化など、モジュールの階層構造を

うまく表してみたいと思っています。

(あと、やっぱりこまめにブログに書いていこうかと思います。

 それとスピードが必要><)


とりあえず、実装したものをいくつかと、パース実行結果を記載しておきます。

  • 代数的データ型 (ソースから抜粋)
  • パース実行関数 (ソースから抜粋)
  • ghci実行例 (実行ログ)

続きを読む

2009-01-03

[][] 今年は「射撃しながら前進」


前から読もうと思っていながら読めてなかった 「Joel on Software」を読んでる。

射撃しながら前進〜!!

これだ。


Joel on Software

Joel on Software

2008-12-31

[] 2008年の振り返り


2008年も最後の日になったということで

来年の自分のためにも、今年一年を振り返っておきたいと思います。

ことしは四半期ごとのまとめがやりやすいらしい。


Q1 (1〜3月) - ネタ探し期

去年の秋頃から

「カイシャの中だけで力を発揮するのではなくて、一個人のエンジニアとしてアイデンティティを確立したい」

みたいな気持ちが強くなってきていたのですが

それで、「カイシャとぶつからない領域で何ができるか?」みたいな

自分探しというか、ネタ探し中心の時期でした。

そういうわけで、自分の心が何に反応するかみてみようと

いろいろと自分に刺激を与えていたようです。


で、なんかコンパイラに興味を持つようになって yacc/lexの勉強を始めたり

小さな言語を作ってカイシャの仕事に適用したりして

コンパイラの雰囲気をつかんだりしていました。



Q2 (4〜6月) - 変化期


4月には今年一番のショックでもあり変化の材料でもあった

PowerBook G4が盗まれる出来事 がありました。

もろもろのデータが失われたのは痛かったですが(とっても><)

これを機に MacBookProを新調し、開発環境は快適になっていきました。


データを失ったのを教訓に、とにかくメモをいろいろとブログに残すようになりました。

それで、Vimperatorを使い始めたのをきっかけにヘルプを日本語に訳したエントリーを書いたら

このブログで今年最多アクセスのエントリーになってしまいました。

Vimperatorのヘルプを日本語にしてみたよ - kei-os2007 against the machine!!

いやいや、ほんとテキトーに書いてたので申し訳ないんですが...直すのもアレだったので。


この時期は Linuxデバドラの勉強してました。

YLUGのことを知ったのもこの時期。

それから Twitter始めました。

6月くらいからは、ブログを書く頻度を下げたかわりに

メモ書き中心だった内容を、人に読んでもらうのを意識しながら書くようになってきて

行動が外向きに変化してきたように思います。



Q3 (7〜9月) - 出撃期


イベントやこれまで参加したことのなかった勉強会に足を運んだ時期でした。

第1回 VimM勉強会に参加して LTできたのは良い経験でした。


あと、ブログに書いてるのはこんな感じ。



勉強会の内容だけでなく、いろいろな人に会ってお話して

人とのつながりができたのが収穫でした。

そして、もう孤独じゃないんだ、と。


Q4 (10〜12月) - 開発期


土日は子守りで家にいることが多かったので、イベントに出かけられず

少し歯がゆい状態でしたが、夏頃から Haskellの勉強していたのを

具体的な成果物につなげるべく、Haskell Parsecライブラリを使って Verilogパーサを書き始めました。

githubリポジトリを活用した開発サイクルが身についてきました。

(いまのソースコード)



というわけでまとめると


カイシャの枠組みでのエンジニア活動だけでなく、個人として動き始めることができた年でしたが

まだスピードが足りないなぁ、と思うし、思い切りも足りないなぁ、と思います。

もっとフットワークを軽くして、来年は小さなアウトプットをたくさん出して

小さく繋いでいくようなやり方を意識する必要があるかもしれないです。


今年 1年間、kei-os2007 against the machine!! に来てくださった皆様

どうもありがとうございました。

あまりブログには書いていませんが、読んでもらえているということが、とても励みになっています。

来年は、このブログを通じて何かお返しできればいいな、と思います。


とりあえず、年明けからはまた週末のイベントには参加できそうです。

(子守り強調月間もおわったので)

2009年、走ろう!


来年もどーぞよろしくです!


追記

「最多アクセス数」といっているのは、google analyticsで見た結果です。

下図のアクセス数のグラフは「週ごと」で出しています。

PVの上位5つが出てますが、Vimperatorのエントリーへのアクセスが最多なんですね。

f:id:kei-os2007:20081231234120p:image

2008-12-13

[][][] 抽象構文木をどうしようかと


とりあえず Verilogシンタックスチェックできる程度、ということで

(意味解析してないから、たとえば入力ポートの信号と input宣言の信号が合ってなくても文句言わないくらいザルですし)

遠くを見ると気を失いそうになるのですが

わからないことを書き出して気持ちを楽にしながら進んでいくとします。

いや、ほんとわからないことだらけだなぁ。

でも Haskell Parsecとは仲良くなれてきたはず。


で、抽象構文木を作らなきゃ、ということで考えているのですが

ただ考えてもわからないと思うので、先人の知恵を拝借しようと


Icarus Verilogの実装をみたりしています。

http://sourceforge.net/projects/iverilog


あと、Ruby Hacking Guide (RHG)を読んだり、とか。

http://i.loveruby.net/ja/rhg/


それから「スクリプトエンジンプログラミング」の本を読んだり実装を見たり、とか。

スクリプトエンジン プログラミング

スクリプトエンジン プログラミング


まずはモジュールの構造を抽出したいと思っているのだけど

完全並列に実行するために必要な要素を、データ構造に仕込んでおきたいなぁ、とか考えたりすると

Icarus Verilogの実装が参考になるかな、と。

ツリー構造というかグラフ構造を意識しないといけないかなぁ、とか考えたり。


Haskellも Parsecじゃない部分(ふつうに Haskellな部分)と

仲良くなっていかないとなぁ。


ブログは頻繁には更新できていませんが、githubにはちまちまと更新しています。

もし気にしてくださってる方がいらっしゃいましたら

githubの方をウォッチしてみていただければ、と思います。

http://github.com/kei-os/vparsec/tree/master


あ、そうか、githubWikiつくったほうがいいな。

2008-12-03

[][][] 左再帰の除去についてプチまとめ


Verilogパーサを書き進めていくと、Verilog構文の左再帰に遭遇します。

Haskell Parsecは再帰下降パーサということで、左再帰の構文をそのまま書くと

stack overflowを起こしてうまく処理を続けられません。

うまいこと左再帰を除去(右再帰に置き換える)する必要があります。

というわけで、ドラゴンブックを読んで仕入れた知識をもとに

うまいこと左再帰を除去してみたので、書いておきます。


再帰の文法が

    A → Aα | β

のようにあるとき、↓のように置き換えていきます。

    A  → βA'
    A' → αA' | ε

とゆーわけで、VerilogBNFから、左再帰の部分を抜粋してみます。

<expression>
    ::= <primary>
    ||= <UNARY_OPERATOR> <primary>
    ||= <expression> <BINARY_OPERATOR> <expression>
    ||= <expression> <QUESTION_MARK> <expression> : <expression>
    ||= <STRING>

んー、このままだと、ちょっとわかりにくいので、変形してみます。

とりあえず A, α, βと対応させられるように、ということで。


変形その1

<expression>
    ::= <Beta>
    ||= <expression> <BINARY_OPERATOR> <expression>
    ||= <expression> <QUESTION_MARK> <expression> : <expression>

<Beta>
    ::= <primary>
    ||= <UNARY_OPERATOR> <primary>
    ||= <STRING>

構造が単純になってきました。

が、もうちょっと変形します。


変形その2

<expression>
    ::= <Beta>
    ||= <expression> <Alpha1>
    ||= <expression> <Alpha2>

<Alpha1>
    ::= <BINARY_OPERATOR> <expression>

<Alpha2>
    ::= <QUESTION_MARK> <expression> : <expression>

<Beta>
    ::= <primary>
    ||= <UNARY_OPERATOR> <primary>
    ||= <STRING>

単純な左再帰の文法にしか見えなくなりました。(見えなくなったはず!)


そういうわけで、この文法を右再帰の文法に変形すれば完了、と思います。


変形その3

<expression>
    ::= <Beta> <expression_>
    ||= <Beta> <expression__>

<expression_>
    ::= [<BINARY_OPERATOR> <expression> <expression_>]

<expression__>
    ::= [<QUESTION_MARK> <expression> : <expression> <expression__>]

<Beta>
    ::= <primary>
    ||= <UNARY_OPERATOR> <primary>
    ||= <STRING>

(たぶんこれでよいのではないかなぁ?)


Haskellコード

じゃ、この部分の Haskellコードです。

ソース全体は githubにて。まだまだまだまだ書きかけですが><

http://github.com/kei-os/vparsec/tree/master/Vparsec.hs


lexeme, tryを入れすぎな気もします。

まだまだ Haskell経験が浅いな。


expression :: Parser String
expression = do { a <- optExpression
                ; b <- expression_ <|> expression__
                ; return $ a ++ b }
        <?> "expression"
    where
        optExpression = try(primary)
          <|> try(do { a <- lexeme unaryOperator
                     ; b <- lexeme primary
                     ; return $ a ++ b })
          <|> string'
        expression_
            = try(do { a <- lexeme binaryOperator
                     ; b <- lexeme expression
                     ; c <- lexeme expression_
                     ; return $ a ++ b ++ c })
          <|> string ""
        expression__
            = try(do { a <- lexeme questionMark
                     ; b <- lexeme expression
                     ; c <- colon
                     ; d <- lexeme expression
                     ; e <- lexeme expression__
                     ; return $ a ++ b ++ c ++ d ++ e })
          <|> string ""