第33回 長岡IT開発者勉強会に参加して感じたこと #nds33

第33回勉強会(2013/09/28) Scala入学式 - 長岡 IT開発者 勉強会(NDS)
久しぶりにちゃんと参加しました、NDS。
今回は、Scala入学式ってことで、意外にも静的型付け言語がメインです。
私が参加した会では、大体PerlやRubyさんたちのような動的型付け言語が主流だったのでNDSって奴はそういう会だと思ってたのですが、静的型付け言語＋IDE使用と来たもんです。事前準備のIntelliJ IDEAのインストールに「げっ」と思った人は少なからずいるのではないでしょうか。

勉強会自体は、猫型先生(@neko_gata_s)さすが、という感じでした。
若い開発者の心を鷲づかみにする技はとても真似できません。*1
ただ、私はbotの写経の早い段階で躓いてしまい、声を上げるのも憚られたので大人しくしてました。
他の人たちは何事も無く終わって「ガッ」してたので、これが若さか...とか勝手に寂しがってたのは秘密です。

静的型付け都市
ニー型！！！！！

圏論都市
ニー型！！！！！

熱いじゃないですか、Niigata。
静的型付けは面倒なことも多いかもしれませんが、強力なパートナー『IDE』がいます。
IDEの機能を使って、他人の書いたclassやメソッドも追いやすくなりますよ。
どこにあるかすぐに見つかりますよ。
そのソースコード、自分が死ぬまでメンテするわけでもないでしょうに。
IDE使うとPCが重い？メモリを積めばいいじゃない！PC買い換えればいいじゃない！
時間は金で買うんです！*2

LTも個性的なものばかりで、大いに楽しませてもらいました。
開発してて楽しければ使う側も楽しいものになりやすいでしょうし、東京とかの仕事を持ってきて受託開発やるだけじゃなくて、新潟からのサービス立ち上げに力を入れていけば技術好きな人もこっちに残ったり、来たりしてくれるんじゃないかなーと。

毎度のことながら、NDSに参加した後は新潟に元気のある人いっぱいいるよなーと感じます。
この勢い、県内の他の業界にも波及できたらもっと良いですよねー。

*1:そっかーゲームかー。下手なオブジェクト指向を解説する教本よりも楽しく深く学べます

*2:まぁ、IDEに限った話じゃありませんが

現場で役立つCSS3デザインパーツライブラリ

現場で役立つCSS3デザインパーツライブラリ

こういうのはネットで収集するべきなのかもしれませんが、そこまで手が回らないって人にまとまった情報として読むことができるので、お勧めだと思います。
今どきのWebアプリを目指すには抑えといて良いかもしれません。

特に業務用アプリって、「見た目よりまず動くこと」になりがちで、見た目は特に指定が無ければダサいものになりがちだと思うんです。
「俺、デザイナーじゃねーし」って心のどこかで思っているデベロッパも少なからずいると思います。でも、それは甘えかも。
確かにデザインまで口出しできる状況にならないこともあるかと思いますが、使う人は、内部ロジックがいかに優れていようともUI/UXで評価してしまうことが多いのも事実です。見た目にちょっと気を付けることで評価が変わってしまうことも大いにあると思いますよ。

素のCSSを使っているので、使っているフレームワーク関係なく導入できると思います。自分で思うようにカスタマイズすることもできるので、知っておいて損はないと思いますし。
っていうかCSS3の表現力はすごいなー、と今更ながら思います。

凝ったデザインにしなくても、多少の手間で見栄えを良くする為のヒントが乗っている良書です。ちょっと言い方は強引ですが、所詮見た目なのでブラウザによって多少見た目が崩れても大した問題じゃないことも多いですし。*1
価値あるシステム*2の為にお手元に1冊いかがでしょうか。

あわせてよみたい

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

*1:特にIEっていうやつ

*2:と思わせる

SSL + Apache HttpComponents + ファイルアップロードで嵌ったことなど

相も変わらず、Javaを書き続けております。
今日は、そんな中でのお話。

