第2回 プロダクトアンチパターン | gihyo.jp
プロダクトの難しさ プロダクトを作るのは本当に難しい。ユーザーが抱える問題を解決しようとしているのだから当然だ。ひょっとしたらあなたは人類史で初めてその問題に取り組んでいるかもしれない。プログラミングも難しいが、「難しさ」の種類が違うように思う。プログラミングの難しさはソースコードを介して他者と共有可能であり、ソースコードは機械語を解するコンピュータとエンジニア向けに書かれたものなのであいまいさが少ない。一方でプロダクトが解こうとする問題はあいまいで多岐にわたる。「タクシーを見つけるのが難しい」から「一緒にお昼ごはんを食べる仲間がいない」まで、1つとして同じものはない。同じ問題を解いている人に出会えることは少ないだろう。 プログラミングにはデザインパターンというものがある。「この形はどこかで見たことあるぞ」「この種のコードはObserverパターンを使えばきれいに依存を分離できる」
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
Google徳生氏「2chに“これ作ったやつ死ね”って書かれて…」 サービス企画者が心得ておくべき、"失敗の哲学"とは？
良いプロダクトは、良い「問い」から生まれる 小野裕史氏（以下、小野）：今までアイデアの持ち上がり方みたいな話だったんですけども、それではどう実行、最終的なプロダクトにしていくかっていうのは、結構ここがさらに次のハードルになっていくと思うんですが。ここの部分をいかに実現していくかという部分においての、ハック面でもいいですし、文化面でも構わないので教えてください。 須藤憲司氏（以下、須藤）：そうですね。佐々木さんのアプローチとすごく似ているというか、我々も、今規模がちっちゃいんで、僕らすごく「問い」を大事にしていて。要は、ある物を作りたい、ある事を解決したいというときに、良い問いだと熱狂できるんですよね。 この問題を解決しようっていうときに、数名が集まって「よし！」ってテンションが上がってディスカッションが活発になってくる。良い問いを、いかに生み出せるかってすごく大事かなと思っていて。 その問
いますぐ採用すべきJavaフレームワークDropWizard(その１) - Qiita
Dropwizardについて3回に渡って説明したいと思います。 今年に入ってリファクタリングなどで有名なマーティン・ファウラーらが所属するthoughtworks社のTechnology RadarのLanguages & frameworksでADOPT（つまりプロジェクトで採用すべきプロダクト）に入りました。 他に入っているものが、Clojure,Scala,Sinatraなので、それらと同じくらい注目すべきプロダクトということになります。 他のプロダクトに比べると日本語の記事が少なく、また、バージョンも上がり変わった部分もあるので記述しました。 なお、Dropwizardは日々進化しているので、この記事の内容もすぐに古くなるかもしれません。 概要 DropWizardは、YammerのWebサービス部分で利用するために作られたフレームワークでした。 自分が思う一番の特徴は、 「1つの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
