aoitaku Advent Calendar 2016 : 5日目 - Swift

この記事は aoitaku Advent Calendar 2016 の 5 日目の記事です。

Ruby の次は Swift の話をします。

iOS アプリ開発

今の会社では主に iOS アプリを開発しています。携帯電話の組み込みアプリ開発からプログラマになったぼくがいまこうして iOS アプリ開発をしているというのはなんだか不思議な感慨があります。
作ってるアプリのことはここには書きません。主に Swift のことについて書きます。

Swift 登場

Swift が出てきたときにめちゃびっくりしました。めちゃきれいな構文なんですよね。これといって革新的な言語ではないんだけど、これまでのモダンな言語が取り組んできたことをしっかり踏まえていて、確実にこれは次世代の言語だぞという感じがしていました。

ところが実際に蓋を開けてみるとそうでもなかったりします。

Cocoa 時代の遺産

Swift で iOS アプリを書くということは、これまで Cocoa フレームワークで書かれてきたものの上で Swift を書くということになる。そういうわけで、 Cocoa フレームワークの名残っぽいところがめっちゃある。

たとえば「動詞+前置詞+名詞(引数)」みたいなメソッド名がありますが、これは Objective-C の命名の名残っぽい。前置詞+名詞の部分が長くなりがちで、これがまあいいか悪いかでいうとあんまりよくない。

それでも、 Objective-CCocoa フレームワークでコード書くのと Cocoa 時代の名残のある Swift でコード書くのだったら、後者の方がいいんじゃないかなと思っています。

Optional

Swift のいいところその 1。Optional とかいうやつがあります。

String?? がそうです。この ? がついてると nil を代入可能になります。Optional でなければ nil は受け付けません。Optional 以外はいつでも安全に使うことができ、Optional も Optional Chaining や Optional Binding によって安全に nil でない値を取り扱うことができるようになります。

Optional Chaining というのは Ruby のぼっち演算子によく似ています。

foo&.bar # hoge が nil ならメソッド bar は呼ばれない

ぼっち演算子というのはこういうやつです。
Optional Chaining はこう。

foo?.bar() // foo が nil ならメソッド bar は呼ばれない

Optional 型は中の値を取り出すためにアンラップする必要があります。 Optional Chaining は nil だったら何もせず、値があればアンラップしてメソッドを呼び出します。 null 安全にメソッド呼び出しができます。

Optional Binding は nil ガードのための仕組みです。

if let foo = foo {
    print("foo は nil でない")
} else {
    print("foo は nil")
}

こういう感じのやつ。let foo = fooOptionalfoo をアンラップして foo に代入してます。nil だったら else にいきます。これとは別に guard キーワードというのもあって、こっちは nil だったら早々にメソッド抜けたいとかそういうときに便利です。

このへんは調べると楽しいと思うので調べてみるといいと思います。

Optional 自体はべつに Swift が先進的なわけではなくて、他の言語にもうある文化でした。Haskell の Maybe とか Scala の Option とかそうです。最近だと Kotlin の Nullable もそうですかね。でも先進的かどうかは別にどうでもよくて、null 安全なコードを書きたい、あるいは書けるようにしていこうという背景があって、Swift もまたそういう背景の中で生まれてきた言語だろう、ということだと思います。

型推論

いいところその 2。
Swift は型推論してくれます。自明な型は省略可能です。でもそもそも Swift の型自体はそんなに書くのは大変ではない印象です。Xcode が補完してくれるというのはあると思いますが。

コレクション

いいところその 3。
配列型とか Dictionary 型とかわりと書きやすいと思います。<>記法はちょっと書くのしんどいなと思っています。

Map<String, List<String>>

これは Java の例なんですけど、こういうのはちょっと嫌な感じだなあと思っています。

Swift だとこう。

// Dictionary<String, Array<String>>
[String: [String]]

簡潔で好みっぽい。

ブロック

いいところその4。
ブロックが書けます。

list.sort { $0 < $1 }

こういうことできます。

Array まわりのメソッドが揃っていて、filter とか map とか reduce とかあるので一通りできます。

enum

Swift の enumswitch に渡すと足りない case を警告したりしてくれて便利です。

enum Fruits {
    case Apple
    case Banana
    case Cherry
}

switch fruits {
case Apple:
  print("りんごだよ~")
}

こういうことすると BananaCherry をちゃんと書くか default 書くかしないとダメって言われます。親切。

いいところほかにもある感じですがぱっと思いついた Swift の気に入ってるところはこんな感じです。

そして Swift 3 へ

Cocoa 時代の遺産の話をしましたが、Swift 3 によって、Swift はあたらしいステージに移行すると考えています。

