Posts Tagged ‘プログラミング’
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/
主に開発に使うマシンは？
Hacker News内の質問、アンケートコーナーで挙がった質問が興味深いです。「カンファレンスに行ったらみんなMacだったんだけど、これって特別なことなの？」という僕らもよく抱く疑問です。なおここでは「80%以上の開発時間に使うマシンで動画を見るとかメール送受信やネットサーフィンをするとかいうのは含めない」という前提条件です。
現在の集計結果は下記の通り。
- Mac Desktop 35 points
- Mac Laptop 192 points
- Windows Desktop 49 points
- Windows Laptop 36 points
- Linux Desktop 67 points
- Linux Laptop 77 points
- Other UNIX (comment below) 6 points
- Other not listed here (comment below) 2 points
(Hacker Newsを見る人の中では)圧倒的にMacですね。実際クライアントがWindowsでもけっきょくはリモートのLinux上でemacsなんてのはWindowsに数えないでしょうし。プライベートと会社がというのも80%以上の実際の開発作業（コーディングとテスト）が行われているマシンと考えて区分するのでしょう。
ということで開発者にはMacかLinuxを与えるというのが常識になってくれるとうれしいですね。
同じ質問をこの記事にもつけるのでぜひみなさん投票してください。
via:http://news.ycombinator.com/item?id=2731321
ザッカーバーグのプログラミングの腕前
Google+上のザッカーバーグのプロフィールページ（真偽不明）に引き続き、プログラミングコンテストサイトのTop Coder上のザッカーバーグのプロフィールページが発掘されて話題になっていました。これを見る限りアルゴリズム系の課題に39回挑戦し、現在のレーティングが1044という事で比較的しっかりしたアクティビティがあるようです。
このサイト上のコンテストでアルゴリズム系の課題に取り組んでみると、自分の腕前とザッカーバーグさん（どこのザッカーバーグさんかはやはり真偽不明）を比較する事ができますね。
via:http://www.topcoder.com/tc?module=MemberProfile&cr=276132
githubがコード解析に使っているライブラリを公開
またまたgithubから新しいプロダクトがアナウンスされました。githubではリポジトリ内のファイルの種類を判別したり、コードハイライトを行うといった機能がありますがこれを途方もない種類の言語に対して実現しています。そして今回公開されたのはまさにそういったコードの検出やハイライティングといった部分のライブラリです。
ちょっと使いどころがすぐに思いつくようなライブラリでもないですが、Rubyで実装された実践的なコードの例として楽しむのも良さそうです。
ORMがアンチパターンである11の理由
サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。
ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない
このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。
- 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。
- 確証があり繰り返されている別の解決方法がある。
当初は良さそうに見えたORMがいざ使ってみると問題が明らかになり、しかもその時には切り替えるわけにもいかなくなるというのが彼の主張です。彼による皮肉がたっぷりの論説の最後に付いていたまとめリストは下記のとおり。
- ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
- 効率はどんなプロジェクトでも最初の頃は十分。
- 不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、抽象化は破綻し、開発者はSQLを使わなければならなくなる。
- ORMの抽象化はほぼ100％のプロジェクトで破綻する。
- オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
- 不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
- リレーションを保存する代わりにORMを全てに適用する場合、設計をよく考える必要がある。
- データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。
- データが元々リレーショナルならリレーショナルデータベースに対するオーバーヘッドになるだけ。
- リレーショナルなクエリはモデルレイヤーに隠蔽する。ただしAPIの設計は汎用化の誘惑に打ち勝ってアプリケーションに必要なデータを返すようにする。
- オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。
ORMを使った事がある人にとっては心当たりがありまくりな主張ではないでしょうか。意外と長文なんですが原文を読んでもらう方がORMが良さそうにみえて問題が起こり、そしてその解決方法などのより正確な主張がわかります。また元の記事には現時点で47のコメントが付いており盛り上がっています。
さて、みなさんはORMを次のプロジェクトでも使いますか？
via:http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern
関連:
データベースの間違った使い方10項目 « A-Listers
いきあたりばったりのアーキテクチャと教訓 － Publickey
あなたのソフトウェアプロジェクトが破滅する10のサイン
週末はやはりリストものという事で、古典的なリストを紹介します。このリストはマイクロソフトでもいくつものプロジェクトを手がけていたDare Obasanjo氏による物です。マイクロソフト繋がりなのかジョエルスポルスキー氏の著作でも見られるような考え方に近いですが、かなり普遍的に当てはまるリストになっています。
- 最初から機能を詰め込みすぎ
- 不確かな技術に依存している
- 稼ぎ頭だったり政治的に強い別な社内プロジェクトと競合している
- 人手が足りない
- 複雑な問題を複雑な方法で解いている
- スケジュールの遅れを報告できない
- スコープが拡大している
- セカンドシステムシンドローム
- プロダクトがエンドユーザーに使われる見込みが無い
- 解決できるかわからない問題がある
このサインを感じ取った所で、実際にエンジニアが打てる対策はあまり無いのが難しいところです。いくつかのサインがあるくらいならまだなんとかなるのでしょうが、大量に当てはまっている状況というのは、、、なんだか身に覚えがあるような・・・。2007年にブログに投稿されたリストですがこのリストも時代を超えて残って行きそうな気配がしますね。
via:http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a76eab63-70f0-48b4-8b75-66c366a651cd
良いデベロッパになる為の13のTIPS
読みやすいTIPSのリストが話題になるのは洋の東西を問わず見られる現象です。ハンガリーのブタペストのデベロッパ、Csaba Okronaさんが書いた記事が話題になっていました。さっそくその項目を見てみましょう。
- レッスン1 全体像を理解せよ
コーディング作業だけに囚われず、ビジネスやプロジェクト等の面からも理解する。 - レッスン2 自分の時間を確保せよ
残業や早出は結局バグを招く。スピードは良いデザインと正しいアーキテクチャから生まれる。 - レッスン3 間違った時は考え方を変えるチャンス
既存の技術で問題が遅くなってきたような場合は新しい技術へ移行する。ただし既存の技術がうまく行っている場合にただトレンドを追ったりはしない - レッスン4 脳を鍛え続けろ
日々のタスク以外の鍛錬を行え。コードゴルフなどはよい例 - レッスン5 人生を大事にする
特に重要。残業が続けば燃え尽きるのも早い。 - レッスン6 集中
マルチタスクを避け、１つの事に集中する。 - レッスン7 自己を貫け
一度や二度の失敗でくじけずに失敗から学ぶ。ずっとうまく行かないならば別の方法を考える機会（レッスン3） - レッスン8 計測せよ
推測だけで方法を決めずにベンチマークなどをとって判断する。人間の感覚は当てにならない - レッスン9 コードのパフォーマンスだけに拘らない
550ミリ秒を500ミリ秒に短縮してもユーザーには分からない - レッスン10 機能を落とす事も考える
どうしても期日に間に合わない場合は必要性が低い部分を切り落として後に回す事もできる。実際この業界では良くある事だ。 - レッスン11 コーディングスタンダードを守れ
たとえチームで開発をしてなくてもコードに一貫性を持たせろ - レッスン12 テストせよ
テストも仕事の一部。テスト用の環境やツールを使えるようにしておく - レッスン13 ユーザビリティ
ユーザーインターフェースを開発する時は常にユーザーの利便性を頭に置く。
Csabaさんの10年の経験の中で感じた経験則だそうですが、とても自然なリストですね。今年現場に入ったような新人のエンジニアにあなたが伝えたいと思う事とかなり共通する部分もあるのでは？遠くハンガリーの地でもこんな事を考えている人(ちなみに漫画好きで仏教徒らしい)が居ると思うのも面白いなと思います。あなたが自分の経験から伝えたい事はなんですか？
5行のコードに7倍の免責事項
OracleのサイトにアップされているHello Wolrdの実装がネタにされていました。Hello Worldですからプログラムは５行しかないのですが、全体像はどうなっているか。（お察しください）
追記:さらに別の指摘がありました
via:http://download.oracle.com/javase/tutorial/getStarted/application/examples/HelloWorldApp.java
SOAPは死なずエンタープライズ界のゾンビ化
外部のシステムや内部のシステムを繋ぐ際に利用される事が多いのがAPIです。そのインターフェースにどういったフォーマットが使われているかについて気になる考え提起した記事が話題になっていました。きっかけはglueconで行われたAPIのカタログサイト、ProgrammableWebのJohn Musser氏によるセッション内での言及です。
ProgrammableWebの情報を元に観測したと思われる傾向は下記のようだったようです。
- 73%のAPIがRESTを使用
- 17%のAPIがSOAPを使用
- 以降、JavaScript XML−RPCが続く
APIのインターフェースを決める際に迷った際にこういった客観的な数字は役に立ちそうです。
via:http://www.readwriteweb.com/enterprise/2011/05/soap-is-not-dead—its-undead.php
Rosetta Code – 各プログラミング言語の実装例集
プログラマなら１つでも多くの言語をマスターしたいと思いますよね？同一の文章を3種類の文字で刻んだロゼッタストーンにあやかったプログラミング言語の実装集が話題になっていました。自分で知っている言語を元に読めば各言語の特徴がわかります。またWikiで運用されているのでまだ実装がない部分に実装例を寄付する事もできます。
現在、登録されている課題は498種類。定番のFizzBuzzなら107の言語で実装されています。
Ruby
BASIC
都度、検索するよりもまとめてみれる事であまり触らない言語を読む時などに役に立つかもしれませんね。RubyとPython、Cあたりは大抵実装例がありそうな気がします。
A-Listers 