ikeike443のブログ

ソフトウェアビジネスに関心がある系のブログ

脆弱性パッチあてろよとかフレームワークのバージョンアップしろよとか

雑記

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日から次の職場です。詳しいことはその時にまた改めてご報告します。

有給長くね？　なにするの

実は書かないといけないものがあり、一ヵ月半ずっと、執筆にかかりきりなのです！
でも飲みにはいけるから、誘ってね！！

SBTメモ：Scctの並列実行を止めるには

Scala sbt

下記のように設定するといいらしい。社内のPull Requestレビューしてて知った。多分動くよ（試してないけどね！）。

parallelExecution in Scct := false,
parallelExecution in ScctTest := false,

備忘

雑記

アジャイルがダメだと思う7つの理由

この記事を読んで、特に1番を見て感じた違和感をTweetしました。備忘。









スクエニがドラクエのリリース計画をコミットしたことがあっただろうか。してほしいけど。

sbtとJenkinsを使ってMavenリポジトリへ成果物をパブリッシュするのってどうするのが正しいの

ですか？


Mavenでビルドしているなら、ジョブ作成の時に「Maven2/3プロジェクトのビルド」を選択してやれば、ビルド後の処理として「Mavenリポジトリへ成果物をデプロイ」が選べますよね。
f:id:ikeike443:20130124184451p:plain


sbtでビルドしている場合は「フリースタイルビルド」で作らざるを得ず、上記の機能が使えません。

その場合、ビルドの「シェルの実行」にて下記のように指定すれば、testが成功した時だけpublishが実行されるようにできます。これでだいたい同じ事ができますね。

JAVA_HOME=/usr/java/default/ /usr/bin/sbt clean scct:test publish

一行で書くのがミソです。sbt publishを単体で実行すると、testの成功／失敗に関わらずpublishが実行されてしまうのでまずいです。