「スパゲッティコード」を含む日記 RSS

はてなキーワード: スパゲッティコードとは

2019-04-29

anond:20190429085205

元号改正周りでさんざんドタバタあったうえに、元号発表からわずか1か月でですが?

僕は昭和平成に変えた時の処理が適当で異常があった可能性も考えているから、30年前どういう改修をしたかまでさかのぼらないとならないと思ってる。

テストケースどころか、オブジェクト指向構造プログラミングすらも怪しくgoto使いまくり時代スパゲッティコードをな!!

2019-04-17

若者応援おじさんの思い出

https://twitter.com/MAEZIMAS/status/1113114798672113665

若者説教する老害は二流。

一流の老害は「君たちこそが真のニュータイプだ」とか言って、若者自分既得権益確保のための鉄砲玉にする。

…いやマジ本当に、若い人気をつけてね。若者説教おじさんは、せいぜいまだ極限の不愉快ですむけど、若者応援おじさんに乗せられると最悪人生詰むので…

というツイート流行っているので、私が遭遇した若者応援おじさんについて書こうと思う。

当時の私は親との折り合いがつかず、学力もそこそこあったし、勉強もしていたのにも関わらず大学に進学せずにフリーターをしていた。実家を出たかったし、大学にも進学したかたから金の工面が当面の目標だった。そんなとき出会ったのが若者応援おじさんのAさんである。Aさんはバブルの頃に就活をしていて、まだインターネットやパーソナル・コンピュータというのが流行る前から電子工作プログラミングをやっていた人だった。実際、経歴を聞いてみると10回以上転職を繰り返しているものの、有名企業(今にして思えば、カビ臭いSIerだが)で部長をしていたことがあって、年収が1700万ぐらい稼いでいたこともある人だった。

最初出会ったとき自分が如何にすごいかということを熱心に語っていた。80年台後半ぐらいのコンピュータ開発の大型プロジェクトに関わっていたとか、セキュリティ専門家とか、今までに触ったことのあるプログラミング言語が300個を超えるとか。でも、当時の技術的なトレンド(MongoDBRuby on Rails、AngularJSとか)についての知識が限りなく少なく、「フレームワークなんてその場で覚えればいい」みたいなタイプだった。中学生の頃にラジオ工作したとか、はんだごてで電子回路設計したとか、そういう話は熱心にするのに、Bram Moolenaarの名前を知らなかったりした。要は、最近プログラマがどういう関心やインセンティブプログラミングやってるかを知らずに、過去の栄光を語ってるようなタイプだったと思う。

まぁ、それでも、その人のコネで中規模程度のSIer入社して、そこそこいい感じの待遇だったように思う。当時の私の技術力は『わかりやすJava入門』『たのしRuby』を一通り終わらせて簡単言語仕様を把握したぐらいでろくにコードも書いたことのないような人間だったから、定時で帰れて手取り二十万もらえるのは甘い汁を吸えたとは思うんだ。

でも入社を決めた一番の理由が、そのAさんが私の関心に理解があると思っていたからだ。というのも、当時の私は「人工知能人工生命に興味があります。三年後に大学入学するまでにプログラミングスキルを磨きつつ生活費学費を稼ぎたい」ということを明言した上で、それを叶えてくれる会社を探していた。技術力はないものの、「自頭がいいか入社してからプログラミングを覚えればすぐに戦力になるよ」と複数人間から言われていて、それぞれ就職先を紹介してもらえるような状況になっていた。今から思えば、そんなコードを書けない人間を自頭なんて胡散臭いもので褒めるような人間は信用してはいけないと思うし、口車に乗せられたと思うのだけど。そこは自分にも甘いところがあったように思う。あ、あと、補足しておくと、当時はDeep Learningなんていうのは全く人口膾炙してなかった時期で、スチュアート・カウフマン金子邦彦に憧れてたような、周回遅れの複雑系に魅せられた若者が私だった。

駄文を書き連ねてしまったが、要は

①親との折り合いが悪く、大学に進学したいが、金が足りない

実家を出るために生活費を稼ぐ必要があったが、飲食バイトとかではスキルが身につかない状態で、価値の高い若い時間無駄にしてしま

③そんなところに現れたのが過去の栄光を話す若者応援おじさんのA

自分殆どコードを書いたことのない業務経験で、21世紀になっても複雑系の話に興味をそそられるような斜に構えたスノッブ

という状況設定理解してくれればいい。

では、入社後の話をしよう。私が配属されたプロジェクトは80万行程度のJavaコードで動いてるBtoB向けの製品保守開発してるプロジェクトだった。やってることはGoogleAmazonMicrosoftみたいな大手ならやってるようなサービスの完全下位互換みたいなソフトウェアを、情弱だけど社員数は多いみたいな企業に売りつけるような仕事だ。国産とか、セキュリティとか、そういうよくわからない言葉を並べ立てて、海外UIも洗練されていて、優秀なエンジニア管理してるものセキュリティ的に怪しいと不安煽り立てて売りつけるようなやつだ。そんなクソみたいな製品でも年間5億円ぐらいの売上になるのだからIT系って糞だなって思う。ネット上では優秀な人間ばかりがアウトプットしてるし、NDAの名の下に詐欺まがいのソフトウェア(今回の例なら無料UIも洗練されていて、使いやすサービス)が明るみにならないのだから、こんな国はさっさとスクラップ・アンド・ビルドすればいいのにって思うよ。IT化されてないのが時代錯誤で〜みたいな記事ネット上でもバズるけど、実際には10年前のスパゲッティコードを惰性と不安につけ込んで売りつけるようなSIerがたくさんある。そんで、そんな意味不明ソフトウェアを導入すれば、どこに何があるのか分からないUI操作に大切な業務時間を奪われて、日本全体の生産性が落ちてしまう。ユーザー時間生産性を奪い、開発者にとっても技術負債しかならないようなソフトウェアを売りつけてる悪性腫瘍みたいなSIerはさっさと滅んでしまえばいいと思うよ。

まぁ、私が配属されたプロジェクトはそんな感じだ。まるで意義を感じないが金にはなってるプロジェクトに配属された。そのプロジェクトの根幹部分は一人のエンジニア設計開発しており、そのエンジニアは既に退職して、どこに何が書いてあるのかわかってない人間が後任として保守を行っている。盲腸みたいに全く有難みのない機能を増やすことでより高く売りつけるようなプロジェクトだった。

そのプロジェクトの中にいる人について話そう。プロジェクトマネージャー仕事漬けで毎月350時間ぐらい働いている60連勤とか当たり前で、常に酔っ払ったような、眠そうな目をしてる人だった。にも関わらず、同じプロジェクト人間仕事がなさすぎて業務時間中に関係ない談笑をしたりしていた。プログラマテスター文書作成をするスタッフが40人ぐらいいるところで、閑散期(機能追加のサーバーリリース前以外)は暇そうにしてる人が多かった。プロジェクトマネージャーを除いて。要は、PM一生懸命働いているが、その一生懸命さは惰性で行われており、無能なのに業務時間が長いPMがいて、その人が全部仕事をやってしまう。他人に頼めない性格らしくて、存在意義が分からない業務他人に頼んでは「なぜこんなこともできないんだ?」って怒鳴るのが生きがいみたいな人だった。頑張ってることがアイデンティティになってて、その頑張りに意味があるのか、必要なのかという吟味ができず、タスク他人に振ることもできず、情報もそのPM一人だけが握っているから、周りの人も「私が仕事を請け負いましょうか」ということもできない。それで新入社員をイビるような存在意義のわからない仕事を振って、できなかったら人格否定をするような感じの。

