• FVM大賞2015 優秀賞 受賞
  • 平成26年度福岡市トライアル発注認定事業者
  • 平成25年度福岡市ステップアップ最優秀賞 受賞
  • 平成25年度九州ニュービジネス優秀賞 受賞
  • 福岡県情報セキュリティ連絡協議会加盟企業
  • 福岡ベンチャーマーケットプレゼン企業
  • 福岡大学共同開発企業
  • 経営革新計画 第1936承認企業
  • 平成23年度九州地域中小企業事業家支援
    お助け隊事業アドバイザー企業
  • 平成23年度福岡市競争入札参加有資格企業

雲の足跡

WEBを張り巡らせるクモであったり
空をただようくもであったりしたい
WEBエンジニアの日々の足跡
雲の足跡

2018年3月16日(金曜日)  (柿添 貴士)

FirefoxQuantumのおすすめアドオン

Quantumでは一部アドオンは利用不可に
FirefoxがQuantumになり、アドオンを追加変更したり削ったりという作業を行いました。
古いバージョンでしか動かないアドオンは削り、最新のバージョンで動くアドオンで必要なモノだけ残しましたので紹介します。

Awesome Timestamp
現在時刻のタイムスタンプ確認ができます。
current timestamp が一秒ごとに増加、microsecondsにも対応。
また日付指定でタイムスタンプの出力、タイムスタンプ入力で日付の出力も可能。
とても便利です、入れましょう。

ColorZilla
カラーピッカーの表示・webページのカラー取得・全カラー取得などが一瞬で使えます。
非常に便利です、入れましょう。

Foxy Gestures
以前利用していたジェスチャーが利用不可となったため、Foxy Gesturesに乗り換えました。
User Scriptの追加も可能です、Googleで検索・上位階層へ移動等もUserScript登録で実現可能。

ただただブラウジングしてるのはタイムロスが結構あります、
どのブラウザにも言えることですがジェスチャーは必ず入れましょう。


Xmarks Bookmark Sync
ブラウザをバラバラに利用するシーンが多いですFF・FFdev・Chrome・Safari・Edgeなどなど、、、
ブックマークの同期がブラウザ間を跨いで統一できるのはとても便利です。
更新が進み正常に動作するようになりましたので継続してXmarksSyncを使うことにしました。
便利です、入れましょう。

大事なのは速度と効率化

アドオンは入れすぎも速度的な面で問題が発生しますが、
有用で使用頻度の高いもの、タイムロスが減らせるもの、
などは入れておくとよいと思います。

上記4アドオンは現行最新バージョンで動作しており、
個人的に利用頻度の高いものです。

効率化の一環として導入してみてはいかがでしょうか。

2018年1月19日(金曜日)  (柿添 貴士)

ビジネスにおける電話とメール

私は基本的に相手の時間を奪いたくないのでメール派でしたが、
電話派の考えもインプットしようと思い、まとめようと思います。

それぞれのメリット、デメリット

電話のメリット
・とにかく早いレスポンスが高速
・話題を瞬時に変えられる
・やりとりを瞬時に往復できる
・意図をすぐに確かめられる
・ニュアンスのずれが生じにくい
・親しみを持ってもらいやすい
・謝罪などの場合誠意が伝わる

電話のデメリット
・相手を電話口に立たせるため、時間を奪う
・多くの場合は記録に残らない

メールのメリット
・相手の時間を奪わない
・テンプレートを使える
・記録に残る
・やり取りのすれ違い(言った言わない問題)が起こらない
・多くの人に情報を伝えられる
・データを送ることができる

メールのデメリット
・レスポンスが早くない
・読んだかどうかわからない
・伝え方が悪い場合ニュアンスのずれが生じる
・相手方のメール整理ができていないと埋もれる

確かに電話の良さもたくさんありました、反省します。
レスポンスの速さもニュアンスのずれが生じにくいのも評価すべき点であると思います。

しかし、"電話を多用し常にレスポンスの速さを求めている方"は、
以下の様な方ではないでしょうか。

