レビュアーとして参加したPlay Frameworkのスターターガイド（洋書）が出ました
Packt PublishingのInstant bookというミニ電子書籍シリーズとして、"Instant Play Framework Starter"という本が出ました。
なぜかレビュアーを依頼されて、まともに英語もしゃべれない身でありながらレビュアーとして参加しました。初めてレビュアーとして参加した書籍が洋書ってのも面白いですね。
献本してくれると言うのでそれをもらってからブログを書こうと思ってたんですが、出版から2日経ってもまだ来ないので先にブログを書いてしまいます。。なのでまだ完成品の中身を見てないので、ほんとに僕がレビュアーとして記載されてるかは分かりませんｗ
この本はPlay Frameworkに興味をもった入門者向けのハンズオン形式のスターターガイドです。PlayのインストールからCRUDの作成くらいまでをさらっと学べます。ScalaとJavaの両方に対応しています。
Playって名前は聞いたことあるけど触ったことないなあ、今度の週末暇だから一日遊んでみるか、っていう人に最も適した本だと思います。
価格も日本円にして約600円くらいと安めですし、KindleでもEpubでも読めるっぽいので、英語が苦じゃない方はどうぞ。
Windows系からLinux系にスキルチェンジする方法、って本を書いたら売れないかな
Hacker newsにThe dying platform: .Netという記事が上がってた。
https://news.ycombinator.com/item?id=5711742
元記事はこれ。
http://roundcrisis.com/2013/05/15/the-dying-platform-net/
内容は元記事を読んで欲しいんだけど、.NETってもうだめだよねー、って話。コメント欄には、.NETはエンタープライズとXBOX案件でめっちゃ使われてるけど、みんなブログ書いたりTweetしたりしないから目立たないだけだよ、とか、大体そのような意見が並んだりしてます。
ちゃんと統計を見たことはないけど、まあ.NETその他Windows系のプラットフォームの上で開発している人は開発者全体のうちの多数派だろうなあと言う気はします。どこでどう線引きして分母を採るのかによってだいぶ変わりそうではあるけども。ま多分。
まあただいわゆるWeb系というか、Linux系というか、OSS系というか、な人達のほうがWeb上では声が大きい（Web系なんだから当然ですね！）ので、アレなんでしょなアレ。
でも、Windows系の開発をやってる人が、スキルセットをWeb系っていうかLinux系にしたい、っていう話は聞く気がするけど、逆は聞かないですよね、どうですかね。気のせいかな。
自分は2007〜2008年頃にそれを感じて、スキルチェンジした一人です。それまで2006年くらいまではWindowsプラットフォームの上でC/Sなアプリを書いてたんですが、なんというか技術的な閉塞感を感じてました。SIerではなくパッケージベンダーだったので、受託開発の矛盾とか悲哀みたいなそういう悩みはあんまりなかったんですが。
文化的なものなのか、なんなのか、その会社の社風なのか、分かりませんが、とにかく勉強をしない、技術基盤のアプデートをしないって感じ。
開発環境をバージョンアップするにもライセンス料がかかるから、かなり古い基盤のままずっと固定化してたのが一つの原因だとは思います。また、使ってるミドルウェアに不具合っぽい不思議な挙動があっても、ソースが見られないので調べられないし、そもそもそういう発想ないし、ベンダーに問い合わせすると回答は1,2週間後だし、でそれもサポートに余計に金払ってそれなので払ってないとそもそも回答なんてないし、Webを検索しても使ってる開発環境が古くてほとんど情報は出てこないし、そもそも使ってる開発環境もクローズならプロジェクトもクローズドなのでWebに情報が流れるわけないんですよね。辛かったですね。。
でだ。Web検索すると出てくるのってWebサービスの人たちの情報ばっかなんですよね。Linux前提の話ばっか。Windows系の記事なんて、ほとんど見たことない。たまに見つけてもバージョン新しすぎる。どこの新世界やねーんって感じ。
2007年にTwitterが流行って、それの影響かしらんけどRailsの話がめっさ世に流れてくるようになって、2008年頃にGoogleAppEngineが出て、Java対応始まって。AWSも噂には聞いてたけど、これくらいの頃に本格的に日本に上陸した。あー、クックパッドもチョー流行って、あれRailsらしいよマジでー、みたいな話し聞いたのもこのころだった気がする。
これらのサービス、ぜーんぶ、Linuxの知識を前提にしてるねん！ コマンドラインやねーん！！ そもそもRubyはWindowsの上ではまともに動かないねーーーーん！！*1
と思わずエセ関西弁で叫びたくなるくらい、あー、おれのスキルセットの場違い感というか時代遅れ感というかレガシー感、すげえ、って思ったわけです。あのころ。
Windows、10年くらい経つとメインフレームっぽい立ち位置になるんじゃねこれ、とその時おもたわけです。消えはしないけど、っていうか、業務システムがこの上でめっちゃ動いてるから消せないけど、ずっと現役ではあるけどまったくもってヒップじゃない、みたいな。
で、2007年の末ごろから、スキルチェンジを図りました。だってそもそもWebにあふれてる記事が読めない。WEB+DB Pressとか何書いてあるかわからん。なんか記事中に普通にコマンドライン出てくるんだけどこれ怖くねーみたいな。いやまあ仕事でHP-UXくらい触ってたからまあ多少は分かるわけですが、仕事の割合的には数％なんですよねそれ。なのでコマンドラインに対する違和感みたいなのはすっごくありました。え、なんでいまどきコマンドライン叩かせるの、みたいなね。
仕事帰りに毎晩机に座って、Linux関連の書籍、Web記事を穴の開くほど読んで動かして、ってのをやりました。会社から帰ってくるの、21時〜22時なので、そこから深夜3時くらいまで毎日。GoogleAppEngineいじってTwitterBot作ってたのもこのころ。そもそも、自宅にはWindowsのマシンしかなかったので、アキバで適当なマシン買ってきてLinuxインストールするところからやってました。
で、その後5年くらい色々会ってまあ今WEB+DB Pressに「前からWeb系でしたよ」みたいな顔して記事書かせてもらったりしたわけですが。
この話のオチは何かっていうと、そういうWindows系のスキルセットから、Linux系のスキルセットに変えたいって思ってる人いっぱいいるんじゃないかな、そういう人たちに向けたスキルセットチェンジ法を本にしたら売れるんじゃないかな、ってことが言いたかったのです。
どうすかね。
*1:今は良くなったっぽいけど詳しいことは知りません
藤田晋氏の本を2冊読んだ
最近Kindleづいていて、立て続けに2冊読んだ。
どちらも面白い。渋谷ではたらく〜 の方は藤田さんが史上最年少で上場（当時）したニュースを大学生の頃（就活の時期だったかな？）に見て、ほぼ同年代なのに差をつけられた感じがしてすごく悔しかったのを覚えてて、楽しく読んだ。
起業家 の方はサイバーエージェントが広告代理店からWebサービスの会社に生まれ変わろうとして四苦八苦していた頃の記録で、これも面白かった。
当時、自分の親しい友人が営業としてサイバーエージェントに中途入社してたので、彼女が入ってた頃はこうだったのかーと思いながら読んだ。彼女は2年経たないくらいでやめたけど。営業っぽい社風と一日に数百通来るメールが嫌だと言ってたなあと。うろ覚えだけど。
その当時、彼女が「藤田社長はサイバーエージェントを技術の会社にしようとしてるけど、うまくいく感じしない」といってたのをうっすら覚えてたので、そういう意味でも楽しく読めた。
今やすっかりサイバーエージェントは技術とWebサービスの会社ってイメージですね。変われば変わるもんだなあと。
ところで、Kindleって読みやすい買いやすいで超やばい。
脆弱性パッチあてろよとかフレームワークのバージョンアップしろよとか
http://www.jins-jp.com/info.html
これ、大変ですね。
保守契約がどうなってたのか、当初見積りにフレームワークの脆弱性パッチ適用作業費用は入ってたのか、顧客はそもそもこう言うことが起こり得ることを予見していたのか。
営業から保守費用が高すぎるって言われて仕方なくこういうところを削った見積り書いて営業に渡して、顧客とちゃんと確認してねみたいなこと伝えて、営業は本質的なことは理解してないから顧客には説明せず、顧客はベンダーに全て任せてるつもりだから気にもせずみたいな。
この手の作業って基本は大した工数にならないはずなんだけど、場合によってはパッチじゃすまずフレームワークのバージョンアップしないといけなくなって、つまるところアプリケーションコードの書き換えが発生したりなんかして、工数跳ね上がっちゃうリスクあるので、保守費用としてはある程度多めに出さないといけないし、この手の作業を間違い無くやれるまたはこの手のバージョンアップでアプリにどう影響が出てどの程度工数使うかがわかるような人って、そんなに稀少種ではないけど、かといってわんさといるわけでもないよね。
SIだと顧客の数だけこの手の作業とリスク管理しないといけなくて、顧客の数だけこれができる要員確保しようとすると大変だし、この手の人をPMOとかアーキテクトとか言うプロジェクト横断な人として持っておく手もあるけど往々にしてそういう人ってエースプログラマーでもあったりするしSEとしても出来る人だったりで特定案件に張り付いてたりして、うまいこと行かないですよね。
何が言いたいかっていうと、SI大変だなあと。
パッケージやらSaaSやらにして、メンテ対象を一箇所に集約したほうがベンダーにも顧客にもメリットあるし、レバレッジきくよね。価格も下げられる。
顧客ごとのカスタマイズはAPI使ってやればいいし、できればカスタマイズしなくていいように機能を作りこみたいよね。そのほうが安く済む。それでもダメならAPI使ってサードパーティさんに作ってもらおう。
そう言うのは難易度高い？ 予算がない？ セールスフォースはやってるしシャノンもやってるし、シナジーも三三もやってるしヌーラボさんもやってるし、みんなやれてるよこわくない。
【備忘】SublimeText2のパッケージリリース方法
自分のための備忘です。細かいところはかなり端折っているのでそのツモリで。。SublimeText2のPackageControlはGithubにtagを作ればいい感じにリリースしてくれる仕組みですざっくり言うと。
手順
コード書く、またはPullRequestをマージする
Githubのマージボタン押したくないときは一旦手許に持ってくる。
# 適当にブランチきっておいた上で。。。
$ git pull origin pull/x/head
テストする
package.jsonを書き換える
URLの末尾とversionを最新のバージョン番号にする
last_modifiedも書き換える
{ "schema_version": "1.2", "packages": [ { "name": "Scalariform", "description": "The wrapper of Scalariform - scala source code formatter", "author": "ikeike443", "homepage": "https://github.com/ikeike443/Sublime-Scalariform", "last_modified": "2012-11-12 17:15:00+09:00", //<- ここも "platforms": { "*": [ { "version": "0.3", //<- ここ "url": "https://nodeload.github.com/ikeike443/Sublime-Scalariform/zip/0.3" //<- ここ } ] } } ] }
pushする
最新バージョン番号でtagを作る
$ git tag -a x.x -m "x.x released" $ git push origin --tags
tagを間違った場合でそのことにすぐ気づいたなら一回消して作り直す
$ git tag -d x.x $ git push origin :refs/tags/x.x $ git tag -a x.x -m "xxxx" $ git push origin --tags
退職しました
去る4月12日（金）を最終出社日として、3年とちょっとお世話になった株式会社シャノンを退職しました。退職しました、と言っても退職日は5月31日ですので、それまでは一応シャノンの社員ではありますが、区切りということでご報告いたします。
シャノンでは割と自由な立場で色々やらせてもらっていました。シャノンは企業向けのマーケティングSaaSを提供する会社です。提供しているSaaSは、お客様の企業サイトやキャンペーンサイトの裏側を支えるようなサービスですので、あまり表に名前が出ることはないのですが、実は地味にシェアが高く、世の中で行われている企業向けセミナー、イベントの結構な割合がシャノンのSaaSを使っています。僕もプライベートで技術カンファレンスやビジネスセミナーに申し込みすると、シャノンの申し込みフォームが出てきたりして、ここもうちなんだ、みたいに感じることが多かったものでした。
シャノンでやったこと
そんなシャノンでの3年間で、僕は主に下記のようなことをやっていました。
SDKの開発、APIドキュメントの整備とトレーニング、サポートなど
シャノンはRESTfullなWeb APIを持っています。Flickrなんかと似た認証API（pre-OAuthって感じの仕様）も早い時期から持っていました。
このAPIを外部の方がスムーズに使えるように、サンプルコードのセットを作り、ドキュメントを整備し、SDKとしてまとめる仕事をしていました。またお客様サイドのエンジニアさんやサードパーティベンダーさんたちにトレーニングをしたり、技術的なサポートなどもしていました。
新製品の開発
上記の仕事と並行して、新製品の開発も行っていました。自分自身でコードを書いたものもあれば、プランとデザインだけを行ってメンバーに書いてもらったものもありますし、パートナー会社さんと開発したものもあります。リリース出来たものも出来なかったものも、色々あります。
node.jsを使ったWebsocketなサービスも作りましたし、Play1+Javaなサービス、Play2+Scalaなサービスも作りました。
技術ブログの立ち上げ
シャノンに入社して一年経ったころに立ちあげ、ちょっとして開発環境について書いてそこそこのブクマをもらいました。その時のエントリがこれです。
やはりシャノンは小さい会社で、知名度もほとんど皆無であったため、できるエンジニアの採用にとてもとても苦労していました。
シャノンは会社の規模にしてはエンジニアの粒がそろっていて、取り組みも面白いものが多かったので、それをそのまま伝えていけば採用に好影響があるんじゃないかと思って始めたものです。
効果はとても大きく、このブログをきっかけにして応募してくれた人、入社を決めてくれた人、がたくさんいます。その人たちが今のシャノンの中核を担ってくれています。
もちろん上記の各々は僕ひとりでやった仕事というわけではなく、上司や同僚、チームメンバーのみんなの協力が合ってこそです。本当に感謝しています。
シャノンはエンジニアの職場としてオススメですか？
Yes!
エンジニアが正しいと思ったことを推し進めやすいいい環境です。
なにげに、Scala, Github, PivotalTracker, Jenkins, Herokuみたいなあたらしめのモノを使って開発している会社ですし（細かいところは部署によって異なります）、エンジニアがいいと思ったものはかなり積極的に採用していく会社です。今挙げたようなツールやテックスタックの選定はもちろん、機能や製品の企画など、提案すればどんどん採用される風土があります。（もちろん相応の責任が伴いますが）
色々やってみたいことがある人にとってはいい職場だと思います。
退職の理由
一身上の都合ですｗ
ただ、色々なタイミングが重なって、次の職場とご縁があったという感じです。
上記に挙げたAPIのSDK開発やサポートの仕事をしていく中で、プラットフォームを作り、サードパーティのエコシステムを作り上げる仕事に魅力を感じ、もっと大きなプラットフォームでこの仕事に専念したい、と思ったことがきっかけではありました。
次はどうするの
決まっています。6月1日から次の職場です。詳しいことはその時にまた改めてご報告します。
有給長くね？ なにするの
実は書かないといけないものがあり、一ヵ月半ずっと、執筆にかかりきりなのです！
でも飲みにはいけるから、誘ってね！！
