さくらのレンタルサーバでは mail delivery agent (MDA) に maildrop が使われているので .mailfilter に設定を書くことで、メール受信時にプログラムを実行できる(サポート対象外)。
$HOME/MailBox/<メールアカント名>/.mailfilter というファイルを作り、
logfile "/home/<アカウント名>/var/log/maildrop/<メールアカウント名>.log" cc "!自分のメールアドレス" cc "| /path/to/my/script" exit
などと書き権限を 600 にしておけば、メールがきた時に自分のメールアドレスに転送するとともにプログラムを実行できる。届いたメールはプログラムの標準入力に渡される。
.mailfilter の文法チェックは次でできる。
maildrop -V 9 .mailfilter < /dev/null
日記アプリ(ジャーナルアプリ)の Day One が今週 Publish というサービスを開始した。
Day One アプリのエントリ画面の右下の Publish のボタンを押した後の画面で「Publish」を押すとそのエントリが Publish のサーバにアップロードされて HTML5 形式になったページが公開される。
もともとプライベートのジャーナル用のアプリなので、公開サービスと連携させるのはちょっとどうなのかと思いもしたけれど、試したところ明示的に Publish したエントリがそのタイミングのみでアップロードされ、勝手に何でも同期されてしまうわけではない感じだ。そういう意味での懸念は大丈夫そう。
Publish したページは以下のような感じ。
整形済みブロックは Day One アプリ上とは違い改行が反映されず auto wrap となる。また今のところ画像がインラインで表示されないとう制約がある。
Publish したページにはアカウントのプロフィールが表示されるけれども、そのアカウントで Publish したインデックスページはないので、基本独立したページができていく感じになる。
位置付け的には Evernote の共有ノートに近い。Markdown で書ける点や、公開ページへの反映を明示的にできる点で Publish の方が個人的には使い勝手がいいと思う。
エントリデータのオリジナルはあくまでもアプリ(と同期をとっている Dropbox 上など)にあり、ネットサービス側にはアップロードで送るという形式は、サービス終了で大切な日記が消えてしまうといった不安感が無くていいな。
SNS の日記アプリもこんな感じでプライベート日記の一部をアップロードする形だといいと思う。Publish だと公開したものを Twitter・Facebook・foursquare でシェアできるけれどもページ自体は全体公開なので、そこをその SNS 内向け公開にできるようなイメージのもので。
「mixi日記や Twitter・Facebook など」と「Blog や Web 日記など」との間あたりのポジションで、両方使っていると利用シーンがちょっと少ないかもとは思う。ただそれらと比べて(機能的にも心理的にも)カジュアルに更新をかけられるので、リアルタイムにアップデートしていくようなイベントエントリを書くのに使うのにいいのかなと思う。
ノート:
(画像は https://dayone.me/publish より)
ようやく Narrate という Day One 互換 Android アプリに出会った。大興奮。
日記アプリ(ジャーナルアプリ)の Day One という iOS アプリを愛用していて自分にとってのキラーアプリなんだけれど、残念ながら Android 版が無いし出る気配もない。日本語入力のしやすさを考えると Android デバイスでジャーナルアプリを使いたいのだけれど、Markdown ファイル + Dropbox 同期なもので代替できるものが今まで見つかっていなかった。そこでようやく出会ったのが Narrate。
なんと Dropbox の Day One アプリフォルダ上にあるエントリファイルと相互同期ができる。Markdown 文法をサポート・位置情報・タグ付け・写真添付機能なども Day One と同じようにサポートしており基本的な部分はほぼ同じようにエントリを書くことができる。天気情報など Day One にはあって Narrate には無いものもあるけれど、普段使いには無くても困らない範囲。Day One で書いたエントリを Narrate で閲覧・変更したり、逆に Narrate で書いたエントリを Day One で閲覧・変更するのも問題無し。
Markdown の解釈に若干の違いがあるのでそこはちょっと意識する必要あり。あと Narrate では全て Markdown として扱われる(Day One ではオプションで Markdown として解釈しない使い方も可能)が、個人的には OK。また Narrate では1行目が必ずタイトル扱いになる。2行目に空行を入れておいても Narrate で編集・保存するとその空行が無くなるという仕様になっている。
既に800強ある Day One のデータと同期させたが、データ量の面では今のところ操作感に問題は無い感じ。
そういえば最初、同期が終わらず泣きそうになった。一晩経っても終わらないのである。もしや何か処理できないファイルがあるのかなと思って var/Dropbox/Apps/Day one/Journal.dayone/entries/ ディレクトリ以下をみたら Emacs の auto-save ファイル (#ファイル名# というやつ)が残っていたので消してみたらビンゴで同期が完了するようになった。ふぅ。
(画像は http://narrateapp.com/ より)
[ Android アプリレビュー ]
Go で書かれている各種ツールを go get しておく場所を作っておく。このあたり定番のディレクトリ名が良くわからないので ~/local/golang にしておいた(~/local/go は Go 環境自体を入れてある)。
先日使い始めた ディレクトリ毎に異なる環境変数を設定してくれる direnv を使い、 ~/local/golang に移動したらここに GOPATH が設定されるようにしておき、そこで適宜 go get するようにする。
$ mkdir ~/local/golang $ cd ~/local/golang $ echo 'layout go' > .envrc $ direnv allow $ go get -u golang.org/x/tools/cmd/goimports $ go get -u github.com/golang/lint/golint $ go get -u github.com/dougm/goflymake
今日は goimports と golint と goflymake をインストール。
goimports は「gofmt + import の自動追加・削除」ツール。golint は Go 用の lint。 goflymake は名前の通り Go の Flymake ツール(on-the-fly 文法チェッカ)。
上の $GOPATH/bin に PATH を通しておく。
if [ -d $HOME/local/golang/bin ]; then PATH=$PATH:$HOME/local/golang/bin fi
go-mode 自体は package.el でインストール済み(package.el は helm を入れた際に設定済み)。
以下今日いれたツールを Emacs から使う設定を追加。
; バッファ保存時に gofmt (あれば goimports) を実行してソースコード整形する。 (add-hook 'before-save-hook 'gofmt-before-save) (let ((goimports (executable-find "goimports"))) (if goimports (setq gofmt-command goimports))) ; M-x golint で golint をかけられるようにする。 (let ((golint-emacs "~/local/golang/src/github.com/golang/lint/misc/emacs")) (if (file-exists-p golint-emacs) (progn (add-to-list 'load-path golint-emacs) (require 'golint)))) ; on-the-fly シンタックスチェックが動くようにする。 (let ((goflymake "~/local/golang/src/github.com/dougm/goflymake")) (if (file-exists-p goflymake) (progn (add-to-list 'load-path goflymake) (require 'go-flymake))))
今日も朝から YAPC::Asia Tokyo 2015 の2日目です。まずは一杯の無限オレンジジュースからスタート。最初はトラックCから。 C の部屋に入れたのはこれが初めてです。なるほど狭め。
言語の特性にあわせて様々なプログラミング言語を活用しているというトーク。サーバサイドで使われているということでちょっと Scala が気になりますが、やはりここでもコンパイルが遅いという話が出ていました。
Go は小さなシングルバイナリを作れるというところがやはり大きな利点。あとはやっぱり Perl はビルドなどのためのツールを作るのに便利だよねという話でした。
Ricardo Signes 氏のトークを聞くのは YAPC::Asia Tokyo 2013 1日目の時(記事)以来です。
前回同様 Perl の機能追加・削除についての話が中心。直観に反するような挙動が修正されるというところは言語としての完成度があがって良いなと。一方、さらに experimental として追加される文法は、ますます変態的になっていくなという印象もありました。
今日は一人でぶらりとTFTビルへ。
リファクタリングを行う理由の中で「Developer Education」という話があって、理解のためにリファクタリングをしてもらうのも良いと言っていて、ああそうだよなと思いました。リファクタリングの素養はあるけれども、チームのコードは知らないという状態の時にはいいなと思います。
あとは、基本的には Martin Fowler の「リファクタリング」を読んでいれば OK な感じです。
ちょっとうつらうつらしてました。あと「カレのヒゲ」はマイクにこすれるので通訳的に要注意のようでした。
Perl 6 における 並列・並行・非同期処理の話。 Perl 6 では言語レベルでこのあたりのサポートがしっかり入ってくるという印象でした。昨日聞いたトークといい、やはり Perl 6 が気になってきました。
Go の各種ツールを使って時間やメモリを消費している部分を見つけてどんどん削っていく様子をライブで実演してくれました。なるほど、ちょっとしたコードでも工夫すると劇的に最適化できるみたいです。
実演中アセンブラコードをチェックしているところや、データが 1 word から 3 words で管理されているという説明などをみて、ああやっぱり Go は C/C++ 的なマシンへの近さやコンパクトさがあるよなとあらためて感じました。
YAPC::Asia Tokyo 最後のトーク(になるかもしれない)となった LT は Kuniwak (@orga_chem) 氏の「Vim script性的解析の光と闇」でした。
CONBU さんが LT の時間内で設営・撤収デモまで実演していて、その素早さに驚嘆でした。まさに神業のレベルです。会期中お世話になりました。
今年はキーノートが無いので LT が終わるとクロージングです。
今年の参加者はなんと約2,130人。今の形での開催は最後と言われている YAPC::Asia は今後どうなっていくのでしょうか。 YAPC::Asia Tokyo 2015 は「The End.」のスライドで幕を閉じました。皆さんお疲れさまでした。
去年の YAPC::Asia Tokyo 2014 では Go 言語の勢いを感じ、その後ちょっとした規模ですが業務ツール開発に使ってみたりしました。
YAPC::Asia Tokyo 2015 では近年になく Perl のトークを見た気がします。しかも今回は Perl 6 のコードををよく見た気がするのは気のせいでしょうか。今回はこれを機に Perl 6 にチャレンジしていきたいと思います。
2019年2月7日 #朝の渋谷
— Naney (@Naney) February 7, 2019
今日もいい日。
DSC-RX0 #RX0 pic.twitter.com/faSbGFv9Es
表やダイアグラムを含むノートを編集・表示するのに Markdown エディタ Typora がかなり良さそう。
Markdown 形式をメインとしてテキストファイルベースでノートを書いていて不便だと思っているのが作表。Markdown ソースファイルで表を編集していて列の追加・削除・入れ替えが必要になった時にはエディタの支援が無いと絶望する。Markdown Mode for Emacs で表編集の機能がいろいろあることを知ってちょっといいかもと思ったけれども、やはり表としてレンダリングされた状態で編集したいなと。
そう思って探してみたら編集画面とプレビュー画面が別れていない Markdown エディタ Typora が表編集もサポートしていると知って試してみた。
使ってみたところ Google ドキュメントで表を編集しているようなのと同様な感じで直感的に表編集できた。欲しかったのこんな感じ!
また表だけでなく
を使ってテキストで簡単な図を書けるというのも嬉しい。 Markdown ファイル中にテキストして書いておけるので、図の画像やそのソースファイルの管理に悩まされないで済むのだ。ノートにちょっとしたロジックツリーを書いておきたいことがあるので良い!
Markdown 文法は GitHub Flavored Markdown ということだしこれは自分にとって主力 Markdown エディタになるのではという予感がする。
※画像は Typora の PressKit https://typora.io/presskit.zip より。
[ ノート・日記はテキストファイルに ] [ Mac アプリケーション ]
Markdown から HTML への変換に MultiMarkdown を使っているので MultiMarkdown 固有の文法が一部使える。
ファイルリストのフィルタで検索しても探せない文字列がある。検索文字列の最後に * をつけると検索できる場合がある。
Android の iA Writer はフォーカスモードにするとカタカタ上下に画面が動くので逆に集中しにくい。
テキストファイルを開いた状態でホームに戻った際に変更があれば自動保存される。ただし再度開いた時に Dropbox 上のファイルが更新されているかのチェックはないので、コンフリクトが起きる可能性はあり。一度編集画面からファイル一覧画面に戻る必要あり。
2003年6月に『日本語の作文技術』を買って読んでから18年。「係り受けの距離を近づける」「修飾語句は大きく長い順に」などのポイントを学んだことが、分かりやすい文章を書くのに大いに参考になっている(体得までは至っておらず、この文章自身まだまだではあるけれども)。
分かりやすい文章の書き方について参考となる本として『日本語の作文技術』をたびたび人に薦めてきた。一方で、民族と言語について著者の強い思いが考えの背景として述べられている点や辛辣な表現がある点などから、スルー力が育っていない中高生には手放しで薦めにくかった。
2004年10月25日に中学生を想定読者とした『中学生からの作文技術』が刊行されていたのを知ったのはいつだったか。作文技術のエッセンスをより平易に説明された1冊のようなので、これなら薦められるのではと今回自身で読んでみた。
なるほど『日本語の作文技術』に比べてかなり読みやすい。要点がまとめられているので、大人にも『中学生からの作文技術』を先に読むのを薦めた方がいいぐらいだ。
主義主張も『日本語の作文技術』よりマイルドなので、これなら中学生でも自分の頭で判断しながら読めるだろう。
学校で習う文法や役物の使い方と本書での説明では異なる部分があるかもしれない。文法について指導要領とは切り離して考える、学校で書く文章は指導要領のルール(スタイルガイド)に合わせるなど本書を鵜呑みにしないことも大切だ。語順の考え方など勘所を学べれば良いと思う。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。