とあるプロジェクトで 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 キーの設定をしていない、もしくは何らかの操作（変更・削除など）をしている可能性があります。

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

前置き

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

背景

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

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

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

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

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

背景

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

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

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

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

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

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

Kotlin で記述したテストを実行した際に下記の Warning が発生。
（ちなみに Kotlin のバージョンは 1.2.50）

w: Classpath entry points to a non-existent location: /path/to/app/src/main/kotlin

調べてみると Kotlin 1.2.51 で修正済み （参考）ということ。

この file.exists() が本質的な対応コードかな？

参考 URL

• 1.2.50 emits warning “Classpath entry points to a non-existent location:”
• Filter out non-existent java source roots in kapt tasks
• Changelog

ちょっとした「こういうもんなのか」ということがあったので備忘録的に残しておく。

Kotlin で書かれたオブジェクト「DataStore」があるとする。

// kotlin
object DataStore {

    private val shared: DataStore = DataStore

    fun shared(): DataStore {
        return shared
    }

    fun setup(context: Context) {
    }

}

このクラスの shared メソッドを Java から呼び出す場合は INSTANCE を経由して呼び出す必要がある。

// java
DataStore.INSTANCE.shared().setup(context);

しかし、 DataStore の shared に JvmStatic アノテーションを付けると…、

// kotlin
object DataStore {

    private val shared: DataStore = DataStore

    @JvmStatic
    fun shared(): DataStore {
        return shared
    }

    fun setup(context: Context) {
    }

}

INSTANCE を経由せずに呼び出すことができる。

// java
DataStore.shared().setup(context);

詳しい調査・解説はまた時間があるときに。

参考 URL

• Calling Kotlin from Java