「フルスクラッチ」を含む日記 RSS

はてなキーワード: フルスクラッチとは

2011-10-06

http://anond.hatelabo.jp/20110220013933

言語云々より、WEB技術に関する基礎知識がなにより大事

セキュリティ対策って何?文字コードって何?セッションって何?HTTPって何?って人多すぎ。

(フレームワークは使えるけど、フルスクラッチだと掲示板すら作れない人達プログラマとして働いてる現状)


WEB開発の言語論争は自称ギーク()でミーハーエンジニアが、

俺って時代を先取りしてるぅ!と言い争ってるだけ、

学習コスト運用コスト、実績、を明確に示せるエンジニアがいないかビジネス案件が一向に増えない。

2011-08-25

http://anond.hatelabo.jp/20110824135254

よこから失礼。

As3なら無料FlashDevelopで十分だよ。純正品より使える。FlexSDKも無料から、実質無料コンパイル環境は整う。

Adobeのやつも買ったがFlashDevelopのほうがいい。

あと、HTML5 vs Flashかいってるけどさ、ちょっとWEBにも動きがほしいよねレベルFlashはどうせ消えるでしょ。HTMLコーダーが食えてた時代が終わったみたいなもの。だいたい情報系の言語スキルなんて5年も持たないって。

ばかでもつかえるエディターが出ればすぐ終わるよそんなものHTML5もそう。

生半可な人がそこに活路をもとめて漕ぎ出したところでエディターが出るまでの寸暇のアドバンテージもない。

そんな範囲のことが飯の種になるわけないじゃなぃぃ?

誰かがつくったものを真似して、誰でもできるようなことになっちゃった制作単価下って食い合いになって終わりさ。

Airアプリでも書けって。だいたいHTML5比較するのにFlash語るのにAir含めないってどうかしてるよ。

ただFlexで書くならフルスクラッチゴリゴリ書けるひとじゃないと何もできないから、組み合わせるだけのプログラミングしかできない人はまだお呼びでないだけ。しかScriptなのにコンパイルからネット上でナレッジシェアされないしね。

FlexActiveXApplet比較するべきで、プラットホームHTML比較すんのはどうなのかなと思うよ。

あと、おまえらSilverLight馬鹿にしてるけど、日本にはこれが使えるエンジニアほとんどいか結構需要あるんだぜ?

MS以外の某大手もプッシュしている。

まり、何がいいたいかっていうと、どんな言語、ツール使おうが、その上位10%にでも食い込んでりゃ食えるよ。

というかプログラミングの上位で食ってる人が特定の言語が使えないなんてことはないよね。

もしそう思ってるんだったら、後から来たのに悠々と追いぬかれるよ。

環境のせいにしてちゃ伸びないんだぜ。

いまいるところでまず嚢中の錐になってくだせぇ


結論としてはFlex言語仕様は糞。殺す気か!

2010-12-09

私がIT技術者になれない理由

大学時代研究室史上最高のプログラミング実力者と言われ、就職後も有能な技術者として褒めそやされるものだろうと考えていた。

しかし、現実はそう甘くなかった。私の職業技術者としての実力は、せいぜい同期のド素人よりはましといった程度だった。

何故こんなことになったのかというと、答えは簡単で、私は、私自身の作ったものか、私個人が気に入ったライブラリルーチンしか使えないような人間だった。開発現場とは、何かを作る場所というよりは、組み立てる場所で、私にはその能力が致命的に欠けていた。

思い返せば、私は確かにライブラリを使ったことが少ない。ライブラリが出回っている分野でも、わざわざフルスクラッチで組み上げるなんてことをよくしていた。私は、多くの技術者が触れられない部分にまで触れられる自分の実力に多少の優越感を持ったものだったが、何のことはない、ただ他者の作った車輪を使いこなせず、同じ成果を得るために、二倍も三倍も時間をかけて、わざわざ不恰好な車輪から作り直していただけだった。

2010-01-14

http://anond.hatelabo.jp/20100114120719

おそらく過去に1億回くらいは言われたことなんだろうけど、

SIのビジネスモデルってほんと無理ありすぎだよなあ。

顧客ごとにほぼフルスクラッチシステム作り上げるなんて、どこの王族相手の商売だよと。F1かと。

