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

「会社の部署変更で技術覚えなければいけなくなったけど、何すれば良いと思う？」という質問を受けたことがあります。 人によって違いますが、多くの場合は「若いから」とか、「学校でコンピュータ習ったことがある」からという理由でそのような役回りが来ている気がします。 ある程度今まで技術的な部分までやっていた人ならば問題がないのですが、相談をしてくる知人の多くは特にコンピュータが好きだったわけでもなく、突然の試練に戸惑っている方が多いと感じました。 このページは、そのような知人のためのメモを作るという目的を含んでいます。 しかし折角作るので、状況が似た方々、学生のうちに技術を身につけて自分の武器にしたい方々、その他の方々などの助けになれば幸と考えております。 なお、ここに書いてある内容は私の趣味が多分に含まれており、どこまで書いてある方式を採用するかは読む方々の裁量に一任しております。 1. はじめに

[Contents]   [Back]   [Prev]   [Up]   [Next]   [Forward] gcov: テスト・カバレッジ・プログラム gcovは、 GNU CCと組み合わせることによって、 プログラムのコード・カバレッジをテストすることができるツールです。 この章では、 gcovのバージョン1.5について説明します。 gcovの紹介 gcovは、 テスト・カバレッジ・プログラムです。 GNU CCとともに使用してプログラムの分析を行えば、 より効率的、 かつ、 より高速に動作するコードを生成することができます。 gcovは、 コードのどの部分に最適化を適用するのが最も効果的であるかを発見するのを支援してくれる、 プロファイリング・ツールとして使用することができます。 また、 gcovを、 別のプロファイリング・ツールであるgprofとともに使用して、 コードのどの部

はじめに　CJ2EEのDataAccessObjectパターンは、企業向けシステム開発で利用される非常に優れたデザインパターンです。これを利用することにより、柔軟なシステムを構築することが可能となります。有名なパターンなので、多くの方はこのパターンを使った設計／開発に携わった経験があるのではないかと思います。　しかし、DataAccessObjectパターンを使った開発は多くのクラスやインターフェイスを定義する必要があります。これは、DataAccessObjectパターンがAbstructFactoryパターンをベースとしているためです。クラスやインターフェイスの数が増えると開発コストだけでなく管理コストも増大し、開発規模が大きくなるほど影響が大きくなります。　本稿では、こうしたDataAccessObjectパターンのデメリットを回避するためのパターンを紹介します。対象読者企業システム

はじめに おかげさまで、前回の記事は多くの方々からご好評をいただけたようでほっとしております。あちこちのブログなどを拝見していますと、記事をきっかけにして身近な例でERDを書いてみた方も見受けられます。今回も身近な題材でデータベース設計というものを考えていきたいと思います。 合言葉は、「量は質に転化する」。では、今回も張り切って行きましょう。 対象読者 データベース設計の初心者～中級者。 必要な環境 以下のいずれかのRDBMS。 PostgreSQL 8.0以上 MySQL 4.0以上 HSQLDB 1.7.2以上 MaxDB 7.5以上 Oracle 10g以上 SQL Server 2000以上 題材 今回の題材は、近所の図書館にあった書籍の予約用紙（図1）です。子供たちと本を借りに行った際にカウンターに置いてあったので早速利用することにしました。では、デー

はじめに システム構築においてデータベース設計は不可欠です。そこで多くの方がデータベースの設計技法について書籍で学んだりするのですが、なかなか身についたと感じられないことも多いのではないかと感じます。 その理由は、実務で任せられる機会というのが少ないからというのが大きなものとして挙げられます。データベース設計というのは、やはり重要な箇所ですから自然と経験のある人に任せられることが多いのが実態です。しかもデータベース設計を担当するのはプロジェクト全体の中でもごく少数だけになりますから、なかなかチャンスが巡ってきません。 しかし、それを嘆いているばかりではスキルが身につかないのも道理です。そこで身近にあるものを何でも手当たり次第にデータベース設計のネタにしてしまうことで、コツコツと地力をつけていこうというのがこのシリーズの主旨です。 合言葉は、「表組みを見たらERDを描け！」　。では、