・スケジューリングができていない
・タスクが山積しており高速で潰していかないといけない
・突発的な緊急対応に迫られている

私は常日頃から、スケジュール・タスク管理をしつつ
緊急タスクへとならないための"備え"を怠らないようにしたいと思います。

ただ、結局一番大切なことは、
"相手がどちらを求めているか"だと思いますので、
その点はしっかり頭に入れておきたいです。

電話での連絡を求められている方には電話を。
メールでの連絡を求められている方にはメールを。

今後も気を付けていきます。

2017年11月17日(金曜日)  (柿添 貴士)

SEOに関する構造化データ3(JSON-LD)

SEOに関する構造化データ3(JSON-LD)

リッチスニペットについて

前々回の記事にも書きました通り、JSON-LD構造化データを利用することで
立地スニペットを検索結果に表示させることもできます

※補足 リッチスニペットとは、通常テキストのみであるスニペットを発展させたもの。
※補足 画像、レビュー評価、パンくず、などのテキスト以外の情報も表示される。


Googleがサポートしているもの

レビュー
人物
商品
会社と組織
レシピ
イベント
音楽

https://developers.google.com/search/docs/guides/intro-structured-data?visit_id=0-636467374533057637-1478415976&hl=ja/&rd=1


実際に使ってみる場合:パンくず

以前はshema.orgでは利用できなかったと記憶していますが、
現在は利用可能なようです。

{
"@context": "http://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"item": {
"@id": "https://www.alivecast.co.jp/",
"name": "TOP"
}
}, {
"@type": "ListItem",
"position": 2,
"item": {
"@id": "https://www.alivecast.co.jp/blog/",
"name": "ブログリスト"
}
}, {
"@type": "ListItem",
"position": 3,
"item": {
"@id": "https://www.alivecast.co.jp/blog/233",
"name": "ブログ詳細"
}
}
]
}

実際に使ってみる場合:評価や価格

ratingValue や ratingCount を偽ってマークアップすると、
検索エンジン側から大きなペナルティをもらうことになりますので、
気をつけましょう。

{
"@context": "http://schema.org/",
"@type": "Restaurant",
"name": "ディナーセット",
"description": "記念日にぴったりのディナーです",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "3.6",
"bestRating": "5",
"ratingCount": "153"
}
}

リッチスニペット導入SEO
現段階ではSEOへ直接的に大きく影響はないと言われています
しかし、ユーザーのクリック率には大きく影響がありますので
正しい情報をより多く検索エンジンに伝えていけたらと思います

2017年10月05日(木曜日)  (柿添 貴士)

SEOに関する構造化データ2(JSON-LD)

実際に構造化データを使う上でJSON-LDを用いましょう。


JSON-LDの基本記述

基本の形
[script]
{
 "@context": "http://schema.org/",
 "@type": "####"
}
[/script]

-* scriptタグの中にまとめて書く
-* HTML内どこに置いてもOK


サイト名

実際にサイト名であれば以下のようになります
{
 "@context": "http://schema.org",
 "@type": "WebSite",
 "name": "AliveCast",
 "url": "https://www.alivecast.co.jp/"
}


よくわからない人向け

エンプティヘッド状態でも容易に使えます。
むしろ専門的な知識がなくても使えます。
面倒臭がりな人は情報を入れてどのような構造化データになるか、
試しにやってみましょう。
https://www.jamesdflynn.com/json-ld-schema-generator/


ガイドライン

2017年9月に構造化データを設定する際に従うべきガイドラインをGoogleが公開しています。
https://developers.google.com/search/docs/guides/sd-policies

簡単に書くと

・構造化データで様々な表示をさせることができるが、表示が記述通りされるとは限らない
・ユーザーにとって最適な検索結果を表示できるようGoogle側で調整する
・検索結果には検索履歴や場所、デバイスの種類を含むさまざまな多くの要素が影響する
・構造化データに書いたものより別の機能ものが適切だと判断することもある
・シンプルな青のタイトルリンクのみが最適だと判断することもある
・ページ情報が、それぞれのガイドラインやに従っていない場合は、構造化データは利用されない
・構造化データテストツールが認識できなかったエラーがある場合は、構造化データは利用されない
・構造化データで指定しているコンテンツがユーザーに見えない場合は、構造化データは利用されない
・構造化データが、ページ情報と関係なかったり誤解を招くようであれば、構造化データは利用されない