NeXTSTEP に由来する NS というプレフィクスが Swift 3 から消えます。NSString も NSDate もみんなただの String や Date になります。*1

Objective-C といえばという感じのあの長いメソッド名も、前置詞以下が名前付き引数になって、シンプルなインターフェースになります。

完全に Cocoa のことを忘れてしまえるかというとそうではないと思いますが、NS つけてから Xcode に「もう NS はいらんやで~」って言われたりすると「そっか……もう NS はいらないのか……」と不思議な感慨を抱いたりします。

まだ Swift 一年生

ここまでいろいろ書いてきたんだけど、今の会社に入って 11 ヶ月になりますが、iOS アプリ開発にフルコミットしてきたわけではないので、Swift もまだまだ自分の手に馴染んだとは言いがたくて、やっぱり自分で一個 iOS アプリ書いてみたいなーという気持ちがあります。

iOS アプリ以外になにやってきたかというと、二つのことをやっていて、どっちも同じ言語です。同じ言語で二つのことをできるやつ、といえば、もうお察しかと思います。

というわけでまた次回。お楽しみに。

*1:全部なくなるわけではないです

aoitaku Advent Calendar 2016 : 4日目 - Ruby

この記事は aoitaku Advent Calendar 2016 の 4 日目の記事です。

PHP の次です。
今の会社に入って最初のプロジェクトが Ruby でした。Ruby で Web の仕事ということで Ruby on Rails です。Rails やるのはこれがはじめてで、めちゃくちゃ苦労したし誘ってくれた人にもめちゃくちゃ迷惑をかけました。忸怩たる思いでいっぱいなんですが、いちおう先月無事に保守期間を終えてクローズできて、完全にぼくの手を離れています。
大変なプロジェクトだった。でも大変だったのは「はじめての Rails」だったからということではないんですよね。

PHPRuby

これはぼくの経歴ではなく、プロジェクトがそういうプロジェクトでした。CakePHP で作られたシステムを Rails でリプレースする。それがぼくの最初の Ruby の仕事でした。
いまから思えば、まっさらな状態で Rails を触っておくべきだった。Mac もあったし、なんでそうしなかったんだろうか、と思ったりもするんだけど、でもチュートリアルやったところでたいして変わらなかったような気もしています。やらないよりはよかったろうとは思うんだけど。一個自分で何か作って動かすところまでやっておきたかった。

PHP は読めるし、CakePHP のことも全く知らないわけではなかったんだけど、とにかく元のシステムの品質が悪かった。これはいいわけではなくて本当に品質のよくないシステムで、プロダクションのプログラムに未使用のコードが普通に混入しているし、プロダクションのデータベースに未使用のテーブルが普通に混入しているし、という状況の中で、仕様書や設計書みたいな資料はなし、動いているプログラムが仕様、という状態でスタート。
何が正しくて何が間違っているのか分からないのでとりあえず愚直に CakePHP のコードを Rails に移植しようとすると当たり前だけどぜんぜん Rails にならない。かといって Rails らしく書くと元の仕様からは大きく手を入れないといけない、ということもたくさんあって、ベターな実装に置き換えたものがあとでクレームがついたり、悪い実装の陰に潜在していたバグが表に出てきたり、いろいろなことがありました。

CakePHP はそんなに筋の悪いフレームワークではないと思っています。もちろん Symfony 2 のほうがよい設計思想だと感じていますし、FuelPHP のほうが小回りきくだろうという感じですし、最近だと Laravel がベターなんじゃないかなと思っていますが、それはそれとして、Cake の上に乗っているコードがあまりよくなかった。

結局ほとんど一から書き直したんだけど、これだったら本当に Rails で一から作ったほうが Rails のこともっとちゃんとわかったろうなあ、と思います。

Rails のこと

Rails のことは話には聞いていたんですが、実際に触るとこれは Rails であって Ruby ではないという実感がありました。
それは Rails の、というか Active なんとかとか Action なんとかのパワフルさがそうしてるんだと思いますが、Rails way で書く、というのが一貫していて、コードは書きやすいように思います。
言うほどちゃんと Rails way が身についたわけではないので、ちゃんと一からプロダクト作ってみたい気持ちがあります。

Rails じゃないこと(あるいは Ruby そのもののこと)

