フローチャートの呪い - カレーなる辛口Javaな加齢日記
http://blog.livedoor.jp/dankogai/archives/51083212.html http://d.hatena.ne.jp/NOV1975/20080719/p2 http://d.hatena.ne.jp/NOV1975/20080719/p4 いまさら議論するのも馬鹿らしいけど，フローチャートなんぞはものの役に立たない． そんなものは作るだけ時間の無駄だし，何かの役にたつこともない． それは何十年も前に結論が出ていると思う． それはあまりに自明であったため，今では話題になることも少なくなった． 人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series) 作者: フレデリック・P,Jr.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子出版社/メーカー: アジソンウェス
フローチャートとFizzBuzz問題 - novtan別館
先の低水準言語での研修 - novtan別館関連エントリに今や懐かしき、FizzBuzz問題の紹介記事が上げられていた。どういう基準だかわからないけど、面白い。 プログラマ職に応募してくる人間のほとんどが書けない「Fizz-Buzz問題」：濃縮還元オレンジニュース｜gihyo.jp … 技術評論社 さて、研修の話だけど、低水準言語ってだけではなく、きちんとフローチャートを書かせて処理の流れを整理し、あるいは効率が悪くないかを考えさせる、ということも重要だと思っています。 これが意外と真っ直ぐ書けないものなんですよ。やろうとしている処理はごく単純なものです。でも言語を想定して書いちゃうから変なフローチャートになる。確かに「レジスタに値をロード」とか考えながら書かなきゃならないのだけど、それ以前に全体の大きなフローが見えていない。FizzBuzzでいうと、一番大きなくくりである「１から１００ま
結論：結局、Javaはクロージャを使えるの？ - lethevert is a programmer
【追記 2008/7/2】とても昔のClosureについて書いた記事が注目を集めてしまったみたいですが、ぜひ、もっと後で書いた次の記事とその関連スレッドの方も確認してみてください。このときよりも、もう少し事情が分かってから書いたものなので、より正確に状況を理解できると思います。それに、私自身、この言葉にはまだ混乱しています・・・ http://d.hatena.ne.jp/lethevert/20070524/p2 - という問いに対して、そろそろ私の結論を整理しておきます。 これは、将来の自分に対する参照の便のための整理です。 前提知識 前提知識として、こちらの内容を読んで理解しておきます。 Closure (computer programming) - Wikipedia [id:lethevert:20060119:p1] [id:lethevert:20060121:p2] また
TopHatenarにみる「Javaの復活」 - ひがやすを技術ブログ
TopHatenarを知っているだろうか。 http://tophatenar.com/ はてなユーザのRSSフィード購読者数とソーシャルブックマーク獲得数のユーザランキングを表示してくれるサイトだ。 ここ2,3ヵ年の流れだと、こういうアイディアサイト(作るに時間はかからないけどアイディアが秀逸なサイト。あまり好きじゃない言葉だけどWeb2.0系サイトともいえるかも)は、Railsで作るのがはやっていた。Railsのほうが作りやすいし、注目も集めるから。 TopHatenarは、実はJavaで作られている。フレームワークはSeasar2系だ。作者は、こういっている。 このサービスは、僕が去年末ごろから持っていたアイデアを、Cubby+Mayaa+S2JDBCの使い心地を確かめる意味を込めて実装したものです。 僕がWebアプリを作る上でのフレームワークの好みは、S2JSF、Teeda、Rai
トップ
基本的には、ここの内容をそのままGitHubに登録してpagesの設定をすれば良い。例えば「Reveal.js、Markdown、Githubでスライドを作成する。」が良くまとまっている。だが1つ謎の事象が起きて悩んだ。 index.htmlの中に、直接markdownを書く時には良いのだが、以下のようにdata-markdown属性でmdファイルを指定すると、不可思議な動作をする。 <section data-markdown="./md/firstpage.md" data-separator="\n---\n$" data-vertical="\n--\n"> <script type="text/template"> </script> </section> 最初にcommit/pushした時は表示されるものの、変更してcommit/pushしても変更が反映されなかったり、そもそも
memcachedの驚愕の事実。
MixiやFacebook、Wikipediaなど、大規模なサイトでmemcachedを利用する例が増えている。マイコミジャーナルのレポートでFacebookの事例紹介があるのだが、なんとmemcached用のサーバは805台で、メモリ容量は15TBにもなるそうだ。ディスクではなくメモリだけで15TB！である。アクティブユーザーの数は7000万人もいるそうだから、それを捌くとなるとハードウェアも凄い規模にならざるを得ないのである。 このように大規模サイトを支えるmemcachedであるが、そのプログラムの中身は一体いかなるものなのであろうか。memcachedはhttp://www.danga.com/memcachedでソースコードが配布されている。現時点での最新版は1.2.5である。ぜひダウンロードしてみてほしい。そしておもむろにファイルサイズを確認してみてほしい。するとあることに気づ
プログラミングとアプリ開発の違い : 404 Blog Not Found
2008年05月19日11:45 カテゴリYAPC::AsiaLightweight Languages プログラミングとアプリ開発の違い ああ、YAPC::Asia::2008のトリ、Perl Is unDeadを見せてあげたかったなあ。 プログラミングのジャンルと難易度(および Web プログラミング批判) - 黎明日記 だってそうだろ？ 「 Web アプリケーション」なんてカッコイイ名前の割に、受け取ったデータを簡単に加工してデータベースに突っ込んで取り出して……それで終わりじゃないか。ビデオやスライドが上がるまでしばらくかかると思うので、とりあえずは以下をご覧あれ。 はてなブックマーク - タグ yapcasia2008 Simon Cozens - YAPC Asia and talking in Japan YAPC::Asia 2008 2日め - てきとうなメモ で、Sch
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
Javaの冗長な記法って小クラス主義の現れではないかな - 矢野勉のはてな日記
Java以下は無駄に長い駄文です。なんか書いてみたはいいもののうまくまとまらなかった。ごく一部しか表せなかった気がする。これではInputStreamReaderとかがたくさんオブジェクトを連結しないと使えないめんどくささをなぜ許容できるか、しか表せてない... もともとは「 Java における本質的でない記述がどのように大規模開発に役立つのか - kwatchの日記」がらみの話です。文中にいくつか「アクセッサが簡潔に定義できない」「FileReader に文字コードを渡せない」のような例があって、「それらが改善されたら大規模開発になにか不利益があるのかどうか」という具体的な質問があったので私はそこにコメントしときました。私はコメント欄に「不利益なんてないよ」と回答しました。実際のところ、後方互換性が維持され、言語としての統一性が維持されるなら別に不利益なんてあるわけない。あるとしたらマネ
はてなブログ | 無料ブログを作成しよう
晴天の価値 2月中旬に出張で千葉へ行った。5日間の滞在中はずっと快晴で、気温は20℃に迫る春のような暖かさだった。仕事は朝から晩まで現場を走り回る過酷なもので、身体的にも精神的にも追い込まれた。毎朝、京葉線から見える美しい景色を眺めて正気を保っていた。太平洋へ燦々と…
Java における本質的でない記述がどのように大規模開発に役立つのか - kなんとかの日記
まじめな話に切り替えて、Java屋さんJava信者さんに質問したいと思います。 質問: Java における、本質的でない冗長な記述は、どのように大規模開発に役立つのでしょうか。 質問の背景を説明すると、以前の晒されエントリで、Java における本質的でない記述の数々について話題にしました。それに対する反応で、『Java は大規模開発向けだから記述が長くてもいいんだ (または長くなくてはいけない)』という意見が多くあります。 たとえば、ブックマークコメントより: エンタプライズ分野であの大伽藍が求められたのだから仕方ないですよ。 エンタープライズ分野のような大規模開発こそ、必要な情報を簡潔にわかりやすく記述する必要があると思ってたんですが、世の中は違うようです。 同じくブックマークコメントより: Java屋の怠慢は高層ビル建築をどうサボるかであって、犬小屋を作る時にどうサボるかという視点とは
小飼弾のフェイントテクニック - kなんとかの日記
ひがさんの、ちょっと前のエントリ。 ボクシングの内藤選手は、フェイントの達人です。ここにパンチを打ち込むぞーと目線を合わせているのと、まったく違う部分にパンチを打ち込むことができるのです。これは、超高度なテクニックで、達人にしかできないそうです。 弾さんのつっこみも、おんなじ感じですよね。何かを引用しつつ、別の部分を掘り下げるっていう。今日、やっとこれは、内藤選手のフェイントと同じなんだと気づきました(笑)。 例えば、「誰が書いても同じコード」は大事なことなのかの私のエントリ。これに対して「同じコード」の同じって何さとふって、TAPをすすめるって言うフェイント。 ついに永和の秘密を公開 - 受託開発の極意のエントリに関しても、極意より作品を - 書評 - 受託開発の極意で本の中身より「何を作ったか」を焦点にするフェイント。 フェイント後の話が面白いから成り立つテクニックだと思うんですが、最
無料ソフトは出来が悪いのか - おやじまんのだめだこりゃ日記
何の気なしに某Yaho○の知恵袋なるところを見ていたら、無料ソフトについての話題に目がとまりました。探してみると無料ソフトやフリーソフトについての質問は意外と多いようです。 読んでいてちょっとまずいなぁと思ったのが、無料ソフトは性能が悪いと思っている人が結構いるということ。「いいソフトだから金を取れる」「金を取れるのはいいソフトはてブコメント見て、言いたいことと書き方が食い違っていたので訂正」って思想が根本にあるようです。しかし、この思想はビジネスモデルが違えばソフト売買による売上なんて狙わなくてもいい場合もあることを全く考えていない恐るべき思想です。そんな偏った思想に毒されないように。有料ソフトと同程度なものはたくさんありますから。逆に有料だけど糞フトもね。 身近な例でいうなら、Firefox、Thunderbird、GoogleToolBar、GIMP、iTuneなどなどはユーザ数も多
404 Blog Not Found:｢怠惰はﾌﾟﾛｸﾞﾗﾏの美徳で言語の機能じゃない｣っていうけど
2008年04月28日21:00 カテゴリLightweight Languages 「怠惰はプログラマの美徳で言語の機能じゃない」っていうけど 怠惰を促す言語とそうでない言語は確かにあるように感じている。 「怠慢はプログラマの美徳」というけれど - kwatchの日記 はてなブックマーク - novtanのブックマーク / 2008年04月28日 怠惰はプログラマの美徳であってそれを言語の機能に求めてはいけない。「怠慢はプログラマの美徳」というけれど - kwatchの日記 例えば、スクリプト言語で次のような Hash や Dict を書いたとする。 data = [ {'name'=>'Foo', 'age'=>20, 'email'=>'foo@mail.com'}, {'name'=>'Bar', 'age'=>21, 'email'=>'bar@mail.net'}, {'nam
「怠慢はプログラマの美徳」というけれど - kなんとかの日記
Java屋Java信者とスクリプト言語屋の間には、「めんどくさい」と感じるセンスについて超えられない壁が存在している。 本質的でない事柄に関する記述があったときに、スクリプト言語屋は「めんどくさい」と感じ、Java屋Java信者はそれを感じないか、または「これは必要な冗長性だ」と本気で思い込んでいる。 前にとり上げたけど、アクセッサの記述がその典型例。本質的でない記述がずらっと並んでいることに、Java屋Java信者はホントに何も感じないのだそうだ。あれがどれだけ readability を下げているか、まったく分かっていない。 また System.out.print() もそう。たかが print 文のくせして、なんで System.out.print() と書かないといけないのか。本来であれば、Java1.5 のタイミングで package java.util; public clas
「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
はてなブログ | 無料ブログを作成しよう
長文日記
えきねっと（JR東日本）もたまには間違える - Ogawa::Memoranda