投稿

ASCII カード

イメージ
そろそろ Macbook Pro でも購入しようかと考えていたところ、 ASCII カード なるものの存在を知り、作ってみた。オリコ版(Mastercard)とニコス版(VISA)があり、海外旅行傷害保険が自動附帯という点だけではあるが優れていたので、オリコにした。 Macbook Pro のようなノートパソコンの場合、外に持ち歩くことを想定すると、保険のようなものは考えておきたくなる。とはいえ、AppleCare+ はそれなりに高くつく。AppleCare+ が念頭にあって、ASCII カードの補償内容を考えた場合、結構いいかなと思った。 例えば、13 インチ/タッチバー付/メモリー 16GBの Macbook Pro だと 220800 円(税別)で AppleCare+ は 25800 円(税別)である。AppleCare+ によって、購入後 2 〜 3 年目に自己負担 11800 〜 33800円(税別)で修理が 2 回まで受けられるようになる。 一方、ASCII カードの保証では、購入後 3 年を過ぎてからも、永久に何回でも補償が受けられる。ただし、自己負担は 1 万円で 1 万円を超えた分が補償され、上限は 1 回 10 万円。また、通常の故障に対する補償はされない。あくまでも、盗難や事故によって破損したようなケースについて補償対象となるので、AppleCare+ とは全く趣旨が異っている。 しかし、外に持ち歩くノート PC で補償を付けたくなる理由は、まさしく通常の故障ではなく偶発的な事故を恐れてのことなので、ASCII カードの補償内容でいいと思う。AppleCare+ が購入後 3 年目までで上記のケースでは 25800 円(税別)であるのに対して、ASCII カードの場合は年会費 1950 円(税別)であるから、3 年間で比較しても 5850 円(税別)となる。ASCII カードがあれば、AppleCare+ を付けようかどうか悩む必要はないと考えたわけだ。 ところで、カードが送付されて規定に目を通してから初めて気付いたことが一つだけあって、ASCII カードで購入しなかった場合は補填率 70% のところ、ASCII カードで購入した場合は補填率 100% となるという部分だが、これが購入後 2 年までという制限があった。2 年を

QNAP で仮想ホスト運用を断念

実家の QNAP NAS の貧弱な性能では、CGI が使い物にならず、Web サーバーは結局、さくらインターネットでマルチドメインを運用することを廃止できないという結論に達した。その上、StartSSL が使い物にならなくなってしまったため、Let's Encrypt に移行したのだが、その機会に、QNAP のポートの割り当ても、デフォルトに戻した。つまり、Web UI 用に、80 (HTTP) と 443 (HTTPS) を割り当て、仮想ホストに 8080 (HTTP) と 8081 (HTTPS) という形である。index.php も元のものにした。 XXX.myqnapcloud.com 用のセキュリティ証明書だけ、Let's Encrypt で用意し、Web UI に HTTPS でアクセスしても証明書エラーが出ないようにしておいた。

Firebase Remote Config

Firebase Remote Config は Resources をクラウド化したようなもので、クラウド上から Resources の定義値を更新するような感覚で利用できる。Resources の内容の更新のためだけに APK を都度アップデートする必要がなくなるので、かなり勝手が良くなる。 もちろん、Resources の値にアクセスする場合よりはいくつかの手続が必要だが、かなり簡素化されている。一定の手続というのは、1: デフォルト値として用意したアプリ内部のリソース(XML)ファイルを読み込む; 2: キャッシュをクラウドから取得して更新する、という 2 つの手続である。後者は、キャッシュの更新間隔を決めることも含む。 以上の理解には、Google 公式ガイドの Sample App Walkthrough とそのサンプルの ソースそのもの を見るのが無駄なく必要十分だろう。 具体的内容については、Google 公式ではないどこかの誰かのブログのサンプルコードの類から学ぼうとしない方がいいと思う。

池上彰の英語力