それはそれとして、ぼくが Ruby と出会ったのは最初に入った会社をやめるより少し前のことでした。RPG ツクール VX のエンジンであるところの RGSS2 が Ruby 1.8系 をスクリプトエンジンとして積んでいて、最初触るまでは「ゲームを Ruby で拡張できるのかなー」くらいのことを思っていたんですが、実際触って「なんじゃこれほとんど Ruby で書いてあるやんけ!」って驚く。
当時 C++ を書いてたぼくは、Ruby のほとんどぜんぶオブジェクトであることのうつくしさとか、Class と Module というクラスシステム、いわゆる mix-in というやつですが、これにめちゃくちゃ感動します。
PHP を仕事で使うようになってからも傍らでずっと Ruby を書いてきました。 演算子式が単なるメソッド呼び出しのシンタックスシュガーだとか、method_missing 使った任意のメッセージ転送とか、動的なメソッド定義とか、演算子オーバーロード 、ブロックのオブジェクト化、lambda、カリー化と部分適用……どんどん Ruby にどっぷりハマっていきました。
このへん あおたくノート をご覧の方にとってはもういまさらですね。Ruby のどこが好きかと聞かれるといろんなところが好きなので一言でいうのはむずかしいですが、内部 DSL が作るのに適したつくりになっているところはたぶんいちばん好きだと思います。

これからの Ruby のこと(あるいは Ruby の先でぼくに起こった変化)

3.0 で型が入る予定ということですが、Matz の「型を書きたくない」に同意しつつも、型がないと困る場面は割と経験していて、型があったらいいのにな、と思うことはままあります。それはそれとして、型を書かずにいきなり書けることは Ruby の魅力だとも思っていて、できるだけ型なんか書かなくても、うまいこと推論してくれるのがいちばんよいとも思っています。
完全に推論してくれなくても、とりあえず実行前、つまりコンパイル時にエラーで弾いてくれたらそれはありがたいわけです。
もっというと、型というか制約がほしくて、同じ型でもたとえば数値だったら正の数だけほしいとかゼロはほしくないとか一定の範囲内の値がほしいとかそういう制約をかけたいことあるわけです。あるいは実行前にパターンマッチのチェックとかできたらいいなとかもあるわけです。
実はそのへんの思想の変化についてはわりと最近起こってきたことで、それが次の記事のテーマになってくるわけですが、そういうわけでまた次回。お楽しみに。

aoitaku Advent Calendar 2016 : 3日目 - PHP

この記事は aoitaku Advent Calendar 2016 の 3 日目の記事です。「日付またいでても朝が来るまでは当日」と供述しており(もう夜なんだよなあ)。

さて、携帯電話の組み込みアプリケーション開発の現場を出て、次に向かうのが Web 業界でした。もともと Perl でブログシステムを自作しようとかそういう志向だったので、Web 業界行きたいというのは就職するときからずっと思ってことではあります。

でも時代は Perl ではなかった。というか、ぼちぼち Ruby の時代っぽいな、ということを思っていました。
Ruby の時代っぽいなと思っていたのに、きょうのテーマは PHP です。

WordPress

なんで WordPress にしようと思ったのかはあんまり覚えていません。
自分のサイトをリニューアルするにあたって、Perl でブログシステム作るのはわりと大変なので、MySQL が使える PHP のほうがよいな、とか、XAMPP で Windows でも一発で一式揃うの楽だな、とか、背景にはいろいろあったと思います。
Ruby じゃなかったのは、WindowsRuby がわりときつい印象があったのもたぶんあると思います。当時のぼくはインフラに対する知識がぜんぜんなくて、そのへんに手を出すことに少なからず抵抗がありました。

さて、自分のサイトに WordPress を導入してリニューアルすることにして、WordPress のテンプレートシステムとか見ていくわけですが、その手の情報は WWW 上に山のようにありました。ググってコード見て弄って、というのを繰り返すだけでだいたい思ったように動いて、なんだ PHP とかいうやつもしかして簡単なんじゃないか? そのときのぼくはそんなことを思っていたのです。

Web 業界にドボン

会社をやめてから数ヶ月の間、病気の療養をしつつ独学で PHP のコードを書いていました。WordPressプラグイン作ったり、JQueryプラグイン作ったりということもしていました。

そのへんの成果物をポートフォリオにして、何社か受けては落ちたりしつつも、従業員 10 人そこそこの小さな Web 制作会社に入社しました。
WordPress で企業のコーポレートサイトを作るのが主な業務で、デザイナーが起こしたデザインを元にひたすら WordPress でコーポレートサイト作るという感じのところでした。

まあ WordPress はわかるし大丈夫やろ。

ところがどっこいぼくが入社して二つ目に担当することになったプロジェクトは WordPress じゃなくて Symfony 使ったウェブサービスの構築でした。

不協和 Symfony

