広く公開された市場の罠

中間業者を中抜きすると受発注者はWin-Winになるか? 事例:クラウドワークス - @ledsun blog

 

結構前の記事ですが、今更ながら読みました。

中間業者なしで、お客さんとエンジニアが直接契約するようになった結果、どうなるのかという話です。

参入障壁が低い->新規参入者の増加->受注価格の低下->受注者、発注者ともにレベルが低下

となり、エンジニアは幸せになれないという結論でした(若干端折ってますが)。

 

この話でまっさきに思い出すのが、「アタリショック」ですね。

供給過剰により、悪貨が良貨を駆逐してしまうという現象です。

 

広く公開された市場でかつ、市場参入者のクオリティがある程度維持されていないと、

結局こうなってしまうんですよね。なんでも。

で、これって別にクラウドワークスだけの問題でもなくて、

今勢いがあるフリーランスエンジニアのエージェントも同様じゃないかなって思うんです。

「使えないエンジニアをどうやって現場に送り込むかが営業の腕の見せ所」

なんていう言葉を聞いたことがありますが、こんなことをしていると、いつかクラウドワークスの二の舞になりそうです。

自分もフリーランスで仕事をしているので、ひとごとではないですが、

いまのところは、某企業の経済圏内で仕事を受けており、上記のような悲惨な目にも合わず、もう少しはご飯が食べれそうです。

 

 

 

 

 

 

 

 

 

JSFの落とし穴

とあるプロジェクトで、JSF2.2(Myfaces)の技術検証を行っているのですが、ステートフルであるが故の落とし穴がありということに気づきました。

JSF2系で登場した便利な機能も非機能面で深掘りをしてみると、うーんそういう動き方をするのね というところがあります。

 
例えば、ViewScoped(javax.faces.view.ViewScoped)なバッキングビーンは、別Viewへ遷移時にインスタンスが即破棄されていると思いがちであるが、実はそうではないらしいです。
myfaces+weldで試したところ、即時削除はされなかったです。
インスタンスの最大数が決められており、それを超えた場合にLRUで削除される実装になっていました。
なので、複数タブを開いて、何回か画面遷移をしてしまうと、古い片方のタブのViewScopedなビーンが削除されてしまいます。
この動きはviewstateも同じで、古いものから削除されるので、複数タブで画面遷移を行っていると、片方のタブのviewstateが削除されてしまい、ViewExpiredExceptionになってしまいます。

 

あ、これは、SAVING_STATE_METHODがserverの場合ですね。

clientであれば、viewstateはclientに保存されるので、知らぬ間に削除されてしまうなんてことは起きません。

 

JSFの肝である、ステートレスなHTTPを無理やりステートフルに見せかけるという手法はやはり限界があるのかもしれません。

 

 

 

はじめてSalesforceやってみた感想

ここ約半年間くらい、はじめてのSalesforce案件に参加していました。
20人月くらいの受託案件でしたが、フルスクラッチの案件と比べて、
良いところ悪いところ色々と思うところがあり、雑多ながら感想を書いてみようかと思います。

 

Javaが分かっていればすぐ慣れる
開発言語のApexがほぼJavaですし、画面作成用のVisualforceという技術はどうみてもJSFです。

・短納期、少人数の案件が多い
みたいです。
少人数ですので、お客さんと話ができて、設計もできて、プログラミング・テストまで一人でできちゃう
様な人じゃないとやっていけなさそうです。
プログラミングしかできませんみたいな人はいらなさそう。

・はまる要件だと非常に簡単にアプリケーションが作れてしまう
標準画面のカスタマイズでほぼできちゃうような案件だと、ほぼプログラミングなしで
開発できちゃうので、フルスクラッチの開発と比較すると低予算で作れちゃいます。
エンドユーザ自身でもカスタマイズできるあたりも良い点。

・大量データの取り扱いが面倒くさい
データストレージ容量と、ガバナ制約の二つがネックで非常に苦労しました。
Saleforceではライセンス数に応じて、ストレージ容量が割り当てられるのですが、
大した容量ではないので大量データを扱うとすぐに使い切ってしまいます。
追加でデータストレージのみを買うこともできるのですのが、これも非常に割高。
またそもそも、プロジェクトの途中でストレージ容量が不足していることが判明して、
追加ストレージが必要になった場合、だれがそのお金を払うの? ってことも問題になってしまうので、
できるだけ早い段階でデータ容量のサイジングをしておかないと困ったことになってしまいます。

