[時間割:OS]『Linuxカーネル徹底理解』
2008/08/27 23:41 posted by kunkichi
水曜は「OS(カーネル)」と「サーバ」の時間。まず、「OS(カーネル)」のテキストにはこれをチョイス。
日経BP出版センター
売り上げランキング: 100628
amazonの評価で星がついている割にはコメントはちょっと辛口。まあムック形式なのであまり細かいところまではカバーできないのもわかるので、とりあえずこの本で概要の部分をある程度理解のベース部分を固めようというところ。薄いので何度も読み返すにはちょうどいいし。
トピックが大きいのでなかなかアウトプットが難しいんだけど少しずつ出していきたいと思います。
ちなみに今は「シグナルと割り込み」のところ。今まで読んだところではメモリとファイルシステム、特にページキャッシュのところは、すごく面白かった。ちょっとsarを使う時の見方が変わった気がする。
「サーバ」のほうはまたちょっとcobblerの日本語訳を進めています。
Category: UNIX, Server, Book | コメント＆トラックバック（0）
[時間割:読書]『チーム力をつくる３ステップ』読了
2008/08/27 23:14 posted by kunkichi
残り一気に読み終わりました。まとめ続き。
本間 直人
翔泳社
売り上げランキング: 24123
3章
- 経験豊富なリーダーがいなくてもみんなそれなりに動く。そのために必要なもの。
- 競争・・・同じ目標に向かうために協力を生む
- 達成可能な目標・・・無理でもない、簡単でもない、ならがんばれる
- 少人数・・・集中しやすい
- やる気のある雰囲気・・・やる気は伝播する
- 過去の成功体験を捨てて（アンラーニング）、環境にあわせて変化していくこと。
- 言いやすい雰囲気、動きやすい雰囲気。それを元にトライアンドエラーから全員が学ぶ。
4章
- 9つのマトリクス
- あなたの成功体験は？
- 厳しく言われてよかった体験は？
- よい上司とは？
- 特技能力/特徴
- 最近の進歩成長/喜び
- なりたい上司は？
- 信頼関係を築くために何をしているか？
- 将来の夢は？
- （夢に近づくためのアクションは？）
- それぞれ、過去の経験、現在、未来の理想を表している。これを把握する。
- どういうことに自分は「喜び」を感じるのか。
- 内在的な喜び（達成感とか成長）と外在的な喜び（評価とか感謝）
5章
- リーダーのマトリクスと部下のマトリクスは違うことを認識。部下のマトリクスが部下のモチベーション向上のヒント
- Let’sの気持ち
6章
- 指示を出す時の注意
- 自分がわかる指示を出すのではなく、相手がわかる指示を出す
- 指示したことではなく、伝わったか？が重要
- 伝え方に注意。8W4H。
- 指示に対してやる気・モチベーション・目的を持たせる
- 明確さ
- やることのインセンティブ・喜び
- 外的な喜びは麻痺するが、内的な喜びは継続する
- 相手が「うれしい」と思うことを指示する。それぞれが「うれしさ」を感じることを割り当てる
- チーム「共通」の喜び
7章
- 評価基準
- 軸・・・何を評価のベースとするか？
- 基準点・・・どこを「よし」とするか？
- 方向性・・・どこへ進むのがよいのか？
- 評価の軸は人それぞれ
- 自分の軸と相手の軸をそろえる
- ほめてほしいところをほめてあげる
- 長所を伸ばす方向で。
８章
- 雰囲気作り
- 自分のやっていることと相手が見えている部分は違う
- その間を埋める、別のコミュニケーション手段
- 話せる機会があることを伝えるシグナル
- 何事も小さなところから。それが広がる。
９章
- 全体最適＞個人最適
- ただし、全体が必要ない場合は、全体＜個人
- 個人最適が全体最適を妨げることもある
- プラスのスパイラル
- PDCAやQC活動も全てこのスパイラルが「プラス」で初めてうまくいく
やっぱり成功体験は重要、もう、これは最近のヒットだなー。自己啓発とかだとこれが個人のレベルで終わっちゃうのだけど、これをチーム内でいかに共有できるか？ってところが強いチームを作るためのキモな気がする。それを達成するためには、個々の違いを意識した上で、相手の立場になってコミュニケーションを取ることが必要ってところかな。
当たり前だけど、これを常に意識するようにしないとね。
P.S. 作者の本間さんからもコメントいただきました。ありがとうございました。
Category: Life Hacks, Book | コメント＆トラックバック（0）
『私と技術書』トークセッションに行ってきた（伊藤直也さん@ジュンク堂梅田店）
2008/08/23 23:44 posted by kunkichi
今日はジュンク堂で伊藤直也さん＠はてなの『サーバ/インフラを支える技術』刊行記念のトークセッションに行ってきました。
テーマは『私と技術書』ということで、自分より上のレベルのエンジニアがこれまでどういう本を読んできて現在に至るかというのは、１エンジニアとしては、それに追いつくためにはどうすればよいか？より高いレベルに到達するためにどうすればよいか？ということを考える上で、非常に参考になると思う。
ということで、多分あとで資料はアップされるだろうとは思うのだけど、自分なりのまとめ＆感想。
- 本を読む目的
- 知識を得ることだけでなく、その本テーマについて「考え」を巡らせること。
- 本を読むことの成功体験
- 受験で何度も参考書を読んで大学合格した。
- 同じ本を何度も読むことで読むたびに発見があった。
- プログラミングを学ぶ
- Webで独学、いきなりソース読む、ポインタやオブジェクト指向
→挫折。
- ちゃんと本を読んで勉強。
- 1冊のPerl本が全ての始まり
- 本質的な書籍
- 繰り返し読むことで深い知識を得ることができる
- 自分の成長と同時に本の成長を感じることができる。すなわち新しい発見
- 成功体験２
- 読書の成果をblogにアップ
- 宮川達彦氏から声がかかる
- Shibuya.pmで講演
- その評判からISPでブログサービスの立ち上げをまかされる
- 本を書く
- はてなから声がかかる
- 成功体験３
- はてなでインフラ。サーバダウンなどの障害。
- 自分に足りない知識に気づく
→ローレイヤーの知識
- カーネルソースを読むなどして対処（この辺は前のセミナーでもあったので省略）
- 「陳腐化しない確かな技術」が大事
- より「本質的」なものに対する理解
- 最近
- 計算機科学
→大きな革新を起こすため。
- 科学には数学が必要。でも苦手。
- 学問の理解を助けるのは背景。
→数学が理解できるようになっていく。
- そして科学が理解できるようになっていく
- 憧れの世界へ手が届くレベルへ。
- 本質的な理解が大事
- エンジニアにとっての本を読むことのモチベーション
- 自分に足りない部分を見つける
- 人に会う
- 会うだけで満足することに注意
- 嫉妬・僻みをコントロールする
- 仕事で困難にぶつかる
- 学習することの困難
- 満たされない承認欲求
- 高度すぎて誰もついて来れない。認めてもらえない。
- 孤独を愛する必要がある
- 何かを犠牲にする必要。趣味とか。
あー、勉強にはやっぱり王道はなくて、こつこつ、すこしづつやっていくのが結局正解なんだよね。ものすごく当たり前のことだけど、理想の自分になるために自分に足りないものを考えるとその道の遠さに挫折することの方が多い。でも、「この道で食っていくんだ！」「この世界に何かを残すんだ！」という強い意志と、日々のたゆまぬ努力、この二つがあれば、それは「不可能」ではないんだよね。やっぱり「男気」が大事だと再認識。
あと、「満たされない承認欲求」というのは、個人的にはものすごく衝撃的だったな。この業界は技術力がモノをいう反面、経営・営業サイドからすればやっぱりそれはどうでもよいことであって、なかなかこちらの言い分が認められないことは多々ある。それは土俵が違うのだからしょうがないことであって、素人にもわかるように説明できない自分の落ち度だと思ってるので納得もできる。でも同じエンジニア同士であっても、レベルの差や個々の思いの差でなかなか理解してもらえないのは、正直つらいと思うことが多々ある。と偉そうなことをいってますが、僕のレベルなんてまだまだ知れてるレベルだから、もっと勉強してこういうことを偉そうに言ってみたい、爆
でも、ちょうど今読んでいる「チーム力」の本とも少し重なる部分があって、自分のやっていることが理解されないことは多々あるのかもしれないけど、個々の考えや理想が違うということを理解した上で、それぞれの考えや理想を踏まえたモチベーションのあげ方とか、そういう部分で協調することによって、全体の技術力を上げることは可能だと信じたいな。今日の話の中でも「成功体験」というのはとても重要だということがわかったし、こういう成功体験をチーム内で各自が体験できるような方向にもっていけば、強くて技術力のあるチームを作ることは「不可能」ではないはず。
こういう風に、人の話が本の内容とリンクすることもまた読書の醍醐味だね、とまとめてみました（笑）
Category: Book, Diary | コメント＆トラックバック（0）
[時間割:Python]『みんなのPython』その２
2008/08/21 23:02 posted by kunkichi
まだChapter1の途中です。数値、文字列ときて、そろそろプログラミングらしいデータの持ち方である、リストから。
柴田 淳
ソフトバンククリエイティブ
売り上げランキング: 50252
リスト
- いわゆる配列
- 文字列も数値も一緒にリストに入れれる
- スライス重要
- 角カッコで定義。ex) a=[1,2,”aaa”,”bbb”]
- インデックスにマイナスを使うと後ろから。
- スライスは開始位置と終了位置+1で指定。ex) a[1:3] で [1,2]が返る。
- スライスで返るのはリストなので注意
- リスト同士を足すと連結。あと、リストに数値/文字列は足せない。足す時はリストで足す。append()メソッドで要素を追加、extendメソッドでリストを連結
- リスト同士をかけると繰り返し。
- リストは文字列と同じシーケンス型だけど、要素の置き換えは代入で可能。
- del文で要素を削除
- max()関数で最大、min()関数で最小の要素を取る。
- sort()メソッドで照準ソート、reverse()メソッドで降順ソート。このメソッドはリストの並び自体を書き換える
- 多次元配列は普通にOK
辞書
- ハッシュと同じ
- 中カッコで定義。コロンでキーと値を組み合わせる。ex) a = {”key1″:”value1″,”key2″:”value2″ }
- 取り出す時は角カッコ ex) a[’key1′]
- 要素の削除とか追加はリストと同じっぽい
- キー一覧を取得するにはkeys()メソッド。
- キーの存在確認はhas_key()メソッド。
タプル
- リストとの違いは書き換え不可ということだけ？
- 丸カッコで定義
- 取り出しはリストと同じ。
- スライスでタプルとして取り出せる
- タプル同士の足し算は可能。ただし新しいタプルに。
- タプルの利点は辞書のキーとして使える。リストは無理。
組み込み型まとめ
- コレクション型・・・複数の要素をまとめるもの。
- シーケンス型（文字列、リスト、タプル）
- マップ型（辞書）
- 変更可否
- これらの型キャストもできる。
うーん、なんとなく、リストとか辞書とか、あとそれを取り出すときとかの囲み記号がPerlとかと違うのがちょっと覚えにくい。そう考えるとPHPって単純なんだけどパッと見ではわからんってのがなー。
でも個人的にプログラミングのキモの一つは、リストとか辞書みたいな、「配列」「ハッシュ」の使い方だと思ってるので、ここはしっかり覚えないと。
Category: Python, Programming | コメント＆トラックバック（0）
[時間割:サーバ] ntpのログで”too many recvbufs allocated (40)”
2008/08/21 00:08 posted by kunkichi
ある時からntpサーバのntpログでちょっと気になる出力が。サーバ絡みなので勉強と称して調査。
too many recvbufs allocated (40)
これが延々、とは言わないまでも、バラバラっと出力されてしばら〜くしてからまたバラバラっと、っていうのが繰り返される。でいろいろ調べてみたところ、とあるMLにこんな投稿が。
[time] Increasing recv buffers on FreeBSD
・・・
My logs are routinely filled with things like
Apr 25 11:36:21 n118 ntpd[56093]: too many recvbufs allocated (40)
Apr 25 11:36:21 n118 last message repeated 3 times
Apr 25 14:17:03 n118 ntpd[56093]: too many recvbufs allocated (40)
Apr 25 14:17:03 n118 last message repeated 3 times
・・・
It appears that I am dropping requests that I could otherwise answer.
I’ve got the bandwidth, memory and CPU to handle more than I’m currently taking, so I’m wondering if anyone knows how to increase the udp receive buffers on FreeBSD (6.2-RELEASE p3)
うん、一緒一緒。Load Average、CPU使用率、メモリ、トラフィック、全部余裕あるところも一緒。
で、そのレスが以下。
[time] Increasing recv buffers on FreeBSD
It’s not the kernel; that message comes from /usr/src/contrib/ntp/libntp/recvbuff.c around lines 161 & 225:
・・・
/*
* Check to see if we're below the low water mark.
*/
if (free_recvbufs <= RECV_LOWAT)
{
if (total_recvbufs >= RECV_TOOMANY)
msyslog(LOG_ERR, "too many recvbufs allocated (%ld)",
total_recvbufs);
・・・
It appears that you can change this definition of RECV_TOOMANY here:
% grep -n RECV_TOOMANY */*
include/recvbuff.h:18:#define RECV_TOOMANY 40 /* this is way too many buffers */
As far as I can tell, this only happens if ntpd gets a whole slew of requests at once before it can generate some replies, and it simply results in ntpd dropping the requests…
ってことで、どうやらntpのソース内で受信バッファが定義されていて、瞬間的に大量のパケットを受信したため、バッファからあふれてしまったということの様子。バッファから溢れてしまったのはもちろん落ちちゃっているので、クライアントからのリクエストに対してレスポンスはなくなっちゃってるってことだよねぇ。
で実はここまでは既にわかっていて、パケットキャプチャすると確かにクライアントのリクエストに対してサーバのレスポンスが少ないんだよね、まあ頻度的にはそれほど多くはないのだけど。
ただ、上の理由は僕のシチュエーションだとちょっと納得できない。なんでかというと
- 突然起きたのなら、クライアントが急に増えたとかっていうような変化があったはず。でも調べてみたところ、そういうことはない。
- クライアントのリクエストに対してサーバのレスポンスが返らないのであれば、サーバ側のトラフィックとしては、INは変わらないけど、OUTが減る、っていうのが考えられるけど、トラフィック自体は両方とも同じぐらい減ってる。
からなんだよねぇ、、、不可解だ。
別の投稿がGoogle Groupsにも上がっててこっちは最新版にバージョンアップしろって書いてあるんだけど、最新版(4.2.4p5)のソース見ても上で指摘されている部分は全く変更ないしなぁ。まあバッファを増やしてビルドし直せばログは出なくなるんだろうけど、なんだかなー。
とりあえず今のところテストで再現できてないのでそれをなんとか、って感じ。NTPの負荷テストなんてやったことないしツールもないみたいだし、ちょっとPerlで書いてみることに。Net::NTPでクライアントからのアクセスをParallel::ForkManager使って並列で多量に実行する感じ。
#!/usr/bin/perl -w
use strict;
use warnings;
use Net::NTP;
use Parallel::ForkManager;
my $pm = new Parallel::ForkManager(1000);
foreach my $i (1..100000){
$pm->start and next;
my %response = get_ntp_response("XXX.XXX.XXX.XXX",123);
foreach my $key (keys %response)
{
print "$key --> $response{$keys}¥n";
}
$pm->finish;
}
$pm->wait_all_children;
うーん、どうかなぁ。とりあえず明日実機で試してみよう。
Category: Server | コメント＆トラックバック（0）
[時間割:C言語]『はじめてのC言語完全入門』
2008/08/19 23:40 posted by kunkichi
火曜日は「C言語」です。
C言語は大学の最初の頃に習ったんだけど、それ以来ほんと触ることなくて、PerlとかPHPとかのインタプリタ言語を触るようになってからはますます疎遠になってました。なので気分的には１からやり直す感じで。カーネルのソースコード読めるようにがんばります！
ということで、引っ張りだしてきたのは以前に買ってたCの入門書。塚越さんの本は読みやすくて好きなんだよね、Perlの本も良かったし。
塚越 一雄
技術評論社
売り上げランキング: 420963
1〜4章
- コンパイル時のステージ。全部gccで一発でやってくれるけど一応。
- ソース書く（*.c）
- プリプロセス（gcc -E *.c > *.i）
コンパイルの前処理。外部ファイルの読み込みとかマクロの置換とか。
- コンパイル（gcc -S *.c か *.i → *.s）
アセンブラコードへの変換。
- アセンブル（gcc -c *.c か *.i か *.s → *.o）
オブジェクトファイル（バイナリ）へ変換
- リンク（gcc *.o）オブジェクトファイルとライブラリをリンク
- Cは外部宣言（宣言と関数定義）の集合。
- 関数定義が一つ必要、かつ関数名はmainである必要がある。
- nmコマンド初めて知った。オブジェクトやライブラリに含まれている関数とかを表示する。
- リンク後の実行ファイルには作成した関数以外にもスタートアップモジュールが追加される。これがmainを呼び出す。
実はCの文法とかというよりも、こういう点が一番勉強したかったところ。バイナリアンになりたい。
Category: C, Programming, Book | コメント＆トラックバック（0）
ライアン・アダムス流Lifehacks
2008/08/19 01:10 posted by kunkichi
いやーこんなところでライアンに出会うとは。
Lifehackersに『ミュージシャン ライアン・アダムスの成功の秘密』と題したエントリが載ってました。ライアンとLifehacksってどう考えてもつながらないんだけどなー（笑）でもちょっと面白そう。とあるテレビでファンからの質問に答えた様子。
Q) ライアンはここ８年で平均１年で１枚のアルバムリリース、１年で３枚リリースした年もあり、またそれ以外にも他のアルバムやサウンドトラックに参加しているという超ハイペース。どうやってこれだけの曲を書いているのか？
A) ミュージシャンの仕事は単に週２、３曲の曲を作る。これが全て、だからやるだけ。これ以外の何者でもない。これをやらないミュージシャンは単にさぼっているだけ。
でLifehackers のまとめは以下。
- 自分のゴールを考えて、それに必要な「アクション」を取ること。
- かつ、これを「継続的」にやること。
- この二つがなければ「ゴール」つまり「成功」はない。
うーん、深読みし過ぎじゃね？（笑）
でも、一時期の不安定な感じから、ここ数年の安定した（というかそんなレベルじゃ追っ付かないw）製作ペース、それとシンプルで落ち着いた曲調が増えていることを考えると、あながち外れてもない気がする。
まあリスナーとしては順調にアルバムをリリースしてもらえれば言うことなしです、はい、笑
Category: Music News, Life Hacks | コメント＆トラックバック（0）
[時間割:Python]『みんなのPython』開始
2008/08/17 22:55 posted by kunkichi
週末は「復習」の予定なのだけど、今週末は多忙＆体調不良でダウン、、、木曜日の「Python」の時間のまとめだけもう書いていたのでアップします。
ちなみに、前にも初めてのPython 第2版で勉強したことがあったのだけど、途中で軽く挫折、、、orz。
どうも完璧主義的にやろうというのはよくないね。多少なりともプログラミングやってればある程度わかってることでも、「きちんとまとめないと」という気持ちから実例入れたりしてちゃんとまとめようというのはやっぱり無理。ブログに書くだけでも時間かかって面倒で続かないなー、僕の場合。
ということで、今回は気になったところだけまとめるっていうのを全体的な方針としてやってます。
気分一新、本も買えました。オライリーのが悪いわけではなくて、気分的な問題。初めてのPython 第2版は持ち歩くのも大変だし（笑）
Chapter1から。
数値
- 整数同士の計算は整数で返される（例：1/2は0）
- 整数と浮動小数点数を組み合わせて計算すると精度の高い方、つまり浮動小数点数で返される（例：1.0/2は0.5）
- ++とか–は使えない。+=とか-=使う。
文字列
- 複数の文字の配列みたいな感じ。Cっぽい。
- マルチバイト文字を使う場合はunicode文字列を使う。
- シングルクォート、ダブルクォート、トリプルクォート。
- どの場合でも変数展開されない。
- トリプルクォートがヒアドキュメントみたいな感じ。
- 連結は+、繰り返しは*。数値演算みたく書ける。
- int()、float()、str()とかで型キャスト。
- 関数とメソッド。
- 配列みたくインデックスで文字を取り出せる。
- でも配列みたく置き換えれない。文字列は配列じゃないから。replaceメソッド使う。
同じこと勉強するにも本によって流れが違うし、片方だけではわからなかったこととか、両方読んですっきりすることもあるね。「多読」がいいのはこういうことか。
Category: Python, Programming | コメント＆トラックバック（0）
[時間割:読書]『チーム力をつくる３ステップ』
2008/08/14 22:30 posted by kunkichi
昨日作った時間割のうち「読書」の時間用に１冊買ってきました。で早速今日読んだところで個人的に気になったところだけ簡単にまとめておきます。アウトプット重要。
1章
- 相手がいるときはうまくいくとは限らないという認識をもつ。それをうまくいかせるためにはどうするか？を考える。
- 話すときはなるべく目線を同じ高さに。
- 発言することのインセンティブを。成功体験重要。
- 2:8の法則でいうような、大半の「普通の人」をいかに動かせるかが大事。あとはついてくる。
2章
- 自分自身の「当たり前」はみんなの「真実」ではないことを認識する。
- 同じイメージを共有するために「標準化」。でも「標準化」できないことの方が多くて当たり前。
- 「伝わったか？」を確認するために質問・相談といったコミュニケーションが必須。
- 質問しやすい雰囲気作り。緊張させない、質問のタイミングを作る、小さなグループ、恥をかかせない。
- これを繰り返して「標準化」を目指す。
- 全体の一部をそれぞれがやるのだから意識違いは当然。だからコミュニケーション。
- 個々の興味をそれぞれ違うのだから意識違いは当然。だからコミュニケーション。
身につまされるなぁ、苦笑。いいチームはつくるためには、独りよがりになってないかを常に意識しないと言うことだね。
Category: Book | コメント＆トラックバック（1）
時間割を作ってみた
2008/08/14 01:09 posted by kunkichi
最近、勉強熱がかなり高まってて、かなりのペースで本を買ってるのだけど、さすがにあれもこれもと欲張っちゃった結果、積読になっちゃったり中途半端な感じになったり。
さすがにこれじゃまずいということで、少し「量より質」を重視する方に移行しつつ、でも今まで通り幅広く勉強する、というのをでためにちょっと調べてみたところ、『時間割』を作ってみるのがなんか良さげ。
ライフハック・プラクティス ～仕事の生産性を上げる習慣～：プラクティス:10「時間割を作る 」 | エンジニアマインド … 技術評論社
時間割は，
「日々の勉強をリズミカルに進めていくためのレール」
のようなものです。
仕事をする上でもこのレールを引いてリズミカルに仕事を進めることで，時間に対する意識も高まり，余計なことを考えることなく「やるべき仕事」に集中することができるのです。
ということで早速始めてみます。実際に時間割をどうやって作っていくかは、僕と同じIT系エンジニアの方が書かれている以下のサイトが参考になりました。
上記の方の時間の割り振り手順は以下。
- Googleの「20%ルール」を参考に、1日8時間×5日（月〜金）×20%＝８時間を、自分のやりたいことをやるための時間として時間割に組み込む方針で。
- やりたいことをとりあえずリストアップ。
- これを「教科」に分類して、時間割に組み込む。
で僕が考えた教科が以下。僕の場合、本当にやりたいことか？今必要なことか？をイメージしてリストアップしたので、結果として今の仕事でもっとスキルを積みたいっていうようなものがほとんどになりました。こうやってみるとどれも関連し合ってるし、ある程度自分の中での優先度が見えるので、「教科」っていうほど大きな分類ではないですね。
言語系
- Perl
運用の中で使うちょっとしたスクリプトをもっと早く効率よく書けるようになりたい。
- C言語
オープンソース系の主要なアプリはほとんどCで書かれているので、行き詰まったりしたときにソース読んで解析・修正できるようになりたい。あとカーネルのソース読むのにも必須だし。
- Python
これは個人的に興味があるっていうのと、オブジェクト指向を学ぶにはよいかなと。
サーバ系
- OS（カーネル）
24svr-TechMTG であったように、根拠のない対処療法ではなくて、カーネルに対する理解を深めて、ちゃんと根拠に基づいた対応をできるようになりたい。
- サーバ
これざっくりな感じになっちゃったなw。というのもサーバ運用とかサーバアプリとかサーバ関連のトピックを「いろいろ」勉強する時間にしようと思ったので。まずはちょっと進んでいないCobblerのドキュメント翻訳をまた再開する予定。
- 自宅サーバ・開発
上が勉強・研究的な意味合いなのに対して、こっちは実践的な位置づけ。ひとりWebサービスを開発と、そのサービスを動かす、自宅サーバとはいっても「本番」としての運用をやっていくためのいろいろな時間。
一般
- 絵の勉強
絵画とかっていう意味ではなく、ちょっとしたイラストなんかをかけるように。写真とかに比べるとイラストはやっぱり個性を出せるポイントになると前から思っていて、サイトのデザインとかブログのコンテンツとしてさらっと挿絵とかかけるといいなぁということで。
- 統計学
これはちょっとサーバ運用とも関連するのだけど、ログ解析とかサービス稼働状況の分析とかに、統計学の知識があればもっと便利かなと。
これで一通り「教科」は出そろったのだけど、これらとは別にちょっとした味付けを入れてみました。
- ちゃんと時間を区切って、休憩もきちんと取るのが、本来のやり方みたいなのだけど、業務上、割り込みも多いし、作り込みすぎると達成できないような気もするので、あまり細かくしない方針。
- ビジネスとかLife Hacksとか、一般的な話題は、その時々で興味が出たり、話題の書籍が出たり、みたいなトリガーが多いので、そういうのは、朝・晩の通勤時に読書の時間を設けることで対応。
- ビジネスとかLife Hacksとか、一般的な話題は、その時々で興味が出たり、話題の書籍が出たり、みたいなトリガーが多いので、そういうのは、朝・晩の通勤時に読書の時間を設けることで対応。
- この年になると1回読んだだけとかではなかなか頭に残らないので（笑）ちゃんと脳に定着させるために、ゆっくりと落ち着ける週末に「復習」の時間を用意。
- あと、仕事を円滑にこなすためのHack的な時間は毎日きちんと用意。
ということでできたのがこれ↓。
内容的にはあんまり無理もしてないし、毎日コツコツとこなせていけそうなレベルで落ち着いたので、満足。
あとは、毎日の達成率の記録や、モチベーション維持のための記録手法を考えないと。とりあえず、これでしばらくがんばっていきたいと思います。
Category: Life Hacks, Diary | コメント＆トラックバック（0）
Page 7 of 27« First...«56789»...Last »
2009/01/05/ 22:51
2008/11/06/ 07:02
2008/10/09/ 07:30
2008/09/16/ 12:08
2008/08/31/ 12:22