当時はまだ Symfony 2 でなくて 1 系だったんですが、なんにしても Web アプリケーションフレームワークはほとんど触ったことがなくて、Rails インスパイアな感じなんだろうなくらいのゆるい認識しかなかったんだけど、チュートリアルからしてもうぜんぜんわからない。
そもそもまず Windows があかんので仮想環境を構築するところからです。VirtualBoxUbuntu 入れて、Symfony 入れて、コマンドラインからタスク叩いてプロジェクト生成して……。
このへんの手順がもう今までの開発とぜんぜん違う。Ubuntu のセットアップもめちゃくちゃ苦労した。
そもそも社内にノウハウがない。なんで社内にノウハウがないプロジェクトを受注してしまうんだ。とか思ったりはするものの、言ってもしょうがないので覚えるしかない。
社内の動作確認用のサーバが必要になって、そもそも社内の共有サーバが Windows サーバでめちゃくちゃ性能が悪くて、これもどうにかできないか、という声がほかのメンバーから上がってる状況で、いっそ Linux サーバ立てたらどうですか、という提案をしたら、ぼくが Linux サーバを立てることになっていた。
クライアントに見せるためのステージング環境が必要になって、さくらの VPS を借りて VPS にデプロイするとかそういうこともやることになりました。

いろんなこと覚えられたので給料もらいながら勉強できてよかったなー!とは思っています。

このプロジェクト、ぼくが入ったときにはすでに納期を 2 ヶ月オーバーしていて、ぼくが入る前にひとりやめてるんですが、彼がいたらたぶん円満にクローズできてたんだろうな、と思ったりしながら、結局最後まで鎮火することなく、炎上したままプロジェクトから手を引くという形で燃え尽きました。

フレームレスワーク

この会社は一年くらいでやめました。事前の予告なしにいきなり正社員からアルバイトに格下げするねと通達されて、何が起こったのかいまでも全然わからないんだけど、まあそういうことがありました。
それからしばらくしてべつの会社に入って、そこでは自社の Web サービスの改修を担当することになるんですが、「社内にわかる人間いないからさあ、フレームワーク?とかは使わないで作ってね~」というちょっと何を言ってるのかわからなかったんですけど、そういう事情でフラットな PHP で Web サービスを作っていました。 たぶんですけどググったら情報出てくるフレームワークのほうがオレオレフレームワークもどきよりぜったいほかの人にもわかるやつだと思うんですよね。

この会社には忘れられない思い出があるのでツイートを引用しておきます。

趣がありますね。

それから

あんまり PHP の話をしてないですが、PHP という言語に対して思うところは実はあんまりなかったりはします。
それでも PHP Matsuri 参加したりとかぼく自身 PHP という言語自体はそんなにきらいではなくて、最近の PHP の状況とかみるとめちゃくちゃよくなってきてるなという印象がありますし、でも実際に PHP を使っている現場はというと、上に書いたようなところもとても多いのではないかという気持ちがあります。ぼくがそういうところしか知らんだけなのかもしれないんだけど。

この会社には丸二年いました。ぼく以外のエンジニアがやめてしまってひとりだったのとか、あたらしい技術に触れたりすることもなさそうだなーとか、なんなら最後の方は HTML と CSS ばっか書いてたなーという感じで、くすぶってる感じでした。

そんなときに声をかけてもらって、今の会社に入ります。
それではまた次回。

aoitaku Advent Calendar 2016 : 2日目 - C++

この記事は aoitaku Advent Calendar 2016 の 2 日目の記事です。「日付またいでても朝が来るまでは当日」と供述しており(もう 4 日なんだよなあ)。

Perl の次の話をします。タイトルに書いてあるんだけどね。

プログラマになった日

今から 9 年くらい前に「職業:プログラマ」になりました。正確に言うと設計もやるので SE でもあったわけですが、アマチュアプログラマでなくプログラムを書いて給料をもらう立場になった、という意味で、ひとつのターニングポイントでした。

就職して出社初日、さっそく現場に放り込まれました。

いや何が起こってるのかぜんぜんわからないんだけど就職したその日にいきなり現場に放り込まれました。OJT? そんなものはなかった。

現場のことをあまり詳しく書くことはしませんが、携帯電話向け組み込みアプリケーション開発をするところに外注スタッフとして配属されました。
組み込みといっても組み込み系ではなくて OS があって OS の上で動くリッチアプリケーションの開発だったので実際 Windows アプリケーション開発とかいまのスマートフォンアプリケーション開発とそうは変わりませんし、というか、そもそもその携帯電話に載っていた OS はスマートフォン向けの OS なわけで、実際のところ当時の携帯電話は構造としてはスマートフォンとほとんど変わらなかったと思っています。

この OS について詳しく書くとぼくが具体的にどの会社のどういう事業で仕事をしていたかわかってしまうので仔細は省略します。大人の事情があるのでこれ以上は書けません。そういえば全然話は関係ないんですけどアドベントカレンダーが話題になっていますね。陰ながら応援しています。

