Archive for the ‘Uncategorized’ Category
GitHubが政府・自治体向けの機能・事例紹介ページを公開
ドイツの活動家が法令をGitHubにアップするといった事例(政府が公開したわけではない事に注意)で知られるように、政府・自治体の発信する情報をGitHubで公開するというアイデアが知られつつ有ります。実際に政府や自治体での利用を促すコンテンツをGitHubが公開しました。
GitHub and Government | Make government better, together.
http://government.github.com/
このページよると180近い政府・自治体の団体がGitHubを利用しており、この事例リストそのものもリポジトリで管理されています。
コンテンツは政府などのIT業界でない方むけにGitHubのコラボレーション機能を説明するコンテンツと事例の紹介という形になっています。説明としては「コラボレーション」「ビジュアライズ」「共有」といった形でGitなどの専門用語を使わずに一般のWebサービスのように紹介されています。
このページで実際に活用の取り組みとして公開されているのは下記のようなストーリーです。
- オークランドでのパブリック・プライベートでのコラボレーション
- カナダでのWebの拡大ツールキット
- シカゴでの自転車道路、歩道などのデータのJSON公開
- フィラデルフィアでのWebホスティングや補助金計算アプリの公開
当初はプロジェクトのページをホスティングするための機能だったGitHub Pagesの機能がいわばCMSのような形で活用されつつあるようです。またオープンデータに関する運動のプラットフォームとしてもJSONのデータのリポジトリといった形での活用が行われつつあります。
現在の所日本での活用事例は無いようですが、いずれ何処かの自治体などでの事例が公開されるかもしれません。事例の掲載などについてもプルリクエストの形で登録を受け付けています。
via:https://github.com/blog/1657-introducing-government-github-com
GitHubが(何故か)ミュージックビデオを公開
タイトルをご覧の通り、GitHubがミュージックビデオを公開しました。曲名は「Better Together」。コラボレーションの素晴らしさを歌ったこの一曲は話題になる事間違いなしです。ビデオにはGitHubberも多数出演していますのでGitHub大好きな私たちにピッタリの一曲です。
追記
このミュージック・ビデオはGitHub Guidesという一連のビデオシリーズの購読を促すものです。以前紹介したようにGitHubは公式YouTubeチャンネルを開設し、動画コンテンツの周知に力をいれているようです。
歌詞
Better Together Song produced by Jeff Kite Sometimes your code looks perfect, Nothing to rearrange. Sometimes you fork, out a feature When you need some kind of change. No matter what the diffs are this time, Nothing's going to stand in my way. Commit from my heart, The code I prefer Give every repo a branch you can merge! Standing tall, learning git is my dream Rise and fall, pull requests with my team Subversion workflow It's not amaze(balls) I'm bound for better days It's my life on GitHub, Nothing's going to stop me now. |
いっしょがいいね 和訳 Yusuke Ando 君のコードが完璧で なにも直すところがない時も フォークして機能を追加して 何かを変えたい時も diffなんかどうでもいい 邪魔するものはなにもない さぁ、心からコミットしよう 僕の好きなコードを マージできるブランチを全部のRepoに送ろう 自信をもって、Gitを学ぶのが僕の夢さ さぁ、飛び出そう 仲間とプルリクエスト Subversionのやり方は退屈さ 楽しい日々へ向かおう GitHubで生きる 何も僕を止められない |
動画
別バージョン（GitHub Guidesの宣伝付き）
上司へ退職を伝える斬新すぎるビデオが話題
上司に退職を伝える為に作成された斬新なビデオが話題になっていました。
まずは動画を御覧ください。
Marina V Shifrin氏はニュース動画を作成する会社に勤務していましたが、交際や時間や体力などを犠牲にし約2年、勤務していましたが、再生数だけに注意を払う上司などに不満を持ち、再生数を気にせず、自分自身の為に動画を撮影しついでに退職の意思を伝えてみたよう。
当然ながらこの動画は現時点で3日で500万回以上再生され大変な話題になっています。
すでにパロディ動画も作成されており、”I Quit Dance”(退職ダンス)というムーブメントに成長するかもしれません。
またMarina氏、はブログなどの活動、コメディアン活動も積極的に行っており、渦中の人物の近況をウォッチするのも面白そうです。
なんでもツイッター上で多数のプロポーズを受けている事に母親が驚いているそうですが、ダンスっぷりはスルーだそうです。
いやぁ、ミームっていいものですねぇ。
米国で話題の食べ物、ラーメンバーガーとクロナッツ
米国の大手ネットメディアの一つであるMashableに目を引く記事が載っていました。「ラーメンバーガーを自作する方法」と題された記事は日本のネットでも話題になったラーメンバーガーをなんと自作するという話です。日本で販売されたラーメンバーガーはバンズに麺とチャーシューを挟むという炭水化物＋炭水化物を攻めている形式でしたが、こちらは麺をバンズに見立てて、ふつうにハンバーグが挟まっているという形です。
何故、急にラーメンバーガーが米国で認知されたのかというと、記事によればブルックリンで開催されたフードフェスティバルでgo ramenのKeizo Shibamoto氏が披露したラーメンバーガーは話題になりなかなか食べるのが難しい逸品になったからのようです。これを受けて、食べにいけないなら自作しちゃおうというDIYな記事なわけですね。日本でいうところの食べるラー油ブームみたいな感じでしょうか。
ちなみに本物は下記のようなルックス。
GO RAMEN!: Miso Pimento Cheese Ramen Burger…
ちなみに元の記事で話題すぎて食べられない食べ物としてもう一つ話題に挙がっているのが「クロナッツ」というクロワッサンの生地で作られたドーナツです。これがまたえらい人気でニューヨークでは行列しても売り切れて買えなかったり、１人２個までというアメリカでは考えられないような購入制限があったりで話題になっています。クロナッツについては既に日本語の記事も色々あるようなのでググってみてください。ニューヨークに関するブログとしては老舗のりばてぃさんのブログにも載っていました。
今、NYで大人気のドミニク・アンセル・ベーカリーのクロナッツ : ニューヨークの遊び方
ちなみにクロナッツはA-ListersのライターではTakashiのみ食べた事があるようです。うらやましい。どちらも話題の食べ物なので米国の方との雑談のネタにもどうぞ。パン屋さんをなさっている方は是非商品化の検討もどうぞ！
TogetherJS – 埋め込むだけでサイトにチャットなどの機能を追加する
Hacker Newsを見ていたらMozillaの公開しているプロジェクトが話題になっていました。内容はシンプルかつ強力です。JavaScriptのコードを埋め込むだけでWebサイト上でチャットやカーソル位置の共有、音声チャットといったコラボレーション機能が使えるようになります。
TogetherJSは次のような機能をサポートしています。
- ビデオと音声のチャット
- テキストチャット
- カーソルとクリックの共有
- 共同ブラウジング
- ユーザ情報の共有
- リアルタイムコンテンツ同期
埋め込むだけで使えるというのはどういうことかと思いますが、実際にはJSで書かれたサーバサイドモジュールとクライアントサイドのスクリプトで構成されています。サーバーサイドを自分自身で稼働させる事も勿論できますが、サンプルとして貼り付けるコードについてはMozillaがホスティングしているhubというサービスをサーバーサイドとして実行されるようになっています。
プロジェクトに大きな貢献をしているIan Bicking氏はさまざまなJavaScriptのモジュールを公開しておりTogetherJSについても拡張可能な構成などに気をつけているようです。単純にサービスとして埋め込むだけではなく、リアルタイムコミュニケーションが肝になるサービスの実装などに利用できるかもしれません。
OSSのバグを直して賞金がゲットできる Bountysource
オープンソースソフトウェアの開発だけで生活していくという夢を現実に近づけるサービスが現れました。その名も「BountySource(賞金ソース)」という事で、GitHub上などで公開されているプロジェクトのバグや機能改善に対して賞金が設定され、修正を行った人に支払う仕組みを提供しているサイトです。公式ブログによると、2004年から運営されていたbountysourceは2012年末にリニューアルして、現在のサービスがスタートしたとのことです。
例えばLESSプロジェクトの「ソースマップを生成する」というバグに対しては3人の開発者の修正が採択され、合計で75ドルの賞金が決定されました。また、このBountysourceのサイトのフロントエンド自身の開発もオープンソース化されており、多数の賞金が設定されています。
このサイトは上記のような賞金をベースにしたクラウドソーシング的な側面を持つだけでなく、任意のプロジェクトに対して寄付を行うというクラウドファンディングとしての機能も持っています。自分が支援したいサービスや利用したいプロジェクトに対して、出資を行う事でプロジェクトの開発に活気が生まれる可能性があります。
多くの寄付金を集めているプロジェクトとしては、GitをJavaScriptで再実装するJs-Gitのプロジェクトは現時点で$34,956もの寄付を集めており今後は開発者に対してこの寄付金が賞金として支払われていくようになります。オープンソースへの寄付としてはかねてよりPayPalなどでの送金がありましたが、Bountysourceを利用する事で資金の流れや開発者の貢献度が可視化される事になります。
まだ日本のプロジェクトが目立っている例は無いようですが、今後は日本での利用事例や同様のサービスが日本で登場するといった展開があるかもしれません。オープンソースの文化に賞金という報酬体系がマッチするかどうかは不明ですが、今後も気になるサイトになりそうです。
via:https://www.bountysource.com/
GitHubの公式YouTubeチャンネルが豊富
さまざまな機能をリリースし続けているGitHubですが、コンテンツづくりも活発になっています。GitHub公式のYouTubeチャンネルではGitHubの理念を説明するインタビュー動画や、GitHubがサポートする女性向けコミュニティ「Passion Project」のイベントでの講演録画、またさまざまなワークショップやカンファレンスなど多岐に渡ります。
素晴らしくなる為には、失敗をする為の余裕が必要なんだ。それがGitHubが特別な存在になった理由です。
GitとGitHubの基本を解説する50分のトレーニング
GitHubを業務に導入するにあたって解説コンテンツなどがあると、導入を推進する立場の労力も下がりますし、こういった動画を活用してみるのも良いかもしれません。なお、これらの動画には当然日本語の字幕などはついていませんが、有志の活躍などによって日本語でも楽しめるようになると良いのではないでしょうか。
綺麗な設計を身に付けるためのSandi Metzルール
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。
このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。
そのルールは以下の通りです。
- クラス内のコードが100行を超えてはならない
- メソッド内のコードが5行を超えてはならない
- 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす）
- コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる
- ビューは1つのインスタンス変数を参照し、そのオブジェクトに対するメッセージ送信のみを行うことができる（
@object.collaborator.valueは許可されない）
- ビューは1つのインスタンス変数を参照し、そのオブジェクトに対するメッセージ送信のみを行うことができる（
項目は少ないですが、方向性としてはThoughtworksアンソロジーという書籍で紹介されていた「オブジェクト指向エクササイズ」に通じるものがあります（あちらはJavaが主な対象でした）。
4つのルールとは別に、このルールを破ってもよい場合として、
- 適切な理由があると考えられる場合
- ペアプログラミングのパートナーやコードレビュアーが許可した場合
がルール0として挙げられています。
thoughtbotでは実際のプロジェクトにこのルールを適用してみたそうで、以下のような知見が得られたようです。
- ルール1 クラス内のコードが100行を超えてはならない
- Single Responsibility Principle（単一責任の原則）を徹底するようになる
- テストも100行以内に収めることを心がけたことで、1つのファイルで多くの機能をテストしすぎていたものを、よりフォーカスの定まった個別のテストに分割できた
- ルール2 メソッド内のコードが5行を超えてはならない
- メソッドを5行に収めるために、
elseやelsif - 条件分岐で1行を使うのではなく、適切な名前のついたプライベートメソッドを作ってそれを呼ぶようになった
- コード片をプライベートメソッドとして抽出することで、命名が行われ、説明としても役立つようになった
- メソッドを5行に収めるために、
- ルール3 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす）
- Railsのビューヘルパーメソッドはとても多くの引数を要求するため、よい解決法が見つからない場合は、ルール0に立ち返り引数をそのままとした
ルール4については、実際のコードを例に詳しく説明がされています。
ルール4を適用すると、1つのコントローラーが1つのオブジェクトだけをビューに引き渡すように設計することになりますが、実際のプロジェクトでは必ずしも1つのコントローラーが1つのものを表示するとは限りません。
例えば、「トップページにアクティビティフィードと通知の数を表示する」といったようなケースも頻繁にありえます。thoughtbotではこのようなケースにFacadeパターンを適用し、アクティビティフィードと通知の数を内包したダッシュボードクラスを定義することで、コントローラーとビュー間のやり取りを単純化させることにしたようです。
詳細は、実際のコード例を見れば一目瞭然だと思いますので、ぜひ元のブログ記事も参照してみてください。
Git SubmoduleのトラブルをGit Subtreeで解決できると知っていますか？
ライブラリやフレームワークなど、外部のリポジトリで管理されているソースコードをプロジェクトに取り込む際によく使われているgit submoduleを使わないほうが良いという論争が起こっています。それを受けてgit subtreeを使うべきであるというエントリがAtlassianのNicola Paolucci氏がブログに投稿しています。彼はまずgit submoduleを使うべきではないという話題が盛り上がっているという事で3つの記事を参照したあとに、git subtreeを使うべき理由と使用例を挙げています。それによるとgit subtreeを使うべき理由は以下のとおり。
- ワークフローがシンプルなので管理が簡単。
- 古いバージョンのgitもサポートしている。(v1.5.2ですら。)
- サブプロジェクトのコードがcloneした直後に利用できる。
- subtreeはユーザに新しい学習を要求しない。subtreeを依存性の解決に使っていることは無視する事ができる。
- subtreeは新しいメタデータファイルを追加しない。例えばsubmodules が追加する.gitmoduleのようなファイル。
- モジュールの内容を別のリポジトリのコピーなどを他所に持たなくても編集できる。
もちろん、git subtreeを使う事への代償もありますが、これらは受け入れられるというあろうとして、下記のように挙げています。
- subtreeをマージする戦略について学ぶ必要がある。
- サブプロジェクトのアップストリームにコントリビュートするのはやや複雑になる。
- 親プロジェクトとサブプロジェクトのコミットを混ぜないようにする責任は自分自身にある。
具体的な利用例は元記事の残りを見て頂くとして、subtreeがsubmoduleを使う場合によくある問題をクリアしていることがわかります。基本的には新たなremoteを追加して別々にmergeしていくだけなのでブランチの管理のような感覚で利用できるという事でsubmoduleを避けてわざわざコピーしてしまったような場合はsubtreeの利用を検討してはどうでしょうか。
via:http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
図解で見るスタートアップのはじめかた
タイトルどおりのインフォグラフィックが興味深いのでご覧ください。いちおう項目を書きだしておきます。
- 現在よりも未来を生きる
- 世界に足りないものを考える
- それやアイデアを書き起こす
- プロトタイプを作る
- プロトタイプを100人に見せる
- プロトタイプを納得行くまで改良する
- 共同創業者を探す
- 会社を登記し株式を分割する
- 資金調達を探しながらバージョン1を開発する
- ローンチし人々に何かをつくったことを知らせる
- ユーザにフォローアップを行い反応を見る
- 反応がなければ改良を行なってローンチする。(airbnbは3回ローンチしている)
- 反応があれば、ユーザを1000人獲得する
- 毎週、5％成長する(大変だけど、可能)
- 4年間、成長を維持する。レートを維持していれば2500万ユーザに到達している
- 大成功！
これなら誰でもスタートアップがはじめられますね！というわけには行かないですが、物事をシンプルに考えてみる助けにはなると思います。数字として出ている1000ユーザ、5％成長などが参考になるのではないでしょうか。
via:http://notes.fundersandfounders.com/post/50348129830/how-to-start-a-startup-15-steps
A-Listers 