タグ

ソフトウェア開発に関するiwskyのブックマーク (36)

  • 第三の修練 :: シェルスクリプト - テスト支援

    シェルスクリプト - テスト支援 今、シェルの開発をやっているんだけれども、テストが面倒くさい。で、楽できるようにテスト支援シェルみたいなのを作った。以外に役に立ったし気に入ったので、たまにメンテナンスしつつ使っていきたいなあとか思っていたけど、お馴染みのセキュリティ云々で持ち出すことが出来ない。せっかくだから何か残しておきたいと思うので、作るときのノウハウ的なものをメモ。ちなみにブラックボックス。 テスト時の準備オペレーションを関数化 異常系のコードを走らせるために、シェルの実行環境とかをいじる必要があったりする。 そういう場合のオペレーションを全部関数化しておく。例えば以下のようなものとか。 設定ファイルなどをリネームする。 DBに対してSQLを発行する。 DBに対して時間差でSQLを発行する。 任意のディレクトリにごみファイルを作る。 設定ファイルなどの内容を書き換える。 共通系モジ

  • デモではものができあがっているように見せない

    Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには・・・彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも

  • 日本のソフトウェア産業を振興させたいなら大企業を一つ潰せ | スラド

    KLAbのCTOであり、オープンソース界隈でも 知られている 仙石浩明氏が自身の日記にて、「日のソフトウェア産業を振興させる唯一にして最も効果的な究極の振興策は大企業の一つをつぶして、死蔵していた優秀な人材を放出させることである」という名言を書かれている。 一見暴論のようにも見えてしまうが、日ほど優秀な技術者を幾つかの大企業の奥底に塩漬けさせている国も珍しいのではないだろうか? そう思うと、どこか適当な会社が一個潰れれば人材が流動化し、優秀な事業家とのマッチングでイノベーションが生まれるという発想もアリに思えてくる。家電業界では業績不振の会社が草刈り場になるという事例も聞いたことがあるが、仮に富士通、日立、NECNTTあたりのどこかが傾くと劇的な変化が生まれるかもしれない。ただ、その他の多勢の社員の生活と日の景気にどう影響するかは恐いところだが。

  • Data Generator

    Data Generator The Data Generator has a new home! Please update your links to point to the following site: http://www.generatedata.com. Ever needed custom formatted sample / test data, like, bad? Well, that's the idea of the Data Generator. It's a free, open source script written in JavaScript, PHP and MySQL that lets you quickly generate large volumes of custom data in a variety of formats for us

  • 人月見積もりでは生産性は上がらない、IPAが警告 ― @IT

    2006/11/29 情報処理推進機構(IPA)は11月29日、2006年度「情報処理産業経営実態調査」の結果を発表した。この調査は「情報処理産業界の財務、経営状況の現状を把握し、今後の経営の参考に供する」(IPA)ことが目的で、1978年以降毎年実施されている。28回目となる今年は従来のアンケート調査に加えてヒアリングも実施し、労働生産性の分析などを行った点が特徴だという。アンケートでは861社から有効な回答が得られた。ヒアリングは25社に対して行った。 2005年度の情報処理産業全体の売上高は0.8%の増加で、伸び率は鈍っているものの2003年度から連続でプラス成長している。経常利益も22.6%の増加で、増収増益となった。ヒアリングの結果でも、経営状況は昨年と比べ良好であるという意見が多く聞かれたという。 生産性に関しては、ソフトウェア業界において、ソフトウェアプロダクト販売分野の売上

  • シンプルで軽快なUMLドローツール UMLet 7公開 | エンタープライズ | マイコミジャーナル

    umlet.comは22日(現地時間)、Javaで記述されたUMLドローツールUMLetのバージョン7を公開した。UMLetはUMLダイアグラムを記述するためのライトウェイト描画ツールであり、シンプルなユーザインタフェースで手軽にUMLを記述できる点が特徴。 今回リリースされたUMLet 7では、以前のバージョンに対して次のような拡張が行われている。 エレメントの色分けをサポート コマンドラインからのファイル名の指定をサポート マウスでのエレメントの選択機能を拡張 UIを洗練させてよりシンプルに "全選択"をサポート その他バグの修正 UMLetの使用方法は非常にシンプルで分かりやすい。起動するとまず図.1のように表示されるので、右枠のエレメントの中から描画したいエレメントをダブルクリックする。すると左の描画領域にそのエレメントがコピーされる。あとはクラス名や属性などは右中段のテキスト領域

  • [ThinkIT] ながさきITモデルへの参画 〜 地場SIerの官公庁システム開発奮戦記 第1回:地場SIerに訪れたチャンス 〜 Curlとの出会い (1/3)

    2003年2月、長崎県庁において休暇システム開発の一般競争入札が開かれた。独特な雰囲気の中で落札業者の名前が呼ばれた。 「休暇システム開発はドゥアイネットに決まりました」 この時から、当社の電子自治体への挑戦がはじまった。 当社ドゥアイネットの社は長崎にあり、主な仕事は大手ベンダーの下請であった。従業員は全12名、事務員を除く11名全員がプログラマであり、営業は1人もいない。唯一、社長である土井が地元や首都圏で営業活動を行い、仕事を受注してくる体制である。 システムを利用するエンドユーザとの接点がほとんどなく、大手ベンダーのSEとシステムについての打ち合わせを行う。開発においても話題となっているような流行の開発言語を使うわけでもなく、大手ベンダーからの指定通りにシステムを開発してきたのである。 受託開発業務は売上がコンスタントに上がるものではない。1つのシステムを納品して、次に同じ顧客か

  • ニーズ指向とシーズ指向(黒須教授のUser Engineering Lecture)

    人間中心設計の立場からは、ニーズ指向を重視し、シーズ指向に否定的な言い方をすることが多い。シーズ指向、すなわち技術の種が開発されてからその使い道を考える、というアプローチは多くの場合に、無理矢理使い道を考えるようなケースや一見おもしろそうでありながら実際には普及することのないケースが多くなり、商業的な成功がなかなか得られない。特に、研究所で技術を開発した研究者が考え出した実用アイデアというものは、学会発表や企業の技術展示などにもしばしば見受けられるが、商品化の「センス」が今ひとつ、というものが多い。商品化のセンス、という表現をしたが、これは単に直感が優れているかどうかという問題ではない。ユーザのニーズや必要性に基礎をおいたアプローチをとれば、その機器やシステムの存在理由が了解性の高いものになるし、そのアプローチをとらなければ、何のために必要なのかがわかりにくいものになってしまう、ということ

    ニーズ指向とシーズ指向(黒須教授のUser Engineering Lecture)
  • リレーショナル・データベースの世界

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • なぜ「デザイン」という行為、「デザイナー」という職業は誤解されるのか - 羨望は無知

    私は個人的興味からゲームデザインについて色々と調査・研究を追いかけている。巷では「ゲームデザイン」という概念はあまりなじみが無いらしく、こういうことをしているんですよ、と説明が必要な機会は多々ある。 こういったときに感じるのが、「デザインは誤解されているな」ということである。たとえば、「ゲームデザインとはゲームのグラフィックやキャラクター、世界観などをつくる仕事である」、という誤解があったりする。このような誤解は、ゲームデザインが理解不足というよりも、デザインという概念そのものが一般的に誤解されているとしか考えられない。 「デザインであると同時に技術でもあるような、ある一つの行為」をすることでしか、真にすぐれたインタフェースというのを作れない場合っていうのが、けっこうあるからなんじゃないかと。(中略)技術を精密に認識できていないから、その技術で可能となるユーザインタフェースを十分にイメージ

    なぜ「デザイン」という行為、「デザイナー」という職業は誤解されるのか - 羨望は無知
  • 分裂勘違い君劇場 - エンジニアの方が優れたユーザインタフェースデザインができる理由

    それから、これは個人的な意見ですが、プログラマはコンピューターの扱いになれているから、そうでない人が使うためのインタフェースを設計することができない、みたいな話をときどき耳にしますが、僕はそれに懐疑的です。インタフェースをうまく設計できない人というのはプログラマに限った話じゃない。それは「プログラマは営業ができない」と乱暴にまとめてしまうのと同じようなこと。 たぶん、プログラムができるかできないかということと、インタフェースをうまく設計できるかできないかというのはあんまり相関がないように思います。むしろコンピュータの世界では、プログラマは頭のなかで思い描いたインタフェースを実現する手段を最も良く知っている部類の人で、インタフェースを作るセンスさえ持ち得れば、それ作るのにもっとも適した人たちなんじゃないかと思います。 知り合いの会社では、半期ごとだかクオーターごとだかに、その期に、もっとも優

    分裂勘違い君劇場 - エンジニアの方が優れたユーザインタフェースデザインができる理由
  • XREA で Ruby on Rails を使う

    XREA で Ruby on Rails を使うことに挑戦してみました。 前提というかおおまかな方針というか XREAではシェルアカウントでできることがかなり制限されています。よって、自分の手元のマシンで必要なものをインストールした後、ファイルをXREAサーバに転送することにします。 また、XREAのドメインウェブ機能を使って、独自ドメインのトップで動かすことを前提とします。そうでない場合はNon VHost Installationを参照してください。 なお、自分の場合は広告免除している環境で動かしましたが、そうでない場合でも基的には同じと思われます。 RubyGems, Railsのインストール 自分の手元のマシンで、普通にRubyGemsとRailsをインストールします。 Getting Started With Railsあたりを参照。 インストールしたら、/usr/local/

  • 組み込み開発フォーラム - MONOist

    世界各国でAI関連規制の整備が進む中で、AIシステムの開発に求められるのが「検証(Verification)」と「妥当性確認(Validation)」から成る「V&Vプロセス」である。特に、自動車や航空宇宙の分野を中心に高い安全性や高い信頼性が重視されるセーフティクリティカルなシステムにAIを導入する際に重要な役割を果たすとみられている。

  • イケてないプログラム(使えない成果物)に見られる3つの共通点

    クイックソートの話で書いたとおり、相変わらず Excel - VBA と格闘する日々が続いております・・・orz 「大企業にありがちな問題。委託開発の甘い罠・・・」でも書いたとおり、今まで外注して作ったソフトウェアってほぼ 100% の確率でイケていないものが完成してます。年末に納品されたソフトウェアのできも酷いの何のって・・・ さて、いままで見てきたイケてないプログラムのダメソースに共通して言えることが3点ありまして、 DRY ( Don’t Repeat Yourself ) でない。同じもしくは似たソースのコピペが至る所に散在する。 ロジックに無駄が多すぎ。行き当たりばったりで作った感、満点。 アルゴリズム知らなさすぎ。馬鹿ループ処理で時間かかりすぎ。 のいずれか、もしくは全部が当てはまります。大抵は全部ですね。こういったソースが納品されると、センス無いなぁ〜と思っちゃうわけ。こうい

  • ひげぽん OSとか作っちゃうかMona- - プログラマは必読かも 「Joel on Software」

    Joel on Softwareposted with amazlet on 06.04.15Joel Spolsky 青木 靖 オーム社 (2005/12) Amazon.co.jp で詳細を見る id:ryoko_komachi:20051218:1135176719でも絶賛されている。 Joel on Softwareを買って読み始めました。 このが出ることを教えてくれたのは、たしかid:naoyaだったと思うのですが、聞いた時点で買うことを心に決めていました。 というのも「プログラマのためのユーザインタフェースデザイン」で、Joel氏の文章を読んでいて、その経験に裏打ちされた内容がとても勉強になったからです。 というか、影響受けまくりました。 書籍版のJoel on Softwareは、上記のサイトの文章をまとめたものが大部分だそうです。 Joel氏はMicrosoftで働いてい

    ひげぽん OSとか作っちゃうかMona- - プログラマは必読かも 「Joel on Software」
  • 小野和俊のブログ:続・プログラム・デザイナー宣言

    前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点

    小野和俊のブログ:続・プログラム・デザイナー宣言
    iwsky
    iwsky 2005/12/11
    「プログラマーにだって、一言でプログラマーとまとめるべきでない」。そうだなー、プログラマに対して感じてた違和感が和らいだ。
  • 自動化のための nmake 入門講座

    2001/09/24 石井 勝 はじめに ここでは,make ユーティリティを使ってプログラマやSEが行う作業を自動化するための方法を解説したいと思います. make は,単にプログラム開発作業だけでなくいろいろな作業を自動化してくれます.自動化する作業のプラットフォームとして make を活用することができます.ところが,最近のプログラマは統合開発環境を使っているせいか, make を理解できる人が非常に少なくなってきました.今やっている開発でも,Makefile をメンテできるのは僕一人という非常にまずいことになっています.また, make について書かれたサイトや書籍が非常に少ないことも敷居を高くしている原因です.make について少しは知っているけど,あまり使いこんだことがない人はこの記事を参考にしてみてください. ところで,make といってもいろいろな種類があり,それぞ

  • eXperts Connection|オンカジ 登録ボーナスのセキュリティー

    eXperts Connection はシステム エンジニアやシステム管理者を対象とし、マイクロソフトのサーバー システム製品を中心に情報交換や意見交換を行うコミュニティです。ユーザーとマイクロソフトからなるチームでテーマを厳選して議論し、情報を共有・蓄積していきます。また、エキスパート コネクションは .NET Framework上で作成されており、サイト上でソースコードを公開しています。ソースコードに対する機能追加や修正に関する議論を行うことで、お客様が作成する.NET アプリケーションの参考にすることが可能です。 eXConn Blogsでは 「マイクロソフト社員による個人または部門(チーム)の Blog」 の運用を行っています。 このブログでは、マイクロソフトでの経験を活かした部門チームが、セキュリティエンジニアを目指している未経験者達が今後取るべき資格や、IT業界においてのセキュ

  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • ソフトウェア開発をシンプルにする考え方のコツ(2/5) - @IT

    さて、「プチ・パラダイム・シフト」だが、今日は5つの価値の中の1つ、「シンプルさ」にコミットすることの意味とその理由を話そう。 いまさらいうまでもないことだが、ソフトウェア開発というのは、複雑さとの戦いだ。大規模になるにつれ、開発が進むにつれ、そして利害関係者(ステークホルダー)が増えるにつれ、問題は複雑になっていく。その複雑な問題にどう立ち向かうか? 工学的に考えてみると次のような感じだろう。 工学的アプローチによる複雑さへの対処: 大人数をうまく分業化する 問題を分割し、適切に割り振る それぞれの分割単位を独立させる 複雑な現実世界のものをモデル化する 現実世界の問題をITでの解決領域にマッピングする 予測し、なるべく正確に計画する 変化する部分と変化しない部分を分離できるようにする

    iwsky
    iwsky 2005/11/06
    「サイバラの原則」(・∀・)イイ!!