©鳶嶋工房 このゲームについて 部屋の中から、とにかく外に出ます。他に目的はありません。 分類としては「脱出系ゲーム」になるとは思いますが、「クリック脱出ゲーム」ではありません。 プレイにはキーボードと、あなたの語彙力、メモなどが必要です。 プレイ方法 キーボードから行動(コマンド)を入力してプレイを進行します。 キーボードで入力を行う前に、一度上の黒い場所をクリックして下さい。 また、ローマ字入力を行うので、キーボードの入力モードは「英数(アルファベット)」にしてください。 >_ と表示されているときは、行動の入力ができます。 ↓ と表示されているときは、メッセージに続きがあるので、何かキーを押します。 コマンドは動詞と名詞を空白で区切って入力します。 例えば、次のように入力します。 >ﾄﾙ ｶｷﾞ 基本ルール メッセージに含まれるカタカナは、コマンドとして入力できます。 詳しいルールは

XProgramming > XP Magazine > Big Visible Charts COLLECTED TOPICS: Kate Oneal | Adventures in C# | Documentation in XP | Book Reviews Big Visible Charts Ron Jeffries 10/20/2004 It's time to revisit the topic of Big Visible Charts. Display important project information not in some formal way, not on the web, not in PowerPoint, but in charts on the wall that no one can miss. [Updated: V

急にお金が必要になってしまいました。キャッシングをするのに、レイクかモビット、どっちを利用するか迷っています。借りるならどっちがお得ですか？ お得という点から言えば、初めてならレイクがよりお得です まず、それぞれの特徴を見ていきましょう。レイクは銀行系で、総量規制の対象外、１万円からお借入可能で、最大500万の限度額、年率4.5～18％、200万まで30日間無利息、または5万までなら180日間無利息、初めてのお借入なら有利な条件ですね。届く封筒は「新生銀行」の名称です。 一方、モビットは消費者金融で、総量規制の対象となります。限度額は500万、年率4.8～18％です。特に無利息期間の指定はありません。WEB完結型なら、審査の電話が入りません。 最高・最低金利だけで見ると、レイクのほうがお得に見えます。また、期間無利息などの点からも、初めての方はレイクのほうがお得な印象です。 反面、新生銀行

特集　Ｃプログラミングの秘訣 最終更新: 2006-03-28 このテキストはC MAGAZINE 1992年4月号に掲載された原稿のオリジナルテキストを元にしてHTMLに変換したものです。掲載文章と細部が異なっていると思われます。また、気付いた個所をいくつか修正してあります。 当時はまだWindows 95もないような時代で、現在の状況から見ると違和感のある内容も結構あるかもしれませんが、時代背景を想像しながら補正しつつ読んでいただければ幸いです。 ※2006年3月28日追記: 何が原因か知りませんがこのページのアクセスが増えているそうなので、 HTML のおかしなところを修正しました。 文章の変更はありません。 なお、このサイト(表ページ)は現在休眠状態ですが、 裏ページ や 裏の裏ページ の方を、細々と更新していたりします。 目次 Part1 よいプログラムを書く条件 Part2 明

はじめに Ruby on Railsには良くかけたチュートリアルがあって、最初の一歩は踏み出 しやすいようになっています。しかし、チュートリアルをひととおり読んで、 scaffoldスゲーということはわかったのだけど、次に何をしたら良いかわから ないという人が多いようです。かくいう筆者もその一人でした。 次に何をすればよいかというと、一番良いのはやはり自分で実際に何かアプリ ケーションを作ってみることです。というわけで、Rails初心者の筆者が、 Railsの勉強がてら「Wikiクローン」を作ってみたので、その過程を書いて見 ることにしました。何かの参考になれば幸いです。 Wikiクローンを選んだのは、良く知られているアプリケーションであることと、 機能を絞れば Rails の練習にはちょうど良いくらいの規模だと思われるから です。 (注: Wikiクローンで大変なのは、Wiki記法のパー

ソフトウェア開発ではこれまで、設計の重要性が繰り返し提言されてきた。良い設計ができれば、仕様を満たして正しく動作するだけでなく、理解や変更がしやすく、さらに再利用しやすいシステムとなる。逆に、そのようなシステムが実現できているのなら、それは良い設計であったといえるだろう。 では、良い設計が実践できているかというと、できていないことの方が多いのではないだろうか。例えば以下のような状況を聞くことは決して少なくない。 良い設計が実践できていない例： 不具合を修正してリリースしたら、その影響によりほかの個所で不具合が発生し収束に時間がかかった ほぼ同じコードが複数個所に大量に存在するため、1つの目的の修正でも数多くの同じ修正が必要となった 修正した場所と本来関係ない個所で問題が発生してしまった 機能アップする場合、修正するより作り直す方が早かった それでは良い設計を実践し、このような状況に陥らない