公開しているサーバにファイルをアップロードするバッチ機能を実装する機会がありました。
ブラウザから呼び出すのと同じように、multipart/form-dataでリクエストを投げてファイルを登録する方式です。
Apache HttpComponents(4.2.3)を使って実装することにして、検証用サーバ(http)に対するファイルアップロードは問題なく実装できました。あ、まだ技術者としてやっていけるじゃん、俺。

本番サーバは当然のことながら通信経路の暗号化がされています。
接続先の変更のみでうまくいくことだろうとタカをくくり、余裕ぶっこいていたのですが・・・。
リクエストパラメータが、nullになってて、登録できません。

正確に言うと、ファイルデータとともに、必須項目でid的なものとか付帯情報もリクエストパラメータに乗せてたのですが、
そのidが設定されていない、とvalidationのエラーになってしまいました(ファイルデータもnull)。
そのidも、サーバに問い合わせて取得するようにしており、そこに至るまでにデータのやり取りを行っている為、
バッチ機能のリクエストがすべてnullになっているわけでもなさそうです。

前述のとおりhttpであれば問題なく動作します。また、httpsでブラウザから同じリクエストを送信しても登録できます。
SSL + multipart/form-data + HttpComponentsの時に思った通りに動かない？

頼みのgoogle先生からも有効な情報を見つけることはできませんでした。
ブラウザからのリクエストとHttpComponentsからのリクエストの差異から、
cipher suiteがAES128-SHAだったりDHE-RSA-AES256-SHAだったりしてたので、もしかして、
この辺を変えなきゃいけないの？と思って調べてみたりしたのですが、有効な情報は得られず。
ブラウザでは動作しているからApacheの設定ってわけでもなさそうだし・・・。

とまぁ、打つ手がなくなってきて「httpだけどhttpsを使っていると言い張ろう*1」とよぎりましたが、
罪悪感もあり、どこまでリクエストが来ているのか検証してみようか、と思いとどまることにしました。

その結果、
SSL + multipart/form-dataで送る時、ファイル情報だけ送れば想定通りに送れる
ことを確認。

それに対する理由を調査するのも骨が折れそうだったので*2、そうとわかれば話は早い。
1回のリクエストでファイルと登録に必要な情報を送っていた箇所を、
登録情報(POST)でSessionに格納し、その後ファイルのみ送信する(multipart/form-data)、の2回に分けて送るように修正し、思った通りに動作するようになりました。

もしかしたら、Apacheの設定とかだったんでしょうか？Javaだから嵌ったの？*3（未だに）S2使ってるから？
あの・・・誰か知っている人いたら教えてください。

*1:もうコイツ技術者とは言えない

*2:もうコイツ技術者とは言えない

*3:被害妄想

SQLアンチパターン読了 #sqlap

SQLアンチパターン

買いました＆読みました。開発者であれば読んで損はない良書です。っていうかシステム開発で対価を頂こうって人は読みましょう。
まだまだRDBMSのシステムは無くならないでしょうし、生み出されていくと思われます。転ばぬ先の杖としてこの本の情報があると「あの時ああしとけば良かった」と悔やむことや後任の担当者に恨まれることが少なくなるでしょう。

システム開発を長いことやってて修羅場を経験している人にしてみたら新しい驚きはないと思います。なので、こういう「べからず集」は、情熱はあるけど経験の少ない人にこそ読んで欲しいと考えます。
先人たちの過ちを自らも経験して学ぶ、というのはあまりにも時間がもったいない。
「若いうちの苦労は買ってでもしろ」とは言いますが、誰も経験したことのない苦労をすべきであって、誰かがした苦労は避けた方がいいと思うんです。時間は有限ですもの。失敗から学ぶことは多いですが、すべて体験しなきゃいけないかというとそうでもない（ハズ）。

この本には、誰かがした苦労がたくさん詰まっています。これを読んだ人は少なくともこのような問題からは避けられるはずです。*1
違う問題に遭遇して頭を使うようにしましょうよ。