私が受けた仕事ととしては、週に1回ベンダーのところに会議をしに行くんだけど、そのときの社内の資料を全部紙でプリントアウトして持っていくというのがあった。文書作成スタッフ製品仕様Wordでまとめて、600ページぐらいのpdfにしたものが1500万円ぐらいで売れるらしく、その増えた言語仕様プリントアウトしてベンダーのところまで持っていく。追加された仕様以外にも、今週やったテスト内容をExcelで纏めたものプリントアウトしたりしていた。紙の量で言うと、一回の会議で2500枚ぐらいで、それをキャリーケースに詰めて客先であるベンダーまで持っていくらしい。聞いた話では、その2500枚の会議資料殆どまれずに捨てられるのに、そのPMベンダーにその慣習を廃止しようとは提案しない。ベンダーとの週一の会議の他にも、進捗報告を主とする社内会議があって、PM以外の人はあのプリントアウトする悪習は廃止すべきという話が上がっているのにPMが首を縦に振らないから一向に改善されない。まぁ、そのプリントアウトするのをやるのが私の仕事だったわけですよ。毎週4時間ぐらい掛けてWordExcel文書サイズとか調整してさ。元の文書サイズや余白が狂ってるのに、客先に失礼だと言われて、手直しして、プリントアウされたコロコロコミック何冊分だよ? みたいな紙の束をホチキスで止めていくんだけど、ホチキスの止め方が汚いとやり直し。

じゃあ、なぜPMは頑なに意味のない業務をし続けて、それによって新入社員を使い潰そうとするのかと言えば、弊社の業績が悪くて倒産しそうだったときにそのベンダーが手を貸してくれたからそのときの恩義があるとかなんとか言っていた。だから、靴を舐めるようなことをするし、他人生産性を奪うようなクソ製品を世の中に出して何も感じないらしい。読みもしない産業廃棄物を作り出して、それを無碍にされて喜んでいるような業務が、今の日本の何割を占めているのだろう? そのPMの口癖は「俺はプログラミングは全くわからないが、こんなプリントアウト段取りもできないようなやつはプログラミングなんてできないと思うよ」だった。FizzBuzzどころか変数関数すら知らないような人間にこんなことを言われるのは屈辱だったし、これが高卒経験就職することなのだろうと思った。

他にも、私が受け持った仕事に、製品が動くかどうかを確認するテスターという仕事があった。RSpecSelenium自動化しようと言っても、そんな技術を持ってる人がいなかったから、一々自分でその製品を触って仕様通りになっているか確認しないといけなかった。画面遷移が600ページのpdfになっているから、それを見ながら正しい画面遷移ができているか確認する業務だったが、正直人間のやる仕事ではないと思う。画面遷移だから前のページから次のページに移行したときに前にどのページだったなんてスクショを撮ったぐらいじゃわからないのに、「このテストExcelにした内容じゃ、本当にテストしたのかわからないだろう?」と言われた。言われたとおりにExcelファイルスクショをひたすら貼り付けていたというのに。しかも、その他にも特定ファイルアップロードするときにどの条件だとアップロードができないか判別するテストをどうやって行うのか考えろというのがあった。今までにテスターをやっていた人に聞いても指針なんてないと言われ、「賢い人はそういうのを考えつくものだ。俺はパソコンに詳しくないが」とPMに言われ、嫌気が差した。

まぁ、ここまで書けば、如何にブラックと言うか、理不尽で不合理な職場かというのはわかったと思うけど、いい面もあったんだ。前にも書いたように、未経験高卒手取り20万貰えたのは嬉しかったし、研修のない会社だったから、最初の二ヶ月ぐらいは一人で勝手勉強しててと言われたから、実働換算で時給3000~4000円ぐらい貰える計算だったのかな。一番瞬間時給が高かった日はメールの返答に20分ぐらい使ったときだったから、日給1万、実働換算の時給が30000円ぐらいになった。それぐらい放任されていた。

最初社長が「君にはソースコードUMLを書いてもらおう」とか言って、クラス図を書く練習をしていたんだけど、現場の人は「今更UMLなんて必要ない」「ソースコードを読めばわかる」と言って、全く必要とされていなかった。だから業務とは関係ないTCP/IPRubyGit勉強をしていた。家のことで勉強に対してモチベーションが落ちていた私は、金を貰えるという環境では目の前の勉強に集中できるようになって、元の勉強するための生活リズムっていうのか、そういうのを取り戻せた。それは当時の私にとっては有難かったと思う。

ここまでをまとめると

無料で使えるサービス下位互換といえるような、他人生産性と金無駄にするような製品を開発してるプロジェクトに配属された

PMけが忙しく働いて、周りの人の割り振りができていない。

PM多忙なのはしなくていい仕事を引き受けているだけ。

社会悪のようなソフトウェアを売りつけて金を稼いでいるプロジェクトだった。

仕様書やテスト内容のプリントアウトという必要ない業務をしたり、指示内容と叱責内容が矛盾する理不尽を受けなければならなかった。

しかし、勉強してるだけで月20万貰える環境は有難く、当時の私にとっては願ったり叶ったりだった。

では、次に私がその会社入社から辞めるまでの経緯について書こう。最初のうちは、自分勉強時間を取れていたし、振られる仕事理不尽で意義を感じられないものであるものの、すぐに終わることが多かったか問題ないと感じた。それが徐々に仕事が増えていき、勉強時間が取れなくなっていった。

ここで若者応援おじさんAの登場である。Aさんは私と会ったときは有名企業に勤めていて、そこを辞めて私を紹介してくれた中小企業で働き始め、その数カ月後に私を紹介してくれた。元々、その会社社長とは懇意にしていたから、一緒に働こうという話が何十年も前からあって、今回ちょうどタイミングが合ったから、その友人の会社の重役として就職したらしい。私が就職したのはその数カ月後だった。

Aさんは「何か問題があったら、部下や上司という立場を気にせずに忌憚なく言ってほしい」「俺は人を見る目はある方だ。君は一本芯の通ったところがあるから、周りに流されずに新しいことをできるだろう」「君には将来性がある」「俺は新しい会社でも権力を持ってるからへんなことを言ったり、したりしてる人がいたら遠慮なく言ってほしい」とかそういうのを入社する前に言っていて、まぁ、色々とおかしいところ、FAKE野郎みたいな発言が多かったけど、そこだけは信じてたんだよね。本当に騙すんだったら、そんなすぐに辞められるようなリスクを上げるような発言はしないだろうってさ。ちなみにFAKE野郎って感じたのは、一方的自分の話だけをして、私が質問すると煙に巻いたり、私のことを買ってるという割には私の話をすぐに中断させて自分の話をし続けるとか。その人はFラン出身だったから、ちょっとインテリなことを言うと「君は変わってるね」って言ったり、きょとんとした顔で10秒ぐらい固まった後、すぐに自分の自慢話を再開したりと、決して自分の知らないことや分からないことを認めようとしなかった点だ。他にも、「私と働きたいと言ってくれていた会社はあったけど、そこは技術的に成長できそうだけど給料は月7万程度でバイト身分から、迷ってるんですよね。バイトから自由時間は多く取れるんですけど」みたいな発言をしたら、鳩が豆鉄砲を食ったような顔をして、私が感じていた不安を取り合ってはくれなかった。Aさんは「俺は社内で影響力を持っているから、君を正社員にすることもできる」みたいな話を延々としてたのに、いざ蓋を開けてみると、「君の面接での受け答えが駄目だから契約社員として雇用することになった」「あれから上層部に渋られてしまって、請負契約にすることになった」と話が二転三転していった。だったら、他にも選択肢があったのに、他のところに就職したのにと思ったが、自分能力や経歴で負い目を感じていたから強く言うことはできなかった。高卒就活するというのはそういうことだ。他にも選択肢があるのにも関わらず、どうせ労働に関する知識がないと足元を見られて、条件を徐々に下げられ、他に選択肢をなくした後で、悪い条件で働かざるを得ない状況になっていた。結局、勤務時間タイムカード管理されてるのにフリーランスとして請負契約を結ぶという偽装請負契約させられ、もっと技術力を磨ける選択肢は潰されてしまっていた。

