プチ技術メモ

技術系の情報を中心に適当に書いています

Amazon.co.jpを利用したくないたった一つの理由

理由
  1. アメリカに納税しているから
まとめ

「国の財政赤字がーっ」と言われて久しいですが、今までAmazon.co.jpばかり利用していました。少し手間はかかりますが、今後はなるべく国内企業のサービスを利用したいと思います。
ちなみに、代替手段はかなり手抜きです。探せば他にも色々なサービスがあります。3番目の「cospa」は、最近「リブセンス」を調査しまくっていた影響です。

日本人の国際感覚に対する違和感

下記の増田を読んで妙に納得がいった。

初めて問題の動画を見てみたが、明らかに、会場の失笑は「中世」を「中年」と言い間違えた部分ではなく、「日本の人権状況は先進的」との発言が原因となっている。

それなのに、マスコミの記事では「中世」を「中年」と言い間違えたことが、失笑の原因としてクローズアップされている。また、動画を見ればすぐに分かることだが、上田特使の英語はお世辞にも流暢とは言えず、当然それを聞いている人たちが、上田特使の些細な言い間違えに反応して失笑など考えられない。失笑するなら、会議の最初から最後まで失笑の連続だろう。

仮にそうだとしても、記事にする前に「失笑」の原因が何であったのかの考察がされたのか疑問に思う。会議の参加者へのインタビューは行ったのだろうか?

私も含めてだが、上田特使の「日本の人権状況は先進的」という発言は、本当にそう思っているのだろうし、多くの日本人も同意することだろう。しかし、海外では「日本の人権状況は後進的」が常識となりつつあるのではないだろうか?もしそうであれば、そのことを国民にきちんと伝え切れていないマスコミの責任は非常に大きいと思う。

リブセンス関連のリンク

最年少上場社長で有名なリブセンスに興味があって色々調べていて、参考になったリンクを適当にまとめてみました。
ちなみに、「特集第2部」の記事が抜けていますが、どうしても見つかりませんでした;;

GitLabのNetwork Graphが優れている4つの理由

はじめに

どこぞでは「貧者のGHE」と言われていたり、いかにもGitLabはGHEの下位互換というイメージがありますが、Network GraphについてはGitLabのほうが優れている4つの理由を説明します。

なお、最新のGitLab 5.2での情報のため、古いバージョンでは当てはまらない項目があるのでご注意ください。

優れている理由

1. コミットのAuthor、ログメッセージ、レビューコメントの件数が表示される

GitHubではコミットにカーソルを当てないとAuthorとログメッセージが表示されませんが、GitLabでは一覧表示されるのでコミットの履歴を追いかけやすくなっています。また、コミットにレビューコメントがある場合は、その件数も表示されます。

2. ブランチ・タグの切替とフィルターができる

GitHubでは必ずmasterブランチが画面中央に初期表示されますが、GitLabでは画面中央に初期表示されるブランチ・タグをセレクトボックスで切り替えることができます。これは、developブランチやstableブランチを使用するようなワークフローの場合に役立ちます。また、セレクトボックスの隣のチェックボックスにチェックを入れると、選択中のタグ・ブランチのコミットのみを表示するようにフィルターをかけることもできます。

3. コミットの検索ができる

GitLabでは、検索窓にコミットのSHAを入力することで、任意のコミットを画面中央に初期表示させることができます。これは、あるコミットの前後でどのような修正が適用されたか調査するような場合に役立ちます。

4. スクロールバーによるスクロールが可能

 GitHubでは画面をスクロールさせるために、画面をドラッグ&ドロップする必要があるので手が疲れますが、GitLabではスクロールバーによるスクロールが可能なので手があまり疲れません。

まとめ

Networkが見やすいことにより、Git flowなど複雑なブランチモデルを導入するハードルが下がります。

それと、手前味噌で恐縮ですが、上記の修正は私がPull Requestで投稿してAcceptされたものになります。不便な所を自分で修正できる点もOSSならではの魅力だと思います。

スクリーンショット

参考までに、GitLab 5.2のNetwork Graphのスクリーンショットを貼っておきます。

f:id:hiroponz:20130529191850p:plain

リブセンス〈生きる意味〉

「リブセンス〈生きる意味〉」という本を読んでいて、面白いことに気が付きました。それは、最年少上場記録で有名なITベンチャーの「リブセンス」の村上太一社長と、漫画「いいひと。」の主人公の北野優二が、驚くほど似ているということです。最も分かりやすいのが、二人の信念の類似性です。

  • 村上太一社長: 人を幸せにするのは自分のため
  • 北野優二: 自分の周りの人が幸せになること

それと、いつもニコニコ笑顔なのもそっくりだと思います。

どちらの本も私がとても好きな本なので、一度読んでみてはいかがでしょうか?

リブセンス<生きる意味> 25歳の最年少上場社長 村上太一の人を幸せにする仕事

リブセンス<生きる意味> 25歳の最年少上場社長 村上太一の人を幸せにする仕事


いいひと。―For new natural life (1) (小学館文庫)

いいひと。―For new natural life (1) (小学館文庫)

OSSのContributorとして活動するということ

少し長くなります。

はじめに

去年から少しずつOSSプロジェクトで活動をしていますが、そのことについて感じていることを書いてみたいと思います。
ちなみに私は、地方の中小IT企業に勤務する普通のサラリーマンプログラマーであり、特別なスキルを持っている訳ではありません。少し変わり者で、最新技術への興味が人より強いというところはあると思います。

