科学×中学生がテーマなノベルゲーム「EVERETT EFFECT」 開発途上版 "interpretation" 公開予定

everett-effect.com

僕がシナリオとか演出とか企画全体の概ね半分くらいをやっている「EVERETT EFFECT」というゲームの開発途上版を5月6日に東京ビッグサイトで行われるコミティア120にあわせて公開します。

ノベルゲーム部公式ページ

ノベルゲーム部、という名前のコミティア部活動の一員としての出展です。

ブースは K04b Sapience です。よろしくおねがいします。

Mac OSXでRPGツクール2000製のゲームを遊ぶ（EasyWine+IPAモナーフォント）

RPGツクール2000や2003の時代、名作フリーゲーム多いですよね。

久しぶりにやりたい作品があったので、手元のMacで動くようにしてみました。

ちなみに、クリアまでやった訳じゃないので、もしかしたらセーブデータの扱いとかでおかしくなることがあるかもしれないです！

2003とかでも似たような感じで動く気がします。まだやってないのですが、上手く行った/行かなかった人がいたらコメントください。

1. EasyWineのインストール

以下のページを参照。 NAVERまとめが公式配布先っていうちょっと変わり種ですね。

🍎 EasyWine.app 🍷 - 😃 mattintosh note 📝

2. RPGツクール2000RTPのインストール

2000時代はRTP同梱は稀ですよねー…ってことで。

RTPをダウンロードして、インストーラーのexeを開くだけです。

もしexeが他のソフトに関連付いてしまってる場合は、副ボタンクリック（二本指とかCtrl+クリックとか）からeasywineを選んで開く。

3. IPAモナーフォントのインストール

以下のサイトからIPAモナーフォントを持ってきてインストール。

各ファイルを開くとFontBookが開くので、流れに従えばインストールできるかと。

IPAモナーフォント

4. user.cfg の編集

レジストリ編集。しないと文字が汚くて遊べたもんじゃない。

参考サイトによると、IPAモナー明朝は下が途切れちゃうから明朝もゴシックにした方がいいとあり、 やってみたら確かに途切れちゃったので僕もゴシックにしてみました。

ここのやり方は、以下の通り。

1. Finderで適当なウィンドウを開いて Cmd+Shift+G でフォルダ移動ダイアログを開く
2. ~/Library/Caches/Wine/prefixes/default/ と入れて開く
3. user.cfg というファイルがあるので、CotEditorなどで開く
4. [Software\\Wine\\Fonts\\Replacements] と書かれたエリアに以下の内容を書き足す

"MS Gothic"="IPA \x30e2\x30ca\x30fc \x30b4\x30b7\x30c3\x30af"
"MS Mincho"="IPA \x30e2\x30ca\x30fc \x660e\x671d"
"MS PGothic"="IPA \x30e2\x30ca\x30fc P\x30b4\x30b7\x30c3\x30af"
"MS PMincho"="IPA \x30e2\x30ca\x30fc P\x660e\x671d"
"MS UI Gothic"="\x30d2\x30e9\x30ae\x30ce\x4e38\x30b4 Pro W4"
"\xff2d\xff33 \x30b4\x30b7\x30c3\x30af"="IPA \x30e2\x30ca\x30fc \x30b4\x30b7\x30c3\x30af"
"\xff2d\xff33 \x660e\x671d"="IPA \x30e2\x30ca\x30fc \x30b4\x30b7\x30c3\x30af"
"\xff2d\xff33 \xff30\x30b4\x30b7\x30c3\x30af"="IPA \x30e2\x30ca\x30fc P\x30b4\x30b7\x30c3\x30af"
"\xff2d\xff33 \xff30\x660e\x671d"="IPA \x30e2\x30ca\x30fc P\x660e\x671d"

尚、念のためuser.cfgのバックアップを取っておいた方が安心です。

参考:

参°ぼっくす: Mac上のWineでRPGツクールのゲームを動作させてみる

🎮 Mac で『Ib（イヴ）』をプレイする 🍎 - 😃 mattintosh note 📝

GAE/Goの基本的な設定の覚え書き

Go言語は昔(1.4まで?)はパッケージ管理の標準的な仕組みがなくて、1.7あたりでvendorディレクトリを必ず読むようになったらしい。 デファクトスタンダードは、今の所glideというものらしい。 godepsも良いみたいだけど、個人的に何となくglideの方が扱いやすく思えたので。

GOPATHを指定する必要があり、僕はautoenvを使う事にしたけど、何にせよこの後のプロセスを踏む前に必ず、作業ディレクトリがGOPATHに含まれてるようにする。

echo $GOPATH
/Users/akn/go:/Users/akn/Documents/TimeCard/time-card-gae

普通の $PATH と同様 : で区切っていいらしい。

で、とにかくディレクトリ構造が肝心。僕はこんな風にした。（srcなしとかも試したけど、srcがないと上手く動作しなかった）