その辺の普通リーマンが「俺専用の車を新規開発してくれ。500万円で。」とか言ったら「馬鹿か?」と言って終わりだろうに。

車なんて1車種あたり開発費数百億だろ。システムなら固定資産系の費用はかからないが、それを除いたって100億くらいはかかってるだろう。

SIでそれだけの予算プロジェクトは全体の0.0001%でもあるか?

IT技術者プロフェッショナルじゃないとか、プロジェクト失敗率が高すぎるとか言うけど、プロ仕事に見合う対価を払える構造に全くなってないんだから、それなりの人材しか集まらないのは当たり前だろって思う。

個々人が優秀だったとしても、個々の仕事にかけられる時間集中力が圧倒的に少ないんだからそれなりの成果しかでねーよって思う。

発注側は費用対効果計算するときにプロジェクト失敗率とかシステムの実効的な稼働率とかを考慮に入れてリアルオプションかなんかで評価してみろと言いたい。無理だろうけど。

2009-11-08

エンタメ小説の書き方を考える(私論・Ver0.2.1)

小説を書こうとしているが、なかなか長編が書けない。

色々、本を読んだり、試したりしているが、難しい。



今までやってきた方法論と考え方をある程度、整理するために、自分の考えを書きながらまとめていこうと思う。

議論はしたくないが(ハイ、チキンです)、ご意見をいただけると嬉しい。

正直、純文学は俺自身よく分かっていないので、エンタメ小説の話という事を前提に読んでいただければ、と思う。



まず、物語パターンに対する有名な言説として、『村上龍の「穴に落ちた主人公が、穴から這い上がる」「 穴に落ちた主人公が、穴の中で野たれ死ぬ」の2つしかない』というのがある。おそらく、これはエンタメ小説の基本形だと思う。「そもそも穴はどうしてできたのか?」「主人公は本当に穴の中にいるのか?」「そもそも主人公はなぜ主人公なのか?」のようなことを延々と逡巡するのが純文学かも知れない(純文学は読まないので、間違っていたらごめんなさい)。純文学は、(面白い/鋭い/ビビットな/より本質的な)問題提起自体が重要であって、それを読者に考えさせることが主題である……様な気がする。ただ、純文学の作者にせよ、物語の基本を踏まえたうえで、あえて外すからサマになるのであろう、とは思うが。



話を元に戻すと、エンタメ小説の基本を俺なりにさらに単純化させると、「主人公が問題を解決するか/しないか」であると思う(以前、増田の「5分で物語を作れるにようになるコツ(p://anond.hatelabo.jp/20091002081424)」が話題になっていたが、この増田の考え方はそれほど間違っていないと思う)。ただし、エンタメ小説は、エンターテイメントである以上、読者を楽しませなければいけない。問題が解決するにせよ、しないにせよ、きちんと納得の行くオチにすべきであろう。そうしないと、読者は満足感を得られないだろうし、満足度が低い店に行かなくなるように、ファンもまた離れていくと思う。



もちろん、将来のファン離れを心配する前に、やる事があるのではないのか?というのはごもっともな意見だと思うが、やはり、自分でも読んでいて面白い物語を書きたいし、途中まで書いていて、自分でも面白くないなあ、と思った事がたびたびあるのでその辺を考えていきたい。



では、面白さとは何か、という話になる訳だが、「主人公が問題を解決するか/しないか」に絞って下に挙げてみよう。

(1)基本的に、読者は「主人公が問題を解決するか/しないか」分からないから、ハラハラドキドキする。サスペンス性(→suspense 不安感。特に、映画小説などで、観客や読者が危機的な場面にはらはらする感情)。あるいは、大抵のエンタメ小説の場合、「主人公が問題を解決してしまう(読者も基本的には楽しむために読むので、ハッピーエンドも望んでいるはず)」ので、どのように解決するのかという点が重要

(2)問題設定の面白さ(舞台設定/キャラクター設定/問題の大きさと主人公の能力バランスなど)。”奇(変わっている事)”であり、”妙(巧妙さ。全体のバランスも含めた緻密な設定)”なほど、評価が高いのではないか?ジャンルSFミステリの場合、いかに凝った問題設定と解法を用意するかがキモになると思われる。ただし、あまりにもぶっ飛びすぎていると、読者が感情移入できなくなる問題も発生するような。

(3)間口の広い感情移入の仕組み。感情移入できない主人公の小説というのは、エンタメ小説の”てい”をなしていないのではないだろうか。主人公に感情移入出来なければ、他人事と捉えられてしまい、熱中して読んでもらえなくなる。想定している読者になんらかの”共感”を持たせるような主人公を用意すべきではないだろうか?(例えば、何らかのコンプレックスを持たせる)

(4)展開のドラマチック性。(1)の”サスペンス性”にもつながってくる話だが、「読者が想定している期待度を超えるという意味で、予想を裏切る」展開が重要になるのではないか。展開が二転三転して、劇的な勝利(問題解決)をするというのが理想かも知れない。もちろん、より読者にドラマにのめり込んでもらうためには、(3)の”間口の広い感情移入の仕組み”が必要でないかと思われる。

(5)主人公の精神的成長によるカタルシス

つまり、教養小説ビルドゥングスロマン)的側面。通過儀礼イニシエーション)としての小説。これこれこういう理由で、彼は”強く””大人に”なったのさ、というお話としてのエンタメ小説



