D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.



    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

I'm just going to wear my Japan Perl Association Head Director's hat for a bit and add a small, but what I consider to be something very important about the whole Moose or no Moose argument:

"Moose Developers, please act like you care (more) about startup cost, use of RAM, and other efficiency issues."

Here's what I mean by the above:

I'm an engineer. I like Moose. I understand the whole Moore's law thing, I understand the "buy more RAM" thing.

However, most of the world is made up of non-engineers. This group is made up of  people who make decisions, or they are your regular joe programmer who don't give a rat's ass if they use Moose or plain hash or worse, some other language.

What these people see are things like numbers. If they see a benchmark touting Moose to be slower, they'll ONLY remember that Moose was lower ranked. They won't remember the context in which the benchmark was taken, nor Moose's advantages.

Furthermore, if a Moose developer responds to that kind of benchmark with a smart-ass comment, or a phrases like "dude, buy more RAM", it just doesn't do anything to convert people's minds. I'd really like to avoid that.

I know Moose is great. I know something like it was long overdue. I'd like to keep using it on all of my projects -- which I try to do now.

But if a client sees these articles and get the wrong idea, I'm going to have to spend another 2 weeks writing up evidence claiming Moose's superiority before I can install it in their systems. And if that happens, I'm just going to whip my Perl-fu and say "bless this hash, and let there be no Moose" -- cause it costs money to prove otherwise.

So, here's my $0.02.

I know that the Moose developers are doing a great job. I'm not even going to say that they need to change their attitude or goals. However, I'd really like them to make a more thought-out response, and act like you actually care about the parties involved that have a slightly different view than yours (in this case, people who really care about speed, memory efficiency, etc). I actually don't care if they actually care. I know they are good enough that they won't completely ignore it. And I/we will contribute where possible. Just... act like you care :)

That will make my life easier. I can point people to the Moose roadmap or whatever and say, "look, they care. they /will/ address your concerns. let's just install Moose in your system for now, yeah?" and go on hacking with Moose.

 And you know, you can always mention/encourage more activities like JPA was doing with gfx to shove some startup costs ;) 

(update: fixed typo and such)
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr






うちの会社、endeworksはスタッフみなさんだいたいやりたい仕事(自分の職能に合った内容)をやれてるのもあってか、長居するときはするし、それ以外の時はさくっと帰ってるし、まぁゆるいもんだ。社長の俺も基本的にはそれでいいと思ってる。ただそこで求められるのは生産性なんだよね。別に一日2時間しか働かなくてもいいけど、1人当たり給料 x 5 ~ 10倍の売り上げを上げてもらわないと会社ってのは基本的に立ちゆかなくなるので、その分だけ担保できてればいいや、って感じ。

追記:5〜10倍ってのは目標というか、それを基本としないといけない、ということですな。実際はそこまでなかなかいかないけど、だからと言って給料 x 2倍でいいよってことになってしまうと、これは完全に破産コースなので、計算上は常に5倍を稼げるように考えていかないといけない、ということ。逆に言うと 給料を決める時に ( 実現可能な売り上げ / 5 )が給料になる、と考えてもいいかもしれない。




    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

今年のYAPCの後、Moose入門 (9/14)、Perl/Ajax/Unicode 9/15、DBIx::Class x MySQL x スケーラビリティ(9/16) の3コースが提供されるわけですが。正直に言おう、もうちょっと人が来ないとちょっと辛い感じ。公平に考えて、かなり価値の高いコース内容になると思います。僕も普通に行きたい感じ。


    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr