プログラミングの作業に何の価値も見出せなくなってしまったd金魚による日記 このページをアンテナに追加 RSSフィード

 iTunes Music Store(Japan) なかのひと あわせて読みたいブログパーツ
|

0001 | 00 |
2004 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2008 | 01 | 02 | 03 | 05 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 |
2010 | 03 | 04 | 06 | 07 | 09 | 10 | 11 |
2011 | 01 | 02 | 10 |
2012 | 04 |
2013 | 01 | 05 | 06 | 07 | 08 | 10 |
2014 | 02 | 03 | 05 | 09 |
2015 | 04 |
2016 | 09 | 11 | 12 |
はてな一覧
アンテナに追加
私のアンテナ
私のダイアリー
私のアーカイブ
私のアイデア
私のブックマーク
私のグループ
私のキーワード
ニュース系、今まで続いているシリーズモノの読み物
dKingyo Utility Toolkit Projectのリリース情報
やっぱり暗号化は大人の味(笑)
プログラムのパッキング方法を調べよ
ココが厳しいよMinGW
ライブラリアン通信
ゲームプログラミングどうしよう
CRCについて
ビット演算練習
d金魚の今更Ajax
Windows Tips
VC6 Tips
Win32 WTL Tips
Ruby for C++ User
Ruby Tips
今日のRubyで嵌った事
正規表現PIECE
書きかけ
続く・・・

私のダイアリーの人気記事
新しくブックマークされた記事


あまり、役に立たなそうな個人的に調べた情報や妄想に耽った事、今 勉強している事ヒソヒソと公開していたりします。 | 登録してくれている方々 | d金魚にメール | 当サイトは640x480の画面解像度に対応しています。
日記へのリンク、アンリンクはフリーですが、selfタグのついている部分のコンテンツの引用はご遠慮願います。ご協力よろしくお願いします。


 | 

2007-05-31 最近のプログラミング的活動 2007年5月

[][]XSLT,SQLRuby on RailsXSLT,SQLやRuby on Rails等を含むブックマーク XSLT,SQLやRuby on Rails等のブックマークコメント

Powered by dKingyo Rails | C++ | プログラミング言語 | アセンブラ | Python

Ruby on Rails

SQL

XSLT

などを中心に学習しています。

少し経ったら面白いものが完成しそうです。

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070531

2007-05-27 SQLiteって遅くない? PART.2

[][]SQLiteって遅くない? PART.2 SQLiteって遅くない? PART.2を含むブックマーク SQLiteって遅くない? PART.2のブックマークコメント

Powered by dKingyo Cisco技術者 | アルゴリズム | Rails | コンパイラ | GNU

 という事で、私が使っているSQLiteDBファイルを使用しているソフトDBファイルを読み込むテストを行ってみた。

 使用するソフトgoogle:SQLite ControlCenter(今回の記事で使ったのは日本語版)

このソフトDBファイル(ここではとあるテーブル内に約10000個のデータが入っているファイル)を読み込ませて最大行数を1000にして

SELECT * FROM テーブル名

そうした結果

Exec Time : 1392 [msec]
Total Time : 48670 [msec]

なのだが・・・この結果は・・・おそらくTotal TimeGUIリストに挿入する処理で時間がかかっているのだろうと予測する。*1では、もう一回・・・

Exec Time : 511 [msec]
Total Time : 52105 [msec]

幾分Exec Timeは良くなったけど・・・。

 なんというか、コンピューターにとって1秒かかる処理というのはとても大きい時間だ。もちろんそれが半分になったとしても・・・一気にデータを読み込む処理は何と遅いんでしょう!!!

 私はSQLiteのこれが遅くてたまらないと感じているのだ。おそらく、このように一気に読み込ませるような処理はリレーショナルデータベースSQLiteとしては向いていないのでは・・・と思ってしまった。*2

 実はこのテストではまだ私は腑に落ちないので別のテストを敢行する予定だ。


続く・・・

*1:こういう根拠の無い予測情報の真意を混乱させるので良くないのは承知の上だが・・・これを(1)とおく

*2:これも(1)の理由と同じく・・・

きさらきさら 2007/06/09 17:00 SELECT * FROM テーブル名 ってデータベースのベンチマークとして実行して意味があるのでしょうか?
そんな処理をDBにさせるぐらいだったら、普通のファイルで十分な気がします。その方がオーバーヘッド少ない分速いでしょう。

studiokingyostudiokingyo 2007/06/16 20:53 仰せのとおりです。
ですが、実際にそのように処理していると思われるソフトウェアを愛用してしまっているため、そのオーバーヘッドがどこにあるのか予想してみようという企画です。
なにかしらの発見があればとSQLiteに様々なテストをしてみるつもりです。

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070527

2007-05-26 d金魚が薦めるHDDケース

[][][]私が薦めるHDDケース 私が薦めるHDDケースを含むブックマーク 私が薦めるHDDケースのブックマークコメント

Powered by dKingyo PHP | 逆引きハンドブック | アセンブラ | 画像処理 | TurboGears


http://www.marshal-no1.jp/products/MAL-0435.html

via http://dkiroku.com/2007-05-23-10.html

がとても魅力的である。

 私の日記を精読してくれているのであれば知っている方も多いと思うが、記録媒体としてはアクセス速度の速いHDDが好きである。

 今までHDDケースというのは何処のメーカーだかはっきりしない格安HDDケースを買っていたのだが、HDDは熱に弱いのである。よって冷却ファンのついたHDDケースがあれば魅力的だと思っていたのだが、そういう機能を付属したものに限っていきなり値段が高くなるのである。そんなジレンマを抱きつつも最近魅力的な製品を見つけたという次第である。


 HDDは独断と偏見Seagateと決めている。次点TOSHIBA、評価が分かれるSUMSUNGHDDなどもバイト単価がHDD内で一番安いという理由で使っている。*1ちなみにHDDを買うのなら初期不良をしっかりチェックして販売してくれるお店で買うのがセオリーである。

*1:どうせ消耗品だしHDDは・・・

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070526

2007-05-25 Visual C++ Tips PART.5

[][]VC6 Tips / ビルドエラー情報を元にソースコードを素早く参照 VC6 Tips / ビルドのエラー情報を元にソースコードを素早く参照を含むブックマーク VC6 Tips / ビルドのエラー情報を元にソースコードを素早く参照のブックマークコメント

Powered by dKingyo WEB DB PRESS | Access | Eclipse | 明快入門 | WEB DB PRESS

--------------------構成: test - Win32 Debug--------------------
コンパイル中...
test.cpp
a:\test.cpp(20) : error C2065: 'exit' : 定義されていない識別子です。

と表示されるビルドログウィンドウを選択してF4キーを押すと順にエラー個所のソースを表示してくれる。

 初めて知った。ちょっと便利かも・・・ちなみに「error C2065」とある所の「C2065」を選択してF1キーを押すとMSDNで「C2065」のエラーコードを参照できる。初心者のうちはこれでエラー原因を知ることができるが、中には説明が短くて難解なエラーコード情報英語でしか提供されていないエラーコード情報がまったくないエラーコード存在するのだが、存在しないエラーコードを出現させるようになれればかなり「使い込んだ感」を感じる。


 余談だが、上記のビルドログをPREタグで囲って表示すると以下のようになる。ちょっと笑ってしまった。

続きを読む

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070525

2007-05-24 Visual C++ Tips PART.4

[][]VC6 Tips / 素晴らしきかなVC6のテキストエディタ VC6 Tips / 素晴らしきかなVC6のテキストエディタを含むブックマーク VC6 Tips / 素晴らしきかなVC6のテキストエディタのブックマークコメント

Powered by dKingyo CG彩色テクニック | 画像処理 | ポケットリファレンス | プログラミング言語 | ソフトウェア開発技術者

 VC6のDeveloper Studioテキストエディタバグもちで有名だ。ファイルサイズが大きいソースコードファイル、特に1MBを超えるソースコード編集なんかには危なっかしくて使ってられない。動作が重い事や編集中に内部処理により固まってしまう事、変な所に文字が挿入されたり、上書きされたり、最悪の場合はソースコード丸ごとがブルースクリーンと共に消えてしまうのである。

 これは残念にも程がある。だが、それでも私はVC6を使っている。分割コンパイル様様である。そろそろEmacsなりVimなりに乗り換える時期だとは思っているのだが・・・。

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070524

2007-05-23 ブロガーへの提言 PART.2

[][][]ブログデザインに関する10のチェックリスブログのデザインに関する10のチェックリストを含むブックマーク ブログのデザインに関する10のチェックリストのブックマークコメント

Powered by dKingyo Rails | プログラミング言語 | VB2005 | PHP | アルゴリズム


■表示領域を狭めた場合でも見やすいデザインを保っているかどうか。

チェック方法:

IE6の場合お気に入りや履歴を表示してその領域を広くする。


様々な画面解像度*1でも見やすいデザインを保っているかどうか。

特に最近普通ディスプレイでは表示できない規格外の縦長の液晶ディスプレイが出てきているのでそれにも対応できるように努力できると望ましい。


フォントの設定が適切かどうか。

参考:

http://loconet.web2.jp/blog/archives/2007/02/cssfontfamily.html


CSSのline-height設定と一緒にfontタグにsize指定を使っていないかどうか。

例:

f:id:studiokingyo:20070526113158j:image:w251

チェック方法:

CSSのline-height設定とfontタグをsize指定で囲った文字(改行が含まれている事がチェックする上で望ましい)のスタイルが「文字のサイズ」*2をどのように設定しても文字が重なって表示されないかどうかを確かめる。


■img,iframeタグで表示される領域がサイドバーと接触していないかどうか。



ごめん。眠いから思い出せない。よって募集中・・・。

*1:640x480 800x600 1024x786等

*2IEにおける

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070523

2007-05-22 SQLiteって遅くない?

[][]SQLiteって遅くない? SQLiteって遅くない?を含むブックマーク SQLiteって遅くない?のブックマークコメント

Powered by dKingyo CG彩色テクニック | 画像処理 | アセンブラ | DTM | Access

なんかSQLiteを使ったアプリケーションってデータベース更新や参照にとても時間が取られている気がするのだが・・・。

事実、それらを使ったアプリケーションの表示が遅くなったりする。

名前のとおり動作が軽いイメージがするが全然LiteではなくHeavyなのだ。

私の場合3000件を超えたあたりでストレスを感じるようになった。いったいどうしてなのだろう。アプリケーションの問題・・・とは考えられないと感じているのだが、どっちつかずなのでとりあえずはSQLiteが遅いと決め付けるのは早計だろう。

よって・・・


続く・・・

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070522

2007-05-21 「ビルゲイツの面接試験ネタに便乗」を今更ながら解いてみた。

[]「ビルゲイツ面接試験ネタに便乗」の非数学的?アプローチ 「ビルゲイツの面接試験ネタに便乗」の非数学的?アプローチを含むブックマーク 「ビルゲイツの面接試験ネタに便乗」の非数学的?アプローチのブックマークコメント

Powered by dKingyo Graphic Gems | WEB DB PRESS | Graphic Gems | はじめての | C言語

http://tkido.blog43.fc2.com/blog-entry-161.html

より

via http://sfuhiro.seesaa.net/article/22420470.html


上に行くにも下に行くにも確率は同じなのでこの確率については考えない。

段は

1 2 3 4 5 6 7

のようになっている。

4段目から始めれば両者の確率は等しい

その着眼点

123 | 567

で両者の数が同じだからである。

この法則に則って5段目からだとすると

12 34 67

と分けられる。分け方が3つあるうちの5段目にいるわけだから

12 34 | 67 

7段目の方に行くには 1/3

1段目の方に行くには 2/3

となるが、行きやすい方を確率とするので

7段目の方に行く確立は2/3

1段目の方に行く確立は1/3


よって棒人間君が生還できる確率は3分の2の確率である。


なんというか、我ながら残念なアプローチ・・・おrz

しかも証明になってないし・・・

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070521

2007-05-18 私の日記に訪れた人が好みそうな時計

[][]プログラマーが好みそうな時計 プログラマーが好みそうな時計を含むブックマーク プログラマーが好みそうな時計のブックマークコメント

を、列挙してみました。

個人的主観ですが

が条件だと思いました。

という事で、以下のURLをどうぞ・・・

http://www.amazon.co.jp/exec/obidos/ASIN/B000KDN73Y/studiokingyo-22

http://www.amazon.co.jp/exec/obidos/ASIN/B000KDP1VU/studiokingyo-22

http://www.amazon.co.jp/exec/obidos/ASIN/B000IIILCI/studiokingyo-22

http://www.amazon.co.jp/exec/obidos/ASIN/B000IKSLE4/studiokingyo-22

http://www.amazon.co.jp/exec/obidos/ASIN/B000AQX8FS/studiokingyo-22

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070518

2007-05-16 booklog.jpが使いにくい

[][]booklog.jpが使いにくい booklog.jpが使いにくいを含むブックマーク booklog.jpが使いにくいのブックマークコメント

Powered by dKingyo シスアド | Rails | Catalyst | HTML | CG彩色テクニック


今まで、本に関するメモhttp://booklog.jp/users/studiokingyoの方に行っていたのだが、どうも登録している本の量が増えてくるに従って編集が大変な事になった。リストとして挙げると

  • カテゴリ編集する際に更新を押すと一番最初のページに戻ってしまう
  • 登録している内容をカテゴリ毎に表示、編集できない。
  • 登録している内容を編集しにくい。
  • 登録している内容を検索できない。
  • ISBNでないと登録できない。

と、あるようにこれらは私にとってネガティブな要因になる。

このくらいのものであるならば自分で作ってしまうのが手っ取り早いような気がしてきた。

XML規格作って(既にあるならばそれを流用)、それを元にViewやSearchするプログラムを組めばよいわけだ。

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070516

2007-05-15 ブロガーへ提言 PART.1

[][]ブロガーへの提言 スタイルシートブロガーへの提言 スタイルシート編を含むブックマーク ブロガーへの提言 スタイルシート編のブックマークコメント