また、面白さとは何か、を追求していくと、以下のような視点も考えられはしないだろうか?

(1)読者の想像力を喚起させる事

例えば、文章レベルで言えば、情景が浮かんでくること。読者に、痛み/恥ずかしさ/快感などの感覚を想起させ、リアリティを持って受け止めさせ、疑似体験させる事。”体験的なもの”として、読者に受け取ってもらえるか。文脈レベルで言えば、展開の読めない”不安”感、手に汗を握る”緊張”感、問題解決による”達成”感などを過去の展開の蓄積により実現しているか?

(2)読者の欲望を刺激する事

例えば、女の子の描画。ポルノでも萌えでも女の子かわいらしさをどういう風に表現し、読者の想像力を喚起させるか。あるいは、食べ物の描画。うまそうな食べ物をうまそうに(文章で)描画できるか。カッコイ戦闘機をどう格好良く(文章で)描画できるか。外には、ファッションなど。粋なファッションを粋に表現できるか。読者が関心がある事柄に対して、いかに”幻想”を抱かせ、”欲望”を感じさせるか、という点。

(3)教養としての側面

さりげなく、”うんちく”を混ぜる。例えば、中世ファンタジー物だったら、朝食は貴族しか取れなかった事を説明しながら、朝食を要求する元貴族商人の心理を読者に想像させるなど(ライトノベル狼と香辛料」にそんなネタがあったはず)。個人的には、少々苦手。資料用に読んだ本で気に入った設定はメモっておくなどしているのだろうか?

(4)虚構と現実の境界性

例えば、伝奇ものの面白さ。現実の実在の人物(や場所?)がファンタジーで出てくるというハイブリット感。あるいは、2chのどこまでネタか分からない感というか。

(5)比喩表現の面白さ

暗喩と直喩。村上春樹は独特の比喩表現で有名になった訳だが。(1)の”読者の想像力を喚起させる事”や(2)の”読者の欲望を刺激する事”に密接に関わってくる。例えば、「彼女の組んだ腕の上には双丘が気持ちよさそうに並んでいる」の様な表現などはどうだろうか。

(6)気の利いた会話

最近流行りの会話劇だが、コント漫才ネット上のやりとりなど、トレンドの文脈をある程度押さえつつも(気に入ったネタストックしておくべきか)、表面だけの真似に留まらないために、自分言葉による体験的要素も問われるのではないか。

(7)説得力のある説教

ガンダム富野氏の説教くらいに説得力がありつつ、面白い説教するためには、独自の価値観を持っている必要がある。大抵の人は人生経験を積めば、それなりの一言を持っているはず。一人の人間としての成熟性が問われる、のかも知れない。

(8)笑いの要素

ギャグユーモアパロディ言葉遊びなど。個人的に苦手な要素である。自分の場合は、どうも野暮ったくなってしまう。センスや基礎教養が問われるからかも知れない。とにかく面白いと思う話を大量に読み、小話を書いたりして、自分にあったやり方を発見するしかないのではないか。自分の場合は、実にどうでも良い事を真剣に議論していく話がウケが良いようだ。

