ku-sukeのブログ

Just another hatena blog

(追記)iOS 9のSafariの広告ブロッカーを検知するテスト

もともとPCの世界にはAdBlockというのがあって、僕も愛用しているのですが、それを良しとしないサイト運営者向けに、FxckAdBlockというJSがgithubで公開されています。

github.com

動作原理としては、存在するはずの広告枠のCSSをチェックし、隠されたりそもそも存在しているかどうかを調べ、NGなら警告を出すというものです。

 

追記:2015-09-20

--ここから--

動作原理としては、特定のclassを含む要素を作成し、CSSとして隠されているかを調べるというものでした。iOS 9のAdBlockerアプリはJSの通信をブロックするものが主流で、CSSで隠すものは少ないため、検知があまりできないようでした。

シンプルに検知するなら以下でどうかなーと思ってます。

<script type="text/javascript" src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
<script type="text/javascript">$(window).load(function(){
if(typeof window.google_ad == "undefined"){$("#header").append("<div style='color:red;'>AdBlock Detected</div>");}
if(typeof window.ga.loaded == "undefined"){$("#header").append("<img src='http://mydomain.example.com/aaaaa.php' />");}
}
);</script>

要は、ページのロード完了時点で主要なタグのオブジェクトの存在有無を確認する感じですね。

Google Adなら、window.google_adとか、GAならwindow.ga.loaded オブジェクトをtypeofして"undefined"じゃないかを調べる感じですね。

--ここまで-- 

 

このブログにはそもそも広告を入れてなかったのですが(ZenBackの下部除く)実験的に復活させてみたうえで上記のJSを導入してみました。(今はもう外しています。)

f:id:ku-suke:20150919094832p:plain

 

みなさんのAdBlockerでの検知状況に関して、@ku_sukeかこのブログのコメント欄にてご報告いただければ幸いです。

 

ちなみに、しばらくしたらうざいので消します。→消しました。)また、コードを下においておきます。

<script type="text/javascript" src="https://raw.githubusercontent.com/sitexw/FuckAdBlock/master/fuckadblock.js"></script>
<script type="text/javascript">
// Function called if AdBlock is detected
function adBlockDetected() {
$("#header").append('<div style="height:360px;background-color:red;font-size:72px;">AdBlockを検出するテスト</div>');
}

// and|or
fuckAdBlock.setOption({
debug: true
});

if(typeof fuckAdBlock === 'undefined') {
adBlockDetected();
} else {
fuckAdBlock.onDetected(adBlockDetected);
fuckAdBlock.onNotDetected(adBlockNotDetected);
// and|or
fuckAdBlock.on(true, adBlockDetected);
fuckAdBlock.on(false, adBlockNotDetected);
// and|or
fuckAdBlock.on(true, adBlockDetected).onNotDetected(adBlockNotDetected);
}
fuckAdBlock.check();
</script>

 

 

microserviceはしんどそうだけど、2層くらいはいいよ

今年携わっているクライアントのシステムを2層化するように進めているんだけど、けっこうアリだなと思うようになってきたので書き留めてみる。

 

■2層システムとは

最近microserviceが話題になってるんですが、役割ごとに多数分割するのではなく、MVCでいうところのMとVCの2つに分割する感じです。

 

図を後で書く

 

■2層システムのそれぞれの役割

バックエンド(データレイヤーとか呼んでる)は、業務要件に適したモデルをJSON APIで提供します。出力だけじゃなく会員登録や各種CRUDができるようにします。

 

逆に、フロント側は原則データベースを持たず、REST APIを用いてウェブアプリケーションを構築します。場合によっては1画面複数APIを叩くので、適宜キャッシュや非同期処理ができるといいですね。

 

■2層システムに分ける意義、幸せなこと

・システムの寿命というかライフサイクルが違う

 一般的にプレゼンテーション層というのは、自社のビジネスではなく世の中の進化に左右されがちです。やれGoogleアルゴリズムを変えたとか、スマホの比率が急に増えたとか、AppIndexingでWebと同じ内容をアプリでも提供した方がいいとか、アドテクなどマーケ系システムのJSと連携したりとかです。

 

その反面、サービスがひと通り立ち上がったあとのビジネスロジック層というのは、それほど頻繁に変わらないし、変わる場合も自社の年間や四半期の経営計画に沿っておちついて計画できます。

 