エンドユーザーさんのために、
正しく確かな情報をマークアップしていきましょう。

リッチスニペットにダイレクトに触れるJSON-LDの記述はまたの機会に触れたいと思います。

2017年9月25日(月曜日)  (柿添 貴士)

SEOに関する構造化データ1

SEOに間接的に関係しているであろう、
検索エンジンクローラーとの対話に必要な、
構造化データについてです。

構造化データとは

ホームページ上の記事・ページ内の文章や単語に対して、
情報や意味をメタデータとして持たせます。

それにより検索ロボット・クローラーの内容解釈を容易にし、
ユーザーにとってより有用な検索結果を、
検索エンジンは提供できるようになります。


クローラーの内容解釈

TakashiKakizoe(Engineer)

私たちヒトがこの文字列を見た際に解釈できるものとして、
アルファベット、TakashiKakizoeという人名?、肩書きはEngineer?
といったことが挙げられます。

Googleをはじめとする検索エンジンのクローラーも、
優秀なAI(人工知能)を裏で動かしていますので、
上記のようなヒト同等の解釈はできます。

しかし、実際に人名であるか肩書きであるか、
これらは確かなものではありません。

そこで、これらの情報・意味を
クローラーに伝える手段の一方法として、
構造化データが挙げ・られます。


構造化データを使うことのメリット

1.意味をクローラーに伝えられる

上述の通り文字列や画像がどのような意味を持っているのかを伝えることで、
そのページには実際にどのようなデータがあるのか、
ユーザーにとってどんな有益な情報があるのか、
これらを容易に把握することが可能となります。

ブログ記事であれば、
誰が書いたか、どのような人物なのか、
どのような事柄について書いてあるのか、

製品であればどのような製品か、
地域であればどのような地域か、

といった情報も書くことができます。

2.リッチスニペット検索結果に表示される

普段のGoogle検索などで目にする検索結果は、
・青文字のページ名とリンク
・サイト内容の短い文字列
等が表示されるかと思います。

しかし、これらだけではなく、
パンくずや画像といったデータが
表示されていることもあります。

これらの付加情報はリッチスニペットと呼ばれ、
その中でもパンくずを簡単に表示してくれることでも、
構造化データの存在は知られています。

これらもページ構造を示した構造化データにより
クローラーに伝えることが・できます。


実際に構造化データを使う

実際にこれらの構造化データを使うためには、
ページのマークアップを行う必要があります。

また、意味を紐づけるためのボキャブラリーについても
知っておく必要があります。

■ボキャブラリー
Google、Microsoft、Yahoo! などが
仕様策定に取り組むschema.orgというものがあります。

ここでの定義をもとにマークアップする方法が一般的です。
http://schema.org

■シンタックス
マークアップを行う際にシンタックスを選択できます。

・Microdata
・RDFa
・RFDa Lite
・JSON-LD

GoogleはJSON-LD形式を推奨していますので、
実際にはJSON-LDでのマークアップを行いましょう。

次回はJSON-LDでのマークアップについて触れたいと思います。

2017年8月04日(金曜日)  (柿添 貴士)

表示優先順位を決めるアルゴリズム

Google検索でいえばどのようなサイトが優先的に表示させるか
Facebookで言えばどのような広告や投稿を優先的に表示させるか

このような優先度を決めるアルゴリズムは日々変化していっています

Facebookは8月2日にニュースフィードの優先度決定アルゴリズムの変更を発表しています

投稿に付随するリンクから飛ぶページの表示が遅い場合、
投稿のランクを下げていくとのことです。
そしてこの変更を数か月かけて適用させていくとのこと。

ユーザーが実際にページリンクをクリックした場合に表示が遅くイライラするとの意見から
この対応に踏み切ったとのことです。

Googleの検索も同様にユーザーがどのような価値を感じるか、
思うか、体験するかが非常に大切になってきます。

