SIerを退職し、Web系に転職しました。アフター

銀行系列の中規模SIerを退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することにしました という記事を書いたところ、想像以上の反響がありました。 それから一年経ったので、その後のことなど書いていこうと思います。

１．変わったこと

２．変わらなかったこと

３．これから

１．変わったこと

・COBOLとJavaAppletを書いていたかつてのシステムエンジニアはフロントエンドエンジニアになった

それっぽく言ったけどjavascriptを書く人になったということですね。今の会社はGoogleApps上でのクラウドサービスを提供していてサーバーをGAEで書いています。私はjsで書かれたフロントを主に、たまにpythonで開発をすることになりました。

・仕事へのモチベーションは上がった

受託で常駐で、というかつてのビジネス構造的から発生していた理不尽さが減りました。github閲覧できないとか。紙と印鑑ありきのフローであるとか。

・出社時間を強制されなくなった

名目ばかりではない裁量労働制になっているんだなあと思います。

・会社でブルックスのコーヒーがおいてあって好きに飲んでいい

大したことない感じするかもしれないが案外こういうのが日々のやる気につながってくるのだと知りました。ところでみなさんレッドブルとかは本当に今この瞬間だけがんばりたい、という時以外は飲まないほうがいいですよ。

・Windowsの世界で生きてきたからMacというかUnixを使うのは大変だった

右クリから空のファイル作ったりできなくてつらいとか、SSどうやって撮るのとか、そもそもこのコマンドボタンというものは一体なんなんだ？とかありました。そして開発に関する作業は結局ターミナルからやるのがいいのだと思い至ります。昔はCOBOLをコンパイルするときくらいしか黒い画面触らなかったものなのですがね。ただしエディタはIDE。

・昔のような方眼紙の設計書はなくなった

もちろん設計書自体がないわけではなく、プログラムの処理を日本語で書いたいわゆる詳細設計書がなくなりました。納品とかありませんし。 ドキュメント的に残すのはサーバーはAPI仕様、クライアントは特にまとまったものはなく、あとはソースとかモデルのコメントみてね、という感じです。最初は何から手を付けていいかわからなくて途方に暮れましたが、慣れると案外なんとかなります。小さく始める、を地で行けるやり方です。

・スケジュールだけが決まっている開発、が基本なくなった

アジャイルっぽくやっているおかげで、ストーリーとそのベロシティで線を想定しています。もちろんリリース先ぎめの物も存在しますが、その時は機能のスコープで調整します。あっこれアジャイルサムライで見たやつだ！ってなりました。

・ユニットテストとCIをするようになった

業務でユニットテストを書くようになりました。今までどうしてそういう現場がなかったのかと思っていましたが、ユニットテストは設計時に予めそうできるような構造しておかねばいけないのであり、そしてその技術はしっかり考えて身につけるべきものであって、なんとなくでできるものではないのだ、ということがわかりました。だから今まではそういう現場に出会わなかったのでしょう。 ユニットテストがあるので、デグレしていない証明のために全てのテストパターンを手動で１週間かけてやるというようなこともしなくてよくなったわけです。自分の書いたコードが既存の仕様を壊せばJenkinsから通知が来るのですから。

・手動でぽちぽちしてExcelにSSを貼るテストはやらなくなった

ユニットテストを通してあるため、手動でやるのは実際のストーリーに沿ったところだけで済みます。いわいるシステムテストのレベルです。

・総じて、開発時に感じる理不尽さや非合理さは以前より減った

コードで解決できることはコードで解決しようという方針が実践されていて、これがプログラマなんだなぁという気持ちになりました。

２．変わらなかったこと

・残業

リリース前には忙しくなり、帰るのも遅くなります。これは想定済みですし、慣れてもいるので特に所感は湧きません。

・絡まったスパゲッティのようで誰も手が出せないが重要なので使わざるをえないレガシーコード

想像はしていたしまあそうだよね、という感じです。でもそれが問題だと認識する素地があるし、なにかにかこつけてリファクタしたり、あわよくば作りなおそうとしていて大変よいと思います。

・勉強しなくてはいけないということ

覚えなくてはいけないことが多すぎてこれはもはや死ぬしかないのではとと思っていましたが、自分の及ばない部分にまで無理に手を出すのがいけないのだと気づきました。まず今業務で使っているものを理解する、しかしそれを完璧に理解しようとすると死ぬのでほどほどにする。次にその周辺を理解する、しかし完璧に理解しようとすると以下略。さらに流行りもの。しかも完璧に以下略。なのです。スーパーハッカーばかり見ていたので勘違しかけていましたが、普通の人は普通の人なりに生きて行くのがよいのです。

・給料

金額自体はちょっと上がったような気もしますが、かつての銀行系列子会社の福利厚生も考えるときっと下がっているでしょう。