それらのライフサイクルというところで分断することで、たとえば表側はNodeJSなどスクリプト言語の軽量なものでかき、長期間コードベースを維持するくらいならさくっと捨てて書きなおしたりしつつ、バックエンドはとにかくパフォーマンスと可用性を重視して、GoやJava/Scalaなどで書くといった具合の技術の選定がしっくりきやすいと個人的に感じています。

 

また、フロント側にデータベースを持たせなければ、サーバのセキュリティ要件をやや緩和しやすくなるきがしますし、バックエンド側をオンプレに置いてhttpsポートだけ開けて、フロントはGAEなどクラウド化するというのもやりやすそうですね。


・業務知識レベルに応じた分業がしやすい

もうひとつ、ある程度の規模のウェブアプリケーションとなると、人の入れ替わりでブラックボックス化しやすいという問題があります。ドキュメントをメンテしたとしても巨大で、外注さんに来てもらってもなれるまで時間がかかったりします。

 

そこで、業務知識も必要なビジネスロジック部分は、ある程度なれた人間を中心に構成し、ミスのないように設計実装をします。そうして出来上がったAPIをドキュメントも含めパッケージングすることで、歴の浅い人や外注さんがプレゼンテーション側を担当し「そこだけ見れば良い」という状況をある程度作り出すことが可能になります。

 

もちろんマイクロサービス的な保守コストの増加というのは少しはあるのですが、それを上回るメリットがあると感じていますし、APIのバージョニングを用いることで、/v1/は2016年までメンテ、/v2/は2017年までということが計画しやすくなります。

TVなどなかなかアップデートされない機器向けに提供する場合を想定し(/v12-lts/のような)5年間の維持を約束するバージョンも提供してもいいかもですね。

 

微妙に、API化するほどじゃないけど、フロント側にデータベース持たせたくないなぁとかいう要件がちらほら出てくるので、当然ながら銀の弾丸ではないのですが、すでにあるていどビジネスが立ち上がっているウェブアプリケーションには結構おすすめだなと思いました。

1万円の価値(と企業規模と業務システム)のはなし

最近、おっさんエンジニア諸氏と久しぶりに飲みに行くときによくする話があるのですが、社員50人の会社から2000人(当時)の会社に転職して、あるいはもっと歴史ある企業のお客様と接するときに痛感することが有ります。

 

本題に行く前に飲みの席で出た具体例を。

 

とあるクラウド形式で提供されるサービスが有り、それは従量課金のクレジットカード払いが標準でした。そこで日本のとある会社が2万円前後の微変動する実費のサービスを請求書払いで月5万円強で企業に提供していました。

 

そこで、「それはぼったくりだよね」という話になったところで、僕が「そんなこともないんじゃないかな」という話を入れました。

長い間日本企業は稟議で予算確保、月末締め、翌月末払いの請求書払いを基本としていて、それをベースに社内システム・人員含む体制が構築されているので、そこからはみ出る処理は手間がかかるんですわ。という話をしました。

 

■日本的な業務の仕組みとあわない

 

たとえば前述の請求書払いの月5万円のサービスだと、5万円×今会計年度末月までの利用費を稟議に上げればいいわけです。予算確保と見積書、支払いが一致するわけですね。

ところが前述のクラウドサービスをそのまま使うとなると話がややこしくなります。

まず、コスト見積がわかんないので、多めに稟議をあげます。100万円とか。そうすると実費30万円だったとしても100万円の予算確保をベースに売上見込みを立てるような業務システムがあるので、そのフォーマットにあった作文を作るわけです。「150万円儲かります」みたいな。

あるいは、ぎりぎりの予算を通そうとすると、1円でも超えた瞬間大慌てで支払期日までに追加の稟議を挙げないといけません。「利用数が突発的に発生し5000円超えました。」みたいな。

さらに会社によっては「見積書の添付をお願いします」と言われることも。。。

 

無事に予算が確保できたら、次はコーポレートカード使用申請です。こちらも限度額があるので注意が必要、かつ、使用額の見込みが不安定となると経理はいい顔をしません。「もし限度額超えて決済できない案件ができたらどうするんですか!」と

 

そういった経理担当を説得し、はれてサービスを使い出すと早速月末が訪れます。実際の使用料金が確定したので先の経理担当に報告します。「今月は$198でした。」「それ何円?」「今日のレートでぐぐったら23,543円です。」「請求タイミングのレートで確定してくれないと困るんだけど」「えっと、いつだっけ。。」

