つぶやき。

bpe : org-mode で Blogger イマサラですが、2015/6/15 に googlecl が動かなくなったことで、現在 bpe は使用できません。 Table of Contents Markdown で Blogger org-mode で Blogger Markdown で Blogger Blogger は、残念ながら Markdown に対応してないんですよね。 Blogger で 無理やり Markdown を使うために、今までは Tips - MarkdownをHTMLにembedする : 404 Blog Not Found の方法を使ってました。 簡単に言うと、textarea 内に Markdown を書いて、js で HTML に変換するってだけです。 この方法のいいところは、Markdown -> HTML 変換なしで Markdown のまま post できることです。 自分で HTML に変換してから post だとそのワンステップ自体も、後で Markdown と HTML を同期するのも面倒ですから。 この方法の問題は、スマートフォン等のモバイルデバイスでうまく表示できないことです。 そりゃナシだろってくらい致命的な問題ですが、これまではそれを知ってて無視してました。 アリテイに言うと、スマートフォンからのアクセスを捨ててたわけです。 今ではたしかに大問題ですが、その昔はそれほどでもありませんでしたし。 ていうかもっと正直に言うと、すっかり忘れてたんです。 最近ひさしぶりに自分のブログを iPhone で見て、そういやそんな問題あったなと。 それで、そろそろなんとかしなきゃならないなということで、このエントリを書くにいたったわけです。 Blogger で Markdown を使うには、StackEdit というテもあります。 StackEdit は Web 上の Markdown エディタで、入力した Markdown を直接 (Blogger を含む) blog 等のサービスに post する機能があります。 ただ、残念ながら HTML タグが含まれているとうまく変換できなくなってしまう問題がありました。 HTML を埋め込めない Markdown って …。 それに、ブラウザ上のエディタなんて、かったるくって使ってられないですよね。 tumblr なら、 Markdown に対応してるんですよね。 tumblr も使ってる のでそっちに一本化してもよかったんですが、 放置してどうしようか迷ってるうちに、org-mode で Blogger に post するテを発見したので、そっちを採用することにしました。 考えてみたら、Markdown より org-mode のほうが more better ですよね。 Markdown なんて、表現力でいったら org-mode のサブセットに過ぎないし、org-mode は HTML エクスポートくらい普通にできるんだし。 なんでスッとそっちを思いつかなかったのか、不思議です。 とはいえ、Tips - MarkdownをHTMLにembedする : 404 Blog Not Foundを採用した当時は、まだ emacs 使ってなかったのでしょうがないんですが。 ただ、HTML エクスポートができるとはいえ、org-mode で快適に Blog を書くためにはもう一つ条件があります。 HTML への変換のステップをなくすことです。 幸い、変換 -> post を一気にやってくれる elisp を 作ってくれてる人 がいたので、そこは No 労力でクリアです。 org-mode で Blogger org-mode から Blogger に post するには、bpe を使います。 もし、まだ googlecl をインストールしてなければ、gdata-python-client と一緒にインストールします。 で、いったん $ google blogger list でもして、認証を通しておきます。 ここでハマったのが、googlecl が PYTHONPATH に設定したパスを見てくれないことでした。 そのせいで、gdata を import してるとこで落ちてしまいます。 結局、googlecl の shebang のパスと僕の環境の python のパスが違ったという、なんでもないことが原因でした。 brew とかで適当に python をインストールしたまま放置してると、こんな簡単なことでつまずいてしまいますのでご注意を。 あとは emacs の設定ファイルに (require 'bpe) (require 'htmlize nil 'noerror) ; to fontify source code block on your blog. (setq bpe:account "your mail address on google blogger") (setq bpe:blog-name "your blog name") (define-key org-mode-map (kbd "C-c C-p") 'bpe:post-article) (define-key org-mode-map (kbd "C-c C-i") 'bpe:insert-template) ;; For Japanese, default is $LANG environment variable. (setq bpe:lang "ja_JP.UTF-8") と書けば準備 ok 。 org ファイルを作ったら、上の define-key にあるとおり C-c C-i すればヘッダのテンプレートを挿入してくれます。 こんなかんじ #+TITLE: #+OPTIONS: toc:nil \n:nil num:nil #+TAGS: #+AUTHOR: タイトル、タグ、および作成者 (必要ならオプションも) を記入したら、あとは記事を書いて C-c C-p で post するだけですね。 しばらくはこのまま org-mode -> Blogger を使ってみて、もしイマイチだったら 他の elisp を試してみるか、org-mode から Tumblr に post するテもあるようなので Tumblr に引っ越すかも。 via Blogger https://ift.tt/gPHviJh 2021-07-04T15:25:00+09:00

テキストエディタ プログラマの主な仕事は、テキストエディットです。 いきなり断定からはじまりましたが、これは事実です。 プログラマの仕事は、テキストエディット以外にもいろいろあります。 ソフトウェア開発は、とても複雑な作業です。 見積、スケジューリング、進捗管理、要件定義、基本設計、詳細設計、テスト計画、単体テスト、結合テスト、統合テスト … etc。 やるべきことは、嫌になるほどあります。 それでもなお、いやしくもプログラマであるのなら、中心となるアクティビティはやはりコーディングです。 他のすべての作業は、コーディングに十分な時間がとれるように計画し、うまくコーディングできるように準備し、意図通りにコーディングできたかを確認するためのものです。 すべては、コーディングを中心に回っているのです。 まあ、少なくとも本来は。 コーディングという作業は、テキストエディットに他なりません。 プログラマにとって、テキストエディタは画家の筆であり、彫刻家のノミ、写真家のカメラです。 ですから、自分自身に合ったエディタを探すことと習熟することは、生産性や品質に大きく影響します。 今回は、このコーディングのための必須ツールである、エディタのハナシです。 僕のエディタ遍歴 IDE について エディタに求めるもの 僕のエディタ遍歴 Emacs 僕の場合、結局 Emacs に辿り着きました。 Emacs は、Emacs Lisp というフルスペックのプログラミング言語を備えていて、これによって非常に高度な拡張が可能になっています。 Emacs 本体も、大部分が Emacs Lisp で実装されています。 このような自己記述的なあり方は、Eclipse などとも共通しますね。 非常に歴史のあるエディタなので、プラグインもかなり充実しています。 そして、これが大事なところなんですが、大昔からあるエディタだからこそ、完全にキーボードだけで操作できます。 手をホームポジションからほとんど動かすことがないため、テキストエディットが高速になり、気が散る機会が減ります。 途中で右手をキーボードから離して、マウスをチラ見して握り、またキーボードに戻って、ホームポジションを指先の感触でさぐるなんていう動作を今までいったい何回繰り返したでしょうか。 そのたびに、視線がディスプレイを離れ、一瞬集中が弱まってしまいます。 一生のうち、トイレで過ごす時間とマウスをまさぐるのに費やす時間の、どっちが多いでしょう。 というカンジで、僕はテキストエディットに関しては、できるだけマウス使わない派です。 Textastic iPhone、およびiPadでは、それぞれ Textastic Code Editor for iPhone と Textastic Code Editor for iPad - Alexander Blach を使っています。 残念ながら iPhone を使うのをやめたので、現在は Textastic も使ってません。 80以上の言語でシンタックスハイライティングが可能で、Groovy にも対応しています。 また、フリックを使ってほとんどの記号をキーボード切り替えなしで入力することができる拡張キーや、カーソル移動を細かく制御できるナビゲーションホイールなど、コード入力を快適にする工夫がいろいろ cool です。 jEdit Emacs の前は、jEdit (Macのみで動作する同名の国産エディタがありますが、それじゃないです) を使ってました。 jEdit は、個性的で素晴らしいエディタです。 Java で実装されていて、MAC、Unix、Windows、 OS/2、および VMS で動作します。 現時点で 200 以上のプログラミング言語をサポートしているので、たいていの場面で困ることはないでしょう。 BeanShell という、Java とよく似たシンタックスのスクリプトを採用していて、マクロ機能も強力です。 豊富なカスタマイズオプションと、プラグインマネジメントシステムを備えていて、非常に多くのプラグインが提供されています。 FTP プラグインを使えば、リモートホスト上のファイルを直接編集することもできます。 ただし、今のところ Markdown のサポートは、貧弱と言わざるをえません。 HTML にレンダリングした結果をエディタ内、またはブラウザを起動してプレビューするプラグインがありますが、編集中のテキストをリアルタイムにハイライトしたり、リンクを機能させたりすることはできないようです。 それと、jEdit もかなりの部分をキーボードだけで操作することができるんですが、そのための設定にちょっと時間がかかり過ぎるかんじがします。 また、キーボードで操作できないプラグインも多いので、完全にキーボードオンリーにはなりません。 秀丸エディタ ずっと昔は、秀丸エディタを使っていたこともあります。 秀丸エディタは、動作が軽快なのが、最大の魅力です。 こちらもまあまあのマクロ機能を備えていますが、Emacs や jEdit のマクロ言語と比べると、いささか見劣りがします。 プラグインシステムはありません。 サポートサイトで、サードパーティ製のシンタックスハイライティングの定義ファイルやマクロのリストを公開していますが、整理なしで羅列されているので、同じことを目的とするものが複数登録されていることがよくあったりして、目的のものを探すのが面倒です。 その他のエディタ Emacs にたどり着く前には、ターミナルでアクセスしなければならないリモートの Unix 系の環境では、Vim を使っていたこともあります。 当時の僕にとっては、ただ直感的でないだけで、GUI の使えない環境でやむをえず使う代替物でしかありませんでした。 初心者にとっては、本当のパワーよりも直感的であることのほうが魅力的なものです。 たどり着いた先がたまたま Emacs でなかったとしたら、おそらく Vim を使っていたでしょう。 やむをえず使ったといえば、インストールが制限されていて、他に選択肢がないときにさくらエディタを使ったこともあります。 が、そのまま使い続けたくなるような魅力は感じませんでした。 Top IDE について IDE といえば、代表的なのは Eclipse と Microsoft Visual Studioですね。 この 2 つでは、僕は圧倒的に Eclipse が好きです。 カスタマイズ性の高さもその理由ですが、プロプライエタリなものにロックインされるのも好きじゃないからです。 このところ、.NET 関連の開発をする機会がないのが幸いです。 最近は、プライベートではもっぱら IntelliJ IDEA を使っています。 けっこう気に入ってきているのですが、まだ使い始めて日が浅いため、これについてはまだ何も言えません。 結局、不満はありつつも IDE は Eclipse に収斂してきました。 こういった IDE のリッチなサポートにすべてを任せるのが、一番だと考えていた時期もありました。 一つの IDE を常に起動しておき、できる限りの作業をそこで済ませます。 それができない場合でも、IDE はバックグラウンドに立ち上げたままにしておき、1 日が終わるまでは、なるべく IDE を終了させない。 OS のデスクトップを作業スペースにするのをやめて、IDE そのものを作業スペースにするわけです。 このやりかたは、ある程度はうまくいきます。 起動の回数を減らすことで、IDE の最大の弱点である起動に費やされる時間を最小限に圧縮し、また IDE にとどまり続けることで、コンテキストスイッチングも軽減することができます。 しかし、やがてはこれにもうんざりしてきます。 やはり、いかんせん遅すぎます。 待ち時間は最小化できても、あれこれいろんなことで、ちょくちょく作業がインタラプトされるのが、次第に耐え難くなってきます。 今まさに頭の中に流れ込んできているインスピレーションを、新鮮なまま逃さず書き留めるにはニブすぎるのです。 IDE のオプションでオフにできるものは、すべてオフにした方がいいという意見を聞いたことがあります。 たしかに、そうすれば割り込みの頻度はかなり下がるはずです。 でも、僕はその意見には懐疑的です。 どんなにイライラさせられるとしても、IDE のたいていの機能はそれなりの理由があって装備されているのです。 すべてのオプションをオフにするのなら、素直にエディタを使ったほうがいいと思います。 IDE の豊富な機能は、魅力的です。 ある面では、その機能が作業の効率を大幅に上げてくれます。 でも、ときにはそれがかえって邪魔になることもあります。 いろんなことができるということは、いろいろ気を散らすネタがあるということでもあるのです。 IDE は、重量級のツールです。 巨大なコードベースの全体を把握し、あっちを覗いたりこっちをいじったりする必要がある場合には非常に有効ですが、範囲を絞って小回りのきくエディタで作業することができるなら、それにこしたことはないのです。 大型船には大型船の、タグボートにはタグボートの役割があるということです。 今は、Emacs と IDE を、場合によって使い分けています。 Top エディタに求めるもの さて、このようなエディタの変遷は、僕がエディタに何を求めているのか ー つまり、僕に合うエディタとはどういうものなのかを示唆しています。 今まで、僕はいったい何が欲しくてエディタを変えてきたのか、考えてみるとこういうことなんじゃないかと思います。 動作が軽快であること キーボードだけで全ての操作ができること 多くのプラットフォームで動作すること 高いカスタマイズ性 幅広い言語に対応したハイライティングやコードアシスト 強力なマクロ ネットワークごしのエディット機能 多くのプラットフォームで動作するという条件には、カスタマイズした内容のポータビリティも含みます。 この込み入った条件は、最初から明らかだったわけではありません。 長年のコーディング経験の中で、徐々に積み上がってきたものです。 1 つの決まった言語しか使っていなかった時には、幅広いプログラミング言語のサポートなど気にしませんでした。 Windows でしか仕事をしていなかった時には、マルチプラットフォームのサポートには注意を払いませんでした。 WEB アプリケーションのクライアントサイドスクリプトを嫌になるほどいじくりまわしてみるまでは、ネットワークごしのエディット機能にあまり必要性を感じませんでした。 Emacs は、上記の様々な条件を完全に満たしています。 現在、仕事上 Mac、Windows、および Linux を使ってます。 それら全ての環境で、Emacs を使用することができます。 しかも、Mac と Windows では、DropBox 経由で設定を共有しています。 今は github 経由でやってます。 本番環境にあるサーバでは、セキュリティ上さすがにムリですが、それでも設定ファイルを手動で持っていけば、ほぼそのまま利用できます。 そんなわけで、今のところ僕は Emacs + Textastic Code Editor を愛用しています。 ところで、 [Emacs] の素晴らしい能力を十分に活かすためには、プラグインの導入によるカスタマイズが欠かせません。 その点で、Emacsテクニックバイブル　～作業効率をカイゼンする200の技～ はとてもいいガイダンスになります。 [Emacs] に同梱のチュートリアルで、基本的な操作はすぐに覚えることができますので、それから、この本に掲載されているプラグインから使いそうなものを手当たり次第に入れてみるだけで、簡単にロケットスタートできます。 それで物足りなくなったときには、どうやったら他のプラグインを探しだしてインストールできるのかも、この本を読めばすぐわかるようになっています。 via Blogger https://ift.tt/26ksK3u 2021-07-04T15:17:00+09:00

Heroku Buildpack Common Lisp を作りました : heroku labs:enable user-env-compile が廃止されたことについて これです。 heroku labs:enable user-env-compile の廃止に対応するために、heroku-buildpack-cl を fork しました。 heroku labs:enable user-env-compile の廃止について Buildpack を使うほうの対応は簡単で、単に heroku labs:enable user-env-compile を使うのをやめるだけです。 既に設定していた heroku config:add は、そのままでちゃんと compile プロセスに渡されます。 Buildpack を作るほうでは、 bin/compile の新しい第 3 引数に渡されてくる ENV_DIR ディレクトリから環境変数を読み込む必要があります。 やりかたは、 Buildpack API | Heroku Dev Center に記載されている、以下のコードを参考にすれば (というか、まるコピで OK) np です。 export_env_dir() { env_dir=$1 whitelist_regex=${2:-''} blacklist_regex=${3:-'^(PATH|GIT_DIR|CPATH|CPPATH|LD_PRELOAD|LIBRARY_PATH)$'} if [ -d "$env_dir" ]; then for e in $(ls $env_dir); do echo "$e" | grep -E "$whitelist_regex" | grep -qvE "$blacklist_regex" && export "$e=$(cat $env_dir/$e)" : done fi } Heroku Buildpack Common Lisp について サンプルアプリ も用意したので、その readme を読んでもらえれば、簡単に動くサンプルが手に入ります。 …だけではさみしいので、以下、日本語で手順を書いときます。 もしまだ Heroku のアカウントを持ってないなら、まず Heroku のアカウント を作って、Heroku Toolbelt をインストールしてください。 サンプルアプリを fork してください。 cd heroku-cl-example してください。 Heroku Buildpack Common Lisp を使って、Heroku アプリを作ってください。 こんなかんじです。 heroku create -s cedar --buildpack https://github.com/craftsmanship/heroku-buildpack-cl.git Common Lisp の実装を選択してください。 heroku config:add CL_IMPL=sbcl または heroku config:add CL_IMPL=ccl Web Server を選択してください。 heroku config:add CL_WEBSERVER=hunchentoot または heroku config:add CL_WEBSERVER=aserve SBCL のソースエンコード問題を回避するには、エンコードを指定してください。 heroku config:add LANG=en_US.UTF-8 デプロイしてください。 git push heroku master これだけです。 Cloud で Common Lisp を使いたいと考えている人は、利用してみてください。 via Blogger https://ift.tt/kyP79vZ 2014-06-30T04:07:00+09:00

プログラミングClojure 第2版 プログラミングClojure 第2版 著者 : Stuart Halloway and Aaron Bedra オーム社 発売日 : 2013-04-26 ブクログでレビューを見る» Lisp 方言なので、Lisper なら理解するのに苦労はない。 Java を知ってれば、なおよい。 今 (2014/6)、PaaS で最もスムーズに利用できる Lisp 族といえば Clojure というところに、この本の価値がある。 via Blogger https://ift.tt/F9thNYQ 2014-06-26T09:46:00+09:00

Gaelyk で日程調整アプリ Any Day 作りました Any Day とは 候補日を設定しといて、参加者に URL を教えとけば、各自の希望日を集められるというものです。 なぜ作ったのか 奥さんに相談されて、そういうサービスをあれこれ探してみたんですが、どのサービスもいまいちマッチしなくて使えませんでした。 なので、もうちょっとだけ自由がきくものを作ろうと。 なにでできているのか おもに Gaelyk + jQuery + Bootstrap でできてます。 ちっさい *.groovy 251 行 5788 文字 *.gtpl 516 行 21042 文字 という、非常に小さな規模です。 行数や文字数を少なくしようという努力は、とくにしてないにもかかわらずです。 アプリ自体ごくシンプルなことしかしてないですが、それにしてもこれほど小さくまとまってるのは、Gaelyk のおかげです。 スピーディ ここまでに使った時間は、たぶん延べ一週間あるかないかだと思います。 Gaelyk を採用したのは初めてなので、次からは最初の少しの学習コストもなくなり、さらにスピーディになると思います。 ちょっとしたワナ i18n プラグインがちゃんと使えてたら、もうちょっと早くあがったかも。 ローカルでは普通に動くのに、App Engine 上で動かすと、文字化けちゃってダメでした。 試行錯誤のすえ、けっきょく多言語対応自体を先送りにしました。 どうやったらうまく動くのか、誰か教えて欲しいです。 あと、言われてみれば「なるほど、そりゃそうだ」なんですが、Gaelyk で jQuery 使おうとして一瞬驚いたのが、”$”の扱いです。 Gaelyk の GTPL (スクリプトレットを含む、JSP っぽい出力テンプレート) は、ざっくり言うとファイル全体を GString として扱います。 “$” 文字は jQuery (あるいは類似の JavaScript ライブラリ) を使用すると頻出するキーワードですが、これは同時に GString 中に式を埋め込むために使われる文字でもあります。 Groovy の経験のある方はピンときたかもしれませんが、埋め込み式をあらわすもの以外の “$” は、すべて “\” でエスケープする必要があります。 幸い、このことは検索すればすぐにひっかかってくるこの議論を見れば、すぐに理解できます。 おかげで、それほど時間をとられずすみました。 それ以外は、すごくスムーズに作れました。 以前 Grails で家庭内イントラアプリを作ったことがあって、そのときもさくさくだと思ったもんですが、Gaelyk はさらにすごいです。 サイト規模とかプラットホームとか、ターゲットが違うので単純に比較することはできませんが。 Gaelyk 、楽しいです。 via Blogger https://ift.tt/pvOzyHN 2014-06-22T13:52:00+09:00

やっぱりオムニフォーカスすごいね 以前、わざわざメールで iCal のリマインダに登録できるスクリプトを作って、OmniFocus はやめたっていうハナシをしました。 Omni Focus で、今はどうしてるかっていうと、結局 OmniFocus に戻りました。 なぜ戻っちゃったのかというと、タスクの見せ方の違いというか、考え方の違いかな。 OmniFocus の場合、これから先のタスクをずらっとリストするんじゃなくて、今やるべきことに集中させてくれるんですね。 OmniFocus では、アラートは普通2回来ます。 タスクの開始が可能になったときと、タスクの期限のときです。 この、タスクの開始可能のアラートが結構効果的で、これがくるまではそのタスクのことを完全に忘れてていいんです。 これ、とても重要なことです。 タスク管理で大事なのは、タスクをすべて把握しておくことではなくて、必要になるまで忘れておけるようにすることです。 把握するのはツールに任せておいて、自分は今のことに集中すること。 これは GTD (Getting Things Done) という TODO 管理手法からくる考え方です。 GTD についての情報は、 GTD のサイトとか Wikipedia を見てみるなり、ググってみればたくさんあります。 OmniFocus は、今もっとも GTD に忠実なツールです。 そのため、他の TODO 管理ツールとはちょっと方向性が違う、独特な雰囲気を持っています。 場合によっては、この独自性のために最初とっつきにくさを感じる方もあるようです。 でも、ちょっと使い慣れてくると、この「忘れておける」ということがまるで空気のように、普段は気にもしないけど、実はとても自然で大事なことになってきます。 実際、僕も iCal リマインダーではそれが十分でなくて、なんだか窒息したような気分になってOmniFocus に戻ってきました。 やっぱり大事なものは、失ってみないとなかなかわからないものです。 そんな自然さが、OmniFocus のすばらしさですね。 それからもうひとつ、「忘れておける」ということをより完全なものにするためには、タスクの実行が可能になったときには、確実に教えてもらえるということが大事です。 教えてもらえることが確実だからこそ、安心して忘れておけるようになるんです。 OmniFocus 2 for iPhone OmniFocus for iPad で、そのために便利なのが、OmniFocus 2 for iPhone と、OmniFocus for iPad です。 これらはすべて、Omni の同期サーバ経由で同期できます。 同期サーバの利用は無料です。 iOS デバイスのユーザにとっては、iOS デバイスの通知センターが、たぶん一番確実なアラートじゃないでしょうか。 やはり、タスク管理には OmniFocus が一番です。 ところで、つい先日 VoodooPad で GTD というハナシを書いたばかりなんですが、これとの関係はどうなんでしょうか？ はい、今は OmniFocus と VoodooPad の 2 つで TODO 管理してます。 なぜ 2 つ必要なのかとか、これらの住み分けのことについては、また今度、気が向いたら書くかもしれません。 via Blogger https://ift.tt/pASL7DH 2013-02-17T19:01:00+09:00

VoodooPad で GTD 2回目 VoodooPad で GTD っぽいことをやってみるハナシの2回目です。 前回は、voodoopad-gtd の導入と簡単な使い方について書きました。 で、ちょっと古いプラグインなので、導入するためにちょっとだけスクリプトを修正しました。 今回は、またちょこっとスクリプトを変更します。 やりたいことは2つ。 Markdown のリストに対応 ページのデフォルトフォーマットが Markdown になっている場合、プラグインが生成する @todo ページ、 @done ページ、および @later ページの内容を、Markdown のリストにする ショートカットキーを変更する 1. Markdown のリストに対応 voodoopad-gtd は、@todo: タグや @done: タグ 、@later: タグをつけた箇所の内容をリストにしたページを生成してくれますが、その内容は単なる改行区切りのプレーンテキストです。 Markdown を使用しているなら、リスト形式にするだけでちょっと見やすくなります。 以下の 3 ファイル全て、同じ箇所を変更します。 Update @todo List.py Update @done List.py Update @later List.py 変更内容は、こんなかんじ。 def main(windowController, *args, **kwargs): - theList = "" + theList = [""] document = windowController.document() if line.find(tag_name) >= 0: - theList += page.displayName() + line.partition(tag_name)[2] + "\n" + theList.append(page.displayName() + line.partition(tag_name)[2]) - theList += "\n\n--\nUpdated at " + time.strftime("%d %b %Y %H:%M",time.localtime()) page = document.createNewPageWithName_(tag_name) - page.setDataAsString_(theList) + separator = "\n* " if page.uti().find("markdown") >= 0 else "\n" + page.setDataAsString_(separator.join(theList) + "\n\n--\nUpdated at " + + time.strftime("%d %b %Y %H:%M",time.localtime())) document.openPageWithTitle_(tag_name) * スペースの都合で、タブ幅は圧縮してます。 手抜きしてるので先頭に空行が入っちゃいますが、むしろ見やすくていいので、放置です。 2. ショートカットキーを変更する デフォルトでは "@todo:" 、"@done:" 、および "@later:" タグの挿入は、それぞれ "Control + t" 、"Control + d" 、"Control + l" に割り当てられています。 ところが、Emacs キーバインドを使い慣れてる人にとって、これらはどれも非常に都合が悪いです。 まるで狙ったかのように、多用するキーストロークばかり潰されています。 そこで、ショートカットキーを変更したいと思います。 "@todo:" タグの挿入は、デフォルトでは"@todo"リストページの生成に割り当てられるショートカット "Control + Shift + t" に割り当て、リストページ生成は "Control + Command + Shift + t" に割り当てます。 "@done" タグ、"@later" タグについても同様です。 変更するファイルはそれぞれ2つです。 TODO Insert @todo.py Update @todo List.py DONE Insert @done.py Update @done List.py LATER Insert @later.py Update @later List.py 変更箇所は、 VPShortcutMask = "control" - VPShortcutKey = "t" + VPShortcutKey = "T" import AppKit と VPShortcutKey = "T" - VPShortcutMask = "control" + VPShortcutMask = "control command" import AppKit です。 DONE 、LATER についても、変更内容は同様です。 見れば察しがつくと思いますが、"VPShortcutKey" がショートカットキーの指定で、"VPShortcutMask" がモディファイアキーの指定です。 "VPShortcutMask" に指定できる値は "control" 、または "ctrl" "command" "option" 、 "opt" 、または "alt" "shift" で、スペースで区切ります。 Shift キーについては、"VPShortcutMask" で指定してもいいですが、上記の変更内容のように、"VPShortcutKey" に大文字を指定することであらわすこともできます。 自分で使いやすいショートカットを割り当ててください。 ほんのちょっとした変更ですが、ぐっと使いやすくなると思います。 via Blogger https://ift.tt/S8Om2an 2013-02-08T13:22:00+09:00

VoodooPad で GTD ひさしぶりの投稿ですが、オブジェクト指向ともプログラミングとも直接関係ないです。 Mac のパーソナル wiki アプリ VoodooPad 5 で、 GTD っぽいことをやってみようというハナシ。 今までは Emacs org-mode + MobileOrg + Dropbox で TODO 管理してました。 でも、最近なぜか MobileOrg の Dropbox ログインで Bad username and password or network error. なんて言われて(もちろん、Email/Password は何度も確認しました)、 sync できなくなってしまいました。 sync なしでも、org-mode 自体は僕の TODO 管理に最適なんですが、 iPhone で見られないのはちょっと痛いです。 いや、まぁテキストなんだから、見ようと思えばもちろん見られるんですが、フォールディングなしの長大な org ファイルで TODO 見る気にはならないです。 なので、これを機に別のやり方も試してみようということで、以前からメモとしてたまに使ってた VoodooPad を、 GTD にも使ってみたいなと。 VoodooPad VoodooPad なら、 VoodooPad for iOS で iPhone/iPad でも気軽に編集できます。 Markdown も使えるし。 さいわい、VoodooPad に GTD 的な機能を追加するプラグインを作ってくれてる親切なヒトがいました。 ここからダウンロードして入れれば OK 。 どこに入れるかは、ダウンロード元のページにも書いてあるし、同梱の README.markdown にも書いてあるんですが、この情報は古いです。 VoodooPad 5 では、 "~/Library/Containers/com.flyingmeat.VoodooPad5/Data/Library/Application Support/VoodooPad/Script PlugIns" です。 あと、スクリプト自体も古い(バージョン3.5用)ので、ちょっとだけ修正してやる必要があります。 Update @done List.py Update @later List.py Update @todo List.py の 33 行目の if page.uti() == "com.fm.page": を、 if page.isText(): に書き換えれば OK 。 使い方は、ダウンロード元のページと、同梱の README.markdown に書いてあります。 一応、簡単に書いておくと 何かメモる (すきなやり方で)。 Take notes (in a somehow chaotic way). メモの中にやるべきこと (タスクとか) を見つけたら、それの前に "@todo:" (Ctrl + T で入れることもできる) か、 "@later:" (Ctrl + L) と書く。 Whenever you find something to be done (i.e: a task) you just add "@todo:" (Control + T) or "@later:" (Control + L) in front of it. タスクリストが見たかったら、 Ctrl + Shift + T を押せば、 "@todo" というページ (なければ生成されます) に、今開いてるドキュメント内の "@todo:" タグが全てリストアップされる。 (それぞれ元のページへのリンク付き) When you need a task list, hit Control + Shift + T and all "@todo:" tags in the current document are listed on a "@todo" page (with a link to the page where the task is) タスクを完了させたら、 "@todo:" タグを "@done:" に書き換える。同梱の"Insert Date"スクリプト (Ctrl + Shift + J) を使って完了日を記録することもできる。 When you complete a task, replace the "@todo:" tag with a "@done:" tag. I use the "Insert Date" script (bound to Control + Shift J) to record the date. 最近完了したタスクをチェックしたいなら、 Ctrl + Shift + D を押せば、 "@done" というページが作られて、 "@done:" のタスクがリストアップされる。 When you need to check what you've acomplished recently, hit Control + Shift + D, and a "@done" page is created with a list of "@done:" tasks. 時間が空いた？それなら Ctrl + Shift + L を押せば、全ての "@later:" タスクがリストアップされた "@later" ページができる。 Spare time? Hit Control + Shift + L and you'll get a "@later" page with all your "@later" tasks. ということらしいです。 さて、これからこいつを使ってみます。 気が向いたら、使ってみた感想とか、また書くかもしれません。 via Blogger https://ift.tt/47p0adY 2013-02-07T19:51:00+09:00

正中頸嚢胞の手術と入院 以前、正中頸嚢胞ができたという記事を書きました。 今回は、そこで予告してた、手術と入院生活について報告したいと思います。 ヒゲソリ準備 自分にとってはあっという間。でも家族にとっては... 痛いのは夜から 回復に向かいはじめればあっという間 入浴はできませんでした 退院後 かかった医療費 ヒゲソリ準備 僕の場合、入院期間は1週間から10日と予告されてましたが、結局ちょうど10日間になりました。 手術は入院の翌日、朝9時から。 7時過ぎくらいから手術着に着替えさせられて、点滴入れられます。 病院の朝は、激早いです。 そのとき、ヒゲソリしてって言われます。 あごひげは患部に近いし、口のまわりは呼吸器を固定するからですね。 あらかじめヒゲソリは準備しときましょう。 記事Top 自分にとってはあっという間。でも家族にとっては... 手術自体は、全身麻酔なのでなんてことないです。 手術室まで歩いてって、自分で手術台に横たわります。 そこで、しばしお医者さんたちの殺伐とした会話に耳を傾けてると、点滴に麻酔を投入されて、あっという間に夢の世界です。 手術に要する時間は、予定では2時間くらいと言われましたが、僕の場合、実際には3時間くらいかかったようです。 その間、病室で待ってる家族には、長引いてることについて何も知らされませんでした。 手術っていうのは、万事順調にいっても、予定どおりの時刻に終了するなんてことは、めったにないものなんだと思います。たぶん。 人それぞれ、麻酔の効き方とか、体質とか違いますし。 ちょっとでも状況を教えてくれたらいいのに...とか思ったりもしますが、執刀医がいちいち実況報告するより、手術に集中していただいたほうがイイに決まってますし。 待つ身としては、少しでも時間がおすと不安でたまらなくなりますけど、そこはじっと待つしかないです。 記事Top 痛いのは夜から 手術後、しばらくは酸素マスク付きです。 2時間は絶対安静で、全く動けません。 それを過ぎたら、トイレまでは歩いてOKになりました。 ただし、はじめは看護師さんの付き添い(もちろん入り口まで)付きです。 看護師さんは、ちゃんと歩けるか観察がてら、酸素マスクがつながってるボンベを運んでくれます。 一人で歩いてOKになったのは、夕方頃、酸素マスクが外れてからです。 さらに、当日はベッドとトイレの往復しか許されません。 病棟内であっても、他の場所に行っていいのは翌日からです。 手術当日、寝る前くらいまではまだ麻酔が残ってるらしく、たいして痛みを感じません。 なぁんだ、これなら入院生活も楽だなぁ。いい休暇かも...なんて思っちゃいますけど、それはワナです。 実は、当日夜から翌日いっぱいが一番辛いところです。 麻酔が切れると、かなり痛いです。 何もしてなくても常に一定の痛みはあるんですが、それは無視できる程度でたいしたことありません。 この時期痛いのは、ツバでも飲み物でも、何かしら飲み込むときです。 正中頸嚢胞を切除するときは、舌骨っていう舌の付け根にある骨の一部も切除し、その奥に続いている嚢胞の根っこまで取り除くらしいです。 舌骨ってのは、口と喉を分けてる喉頭蓋って部分と非常に近いので、舌骨を切除することで喉頭蓋が腫れ上がることになります。 喉頭蓋は、なにか飲み込む時には反射的に動くので、そのたびにすごく痛むんです。 ツバって、けっこう無意識に飲み込んでるものなので、四六時中痛いです。 手術翌日の朝ごはんは、半分も食べられませんでした。 入院食は、最初からお粥を注文しておくことをお勧めします。 それでも最初は食べられないので、毎食前に痛み止めをお願いすることになります。 痛いといえば、首コリとお尻の痛みも、かなりのものです。 正中頸嚢胞の切除では首を切ってるわけなので、しばらく首を動かせません。 なので、最初は仰向けにも横向きにも寝られません。 他の方がどうしてるのかは知りませんが、僕の場合は座って寝るしかありませんでした。 最初は、まるでむち打ちの首コルセットみたいにガチガチに固められてるので、座ってれば首は自然と支えられます。 ベッドのアタマ側を起こして座って寝てると、お尻が痛くなってきます。 病院のベッドって、けっこう固いですし。 あまりに痛くなって目が覚めたら、身を起こしてしばらく普通に座るしかなくなります。 ところが、首の正面を切ってるので上を向くことができず、常に俯き加減になってます。 ずーっと俯いてると、首の後ろがガチガチに凝ってきて、とても痛くなってきます。 これはこれで、すぐに限界が来るので、またベッドに背をあずけて座ることになります。 しばらくすると、またお尻が...の繰り返しです。 最初は、ろくに寝られないです。 それどころか、この上体を前後に傾ける動作は、起きてる間もエンドレスに続きます。 夜ちゃんと寝れないので、昼間もずっとウトウトすることになります。 暇つぶしに何しようかーなんて、ほとんど考える必要ないです。 手術後3日目くらいまでは、嚥下痛とお尻の痛みと首の後ろのコリの痛みが全てです。 嚥下痛には痛み止めをもらうしかないですが、お尻の痛みはいいクッションがあれば軽減できます。 お尻の痛みが軽減できれば、より長時間ベッドに背をあずけたままにできるので、首の後ろのコリも少なくなります。 クッション大事です。 麻酔してる間、口に呼吸器の管を入れるんですが、これが固いのかなんなのか、手術後2〜3日の間、上下の前歯が1本ずつ、ちょっと痛かったです。 まぁ、他の痛みに比べたら、なんてことありませんけど。 手術前に麻酔科の医師から説明されますが、これのせいで手術中に前歯が折れる可能性もあるんだそうです。 歯の弱い方は、これについても一応覚悟しといたほうがいいかもしれません。 あと、手術後に患部を覆うガーゼをとめて、首をぐっと固定するために使用されるテープの粘着力が結構強力なので、肌が弱いとかぶれます。 僕は、でかいのから小さいのまで、いくつか水ぶくれができました。 これは、医師に言えば軟膏をつけてくれます。 ほっとけば治るだろうと思ってしばらく言わなかったんですが、ぜんぜん治る気配がありませんでした。 ある朝、医師の方で気がついて軟膏を塗ってくれたら、翌日にはもう治ってました。 病院で使用されてる薬は、さすがにすごいなぁと、ちょっと感心しました。 テープにかぶれたら、医師にすぐ言いましょう。 記事Top 回復に向かいはじめればあっという間 最初の3日くらいは、ぜんぜん痛みがおさまってる感じがしません。 いつになったらよくなるんだろうって感じます。 でも、それを乗り越えると、急に痛みが減ってきます。 嚥下痛や喉が腫れてる感じは、朝はどうしても残りますが、昼間はほとんど気にならなくなってきます。 そうなってくると、首も少しは動かせるようになってくるので、首の後ろのコリもなくなります。 ベッドに背をあずけていなければならない時間も減ってきますので、お尻の痛みも減ってきます。 あとは、どんどん楽になってきます。 だいぶ痛みがなくなってきても、首を動かした時にはちくちくとした痛みがあります。 これは、縫合した糸がつっているためだと思われます。 抜糸したら、それもすっきりなくなりました。 抜糸は、思ってるより痛かったです。 糸を1本ずつ、ハサミみたいなもので切ってから取り除いていくんですが、「そのハサミで身を切ってない？」って思うくらい痛かったです。 でも、済んだらとてもすっきりしますから、それを期待して我慢しましょう。 記事Top 入浴はできませんでした 僕の場合、入院中は一度も入浴できませんでした。 タオルで体を拭くことしかできなかったわけで、今回はじめてドライシャンプーってのを使いました。 2〜3日したら入浴できるだろうとタカをくくってたので、はじめはドライシャンプーまでは用意していませんでした。 ところが、その後も全く入浴が許可される様子がなかったので、急遽買ってきてもらうハメになりました。 正中頸嚢胞の手術を受けた方が、みんな入浴を許可されないのかどうかは知りませんが、一応最初からドライシャンプーは用意しておいたほうがいいかもしれません。 記事Top 退院後 退院後は、しばらく激しく上を向く動作は避けたほうがいいそうですが、傷口にちょっとモノがあたる程度のことは、問題ないそうです。 子供の頭突きみたいな激しい衝撃は、もちろん避ける必要があります。 退院2日後に診察に来るようにと言われ、行ってきました。 経過は問題ないようですが、まだ軽い痛みは残ってるので、痛み止めだけ処方されました。 あと1〜2回様子を見れば、終わりの予定です。 まだ、傷口周辺は硬さが残り、触ると少しだけ痛いですが、これは1ヶ月くらいでだんだんなくなっていくんだそうです。 また、舌骨からつながっていた嚢胞のスジが、顎の肉を吊ってたらしく、これがなくなったことで、幾分顎がたるんだような状態になってるんだそうです。 僕はもともと太り気味なんですが、言われてみれば、ちょっと2重顎が大きくなってるカンジがします。 このたるんだ状態も、じょじょに戻るそうです。 危険が少ない手術でもやっぱり体力はかなり奪われるようで、退院2日後、手術からは10日経っている今でも、けっこう疲れやすいです。 しばらくは、あまりムリはしないように気をつけたほうがよさそうです。 記事Top かかった医療費 入院費は、差額ベッド代なしの病室で、結局14万円台でした。 予告されてたのは9〜10万程度だったので、1.5倍近く高かったことになります。 もちろん、これは僕の場合の金額であって、治療の経過によって変わってくるはずですので、ご注意ください。 僕の場合、喉頭蓋の腫れがなかなかひかなかったせいで、ずっと抗生剤と痛み止めを使ってたから高くなったのかもしれません。 退院後2日目の診察には410円、痛み止めが400円で、計810円した。 記事Top 医療費についての追記 医療費について、大事なことを書き忘れてました。 高額医療費制度のことです。 エクサムさんのご質問のおかげで、書き忘れてることに気づくことができました。 ありがとうございます。 高額医療費制度は、医療費が一定額を超える場合に、超えた分について自治体(?)が補償してくれる...というカンジの制度です。 すいませんが、こういうことには疎くて、手続きは奥さんに任せっぱなしなんです。 自分が言ってることが正確かどうかについて、全く自信がありません。 ただ、僕が言いたいのは、そういった制度があるということです。 これ知ってるのと知らないとでは、実際の出費がぜんぜん違ってきます。 自治体の制度だとすると、どのみち具体的な手続きや金額などは自治体ごとに違うかもしれませんし、詳細はご確認ください。 僕の場合、1ヶ月の医療費が8万円を超えた分について、補償してもらえるようです。 ここで、1ヶ月のというところがポイントです。 入院期間が月をまたぐと、医療費が分断されてしまって8万円を超えなくなってしまう可能性があります。 そのため、一旦2月下旬から入院する予定になっていたのを、3月上旬に変更しなければなりませんでした。 病院は支払いを退院時にまとめるということは、してくれませんでした。 全ての病院でまとめ払いを受け付けてくれないのか、それとも病院によるのかは僕にはわかりませんので、必要なら事前に病院にご確認ください。 それから、通常は高額医療費制度のお金がもらえるまでには、けっこうな期間がかかります。 でも、僕が入院した病院では事前に申請をしておくことで、入院費の支払い時にその分を差し引いてくれるというサービスがありました。 これについても、事前に病院にご確認ください。 記事Top via Blogger https://ift.tt/jtBTfPH 2012-03-16T13:29:00+09:00

XBox 360、延命成功!? ウチのXBox 360が壊れたわけなんですが、ニューマシンが来るのは4/5でまだ半月も先だし、退院祝いにThe Elder Scrolls V : Skyrim買ってきちゃったし、去年から予約済みのマスエフェクト 3だってもう届くし。 せっかく自宅療養中なのにおあずけなのは、やっぱ痛すぎ。 てことで、巷で噂の「温めて冷まして直す」をやってみました。 「タオル療法」とか「タオル法」なんていう名前でも呼ばれてるやり方です。 HDDなどの増設ハードウェアをすべて外し、ディスクが入っていないことを確認した上で、本体をバスタオルや毛布などで包み、電源を入れて20〜30分ほど放置します。 包んでいたバスタオルや毛布を取り除き、電源を切って20〜30分ほど放置。 以上。とても簡単です。 あとは、再度電源を入れてみて、正常に起動するかどうか確認するだけ。 Xbox 360の本体異常の原因のほとんどは、基板上のハンダのクラックや剥がれが原因なので、過熱状態にして一旦ハンダを溶かすことで、くっつけ直すという作戦です。 結果は...なんと、ほんとに直りました！ 驚きました。すごいことを思いつく人がいるもんですね。 もちろん、これはちゃんとした修理ではなくて、単なる延命措置なので、例の素敵なXbox 360 スター・ウォーズ リミテッド エディション の予約は取り消しません。 でも、それが来るまでのおあずけ期間が少しでも縮むのは、とても嬉しいです。 今回、僕が参考にしたのは、 とか ゲーム翻訳者のブログ　～ゲームトランスレーター～ Xbox 360 Towel Trick 【Xbox 360 タオル法】 とかのあたりでした。 まぁ、直ったといっても、次はもう起動しないかもしれない。 いつまたRRoD (Red Ring of Death)状態に戻ってしまうかわからない。 下手したら、最初から直るどころか止めをさしてしまうかもしれないという、危うい民間療法です。 もう無償修理期間は終わってるし、修理不能になっても構わないという状況でなかったら、おすすめしません。 ハードウェア素人の僕でも、少なくとも2つのリスクが考えられます。 過熱状態にするということは、CPUやGPUに過酷な試練を与えることになります。 それで瀕死のXbox 360くんに止めをさしてしまいかねません。 こんな温度管理なっしんぐなハンダ付けしたら、問題が起こった箇所以外も含めて、全てのハンダが劣化します。 劣化したハンダは、ほんのちょっとした衝撃でも、クラックや剥がれを起こしてしまいます。 なので、一旦直ったとしても、再発する可能性はかなり大きいでしょう。 というカンジで、とてもオススメはできないやり方なんですが、ダメモトでいいならやってみる価値はありますね。 2012-3-17 追記: やっぱりダメでした 一時は成功かと思われましたが、結局ダメでした。 ディスクを入れていない状態でないと、起動しない ゲームをHDDに取り込もうとすると、途中でハング ゲームをディスクから起動すると、開始後数分でハング すでにHDDに取り込み済みのゲームを起動すると、ディスクからの起動時より多少長くもつものの、やはり数分でハング ということで、ダッシュボードまで起動するようにはなったものの、結局ゲームをプレイできる状態ではありませんでした。 がっつりヌカ喜びさせていただきました。 残念です。 via Blogger https://ift.tt/aLZ5zBK 2012-03-16T02:28:00+09:00