なんというか、なかなかに多忙。
学習は継続しているが、プログラミングまで時間が回らない現状がある。
もう一段、いろいろなことの効率化を考えないとこれは打破できない。
一度、そこからやりなおそう。
なんか自分、やり直してばっかり。。。
こつこつ。
2009年8月30日日曜日
端末で論理記号がずれる (3)
UnicodeとEmacsの仕様を多少読んでみた。
以前、EastAsian ambiguous width characters が根源、と書いたが、これは少し乱暴だった。
というのは、あたりまえなのですが、論理記号は EastAsian というカテゴリではないから。
端末上のEmacsを多少いじってみてわかったのだが、mathematical symbols と その supplemental なものどもについて、'small'とついているものが、half width であるというのがルールであるとするならば、単純に、Emacsとフォント(X?)の双方がUnicode標準に精確に準拠していないために発生していることがわかった。
で、そういうルールは無いということであれば、根源はEastAsianの場合と同じだ。
これ、keymapやabbrevをつかって ad hoc な解決はできるのだけど、やっぱり根本解決しないと気持ち悪い。しかし curses 含めて対応されるのは時間がかかりそう。。。
そろそろGtkなEmacsに移行すべきかもしれない。
以前、EastAsian ambiguous width characters が根源、と書いたが、これは少し乱暴だった。
というのは、あたりまえなのですが、論理記号は EastAsian というカテゴリではないから。
端末上のEmacsを多少いじってみてわかったのだが、mathematical symbols と その supplemental なものどもについて、'small'とついているものが、half width であるというのがルールであるとするならば、単純に、Emacsとフォント(X?)の双方がUnicode標準に精確に準拠していないために発生していることがわかった。
で、そういうルールは無いということであれば、根源はEastAsianの場合と同じだ。
これ、keymapやabbrevをつかって ad hoc な解決はできるのだけど、やっぱり根本解決しないと気持ち悪い。しかし curses 含めて対応されるのは時間がかかりそう。。。
そろそろGtkなEmacsに移行すべきかもしれない。
2009年8月17日月曜日
端末で論理記号がずれる (2)
Webで調べた。Unicodeでいうと、
EastAsian ambiguous width characters
というところが問題の根源らしい。
Emacs上での対応状況は、
[mule-ja-2009:09575]
以下のスレッドにくわしい。
EastAsian ambiguous width characters
というところが問題の根源らしい。
Emacs上での対応状況は、
[mule-ja-2009:09575]
以下のスレッドにくわしい。
2009年7月27日月曜日
【雑】ブログのラベル(タグ)整理
ラベル(タグ)のメンテをちょこちょこやってます。
モチベーションは次のとおり。
こつこつ。
モチベーションは次のとおり。
- 話題がクロスオーバーしてきたので、タグを整備すると自分にとっても便利。
- 一過性の興味などにより、エントリが1つしかないタグがある。これは他のにマージしていく。タグ数を減らした方が見易いから。
- 同義語なタグについて考える。そのまま残すことに語彙として価値があるか、それともマージするか。
こつこつ。
2009年7月19日日曜日
データベース実践講義(Database in depth)を読む
Prologと論理のことが多少わかってきたところで、じゃあRDBって何なのさ、ということを探ってみたい。ぼやぼやーとした感じでよいので。
そこで、次の本を読むことにした。
C.J.Dateのデータベース実践講義
根を詰めると倒れるので、ぼやぼやーといきたい。
そこで、次の本を読むことにした。
C.J.Dateのデータベース実践講義
根を詰めると倒れるので、ぼやぼやーといきたい。
2009年7月17日金曜日
端末で論理記号がずれる
SKKの▽とかもそうなので、悩みは深いのですが、
端末で論理記号がずれる、というか、論理記号の後続が
めりこんじゃうんだよね。見ずらくて、萎える。
これ、端末の問題なのかフォントの問題なのかその両方
の組み合わせなのか、なんだけど、gtkアプリはずれない。
困ったなぁ。
端末で論理記号がずれる、というか、論理記号の後続が
めりこんじゃうんだよね。見ずらくて、萎える。
これ、端末の問題なのかフォントの問題なのかその両方
の組み合わせなのか、なんだけど、gtkアプリはずれない。
困ったなぁ。
2009年7月7日火曜日
プログラミングの習作という考え方
プログラミングの学習の道程は長いですね。
まだまだ知識が足りなくて、まともなプログラムが組めるとは思えません。
雛鳥がある日飛び立つように、いろいろな準備がととのったら自然と自分自身のプログラムを書き初めるのかなぁ、と思っています。
もともと書きたいもの、実現したいことはいろいろあるんです。それを実現するために言語としてはCommon Lispを選択しました。その選定だけで1年くらいつかったかもしれません。で、ちゃんとした学習をはじめて1年半くらい。1年半前とくらべれば、自身としては進歩していると思うのですが、知らなければいけないことの分量からすると道遥です。
そのことはこんな風に考えています。
たとえば、理論物理学で何か仕事をなそうと思ったら、やはり大学レベルの物理と数学の理解は仕事の分野によらず大事だと思うのです。ぱっと思いつくところを列記すると(物理だけ)、古典力学、光学、熱力学、解析力学、電磁気学、場の理論、量子力学、特殊相対性理論、一般相対性理論、固体物理、流体力学、統計力学、場の量子論、量子電磁力学、量子色力学、非線形の基礎あたりまでは進む分野にかかわらずきっちりおさえておかないとお話にならないと思うのです。この年齢まで計算機とその周辺というのをじっくりと勉強したことがなかったので、今はそういう蓄積をしているときだという位置付けです。
そんなこんな、なんですが、目標としている成果物じゃなくても、プログラミングにも習作というのがあるのではないか、と思えてきました。もちろん、あるとは思うのですが、自分自身がそれがあると考えられるようになったことが大事です。
Shibuya.lisp TT#3のShiroさんのお話にあったToyであっても、習作としていくつか取り組んでいくこともありなんじゃないかと思えてきました。
それは模写かもしれないしスケッチかもしれないし、そういうメタファのない何かかもしれません。
ちょっと考えてみようと思います。
まだまだ知識が足りなくて、まともなプログラムが組めるとは思えません。
雛鳥がある日飛び立つように、いろいろな準備がととのったら自然と自分自身のプログラムを書き初めるのかなぁ、と思っています。
もともと書きたいもの、実現したいことはいろいろあるんです。それを実現するために言語としてはCommon Lispを選択しました。その選定だけで1年くらいつかったかもしれません。で、ちゃんとした学習をはじめて1年半くらい。1年半前とくらべれば、自身としては進歩していると思うのですが、知らなければいけないことの分量からすると道遥です。
そのことはこんな風に考えています。
たとえば、理論物理学で何か仕事をなそうと思ったら、やはり大学レベルの物理と数学の理解は仕事の分野によらず大事だと思うのです。ぱっと思いつくところを列記すると(物理だけ)、古典力学、光学、熱力学、解析力学、電磁気学、場の理論、量子力学、特殊相対性理論、一般相対性理論、固体物理、流体力学、統計力学、場の量子論、量子電磁力学、量子色力学、非線形の基礎あたりまでは進む分野にかかわらずきっちりおさえておかないとお話にならないと思うのです。この年齢まで計算機とその周辺というのをじっくりと勉強したことがなかったので、今はそういう蓄積をしているときだという位置付けです。
そんなこんな、なんですが、目標としている成果物じゃなくても、プログラミングにも習作というのがあるのではないか、と思えてきました。もちろん、あるとは思うのですが、自分自身がそれがあると考えられるようになったことが大事です。
Shibuya.lisp TT#3のShiroさんのお話にあったToyであっても、習作としていくつか取り組んでいくこともありなんじゃないかと思えてきました。
それは模写かもしれないしスケッチかもしれないし、そういうメタファのない何かかもしれません。
ちょっと考えてみようと思います。
2009年7月5日日曜日
英単語を使う理由
かなり疲れた状態で書くのでこわいのですが。
書きたいと思ったので書いちゃって、しかも公開しちゃいます。
ブログのエントリを書くときに、結構英単語をおりまぜて書いています。本当は嫌なんです。日本語で書きたい。日本人だし。あと英単語をおりまぜるなんてなんかいやらしい気もして。
それでも英単語で書くのは、理由があります。
誤解がないように補足しておきますが、日本語も米語とくらべていいところがいろいろあるのです。まず、掲題の「は」は非常にコンパクトで有用です。主述関係にとらわれずに、多様な関係を述語でくくれるのも柔軟です。助詞「が」の代行もやっかいな側面もありますが総称助詞としてadhocな表現には便利です。オノマトペが潤沢です。表意文字の漢字もコンパクトです。
で、結果として英単語をおりまぜて書くのですが、それもやりきれていません。後からみれば、ここは複数だよな、とか、theがないと結局意味ないけどthe入れてないじゃん、とか。仕事の文書ではきっちりやらないといけないわけですが、まあブログなのでいいかな、と。
何かを文章にして言明する、ということは、悩みが深いです。
書きたいと思ったので書いちゃって、しかも公開しちゃいます。
ブログのエントリを書くときに、結構英単語をおりまぜて書いています。本当は嫌なんです。日本語で書きたい。日本人だし。あと英単語をおりまぜるなんてなんかいやらしい気もして。
それでも英単語で書くのは、理由があります。
- 訳語のゆらぎの問題
- 米語だとゆらいでいないのに、日本語の訳語が本や訳書によってゆらいでいるものがあります。用語のゆらぎが理解を相当にさまたげることはDomain Driven Designで散々言われていることですよね。これは損失だと思います。
- もしかしたらどこかで適切な訳語の定義がなされているものもあるかもしれないが、それを探す方法がなかったり、手間だったり。
- 米語だとゆらいでいないのに、日本語の訳語が本や訳書によってゆらいでいるものがあります。用語のゆらぎが理解を相当にさまたげることはDomain Driven Designで散々言われていることですよね。これは損失だと思います。
- 訳語のイメージが理解を妨げる問題
- なんどかこのブログでも書いていますが、expressionsを式と訳語にしたこと、variablesを変数と訳語にしたことは、日本の数学教育の失敗だと思っています。式は訳語としてはありなんですが、式がもつ古来からの意味を理解している現代人は普遍的ではないので、うまくイメージできないことがほとんどと思います。いっそのことexpressionsは「表現」の方がよかったと思います。またvariablesを変数としたのは明確な失敗です。variablesを変数としたことの失敗は議論の余地が少ないと思います。そもそもvariablesの中に数という意味要素は含まれていないはずです。数理論理学では変数じゃやりきれないので変項と言うようです。が、これもイマイチです。おもいきって大和言葉の「うつろい」でもよかったかもしれません。こういうことがいろいろあるのです。
- もしかしたら、これら問題は、和算と洋算のオントロジをマッピングする際に発生したものであり訳語を考案したのではないかもしれません。しかし経緯によらず欠点は欠点です。
- なんどかこのブログでも書いていますが、expressionsを式と訳語にしたこと、variablesを変数と訳語にしたことは、日本の数学教育の失敗だと思っています。式は訳語としてはありなんですが、式がもつ古来からの意味を理解している現代人は普遍的ではないので、うまくイメージできないことがほとんどと思います。いっそのことexpressionsは「表現」の方がよかったと思います。またvariablesを変数としたのは明確な失敗です。variablesを変数としたことの失敗は議論の余地が少ないと思います。そもそもvariablesの中に数という意味要素は含まれていないはずです。数理論理学では変数じゃやりきれないので変項と言うようです。が、これもイマイチです。おもいきって大和言葉の「うつろい」でもよかったかもしれません。こういうことがいろいろあるのです。
- 名詞のもつパワー
- 英文を読んでいてよく思うのは、名詞が運ぶ意味の量が多いことです。まず数の概念。文脈とあいまって、単数形、複数形で同じ単語でも意味がかなり違います。そしてtheを代表とするanaphoricな機構がこれまた文脈とあいまって意味をたくさん運ぶことができます。もちろん日本語でも表現できるのですが、簡潔さが違います。
- lisp is beautiful.
- A lisp is beautiful. (この表現はほとんどつかわないと思いますが)
- The lisp is beautiful.
- Lisps are beautiful.
- The lisps are beautiful.
みんな意味やニュアンスが違います。日本語に意訳すると次の感じだと思います。- lispという考え方または概念/存在は美しい。
- ある美しいlispがあると考えてみる。
- (文脈によって特定された)そのlispは美しい。
- (実体をもった、すなわちlispにおいては処理系どももイメージされつつ)lispってきれいだなぁ。
- (文脈によって特定された性質を鑑みつつ)そんなlispって綺麗だよね。
科学の書籍について、訳書が原書よりも厚くなる理由はこの部分にあるのではと睨んでいます。(統計的な検証はしていません) - lisp is beautiful.
- 英文を読んでいてよく思うのは、名詞が運ぶ意味の量が多いことです。まず数の概念。文脈とあいまって、単数形、複数形で同じ単語でも意味がかなり違います。そしてtheを代表とするanaphoricな機構がこれまた文脈とあいまって意味をたくさん運ぶことができます。もちろん日本語でも表現できるのですが、簡潔さが違います。
誤解がないように補足しておきますが、日本語も米語とくらべていいところがいろいろあるのです。まず、掲題の「は」は非常にコンパクトで有用です。主述関係にとらわれずに、多様な関係を述語でくくれるのも柔軟です。助詞「が」の代行もやっかいな側面もありますが総称助詞としてadhocな表現には便利です。オノマトペが潤沢です。表意文字の漢字もコンパクトです。
で、結果として英単語をおりまぜて書くのですが、それもやりきれていません。後からみれば、ここは複数だよな、とか、theがないと結局意味ないけどthe入れてないじゃん、とか。仕事の文書ではきっちりやらないといけないわけですが、まあブログなのでいいかな、と。
何かを文章にして言明する、ということは、悩みが深いです。
2009年7月4日土曜日
Shibuya.lisp TT#3を観覧
今回もとても楽しめた。
まず、スタッフのみなさんに感謝。
また、どの発表も個性があり勉強になりました。
発表者のみなさん、ありがとうございました。
備忘録として雑感をいくつか。
Takeばかりでなく、自分もはやくGiveできようになりたいなぁ。
こつこつ。
まず、スタッフのみなさんに感謝。
また、どの発表も個性があり勉強になりました。
発表者のみなさん、ありがとうございました。
備忘録として雑感をいくつか。
- 今までと違ったのは、予期せず自分がScheme/Gauche/Kahuaの知識をもって臨めたこと。今回、Web application frameworkの話題が多かったことがあいまって、前回までよりも個々の発表を深く理解できたと思う。
- Web application frameworkに関係するものは、Railsを意識していた。でもRailsと同じ方向では駄目だと思う。Rails自体、遠からず衰退すると思うし。そういう意味で、teepeedee2のルールベースの試みは可能性を感じた。
- Inside c-wrapperの小黒さんは、まずプレゼンテーションが円熟だった。内容も大変勉強になった。CとVMとの狭間のお話は日頃なかなか見えない処理系内部の機構が見える化されて、おもしろい。
- やはりもっとも興味深かったのはshiroさんのお話。とくにGaucheを日頃どのように自身の武器として使い、どのような手練手管で問題解決をしているのか、またそれがどのようにGaucheのリリースに反映されているのかというのが本人のお話として聴けたのはためになった。高速化のadhocな工夫、コードの可読効率を上げるための試行錯誤、macro-expand-timeの壁とメタプログラミングの超越によるその解決への野望、他の言語/処理系(v8,clojure,etc)をちらちら見ている感じ、型推論などへの言語仕様拡張、などなど。
Takeばかりでなく、自分もはやくGiveできようになりたいなぁ。
こつこつ。
2009年6月28日日曜日
Gaucheを勉強してみる
今の自分がやりきれるのかわからないがGaucheを勉強してみることにした。
というのは、どうもCommon Lispの理解をもう一段上げるにはやはりコンパイラやインタプリタの理解が基礎に必要だと思うのだが、そのための良書にSchemeで書かれたものが結構ありそうだからだ。そこで、
->プログラミングGauche
--> SICP
---> インタプリタやコンパイラ本 (Schemeベース) (これの他にCベースのもやる)
----> Common Lispの理解に再帰
とプランしてみた。
PAIP勉強会とかProcessing勉強会とかいろいろ忙しくはあるのだが、これはこれでスタックが深いので、早めに準備しておこうという算段だ。やりきれないかも。
というのは、どうもCommon Lispの理解をもう一段上げるにはやはりコンパイラやインタプリタの理解が基礎に必要だと思うのだが、そのための良書にSchemeで書かれたものが結構ありそうだからだ。そこで、
->プログラミングGauche
--> SICP
---> インタプリタやコンパイラ本 (Schemeベース) (これの他にCベースのもやる)
----> Common Lispの理解に再帰
とプランしてみた。
PAIP勉強会とかProcessing勉強会とかいろいろ忙しくはあるのだが、これはこれでスタックが深いので、早めに準備しておこうという算段だ。やりきれないかも。
2009年6月21日日曜日
最近の取組み
業務繁忙なのもあるのだが、ここのところブログを書いたりメールを書いたりと、コミュニケーションすることに困難がある。筆が重い。どうしてだろう。。。
自分なりのペースで勉強は続けているので近況を。
とりあえずやらなきゃ、ということで物理的に近い人で集ってやってみている。将来的には、もっと広く募ってやりたいなぁ。
こつこつ。
自分なりのペースで勉強は続けているので近況を。
- 5月半ばからプロジェクトマネージメント勉強会を開催。こちらは本職なので、WBS-EVMをごりごりと。
- 5月末からPAIP勉強会を開催。6章まで完了。自分的には2周目なので、理解が深まってうれしい。
- Processing勉強会を準備中(6月末開始予定)。準備にあたって、まずはLEARNING PROCESSINGを読了した。プログラミングのよい入門書だなぁ。
とりあえずやらなきゃ、ということで物理的に近い人で集ってやってみている。将来的には、もっと広く募ってやりたいなぁ。
こつこつ。
2009年4月17日金曜日
2009年3月2日月曜日
Shibuya.lisp TT#2を観覧
土曜日はShibuya.lisp TT#2をなんとか観覧できた。
TTもLTも、それぞれが特徴をもち、大変勉強になった。
御尽力された運営の皆様に感謝。
ああいう催しというのはほとんど参加したことがなくて、実はShibuya.lisp TT#1が初めてだった。そしてTT#2が二回目。参加して感じることは、興味深いのは、この人スゲーということではなく、スゲーと言われる人々がみせる折り合いの付け方というかこつこつ日々進んでいることの片鱗というかが垣間見えるのが勉強になる、ということ。
今回も全員の発表者の方からいろいろな観点で学ばせていただいた。その中で日々こつこつという視点で興味深かったのは、和田先生の「再帰、大好き。このseparateっていう関数くらいすごい再帰関数がすらすら書けたらなぁ、と思うんだけどなかなかそこまでいけてません」というような発言だったり、リトルウイングの藤田さんの「MacのSDLがよくわかってなくて、CPU使用率が60%くらいなんです。(中略) MacのSDLのマルチスレッドもよくわからず、止めるにはこうするしかないんですよ」(と、アクティビティモニタから強制終了を)。また、著名な方々が、休憩時間に、和田先生のTAOCPの例がよくわからんとか雑談されてたりとか、気さくにディスカッションする中からもそういうことが読取れた。
もう一回確認したいのが山下さんのLazyのお話。これはLT5分だからかプレゼンの自動タイピングというか再生スピードが結構速かった。体調が悪いこともあり、読むのがついていけなかった。
Common Lispを勉強中の身としては、黒田さんのTTにも触れておくべきだろう。内容的には自分自身がCommon Lispを第一言語として選択している身であることもあり、共感できることが多かった。ただし、Schemeへの懸念というか「Lispじゃないだろ」という点については半分くらい共感できたが半分はわからなかった。このわからない半分というのは、R5RSは読み込んだことがあるし、R5RSの処理系(当時のgauche、plt-scheme)は使ったことがあるが、R6RSは一読すらしていないことから発生している。黒田さんがR6RSに触れた部分は判断不能だったということ。
しかしながら、藤田さんがR6RSのpackageとsyntax-caseとについて仕様記述の不十分さと、いくつかのケースでの振舞の気持ち悪さを言明されていたので、Schemeも言語の基礎設計が終わるのにはまだ時間がかかりそうなのかな、とは感じた。
よろよろ。
TTもLTも、それぞれが特徴をもち、大変勉強になった。
御尽力された運営の皆様に感謝。
ああいう催しというのはほとんど参加したことがなくて、実はShibuya.lisp TT#1が初めてだった。そしてTT#2が二回目。参加して感じることは、興味深いのは、この人スゲーということではなく、スゲーと言われる人々がみせる折り合いの付け方というかこつこつ日々進んでいることの片鱗というかが垣間見えるのが勉強になる、ということ。
今回も全員の発表者の方からいろいろな観点で学ばせていただいた。その中で日々こつこつという視点で興味深かったのは、和田先生の「再帰、大好き。このseparateっていう関数くらいすごい再帰関数がすらすら書けたらなぁ、と思うんだけどなかなかそこまでいけてません」というような発言だったり、リトルウイングの藤田さんの「MacのSDLがよくわかってなくて、CPU使用率が60%くらいなんです。(中略) MacのSDLのマルチスレッドもよくわからず、止めるにはこうするしかないんですよ」(と、アクティビティモニタから強制終了を)。また、著名な方々が、休憩時間に、和田先生のTAOCPの例がよくわからんとか雑談されてたりとか、気さくにディスカッションする中からもそういうことが読取れた。
もう一回確認したいのが山下さんのLazyのお話。これはLT5分だからかプレゼンの自動タイピングというか再生スピードが結構速かった。体調が悪いこともあり、読むのがついていけなかった。
Common Lispを勉強中の身としては、黒田さんのTTにも触れておくべきだろう。内容的には自分自身がCommon Lispを第一言語として選択している身であることもあり、共感できることが多かった。ただし、Schemeへの懸念というか「Lispじゃないだろ」という点については半分くらい共感できたが半分はわからなかった。このわからない半分というのは、R5RSは読み込んだことがあるし、R5RSの処理系(当時のgauche、plt-scheme)は使ったことがあるが、R6RSは一読すらしていないことから発生している。黒田さんがR6RSに触れた部分は判断不能だったということ。
しかしながら、藤田さんがR6RSのpackageとsyntax-caseとについて仕様記述の不十分さと、いくつかのケースでの振舞の気持ち悪さを言明されていたので、Schemeも言語の基礎設計が終わるのにはまだ時間がかかりそうなのかな、とは感じた。
よろよろ。
2009年2月27日金曜日
2009年1月26日月曜日
<を& l t ;に手で変換している件について
M-x replace-regexpで一括変換するかどうかは問題ではなく、<pre></pre>でソースコードを記載しているのは何かがおかしい。何かがまちがっている。。。
2009年1月25日日曜日
ルポルタージュと言語力
ちょっと誤解を与えるかな、と思ったので、補足を。
ものごとの深層を捉えるには、得られた情報を整理し、それらを吟味することが必要になる。場合によって新しい概念への抽象化が必要になる。抽象と具象をいったりきたりもする。それには言語の力が重要だ。なので、実は表現をする段だけではなく、そもそも考えを形成していく際にも言語力のよしあしが効いてくる。ここの事情があるので、自分としてはなるべく柔軟な言語で思考したいと思い、Lispを選択している。自分の思考が例えばJavaに制約されていくのは苦痛だからだ。
言語力で指しているのは言語なだけに、それはさまざまな思考の根底とはなっている。その上で、プログラムを書くということは対象領域のルポルタージュ的側面が強いということ。
ものごとの深層を捉えるには、得られた情報を整理し、それらを吟味することが必要になる。場合によって新しい概念への抽象化が必要になる。抽象と具象をいったりきたりもする。それには言語の力が重要だ。なので、実は表現をする段だけではなく、そもそも考えを形成していく際にも言語力のよしあしが効いてくる。ここの事情があるので、自分としてはなるべく柔軟な言語で思考したいと思い、Lispを選択している。自分の思考が例えばJavaに制約されていくのは苦痛だからだ。
言語力で指しているのは言語なだけに、それはさまざまな思考の根底とはなっている。その上で、プログラムを書くということは対象領域のルポルタージュ的側面が強いということ。
プログラミングとルポルタージュ
クヌース先生はプログラミングは文学であるといっていたらしいが、自分にはどうもルポルタージュに思える。プログラミング言語にいくら精通していてもそれだけではよいプログラムは書けない。というかそれだけではプログラムを書く対象というかモチベーションが存在しない。解決すべき対象に対する調査や知見があって、初めてプログラムを書くことができる。文学もものによってそういう側面があると思うが、より直接的なのはルポルタージュだ。いろいろな手法を用いて根気よく調査して対象の深層を捉える。それを表現するところで言語力がものをいう。
2009年1月24日土曜日
GTD
あまりに業務がいそがしいので、GTDをやってみている。
やってみてGTDでは問題は解決しないことがわかった。GTD自体はいい感じだが。
打ち合わせの数が多すぎるのだ。打ち合わせの準備をして、打ち合わせをして、打ち合わせの結果を周知して、ということで手一杯。一日あたり、大小15個くらいの打ち合わせがある。
逆に言うと、それをなんとかすればなんとかなるかも、ということがわかった。
こつこつ。
- アプリはOmniFocus。
- GTDというメソッドはいい感じ。
- OmniFocusもわるくないが、私の場合、アクションと業務が複雑に関連しているので、もうちょっと機能が欲しいところ。
- rubikitchさんのところでorg-modeでGTDもできるというのがあった。先々はorg-modeに挑戦してみるか。
やってみてGTDでは問題は解決しないことがわかった。GTD自体はいい感じだが。
打ち合わせの数が多すぎるのだ。打ち合わせの準備をして、打ち合わせをして、打ち合わせの結果を周知して、ということで手一杯。一日あたり、大小15個くらいの打ち合わせがある。
逆に言うと、それをなんとかすればなんとかなるかも、ということがわかった。
こつこつ。
登録:
投稿 (Atom)