そして決済タイミングの為替レートで説明を終わらせると「それでは領収証の原本を送付してもらって下さい」と言われたりします。ないよ。Webの管理コンソール見てよ。あってもPDFなんだけど「原本」って何さ。

 

■言いたいことは業務システムのクソさではなく

 

ようするに、クレジットカードでドル払い、従量課金で年間コストが正確に予測できないサービスは、大企業の非IT部門との間で多大な調整コストが発生します。そんな事務処理に毎月数時間費やすとしたらどうでしょう。それが月3万円で解決できるなら払うという企業担当者はめちゃくちゃ多いです。さらに紙のNDAも結ばしてくれると最高。

 

ここで表題の1万円の価値になるんですが、零細企業、あるいは個人事業主にとって毎月3万円って大金だと思うのです。月の売上が100万円とかだと3%じゃないですか。

 

でも、月の売上が1億とか、10億になってくると、3万円なんて誤差でしかないわけです。なので「日本のトラディッショナルな社内標準のワークフローでできるようになる」ことは、大企業にとっては数万円、へたしたら数十万円くらい喜んで払うわけです。

 

僕が1万円の価値っていうのを感じたのは、やっぱ大企業って機材や検証機はケチらないし、いざ広告打つぞってなったら、数万円単位じゃなく数百万円単位だし、逆に月間の売上1000万円くらいだと失敗とみなされるし、子会社が独立して8億円の売却益が発生しても、「当期純利益への影響が軽微なため」って発表しちゃったりして、違うなーと思うわけです。

 

もちろん、そこで所属する人間も、家に帰ればただの人なので、卵1パック188円で高いな、と思ったりするわけで会社人間としての金銭感覚とのギャップでも考えちゃうわけです。

 

■結論:本質的な価値ではないところも含め「顧客価値」

 

だから僕は、もし日本でB2Bのサービスをやるなら、固定金額や請求書払い+営業部隊っていうのは(必要とは言わないけど)顧客提供価値の一部だと思ってます。価格帯によっては本質的な価値よりもそっちのほうが上回る場合もあるんだけど、そこはサービス設計としてグローバルじゃなく日本市場をターゲットとするならアリだと思います。

 

技術者の人って本質的な価値しか追求されない方が結構多いので、こういうはなしをおっさんエンジニア諸氏とすると盛り上がるわけですw

 

※そんなクソみたいな業務システムになってる企業は滅びればいいという皆様には同意しますが、おおいんですよ。普通に。売上1億円超える企業だとこっちのほうがスタンダードだと感じます。

 

※その分、大口契約の可能性も高いわけで。めんどくさいから年間契約で10ユーザー分よろしく的な。大口契約になればサービス提供側も、事務処理コスト分サービスに転嫁しなくていいので、本質的になりますね!

Bootstrapよりキレイ!Googleのマテリアルデザインキット

Bootstrapの見慣れた感というか、モック感から脱却しようとFoundationとかに手を出しかけてたのですが、Googleがだしてきたマテリアルデザインキットがすごく良かったので紹介します。

 

f:id:ku-suke:20150804202136p:plain

 

たとえば管理画面風のデザインはこれ

 

ほかにもBootstrap風の上部メニューのデザイン(Android)もあったり

 

f:id:ku-suke:20150804202525p:plain

 

コンポーネントと呼ばれる部品も充実しています。これ見るだけで色々できそうな気がしますね!

 

f:id:ku-suke:20150804210236p:plain

 

Blog風など幾つか提供されています。いまとあるサイドプロジェクトで簡易的な管理画面をつくろうとしてたのですが、早速活用していい感じに仕上げることが出来ました。

 

ダウンロードすると全テンプレートが含まれているので、コピペで組み合わせるだけでも結構いい感じに出来ます。Bootstrapに飽きてきたら、ぜひ使ってみてください。

 

www.getmdl.io

LinkStation LS210D にjets3tいれてGoogle Nearline Storageにバックアップ

MacBook Airの容量がいっぱいだったので、先日安かったNASを買いました。

 

 それで、ひとしきりバックアップとったあと、MacBookからデータごっそり抜いて空き容量200GBまで戻したんですが、そうするとやっぱり心もとないので、クラウドにバックアップを取ることにしました。

 

