僕がどうやってプログラミングを覚えたか(前編)

プログラミングの習得・上達方法は人それぞれです。アカデミックでコンピュータサイエンスを習った人、独学でやってきた人、得意なこと・苦手なこと様々でしょう。

道筋はいくつもありますが、ここでは僕の道筋を書くことで、誰かのヒントになればと思います。

前編はわりととりとめもなく僕という個人の道筋を示す記事としました。後編ではこれまでに得た知見をまとめました。

僕 is 誰

erukiti と申します。プログラミングを始めて30年になります。プログラミングは完全に独学で覚えました。上達の効率はさほど良くない方だとは思います。

専門学校卒ですが、専門学校はモラトリアムのためだけに言ってたので実質内職しかしてないです。高校もパソ通にハマって勉強一切やってなかったので、ギリギリの卒業でした(日数も成績も)

そのあとは10年引きこもりニートしておりました。

そっから就職して、辞めてからフリーランスでエンジニアや、ちょっとしたライティングなどをやっています。

プログラミングを始めたきっかけ

むかしむかしあるところにMSX-FANというMSXの雑誌があってのう。

昔のパソコン雑誌にはゲームとかの読者投稿ページがあって、MSX-FANではファンダムという名前だったんですが、それに掲載されてるゲームがアホみたいに面白かったのです。

元々ファミコンでゲームにハマり倒してて、ファンダムのゲームの持つ、ゲームの本質をひたすら追求し続けた世界のゲームがやたら面白かったのです。

いかに短い行数(要するに掲載紙面)でどれだけ面白いゲームを作るのか?アクション、RPG、パズル、3Dレースゲーム(!!)などがありました。

で、当時はオンラインでダウンロードするなんてのはないし、CD-ROMが一般的な時代でもないので、紙面のソースコードを打ち込むしかないので、僕の初手は打ち込みでした。いわゆる写経ですね。

そこからゲームバランスや機能をいじるために改造しました。

個人的には初学者は、写経 + 改造が手っ取り早いと思っています。

BASICでゲームを作る!みたいな本も買ったけど、サンプルゲームがクッソつまらなかったので投げ捨てました。

ちなみに入ったきっかけはゲームですが、ゲーム作りよりもツール作りの方が楽しくて、結局ゲームを作ってないです。

C言語に手を出す

BASICやマシン語、アセンブラと格闘するよりはC言語が圧倒的に楽な時代なので、C言語やり始めました。当時のMSXで動くフル仕様のCコンパイラなんて存在していなかったので、MSX時代はあまり進捗がなく、世界が変わったのはPC-98を手に入れてからです。

PC-98というかMS-DOSで動く無料のCコンパイラ(LSI-C試食版)を手に入れてから、パソコン通信のホスト局(サーバー)を作ったり、ちょこちょこツールを作ったりしてました。

ここに至るまでは割と泥臭く来てます。本を読んだりパソ通でプログラミングの話題をROMったり議論したり、あるいは人の書いたソースコードを読んだり、改造したり。

ぶっちゃけgithubという世界最強の教材共有サイトがあり、他にもいっぱい知見の詰まった高速道路が整備された、現代なら1年もかからないでしょう。きっと。

FreeBSDをインストールしてから

PC-98にFreeBSDを入れてから世界が変わりました。vi(あるいはvim)もEmacsも個人的に好みじゃなく、PC-98時代に愛用していたVzと同じようなエディタがほしくて作りました。

完全な自作というわけではなくて、nxeditというエディタがすでにあって、それを改造しつつ中身をほとんど作り替えたやつがneです。

元が素朴な単方向リンクのリスト構造でテキストを保持していたので、まず双方向リンクかつキャッシュ機能のリストを作成しました。テキストエディタで行にアクセスするとき、どうせその行の周辺にしかアクセスしないんだから、キャッシュ機能を付ければええやろ!ってノリで行番号ベースのリスト構造というのを作ったのでした。

ターミナル出力も素朴だったので、画面更新の時にバッファリングして、どのエスケープシーケンスを発行すれば一番文字数が少ないのかを計算してそれを出力するというのを実装しました。(仮想DOMみたいなもの)

当時の性能や環境では、文字数=速度と見なして問題なかったので。

neでやってたことは、アルゴリズムについてあれこれ実験してみる感じだったと言えます。

MSXエミュレータを作った

今度はSDLというマルチプラットフォームでDirectXっぽいライブラリを使ってZodiacというMSXエミュレータを作りました。今は亡きSourceForge(ほんとはあるんだけど、悪落ちしたのでないです。SourceForgeは死んだのだ)で公開していました。

僕がWindows/FreeBSDで動くバージョンを作り、他の人の手でMacOSに移植されたり、BeOSで動いたりしてました。

Z80エミュレーションは、インタプリタ型にしては高速なヤツを作ったものの、たぶん今の時代ならCコンパイラによる最適化で到達しそうな程度のチューニングだったかもしれません。

画面出力はよくあるダブルバッファリングです。

音声出力では、実時間、MSXのクロック、音の出力をそれぞれ同期していい感じに制御するみたいなのを作ってました。44.1KHzは言い換えると1秒間に44100個のデータを送りつけるという意味であり、そこらへんはオーディオ回路のクロックに左右されます。なので音の出力をマスターとして、実時間を微妙にねじ曲げつつ、MSXのクロック分のCPU処理をしてました。

画像や音声関連が僕の苦手領域だったので、ある意味それを克服するためのプロダクトだったといえます。

ちなみにコードフォーマットが独自すぎてブーイングを受けたので、途中から一般的なBSD styleにしました。

非公開のアプリを作った

Win32APIを使ったチャットソフト(兼ファイル送受信機能付き)を内輪で動かしてたり、ちょっといえないソフトを作ったり、ちょっといえないソフトを作ったりしてました。

Rubyは2000年だったかに始めました(linux.or.jpの読書感想文でRubyの最初の本をもらったのがきっかけ)

就職してから

フルスクラッチやそれに近い状況で何かを作るのは得意なんですが、就職してからは、他人のコードのメンテをやり始めて、それが思いのほか極度に苦手で苦戦しました。

まぁ、メンタル病んで休職したりいろいろでしたが、現場で実際に色々なコード、設計などに触れて、それはそれで経験値になりました。

Qiitaにブログを投稿しだした

Qiitaに書き始めました。最初の記事は2013年に書いたScalaを動かすというものです。ちなみにメンタルの病みの進行速度が一番早かった頃です…。

Qiitaにあれこれ投稿してから、明らかに自分のあれこれが変わりました。個人的には、プログラミング上達には「ブログを書く」が一番の近道だと思っています。

本を書き出した

技術書典2で初のサークル参加をして本を出しました。それ以後はひたすら本を書いてみたりあれこれしている感じです。

「ブログを書く」以上にプログラミング上達に役立つのが「本を書く」です。同人誌でぜんぜんかまわないので本を書くべきです。

書き方がわからない?そんなあなたには技術同人誌を書こう!アウトプットのススメがおすすめです。同人誌を書くのに必要な全部がこの本には載っています!

前編はこんなところで

今回の記事では歴史をなぞった感じですが、後編では自分が転換点だと思ったこと、これは効果的だと思ったことなどを一通り書きます。



この記事が気に入ったらサポートをしてみませんか?