36 karma · joined May 17, 2012
email: rfirestone@ciber.com
I highly recommend not learning this about otters
How many times does the inferior product with better marketing win? The reality is a lot.
A random developer saying “hey checkout this npm package I wrote to do XYZ” is something that could directly be useful to people in their own projects or in the future.
If a company seriously tried it productivity would go to zero. You have invented a system that aligns the developer interest with gaming the system not shipping quality code.
A couple of people I know have nexus 7 tablets for doing their android work.
Seriously computers are cheap go buy one.
If I was evaluating your solution based on what they are asking for I would have passed on you as well. Your solution is unnecessarily complex and over built. They are asking if can you use JS to manipulate a select box. Not including tests you have brought in 400+ lines of code (184 lines of code + the EventEmitter library) to implement 75% of the functionality you were asked for. That is a lot of code to take an item from a select box and add it to a list. Knowing that developers leave I would not want to inherit a solution like this.
To put it in car terms you built a 911 when the customer was asking for a vw bug.
I would't expect rails on it's own to get dramatically faster. The way it is going to get way faster is to strip out a lot of why to use rails and get closer to what we get from a pure rack app. The flip side is we lose a lot less off the top line speed see in benchmarking.
Using things like Russian doll caching and turbo links can make apps seem faster.
With some patience jruby and the right server setup rails can get a pretty big performance boost. For long running processes like web servers jruby can be a pretty big win for the ruby ecosystem.
There is some very thorough benchmarking done by Brian Knapp comparing different ruby runtime/server/framework combinations you can see here http://www.madebymarket.com/blog/dev/ruby-web-benchmark-repo...
1) Keep your code as simple as possible. In the real world if you can call your code complex or clever it is probably bad.
2) When presented with a problem don't immediately reach for the keyboard. Take some time to make sure you understand the actual problem that you are solving.
3) Good enough and working beats perfect and not working. Perfectionists make horrible co-workers and usually end up with horrible code.
We looked at a couple of other integrations. rails-assets.org was the only one that did't require adding extra parts that need to get managed. Time spent managing multiple packaging systems is time not spent doing productive work.
To address your example there are literally dozens of mutual fund comparison tools. Mutual fund companies are required to publish their fund data in a standard format specifically to make comparison between funds possible.
You were not paid for the work you put into a non trivial piece of software. If your co-founder is serious about continuing with the company and wants to use what you wrote she really only has two options. 1) suck it up and give you a serious equity stake. 2) license it from you where you make a % of sales or a fixed amount per install. She does have a 3rd option to use your software and gamble that the company is never successful enough for you to sue her for an obscene amount money.