税金は死んでから納めよう - 小飼弾
というわけで、前回からの続き。 なぜ増税は消費税であっては駄目なのか – 小飼弾 : アゴラ 長くなったので、続きは次回ということにさせていただく。が、ヒントはここに上げてもよいだろう。 次回はこのグラフからはじまる。 改めてこのグラフをご覧頂きたい。 これはバブル経済のただ中にあった1990年を100とした場合の、名目GDPと個人金融資産の推移である。見てのとおり、名目GDPはほとんど増えていない。「失われた20年」の姿はここにもくっきり映し出されている。 ところが、個人金融資産はその中にあって増えているのである。1000兆だったものが1400兆に。リーマンショックによるへこみも見て取れるが、2009年を見るとGDPがマイナスなのに増えている。一体どういうことなのか? 現役世代から高齢世代への所得移転がその原因ではないか。 年齢階層別の金融資産保有割合をグラフ化してみる:Garbagen
これからプログラミングをはじめる人へ
この記事はまつもとゆきひろ氏が，2008年3月24日に発売した日経ソフトウエア2008年5月号の特集「はじめてのプログラミング」向けに著したものの再掲です。記述された内容は，執筆当時の情報に基づいています。 この手紙を読まれるころには桜の便りも聞かれているのではないでしょうか。プログラミングに挑戦したいというお話を聞き，大変うれしい限りです。 思い返せば，私がプログラミングの道に分け入ったのはまだ中学生のとき。早くも20年以上の年月が流れてしまいました。プログラミングに携わってきた時間は長いものの，常にその密度が高かったとは言い切れないようにも思います。でも，先輩として，いくらかはお役に立てる言葉を残せるのではないかと思い，筆をとります。 「プログラミングとは何か」。私に言わせれば「人生そのもの」です。私以外の人はそれぞれ別の答えを持つでしょう。ただ，少なくとも言えることは，プログラミング
fladdict.net: 情報共有をしない奴は何故アホなのか？
前回のエントリーで、「情報共有の重要さを理解できない奴はアホだ」と書いた。何故アホなのか？ ＜追記＞ コメント欄で指摘されましたが、「情報を共有しない奴はアホか？」というのは表現として不適説でした。正確には共有しない事が悪いのではなく、「共有しないほうが得だと考え、意図的に情報を隠している奴は何故アホか？」ですね。 ここは素直にゴメンナサイです。 「共有か？抜け駆か？」という話では、往々にしてゲーム理論や囚人のジレンマが引用される。だが、この囚人のジレンマは、実のところ机上の空論だったりする。それはなぜか。 なぜ囚人のジレンマは机上の空論か？ 囚人のジレンマには幾つかの成立条件がある。 その１つは、「プレイヤー間での情報交換や、強制力のある合意を形成できない環境」というものだ。つまり、情報交換ができるプレイヤーが多数存在する時点で、囚人のジレンマを持ちいた説明には意味がない。 プレイヤー間
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年5月11日 水曜 私が最初の本当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。 はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。 「いつもこんなに汚いの?」と私は聞いてみた。 「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」 なんてこった。 毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないこと
オープンソースの誤解がよろしくない理由 - enbug diary (2008-03-21
_ オープンソースの誤解がよろしくない理由 まず前提として述べておきますが、 私は長年GNU Maintainerをやっていることからもわかるように、 フリーソフトウェアの熱烈な支持者です。 趣味で話すときにオープンソースという言葉を使うことは、 せいぜい相手に合わせたいときだけです。 オープンソースはビジネス用語と割り切ってます。 さて、 う めだもちおは DISられるべきなの? に私なりのコメントをしておきます。 なぜオープンソースの妙な認識を広められると困るのか。 それはもちろん本来同じオープンソースであるべきものが、 誰かが広めたおかしな定義に基づいて、 「それはオープンソース的でない」とか、 わけのわからない批判が現れるからです。 勝手に決めた視野の狭い定義にしたがって、 オープンソースの守備範囲を狭めることは、 百害あって一利なしです。 古くは GNU Deluxe Distr
Geekなぺーじ : 良いプログラマの見分け方
「How to recognise a good programmer」という記事がありました。 良いプログラマを見分けて雇用するためのTIPSが書いてありました。 原文前半では、Paul Graham氏が書いている「The 18 mistakes that kill startups, 日本語版:スタートアップを殺す18の誤り」というエッセーに書かれている「90年代のE-コマースで多くのベンチャーを失敗させたのが質の悪いプログラマであるが、プログラマではない起業家には良いプログラマと悪いプログラマを見分ける術がない。」といった内容に対して反論すると書いています。 見分け方をまとめると、以下のようになるそうです。 流石に全ての項目を満たすような人は少ないそうですが、どれか一つでもあてはまる項目があれば、それは良いプログラマなのかも知れないそうです。 原文には、詳細な説明があるので興味のある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
