DDN は 音楽 ・ 映像 に関する デジタル アート を中心に情報ミックスを配信中
DDN は 音楽 ・ 映像 に関する デジタル アート を中心に情報ミックスを配信中
Webプログラミングは何故オブジェクト指向でない?~WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet+JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって? ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発:第1回 Hello, Wicket|gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ
糸井重里がほぼ日の創刊時から 2011年まで連載していた、 ちょっと長めのコラムです。 「今日のダーリン」とは別に 毎週月曜日に掲載されていました。 聞くは、最高の仕事。 2010-01-25 また、じぶんへのメモをもとにして、 それを広げたものを、ここに書いておくことにした。 メモには、「聞くは最高の仕事」とあった。 ‥‥。 「ほぼ日」をはじめるとき、 いろいろ考えたことのなかに、 「聞く」をもっと大事にしよう、ということがある。 よく見ろ、とか、ちゃんと見なきゃとか、 「見る」のほうはもう、 いまの時代の重要な感覚だということになっている。 いま現在、この文を読んでいることも、 「見る」をしているわけだし。 本を読むことだとか、 テレビや映画を楽しむことだとかも、 「見る」が前提になっている。 「目を放しちゃいけない」であるとか、 「じっと見ていればわかる」だとか、 仕事をしていくうえ
あらためて書きますが、わたしのエンジニア歴は20年です。20年前といえば、バブルの末期だったと記憶しています。世の中が好景気だったので、学歴が低いわたしでも就職で苦労した記憶はありません。今の若い人から見たらうらやましいというか信じられないと思います。 エンジニアとしても「ハードウェア設計」から始まり、プロジェクト規模も大規模(都市銀行)から1人でデバイスドライバ作ったり、PG、SE、 PMどれも経験しましたし、正社員、派遣、フリー、経営者(起業)すべて経験しました。プロジェクト自体の失敗はあまりないですが、起業は多分失敗しました(それでも懲りずにまたやりたいと思っています)。 いろいろな立場でいろいろな規模のプロジェクトを経験してきたのですが、ここ最近は昔と違い、エンジニアの気質が変わってきたと感じます。これは若いエンジニアだけはなく、それなりに経験のあるベテラン領域のエンジニアも同様で
先日、京都の知恩寺で恒例の古本祭りが開催されました。広い境内には多くのテントが設置され、幅広い年齢層の客で賑っていました。興味を惹かれたのは古ぼけた仏教関係書が置かれた一角です。分厚い本が多く、数千点はあろうかと思われるその量の多さに驚かされました。 むろん、ここに展示されている仏教関係書は一部であり、他にも多数ある筈です。多くはこの100年くらいに書かれたものでしょうが、著作のために使われたエネルギーはまことに膨大なものです。それを経済的に支えたものは多くの信者であったことでしょう。私のような門外漢にとって、それは同時に膨大な無駄の集積と思われます。 いかに緻密な論理で構築されたものであっても、それが妄想の上に築かれたのであれば砂上の楼閣に過ぎません。妄想を持たない者、異なる妄想を持つ者にとってはほどんど意味がありません。一般に仏教書が無心論者やキリスト教徒にとって意味を持つことがないよ
自転車置き場 パーキンソンの凡俗法則(パーキンソンのぼんぞくほうそく、英: Parkinson's Law of Triviality)とは、シリル・ノースコート・パーキンソン(英語版)が1957年に発表した、「組織は些細な物事に対して、不釣り合いなほど重点を置く」という主張である。パーキンソンがこの法則を説明する際に用いたたとえ話から「自転車置き場のコンセプト」、「自転車置き場の色」または「自転車置き場の議論」などの言い回しで使われることもある。 この法則は、シリル・ノースコート・パーキンソン(英語版)による、経営の風刺書『パーキンソンの法則』[1] の中で出されたものである。パーキンソンはこの法則を説明するたとえ話として、委員会が原子力発電所と自転車置き場の建設について審議する様子を比較している。 原子炉の建設計画は、あまりにも巨大な費用が必要で、あまりにも複雑であるため一般人には理解
テストファーストは、XP(エクストリームプログラミング)の中でも特に広く浸透したプラクティスの1つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
ロゴをデザインしたい。 そんなときにおすすめなのが、『45 Rules for Creating a Great Logo Design』。素晴らしいロゴをデザインするための45の法則だ。 以下にご紹介。 3つ以上の色を使わない。 絶対に必要というわけでないものはすべて除外する。 文字はあなたの祖母でも簡単に読めなければならない。 ロゴとはっきり認識できなければならない。 ロゴにユニークな形やレイアウトを取り入れる。 あなたの親や配偶者がデザインについて思うことを徹底的に無視する。 3人以上の人にロゴが魅力的に見えるかを確認する。 有名なロゴの要素を使ってオリジナルだと主張しない。 どんな場合でもイラスト集を使わない。 ロゴは白黒でもかっこよく見えるべき。 逆さにしても認識できること。 リサイズしても認識できること。 ロゴがアイコンやシンボル、テキストを含む場合、それぞれ良さが引き立つよう
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね?」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
ヨハネス・フリードリヒ・レオポルト・フォン・ゼークト(Johannes Friedrich Leopold von Seeckt、1866年4月22日 - 1936年12月27日)は、ドイツの陸軍軍人、政治家。ヴァイマル共和国軍最大の実力者。最終階級は上級大将。通称はハンス・フォン・ゼークト(Hans von Seeckt)。 帝政時代には陸軍参謀総長、ヴァイマル共和政時代には陸軍兵務局長、陸軍統帥部長官を務め、1920年代前半のヴァイマル共和国軍最大の実力者として「国家の内部における国家」である軍の権威を確立し[1]、軍部に多大な影響力を持っていた。また1930年には国会議員も務めた。 帝政ドイツ時代のゼークト 1915年、ハンス・フォン・ゼークト(右から3番目)とヴィルヘルム2世(中央)およびマッケンゼン(右から2番目) 1866年にシュレースヴィヒ=ホルシュタイン州でプロイセン陸軍将
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか? まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件(フィーチャ)を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
2023年01月04日01:09 カテゴリ (お知らせ)こちらのブログは閉鎖して元のココログに戻そうと思います お知らせ。(2023/1/4) ・こちらのブログは閉鎖して、ココログのほうに統一することにしました。 ・元々このブログは@niftyのココログで展開してました。 sanonosa システム管理コラム集 ・あるときココログに限界を感じてlivedoorブログに移転しようと考えてこちらを開設して少し移転してましたが、何年も放置したままでした。いつまでもこの状態は中途半端なので、こちらは閉鎖して元のココログに戻そうと思います。 どうぞよろしくお願いいたします。 sanonosa コメント( 0 ) 2017年12月17日10:38 カテゴリ 「Amazon Web Services負荷試験入門」の書評 技術評論社より「Amazon Web Services負荷試験入門」を献本いただいて
Four letter words: 題名だけではなんのことかさっぱりだと思いますが、これは先日 37Signals のブログ Signal vs Noise での記事「Four letter words」を読んでいて思ったことです。記事では他人、特にプログラマーとデザイナーのように違う畑の人とがコラボレーションしているときに注意しないといけない4文字言葉が紹介されていました。いいえ、f*** とか s*** ではありません。それは、 Need、Must、Can’t、Easy、Just、Only、Fast の7つです。使用例は次のような感じ。ちょっとあきれ気味の口調で読み上げると、やる気減退効果は絶大です。 We really need it. If we don’t we can’t make the customer happy. Wouldn’t it be easy if we j
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く