エンジニアが知っておくべき複式簿記というシステム
っていうタイトルでなんか書くと面白いかなと思ったのでいつか書くかも。。意外と財務諸表読めないエンジニアって多いよねと思い。簿記知ってると読めるのかっていうとそんなこともないんだけど、助けにはなりますよね。
簿記は世界最古の情報システムと言ってもいいもので、結構面白いので暇なときに学ぶと楽しいと思います。エンジニアの人なら簿記システムの理解はすぐだと思います。会計の話になると覚えないといけないことが多くて辟易するけど。
エンジニアのための会計入門、みたいな本は結構出てるんですよね。
でも、エンジニアにとって面白いのって、複式簿記という良く考えられたシステムのほうだと思うんだよね。これが500年くらい前にできたってのはほんと信じがたい。ユダヤ人（が発明したと言われてます）すげえ。
レビュアーとして参加した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