私は会社問題点を丁寧に分析してpdfにまとめてAさんに送ったんだ。それが間違いだった。如何に会社がそのベンダーに良くしてもらったか、大変なのをわかった上で俺たちが会社を立て直してきたかということばかりを話していた。百歩譲ってそこはいいとしても、ベンダーとは関係なく職場環境を良くするための話までいい加減に聞かされてうんざりしていた。

「Aという問題があります。その背景にはBがあります。そのためにはCという解決策があります

という話をしたときに、「Bぐらいみんな当たり前にしている。君だけ特別扱いすることはできない」みたいな返し方をされて、問題が発生してる事自体はないものとされていった。結局、職場にはびこる不合理で理不尽業務ルール改善することはなく、私への人格攻撃で終わってしまった。

毎日どうでもいい作業で疲れ切って勉強時間が取れなくなってしまった私は、最初出会った頃のAさんの言葉を信じて、「私が本当にしたいことは、仕様書やテスト時のスクショプリントアウトしたり、よくわからないテスターをやったりすることではない。このままでは、プログラマとしてのキャリアを積むための勉強時間を作ることもできないし、業務内でコードを書くこともないか業務時間を短くしてほしい」と言った。少なくとも、最初Aさんと会ったときは、「君には人工知能このエントリーをはてなブックマークに追加ツイートシェア

2019-02-24

もっと有意義時間の過ごし方

それは、何もしないことだ。

最近やっと分かってきたんだ。

社会的生物としてはそれは×印をもらう行動のように思えるが、

それ以前に人間という生物として自分のことを捉えなきゃいけなかったんだ。

何もせず過ごす時間は何よりも大切で、有意義で、生物の基礎として譲ってはならない時間だったんだ。

他の哺乳類霊長類を見てみろ。彼らは圧倒的に、何もしていない時間が長い。そこに気づきを得るべきだ。

動物人間は違う、などという考え方はただの驕り高ぶりにすぎない。

何もしない時間のことを休息と呼ぶなら、睡眠も似たような文脈で語られることがあるが、それとは別だ。

十分な睡眠も当然、何よりも死守すべき時間のうちの一つではある。

脳のデフラグタイムである睡眠大事だが、それをハードウェアデバッグとするならば、

覚醒時における何もしない時間は、ソフトウェアデバッグだ。

別に瞑想というほど作法にこだわる必要はない。

何もしないでいられるほど、日常タスクやら何やらに追われずに済む時間

それがあって始めて、人間精神は強固な安定を得られる。

精神の安定は、何もしない時間きっかけに始まる自省によってもたらされると考えられる。

自省を「する」という感覚ではなく、ぼーっとすることが自省に「なる」のだ。

自省というと説教臭い印象が出てしまうが、言うなれば自分輪郭を正しく認識するための時間だ。

世界自分境界線キャリブレーションする、ということだ。

そういう機会を失ったまま毎日をすごし、それを何年かつづけると、人間は壊れる。

たいてい肉体よりも先に精神が壊れ、最終的には自殺へ向かうように脳が動き出す。

思うに、鬱になった時点でやっと何もしない時間を得られても、ほとんど手遅れなのだ

不適切コードの上に不適切コードを何重にも重ねたスパゲッティコードが、

致命的なエラーを吐きはじめた時にやっと手直しを始めようと思っても、ほぼ諦めざるを得ないレベルに困難なのと同じなのだ

これは、休日にしっかり休息をとる、という話ではない。

おそらく、睡眠と同じように毎日必要時間なのだ野生動物のように。

1日に何分、あるいは何時間、どれくらい必要かは分からないが、長ければ長いほどいいだろう。

これ以上何もせずにいられない、と自発的に動き出す気になるまでは、ぼーっとするべきだ。

これは個人的体感なのだが、睡眠場合、前日にたくさんの経験をした密度の濃い日ほど、多くの睡眠時間必要になる。

それと同じで、たくさんの情動を抱える人、精神が揺さぶられた日ほど、多くの何もしない時間必要になるのではないか

その点でいうと、このサイトに書き込んだり閲覧したりという行為は、人によるがいたずらに情動を激しくする行為と言っても過言ではない。

増田を利用するのなら、同時にぼーっとする時間も摂らねばならないと考えられる。

2019-02-16

anond:20190216172922

俺も似たような状態で「これマジゴミっすねークソっす。数年ぶりにスパゲッティコードって単語思い出しましたよ」って言いたいけど相手は客なので言えない

まあ俺も正しい教育を受けてない自己流だから俺が間違ってるかもしれないし

リーナスも人の心取り戻したしね・・・

部下と共有して反面教師にしたらちょっとは気が晴れるかな・・・

ダウンロード違法化について

 ダウンロード違法化話題になっている。

 このことを考えるには「本とは何であるか」を今一度考える必要がある。

 本はもともとは「情報を記録してより多くの人に伝達する」ためのものだろう。

 「作者が金銭を得る」ことは本来なら「副作用」に類するものだ。

 「本とは何であるか」を見失ってしまたから複製が罪とされるのだ。

 もちろん、これは個人の感想に過ぎないが、もし間違っているなら教えてほしい。

 本とは一体何なのか?

 なぜ本を複製することが罪となるのだ?

