[バグ]の検索結果

＋ 

A NetaCha（ネタ＋非同期チャット）というサイトを作りました

－ 

A NetaCha（ネタ＋非同期チャット）というサイトを作りました

NetaCha（ネタ＋非同期チャット）というサイトを新しく作成しました。NetaChaは、ニュースや動画、画像などのさまざまなネタ（登録ユーザーのみ作成可能）に対し、閲覧者が短いメッセージを投稿していく形式のコミュ...

NetaCha（ネタ＋非同期チャット）というサイトを新しく作成しました。

NetaChaは、ニュースや動画、画像などのさまざまなネタ（登録ユーザーのみ作成可能）に対し、閲覧者が短いメッセージを投稿していく形式のコミュニティサービスで、メッセージの投稿にユーザー登録などの手続きは必要ないため、すぐに同じテーマに関心を持つ人とのコミュニケーションが楽しめます。

というのが一応の狙いです。掲示板よりも書き込みやすいのではないかと思ってます。

ただし、作ったばかりなのでまだバグが多いかもしれません。

[1329] Posted by kagahiro at 2009/05/19 09:33:19
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A Debug Hacks デバッグを極めるテクニック＆ツール

－ 

A Debug Hacks デバッグを極めるテクニック＆ツール

ミラクル・リナックスのエンジニアによって書かれた「DEBUG HACKS」という本の出版を記念して、Debug Hacks Conference 2009 というイベントで著者による講演が行われるそうです。Debug Hacks Conference 2009のお知...

ミラクル・リナックスのエンジニアによって書かれた「DEBUG HACKS」という本の出版を記念して、Debug Hacks Conference 2009 というイベントで著者による講演が行われるそうです。

Debug Hacks Conference 2009のお知らせ

日時：4月23日、18時半開場、19時開始
場所：IIJ大会議室
http://www.iij.ad.jp/info/map/head-office.html
〒101-0051 東京都千代田区神田神保町1-105 神保町三井ビルディング
定員：100名
無料

既に定員の100人に達しているので今から申し込んでも出席できる可能性はほとんどないですが、キャンセル待ちでもよいという人は申し込んでみてはいかがでしょう。

ちなみに、内容的には惹かれるものもあるのですが、私が講演会に行く予定はありません。本はそのうち買うかもしれません。

Debug Hacks -デバッグを極めるテクニック&ツール
ミラクル・リナックスのエンジニアたちが、Linuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技などが披露されている。
著者：吉岡 弘隆,大和 一洋,大岩 尚宏,安部 東洋,吉田 俊輔
価格：3,360円
オライリージャパン

[1289] Posted by kagahiro at 2009/04/14 06:01:25
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A 59Tracker 2.2 を公開しました

－ 

A 59Tracker 2.2 を公開しました

オープンソースソフトとして公開しているソーシャルブックマーク機能搭載のブログソフトウェア「59Tracker」の最新版「59Tracker 2.2」を公開しました。「59Tracker 2.1」からの変更点は、検索時に「次のページ」が正...

オープンソースソフトとして公開しているソーシャルブックマーク機能搭載のブログソフトウェア「59Tracker」の最新版「59Tracker 2.2」を公開しました。

「59Tracker 2.1」からの変更点は、検索時に「次のページ」が正しく表示されない不具合の修正のみです。ファイルとしてはsearch.cgiのみ更新されています。

59Tracker 2.2 (UTF-8) 最新版


大きなバグ・・・、なんで今まで気がつかなかったんだろう。

[1246] Posted by kagahiro at 2009/02/05 23:40:31
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A グループブログは個人ブログより敷居が高い

－ 

A グループブログは個人ブログより敷居が高い

「livedoor Blog」の管理画面が大幅にリニューアルされて使いやすくなってます。もっとも、まだいろいろ不具合（バグ）はあるようですが・・・新管理画面の不具合状況と、未対応機能についてそれはそうと、今回のリニ...

「livedoor Blog」の管理画面が大幅にリニューアルされて使いやすくなってます。もっとも、まだいろいろ不具合（バグ）はあるようですが・・・

新管理画面の不具合状況と、未対応機能について

それはそうと、今回のリニューアルでひとつのブログをグループ(複数のメンバー)で運営することが可能な「グループブログ機能」が導入されているのですが、そう簡単にライブドアが期待しているように「ブログ更新に対するモチベーションの向上」してブログの更新頻度が増えるということは無いと思います。