your-app-dir
└── src
    ├── app.yaml
    ├── glide.lock
    ├── glide.yaml
    ├── main.go
    ├── server
    │   └── server.go
    └── vendor

主要なファイルの中身を晒しておく。

app.yaml

application: my-app
version: 0
runtime: go
api_version: go1

handlers:
- url: /.*
  script: _go_app

nobuild_files:
- vendor

skip_files:
- vendor/.*$

main.go

package main

import (
    "server"
)

func init() {
    server.Start()
}

良く分かんないんだけど、main.goから直接vendor以下のを読みに行くと上手く行かなかったので、server packageを定義して、そっちから読むようにしてる。

あとは以下で開発

goapp serve

もしくはデプロイ

goapp deploy

これだと覚え書きすぎて分かりにくいので、丁寧めの記事へのリンクを貼っておきます。 ただし、僕は goenv を使って app/srcでディレクトリを分ける方法はCan’t findとか言われてライブラリが読まれず、上手く行かなかった。

www.freegufo.com

qiita.com

qiita.com

Refile+S3のpresignにSwiftからダイレクトにアップロードする

画像等のファイルをS3(とかのクラウドストレージ)に置くのが当たり前になってきた昨今、クライアントから画像をアップロードするときにアプリケーションサーバーを経由するのは、そこからさらにS3に挙げるという点ではムダ。

この改善方法として、クライアントサイド（ブラウザやネイティブアプリ）からS3に直接アップロードして、アプリケーションサーバーには「ここに置いといたよ」とだけ伝える方法がある。 このアプローチは、特にherokuのようなアプリケーションサーバーに負荷をかけたくない環境では高い効果を発揮する。

で、このエントリの対象読者は、上の文で何が言いたいか分かってくれる人。

そうじゃない人は、諦めてアプリケーションサーバーに頼ってCarrierWaveかPaperclipの安定版を使う事を強くオススメする。

さて本題。

CarrierWaveの後継と噂される（同じ人が開発している）Rails向けの画像取り扱いgemのRefileというのがある。まだ安定バージョンではないし、Rails5系に組み込もうとするとSinatraとrakeのバージョンがぶつかってしまったり面倒が多いが、設計はCarrierWaveよりもさらに洗練されているっぽい。

GitHub - refile/refile: Ruby file uploads, take 3

Refileにはdirect uploadとPresigned uploadsという機能がある。（大文字小文字はREADMEに倣った）

direct uploadはフォームをsubmitしようとしたときにファイルを1個ずつRails側に送って、それが完了してからフォームをsubmitする方式。

Presigned uploadsは、上記で言ったS3に直接上げる方式。

Refileでは、Javascriptからのアップロードのみ実装されているので、これをSwift側で実装する。

ざっくり言えば refile/refile.js at master · refile/refile · GitHub の移植。

// まずはpresign情報を取得する
request("https://example.com/attachments/cache/presign").validate().responseSwiftyJSON { (presignResponse) in
    // ※エラー処理は自分で書いて下さいね。 switchで .Success / .Failure 分岐するのが個人的には好き。
    let url = presignResponse.value!["url"].stringValue
    let fields = presignResponse.value!["fields"].dictionaryValue
    let asName = presignResponse.value!["as"].stringValue
    
    Alamofire.upload(multipartFormData: { (multipartFormData) in
        
        for (name, value) in fields {
            multipartFormData.append(value.stringValue.data(using: .utf8)!, withName: name)
        }
        
        // 以下のNSDataを用意する部分もお好みで。 UIImagePNGRepresentation を使っても良いし、拡張子などで分岐しても良い。
        let image = UIImage(named: "image1.jpg")!
        let imageData = UIImageJPEGRepresentation(image, 1.0)!
        
        multipartFormData.append(imageData, withName: asName)
        
    }, to: url, encodingCompletion: { (encodingResult) in
        // ここにもAlamofireのドキュメントを参照してエラー分岐等を書く必要があると思います。
        print("uploaded")
    })
}

ここで得たデータをPOSTやPUTしてruby側でActiveRecordに渡してやる必要があるけれど、そこはまだやってないので追記するつもり。

ちなみに現状のGemfileの中身はこんな感じ。

tagすら切られてない中途半端なバージョンなので、不用意にバージョンが上がってバグらないように一応refを固定。

gem 'rails', '~> 5.0.1'

# Refile (最新版, unstableなので依存解決のために無理して入れてます)
gem "refile", require: "refile/rails", github: 'refile/refile', ref: 'd7a42dcd7c'
gem "refile-mini_magick"
gem "refile-s3"
# Refileのために以下が必要っぽい
gem "sinatra", github: "sinatra/sinatra", tag: "v2.0.0.beta2"

そういえば、全然関係ないんですが、最近Skyrimにハマってます。めっちゃ面白いですね。

JWTで認証するGem「Knock」でRSA認証する

