タグ

開発に関するzionicのブックマーク (18)

  • これが「老害」なのだろうか? - がるの健忘録

    元ネタ。 1800人月のネット・バンク構築 実装までオブジェクト指向で貫く http://itpro.nikkeibp.co.jp/article/COLUMN/20080819/313004/?ST=system&P=1 ………えとですねぇ。 「当にそれでやるんですか」。中央三井信託銀行が2008年1月にサービスを全面開始したインターネット・バンキング・サービス「中央三井ダイレクト」は、開発の企画当初から社内・グループ内で不安の声が相次いだ。システム開発の分析から設計、そして実装に至るまで、全面的にオブジェクト指向の技術や方法論で基幹系システムを構築するという前代未聞のプロジェクトだったからだ。 何かどこかにどのようにかの問題でも? 「現場の勉強意欲の欠落以外」で。 っつかですね。どこぞのフリーウェア作ってるところの開発規約だかでも「オブジェクト指向は最新すぎる技術なので使わない」とか

    これが「老害」なのだろうか? - がるの健忘録
    zionic
    zionic 2008/09/16
    老害とはちょっと違う気も。未成熟のまま年老いてしまったSI業界の半分は絶望でできています。
  • ペーパープロトタイピング事例集 | 秋元@サイボウズラボ・プログラマー・ブログ

    実際に動的なウェブサイトを作ってしまう前に、紙上でデザインや部品の配置、画面遷移などを確認するペーパープロトタイピングという設計技法があります。書籍もありますね。 ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする そのペーパープロトタイピングの事例を集めたページというのがありました。たとえば次のこれは、2000年5月31日にスケッチされたtwitterのプロトタイプです。当時はstat.usという仮名で、これによるとtwitterはLiveJounal(ブログサービス)とAIM(インスタントメッセンジャー)から最初の着想を得てから実装まで5年以上の間があったことになりますね。 FlickrのPlacesページやVimeoなどのペーパープロトタイプの写真も紹介されています。 こちらは韓国のポータルサイトDaumのAjaxウェブメール開発時に行なわれた、ペーパープロト

    ペーパープロトタイピング事例集 | 秋元@サイボウズラボ・プログラマー・ブログ
    zionic
    zionic 2008/06/26
    ペーパープロトタイピングの実例
  • マルチコア時代のサーバ設計について - Happy Hacking Diary

    来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

    マルチコア時代のサーバ設計について - Happy Hacking Diary
    zionic
    zionic 2008/05/08
    マルチコア環境におけるサーバソフトウェアの設計について
  • 窓の杜 - 【NEWS】プログラムの動作テスト用のダミーデータを簡単に大量作成「プラデータ」

    プログラムの動作テスト用のダミーデータを簡単に大量作成できるソフト「プラデータ」v1.0が、4日に公開された。Windows XP/Vistaに対応するフリーソフトで、現在作者のホームページからダウンロードできる。なお、動作には.NET Framework 2.0が必要。 「プラデータ」は、プログラムの動作テスト用のダミーデータを簡単に作成できるソフト。CSV/TSV形式のファイルなど、テキスト形式のダミーデータを大量に作成できるので、各種テキスト形式での入出力機能をもつソフトの動作をテストしたい場合などに便利だ。 ダミーデータを作成するには、まず“定義”を作成する。たとえば、1番目は数字4桁からなるID、2番目は最大12文字の名前、などといったようにデータの構造を決めて、リストに記入しよう。“定義”のデータ型には、テキスト・数値・日時を選択可能で、数値の桁数や文字列の長さ、日時の形式など

    zionic
    zionic 2008/04/23
    便利かも。
  • MOONGIFT: � GitもGUIがあると便利に「Git GUI」:オープンソースを毎日紹介

    慣れるとCUIで十分な気もするが、やはりGUIインタフェースがあった方が最初のとっかかりには良い。それはバージョン管理システムであっても同様だ。CVSがもてはやされたのはWinCVSがあったからだろうし、Subversionは言わずと知れたTortoiseSVNがある。 メイン画面。ここからコミット、プッシュを行う 同様にGitでもGUIインタフェースがあると便利に感じることがあるかも知れない。そこでこれだ。 今回紹介するオープンソース・ソフトウェアはGit GUI、GitGUIフロントエンドだ。 Git GUIはTkで開発されたソフトウェアで、WindowsMac OSXLinuxとで動作する(試したのはMac OSX向けのみ)。標準で配布されているものではないが、Google Codeで配布されているバージョンであれば一部日語化されている。 設定画面 可能な処理はレポジトリの作

    MOONGIFT: � GitもGUIがあると便利に「Git GUI」:オープンソースを毎日紹介
    zionic
    zionic 2008/04/11
    gitのGUIは欲しかったところ<へたれなので。
  • MOONGIFT: >> Subversionのステータスを見える化「StatSVN」:オープンソースを毎日紹介

    バージョン管理が日々利用していれば、開発した結果が蓄積されていることだろうと思う。そうしたログ情報を活用しているだろうか。大抵、何らかの問題があったときに、見返す程度だろう。 それではせっかくの情報が活用しきれていない。解析し、さらに開発効率を高める情報源として利用しよう。 今回紹介するオープンソース・ソフトウェアはStatSVN、Subvesion解析ソフトウェアだ。 StatSVNはSubversionから出力されるログ情報を解析してHTMLやグラフに変換するソフトウェアだ。解析元になるデータは、XML形式でsvnコマンドで出力する必要がある。そして、そのXMLデータを解析すると、一気にファイルが出力される。 開発者ごとに開発行数、Subversion全体における行数の変化、平均ファイルサイズ、ログメッセージを月ごとで出力と言った機能がある。日語のコミットログは文字化けするが、HTM

    MOONGIFT: >> Subversionのステータスを見える化「StatSVN」:オープンソースを毎日紹介
  • MOONGIFT: » ActionScript GUIフレームワーク「AsWing」:オープンソースを毎日紹介

    Flashと言うと、興味はあっても手は出していない技術者が数多い。なぜかと言えば、デザインとプログラムが融合していて何となく難しそうな感じがする事と、有償というイメージがある事に所以するだろう。 ActionScript2/3の開発についてはFlashDevelopを使えば良い。しかしこれでは画面デザインをプログラムベースで作らなければならない。そこでこれだ。 今回紹介するオープンソース・ソフトウェアはAsWing、ActionScript向けのGUIフレームワークだ。 AsWingはActionScript2/3に対応したGUIフレームワークだ。ボタン、チェックボックス、スライダ、プログレスバー、コンボボックス等、GUIを仕上げるのに十分なコンポーネントが提供されている。 これらをActionScript上でimportすれば良い。だが、これではプログラムベースという難点が解決していない

    MOONGIFT: » ActionScript GUIフレームワーク「AsWing」:オープンソースを毎日紹介
    zionic
    zionic 2008/02/19
    GUIビルダ
  • COBOL屋の呪縛 - masayang's diary

    今回の日出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低2件は増える。 入れ子になれば、4件、8件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調

    COBOL屋の呪縛 - masayang's diary
    zionic
    zionic 2007/09/25
    純粋培養なWEB屋に同じような事された。正規化無しで200列以上のデータが並ぶ。嫌がらせかよ。
  • HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方

    HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,

  • 仕様から学ぶOpenIDのキホン - @IT

    にわかに注目を集めている、URLをIDとして利用する認証プロトコル、OpenID。連載ではこのプロトコルの仕組みを技術的に解説するとともに、OpenIDが今後どのように活用されていくのかを紹介する(編集部) OpenIDってなんだろう? 現在、国内外でにわかに注目されつつあるOpenIDという仕組みを聞いたことがあるでしょうか? これはユーザー中心の分散ID認証システムですが、まだ日での普及は進んでいない状況です。 これにはいくつか原因が挙げられるでしょうが、筆者はOpenIDが正しく理解されていないことが原因だと考えます。 連載ではOpenIDの現行仕様、およびその拡張仕様とともに、実装を例に取りつつOpenIDとは何かということを明らかにしていきます。最終的にはOpenIDが切り開く未来を見るため、現在策定中の次期仕様についても触れていきたいと思います。 広がりつつあるブラウザベ

    仕様から学ぶOpenIDのキホン - @IT
  • 怠訳 - TDDはもう古い!これからはADDだ! : 404 Blog Not Found

    2007年06月21日04:30 カテゴリ翻訳/紹介Art 怠訳 - TDDはもう古い!これからはADDだ! こいつは厄さずにいられない。 scottberkun.com ? Blog Archive - Asshole driven development くそったれ駆動開発 - Asshole Driven development (ADD) チーム一のくそったれが、重要事項を全て決断する開発手法。理も知も技も、くそったれ殿が部屋にお出ましになるやいなやゴミ箱行き。くそったれ殿の詈と痴と偽が職場を支配する。いや、ちっとは知も技も残っているのも知れないが、ク氏の手にかかれば千の風になって飛んで行く。 認知的不協和開発 - Cognitive Dissonance development (CDD) どんな現場においても、ソフトウェアのあるべき姿に関して相反する理想が拮抗しているが、個々の

    怠訳 - TDDはもう古い!これからはADDだ! : 404 Blog Not Found
    zionic
    zionic 2007/06/21
    DBDが溢れてる。ADDもわりと。
  • 上流工程の問題解決 仕様変更編【前編】

    システムが以前よりも複雑化している現在,多くの開発者やユーザーは,「仕様変更がある程度起こるのは仕方がないこと」と前向きに受け止めてはいる。だが一方で,仕様変更によるコスト超過などが原因で,プロジェクトが失敗に陥ることが非常に多い。仕様変更によるトラブルを極力防ぐにはどうすればよいのか。現場担当者の知恵から解決法を探ってみた。 「設計書の50%に手を加えなければならないほど仕様変更が続出し,収拾がつかなくなってしまった」。NTTデータ東北の太田雅典氏(法人システム事業部 第一開発担当課長)は,数年前に手がけたある出版社の広告管理システムで,開発中に起こった仕様変更のトラブルを振り返る。このプロジェクトでは,設計が一通り終わり,実装(プログラミング)フェーズに入ってから,データベース(DB)の構造や,帳票出力用の計算式,他システムとの接続インタフェースなど,システムの根幹をなす仕様の変更を次

    上流工程の問題解決 仕様変更編【前編】
    zionic
    zionic 2007/06/01
    案件判定シート
  • ウノウラボ Unoh Labs: オープンソース戦略により、無償で使えるようになった負荷テストツール

    こんにちは! やまもと@テスト番長です。 ウノウラボのコメント欄まで熟読されている慧眼な方は既にお気づきかもしれませんが、WebLOADという商用の負荷テストツールがオープンソース化され、無料で利用出来るようになりました。 http://www.webload.org/ 以前自分が書いた WEBアプリのテストに必須なツール7種のエントリにsaltysonicさんがコメントで教えてくださいました。ありがとうございました! souceforge.net を探してみたところ、見つかりました。 WebLOAD 早速触ってみていますが、さすがに元商用だけあって多機能なようです。 関連記事も探してみたところ、以下のものが見つかりました。 http://news.earthweb.com/ent-news/article.php/3670176 http://www.testingreflec

    zionic
    zionic 2007/05/17
    負荷テストツール
  • Getting Real by 37signals

    Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> �LN�U �u�M�U Getting Real The smarter, faster, easier way to build a successful web application Start reading →

    Getting Real by 37signals
  • TAKESAKO @ Yet another Cybozu Labs: ニコニコ動画勉強会に行ってきました

    日ドワンゴさんの会議室にてこっそり開催されたニコニコ動画勉強会に参加してきました。 日の動画コメントサービス「ニコニコ動画」の裏側をドワンゴの開発者の方から 直接お話しを聞いて、参加者も一緒に意見交換ができる非常に面白い勉強会でした。 ドワンゴさんとしては会社で行なう技術者向けの勉強会初めての試みということもあり、 まずは開発者の知り合いベースで声をかけあって少人数で開催することにしたそうです。 六木のクラブの人や、バイナリカンファレンスでご一緒した人とこんなところで お会いできるとは思っていませんで、さまに想定の範囲外でした。 その甲斐あって密度の濃い話ができたと思います。 以下、自分用のメモを公開できる範囲で書きます。間違っていたらすみません。(ご指摘いただければすぐに訂正します) ■ニコニコ動画の苦労話 (Sさん) ニコニコ動画の歴史 2006年10月 一人でプロトタイプを開発

  • 巨大SNSを支える多言語混在RPC開発フレームワーク“Thrift” ― @IT

    2007/04/03 全米で第6位のトラフィックを稼ぐ人気SNSサイト「Facebook」のコアモジュール「Thrift」がオープンソースとして公開された(公式ブログ)。ライセンスは独自の「Thrift Software License」(改変や再配布を許容している点はGPL同様のようだ)。Facebookは学生向けSNSとして2004年にスタートし、その後、学生以外にも会員を拡大。2007年2月現在の会員数は1700万人。アップロードされている写真点数は10億枚以上で、1日600万枚の画像がアップロードされるなど、画像共有サイトとして見てもFlickrよりも大きい。そんな急成長した巨大サイトを支えたのは、独自に作り上げた開発フレームワークだったようだ。 多数の言語で開発したモジュールをシームレスに統合 Facebookが、開発フレームワークとして自ら作成したのがThriftだ。“thri

  • 社内デモで大成功をしてはいけない:Geekなぺーじ

    こうなってしまうと「ちょっと待ってください!ハリボテなんです!正常系しか動いていないんです!」とイキナリ非常事態宣言が発令される状況になってしまいます。 一番この問題が発生しがちな状況は、デモをする相手が技術的なバックグラウンドを持たない場合であると思われます。 恐らく、正常系だけで張りぼてで無理矢理動かすという概念があまり理解できていないと考えられます。 プログラミング経験が全く無い人にとっては「動いてるではないか。これ以上何をする?早く発売したい。」という思考になるのは当然であると言えば当然かもしれません。 もちろん、いくらデモであるとは言っても、まともに設計をしていればそのような問題は発生しづらいと思いますが、時間が無いとどうしてもやっつけで何とか無理矢理作り上げてしまうという状況が発生します。 また、開発人数が少ないと発生し易いと感じています。 例えば、一人だとまじめに設計するより

    zionic
    zionic 2007/02/16
    激しくありがち。泣きそう。
  • Geekなぺーじ : プログラマのモチベーションを高める9の事項

    「Nine Things Developers Want More Than Money」という記事がありました。 面白かったので要約してみました。 誤訳や勘違いがあるかも知れないので詳細は元記事をご覧下さい。 1. 成功するプロジェクトであること 多くのプロジェクトはそもそも失敗するような計画で行われているという悲しい現実があると書いてありました。 成功の要素として、現実的な納期、安物のツールを使うことを強制されないこと、ろくでもないマネジメント・仕様変更・暗黙の仕様 などを要求する発注先にあたらないなどが重要だそうです。 2. すばらしいマネジメントが行われていること プロジェクトと人の両面ですばらしいマネジメントが行われていることが重要だそうです。 身を挺してチームを守るようなすばらしいマネージャに対してはプログラマはソフトウェアの品質で応えるそうです。 3. 新しいことを学べること

  • 1