心底欲しいものは口に出来ない法則 - p0t

「要領が悪く、無能な人間に見られたくない。」

というのを自分が心底思っていて、それゆえに「忙しい」という発言に抵抗があるのかと思うと我ながら結構恥ずかしい。

ホントに、

「金が欲しい」

とか、

「モテたい!っていうかもっと言うと老若男女にチヤホヤされたい!」

とかは全然言えるんですが、

「忙しい」

というのはもう単純に生理的嫌悪感になっていて一回でも口に出すのもはばかられる感じでした。

5年前にはこんなエントリーを書いてることからも症状は深刻です。

「無能に見られたくない」

というのはもっとプリミティブに分解すると、

「理性的でありたい」「知的でありたい」

というロジックが幅効かせてる業界(コミュニティー)の人の共通の欲求であり、絶対善(=カッコいい)みたいなところがあるのかなと思います。ちょっとそれは柔軟じゃないというか、自由じゃないなと思ったのでチャンスがあったら「忙しい」って言ってみようと思ってました。

この間、仕事の都合で美容室の予約を当日にキャンセルしてずらしてもらいました。もちろん美容師さんはコミュニケーション能力が高いので、

「仕事忙しいんですか〜?」

とか聞いてきますわな。今までだと、

「ぼちぼちですねー」とか「そうでもないですねー」

とか言ってました。今考えると、いやそこは話しの掴みとしてもってこいな話題で、そう答えたら話し続かなくて相手も困るだろう。と思うんですが、「忙しい」が放送禁止用語かっつーぐらいの鬼回避を見せてました。しかし、今日の俺は今までの俺じゃない!予約一回キャンセルしてるんだしここで言わずしてどこで言う?

I can fly! ミζ゜

「そうですね〜、ちょっと忙しいですね〜。」

・・・・・・・・・。

俺がこんな覚悟で回答したことなどもちろん美容師さんは知る由も無く、以前よりも自然な会話になりました。

出てきた後、少し気持ちが軽くなった気がしました。

関連:

先日付けでアクトインディ株式会社を退職しました。

今日からは毎日がエブリデイフィヨルドになります。

癒されます。

日本Hamlの会

日本Hamlの会の活動内容

  • Haml/Sassに関する情報交換 (Rails勉強会@東京やirc.freenode.netの#rails-tokyoチャンネルで)
  • 各種イベントにおけるHaml/Sassの宣伝
  • オープンソースプロダクトにHaml化パッチを投げる

ロビー活動というレベルを超えてテロに近いですね。応援したいです。

appengine-cl - Project Hosting on Google Code

「なん・・・だと・・・?」

誰かがドでかいことやってのけた!

quekさんがABCLをGAEで動かしてみたら正規表現モジュールを読み込むと初期化でタイムアウトすると切なく話してたのに・・・。

・・・と思ったらGAE for Common Lispの略じゃないのね。

Pythonで実装されたPythonインタプリタ「PyPy 1.2」リリース、JITコンパイラ採用で高速化を達成 - SourceForge.JP Magazine : オープンソースの話題満載

「PyPy」開発チームは3月12日、最新版となる「PyPy 1.2」を公開した。JIT(Just-In-Time)コンパイラを初めて搭載、パフォーマンス向上が最大の特徴となる。

PyPIと発音が同じで分かり辛いな!

情熱プログラマー ソフトウェア開発者の幸せな生き方

どこかのブログでオススメされていたので買った情熱プログラマーが届きました。

Amazon.co.jp: 情熱プログラマー ソフトウェア開発者の幸せな生き方: Chad Fowler, でびあんぐる: 本

内容紹介

本書は、等身大のプログラマの一人がキャリア開発の重要性を説き、そのための心構えなどを示したもの。「プログラマはビジネス視点を持って意識的なキャリア開発をすべき」という視点から、その実践方法を著者独特の生き生きとした共感できる語り口で伝える。

『My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド』(オーム社、2006年)の改題改訂第2版。

なん・・・だと・・・?

(内容が悪い訳ではありません。My Job Went To Indiaもう持ってます)

My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド

WebGLに期待してOpenGLの基礎を勉強して行きたい。

hello.c:

#include <GLUT/glut.h>

void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glFlush();
}

void init(void)
{
glClearColor(0.0, 0.0, 1.0, 1.0);
}

int main(int argc, char *argv[])
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_RGBA);
glutCreateWindow(argv[0]);
glutDisplayFunc(display);
init();
glutMainLoop();
return 0;
}

Makefile:

PROGRAM = hello
SRCS = hello.c
OBJS = $(subst .c,.o,$(SRCS))

CFLAGS = -framework GLUT -framework OpenGL

$(PROGRAM): $(SRCS)
$(CC) $(CFLAGS) -o $@ $<

.PHONY: clean

clean:
$(RM) $(OBJS) $(PROGRAM)
% make
% ./hello

./hello

文字コード入門







「・・・。」







やってくれたのう

「やってくれたのう・・・Amazon・・・。」

関連:重複 - p0t

フレームワークで分析するのを本当にやめて欲しい: 切込隊長BLOG(ブログ) Lead‐off man's Blog

まあ、何を言いたいかというと、現場で頑張る人、現場を仕切る管理職、組織を率いる経営者と、立場によって知っておくべき枠組みや、価値観・優先順位は違うんだよ、ということ。4象限程度のフレームワークで仕事していいのは、現場や物理を相手にする物づくりの人たちだけ。

「問題を構成する最小限の要素の性質と関係を詳しく調べていけば全ての問題が解決するはず」というボトムアップ式の思考では対応できる問題の複雑度が低く、市場予測や経営といった複雑な問題を解決する手法として適さない。(できるとしても計算量が多すぎて現実的な時間無いに終わらない。)

それが理解されないというイラつきでしょうか。

こちらのブログの方はおそらく話したり書き殴ったりするより考えるスピードの方が速くて終わる頃には自分の中で結論はまとまっていて、既に次のことを考えているといった感じの人なんじゃないでしょうか。頭の回転が速い人を見ていてそうなのかな、と思うことがあります。

僕は頭の回転が遅く、話すのもゆっくりなので、風呂入ったり、誰かに話したり、ブログに書いたりしないと考えがまとまりません。

上記の点を相手に説明するとしたらこういう感じでしょうか。

線形代数に対して非線形科学があるように、ボトムアップだけが問題解決の手法ではない。ブラックボックスの群れの動きのパターンから法則を見つけだして予測し、制御する手法が市場予測や経営などには有効である。