Fine Software Writings
最近のもの 目標でなく恐怖を明確にすべき理由 (Tim Ferriss) 我々が築き、掘っている未来 (Elon Musk) 表計算ソフト誕生の話 (Dan Bricklin) Linuxの背後にある精神 (Linus Torvalds) 先延ばし魔の頭の中はどうなっているか (Tim Urban) 好きになる仕事はどうしたら見つかるのか (Scott Dinsmore) 人間に新たな感覚を作り出すことは可能か？ (David Eagleman) 人工知能が人間より高い知性を持つようになったとき何が起きるか？ (Nick Bostrom) 厄介な問題を解決したい？ ではトーストの作り方を説明してください (Tom Wujec) 子供の夢を奪う学校というシステム (Seth Godin) 彼らがいなくなってしまう前に (Jimmy Nelson) 頭良さそうにTED風プレゼンをする方法 (W
steps to phantasien t(2006-09-01)
2006-09-01 近況 いまの余暇コードは Makefile のかわりに SCons を使っている. Scons は python 製の make alternative. (概要は Radium Software に記事があった.) "#include" によるヘッダファイルの依存関係を勝手に解決してくれるのがいい. 私は何度やっても Makefile の dep ターゲットをうまく書けない. 泣きたくなる. gcc -MD で作った .dep ファイルが どのタイミングで Makefile に incldue されるのか, 実のところ未だによくわかっていない. 少し前にやった仕事でも, 試行錯誤の末になんとなく動いた Makefile をおそるおそる使っていた. (マニュアルをぱくったんだっけ...でも sed なんて使わなかったような...) 一体何がどの順序で評価されるのかさっ
JavaとPerlとTDDと回想と。 - nothing but trouble
この辺りのお話で。 『WEB+DB PRESS Vol.35』:実演! テスト駆動開発 - 角谷HTML化計画(2006-10-24) 404 Blog Not Found:テキストエディタさえあればできるTDD JavaもPerlも俺の中では、かなり上位にランクインする好きな言語なんだけど、なんか両者の文化圏は妙に対立することが多いよね。 今回のは、小飼さんの「Eclipseの中」発言が全てを集約している気がする。 エンタープライズJavaな現場ってのは、経験上、窮屈なもので、だからこそJavaというアーキテクトがガチガチにプログラマを縛っていけるような言語が受け入れられたということがあると思う。 俺が、初めてJavaを本格的に業務で使ったのは、2001年ぐらいだったとおもうんだけど、まだEclipseですら、重くて使い物にならないと思われていたような時代で、その頃はSolaris上で、
「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ
JTBの元取締役CIO(最高情報責任者)の方が、ITシステム開発が設備への投資であるかのような前提で書いていますが、この前提は間違っていると思います。 ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。 たとえば、新しいビジネスを実現するための、新しい店舗オペレーションや配送システムの開発は、ソフトウェアシステムの開発そのものです。 あたらしいビジネスを立ち上げるために、設計すべきものは、たとえば: ●迅速で高品質な状況対応を可能とする意思決定メカニズムの設計。 ●現場で柔軟な対応が出来、かつ、従業員の士気があがるような、責任・権限メカニズムと、それと連動した人事評価・報酬システムの設計。 ●現実的に調達可能な人材と、十分な投資効果の見込める従業員教育シ
最上の日々 - 数学を表現するのに最適な媒体はコンピュータである
▼ 数学の表現の媒体としてのコンピュータつづき あのあとyoriyukiさんから有用な示唆をもらいました。 （これだけ書くのも大変だろうなあ。いつもお世話になってます。） 証明チェッカのあちら側とこちら側 私的にみたハイライトはこの辺りかな： 論理に関する部分はうまくいかなそうな気が(直観的には)します。言語や論理について一般の人が抱いている直観は誤っているか、すくなくとも混乱していることが多く、そのまま形式化しようとするとうまくいかないからです。例えば、名詞は何か対象を名指している、といった考えがその例になるでしょう。この場合、何の対象も指さない時や、複数の対象に当てはまるときにどうするか、といった問題が考えられてないのですが、にもかかわらず強固な直観としてなかなかここから自由になれないようにに思います。 言い方を変えると、自然言語に近いもの純粋に形式的に取り扱おうとすると
かたい技術とやわらかい技術 : 小野和俊のブログ
1976年生まれ。1999年慶應義塾大学環境情報学部卒業後、同年サン・マイクロシステムズ株式会社に入社。入社後まもなく米国 Sun Microsystems, Inc での開発を経験し、2000年より株式会社アプレッソ代表取締役に就任、データ連携ミドルウェア DataSpider を開発する。2002年には DataSpider が SOFTIC ソフトウェア・プロダクト・オブ・ザ・イヤーを受賞。2004年度未踏ソフトウェア創造事業 Galapagos プロジェクト共同開発者。2007年〜2010年日経ソフトウェア巻頭連載「小野和俊のプログラマ独立独歩」執筆。2008年〜2011年九州大学大学院「高度ICTリーダーシップ特論」非常勤講師。2013年よりセゾン情報システムズ HULFT事業CTO、2014年 CTO、2015年 取締役 CTO、2016年 常務取締役 CTOを務め、2019年
設計者の発言: 詳細設計とコーディングの融合
「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」で例示したような「実装独立な基本設計」にもとづいて、「実装依存な設計」をまとめる。それが「詳細設計」と呼ばれる工程で、なかなか問題の多い局面だ。その扱いにくさは、この工程が実装技術の未発達さゆえの「本来は不要な手順」である点に端を発している。しかし、実装技術の発展にともなって詳細設計の工程はプログラミングに吸収されつつある。その変化はプログラマとアプリケーションエンジニアとの適正な棲み分けをもたらすものでもある。 ◆詳細設計の悩ましさ 経験者ならよくわかると思うが、詳細設計作業のいちばんやっかいな点は、手を抜いても誠実にやっても問題を生じる点だ。まず手を抜くと、プログラマの能力差にしたがったバラバラな品質のプログラムが出来上がる。プログラマからの問い合わせも増えるので、けっきょく手間がとられる。手を抜いてろくなことはない。 では、誰が作ってもそっくりなプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「多重参照」の問題点 - 最上の日々
Joel on Software