型のある世界

さて、C++ の話をします。ぼくはそれまで Perl を書いていたので、型システムのある言語に触れるのはこれがはじめてでした。もちろん事前コンパイルをする言語もこれがはじめてです。

型という概念、実は Perl でも意識します。

たとえば Perl の比較演算子には二種類あります。ひとつは数値比較演算子。もうひとつが文字列比較演算子です。Perl では数値と文字列は明確に区別されます。数値比較演算子オペランドは数値として扱われ、文字列比較演算子オペランドは文字列かそうでないかも判定します。

1 == '1' # true
1 eq '1' # false

こういう世界にいたので、型らしきものの存在をぼくは知っていました。 むしろ型があることで「ある変数が何を示しているのかは宣言を見ればわかる」という恩恵を受けられることに気付きます。
もちろん型があって困ったこともあります。たとえば配列は基本的に同じ型しか取り扱わないので、Perl のように型を気にせず適当に配列に突っ込むみたいなことはできないし、Perl で最高だと思っていた連想配列のようなものは C++ には基本的には存在しないので、ちょっとしたものをひとつの変数にまとめて取り回したいとなったら構造体をいちいち宣言しないといけなくて面倒だなと思ったりはしました。

ポインタのある世界

C や C++ といえばポインタ。メモリのアドレスがむき出しの世界です。

さて、Perl にはリファレンスがあります。

C や C++ のポインタと Perl のリファレンスの違いは何かというと、やりたいこととしては同じです。違ってるのはメモリのアドレスがむき出しかどうかという点です。

どちらも値そのものではなく値のある場所を指し示す何かという情報を取り扱うという意味では同じものだと思っています。

「ポインタむずかしい」ということをよく聞きます。ぼくは Perl のリファレンスよりポインタのほうがメモリアドレスがむき出しになってる分理解しやすい気がしています。ポインタの場合、変数に入ってるのはメモリアドレスっていう実際の値ですからね。

「ポインタむずかしい」という人は、じゃあたとえば C++ の参照はわかるかというと、たぶんポインタよりむずかしいのではないかと思います。なんなら「ポインタがあるのになんで参照が必要なんだ?」と思うかもしれない。

C++ の参照がむずかしいなら、他の言語の参照だって多分むずかしいと思います。

逆に「変数が何を示しているのか」という根本的な理解があれば、ポインタも参照も概念としてはわかるんじゃないかと思っています。

Perlスクリプト言語ながら、変数の前に記号つけて変数をリファレンスにしたり、リファレンスの記号を置き換えることでリファレンスが指し示している値を参照したりということをします。これはポインタとやりたいこととしては一緒です。

メモリに対する意識

たとえば文字列なんですが、文字列というのは実体は文字の配列です。一文字の実体は何らかの数値で、文字列は文字をあらわす数値の配列だということになります。*1
さて、10 万文字の文字列があったとして、文字列を引数として受け取る関数に、この 10 万文字の文字列を引数に渡すことを考えます。

10 万文字の文字列は関数に渡されるときに、あたらしい変数としてコピーされます。このとき 10 万文字分のメモリコピーが発生します。10 万文字というのは乱暴にいって 2 ~ 300 KB くらいです。*2 元の文字列が 300 KB メモリを使ってて、関数の引数に渡すとさらに 300 KB メモリを使うというわけです。メモリ消費自体もそうですが、300 KB 分のメモリコピーを繰り返すとそれ自体に時間がかかりそうですね? CPU が一度に処理できるデータ量には限界があるので、大きなデータを処理するのはそれだけで時間がかかります。単なるコピーですらそうです。
メモリコピーに時間がかかるのもそうだし、メモリサイズには限界があるので、直接値を扱うことを繰り返しているとメモリが足りなくなったりもします。実際にメモリが限られた環境では関数の呼び出しが深くなるとスタック領域を破壊したりします。

実際に仕事でもスタック破壊に遭遇したことがあります。
開発機は PC なのでメモリは充分にある一方、実機は携帯電話なのでメモリには限りがあり、開発機のエミュレータ上で動作確認する分には問題なく動くのに、実機上では存在するはずの関数の呼び出しでアクセス違反が発生して異常終了する、ということがありました。アクセス違反になるのはスタック領域が足りなくなったからなんですが、スタック領域が足りなくなった原因は何かというと巨大な構造体の値渡しでした。
思わず「なんでこういうことするの……」って口からこぼれましたが、いま思い返してみると原因がわかってよかったですね(よくない)。

ちなみに巨大な構造体はヒープ領域に置くようにしたので問題はなくなりました。

