Posts Tagged ‘論争’
新時代に突入したPHPのフレームワーク戦争
2012年9月、PHPのフレームワーク戦争は新たな局面に突入した事が明確になってきました。PHPフレームワーク、Symfonyプロジェクトの創始者であるFabien Potencier氏のブログ記事がPHPフレームワーク界で話題です。
オブジェクト指向を本格的にサポートしたPHP5とRailsが与えたインスピレーションから始まった2005年頃からはsymfonyやZend Framework、CakePHP、CodeIgnitierなどのフレームワークを生み出しました。その後、名前空間をサポートしたPHP5.3がリリースされるとコードの抜本的な構造などを見なおした次世代フレームワークが次々に登場します。冒頭のFabien氏の記事では2012年9月6日にZendFramework 2.0とSymfony2.1が奇しくも同日にリリースされました。Fabien氏はZendFrameworkのリリースを祝福した上で、「何故、他のXというフレームワークよりSymfonyを選ぶのか？」という質問の回答としてブログの記事を投稿しています。
記事によると下記のような点をSymfonyを選ぶ理由として挙げています。
- Symfonyはフレームワークではなく、プロジェクトであり用途に応じて様々なコンポーネントをそのままつかったり、Sliexとして使ったり、フルスタックなフレームワークとして使う事もできる。
- 大きな採用事例があること。(BBC NBC TEDなど)
- 大きなコミュニティがあり、昨年だけでも550人以上が貢献している。
- 車輪の再発明をしない事を推奨しておりさまざまなコンポーネントが開発、公開されている
この記事には非常に多くのコメントが寄せられ、このようなドキュメントを各フレームワークが記述したらいいのではなどという声も上がり始めました。そしてCakePHPの開発チームの一人であるJose Diaz-Gonzalez氏が正に返信の記事である「Why to Actually Choose CakePHP?(なぜ実際はCakePHPを選ぶのか？)」という記事を公開します。こちらの記事ではジョークを交えて下記のような点をCakePHPを選ぶ理由として挙げています。
- 熱心な開発者
- 継続的なリリース
- モデルレイヤー
配列がPHPでデータを扱う最良の方法であるから。Cake3からはモデルをオブジェクトとして扱う事もできるようになるが。- Symfonyじゃないこと
- パトリオットエールハウス
このバーで一緒にエールを一杯飲んだ相手しか信用しないので
また前後してZendFrameworkの開発チームのEvan氏は「Why ZendFramework」という記事を公開します。こちらの記事では直接Fabien氏の記事を引用しつつZendFrameworkを選ぶ理由として下記のような点を挙げています。
- ZendFrameworkはずっとコンポーネント志向だった
- ZendFrameworkも大企業につかれている。(BBC, Cisco, Discovery, Panasonic, Offers.com等 同様にオープンソースプロジェクトでも使われている。: Magento, TomatoCMS, pimcore, Centurion, Digitalus CMS, Webfolio, PHProjekt, Concrete5)
- コミュニティの活発さ、車輪の再発明をしない事などは同じようにZendFrameworkにも当てはまる
全てを読んでみると、説得力のあるSymfony,場外戦術を仕掛けるCakePHP、俺も俺もといった感じのZendFrameworkという感じです。いずれの主張もRails直後のような機能ではなく、汎用性やコミュニティの活発さなどに言及している点が印象的です。技術的にはPSR-0やPSR-1といったフレームワーク間で設計や規約が共有化され、コンポーネント化や相互の再利用がしやすくなっている点もあり、コミュニティこそがフレームワークの特性になってきているのかもしれません。
喜びの多いプログラミング言語は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にも無い状態との事です。インターネットが発達した現代でもアクセスできる情報はやはり英語のものがせいぜいで、それ以外の言語で書かれた知識は埋もれてしまっている事を考えさせれる出来事です。
アプリは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
もしもプログラミング言語が車か船だったら
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
ミーティング：仕事が死ぬ場所
寂しい気分ですか？自分で仕事をするのが嫌になりましたか？自分で決断をするのが嫌ですか？
それならミーティングを開催しましょう！
皮肉なネタ画像と共にミーティングについての5原則がCoding Horrorに掲載されていました。
- 1時間以上のミーティングをしたものは死刑
ミーティングが1時間以内に収まらない場合は根本的な過ちがある。まずはそれを正すべき。 - 全てのミーティングは明確なミッションステートメントが必要
ミーティングの目的を簡潔な短文で定義できますか？ - ミーティング前に宿題を済ませる
ミーティングのアジェンダを明確にしたら参加者には事前に何を話すべきかを伝えます。ミーティングルームに入る前に宿題を済ませて準備ができている事が1時間以内にミーティングを終わらせる秘訣です。 - 任意参加にせよ
必須参加は甘えです。ミーティングの参加者はそこに居たいと思っているべきです。 - ミーティングの最後にやることをまとめる
なにもやることがないとすれば、そのミーティングは存在している理由がない。
どうもミーティングでアジェンダと資料を順番に読み上げるような光景を目にすることが多い気がするので、忘れがちな原則ですね。また元記事では途中にgithubでのミーティングについての一節が引用されています。
githubではミーティングはしません。それどころか勤務時間や勤務日もなく、休暇や病欠も記録していません。マネージャーも組織表もありません。ドレスコードや総務管理部もありません。
githubはミーティングが無いどころの騒ぎではありませんが、やはり無駄な時間を費やしたと感じたのであればそこには何か問題があるのかもしれませんね。
via:http://www.codinghorror.com/blog/2012/02/meetings-where-work-goes-to-die.html
iPhoneのホームボタンは難しすぎる？
Chart by Andrew Durdin
「iPhoneはボタンが1つしかないからシンプルで使いやすい」という風に感じた事はありますか？プログラミング系のブログであるCoding HorrorにてThe One Button Mystique（1ボタンの神秘）と題された記事が公開されていました。Kindle Fireは「少なくとも１つくらいボタンがあるべきだった」といいつつも、1ボタンハードウェアの問題点について提起されています。
上記のチャートはiPhoneのホームボタンの挙動を表したチャートですが、様々な場面ごとにクリック、ダブルクリック、トリプルクリック、クリックアンドホールド、長押し後にクリックの5通りもの操作があることが図になっています。
同じようにボタンとランプが1つだけのマイクをペアリングする時の操作のわかりにくさなどに触れつつ、「アップルはシンプルで明快なデザインをする一方で、時たまやり過ぎる」と評しています。※例として最初のMacにはカーソルキーがなかった事が挙げられています。
コメント欄では、「いやいや、iPhoneにはボタンは5個（音量など）あるでしょ」とか「クリック、ダブルクリック、トリプルクリック、クリックアンドホールドってモールス信号みたいだ」などのツッコミがあって盛り上がっています。
ボタンが1個のiphone、本当に使いやすいと思いますか？
via: http://www.codinghorror.com/blog/2012/02/the-one-button-mystique.html
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
MongoDBは新たなMySQLなのか？
利用が急速に広がっているMongoDBですが、「MongoDBはMySQLをリプレースしていくのか」という話題が複数のブログで語られています。Joseph Ritcheyさんの記事では「全てのウェブアプリケーションがMongoDBにするわけではないだろう」と言いつつも、スケーリングの容易さやOracleがMySQLを保有したリスクなどに触れつつMongoDBをプッシュしています。
この記事に呼応して書かれたのがRedmonkのStephen O’Gradyさんの記事では「MongoDBの役割が10年前のMySQLに似ている」という印象を述べています。かつてはエンタープライズで必要とされていたストアドプロシージャーやトリガーなどの機能を欠いていたMySQLですが、最もポピュラーなRDMSになりました。これと同じような事がMongoDBでも起こるのではないかという事ですね。
元記事には他にもいくつかの観点と図表があります。10年後の状況を予測するにあたって、10年前と現在の違いを考えるというのは良いアプローチですね。
via:http://redmonk.com/sogrady/2011/07/06/mongodb-is-the-new-mysql/
Pastebinが悪用されているという話
古株のコードスニペット共有サイト、「Pastebinが悪用されている」という気になる話を取り上げたブログの記事が話題になっていました。なんでも公開されているコードをクリックしたらコードではなくコンピューターが
クラックされたようなログが見えたとの事。
見つかったログというのは下記のようなものだったそうです。（実際のログの例が元記事にあります。）
- WiFiクラッキング
- キーロガー
- 会話のログ
- リッピングされた音楽
- アダルトサイトのアクセス情報
これらのログはPastebinにアクセスすると危険という事ではなく、なんらかのマルウェアが情報の送信先にPastebinを使っているという事のようですね。コメントもかなりついていましたが、「元からこんなもんだよ」というような感じでどうやら常識のようです。
A-Listers 