Bot: Cincraw Crawler - Mozilla/5.0 (compatible; Cincraw/1.0; +http://cincrawdata.net/bot/)

このユーザーエージェントは、自分の管理するサービスでたまに見かけるものです。

Mozilla/5.0 (compatible; Cincraw/1.0; +http://cincrawdata.net/bot/)

株式会社 CINC さんの開発したクローラーのようです。 目的はかかれていないですが、アクセスログを追う限りは非常に礼儀正しいクローラーです。

技術検証用なのでしょうかね?

Cincraw Crawler のクローリングポリシー

Homebrew: インストール先のディレクトリーを /usr/local 以外に指定する方法

Mac ユーザーのエンジニアなら多くの人が Homebrew を使うと思います。
個人的には root 権限が要らないユーザーホームディレクトリー直下に置くのがおすすめです。

$ mkdir -p .homebrew/
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C ~/.homebrew
$ cat << 'EOF' >> ~/.bash_profile
export PATH=$HOME/.homebrew/bin:$PATH
export HOMEBREW_CACHE=$HOME/.homebrew/caches
EOF

参考

Git: 'remote: Repository not found. fatal: repository ~ not found' - Git でプッシュできない件

とあるプロジェクトで Github 上のリポジトリーをローカルにクローンして、諸々作業し終えたあとにコミットしてリモートにプッシュしようとしたときにこのようなエラーが発生しました。

$ git push origin XXXXX
remote: Repository not found.
fatal: repository 'https://github.com/XXXXX/YYYYY.git' not found

エラー内容を見ての通り「リモートにリポジトリーが見つかりません」というメッセージです。

確かにクローンしたはずなのに…と思い、リポジトリーを確認したところやはり存在しているので「もしかするとプッシュする権限がないのではないか」と思って、リポジトリー管理者に問い合わせたところ、案の定、書き込み権限がなかったようでした。

Github の公式ヘルプにも載っていますが、このエラーが発生したら、次のことを疑ってみましょう。

1. 存在を確認しましょう

リポジトリーの名前は「大文字・小文字を区別」するので、タイポかもしれないです。

クローンまたはプッシュが出来る想定ならばリポジトリーも閲覧できるはずなので、リポジトリーの存在を確認する意味でも、実際にアクセスしてみましょう。

アクセスできたならば、そのリポジトリーのクローン URL をコピーして使ってみましょう。

2. 権限を確認しましょう

このエラーは、プライベートリポジトリーをクローンするときに閲覧権限を与えられていないときに発生するエラーでもあります。

閲覧権限は下記のパターンが考えられます。

  • リポジトリーの所有者である
  • リポジトリーのコラボレーターである
  • リポジトリーにアクセス権のあるメンバーである

あとは書込権限を与えられていないリポジトリーにプッシュしようとしたときにもこのエラーが発生します。

これについては当該リポジトリーに対しての書込権限があるかどうかです。

3. SSH アクセスを確認しましょう

SSH 形式でクローン、プッシュするときに実は SSH キーの設定をしていない、もしくは何らかの操作(変更・削除など)をしている可能性があります。

自分のアカウントを確認してみましょう。

Git

Facebook: 1 つのサイトで複数の Facebook Pixel タグを設定するには

前置き

いまさらながらな内容かもしれませんが、ちょっと気になったので備忘録的に書いておきます。 そこからかよっ!という説明になっているかもしれません…。

背景

サービスを運営しているとどこかのタイミングで Facebook などのソーシャルサービスに広告を配信するフェーズが出てきたりします。

Facebook には Facebook 上で広告配信するための管理コンソールであるビジネスマネージャという機能があります。 Facebook に広告を出稿する際には、このビジネスマネージャから発行される広告の効果を測定するためにピクセルタグというものをサイト内のあちこちに貼り付けることになるでしょう。

しかしながら、自社または自身で Facebook の広告を運用するのは大変だったりします。 そこで広告代理店が間に入り、決められた予算内で目標の効果を達成するべく、広告の運用を代行してくれたりします。

代理店が 1 社であればピクセルタグの導入はテンプレ(教科書)通りに導入できますが、 2 社以上になってくると問題が発生してきます。

どういう問題が発生するかというと、ピクセルタグから送信されるデータに不整合(重複して送られたり、優先度が決まっていたり)が発生するのです。

つづきをみる

API 記述言語や API ドキュメンテーションツールの比較(Swagger、API Blueprint、RAML)

背景

「最近」というには最近すぎる気がしますが、今日のシステム開発では、変化し続ける要件に対応するため、システム自体にも柔軟性がもとめられています。

その中でも、サーバーとクライアント、またはサーバー同士のやり取りのためのインターフェイスである Web API(以下、小面倒なので平たく API と呼びます)は Web システムにとって、もはや欠かせないものだと思います。
その API を設計する際には多くの人が RESTful API を採用するでしょう。

しかし、採用したものの設計方針が人によって微妙にバラつきがあったり、ドキュメントの運用保守ができていなかったり、モックや API コンソールを作らなければならなかったり、ドキュメントからではなくコードから書く人がいたりと、開発規模や状況に応じていろいろなレベルの課題が存在します。

そろそろ上記のようなことは API 設計が終わった段階で 8 割くらい終わっている状態にしたいですよね。
API の保守は、ソースコードそのものだけでなく、ドキュメント、API コンソールやスタブ、単体テストなど影響が広範囲に及びます。
それらの解決の手助けをしてくれるのが API ドキュメンテーションツール(一部では API フレームワークとも呼ばれている?)です。

API ドキュメンテーションツールとは

API ドキュメンテーションツールは、設計から開発、ドキュメント生成までをワンストップでサポートします。
最近のツールでいうと、そのツールが対応している記述方式(API 記述言語というべきか?)で API を定義することで、以下のようなことができます。

つづきをみる