GitExtensionsへのPull Requestを投稿した経緯

まず、私が初めてPull Requestを送ったOSSのプロジェクトはgitextensions/gitextensions · GitHubになります。以下が私が投稿したPull Requestになります。

話は去年の9月頃に遡ります。当時、私はSVNのブランチ間のマージ管理に限界を感じてきていてsvnからgitへの移行を本格的に検討していました。移行を実施するに当たり、Windowsで使いやすいGUIクライアントがないか探していて、TortoiseGitとGitExtensionsを試しました。TortoiseGitはTortoiseSVNに近いUIを持つという利点はありましたが、そのためにGitの持つ強力なブランチ機能が犠牲になっている感じがあり、GitExtensionsを採用することに決めました。
しかし、そこには問題があり、当時のGitExtensionsは日本語のファイル名や日本語のコミットメッセージに関する、いくつかのバグが存在することが、事前調査にて判明していました。幸運にもGitExtensionsはC#で作られていて、直近のプロジェクトをC#で行った経験から、自力でその不具合を修正することができました。
そこで、せっかく直したのだからついでにPull Requestを投稿してみました。すると、GitExtensionsのコミッターのJanusz Białobrzewskiからすぐに反応があり、「こっちだと再現しないんだけど、詳しく教えてくれないか?」というようなコメントをもらい、非常に気軽な感じでやり取りをすることができ、OSSのプロジェクトに対する敷居をグッと下げることが出来ました。

GitLabにPull Requestを投稿した経緯

とりあえず、GUIクライアントの目処はつきましたが、次は使いやすいWEB UIを探す必要がありました。Gitに移行するついでに、見えないチカラ: A successful Git branching model を翻訳しましたにあるような、ワークフローの導入を検討していました。しかし、そのためには既に使用していたRedmineでは機能不足であり、GitHubにあるような"Pull Request"と"Network"の機能は必須であるように感じました。会社からGitHubを利用するお金を出してもらえる目処もなかった上に、IDとパスワードによる認証ではセキュリティ的に問題がありました。
色々と調べた結果gitlabhq/gitlabhq · GitHubを導入すれば、やりたいことは出来そうということが分かり、GitLabを導入することを決めました。そして、GitLabにプルリクエストを送ってみた - プチ技術メモにあるように、Networkに使いにくさを感じたため、自分で直してPull Requestを投稿しました。この時は、GitExtensionsで一度Pull Requestを投稿した経験があったので、当たり前のようにPull Requestを投稿したように記憶しています。

言いたいこと

結局、何が言いたいのかというと、GitHubにホスティングされているOSSプロジェクトにPull Requestを投稿することは、特別なことではなく、私のような普通のプログラマーこそ、どんどん挑戦すべきだということです。私の場合、職場の上司が私の技術的な取り組みに対して非常に寛容なところがあり、仕事の合間に色々と調査することが出来たことが大きかったと思いますが、少し頑張れば誰にでも出来ることだと思います。

それと、GitLabのContributorとして活動していて気が付いたことですが、日本人のContributorが本当に少ないです。GitLabは日本でもそこそこ人気であり、もっと日本人のContributorがいてもいい気がしますが、現在、継続的に活動しているのは私一人という状況です。OSSのContributorとして活動することにより、プログラマーとしての能力を飛躍的に高めることができると実感していますが、そこに参加する日本人が少ないことは非常にもったいないことだと思います。

最後に

最後になりますが、日本でOSSのContributorというと一部のスーパープログラマが趣味でやるもので、一種のボランティア活動というイメージがあります。そのため、普通のプログラマーがOSSで積極的に活動しようというインセンシティブが働かないのだと思います。一方、海外に目を向けるとGoogleやAmazonはOSSコミュニティに対して大きな投資を行い、それにより多数の優秀なプログラマを集めて、急速な成長を遂げています。日本においても、OSSでの活動を通してプログラマのキャリアアップが可能となるような環境があれば、OSS界隈で活動するプログラマが増えて、日本のIT技術の底上げに繋がるのではないかと思う今日この頃です。

GitLab 5.1がリリースされ、なぜかMVPに選ばれてた

毎月22日の定期リリースということで、予定通り4月22日にGitLab 5.1がリリースされました。今回の主な変更点を適当に訳すと以下の通りです。

  1. 通知設定がプロジェクト毎に3段階に設定できるようになったよ。
  2. バックアップ機能をリファクターしたよ。添付ファイルとプロジェクトのwrite hook(?)とsshの権限も復元できるようになったよ。
  3. ネットワークグラフがかっこよくなったよ。垂直方向になって、コミットメッセージとかが表示されるよ。
  4. UnicornからPumaに切り替えたことで、パフォーマンスとメモリ消費量が改善されたよ。

このうちの3番目の修正が評価されて、MVPに選ばれたみたいですwそれと、通知設定は"My Profile"の"Notification"でユーザー毎に自分で変更できるようです。

早速、会社のGitLabを5.1にアップデートしましたが、プロジェクトのファイルを表示する画面でエラーが発生するという罠がありました。原因はサーバーのgitのバージョンが古いせいだったので、ついでに、gitのバージョンを1.8.2にアップデートして無事解決しました。

GitLabはバージョンアップが頻繁でどんどん機能が追加されるのが魅力の一つですが、結構な確立で何らかの罠があるので、本番環境のバージョンアップ前にテスト環境での事前検証を実施することが大切だと改めて思いました。