LinkStationは下位機種でもいろいろいじれるみたいなので、早速その通りやってみました。(2015年7月時点の情報です。真似する場合は自己責任で。)

 

今回アップロード先に選んだのは、Google Nearline Storageです。Amazon Glacierとちがって、取り出すときも3秒程度の待ちが入るのみとなり、おねだんも1GB1円程度なので、お買い得です。

Dropboxはじめとする同期型ストレージでもいいのですが、いまのところ上位プランにしてないのでこちらにおさまりました。

 

1.SSHを使えるようにする

この方法が今でも使えました。これを使って、acp_commanderでSSHを使えるようにします。

% java -jar acp_commander.jar -t [LinkStationのIPアドレス] -ip [LinkStationのIPアドレス] -pw [LinkStationのadminのパスワード] -c "sed -i 's/UsePAM yes/UsePAM no/g' /etc/sshd_config"
% java -jar acp_commander.jar -t [LinkStationのIPアドレス] -ip [LinkStationのIPアドレス] -pw [LinkStationのadminのパスワード] -c "sed -i 's/PermitRootLogin no/PermitRootLogin yes/g' /etc/sshd_config"
% java -jar acp_commander.jar -t [LinkStationのIPアドレス] -ip [LinkStationのIPアドレス] -pw [LinkStationのadminのパスワード] -c "(echo [設定したいrootのパスワード]; echo [設定したいrootのパスワード])| passwd"
% java -jar acp_commander.jar -t [LinkStationのIPアドレス] -ip [LinkStationのIPアドレス] -pw [LinkStationのadminのパスワード] -c "sed -i 's/SUPPORT_SFTP=0/SUPPORT_SFTP=1/g' /etc/nas_feature"
% java -jar acp_commander.jar -t [LinkStationのIPアドレス] -ip [LinkStationのIPアドレス] -pw [LinkStationのadminのパスワード] -c "/etc/init.d/sshd.sh restart"

LinkStation LS420Dにs3cmdとawscliを入れてみた - Qiita

 2.Javaの導入

LinkStationはarmなので、ラズパイの記事を参考に調べたら普通にarm用があったのでインスコできました。

JDK 8 for ARM - Download

/usr/java/jdk1.8.0_51 あたりに展開するだけのお手軽さ。

.bash_profileとかにJAVA_HOMEを書いときます。後述するcron化する際には、sh自体に書いてきます。

JAVA_HOME=/usr/java/jdk1.8.0_51
export JAVA_HOME 

3.jets3tの導入

S3とシンクロするJetS3tがS3Syncより早いらしいという記事を見て、こちらを導入することにしました。ダウンロードして解凍するだけのお手軽パックです。

http://www.jets3t.org/

4.Google Cloud Consoleを有効に

JetSetをダウンロードしたら、GoogleCloudConsoleでスイッチを入れます。

ここがわかりやすかったです。一点違う点は、ストレージクラスを「Nearline」リージョンを「アジア」にしたことくらいでしょうか。

5.設定ファイルを編集

4.で「相互運用性」にチェックを入れるとアクセスキーと非公開キーが手に入るので、それをconfig/synchronize.propertiesの該当行をコメントアウトします。

http://www.jets3t.org/applications/synchronize.html

あとは、バックアップしたいフォルダに、.jets3t-ignoreファイルを設置し、中に

.*

とだけ書いておきました。(これでMacメタデータファイルがバックアップされなくなる)

6.実行!cron化

ここまでできたら試しに実行します。

[root@LS210DDFD jets3t-0.9.3]# bin/synchronize.sh --provider GS UP <バケット名>/home /mnt/disk1/バックアップしたいパス/Desktop

 --provider GSでGoogle Cloud Storageが選択されます。

うまくいったら、こいつをcronに登録し、synchronize.shの先頭にでもJAVA_HOMEを記載しておけば安心です。

 

たとえば、ソースコードはgitだからいいやとか、Donloadフォルダはいいやとか、.jets3t-ignoreファイルで細かく指定できるので、バックアップ時間とストレージ料金を節約できるので、うまく活用してみてくださいね

防水ビデオカメラ持っててよかった話

f:id:ku-suke:20150605202238j:plain

休み明けのタスクこなしつつ溜まった画像やムービーを取り込んでたんですが、子供いる人は、防水ビデオカメラ絶対持ってたほうがいいです。前にもいいましたが。

 

blog.ku-suke.jp

 