※なお「本」をテーマとしているのは真偽は不明であるダウンロード違法化出版業界要請であるとされているため。

 もはや、この前提が正しくないのかもしれない。

 ミリオンセラーを出せば巨額の富を得ることできたのが、よくない。

 「良い商売」になってしまたか権力構造が生まれることになる。

 当初の目的は忘れ去られ、一部の人間のための理屈が全体を支配する。

 かつては「製本コスト必要」だったから、その費用請求したに過ぎない。

 しか現代ではデジタル技術によりゼロコストでの複製が可能だ。

 複製コストがかからないのなら読者は料金を支払うのはなぜか?

 「本を出したい側」すなわち「情報を記録したい側」「情報を伝達したい側」にとっては「無制限いくらでもデジタル複製できる」現代の状況は本来ならば喜ぶべきことではないのか?

 記録性や伝達性を高めるために生み出された手段としての本だが、逆にそれらを喪失しつつある。

 商売邪魔になるからと記録されなくなる。

 これでは本末転倒ではないか? 方向性を見失ってはいいか

 複製が悪と言うならばテクノロジーは間違った方向に進んでしまったのだろうか?

 複製コストだけじゃなく作者の生活費必要

 「本を売る」ということで作者の生活保障するシステムだ……、というのは一理あるだろう。

 だがシステムとしては欠陥まみれだ。拗れすぎてしまった。まるでスパゲッティコードだ。

 通説では「本を売るだけで生活できるようになれば生活のすべてを本を作ることに費やすことができる」とされている。

 しかし「売れること」への強迫観念質的変化をもたらしてしまった。

 競争はとても過酷だ。限られた人間けが「作者」になれる。

 「売れなければならない」から表現たかたことを切り捨てる。

 だというのに本は売れずに儲かりもしないなら怒りも沸くだろう。

 一体誰が得をしているというのだ?

 「本が売れなければ作者は生活できない」とは作者になれた側の理屈だ。

 現在システムでも切り捨てられている人間はいる。

 日の当たることのないものは闇の中へ葬られ、なかったことにされているだけだ。

 「本を出す」ということが「競争勝利した」という別の意味合いへと変容しつつある。

 半ば競技化した出版競争というもの他人を踏みつけた上にある勝利だ。

 ジャンルにもよるが、作品の中でどれほど綺麗事を語っていても、背景にあるのは血生臭い権利の獲得競争だ。

 トロフィー価値が下がるから「本は売れなければならない」という逆説的理論が構築される。

 目指すべきは「本が売れなくても生活できる」社会ではないのか?

 なら、いかにしてそれが可能なのか?

 ここで映画音楽の例を見てみよう。

 ところで映画音楽はいち早くダウンロード違法化を取り入れた。

 しか音楽なら公式MV公式無料配信され、映画なら地上波で放映されるものも珍しくない。

 有名な作品ほど、そうなる。

 結局はダウンロード違法化とは裏腹に無料デジタルコンテンツ提供されている状況だ。

 その一方で知名度の低い作品は人に知られることもなく消え去っていく。

 ダウンロード違法化によってデジタルデータ販売収益が得られるようになったのだろうか?

 どうやら、デジタルデータ販売とは別に収益を得ている様子だ。

 映画音楽と本の違いはなんなのか?

 キーとなるのは「施設」だ。

 映画ならば映画館が、音楽ならばライブハウスコンサートホールがある。

 他にもスポーツ場合でも施設があってプロがいる。

 野球ならば野球場、サッカーならサッカー場、バスケットボールならバスケットコートプールならプールゴルフならゴルフ場といった具合にだ。

 お金が欲しい人とお金を払いたい人が施設に集まる。

 施設を基点とする集金システムは、強い。

 「他人土地に無断で立ち入ってはいけない」という始原的なルールに基づいているためだろう。

 うまくいっているファンビジネスには施設があって、うまくいっていないファンビジネスには施設がない。

 本は施設との結びつきが弱い。

 「基盤となる施設の不在」こそが本の作者の食えないことの最大の要因であるとは考えられないだろうか?

 本にも書店図書館漫画喫茶といった関連施設があるにはある。

 だが、それらは作者の収入に直接的に結びついてはいない。

 デジタルデータのない時代、本は書店に行かなければ入手することができなかった。

 書店は「発売日に本を手に入れる」という日常の中でのプチイベント提供する施設であったといえる。

 しか現代ではデジタルデータがある。

 しかも売る側の人間が「本と電子書籍は同じ価値ですよ」と宣伝しているのだ。

 実物とデジタルデータは本当に同じ価値なのだろうか?

 書店でのサイン会のようなイベントは「宣伝になるから」という理由無償であることが慣例となっているらしい。

 むしろデジタルデータ無料サイン会が有料であるほうが直感的ではないか

 テレビ放送されてこそ「遊園地で僕と握手」というシステムがなりたつ。

 アニメ業界も同様に施設を持たないか金策に苦労するのではないだろうか?

 イラストレーターならアトリエアニメならアニメスタジオのような施設はあるが、これらは工場に近い。

 売れないといわれているアニメ業界だが、一部のアニメ映画はその例外のようだ。

 映画館という施設のパワーを借りたからうまくいったのかもしれない。

 それでは、どんな施設を作ればいいか

 それは出版業界人間が考えるべきことだろう。

 もし何のアイディアも思い浮かばないようであれば出版業界になんの存在意義があるのか?

 出版業界などダウンロード違法化と一緒に崩壊してしまえばいい。

 もしも作者と読者が直接的に結びついてしまえば出版社はお役ごめんだ。

 今後の生き残りを狙うなら出版社にも施設を用意する動機はあるはずだ。

 商業施設というのはただそこにあるだけでなく「関係性」を提供するものだ。

 演者と観客、対戦相手講師と受講生、提供する側とされる側といった関係性だ。

 お金を持っている人、お金を使う人、あるいは大勢の人との「関係性」を提供する「施設」だ。

 もしくは公共性を持った施設でもいいかもしれない。

 ここでいう施設というものはまったく新しい概念でなくてもかまわない。

 地図でも開いて目に付く限りの施設を本と結び付けて考えればアイディアひとつも思い浮かぶことだろう。

 本が売れないかダウンロード違法化というのは根本からしておかしい。

 それよりも適当施設を用意するほうがよっぽど現実的だと思うがどうだろうか?

2019-01-23

anond:20190123154455

かにスパゲッティコードを読むのは大変だが、時間はあっただろ

結局、公務員試験IPA資格しか持ってないパソコン先生しか居なかったんだろ

内製が良いかいかは置いといて、素直に外部に委託した方が良いわ

ほんと、公務員試験って邪魔だわ。真面目な無能しか残らないし

2016-12-15

複数の集合の関係を整理してみよう

プログラマ「いやぁ、論理演算パターン多すぎてマジ混乱してきた・・・

?????「困っているようだね」

プログラマ「そうなんです。論理和 , 論理和否定, 排他的論理和...。いくつもあって頭が混乱してきたんです。」

?????「それならこれを使いなさい」

プログラマ「ぎゃー!!!あんなにイミフだったif文が視覚的に図式化されてスラスラ書けるぅぅうううう!!!!!あばばばばば!!!!」

?????「ククク・・・興味を持ったようだな」

?????「そうだろう。君がこの仕事を続ける限り、各集合をひとつの閉曲線(例えば円)の内部で表し、相関関係をその閉曲線の交わり方によって表す図を知っているということは一生役に立つぞ。」

?????「もうひとつ情報を与えてやろう」

?????「ド・モルガン・・・

プログラマ「え・・?」

?????「暗黒に染まったif文をキレイに書き直す度にパワーがはるかに増す・・その更新無限にオレは残している・・その意味がわかるな?」

プログラマ「いきなり意味がわからないことを言いやがって!!こいつ、なんかやばいぞっ!!!!」

ゴゴゴゴゴ....