Knockのデフォルトは secret_key_base を使ったHMAC using SHA-256らしい。

つまり、公開鍵暗号じゃないので、クライアントサイドで自由に中身を見れるというJWTの利点を半分失ってる（安全性については問題ないと思うけど…）

（追記）…と適当な事を書いてたら補足を頂きました。その通りですね！ @koniyan ありがとう。

@AknEp HSとRSの違いはクライアント側で見れるかではなく、クライアント側で公開鍵を使ってverifyできるかどうかが違いじゃないかな。

— Kyoji Konishi (@koniyan) 2017年2月16日

※この辺とても難しいし、僕は暗号の専門家じゃないので、重要なプロジェクトで使う場合は、鵜呑みにしないで裏を取ってくださいね。

で、このメモで書いておきたいのは、KnockでRSA認証する方法。ただそれだけ。

まず、g knock:install で生成される knock.rb の各項目に以下のような感じで書く。 File.readにしてるけど、ENVに設定すればENVから引っ張り出しても良いと思う。（ENVに改行入れる手段とかは知らない…）

# knock.rb
config.token_signature_algorithm = 'RS256'
config.token_secret_signature_key = OpenSSL::PKey.read(File.read(Rails.root.join('keys','jwt-private.pem')))
config.token_public_key = OpenSSL::PKey.read(File.read(Rails.root.join('keys','jwt-public.pem')))

で、以下のコマンドで鍵ペアを生成する。

openssl genrsa 2048 > jwt-private.pem
openssl rsa -in jwt-private.pem -pubout -out jwt-public.pem

あとは所定の位置にpemファイルを置いておくだけ。 クライアントサイドで複合したい時は、jwt-public.pem を誰でも見れるところに置いておくなりして、複合すればOK。お手軽。

特に分かりやすい利点としては、複合したトークンのexpをチェックするだけで期限がチェックできるので、トークンの延長をすべきか否かの判断とかが手軽にできる。とか。そのへん。

ClipMenu, Clippy がハングアップするので Pastebot に乗り換えたら神だった

クリップボード管理アプリで ClipMenu や、その思想を受け継ぐClippyがありますが、僕の環境だと度々CPUが100%に張り付きます。

何かないかなーと思っていたら、Tweetbotなどで有名なチームTapbotsが、Pastebotというアプリを出してました。 かなり使いやすいのでオススメ。

Pastebot Beta

「プログラマーになるにはどうしたら良いですか？」への僕なりの回答、もしくはコンピュータを軸とする僕の自伝

この記事を書くまでの経緯

「(職種名)になるためには何をすればいいですか？」という質問する時点で向いていないと考えです。
やりたいという意欲と行動力(これ大切)があれば、必要なスキルを習得していくし、それを繰り返していくうちに「あれ、これで食っていけんじゃね？」という感じでその仕事に就くんだと思います

— ひげねこ@技 (@HigenekoTech) 2016年6月8日

というツイートを見かけた。（こういう意見は今までにもよく見て、もやもやしていた。）

触発される形でこいう感じのことを書いた。

こういうの見るけど僕はそうは思わなくて、僕らは何となくの憧れからだんだんそっちに歩んでいくということもあると思うんですよね。 そうじゃないと、生来的に環境がたまたま揃ってた人だけがその道に進めるっていう、割と狭苦しい世界になる

— あおみかんはめげない (@AknEp) 2016年6月8日

子供の頃ろ僕はよく「Webデザイナーになるにはどうしたらいいのか」とか「コンピュータのことを仕事にするにはどうしたらいいのか」とか調べて、どうやら工学部や情報系の学部に大学で行くのが良いとぼんやり理解していて意図的にそっちを選んだし、逆にそれなくしてどうやって進路を選べというのか

— あおみかんはめげない (@AknEp) 2016年6月8日

極端な話、中学くらいまでに「医者になるには医学部に行く必要があって、医学部に行くのは結構難関だから勉強しなきゃならないらしい」という情報抜きにして、どうやって医者になるんだ？ その情報を得るのに最適な質問が「お医者さんになるにはどうすればいいですか？」じゃないのか？

— あおみかんはめげない (@AknEp) 2016年6月8日

「プログラマーになるにはどうしたらいいですか？」と聞いたら向いてないとか意味不明な返事されて困ってる若者いたら連絡ください。僕は建設的に力になりますよ。

— あおみかんはめげない (@AknEp) 2016年6月8日

…という感じの事を考えまして、じゃあ僕なりの「プログラマーになるにはどうしたらいいのか」を軽く記事にしておいたら数人くらいの糧にはなるかもな、と思って書き留めておく次第。

ちなみに僕のパターン自体は、この見かけたツイートに書かれている「やりたいという意欲と行動力(これ大切)があれば、必要なスキルを習得していくし、それを繰り返していくうちに「あれ、これで食っていけんじゃね？」という感じでその仕事に就く」というパターンそのものなんですが、それってどういうことなのか事実を具体的に書かないとイマイチ体験してない人には何のことか分からなそうなので、全部書いた。

