  |
はてなキーワード: ソースコードとは
まあ、どのくらいの数のギークがそういう彼女をゲットできるかは別にして、
「ギークではまったくないんだが、しかし自分のギーク趣味を肯定的に黙認してくれて、
その上で全く知らないギークの世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、ギークのことを紹介するために
知ってもらうべき10人を選んでみたいのだけれど。
（要は「脱オタクファッションガイド」の正反対版だな。彼女にギークを布教するのではなく
相互のコミュニケーションの入口として）
彼女の設定は
インターネットは普通に使うけど、フィードをがんがん読んだりする程じゃない。
サブカル度も低いが、頭はけっこう良い
という条件で。
まあ、いきなりここかよとも思うけれど、ネットウオッチを濃縮しきっていて、ネットウオッチを決定づけたという点では
外せないんだよなあ。
ただ、ここで Plagger トーク全開にしてしまうと、彼女との関係が崩れるかも。
otsune は Plagger のソースを読むことで perl を習得したことであまりにも有名だ。 otsune はネットウォッチを効率化するために Plagger を利用しているうちに、いつのまにか Plagger の committer になっており、モダンな Perl のコードを書いている。
ただただ、がむしゃらにソフト開発をしていたいという考えって、「ギークが考える一般人に受け入れられそうなギーク（そうギークが思い込んでいるだけ。実際は全然受け入れられない）」そのもの
という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには
一番よさそうな素材なんじゃないのかな。
「ギークとしてはこの二人は“人間”としていいと思うんだけど、率直に言ってどう？」って。
ある種の最速主義者が持ってる最速への憧憬と、はては社員的なネタへのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにも宮崎駿的な
「長髪なださカッコよさ」を体現するネタ
をはじめとして、ギーク好きのする LDR を世界にちりばめているのが、紹介してみたい理由。
たぶんこれを見た彼女は「 wassr だよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
この系譜のサービスがその後続きまくりなこと、これがアメリカでは大人気になったこと、
アメリカなら Google に買収されて、それが日本に輸入されてもおかしくはなさそうなのに、
日本国内でこういうのがつくられないこと、なんかを非ギーク彼女と話してみたいかな、という妄想的願望。
「やっぱり CodeReposはハッカーのためのものだよね」という話になったときに、そこで選ぶのは「 typester 」
でもいいのだけれど、そこでこっちを選んだのは、このユーザにかける征夷大将軍の思いが好きだから。
断腸の思いでかっこつけてもそれでも将軍くさい、っていう様が、どうしても俺の心をつかんでしまうのは、
その「捨てる」ということへの諦めきれなさがいかにも将軍的だなあと思えてしまうから。
Yappo のよく分からない英語の発音を俺自身は冗長とは思わないし、もう一生捨てられないだろうとは思うけれど、一方でこれが
なのに、発言の端々で将軍臭を漂わせて POST してしまう、というあたり、どうしても
「自分の物語を形作ってきたものが捨てられないギーク」としては、たとえ Yappo がそういうキャラでなかったとしても、
親近感を禁じ得ない。将軍としての表情の高評価と合わせて、そんなことを彼女に話してみたい。
今の若年層で Sledge::ThereText のソース見たことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。
Tatsuhiko Miyagawa のソースコードは可読性が高いことで世界的に有名であって、すごく技術的にバランスがいいので、世の Perl プログラマは学ぶところが多いでしょう
いわゆるKENT 的な CGI でしか Perl を知らない彼女には見せてあげたいなと思う。
ujihisa の Ruby で連投をギークとして教えたい、というお節介焼きから見せる、ということではなくて。
「日常使っているものから連投する」的な感覚がギークには共通してあるのかなということを感じていて、
だからこそ RejectRejectKaigi はビューティフルドリーマー以外ではあり得なかったとも思う。
そういうところを単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。地雷が火を噴くか否か、そこのスリルを味わってみたいなあ。
こういう Founder of 全裸／チンコが全裸でプレゼンしてそれを ust して、それが非オタに受け入れられるか
気持ち悪さを誘発するか、というのを見てみたい
9 人まではあっさり決まったんだけど 10 人目は空白でもいいかな、などと思いつつ、便宜的に dankogai を選んだ。
otsune から始まって dankogai で終わるのもそれなりに収まりはいいだろうし、 Encode 以降の Perl 時代の先駆けと
なったギークでもあるし、紹介する価値はあるのだろうけど、もっと他にいいギークがありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい 10 人目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
こういう試みそのものに関する意見も聞けたら嬉しい。
犯人が分かったよママ。開発効率が悪いのは商用のAPサーバーのせいですよ。EJBの仕様のせいですよ。あ、もちろん、仕様がおかしいとか、コーダーの質が低いというのは抜いて考えてね。
これを読んでる人たちはわかると思うけど、Tomcatとかで開発してればちょっとソースコードかえたらすぐ動かせるじゃん？メソッド追加したりしたら、再起動かけなきゃいけないけどさ、すぐに再起動出来るじゃん？待っても10秒かかるかかかんないかでしょ？声を大にしていいたいけど、商用のAPサーバー共は再起動に数十秒から数分かかるんですよ？そりゃね、再起動の必要がないような修正だったらさ、10秒ちょいで使えるようになるけどね、正直そんなに待ってらんないんですよ。そりゃEJBの仕様をうまく使えばそれなりの部分を補えるかもしれないけどさ、開発中にどれだけの回数再起動すると思ってんの？開発効率もそうだけど再起動効率をもっと考えた方がいいよ。まぁ、そういうAPサーバーで開発した場合の体感待ち時間比は、
それとさ、EJBとか使うとさいろーんなことができるのよ。でもね、できること多すぎるのに、実際使う機能って実はその中の1/100(感覚ね)くらいだったりするわけ。それってものすごーくたくさんの設定の中から必要なものだけを見つけ出して設定するのよ。まぁいっちゃえば、設定をプログラミングしてるみたいなもん。だからね、EJBの機能を使ってるだけだから自分たちでコードを書いてないわけじゃない。これで勘違いする人が多くて、その分のテストが必要ないとか、設定してあるだけだからAPサーバーを信用すればいいとか勘違いする訳。つか設定をプログラミングしましたよ？なんでその設定が間違ってるかどうかを検証しないでいいんですかと小一時間問いつめたい。
そんな重量級の仕様を把握してなければ使えないようなものは使わない方がいいと思う訳。例えばね、商用のAPサーバーを使う理由として、バグがあったときにサポートを受けられるからっていうのをよく聞くんだけどさ、そうそう簡単に問い合わせ出来ないよね？そうすると内部の仕様を推測して動かすよね？効率悪いよね？ていうかさ、設定があってるかどうかもサポートの人はわからないんだからさ。だったらオープンソースの方が自分で中身見れるし、そこまで深くないし扱いやすいじゃん。法律のことはよくわからないんだけど、APサーバーのバグで損害がでたらAPサーバーを出してるところの責任になるのかな？そうだったら使う意味はあるかもね。それでもそんなに重くなくていい。むしろTomcatをどこかが責任持ってくれればいいよ。
Railsとかさフレームワークでどれくらいの開発効率で差がでる！！とかいってるけど、APサーバーでの開発効率にもっと目を向けてもいいんじゃない？むしろAPサーバーをだしてるところは、そこで勝負するといいと思うんだけどな。むしろ、商用なんだから再起動にかかる時間を1秒くらいにしてほしいもんですね
______________
ちょっと番外編
あぁ、そうかー。仕事で開発をやってるWebシステムのPGがのびにくいのはそういったAPサーバーでしか開発をしたことがないってのもあるのかもね。だって普通の言語を勉強する場合だと、すぐにコンパイルして実行出来るからたくさん経験がつめるけど、そういった重量級のAPサーバー上でばっかり開発してる人だと、反復するのにすごいコストがかかるもんね。そりゃ伸びにくいよね。
そして、それを改修するという気持ちの悪い作業も嫌いだ
「給料分働かどうか」ということが問題なのではなく、現場の人間が肌で感じる不合理が意志決定にフィードバックされていないということであり、それは単なるシステム設計の失敗（あるいは運用の不具合）という問題では。
元増田の提言はそれなりに論理的なので、問題は、その提言が費用対効果を満たしているかとか客からの納期要求を満たしているかとか、そういう部分のはず。そこをきちんと詰め切れない上司に能力が欠けていると思います。「無意味な労働」を「精神論でやり抜く」のが仕事だ、という前世紀的労働観を個人が持つのは別に自由ですが、会社全体として持つのはいかがなものか。
そして、それを改修するという気持ちの悪い作業も嫌いだ
「君は自分の好きなことはどこまでもやるけど、そうじゃない事は全然やらない」
直すべきだとは思いつつも、どうにもこうにも露骨な態度だったらしい
事の発端として、たまたま面談があり、今どう思っているかを聞かれたのでそれを答えた
今の仕事は思っていた程面白い物じゃなかったし、やる気が出ない、だから、今のプロジェクトを抜けたいという自分の意思を伝えた
はっきり言ってやった
こんなクサレ仕事もうやってらんねーと
HTMLをIF文でただ分岐出力しているだけのえせCMSは使い物にならないと
仕組みとして全体設計をやり直すべきだろうと
初期はもっとシンプルだったはずなのになぁとソースコードを眺めるたびにそう思っていた
上司は、人間関係が嫌になっているんじゃないかって勘ぐっていたけど、吐き気するようなソースコード眺める方が、自分は嫌だ
そして、それを改修するという気持ちの悪い作業も嫌いだ
それを伝えたが、果たしてどれだけ伝わっているのやら
もし、今のシステムを全部フルスクラッチで書き直すというのなら、少しだけ興味が引かれる
今みたいな環境依存の言語をメインで使うというなら、きっぱりと断る
そう言ったら、冒頭の台詞が上司の口から飛び出した
なんだよ、結局正直に話してこれかよ
ちょっとその上司が嫌いになった
俺は大手のメーカーに2年勤めて、やっぱり技術的な向上心をもってベンチャーに転職したものの、結局は半年もせずに辞めてしまった。
そこは元増田が言ってる様な
意外だった。だってホッテントリでもよく見かける会社だぞ。そんな会社がわざわざ、ブログで求人までしているんだぞ。 ブログで就職とかTwitterで就職とか、いつも華々しく話題になるあれは何だというのだ。
な会社だったにも関わらず、開発されるシステムのクオリティは低く、ソースコード自体の洗練さもない現場だったからだ。
帰宅時間は早くて終電だったし、休日に出社して泊まることなんてざらだった。給料は半分になった。
若い会社だったからもあるだろうが、開発者としての意識の低い同僚、基本的なホウレンソウが出来ない同僚にも驚いた。
大手のメーカーの社員はなんだかんだでたまに技術志向の高い人間がいる。その人たちは業務でコードが書けなくても、独学で取り入れて自然に組織に浸透させていく。そういう人たちと比べてしまうと、どうしても失敗したと思わずにいられなかった。
辞めると決めたその時は他のこともあってボロボロだった。この業界はみんなこんなもんだろうと思った。
だから、半年ぐらい仕事もせずにいたけどあるきっかけで他のベンチャーに就職して今に至るわけだけど、みんなこんなもんだろうというのは大間違いで、ちゃんとした人がちゃんと仕事をしていた。
まあそこらへん、自分の場合は憧れが強くあったばっかりに、絶望が強くて復帰するのに時間がかかったという経験がある。だからこういうエントリを見るたんびになんだか、胸がチリチリっとしてくるんだよね
そりゃあ、オープンソースの定義には「ソースコードは無償で配布しなければならない」なんて文はないけど。
でも、ソースコードを有償で配布している奴なんて、いったいどこにいるの？
そんな奴はどこにもいないんじゃないの？
梅田望夫がオープンソースの俺定義をした！ってんで顔を真っ赤にして反論している人たちって何なの？
http://enbug.tdiary.net/20080315.html#p02
こことか、
http://kazuhiko.tdiary.net/20080317.html#p01
こことか。
オープンソースとは、ソフトウェアのソースコード（人が記述したプログラムそのもの）をネット上に無償公開し、世界中の不特定多数の開発者が自由に参加できる環境を用意し、そのソフトウェアをさらに開発していく方式のことだ。
成功したオープンソースプロジェクトで起こっている現象を説明する言葉としてはそんなに悪いものじゃないだろうに。
関連して：
http://d.hatena.ne.jp/hujikojp/20080320/selfish_progammer
http://d.hatena.ne.jp/hujikojp/20080321/misunderstanding_of_opensource
大学でプログラミングの演習をしています。(言語はJavaです)
if,for,whileとかの制御構文は理解し、クラス、メソッドや継承やインターフェイスといったオブジェクト指向の基本的な仕組みもある程度理解できました。
学校の演習で出る程度の、クラスが数個で済むような問題、例えば、ファイルを読みこんで文字数を数えたり、じゃんけんをするといったプログラムなら書けるくらいにはなりました。
でも、それ以上の規模のプログラムを自分で作ろうとすると、どうやって設計したらよいのかよく分からなくなってしまうのです。
例えば、自分は囲碁が趣味なのですが、いざ自分で囲碁のプログラムをかこうと思うと、どこから手をつけたらいいのか分からなくなってしまうのです。
プログラミングが上手い友人に相談したところ、ネット上にあるソースコードを読んだり、本に載っているプログラムを自分なりに改造してみたりすると良いと言われたのですが、正直それでを繰り返していても、あまり上達したという実感が湧かないのです。
みなさんは、どうやって大きめのプログラムが書けるようになりましたか?
私は朝が弱い。
起きたときにはいつも15時だ。
、、、え、15時！？
違う、違う。
7時だ。
つけっぱなしのPCの前に座ると、さっそうとEclipseを立ち上げる。
今日までの課題がある。
相手からメッセージが来るたびに、
ソースコードの135行目にある
messageVisitedメソッドが呼ばれるはずなのだが、一向に呼ばれる気配が無い。
メッセンジャーで誰かに聞いてみてもいいが、この時間では相手に大変迷惑だろうと思ってやめた。
よくよく自分でターミナルを睨んでいると、何やら例外がたんまり出ているようだ。
相手をうまく認識できていないらしい。
sunshine@earth: ~/kadai/java/chat/$ javac chat
sunshine@earth: ~/kadai/java/chat/$ java chat moonlight
Exception in thread "main" ,,,,,,,
私は目をおさえながら、ふうっと息をついた。
これは時間がかかりそうだ。
今日中の提出は無理かもしれない。
席を立つと、台所にあるコーヒーメーカーに水と粉をセットしてスイッチを入れた。
とにもかくにも、コーヒーでも飲まないことにはやってられない。
あと、必要なのは、何か食べるものだろう。
私は部屋を後にした。
またコンビニかよ。
ソースコードのコメントで日本語の書き込みを見るとなんか嫌な気分になってしょうがない。
これは特に自分はできるプログラマだと思っている人間に多いと思うんだけど、ちゃんとした文章は英語でも書けるくせに、開発上のやりとりになると「わざわざ」日本語を使って自分が日本人技術者に配慮していることをアピールする。なんで通常の文章で書けるように英語を使ってコメントすることに抵抗があるんでしょうか。そういう優越感ゲームってコミュニケーションの妨げになることも多いと思うんだけどどうでしょうか。
書き込みを英語で統一しろってのは日本語の出来ない人間の傲慢だという意見もあるかもしれんけど、なんで一部のプログラマは日本語での書き込みに固執するの？自分たちが特別だとでも思ってるんじゃないの？
ソースコードのコメントで英語の書き込みを見るとなんか嫌な気分になってしょうがない。
これは特に自分はできるプログラマだと思っている人間に多いと思うんだけど、ちゃんとした文章は日本語で書けるくせに、開発上のやりとりになると「わざわざ」英語を使って自分がバイリンガルであることをアピールする。なんで通常の文章で書けるように日本語を使ってコメントすることに抵抗があるんでしょうか。そういう優越感ゲームってコミュニケーションの妨げになることも多いと思うんだけどどうでしょうか。
書き込みを日本語で統一しろってのは英語の出来ない人間の傲慢だという意見もあるかもしれんけど、なんで一部のプログラマは英語での書き込みに固執するの？自分たちが特別だとでも思ってるんじゃないの？
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。
注意：以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。
なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)
Tuesday, February 19, 2008
先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。
それぞれのExcelワークブックは1つのcompound fileに収められている
つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。
もしあなたが週末を、Wordドキュメントをブログにインポートしたり、あなたの個人的な財務データからExcelフォーマットのスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通のプログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:
この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。
理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。
これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:
これはライブラリを使うことを想定して設計されている。もしあなたがバイナリをインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリのサポートが存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。
オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートをWord文書に埋め込んだりできる。完璧なWordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。
それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットはWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマがファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordのコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLやHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットがドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターとエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。
それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordのパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧なWordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンでWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。
それはアプリケーションの歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftのインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordやExcelには費やされてきたのであり、これらのアプリケーションの完璧なクローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションがサポートする全てのフィーチャーの簡潔なサマリーなのだ。
手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。
Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。
1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルがWindowsとMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelはファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。
実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙なディティールを発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelのソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙なビットを全て完全に記述することはできない。
そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。
唯一導き得る結論はこれだ。
MicrosoftがMicrosoftとOfficeのファイルフォーマットをリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットをインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチなアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムのリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。
オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。
ヘビーな仕事はOfficeにやらせよう。WordとExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。
この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:
これらのケースの全てにおいて、Officeオブジェクトにインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザに入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。
書き込むファイルにはもっとシンプルなフォーマットを使いなさい。単にOfficeドキュメントをプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマット、WordやExcelでも問題なく開くことができるようなフォーマットが存在する。
いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。
コーダークミ（２５）が１日夜、先月２９日放送のラジオ番組で「メソッドのステップ数が３５を超えるとソースコードが腐る」と不適切発言をしたことについて公式ホームページで謝罪した。所属事務所には批判の声が相次ぎ、同社が深夜まで対応を協議した結果、新アルバム「JDK 7 Project」のプロモーション活動を自粛する事態に発展した。
失言があったのは、先月２９日深夜１時から放送されたニッポン放送「コーダークミのオールナイトエクセプション」。番組冒頭、コーダーの男性マネジャー（３１）のコーディングの話題に触れ「やっぱ３５（行）超えると、ソースが腐ってくるんですね。ホントに！ だから、できれば１つのメソッドは３５行ぐらいに収めてほしい」と発言した。
この発言に同局には、放送後からこの日夜までにメールで二十数件、電話で数件の苦情や問い合わせが寄せられた。番組が収録だったこともあり、同局もＨＰで「パーソナリティー、コーダークミの不適切な発言を放送しました。配慮を欠き、誤解を招く放送をしたことをおわびするとともに、深く反省します」と陳謝した。
関係者によると、コーダーは「 LL ( Lightweight Language ) の楽しさを知って欲しい」というマネジャーへの愛情表現として発言したつもりだったが、現在は深く反省しているという。
美しさの定義によって違ってくるんじゃないのかな。
個人的に、無駄が無いけど頭を使う書き方は嫌い。おで馬鹿だがら。
それはそれで「美しい大きさと動き」なんだろうけど。
携帯とかの大きさ、速さを求める場合の美しさはこれなんだろうな。
あと、一発でおしまいの後で改修や流用をしない系とか、一人で組む場合もそうなんだろうなあ。
逆に、たくさんの人が触れることを考えた、人間の頭と目に優しいソース。可読性があるってやつ？これも美しいです。
こっちのほうが好きです。おで馬鹿だがら。
後々の機能追加とかを考えられるヤツの美しいはこれだと思う。
会社とかでこのひとじゃないとこのプログラムが直せない、というか他の人がやると時間がかかってしょうがない…なんてのはダメだからね。
見易くて理解がしやすければ、もし担当者がダメになっても他の人に助けを求めやすいです。
ゲームなんかも…一発モノだけどこっちの観点でやったほうが遅れが出にくくていいんだけどな……
そういや、昔はhtmlなんてメモ帳手打ち派なんていうこだわりさんがいたけど、ブロードバンドの今じゃ個人でやる限りは
以下から必要なファイルをDL。wiki/skinに放り込む。
http://code.google.com/p/google-code-prettify/
<?php if (PKWK_ALLOW_JAVASCRIPT) { ?> <script type="text/javascript" src="skin/prettify.js"></script> <link href="skin/prettify.css" rel="stylesheet" type="text/css"/> <?php } //** SETTING FOR GOOGLE CODE PRETTIFY! **//?>
<body onload="prettyPrint()">
Class Pre extends Element { ... function toString() { return $this->wrap(join("\n", $this->elements), 'pre', ' class="prettyprint"'); } }
define('PKWK_ALLOW_JAVASCRIPT', 1);
研究用に作成したプログラムのライセンスって何にしたらいいのだろう？
いろいろ既存のものをみてみたけれどランセンス表記のないものが非常に多い。研究者ってのはGPLすら知らんのだろうか？
そもそも公開してあったらまだいいほうで、論文はあれだけ公開するくせにソースコードは公開しないとか何を考えているんだろう。
まぁおいといて。
気になること。
プログラムを作ったといっても正直論文、教科書の数式をプログラムに翻訳しただけであってそこに著作権を求めていいのだろうか。
いや、もちろん求めていいのだろうけれど、ある程度レベルの高い人が書けば全部同じになるのではないかとも思うわけで。
また、コピー自由的なライセンスにしても、プログラムを書け宿題でコピーをされては困るし、そこも条件に入れたほうがいいのだろうかとも思ったりもする（そのような条件をいれても宿題で使ったかどうかなど発見できないが）。
そんなこんなでめんどうくさくなってライセンス設定していない人が多いのかなぁ。
レポートに詳細を書けって言われているんじゃないか？
数式で書くところをちゃんと書くとか、説明にしても文章で書けという。
どうして「ソースコードのＮ行目・・・」的な文章をレポートに書いたのかわからない。
ソースコードの解説でも書こうとしたのかい？いらんよ
可読性の高いソースコードが良いコードとされるに至ったのは、一体いつ頃からであっただろうか……。
その結果、何が起こった？
難解だが愉快なスパゲッティコードは悪となった。呆然とさせられるあの遊び心に満ちたトリッキーコードは悪となった。感動のコードゴルフもまた悪手とされた。
プログラミングとしての技巧的なものに取って代わって、より安易なコードを書くことが良いこととされるに至った。よりテクニカルな、たった一行にも知識と労力を要するコードよりも、誰にでも読めるようなコードが良いとされるに至った。
じゃあ、ぼくらプログラマを志すものは、一体何がしたかったんだ？ ソフトウェアを作りたかった？ 断じて否！ あの考え抜かれたコードの中に美と情熱と思想とを感じ取り、それに憧れたんだ。愚直なコードに誰が感動しよう、誰が憧れよう！ 誰にでも作れるようなソフトウェアでも構わない、他の誰にも書けないようなあのコードを書いた人々と、そのコードに憧れたんだ。それを解読できる人々に憧れたんだ！