技術
July 04, 2016
(何をおもったか) おもうところあって Evernote に保存したノートを全て Simplenote に移したくなった。
そもそも、リッチな文字装飾はいらない。
自分に必要なのは、ただのプレーンテキストだ。
なんてことを時折おもいながら、とてもリッチに文字装飾ができる Evernote を有り難く使っていた。
でも、おもうところがあった。
なので、プレーンテキストで使える Simplenote へ移行。
一応 Mac にも Windows にも iOS にも Android にもアプリがあるし、Web クライアントもある。プレーンテキストしか使わないならこれでじゅうぶんでもある。
この「移行系」の実装をいくつか見たんだけれど、Evernote の api key を取得する必要があるやつが多くて、その取得じたいけっこう面倒くさいんだけど、取得したキーを使って OAuth で token を取得したりと、その先の道もなかなか険しくて面倒。
ということで、Mac のローカルに保存されてるノートから Simplenote に移せないか をヒマな時間にちょこちょこ調べていた。
ローカルには ENML (Evernote Markup Language) という HTML っぽい形式のノートと、SQLite で保存されてるノートのメタデータが見付かった。
HTML っぽい形式なら Mac に入ってる textutil でテキストに変換出来そう。
SQLite で保存されたデータは普通に SQL で検索して、データ形式を調べていたら、なんとなくそれっぽいデータをひととおり発見できた。
あとは、WebService::Simplenote という CPAN モジュールを使えば、なんとか出来るんじゃないか？ってことで作ってみた。
Simplenote は web 認証とおなじ認証情報を使うことで API が使える。
実はこの API はもう古いっぽくて、今は Simperium という API が主流っぽいので、この API を使ってるクライアントはそのうちハシゴを外されるかもしれないけど、一応今時点でまだ使えてる…。
一応、ローカルにある ENML データを読み込んで、SQLite のデータからタイトルとタグをつけた状態で Simplenote にちゃんと保存された。
ただ難点は、WebService::Simplenote で保存されたノートは、絶対に Trash (ゴミ箱) に放りこまれてしまう…。
ただ、Trash からはノートの右上にある折れ曲った矢印のボタンをワンクリックすれば、普通のノートに移行できるので、まぁ手で移すよりはたいした面倒さではない。
移したあとポチポチしてください。
Windows 版の対応とかは自分が使ってないぶんとくに考えてないんで、それ用に誰かやってください。
![EVERNOTE Perfect GuideBook [改訂第2版]](http://ecx.images-amazon.com/images/I/51W6MPUXw%2BL._SL160_.jpg)
そもそも、リッチな文字装飾はいらない。
自分に必要なのは、ただのプレーンテキストだ。
なんてことを時折おもいながら、とてもリッチに文字装飾ができる Evernote を有り難く使っていた。
でも、おもうところがあった。
なので、プレーンテキストで使える Simplenote へ移行。
一応 Mac にも Windows にも iOS にも Android にもアプリがあるし、Web クライアントもある。プレーンテキストしか使わないならこれでじゅうぶんでもある。
この「移行系」の実装をいくつか見たんだけれど、Evernote の api key を取得する必要があるやつが多くて、その取得じたいけっこう面倒くさいんだけど、取得したキーを使って OAuth で token を取得したりと、その先の道もなかなか険しくて面倒。
ということで、Mac のローカルに保存されてるノートから Simplenote に移せないか をヒマな時間にちょこちょこ調べていた。
ローカルには ENML (Evernote Markup Language) という HTML っぽい形式のノートと、SQLite で保存されてるノートのメタデータが見付かった。
HTML っぽい形式なら Mac に入ってる textutil でテキストに変換出来そう。
SQLite で保存されたデータは普通に SQL で検索して、データ形式を調べていたら、なんとなくそれっぽいデータをひととおり発見できた。
あとは、WebService::Simplenote という CPAN モジュールを使えば、なんとか出来るんじゃないか？ってことで作ってみた。
Simplenote は web 認証とおなじ認証情報を使うことで API が使える。
実はこの API はもう古いっぽくて、今は Simperium という API が主流っぽいので、この API を使ってるクライアントはそのうちハシゴを外されるかもしれないけど、一応今時点でまだ使えてる…。
一応、ローカルにある ENML データを読み込んで、SQLite のデータからタイトルとタグをつけた状態で Simplenote にちゃんと保存された。
ただ難点は、WebService::Simplenote で保存されたノートは、絶対に Trash (ゴミ箱) に放りこまれてしまう…。
ただ、Trash からはノートの右上にある折れ曲った矢印のボタンをワンクリックすれば、普通のノートに移行できるので、まぁ手で移すよりはたいした面倒さではない。
移したあとポチポチしてください。
Windows 版の対応とかは自分が使ってないぶんとくに考えてないんで、それ用に誰かやってください。
November 05, 2014
表題のことがしたかった。
Apache の core にある
日本語のドキュメントには明記されてないのに、英語のドキュメントには明記されている罠。
ということで、
Plack-Middleware-LimitRequest - search.cpan.org
使いかたは SYNOPSIS にある通りです。
そもそも、
全体で DDoS 対策するべきであることは間違いありませんが、アプリケーションの用途や性質によって制限値を変えられたほうが幸せになれるケースもあるんじゃないかなぁとかおもいました。
「あっちがこのぐらいの値を要求するから、こっちは本当はこんなに必要ないし受け付けたくはないけど仕方なく大きめに設定してる」
みたいなケースには悪くないとおもいます。
まぁ、当初の目的は
こういうネタ書くの何年ぶりだろ。
うんこちんちん。
Apache の core にある
LimitRequestBody ってディレクティブ使ったら request body が巨大なのとか防げるんだとおもってたら、どうも mod_proxy を使って reverse proxy にしている場合、proxy するリクエストにこの制限は効かないらしい。日本語のドキュメントには明記されてないのに、英語のドキュメントには明記されている罠。
ということで、
LimitRequest* のディレクティブのような挙動を Plack 環境でよしなにやってくれる middleware を書いたらいいんじゃね？ってなってサラっとでっちあげてみました。Plack-Middleware-LimitRequest - search.cpan.org
使いかたは SYNOPSIS にある通りです。
use Plack::Builder;
my $app = sub { ... };
builder {
enable 'LimitRequest',
body => 102400,
fields => 50,
field_size => 4094,
line => 4094
;
$app;
};
なんで、LimitRequestBody の実装だけにとどめなかったかっていうと、Plack が前段で動いているような奇抜な環境の場合にも制限できたほうが嬉しい人がこの世の中には若干いたりするんじゃないかな？という妄想をしたから。そもそも、
LimitRequest* 系ディレクティブって、〜Body はユーザに認められたコンテキスト (VirtualHost や Directory コンテナ内、.htaccess など) で設定出来るのに対して、他の 〜Fields, 〜FieldSize, 〜Line はグローバルコンテキスト (httpd.conf) でしか設定出来ないので、一部スコープにしか影響しないものと全体に影響するものを一つの middleware で実現するのはどうなのよ？っていう感じもありますけど、逆に言えば、グローバルコンテキストでしか実現できなかったものを、一つの $app のスコープ内の挙動にとどめられるってのは考えようによってはメリットでもあるんじゃないかな？と考えました。全体で DDoS 対策するべきであることは間違いありませんが、アプリケーションの用途や性質によって制限値を変えられたほうが幸せになれるケースもあるんじゃないかなぁとかおもいました。
「あっちがこのぐらいの値を要求するから、こっちは本当はこんなに必要ないし受け付けたくはないけど仕方なく大きめに設定してる」
みたいなケースには悪くないとおもいます。
まぁ、当初の目的は
LimitRequestBody をやりたかっただけなので、同様のケースで困っている方がいれば是非ご利用ください。こういうネタ書くの何年ぶりだろ。
うんこちんちん。
January 29, 2014
ひろしまさん (廣島さん) は、これまでたった 1 文字の Twitter アカウント @N を持っていました。
何故「持っていました」と、過去形なのかというと、どうやら先日、巧妙な罠に、本人ではなく 2 社の有名 IT 関連企業がハメられたことによって、ひろしまさんの稀少なそのアカウントが第三者によって盗まれてしまったそうなのです。
2014/02/26 追記:
記事掲載時点では「持っていました」と過去形で表現していますが、ひろしまさん本人によるツイートで、2014/02/25 の昼過ぎ (日本時間 2014/02/26 の早朝) に、この事件によって盗まれてしまったアカウント @N がようやく取り戻されたことがわかりました。
解決まで一ヶ月以上という相当な時間がかかりましたが、無事解決に至ったようです。
何故そんな悲劇が起こったのか、ことの経緯が詳細にひろしまさんの Medium に掲載されていました。
カリフォルニア在住のひろしまさんの Medium は、原文が英語なので (たまに日本語を書くとひらがなしか書かない)、簡単に和訳したものをここに掲載します。
おそらく「まさか自分の身にそんなことは起こるまい」とおもっているでしょうが、これは自分の認識の甘さということより、企業の認識の甘さが原因になっています。だから言ってしまえば「誰の身に起こるかわからない」ということを肝に命じ、文末にある注意喚起をアドバイスとして参考にされると良いとおもいます。
続きを読む
何故「持っていました」と、過去形なのかというと、どうやら先日、巧妙な罠に、本人ではなく 2 社の有名 IT 関連企業がハメられたことによって、ひろしまさんの稀少なそのアカウントが第三者によって盗まれてしまったそうなのです。
2014/02/26 追記:
記事掲載時点では「持っていました」と過去形で表現していますが、ひろしまさん本人によるツイートで、2014/02/25 の昼過ぎ (日本時間 2014/02/26 の早朝) に、この事件によって盗まれてしまったアカウント @N がようやく取り戻されたことがわかりました。
Order has been restored.
— Naoki Hiroshima (@N) February 25, 2014解決まで一ヶ月以上という相当な時間がかかりましたが、無事解決に至ったようです。
何故そんな悲劇が起こったのか、ことの経緯が詳細にひろしまさんの Medium に掲載されていました。
カリフォルニア在住のひろしまさんの Medium は、原文が英語なので (たまに日本語を書くとひらがなしか書かない)、簡単に和訳したものをここに掲載します。
おそらく「まさか自分の身にそんなことは起こるまい」とおもっているでしょうが、これは自分の認識の甘さということより、企業の認識の甘さが原因になっています。だから言ってしまえば「誰の身に起こるかわからない」ということを肝に命じ、文末にある注意喚起をアドバイスとして参考にされると良いとおもいます。
続きを読む
July 06, 2011
Shibuya.pm #16 「夏の正規表現祭り」で、正規表現のお話をさせていただきました。
まぁ、「電話番号にマッチする正規表現」とか「郵便番号にマッチする正規表現」とかよく書かれてるけど、「どれもこれも手緩いよね」って話。
あ、だいぶはしょったかな。
とりあえずスライドに書いたので、発表をご覧になってない方はスライドからご覧ください。
ふと見返すと、このブログで電話番号の正規表現を公表するのは 3 度目ですが、あれからだいぶ経ってますね。
今ではもっと厳密な正規表現を作っています。
そして、Number::Phone::JP に続き、Number::ZipCode::JP という酔狂なモジュールが公開された記念で、郵便番号にマッチする正規表現を今回初めて公開しますが、そもそもここまで厳密な正規表現が公開されること自体、本邦初公開ってヤツでしょう。
Shibuya.pm でも言いましたが、郵便番号は 7 桁あるので数字の組み合わせは 1 千万個 (000-0000 〜 999-9999) あります。
しかし、実際には使われていない郵便番号がその中で 9,859,522 個。
つまり 7 桁の数字の組み合わせ全体の約 98.6% は、郵便番号として「正しい」と判定してはいけないのです。
それなのに、「3 桁数字 ハイフン 4 桁数字は郵便番号として正しい」とするものが多く、憤慨し、こういう正規表現を作らずにはいられなくなった。世の中の多くの人の間違い、これがその原動力になったのです。
いや、憤慨は嘘です。全然嘘です。
ということで、2011-06-01 総務省公表データに基く、電話番号の正規表現、2011-06-30 日本郵便発表データに基く、郵便番号の正規表現をご紹介します。続きを読む
まぁ、「電話番号にマッチする正規表現」とか「郵便番号にマッチする正規表現」とかよく書かれてるけど、「どれもこれも手緩いよね」って話。
あ、だいぶはしょったかな。
とりあえずスライドに書いたので、発表をご覧になってない方はスライドからご覧ください。
ふと見返すと、このブログで電話番号の正規表現を公表するのは 3 度目ですが、あれからだいぶ経ってますね。
今ではもっと厳密な正規表現を作っています。
そして、Number::Phone::JP に続き、Number::ZipCode::JP という酔狂なモジュールが公開された記念で、郵便番号にマッチする正規表現を今回初めて公開しますが、そもそもここまで厳密な正規表現が公開されること自体、本邦初公開ってヤツでしょう。
Shibuya.pm でも言いましたが、郵便番号は 7 桁あるので数字の組み合わせは 1 千万個 (000-0000 〜 999-9999) あります。
しかし、実際には使われていない郵便番号がその中で 9,859,522 個。
つまり 7 桁の数字の組み合わせ全体の約 98.6% は、郵便番号として「正しい」と判定してはいけないのです。
それなのに、「3 桁数字 ハイフン 4 桁数字は郵便番号として正しい」とするものが多く、憤慨し、こういう正規表現を作らずにはいられなくなった。世の中の多くの人の間違い、これがその原動力になったのです。
いや、憤慨は嘘です。全然嘘です。
ということで、2011-06-01 総務省公表データに基く、電話番号の正規表現、2011-06-30 日本郵便発表データに基く、郵便番号の正規表現をご紹介します。続きを読む
October 16, 2010
YAPC::Asia 2010 で LT をさせていただきました。
5 分枠で 100 枚のスライドになったので、かなり早口になりました。
銅鑼は鳴りませんでしたが、きっと 4:58 ぐらいギリギリにおさまったとおもいます。
トーク自体は日本語で行ないましたが、英語圏の方も結構いらっしゃるので、全セリフを決めておき、LT に英語字幕をつける試みをしてみました。
ただシャッフルするだけなのに、やりかたがこれほどまでに出てくるということに、TIMTOWTDI な Perl の特性がよくあらわれているとおもいます。
スライドは slidshare にアップしたものをご覧ください。
毎週毎週一緒に楽しく頭をかかえながらシャッフルをひねり出した弊社の同僚、元同僚の皆様に感謝します。
今年も YAPC::Asia 楽しかったー！
5 分枠で 100 枚のスライドになったので、かなり早口になりました。
銅鑼は鳴りませんでしたが、きっと 4:58 ぐらいギリギリにおさまったとおもいます。
トーク自体は日本語で行ないましたが、英語圏の方も結構いらっしゃるので、全セリフを決めておき、LT に英語字幕をつける試みをしてみました。
ただシャッフルするだけなのに、やりかたがこれほどまでに出てくるということに、TIMTOWTDI な Perl の特性がよくあらわれているとおもいます。
スライドは slidshare にアップしたものをご覧ください。
毎週毎週一緒に楽しく頭をかかえながらシャッフルをひねり出した弊社の同僚、元同僚の皆様に感謝します。
今年も YAPC::Asia 楽しかったー！
There are so many ways to shuffle it
View more presentations from Koichi Taniguchi.
