ソフトウェアの肥大化について - bkブログ
ソフトウェアの肥大化について 肥大化したソフトウェアというとリソース食いでメンテナンスがしづらい厄介ものというイメージがあります。しかし、広く使われているソフトウェアは多かれ少なかれ肥大化しているように思えます。ソフトウェアの肥大化はよくないことなのでしょうか。 結論からいえば、必ずしも悪いことではありません。この話題は Joel Spolsky 氏がストラテジー･レターIV：ブロートウェアと80/20の神話で書いています。私が付け加えられることはあまりありませんが、最近、知人との間で話題になったので、少し書いてみたいと思います。 数年前、 Alan Kay 氏の Squaek についての講演を聞きにいったとき、途中でコードのサイズが話題になり、Squeak のコードはこんなに小さい（具体的な数字は忘れました）といって、何千万行もある Windows NT を引き合いに出して、Squaek
横着プログラミング 第3回: 履歴マニア
最終更新日: 2002-05-18 (公開日: 2002-05-18) Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿です。 コンピュータの方がうまくできることに人間を使うな。 -- Tom Duff *1 私の見る限り、プログラマという人種は決まって事務作業が嫌いな ようである。同じような書類を何枚も書かされたり、1つ誤字があ るから書き直せと言われたりすると、異常にストレスがたまる。 同様に、計算機を使っていても、同じような作業を何度も繰り返し たり、ちょっとでも間違えたら最初からやり直し、というのは耐え られない。そこで、今回は履歴を活用して作業の再利用をするノウ ハウを取り上げる。 シェルの履歴 Unixを使い始めて間もない初心者が作業しているところを見ると、 打ち間違えたコマンドを律儀に最初から打ち直しているのに気づく
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
Ruby/ProgressBar: A Text Progress Bar Library for Ruby
Ruby/ProgressBar is a text progress bar library for Ruby. It can indicate progress with percentage, a progress bar, and estimated remaining time. The latest version of Ruby/ProgressBar is available at <URL:/ruby-progressbar/> . Examples % irb --simple-prompt -r progressbar >> pbar = ProgressBar.new("test", 100) => (ProgressBar: 0/100) >> 100.times {sleep(0.1); pbar.inc}; pbar.finish test: 100% |oo
いやなブログ - 文字列操作の比較表: Ruby, Python, JavaScript, P...
文字列操作の比較表: Ruby, Python, JavaScript, Perl, C++ Ruby, Python, JavaScript, Perl, C++ の文字列操作の比較表を作りました。配列操作の比較表の続編です。間違いなどがあったらご指摘いただけると助かります。 Ruby (String) Python (str) JavaScript (String) Perl C++ (std::string)
いやなブログ: 配列操作の比較表: Ruby, Python, JavaScript, Perl, C++
配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)
C++ の設計と進化 - いやなブログ
C++の設計と進化 しばらく前からのろのろ読んでいた『C++の設計と進化』を読み終えました。C++ の設計者、Bjarne Stroustrup 氏による著作です。 C++は多様なスタイルを許す C++にはCから受け継いだポインタ、構造体、マクロといった機能に加えて、リファレンス、クラス、テンプレート、例外、ネームスペースといった新たな機能が追加されています。 この結果、C++のプログラムは、昔ながらのC、クラスベースのオブジェクト指向プログラミング、テンプレートによるジェネリックプログラミング、など、さまざまなスタイルで書くことができます。これらを混在させることも可能です。 私が以前から疑問に思っていたのは、なぜ C++ はこんなにいろんな書き方ができるのか（コーディングスタイルもまちまちだし）、ということです。本書の第一章にまさにその答えがありました。 C++の設計の多くの部分が、強制
C++と Pthreads でミニマルなHTTPサーバを書く - いやなブログ
C++と Pthreads でミニマルなHTTPサーバを書く 『UNIXネットワークプログラミング』を読んでいると、自分でも何かネットワーク系の小さなプログラムを書いてみたくなりました。そこで、ミニマルなHTTPサーバを C++と Pthreads で書いてみました。 同じ著者の「詳解UNIXプログラミング」もそうだったように、今回の本もほとんどすべてのページに、重要なことが書かれています（最後のほうのXTIの部分は例外かもしれませんが）。 たとえば、27章ではネットワークサーバの実装として、次の設計方針がそれぞれ検討され、実際のコード付きで解説されています。 クライアントごとに fork 事前に fork - 各プロセスで accept 事前に fork - ファイルロックで accept を保護 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PRO
Emacsでファイルの自動保存 (auto-save-buffers)
うっかりファイルの保存を忘れていたために、OSやアプリケーショ ンが突然落ちて何時間もの作業を失ったという経験のある人は多い。 うっかりと書いたが、これはうっかりしていた人間が悪いというよ り、作業内容を失ってしまう計算機の方が悪い話である。 こうした「ファイルの保存し忘れ問題」に備える現実的な対策は、 ファイルの保存をこまめに行う、という方法である。実際、多くの 人がこれを行っている。なんだかおかしな話だ。 Emacs にはバックアップを自動保存する機能が備わっているが、 いざというときに復元の仕方がよくわからない。 M-x recove-file して復元するファイル名を指定する。 バックアップファイルが残っているときにファイルを開くと M-x recover-file せよ、と説明がでるけど、 再度ファイル名を指定し直さないといけないのは不便 (このととき RET を押だけでもいいけ
Dependency Injection の基本的なアイディア - bkブログ
Dependency Injection の基本的なアイディア Inversion of Control コンテナと Dependency Injection パターンを読みました。関連する事柄を広くカバーした、隙のない記事です。 ただ、割とボリュームがあるので、「Dependency Injection って結局何なの?」ということを手っ取り早く知りたい向きにはあまり向かないかもしれません。そこで、基本的なアイディアを手短にまとめてみました。 Dependency Injection (依存性注入、DIと略) とはその名の通り、依存性を注入するパターン (テクニック) です。もう少し言葉を加えると、依存性を内部に抱え込まずに外部から注入する、パターンです。 Dependency Injection の基本的なアイディアは「依存性を外部から注入する」です。 DIコンテナと呼ばれるフレームワ
横着プログラミング 第1回: Unixのメモ技術
最終更新日: 2002-03-18 (公開日: 2002-03-18) Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿です。 横着プログラミングとは 私は必要が発明の母だとは思わない。私の意見では、発明とは怠惰 から、おそらくはまた、まさに無精から生じるものである。面倒を 省くために。 -- アガサ・クリスティ この言葉によると、どうも発明とは横着したいがために生まれるも のらしい。そう考えてみると確かに、私がプログラミングをする動 機は、横着するためのソフトウェアを作るため、という要素が大き い。突然、「うげー、面倒くせー」と叫んでプログラムを書き始め るのである。 そんなわけで、横着するためにプログラミングすることを私は勝手 に「横着プログラミング」と呼んでいる。本連載では横着プログラ ミングをテーマに、横着のコツや私が作っ
自転車置場の議論 - bkブログ
自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの
年を取ると環境設定がどうでもよくなる現象 - bkブログ
年を取ると環境設定がどうでもよくなる現象 環境設定に関するエッセイを書きました。 もともとは、とあるメディア向けに書いたものですが、 諸事情により、ブログにて公開することにしました。 環境設定と老化 ソフトウェア開発を行う上で、プログラマはさまざまなツールを使います。そして、ツールをカスタマイズしたり、ときおり新たなツールを導入するなどして、開発環境を整えます。具体的には、テキストエディタの設定を変更したり、ブラウザに拡張機能をインストールしたり、といったことを行います。 私の場合、以前はこうした環境設定に情熱を燃やしていましたが、年をとるにつれて、その情熱は徐々に衰えてきました。周りのプログラマを見渡しても、多かれ少なかれ、同じ傾向が見られます。 というわけで、今回は「年を取ると環境設定がどうでもよくなる現象」がなぜ起きるかについて考察してみたいと思います。それではさっそく、思い当たる要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://0xcc.net/diary/20040809.html