イメージ
イランの街で掲げられた“DOWN WITH THE U.S.A”を見て曰く『「打倒アメリカ」と書いてある』ってドヤ顔で池上さん…… アメリカが中東(シリア)なんかで空爆してるのを指して、「爆弾がアメリカと一緒に降ってくる」って言ってるだけ、絵に描いてあることそのまんま、中学レベルの英語でしょう。 誰が「打倒」なんて言ってるかというと、イランの人がそのポスターで言っていないセリフだから、他ならぬ、池上さん(の脳内の誰か)のセリフってことになる。 というか、ちょっと以前にも、池上さんの出身母体である NHK の通常のニュースで、アメリカのシリア攻撃に対してイランで反米抗議運動が広がってるというものを見たことがあるけど、英語では“Americans go home!”で、単に中東への派兵をやめて「家に帰れ」ということしか言ってないのに、NHK の字幕は、「アメリカに死を!」だった。NHK と NHK ブランドに肯定的な日本全国津々浦々の視聴者はこういうレベルで世界を認識したつもりになっている。 池上彰は英語が堪能である。自らの海外取材に駆使するだけではなく、NHK時代には国際シンポジウムの司会も英語でこなした。 (公式ファンクラブの解説より) 大学入試で英語の配点が高い慶應大学の出身。 これが日本の英語の現状。

Firebase と Admob のリンク

イメージ
Firebase アカウント(A)で独自の Admob アカウントを用意しないで、別の Admob アカウント(B)に Firebase プロジェクトをリンクしたい場合のポイント。 普通に Admob アカウント(B)で Firebase とリンクしようとすると、その Admob アカウント側の Firebase アカウント内に新規にプロジェクトが作成されて Admob とリンクしようとする。これを避けるには、Admob アカウント(B)側の Firebase アカウント内に、Admob とリンクしたい Firebase(A)のプロジェクトを共有しておく必要がある。これは、Firebase(A)で、Admob アカウント(B)をユーザーとして追加しておく必要がある。この時、権限は オーナー権限である必要がある ようだ。編集権限だと、Admob アカウント(B)側の Firebase アカウント内に Firebase(A)のプロジェクトが共有された状態になることはなるのだが、依然、Admob からリンクできない。 オーナー権限で共有された状態であると、Admob からリンクする際に、(新規プロジェクトの作成ではなく)既存のプロジェクトとして選択できる状態で認識されるようになる。

Handler(mainLooper).post() を使うやり方と、runOnUithread() を使うやり方の違い

基本的に runOnUiThread() は Handler(mainLooper).post() へのラッパーとして用意されているが、 メイン UI スレッドから実行する場合は挙動が異なる 。 メイン UI スレッドから実行した場合は、Handler(mainLooper).post() されずにスルーされて、そのまま Runnable の内容を実行する扱いとなる。なので、View の再描画など、強制的にタスクを発生させたいがために Handler(mainLooper).post() したい場合に、メイン UI から runOnUiThread() を使っても無意味なので、この場合は明示的に Handler(mainLooper).post() を記述して実行する必要がある。 cf. runOnUiThread vs Looper.getMainLooper().post in Android

PreferenceFragment

1 年以上ぶりくらいに本格的な Android プログラミングに回帰。そのせいか、固定観念から多少自由になったかもしれない。 例えば、PreferenceFragment。古い PreferenceActivity が obsolete になって、代わりに PreferenceFragment を使うように 公式リファレンス に書かれている。それで、ネット上の情報をいくつか見ても、受け売りの解説ばかりなものだから、皆が自前の MyPreferenceActivity 的なるものを用意して、その中で PreferenceFragment を実装するような感じにしてる。 そこで今回、「そもそも、MainActivity で直接 PreferenceFragment を使っちゃいけない理由なんてあるのかい」と思って、やってみたら──できた! 今までの MyPreferenceActivity をわざわざ専用に用意して PreferenceFragment を使うやり方って、何だったのだろうか……。 受け売り情報撒き散らすのやめて欲しい。 いや、まあ、ブログなんだから、本来は各人の私的なメモという性格のものではあるんだろうけど。

