Posts Tagged ‘考え方’
良い仕事は仕事を愛することから始まる
Engine YardのアプリケーションエンジニアのKevin Hollerさんが自身のブログに投稿した記事がHacker Newsで話題になっていました。記事では彼が14歳の時に始めた地元のパブでのアルバイトを通じて学んだ仕事への姿勢について触れています。バイトを始めた当初は平凡な作業の繰り返しの仕事を稼いだお金で何を買うかを考えたり、時計に注意してシフトが終わったらすぐに帰るという姿勢で乗り切っていたようです。一年後には仕事も覚え、仕事に行く事が一番大変という状況だったようです。そんな中で彼が昼休みに見かけたバーテンダーの仕事ぶりが彼の意識を変えます。
ある日曜の午後、店は殆ど空っぽで私はランチを食べながらバーテンダー達と話していた。バーテンダのうちの1人はバーを整頓するのに忙しそうで、他のバーテンダーは普通の作業をしたりすることが無さそうだった。私は何故彼が整頓に忙しいのかを尋ねると彼はこう答えた。「このドリンクは今年は人気なので前に並べないといけないんだ。」このバーテンダーの他のバーテンダーとの違いは店を良くしようとしている事だ。そしてそれが同時にこのバーを彼が楽しんで働ける場所にしている。他のバーテンダー達は言われた事だけやって他の事はしない。もちろん彼だって私と同じくお金の為に働いている。
この日以降、Kevinさんは仕事への姿勢を変えて平凡な仕事を楽しいものにするべくプライドを持って取り組むようになったそうです。大学に入りプログラマーとしての仕事を始めるまで続けていたアルバイトを通じて彼は立派なバーテンダーになりこの経験を下記のようにまとめています。
私は雇用主の為に働いているというよりも、自分自身の為に働いていた。その姿勢が自分自身をより幸福な人間に変え、それが雇用主の為にも良い事だった。
この投稿に対してはHacker Newsの住民も多いに反応しており同様の記事を書いたことがある方もいたようです。否定的な意見では「1000ユーロ以上稼げる仕事をしているからそんなことが言えるんだ」というような者もあり英語の議論ですが内容が追いやすいですね。
この春から新しい生活になり戸惑っている方や仕事が退屈だと感じている方にとって何かヒントになるかもしれません。あなたは現在の自分の仕事を愛せていますか？
via:http://www.kevinholler.com/love-what-you-do-not-what-you-earn/
API設計に関する10のワーストプラクティス
過半数の開発者が平均で3つ以上のAPIのインテグレーションを実装していると言われている昨今、「使い辛い設計のAPI」を実装するのは開発者にとっては頭の痛い問題ではないでしょうか？ Programable Web上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まったようです。この記事によると悪いAPIに見られるプラクティスは下記のようなものだそうです。
- 貧弱なエラーハンドリング
- HTTPのルールを無視したREST API
- 裏に潜んだ生のデータモデルの露出
- セキュリティの複雑さ
- ドキュメント化されていない予期せぬリリース
- 貧弱なデベロッパエクスペリエンス
- MVCフレームワークが良いAPIにしてくれるという思い込み
- 開発すれば使ってもらえると見なすこと
- 不十分なサポート
- 貧弱なドキュメンテーション
APIを利用するだけでなく、APIを提供する場合に上記のようなポイントを気に留めておくと役に立ちそうです。
via:http://blog.programmableweb.com/2012/08/03/top-10-api-worst-practices/
新時代に突入した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といったフレームワーク間で設計や規約が共有化され、コンポーネント化や相互の再利用がしやすくなっている点もあり、コミュニティこそがフレームワークの特性になってきているのかもしれません。
Apple というブランドと顔
Apple の成長は目覚ましいものがあります。アナリストの Horace Dediu は Apple の販売員増加について数字と販売戦略を絡めて語っています。
iPhone が発売されてこの５年間で、直営店の数は 172 から 361 に増え、35,852 もの販売員を雇いました。2007年の第一四半期には平均 37人だった各店舗の従業員数も、5 年後の 2012 年の第一四半期には、177 人に増えています。多くの数字がこのエントリには登場しますが、面白いのは、販売員の増加割合は、アップルストアの訪問客の増加割合より多く、また各販売員が顧客と話す時間は増加している、という事です。
私の知る限り、これはテック系としては非常に珍しい。ほとんどのテック企業では、全く正反対の事を模索してきた：煩雑な販売手順とサポートの手間を手順化して、「付加価値付け」を、（自社ではなく）他人である販売業者に任せる、ということ。
This is, as far as I know, a unique relationship for a technology company. If anything, most technology companies have sought the exact opposite: to put others’ faces in front of customers–to break the messy process of sales and support down into pieces to be outsourced to “value adding” resellers.
私は Harvard Business Review に転載されていたエントリ: Why is Apple Hiring So Many Retail Employees?（タイトルがやや釣り気味）を最初に読んで結論がないと思いましたが、ブランド、という観点に注目すると、非常に面白いと思います。販売員も Apple というブランドを構成する一部なんですね。コメント欄で給料の話なども出ています。
via Why is Apple Hiring So Many Retail Employees? via The face and the brand
アプリは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
あなたのfacebookのパスワードは実は3つあります
見出しと画像のとおりですが、我々のfacebookのパスワードは実は3つ存在しているという記事がHackerNewsで話題になっていました。実際に試してみるとfacebookのパスワードはいくつかのバリエーションを正しいパスワードとして受け付けています。
- 自分が決めたままのパスワード
- 自分が決めたパスワードの大文字を小文字に、小文字を大文字に入れ替えたパスワード
- パスワードの1文字目が小文字だった場合はそれを大文字にしたパスワード
理由はみなさんも推測のとおり、CAPSロックが意図せずに入ってしまっているケースやスマートフォンなどで最初の1文字目が自動的に大文字になって入力される場合を許容する為の挙動だと思われます。このような仕様については2011年9月のZDNetの記事でも言及されており、知っている人にとっては既知の情報かもしれません。
皆さんのサービスではこういったパスワード入力間違いを許容するような仕様を実は持っていますか？また他にもこういった挙動をするサービスをご存知であればコメントやツイートでお知らせください。
via:Your Facebook Account has Three Passwords
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
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
起業する10の理由と起業しない10の理由
おそらく野心のあるプログラマーやクリエイターなら起業を考えた事はあるのではないでしょうか？ソーシャルやゲーム関係に関する話題などを取り上げているVentureBeat上に掲載された「起業する10の理由と起業しない10の理由」が話題に挙っていました。書き手は投資銀行に勤めているMegan Lisa Jones氏です。
さて記事内で紹介されている起業する理由としない理由は以下の通り。
起業する10の理由
- 基本的な条件を満たしたアイデアがある
大きく成長している市場で、マネタイズする方法が明らかで、協力するパートナーが居て、長期的なポテンシャルがある。 - あなたが自身の金銭的、業務的なリスクをコントロールする余裕がある。
- あなたが不安定で長時間労働ができる。
- あなたがその市場、製品、サービスに愛情がある。
- あなたにその業界への情熱がある。
- あなたが職を必要としている。（かつ職を探すよりも魅力的）
- あなたが確かなスキルやコネクションを持っている。必要な競合調査などの考えうるリサーチも済んでいる。
- 信頼できる他人にあなたのアイデアを確認してもらっている。
- ビジネスの立ち上げが既に趣味の一環になっている。
- 犠牲を払ってでも、素晴らしい会社を作りたい。
起業しない10の理由
- 良いアイデアはあるが、十分なリサーチをしていない。
- みんながそれで儲けているように見える。
- マーク・ザッカーバーグのようになりたい。それに彼はただの若僧だ。
- すぐに大金を得たい。
- 素晴らしい次の時代のキラーアイデアを見つけたから。(何故、誰もやっていないのだろうか？)
- 職が必要で他にどうしたらいいかわからない。
- 今実行しなければ、キャリアが行き詰まってしまう。
- あなたが自分の上司や業界や配偶者を嫌っている。
- 自由なスケジュールで働きたい。
- 創業者として名声を得たい。
非常に手厳しいリストですが、Meganさんは「スタートアップは決して簡単ではなく、理由やアドバンテージ、リスクを評価した上で何か優れたものを作りましょう」と締めくくっています。スタートアップを評価する側の人の意見なので冷静ですね。
via:http://venturebeat.com/2011/06/08/10-reasons-to-start-a-company-and-10-not-to/
