まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

IBM Cloud(Bluemix) のアカウントを所有していると、マネージドサービスとして利用できる GitLab が使えるようになります。サーバーのインストールなどは不要で、プライベートリポジトリを作成することも可能です:
2018011701


使い勝手は GitLab そのものだと思ってください。Issues 管理の機能も使えますし、IBM Cloud の Continous Delivery サービスと連携した Delivery Pipeline による DevOps サービスの一部としても利用できるようになっています。アカウントをお持ちの方は、単にプライベートリポジトリが使える Git として考えるだけでも便利だと思うので、是非活用してください。


ところで、この IBM Cloud の Git を使って Java のアプリケーションコードを管理しようと、作成したリポジトリから Eclipse の Git 機能を使って clone を試みた際に、稀に以下のようなエラーメッセージに遭遇し、クローンに失敗することがあります:
  :
  :
!MESSAGE https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
!STACK 0
org.eclipse.jgit.api.errors.TransportException: https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
  at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:196)
  at org.eclipse.egit.core.op.ListRemoteOperation.run(ListRemoteOperation.java:99)
  at org.eclipse.egit.ui.internal.clone.SourceBranchPage$8.run(SourceBranchPage.java:324)
  at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.jgit.errors.TransportException: https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
  at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:499)
  at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:308)
  at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:175)
  :
  :

「git-upload-pack がオープンできない」という耳慣れないエラーメッセージで、実はこのメッセージそのものからは原因の追求が難しいものでした。同じようなエラーに遭遇する人が現れた場合に備えて、自分の経験と回避策を紹介します。

エラーメッセージそのものからはわかりにくにのですが、実は直接の原因は暗号化方式の不一致による通信エラーでした。

まず上記で紹介した IBM Cloud の Git 機能を https 接続で使う場合の暗号化方式には TLS v1.2 を使う必要があります:
https://console.bluemix.net/docs/services/ContinuousDelivery/git_working.html#git_local


さて、Eclipse が使う Java のバージョンが 1.8 以上であれば、デフォルト設定のままで TLS v1.2 が使われます。したがってこの場合は何もしなくてもそのまま IBM Cloud の Git を利用することができます。

一方、Eclipse の Java バージョンが 1.7 以下だった場合、デフォルト設定で採用される通信方式は TLS v1.1 以下です。つまり条件を満たしていないことになります。そしてこの条件で Git に接続しようとすると上記のようなエラーメッセージが表示されてしまうのでした。


では、このエラーメッセージが出た場合の解決策はどうすればいいのでしょうか? 1つの方法としてJava のバージョンを 1.8 以上にするという簡単な方法があります。Java 1.8 以上であれば上記のように(デフォルトで) TLS v1.2 が使われるので、この条件を満たすことができるようになります。

ただ何らかの事情で Java 1.8 を導入するわけにはいかない場合もあると思っています。そのような場合は以下の1行を eclipse.ini に追加した上で Eclipse を起動する、という方法もあります:
  :
  :
-Dhttps.protocols=TLSv1.2

この記述により、Java が 1.7 以下であっても強制的に https 接続時の暗号化方式を TLS v1.2 に指定することができ、やはり上記のエラーを回避することができるようになります。


IBM Cloud 以外の Git でも、同様のエラーメッセージが出た場合にはこの対策が有効だと思っています。頭の片隅に入れながら、無料で便利な IBM Cloud の Git を是非使ってみてください。


2018 年最初のブログエントリはちとマジメなマンホールマップネタにします。

2010 年夏のリリースから7年半近くもの間に多くのマンホールファンの皆様に愛され、成長を続けてきたマンホールマップですが、リリース当初の小規模運営時には想定していなかった問題にも多く直面してきました(コストとか、容量とか、プラットフォームの仕様変更とか、・・・)。そしてその都度問題を先送り解決しながら成長してきました。

そんな問題の中で、未解決だったことの1つが「利用規約」および「プライバシーポリシー」でした。端的な言い方をすると「マンホールマップにアップロードした画像の著作権はどうなるのか?」という問題です。サービス開始当初はいわば「一部のマニア向けサービス」であり、当時存在していなかった位置情報付きマンホール情報共有サービスとしての物珍しさから、細かいことを気にする人も少なかったように思えます(僕が知らなかっただけかもしれませんが)。

時は流れ、ユーザーや業界の努力、そして街歩き等他の趣味と合わせる形での認知度もあがり、マンホール探しそのものが趣味として認知されつつあるようになってきました。同時にマニアの域を超えて、広く一般の人がマンホールに興味を持つようになり、マンホールマップは(色々なこだわりは残しつつも)マニア向けではないサービスとしての変革が求められるようになってきました。

さて利用規約およびプライバシーポリシーの問題です。実はこれまでマンホールマップには明確な利用規約およびプライバシーポリシーの明示がありませんでした。昨年だけでこの点での質問を何度かいただくようになり、そろそろサービス提供側としての対応が求められていることを認識しました。という背景もあり、2018 年最初のアップデートに併せて遅ればせながらマンホールマップの利用規約およびプライバシーポリシーを用意する運びとなりました:
利用規約
プライバシーポリシー