ユーザーに価値のないページは表示ランクを落とされてしまうのが実情です。

ユーザーが望んでいるものは何か?
わかりやすく情報を提供できているか?
読み込みスピードは遅くないか?

あげるとキリがないですが、
常にエンドユーザーの目線が大切ですね。

2017年5月29日(月曜日)  (柿添 貴士)

phpmdを使ってみる



 
 
phpmdとは
phpmdはPHP Mess Ditector、コードでバグを生みそうな箇所、設計、実装上の問題をルールに従って検出してくれるツールです
http://phpmd.org/about.html

早速インストール
pearコマンドを使います、&yum
# yum install php-pear
# pear channel-discover pear.pdepend.org
# pear install pdepend/PHP_Depend
# pear channel-discover pear.phpmd.org
# pear install --alldeps phpmd/PHP_PMD
# pear install PHP_CodeSniffer

composer利用
URL:(https://getcomposer.org)

JSON_FILE:composer.json
{
"require-dev": {
"phpmd/phpmd" : "*"
}
}
# php composer.phar install
# sudo ln -s /vagrant/vendor/phpmd/phpmd/src/bin/phpmd /usr/bin/phpmd
# sudo chmod ugo+x /usr/bin/phpmd

実際に使ってみる
phpmd hoge.class.php text cleancode,codesize,controversial,design,naming,unusedcode

cleancode:コードが綺麗であるかどうか
codesize:コードの複雑さを検出
controversial:命名規則、キャメルケースなどを検出
design:設計上の問題を検出
naming:メソッド名、プロパティ名の名称をチェックする
unusedcode:使われていないプロパティや変数などの検出

コードのxx行目が複雑すぎるぞ
コードのyy行目の命名規則がおかしいぞ
コードのzz行目のプロパティはどこでも使われてないぞ
であったり、メソッド多すぎるぞ、行数長すぎだぞ

などなど実装上の問題をゴロゴロとリストアップしてくれます
テストのサーバや自身のプライベートサーバ上に載せて見てたりします
classが大規模になってメンテナンス性が落ちてるんじゃないかとか
設計上これで大丈夫か、簡単に見てみたいなって時には使えるんじゃないかと思います

2017年4月07日(金曜日)  (柿添 貴士)

terminalでよく使うコマンドと由来

黒い画面に緑の文字
macで頻繁にお世話になるterminalですが
画面が画面だけに抵抗感があるかもしれません
便利です使いましょう
コマンドは使っていれば覚えられますが由来がわかれば
由来がトリガーとなって頭から抜けた時も簡単に思い出すでしょう
コマンドが覚えられないから使わないなんてもったいないですよ



cd 指定先のディレクトリに移動
"Change Directory"から来ているのだそうだ

cd / でルートへ
cd ~/
cd /var/www/html/

なんかもよく使うはずです ねっ

find ファイルを探してくれる
"Find" そのままなので忘れようがない・・・!
find パス -name "ファイル名"
find . -name "*.html" | xargs grep "文字列"
で文字列が含むファイルを返します
引数 -lもつけちゃっても良いです

pwd 現在のパスを表示してくれる
"Print Working Directory"から来ているそうだ
今いるディレクトリを出力しろ!とのこと

ls 現在パスでファイルやディレクトリの表示
"List" からとのこと
ls -la なんかで見やすくなりますね

cat ファイルをターミナル上に表示
ファイルをターミナル上に表示する時にだいたい使いますが
複数のファイルを連結して出力したりする時にも使います
"Catenate Concatenate" からとのこと

mkdir ディレクトリを作る
"Make Directory"から

clear ターミナルで出力を綺麗に吹き飛ばす
"Clear"から
cd ls -la clear cd ls -la と連続で・・・

rm 削除する
"Remove" から来てます
rm -rf ./* なんかで
常日頃から吹き飛ばしていると大事なところで消しとばします
くれぐれも注意してください

cp コピーする
"Copy" から来てます そりゃそうだ
cp -r コピーするファイル名 新しいファイル名でコピーできます

mv ファイルを移動する
"Move" から来てます
mv 移動したいファイル名 移動後のディレクトリ で移動させましょう

システムいじってる人間は常日頃から触っているので抵抗感はないとは思いますが
sassやgitなどでデザイナーさんが触る機会が来た時コマンドを忘れないようここに残しときます

vim chmod chown ssh などはまたの機会にしましょう

2017年2月15日(水曜日)  (柿添 貴士)

PHP DB周りが遅いとき

DBサーバを増強、チューニングする前に、
PHP側・クエリなどを見直すと速度改善が可能かもしれません。
チューニング以外で軽く思いつくものを書いてみたいと思います。

・INDEXを貼るカラムは適切かどうか
そもそもの問題になってきますが、
検索に頻繁に利用するカラムについてはインデックスを適切に張る必要があります。
間違ってもすべてのカラムに張るなんてことはやめておきましょう、激重になります。

・SQL検索条件にインデックスを使用しているか
検索条件にインデックスを利用せずTABLE全件検索を行っていませんか。
速度改善のために適切なインデックスを張ったカラムを利用しましょう。

・無駄なカラムの読み込みを行っていないか
SELECT * として、カラムの内容を全て読み込んでいないか。
SELECT `XX1`,`XX2`,`XX3`と、指定してあげた方がもちろん速いです。
不必要なカラムは余計な処理を招くだけですので、必要なものだけ呼んできましょう。

・SQL文にクォートをつけ忘れていないか
クォートをつけずとも利用は可能ですが、しっかりつけましょう。
面倒だとは思いますが、パフォーマンスに多大な影響を与えます。
SQL文のフィールド名、検索語など解釈に時間がかかるため、
クォートにより判定のスピードをあげましょう。
数十万件のデータ読み出しで5000倍ほどの開きも出てきます。

・必要な行数のみフェッチしているか
HTML上で利用するデータのリストなどはLIMITをかけて件数制限をしましょう。
LIMITをかけずに数十万件のデータを読み込むのは非常に効率が悪いです。
使うものだけ呼んでくるのがスマートです。

・DBアクセス回数を最小にしているか
何度も、何度も同じテーブルにアクセスして違うデータを取ってくるのは非効率的です。
1回で複数の値を取る方法がある場合はそちらを選択しましょう。

・WHERE句 条件判定を極力少なくしているか
設計の問題もありますが、同じ条件で分岐する場合は複数書く必要もありません、
必要なものだけ書き、判定を極力少なくしましょう。

・WHERE句 で指定するカラムは行数が少ない方から指定しているか
WHERE句 判定の順にも気をつけましょう、先判定で行数が少ない方を優先で書きましょう。

・できる限りSQL側で処理を行っているか
PHP側のロジックでSQLができることをでカバーすると、ほぼ遅くなります。
設計にもよりますが、どちらに処理をさせるかは見極めをしっかりしましょう。
DBサーバの処理を肩代わりできるのは、四則演算と最後のソートだけだそうです。

2016年12月22日(木曜日)  (柿添 貴士)

無駄な処理を削る




今週末はクリスマス、一年が過ぎるのもあっという間です。

気温の変動が激しく寒いのか暖かいのかわかりませんので、

風邪にご注意ください。



システムグループの一員として

仕事で、プライベートで、たくさんの言語・フレームワークに触れてます

一番触っているのはPHPだと思いますが、

実際にすべての処理を一から追ってみてどこが無駄な処理かというのを追うのは苦労します



そこで、プロファイラの出番です

---

プロファイラとは性能解析ツールであり、

プログラム実行時の各種情報を収集する。

特に、関数呼び出しの頻度やそれにかかる時間を計測する。

---


どこで何がどのくらい呼ばれて、どのくらい時間かかっているのか?

ということが分かるわけですね。


PHPでいうと、 xhprofという便利なプロファイラがあります。

これにxhguiとgraphvizを用いてわかりやすく処理の流れを追うことができます。



無駄処理、重複処理は極力削っていきましょう。

私はプライベートサーバに突っ込んでいろいろ処理を追ってみたいと思います。