[設計]の検索結果

＋ 

A [書籍]Oracle（オラクル）関連

－ 

A [書籍]Oracle（オラクル）関連

Oracleの入門書、データベースのアーキテクチャから運用・管理、データベース設計、PL/SQL、プログラミングなどの Oracle（オラクル）に関する書籍。Oracle DB ユーザーズガイド＜9i&10g対応＞初めてOracleを使う人で...

Oracleの入門書、データベースのアーキテクチャから運用・管理、データベース設計、PL/SQL、プログラミングなどの Oracle（オラクル）に関する書籍。

Oracle DB ユーザーズガイド＜9i&10g対応＞
初めてOracleを使う人でも理解しやすい丁寧な解説と、実践で使えるテクニックを扱ったSQLの入門書。

プロとしてのOracle 物理設計入門
データベースの性能を決定する物理設計をOracleのアーキテクチャから理論的に詳解。設計・構築だけでなく、パフォーマンスチューニングにも活用できるノウハウが記述されている。

詳解 Oracleアーキテクチャ
Oracleの基本的なアーキテクチャ概要からトランザクション管理、ロッキング、クラスタリングまで、Oracleアーキテクチャを徹底解説。

Oracle Database 10g運用管理ガイド
Oracle10g Database Enterprise Editionを安全に運用するための実践ガイド。RedHat Linux Enterprise Linux 3.0 を基本として、Windows 2003 Server/HP-UX版との相違点も記載されている。

Oracle逆引き大全500の極意 DB管理編―Oracle 10g/9i(Windows/UNIX)対応
Oracleデータベースの管理に携わるユーザーを対象に現場で役立つテクニックを解説。データベース管理の基本から応用テクニックまでを、最新のOracle10gだけでなくOracle9i、8iにも役立つようにSQL文を中心に解説した書籍。

Oracle9i DBAハンドブック
Oracle9iについて、最新の機能を紹介するだけでなく、それらを駆使してOracleデータベースの管理を容易にする方法、機能と適切なプランニングテクニックや管理テクニックも分野ごとに紹介。

Oracle DBA Unixコマンドデスクトップリファレンス
オラクルデータベース管理者が頻繁に利用するUnixコマンドを中心としたわかりやすい解説と、実用的なUnixスクリプトを紹介。 DBAの業務に直結する実例豊富なデスクトップリファレンス。

Oracle on UNIXデータベース管理
データベース管理者が日常よく使うUNIXコマンドの操作とOracleの管理トピックの解説書。動作原理、連携のしくみを詳細に解説した書籍。

Oracleパフォーマンスチューニング
設計者、プログラマー、データベース管理者、システム管理者を対象にチューニングの問題を取りあげた広範かつ詳細な解説書。

Oracle & UNIXパフォーマンスチューニング
UNIXとOracleの概念を紹介しながら、OracleとUNIXカーネルの内部動作について詳細に説明。

SEのためのOracleチューニングハンドブック
Oracle導入時にSEが考慮しなければならないチューニングのポイントを開発工程（要件定義、基本設計、詳細設計、開発、導入、パフォーマンスチューニング）にそって解説。

Oracleデータベース バックアップリカバリテクニック
システムのバックアップ設計を行うエンジニアを対象に、バックアップの技術について初歩から高度なテクニックまでを解説。

Oracleシステム設計
データモデリング、データベースシステム特有の設計上の注意点、アーキテクチャを設計する際のテクニック、コードデザインなど、システム設計の基本から応用まで解説された書籍。

Oracleパワーアップテクニック―テーブル設計からパフォーマンスチューニングまで
データベースシステムの開発者、管理者を対象として、Oracleの性能を引き出すためのポイントをわかりやすく解説。運用、システム拡張を考慮したテーブル設計から、稼働システムのパフォーマンスチューニングまで。

プロとしてのOracle PL/SQL入門
Oracle教育のプロフェッショナル集団が書き下ろしたPL/SQL解説書。PL/SQLの基礎文法からじっくり詳解し、学習者の理解しにくい難所は人気講師が要点解説。

Oracle PL/SQLプログラミング 基礎編
Oracle社のPL/SQL言語を豊富な例題とともに解説。基礎編では基本的な言語仕様やデータ構造、制御構造、カーソル、例外処理、表、パッケージや組み込み関数などの各種言語要素がとりあげられている。

Oracle PL/SQLプログラミング 応用編 第2版
PL/SQL言語を細部にわたって広範囲にカバー。新機能だけでなく実際のプログラミングに役立つヒントも多数掲載されている書籍。

Oracle PL/SQL組み込みパッケージ/関数デスクトップリファレンス
OracleのPL/SQL言語の中でも、日々のプログラミング作業でよく使用するパッケージ、組み込み関数およびプログラム例がコンパクトにまとめられている。

