Outside.In Scales Up - Case Study - PHP to Rails
engineyard.com
Outside.In Scales Up - Case Study - PHP to Rails
1–10 of 10 posts
Re: Outside.In Scales Up - Case Study - PHP to Rails
#2This is simply an ad for Engine Yard.
Re: Outside.In Scales Up - Case Study - PHP to Rails
#3Self-promotional post alert! This is from jiparker.com, the homepage of the guy who posted this item:
"After almost 10 years at Ameren as a developer, I will be taking an Account Manager position with the internet start up Engine Yard out of San Francisco."
Re: Outside.In Scales Up - Case Study - PHP to Rails
#4Self-promotional post alert! This is from jiparker.com, the homepage of the guy who posted this item: "After almost 10 years at Ameren as a developer, I will be taking an Account Manager position with the internet start up Engine Yard out of San Francisco."
who cares? The post is either good or it isn't, where the poster works or his intentions are unimportant.
Re: Outside.In Scales Up - Case Study - PHP to Rails
#5This is simply an ad for Engine Yard.
Not a very good one - the site is slow as hell right now.
Re: Outside.In Scales Up - Case Study - PHP to Rails
#6Here's the actual blog post: http://blog.outside.in/2008/01/22/outsidein-switches-to-rail...
PS. Disclaimer: I work at outside.in too :)
Re: Outside.In Scales Up - Case Study - PHP to Rails
#7This really has no business being on the site. I program in both PHP and Ruby, but there are no bench marks or explanations as to why the company needed to switch to Rails. What was the problem in PHP that they couldn't solve that needed a complete port? What were the "architectural" problems that required the expensive & time-consuming process of switching languages?
Without any kind of data or insight into the train of thought behind the change, this falls into the infotainment /advertising category. We can do better than this.
Re: Outside.In Scales Up - Case Study - PHP to Rails
#8This really has no business being on the site. I program in both PHP and Ruby, but there are no bench marks or explanations as to why the company needed to switch to Rails. What was the problem in PHP that they couldn't solve that needed a complete port? What were the "architectural" problems that required the expensive & time-consuming process of switching languages? Without any kind of data or insight into the trai…
Perhaps it's for maintenance reasons? Who knows probably the first iteration of their site was the standard PHP + SQL+ HTML format.
Re: Outside.In Scales Up - Case Study - PHP to Rails
#9This really has no business being on the site. I program in both PHP and Ruby, but there are no bench marks or explanations as to why the company needed to switch to Rails. What was the problem in PHP that they couldn't solve that needed a complete port? What were the "architectural" problems that required the expensive & time-consuming process of switching languages? Without any kind of data or insight into the trai…
Perhaps it's for maintenance reasons? Who knows probably the first iteration of their site was the standard PHP + SQL+ HTML format.
Is it really that hard to create maintainable PHP code? I've been guilty of making spaghetti code myself, but after a little studying and re-learning the stuff I learned in college, I improved measurably in a matter of weeks.
It isn't so hard to write maintainable PHP code; although maybe the nature of this application was different. If they had written the rationale, I wouldn't have any of these questions :(
Re: Outside.In Scales Up - Case Study - PHP to Rails
#10Earlier quoted context omitted.
Perhaps it's for maintenance reasons? Who knows probably the first iteration of their site was the standard PHP + SQL+ HTML format.
Is it really that hard to create maintainable PHP code? I've been guilty of making spaghetti code myself, but after a little studying and re-learning the stuff I learned in college, I improved measurably in a matter of weeks. It isn't so hard to write maintainable PHP code; although maybe the nature of this application was different. If they had written the rationale, I wouldn't have any of these questions :(
While I agree with you on your premise I'm sitting next to a guy on the cubicle to my left writing a mediumish CMS for a client in the usual PHP sort of way. Although his code is nicely indented and formatted for reading. He's having a hella of a time navigating his code base(which is like what? 3000 LOC) when the client requests for simple changes.