システムは作って終わりでなく、作ってからがスタート。仕様変更もバシバシくるわけです。本書にはそんな時にも対応できるようなノウハウがたっぷり詰まってます。場当たり的な対応でその場はしのげてもいつか帰ってくるんだぞ、ということが垣間見えるのではないでしょうか。*2

あと、個人的な意見ですが、DBを使ったテストはSlow Testsになりますが、やっておいて損はないと思います。Mockを駆使して使わないようにするのも良いですが、最終的にRDBMSから取得するデータが違ってたら意味ないですし、カラム変更によってデグレっても気づきにくいですしね。結合して始めて「あらら」とならないようにしましょうね。少しでも複雑だなぁと思ったSELECTは自動化の対象にしましょうぜ。

*1:間違った方向に進めようとする上司を説得するネタ帳としても有効ですｗ

*2:まぁ、いい加減な対応をした人に必ず帰ってくるわけでもないってのが世知辛い世の中ですが

Eclipse+Maven+Tomcat7+複数プロジェクトな環境を作る

表題の環境(Seasarプロジェクト使用)を作ろうとしてたんです。

[入れるもの]
Eclipse 4.2
m2eclipse
sysdeo-tomcat 3.3(Tomcat7を使用したいので)

[忘れちゃいけない]
ふたがわさんのDevLoader改変モジュール

で、Tomcatプラグイン／プロジェクトの設定をして、EclipseからTomcatを実行したのですが、java.lang.VerifyErrorが投げられて実行できません。
よくよく調べてみると、Tomcat7用のDevLoaderがあるみたいなので、そちらを使ってみますが・・・。
改変部分が無いからClassNotFoundExceptionが出ます。さらに、.#webclasspathに記述されるpathの中でプロジェクトを参照している箇所がフルパスで記述されていませんでした。むー、動かないー。

で、作ってみた

誰かが作ってくれるのを待っててもしょうがないので、作ってみました。ベースはTomcat7のDevLoader。
https://github.com/nemuzuka/tomcat7-devloader-ex

使い方

ビルドした、devloader7-1.0.0.jarを$TOMCAT_HOME/libに配置して下さい。(元々のDevLoaderは不要です)

除外処理は、ふたがわさんの部分を丸パクリ拝借しました。
$TOMCAT_HOME/confにdevloader.confを配置すれば追加で除外設定をします。

プロジェクト参照に関しては、
$TOMCAT_HOME/confにreferencePath.confを配置します。
指定内容は、
[参照プロジェクトまでのpath,プロジェクトの出力ディレクトリのpath]
を指定します。

例えば、参照プロジェクト(app-common)が、
C:/eclipse/workspace/project
ディレクトリに配置されていて、出力ディレクトリがEclipse上で
/target/classes
と設定されている場合、referencePath.confには、

C:/eclipse/workspace/project,/target/classes

と記述します。
LoaderがLoadする際に、
C:/eclipse/workspace/project/app-common/target/classes
をクラスパスに追加します。*1

情報が見つけられなかったので無駄に頑張った気もするのですが、もっと他にいい方法があれば、教えてください。
ってか、みんなはTomcat*2で開発してないのかなー？

ちなみに

上記モジュールはTomcat7用ですが、sysdeo-tomcat 3.3でTomcat6を使う際にも同様の問題が発生したので、上記処理を組み込んだものも作成しました。
https://github.com/nemuzuka/tomcat-devloader-ex

*1:複数行指定可能で、先頭行から順番にディレクトリが存在するまで繰り返します

*2:というかそもそもJava？

成果発表

持て余した時間を、子供の相手もそこそこに、個人的なアプリ開発に費やしてました。
もう飽きた見せてもいいくらいになってきたのでお披露目しようかと思います。

Mishima

夏前から作ってた、GAE/Jで動作するITS。スマフォ用画面もあります。
サイト
ソースコード

Yoita

LL言語も嗜んでみようと思いたち、RoRでつくってみたスケジューラ。Facebook連携とかやってみました。Heroku上で動作。
サイト
ソースコード

