GBLシーズン15でACE到達
ポケモンGOの対人戦GOバトルリーグ。シーズン15「隠された宝石」シーズンでACE到達。
昨日、ランク20までの規定の勝利数を達成してもらった初期レートが1953。前シーズンの初期レートが1900ぐらいだったので、けっこうもらえた。
今シーズンのスーパーリーグというレギュレーションは、技変更などがあって前シーズンとは環境が激変。前シーズンが決まりきったテンプレパーティばかり出てきて、今イチ面白みに欠けたのことを考えると、今シーズンはパーティのバリエーションが豊富でかなり面白い。
いちいち一試合ごとに右往左往ジタバタすることになって負けが込むことも多かったんだけど「あーでもないこーでもない」が面白いんでスマホを投げるようなことにはならなかった。かな。
とりあえず。今シーズンも目標はこれで達成。まだまだシーズンは続くので、面白いゲームができればいいなあ、と。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
毎月金をドブに捨てる
個人情報を持つとか、決済が絡むとか、直接ECをやっていたり広告収入が大きかったりWEBで金を稼いでいるので止めるわけにはいかないとか。これらは安全堅牢側にふっておく必要があるので、サイト規模に関わらずそれなりのスペックが求められる。サーバーの維持管理だけでかなり高額となる。
でもそれ以外、いわゆる広報告知ブランディング目的のWEBサイトで、アクセスも1日1万もないような規模なのに毎月ランニングでン万円はない。
・少し見たビックリの例。
サイトとして25年は古い。今どきSHIFT_JISでテーブル組み。スタイルシートが3行程あるだけの静的なHTMLがペタペタあるだけ。metaタグにキャッシュコントロールも書いてないのでページを編集変更しても「ページの再読み込み」をしないと反映されない。制作会社に聞いても原因がわからないと言われたらしい（ほんまかいな）いくらでサイトを発注したのか不明だけど呆れたというか驚いた。シンプルなのと手抜きは違う。
当然アクセス解析もナニソレ状態で効果測定もできていない。リンクをクリックしたらどこに行くのかよくわからない。ページ毎のデザインもバラバラでUI的にひどいありさま。ソーシャルどころか鎖国。IAもくそもあったもんじゃない。
でもって、これをOKとしているから腰が抜けてしまった。こういうのに毎月ン万も払うぐらいなら、サイトを閉めて他のことにその金を回した方がいい。どうせ金をドブに捨てるんだったらわたしの口座に振り込んでください。
千代田区某界隈の零細はネットやITに関して100年遅れてる。古い街はネットも古い。
ショボいデザインばかりのサイトを作ってる無職初老がエラソにいうことじゃないかも知れないけど、見ていてイライラしてしまった。
わたしはそれでも最低限のことは考えている、つもり。
サイトの目的＝誰のため・何のためというのはサイトを作る時にまず考える。雑誌など一般読者ユーザーに向けたものなら何でも同じだろう。
次にサイトに乗せる情報を決定、動線を検討、ラベリングなどディテールも詰める。こうした情報設計がサイトの基礎体力となる。
2009年発行の本だけど『IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計』は今でも通用する名著。わかりやすく丁寧な説明でいちいち腑に落ちる。今でも悩む前にこの本をパラパラめくることが多い。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
iOSデベロッパ更新
app storeでアプリを販売するためのiOSデベロッパプログラムは1年8400円（同じAppleでも、iBookstoreは登録無料）
去年7月11日に登録したのでそろそろ1年。app storeでアプリ内課金型の電子書籍は、よっぽどしっかりプロモーションをしないとまるで売れない。
1年かかって、デベロッパプログラムの登録料すら回収できないので今後は考えどころ。ひとさまの原稿を預かった以上は約束・信用、今回は更新。
『iOSデベロッパプログラムとユリシーズの瞳』 （2012/7/11）
そろそろ原稿の用意もできそうなので、SakuttoBookを注文してiOSデベロッパプログラムに登録（購入）してみた。
更新の手続き。
・iOSデベロッパプログラムに登録（購入）
アクティベーションコードを入力して契約更新。
・アプリ制作のために 以下にアクセス
「Member Center - Apple Developer」 https://developer.apple.com/membercenter/index.action
「Certificates, Identifiers & Profiles」
↑このあたりから入っていって、期限切れとなる証明書とProvisioning を新たに作成する（開発用と公開用で各々２種類ずつ）※ これがかなり面倒くさい。
1) macの キーチェーンアクセス→証明書アシスタント→認証局に証明書を要求
2) ディスクに証明書を要求するためのファイル（CertificateSigningRequest.certSigningRequest）を保存
上記ファイルを使ってここから開発用と公開用証明書を取得・登録する
3) Member Centerにアクセスして証明書を取得する
4) さきほど保存したファイルをアップロードして送信
5) 証明書（ios_development.cer）をダウンロード
証明書をダブルクリックしてキーチェーンに登録（開発用と公開用に3から繰り返し）
こちらのサイトがとても参考になります。ありがとうございます。
『iPhoneアプリを実機で動かす』https://kentaro-shimizu.com/lecture/iphone/step3.html
プログラマでもなく、Xcodeでアプリを作ることができる・作りたいとも思ってなくて、電子書籍を店頭に並べたい、ということで始めたという経緯もあり、ibookstoreがオープンしたこともあり、今後はibookstoreに移行するつもり。
そもそも、わたしが現在利用している電子書籍作成ソフトで作られる電子書籍アプリ（言葉が重複）は、単純な電子書籍なので、間違いなくリジェクト対象。
新作を投入したら既存のまでリジェクトされそうで、恐ろしくて更新できない。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
野良ITで無為徒食
なにもなさず、いたずらにくうだけ。無為徒食と書く。いや、自分のことなんだけど。フリーランスだ、個人事業主だと言ったところで仕事がないんじゃ、ただの５０代無職。
クライアントもなく営業力もないので。
ひたすらマッチングサイトを眺めて、できそうな仕事が流れてたら手を挙げて、うまく合えば仕事にありつく。SES契約というIT系の口入屋に登録して（契約形態が請負の請負の請負とかグレー）たまに流れてくる仕事でできそうなのがあったら手を挙げてみる。けど、現場が求めてるのは30代まで、それも教育、訓練されたエンジニア。わたしのような野良ITもどきだと、上流工程がどうしたとか、工数がどうした、なんて専門用語から摺合せの必要があり、無駄なコストがかかることになるので出番はない。
ただでさえ、あとはボケるだけの年齢だ。ぼーっとしてると脳みそが腐る・腕が鈍るので、phpのフレームワークcakePHPをいじってみたり、jquery mobileでモバイルサイトを作ってみたり、facebookのAPIをいじってウォールに投稿できるようにしてみたり。思いつきで食い散らかし。
公開中の 趣味は読書２ も 創作文芸見本誌会場HappyReading も、今のところ、機能追加のネタも思いつかず、平穏無事安定稼働状態でバグ取りに追われることもなく、perlのコードを書く機会が減ってるので、少しでもなにか作る方向で頭を回しておかないと。
個人でやる以上、頭と体の健康が第一、だよなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
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」
使いやすいサイトにするには
機能追加なのか、機能削除なのか、という記事を見かけて、なるほどなあ、と。なんかあやふやな言い方になっちゃうんだけど、「サービスレベルの向上」イコール、機能を追加すること、と思いがちで、実際、ユーザーの声を聞くと「検索に絞込みがほしい」とか「掲示板から移動できるようにしてほしい」とか、機能の追加要求。なもんで、ついつい現状にない機能をほいほい追加してしまったり。
ところが、アクセスログを解析してると、使われる機能はごく一部。
UIが悪くて用意しても使ってもらえない機能になってるのか、ほんとに使えない機能なのかはおいといて、機能が増えると、ページの中に無駄な動線、意味不明なボタンできたりして、それは「使いにくいサイト」になっているということ。
「サービスレベルの向上」を考えたときに、機能追加するより、機能削除をまず検討すべき。
使われていない機能は、同じリンクで違う動作になったり、予期せぬ動きをしたり、ユーザーにとって使いにくいページになるだけ。
使われていない機能を削除することによって、使われている機能がさらに使いやすく・アクセスしやすくなって、それだけでユーザーのPVや滞在時間が伸びることが検証されている、そうだ。
ひらたく言ってしまうと、シンプルなのが一番。たぶん、盆栽の美と同じですな。
（もちろん、目的に対してシンプル、ということであって、シンプルすぎて、機能が足りなくて、目的達成できないのは、論外）
リニューアルした「趣味は読書２」 https://doncha.net/ はレンタルサーバーの制約もあって、やれることは限られていた。それまでのアクセスログを眺めて、使われていない機能をばっさり切ることで、ページ内に予期しないアクションが減った、はず。
それもあってのことか、継続して使ってもらってるユーザーさんのアクセス頻度が上がっているように見える。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
