2015年12月を最終出勤とし、現在の会社を退職いたします。在職中はたくさんのご支援を頂きまして、誠にありがとうございました。
在職中は公私を通じてたくさんの才能と出会い、刺激的な４年間を過ごしました。人間としてどこか欠落していた自分も人間らしさを少し身につけられた気もします。終わってみると、とても寂しくて、感傷的になってまだ冷静に振り返ることができません。
（エントリタイトルをつけるときはがっつり振り返る気まんまんでした・・）
アプリエンジニアとして入社し、企画、ディレクションとサービス作りを一通りさせていただき、大阪拠点をたちあげて、小さな組織でしたがマネジメントも経験させていただきました。
後半は広告代理店部門に異動し、デジタルマーケティングの仕事に携わる中でやりがいと成果が両立し、この仕事ならおっさんでも若いもんに負けず頑張れるわ！と自分へのキャリアにとって自信を深めることができました。また何年後か、いつかはマーケの世界に戻ってきたいと思っています。
次はまた事業にチャレンジ*1すべく東京にゆきます。また練馬区に住みますです。
年齢が上がるということと、家族を持ち子を育てるということは、人生の掛け金が上がってきているなと感じます。そう簡単に飛び込めない度合いがあがってるなと。
今回の東京行きに関しても、住み慣れた土地や友人たちと離れることはとてもさみしいし、特に小学生の息子はせっかく出来た友達とお別れし寂しい思いをさせてしまいました。
支えてくれる家族のためにも、また、一緒にやってきた仲間に恥ずかしくない成果を挙げれるよう、2016年は「やるしかない」の精神で進んでいく所存です。
割と頻繁に心折れる可能性もあるので、みなさんぜひご飯に誘ってくださいｗ
で、誰？という暖かなブコメもお待ちしております。
*1:独立しないの？と今回も聞かれましたが、もう少しサラリーマンのメリットを享受したいと思います。次の会社も一定のルール内で副業できるので、講演や顧問などは引き続きお受けできます。
便利すぎてキャラ崩壊しましたこんばんわ。
みなさん、飲んでますか。幹事の皆さん、がんばってますか。あと今年も10営業日くらいしかないですよーーーー
金曜の飲み会のお店を決めるのをついつい放置してて、いやーそろそろ決めないと・・と思ってる時に、ペコッターが面白いみたいなので使ってみましょうよという流れになり代表して僕が使ってみました。
こんな感じで、最初のレスは2分後くらい、2件目も5分以内にレスが有りました。スペインバル、イタリアン×お野菜てきなところだったので、日本酒か焼酎にあうところも〜とこのUIに精一杯しゃべり方を合わせてコメントすると、追加で豆腐のお店もおススメいただきました。
ペコッターすごいね～この中でどれにする？ということで、最初にレコメンドされたスペインバル行こーぜとなりまして、予約を依頼しました。
結論からいうと、スペインバルは１２月の金曜夜ということで、満席でした。でもそこからのリカバリがすごかったｗ
すかさず他におすすめされた２件も電話してくれた。そして満席だったぺこり。でもそこからのリカバリがすごい！
すごい、お隣にあるとかなんなんだその情報ｗ
Androidアプリがないのが残念なぐらい12月の金曜日に最高のサービスでした。上司から「いい感じの店探しといて」と言われた皆さん、ペコッターにまるなげしましょう。投稿・質問はiOSアプリからのみっぽいです。
※なおステマではありません
最近ちらほら、Wordpressキツイよねという話がWeb屋さんの知り合いからよく耳にする機会があるように感じます。というか、僕自身コーポレートサイト製作の案件とか相談された時に、Wordpressはちょっとないなと思っちゃいます。（まぁ予算があったり規模がデカければ普通に商用CMS使いますが。）
そんななか滋賀の渚さんが虚構新聞のサイトとアプリをまるっとリニューアルして、すんごく薄いCMS？的なものを作られていたので影響されて考えをまとめてみました。
だいたい、昔の静的サイト制作のノリのままCMS化が進んでWordpress使いやすいよね～で流れてしまった挙句、バージョンアップや脆弱性対応でつらい目にあってWordpressやめたくなってるんだと思います。
そもそもの前提として
というかんじだと思うんですよ。
裏返すと、以下の様なCMSがあれば良いなーと個人的に思うわけです。
いかがでしょうか。PHP製の軽量CMSを幾つかあさってるのですが、まだこれといったものに出会えていません。SoyCMSとかbaserCMSもいいのですが、もっともっと薄いものを探しています。
例）Monstra
例）kirby
ほかにもPico,getSimpleなどあるのですが、これらは結構似通っていて、Markdownベースだったりします。クライアントにMarkdown書いてっていうのもなぁ（Aceエディタとかあるけども）と思って、あまり深入りしていません。これくらいのシンプルな薄いCMSで、gitとmarkdownがなくても使えるものがあったらぜひ教えて下さい。
鈴木さんの記事を読みましてAMPの仕組みについて読んでみました。以下抜粋して日本語メモを。
モバイルウェブが爆速に！ GoogleがAMP (Accelerated Mobile Pages) を立ち上げ | 海外SEO情報ブログ
追記：ざっくり言うと、主にニュースとか静的コンテンツを想定し、HTML+CSSでJSは原則禁止、広告とかで使いたい場合iframeを用意するのでその中だけ。iframeや画像は事前にサイズを固定し変更不可にすることでlazyloadしてもレンダリング時にガタガタしないよね。というAMP HTMLフレームワークを策定したお話です。
原文：https://www.ampproject.org/how-it-works/
（※見出しは筆者による）
Web performance is not unexplored territory for the tech community: books have been written about it, many talks have been given – there is even an entire conference series dedicated to the topic. However, users still frequently see poor web performance in the wild, particularly on mobile devices.
Consumption of news articles, and similar relatively static content, is often painfully slow, with pages taking a long time to load. Even after text becomes visible, pages continue to build up over many seconds, as ads and images come into display. The result is an often jarring experience of janky scrolling and users needlessly losing their reading position.
中略
To make the web fast at scale, we want to make it easier to create documents that are fast-by-default.
ウェブパフォーマンスは、技術コミュニティにとって未知の領域ではなくなったものの、ことモバイルウェブにおいてはまだまだ荒削りの状態です。ニュース記事を読むにしても、テキストが表示されてなお画像や広告を読み込むためにページの構築は何秒間も続きます。その結果ユーザは読むために不毛なスクロールと耳障りな経験をします。
そこで我々はWebを高速にスケールさせるために、デフォルトで高速なドキュメントを作りやすくしたいと考えました。
The web today is many things: an application platform, an e-commerce platform, a content platform, a gaming platform, and so much more. We decided to focus entirely on static content
いまウェブはEC、プラットフォーム、ゲームなど様々なものでできているので、その中で容易に適用できる静的コンテンツに集中することに決めました。
We began to experiment with an idea: could we develop a restricted subset of the things we’d use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance? That experiment has culminated in a promising proof of concept we call Accelerated Mobile Pages (AMP). AMP HTML is built on existing web technologies, and the documents written in it render in all modern web browsers and web views.
我々はHTMLのサブセットを開発し高速で表現力豊かな、そして信頼できるパフォーマンスを実現できるか検証し、AMPと呼ばれるコンセプトを実証しました。
AMP HTMLは既存のWeb技術で作られているため、すべてのモダンブラウザやWebViewで適切にレンダリングされます。（※翻訳元のページ自体がAMP HTMLで記述されています）
We think AMP HTML is promising, but we know it's not complete. We are sharing our proof-of-concept on GitHub to start a conversation about how to make static content on the web fast.
AMP HTMLは有望だと思いますが完全ではありません。ぜひgithubページをみて静的コンテンツを（モバイル）ウェブ上で高速にする方法について議論しましょう。
One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.
私達が早くから認識していたパフォーマンス問題の一つに、ページ内に埋め込まれる多数のJavaScript（ライブラリやツール等）があります。
JavaScript＝パフォーマンス低下というわけではありません。しかし任意のJavascriptを実行させるとパフォーマンスの保証を行うことが非常に難しいため、難しい決断でしたがAMP HTMLは一切のJavaScript（自信が書いたものもサードパーティ製のものも）を含めないことにしました。
JavaScript is the core building block for advanced web apps, but for static content it may not always be required
中略
But the web platform has a great solution: custom elements and web components. AMP components may have JavaScript under the hood, but it is coordinated with other AMP components, so its composition into the page doesn’t cause performance degradation.
JavaScriptは先進的なWebアプリにとって中心をなすものですが、必ずしも静的コンテンツに必要ではありません。（投票などの機能を用いている記事はあるものの）ウェブプラットフォームにはカスタム要素とweb componentがあります。AMPコンポーネントの中にJavaScriptを用意しています、他のAMPコンポーネントと協調して動作するためパフォーマンスの低下を引き起こしません。
So, AMP HTML comes with strong limitations on JS. What about CSS? AMP HTML loves CSS! We do add some best practice enforcement, but we do want AMP HTML documents to look like their authors intended them to, and so allowing extensive styling is core to the platform.
AMP HTMLがJSに強い制限を加える一方、CSSはどうでしょうか。AMP HTMLはCSSが大好きです！いくつかのベストプラクティスを用意しましたが、AMPページで制作者の表現をぜひして欲しいので、スタイルの許可をプラットフォームのコアとして据えています。
Ads and analytics – while critical for publishers – are a big part of the performance problem and so they must be a big part of the solution.
中略
AMP HTML does not allow this. We realize that both ads and analytics are an important element of monetization on the web, and so we need to support them: our goal is to realign monetization with great user experience.
パブリッシャーにとって、広告と解析がとても重要であることは理解しています。（広告や解析は様々なタイミングでJSを実行しますが）AMP HTMLではそれらを許可しません。解析や広告がウェブでの重要なマネタイズ手段だと認識しているので、我々はそれをサポートする必要があります。私達のゴールは素晴らしいユーザ体験とともにマネタイズを再編成することです。
AMP HTML is taking the following approach to analytics: so-called “tracking pixels” can be embedded into AMP documents as long as they don’t use JavaScript. They typically come with a
noscriptversion that makes this easy. More advanced analytics are currently not supported. Our vision is to deploy a single, unified, auditable, high performance, open source analytics library with AMP HTML that can report to various existing analytics provider backends, so it is possible to use the existing ecosystem without overloading a page with analytics software.
AMP HTMLでは、従来noscriptタグとともに用いられていたような解析ピクセルを使用して下さい。それ以上の高度な解析は現在サポートしていませんが、AMP HTMLが従来と同様の解析を出来るようなオープンソースライブラリを提供したいと構想しています。
instead they live in sandboxed iframes with no access to the primary document. 中略
We also prioritize ads lower during loading than other content and optimize load timing to avoid jank. Ads in AMP files can still be heavyweight, so there is still a lot of work to do for us.
（AMP HTMLはJSが利用できませんが）代わりにサンドボックスiframeに広告を表示できます。iframeは優先度低くロードされることでページロードを阻害しません。iframe内の広告自体に関しては、まだまだ高速ではないため私たちは多くのことをする必要があります。
So, how fast is AMP HTML? Pretty fast. In a sample of pages our early partners created we are seeing performance improvements measured through Speed Index between 15% and 85%. This was measured with a simulated 3G connection and a simulated Nexus 5 device.
それで、どれくらい速いのでしょう？めっちゃ速いで。SpeedIndexを使用してNexus 5の３G回線で計測したら、15%～85%位早くなりました。
But how do we get from good to, let’s say, instant? We’ll cheat :) AMP documents are from the ground up designed to be efficiently pre-renderable. Browsers have long supported pre-rendering through the
<link rel=prerender>tag, but they need to be conservative about this mechanism because prerendering can be expensive. With AMP HTML we added the ability to tell a document: render yourself, but only as far as what is visible above the fold and only elements which are not CPU intensive to minimize the cost of pre-rendering. With this mechanism in place, referrers of AMP document can initiate rendering of docs before the user acts much more aggressively, so that in many cases the document will be done rendering by the time the user clicks.
でも、どのように実現しているのでしょうか。私たちはズルをしました。AMPは事前にレンダリングしやすいようにデザインされています。各ブラウザは<link rel=prerender>タグを実装していましたが、処理が重くあまり利用されてきませんでした。AMP HTMLは、ブラウザ自身がレンダリングするもののファーストビューができるだけ早く、かつCPU負荷の高くないものという条件でプレレンダリングするようブラウザに伝えます。このため、多くの場合でユーザがクリックする前にドキュメントのレンダリングが完了しているのです。
With all of these techniques in place, AMP HTML documents can be loaded with a small set of HTTP requests: the document itself, custom fonts (if used) and what we call the AMP JavaScript library that implements the AMP custom elements and resource loading.
これらのテクニックを適切にするため、AMP HTMLは少数のHTTPリクエストでロードできます。ドキュメント自体、カスタムフォント（使う場合）そしてカスタム要素やリソースをロードするためのAMPライブラリと呼んでいるものです。
Our goal with AMP HTML is reliable performance, so we designed it to be easily cacheable by content delivery networks (CDNs). Google is offering a service that delivers AMP HTML documents given their URL through its CDN. Others can use this service or make their own or serve AMP HTML pages from a plain-old-web-server.
信頼できるパフォーマンスを達成するため、CDN経由でキャッシュ可能な配信できるようにしました。AMP HTMLはGoogleが提供するCDN経由で配信することができます。もちろん自身のサーバからでも、普通の古いサーバからでも配信することが可能です。
This brings us to the final topic that makes AMP HTML unique: all resource loading is controlled by the AMP library and, more importantly, resources must declare their sizing up-front.
This doesn’t mean that resources can’t be responsive – they can be, but their aspect ratio or dimensions needs to be inferable from the HTML alone. This means that after initial layout, an AMP document does not change until user action.
中略
This gets us lazy loading with zero visual jank.
最後に、AMP HTMLを特徴づけている点について。すべてのリソースは、事前に自分のサイズを定義しておかなければなりません。
これは、レスポンシブデザインに対応していないという意味ではありませんが、縦横比やサイズを初期ロードのタイミングでHTMLから読み取れるようにしておく必要があります。AMPページは初期レイアウトされてから、ユーザがアクションするまでレイアウトが変化しません。（広告であっても固定の枠からサイズ変更を許可しないので）非同期でリソースを読み込んでもページがガタガタとレンダリングされることがありません。
To summarize: AMP HTML is a specialized subset of HTML with custom elements that provides reliable performance and instant loading of static content. Nothing about the project is set in stone.
中略
まとめ：AMP HTMLはHTMLのサブセットとカスタム要素で出来ていますが、まだなにも確定はしていません。See you over on GitHub!
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
ということで、HTML+CSSでシンプルなページを用意し、JSを禁止し、画像や広告の表示サイズを事前に固定することで、高速ロード、高速レンダリングかつ読みやすくなるよね！ということのようでした。Googleが参加するということでWeb界隈の人は抑えておいたほうが良いと思います。
先のエントリで、検出テストをやってみたのですが、だいたい仕組みとかがわかってきたのでfuckadblockに頼らないお手軽対策をやってみたいと思います。
一応傾向値だけは知っときたいなと思って、設定してみました。これでほぼGAのブロック率は計測できるんじゃないかなと思います。
<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.ga.loaded == "undefined"){$("#header").append("<img src='http://example.com/analytics.php' />");}
}
);</script>
本来windowのロードが完了した時点では、gaのロードが概ね終わってるはずなので、そのタイミングに引っ掛けてwindow.ga.loadedプロパティの有無を調べるという方法です。
これで検出できた場合に、自分のドメインに設置したGAにサーバサイドでページビューを送信するスクリプトを読ませるようにします。Universal Analyticsをガラケーサイトに対応させるためのスクリプトみたいな感じです。
いちおうCookieでユニークユーザを計測できるようにしつつ、IPとUserAgentだけ送信しておきます（仕組み上GhosteryみたいなPC用のブロッカーも反応するので。）
ちゃんとやる場合はページパスも渡すようにしてもいいのですが、今回は傾向値を掴みたいだけなので固定パスでpageviewを送ります。ここは好みに合わせて、埋め込み元からパスやタイトル情報を渡したり、eventで送信してもいいですね。詳しくはMeasurement Protocolを読みましょう。
この方法で、GAのBlock率を計測することができます。なお、24時間での実験結果ではこんだけBlockerの記事書いててもGAブロック率7%程度でした。
広告屋さん向けに書いておくと、GTM/YTMなどのブロック率検知も同様に行えます。
GTMなら、window.google_tag_managerとか、YTMはちょっとわかりやすいパラメータが見当たらなかったのですが、window.BrightTag.V2_RESPONSEとかですかね。
PCでテストする場合は、Ghosteryの拡張でオン・オフしながらChromeのコンソールでconsole.dir(window)として、ブロック時と非ブロック時で違いが検出できそうかつwindow.loadイベントのタイミングで拾えそうなものを選びます。
ちなみに、解析用スクリプトはadとかanalyticsっていう単語を入れると引っかかる可能性があるので、自ドメインで無関係そうなファイル名にするのが無難だと思います。
もともとPCの世界にはAdBlockというのがあって、僕も愛用しているのですが、それを良しとしないサイト運営者向けに、FxckAdBlockというJSがgithubで公開されています。
動作原理としては、存在するはずの広告枠のCSSをチェックし、隠されたりそもそも存在しているかどうかを調べ、NGなら警告を出すというものです。
--ここから--
動作原理としては、特定の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を導入してみました。（今はもう外しています。）
みなさんの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>