Koshiji

家にあるスケジュールボード的なものをイメージして、（主に家族間の）メッセージのやりとりができるようにしたかったんだけど、ごちゃごちゃしてきてわけがわからなくなりました・・・。GAE/Jで動作します。
サイト
ソースコード

基本的にサーバからJSONでデータ貰ってjsでレンダリングしてます。新し目のブラウザであれば大きな問題は無いと思います*1。この方式にもかなり慣れてきました。
GAE上で動作するアプリはGoogleアカウントが必要ですが、デモサイトもあるので動かしてみて感想を頂ければ嬉しいです。

*1:IEは気にしてません

第28回 長岡IT開発者勉強会に参加してきた #nds28

9/22にNDSに参加してきました。
「スーツvsギーク討論会」というテーマでディスカッション形式でした。勉強会でディスカッションってめずらしかったです。皆さんが現在に至るまでの経緯の違いからか、伝えたいことが伝わらず歯がゆく思うこともありましたが、最終的に「ゴールは一緒なので協力しましょうよね」、という落とし所になってよかったと思います。こういう話でムズムズしている人は、社内でやってみたらいいのに、と思いました。そっちの方がわだかまり少なくなると思います*1

僕の勝手なイメージからすると「スーツ」「ギーク」って、自分に壁を作っているだけだと思うんです。僕は「スーツ（ギーク）」だから「ギーク（スーツ）」の話はわからないと言っているように思えて。「俺がこんなに頑張ってるのに報われないのはギーク（スーツ）の奴らのせいだ」って言いやすくしてるだけじゃないかな、なんて歯がゆく思ってましたが、今回の人たちはそうではありませんでした。本当に「できる人」ってのは両方の素養を持っている人なんだろうと思ってまして、私もそうありたいと常日頃考えている次第です。ギークだってコスト意識持つべきだし、スーツだっていつまでもStr◯tsベースの自社フレームワークを使いまわしてシステムを開発することに疑問を持つべきです。*2

僕の話になりますが、仕事である以上気が進まなくてもやらなければならないことが往々にしてあります。そんな中でも自分が選択し決定した中で仕事をして少しでもモチベーションを高く維持したいと思った時にはプライムで仕事をするしかないと思い、技術だけでなくマネージメントの勉強もするようになりました。技術だけだと結局マネージャに良いように使われる、マネージメントだけだとデベロッパーに嘘をつかれても気づかない、と思ったからです*3
他人が頼りないなら自分がなってやるという選択肢もあると思います。それを放棄するのなら状況はきっと変わらないし、押し付けられたと思いながら言われたことをやるしか無いと思うんです。お互いの話が（納得できなくても）理解できるような人間になりたいなぁ、と思ってます。

今回の勉強会は学生さんの参加が多かったので意味がわからないことも多かったと思いますし、必要以上に怖がらせたこともあったと思います。若干煽ってしまった感があります。ごめんなさい。ですが、SIとWeb系でのビジネスの違いはあれど、開発に携わってお金を貰う以上、一人でやるのでなければこの手の話は出てきます。すでにお金を払う人がいる時点で一人じゃないですしね。それに、閉じられた世界で気の合う仲間と仲良くビジネスをする、というのは現実問題無いでしょう*4。それだけ、お金を稼ぐというのはシビアなんです。

ただ、今までの技術的な興味が「プロジェクトの成功率を上げる」ことから始めていたのですが、純粋に「楽しいからプログラムする」ということからこともしてみたいなーと思うようになりました。静的言語は最近の他人からは敬遠されるのかな・・・。

勢いで描いたLT

NDS#28 SIerの未来 from Kazumune Katagiri

*1:決裂しても責任は取れませんがｗ

*2:JDKも新しい奴に対応しましょうよ！

*3:まぁ、無条件に他人を信じれない性格なんですよね。で、まぁ、どっちから見ても使いづらい中途半端な社会人ができあがってしまったのですがｗ

*4:あったとしてもそう遠くない未来に破綻するんじゃないかな