投稿者アーカイブ
GitHub全体のサマリのレポートサイト – Octoboard
開発者にとって最重要なサービスになりつつあるGitHubの日々の状況を一覧できるサイトが登場しました。その名もOctoboard。日々のコミットやフォーク、プルリクエストの量が平均より多いかどうかなどをリポートしています。
これによると一日あたり10万以上のアクティビティがあり、5000近いリポジトリが作成され、3000以上のIDが登録されているようです。GitHubの規模感を説明する際などに便利な資料になりそうです。
喜びの多いプログラミング言語はObjective-CとPHPと判明
いやいやもっと楽しい言語あるでしょ？と思った方にとっても興味深い調査結果がExploring Expressions of Emotions in GitHub Commit Messages(GitHub上のコミットメッセージの感情表現の調査)として公開されていました。記事の作者はベルリンのRamiro Gómezさんで、自然言語とプログラミング言語の双方に関心のある彼はGitHubが公開した統計情報からさまざまな感情表現をコミットメッセージから探して分析するという調査を行いました。これによりanger(怒り), joy(喜び), amusement(楽しみ) surprise(驚き)の表現が多く使われているプログラミング言語のランキングを生成して公開しています。
怒りの言語はVimL、C、Shell
怒りのランキングではangry(腹を立てる)、annoying(いらいらする)、cranky(酷い)、hate(嫌い)といった単語を抽出し、結果的には2位にダブルスコア近い差をつけてVimLがトップに輝いています。次いでCやShellなどもインストーラーが全てのファイルを削除するといったクリティカルな問題に発展しそうな気配があり、そういうものなのかなという気がします。
しかし何故VimLの人たちが際立って怒っているのかは謎です。
喜びの言語はObjective-C、PHP、Perl
続いて喜びのランキングではyes、yay(やった)、bingo(それだ)、glad(うれしい)といった単語を抽出しObjective-CとPHPが際立って高い結果になっています。どちらもプログラミング言語としては理路整然という訳ではない部分もありそうですが、動く物を作るという行為には直結していそうなイメージがあり、ものづくりを楽しんでいる雰囲気が現れているのかもしれません。
本文では触れられていませんが、怒りの言語でトップであるVimLが最下位に入っている点も見逃せません。
楽しみの言語はRuby、C#、Java
楽しみのランキングでは、lol(笑)、rofl(爆笑)といった笑いのスラングを抽出したところ、RubyとC#が際立って高い結果になっています。また本文では触れられていませんが、怒りの言語の王様であるVimLが最下位にまたしても入っている点も見逃せません。
Rubyが上位に入っているのはコミュニティの発展がGitHub上で達成されているという事なのかもしれません。
驚きの言語はPerl、Objective-C、C
驚きのランキングではgosh(おやっ)、stumped(当惑)、surprised(驚いた)などの単語を抽出し、PerlとObjective-Cが高い結果になっています。またC++とPHPは下位に沈んでいます。
罵りが多い言語はVimL、Objective-C、C
所謂、Disり合いについても分析が行われ、ここではいわゆる罵倒表現達(wtf等)を抽出しています。堂々のトップに輝いているのはVimLです。また意外にもPHPは下位に沈んでいます。なお例として抽出されたコメントが例示されているのですがこの項目についてはとてもストレートな感じでわかりやすいです。
プログラミング言語の人気というのはなんとなく感じる部分はありますが、こういった分析は各言語の成熟度や使われるシチュエーションについて想像する助けになりそうです。この調査の為のコードもGitHubで公開されていますので、フォークして日本語のメッセージで分析したり別の観点のレポートを作ってみるのも面白いかもしれません。
またVimLユーザの怒りの理由についての情報もお待ちしております。
via:http://geeksta.net/geeklog/exploring-expressions-emotions-github-commit-messages/
ソ連の宇宙開発で使われていたプログラミング言語は？
stackexchange.com上のソビエトの宇宙開発でどんなプログラミング言語が使われているのか？という話題で興味深い議論が展開されています。
投稿者は「ソビエトの宇宙開発プログラムの宇宙船ブランでProLogが使われていたのを知りましたが、それ以前でどのようなプログラミング言語が使われていたのか誰か知りませんか？」という質問を投稿します。
それに対して「ソース出せ」というツッコミがつくと、投稿者は公開されたCIAの調査資料にProLogが使われていたと記載があったと返信します。
その後の回答で最も支持されているのはロシア語の書籍「 First computers for space applications (Герман Носкин, Первые БЦВМ космического применения)」を持っている方からの回答です。著者自身が宇宙開発に参加していたという事もありかなり貴重な情報が紹介されています。
- 70年代まではデジタルコンピュータは使われていなかった
- 最初に使われたコンピュータはSalut-4でソ連で利用されていたコンピュータと互換性がありPL-1とFortranが使えた
- またブランでは3つの言語が使われていたとの言及がウェブサイトにあり、オンボード機器には PROL2、地上のテストにはDipol 、Laks がモデリングに使われた。
- ブランプログラムが終わる頃、3つの言語はDrakonに統合された。
なんだか身近でない言葉がバンバン出てくるすごい話です。どうやら最終的に長く使われたDrakonも国際的に認知されておらず、情報がWikipediaにも無い状態との事です。インターネットが発達した現代でもアクセスできる情報はやはり英語のものがせいぜいで、それ以外の言語で書かれた知識は埋もれてしまっている事を考えさせれる出来事です。
GitHubがOctocatのアニメーションを制作中
少し前のGitHub公式ブログにTony Jaramillo氏がGitHubに加入したという興味深い記事を再発見しました。GitHubの公式ブログではメンバーの加入の際には記事が投稿されるのが恒例になっていますが、今回のTony氏はユニークです。なんと彼はアニメーターなんです。この記事でも彼の今後の活動についてはOctocatのアニメーションを制作するとだけ書かれています。そして元記事のリンクをクリックした人はお気づきかと思いますが、この元記事の最初にある画像もアニメーションGIFなんですよ！（動くOctocatは必見）
Tony氏のウェブサイトにもさまざまなアニメーション作品が掲載されています。GitHubのサイトではこれまでもマウス操作に合わせて動いていた部分もありましたが、今後はより可愛らしく動きまわるOctocatが見れるようになるのでしょうか。公開が楽しみですね。
via:https://github.com/blog/1131-tony-jaramillo-is-a-githubber
参加費10万円、説明は一切無しのイベントチケットが好評発売中
参加費用999ユーロ(約10万円)、2泊3日、日時以外の詳細は一切不明のイベントのチケットをあなたなら買いますか？このFunConfは今年で3回目を迎える異色のカンファレンスです。割り切った作りのサイトは実際に見てもらうのが一番として、このカンファレンスの特徴は会場がユニークな事です。第一回は走行中の貸切バス、第二回は城とかなりぶっ飛んでいます。このカンファレンスのクチコミはなかなか温度が高く、筆者も海外のゲストからこのカンファレンスをお勧めされた事が3回ほどあります。
たとえばこのAndrei Zmievski氏はDiggやYahooといったサービスのエンジニアだった事があり、なおかつPHPのテンプレートエンジン、Smartyの元作者であり、お蔵入りになったPHP6の中心人物でした。(しかもTwitterのアカウントが”a”の一文字)また運営しているPaul & EamoのEamon氏はPHPのPaaSサービスのOrchestra.ioのファウンダーでCoderDojoの発起人のJames Whelton氏の友人です。
他の参加者やスピーカーも豪華な顔ぶれである事が予想されますが、真相は参加しないとわからないようです。。。気になりますね。
追記
あまりに謎が多いとの反響があったので画像を検索してみるとやはりすごいです。
2010年のFunConf (バスの車内で開催)
2011年のFunConf (城とデロリアン)
Appceleratorの開発者が語るTitaniumとPhoneGapの比較
iOSとAndroidのクロスプラットフォームなアプリケーションをする際に使われるTitanium MobileとPhone GapをTitaniumの開発元、Appceleratorの開発者Kevin Whinnery氏が比較した記事が話題になっていました。
Kevin氏は「上空1万フィートから見ればTitaniumとPhone Gapは似ているように見える。どちらもクロスプラットフォームでJavaScriptとWebの技術を要求し、オープンソースライセンスを採用している。しかし似ている所はそれぐらいしかない。どちらも思想や問題を達成する為のアプローチは異なっている」という書き出しで二つのプラットフォームがかなり異なっている事を強調した上でいくつかのポイントを比較しています。
Phone Gapについて
- 実現する事
HTMLベースのWebアプリケーションをネイティブアプリとして配布、インストールできるようにする。 - ワークフロー
HTML,CSS,JavaScriptを静的なサイトのようにローカルで編集する。ネイティブのツールセットは不要。 - 動作原理
各プラットフォームのWebブラウザコンポーネント(Web View)などを立ち上げ、作成されたHTMLを読み込んで表示する。 - 拡張方法
JavaScriptから呼び出されるインタフェースを作成し、そこから呼び出されるネイティブコードを作成して登録する。(How to Create a PhoneGap Plugin for iOS) - 強み
Web Viewをサポートしていればどんな環境でも動作する。プラグインによる拡張がシンプル。 - 弱み
UIのクオリティがWeb Viewのクオリティに依存する。特にAndroidでは制限がある。ネイティブのUIを使った拡張ができない。
Titaniumについて
- 実現する事
クロスプラットフォームなJavaScriptランタイムとモバイル向けのAPIを提供する。 - ワークフロー
各プラットフォームのツールをセットアップした後にTitaniumのツールのみ使う。このツールをIDEから利用する事もできる。 - 動作原理
ネイティブコード上でJavaScriptの実行環境（iOSではJavaScriptCore、AndroidではデフォルトのV8またはRhino）が動作し、JavaScriptのソースコードを実行時に解釈して動作する。 - 拡張方法
UIを含む視覚的なコンポーネントも拡張できる。ネイティブ側、JavaScript側の双方から呼び出し可能なプロキシオブジェクトを実装し、ブリッジとして利用できる。 - 強み
高レベルなAPIが提供されていて、さまざまなネイティブの機能を利用できる。 - 弱み
新たな環境に対応させるのが難しく、iOS、Android、Webにしか対応していない。
元の記事はかなりの長文ですが、Phone Gapが本来はWebブラウザから利用できない機能（カメラやセンサーなど）を使えるようにするという機能はWebブラウザの機能そのものが強化されると意味がないものになる可能性があるなど、若干Titanium寄りに見える部分があります。また双方のプラットフォームの思想的な違いやビジネスモデルについても言及している部分がある点もユニークな内容です。
それぞれのプラットフォームの動作原理の解説は興味深い内容ですので読んでみて頂ければと思います。
さてみなさんはどちらのプラットフォームを使いますか？
訂正
Kevin氏を元開発者と表記しておりましたが、現在もAppceleratorの開発者であるとのご指摘を頂きました。訂正させて頂きます。誤訳により誤解を招いてしまい申し訳ありませんでした。
via:http://kevinwhinnery.com/post/22764624253/comparing-titanium-and-phonegap
アプリはWebサイトを殺すのか？
A-Listers的にはかなりプッシュしているCoding Horrorに”Will Apps Kill Websites?”と題されたスマートフォン・タブレットのアプリとWebサイトの今後について考察した記事が投稿されていました。記事はeBayが多くに人に使われていて、筆者にとっても有用でさまざまな出来事が起きている事を前置きした上で、「eBayのWebサイトが常に使いづらく閲覧しづらいままだった」事は不変であると述べています。その上でアプリ版eBayとWebサイト版のeBayの比較を行なっています。
タブレット版eBay
筆者によると「eBayのアプリには良くない点もたくさんあるが、Webサイトはさらに最悪」と補足した上でeBayの超熟練ユーザでない限りはWebサイト版を避けるべきであると評しています。教訓として「制約を受け入れる事(embrace constraints)」を挙げています。限定されたUIや限られたスクリーンサイズはMacやPCがパワフルになって失われた強みであるとしています。eBayはWebによくある風土病(endemic on the web)として1999年から機能が増大しつづけ、Webブラウザ上でほとんどなんでもできるようになった結果、ユーザにとっては使いづらいものになってしまっています。
筆者はスケールアップできるシンプルなデザインをせよ、スケールダウンが必要な複雑なものは避けろとしてモバイルファーストのアプローチを取り、どのデバイスでも一貫性を保つように考慮することでシンプルであり続ける事にフォーカスできると説いています。
その上で優れたタブレットなどが存在する今、それでもWebサイトがまだ必要なのかどうかという事を考えるべく、アプリとWebサイトそれぞれが優れている点をリストにして列挙しています。
アプリがWebサイトよりも優れている理由
- より高速
HTMLやCSSといったオーバーヘッドが無く、ユーザの操作に応じてネイティブUIを高速に表示できる - シンプルなネイティブUIを使っている
- 画面を有効に使っている
画面のサイズのバリエーションがPCよりも少ない為、デザインはそれに合わせるさせすれば良い。 - 外出先やオフラインでも使える
Webサイトがアプリより優れている理由
- どのようなデバイスでもブラウザがあれば動く
- インストールの必要が無い
アプリを探してインストールしたとしても大量のアプリをポケモンのように管理しなければならない。 - アップデートの必要が無い
Webサイトは常に最新 - 共通のエクスペリエンスを提供できる
さまざまな種類のUIがあればユーザも提供者側にも負担になる。
筆者はどちらが明確な勝者とは言えず、アプリは常にWebサイトに依存している点に触れた上でアプリに殺されてしまうWebサイトはよほどひどいWebサイトに限られるだろうと結んでいます。元の記事ではここで取り上げていないような点にも触れており、外部記事へのリンクなどもあって気になる方は一読をおすすめします。
via:http://www.codinghorror.com/blog/2012/04/will-apps-kill-websites.html
GitHub直伝 プルリクエスト活用の3つのコツ
GitHubの特に重要な機能である「プルリクエスト」の活用方法についてGitHub社内でのノウハウが公式ブログの記事になっていました。GitHubが今回更新をしたAboutページの開発でも2ヶ月の間に10人のメンバーが130のコミットと91のコメントのやりとりがブランチ上で行われていました。
GitHubberによる講演などでもプリリクエストが重要な機能であると強調されているようです。
記事によるとプルリクエストは新しいアイデアについてのディスカッションを生み、協力してくれる人を見つける為のとても良い方法との事で活用するコツとして以下の3つの点を紹介しています。
- プルリクエストはなるべく早く起こす
プルリクエストは機能についての意見交換をする良いきっかけになります。コードの修正が終わっていなくてもなるべく早くプルリクエストをする事で、最後にまとめてフィードバックをするのではなく発展的にコメントする事ができます。 - プルリクエストはブランチからブランチで
GitHubでは誰もgithub/githubのフォークを持っていません。同じレポジトリのブランチ同士でプルリクエストを行なっています。 - プルリクエストはマージされなくてもよい
プルリクエストは簡単に起こして、フィードバックを得たりブランチ上の進捗を追跡できる手段です。もしアイデアの中に良くない部分があればマージせずにプルリクエストを閉じればよいです。GitHubでもいつもそうしています。
GitHubを仕事に活用し、業務の中でプルリクエストを活用する人も増えてきていると思いますが「フォークを作らない事」や「コード修正が終わる前のプルリクエスト」などは目新しいアイデアと言えるかもしれません。ブランチの管理などはみなさんも試行錯誤していると思いますが覚えておいて損はないTIPSと言えそうです。
記事中でも言及されているようにGitHubのメンバーが講演した際のスライドにもコードレビューをプルリクエストで行う方法について解説がありますのであわせてどうぞ。
How GitHub Uses GitHub to Build GitHub // Speaker Deck
via:https://github.com/blog/1124-how-we-use-pull-requests-to-build-github
あなたのfacebookのパスワードは実は3つあります
見出しと画像のとおりですが、我々のfacebookのパスワードは実は3つ存在しているという記事がHackerNewsで話題になっていました。実際に試してみるとfacebookのパスワードはいくつかのバリエーションを正しいパスワードとして受け付けています。
- 自分が決めたままのパスワード
- 自分が決めたパスワードの大文字を小文字に、小文字を大文字に入れ替えたパスワード
- パスワードの1文字目が小文字だった場合はそれを大文字にしたパスワード
理由はみなさんも推測のとおり、CAPSロックが意図せずに入ってしまっているケースやスマートフォンなどで最初の1文字目が自動的に大文字になって入力される場合を許容する為の挙動だと思われます。このような仕様については2011年9月のZDNetの記事でも言及されており、知っている人にとっては既知の情報かもしれません。
皆さんのサービスではこういったパスワード入力間違いを許容するような仕様を実は持っていますか？また他にもこういった挙動をするサービスをご存知であればコメントやツイートでお知らせください。
via:Your Facebook Account has Three Passwords
IRCをまだ使っていますか？
インターネットユーザやハッカーの為のチャットツールとして長年親しまれてきたIRCのユーザ数が減少してきているという記事がRoyal Pingdomに掲載されていました。2003年と比較して実に60%も指標が減少し、多くのユーザは他のさまざまなソーシャルメディアなどに流入していると考えられます。
記事ではIRCの作者であるフィンランド人で現在はグーグルに努めているJarkko Oikarinen氏へのインタビューも行われています。彼は企業がユーザーのプロフィールなどを自身のサービスの内側に留めるようになった流れなどについて指摘した上でこの状況を変えるような開発者の出現を期待する旨のコメントをしています。
“It does not necessarily require a large team to make significant progress. Just one person can make a huge difference,” Oikarinen says.
“大きな進歩を生むのは大きなチームとは限らない。たった1人の個人でも大きな変化を起こすことが出来る”
3Dバーチャルワールドやマルチメディアなどのなんらかの大きな変化をIRCにもたらす開発者の出現を彼は期待しているようです。
世界最初のIRCサーバ
IRCの利用のシーン自体は小さくなっていますが、IRCがすぐに無くなってしまうとは考えれない(there’s no reason to think that IRC will disappear anytime soon)ともあり、全体が減少している中で順調にユーザが増えているfreenodeの状況なども示されています。元記事にはIRCノードの運営者の意見(DOS攻撃の問題やwarez文化、ソーシャルメディア)が挙げられています。今後、IRCがどういう技術になっていくのかを考えてみるのも面白いかもしれません。
via:http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-irc/
A-Listers 