注意事項

当然ですが、この記事はあくまで僕の個人的な見解です。 教師だろうと親だろうと人生を左右する決定を少数の意見だけで決めてしまうのは危険なことです。なるべく裏を取るようにしましょう。（おそらくこの読者にとって）赤の他人である僕の言うことなら尚更ですね。

ここでの「プログラマーになるには」というのは、職業としてプログラミングを中心的な生業（生活していくためのメインの仕事）にする、という意味で捉えています。

僕の話

「どうすればいいのか」をいきなりダイレクトに書くよりむしろ、僕の個人的なプログラミングに繋がったことや周辺の関係ないこと含めて書き留めた方がむしろ参考にする上で有用な気がしたので、アドバイスを交えつつ僕の個人的な体験を書き留めます。 長々としたのを読む気が起きない人は「本題」という見出しまで飛ばしてください。

お前誰？

大学を卒業して、大学院で膝に矢を受けてしまって、今はフリーランスのプログラマーとして、都内でそれなりに生活できるくらいには稼いでいる人（27歳）です。

幼少期

おそらく比較的頭の良い子供として生を受けました。家は割と貧しかったです。 何故か超古いワープロがあり、小さい頃はそれを弄って遊んだりもしていました。 なんとなく、数学に繋がるようなこと、理科につながるような事が好きで得意だったようです。 ざっと言ってしまえば、少々アスペルガーっぽさのある子供だったようです。（余談ですが、そういう人をBAPと呼んだりします）

プログラミングは知的な技能なので、頭が悪いと務まりません。 あくまで生来的な適性としては、多少コミュニケーションに難があってもかまわない（もちろん得意でも構いませんよ！）けれど、論理的な思考力が欠けている人には向いていません。 向いていないだけで、訓練でどうにかなる可能性も、どこかで歯車が噛み合って秀でていける可能性も勿論ありますが、単に最初の向き不向きの話をしています。 （後述しますが、本当に社会でプログラマーをやっていくには、コミュニケーション能力がてんでダメでいいという訳ではありません）

小学校くらい

低学年は普通に遊んだり喧嘩したりしつつ過ごしていました。小学校3年生の頃に授業でパソコンに触れて、非常に面白い体験でした。 4年生の時の先生が替わった先生で、教室になかなか高機能なワープロを置いていて、僕は頻繁にお絵かきソフトなどで遊んでいました。（今見るとすごくしょぼいピカチュウの絵とかを描いてた）

そうしたら母がボーナスをほぼ全額つぎ込んでiMacを買ってくれまして、これがひとつの僕の人生のターニングポイントでした。

高学年になると、ほんのわずかですが授業でパソコンを触れたりするので、その中でFront Page Expressを触って、HTMLで「100個くらいリンクがあって一個だけアタリ」みたいな簡単なWebページを作って「宝さがし」として学内のイントラネット（…だと思う）で公開したりして遊んでいました。 クラスメイトからは今で言う「クソゲー」と言われましたが、何だかんだみんな楽しんでくれていた気もします。

中学校くらい

小学校の頃に触っていたFront Page Expressでどうぶつの森のファンサイトを作って公開とかしていました。 たぶん「ホームページ　つくりかた」とかで検索して、自分が理解出来る所を探したんだと思います。サーバーが必要だと知って、サーバーはお金を払ってレンタルするもので、プロバイダが貸してくれたりもする、自分が使っているぷららというプロバイダはそれを提供しているらしい。ここまで頑張って調べて親に頼んで使わせて貰いました。 いろんなサイトを見て行く中で「フレーム」という、ページを分割表示する方法があると知り、どうやらFrontPageではなく、それが内部で扱っているHTMLというものを直接弄る必要があると知り、当時なりに頑張って調べてなんとか方法を見つけて自分のサイトに反映しました。 （フレーム、最近はほとんど見ないので知らない人もいるんだろうな…）

余談ですが、当時好きだった女の子が結構こういうのが分かる子で、その子のサイトを見ると何かカーソルが可愛くなるので、どうやんの？と聞いたら「CSSってのでやるんだよ」と言われて調べたりしてました。

また、掲示板やチャットを設置したいなーと思ったら、CGIというのを設置すると出来ると知り、CGIを設置するにはFTPでアスキーモードで転送してdatディレクトリをパーミッション666にする必要がある…といった情報を得て、なんとかパーミッションの概念を理解しつつ、頑張ってトライアンドエラーで設置していました。

当時、知人のおじさんから古いパソコンを貰ったりしていて、多分当時2,3万円くらいの価値だったと思うのですが、古いパソコンを譲って貰ったり、ヤフオクでおこずかいで買ったりして、Windowsも扱うようになりました。

