サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
mumurik2.wordpress.com
戦争が短期決戦であると、軍の総帥が戦争のトップとなる方が有利と言われています。 戦争が長期戦になると、政治家が軍のトップとなる方が有利だそうです。
プログラマがお金を稼ぐ方法は、会社を興して成功するものらしい、という話を聞いていたので、そうやってお金を儲ける事にしました。
まず、ここではモデルとは何か、という事を感覚的に理解してもらい、それを実際のソフトウェア開発で役に立たせるのを目的とします。 哲学的な議論や言葉の真の定義を問題にはしません。 また、ソフトウェア開発の話をするのが目的で、真にモデルとは何か、という話をする気はありません。
ここ2~3年位の自分の仕事のやり方は、それ以前とずいぶん変わったように思う。 ようするにUnit Testを書いてIDEをフルに使い、Refactoringが出来るようになった、という事なのかもしれないけれど、それが意味する事は結構深い。 ここではレベルという切り口でそんな話をしてみたいと思います。 コーディング レベル1のプログラマのコーディングというのが、適当に書いてみてコンパイルして動かしてみて、動かないのをデバッガを当てて追っていって対症療法的に直すのを繰り返す、というスタイルだとしましょう。 レベル2のプログラマのコーディングは動くように書いて、コンパイルしてデバッガを当てて動かして、どこに勘違いがあるのかを知ろうとするスタイルでしょうか。 レベル3のプログラマのコーディングは、コードを書いてみて、バグが出得るかを考えて、何故バグが出る事が有り得ない形に書けないかをいろいろなコー
私は仕事のほとんど全ての時間をコーディングに費やしています。 最近仕事をしていて、そのさらにほとんど全てが、だいたい同じ作業である、と感じるようになりました。 それは何なのか?としばらく考えてみた所、 どうも「適切な抽象を作り出す」という作業であるという気がします。 「適切な抽象を作り出す」という作業は、 「何となく漠然と感じたり居るような気がする存在」に、 名前を与え コード上に存在するようにコードを書き換える 事を意味します。 ここでは短くする為、「何となく漠然と感じたり居たりするような気がする存在」を「何か」、 そしてそこに抽象を与える作業を「何か化」と呼ぶとします。 実際の順番としてはそういう向きだけでは無く、 名前を与えてコード上にそれを存在させてみて始めてそれが「何」なのかが分かる事もあります。 本当の理解には、名前を与えて存在させてみないと辿りつけない事の方が多い。 まず名前
私はパフォーマンスチューニングをちゃんと行えた経験を持ちません。 何度かチャレンジするのですが、いつも現実の状況と本来やるべき事との差の大きさに阻まれて、結局本来あるべき姿とは全然関係無い、我流の場当たり的な手法で少しマシなパフォーマンスにしてお茶を濁す事になります。語るのも恥ずかしい状況です。 reviewでも見積もりでもUnitTestでも、本来やるべきやり方でやると、我流でやっていたのが恥ずかしくなる程劇的な効果があるものです。パフォーマンスチューニングも間違いなくそういう物でしょう。 でもreviewや見積もりと同様、現実に適用する場合の最初の一回は、今の状況と教科書的な状況の間のギャップを、創意工夫や経験で埋めてやら無いといけません。そしてその埋める事がパフォーマンスチューニングではまだ出来た事がありません。 パフォーマンスチューニングがきっちり出来るプログラマ、というのはプロフ
ここ2~3年ほど、もう書くコード自体には進歩は無くなったと思っていました。 関心も良いコードを書くという事から、どれだけ多くの事を事前に予測するか、とか、速度やユーザビリティといった別の項目にシフトしていました。 自分のコードが悪い、と思っているのではありません。 むしろ自分が挑んでいる問題が小さな問題なので、ここより先は必要無い、と思っていたのです。 より大きな問題に挑むには、他の能力が足を引っ張るから難しい、 と思っていました。 また、大きな問題に挑む事自体にそれ程価値を見出せなくなってきていたため、 コーディング能力自体は必要と思うレベルを超えたと感じていました。 そういう訳でコード自体にあまり関心は持っていなかったのですが、 お仕事はコード書きです。 毎日朝から夕方までコードを書いて日々を過ごします。 そんな風に3年間も過ごしていたからか、 最近は自分の書くコードが変わってきたよう
プログラマのイメージ向上委員会。 私はだいたい定時で帰ります。 仕事が無い訳では無いけれど、残業はしません。 仕事の区切りが悪いとかで残業した時は、その次の日に早く帰る事にしています。 一週間全体で残業になる事はほとんど無いし、一ヶ月で5時間を越える事もほとんどありません。 だいたい9:00~17:00くらいの労働です。 最近は帰りに日が沈んでいて悲しいですが、夏の間は日が出ている間に帰ります。 帰り道、一仕事を終えて、暮れ行く空を見ながらafter 5の予定を立てつつ帰宅するのが一日の中でも好きな時間です。 給料はなかな貰っています。 年齢的な事も含めると、マスコミや金融系とも戦えるくらいです。 私が出来る仕事の中ではもっとも高い給料でしょう。 労働時間の短さを考えると、なんでこんなに貰っているんだろう?とすら思います。 おそらくこの給料を他の職種で超える事は、私には出来ません。 仕事の
さしあたって今年や来年に辞める気は無いのですが、それなりにお金がたまったらいったん退職して数年はぷらぷらしようかなぁ、と思っています。 そこでこんな風にしたいなぁ、というのをなんとなく思いつくままに書いてみます。 まず、退職当初は税金の振込みだとか書類関係がいろいろあると思うので、基本的には日本にいる予定です。沖縄のゲストハウスは安い、という噂を聞いたので、春は沖縄に花粉を回避に行くつもりです。 初年度は最低でも半年に一度くらいは今の家に帰ってきたい。 出先ではPC環境は無しで。ネット喫茶とかあればそこを使うけれど、ノートPCはもって行かない方向で。 沖縄に飽きて花粉の季節じゃなければ日本を適当にぷらぷら回ってたまに東京に帰ってきて郵便物を処理、という感じに。 一通り退職後の事務処理が終わったら、まずはインドネシアに渡ろうと思います。 あそこらへんをぷらぷら回って、ビザが無くなって来たらオ
なんとなくスト3シリーズの話をしたくなった。 あまり正確な話ではありません。真実が知りたければgoogleにでも聞いてみてください。 まず、スト3には、スト3、スト3 2nd ストライク、 スト3 3rdインパクトという三つのシリーズがある。 全くの別ゲー(シリーズ物ではありますが) スト3 2ってなんだよ、と2が出た当時は話題にした。 2ndインパクトってのがいかにもあれのパクりなのも当時はリアルタイムだったので話題になった。 スト3が出た当初、ブロッキングというシステムが一部の人に受けたが、ほとんどの人がやらなかった。 スト3はあまりにも素人殺し過ぎた。まず飛べない、技出せない、適当固めも全部ブロッキングで取られる(どの技も隙が多かった)、という事で爽快感ゼロのゲームだった。 なんかこう、一手一手が抜き身の剣みたいで適当に遊べない。 好きな人は惚れこんだが、素人は凄い速度で離れていった
というチャートが示されていて、最近は現場よりの需要も増えてきて新しいパスが出来た、とコンサルタントがどうこうとかアーキテクトがどうとか書かれていました。 基本的にはプログラマというのが一番の下っ端で、その上級職としてSEがあり、それを経験するとそれ以降の上級職につける、という認識は変わらないようです。 OSCで一番印象に残ったのはセッションでは無くこの冊子でした。 Open Sourceのイベントは、プログラマ寄りのイベントだと思います。 そのイベントで入場時に配られる会場パンフレットと同じ扱いのこの冊子ですらこうであるほど、プログラマが最下級職である、という認識は一般的なのでしょうか? おそらくそうなのでしょう。 私は現在外資の支社で働いています。 外資だと場所によるでしょうけれど、プログラマの地位というのは総じて高いと思います。 退職までプログラマを続けても居場所はありますし、出世もし
私がこういうの大嫌いなのは一部では有名な話ですが、職場では寛容に、ネット上では偏屈に、がポリシーなので素直に流しました。
蝕の前のあの勝負の話です。 アーキテクチャを決めて下の人に実装を任せたりだとか他人に仕事を振ったりだとかたくさんのサブコンを使って一定の品質のアウトプットを出すべく管理したりだとか複数の会社の係る仕事でお互いの進捗を管理しつつ予想外の事やらトラブルやらを調整したりだとか会社の方針を決めるような上の会議に参加して問題を根本から解決したりだとか業界の趨勢を決めるようなサービスの立案やら実現やらに力を注いだりだとか。 そういった仕事に関わっている天才プログラマよりも、現場の最前線で延々とコードを書いているコーダーの方が最後にはプログラマとしての「物を作る能力」は高くなる、という信念のような物を、私は持っています。 最後にはコードを書いている人が勝つ、と。 根拠は特にありません。 とにかく、ただ何もせずにコードだけ書いている人が最強だと思っているのです。 そう思うようになったのはいつからでしょうか
書き順を守っていると、expectedとinputの所にそのテストの本質が書かれます。 本質が分離されていると良い事は幾つかあります。 保守がしやすい、というのがそのうちの一つです。 まず、読みやすい。 expectedとinputを読むだけでテストの内容が理解出来る為、コードを読む必要はほとんど無くなります。 英語で説明的に書かれている為、他人の作ったUnit Testを一通り理解するのも圧倒的に楽です。 テストのinputとexpectを読めば一通りテスト対象のクラスの仕様も分かります。 Mockのsetup等手順が大きくなればなるほどテストの可読性は落ちますが、そこがexpectやinputと分離されていると、全て読まなくてはいけない場合でもだいぶ楽になります。 また、本質はあまり変更されません。 コンストラクタの引数が変わったり、テストに必要な何かが変わる事はあり得ますが、inpu
私が概ね全てのお仕事コードにUnit Testをつけるようになって、だいたい3年になります。 Testabilityという物に高い意識を持つようになった期間とだいたい一致している為、Unit Testを書くという事自体のキャリアもまだ3年です。 プログラムを書くという事だともうすぐ10年になりますが、Unit Testはようやく素人の域を脱した程度の所です。 まだまだそんなレベルではありますが、それでも3年続ければ3年続けただけの物もあります。 その一つとして、Unit Testの書き順という考え方があります。 Unit Testを書く時に、最初に何から書くでしょうか? 私は expectedの変数 inputの変数 その他 という風に書きます。1と2は入れ替わる事もあります。例を挙げましょう。 function Adder() { return {add: function(a, b)
ちょっとドラマみたいで格好良いですよね? 友人が訳していた Effective JavaScript http://www.hyuki.com/yukiwiki/wiki.cgi?EfficientJavaScript 追試出来ない速度の話題に、意味はあるのでしょうか? まずは計測環境。 IE: javascript:(function(){var w=window.open("about:blank");var s=’var p={b:function(){this.s=new Date()},e:function(){this.e2=new Date()}};function sP(){p.b();eval(document.getElementById("e").value);p.e();alert(p.e2-p.s);}’;w.document.body.innerHTML=”;w
最近更新する事も無くなってきましたし、spacesのアクセスログが無くなったりWordPress.comに移行させられたりで面倒も増えたので、更新をやめようと思います。 自分の過去の投稿はそこそこ気に入っているので移行はしてみました。 #このハンドルともそろそろお別れですかね。
upuloadの際、横長の画像が小さく縮小されてしまいました。明日からしばらくIPアンリーチャブルなので、それが終わったらupしなおします。 文字の大きさや画像の幾つかは差し替えがありますが、基本的な内容はこのままのつもりです。 前回は思ったよりも好評で、分かったという人も何人かいました。 でも今回は偏屈blogらしく、さっぱりわからなさそうな所まで突き進みます。 前回までで、あまり明らかになっていない部分が二箇所あります。 – TemplateContainer attributeの意味 – データ連結式を最初に解説した理由 この二つが今回つながります。 最初に用語の解説をします。 <%# %>で囲まれる式を「データ連結式」といいます。 半分英語で「DataBind式」ともいいます。 以下ではこの用語を使っていきます。 今回も例を出しましょう。 今回は、RepeaterControlの簡
artonさんの所の方が宣伝がしっかりしている、というのもあれなので(^^; ちょっとここまでのまとめをしてみます。 粗筋 ASP.NET上で開発する人はどうも基礎力に欠ける傾向にあります。 例えばDIとかデメテルとかDIPとか、Javaの世界では常識な物をちゃんと理解していなかったります。 JavaのPoEAAやExpert One on One系に該当する本は無いかな?というのが始まりです。 この時点で書いてある事、ITemplateに押し出せとかPageからControlへのリファクタリングとかITemplateのfakeなどはまだこの世に存在しない話題ですかね。 ここでITemplateの名前を出したのは、MVCやフロントコントローラなんかの話に対する牽制のつもりでした。 それではASP.NETじゃないでしょう?と。 それに対してartonさんから、patterns and pra
何故Openじゃなくてはいけないのでしょうか? 今MAYERを読んでいるのですが、いまいち納得いきません。 もともと私は、継承をどこで使えば良いのか、良く分かっていません。 それに対する答えを期待して読み始めたMAYERですが、やっぱり読んでも良く分かりません。 以下、つれづれに思う事を。 仕様は変わる物で、それに合わせてソフトウェアも適応するからmoduleはOpenである必要がある、とMAYERは言っています。 でも仕様が変わったから実装を変更したい、というのは、どういう場合でしょうか? 仕様に変更があった場合、そのまさに変更された場所が直されるべきです。 その時に他の部分に影響を与えないように継承が使われる、というのはおかしいと思うのです。 だって、そこは変更のあった場所なのですから。何故変更の無い場合を残す必要があるのでしょうか? そこが、他の事にも使われるのだとするなら、そちらの
前回、C言語の関数を説明するのにgcc -Sを示すかのような説明で、さっぱり分からないと大反響でした。 今回はもう少しだけ曖昧に話す事にします。 前提として – TagPrefixとしてMUを使う(mumurikのMUです) – UserControlの事は忘れる とします。 [粗筋] 貴方はASP.NETで開発をしているソフトウェア会社のプログラマです。 ある日、貴方のボスが貴方のデスクに来て「YesNoというWebControlを作ってくれないか?」と言ってきました。 まずはNOと言え!はRailsスタイルらしいけれども、ASP.NETはいつでもYESがスタイルです(嘘) このコントロールは以下のような物だとします。 YesNoコントロールはYesとNoの二つのボタンを持ち、イベントとしてYesとNoを持つとします。 class YesNoControl : WebControl {
では要望にお応えして…何故かDataBindの話を始めましょう(なんで?) 終わる頃には「なるほど」と思ってもらえるはずです(だとイイナ!)。 一応読みたい、と表明している読者が二人いる珍しい内容なので(一人はオフライン)、少し真面目に書きます。 ただ、かなり基礎的な話になるので、ひょっとしたら読むのは厳しいかもしれません。 (正直blogで扱える範囲は超えるかも。誰か本書いてください) なお、ASP.NET関連の書籍は全て職場においてあり、ASP.NETのインストールされているマシンも職場にしか無いので記憶とローカルにインストールされているMSDNだけで書きます。 だから間違いも結構あります。特にコードのコンパイル結果は何も見ずに書いているのでだいぶ違う物だと思います(実際はもっと細かい関数がいっぱい出来る) 根元だけくみとっていただければ幸いです。 基本的に、ASP.NETのページは要
面白いメタファーで言いたい事も良く分かり、本音ではかなり同調もしてますが(VSの他にもFrameworkをいじらずにコンパイラをいじるというのも圧力釜っぽい気はする)敢えてずらして反応する。
このページを最初にブックマークしてみませんか?
『勉強するのが、そんなに偉い訳!?』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く