Oracle PL/SQLワークブック
実践的な例題を豊富に掲載したOracleプログラマーのためのPL/SQLのプログラミング問題集。前半が問題で、後半が解答になっている。日常の業務で直面しそうな問題を多数掲載し、サンプルコード集としても利用できる。

Oracle+Javaアプリケーション開発
最大シェアを誇るデータベース「Oracle」と、人気プログラミング言語「Java」。定番の2つのテクノロジーを一度に習得、両者の特性をフルに活用したアプリケーション開発をマスターできる解説書。

OracleのためのJava開発技法―JDBC、SQLJ、EJB、BC4J、Servlet、JSP
Oracleに搭載されたJavaテクノロジーを理解し、実際の開発に適用させるために必要なすべての解説とサンプルコード。

Visual Basic+Oracleシステム構築実装ガイド―C/Sシステム構築の真髄がわかる
Visual Basicを使って、RDBMSのデファクトスタンダードであるOracleのデータベースシステムを構築・実装する入門ガイド。

Oracle C/C++実践入門 Pro*C/C++とOCIによるDBプログラミング
OracleデータベースにアクセスするC/C++プログラムの開発にフォーカスした技術書。基本的なデータ操作はもちろん、動的SQLの記述といった実践的テクニックも紹介されている。

Oracle逆引き大全500の極意 プログラミング編
やりたい事柄から目的の実現方法を解説するスタイルで、基本から応用テクニックまでを網羅されている。

[351] Posted by buzei at 2008/05/23 14:12:54
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A ソフトウェア開発にハリーポッターはいらない

－ 

A ソフトウェア開発にハリーポッターはいらない

出来上がったプログラムがちゃんと動くと嬉しいものですが、ソフトウェア開発の作業自体はとても地味なものです。残念ながらソフトウェアが魔法のように出来上がるなんてことはありません。プログラミングは一つ一つ...

出来上がったプログラムがちゃんと動くと嬉しいものですが、ソフトウェア開発の作業自体はとても地味なものです。残念ながらソフトウェアが魔法のように出来上がるなんてことはありません。

プログラミングは一つ一つコードを書いていくだけですし、デバックは一つ一つバグを潰していくだけ、テストは一つ一つはプログラムが仕様どおりできているのかを確認していくだけです。ソフトウェア開発において魔法を使う余地などないのです。

もちろんどのように作業設計するかによって作業効率は変わってきますが、そのような設計能力は一朝一夕に身に付くものではなく日々の作業を自分の頭で考えながら着実にやっていくことで身につくものです。

ソフトウェア開発におけるハリー・ポッターは？

自分も「魔法」を身に付けたいと切実に思いますが、この例えでいくとホグワーツはどこになるのでしょうね。

優れたソフトウェア開発者になりたいのであれば、どこかの魔法学校で「魔法（そんなものは存在しない）」を身に付けることなど考えず、自分の頭で考えたことを一つずつやっていくべきではないでしょうか。どんな優れた人間であってもそれ以上のことができるとは私には思えません。

ライト、ついてますか―問題発見の人間学 著者：G.M.ワインバーグ,木村 泉 価格：￥ 2,100 共立出版 by Amalink

[148] Posted by buzei at 2007/12/11 04:22:48
0 point | Link (2) | Trackback (0) | Comment (0)

＋ 

A あるプログラマのサクセスストリー？

－ 

A あるプログラマのサクセスストリー？

ブラック会社に勤めてるんだが、もう俺は限界かもしれない職業はプログラマ。この職業、マジでやばすぎる。入社日での出来事。パソコンを渡される→指示された通り、色々なものをインストール→設計書を渡される。「...

ブラック会社に勤めてるんだが、もう俺は限界かもしれない

職業はプログラマ。この職業、マジでやばすぎる。

入社日での出来事。
パソコンを渡される→指示された通り、色々なものをインストール→設計書を渡される。

「これでおっけーと。んじゃ作れ」
「え？」
「いや作れって」
「あ、え？は、はい」
「みんな忙しいから、出来る限り自分で解決しろよ」

そう言って去っていくチームリーダー。
このまま悩んでてもしょうがない。とりあえず設計書を見てみるか。
フレームワークがどうのこうの、うんたらかんたら・・・。テストはどうのこうの・・・。


ワケわからんぞ

（略）

ブラック会社に勤めてるんだが、もう俺は限界かもしれない　２

一体なんだろうか。特別賞与か何かくれんのかな。

ノックする。