あ、部活動は科学部に入っていましたが、当初は部長候補だったのに途中で人間関係の問題などで部活にロクに行かない期間などがあり、責任感のなさを先生に指摘され、部長にはなれませんでした。この事が１つのきっかけで「周りの人とのコミュニケーションも大事にしないとだめなんだな」という課題を自分の１つの大きな課題だと認識するようになった覚えがあります。 ただ、自分はコンピュータや物理系の研究がしたいのに、主に先生の専門だからという都合で生物系の研究をやらされていたので、それを言い訳にしていた気もします。（もちろん今では、そういう言い訳はあんまりよくないなぁ、と思います）

中学校高学年になる頃には、CSSがそれなりに書けるようになってきて、HTMLとCSSを組み合わせて作るべきものらしいというさわりくらいまで理解しつつ、受験勉強がやばくなってきたので付け焼き刃で何とかそれなりの進学校に受かりました。 95%くらい受かるのでナメてたんですけど、どうやら受験者のうち下から7%くらいだったので、運が悪かったら落ちてましたね……

この辺りで、世に公開したものを人が見てくれて、そこで貰った意見や情報を元にまた何かする、という流れが出来てきた気もします。 当時はまだインターネットもごく一部の人だけが使っているもので、今よりずっと炎上するリスクとかはない穏やかな、いわば趣味の世界の時代でした。

高校くらい

高校が随分と厳しい進学校でした。僕は興味のあることしか勉強したくないワガママ人間だったので、押し付けられる課題を色々理由をつけてやらない上、注意されても刃向かうので、かなり問題児でした。 秋田県で二番目の進学校だったはずですが、あの学校の教育方針や内容が悪いのだと、今でも思っています。 話が逸れるんですが「大人になったら分かる」という大人の発言は半分くらい本当ですが、教師の言うもののうち半分くらいはウソです。 教師は「卒業生は皆感謝している」とか言うんですけど、感謝してる卒業生くらいしか卒業後に母校を訪れるわけないんだから当たり前だろ。。。

ただ、教師にどやされている髪がボサボサでちょっと感じの悪いパソコンオタクと仲良くしたい人も中々いないので、高校時代は本当に少しだけの友達しかいませんでした。 どうやら高2くらいで何が悪かったかは分かってきたのですが、ファーストコンタクトに失敗した人たちと上手くやり直すのは僕には難しすぎたので、大学行ったらいい感じにやり直せるように、人に好かれる人はどういう振る舞いをしているのか観察して理解するように務めていた気がします。

学校が嫌だった跳ね返りと、田舎で遊びに行く場所もなかったのと、家族関係も当時あまりよくなかったのとで、連日コンピュータとインターネットに向かっていました。

自分のサイトをアップロードしている先の「サーバー」って何なんだろう？ということがふと気になったのはこの頃で、どうやらLinuxというOSで動いている場合が多く、それは無料で手に入ってCD-Rに焼くと手元のパソコンにインストールできて、DynamicDNSというのを使うと自宅サーバーをインターネットに公開することが出来る、セキュリティには細心の注意を払う必要がある、という事を知った僕は、試しに1台古めのパソコンで動かしてみました。 毎日のようにインストールや構築作業をして、いくつかのOSを試した後、VineLinuxというのが比較的日本語の情報も多くて楽だと思ったので、そのサーバーで色んなことをしました。 （今だったらUbuntuとかが楽だと思います。Vineは滅んでいるので注意してください）

とにかくその学校が嫌いだったのですが、嫌いがアイデンティティになってしまっていた僕は、変な方向に邁進して以下のような事をやりました。（よい子はマネしないように）

• 学校の2chスレと連動する非公式サイトを自宅サーバーで立ち上げる
• サイトをセマンティックなHTML/CSSで表現。 面倒になってきたのでPHPで携帯チェックを入れて、携帯とPCで元のコンテンツをいい感じに出し分けるようにする
• 携帯向けに最寄りバス＆電車の時刻表を見れる機能をPHPで書いて導入。URLパラメータで携帯からも簡単にチェック出来るようにしてちょっとしたアクセス数になる
• 2chのdatをHTMLで読めるようにしたかったのでperlでdatを読み込んで表示するコードを書く。重すぎたので何回か書き直してやっと軽くなったりしてた。
• アクセス数が気になるのでアクセス解析を導入する (確か awstats)
• 教師の悪口を自分じゃなく皆が書いたという建前にしたかったのでWikiを立ち上げて好き放題書く（最低だ…俺って…）ちなみに言い訳しておくと、実名は伏せた上で、知っている人（生徒）が見たら誰のことか分かる、というぐらいにしていました。
• ネットラジオに興味を持ち、ネットラジオ用途のサーバーソフトを自宅サーバーにインストールして、ネットで出来た学校の友達（意味わからんな）を家に呼んで4人でネトラジとかしてました。（センター試験の1週間前だっけ？流石にセンター試験が終わった後だったかも？）
• 今はそのサイトはありません。

