CESA DEVELOPERS CONFERENCE 2006レポート スクエニ村田氏ら、門外不出の「FF」開発ノウハウを一挙公開
【9月26日】 レベルファイブ、「LEVEL5 VISION 2008」開催 完全新作や新規プロジェクトを多数発表 SCEJ、「PlayStation C.A.M.P!」インタビュー これまでにないゲームを作り出す人材を発掘する 新クリエイター発掘支援プログラム ヴァナ・ディール“水晶大戦”探放記 バージョンアップレポート“「アルタナの神兵」編” シージターレットがお目見えした最新カンパニエ仕様から 獣人拠点の将領NM、新WSクエスト冒頭など紹介!! コーエー、PSP「Zill O'll 〜infinite plus〜」 新キャラクタ登場などの新要素を追加して発売決定 タッチペンですべて操作できる新感覚ボクシングアクション ESP、DS「はじめの一歩 THE FIGHTING! DS」 バンダイナムコ、「SEED DESTINY」より3機のガンダムが参戦!! PS2/PS3/
最速インターフェース研究会 :: AutoHotkeyを使ってFirefoxをリロードするだけのexeファイルを作ってみた
エディタの保存と同時にブラウザを自動でリロードさせると開発がはかどって素晴らしいよ、みたいな話をしてたら軽く派生したわけなんですが 自動リロードで開発をアジャイルにするたった一つの方法！ < 31 < July < 2006 < nulog, NULL::something : out of the headphone http://lowreal.net/logs/2006/07/31/1 hail2u.net - Weblog - CSSファイルを保存すると同時にブラウザをリロード http://hail2u.net/blog/webdesign/save-css-file-and-reload-browser.html WSHやRubyからキー操作を送るって方法だと、操作対象のウィンドウをアクティブにしないとキー操作を受け付けてくれなかったりして(もっといい方法あるのかも知れないけど
利用者の立場を考えたペルソナ／シナリオ法による開発とは
Speaker 株式会社アプレッソ代表取締役副社長 CTO 小野和俊氏【ユーザビリティ研究会】では、ペルソナ／シナリオ法による開発の具体例などを紹介していきます。ペルソナを使ったことで発見された画面デザイン上の問題点や機能重複などをいくつか紹介する予定です。 リッチクライアント技術の登場・進展により、ソフトウェア・ユーザーインターフェイスの表現自由度が非常に高まり、いろいろなものが作れるようになりました。 ただ、いろいろなものが作成可能な道具が与えられたというのは、その道具を間違って使ってしまうことにも結び付き、それがこれからの課題だといえます。 HTMLを用いたWebベースのソフトウェアでは、ごく限られたソフトウェア部品しかなく、結果的にシンプルな操作性が実現されていた。そのように表現の方法が限られていたものが、いま自由に表現できる時代になろうとしています。その自由な表現が可能だという状
ポジティブシンキングの功罪 : 小野和俊のブログ
はじめに断っておくと私はかなりポジティブシンキングな方である。問題が見つかったときにも「調査が進み問題が発見された」などと、つい前向きに発言してしまうところがある。 ポジティブシンキングの功と罪のうち、功については言わずもがな、文句ばかり言っているよりも物事に前向きに取り組んだ方が気持ちが良いし、前向きな姿勢でいるからこそ見えてくる可能性というものもある。 しかしこのエントリで取り扱いたいのは主にポジティブシンキングの罪の部分である。 往々にして最も大切なことは最も言いにくいことの中に隠されており、ポジティブシンキングであるが故に負の部分が見えなくなって本質を見誤ってしまうといった危険性は、私たちの生活の様々な場面において存在する。 自分たちが提供しているソフトウェアやサービスで、最も嫌いな機能、最も使いにくい箇所等をユーザーや社内の関連部署の人に投票してもらってランキングを競う。ここで見
第9回 デザイナーがプログラマに歩み寄るべき理由（わけ）
筆者は，「プログラマがデザインセンスやセールス・プロモーションのノウハウを身に付けるよりも，デザイナーが技術を身に付けて80歩進み，プログラマには20歩進んでもらって握手するほうが合理的だ」と思っている（第1回目， 第4回目を参照）。Web制作者の世界では，通常，プログラマがデザイナーに歩み寄るほうが手っ取り早いと思われているにもかかわらず，なぜ筆者は，その逆のことを主張するのか。 良いデザインとは「成功するデザイン」 デザイナーがプログラマに歩み寄るべきと考えるには，ちゃんとした理由がある。詳しく説明しよう。まずは，次のAからEの項目を読んでほしい。 A） 誰が見てもほっとしたり，心安らぐようなWebデザインを目指すべきだ B） 美しい，いわゆる統計上人気のある色だけをこだわって選び，うまく組み合わせることができれば，素晴らしいデザインに仕上がるだろう C） 対象に合った色彩を使うこと―
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：レグレッション・テストに逆ギレ
どうも更新が滞りがちですが、いよいよ新サービスのリリース・カウントダウンが始まりました。寝ても覚めても開発とバグ取りにいそしむ中毒状態で、メールにさえろくに返事ができておらず、ゴメンなさい！いましばらくご辛抱下さい！ 近況としては、IRS（米国税局）から「キミはちゃんと確定申告を期日までに行わなかったからペナルティじゃ」という、折り目正しくきちんと納税した人間に対してありえない通告があったので、先方が真っ先に小切手を振り出した記録をこれでもかと全部コピーして送りつけて、お前たちはドロボーかと詰問して謝罪をとりつけたり、相棒のダニーが唐突に投票権を持つ米国民の義務であるJury Duty（陪審員義務）に駆り出されて一週間まるまる留守になったり、歯医者に行ってチェックアップしてもらったら$800/月もの医療保険に加入しているにもかかわらず$4,000という高額な治療費の見積もりをもらって開いた
川o・-・）＜2nd life - Rails における信頼とは
アンカテ(Uncategorizable Blog) - Rails的世界の「安心」と「信頼」の力学 自分の場合 Rails における信頼とは DHH (Rails 作者) のセンスだと思ってます。Rails はマーケティング、設計思想、共に成功したと言えますが、そのうちエンジニアの自分が興味があるのは設計思想なわけで。 最初 Rails に出会ったときは、日本では一年遅れでやってきた「Rails って簡単に素早く Web アプリケーションが作れるよね」といったスピード感に Rails ってばスゲー、と思いましたが今は違います。ここら辺は結局フレームワークに慣れれば、他のフレームワークでも大概は出だしのスピード感をつけることができます*1。 実際 Rails を使っていても、周りのその他たくさんの開発者と技術力の差をつけるには、結局 Rails のソースを読み、ネット上でかなりの情報が流れ
BKCon 2006 - にぽたん研究所
昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち
シフトJIS / EUC-JPとUnicodeとの妥当な変換表: Netsphere Laboratories
2004.10.17 新規作成。2004.12.19 加筆。2005.04.02加筆。 最近、コンピュータで扱う文字列の文字コードがUnicodeでなければならない場面が増えてきた。UnicodeとシフトJIS、EUC-JPを変換する機会が多い。この変換は変換表で行うが、変換表が実際的なものでなければ、文字化けが発生することになる。 おかしな変換表は、これまでは、特にLinuxなどの上で動作するオープンソースソフトウェアで多く見られた。おそらく規格原理主義者が多かったためだろう。そもそも、規格どおりに変換表を作ると、実用的な変換表にはならない。しかし、最近ではまともな変換表を実装しているものも増えてきて、うまく選ぶだけでいいようになってきている。 変換表の違いをまとめたページはよく見かけるが、実際にどのような条件を満たして変換するものを選べばいいか不明なので、まとめてみた。 変換表に求めら
最上の日々 - 数学を表現するのに最適な媒体はコンピュータである
▼ 数学の表現の媒体としてのコンピュータつづき あのあとyoriyukiさんから有用な示唆をもらいました。 （これだけ書くのも大変だろうなあ。いつもお世話になってます。） 証明チェッカのあちら側とこちら側 私的にみたハイライトはこの辺りかな： 論理に関する部分はうまくいかなそうな気が(直観的には)します。言語や論理について一般の人が抱いている直観は誤っているか、すくなくとも混乱していることが多く、そのまま形式化しようとするとうまくいかないからです。例えば、名詞は何か対象を名指している、といった考えがその例になるでしょう。この場合、何の対象も指さない時や、複数の対象に当てはまるときにどうするか、といった問題が考えられてないのですが、にもかかわらず強固な直観としてなかなかここから自由になれないようにに思います。 言い方を変えると、自然言語に近いもの純粋に形式的に取り扱おうとすると
ITベンチャーが守るべき7ヶ条
ボストンで行われている TiECON East 2006 というカンファレンスで、"Future of Software"というパネルディスカッションが行われ、そこで「ITベンチャーが守るべき7ヶ条」なるものが提言されたそうです： ■ Kleiner Perkins 7 rules for software start-ups (Don Dodge on the Next Big Thing) ベンチャーキャピタルの Kleiner Perkins のパートナー、Ajit Nazre 氏の意見とのこと。7ヶ条を翻訳してみるとこんな感じ： ユーザーがすぐに価値を手にできるようにせよ -- 初めて使った瞬間から、何か問題が解決できたり、価値が実現されるようにしなければならない。 クチコミを利用しろ -- プッシュ型ではなく、プル型で利用者を増やせ。営業部隊は必要ない。 追加で必要なIT技術（ソ
出来ないことは出来ないと言って欲しい：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
ITコンサルタントとして、製品やSIerの選定評価に携わるときにいつも思うことがある。 「出来ないことは出来ないと言って欲しい」 のである。ところが、何でもかんでも「出来ます」「（製品の）標準機能で対応できます」といって嘘をつく担当者の多いことこの上ない。困ったものだ。フェーズにもよるが正直に言ってもらえれば傷は浅い、もし出来ないならその機能を減らすなり他の方法を考える為に我々ＩＴコンサルタントが間に入っているのだから。 こういう人はＳＥに比べると営業に非常に多い。また国内ベンダーに比較すると海外ベンダーの人はなかなか「出来ません」とか「追加開発（カスタマイズ)になります」とは言わない傾向がある。 まあ彼らの立場からすると「出来ません」と答えた時点で評価を下げられて失注してしまうかもしれないのだからこういう行動に出るのもある程度まではわかるのだが、こちらから出来そうにない技術的ポイントを具
デスマーチのコストは誰が負担しているのか？：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
「出来ないことは出来ないと言って欲しい」のエントリーの続きになるが、こうして営業がはったりをいった後のプロジェクトは多くの場合最後にひどいことになる。出来るといった部分が実際には出来なくて問題となり、その対応の為に納期遅延が発生するのである。業界で有名なデスマーチの到来である。 そんな時にも大手のSIerの場合、最後の時点でSEや技術者を大量に投入して火消しにかかる。大手ベンダーだとマシンパフォーマンスの問題であればCPUやメモリの追加で対応するし、研究所から新しい技術を持ち込む。出来ない部分もSEの物量にモノを言わせて最終的にはなんとか作りこんでしまったりする。 そしてそういった時にもユーザの上層部は「さすが○○だ」といって満足してプロジェクトが完了する。 さて果たしてそうなのか？その大量に投入したＳＥの体力や技術のコストはどこが負担しているのだろうか？もしSIerが負担しているのだとし
[結] 2006年6月 - 結城浩の日記:モノクロ画像がカラーに見える錯視
目次 2006年6月25日 - 長男と完全数談義 / 2006年6月23日 - ティナからの手紙 / 2006年6月20日 - 無神論者との対話 / 2006年6月18日 - 父の日 / 2006年6月16日 - ソフトウェアは、私たちの想像よりもずっと複雑 / 2006年6月14日 - 仕事 / 2006年6月13日 - 無限羽の鳩と無限個の巣 / 仕事 / Haskell / 読書 / 2006年6月12日 - 仕事 / 2006年6月10日 - モノクロ画像がカラーに見える錯視 / 日記ダイジェストを更新 / 2006年6月8日 - www.textfile.orgのお引っ越し / 2006年6月5日 - 仕事 / 2006年6月4日 - 今日の一日 / 2006年6月3日 - 誤植 / 2006年6月1日 - 仕事 / ぜひ、感想をお送りください 日記一覧 2006年6月25日 ■
連続的で不可視の「プロジェクトX」たち - アンカテ
「プロジェクトＸ」成功の原因は、プロジェクトを描くフォーマットにあった。つらいプロジェクト、成功への道は見えない。そこで「男たちの逆転をかけたドラマ」（だいたい番組開始35〜40分ぐらいだったか。「水戸黄門」を想起させる）が始まって、めでたくプロジェクトはうまくいく。 多くの人々がこのパターンにはまり、日本PTA全国協議会は「プロジェクトＸ」を2003、2004年度の「子供に見せたい番組」に選定するまでになった。 少し考えれば、この構図が欺瞞（ぎまん）であることはすぐ分かる。「男たちの逆転をかけたドラマ」を仕掛けなければならないという時点で、すでにプロジェクト管理は失敗しているのだから。 適切なプロジェクト管理によって、潜在的な危機を事前に回避して本当に成功したプロジェクトはドラマにも研究材料にもなりにくい。従って、なかなか人の目に止まらない。 日本Rubyカンファレンス2006というイベ
わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊
この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」 コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。 で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ウォーターフォールモデル」は普及以前から批判されていた！？
Orange Beach Charter Fishing Trips, the C-Rose
A. WEBプログラマコース
http://d.hatena.ne.jp/lestrrat/20060716