「どうぞ」
「失礼します」
「よくがんばったな、1くん」
「おかげさまで。けど、ちょっと休みたいですね。弱音を吐くんじゃないですけどｗ」
「いやいや、いいよｗ　1週間ぐらい休みを取りなさい」
「ありがとうございます。それで話ってなんでしょうか」
「いやーリーダー居るだろ」
「えぇ」
「変わってみないかね、次のプロジェクトで」

は？

「藤田くんが一番適任なんだが、彼はその気がないみたいでね。
　それで二番目の実力者の君に頼みたいんだよ」

おいおいおいおい、ちょっと待て！！！！どーする俺！？どーなる俺！？続くぅ！！（たぶん

デスマ編　完

-----

いやー、マジ吹いた。
でも、おそらくこれは実話だなｗ

ブラック会社に勤めてるんだが、もう俺は限界かもしれない 著者：黒井勇人 価格：1,470円 新潮社

by Amalink

[136] Posted by buzei at 2007/12/02 17:03:05
3 point | Link (5) | Trackback (0) | Comment (3)

＋ 

A 指輪物語（ゆびわものがたり）

－ 

A 指輪物語（ゆびわものがたり）

指輪物語（ゆびわものがたり）は、すべてのファンタジーの原点と言われるJ.R.R.トールキンの小説で、エルフ、人間、ドワーフ、ホビットなどが住む太古の世界「中つ国」を舞台に、冥王サウロンが失った世界を滅ぼす邪...

指輪物語（ゆびわものがたり）は、すべてのファンタジーの原点と言われるJ.R.R.トールキンの小説で、エルフ、人間、ドワーフ、ホビットなどが住む太古の世界「中つ国」を舞台に、冥王サウロンが失った世界を滅ぼす邪悪な指輪を手に入れたホビット族のフロドが、仲間達とともに指輪を破壊するために「滅びの亀裂」と呼ばれる火口へと旅立つ壮大な冒険物語となっている。ファンタジー小説だけでなく漫画やゲームなどにも大きな影響を与えている。アカデミー賞を受賞した映画「ロード・オブ・ザ・リング」の原作でもある。

文庫 新版 指輪物語 全9巻セット
妖精族や小人族の住む太古の世界の「中つ国」。世界を破滅させる魔力を秘めた指輪を破棄するために旅に出た勇敢な小人ホビット族の若者フロドの冒険物語の文庫版。

指輪物語 (10) 新版 追補編
ゴンドール王国の王となるアラゴルンの先祖や指輪の仲間のその後がわかる。巻末に詳細な索引付き。

Lord of the Rings (ロード・オブ・ザ・リング)
指輪物語の原書。

トールキン指輪物語事典 ― 普及版
歴史、地理、種族や国々、登場人物にいたるまで400以上の項目と、150以上におよぶ図版を収録、あらゆる側面から「指輪物語」を知ることができる画期的百科事典。

トールキンによる『指輪物語』の図像世界(イメージ)
トールキンの自筆画によるビルボやガンダルフ、ミドルアースなど、作品に登場する人物や世界の作者自身のイメージを描いた未公開をふくむ200点の自筆画を収録。

The Atlas of Middle-Earth 「中つ国」歴史地図 ― トールキン世界のすべて
「指輪物語」「シルマリルの物語」などの舞台となる、トールキンが創造した「中つ国」。その壮大なファンタジーの国の克明な地図を描いた書籍。第一紀、第二紀、第三紀、の合戦や主要な場所は、すべて網羅されており、特殊な地形の描写や、城などの設計図、「中つ国」の歴史全体を通じての気候、人口分布、言語、植生といった、テーマ別の地図も記載されている。

ロード・オブ・ザ・リング コレクターズ・エディション トリロジーBOX セット(DVD)
「ロード・オブ・ザ・リング ― コレクターズ・エディション」、「ロード・オブ・ザ・リング 二つの塔 コレクターズ・エディション」、「ロード・オブ・ザ・リング 王の帰還」同梱したのBOXセット。

[108] Posted by buzei at 2007/11/04 22:37:49
0 point | Link (3) | Trackback (0) | Comment (0)

＋ 

A デバッグを効率的に進めるための９の心得

－ 

A デバッグを効率的に進めるための９の心得

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、...

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、品質が低い状態でリリースされてしまうことになります。テストを円滑に進めソフトウェアの品質の高めていくためには、バグを迅速かつ正確にバグを修正していく必要があります。

しかし、オブジェクト指向プログラミング（OOP）やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。

知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。

1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。

2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。

3. 問題を確実に再現できるようする
問題が発生する条件（操作手順、データなど）を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。

4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。

5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。

6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。

7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。

8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。

9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。

[67] Posted by buzei at 2007/09/11 04:59:32
0 point | Link (2) | Trackback (0) | Comment (0)