・将来

かつては曲りなりに用意されてたPG→SE→PMというキャリアパスはもはや関係なくなりましたので、将来のことはわからなくなりました。

３．これから

変わったことと変わらなかったことも踏まえて考えると、きっと私はこの転職をしてよかったのだろうと思いました。とはいえ今もあのCOBOLとJava基幹システムやC#とExcelの業務システムを保守している人達がいるのですから、私にはできなかったことをする彼らには敬慕の念が止むことはありません。ただきっと私には合わなかったのなのだろうと思います。それに気づくのに６年かかってしまいましたが。

私は今年で30才になります。とても若いとは言えない年なのですから、これからどういうふうに生きていくのかも考えなくてはいけません。 ただコードを書くだけなら、アルバイトにきている学生の子の方ががよっぽどよくできます。 私はコードを書ける上に、さらに◯◯がわかる、◯◯ができるにならなければいけません。かつてのようにシステムエンジニアだったのなら、それは業務知識だということになっていたことでしょう。会計、流通、生産、在庫。 しかしもはや特定の業種の特定の業務に精通するすべはないし、するつもりもありません。私はコードを書くことでどんな問題を解決できるようになるべきなのでしょうね。 よくあるゼネラリストスペシャリストの区分ならスペシャリストの方がイメージしやすいです。いずれかの技術の領域に詳しい上に、それを自社のプロダクトにどう活かすのか、という考慮ができる人。そのプロダクトがなんなのかについてはきっと限定させない方がいいとは思いますが。

とはいえこれと決めてかかってそれしかやらないのも視野狭窄だと思いますし、日々の興味の先にあるものにしなければ破綻することは経験から学びました。そういう要素になりうるものを日常的に意識しなくてはいけないのだと今では思っています。

あまりハードよりには興味が向かないことが判明してきています。アプリケーションのよい設計とはどういうものか。保守しやすいコードはどういうものか。どんなドキュメントがあるべきなのか。どういうテストをするべきなのか。品質とはどういうことか。そういうことに興味が向いているのかもしれないと思い始めています。おそらく昔苦しめられたから。

でもそれはテストエンジニアになりたいのか、と言われるとと少しちがっていて、私が作ったアプリケーションが不具合や不都合がなくユーザーに対して最大限利益を与えるためにはどうすればいいのか？ということを突き詰めるべきだと考えるのがしっくりきます。 何もかっこよい意識高いアピールのために言うのではないのです。そうすれば、「私自身が最も外部から煩わされない」状態になるに違いないからです。非常に利己的な理由です。だから信じるに値する目標なのです。つまり、これを言葉にすると、「アプリケーション開発のスペシャリスト」になるのかもしれません。一気にうさんくさくなってしまいますが。

ところで転職以前の当時の自分のツイートなんかを見なおしてみると。当時まったくその気はなかったです。なかったののですが。どうみても病んでますねこれ。気づかないものですこわい。 かつて私は、情熱の炎を燃やすために危機感をくべました。だがそれもいずれ燃え尽きるときがきます。そのとき私は何を差し出すことになるのでしょうか。

DirectXSDKサンプルを空のプロジェクトに移す場合のプロパティ設定

DirectSDKについているDirectX Sample BrowserでDirectxアプリのサンプルが見られる。そのコードを自分で用意したプロジェクトで動かしたいときに、どのようにプロパティを設定するか。

例として、Tutorial01:CreateDeviceを、VisualStudio2012で新しく作成した空のプロジェクトで動かしたい場合。

最低限ここをサンプルプロジェクトと同じように設定すればおそらく動く。

http://gyazo.com/0ccbfde17e44130db80f3fc3f809b90c

全般ー文字セット

http://gyazo.com/294fc0f667e4f4c83ff6a6b59b37883b

VC++ディレクトリーインクルードディレクトリ

VC++ディレクトリーライブラリディレクトリ

http://gyazo.com/3622d4ecf21b43de9cbde5bbe6d18bae

リンカー入力ー追加の依存ファイル

Node.js、DojoToolKit、MongoDB、Herokuでアプリを作った話

こちらで公開してます。

http://todo-4-you.herokuapp.com/

ソースはこちら。

https://github.com/arvelt/hello-nodejs

今回使った主なライブラリやサービス

• Node.js
• Express（3.X）
• Passport
• Mongoose
• Mocha
• Supertes
• Dojo tool kit（1.9.X）
• MongDB
• Travis CI
• waffle.io

 

所感