ヒープ領域とスタック領域のことは説明しません。ただ、メモリを意識しないで適当にコードを書くとめちゃくちゃ困るぞということです。メモリを意識するということは、変数が何を示しているのか理解するということだと思っています。

「ポインタを必要以上に恐れるべきではない。ポインタより恐ろしいのはメモリに対する無意識である」

ちなみに、ぼくがメモリを意識するようになったのは Perl のリファレンスについての説明を読んでからです。最初に触れた言語が Perl だったから、ぼくはプログラマとしてなんとかやってこれたような気がします。

オブジェクト指向

Perlオブジェクト指向ではない、とみなされていたように思います。実際には Perl のモジュールはオブジェクト指向をサポートします。C++ に出会う前にぼくはオブジェクト指向について既に知っていました。C++ で class を見て、Perl よりずいぶん簡単にクラスを書けるなという感想を持ったのを覚えています。

しかしめちゃくちゃ覚えることが多かった。 たとえば C++ には interface というキーワードがなくて、interface っぽいものを作るには、純粋仮想関数とかいうやつを使います。ところでいまこのくだり書いてて自分でびっくりしたんだけど C++ なんてもう久しく書いてないのに「 interface のために純粋仮想関数を書く」ということを覚えていてめっちゃびっくりした*3
純粋仮想関数って聞いて直感的にこれが interface のためのものですよってわかるかといったらわかるわけないですし、virtual キーワードが派生クラスでオーバーライド可能だということを示すものですよということもぜんぜんわからなくて、このへんは Java のキーワードの明確さがうらやましく感じたりしました。*4

ジェネリクス

でも一番苦労したのはテンプレートです。ジェネリクスという概念がそもそも未知のものでした。
未知のものだった以上に、テンプレートが絡んだエラーがめちゃくちゃわかりにくくて、どこをどう修正したらエラーを解消できるのかぜんぜんわからなくて苦労した覚えがあります。
ジェネリクスがとても便利なものだということを知るのはもうちょっと後のことですが、当時から今にいたるまでずっとテンプレートに対して「C++こわい」という印象を持っています。

現場から去るとき

この現場には丸三年いました。
あとで聞いた話によると、ぼくが配属された部署は、いろんな外注社員が放り込まれるけどだいたいみんな一ヶ月で異動願を申し出るか、使えないからもう来なくていいよとお払い箱にされるかどちらからしいです。
ぼくよりちょっと前に入った人がものをめちゃくちゃ覚えるのが苦手な人で、ぼくも何度も繰り返し同じことを説明した記憶がありますが、彼はそれでも二年くらいぼくと同じ部署にいました。
彼ですらそれだけ長くいたことを考えると一ヶ月でみんなやめることになったというのは嘘なんじゃないかという気がしていますが、どうも嘘ではないらしく、ほかのアウトソーシング系の会社の人と話したときに「あの現場ねー有名だよねー、どれくらいいたの?」って聞かれて「三年ですかね」って答えたら驚かれたのでこっちが驚いたというかなんというか。

やめた理由は直接的には病気を患ったからです。
まあ慢性的な睡眠不足とか偏った栄養とかストレスとかいろいろあると思いますが、不眠がひどいし何か食べるとだいたい下痢するし偏頭痛は常態化しているし……まあでもわりとある話です。ありふれた話です。

やめずにあの場所にいたら、ぼくはどういうプログラマになっていたのか、たまに想像することがあります。携帯電話の開発は、もう当時そろそろ行き着くところまで来たなという感じで、スマートフォンによって市場は一新されるだろうな、そういう気配がありました。これからは AndroidiPhone の時代になる。それは多分あの場にいた誰もが感じていただろうと思います。
Android 向けの組み込みアプリケーション開発チームに入ることはできなかったんじゃないかな。即戦力になる Java プログラマでチームが再編され、ぼくは携帯電話開発から遅かれ早かれ去っていただろうと思います。次にどこに行ったかはわかりません。
現場を去って、次の現場としてトヨタ系のロボット制御システム開発の現場の面接にいってここは内定出てた*5らしいんですが、ぼくはこれを断って会社を辞めて、しばらくの後、ウェブエンジニアを目指すことになります。

さて、この現場を去るちょっと前くらい、ぼくは RPG ツクール VX を買いました。たぶんらんだむダンジョンをプレイしたからだと思うんですが、現場がわりとしんどくて、手慰みにゲームでも作りたいなとかそういうことを思っていました。 というわけで、C++ の次は…… PHP の話をします。お楽しみに。

*1:適当なテキストファイルをバイナリエディタで開いてみればわかると思います

*2:文字コードによります

*3:書いてからあってるか不安になって一応調べました

*4:今覚えば気の迷いです

