[ソースコード]の検索結果

＋ 

A オープンソースソフト

－ 

A オープンソースソフト

オープンソースソフトとは、そのソフトウェアのソースコード(プログラム)が一般に公開されているソフトウェアのことで、オープンソースソフトの利用者はプログラムを自由にコピーしたり、カスタマイズしたりすること...

オープンソースソフトとは、そのソフトウェアのソースコード(プログラム)が一般に公開されているソフトウェアのことで、オープンソースソフトの利用者はプログラムを自由にコピーしたり、カスタマイズしたりすることができる。

代表的なオープンソースライセンスとしてはGPL(GNU General Public License)とBSDライセンスが挙げられるが、他にも様々なライセンス条項のオープンソースソフトが存在する。

現在広く利用されているオープンソースソフトとしては、OSではLinuxとFreeBSD、WebサーバーではApache、ファイルサーバーではSamba、プログラミング言語ではPerl、PHP、Ruby、gcc、データベースシステムではMySQL、PostgreSQLなどがあげられる。

MOONGIFT
オープンソースソフトやフリーウェアを毎日紹介しているブログ。

SourceForge（ソースフォージュ）
オープンソースソフトの開発者向けに、CVS/SVNリポジトリ、Wikiシステム、メーリングリスト、バグ追跡システム、掲示板・フォーラム、タスク管理システム、 Webサイトホスティング、リリースファイルのダウンロードサービス、永久的なファイル保管、完全なバックアップ、シェル環境、コンパイル・ファームなどの総合的にプロジェクト管理を行う環境を、Webベースで提供する無料サービス。

オープンソースソフトウェアの本当の使い方 [技評SE新書] 著者：濱野 賢一朗/鈴木 友峰 価格：882円 技術評論社 by Amalink

[439] Posted by buzei at 2008/06/25 22:05:46
1 point | Link (6) | Trackback (0) | Comment (1)

＋ 

A CentOS

－ 

A CentOS

CentOSとは、誰でも無料で使えるようなエンタープライズレベルのLinuxシステムを提供するために、Red Hat社が無償公開したソースコードから、同社の商標、商用パッケージなどを含まない形でリビルドされた、Red Hat ...

CentOSとは、誰でも無料で使えるようなエンタープライズレベルのLinuxシステムを提供するために、Red Hat社が無償公開したソースコードから、同社の商標、商用パッケージなどを含まない形でリビルドされた、Red Hat Enterprise Linux(RHEL)と100%のバイナリ互換の実現を目標とするフリーLinuxディストリビューションで、一般にはWhite Box Enterprise Linux、Scientific Linux 等とともに「RHELクローン」と呼ばれる。

CentOS という名前は「Community ENTerprise Operating System(コミュニティベースで開発された、エンタープライズクラスのオペレーティングシステム)」に由来する。CentOSの開発配布には、Red Hat社は一切関与しておらずRed Hat社のサポートは受けられない。

CentOS/FAQ
www.centos.org - The Community ENTerprise Operating System(公式サイト)
centosユーザーメーリングリスト
CentOSで自宅サーバー構築

CentOSサーバ構築バイブル (MYCOM UNIX Books) 著者：川井 義治,伊藤 幸夫,米田 満,野川 准子 毎日コミュニケーションズ by Amalink

[196] Posted by buzei at 2008/01/17 04:12:28
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A Movable Type(ムーバブルタイプ)のコア部分がGPLに

－ 

A Movable Type(ムーバブルタイプ)のコア部分がGPLに

Movable Type(ムーバブルタイプ)のコア部分が、GPL(GNU General Public License)で公開された。Movable Type Open Sourceは、「Movable Type Open Source」という個別のソフトウェアで、Movable Type 基本ライセンス...

Movable Type(ムーバブルタイプ)のコア部分が、GPL(GNU General Public License)で公開された。

Movable Type Open Sourceは、「Movable Type Open Source」という個別のソフトウェアで、Movable Type 基本ライセンスや個人無償ライセンスで利用可能なMovable Type とは別のプロダクトとなる。ただし、ソースコードは、その他の商用版のMovable Type のコア部分とほぼ同等で、開発のプラットフォームとしての位置づけとなる。

また、開発プロセスのオープン化も行われ、ソースコードのバージョン管理システムである Subversion から、最新のソースコードを随時チェックアウト (ダウンロード) することが可能になる。

MTOS: Movable Type オープンソース・プロジェクト

[154] Posted by buzei at 2007/12/14 03:22:28
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)