[開発ツール]の検索結果
ニコニコ動画はニワンゴが提供している動画に自由にコメントをつけて楽しめるサービスで、当初はYouTubeなど他の動画共有サイトの動画にコメントをつけるサービスとして開始され爆発的な人気を博した。しかし、YouTubeからアクセスを遮断されたため、一時サービスの中断を余儀なくされ、会員制でユーザー数を制限しつつ独自の動画共有サービス「SMILEVIDEO 」に移行することで、サービスを再開した。日本では動画共有サービスとして一時はYouTubeを上回る人気となったが、現在はYouTubeに抜かれユーザーは減少している。
2007年6月には、ニコニコ動画普及委員会のメンバーがオンライン上、オフライン上で議論を重ね結果をまとめた、ニコニコ宣言(仮)を発表している。
ニコニコ動画(RC2)
ニコニコ動画 開発者ブログ（新着情報）
ユーザ同士の質問＆交流掲示板
ニコニコ動画に関するサイト
NicoPlayer
ニコニコ動画の動画をコメント付きで再生するソフト。動画とコメントのダウンロード、コメントフィルタ機能でNGワードなど表示するコメントの制御や修飾も行うこともできる。
ニコニコ動画保存ツール 「SmileDownloader」
ニコニコ動画やYouTubeの動画を IEの右クリックメニューから簡単に保存できるダウンローダー。
Vid-DL - 動画ダウンロード保存支援ツール
動画共有サイトの動画をファイルに保存するツール。Youtubeやニコニコ動画のほか多数の動画サイトにも対応している。
チューブ＆ニコ録画
YouTubeやニコニコ動画をパソコンにダウンロードする有料ソフト。
2007年6月には、ニコニコ動画普及委員会のメンバーがオンライン上、オフライン上で議論を重ね結果をまとめた、ニコニコ宣言(仮)を発表している。
ニコニコ動画(RC2)
ニコニコ動画 開発者ブログ（新着情報）
ユーザ同士の質問＆交流掲示板
ニコニコ動画に関するサイト
NicoPlayer
ニコニコ動画の動画をコメント付きで再生するソフト。動画とコメントのダウンロード、コメントフィルタ機能でNGワードなど表示するコメントの制御や修飾も行うこともできる。
ニコニコ動画保存ツール 「SmileDownloader」
ニコニコ動画やYouTubeの動画を IEの右クリックメニューから簡単に保存できるダウンローダー。
Vid-DL - 動画ダウンロード保存支援ツール
動画共有サイトの動画をファイルに保存するツール。Youtubeやニコニコ動画のほか多数の動画サイトにも対応している。
チューブ＆ニコ録画
YouTubeやニコニコ動画をパソコンにダウンロードする有料ソフト。
バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、品質が低い状態でリリースされてしまうことになります。テストを円滑に進めソフトウェアの品質の高めていくためには、バグを迅速かつ正確にバグを修正していく必要があります。
しかし、オブジェクト指向プログラミング（OOP）やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。
知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。
1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。
2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。
3. 問題を確実に再現できるようする
問題が発生する条件（操作手順、データなど）を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。
4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。
5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。
6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。
7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。
8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。
9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。
しかし、オブジェクト指向プログラミング（OOP）やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。
知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。
1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。
2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。
3. 問題を確実に再現できるようする
問題が発生する条件（操作手順、データなど）を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。
4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。
5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。
6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。
7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。
8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。
9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。
Cygwin（シグウィン）とは、マイクロソフトのOSであるWindows上で動作する無料のLinuxライクな環境の一つで、GNUの開発ツールをはじめとして、UNIX向けのさまざまな標準ツールがWindows上で利用できるようになっている。
Cygwin の開発は1995年から Cygnus Solutions によって始められたが、その後、Linuxディストリビューターとして知られるRed Hatに買収され、現在は Red Hat Software の一部門となっている。
Cygwin（シグウィン）のセットアップ方法や使い方を解説しているサイト
Using Cygwin.Cygwinのセットアップと設定についての日本語による解説。
Cygwin JE
Cygwinに日本語化/国際化されたソフトウェア等を提供するパッケージ集。
Cygwin Translation Library(Cygwin 文書図書館(翻訳館))
Cygwin 本家サイトで公開されているドキュメントの日本語訳など。
Cygwin Information and Installation
Cygwinの本家サイト。（英語）
Cygwinの使い方
Cygwinの使い方を解説しているサイト。
バージル・グリフィス氏によって開発されたIPアドレスからWikipediaの編集履歴を調べるツール「Wikiscanner」によって、アメリカ政府機関やローマ法王庁を始めとする世界各地の政府機関、国際組織、大企業などがWiki...
Movable Type（ムーバブルタイプ）のオープンソース版（GPL）が今年（2007年）第三4半期にリリースされる予定になっているようです。Movable Type 4 の開発と、ベータテスト、オープンソースについてMovable Type（ム...
携帯コンテンツを作成・開発するためのツールがダウンロードできるサイトや技術情報が掲載されているサイト。NTT ドコモ（i-モード）iモードHTMLシミュレータ900iシリーズ以前のiモード対応HTML及びFlashで構成された...
XMLに関する書籍。XMLの入門書や技術的な解説書など。やさしいXMLXML文書の記述方法からXSLによる文書操作、さらにDOMとSAXを使った高度なJavaプログラミングまで、 XMLアプリケーションを構築するための基本技術を、...
Motorola、日本電気株式会社、NTTドコモ、パナソニックモバイルコミュニケーションズ、Samsung Electronics、Vodafone Groupの6社が、Linux（リナックス） OSによる携帯電話向けソフトウェアプラットフォームの構築を...
XAMP（エグザンプ）とは、Linux、Windows、Mac OS X、SolarisにApache、MySQL、PHP、Perlを一括してインストールできる無償のディストリビューションで、非営利組織プロジェクトApache Friendsが開発、配布している。...
サン・マイクロシステムズが、「Java Platform Standard Edition（Java SE）」と、「Java Platform Micro Edition（Java ME）」のソースコードをGNU General Public License version 2（GPLv2）で無償公開すると発表...
アクセスランキング
今日のアクセスランキング TOP 10
- 時間指定で仲値トレードも簡単にできる無料EA「NAKANE3 Ver 2.02」 (1 PV)
- SQLのSELECT文で先頭から上位（TOP）10件のレコードを取得する方法（SQL Server、Oracle、MySQL、PostgreSQL） (1 PV)
- MT4向けブレイクアウトEA「NEKONEKO（ネコネコ） FREE」（0.01ロット固定、無料、使用期限無し） (1 PV)
- [FX]高値更新・安値更新でエントリー、MT4向け無料スキャルピングEA「1Scalper」#システムトレード (1 PV)
今月のアクセスランキング TOP 10
- SQLのSELECT文で先頭から上位（TOP）10件のレコードを取得する方法（SQL Server、Oracle、MySQL、PostgreSQL） (1957 PV)
- 安全性重視の完全無料ナンピンマーチンEA「Million Dollar（ミリオンダラー）」 #FX #ゴールド #ビットコイン (346 PV)
- Google Finance（グーグルファイナンス）- リアルタイム株価情報、金融ニュース、日本株 (290 PV)
- MT4向けオープンソースナンピンマーチンEA「Automaton」 (172 PV)
- 自作のMT4向け無料EA（口座縛り無し、ブローカー縛り無し、使用期限無し）とゴゴジャン出品中の有料EAの一覧 #MT4 (156 PV)
- 完全無料のMT5用ナンピンEA「Nanpin K（ナンピンケイ） MT5」 (149 PV)
- [FX]高値更新・安値更新でエントリー、MT4向け無料スキャルピングEA「1Scalper」#システムトレード (146 PV)
- MT4向け1ポジアノマリーEA「DAY TRADING」オープンソースライセンス（GPL3）で公開 #ドル円 (131 PV)
- 完全無料のMT4向けナンピンEA「Nanpin K（ナンピンケイ）」 (122 PV)
- SQLiteのSELECT文で上位 (TOP) n件のデータを取得する (115 PV)
アクセス統計
ディレクトリ
関連サイト