そんな中、とあるゲームではわわーっとなった僕は、ロボットの特に知能的な部分（人工知能）に関する事がやりたかったのですが、ソフトウェア周りはかなり適性があることが分かったので独学で良いかなと思い（これはあまりに物事をナメていたと後に痛感したのですが）ハードウェアとソフトウェアの両方が分かっていないとロボットは作れそうにないと思い、ハードウェアの勉強が出来そうな学部を選んで、無事入学することが出来ました。

当初は東北大志望だったのですが、地元嫌いから遠くに離れたかったので筑波に志望を変え、センター試験が終わったら学校に行かなくて良くなったのでマイペースに勉強を開始したら（図書館で勉強してました）どんどん問題が解けるようになり、模試ではC判定でしたが、運もよく受かりました。

自慢みたいになってますけれど、先生の言うことを聞いても入試の点数は上がらなくて、入試の問題を解けるようになってはじめて入試の点数が上がるのですよ。当時は大学に行けば全てが上手く行くと思っていたし、本当に何としてでも入学したかった（秋田を離れたかったという意味でもあるのですが…）ので、僕なりに最大限の努力をしていました。

大学に入ってから

動機はどうあれ、親元を遠く離れたのは正解でした。自分に欠けているものが何なのか、一人暮らしすることで改めて痛感しましたし、一人の時間が沢山取れることで、考え事に耽ったり、読書したり、勉強したり出来る時間が増えました。

前述の通り人と上手くやる方法を少しは観察から体得していたので、なるべく猫を被って上手くやろうとしていました。成功した時も失敗したときもありましたが、高校の時ほど悲惨な事にはならず、それなりに友達も出来て有意義な学生生活を過ごせました。

それまで井の中の蛙で、高校生にしては超パソコン詳しいと思っていた僕は、確かに学部（正確には学類という）の中でもトップクラスにコンピュータに詳しかったし、プログラミングの授業も授業時間に退屈しながら理解するくらい楽勝だったのですが、上には上がいることを思い知りました。

筑波大にはAC入試という、一種のAO入試というか一芸入試というか、そんな不思議な試験がありまして、情報系のAC生は特にやばい奴がいる所でした。 1年生の時から入っていた団体で同期だった彼もAC生で、当時の知識レベルは僕とは雲泥の差でした。その時点でそこまで差があった理由は僕には分からないのですが、とにかく僕より5年は少なくとも先を行っていました。 最初は精神的な幼さからそれを認められずにいたのですが、彼の度量の広さもあり、一緒にプロジェクトをこなしていく中で仲良くなる事が出来て、かなり色々なことを教わりました。

大学ではとにかく、バイタリティも能力も自分よりずっと高いヤバい人達を沢山見かけて、まだまだ頑張らなきゃ全然だめなんだなと感じました。

中だるみというか、授業が疎かになったりもしたのですが、プログラミング周りの勉強を続けつつ、一応卒業できるだけの単位と卒業研究の成果を揃え、何とか4年で卒業することが出来ました。

大学院にも進学して僕なりに頑張ったけど燃え尽きて、ロボットや人工知能の事は諦めたりしたのですが、だんだん関係なくなってくるので、一旦僕の話はここで終わりにします。

本題

で、そこからどうやってプログラマーになったのか

その後、当時だんだん流行ってきていたRuby on Railsを触ってみて、プログラミングが結構できる、くらいの立ち位置になった僕は、知り合いに誘われて、とあるベンチャー企業でプログラミングのアルバイトをしました。 その会社は滅茶苦茶で、最初はRuby on Railsという話だったのが、途中でバグだらけのiOSアプリをデバッグする仕事に変わったりしたんですが、僕は僕で面白かったのでその話をうけて、滅茶苦茶なiOSアプリのコードのバグをなるべく潰したりしました。仕様がめちゃくちゃ過ぎて、加熱された焼け石に水をかけつづけるような作業でしたが、一応の形にはなりました。 商魂たくましく、時給制だけだとダラダラやってしまうから、プロジェクトが完遂したタイミングでの成果報酬も寄越せと交渉したりして（後輩にかっこいいとこ見せたかった）、徐々にフリーランスへの片鱗を見せていた気がします。

その会社に誘われて入社したんですが9ヶ月くらいで辞めました。なるほどプログラミングが出来ても仕様や企画がダメだと何にもならんのだなと理解しはじめ、単にプログラミング技術だけではなく、企画の練り方、アイディアの作り方、ビジネスモデルの確立の仕方なども勉強すべきなのだと思うようになり、少しですが勉強するようになりました。

その他の所感

