タグ

developmentに関するyuuponのブックマーク (105)

  • Cocoa Literature

    (Article count: 4095) Articles about programming in Cocoa are many and in many places. The majority of them are of very high quality. To help out, I made this collected index, searchable by title or by article content. This page is very easy to maintain, so please email me any other articles out there that I've missed. Of course, make sure you also know about Apple's Cocoa docs! Also note that the

    yuupon
    yuupon 2009/11/16
    Cocoaのまとめサイト
  • 第25回 Rackとは何か(3)ミドルウェアのすすめ | gihyo.jp

    前回、前々回の記事では、Rackの生まれた背景、Rackとは何か、実際にRackアプリケーションを作る際に使えるものをご紹介しましたが、もう一つまだ説明していない重要な要素がRackにはあります。今回は、そのミドルウェアという仕組みについてご紹介します。 ミドルウェアとは ミドルウェアとは何かを一言で言うと、「⁠別なアプリケーションをラップして、リクエストやレスポンスを加工したり、処理を切り換えたりするRackアプリケーション」です。 この仕組みがあることで一体何ができるのでしょうか。Webアプリケーションを作っていると、リクエストやレスポンスをアプリケーションに行く前やアプリケーションの処理の後に加工したくなることはよくあります。例えば、条件に応じてURLの書き換えをしたり、エンコーディングの変換をしたり、Cookieの処理をしたり…といったことが日常茶飯事です。こういう処理を、サーバと

    第25回 Rackとは何か(3)ミドルウェアのすすめ | gihyo.jp
  • JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]

    代表中山陽平 ブログ「苦手意識を無くせばWeb活用はうまくいく」弊社では「がんばる中小企業」のWeb活用をサポートしています。今の時代、第3者である、制作会社や代理店におまかせでは勝てません。同じような商品・サービスが溢れる中、選んでもらうためのコンセプトを立て、それを実現するためにネットもリアルも総動員しながら戦う必要があります。 みなさんが世の中に・自社の従業員に実現したい幸せや提供価値を、しっかりと実現していくためには、みなさん自身が主役になり、私達のような専門会社が側面支援するのがベストです。 このブログでは御社が中心となってウェブ活用できるヒントを配信しています。お悩みの方はお気軽に問い合わせフォームからご相談ください。 最新の記事一覧

    JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]
  • はてなブログ | 無料ブログを作成しよう

    うめぇヨーグルトソースでもいかがですか。個人差にもよりますが。もしよろしければ。 お久しぶりです。 最近うんめぇ〜と思ってるヨーグルトソースがあるので、書いていこうと思います。 ヨーグルトとハーブ類をもりもり使うので、そういうのがべられない方にはうんめぇソースではないです。ごめんなさい…。もしよろしければお茶だけも…旦~ 【用意する…

    はてなブログ | 無料ブログを作成しよう
  • 劣化するソフトウエア

    1960 年生まれ,独身フリー・プログラマの生態とは? 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から,現在に至るまでの生活を振り返って,順次公開していく予定です。プログラミングに興味がある人もない人も,フリー・プログラマを目指している人もそうでない人も,“華麗”とはほど遠い,フリー・プログラマの生活をちょっと覗いてみませんか。 ※ 記事は執筆時の情報に基づいており,現在では異なる場合があります。 私たちが顧客に納めるソフトウエアなどの成果物に対しては,瑕疵担保責任というものが課せられている。そのため,あらかじめ合意した期間内に不具合などが見られた場合には無償で対応しなくてはならない。 一般的には,検出されるソフトウエアの不具合というものは時間が経つにつれて少なくなっていくはずであり,それによるリスクも減ってい

    劣化するソフトウエア
    yuupon
    yuupon 2009/10/26
    作り手としての意見。
  • 「RESTful MVC」なアーキテクチャの話

    最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON(XMLでもかまわない)をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく(ずる=来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事)

    「RESTful MVC」なアーキテクチャの話
    yuupon
    yuupon 2009/10/18
    このアーキテクチャは自分も思いついたことがある。
  • CakePHPを使ったMVC設計のベストプラクティス - Sooey

    CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしいべ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ

  • デザイン・パターンとは何か

    先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、(業界に蓄積されたノウハウに立脚した)何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな(場合によってはお互いに矛盾する)要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効

  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

  • Webアプリ開発における「内部APIモデル」 - Tous Les Jours 攻防記

    前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは2つあります。 (1)言語やフレームワークの選択自由度が上がる 現在運

    Webアプリ開発における「内部APIモデル」 - Tous Les Jours 攻防記
  • 脱OpenPNE。 - Lang-8でRuby on Railsを採用 - Tous Les Jours 攻防記

    Rails導入の背景 永らくOpenPNEベースで開発を続けていたLang-8ですが、以下のような課題を抱え続けていました。 生産性が低い → フレームワークの力を借りて生産性を上げたい ページのAjax化に一苦労 → Ajax対応フレームワークでJS周りの開発効率を上げたい デバッグがやりにくい → テスト駆動開発を低コストで導入したい もうそろそろ、何かフレームワークを導入するべきだろうと。 スケールするの? フレームワークを選定する上では、DB周りがスケールするかどうかを最重要視しました。 たとえばRailsのO/RマッパであるActiveRecordは単一DBを前提にしており、スケールさせることが難しいらしい、なんて話を聞きます。メインのDBをActiveRecordで構築しなおすのはいやだなー、と。データ移行の手間もあるし。。。SNSにとってボトルネックは常にDBなので、サイトの

    脱OpenPNE。 - Lang-8でRuby on Railsを採用 - Tous Les Jours 攻防記
  • 全文検索サーバ: これからSolrを始める人のためのApache Solr概要と便利な情報リスト集

    はじめまして。 プロダクト&サービス事業部 リーダーの久保です。 今日は、当社で利用しているOSSの全文検索アプリケーションであるApache Solrについてご紹介したいと思います。 GoogleでSolrを検索しても、日語圏のコンテンツはまだまだ少ないようです。 当社がSolrを使い始めた昨年は現在よりもさらに少なく、結構苦労しました。 今回はやや雑多な内容となりますが、新しくSolrを使う際に必要と考えられる情報をまとめてみました。 エントリーでは、Solr1.3を対象としています。 Solr1.3が現在の安定版で、Solr1.4-devが開発版となります。 目次 Solrとは 機能一覧 実績/事例 Solrを使ったシステムの開発方法 おすすめする方 データ量/性能とハードウェア マルチコア構成 様々な検索 スケールアウト 検索と更新 Solrを始めるための情報リスト 全

  • 第6回 Solr/Luceneの活用に知っておくべき点

    前回までに,Solr/Luceneの概要と簡単な導入検証までを説明しました。Lucene自体はライブラリであることから,これを利用して高度なアプリケーションを独自に実装することも可能ですが、簡単な検索機能であればSolrを利用し、比較的容易に利用できることがお分かりいただけたのではないでしょうか。今回は,導入のための留意点と,周辺のツール類を紹介します。 Solr/Lucene導入の実際 では,導入時の留意点について順に説明してきましょう。 ●インデックス設計 一般的に全文検索エンジンは,プレーンテキストのような非構造化データを効率良く検索するものです。そのため,データを格納するインデックスに対して,データを「ともかく放り込む」といった設計も可能です。 誤解を恐れずにいえば,その考え方自体は大きく間違っていません。しかし,インデックスの構造を充分に設計した方が,より効率の良い効果的な検索機

    第6回 Solr/Luceneの活用に知っておくべき点
  • http://neta.ywcafe.net/001023.html

    yuupon
    yuupon 2009/10/03
    キューが役にたつ非同期処理は割と多い。
  • セガが取り組んだ「ゲーム開発のプロセス改善策」

    家庭用ゲーム機の劇的な進化がゲーム開発をより困難にしている? 1983年に任天堂の「ファミリーコンピュータ」が登場し、社会現象を巻き起こしてから約26年。家庭用ゲーム機は飛躍的に進化を遂げ、現在の最新機であるソニーの「プレイステーション 3」(以下、PS3)、マイクロソフトの「Xbox 360」などでは、CGを駆使してまるで実写のようなリアルな映像が楽しめるゲームタイトルが次々と生み出されている。 こうした家庭用ゲーム機の進化に伴い、ゲームソフトの開発を手掛けるメーカーにとっては「より高品質なゲームタイトルを、より短納期に開発する」ことが求められるようになった。そのため、その開発プロジェクトも従来とは比べものにならないくらい規模が大きくなった。これが「開発工数とプログラムコード行数の増大によるバグの大量発生」など、さまざまな問題を引き起こしており、ゲーム業界全体の重大な課題となっている。

    セガが取り組んだ「ゲーム開発のプロセス改善策」
  • ユーザー指向のもの作りに関する一考察:中島聡・ネット時代のデジタルライフスタイル

    この週末に私が読んでいるは、私のもう一つのブログでも紹介記事を書いた「The Ten Faces of Innovation」。そのに私がいままで漠然と感じていてうまく説明できなかったことを上手に説明してくれている記述を見つけた。 そこには、自動車産業の父、Henry Fordの言葉「もし私がカスタマーに何が欲しいかと尋ねたら、彼らは『もっと早い馬が欲しい』と言っていたでしょう」が引用してあり、「カスタマー(顧客)の声を聞くことは大切だが、彼らに『何が欲しいか』を聞いても必ずしも答えは出て来ない。それよりも彼らの行動を良く観察し、どんなところで苦労しているか、彼らなりにどんな工夫をして今あるものを使いこなしているかを理解した上で、何を作るべきかを考えるべきだ」と結論付けている。 ものすごく共感できる。この業界にいると、「ユーザーの声を聞くことは大切だ」というセリフは良く聞くが、それを頭

    ユーザー指向のもの作りに関する一考察:中島聡・ネット時代のデジタルライフスタイル
    yuupon
    yuupon 2009/09/24
    顧客の声を聞き、彼らが欲しいものをそのまま作るのはユーザ指向のもの作りを誤解している。まずユーザ層全体を良く観察して疑問と答えを見つける。
  • Kazuho@Cybozu Labs: Q4M - MySQL 上で動作するメッセージキュー

    « ウェブアプリケーションにおけるHDDの正しい使い方 | メイン | Pathtraq リニューアルのおしらせ (リアルタイム検索機能の追加ほか) » 2008年01月15日 Q4M - MySQL 上で動作するメッセージキュー 数年来ずっと「RDBMSに統合されたメッセージキューがほしい」と言ってきたわけですが、昨年末にストレージエンジンをプラグインとして開発できる MySQL 5.1 が RC になっていることに気づき、自分で作ってみました。 Q4M (Queue for MySQL) は MySQL 5.1 のプラガブル・ストレージ・エンジンとして動作するメッセージキューであり、堅牢・高速・柔軟であるよう設計されています。昨年12月遅くに開発が開始され、まだ非常に原始的ですが、かなり高速に動作します。 q4m.31tools.com 自分の英語を日語訳するというのも変なものですが

  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
  • 幸せなエンジニアになるための仕事術/まつもとゆきひろ&平鍋健児 - tmtms のメモ

    幸せ 平鍋: 1. 技術的な困難を達成。 2. お客様に感謝された。 最初は1だったけど最近は2。 まつもと: 理不尽な目に合わないこと。 思うようにツールが動かない→自分でつくる。 OSSは自分で手を入れられる。 平鍋: 自分一人の幸せじゃない。 プロジェクトが終わっても続く人間関係。 人のつながり。信頼。 まつもと: 通勤が3時間。理不尽→地方。 納得行かない変更が顧客から言われたくない 平鍋: エンジニアで不幸せな人へ。仕事は選べる。極端なこと言えば辞めればいい。 ワークライフ・バランス実現の戦略(例:地方に住むこと) 平鍋: 1995.子供を育てられるかを考えたときに自分の中での都会の価値がさがってきた。 田舎に帰ってから、世界のことを考えた。JUDE,アジャイルをやり始めた。 まつもと: 鳥取→つくば→島根 1997. OSSビジネスを始めようと声をかけてもらって島根へ。 理不尽

    幸せなエンジニアになるための仕事術/まつもとゆきひろ&平鍋健児 - tmtms のメモ
  • 【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか?

    ソースコード読解力は個人差が大きい コードレビューなどで、他の人のソースコードを読んだり理解したりする速度が気になることはありませんか? また、読む速度や理解する速度がとても速い人がいると感じたり、自分が周りの人よりも速いと思ったりすることがあるのではないでしょうか。私たちの研究グループで実施した観察でもソースコードを読む速度は個人差が大きいことを確認しており、同じソースコードを理解するための時間に6倍の差がある事例を確認しています。 では、自分自身のソースコードを読む速度や理解する速度が、平均と比べて速いのか遅いのかを知るためにはどうしたらよいでしょうか? 最も簡単な方法は、社内などの身の周りの人とコードレビュー時間を比べてみることでしょう。他にも、参加者全員でソースコードを読むような社外勉強会に参加する方法もありそうです。 文献からは大まかな速度を知ることができる 書籍、標準、論文の情

    【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか?