タグ

2009年5月11日のブックマーク (6件)

  • Eclipseがエラーで起動しない

    JVM terminated. Exit code=-1 -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx512m -XX:MaxPermSize=256M -Djava.class.path=D:\eclipse\plugins\org.eclipse.equiox.launcher_1.0.100.v20080509-1800.jar -os win32 -ws win32 -arch x86 -showsplash D:\eclipse\plugins\org.eclipse.platform_3.3.100.v200806172000\splash.bmp -launcher D:\eclipse\eclipse.exe -name Eclipse --launcher.library D:\eclipse\plugins\org.eclips

    Eclipseがエラーで起動しない
    koroharo
    koroharo 2009/05/11
    eclipse
  • ハフマン符号化法

    ハフマン符号化法は文字だけで説明したので、この場で読むことが出来るようにいたします。 ファイル圧縮技術 -ハフマン符号化法の紹介- LHAってソフト、知ってますよね。ファイル圧縮ソフトです。たとえばフロッピーディスク2枚分のデータを、フロッピーディスク1枚に納まるようにしてしまいます。 なぜそんなことができるのでしょうか。 LHA付属のドキュメント・ファイルを読んでみます。 吉崎 栄泰「LHA取り扱い説明書」Ver.2.13 1991/07/20 NIFTY-Serve SDI00506 の 「0. はじめに」には >>アルゴリズムを動的ハフマン法から静的ハフマン法に変更したので、・・・・ という一文が書いてあります。 ハフマン法って何だろう。きっと、ものすごい数学技術を使っているんだろうな・・・と思っていたときに、たまたま読んだのがA・K・デュードニー「チューリング・オムニバス 第1巻

  • 例として推奨されているドメイン名とIPアドレス - あどけない話

    解説記事や発表資料で、ドメインの例を出す場合、example.jp等を使うことが推奨されているのを知っている人は多いでしょう。しかし、IPアドレスの方は知らない人もいるみたいです。ここでは両方について出典を示しながらまとめます。 知っていて別の例を使うのはいいのですが、知らないで別の例を使うのはよくないです。 gTLDのドメイン名の例 RFC2606で以下のように定められています。 3. Reserved Example Second Level Domain Names The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples. example.com exa

    例として推奨されているドメイン名とIPアドレス - あどけない話
  • いいコーディング規約、悪いコーディング規約? | スラド デベロッパー

    格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。 可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか? ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか? /.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか? 逆に規約のせいで問題が起きてしまったケースなどあるだろうか? 他にも、使える「自分ルール」などもあれば是非。

  • 将来しなくても良くなるコーディングテクニック | スラド デベロッパー

    もうやらなくていい昔のコーディングテクニックあれこれという話題がありました。過去は過去として振り返るのは有効ですが、それを踏まえた上で、将来しなくても良くなるコーディングテクニック、というのは何でしょうか ? IDE や言語環境の改善により、人間が無駄なことをしなくて済む環境は整いつつあるも、まだまだ改善しなければならない部分は多い。そんな環境改善に伴い、今は行っているけど将来的には意味が乏しくなるコーディングテクニックというのを語り合うのも面白いのではなかろうか ? 日頃の不満点、こうなったらいいな、など色々思いはあるでしょうが、コーディングテクニック関連の雑談ということでは丁度良い機会でもあることだし、忌憚無い意見をお聞かせ下さい。

  • もうやらなくていい昔のコーディングテクニックあれこれ | スラド

    ソフトウェア開発は複雑なものだが、年月とともにその開発プロセスは改善されてきたと言えるだろう。「熟練の」プログラマーであればマニュアルチューニングなどを行ったことも記憶に残っているだろう。しかし今日の開発ツールは、昔であれば手で書かなければならなかったような複雑な機能を自動的に行ってくれたりする。多くの開発者はこれを歓迎している。すでに若いナマイキな奴は、我々のような時代遅れの人間がこれらのことを手で行っていたと気付かないかもしれない。 Esther Schindler氏は古株プログラマーらに「頭痛の種だった昔のプログラミングテクニック」について尋ね、自身の経験も交えた記事をComputerWorldに掲載している。パンチカードとか、ハンガリアン記法とか、覚えているだろうか? 元記事に挙げられている「頭痛の種」には(バブルソートなどの)ソートアルゴリズム、リンクリストやハッシュテーブルの実