タグ

ブックマーク / odz.hatenablog.com (10)

  • 低レイヤ以外の技術ってそんなに軽いのか - odz buffer

    えーっと、誰かのおもりをするためだけに飼われている社畜はいません(少なくともうちの会社には)。ソフト屋が誰かに助けてもらうことを前提としてソフトウェア関連スキルのポートフォリオを組むのはやめた方がいい。最初はいい。分からないこともあるだろう。誰かと協力しなきゃ解決できない問題もあると思う。でもアーキテクチャ固有の脂っこい問題だけ誰かに丸投げして押しつけておいて、"私はプロのソフト屋でござい"ってのはちょっと虫がよすぎるように思う。 だから、そういう仕事ばかりじゃないわけですよ。極端な話、Linux + Apache + MySQL + PHP*1 な仕事もあって、そういう場合、gdb で apache のプロセスを attach して mod_php のアセンブリレベルデバッグを始めたりははしないんですよ、普通は。何か問題があってもたいていはソースレベルデバッグで済むでしょ。なにか、epo

    低レイヤ以外の技術ってそんなに軽いのか - odz buffer
  • 正規化 - odz buffer

    ref:ウノウラボ Unoh Labs: Mac OS X上のUnicode ref:はてなブックマーク - ウノウラボ Unoh Labs: Mac OS X上のUnicode 符号化方式と正規化の問題を激しく混同した解説をどうも。ブックマークコメントをみても正しく問題が伝わっていないように思える。というか、書いた人がきちんと認識してないんじゃないか。 2007年09月04日 omaya omaya 誰が悪いんだろう。 強いて言えば NFD な Unicode の入力に対してまともに動かない Web アプリじゃないかな。 2007年09月04日 mattn mattn macosx, unicode ブラウザのバグだしバージョンで処理しないといけないのかな... ブラウザのバグではない。 しかもややこしいことに、UTF-8で濁点をあらわすコードは「U+309B」(KATAKANA-HIR

    正規化 - odz buffer
  • 配列とポインタ #3 - odz buffer

    なんか、ネタを小出しにしている感があるなぁ。まともな Web 環境にもどったしとりあえず、昨日のネタの簡単な解説をば。(C FAQ 1 見とけという話も) 型情報もまとめて出力すると、結果は下記のようになる。 a: value = 0xbffff62c, size = 200, type = int [5][10] a + 0: value = 0xbffff62c, size = 4, type = int (*) [10] &a: value = 0xbffff62c, size = 4, type = int (*) [5][10] *a: value = 0xbffff62c, size = 40, type = int [10] a[0]: value = 0xbffff62c, size = 40, type = int [10] &a[0]: value = 0xbffff6

    配列とポインタ #3 - odz buffer
  • 抽象度と難易度 - odz buffer

    ref:プログラミング言語を作る日記 via:ときどきの雑記帖 リターンズ 2007年8月 ところで初心者向けの学習用言語としてCが向いているかどうか、という議論があるようですが、会社の新人の教育担当を何度かしたことがある私の経験からすると、たいていの人は、「低レベルな概念の方が理解が早い」ようです(これもあちこちで書いてるな)。うちの会社に関して言えば、基情報レベルの勉強を事前に済ませているというのもあるのでしょうが、メモリはわかっている。アドレスも(一応)わかっている。ポインタでつまづくのは、アドレスがわからないためではなく、「intへのポインタに1足すと4進んだりする」といった、アドレスとは異なる挙動を示すところからだと思います(私もそうだった)。 おお、なるほど。「変数」と「変数への参照」より、「変数を格納しているメモリ領域」と「そのアドレス」といった具体的なものの方が、理解しや

    抽象度と難易度 - odz buffer
  • ランダムな文字列生成 - odz buffer

    ref:http://subtech.g.hatena.ne.jp/secondlife/20070821/1187667574 ref:http://subtech.g.hatena.ne.jp/secondlife/20070820/1187578797 ref:http://d.hatena.ne.jp/knagano/20070820/1187621230 ref:http://d.hatena.ne.jp/knagano/20070821/1187656060 いや、そりゃまぁねぇ。例えば、0 から 1999 までの数字なんかだと半分は先頭 1 で、先頭が 0 になる確率は 1/2000 だ。 で、まぁ、普通に考えて元の生成乱数の範囲を 変えて、先頭の文字を除けばいいんではないかな。 rand(36 ** 9).to_s(36)[1, 8] h = Hash.new { |h,

    ランダムな文字列生成 - odz buffer
  • 一方向リスト - odz buffer

    ref:Fomalhaut of Piscis Australis : [python] どう書く?-- 一方向リスト編 ref:Fomalhaut of Piscis Australis : [python] どう書く?-- 一方向リスト編その2 ref:DARK SERVER - $ [python] どう書く?-- 一方向リスト編 def get_endpoint( linked_list ): difference = set( linked_list.values() ) - set( linked_list.keys() ) return (None if difference == set([]) else difference) なんで、そんなわざわざ集合オブジェクト作るんだろ。同じことならこれでいいんじゃねーのかと。 def get_endpoint(linked_lis

    一方向リスト - odz buffer
  • 例外の発生箇所を gdb で捕捉する - odz buffer

    gdb で catch throw を使えば例外を捕捉できるという話をコメントで教えていただいたので、試してみた。 #include <string> static void foo(void); int main() { foo(); return 0; } static void foo() { std::string s = "abc"; s.replace(-1, 0, "d"); } % g++ -g -Wall -W -O2 exc_bt.cpp -o exc_bt % gdb exc_bt GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you

    例外の発生箇所を gdb で捕捉する - odz buffer
  • ファイル名と取り扱いとコマンド置換 - odz buffer

    ななし 『ファイルがないと * のままになるので、ls DIR 2>/dev/null と書いたりしますね。』 (2007/07/09 11:10) まぁ、そのとおりなんだけど、ls とコマンド置換を使ってファイル名を取得しようとすると、パスに空白が含まれていたりする場合にはまれる。 % touch 'odz buffer' % ls `ls` ls: odz: No such file or directory ls: buffer: No such file or directoryあと、関係ないけど、-F オプション付きの GNU ls の挙動はなんだかよくわからない。 % ln -s usr . % ls -F usr usr@ % ls -F usr/ X11R6/ bin/ doc/ games/ include/ lib/ lib64/ local/ sbin/ share/

    ファイル名と取り扱いとコマンド置換 - odz buffer
  • シェルスクリプトの書き方 - odz buffer

    ref:関数プログラミング的なシェルスクリプト via:Ryoの開発日記 - シェルスクリプトよくわかんね どこからつっこめばいいのやら。 コマンド置換とパス展開 ディレクトリ以下のファイルがほしいなら `ls ${2}` ではなく素直に "$2"/* でいいのでは。 クォート どのような入力がくるかわからないときはちゃんと引用符で囲みましょう。 if [ -f $FULL ]; then $1 $FULL; fi ではなく、きちんと if [ -f "$FULL" ]; then "$1" "$FULL"; fi とする。 リダイレクト #! /bin/bash cat $1 | tr -d '\r' > $1 これがうまく動いているのはたまたま。理由は以前書いたので、そちらを参照。 というかね、こういうことはいちいちシェルスクリプトをつくるんではなくて、find と xargs を使う

    シェルスクリプトの書き方 - odz buffer
  • 文字化け - odz buffer

    ref:PHPの文字化けを気で解決する - ぎじゅっやさん via:よくきたはてダ - 惜しいが間違っている 上鍵さんからツッコミが入ってますが、別の点を。 先ほどの例の時にも書いたが、PHPには内部エンコードという概念は存在しない。ではmbstring.internal_encodingとは何なのか。これは mbstring関数のデフォルトエンコード なだけである。 しかし、変換元が固定になるというのは重要なことなので、 これはソースコードと揃えておくのがBetter。 変換元て。mbstring の関数てエンコーディング変換だけじゃないんだけどなぁ。mb_strlen だって mb_ereg 系の関数だってデフォルトのエンコーディングは mbstring.internal_encoding になるわけで、ソースコードと揃えるのは「Better」というより「原則」だろう。全ての mbs

    文字化け - odz buffer
  • 1