個人ブログであれば自分が記事を書けば良いだけですが、グループブログの場合当然ですが、メンバー集めをしなければならないからです。このメンバー集めは社内ブログのように始めからグループが存在するのであればともかく、個人でブログを書いているようなブロガーにとってはかなり荷が重いと思われます。

もちろん、うまくメンバーを仲間を集めることができればコンテンツの内容を充実させることはできると思うので、複数のメンバーで一つのブログを運営する機能はブログソフトウェアには必要だとは思いますが、単に複数のメンバーで記事が書ける機能だけでなく、メンバー集めをサポートするような機能も必要なのではないかと思っています。

というわけで、59Trackerには、ソーシャルブックマーク機能を 付けているわけですが、「語句ログ」を例に挙げると、ゼロではないですがそれほど登録ユーザー が多いわけではないので、ネット経由で参加者を増やすためにはもう少し工夫する必要がありそうです。

ライブドアが「livedoor Blog」をリニューアル、グループブログ機能を強化

[1244] Posted by kagahiro at 2009/01/29 02:33:01
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A 進ちょく管理サービス「fixdap(フィックスダップ)」

－ 

A 進ちょく管理サービス「fixdap(フィックスダップ)」

ライブドアが、業務の進行管理から同窓会の出欠管理などに使える無料の進ちょく管理サービス「fixdap（フィックスダップ）」の提供を開始した。「fixdap」は、システム開発などの分野でプロジェクトのバグを登録し、...

ライブドアが、業務の進行管理から同窓会の出欠管理などに使える無料の進ちょく管理サービス「fixdap（フィックスダップ）」の提供を開始した。

「fixdap」は、システム開発などの分野でプロジェクトのバグを登録し、修正状況を管理する「バグトラッキングシステム（BTS）」のひとつで、各プロジェクトに関わる複数の参加者で使用し、サイト上で各自の担当業務や締切、進行などを一元的に管理し、参加者全員で進ちょく状況を確認することができる。また、画像などの各種データをサイト上に置くこともでき、関連資料をまとめて管理することが可能となっている。ライブドアが以前から自社内でのソフトウェア開発やプロジェクトの進ちょく管理にBTSを利用していた経緯から、そのノウハウを活かし、自社で活用していたものに改良を加え、新サービスとして公開した。利用は無料の会員登録（PC版からのみ）が必要で、登録後は、携帯電話からモバイル版の閲覧も可能。

ライブドアでは、ウェブサイト開発に関わる中小のネット関連企業や、同窓会や学生サークルなどでイベントを主催する幹事が進ちょく管理のツールとして使用することを想定し、一般・企業ユーザー双方からの利用を拡大し、将来的には企業向けの有料販売や海外展開につなげる予定としている。

ライブドア、無料サービス「fixdap(フィックスダップ)」を開始。新規事業の社内公募制から生まれた第1弾企画
タスク共有ツールの決定版 - fixdap

バグトラッキングシステム（BTS）を作業管理に使うのは良いとは思うのですが、残念ながら、最近特にセキュリティに過敏になっている企業で利用されることはないと思います。個人やコミュニティ、オープンソースプロジェクトなどの作業管理には使えると思います。とりあえず、「掲示板ソフト 59bbs の開発」というのを作ってみました。「確認」ステータスの使い方はよくわかりませんが、タスクのステータスの遷移がシンプルなのがいいですね。「完了」があるなら「確認」はいらないと思います。

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか 著者：エドワード・ヨードン 日経BP社 by Amalink

[1142] Posted by kagahiro at 2007/12/19 05:30:07
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

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

－ 

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

残念ながらソフトウェアが魔法のように出来上がるなんてことはありません。プログラミングは一つ一つコードを書いていくだけですし、デバックは一つ一つバグを潰していくだけ、テストは一つ一つはプログラムが仕様ど...

残念ながらソフトウェアが魔法のように出来上がるなんてことはありません。

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

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

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

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

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

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

[1127] Posted by kagahiro at 2007/12/04 00:17:15
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A YSTでサイトが正しく評価されない不具合？

－ 

A YSTでサイトが正しく評価されない不具合？

2007/10/31のYahoo!インデックス更新以降、トップページの検索順位が下がる現象が発生しているようですが、その原因はYahoo!の検索エンジン「YST」では不具合ではないかということです。YSTのバグどうもYSTでは、階層...