Powered by dKingyo TOEFL 突破 | GNU | TOEFL 突破 | Visual Basic | ソフトウェア開発技術者

ブロガー諸君!!!

640x480や800x600という低解像度にしてブラウザで自分のブログを見たまえ!!!

サイドバーで記事が見えにくくなっていないか!!?

スタイルシートの影響で記事のフォーマットが崩れていないか!!?

そうでないならば問題ないが、往々にして崩れているのだよ!!!


IE6を使っているなら「お気に入り」を表示させておもいっきりお気に入り部分のサイドバーを広くしてみよう!横スクロールバーが表示されずに自分のブログの配置などのスタイルが崩れたらそのブログスタイルシートは欠陥があるということだ。*1

また、よくあるのがサイドバーがあることによって本文が切れて表示されてしまう事。*2これもサイドバーを使ったブログによく見られる現象である。


私がサイドバーを使わない理由の一つとしてその手の対応から逃れるためというのもあるのだ。

[][]私が良く訪れているブログにて・・・ 私が良く訪れているブログにて・・・を含むブックマーク 私が良く訪れているブログにて・・・のブックマークコメント

 サイドバーの問題が解消されていました・・・。いや、つい最近までサイドバーの問題はあったはずなのだが・・・。この記事がそんなに影響を与えているとは思えないのだが・・・。ちょっとしたgoogle:百匹目の猿現象

 でも、一番解消されて欲しい某超有名記事サイトはお気に入り部分を広くすると未だにサイドバーの下に記事が表示されるという状態になっている。これだと下にクスロールする量が一苦労を通り越していますよ。まぁ、このようなマイナーサイトを超有名記事サイトの管理者が見るわけ無いか・・・百匹目の猿現象が千匹目になるのを願うばかり。

 さて、これよりアイディアブラウザが沢山登場する中で、ブラウザスタイルシートJavaScriptの動作状況などを気軽にPOSTできるフォームがあれば便利だと思った。この手のことをブログコメントに書き込むのも憚られるし。

*1環境依存というのもあるかもしれないがデファクトスタンダードのIE6ですらそうなってしまう。私の通っているブログサイトで特に見られる現象である。

*2:特にソースコード等、おそらくはpreが関係しているのかもしれない

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070515

2007-05-14 「未経験から・・・」の誤解

[][]未経験からWebクリエーター未経験からWebクリエーター?を含むブックマーク 未経験からWebクリエーター?のブックマークコメント

Powered by dKingyo AJAX | Rails | Perl | TOEIC 突破 | Python

そう。あのバナーである。(あえて、図示はしないが・・・)

このバナーに載っている顔写真がバナーを掲載しているブログの著者であるかのようで誤解してしまうのだ。

なんとなくこのバナーは卓逸なデザインだと感じた。

俗に言うアルファブロガーブログにはたいていこのバナーが貼り付けられているので私の中ではちょっとしたブームである。

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070514

2007-05-05 子供の日には二分木を対戦させるならわしがあります

[][]Red Black Tree 対決 Red Black Tree 対決を含むブックマーク Red Black Tree 対決のブックマークコメント

Powered by dKingyo Rails | ソフトウェア開発技術者 | GPU Gems | 画像処理 | C言語

某氏が公開していたRed Black Treeの実装と既存のRed Black Treeの実装を対戦させてみた。

インクリメントキ

1	/ Challenger red black tree delete	/ 2035
2	/ red black tree insert	/ 54441
3	/ STLport red black tree delete	/ 78082
4	/ Challenger red black tree insert	/ 101272
5	/ STLport red black tree insert	/ 140324
6	/ red black tree delete	/ 181662

ランダムキー

1	/ Challenger red black tree delete	/ 5127
2	/ red black tree delete	/ 18825
3	/ red black tree insert	/ 96301
4	/ Challenger red black tree insert	/ 108134
5	/ STLport red black tree insert	/ 118734
6	/ STLport red black tree delete	/ 188965

deleteが異様に早い。

某氏のソースコードを見てみたが、理解するには1日つぶしそうだ・・・。



さて、このテストをやっていて気付いた。

dkutil_cのred black treeがランダムな要素をキーとしdeleteする時に内部に格納していたデータが入れたデータと違っているという現象が発生したのだ。これは忌々しき事態だ。

dkutil_cはかなりバグチェックは行っているはずなのだが・・・

要素を二重削除していたのでバグっていました。dkutil_cのミスではなく完全にプログラミングしている私のミスでした。

トラックバック - http://d.hatena.ne.jp/studiokingyo/20070505
 | 
Program | Debug | dKingyo Utility Toolkit | library | D言語 | 御本とか | 備忘録 | テクニック | WayBack | 格言 | 英語 | 他力本願 | news | software |

デースケドガー