• 最初Expressの最新を使おうとしたらPassportがまだ対応していないのかうまく動かないくてハマったので、古い方をつかうことにした。
• angular.jsじゃなくてDojoを使ってるのは仕事で使用しているので理解を深めるため。DojoはWebページをWidgetと称するビューにして組み立てていく。
• waffle.ioを使ってgithub issue駆動と最小git flowでやっていく。issueをTODOとして使って、対応するissueのfeatureブランチ切って、masterにPR出すということをしていた。ちょっと試したいというときにはdevlopもreleaceもいらないと思う。
• APIに対するテストコードを書いてみる。ちょっと微妙な感じもあるが、テスト時はテスト環境のDBを初期化するようなコードをアプリ自体に持っている。NODE_ENVがtestの場合はDB状態をまっさらでテストできるようにしている。
• Sinonを使ってクライアントテスト書こう！と意気込んでいたが、労力に成果が見合わなくなるのでSuperTestでREST API対するassertを書くことにした。RESTのつもりだけど、違うぜっていうのがあったら教えて下さい。doc.mdに仕様書いてある。というかAPI仕様を書くための標準表記法ってあったっけ。
• Travis CIを使ったことなかったので使ってみた。むしろそのためにテストでっちあげた感じがある。ちゃんとログも見えるしなかなかおもしろい。
• Herokuへのデプロイは手動でひと通り確認したあと、Travisからの自動アップロードへと変更した。全てのプッシュごとにデプロイされてもつらいので、masterへのpushでHerokuへデプロイするようにした。travis.ymlをちょっと変えるだけでそれだけのことができるようになり、かがくのちからってすげーという感がある。
• TravisのCLI がよくできていて、travis setup heroku とかコマンド叩くとHerokuのAPIkeyを暗号化してtravis.ymlに載せてくれるのでほとんど何も気にしないでいけた。魔法かよ。

 

困ったところと解決案とか

• Githubのリポジトリがそのまま使用されるのでAPI key等の秘匿したいものはどうしようかという問題。環境変数にいれようという対応。
• https://github.com/arvelt/hello-nodejs/issues/16
• https://github.com/arvelt/hello-nodejs/issues/17 

 

Dojo tool kitの使い方とか

• attach-pointがdijitオブジェクトにならない問題とか。仕事で使っているときは誰かがすでにやってくれていたので、自分でやってみてわかっていなかったせいで３日くらいハマった。
• https://github.com/arvelt/dojo-widget-load-sample/issues/1 
• dojo/store/JsonRestはレスポンスが必ずjsonオブジェクトじゃないとうまくいかない話。
• https://github.com/arvelt/hello-nodejs/issues/9

Dojo tool kitのdojoConfigについて

ちょっとはまったので。dojoConfigについて。 

javascriptの勉強がてらこういうコードを書き始めている。

https://github.com/arvelt/hello-nodejs

サーバーをnode.js、クライアントをDojo tool kitで書いたTodoアプリ。

dojo tool kitを使用する場合に、dojo.jsというライブラリを読み込む必要がある。

"//ajax.googleapis.com/ajax/libs/dojo/1.9.3/dojo/dojo.js"など外部から読み込むか、dojoが提供するビルドを行い、配布用dojoパッケージを作成するかのいずれかである。

使用する際にはdojoConfigという値にライブラリ自体に渡す設定が行える 。

http://dojotoolkit.org/documentation/tutorials/1.9/dojo_config/

ここで指定したpackagesが反映されていなくてわけがわからなかったのである。

その答え。外部から読み込んだ場合には先にdojoConfigを設定してからでないと機能しない。理屈を聞けばあたりまえだが、もっとわかりやすくなってほしい。

パーフェクトPythonを読んでのメモ

１章−９章が、言語仕様のことについて書いてあるので、まずここを読み込むのがおすすめ。ここで概要を抑えて公式ドキュメントを読むとすんなり頭に入りやすい。

実践的な部分については、「Pythonプロフェッショナルプログラミング」を読むほうが良いかもしれない。

pepsについて

poythonの禅。import thisで読める。

変数、定数について。

論理型、シーケンス型、セット型、辞書型について。

条件文、演算子、ループ、リスト内包表記、例外処理について。

関数について。

クラスについて。

モジュールとパッケージについて。

１０章でコマンドラインアプリケーションについて触れていますが、

pythonのデータ構造をいかに扱うかという点を書いているのでここは手を動かしてみるといい感じかも。

１２章でライブラリとして配布する方法について。大事なものはすでにあるわけで、かゆいところに手が届くようなことを解決するコードを書いたら、ライブラリにして公開したいですね。

これ以降はライブラリの紹介みたいな感じになるので気になるとこだけメモ。

１４章の最初にあるWSGIはWAFの基礎になる気がするのでおさえたい。Djangoとかflaskとかもこれの上で動いてたはず。

趣味プログラミングように１６章のマルチメディア、１７章のネットワーク系をさらっておくと遊べそう。

基本わかってない私は何度も読み返さないといけないと思う。