(9)恐怖の要素

笑いと恐怖は近いものがある、と言われている。(8)の”笑いの要素”がうまく書ける人は、恐怖もうまく書けるのではないか。これも個人的には苦手な要素だ。ホラー映画も苦手だし。単に読者のトラウマを刺激しても、嫌われるだけだろうし……。ただ、最近トレンドにはこの要素が絡んでくる作品も多いのではないか。また、サスペンス性を上げるという面でも重要な要素であろう(ジェットコースターのようなスリル快感の関係というか)。それから、演出技法としては(1)の”読者の想像力を喚起させる事”と関連性が高いと思う。スティーブン・キングなどを読んで勉強すべきかも。

(10)恋愛的な要素

いわゆる一つの萌え要素、と言う訳でもないが(ほら、スベった)、自分の中にある理想ヒロイン像を具現化して駆け引き思考実験するという意味では、裸になって踊るようなものだと思う。慣れれば快感になるのかも知れない。ただ、個人的には最近食傷気味。

(11)バイオレンス

闘争本能を刺激する要素。”読者の想像力を喚起”させ、重みのあるリアリティとして受け取ってもらえないと、単なる茶番になるような気がする。



……ひたすら要素を羅列してきたが、要するに、”読者の感情や価値観を揺さぶる”という点が重要なのかも知れない、と思った。