*5:面談で話した前の現場での三年間の話が生きたらしいです

aoitaku Advent Calendar 2016 : 1日目 - Perl

この記事は aoitaku Advent Calendar 2016 の 1 日目の記事です。「日付またいでても朝が来るまでは当日」と供述しており。

ひとりアドベントカレンダーは毎年やろうと思うんですが完走できないことをおそれてけっきょくやらずじまいになっていたんですがヴぃさんがやっているのを見て勇気づけられたのでやることにしました。完走目指してがんばります。

一日目なのでぼくの最初のプログラミング体験についての話をします。

最初のプログラミング未満

ぼくの最初の個人ウェブサイトは 2003 年の 4 月に開設されました。

当時はみんなわりと個人ウェブサイトを作ったりするのがふつうの時代で、メモ帳に HTML タグを直打ちして FTP でアップするというのがよく行われていました。
ぼくも HTML タグリファレンスを読みながらタグ打ちでウェブページを作ってドット絵とか小説とかを公開していました。 ぼくにとってコンピュータ言語を使って何かをするという体験は、主にこれが最初です。*1

このサイトは 10 ヶ月くらいで閉鎖して、2004 年の 3 月頃に二つ目の個人ウェブサイトを開設します。このときに CGI を設置できる有料レンタルサーバーを借りて、掲示板などを設置したりしました。ぼくのプログラミングはここから始まりました。

Perl との出会い

CGIソースコードの拡張子が cgi だったせいで当時 CGIプログラミング言語の一種だと思っていたぼくですが、このときぼくが触れたプログラミング言語Perl です。
ぼくが最初にプログラミングを行った言語は、 Perl でした。

Perl はいわゆるスクリプト言語で、動的型付け、コンパイルが不要という特徴があります。といってもこれが最初なのでそのあたりのことはよくわかっていません。

最初に戸惑ったのはパーミッションというやつでした。わかる人はわかると思うのですが、パーミッションというやつを正しく設定しないと CGI はちゃんと動作しません。このへんの理屈はいまではよく理解できるのですが、当時はよくわかってなかったので何回やっても覚えられませんでした。パーミッションってなんやねん、と。
まあでも当たり前なんですよね。なんでもかんでも自由にプログラム実行できるほうがおかしい。スクリプトはプログラムなのだから、パーミッションを適切に付与する必要がある。それだけのことです。

それだけのことがわかっていない当時のぼくは、まず既存のスクリプトを改変するところからはじめました。

掲示板のスクリプトが配布されていたのでこれをダウンロードしてきて、設定項目をいじって FTP でアップしてパーミッションを設定する。

動いて感動して、でも自分のホームページと背景色が違う *2 のでどうも借り物感が強い、ここは自分のサイトなんだからやっぱり自分のサイトのカラーにしたいよねと思って、背景色を変えたり文字色を変えたりということをはじめます。

そしてぼくはこう思うわけです。

「なんでこの掲示板スクリプト bgcolor とかいうレガシーなものいまだに使ってるんだ?」

そう、ぼくは当時 HTML 原理主義者だったのでした。

見た目は CSS で指定し、HTML は文書構造を表現するものであるという考えを持っていたぼくは、font 要素*3排除、center 要素排除、bgcolor 属性排除……と非推奨の要素や属性をスクリプトから消し去ることに躍起になっていました。

ところがだいたいのスクリプトはここまでのことをする想定になっていないので、スクリプトの大改造が必要になります。
HTML/CSS の仕様を読んだりして Web 標準とかいうものを理解したつもりになって調子に乗っていたぼくは、Perl も調べたら簡単にわかるんじゃね?という甘い気持ちで Perl についてググりまくるようになります。

500 Internal Server Error

「ぜんぜんわからん」

Perl は「とても読みにくいプログラミング言語」として知られています。何がわからなかったかというと、書いてあるプログラムの意図がぜんぜんわからなかった。Perl の解説サイトとかは当時たくさんあったんですが*4、解説サイトを見てもスクリプト組んだ人の気持ちまではわからないわけです。そもそも個人が独学で書いた Perl スクリプトのコードの品質は非常に低く、Perl という言語がとても自由な記述を許容する言語だったこともあって、既存のスクリプトの改変は非常に難航します。

500 Internal Server Error を何度も目にしました。

ぼくは気付きます。

「もっとシンプルなスクリプト使えばいいんだ」

片っ端からスクリプトをダウンロードしてきて、機能が少ないものを探しました。機能が少ないものはコード量が少ないので理解しやすいと思ったのです。そしてそれはだいたい当たっていて、小さなものから少しずつ Perl への理解が深まっていきます。