プログラミング周りの世界って、まだまだ発展途上で、免許もなくて、教育制度も確立していません。 だから、プログラミング周辺のありとあらゆることに詳しい方が仕事として成立しやすく、結果的に僕みたいに幼少期から延々とコンピュータに触れていたような人がある程度、有利です。 もちろん、大学くらいあるいは大人になってからはじめても、勉強によって追い抜くことは可能です。分野を絞って、CGだけ超詳しいとか、ネットワークだけ超詳しいとか、そういうのを目指すといいと思います。 「いろいろ知ってる」という強みには雑多なトライアンドエラーの積み重ねが必要なので、あなたがそれほど若くないなら、僕みたいな方針は無理に目指さない方が得策だと思います。年季が入ってくれば変わってきますし。

これは漫画家やイラストレーター、文筆業、作曲家といったクリエイター業にも共通するのですが、こういった業種は腕が全てなんですね。 この腕っていうのは必ずしもプログラミング技術や絵の上手さだけでなくて、交渉力やコミュニケーション能力、自己管理能力とか色んな能力が複合した能力を指して、最終的に成果を出してお金を稼ぐ能力、ということです。

新卒で入社するなら交渉とか関係ないんじゃないかと思う人もいると思うんですが、何度か転職している友人もいるので、交渉力は大事だと思います。一発で自分に合う良い会社に入れた人であっても、社内政治で上手くやりぬくのは一種の交渉力が要求されますし、全くないとやっぱり困るんじゃないかな。

進路選択がまだなら

是非、情報系の学部に進むことを進めます。

なるべく偏差値の高い大学をオススメします。やはり偏差値が高いと優秀な人の割合は高いです。 但し、受験勉強一辺倒になって入学するよりは、他の事もある程度こなした上で自分が自然に入れる大学に入るのを僕はオススメします。 無理して大学に入ると地頭が足りなくて授業についていけなくなる恐れがあるので、分相応な大学に入った方がいいと僕は思います。 また、カリキュラムもよく調べて、かならずオープンキャンパス等には一度は行った方がいいですね。一般的な大学入試のアドバイスになってくるのでこの辺で終わり。

専門学校という選択肢がどうなのかは僕は残念ながら行ったことがないので分かりませんが、どうやらゲームプログラマーとかだと結構アリみたいです。 ただ、学力的にある程度の大学に行けるのなら、大学の方がよさそうです。業界で見る優秀な人の多くは大卒だという雑な理屈なので、あなたが専門学校に行っても優秀なプログラマーになれる可能性は大いにあります。

進路選択後（別の分野の学部生や社会人など）なら

進路選択をした後でこの長ったらしいエントリを見るということは、プログラミングをどこまで勉強したらプログラマーとして就職・転職できるかが聞きたいんだと思います。

１つのルートとしては「未経験者歓迎！」と書いてあるヤバい求人に飛び込む事です。案外良いところに入れるかも知れませんし、あちらも赤字は吹きたくないので何か仕事は振ってきます。何かは身につくし、１つの選択肢と言えるでしょう。

もう１つのルートとしては、技術をまずはある程度身につける、という手があります。どういう技術をみにつけると良いかは次の段落を参照してください。

今プログラマーになるなら押さえて欲しい知識

分野によっては不要なこともあるので、ここでは、Webアプリケーションやスマートフォン向けアプリケーションでは少なくとも必要な知識、と解釈してください。

• Git でコミット、プッシュ、マージ、コンフリクトが最低限出来ること
• 何らかのプログラミング言語で、オブジェクト指向プログラミングが出来ること。 クラス・インスタンス・メソッド・インスタンス変数といった言葉をすべて理解していること
• ある程度、英語での読解能力があり、英語で書かれたプログラミングのドキュメントを（辞書を引いても構わない、遅くても構わないが）読むことができて、変数やメソッドを英語で適切に命名できること
• コマンドラインインタフェースで簡単なファイル操作やミドルウェア類のインストールができること
• エラーメッセージをきちんと読み解き、問題点を切り分けて解決できること（どんなものでもというのは難しいので、自分が専門とする分野では少なくとも出来るとよい）

雑多な分類ですが、以下のよに分類して僕が必要だなぁと思うことを書いておきました。 もちろん横断した知識があればよりよいです。 逆に、ちょっと欠けてても先輩から教わりながらで許してもらえる事もあります。（あっ…ここでコミュニケーション能力が役に立つんだな…）

Webフロントエンドエンジニア

Webサイトやシステムの表示をやる人。デザイナーの隣。もちろんバックエンドともお隣 挙げている項目が少ないですが、往々にしてデザイナー寄りもしくはバックエンドよりの知識も一緒に求められます。

• デザイナーと会話出来る程度のデザインの基礎知識(色相・明度といった色の概念、隣接・繰り返しといったデザインの大原則、基本的なタイポグラフィ)
• 画像形式の基礎知識（ラスタとベクタ、不可逆圧縮と可逆圧縮）
• HTML, CSS でのコーディング技術
• JavaScriptでのコーディング技術（一昔前はjQueryとかでしたが、今はAngularやReactなどに移り変わっていて、これら知識が必要だと思います。）
• 世間一般のWebシステムを観察して得た、フロントエンドの洞察や知識