(文字による心理操作によって衝撃を与える、という意味では、詐欺師に近いものがあるというか。嘘をつくのがうまい人間お話を作るのが上手、というのも頷ける。本来、エンターテイナーというのはそういうものなのかも知れないが。ヤクザ業界というか。現在最強の任天堂さえ。というか、任天堂こそが勝つべくして勝っている”名博打打ち”なのではないか。そもそも、経営という概念自体が(ry



あと、話題になっている、うまい=面白いでない、という件について。

これに関しては、下のWeb引用本質に近いかも知れない。

テクニックは描いた量に比例する(作品の)魅力は考えた量に比例する



物語の中だるみについて。

Webより引用タイトルは、「物語の推進力」。

途中からなんだか間延びしている、なんだか乗れない、と感じたとき、物語の推進力が低下している。

主人公を追い込んだり、障害を増幅したりして、推進力を高める必要がある。すなわち障害やクリア条件を上げていくのである。

主人公は最後のゴールに簡単に到達してはいけない。ハードルが最初よりも下がってはいけない。敵が最初よりも弱くなってはいけない。

考えてみれば、続刊の出ない、あの小説やあの小説も、すでに、主人公を危機に陥れる「強い敵(難しい問題)」が取り除かれてしまったのではないか。あとは、シミュレーションゲームの終盤局面のように力押しで何とかなる状態というか。主人公がリアルに死ぬ/臨死体験するくらいの危機が常にある状態で、最後の最後で、”おおかた”の問題が片付くのが理想かも知れない。



文章力の磨き方。

基本かも知れないが、自分の好きな作家の文章を写す(タイプする)。良さが理解できない作家の文章を写しても多分、意味は無いと思う。文章を写すだけのヒマがない場合は、ラインを引きながら読むだけでも違うような気がした。逆に思ったのだが、好きな作家の文章をラインを引きながら読んでいると、作者の認識力の限界を見切る事がたまにある(例えば、そもそもの問題設定の矛盾とか、作者のルーツ(根源)はどこにあるとか)。その辺が大切なのではないか。また、好きな作家は最低二回読むべきかも知れない。

(Webより引用

正しく見るためには二度見よ。

美しく見るためには一度しか見るな。



努力不足について。Webより引用

スクラップビルドの不足。

実は、優れたツリーの裏側に何十枚もの「デッサン」がある。

書いちゃ捨て、拾っては直しのスクラップビルドが必要なんだが、

フツーの指南本はそこを省く。本書には「デッサン」の線が沢山見えてくる。

ダウンタウンコントの作り方。

まずはオーソドックスネタを考える、と。

例えば医者コントってテーマを決めたら、オーソドックス医者コントを、だーっと全部考える。

それだけでも充分おもしろいっていうネタにしておきつつ、更に松本がやった作業って言うのは、 部分部分で、どれだけ予想できる笑いを裏切るかって作業。確かにこれでもおもしろいけど、ここはこうやったらもっとおもしろい、こうやったらもっと裏切ってる…そういうのを延々繰り返していって、どれが一番ベスト裏切りかなぁってことを積み上げて、ネタを磨き上げていくんだって。

例えば、小説創作手法にシミュレーション的手法を取り入れるということなのかも知れない。つまり、何回も思考実験を繰り返して、ドラマチックな展開のものだけを商品化する、という考え方。確かに、小説は元々、思考実験的な物を含んでいると思う。



その他。

ハッカー的に小説を書くとするとどうなるか。

「最初からフルスクラッチすると、効率が悪すぎる(1から作るのは大変であり、ベーマガプログラムを改造しながらプログラミングを覚えていったように、まず改造する)」「問題を小さく切り刻む」「リファクタリング」的な要素を考えると、二次創作のSSをとにかく大量に書き、慣れてきたら、規模を増大させていく、徐々に設定も作り込んでいく、の様な方向になるのではないか。



まだよく分かっていない事。

あかほりさとる新書に、「見たいシーンを書け」と書いてあったが、全く別のWeb上の指摘で、「最近ドラマは、脚本家が見たいシーンだけ繋げていった感じで、物語的な山場や整合性が軽視されているのではないか?」のようなものがあった。その辺の解決法。

次に、再読に耐える小説とはどういう小説か、という問題。

文章の勉強以外であまり再読をした事がないので、よく分からない。

最後に、まだ消化できていない、村上春樹言葉

何かを創り出そうというタイプ人間には多かれ少なかれ、精神的な「欠損」があります。

その欠損を埋めようとするところから、何かをクリエイトしたいという欲望や欲求が生まれてくることが多いのです。

もちろんそれだけじゃないけど、そういうケースはしばしば見受けられます。

問題はその欠損をどこまで「普遍的なもの」にまで高めていけるかということだと思うんです。

中にはその欠損の欠損性にいつまでも拘泥しているという人もいます。

それでは本当の芸術にはなりませんよね。そのためには、人はもっと広く世界を見なくてはなりません。

 人生は長期戦ですから、ゆっくりとしっかり息をしながら、前に進んでいってください。



まとまらないけど、以上。



補足。

(1)確かに、とりあえず、稚拙でも一作書き上げるという考えもありかも知れない。試してみるか……。

(2)色々本の紹介、ありがとうございます。

(3)Webからの引用元を書かないのに、他意はありません。面白いと思った文章は個人的にスクラップしているのですが(ローカルメモ帳コピペするだけ、のようなもの)、URLまでは保存していませんでした。申し訳ないです。

(4)確かに、あるパターンの繰り返しや場面転換の組み合わせというのは、あまり考えた事がなかったですね。なるほど。……少し見通しが立った感じです。ミクロレベルマクロレベルの視点を重視しすぎて、中規模レベルパターン認識がうまくいっていなかったようです。皆さん、ご意見ありがとうございました。(さらに追記すると、これは上に書いたあかほりさとる新書の話にも繋がってきますね。それなりに問題意識を持っていたけれど、もう一押し足りませんでしたね>自分

2009-10-29

フルスクラッチ指向と枯れた技術の水平思考

くたたんは「フルスクラッチ指向」で、任天堂は「枯れた技術の水平思考」だ。だから、任天堂正義だ。妊娠大勝利!ということを言いたい訳ではないのだが。



とは言え、素人妄想するに、もし、「成功から没落への流れ」があるならば、以下のような物ではないかと思った。



(1)先端業界ではなく、"周辺"業界において、何らかの商品企画が立ち上がる。もちろん、金がないので、技術的には、チープな既存技術の組み合わせである。日本の場合、開発者現場感覚アイディアの妙が問われる。「枯れた技術の水平思考」。米国の場合、壮大な未来ビジョンの中の尖兵としての立ち位置である。前者の場合、会社上層部は大して理解も期待もしていない。後者の場合、理解も期待もある程度している。ただ、両者とも、安い掛け金を賭ける分散投資の駒の一つでしかないし、"周辺"業界なので、一癖も二癖もある屈折した人材が集まっているのは変わらないかも。



(2)日本の場合:「たまたま当たる」。当たったので、ゴテゴテと付加機能をつけて、バージョンアップしながら商品の寿命を延命する。当たらなかったら、次の商品開発に向かう。米国の場合:地道に理想に向かってバージョンアップが続けられる。ある日、追加した付加機能がユーザーから素晴らしく評価され、いきなり「歯車がかみ合う」。それでも、当初の壮大な未来ビジョンに向かってバージョンアップしていく。いくらバージョンアップしても、ユーザーに評価されず、兵站が尽きたら、次の商品開発に向かう。



(3)日米共通だが、徐々に部分部分をフルスクラッチ化していき、他者が追いつけないようにする。



(4)日本:付加機能をつけすぎて、ゴテゴテしてくる。一般的に、日本の場合、ボトムアップ型であり、ビジョンがそもそも明確でない場合が多い。右往左往しながら進んでいく。ウリに出来るような付加機能がなくなったら商品寿命おしまいに近い。米国米国の場合は、トップダウン型で、当初の計画のビジョンが達成されたならば、日本と同じようにゴテゴテと余計な機能をつけ、迷走する場合が多い。逆に言えば、任天堂は、「枯れた技術の水平思考」の本家だけあって、フルスクラッチリスクの罠からうまく逃げているように見えるし、アップルは、そのたびに新しいビジョンを提示するという逃げ方をしているように見える。細かいバージョンアップの積み重ねと比較的リスクを抑えた許容範囲内の冒険/実験をするのが大切であり、トレンドになっているような気がする。良く悪口を言われているSCEでも、ファームウェアの細かいバージョンアップは評価されているし、MSフリーの開発環境などもかなり評価されていると思う。



(5)その商品を打倒するような「イノベーションのジレンマ」が起こり、打倒される(可能性が高い)。

2009-08-18

http://anond.hatelabo.jp/20090818181833

わかってない人がそこらじゅう(顧客企業責任者とか)にいて、IT屋を困らせてるケースがとても多いんだけど。

システム開発って「製造」じゃないのよ。機械勝手に決まった設計図に従って車作ってくれるようなもんじゃないわけ。

車で言うと「設計」に対応するんだよ。

シャーシの規格をどうするか、特別仕様を盛り込むためにどうするか、エンジンはどれを使うか、あるいは一から開発するのか、

タイヤは?ホイールは?アクセルブレーキ機構は?ボディは?素材は?色は?オプションは?

顧客ごとにフルスクラッチで新車種を開発するようなもんなんだよ。

それだけでもう「やってらんねーんだろうな」って想像できない?

2009-04-08

http://anond.hatelabo.jp/20090408001238

帰宅

レスありがとうございます。

気持ちが楽になりました。


以下チラ裏



業務系って技術は全然いらないと思うんですよ

プログラミングスキルならifとwhileかけりゃ全然OK

意味不明なテーブルに対して、仕様も解らないのに延々とSQLを考えて、

hoge=higeで検索されてるよねっていう不毛テストを延々繰り替えして、

スケジュール間に合わなくて怒られて、(まぁこれは俺が仕事できないのが悪いんだけど)

最後の最後でドバッとフルスクラッチで書き直す。あほか

むしろ、技術的なことより、業務仕様に詳しくないとやってらんないと思うんです。

で、

正直、そういうのに興味はまったくないし、

なんかこれってITって言うのか?とか思ってたり。

1年間ずーっと。



とにかく、もっと技術的なことをやりたい。

今の会社の先輩、上司を見てても、年がら年中客先を転々してて、

あんなふうにはなりたくない。嫌悪感すら覚える。

漠然としてるけど、もっといい環境があるんじゃないのかとか思う。

ということでそろそろ退職届け書き始めます。



M男です。

お前はゆとりすぎる。社会人として意識が甘すぎるってところを突っ込んでください。

2008-10-11

私のプログラム

初めは小学生の頃か。

実物のスペースインベーダー記憶はない。

しかし、それを皮切りにアーケードゲームのみならず、ゲームウォッチ、ケームセンター嵐などを経て、ファミコンが登場する「ゲーム」の時代だった。

「ゲーム」コンピューターゲーム意味になった時代だった。小学生も「コンピューター」にワクワクした。

21世紀コンピューターにより人工知能ができる。そんな時代だった。

でも、アルファベットを知らない小学生BASICは難しかった。ぴゅう太がせいぜいだった。


中学生学校PC-9801があった。後のパソコンである。

PRINT」で文字を表示する。「GOTO」で行き先を変える。それは分かった。でも何をすればよいか分からなかった。

だから「ベーマガ」で16進数を打った。でも動かなかった。何度も調べ、直し、試した。デバッグした。

してようやくゲームが動いた。ゲームはつまらなかった。

でも動いた。自分の入れた文字で数字でコンピュータが動いた。自分で動かした。動かせた。

BASICで線を引きマシン語で文字を動かした。


高専に進んだ。Turbo Pascalコラムスもどきを作った。

初めてフルスクラッチで書いた。配列も使った。

小学生のころから6年が過ぎていた。

Turbo Cも使った。IDEで使うそれは、インタプリタのノリだった。

FM-Rレイトレースもした。一晩かけて、エラーが起きていた。

でも、構造プログラミングを学んだ。ポインタも学んだ。マシン語の知識が役立った。


Solarisも使った。EmacsやXも使った。オブジェクト指向も知らずC++にも触れた。

GC構造体を代入して使い回し、Xサーバを落した。

家のノートFreeBSDを入れた。rootになった。

awksed正規表現を学んだ。そしてperlに出会った。

コラムスもどきを作ってから6年が過ぎていた。

テレホーダイにした。Mewを使った。チャットをした。


perlで掲示版の書き込みをチェックし、madokaで遊んだ。CGIを書いたりした。

脆弱性を見つけた。作者にメールした。ドキドキした。

perlと出会ってから6年が過ぎていた。

オープンソースプロジェクトに参加した。

はてなに出会った。JavaScriptに出会った。

BookmarkletgreasemonkeyAjaxオブジェクトだらけだった。


初めはゲームだった。でも最初だけだった。

ハードを叩き、ライブラリを叩いていた。

サーバを叩き、ブラウザを叩いてきた。

気が付いたら24年が経っている。

今、pythonで書いている。

ようやく、言語の違いには慣れてきた。でも、まだLISPを使った事はない。


道はまだまだある。未知の世界につながっている。

作りたい物が本当は何かは分からない。作れる物が本当は何かは分からない。

でも、何かがあるような気はする。だからプログラムしてみる。

どんなふうに動くのかは分かってない気がするけれど、分かっている事もある。

今も「コンピューター」にワクワクしている。

それが今の私のstatusだ。


http://anond.hatelabo.jp/20081011173016

2008-07-29

未だにコードがどうたらこうたら言ってるやつは

未だに泥がどうたらこうたら言ってるやつは

http://anond.hatelabo.jp/20080717201617

平日は他人の書いた仕様書通りに実装して、土日は参考書通りにデモ実装して喜んでる暇があったら、自分の頭で一からアイデア考えて、すべての工程を自分でやれ。

土日に他人のWEBAPI使ってちっさいコード書いて自己満足してる暇があったら、フルスクラッチで大きなアイデアを実現してみろ。

ライブラリが使えるだけなのにプログラミングが出来ますって言っちゃっていいのかな?なんて引け目感じてる暇があるなら、さっさと自分で新しいライブラリ書いてみろよ。

ワンライナーが、コンパイラ依存が、言語仕様が、とかム板やブログ無駄煽りをやってる暇があったら、何か他人に役立つものを自力できちんと最後まで作れ。

RSSリーダー更新ボタン連打してる暇があったら、まだやられていないアイデアを目を皿にして探せ。

梅田モチオさん最高っとか余裕こいてる暇があったら、自分で起業して玉砕してみろ。

お前らのモヤモヤした悩みはお前らの行動によってしか解決されないんだよ。

起きてる間ずっと自分の頭で考え、決定的なアイデアに集中し、わき目も振らずに最後まで実装できたやつだけが、

泥のように働く』とか日本語能力皆無の癖して

偉そうにふんぞり返ってるアホをぶちのめせるんだよ。

2008-07-18

未だにコードがどうたらこうたら言ってるやつは


未だに泥がどうたらこうたら言ってるやつは

http://anond.hatelabo.jp/20080717201617


平日は他人の書いた仕様書通りに実装して、土日は参考書通りにデモ実装して喜んでる暇があったら、自分の頭で一からアイデア考えて、すべての工程を自分でやれ。

土日に他人のWEBAPI使ってちっさいコード書いて自己満足してる暇があったら、フルスクラッチで大きなアイデアを実現してみろ。

ライブラリが使えるだけなのにプログラミングが出来ますって言っちゃっていいのかな?なんて引け目感じてる暇があるなら、さっさと自分で新しいライブラリ書いてみろよ。

ワンライナーが、コンパイラ依存が、言語仕様が、とかム板やブログ無駄煽りをやってる暇があったら、何か他人に役立つものを自力できちんと最後まで作れ。

RSSリーダー更新ボタン連打してる暇があったら、まだやられていないアイデアを目を皿にして探せ。

梅田モチオさん最高っとか余裕こいてる暇があったら、自分で起業して玉砕してみろ。


お前らのモヤモヤした悩みはお前らの行動によってしか解決されないんだよ。

起きてる間ずっと自分の頭で考え、決定的なアイデアに集中し、わき目も振らずに最後まで実装できたやつだけが、

泥のように働く』とか日本語能力皆無の癖して

偉そうにふんぞり返ってるアホをぶちのめせるんだよ。

2008-06-20

http://anond.hatelabo.jp/20080620235237

も,もぉちょっとだけリーマンで上り詰めたいんです。。

くそー。フルスクラッチ専門って言い切っちゃおっかにゃー。。

2008-05-27

http://anond.hatelabo.jp/20080527024018

設計からやり直してフルスクラッチでどのくらいの日数で機能を実装できるのか、

さらにその効果が会社に対してどれくらいあるのか

そういうことを話してみないとただの戯言でしかないよ。

上司人間関係に悩んでるんじゃないかと心配してたんだとしたらなおさら、子供みたいな事言われた事にがっかりしたと思う。

上司に言われて

今日上司に言われた

「君は自分の好きなことはどこまでもやるけど、そうじゃない事は全然やらない」

直すべきだとは思いつつも、どうにもこうにも露骨な態度だったらしい

事の発端として、たまたま面談があり、今どう思っているかを聞かれたのでそれを答えた

今の仕事は思っていた程面白い物じゃなかったし、やる気が出ない、だから、今のプロジェクトを抜けたいという自分の意思を伝えた

はっきり言ってやった

こんなクサレ仕事もうやってらんねーと

HTMLをIF文でただ分岐出力しているだけのえせCMSは使い物にならないと

仕組みとして全体設計をやり直すべきだろうと

初期はもっとシンプルだったはずなのになぁとソースコードを眺めるたびにそう思っていた

上司は、人間関係が嫌になっているんじゃないかって勘ぐっていたけど、吐き気するようなソースコード眺める方が、自分は嫌だ

そして、それを改修するという気持ちの悪い作業も嫌いだ

それを伝えたが、果たしてどれだけ伝わっているのやら

もし、今のシステムを全部フルスクラッチで書き直すというのなら、少しだけ興味が引かれる

その場合、使用する言語はせめてPHPRubyにして欲しい

今みたいな環境依存言語メインで使うというなら、きっぱりと断る

そう言ったら、冒頭の台詞が上司の口から飛び出した

なんだよ、結局正直に話してこれかよ

ちょっとその上司が嫌いになった

2007-06-25

絶対安全なOSのための理想的なシェアは何パーセントだろう

世界シェアが0.0001%なら絶対安全だろうか?

そんなことはない。

クラックする利益がある人がいればなんとかしてやってしまうだろう。

シェアがどんなに少なかろうがクラックされない保証はない。

シェアの低いOSを使うことよりももっと安全なのはフルスクラッチで自分でOSを書くことだ。

かつ一台だけのマシンでしか使わないこと。

(使うマシンごとに別のOSを開発する)

さらに製作のための言語も自分で開発する。

機械語レベルバリエーションができる)

そのOSハッキングするのは至難の業だ。

http://anond.hatelabo.jp/20070625103752

- 転職ならen
- 派遣ならen
 
1ページ中1ページ目を表示(合計:16件)