2007/10/31のYahoo!インデックス更新以降、トップページの検索順位が下がる現象が発生しているようですが、その原因はYahoo!の検索エンジン「YST」では不具合ではないかということです。

YSTのバグ

どうもYSTでは、階層と順位が逆転したときにはアルゴリズムに沿って正しいサイトの評価がされない可能性がある。基本的に各検索エンジンのアルゴリズムの中身は、それぞれの会社が決定権を持つことであるから、それによって下層ページが上層ページよりも評価が高くなったとしてもそれ自体には外部のものが口を挟む問題ではない。しかし、明らかに関連する数値に誤りがある以上は是正を行うべき余地が有ると考える。

検索結果で確認してみるこのサイトも階層と順位が逆転しているようなのでひとごとではなさそうです。下の階層にブログがあってブログの方の被リンクや更新頻度が高いので、階層が低いページの順位が高いのはしょうがないのですが、Yahoo!経由でのアクセス数が激減しているので何とかしたいところです。

ただ、通常Dのように評価の低いページがCよりも高い評価を受けることは考えにくい。ではどのような場合が問題となるのであろうか。これに関しては幾つかの可能性を留保するという前提つきであるが、更新頻度の高さが関係しているように思える。例えば物品販売系や情報系のサイトであれば新着情報や場合によってはサイトマップ、ブログなどであればフィードなどもこれに含まれる。これらはサイト内のどこが更新されようともそれに伴って更新されるからである。そしてその分クロールの頻度も高いであろうし、SEOに関心のあるサイトであればロボット用のサイトマップなどで更新を知らせているのであろうから更に頻度は高くなって当然であろう。

不具合の条件としてクロール（更新）の頻度が影響しているのではないかということなので、とりあえず以下の対策を行なってみました。

• トップページをブログの更新と連動して動的に更新されるようにする。
  
• サイトマップのchangefreq、priorityを変更しトップページのクロール頻繁、優先度を上げる。

これでなんとかなってくれればよいのですが・・・

ヤフーのトップページ下落ペナルティ(TDP)の確認法 - 1000番目にも出てこない意味

Yahoo!の検索結果が意図的に操作されているというのであればどうしようもないのは言うまでもありません。

[1113] Posted by kagahiro at 2007/11/09 04:36:46
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A SourceForge（ソースフォージュ）

－ 

A SourceForge（ソースフォージュ）

SourceForge（ソースフォージュ）は、オープンソース・ソフトウェアの開発者にCVS/SVNリポジトリ、Wikiシステム、メーリングリスト、バグ追跡システム、掲示板・フォーラム、タスク管理システム、 Webサイトホスティ...

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

SourceForge.jp

[1094] Posted by kagahiro at 2007/10/17 03:59:35
0 point | Link (2) | Trackback (0) | Comment (0)

＋ 

A デバッグを効率的に行なうための９の心得

－ 

A デバッグを効率的に行なうための９の心得

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

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

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

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

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

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

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

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

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

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

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

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

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

[1067] Posted by kagahiro at 2007/09/10 05:49:45
1 point | Link (3) | Trackback (0) | Comment (1)

＋ 

A 「アマゾンアフィリエイト」画像付き商品リンク作成ツール「Amalink」

－ 

A 「アマゾンアフィリエイト」画像付き商品リンク作成ツール「Amalink」

ブログ等に貼り付けるためのアマゾンの商品リンクを、Amazon ECS のRESTリクエストを利用して、画像付きで生成するフォームを作成しました。商品のASINとアソシエイトIDを入力して作成ボタンをクリックすると画像付き...

ブログ等に貼り付けるためのアマゾンの商品リンクを、Amazon ECS のRESTリクエストを利用して、画像付きで生成するフォームを作成しました。商品のASINとアソシエイトIDを入力して作成ボタンをクリックすると画像付きのアマゾン商品リンクが作成されます。

Amalink - 「アマゾンアフィリエイト」画像付き商品リンク作成ツール

ソースファイル（amalink.cgi、amalink.htmlt）も公開しておきますので、レイアウトや表示内容が気に入らない場合は適当にカスタマイズしてください。文字エンコードはUTF-8。perl 5.8 以降に対応。JavaScriptも少し使ってます。

参考：
Amazon ECS 4.0　解説1 RESTリクエストのパラメータ
Perl 5.8でUTF-8の文字コードを扱う

(追記あり)

[1053] Posted by kagahiro at 2007/06/22 07:08:00
3 point | Link (3) | Trackback (0) | Comment (3)