Posts Tagged ‘プログラミング’
喜びの多いプログラミング言語は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にも無い状態との事です。インターネットが発達した現代でもアクセスできる情報はやはり英語のものがせいぜいで、それ以外の言語で書かれた知識は埋もれてしまっている事を考えさせれる出来事です。
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
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
Codesprints – WEB上で参加できるプログラミングコンテスト
Codesprintsはinterview street上で開催されるコーディングイベントです。出題されるパズルのような問題に対してコードを登録でき、スコアなどがランキングされます。ちょうど昨日はQuoraのスポンサードする5時間のプログラミングコンテストが開催されていました。
ログインするとこんな画面で問題の確認とコードの送信ができます。コードを実際に書かせる面接というのは古くからありますが、今後は選考のもっと早い段階でコーディングの技術を見るということでさらなる実力主義になっていきそうですね。
via:https://www.interviewstreet.com/challenges/
23人のキッズがプログラミングに熱中したCoderDojo
子供にプログラミングの楽しさを伝える場所があったら素晴らしい場所になる。その証拠といってもいいような写真と記事がgithubのブログにアップされていました。githubでは先日紹介した、子供向けのプログラミングイベントCoderDojoという活動に参加しその最初のイベントが先週末に開催され大盛況だったようです。
23人の子供とたくさんの親、12人のメンターで満員の会場。(※そして脅威のMac率)最初の1時間はHTMLについての内容で子供たちはタグがどのように動くのかを学び、自分自身についてのウェブサイトや2匹のセイウチの写真、Minecraft、脅威の数の忍者軍団についてのページを作成しました。
10分間のランチ休憩(短い！)の後はGame Makerを使ったセッションに移り、メンター達もレッスンの間にソフトウェアの動きを理解するという興味深い進行になりました。ゲームの作成は子供たちにとってもお気に入りだったようで、キーを押すとパックマンがその方向に動くというコードを1方向分を教えただけで残りの3方向をメンターの助けをあまり借りずに書くことができたようです。
最終的にはパックマンを操作してゴーストを食べるというゲームが完成しあっという間の2時間のセッションが終了。終了の際には子供たちもメンターも親も口を揃えてあっという間に終わってしまった楽しい時間を惜しんでいたようです。
「メンターの人がたくさんいて、手を上げればすぐに教えてもらえた」という感想が多かったそうで、メンターや親のサポート体制が行き届いていた事が結果に現れたようです。次回のセッションは3月末に開催され、その後は毎週土曜日の開催になる予定のようです。
元の記事のコメント欄も賞賛のコメントや「Scratchを使ったら？」「Octopintを発見」といったコメントがついていて楽しい雰囲気になっています。日本でもScratchを使った子供向けのイベントを企画している方もいるようですので、このCoderDojoの日本版を見れる日も近いかもしれません。
TechCrunchにも載っていました！
CoderDojoがGitHubと提携して子どもたちのプログラミング独学を支援
もしもプログラミング言語が車か船だったら
If programming languages were cars…という記事が話題になっています。Nathan Riceさんが書いたこの画像を交えた記事は国内外で2/12頃から幅広く話題になっています。2008年の4月にも似たような趣旨のIf a programming language was a boat…（もしもプログラミング言語がボートだったら）という記事があったので両方を交えていくつかご紹介します。
Perl
Perlは神託で作られた謎めいた車か、港で力強い牽引をするタグボートでしょう。
Ruby
議論の余地はあるけども巧みでややエレガントな車か、ピカピカして運転するのが楽しい流行のボートでしょう。
Java
Javaはちょっとダサいけど実用的な車か、大量の貨物を運ぶけど操縦の楽しくない貨物船でしょう。
C
Cは40年を経てもなおベストな軍用車両か、パフォーマンスに最適化された原子力潜水艦でしょう、
PHP
PHPはご覧の通りの紫のバットワゴンか竹で出来た筏でしょう。
HTML
HTMLはボートではありません。
記事を書いた方の嗜好が見えるという意味で今後も思い出した頃に続いて欲しいシリーズですね。そして安定してネタにされているPHPさんさすがです。
via:arguably
via:If a programming language was a boat… | CompSci.ca/blog
node.jsの開発リーダーがRyan Dahl氏からIsaac Schlueter氏に
photo by franksvalli
http://news.ycombinator.com/item?id=3530546
飛ぶ鳥を落とす勢いのnode.jsについて創始者のRyan Dahl氏がプロジェクトのゲートキーパーのポジションをIsaac Schlueter氏に移譲するとのアナウンスがHacker Newsで話題になっていました。Ryan氏は優しい独裁者の例としてWikipediaに記載されているほどの強い影響力を持っていましたが、今後はアドバイスに徹しつつ別のプロジェクトを進めるようです。（joyent社にも引き続き在籍するとの事）
コメント欄を見てみるとRuby on RailsのDHHがプロジェクトを引っ張る立場から退いた件と同じなのか？というようなやりとりがされています。DHHは現在でもそれなりにプロジェクトにコミットしているようですが、Ryan氏の今後のプロジェクトの関わりはより限定的になるとの予測のようです。
(黄色がRyan氏、青色がIssac氏の活動状況)
とはいえ直近のアップデートの状況から見るとIssac氏の活躍はコミュニティに知られているようで、この体制の変更は祝福されている様子です。やはり活動状況をウォッチすることでしか実際の状況はわからないものなんですね。
via:http://news.ycombinator.com/item?id=3530546
HABTMリレーションシップは悪であるという論争
Ruby On RailsやCakePHPといったフレームワークのORマッパに存在するHas And Belongs To Manyという機能(通称:HABTM)があります。HABTMとは2つのデータモデルを中間のデータを介して関連させるデータモデルで冒頭の図のようなデータモデルです。筆者がこの省略形の読み方などについてTwitterで話していたところ、興味深いリプライを受け取りました。
俺らはHABTMなんか使わない。なぜならHABTMは悪だからだ。
HABTMについて検索したところ見つかったのがThe evil, unnecessary has_and_belongs_to_manyと題された記事。それによると下記の理由からHABTMを使うべきではないとしています。
- joinテーブルが隠蔽されて過度に魔法的である。また
- たいていの場合、ジョインしたモデルにデータが増える。これをHABTMから追うのは難しい。
- HABTMではなくHMTを使えばなんの問題もない。
- データが大きなってしまってからHMTに移行するのは難しい。
文中に出ているHMTとはHasManyの:throughオプションの事で、HMTを利用すれば中間のモデルを介さずに同様のデータ構造を実現できます。蛇足ですがこれまでは「HABTM」を「はびたむ」と発音していましたが、助言に従って「エイチエービーティーエム」と発音していくことにします。
HABTMはRailsにインスパイアされたCakePHPにも実装されていますが、Railsのコミュニティではすでにバッドプラクティスになっているというギャップが興味深いですね。おそらく他にもこのような例があるのではと思います。
via:http://archive.culann.com/2008/03/the-evil-unnecessary-has_and_belongs_to_many
2011年の定番オープンソースソフトウェアリスト(開発編)
日常の開発に欠かす事の出来ないソフトウェアといったら何が思いかびますか？数多くのソフトウェアの中から昨今のトレンドを元にInfoWorldがセレクトした2011年のオープンソフトウェアランキングが発表されていました。10本のソフトウェアに選ばれたのは下記のソフトウェアです。
- CakePHP
Ruby on Railsの影響を受けたPHP用のフレームワーク。習得の容易さとコミュニティの活発さで人気。 - CoffeeScript
インターフェースやサーバーサイドに欠かす事のできないJavaScriptをより記述しやすくする中間言語 - git
バージョン管理の標準になりつつある分散型SCM - hadoop
大規模分散処理を実現するフレームワーク - Hudson / Jenkins
継続的ビルド(Continuous Integration)を行う為のサーバーソフトウェア - jQuery mobile / Sencha Touch
スマートフォン向けのUIを実装する為のフレームワーク - MongoDB
NoSQLデータベースの中でも抜きん出ているスキーマレスデータベース。 - Node.js
サーバーサイドまでもJavaScriptで記述しスレッドを使わない事で効率的なメモリ利用を実現する。 - Web2py
デポール大学のMassimo Di Pierro氏が開発した使いやすくパワフルなWEBアプリケーションフレームワーク
どのソフトウェアも大きな知名度を持ち、実際の活用を聞く事が増えて来たようなものではないでしょうか。選定の条件はいまひとつ不透明ではありますが、この中で利用した事がないものがあれば一考の価値はありそうです。なおリンク先にはデスクトップアプリケーションやデータセンターソフトウェアなどのランキングも掲載されており、7ZipやEucalyptusなどが選定されています。
