タグ

設計に関するcubeonのブックマーク (5)

  • Webサイトの制作スピードを、より向上させる目的で作られたスターターキット・99lime

    結構参考になったので備忘録がてら ご紹介。Webサイトの制作スピードを より向上させるために、汎用的なUI を集めて、マークアップも綺麗な状態 で済むように設計されたスターター キット、というかフレームワークです。 制作スピードを向上させる目的で作られたHTML5フレームワークです。レイアウトだけでなく、汎用的なUIも備わっていて、class名1つ付けるだけでタブやスライドショーを実装出来るようになっています。 そういった仕様にする事で、シンプルで綺麗で可読性の高いソースを保てるように設計されていたりと、結構参考になるスターターキットですよ。フレームワークは自作してるので良い部分を組み込んでみようかなと思いました。 タブやドロップダウン、スライドショーなどを備えているだけでなく、class名1つで実装出来るようになっているので、綺麗なソースを保持する事が出来るようになっています。 いろいろ

    Webサイトの制作スピードを、より向上させる目的で作られたスターターキット・99lime
  • InfoQ: SplkskyとBobおじさんの対決

    ここ数週間、Joel Spolsky(リンク)とRobert C Martin(リンク)(Bobおじさんと呼ばれている)の間で議論が交わされている。そもそもの発端は、Jeff Atwood (リンク)とJoel Spolskyの「38:th Stack Overflow」 (リンク) というポッドキャストで、Joelの「よくユニットテスティングをJoelテストの13番目の項目に加えるべきだと言われるんだけど、それには反対なんだ」という発言だった(Joelテストとは、「Joelテスト: よりよいコードのための12のステップ」のことだ) (リンク)。Joelはこのように説明している(リンク)。 テスト駆動開発について議論されていることですが、すべてはユニットテストすべきだという意見があります……たくさんの人が私に、Joelテストを読んだ後で、「13番目の項目としてユニットテスティングを加えるべ

    InfoQ: SplkskyとBobおじさんの対決
  • 「リファクタリング」の完全読破。その1 - 南極の図書館

    ファウラーの言わずと知れた名著だけど、私は15章構成のうちカタログ部分(第5章〜第12章)を今まで読んでいなかった。 理由としては、やはり古いこと、そんなに難しい内容では無いこと、リファクタリングの思想という意味では理解していたこと。 ホントに古いなので、もういいかなと思っていたんだけど、少し読み直したらやっぱり一度は全部書くべきだった。 リファクタリングの思想と同じくらい、カタログにある各種技術は重要だった。 それに「おすすめのは?」と聞かれたときに、とりあえずこれを挙げることは多くて、そのくせ完読してないのは質が悪いというのもある。 ということで、今回は「はじめに」と「第1章」 はじめに ここでは書の説明と、リファクタリングについての話が少し。 ・リファクタリングはリスクが高いのでやみくもに行ってはいけないこと。 ・手順を守り、体系的に行うこと。 ・具体的には「1度に1ステップず

    「リファクタリング」の完全読破。その1 - 南極の図書館
  • 『iOSヒューマンインターフェイスガイドライン』はUI解説書の枠を越えている :国内・海外情報から見える『企業のWEB活用法』:ITmedia オルタナティブ・ブログ

    中小企業がITを活用して売り上げにつなげるにはどうしたらいいか?WEBマーケティングとWEB戦略コンサル実績350社50業種以上の実績とノウハウで、海外の最先端情報を中心に、噛み砕いてご紹介。 作成者:中山陽平 iOS、実質的にはiPhoneのアプリケーションを作る際に参照してくださいと言う事で配布されている「iOSヒューマンインターフェイスガイドライン(以下iOS_HIG)」 弊社のシステムを真剣にスマートフォン対応にするために読み始めたのですが、この内容が、ただのインターフェイスのガイドラインだけではなく、さらに踏み込んだ内容になっていて驚きました。 Appleのサードパーティアプリに対する姿勢、サードパーティアプリケーションがiPhoneの大きな魅力であるという認識が、このガイドラインからはにじみ出ています。 App開発者以外もぜひ見ておくべき これはぜひ、WEBに関わる方は見て頂き

    『iOSヒューマンインターフェイスガイドライン』はUI解説書の枠を越えている :国内・海外情報から見える『企業のWEB活用法』:ITmedia オルタナティブ・ブログ
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
    cubeon
    cubeon 2010/11/24
    昔も現場のフィードバックなしにやみくもにウォーターフォールで設計したら開発で業務フローがダメになるからよく考えろって人はいたんだがな…
  • 1