ブログ

  • Android から Google Analytics をオプトアウトできる Sleipnir Mobile の拡張をリリースしました

    Android から Google Analytics をオプトアウトできる Sleipnir Mobile の拡張をリリースしました

    需要があるかないかはわからないですが、少なくともぼくにはあったのでリリース。

    Google Analytics アクセス解析を使っている場合、サイトチェックなど自分でアクセスした分まで解析される…ってのを防ぐことができるようになります(要 Sleipnir Mobile)。

    拡張を入れる説明や手順など。

     

    Sleipnir Mobile

    デスクトップのウェブブラウザとして一世を風靡したブラウザの Android 版です。

    気に入ってるのでぼくはメインで有料版を使っています。

    Sleipnir Mobile - ウェブブラウザ 

    制作: Fenrir Inc.
    価格: 無料
    平均評価: 4.1(合計 6,076 件)

    posted by: AndroidHTML v2.2

    Sleipnir Mobile Black Edition 

    制作: Fenrir Inc.
    価格: ¥600
    平均評価: 4.1(合計 547 件)

    posted by: AndroidHTML v2.2

     

    インストールして次へ。

     

    拡張機能をインストールする

    Sleipnir Mobile を起動して作業を進めていきます。

    スクリーンショットの説明通りにやれば拡張機能がインストールできます。

    インストールが終われば、あとはもう普通にブラウジングするだけ。

    Analytics に自分の閲覧は送信されません、素敵。

     

    ホホまとめ

    欲しいなーと思っていた拡張だったので、「ないなら作る」を実現する形になりました。

    Android 端末でのウェブサイトチェックにいいんじゃないでしょうか。

  • Frontback、ついに Android アプリがリリースされたんでさらっと使ってみたっっったよ!

    Frontback、ついに Android アプリがリリースされたんでさらっと使ってみたっっったよ!

    Frontback。

    スマートフォンの背面カメラと前面カメラを使って写真を撮り、1枚にまとめることによって新しいクリエイティブな作品が出来上がる、という素敵なアプリ。

    iPhone 用には昨年リリースされて大盛り上がりしていました。

    2014年4月11日、ようやく Android アプリがリリースされましたので是非、という紹介記事を。

     

    Frontback って何が楽しいの?

    むしろぼくが聞きたいぐらいの疑問ですね。

    わりと Twitter なんかに連携させるのがいいっぽいです。

    タグつきのツイートを眺めてみるといいでしょう。


     

    Frontback は Play Store から

    無料です。 試すだけ試してみたらいいんじゃないでしょうか。
    Frontback
    制作: Frontback
    価格: 無料
    平均評価: 5.0(合計 4 件)
    posted by: AndroidHTML v2.2
     

    Frontback、Android 版の使い方

    さらっと一通りの機能を使ってみました。  

    最初にアカウント登録→ログイン

    Google+ アカウントがあれば登録せずにサインインできます。 アカウントを新規作成してもいいでしょう。 [gallery type="rectangular" ids="1037,1038"] おすすめユーザーは華麗にスルー。  

    メイン画面や設定画面

    メイン画面にはストリームが流れる仕様。 画面に1枚どーんと出てくるんですね。 左上をタップすると設定へ。 Twitter や Facebook 連携、プロフィール設定などできます。 [gallery type="rectangular" ids="1039,1040,1041"]  

    Frontback Android、撮影してみる

    この記事を書きながらおもしろ写真を撮るのはちょっと無理だと判断したため、記事を書きながら初使用。 まずは背面カメラで1枚、その次に前面カメラで1枚。 すると投稿できるようになりました。やったね。 [gallery type="rectangular" ids="1042,1043"]  

    ホホまとめ

    一部の Android ユーザーには待望なのでは。 少しづつ使っていこうと思いました。

  • 『Facebook の誕生日おめでとうコメント、いらないんですけど』と相談を受けたので

    『Facebook の誕生日おめでとうコメント、いらないんですけど』と相談を受けたので

    Facebook という SNS があります。

    もっぱら己の充実ぶりをアピールする場(偏見)として使われてますね。

    先日タイトル通りの相談を受けたので、誕生日を公開しないように処置してあげました。

    やってあげると、「そんなことできたんですねー!!」と喜んでくれました。

    ついでにパソコンからの設定方法をメモ。

     

    なぜ誕生日おめでとうコメントがいらないか

    ぼくは元より生年月日を非公開にしています。

    相談者曰く、

    「仲良しならメールなり電話なり直接会ってなり、おめでとうって言ってくれる。むしろ、Facebook でおめでとうってコメントしてくれる人はだいたいそんなに仲良くない。しかも、コメント返すのが面倒だ。」

    という、概ね同意できる理由でした。

    参考までに一例の画像を。

    100件超のお誕生日コメント一例
    100件超のお誕生日コメント一例

    ※理由には個人差があります。

     

    パソコンから Facebook の誕生日を非公開にする手順

    パソコンのブラウザから Facebook にアクセスして次へ。

     

    1. 自分のプロフィールを編集

    左上の自分の名前下、”プロフィールを編集” をクリック。

    プロフィールを編集
    プロフィールを編集

     

    2. 誕生日の編集

    画面遷移の後、基本データの欄より誕生日を見つけ、マウスホバーすると “編集” と出てくるので編集をクリック。

    誕生日をマウスホバー → 編集
    誕生日をマウスホバー → 編集

     

    3. 誕生日の公開範囲を絞る

    編集 をクリックするとポップアップが開くので、南京錠アイコンをクリックして公開範囲を選択。

    公開範囲を自分のみにするといいよ。
    公開範囲を自分のみにするといいよ。

     

    4. 最後に変更を保存

    で、変更を保存すれば OK。

    変更を保存
    変更を保存

     

    簡単ですね。

     

    ホホまとめ

    そもそも誕生日を祝われることがそんなに好きではない&コメント返しが面倒だって人は少なからずいらっしゃるのでは。

    律儀にコメントを返すのも一興、公開しないようにするのも一興。

    SNS をどう使うかという知識を蓄えておいたら、ひょんなことで役に立った、という経験でした。

    ついでにあなたが Facebook ページにいいねしてくれるとぼくはうれしいです(。・ω・。)

     

  • アホすぎる WEB サービス、クリヌイターが公開されたですって!

    アホすぎる WEB サービス、クリヌイターが公開されたですって!

    先日、なぜかテストにちらっと関わっていた WEB サービスがリリースされましたので紹介してみます。

     

    クリヌイター

    名前からは想像もつかないそのサービス内容。

    Twitter の公式アカウントも開始され。

    https://twitter.com/cre_nui/status/449773102096871424

     

    クリヌイターでできること

    画像をアップロードすればオシャレな水玉模様に加工できる!

    という簡単なもの。

    水玉模様は割とぼく、好みです。

     

    使ってみたらわかるよ、たぶん

    クリヌイターサイトへのリンクをスクリーンショット付きで載せておきます。

    クリヌイター - オンライン水玉ジェネレーター
    クリヌイター – オンライン水玉ジェネレーター

     

    なんとスマートフォンにも対応しているという。

    水玉模様ファンには必携の WEB サービスですね!

  • WordPress 3.9 でキャプションとギャラリーが HTML5 に対応、テーマ作ってる人は要チェック。

    WordPress 3.9 でキャプションとギャラリーが HTML5 に対応、テーマ作ってる人は要チェック。

    そろそろ WordPress 3.9 が来そうですね!

    TinyMCE のメジャーバージョンが上がったり、その他細かく変わっている3.9、一応追えるだけ追ってます。

    今回は WordPress 3.9 から実装される、キャプションとギャラリーの HTML5 対応について。

     

    HTML5 対応とは

    WordPress 3.6 から追加されました HTML5 対応。

    3.6 から使えたのは、

    • コメントリスト
    • コメントフォーム
    • 検索フォーム

    の3つでした。

    3.9 からは新たにここへ、ギャラリーとキャプションが追加されるというわけです。

     

    キャプションの HTML5 対応での変化

    キャプション、HTML5 でない通常の出力コードは

    <div class="wp-caption" style="" id="attachment_xxx">
    	<img height="xxx" width="xxx" src="http://example.com/img.jpg" alt="xxx" title="xxx" class="wp-image-xxx">
    
    	<p class="wp-caption-text">
    		キャプションのテキスト
    	</p>
    </div>

    div で画像とキャプションのテキストを囲う出力です。

    HTML5 に対応させると、

    <figure class="wp-caption" style="" id="attachment_xxx">
    	<img height="xxx" width="xxx" src="http://example.com/img.jpg" alt="xxx" title="xxx" class="wp-image-xxx">
    
    	<figcaption class="wp-caption-text">
    		キャプションのテキスト
    	</figcaption>
    </figure>

    図表を示すタグである figure とその注釈を示す figcaption にそれぞれ置き換わり、正しい意味づけのマークアップへと変貌します。

     

    ギャラリーの HTML5 対応での変化

    ギャラリー、HTML5 でない通常の出力コードは

    <div class="gallery ..." id="gallery-x" ...>
    	<dl class="gallery-item">
    		<dt class="gallery-icon landscape">
    			<a href="http://example.com/img.jpg">
    				<img height="150" width="150" ... />
    			</a>
    		</dt>
    		<dd class="wp-caption-text gallery-caption">
    			キャプションのテキスト
    		</dd>
    	</dl>
    	<dl class="gallery-item">
    		…
    	</dl>
    	<br style="clear: both">
    </div>

    出力は dl、定義リストでマークアップされています。

    HTML5 に対応させると、

    <div class="gallery ..." id="gallery-x" ...>
    	<figure class="gallery-item">
    		<div class="gallery-icon landscape">
    			<a href="http://example.com/img.jpg">
    				<img height="150" width="150" ... />
    			</a>
    		</div>
    		<figcaption class="wp-caption-text gallery-caption">
    			キャプションのテキスト
    		</figcaption>
    	</figure>
    	<figure class="gallery-item">
    		…
    	</figure>
    	<br style="clear: both">
    </div>

    キャプションの対応と似た感じ、画像を figure で括り、キャプションは figcaption でキャプションを示すように。

    そして dt → div ですね。

    HTML5 マークアップによって意味づけがなされたことを見てとれます。

     

    キャプション・ギャラリーの HTML5適用方法

    コードは簡単、add_theme_support のにて記述。

    add_theme_support( 'html5', array( 'caption', 'gallery' ) );

    すでに記述がある場合は、配列に caption と gallery を足してやればいいです。

    適用できるもの全てを HTML5 にする場合はこう。

    // キャプション、コメントフォーム、検索フォーム、コメントリスト、ギャラリーを html5 マークアップにしてくれる
    add_theme_support( 'html5', array( 'caption', 'comment-list', 'comment-form', 'gallery', 'search-form' ) );

    WordPress 3.8以下で足しておいても問題は起きないし何も変わらないので、今のうちに書いておくといいかも。

     

    css の追加・変更が必要

    HTML5 対応に伴い、スタイル指定を少し変えてやる必要があります。

    Twenty Thirteen, Twenty Fourteen のギャラリー&キャプション HTML5 対応&修正コミットを参考にしてスタイル指定をちょっと変えてあげればいいです。

     

    ホホまとめ

    毎回のバージョンアップで機能が次々と追加されるので楽しいですね。

    次は増えた関数で使えそうなのをまとめようと思います。

    バージョンアップマニアとしてはしばらく愉快な日々が続きそう。

  • 構造化データマークアップ、ブログの記事ページで実際に使用中のまとめ【microdata】

    構造化データマークアップ、ブログの記事ページで実際に使用中のまとめ【microdata】

    ブログのテーマを作り直した際に、構造化データマークアップをかなり意識しました。

    テーマ反映から1ヶ月近く経って特に問題もなさそう。

    己の後学のために現状をまとめ。

     

    構造化データマークアップ(microdata)とは

    Google ウェブマスターツールのヘルプより引用

    HTML5 microdata(リンク先は英語)は、特定の種類の情報(レビュー、人物、イベントなど)を記述するコンテンツにラベル付けする方法の 1 つです。情報の種類によって、人物、イベント、レビューなど、記述する特定の種類のアイテムがあります。たとえばイベントには、会場、開始時間、名前、カテゴリなどのプロパティがあります。

    html だけでは定義できない様々な情報を、microdata という形式で記述することにより、検索エンジンなどのロボットへ正しくコンテンツを伝えられる、というもの。

    2011年時点で既に Google、MS、Yahoo!、構造化データマークアップの標準化で協力 とあるように各社力を入れているので、今後必須でしょう。

     

    構造化データのマークアップ方法

    ちょっと書き切れないので今後に回すとして。

    公式ドキュメントを参照ください。

     

    パンくずリスト

    パンくずリストは Google 検索でリッチスニペットが出るようになる、ってことでわりと有名ですかね。

    使っている人も多いだろうなので割愛。

    Google さんのリッチ スニペット – パンくずリストを見るといいかも。

     

    BlogPosting

    ブログ投稿用のスキーマ。

    Google の構造化データ マークアップ支援ツール、記事を選ぶと簡単にできはしますが、付けたい情報を支援してくれないので手動でマークアップ。

     

    使っている BlogPosting のプロパティ

    参考: Schema.org

    タイプ: http://schema.org/BlogPosting
    プロパティ 期待される型 説明
    articleSection テキスト 記事が属する1つ以上のカテゴリ
    author Person もしくは Organization コンテンツの著者情報
    dateModified 日付 記事を編集した日付
    datePublished 日付 記事を公開した日付
    discussionUrl URL コメントへのリンク
    headline テキスト 記事の見出し
    interactionCount テキスト 記事と相関する特定ユーザー数。いいね数やツイート数、コメント数など。
    UserInteraction のサブタイプであること。
    thumbnailUrl URL 記事のサムネイル(アイキャッチ)
    url URL 記事の URL
    wordCount 整数値 記事の文字数

     

    ImageObject

    画像ファイル。

     

    使っている ImageObject のプロパティ

    参考: Schema.org

    タイプ: http://schema.org/ImageObject
    プロパティ 期待される型 説明
    caption テキスト 画像のキャプション
    contentURL URL メディアオブジェクトの URL

     

    Person

    人物を表すやつ。

     

    使っている Person のプロパティ

    参考: Schema.org

    タイプ: http://schema.org/Person
    プロパティ 期待される型 説明
    name テキスト 記事が属する1つ以上のカテゴリ
    url URL 項目の URL

     

    UserComments

    項目上へのユーザーコメント。

     

    使っている UserComments のプロパティ

    参考: Schema.org

    タイプ: http://schema.org/UserComments
    プロパティ 期待される型 説明
    creator テキスト 記事が属する1つ以上のカテゴリ
    commentTime 日付 コメントされた時間
    commentText テキスト コメント本文
    replyToUrl URL コメントへの返信 URL

     

    なぜ構造化が必要なのか

    ここは難しいところ。

    デザインありきなのか、構造から考えて積み上げていくのか。

    全部できるのが一番いいですね。

    思うに、構造から考えることで見せたい・重要である情報を漏れなく人・機械へ一定の形を持って伝えることが可能になるんじゃないかな。

     

    ホホまとめ

    構造化データマークアップは Google の構造化データ テスト ツールで確認できます。

    この記事の場合ですと、こんな感じ

    もはや見過ごせないレベルで普及すると個人的には思ってるので、要チェック。

    今使ってる以上にまだまだ使える scheme があるため今後も精進しないといけないなぁと感じています。

  • 「この記事は~分で読めます」のコードがそもそも間違ってる説 & 導入している理由

    「この記事は~分で読めます」のコードがそもそも間違ってる説 & 導入している理由

    今村界では日本一有名だという今村だけがわかるブログさんの記事に完全に刺激を受けて書いています。

    是非・このブログの場合・そもそも論・ふわっとした感想で構成しました。

    巷に溢れる「~分で読めます」っていう WordPress 用のコードが間違ってるとぼくは思っていて。

    そもそも、前提条件である文字数がおかしいんじゃないのかな?

    是非から。

     

    「この記事は~分で読めます」を入れるかどうかの是非

    主観でいいんじゃないですか?

    入れたい人は入れればいい、入れたくない人は入れなくていい。

    自分のブログなんですから。

    誰にケチを付けられようと譲らない姿勢、嫌いじゃないです。

    ちなみにぼくは記事の日付と本文以外目に入らないタイプです。

     

    このブログの場合

    実はこっそり、「この記事はだいたい~分ぐらいで読めるよ」ってのを入れてます。

    文字数のところにさりげなく。

     

    なぜ入れるのか、その理由

    これに関しては webcre8 さんの記事、メタ情報としてって理由と似てます。

    読める時間は副次的な要素、むしろ、文字数を表記することが重要だと思っていて。

    なおかつ文字数をただのメタデータとしてではなく、構造化データマークアップに使えるというのが大きな理由。(※構造化データマークアップについては Google ウェブマスターのヘルプを参照されるといいかも

    ぼくの場合は microdata を使って記述。

    <article itemscope itemtype="http://schema.org/BlogPosting">
    	…
    	<meta itemprop="wordCount" content="xxxx" />
    	…
    	<span>x,xxx 文字</span>
    	…
    </article>

    ※デザインの都合上メタタグ

    構造化データマークアップをすることで、検索エンジンがサイトの情報を解釈しやすくなるんですねー。

    検索エンジンさんに記事の文字数をお知らせするついでに、ホバーアクションで読める時間を表示した、それが理由です。

     

    コードがそもそも間違ってる

    Google で “記事は~分で読めます” を検索して無作為にいくつか WordPress 用のコードが書いてあるのを見繕ってみました。

    だいたいにおいてこんな感じのコードでした。

    <?php
    /*
     * わかりやすいように処理をひとつずつ書いてます
     */
    
    global $post;
    // 投稿のコンテンツを取得
    $content = $post->post_content;
    // タグを除去
    $content = strip_tags( $content );
    // マルチバイトな文字列の長さを得る
    $content = mb_strlen( $content );
    // 600文字を1分で読める計算をする
    $read_count = round( $content / 600 ) + 1;
    ?>

     

    たとえば、キャプション付きの画像があるこんなページ。

    サンプル
    サンプル

    このキャプションだけのコンテンツを前述のコード途中、文字数を出力してみると、おや。

    91文字…
    91文字…

    なんと 91文字。

    これ、ぜったいウソですよね。

    ショートコードを省く処理が入ってないので、文字数が知らない間に水増しされるという…。

    ですから、「この記事は~分で読めます」を計算している文字数がそもそも違う。

    ギャラリーやプラグインのショートコードを使っている場合も上記に同じく。

    ちなみに執筆時点で、“分で読めます strip_shortcodes” の検索結果は皆無でした。

     

    おそらく、正しいコード

    ショートコードを省く処理を入れます。

    あと、空白も1文字としてカウントされるので、空白も消し去って文字数を取得してあげましょう。

    <?php
    global $post;
    // 投稿のコンテンツを取得
    $content = $post->post_content;
    // タグを除去
    $content = strip_tags( $content );
    // ショートコードを消し去る
    $content = strip_shortcodes( $content );
    // 空白文字列を消し去る
    $content = preg_replace( '/(\015\012)|(\015)|(\012)/', '', $content );
    // マルチバイトな文字列の長さを得る
    $word_count = mb_strlen( $content );
    // 600文字を1分で読める計算をする
    $read_count = round( $word_count / 600 ) + 1;
    ?>

    文字数がきちんとカウントされるはず。

     

    ホホまとめ

    ぼくが思う結論としましては、どんな情報であれ自分の中で精査・反芻できればベストだなーと。

    理由付け・考えるキッカケができるのでね。

    とはいえ、時間の制約・技術など限られたリソースをどこに割くかというのも悩みどころ。

    偉そうに書いてはいますが、自分への戒めが8割方であり。

    こうやって色々推敲するのは楽しいものですね。

    \この記事は2時間で書きました/

  • 久しぶりのブルースクリーンにより日頃のバックアップが重要だということを再確認

    久しぶりのブルースクリーンにより日頃のバックアップが重要だということを再確認

    1週間ぐらい前の話。

    頗る久々にパソコンがブルースクリーンに見舞われ、起動出来なくなり。

    毎日取っているバックアップからリカバリした際、不足の事態に常日頃から備えておくことの意味を思い知りました。

     

    事の顛末

    デスクトップ環境では主として Windows 7 x64 を使用。

    とあるソフトウェアをアンインストール後、再起動した際にそれは起こります。

     

    STOP:c000021a{Fatal system Error}

    Fatal system Error、致命的なシステムエラー。

    STOP c000021a {Fatal system Error}
    STOP:c000021a{Fatal system Error}

     

    トラブルには慣れっこなのですが今回ばかりは閉口。

    どうやら Windows が使うシステムファイルごと消し去ってしまった模様。

    再起動がループ。

    検索云々でどうにかなる性質ではなく、Windows 自体を欠損させてしまい。

     

    そんな時のためにバックアップしてあった

    OS X だと Time Machine という簡単なシステム丸ごとバックアップが標準搭載ですが、Windows には簡単なバックアップはシステムの復元ってのがある程度。

    丸ごとではないためシステムの復元を切ってまして。

    その代わり家庭用なら無料で使える EaseUS Todo Backup Free にて毎日定時バックアップをしていたのです。

     

    復元、そして復活へ

    詳細な手順は省きますが、システムごと復元。

    EaseUS Todo Backup 復元中
    EaseUS Todo Backup 復元中

     

    難を逃れることができました。

     

    ブルースクリーンの原因は人為的なミス

    常に動かしているものなので、何かしらの作業がいつ引き金になるとも限りません。

    そして、起動しなくなる原因は使用者の誤った操作に依ることがほとんど。

    ミスを無くすことが何より重要。

     

    備えあれば、何とやら

    憂いなし。

    ほんとに、憂うことは何一つなく、原因を特定した後すみやかにシステムをまるごと復元させました。

    元よりユーザーデータなどは別ドライブに退避しているので、最悪 OS の再インストールになったとしてもダメージはそもそもそんなにありません。

    いつ何が起きてもどうにかなるわー

    なんて気持ちを常に持っていられることで、不測の事態にも対処できるんだろうなと改めて感じた、そんな1日があったという話でした。