PC版ページ(http://manholemap.juge.me/)ではトップページの一番下に、
2018010401


モバイル向けページ(http://manholemap.juge.me/m.jsp)ではトップページのメニューの最後に、それぞれリンクが付いています:
2018010402


これら2つのページの内容は利用するウェブブラウザの言語設定によって日本語または英語で表示されるようになっています。以下の補足については日本語をベースとしています。

以下は(2018/01/04 時点での)特に利用規約に関する内容を補足したものです。上記2ページを読んだだけだと「結局アップロードした画像の著作権はどうなってるの?」という問題の答がわかりにくいと思っているので、その点を解説しています。

利用規約内には以下のようにかかれています(2018/01/04):
ユーザーが投稿した写真(画像)の著作権について

Juge.Me およびマンホールマップでは、ユーザーが本サービスに、またはこれを通じて投稿するいかなるユーザーコンテンツについても、その所有権を主張しません。 ただしユーザーは、ユーザーが本サービスに、またはこれを通じて投稿するユーザーコンテンツを、Juge.Me およびマンホールマップが http://manholemap.juge.me/privacy.jsp に掲載されている本サービスのプライバシーポリシーに従って利用する、非独占的かつ無料、譲渡可能かつ再許諾権付きの世界的使用許諾を付与するものとします。 またユーザーが投稿したマンホールマップ内の画像はマンホールマップのページ単位で第三者がシェア/共有することについては同意するものとします。

マンホールマップ側ではその著作権を「主張しない」ことを明言しています。つまり写真の著作権は投稿者にあり続けます。著作権についてはこの点を明確にしました。

ただし以下の2点に注意してください:
(1) ただしユーザーは、ユーザーが本サービスに、またはこれを通じて投稿するユーザーコンテンツを、Juge.Me およびマンホールマップが http://manholemap.juge.me/privacy.jsp に掲載されている本サービスのプライバシーポリシーに従って利用する、非独占的かつ無料、譲渡可能かつ再許諾権付きの世界的使用許諾を付与するものとします。

(2) またユーザーが投稿したマンホールマップ内の画像はマンホールマップのページ単位で第三者がシェア/共有することについては同意するものとします。

(1) はユーザー(投稿者)が投稿する画像コンテンツについて、マンホールマップ側に対して、
  • 「非独占的に(マンホールマップだけのものではなく、他の SNS 等に投稿することができる)」
  • 「無料(その際、投稿者に著作権料は支払われない)」
  • 「譲渡可能かつ再許諾権付き(マンホールマップ側の判断で他のメディアやサービスに画像を提供することができる)」
という条件を付与する、という意図を含んでいます。

実際のところ、これまでもマンホールマップ内のコンテンツは誰でも利用可能な API によってアクセスすることができ、その API によって多くの関連サービスが生まれてきていました。加えてマンホールマップでは画像の全体的な色に近い色で画像に枠を付けて表示するなどの加工を行った上で表示しています。それらを明文化した形になります。

また、(2) は画像としての勝手な再利用は制限していますが、マンホールマップのページ(URL)単位で SNS にシェアしたり、ブログなどで再利用することについては第三者が無許可で自由に使うことができることを謳っています。


基本的にはこれまで通りの機能を後追いする利用規約(とプライバシーポリシー)としているつもりですが、どうしてもこの内容での公開に不安を感じられる場合は相談いただくか、あるいはお手数ですが問題が解決するまでの間、いったん削除していただきたいです。




自宅で動かし続けているラズベリーパイの単体での無停止連続稼働時間が 500 日を超えました:
20171230
(↑ 2017/12/30 時点で 530 日)

無停止で稼働し続けることそれ自体に価値があるとは思っていないのですが、このラズパイからは CPU 温度と CPU 負荷率を1秒ごとに IBM Cloud の Watson IoT Platform に送信し続けており、ずっと記録を残しています(その手順はこちら)。そのデータ元がこのラズベリーパイなので、もう2年近くもデータを連続送信できていることになります。

一方で、「ラズベリーパイは不安定」、「無停止連続稼働にはむかない」という印象を持っている人も少なくないと思います。というわけで自分がこの無停止稼働環境をどうやって運用しているか、(個人的な見解ですが)もしかしたらヒントになりそうな部分を2つ紹介します。

(1) ラズベリーパイ2

使っているモデルはラズベリーパイ「2」です。「3」や「zero」ではありません。個人的には2が一番安定していると思っています。zeroは論外として(苦笑)、3はスペックこそ2よりも上がっていますが、電源供給が不安定という(個人的な)印象です。確かに安定して電源を供給できるケーブルがあれば安定しているのでしょうが、この「安定して電源を供給できるケーブル」を見つけるのがなかなかに難しく、苦労している人も多いと思っています。その点で2はまず問題なく安定した電源供給ができると思っています。実際、自分はラズパイ3も2台持っているのですが、電源供給でかなり苦労しています。

ここまで聞いて「でも2だと標準機能だけでは無線 LAN が使えないからなあ・・」と思った方、次を参照ください。


(2) ネットワークは LAN ケーブル

ラズベリーパイに限りませんが、安定稼働させようとする場合、有線 LAN を使うべきだと思っています。あとトラブル発生時の原因箇所切り分けや、対処に必要な手続きも無線 LAN の方が複雑です。



まとめると「ラズパイ2を使って電源を、そして有線 LAN でネットワークをそれぞれ安定させる」のが鍵ではないかな、と思っています。 が、実際の所はどうなんでしょう?ただラズパイを安定して連続稼働させることに苦労されている方がいたら参考にしてみてください。


このページのトップヘ