あとはガバナ制約。一度に更新できるレコード件数が1万件なので、一括でデータをリペアしたい場合、
非常に面倒です。
100万件のレコードの制御用のフラグを一度に変更したい場合、RDBならUpdate文を一回投げれば終わりですが、
そんな簡単にはいきません。1万件ずつ更新するか、DataLoaderというツールを使用して、CSV Export->Updateを行うしかないです。
やれないこともないのですが、ただのフラグの更新なのに面倒な手順を踏まないといけないあたり、
非常に腹立たしいです。

・まとめ
ほぼ標準画面のみで開発できる案件なら、かなり強力なプラットフォームかなと思いますが、
逆にあまり向いていない大量データやら、標準画面がほぼ使えない案件だと、
あんまりメリットないかもなぁ的なところもありました。
とりあえず、はじめからSalesforeありきで導入するものではないなと。
業務要件として向いていると判断したのなら導入すればいいんじゃないでしょうか。

 

ORMの使い方

ORM についてこんな記事がありました。

典型的なORMあるあるですね。


あなたのORMの使い方は間違っている

 

特にN+1問題は厄介ですね。

自分が携わったHibernateを使っていたプロジェクトでは、一画面表示するのに数百回クエリを発行してたりするのもざらでした。

関連はとりあえず Lazy にしておいて、検索時に関連の取得が必要であるならば、

出来る限り join fetch でもってきてあげるべきだと思うのですが、

「join fetchってなーにー」というレベルの人が大半だったりするプロジェクトもあったりするのも多いのでさらに厄介です。

まぁ、まともに使うためにはある程度のお勉強が必要ってことですね。

そんなことを考えると、じゃあ別なフレームワークのほうがいいんじゃねってことになるんですが、

現代の一般的な SI プロジェクトでは何を使っているんでしょうねぇ。

やっぱり S2Jdbc とかいまだにおおいのかなぁ。

 

 

 

 

 

TDD is dead. うんたらかんたら

DHHがこんなこと書いてました

 

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

 

翻訳もされてました

 

http://d.hatena.ne.jp/yach/20140424

 

TDDがだめというよりは、TDD原理主義者どもがうざくてしょうがねぇ

ってことでしょうかね

 

 

Specification By Exampleの読書中(6)

間が空いてしまいましたが、前回の続きです。

Chapter6の後半部分の要約です。

どうやって周りの人間を巻き込んでいくかみたいな話です。

開発者、ビジネスアナリスト、ステークホルダーが協力していくために

どうやればいいかについてです。

やはり重要な部分なのか、この章は若干長いです。

SBEに特化した話ではなく、一般的な上流工程テクニックのようなきもしますが、

SBEではなおさら重要なのでしょう。

 

受け入れテストを書くときに開発者を巻き込む

開発者を巻き込まないと、彼らは機能を実装するのにもっと時間を費やせるようになる。

これによって、仕様に実装に必要な情報が含まれなくなってしまうリスクが増大する。

自動化も難しくなる

(いみわからん・・・。)

 

インフォーマルな会話をする

ステークホルダーとのアドホックな会話は有用。

ワークショップの代わりになる。

詳しい人だけで集まって話してみる。

で、ストーリーについての認識を共有する。

 

仕様に合意を得る際にもべつに、ミーティングしなくてもいい。

他のステークホルダーからのインプットが必要ならやる。

 

コラボレーションの準備

みんなで仕様決めをするための準備が必要ってことみたいです。

チームメンバーで理解のレベルに差があったりすると、仕様決めしても

うまくいかないよねってことです。

予備的なフェーズでおおまかに議論しておけってことでしょうか。

よくわかりませんが。

 

 

 

 

 

 

Specification By Exampleの読書中(5)

今回は、Chapter 6 Specifying collaborativelyからです。

みんなが理解しやすい仕様を作るために、みんなで仕様決めをしましょうと言う話です。

いかにしてコミュニケーションギャップをうめるか、それについてさまざまな技法があるわけですが、ここではそれについて解説をしています。

 

・全チームでのワークショップ

(SBEで初めからやると決めている場合)

ビジネスステークホルダーやらドメインエキスパートやら開発者が集まって、

みんなで仕様を決めます。

これは、各ステークホルダーたちにシステムがどうあるべきか理解するのに

とっても役立つらしいです。

忙しいお偉いさんにも参加してもらう必要があるので、コストが大きいですが、

要求を理解するためには必要みたいですね。

 

・小さいワークショップ

(頻繁に解明することがある場合)

1人の開発者、1人のテスター、1人のビジネスアナリストで始めます。

全チームでのワークショップより簡単に開催することが出来るし、違う見方の人からフィードバックを受けることが出来ます。

 

・ペアライティング

(成熟したソフトウェア)

ワークショップなしでもやることが十分にわかっている場合、

開発者と、ビジネスアナリストの二人で話し合いながら、

仕様決めをしていきます。

コストがかからず効率的な方法です。