何かと最強なITSをフル活用し、夏休みを早めに取って水曜午後から土曜まで千葉県の夢の国にいたんですよ。なんとオフィシャルホテルのホテルオークラ東京ベイがITS補助で半額以下くらいで泊まれるので。しかも閑散期でスーペリアからデラックスにアップグレードしてくれた。

 

 

本題はそこではなくて、2日目のシーが、夕方くらいから雨だったのです。大体アトラクション回って子供も疲れてきたんで一旦外に出て安い飯をかきこんで、雨具を装備して船が出てくるアレを見に行ったわけです。

 

そこそこ降ってきた中、子供の思い出もある程度残してあげたいなーとか考えながら、カメラをメインからサブの防水の方に切り替えて、取りまくることが出来ました。

 

画質悪いし、照度合わせられずにブレまくるのですが、ある程度設定してやれば冒頭のように爆発するネズミさんくらい撮れました。

 

ゴンドラも貸し切りでした。おにーさん8人位でイタリア語で歌ってくれたり、雨が降りまくる中すんごく楽しい話をしてくれました。

f:id:ku-suke:20150607230132p:plain

こっちはさらにブレまくる(フラッシュすると露出計算ミスと相まって白飛びするので、ノーフラッシュで1秒程度のシャッタースピード)のですが、雨の中貸し切りのゴンドラ乗ったね―という思い出づくりに、スペック低くても防水デジカメが本当にオススメです。

 

自分の持ってるパナの旧Xactiの最後の機種はもはやプレミア価格となっているので、オススメできませんが、ズームはそこそこでも小さいのだとFinePixか、運動会とか湖のほとりからネズミさんの表情を撮影したい場合は40xズームついてるJVCのビデオカメラがいいのではないでしょうか。

 

繰り返しますが、画質とかどうでもいいから、思い出を残したいというパパママ向けには、ズーム>防水>光学式手ぶれ補正>USB充電の順でオススメします。

 

Finepix 

 JVC

 

0x20歳になりました。醤油を借りられる人になる

f:id:ku-suke:20150418005648p:plain

先週誕生日を迎え、16進数で桁がひとつ上がりました。今年の目標は、醤油を借りられる人になる。にしようと思います。(写真は息子氏と)

なにかというと、能動的に人にお願いごとが出来る人になるということです。

醤油というのはこちら

三井不動産がアンケート実施なのでその分は差し引くとして、注目すべきは「貸せる」がほぼ100%近いにも関わらず、「借りにいける」が2/3ほどしか居ないということです。

このへんに僕も含み日本人の文化があると思います。ようは、人に迷惑をかけてはいけないという教育、あるいは空気に浸かって生きてきたために、醤油を借りるという相手が迷惑するかもしれない行為にやっぱりちょっと躊躇してしまうのです。

 

更にこの点は、心理的に優位な立場に自分を置いていたいという願望に通じるものがあると思います。ネットで安全なところから「間違った人」を叩くのもそうだし、突然押しかけて醤油を受け渡す行為において、貸してあげる側は優位に立てるわけですから1本150円の醤油の3分の1としても、50円以上の価値はありそうです。

 

ですが、ここで問題なのは、自分の心理的優位性を崩したくないがために醤油を我慢してしまう人がいることです。自分もそのタイプなんです。醤油がなければ塩でもソースでもコンソメでもいいじゃない。わざわざ人様の家におしかけなくてもと。

自分を過度に守ってしまうわけです。だから仕事以外の雑談も未だに苦手です。相手をよく知るために聞き手に回りましょうというのがありますが、じゃあズケズケと相手のたとえば家族構成とか、土日何やってるのとか、どこ住んでるのとか、聞いてしまったら失礼なんじゃないか。と思ってしまうわけです。

失礼だと感じさせる=迷惑をかけるということに罪の意識があります。だから会話が続かないんです。だまっちゃって。

 

何の話かわかりませんが、おかげさまで仕事ほかもろもろ順調に回り出したので、調子のいい時に苦手克服にチャレンジするため、積極的に皆さんに小さな迷惑をかけれるよう?頑張ります。いままでは小さな迷惑を掛けたくないと思うあまり、連絡がなくなり疎遠になったり、抱え込んで炎上してから泣き入れたりしてたので。

というわけでいろいろおねがいしますね。ただその際礼儀がなってないなと思う場合は指摘していただければ幸いです。