パーフェクトPython (PERFECT SERIES 5)

three.jsをさわってみた話

3Dに興味あります。そこでjavascriptで3Dに関することを扱うライブラリでthree.jsというのを触ってみました。レンダリングにwebglを使えることが特徴です。コード書いたのだいぶ前だけど忘れないうちにメモ。

○three.js

http://threejs.org/

○three.jsを使って作ったもの

ゲームっぽいもの。すぐに動きます。

https://dl.dropboxusercontent.com/u/19360039/threejs-sandbox/examples/game_avoidblock.html

○ソースコード

https://github.com/arvelt/threejs-sandbox/blob/master/examples/game_avoidblock.html

3Dのあれやこれをあれほどの少ないコード量で書くことができます。3Dのことを全く知らない状態から初めていますが、とりあえず動くものを作ることができました。

○気づいたこと

・3Dがそもそもわからない

サイトならここ

http://wgld.org/d/webgl/w003.html 

本ならこれ

明解 3次元コンピュータグラフィックス

１，２，３章あたりに、コンピューターで3Dを扱うことの体系的な概念が書いてあるので、ほんとうの初学者におすすめ。

コンピューターで2Dとか3Dとかって意味わからんしと思ってたのが、ぼんやりとわかるようになる。

・んでthree.jsで何ができんの

http://threejs.org/examples/

公式サイトのexsample。

http://stemkoski.github.io/Three.js/

three.jsのサンプルを集めたサイト。こういうことやりたいときはどうやんのってときに探しに行くときに眺めると閃きを得たりする。

http://wgld.org/d/webgl/

webglはそもそもなんやねんというのがわからないときなど。体系的に書いてるので読みやすい。

・実際にとるべき手順

１．まず3Dの概念をおぼろげに理解する

２．それらがthree.js上でどう抽象化されているか把握する

３．自分がやりたいことは3D的にどう実現したらいいかを分割する

４．その分割した要素をやってるサンプルを探す。

５．ソースを読んで真似をする

６．コード書く、動かす、デバッグする。

７．４－６を繰り返す。

８．完成！

・まとめ的な

three.jsはシーン、ジオメトリ、ライト、カメラ、レンダリング、を書いていくと完成する。

three.jsはいまだ黎明期であり、バージョン上がれば動かなかったりするようなものがざらにあるので注意しないといけない。

3Dのモデルは形状と表面を分けて考える。

表示するものがないとなにも意味が無いので、3Dモデリングが最も重要。

3Dの本質は数学の世界なのでかつて因数分解でつまづいた私には手に負えない。もし続けていくならば、抽象化したものに対する操作の概念として把握しなければならない。

小さなチーム、大きな仕事(完全版)の読書メモ

小さなチーム、大きな仕事を読みました。サクサク読めていいですね。

１つのことを、自分たちだけでやれ。技術をどうこうというかは、意識を高めてくれる良書です。

内容メモ

現実の世界とは場所ではなく言い訳だ。何も試さないことの正当化だ。あなたには関係ない。

現実と折り合わない計画にしたがうのはもっと恐ろしい。

本当のヒーローは仕事をさっさと片づける方法を見つけ出し、とっくに帰宅している。

すごい製品やサービスを生み出す最も単純な方法はあなたが使いたいものを作ることだ。

中途半端な1つのものよりも、とてもよくできた半分の大きさのもののほうがいいに決まってる。

始めるときは、ディティールは忘れろ。

一番大切なものが残るまで切り落としてそれを繰り返していく。

副産物を生み出していることすら気づかない。だが副産物も売れる。

どういった問題を解決するのか？ほんとにそれに価値があるのか？

睡眠をとろう。

問題を可能な限り小さな要素に分解する。

模倣の問題は理解を飛ばしてしまうこと。

競合の一つ上をいくのではなく、一つ下回るようにしてみる。その代わりそれをうまくやる。

顧客が常に正しいと信じてはいけない。

既存の顧客にこだわり続けると、新しい顧客が切り離されてしまう

偉大な料理人はレシピを公開し料理本を書く。ビジネスも彼らを見習うべきなのだ。

試してもらう。それが顧客にとって手放せないものであるなら、利益を得られる。

まず自分自身でやってみる

限界の時こそ人を雇う、その前の段階ではない。

有能な人でも、必要のない人間を雇うことはない。

顧客と社員の間に人が多いほど、顧客の声は歪んだり失われる。

ポジティブな意見よりネガティブな意見のほうが情熱的にうるさい。

文化とは方針ではない、物や行事や言葉でもない。行動だ。

何でも許可が必要を必要とする環境は、何も自分で考えない文化を作る。社員を子供扱いする必要はない。

書き物が格式高くある必要はない、あなたらしく正直であればよい

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則