最上の日々 - 数学を表現するのに最適な媒体はコンピュータである
▼ 数学の表現の媒体としてのコンピュータつづき あのあとyoriyukiさんから有用な示唆をもらいました。 （これだけ書くのも大変だろうなあ。いつもお世話になってます。） 証明チェッカのあちら側とこちら側 私的にみたハイライトはこの辺りかな： 論理に関する部分はうまくいかなそうな気が(直観的には)します。言語や論理について一般の人が抱いている直観は誤っているか、すくなくとも混乱していることが多く、そのまま形式化しようとするとうまくいかないからです。例えば、名詞は何か対象を名指している、といった考えがその例になるでしょう。この場合、何の対象も指さない時や、複数の対象に当てはまるときにどうするか、といった問題が考えられてないのですが、にもかかわらず強固な直観としてなかなかここから自由になれないようにに思います。 言い方を変えると、自然言語に近いもの純粋に形式的に取り扱おうとすると
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: 10 Best Mutual Funds Work from Home Cheap Air Tickets Credit Card Application Dental Plans Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
【レポート】JavaOne 2006 - Kent Beck氏ユニットテストフレームワークの大御所JUnit 4の新機能語る | エンタープライズ | マイコミジャーナル
JUnitはJavaプログラムでユニットテストを行うためのフレームワークを提供するツールであり、Javaアプリケーション開発者の間で古くから広く使われてきた。しかしJUnitのテストコードの記述手法は現在のJavaにとっては多少古いスタイルであり、ここ最近ではTestNGなどの新しく登場したテストツールにそのシェアを譲りつつあった。そこでJUnitを提供するJUnit.orgでは今年2月、アーキテクチャを全面的に作り直し、新しいスタイルを採り入れたJUnit 4を公開した。 サンフランシスコで開催中の2006 JavaOne Conferenceでは17日(現地時間)、JUnitの開発者であるKent Beck氏とAlberto Savoia氏による「JUnit 4 and Java SE 5: Better Testing by Design」というタイトルのテクニカルセッションが行われ
プロジェクトチームのリーダーに向く人、向かない人 ― ＠IT情報マネジメント
チームで遂行されるプロジェクトにおいて、優秀なリーダーの存在は極めて重要です。そこで今回から、リーダーについて考えてみることにします。リーダーシップの具体的な技術に関してはコーチングなどの記事を参考にしていただくことにして、ここではもっとベーシックなところをターゲットにします。なお対象としては、ユーザーサイドに限らずプロジェクト一般についての話となります。 誰でも持っているリーダーの素質 よく話題になることに、リーダーにはリーダーとしての素質がなければならないのか、ということがあります。ある程度の素質は必要でしょうが、それは大多数の人が持っているはずです。そのように考えられる根拠はあります。 例えば、ふさわしい人が地位に就くのではなく、「地位が人を育てる」ケースはよく知られています（年功序列主義の会社ではよく見られることです）。これは、リーダーとして特別な素質がないと思われたり、思い込んだ
naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ
かたい技術とやわらかい技術 : 小野和俊のブログ
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年
koyachiの日記 - Joshua Schachter(del.icio.us)による大規模アプリケーション構築の注意点
del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache
「3年で陳腐化するWebサイトの構築には軽量言語のほうが向いている」，日本Rubyの会，高橋征義会長
「3年で陳腐化するWebサイトの構築には軽量言語のほうが向いている」，日本Rubyの会，高橋征義会長 Developers Summit 2006（デブサミ2006） 「Web（サイトの構築）にはLightweight Language（LL：軽量言語）が向いている」。「日本Rubyの会」の会長でツインスパークに勤務する高橋征義氏は2006年2月9日，東京・目黒で開催されている開発者向けカンファレンス「Developers Summit 2006（デブサミ2006）」の講演でこう語った。その理由は「Webサイトの陳腐化のサイクル」にあるという。 高橋氏は「Webサイトは構築してから3年経つと陳腐化する」と指摘する。ただ，壊れたわけでもないWebサイトを3年でリニューアルするには，事前に顧客と話をつけておく必要がある。3年で捨てる予定のアプリケーションの予算は少ない—これが，WebにはPHP
SE ライフ Vol.4 SEのための見える化!の技術 - naoyaのはてなダイアリー
SEライフVol.4 SEのための見える化!の技術がまもなく発売されます。見える化! というのは、タスクとか、スケジュールとか、本来見えない物をどう見えるようにしてプロジェクトを成功に導くかという話。はてなでいうところのあしかみたいなもん。 SE ライフ Vol.4 SEのための見える化!の技術 (SEライフ) 作者: 技術評論社編集部出版社/メーカー: 技術評論社発売日: 2005/11/29メディア: 大型本 クリック: 17回この商品を含むブログ (30件) を見る この中で「はてなが挑む見える化」という題名で、僕のインタビュー記事が掲載されています。企業の隠し事はイクナイとか、半数に反対されたときこそやるべきとか、思いつく人は一万人いてもやる人は一人か二人、とかあとはてなアイデアのこととか、そんな話をしました。 インタビュワーの方が上手だったので、僕も話したいことをストレートに伝え
「保守しやすいこと」が、良いプロセス～開発における、「設計」と「プロセス」の双対関係～：An Agile Way：オルタナティブ・ブログ
前回、「EoM(保守容易性)が良い設計の基準だ、そして、EoM＝EoT+EoCだ」という議論を書いた。ここまでの議論は、ソフトウェアの設計についてのものであり、開発の「プロセス」（あるいはプラクティス）とは無関係に進めてきた。ここで、１つの経験則を使って、プロセスの方（鏡の反対側）を見てみたい。その経験則とは、 コーンウェイの法則： ソフトウェアの構造は開発チームの構造に一致する。コンパイラを４チーム編成で作れば、４パスコンパイラになる である。（※この法則は、ソフトウェアとチームの「構造」（organization）について述べたものだが、ここでは、プロセスについて拡大解釈する） この法則を使うと、３つの設計品質についての方針は、そのまま、プロセスについての方針にミラーコピーできる。 EoTに関するプロセスの命題は、テストというより、「テスティング」という活動が、プロセスの中で最も重要な
「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]
良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、
設計者の発言: 詳細設計とコーディングの融合
「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」で例示したような「実装独立な基本設計」にもとづいて、「実装依存な設計」をまとめる。それが「詳細設計」と呼ばれる工程で、なかなか問題の多い局面だ。その扱いにくさは、この工程が実装技術の未発達さゆえの「本来は不要な手順」である点に端を発している。しかし、実装技術の発展にともなって詳細設計の工程はプログラミングに吸収されつつある。その変化はプログラマとアプリケーションエンジニアとの適正な棲み分けをもたらすものでもある。 ◆詳細設計の悩ましさ 経験者ならよくわかると思うが、詳細設計作業のいちばんやっかいな点は、手を抜いても誠実にやっても問題を生じる点だ。まず手を抜くと、プログラマの能力差にしたがったバラバラな品質のプログラムが出来上がる。プログラマからの問い合わせも増えるので、けっきょく手間がとられる。手を抜いてろくなことはない。 では、誰が作ってもそっくりなプ
CNET Japan Blog - 近藤淳也の新ネットコミュニティ論：50%の完成度でサービスを出す
はてなでサービスを出す時に心がけていることとして、「50%くらいの完成度でサービスを出す」という事があります。 普通に考えれば、サービスは「これで完成」と思う部分まで作り上げて出すべきものである気がしますが、ウェブサービスの場合、実際は半分くらいの完成度で出した方がうまく行く確率が高いと思います。 新しいサービス（例えばブログとWikiがくっついたようなダイアリー）の構想を考えたとして、そのサービスの機能は3種類ぐらいに分けて考えられます。 最低限必要な機能…ログインや日記を書く機能など。どんなシステムでも持ち合わせている機能 そのサービスを特徴付ける基本機能…キーワードの自動リンクシステムや、それを実現するためのキーワード作成機能など。どのサービスにもあるわけではないが、サービスのコンセプトを表すために必須の機能 発展的機能…1.や2.を前提として考えた場合に必要となるであろう機能。コメ
プログラムはプロセスで組むんじゃない。ひとりひとりの技術者が組むんだ - きしだのHatena
元ネタは中田英寿がよくいってた 「サッカーはシステムでやるんじゃない。ひとりひとりの選手がやるんだ」 みたいな話なんですけどね。 「1:1で負けていてはシステムは機能しない」とか。 要するに開発を成功させるためにはプロセスをごちゃごちゃいじくるよりプログラマの「フィジカル」の強さを上げることの方が大切なんじゃないかと思うわけです。 アジャイルとかXPとかやわらかいプロセスだと、よりプログラマのフィジカルっていうのが求められると思うんですね。平鍋さんのお話とか聞いてても、同じやり方で成功させるためには「平鍋さんとその仲間たち」レベルの技術者が必要だよなぁとか。 ここでの「フィジカル」っていうのは、デザインパターンとかオブジェクト指向とかリファクタリングとか、そういう「テクニック」ではなくてもっと基本的な力のことで、要するに与えられた処理が間違いなく書けるかどうかっていうことです。 例えばko
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.villagecenter.co.jp/book/think_gnu.html
i d e a * i d e a - ローカル開発環境ができた
Joel on Software
ブラックジャックのオブジェクト指向開発