facebookのウォールに投稿するアプリ
使い勝手がよくわからないし、プライバシーというか公開範囲もよくわからないし、妙にうっとーしーオススメされるので、すっかり放置のfacebook。正直なところ、なんか胡散臭くて、魅力を感じないんだけど、ユーザー数を考えるとちょっと調べておいたほうがいいような気がした。
で、この雑記帖のRSSをwallに投稿できればいいなあ、と。有名どころの、facebook graffitiというのを試したところ、反映されない。投稿されない。設定をいじっても沈黙したままで使いものにならない（たぶん、わたしの設定が悪い）
しょうがないんで、自作の方向で。facebookのAPIを触ってみるいい機会だ。
https://developers.facebook.com/apps
アプリを登録するために、携帯電話のメールアドレスかクレジットカードで本人認証が必要。それ以外は twitterのアプリと似たようなもんだ。WEBアプリとして登録。ドメインやアプリの名前、アプリのURLなどを入力して、アプリの app_id app_secret が管理画面で確認できる。
後は、facebookの、認証するためのURLにGETでリクエスト。レスポンスに含まれるパラメータでまたGETして、と。OAuthのやりとりは、OAuth1.0Aのtwitterより、OAuth2.0のfacebookの方が簡単、かもしれない。
具体的でわかりやすい解説は、ほかのページがたくさんあるので、検索してください。
ここでは。
facebookが用意してるSDKはPHPとJavascript。わたしが多少なりとも使えるのはperl。SDKがないので、perlでベタベタ書いていったメモ。（さらについでにいうと、CPANにはfacebookのモジュールがあるので、それを使った方がいい）
とりあえず。facebookの自分のwallにpost、投稿できるまでを忘れないうちに。
access tokenさえ取得してしまえばOK。
その１．コードを取得する
APP_ID、URLは、アプリ登録した時の管理画面に表示されている。
コンマ区切りのパラメータscope。
・publish_stream、wallに書き込む権限くださいね。
・offline_access、access tokenの期限を無期限にしてくださいね。
ということらしい。
[08/28 10:35:26] offline_access は2012/7/5で廃止になった。記事最後に代替手段追記
上記URLにアクセスすると、facebookの、このアプリを使いますか、というページに行くので、そこで承認＝OKすると、facebookから、URLにコードをつけて返ってくる。
URL?code=CODECODECODE
その２．access tokenを取得する
１で取得したコードと、アプリ登録時に取得するapp secretをパラメータに追加して、上記URLにアクセスする。
8行目、その２で作ったURLにアクセス。問題なければ、レスポンス＝htmlの中に、access_tokenが入っているのでそれをメモる。（今回は、自分のブログ記事を流すことが目的なので、そのままaccess token を使う）
ウォールに投稿するには
https://graph.facebook.com/USER_ID/feed ※
というURLにPOSTすることになる。ここでちょっとハマる。USER_IDなんてこれまでの過程で一度も出てきてない。取得した access token を使って USER IDを取得する必要があった。
access token をパラメータにつけてアクセスするとJSON形式でデータが返ってくる。その中に user idという項目があるので、それをメモる。
使ったもの必要なものは以下。
アプリ登録時取得 app_id app_secret
OAuthで取得 code access_token
APIで取得 user_id
※のURLに対して、POSTで本文を投稿する。
本文に最低限必要なのは access_tokenとmessage。（その他のパラメータには、link name caption description picture などがある）
access_token=ACCESS_TOKEN&message=URLENCODE(message)という形式。
これで投稿ができるようになった。ブログの最新記事をfacebookのウォールに投稿するには、本文を適当に整えるだけ。あとでやっつけてしまおう。
SDKがあるので、モバイルアプリも頑張れば作れる、ような気がする。でもなあ、facebookってどうも信用できんのだ。
[08/28 10:35:26]
追記
offline_access を指定することで access token の有効期限は永続的だったが、2012/7/5にoffline_accessが廃止となって、access_token の有効期限をチェックしなきゃいけなくなった。
詳しくは以下のURL（ありがとうございます！）
https://appofit.com/facebook/remove_offline_access/
ウチは、ユーザー権限で何かするわけでもないので、有効期限が永続的に使えるアプリのトークンでwallに投稿することにした。
上記URLに直接アクセスするとaccess_tokenがわかるので、それをメモってハードコーディング。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
perl で QRcode生成
perlは本当にスゲー。こんなのないかな、あるかな、と思ったら、ほとんどすでにCPANに登録されている。ほかの lightweight language の状況は知らないので比較できないけど、perlがあればほとんど用が足りてしまうんじゃないか。
てことで、QRコードの生成。
創作文芸見本誌会場HappyReading のスマホ版を作ったことだし、スマートフォンで見てもらえるように、誘導したい、というのが目的。スマートフォンでちまちまURLを入力するのはうっとーしーんで、QRコードの出番だろう、と。
レンタルサーバーのlolipopには GD モジュールと一部の関連モジュールはインストールされているらしい。ただ、ここで肝心の、QRコードがインストールされていないので、CPANからもってきた。
CPAN https://search.cpan.org/~kwitknr/GD-Barcode-1.15/
↑これをダウンロードして解凍展開。中を見ると、何かをコンパイルするワケでもなく、ただ所定のディレクトリにコピーしてるだけの pure perl モジュール。そのままlolipopにFTPでアップロードしたら、問題なく使えた。
コードは、これだけ。
STRINGの部分にURLとかテキストを入れる。日本語もOKだけど、検索してみると、ガラケーはSHIFT JIS なので、文字コードを SHIFT JIS にしていることが多い。
これで、QRコードの画像 png を出力してくれるので、img タグに、このスクリプトのURLを書いておけばいい。ちょっと調べたのがQRコードの仕様。
ECC というは、エラー修復レベル。
アウトドアなど汚れ・破損が激しそうなところで使う場合には Hレベル(修復30%）、などなど修復できるレベルがあるので、それを指定する。
ModuleSize というのは、文字通りセルサイズ。
ひとつひとつのセルのサイズを指定できる。
Version・型番というのはセル構成＝セル数。
１～40まであって、大きいほど記録する文字数が増える。
て、ウチみたいな素人ヨタ話のブログを見るより、開発者の一次情報を確認しましょう。
QRコードドットコム
画像を生成して表示するのに、ほんの少し時間がかかるので、サイトではajaxを使ってスクリプトを呼び出すようにした。情報としては、URLとサークル名、本のタイトル。
スマホのQRコードで読み取って、URLに飛ぶとその本のページが開く。おお、これは便利だ。便利なはずだ。きっと。だがしかし。
QRコードの活用例として、流通の現場で商品の確認とか、製造の現場での商品トレースとか、バス停で時刻表とか、有効に活用されている。たとえば、WEBへ誘導するのに、チラシや名刺にQRコードがプリントされていたら便利。だけど、サイト上にQRコードを表示して、さてそれってどうなの？PCでサイトを見ていて、そのページをスマートフォンでも見てみたい、というリクエストがそんなにあるとは思えない。
QRコードが使えるのでとりあえずつけてみました感が漂う。
WEBサイト上にQRコードが表示してあって、こいつは便利だぜ、待ってたぜ、という事例があったら、ぜひ教えてください。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
今年2011年公開のWEBサービス
311の震災があって、今まで自宅サーバーで公開していた読書SNS「趣味は読書」を、lolipopに移行。スクリプトをイチから作り直してWEB本棚サービス「趣味は読書２」として2011年4月、全面リニューアルオープン。
https://doncha.net/
掲示板などあれこれてんこ盛りにしていた前サイトと違って、シンプルで使いやすくなったというレスポンスをもらって、運営中・公開中。
ぶっちゃけ。震災で、自宅でサービスを公開することの限界を痛感した。いつダウンするかわからないようなシロモノを公開して使ってもらうわけにはいかない。
文学フリマ界隈での議論を見ていてでっち上げ。
https://books.doncha.net/happy-reading
創作文芸同人誌応援サイト、「創作文芸見本誌会場HappyReading」2011年12月14日公開。好評のようで登録も順調。って、twitterのDMを使って登録のお願いをしていった、のもスタートとして正解だった、かも。
このまま登録が増えてくれると、サイトを作った甲斐があった、というもの。
というふたつのWEBサービスを今年2011年公開できた。
どちらも少しずつとはいえ、使ってくれているひとがいて、うれしい。
で。この「うれしい」気持ちを大切にして、いろんなサービスを考えていきたいなあ、と改めて。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
創作文芸見本誌会場HappyReading
必要だろうと思った機能を最低限つけて、バグをひとつずつ潰して、まず最初の完成形となった。
とりあえずのメモ。
データベースは、mysqlではなくてsqlite。
どうして？lolipopのmysqlは重いので、ページ表示がもっさりしてしまう。レスポンスが早い、というのがwebの絶対正義。
sqliteは複数の同時アクセスに弱いという評判だけど？確かにその通りらしいけど、ウチぐらいのアクセスなら十分。むしろファイルひとつがそのままDBなので、バックアップなどのメンテがらくちん。そっちのメリットのほうが大きい。
mysqlとかpostgresqlのようなRDBが必要になったら、そのときそのままSQLなどは移せる。
データ構成は。
基本的に、一意に決まる本の情報以外の付属情報はすべてタグとして処理。著者やカテゴリなど。でも、イベント情報関係は別テーブルで管理（同人誌の場合、イベント参加情報は重要なので）
詳細ページを閲覧された回数や立ち読みされた回数はまた別管理で。モチベーションのため。
ページ表示に使うためのマスターテーブルは特になくて、idではなくて、ユーザー入力によるテキストのタイトル部分をキーにしている、というのが後々禍根を残しそうな予感。でもたぶん、そのおかげでおそらく内部SEO対策となる、はず。urlとページタイトルとコンテンツのh1の関連が強くなるし、そこで使われるキーワードがアンカーテキストとしてページ上部に出現する、いわゆるSEOとしては理想的な構造。
サイトの目的とか。
立ち読みをしてもらう。
面白かったら作者やサークル、カテゴリで芋づる式に次の立ち読みをしてもらう。
動線はそのために作る。それによって結果として内部SEO対策となる。
表示側。
一覧ページと詳細ページだけ。あとは、利用規約など。
サイトのトップページは必要ない？意図を持ってなにかをおすすめするとか企画するようなサイトではない。なので、単純にひらたく、なんらかの一覧ページをトップにすればいい。
ページの目的は立ち読みのテキストを読んでもらうことなので、一覧も詳細もワンクリックで立ち読みが開くように。
サークル名や著者名など本に付属するデータはすべてリンクとする。面白かったら芋づる式に次を読んでもらいたいから。
登録側。
テーブル構造のまんま。必須項目などはjavascriptでUIを作る。必須入力項目が多いので、少しでも便利にしておきたいところだけど、まだまだ検討材料が多い。
同人誌に限った話ではなくて。デザフェスなんかを見て感じることで。
世間とか時代とかに、もし閉塞感があるとすれば、これからは組織に頼らない個人こそが勝負できるんじゃないかと思う。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ケータイからPCメールを読むために
今どきスマホだろ、gmailだろ、というのはおいといて。わたしはまだシャープの太陽光パネル搭載のガラケー。なもんで、PCのメール（biglobeのメール）を見るのが面倒くさい。というかよくわからない。
Net::POP3 などのモジュールもあるにはあるけど、以前に、同じようなスクリプトを書いてたり、写メール用のスクリプトも書いてあったんで、テキトーにつまんで使いまわせばイケんだろ、ぐらいに考えて、ちょろっと書き直し・書き足ししてみた。とりあえずバージョンは割りとすんなり、ほぼ何も考えず、サブルーチンをちょっとだけ書き直してつなぎ直したら、あっさりケータイからPCメールも取得できるようになった。（Socketぐらいしか使ってないんで、ほぼどんなレンタルサーバーでも使える）
これで、外出先でもケータイでPCメールをチェックできる。
とはいえ、どうも反応が遅い、いや、以前から。
POP３のマニュアルというか検索してわかりやすいページを発見。
https://www.atmarkit.co.jp/fnetwork/rensai/netpro07/netpro01.html
面倒だし、動いてるからいいや、という理由で、使ってたのは、LISTとRETR、QUITだけ。上記ページを見ると TOPとかUIDLとか便利なコマンドがあるので、追加変更。
一度に全部持ってくるのは、迷惑メールもあるし、無駄なので、ヘッダーを取得して一覧して、スパムを削除して、選択して本文を見る、形式に変えたら、自画自賛の便利さ。
自分で使うことしか考えてないので、表示はお粗末でそっけない、dlとpだけ。これでオッケーなのだ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
「趣味は読書２」にtwitter経由検索
twitter連携その２．twitterでリプライ飛ばしてもらって、タイトル検索もしくは著者検索をして、リプライで返す。というやつ。
仕組みは簡単。twitterである程度決まった書き方してもらえば、そこから正規表現でテキトーにバラしてSQLにして投げ込むだけのお手軽さ。
とはいえ、twitter の仕様？ since_id が意味不明でハマってしまった。
since_idは、そのID以降のtweetを拾う。
と思ってたんだけど、どうやっても出てこない。検索しまくったもののよくわからない。しょうがないんで、前回取得した最大のIDをDBに記録。特にパラメータもなしに mention を1ページ20件×5ページ分取得して、記録しておいたIDより小さいものがあったらスキップ、というなんだかアレなやりかたになってしまった。
lolipop のロリポプランでは、cron の最小間隔5分。5分ごと、twitterで、mentionを取得することになる。その間に１００超えるリプライがあったらあふれてしまうので、そのときは最大取得ページ数を増やすことに。現状、たぶんほとんど使われないので、これでも平気、のはず。
一応、ケータイで自分の本棚の検索をできるようにしてあるんだけど、こっちはIDとパスワードをそのたびに入力しなきゃいけない、ちょっとした面倒がけっこうなハードル。ケータイでtwitter見ることが多いので、急ぎじゃなければ（検索結果が返ってくるまで、最大で5分はかかる）twitter経由で検索するかな。
https://doncha.net/about.pl?c=help
https://twitter.com/dokusyo2
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