スカラーと配列と連想配列? この連想配列とかいうやつめっちゃ便利では」 「リファレンスとデリファレンス……値渡しはメモリコピーが発生して遅いからリファレンスを使う、なるほど」 「モジュール使いたい……レンタルサーバにモジュールない……」

で、いろいろあってサーバを移転したりサイトをリニューアルしたりとかして、Alias under the Azure が開設されます。モジュールもサーバ管理者に申請したらインストールしてもらえたりしました。

「この bloxsom とかいうやつめっちゃいいな」

bloxsom と出会います。

自前のブログシステムの構築

レンタルブログの管理画面の使いにくさに辟易していたぼくは、自分用のブログシステムがほしいと思うようになりました。簡易記法を使ってルビを簡単に振れるようになったらいいのにとか、リンクとか引用文とか簡単に書けたらいいのにとか。当時のブログは基本的に HTML タグ直書きで、しかも使えるタグと使えないタグがあったりしたものです。

bloxsom に自前のプラグインを組み込んで、自前の簡易記法パーサでテキスト変換して HTML 出力するようにすればいいのでは?みたいなことを考えてしまったぼくは、簡易テキストフォーマット沼に足を踏み入れることになります。

まあ今から考えると Markdown でよかったですよね。bloxsom の作者は Markdown の作者でもありまして、もちろん当時から Markdown は存在しているし、ぼくも Markdown の存在は知ってたんですが、なんで Markdown ではいけなかったんだろう。ルビがないからかな。自分で作りたかったからかもしれない。

もちろんこれは頓挫しました。

頓挫しましたが、それはそれで、それなりにぼくにとって経験になりました。Perl と出会っていなければ、ぼくはプログラマになることはできなかったろうと思っています。

挫折の先

Perl の後、ぼくは RubyPHP に出会います。そして結果的には PHP ではなく Ruby を使うのがメインになっていくのですが、これは PHP ではゲームプログラミングができなかったからというだけのことで、ぼくの指向が Web 方面のままだったならば、PHP の道を進んでいったかもしれません。

さて、PerlRubyPHP の間にもう一つ言語があります。 ぼくは Perl に触れた経験のおかげでその言語とうまく付き合っていくことができたわけなんですが、2日目はその言語の話をします。お楽しみに。

*1:厳密にはこれ以前に BASIC の写経とかやったりはしています

*2:当時のぼくのサイトは背景色が濃い青色、文字色が青みがかった白色でした

*3:この頃からタグという言葉を使うのをやめて要素という言葉を使い始めます

*4:そういえば多くの個人サイトの消失にともなって Perl の解説サイトは随分減った気がします

SCE_2 メモ

リアス(海岸)、エスチャリー(汽水域)、ラグーン(湾)、ベーシン(流域)、フィヨルド(氷河に侵食された入江)、トレンチ(海溝)はみんな水の地形に関する名前なのに対して、リクケイとアイリアは島である。 また、リクケイは陸と繋がっている一方、アイリアは海に閉ざされている。

オチはない。

フィンランド語は猫の言葉という本を読みました

フィンランド語は猫の言葉

フィンランド語は猫の言葉

めちゃくちゃおもしろかった。
書かれてから随分経つ本なんだけど今読んでもぜんぜん色あせないよさがあります。惜しむらくは学生の頃に読んでおきたかったとかそういうことだけですね(※ぼくは外国語学部にいましたが諸般の事情で二年次に中途退学しています)。

著者によるフィンランド留学の記録を軽いタッチの文で綴った本なんですが、タイトルからしてもう絶妙なセンスで(なんでこういうタイトルなのかは読めばわかるのでぜひ読んでほしい)、読めば読むほどにフィンランドって楽しい!って気持ちになります。

巻き舌のrが発音できなくて苦しかったとか子音が連続する発音が苦手だったとか、母音が現れることが多い言語なので日本語の別の言葉に空耳しやすくて可笑しみがあるとか、外国語の入門の際に触れると「あ~わかる!」ってなるところがたくさんあって、これから外国語やろうとか、いま外国語やってるんだけどなかなかモチベーションが上がらないみたいな人は読むと元気になるんじゃないかとか思います。 わからんこと多いしむずかしいことも多いからしんどいこともあるけど、外国語って楽しいんですよ。

話は留学したときのことなのでフィンランド語に限らないフィンランドでの生活に広く渡っていて、フィンランド人、ひいてはフィンランドという国の空気とかそういうのも伝わってきて、フィンランドってええ国やなあ、と思いました。もともとぼくが北欧好きとかはあります。

Kindle で手頃な価格で買えるし、さくっと読めるくらいの読みやすさなので、興味わいたらぜひ読んでほしい。いい本です。