プログラマ「だめだ!暗黒の力が強烈過ぎて僕のスパゲッティコードの力では太刀打ち出来無い(´・_・`)...!!」

プログラマ「きさま!まさか!!(((((((( ;゚Д゚))))))))ガクガクブルブルガタガタブルブル」

ベン図 「フハハハハ!!!!!!!!!!!そのまさかだ!」

2016-05-15

http://anond.hatelabo.jp/20160515204046

またすさまじいスパゲッティコードですが、要するにtimeengine.js

        set: function set(tval) {

の中の

              seq.valOnT = seq.evalEqs(tval); //self eqs eval

で値を破壊的に更新して、それを

        get: function get() {
          return seq.valOnT;
        },

で読みだしている、まさに命令型の変数ですね。

「どんなプログラムハードウェアレベルでは命令型」と言いますが、kenokabeさんのコードライブラリの内部実装だけでなく、ライブラリユーザに見えるレベルでも

      __drawFrom.t = {
        x: e.clientX,
        y: e.clientY
      };

など、もろに命令型の破壊的代入ですね。

2016-03-19

http://anond.hatelabo.jp/20160318091757

ああQiitaに出没してるスパゲッティコードと気炎吐くだけの駱駝さんね・・・

timeengineのソースコードはそのサイトにあるように200行以下にまとめられている簡潔なコードだけど、どこがどうスパゲッティになってるのか「おまえが理解できない」という以外のきちんとした理由でどうぞ?まあリファクタリングしろっつってもOCamlしか書けないんだろうし土台無理だろうけど。「お絵かきロジック」にするためには、マウスイベントとTimeengineそのまま接続したら良い、超簡単のはライブラリ特性として見りゃわかるが、それすら理解できないやつが何いってんだよw

2015-09-20

オブジェクト指向肯定的に扱われない理由を考えた。

システム定義する場合、そのシステム「どのような機能」を持つかと、その機能を「どのように実現する」か。という二つに分かれる。

前者は、アプリケーションドメインと呼び、後者ソリューションドメインと呼ぶ。

抽象化された論理的設計アプリケーションドメインに含まれソリューションドメイン言語環境適応させた実体になる。

少し前、システムソリューションドメインのみを実現したモノとして扱われ、そこにオブジェクト指向を組み合わせることが多かった。

ただ似ているという理由で、継承が行われることが多発した。「オブジェクト指向がそのまま、ごちゃまぜになって散り散りに流出した。」

というか、そもそもアプリケーションドメインって考えが無かった。それが設計書との乖離を産みスパゲッティコードが増えた。

オブジェクト指向最初に学ぶ継承が、ポリモーフィズム多様性)を実現するための1つの特性しかないのに

継承のためにオブジェクト指向を使っても良い」という誤った考えが、勘違いの原因だろう。

この問題は、最近では結構認知されてるのだが、実際の現場では、打開策を模索中な場合が多い。

近年のアプローチは、システム上でもアプリケーションドメイン表現されるべきという考えである

打開策としては、このアプローチによる実績を増やしていくこと。

まずは、なぜ継承が負とされたかを考えてみた。

2014-08-25

アイスバケツチャレンジといい、ふるさと納税といい

寄付税金話題性によって集めるってのはどうかと思うんだよな。

アイスバケツチャレンジみたいなのが流行ったら募金の集まらない団体に関して

宣伝が下手なのが悪い」

とか言い出す奴らがいてもおかしくないじゃん。

このままだと募金を取り合うためにステマっぽいことをカネ使ってやるやつがますますはびこるし、

その果てにあるのはアコギな奴らが他人善意を上手に毟り取る手段競争する世界だ。

アグネス御殿とか見てるとすでに大分そうなってるけど、

いよいよそれが来る所まで来て全ての募金アコギな連中の手に集まって

活動資金」として闇に葬られてしま時代が来るよ。

ふるさと納税だってそう。

今は売りがある所がちょっと頑張って税金誘致してもらってるだけだけど、

そのうち競争がどんどん加速して最後には売りのないような県が無理してまでカネを集めようとするようになる。

そうなったらふるさと納税なのに産地偽装とかが起こるようになるよ。

そしたら一つの地方自治体がやった不祥事のせいで国中の税金への不信感はいよいよ爆発する。

年金が使い込まれて、箱物行政が失敗して、消費税増税タイミングや調整を完璧にしくじって、

パンパンになった堪忍袋がいよいよ弾け飛ぶ、その最後の一撃になりうるよ。

ふるさと納税なんて今すぐやめさせた方がいい。

こんな「生き残るべき自治体を決めるためのラットレース」みたいな事を続けてたら何かがきっと崩壊する。

世の中は錆びついてるから一度崩れてしまった方がいいという気持ちは自分にもあるが、

そういった気持ちはある種の病理だ。

巨大なスパゲッティコードを一から全部やり直して結果的プラスになる確率がどれぐらい低いかを俺たちは知ってる。

答えが見つかり、変革のチャンスが訪れるまでは、無理に崩さないで崩れないようにした方がいいんだ。


アイスバケツチャレンジふるさと納税みたいなのは結局のところ

「目立った奴がパイを大きく食いちぎる」ってシステムだ。

こんな事をやってたら世の中自体宣伝うまい奴らや嘘が上手につける奴らの食い扶持になっちまう

いい加減やめるべきだ。

目立てば勝ちなんて考え鼻、小中学生クラスヒーローになろうとした瞬間にだけ許されるんだ

2014-04-20

組織スパゲッティコード

90 : 名無しさん

あれこれ改造して継ぎ足していくうちにコードスパゲッティになってるように

運営のもの構造スパゲッティになってるようだね

どう儲けても関係ないんだけどさ複雑な人間関係になってるのはわかるわー

2014/04/20(日) 01:48:32

91 : 名無しさん

そう、それ書こうと思って完全に忘れてた

今、というかもう何年も前からシステムよりも人間関係利益関係スパゲッティコード化が深刻

んなこと2ちゃんに限らず金絡むことならどんなことでも多かれ少なかれそうなるんだけどさ

どんな監査システムが入っていたとしても、ね

2014/04/20(日) 01:52:10

92 : 名無しさん

ま、2ちゃんってのはわざと人間関係スパゲッティ化推進していた組織の典型なんだけども

じゃないとやってられない、ということと

続けていくうちにそのカラクリを利用すればあんなことやこんなことも(ry っていう意思作用とか

2014/04/20(日) 01:54:46

2013-06-26

IT業界って・・・

門外漢なんだけどIT業界についてリアルの知人に話を聞いても

やれデスマだの鬱で休職だの退職だの大事パスワード書いた付箋がモニターに貼ってあっただの

スパゲッティコードがどうしただの

ロクな話が聞けたためしがないんだけどこれって滅びたりしないの?

それともそんな話はごくごく一部だけで

それ以外のほとんどの人は優秀で生産性が高くて定時で帰れて趣味家族サービス時間を使ってるホワイトな人たちだったりするの?

2013-04-24

数年前新卒で某メーカー就職した。

研究希望だったが配属されたのは希望とは異なる情報システム部門だった。

SEではあるんだけど自分コード書いて開発することが多かった。

Webシステム担当になったんだけど、HTMLくらいは書いたことあるけど他は完全に素人って状態だったので最初のうちは覚えること多くて面白かった。それなりに勉強もした。仕事ってものにも興味がもてた。

だけど1年くらいしてからかな、すごく仕事がつまらなくなった。

社内のシステムは、テストコードなんて1行もないし、そもそも仕様書すら無くて担当者も代わって中身はブラックボックスだけど動いてるから放置してるとかそんなシステムごろごろしてる、そんな感じだった。

まあそんな状況のシステム担当にされたらもう悲惨だよね。スパゲッティコード読みといて、テスト作って、仕様書整備して、それの繰り返し。全部我流でつくった。

そしたら数年すぎてた。

もう仕事に対するモチベーションなんて無くなってしまった。

国内メーカーなんてもうあまり体力ないから社内システムにあまりリソース費やせるわけもなく、今のシステムを生きながらえることの要員でしか無くなってしまったんで、どこにやる気見出したら良いのかもよくわからん

情シス部門がゆえにユーザーは他の部門だからそいつらのサポートもしなきゃならんのだけど、うちの会社ITレベルの低さも思い知った。

障害発生だ!情シス部門は何やってんだ!とかクレームくるけど、調べてみると単に操作間違ってるだけどかざらだし、何もしてないのにPC壊れた言ってくるとかそういうレベル

もううんざりだよ。

勉強会とか行って例えばHTML5がどうのこうのって話があってですねって会社で話してみるじゃん、するとそんなのうちのシステムでは使わんねって一蹴。

悲しいね。そんなの続くとね、自分が持ってた技術的興味も薄れていくんだよね。

仕事じゃあまり面白いこと出来ないからせめて余暇でって思ってたけど、結局のところ一日の大半は仕事で埋まってるわけでなかなかこれはこれでモチベーションの維持が難しい。

で、先日あまりの胃の痛さで倒れた。

病院行ったらストレス性の胃潰瘍だって

もう体もだめになってしまった。

転職を考えたことは当然あるんだけど、今まで我流でやってきたかスキルは低いし、何か大きな仕事をやってきたわけでもない。もうすぐ30だけど、世の中の30っていったらもっといい仕事出来てるイメージがある。

あと給料とか福利厚生の面では今の世の中の水準を考えると割りと良い方で、転職となるときっと待遇も悪くならざるを得ないよなあとか考えてしまって踏み切れない。

どうしたらいいのかね。

このまま座して死ぬのを待つだけなのか。

それは嫌なのに行動できない。

これがまさに社畜なんだろうなあって思うと泣けてくる。

仕事がつまらないって本当に不幸なことだよ。

2013-03-27

プログラミングの初級になるためにの目次

http://anond.hatelabo.jp/20130325172822 の続き

言語Java7を想定。(Java8が迫っていますが、Lambdaなど関数型は、まだ早いと言うことで)

定理由は、C++比較して学べるところが大きく、安全シンプル言語から

※いきなりJavascriptはやめとけ、PHPは論外。

RubyScalaでないのは、筆者が初心者には適切には教えられないから。

おもちゃToyとしてjQueryで遊ぶのは、悪くは無いと思う。

0.はじめに

これ以降は名著の紹介や学習方法の紹介が主体となります。名著のコンポジションという形が時間限界ですね。

量については「初級になるなら、専門書を計3,000ページは修得することは覚悟してね」なんて言ったりしています

Javaで初級のわかりやすい指標ですと、[amazon:Effective Java]とGoFまでの修得。

初級になるまでに登竜門への挑戦期間を含めて、3~4年はかかっても仕方が無いとも思います

※逆に「一山いくらのコーダー」というのは、Effctive JavaGoFが達成している技術も知らずに「自分Javaプログラマー」だと誤解してしまっているような人達です。

そういったコーダーは何年経とうとも初級プログラマーにすら敵いません。

初級を目指して、プログラミングを楽しんでください。

ただ、学ぶべきことはべらぼうですが、「各分野毎に、エレガントな方法がある。だから探して修得する」ということが大切です。

※「一を聞いて十を知る」ような優秀な人に、50冊くらいドーンと本を置いてあげて、各本の目次を読ませるだけで、

底の見え無さを悟ってくれたりすると、嬉しくなってしまます

※余談ですが、その底の見え無さは数学という学問のものですね。例えば、関数型言語の底流に「圏論」というここ100年の最新の数学があります

また中級くらいで、Liskovの置換原則などが載っている本を紹介しますが、

そのLiskovの置換原則の周辺で出てくるcovariant(共変)って、圏論という数学概念だったりします。

数学出身としては、数学現実に活かされている嬉しい事例です。

閑話休題

1.目次

1)エディター・コマンドライン正規表現友達

「速く正確に大量の出力」という能力は、プログラミングをする上でも、ドキュメントを書く上でも、何より「つまら仕事」の時間圧縮ができるようになるため、重要です。

スローガンとしては「思考のスピードで出力することを目指そう」です。

紹介するエディターはemacsvimExcelです。ついでにIMEとしてATOKを使用しているため、ATOK操作Emacsライクにする話も紹介します。

ExcelWindows環境Meadowすら入れさせてくれない場合最後の砦という扱いです。

コマンドラインは、「コマンドラインというものがある」「時として非常に強力である」程度の紹介です。

※筆者はzsh全然使えません。使いこなしている方々と接する度に「勉強しなきゃな~、でも、あっちの方を先にやりたい・・・」とグズグズして、はや何年・・・

正規表現は置換を用いて、テキストの一括編集重要です。後、遭遇したくない事態ですが、スパゲッティコードの解析をする上での最後の砦です。

※遭遇したくない例

ん?何か変なところで副作用のある処理があるようだなぁ(消沈)、SQLのInsertかUpdateか一応Mergeも使っているところから逆算して原因箇所を探すか・・・(諦念)

この糞コードがっ!!こんなところに書くんじゃねぇ!!(憤怒激高)

(ここで、他にやらかしていそうな似たようなコード正規表現grep検索。改行コード込みにすれば複数文検索も可能)

わはは、予想通り共通化すべきロジックメソッドがそこら中にある・・・

2)アルゴリズムに始まりアルゴリズムに終わる(データ構造アルゴリズムの一部という認識言葉を使っています)

入門編で一つLinkedListというアルゴリズムを学びました。

少なくとも一つ本を読みながら自力でアルゴリズムを学べる人なら、大成できる可能性があります

前に紹介した[amazon:C++実践プログラミング]には、LikedListやStackなど基本的なアルゴリズムが載っておりますが、

これに加えて、初級になるためにはこれくらいは知っておいて欲しいというものを紹介します。

※後、最初から必ずしも手を出さなくても良い上限も紹介いたします。

3)正・不正の定式化・自動テスト・ロギング・アサーション・例外・契約プログラミング

プログラムは、データ入力して、加工して出力・保存する処理の繰り返しです。

まり、各一連の繰り返し毎に、「正しい入力」「正しい出力」を定式化する必要があります

それを人間の手では無くコンピューターやらせられるように、つまり自動テストできるようにテストプログラミングします。

そこで処理の進捗を確認するためにロギングし、処理が想定通りであるかをアサーションでチェックし、

不正入力不正な出力=例外が起きたら、対処策をプログラミングします。

(ex 途中で処理を中断して、入力者に適切な入力メッセージを伝えてあげる。入力自動補正などもあり得る)

で、ここら辺をまとめてどうあるべきかとして「契約プログラミング」があります

※余談。定式化・テストに際して、数学畑の人間としては、Javaだとequalsのオーバーライドでも必要になるし、同値関係同値分割だけでなく、集合論群論から学んで欲しい・・・(ここいらは数学科学部1~2年の学習内容)

4)名著を読め、新たな名著を探せるようになれ・素晴らしい人を見つけたら、縁を大切に

名著は英語で読みましょう。名著が名著たる由縁は、度々引用されることにあります

まり最新の技術書を読むときに、引用された名著のフレーズが、新旧のリンクをなし、理解の助けになります

対話は学問をする上で非常に重要です。

壁打ちといって、独り言で思考補助をするよりも遙かに有益です。

※素晴らしい師匠を探すなら、大学行くのが一番ですが、見聞を広げていく中で出会いを待つしかないとも思います

5)オブジェクト指向とはなんぞやとGoFデザインパターン + マルチスレッドプログラミング

マルチスレッドが難しいのは「バグを起こしにくいプログラミング」を求められるから

まりTry and Errorからの決別が求められ、今後の仕様変更拡張も踏まえて慎重に慎重にデザインする必要があります

できる限りステータス変数を持たずに安全に、でもマルチスレッドにするのだから効率を追求しなければ本末転倒

でも効率のためにはメモ化に代表されるキャッシング必須と、アンビバレンツな要素のバランス取りが難しい。

このために、リエントラントな実装・抽象と実装の分離など様々なエッセンスを駆使することが必要です。

床屋哲学者問題

6)日々コツコツと

というよりも孔子曰く、知っているよりも好きであること。好きであることよりも楽しめることのほうが強く、

気づいたら日々時間が許す限りプログラミングをしてしまうのが理想です。

仕事として嫌々スキルを磨かなきゃということが、これほど不幸な職業も無いですね。

余談 FizzBuzz写経について

FizzBuzz」は、本来の目的通り、協力会社の選定の際の足切りには便利ですが、

学習の達成度を測るには、簡単すぎる不適切な問題ですね。

写経

数学畑の人間として言わしてもらうと、

写経数学証明問題を、教科書テンプレ通りに、数値や名称だけ変えて記述することしか出来ない人の発想。

まり矛盾無く一貫した論理モデル」の構築が自由に出来ず、テンプレの微修正しか出来ない人の発想。

また、外部の「矛盾無く一貫した論理モデル」の吸収が不自由で、アルゴリズムを「手順」としてしか捉えられないように見受けられる。

プログラマーとしての大成は見込めないと思う。

数学畑として提供できる試金石

連続であること確かめるための「ε-Δ論法」(数学科学部1年の学習内容)

事前知識無く、このモデルを理解できる人は、十分に「矛盾無く一貫した論理モデル」を構築できる人。

1.まず「連続」とは何ぞやと考えて概念を膨らませてください。

2.十分思考できたと思えたら、Wikiあたりでイプシロン デルタ論法を見てください。

2013-03-22

プログラミング出来ない奴ちょっと来い

プログラミング出来る方法教える。

世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

いや実際に "ない" というのはかなり語弊があるかもしれない。

しかし、通常この種の説明している本に辿り着くまでには多くの時間必要だ。

普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要概念を獲得するのだと思う。

例えば、「計算機プログラム構造解釈」や「実用 Common Lisp」、「コンピュータプログラミング概念技法モデル」などの書籍現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。

しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。

そして、"普通プログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

それは自分の作りたいアプリだったり、

クライアントから発注されたプロジェクトだったり、

上司から頼まれた仕事だったり、

業務を効率化させるための Excel マクロだったり、

授業で出された宿題だったり、人それぞれだろう。

このような目の前の問題を解決したい人達が、わざわざ LispMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。(ちなみに、LispMozart は上記の書籍で実際に使われている言語である。)

目的現在の問題を解決することであって、

新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。

もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。

純粋プログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。

今回はそのような”純粋プログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。


そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である

もしプログラミング学習限界を感じているのであれば、プログラミング学習方法が間違っている可能性が高い。

そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミング学習方法や上達するための正しいスタンス" を説く本はほとんどない。


できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも

より多くの人がより生産的にプログラムが出来るようになるためにも

そして特に、右も左も分からなかったプログラミングを始めたばかりの過去自分に対して、

効果的な学習方法プログラムする際の指針を書き記したいと思う。

それらは単に指針を示しているだけなので、

どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。

後はどれだけそれを実践に移し地道にプログラミングしていくだけである

正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。

プログラマレベルを以下の 3 つに分けてそれぞれについて説明していきたい。

1. 初心者レベル

プログラミング半年未満

・使えるプログラミング言語は一つだけ

ただし以下のことは出来ない。

・500行以上のコードが書けない

エラーが出た時の対処方法が分からない

写経は出来るが、自分プログラムが書けない

2. 中級者レベル

プログラミング半年 〜 3年

・1つ以上のプログラミング言語は使える

オブジェクト指向は理解している

ただし以下に当てはまる。

自分制作しているアプリケーション向けに "実用的なフレームワークライブラリ" を書けない

・1万行以上のコードだとスパゲッティコードになり、保守不能になる

・重複するコードが多く存在する

・適切なサブルーチン化できない

3. 上級者レベル

プログラミング歴 3 年以上

現実の問題に対して適切なデータ構造アルゴリズムを選択できる

抽象化について理解し、可変部分と不変部分を考慮した設計ができる

全てのプログラマはどれかのレベルに属するはずである

またそれぞれのレベルクリアするには明確な壁がある様に思う。

これらの壁を超えるにはどうすればよいかを説明する。

前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。


初心者レベルの人に向けて

完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。

検索エンジンで似たプログラム検索コピーペーストする

・本に載っているプログラムをそのまま書き写す(いわゆる写経

上のような行動を行なっているだけでは、いつまで経っても自分プログラミングが出来るようにならない。

なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。

それは、【プログラミング言語モデル】を自分の中に作ることである

プログラミング言語ルールの塊である

それは普通言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。

のしきたりを学べば書けるようになれる。非常に単純だ。

それなのに、なぜいつまで経っても書けないのか?

それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないかである

特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである

それは例えば、日本語を話すことと似ている。

友達と会話する時、頭を使っているだろうか。

それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。

プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。

もちろん日本語話せるだけでは、ミーティングプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。

それには以下の点を意識してプログラミングすればよい。

・"何をしたい時" に "どう書けば正しく動くか" というデータベースプログラミング言語モデル)を自分の中に作ること

このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。

1. エラーをたくさん出す

2. デバックの仕方を覚える

3. 小さく動かして確かめ

4. Google を使い倒す

まり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである


これらについては以下で詳しく説明するとして、

まず最初初心者ありがちな間違いをいくつか列挙してする。


関数メソッドをたくさん覚えなければいけない

無理して覚えなくてよい。

プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。

よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである

覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。

しろ実現したい処理が既にメソッド関数として提供されていないか、調べる力の方が大事

エラーがいっぱい出てつらい

全く問題ない。

以下で述べるようにエラーとどう付き合うかが非常に重要

写経をしなければならない

教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。

上記でも述べたように、これからまり無駄努力をしないことを願って言えば、

写経にはほとんど意味がないと思って取り組んだ方がいい。

写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。

なぜならば写経は "作業" だからだ。

そこに "言語モデル" や "思考" が伴わないと意味がない。

”思考” が伴わないとただの書き写す作業をしているだけだ。

自分の中に "モデル" が出来ていないので、いざ自分プログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。

写経はそもそもプログラミングに対するスタンスプロセスのもの勘違いさせる危険性をはらんでいるいる。

写経する場合、書き写しの間違いがなければプログラムは問題なく動く。

しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。

そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラム完璧ものにしていく。

書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。

また、以下で述べるようにエラーが発生した場合デバッグ作業は非常に重要であるだが、そのための作法写経から学ぶことができない。

なぜならば、写経中にエラーが発生した場合教科書自分で書いたプログラム間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である

それでは、デバッグ方法言語モデルを作るとても大切なプロセス経験できない。

ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである

とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。

さて初心者が陥りやすい部分については説明したので、

今度はどのように "言語モデル" を自分の中に作っていくかについて説明する。

1. エラーをたくさん出す

初心者エラーを出さない様にと慎重にプログラミングしようとしがちだ。

はっきり言うと、それは間違ったプログラミングスタイルだ。

特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。

PHP で例えると、

printf の書式だとか

文末に付けるセミコロンだとか

function はネストできないとか

変数には $ を付けなければならないだとか

グローバル変数関数の中で使う場合は global 宣言するとか

などである

初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。

例え今回作っていたプログラムエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。

しかし、それでよいのだ。

エラーを修正することの繰り返しの中で、その言語モデル自分の中に出来てくる。

そのようなトライアンドエラーを繰り返えすことで、"言語モデル" は文字通り体の中に染み込み、プログラムだんだんと書ける様になっていく。

おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。

誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。

そして最終定期には、難なく自転車を乗りこなせるようなっている。

プログラミング言語を学ぶ時も同じである

最初は何度やってもいろいろなエラーが出てくる。

それらのエラーを地道に1つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。

そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。

自転車も本を読んだだけで乗れるようにはなれないのと同じで

プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。

それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。

そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。

早めにそれに気付いて受け入れる必要がある。

2. デバッグの仕方を覚える

さてエラー重要性については上で強調した。

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。

期待しない動作をした時のデバッグという。

まずいちばん基本的で一番重要デバック方法printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめ方法である

僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグ重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである

初心者からこそ、デバッグ方法論や開発環境をきちんと整えるべきである

ほとんどの言語処理系では、デバッグ作業を支援する機能提供している。

からなければ、"言語 デバッグ方法" でグーグル検索してみればよい。

例を挙げると、

C言語だったら、gdb

PHP だったら Xdebug

Ruby だったら pp モジュール

Schemegauche)だったら #?= デバッグ

javascript だったら firebug

言語はいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

これは無益時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。


3 小さく動かして確かめ

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。

その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。

そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。

そのためまず小さく作って小さく確かめ部品を組み合わせてプログラムを作っていくことが大事になる。

一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。

ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢検討してみるべきだ。

"Small is Beautiful"

これは非常に有名な unix (という OS)の設計理念である

unix開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。

まだプログラミング経験の浅い人も、これから偉大な開発者経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。


4 Google を使い倒す

先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。

おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。

原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。




現実プログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事能力とは、実は "忍耐力" だろうと少しばかり思っている。

でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。

そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。

ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。





2010-12-08

http://anond.hatelabo.jp/20101208010138

日本はね、客がガラパゴスを助長するようになってる。

過去出来たことが出来なくなることに異様に厳しい

だから、常に「一つ前よりも良くなる」事を求める。

そのことが、メーカーAndroid移行が進んでいる一つの原因なんだよね。既に、メーカー内製のコードメンテ不能の状態に陥っている。しかし、過去に搭載した機能(フィーチャー)の維持は絶対だから、機能追加の度に死人が出るスパゲッティコードを捨てられない。…なんてことを、もう何年もやっている。

で、そんなコードの上にフルブラウザ追加だ、タッチUI搭載だ、ソーシャルサービス対応だ、なんてのはどう逆立ちしたって無理に決まっている。今のメーカーには、Android採用以外に選択肢はないんだよ。

日本ものづくり」なんて、とっくの昔に終わっている。iPhoneやらAndroidやらの躍進は、ついにそのことを隠せなくなったことの現われに過ぎない。

2009-07-12

刺されるかもしれない

完全に逆恨みなのだが、

自分ができることを彼はできない。

自分はそれだけ時間をかけて、技術自分のものにしてきたからできるのだが、

とにかく注目され一番でいたがる彼にとっては自分はたぶん目障りなのだろう

いちいち張り合ってきたり、鎌をかけてきたり、

ねたみを前面に押し出してきたり、陰口を聞こえるようにたたいたり、

たまたま失敗したことを鬼の首をとったかのように皆に言ってまわったり。

自分は確かに結構いい加減だ。

整理整頓なんかは最も苦手だ。

でも幸いなことに作業スピードだけは人一倍速い。

そうやって能力のなさを回数をこなすことでカバーしてきた。

丁寧に一度でものにできるタイプではないのだ。

ただそういう性格だから、ルールを遵守するのではなく場合に応じて柔軟に対応することはできる。

そういうところもおそらく彼には気に入らないのだろう。

彼は、自分が彼よりも下であると思っている。

年齢的には確かにそうである。

彼はきっと偉そうにしたいのだろうと思う。

だがそれを自分邪魔しているのだろうと思う。

単に習得のためにかけた時間が違うだけなのだが。

また、彼はその性格のためか、周囲の人から敬遠されがちである。

仕方ない。

目立ちたがりで、偉そうにしたがって、

人を見下して、文句が多くて、

人の失敗に喜び、人が成功したら卑屈になってねたみ、

失敗は誰かのせいにしてうまく行ったことは自分の手柄にしてしまうのだから、

嫌煙されているという状態にあるだけまだましである。


金曜、やはり彼とは方針が異なってぶつかった。

自分はあまり自己主張をせずに、とりあえず面倒なので彼に合わせてから、

うまくいかなかったことを客観的にわからせて、

お互いに模索するというふりをしながら自分の考えた方針の方へ誘導していった。

正直二度手間なので面倒なのだが、

まともにぶつかると卑屈になってすべてを放棄するのでもっとめんどくさいのである。

失敗したことは彼のプライドを傷つけたのであろう。

自分は失敗するかどうかはわからなかったし仕方ないと言ったのだが、

彼は自分を、親の敵か何かのようにしばらく睨んでいた。

方針がとりあえず決定してからは、失敗の埋め合わせのつもりなのか、

すべてを自分でやろうと抱え込み始めた。

自分は特に止めなかった。フォローという姿勢をとりながら、

当然出てくるであろう不具合を修正していっただけである。

しかし自分が修正に入り始めてからは例の如く彼はすべてを放棄し、全く仕事をしなくなってしまった。

やんわりととがめたのだが、他人の邪魔をするために姿を消してしまった。

いないほうが楽なのでそれ以上注意はしなかった。

スパゲッティコードはきちんとオブジェクト指向型のプロジェクトに生まれ変わった。

彼がそれを知っているのか知らないのかはわからないが、

取扱説明書関数ライブラリも作成しておいた。

そして今日である。今日会社休みなのでゆっくりと寝た。

起きたらメールが何件か入っていた。友人と恋人それから、彼だった。

件名も本文のないメールだった。

気味が悪い。

掃除をしている間に呼び鈴が鳴った。出てみたが応答がなかった。

いやな予感がした。

ヘッドフォンをして絵を描いていたのだが、音楽の合間に何度か呼び鈴が鳴るのが聞こえた。

聞こえないふりをしておいた。でもドアスコープのぞきに行った。

彼が立っていた。

寮だから彼が自分の部屋を知っているのは当然なのだが、いやな予感がしたので無視した。

そしていま、ベランダから重い音がした。

気のせいであることを願って増田を書いている。

追記

まだ生きてるよー\(^o^)/

夜は気持ちが暗くなるからいけませんね

気のせいだって言えればなおよいんだけれども

さらに追記

先ほどロビーであったので和解?してきました。

とりあえず彼は、この間の態度は申し訳なかった、お詫びに食事でも、ということを言いたかったようです。

昨日何度も尋ねたのに応答がなかったので心配したなどとも言われました。

自分としては、心配していただいたのはありがたいが健康そのものであるということ、宅急便などの事前にわかっている訪問者以外には対応していないということ、夜分遅くに女性宅に直接来るのは同僚であっても非常識であるということ、会社の話は会社でしてくれればよいので部屋には来ないでほしいということ、以前にも食事や休日の一対一での外出などの誘いはきっぱり拒否しているが直接部屋に来られるのも迷惑だし心理的な負担になるのでやめてほしいということ、すでに何度も迷惑だと言っているので今後改善がなかった場合はハラスメントだということでしかるべき機関に相談することなどを伝えました。あくまでもビジネスライクなお付き合いなら歓迎ですが、個人的なお付き合いに関してはお断りしていますとも。

彼は聞いているのかいないのか、新しい自転車を買ったなどという話をしていました。とりあえず別れてから自転車置き場に行くと、自分自転車に真新しい自転車、おそらく彼のものだろうとおもわれるクロスバイクが立てかけてありました。おかげさまで少し自転車の具合が悪いです。嫌がらせなのかこれは。

2007-11-03

anond:20071103140726

ごめんね現場の方。私的に、そんな状況には一切興味がないし、どうでもいいんですよ。

ただ、プログラミングの、プログラミング自体の(完成したソフトウェアではなく)楽しさ美しさ感動は何処にあるのか、ということだけを考えて件の文を書いたのです。小説のような、絵画のような、音楽のようなソースがあって何が悪いのでしょう? 誰にでも読めるものよりも難解なものが、複雑怪奇な絡まりがかえって良いとされるような、そんな価値観があっても良いのではないでしょうか?

あの文章では「ぼくら」とか書いちゃいましたけど、言いたいのは「別の価値もあるんじゃないか?」ってことです。

それから、言わんとしていたスパゲッティコードは、かように無意味なだけのコードではないです。見るからにスパゲッティなのだけれども、それによって何か愉快な演出、パズルのような楽しみ与えてくれるような、そんなコードです。

http://anond.hatelabo.jp/20071103133112

難解だが愉快スパゲッティコード

こないだこんなのがあったんだぜ?

というような話題話しにはできても、愉快だったためしは一度もない。

助けてくれ!というどう考えても死亡フラグヘルプに駆けつけたことがある。

メーカー子会社だ。コードスタイルを見るに多分以前はコボルとかをやっていた連中だと思う。

コードを見てこれほど唖然としたことはない。

言語は…なんだったかな…時代的にaspだったような気がする。

コードを見て泣いた。functionのひとつもありはしない。

一晩の徹夜の後、3000行あったコードは300行になっていた。

難読すぎてスパゲッティーを解いた結果がこれだ。

何か機能を盛り込み忘れたのではないのかと目をゴシゴシした。

10人ぐらいをつっこんで数十の主要なコードを直した。

目をごしごしして2日間の貫徹だ。

成果物はなぜかボリュームが減っていた。

普段だったら絶対に許されない修正方法だが、

緊急に緊急を要したためコードを見てからの説得はかなり強引だった。

ただのスパゲティは修正するのがムリだと判断したからだ。

このプロジェクトを進行した連中無駄努力をただ恨みながら。

それ依頼、コードレビューを煩くするようになった。

自分のところのメンバーであんなコードを生み出されちゃ適わない。

他の協力会社にもずいぶん口うるさくいうようになった。

バグ出しで工数かけるまえにコードレビューだ。

君が苦労して実装しているところは既に**が**で実装している。

こういうだけで相当数工数が稼げた。

テクニカルな一行は分解されただの部品になった。

部品にしておけばみんながそれを利用できるからだ。

1人で組み上げるならいくらトリッキーでも構わない。

2人以上でやるならルールを作れ。

話しはそれからだ。

可読性の高いソースコードが良いコードとされるに至ったのは、一体いつ頃からであっただろうか……。

その結果、何が起こった?

難解だが愉快なスパゲッティコードは悪となった。呆然とさせられるあの遊び心に満ちたトリッキーコードは悪となった。感動コードゴルフもまた悪手とされた。

プログラミングとしての技巧的なものに取って代わって、より安易なコードを書くことが良いこととされるに至った。よりテクニカルな、たった一行にも知識と労力を要するコードよりも、誰にでも読めるようなコードが良いとされるに至った。

じゃあ、ぼくらプログラマを志すものは、一体何がしたかったんだ? ソフトウェアを作りたかった? 断じて否! あの考え抜かれたコードの中に美と情熱思想とを感じ取り、それに憧れたんだ。愚直なコードに誰が感動しよう、誰が憧れよう! 誰にでも作れるようなソフトウェアでも構わない、他の誰にも書けないようなあのコードを書いた人々と、そのコードに憧れたんだ。それを解読できる人々に憧れたんだ!

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん