« ディスクが1回転する間に複数回 fdatasync する方法について | メイン | Q4M - MySQL 上で動作するメッセージキュー » 2008年01月04日 ウェブアプリケーションにおけるHDDの正しい使い方 データベース等のソフトウェアは一般に、停電やOSのクラッシュ時にデータが破壊されないよう、HDD へデータ保存が完了したか確認しながら処理を行うようになっています。その目的を果たすためにどのような API が OS によって提供されているか、少し勉強し直すことにしました。 下表のうち、赤い部分がデータの永続性が保証されない危険な手法、青い部分が安全な手法です。したがって、各行において出来るだけ左側の (高速側の) 、そして言うまでもなく青い色の同期手法を使っていることが望ましいということになります。 OS openモード HDD または RAID 内の書込先 キャッシュ
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
これは至言だと思う. イネムリネズミ日記 2007-06-17 梅雨が中休みするなら俺だって 業務系のシステムを作りたい人には申し訳有りませんが、世界の進歩のスピードは言語の成長のスピードを超えています。バグのない、安定したプログラムを作りたければ、熟練したプログラマに C で書かせるのが最も良い選択肢でしょう。バグがあるかもしれないけど、とりあえずできればいいや、ナンチャッテ、次のリリースで直すから許してチョという代物は軽量言語で書くのを僕はお勧めします。 僕にとって、軽量言語とはそういうものです。 しかし,いくらなんでも C コードを最初から人間が手書きするような時代では無い.C/C++ では,マシン間の互換性を取るだけでも,ifdef の塊になるし. となると,Haskell とかで型システムなどによる検証済みの C コードを吐くとか,そういう方向になってくる.つまり,Ruby とか
非テキストプログラミングとLLの次 LILYというプログラミング環境の紹介ビデオをみて、考えが少し進んだ。 1. 視覚的プログラミングの目的設定は、プログラミングを簡単にすることというよりは、 多人数同時プログラミングをすることに置いたほうが良い可能性があるな、ということ。 2. リンクとノードを使った視覚的プログラミングは、 極めて限られたDSLにしかなり得ないだろうということ。 3. 視覚的プログラミングの研究で得られたアイデアは、 独自の開発環境ではなく、テキストエディタや、テキストを使う言語処理系の 仕様に反映していくのが良いだろうということ。 4. LLの次に必要なのは視覚的プログラミングではなく、 共同作業や非同期的変更を前提として設計された、 テキストベースの、不定・動的・非同期プログラミング環境だろうということ。 5. 上記のような環境ができて初めて、関数型言語が花開くかも
2006年12月19日17:00 カテゴリArt 美しいプログラムの美しくないソース 半分だけ同意。 304 Not Modified: プログラマの美意識 私にとって美しいプログラムとは、シンプルなプログラムのことです。なぜ半分だけ、かというと、美しくない状況をより美しくすることがプログラムの使命であるならば、結果としてソースコードが美しくならないことも往々にしてあるから。 もっと身も蓋もない言い方をすると、この世の穢れをプログラムが背負う事もまたあるのだということ。 このことは、特にAPIを提供するソースを書くときに顕著だ。こういったプログラムに求められるのは、APIが美しいことであって、ソースコードそのものが美しいことではない。そこでは、さまざまな泥臭いことはAPIを提供するプログラムがかぶることで、APIのユーザーは醜いものを気にせずにプログラムできるようになる。 実装が美しいけど
2006年11月28日12:15 カテゴリLightweight LanguagesOpen Source プログラマがC言語を学ぶべきたった一つの理由 あれ?一番大事な奴が抜けている。 The C Programmming Lanugage K&R Geekなぺーじ:プログラマがC言語を学ぶべき10の理由 「Ten reasons why every programmer should learn C」という記事がありました。 個人的な感想ですが、何と無く言いたい事はわかる気がしました。 ただ、多少誇張している(言い過ぎ/嘘)かなと思いました。 あと、恐らくLinuxとオープンソースなどを念頭において書いているんだろうなと思いました。 [中略] ちょっと言いすぎ感も漂う内容でしたが、面白かったので訳してみました。 0) So you can write your programming
業務システム開発の世界では、案件毎のプログラミング(従来の意味での、狭義のプログラミング)を減らすような工夫が発展し続けている。コードを自動生成させたり、設定ファイルの編集でシステムの動きを指定できる。そんな実装用フレームワークの発展が止まらない。コーディング量を減らすための工夫をしたがらないのは、工数ベースで稼ぐ派遣業の経営者くらいだろう。 そのような技術革新の結果として、以前にも書いたように、システム開発での分業体制が変化する。ある種のプログラマは個々の開発案件ではとんと姿を見せなくなる。彼らは「別室」でフレームワークの開発に従事しているからだ。フレームワークは個々のシステムを生み出す「金型」とか「工作機械」のようなものなので、彼らを「金型プログラマ」と呼ぼう。いっぽうの、個々の開発案件のプロジェクトルームで働いているのは「製品プログラマ」だ。彼らは「金型プログラマ」が開発したフレーム
ちょうど1年前に日経ソフトウエアというプログラミング雑誌の編集部に異動になって以来,「プログラミングって一体何だろう?」とずっと考えて続けている。今度,日経ソフトウエア6月号で“プログラミングをしたことのない人向けの超入門記事”を書くことになり,プログラミングの本質について考えてみるいい機会だと思った。そこでふと気が付いた。「プログラミングをしたことのない人が考えていることが,自分にはわからない」ということに。 私には職業プログラマの経験はないし,長いプログラムを書いた経験もない。いわゆる「コードが書ける」人間だとはお世辞にも言えない。自分が記事の中で書いたサンプル・プログラムをあとで見返して,不自然な部分を発見して赤面するなんてことはよくあるし,最近よく参加している勉強会(注1)では演習問題が解けなくて苦しんでいる。 注1:「素人くさいSICP読書会」といいます。SICP(Structu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く