プログラミング・パラダイム

結局、「オブジェクト指向プログラミング(OOP)」というのは、1) 手続指向は構造化で、2) データは構造体で、ということであり、この両者を、3) 構造化された手続(メソッド)を、構造体(オブジェクト)単位で整理することでまとめた、というだけの話であり、これ以上でもないし、これ以下でもないのではないかと思う。 手続自体は、あくまでも構造化プログラミング的な観点で整理を行なうべきで、これを生半可なオブジェクト指向的観点で整理すると、コードが無茶苦茶になって却って“百害あって一利なし”といっても言い過ぎにはならない気がする。少なくとも、自分の場合はそうである。 そうやって、構造化プログラミング的にすっきりと整えられた個々のコードが、集合して複数のコード群としてそのままそこいらにぶちまけられている時に、手続指向の限界が急にクローズアップされてくる。 この時に整理整頓の“容れ物”として俄かに脚光を浴びることになるのが、構造体(オブジェクト)である。手続のためのコードをそのまま“裸”でそこいらにぶちまけては置かないようにしよう、必ず、構造体に入れられた(カプセル化)状態で置いておくことにしようね、というのが僕流のオブジェクト指向像である。 上のことをちゃんと自覚していないで、「オブジェクト指向スゲー」で何でもかんでもオブジェクト指向のノリを持ち込もうとすると、むしろコードの見通しが悪くなって、あっちへ飛んだり、こっちへ飛んだりと、ダイクストラ先生が「goto は使わないようにしよう」といった時代の事情に逆戻りして、あっちのメソッドこっちのメソッドを飛び回るような、いわば「goto なきスパゲッティ化プログラミング」に陥ってしまう。 新しいコードをスクラッチで組んでいく時、ここは手続指向で素直に、一つ一つの処理を継ぎ足して行ってプログラミングするのが、やはり王道なのではないかと思う。そしてそのコードが伸びるにつれ、(2回以上)多用される同様の処理は、サブルーチンとして分離する。そのことで、「コードをコピー&ペーストして使い回すことを避ける」というのが、構造化プログラミングの単純かつ肝となる原点だと思う。ある処理に関するコードが記述される場所を一元化することで、後に変更の必要が生じた時に、あちこちを修正して回るというようなことは避けないと、例えば、一部を修正し、一部

オブジェクト指向プログラミングと構造化プログラミング

オブジェクト指向プログラミング(OOP)と構造化プログラミング(手続指向)を対立する概念だと思っていたが、どうやら間違っていたようだ。 詳細は別の機会でもあれば書くかもしれないが、両者は共存可能、というか共存させるのが適切だと思った。 この結論に達することで、メソッド定義の private と public、static と dynamic の使い分けもはっきり線引きできるようになったと思う。 構造化プログラミングは static で、そのうちのサブルーチン部分は private、メインルーチンは public。 オブジェクト指向プログラミングは dynamic で、オブジェクトの操作に関するインターフェイスとしてのメソッドは public。 大ざっぱな分け方としてはそんな感じ。

期間限定dポイントの裏技

イメージ
年末年始のキャンペーン( 【dケータイ払いプラス】冬のスーパァ~チャンス! )で獲得したボーナスポイントの期限がそろそろ迫ってきたので、適当に対処しておきました。 合計ポイント数は変わっていませんが、10 回の処理の結果、内訳の期間・用途限定ポイントが 500 ポイント分減って(通常ポイントと入れ替わって)いるのがわかります。 2017-03-12 追記:3月初めに、ローソンのシステムが修正され、上記裏技が塞がれたようです。(期間限定ポイントはすべて変換済ではあったものの)たった一回しか活躍の機会がなかったとは、とほほ……