Webバックエンドアプリケーションエンジニア

Webサイトのロジックを作る人。上述のフロントと、インフラエンジニアのお隣かな。

• そのWebサービスの仕様をまとめあげる仕様策定の能力（≒文章力+論理的思考力みたいな感じ）
• リレーショナルデータベースの知識（「ボイスコッド正規化」が何か分かるくらいまでは勉強しよう）
• 何らかのプログラミング言語で書かれたWebアプリケーションフレームワーク、最低でも１つに精通していること（例：Ruby on Rails, Django, Play! Framework, Laravel, Gin, Phoenix, etc ...）
• サーバー・クライアントモデルの基礎知識
• HTTPプロトコルの基礎知識（HTTPメソッドやステータスコード、Cookieなど）
• Unixプロセスの基礎知識
• 暗号化の基礎知識（SSLとか公開鍵暗号とか）
• セキュリティの基礎知識（CSRF,XSS,SQLインジェクション,セッションハイジャック, etc...）
• HTMLのコーディング技術
• CSSとJSの簡単な理解（フロント側と会話する上で何もしらないとちょっとマズいので最低限は知ってて欲しい）
• ブラウザの仕様についての理解（普段から使っていれば分かるようなユーザーとしての知識）

Webインフラエンジニア

Webアプリケーションが動くサーバーが安定して動くように頑張る人。 僕がそこまで詳しくないので、ちょっと足りないものや間違っているがあるかもしれませんが、足がかり程度に。

• Unixの深い理解（プロセスと親子関係、ランレベル、メモリ、サーバー監視の手法）
• クラウドコンピューティングの知識（ロードバランサ、ヘルスチェック、VMのインスタンスという概念やスナップショット、著名なクラウドプラットフォーム固有の知識）
• ネットワークの深い理解（TCP/IP、HTTPをとっかかりに、物理層からTCPの層まで理解しているべき、輻輳や再送制御なども知ってた方がいいはず）
• セキュリティの深い理解（バックエンドのものに加えて様々な知識が欲しい）
• 最近はChefが使えると良い
• Dockerも使えると良い

スマートフォンアプリエンジニア(UI側)

求人ではロジック側と一緒の場合もあるし、両方兼ねてる方がずっといいです。半分くらいはWebフロントと被る。

• デザイナーと会話出来る程度のデザインの基礎知識(色相・明度といった色の概念、隣接・繰り返しといったデザインの大原則、基本的なタイポグラフィ)
• 画像形式の基礎知識（ラスタとベクタ、不可逆圧縮と可逆圧縮）
• 対象プラットフォームでのコーディング技術 （iOSならObjective-C/Swift, AndroidならJava/Kotlinなど）
• 対象プラットフォーム自体への理解（普段からスマートフォンを使っていたら気づくようなこと、push通知が来るときに事前にチェックされるとか、そういうこと）
• 気持ちの良い動きを作れるセンス（センスは才能ではなく観察から身につけるものなので、世の中の色んなUIを触って気付いた事を糧にしましょう）
• 対象プラットフォームのデザインルールの理解（iOSなら"iOS Human Interface Guidelines"を理解する必要あり。Androidでも似たようなのがあるんじゃないかな？）
• 世間一般のスマートフォンアプリを観察して得た洞察や知識

スマートフォンアプリエンジニア(ロジック側)

何か項目少ないけど、アプリの種類によっていろんな知識が必要になるので一般化しにくかっただけで、実際には実務の中で覚えても良いけれど、もっと多くの知識が必要です。

• 対象プラットフォームでのコーディング技術 （iOSならObjective-C/Swift, AndroidならJava/Kotlinなど）
• 対象プラットフォーム自体への理解（普段からスマートフォンを使っていたら気づくようなこと、push通知が来るときに事前にチェックされるとか、そういうこと）
• 世間一般のスマートフォンアプリを観察して得た洞察や知識
• スレッドの概念（少なくともiOSでは必要だけどAndroidはどうなんだろ、知らない）
• HTTPの基礎知識（サーバーと通信するアプリが多いので）
• RDBの知識（端末内にSQLiteとかでデータを保持する事が多いので）

おわりに

筆（指だけど）が乗って結構長くなっちゃった。許して！

もう一回書くけど、僕みたいなパターンだけがプログラマーになる道ではなく、１つのパターンだよってことだから誤読しないでね。 それと、最後に並べた職種毎のスキルのリストは現場によってまちまちだし、実際には「体力と根性」が最強のスキルだったりするので、何処からやって良いか、足がかりがない人のための参考程度のものです。これだけ押さえたら完璧って事でもないし、欠けてたら役立たずって訳でもないです。

炎上防止の言い訳も終わったのでこんなところで。