OOコード養成ギブス - rants
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
malloc(3)のメモリ管理構造 VA Linux Systems Japan
malloc()といえばＣ言語ではお馴染みのライブラリで、最も良く使用されるライブラリの一つです。しかしその分だけ何らかの不具合を経験した人も多いのではないでしょうか。本書ではmalloc()、free()で確保、解放されるメモリリソースが内部的にどのように管理されているかを説明していきます。mallocライブラリの仕様を理解する事で、ライブラリ使用時に何らかの不具合が発生した際の手助けになればと思います。 ここではLinuxディストリビューションで標準的に使用されているglibcのmallocライブラリを扱います。今回の調査では次の環境を使用しています。 ディストリビューション :Debian sarge パッケージバージョン :glibc-2.3.2.ds1-22 OS : i386 Linux 本書では、上記の通りi386アーキテクチャの場合について記述しています。
質問が来たので答えてみる — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
Failgrind: Failmalloc on Valgrind framework
以前, Failmalloc がなかなか良いという話をした. その中で書いた "malloc() の失敗するタイミングを呼出元の関数名で制限する" 機能. スタックを覗いたりが面倒で vaporware のまま放置してたんだけど, Valgrind を使うとあっさり実現できた. 本家リスペクトで Failgrind と命名. (レポジトリ, スナップショット) インストール Failgrind は Valgrind に対する patch になっている. patch といっても中のコードは手つかずで, ビルドシステムに相乗りするだけ. Valgrind は マニュアルに拡張の仕方が載っている だけあって, フレームワークとしての利用を前提としている. なので patch という響きを嫌がらないでください. まず valgrind-3.3.0 を展開: $ tar xvjf ~/Downloa
はてなブログ | 無料ブログを作成しよう
猛暑を乗り切った服・小物・その他 とにかく2025年の夏は暑かった。 と、毎年言っている気がするけど、今年は特別暑かったのではないか。これが地球温暖化なのだと見せつけられているような気がする。スノーボーダーとしてはそれに全力で抗う必要があるんだけど、自分の態度がまだ追いついていない。 生…
プログラムで作りたいものなんて、なくたっていいじゃん - @kyanny's blog
ちょっとカチンときたので、反論します。 これはどの言語でも言えると思うのだが、「作りたいプログラム」がないのに、闇雲にプログラミング言語の勉強をしてもしょうがないと思う。というのは、世の中にいろいろなプログラミング言語があるのは、「作りたいプログラムに向いているプログラミング言語、向かないプログラミング言語」があるからだと思うからである。いけがみは Haskell が好きであるが、全てのプログラムを Haskell で書こうとは思わない。 http://madscientist.jp/~ikegami/diary/20080512.html#p02 僕はプログラムでこういうものが作りたい、というのはあんまりありません。プログラムを勉強しはじめた、五、六年前からずっとそうで、だから当時も自分よりプログラムがかける人に、どうやったら読み書きできるようになれますかと聞いて、「プログラムで実現した
[C++][C++0x]structual よりも non-intrusive だと思うにゃー - Cry’s Diary
http://www.kmonos.net/wlog/85.html#_0905080505 う〜ん， structural かどうかではなくて non-intrusive かどうかっていう軸の方が重要だと思うんですけれどどうなんでしょうかねー． non-intrusive という言葉を明快に定義してくれている書籍なりサイトなりが少なくてアレなんですが，オレオレな理解で行くと， non-intrusive とは，あるデータ型 T が何らかの制約 (これこれこういうインタフェイスを持ってないといけないよ，という決まり) を満足しているかどうか，に関する記述が T の定義と独立に記述することができる，あるいはもはや制約の充足に関する記述自体不要，ということだと理解しています． 歴史的な流れでいうと STL の存在が大きいのはこれは k.inaba さんの指摘どおりだと自分も思っていて，たとえば
![[C++][C++0x]structual よりも non-intrusive だと思うにゃー - Cry’s Diary](https://cdn-ak-scissors.b.st-hatena.com/image/square/4eeb881c10b56f21a93c2d862da1a784f0d14d13/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F8454420450097600593%2F10257846132638277339%2F1537749311)
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
納得いかないことがある - Faith and Brave - C++で遊ぼう
以下のようなことを言うひとがたまにいる 「プログラムなんてエンドユーザーは見ないんだから・・・」 プログラミングのテクニックはエンドユーザーに見せつけるものでは当然ありません プログラミングのテクニックは内部的品質の向上のためであり それは顧客にではなく今後の開発に貢献するのです
Born to code
大まかな設計図をあたまに浮かべ、おもむろにコードを書き始める 下回りの部品から順番に、丁寧に積み上げて行く それでも必ず後から下回りの設計に気に食わない部分が出てくるので、 苦しくてもそこは躊躇せずに壊しては作り直す そうして行くうちに、だんだんと下の方から設計がしっかりしたものになってくる 踏み固められた地面が固くなるように、少しづつ強固なプラットフォームが作られて行く 「今日はここまで実現しよう」と決めたら死にものぐるいでそこまで走る でも頭が回らなくなってきたら早く寝る そうやって愛しい我が子を育てる様にコードを一行一行書いていく 何百万人、何千万人もの人に使ってもらえる日を夢見ながら プログラミングという楽しみがある時代に生まれて来ることができた幸せを噛み締めながら
gcc の組織はどうやって開発を進めているのか？ - ひげぽん OSとか作っちゃうかMona-
多くの人がお世話になっているコンパイラ gcc 。 この gcc の組織がどのように開発を進めているかという記事が Reddit に挙がっていました。 How Does the Gcc Organization Work? 原文を読んでもらうのが一番良いのですが、gcc が珍しい点として以下の項目があげられています。 20年間もアクティブなフリーソフトウェアプロジェクトであること。 多くのアクティブな貢献者がいること。 特定の1つの会社や組織と関連があるわけではないこと。 比較的インフォーマルな組織構造であること。 1人の中心的なメンテナがいるわけではない。 1997年に egcs プロジェクトとしてフォークするという大きな組織的転換を生き抜いたこと。そして結局それが開発のメインラインとなったこと。 「1人の中心的なメンテナがいるわけではない。」というのは意外ですね。
d.y.d.構文解析の話をしよう
16:46 08/03/30 YZ1.DLL 0.30 リリース しました。 具体的には、ヘッダの格納ファイル数フィールドに実際より大きい値が入ってると変なとこ読もうとして落ちるバグ修正。 GreenPad の修正は来週くらいには…。 Booooooost Boost 1.35.0 来てました。 Asio と Fusion と GIL の三枚看板がでかいですが、Bimap が地味に便利だ。 あと、mbさんのEgg のレビューが明日からでしょうか。（また スケジュール から消えてますが…Protoが入る前までロールバックしてる？） 他人事ながらドキドキ。 17:36 08/03/28 ケース 十年来の疑問なんですが、"case" に単独で対応する日本語ってなんになるんですかね。 "case-insensitive" や "lowercase" の "case"。単に "case-insens
enbug diary(2008-02-02)
_ 日常 本当は朝のうちに行くつもりだったのに、 結局夕方になってから、 No Country for Old Men を観に行った。 原作の評判は聞いていたのだが、映画も割と評判良さそうだったので、 見に行く気になった。 少々オーソドックスなストーリーと言えなくもないが、 映画の世界にどっぷり浸かれて、かなり良かったー。 ハリウッドじゃ、最近はゲームやコミックの映画化が多くて、 どうしても勧善懲悪な内容になりがちで、 少々食傷気味だっただけに、 こういう善対悪にならない構図は非常によろしい。 一応善に限りなく近い存在であるシェリフは常に事件から一歩退いた位置にいるし、 観客の多くが一見善と捉えがちな主役は所詮こそ泥だ。 どっちの方がより恐ろしい存在か程度の違いしかないと言っていい。 たぶん、この映画で最も重要なテーマは自分の運命の決め方なんだと思う。 われわれは常に何かを選択しながら生き
プログラマと失われた時 — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
ユメのチカラ: カーネルにおけるリグレッションの特定
例えば、2.6.17では問題ないのに、2.6.18だとなぜか問題が発生するとする。linux kernel は git というソースコード管理システムによって、全ての変更が管理されているので、その機能を利用して問題を発生させたパッチを特定する事ができる。 基本的な考え方は、コミットしたパッチを問題を発生させた組と、発生しない組にわけていって、問題を絞り込む。2分検索だ。 例えば、1000個分の変更がコミットされていたとする。これを問題が発生しない状況から一個一個順ぐりにあてていき、問題が発生したら、最後にあてたパッチが原因だということがわかる。この順ぐりにあてていく場合、最悪1000回試行錯誤しなくてはいけない。 2分検索の場合、まづ、500個分あてた状態で(gitで簡単にそのような状況をつくれる)試験をし、仮に問題が発生しなければ、残りの500個に問題があるので、さらに、その半分250個
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
C言語: UNIX最速ファイルコピー
Created: Kazuki Ohta, 2006/06/14 Last Update: Kazuki Ohta, 2006/06/14 「write(2)の正しい使い方」と同じく、OS演習でやった事の延長線の記事を書いてみる。お題は「UNIX上で大規模ファイルを最速でコピーする方法」だ。一般的に、UNIXでファイルをcopyする際には以下のような方法が有る。 read -> write read -> write with posix_fadvice mmap -> mmap -> memcpy -> fsync mmap -> mmap -> memcpy -> fsync with madvise mmap -> write mmap -> write with madvise read, write, mmap辺りは良いとして、posix_fadviseというシステムコールが有
僻地のプログラマkmt-t - わりとどうでもいい日記 1.0
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NameBright - Coming Soon
「CLIとGUIの架け橋」zenity跡地 - 試験運用中なLinux備忘録・旧記事
