You created Merb in the first place. Didn't you? Its missing from the story!
Are you thinking of Yehuda Katz who works at EngineYard? http://yehudakatz.com/
My short history of Engine Yard and my Resignation
31–40 of 76 posts
Re: My short history of Engine Yard and my Resignation
#32You created Merb in the first place. Didn't you? Its missing from the story!
How does Merb compare to Padrino? Any ideas? Besides Merb being part of Rails now.
The way I've been explaining Padrino is that it's Merb built on top of Sinatra.
Merb was a lightweight, modular framework made up of a small merb-core and then merb-more, a collection of 20ish gems that provided various bits of functionality, most of which were problems that Rails solved in its core. Stuff like merb-helpers. If you wanted fancy helper methods, you required the merb-helpers gem. If you didn't care, you would not require that and have a slightly more efficient app. Similarly, it didn't have an ORM baked in--you'd use some gem like DataMapper (with an additional merb_datamapper gem that told Merb how to integrate with DataMapper).
Padrino seems to have the same setup of a minimal core with lots of modular plugins, but its equivalent to merb-core is sinatra. Which is awesome because sinatra is great and this way they don't have to reinvent the wheel.
Re: My short history of Engine Yard and my Resignation
#33Earlier quoted context omitted.
I'm not positive as to what you specifically are referring. There are easy options for simple apps. As things get complicated, there are managed hosting options that are hyper-specialized to Rails, such as EngineYard. There was a time when administering a Rails app was a much more hairy proposition than it is today, though.
Ive heard the complete opposite is true. That rails while improved is still a pain to deal with. THe benefit of tails is that theres more and more people using it so theres some expertise out there.
Like any opinion, people are bound to have different ones. Using something like Passenger, you just put your app somewhere on your box, and add two lines to your httpd.conf, and you're done. I use nginx/unicorn, but it's still really easy.
Re: My short history of Engine Yard and my Resignation
#34That is the new way to build companies, College degrees don’t matter much IMHO anymore, for developers anyway. It’s more how you interact with the open source community and what you release yourself. Your github account has become your new resume and what you say on Twitter and in various IRC channels are more likely to get you the best jobs then any recruiters ever will. I'm interested in education, hiring, and matt…
That's a terribly short sighted thing to say (by the poster). I know HN users don't seem to value education, but a college degree has a lot of value outside of the education component. Living with others, compromising, group work, social life, classes outside your area of focus, etc. I'd rather hire someone who has been through this than a hacker who has only spent time in the echo chamber of forums and fellow geeks.…
We called these hackers "polymath" and it is far easier and much cheaper to get rid of TV and get hobbies.
Beside, 4 hours of tv watching a day is practically a part time job. Might as well spend that free time on something more relaxing and brain stimulating.
Re: My short history of Engine Yard and my Resignation
#35"We just were victims of our own success and could not deploy customers fast enough to get free time to build the automated system that AppCloud is today." This is a really hard problem IMHO. Obviously it depends on your business model, but I've found it at times an unsolvable problem...
Yeah, it seems to be quite a common problem at the moment. Look at Twitter; more specifically Digg, who have suffered from this for years and are only now getting out from it.
Re: My short history of Engine Yard and my Resignation
#36Well written. I had never heard of the author or his company, yet unlike so many of the articles that come through here, it had enough context baked in that you could follow it without a Google search. I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?
"I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?"
That WAS my experience with Rails, but I'm pretty sure that the problem wasn't due to Rails, but rather the way that our system ended up being architected.
An intelligent setup would have been to have each child site a separate, service-backed (i.e. no ActiveRecord -- that scaled abysmally, and I don't know whether or not it's improved enough for more than prototypes since then, so that part might be outdated now) Rails application. The company common resources like custom Javascript, authentication (ours used a pretty hefty RSA server setup) and style sheets should be hosted in their own Rails app.
Do it that way, and ensure that your developers aren't idiots like the blithering idiot that thought he was an architect (without nepotism he'd have been fired instead of promoted to architect, as his only previous industry experience was as a gopher at accidenture), and you can make a Rails app that's not only robust, but also scales well.
It also avoids the tight coupling problem that the gen-y's and sweatshoppers all seem to love so much.
You decide to add a new feature? Spin up a new Rails app. You need to change the styling? No problem, update them in one place.
Not that any of that is specific to Rails, but even back in 2005, that approach worked well... and the company I was working for might have been successful if we'd stayed that course.
Re: My short history of Engine Yard and my Resignation
#37That is the new way to build companies, College degrees don’t matter much IMHO anymore, for developers anyway. It’s more how you interact with the open source community and what you release yourself. Your github account has become your new resume and what you say on Twitter and in various IRC channels are more likely to get you the best jobs then any recruiters ever will. I'm interested in education, hiring, and matt…
Beware selection bias.
Re: My short history of Engine Yard and my Resignation
#38Is there anything in this "Oh the stories I could tell if only I could. But I feel that telling this positive story of the history of EY is the classy way to go out and I wish Engine Yard all the best in the world" Any unrest?
I don't think anyone would leave right before their stock was about vest, without a solid reason. :) But the key term is classy.
True story: in the early days of Merb, before it had really gotten a lot of attention, I once hit a show stopper - hopped on IRC, told him about my problem, he found the bug, fixed the bug, pushed a new release in something like 15 minutes IIRC, and stayed cool about it the entire time.
Best of luck to him!
Re: My short history of Engine Yard and my Resignation
#39Is there anything in this "Oh the stories I could tell if only I could. But I feel that telling this positive story of the history of EY is the classy way to go out and I wish Engine Yard all the best in the world" Any unrest?
All businesses have their ups and downs. I was with a startup for 6 years and certainly have a good set of stories. It just isn't good karma to air dirty laundry.
Re: My short history of Engine Yard and my Resignation
#40Earlier quoted context omitted.
I'm not positive as to what you specifically are referring. There are easy options for simple apps. As things get complicated, there are managed hosting options that are hyper-specialized to Rails, such as EngineYard. There was a time when administering a Rails app was a much more hairy proposition than it is today, though.
Ive heard the complete opposite is true. That rails while improved is still a pain to deal with. THe benefit of tails is that theres more and more people using it so theres some expertise out there.
Having worked full time in both .NET environments and now in Ruby/Rails, the toolkit in the ruby community is very robust and a far better experience. Any of our developers can do a production deployment with one command and do it with zero downtime. In .NET, it was never as elegant.
The problem is something gets started in the infancy of a framework or tooling and continues to get propagated. The "hearing" rather than "using".