BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rails

Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rails

Bookmarks

TekPub is a web site devoted to developers, giving them a source of focused on-line training in various topics from Microsoft Entity Framework to writing your own blog engine using Ruby on Rails.  The site was created by ex-Microsoft employee Rob Conery with The Lounge owner James Avery.

TekPub is an interesting study in a company who started on ASP.NET MVC and quickly moved to Ruby on Rails.  InfoQ had the opportunity to talk with Rob and James about TekPub and their journey from using ASP.NET MVC to Ruby on Rails.

Rob Bazinet (RB): For readers who are unfamiliar with your product, tell us about TekPub?

James Avery (JA): TekPub provides high-quality technical screencasts for programmers. Our goal is to help someone learn about a new technology in a couple of hours by watching someone who is very familiar with the technology not only cover the basics but also dive deep into using the technology in a real-world application. Instead of waiting months to get a book that is most likely already out of date, our subscribers can get the jump on a new technology right away. We have already finished our ASP.NET MVC 2 screencast series and there still isn't a book out on the subject.

RB: Who is James Avery and Rob Conery?

JA: I run a couple of technology startups in addition to TekPub. I run The Lounge and Ruby Row advertising networks, focused on .NET and Ruby developers respectively. I also help run DotNetKicks, a community site for .NET developers. My latest focus is Adzerk which is the web server I built to run The Lounge and Ruby Row available for others to use. I got started on the web in the mid 90s and moved to Microsoft technologies when .NET launched. Lately I have been using .NET, Ruby on Rails, MongoDB, and whatever else strikes my fancy.

Rob Conery (RC): I've been working in the software industry since 1991, doing the typical mundane database/CGI/HTML stuff. I crossed over to ASP in 1997 and have stuck with Microsoft stuff since. In 2006 I went to work for Microsoft and focused on helping people learn and use the new ASP.NET MVC framework. I left in 2009 to do some different things (more focused on Open Source platforms) and ended up founding Tekpub with James Avery.

RB: Would you explain the architecture of TekPub on launch day?

JA: The first version of TekPub was a Ruby on Rails application Rob threw together in a weekend. We talked it over and realized it needed to be scrapped and since we both knew ASP.NET MVC inside and out we decided to go with that. I am firm believer that starting a new business is not the time to also try and learn a new technology. Rob and I had both written and deployed Rails applications in the past, but when it came down to it we both knew ASP.NET MVC much better than Rails. So we scrapped that and put together an ASP.NET MVC site. We later scrapped that site and re-built it because it was getting too complicated. When we launched, it was that third version that went live. It was ASP.NET MVC, C#, and MS SQL Server. 

RB: What challenges did you see with people using the site and from the perspective of you managing the site?

RC: Initially, on the very first day, it was our bandwidth. We announced on Twitter and it buried our ISP due to the bandwidth demands. They literally had engineers "sitting on the switch" to keep it open and functional - but it stopped working. So I pushed all of our free content to Amazon S3 within 2 hours of our launch - which helped tremendously.

Also - a subset of people didn't like Silverlight and wouldn't install it. We took ads out on Reddit and people simply saw our site as something sponsored by Microsoft - which is the exact opposite of our goal. So that was a major issue for us. 

JA: ASP.NET MVC ran just fine, and the Windows stack was fine. We didn't have any challenges in that area. The main challenge actually came from the decision to use Silverlight for streaming. We had a lot of kickback from people who didn't want to install Silverlight and I convinced Rob we had to switch to Flash. We moved to Flash and haven't had a single person complain. We hope to have HTML5 available soon.

RB: How did the architecture handle the user demand?

RC: We never had an issue with the underlying framework - it handled it perfectly. It's not a terribly intense site (in terms of functionality) so we never really had an issue that way. 

RB: If the platform was holding up fine, what prompted the change of architecture?

RC: Money. We were enrolled in Microsoft BizSpark Program and it was great for getting off the ground, but projecting into the future we realized that everything - from our database down to our development environment would have to be paid for after 3 years. We also figured that we'd probably need a separate server to run videos properly (for streaming) to Silverlight (using Streaming Media) which would be another license cost - and, in addition, we'd need to buy Media Encoder in order to encode the video for Smooth Streaming.

This might not be an issue for a large company, but when we sat down to assess what the bills would be - well let's just say that it was about 5 figures. We put our business hats on and tried to justify that cost - and we couldn't.

Not only that, James and I both knew Rails pretty well. We realized we could push everything into the cloud with better streaming and throughput for a microscopic fraction of the price - so that's what we did.

JA: As Rob mentioned cost was one of the factors, BizSpark is great but it is basically a ticking time bomb. I think more than cost though the motivating factor was around what we both wanted to be using day to day. ASP.NET MVC and .NET are very lacking in some areas that are very important to us. The testing story on .NET is not the best, you have to jump through a lot of hoops to design your application in the right way to handle testing and then writing the tests themselves is not as clean or usable as some other languages. One of the other areas of high friction was deployment, there are ways to handle it in .NET but nothing as nice or clean as Capistrano. 

RB: So what does the TekPub platform look like today?

RC: We moved to Rails 2.3.5 using MongoMapper against MongoDB. We have a reporting setup that uses MySQL to track stuff we need to report on which uses DataMapper. We also plugged in New Relic RPM to keep track of our site and it's health - all of this is less than 1% of what it would have cost us, on average, with BizSpark. 

JA: This solved all of our issues around licensing, we pay about $80/month for a large Ubuntu instance on Amazon EC2, after the reserved instance fee. It’s a technology that both Rob and I really enjoy working with, we have great testing with Cucumber, and deployments with Capistrano are simple and easy. 

RB: Can you give us a bit more detail on your technology stack?

RC: Using Rails 2.3.5 against MongoMapper/MongoDB and DataMapper with MySQL 5.2. We are also using New Relic RPM which is just great. 

JA: We are using Rails 2.3.5 running on Ruby 1.8.7 running through Passenger. On the DB side we talk to MongoDB version 1.3.4 using the excellent MongoMapper gem. We also use MySQL 5.1 through DataMapper. We don't make use of too many other gems, we use Pony for sending email and rpx_now to talk to RPX for our authentication. We are both big fans of HAML and use that for all of our views.

RB: What does your EC2 configuration look like?

JA: Because all of the content is served from CloudFront we can afford to use a fairly small server. We are on a single large EC2 instance (2 virtual cores, 2 compute units each and ~7G of ram). It's running Ubuntu 9.1 (karmic) and Apache. I wish there was more here, but it is very simple to get this up and running on EC2.

RB: Why did you choose Ruby on Rails?

RC: It's what James and I both knew, and the plug-in story is very compelling. For instance - New Relic is a god-send. I don't worry about the server freaking out, and I can see the "choke points" of all the code. They also track the highest-occurring queries and will even suggest improvements.

MongoMapper is an incredible data tool and MongoDB itself is faster than lightning. The Rails platform has matured to the point where it's almost difficult to justify *not* using it. 

JA: All the problems we had (licensing, testing, deployments) could have been overcome. We could have used workarounds, written our own deployment framework, etc. What is comes down to is that we both really enjoy working with Rails and we enjoy the Rails community and the tools and libraries available. One of the best parts about running the show is that we get to do what makes us happy.

RB: Why did you choose MongoDB versus a more conventional database such as MySQL or PostgreSQL?

RC: Speed and extensibility. It's so very simple to work with MongoDB - there are no migrations to worry about and you can have a ton of flexibility with it. It's also ridiculously fast - and the speed perception is huge for users. 

JA: We are using both actually, we use MongoDB for what it does well (flexibly store information about the productions, users, orders, etc) and we rely on MySQL for what it does best, providing a durable transactional log of what is happening. 

RB: What immediate benefits have you seen from the rewrite and the new design?

RC: Immediate - the first thing people notice is the speed of it all. They also notice a bit of a "tighter" design which we were allowed to focus on a bit more as the server-side stuff is really trivial, to be honest.

Not only that - but we've had some issues that we were able to iron out within seconds as the deployment story is so very, very simple with Capistrano. Issue a fix and push - takes seconds.

Our testing suite grew tremendously as well - Cucumber is a joy to use and lets you do some things that are a bit hard with ASP.NET MVC. For instance - testing PayPal's IPN posts are pretty tough with ASP. It's possible to do - if you create a FormCollection and push it through - but couple that with the anti-forgery protection and the story gets a bit more difficult.

With Rails/Cucumber/Webrat, it's a matter of filling out a hash and posting it - then making sure everything happened to plan. I think our users are seeing a bit more functionality that works as intended - which is great.

JA: The most immediate benefit has been the speed at which we are making changes and pushing them up to production. On the ASP.NET MVC site I would often write SQL scripts to handle complicated support requests, like changing someone's OpenID or combining accounts, but now I just spend the 30-60 minutes to write a couple of lines of Ruby and push it up.

One of the biggest changes in the rewrite is actually how we are serving files to our users. In the past we would stream files from either our server or from a Wowza media server running on EC2. Both of these solutions were adequate but expensive and didn't work as well for people in other countries. Around the time we started our re-design Amazon announced the ability to serve private content through CloudFront and CloudFront Streaming. All of our content is now served from CloudFront using securely signed URLs which means users anywhere in the world are getting great download speed. It also saves us money since we are only paying for the bandwidth we use and don't have additional machine or licensing costs.

RB: What does your TDD testing methodology consist of in your current implementation?  Any mocking involved?

JA: We use Cucumber and Pickle and that's about it. Rob can probably detail this better than I could.

RC: No mocking - pure BDD. I hate the drag of feeling like I need to have "code coverage" - I have a business to run and I'd rather make sure that the user experience is solid and to me that means BDD. Cucumber played a really big role - as did Pickle and Factory Girl - all of it went together amazingly well with MongoMapper and it made me actually laugh a few times and what I was doing on the Microsoft stack versus what I could do now. I was almost completely thinking business-first and didn't even really notice the mechanics of the testing. 

RB: How does your current testing methods compare to what you had on Microsoft?

RC: 100% difference. It was a pain to test with the Microsoft stuff and when you're poor and have 3 months until the money runs out, testing is something that you have a hard time justifying. I'm not afraid to say it - I wrote a ton of crap for our first revision. It doesn't matter how good your application is if you don't have customers and all I really needed to be sure of was that it didn't fail when it wasn't supposed to. So I had some tests, but nothing to gives me the comfort I wanted. We did wrap the PayPal stuff in a ton of tests, you have to. When it comes to their API and I torched their sandbox environment for 3 straight days and STILL had issues rolling live.  

That aside - it's night and day. We're covered with all kinds of behavior now and I think James even got around to writing some.

JA: Microsoft testing is always a fight, mainly because C# and static languages don't lend themselves well to testing. It always feels like you are jumping through hoops when testing on .NET. That being said the SpecFlow framework on .NET does look very promising, but I doubt it can overcome all of the drawbacks of testing in .NET.

RB: How hard is it to do testing on a Microsoft stack and why?

RC: The language and the tools. If Microsoft thought more about it, it would be a bit easier to test the stuff. You can't do RSpec with any language other than Ruby really - it just makes it easy. Microsoft could capitalize on that with the DLR... but they don't. It's not in their ".NET Story" and that's OK - it's their business decision. It was ours to move away from that. 

RB: What lessons or takeaways have you gotten from a total redesign?

RC: None really - I think both James and I knew that we'd hit a point where we would need to adjust and rewrite. This is my 3rd startup and I think it's the 5th for James and we had a long discussion about what to use in the beginning. We both agreed that we'd need to "go with what you know and get it out" - so we did. 

We were lucky in that the idea took hold - we then moved into "OK let's plan for the next 3-5 years and go into controlled-growth mode" - which is where we are now. We don't want to be huge, we don't want IT people or a group of developers who work on stuff. We want to do it ourselves and stay small - focusing on the idea that got us here.

Rails is super easy for two guys like us to work on and maintain. We have the most scalable backend in the world (Amazon EC2 with auto-scale) and we're having fun doing what we're doing.

JA: I think most people would look at this story and think that we should have gone with Rails to begin with, but I am actually very glad we didn't. I think our instinct to stick with what we knew the best made sense while launching our business and let us worry about all of the business issues without worrying about our tools. Now that the business is launched and on firm ground it is the perfect time to let our inner geeks run a little wild and move to a platform we both enjoy more.

RB: Do you see any weaknesses to the current architecture?  What would you change if you were starting over again today?

RC: Nothing on my end - I love it all. It's weird for me - I've been a Microsoft person for a long time but putting on my business hat... well it just doesn't make any sense at all for us. I like the idea that scaling comes at the cost of hardware  - and it will be a really long time that we'll need any. Our servers are essentially "liquid" and we can buff as needed. Can't do that with the Microsoft boxes (from what I know) and if you try to latch on separate machines, you end up with a big bill. 

JA: The only change I would like to the current architecture is to break out MongoDB from our single server, it makes sense to run MongoDB in a pair whenever possible but with replica pairs being depreciated it makes sense for us to wait on the MongoDB team to develop their new pairing strategy and start with that. The cost of an addition two VMs and the fact that everything is running fine on our single server also deters us from doing this right now.

RB: Thank you Rob and James for taking the time to talk with me today.

Additional information about TekPub can be found on the company web site.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Great writeup

    by Carl Furrow,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Lots of interesting information there. Read right through it without stopping. Always nice to hear how companies get their start, etc.

  • I moved from Asp.net to Ruby too for my own business

    by Aymeric Ggggggg,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I had a similar very positive experience in my migration to Ruby on Rails. After 10 years with .Net, I can't believe I am more productive with three weeks in Ruby on Rails..

    I wrote a blog post about it here

  • A Glaring Omission

    by Mark Richman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    They glaringly omit the amount of effort and time required to bring the Rails version of the app to feature parity with the ASP.NET MVC version. I have an ASP.NET app that I'd love to dump in favor of Rails, however it would be a tough sell if it were to take me 6 months of full time work. Also, there is an opportunity cost in making the move, as feature enhancements would be suspended for the duration of the rewrite. At the end of the rewrite, you basically have the same app you started with, albeit with a far more flexible, productive, and inexpensive framework.

    Thanks,
    Mark A. Richman, MBA
    www.markrichman.com

  • Re: A Glaring Omission

    by Tim Heckel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Because the original was asp.net mvc, I think the rewrite was much easier than it would have been had the site been originally coded using asp.net webforms. I'll bet 90% of the work was already done in the css/html and the actual video screencasts, so moving the 10% out of mvc and into rails was not nearly as challenging..mostly, it's just wiring up the views a different way and tweaking the view with haml. Just my two cents.

  • Re: A Glaring Omission

    by Mark Richman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That's my situation exactly - a huge Web Forms app that I'd like to port to rails. There is no clean parallel to follow. I simply can't make the business case to port it with such sunk cost invested.

  • Streaming

    by Gary Pinkham,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I know this is about the move from ASP.Net MVC to RoR. But I wish they talked more about the Video Streaming.. :-) I'm building a RoR site now and need private secure video streaming..

  • Re: A Glaring Omission

    by Ryan Riley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Mark,

    If you want to move to Rails (or even MVC) from WebForms, you are going to have a lot of work ahead of you no matter what. I'm working on a hybrid app right now, where we are moving some but not all of our WebForms stuff over. The worst part is that all of your Model information is in the WebForms code-behind files. That means refactor, refactor, and then refactor some more. You can build WebForms in such a way that you don't have that pain, but most people didn't and haven't.

    So, if you want to move off of WebForms (doesn't really matter to what), you'll first need to figure out what your Model really looks like. That means you'll likely need to do the refactor of your existing app before you can move to any mvc framework. Well, you could also start over, but I'm gleaning that's not what you really want to do.

    By the way, if you are hosting your own, you could run IronRuby on Rails and use all of your refactored C# directly instead of having to port it all over to Ruby.

    Ryan

  • Too much biased article

    by Tomas Janovsky,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think it is very biased article, basically comparing new generation of the product with a lot of differences that are not tied to the specific language or technology.

    And something you call a "startup" and can't make you money for server licenses after three years is a very specific case itself.. Nobody force you to use Enterprise editions just because you got them with BizSpark...

  • Re: A Glaring Omission

    by Rob Conery,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In total time - it took me 3 weeks. I actually rewrote the thing in Sinatra first but then realized there were some things I wanted to use as part of the framework.

    I didn't use any generators - no scaffolding or anything. My workflow was pretty simple: crank out a feature (Cucumber specs) and build against it. I could easily knock out a feature/day and in about 8 days it was all built out (my model).

    It was then a matter of putting the views together. This is where things get really easy with Rails - I'd set up the routes, build out the Controller, and nail down the Views. I already had the CSS from our old site and it took me about 4-5 days to set things up.

    The final step was PayPal and bullet-proofing. PayPal is really horrible to work with and it took me 2-3 days to make sure we were covered as we wanted to be. I also setup some reporting in this time.

    The final step was pulling in the old data - for this I used Rake and kicked up about 5 rake tasks to pull stuff in from our old site using XMLRpc. That took me 2 days.

  • Re: Too much biased article

    by Rob Conery,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In terms of bias - I used to work at Microsoft and my face is on the cover of an ASP.NET MVC book, right next to Scott Guthrie. If you were going to call me biased - I would understand if it's toward MS stuff.

    In terms of "New Stuff" - we didn't really do much different. The changes we made were planned, yes, but they weren't put in because of Rails.

    Your final point is a bit ridiculous. We surely can make enough money for licensing - the question is why? No one is forcing us to use Enterprise and indeed we aren't - we were using SQL Standard (which is $7100/cpu). Now if you want to pony up $14,000 for a database - be my guest. I'd rather pay nothing.

  • Re: A Glaring Omission

    by Mark Richman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What are you using for PayPal integration? I've been wresting with recurring payments and IPN. There really is no good way to automate IPN testing is there?

  • Re: A Glaring Omission

    by Rob Conery,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Mark - the ActiveMerchant gem is great for most of the stuff when integrating PayPal. I had to handroll a few things as well since we use the PayPal membership stuff. All in all it was pretty easy to test - except for the fact that it's PayPal and they're horrible.

  • Re: A Glaring Omission

    by Mark Richman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I was looking at ActiveMerchant, but I didn't see an option for recurring payments using PayPal. Right now I'm using the client-side 'subscribe' button to www.paypal.com/cgi-bin/webscr. I'd really like to keep the control on the server side, instead of redirecting away to PayPal, then redirecting back to my app, hoping IPN fired somewhere in between. Any ideas?

  • Re: A Glaring Omission

    by Rob Conery,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yah - that's what we're using. The thing ActiveMerchant is good at is receiving the IPN and pinging for verification. Once that's done you can pull in the post hash and examine it - I rolled it into a class that returns the hash values.

  • Tekpub Training Stuff

    by saeid pahlevan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Does this decision on moving away from Microsoft stuff impact the training materials presented in TekPub?

  • Re: Tekpub Training Stuff

    by Rob Conery,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Not at all - this is just a decision we made about our infrastructure. We maintain neutrality completely - even if we, personally have opinions - there is no place for bias in *what* we present. Some authors (including myself) might be quite excited about the subject they're showing - and we allow for that. However I'll never decide not to cover something because I have an opinion on it. Case in point: EF. Not my favorite tool, but a lot of people need to use it, so we covered it :)>

  • Re: Too much biased article - I agree

    by Brice Cave,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I know I am kind of late to this party, but I agree with Tomas.

    I love you, Rob, but some of the points you make are moot.

    You mention paying 14,000K for a DB server, but that would be if you are hosting this all yourself, which you are not. That would also imply a bunch of other costs for maintenance and infrastructure. If you were to host the RoR version and streaming media servers yourself you would be shelling out some dough, even if it was for a much lower cost than a complete MS environment.

    Amazon offers EC2 with MS platform including SQL Server. Admittedly, I have read about issues with SQL Server performance on EC2, but the jury is still out... I would like to see some recent tests (but I digress).

    For my current startup, we considered Amazon's EC2, but ended up using a shared 8 way cluster for hosting our services (providing data for our iPhone clients...Android and Windows 7 to come) on Windows 2008 with SQL Server 2008 R2 for $63.00/month at ReliableSite.net. Web sites are hosted very cheaply at a big provider who shall remain nameless (also MS/.NET 4/ASP.NET MVC...) which we may move elsewhere for the about the same monthly price (less than 20 bucks). We may consider moving to Amazon EC2 to host our services if the future bodes well, or even consider *gasp* Windows Azure!

    We are also leveraging Amazon Cloudfront and S3 for delivering our private content (mostly audio), just like TekPub. "We don't need no stinkin' Media Server" ;) This provided the easiest, best, and cheapest option for us as a bootstrapping startup.

    So... Comparing your costs hosting stuff in the 'cloud' (to use a really over-used buzzword!) to the cost of hosting a full-on Microsoft environment on your own infrastructure, in your own shop is not really fair, IMHO. All of the MS goodness is available in the same format, albeit slightly more expensive on the average from what I have seen. When my BizSpark runs out, I will gladly pay for a full MSDN license (or just Action Pack) to get what I need to continue using a fully licensed development environment. I could settle for a less feature-packed, reduced toolset development story on free stuff for MS development, but I won't. My time is very valuable to me.

    I have not had the opportunity to experience the testing situation with RoR (or RoR in any fashion) because I am too busy paying the bills with Microsoft-based development and spending time with my wife and 3 kids. That I will have to take your word for, because I really value your opinion, and I can always just take a gander at it on TekPub with my ~$19/mo subscription (2 months as a customer)!

    All that said, thanks, Rob and James, for providing so much great content to the community. I just disagree with most of the biggest reasons ($$) for the switch.

    Thanks for reading.

    Brice

  • Re: Tekpub Training Stuff

    by Wil Moore,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Rob,

    Very interesting article. You seem to allude to not liking Entity Framework. My work with ZF and Doctrine2 (PHP) has gotten me interested in .NET MVC2 and EF. From what I've been reading so far, it seems like an great framework. What is your opinion on it? You've now got me _very_ curious.

  • Re: Too much biased article - I agree

    by Rob Conery,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Brice - the numbers aren't that simple to calculate for SQL, believe it or not. To get within $5K/yr with Azure we would have to enroll in an ISV program (it's not ISV exactly - I can't remember what it is) and we could qualify for SQL Standard - this would put us in at about $5K/yr over the EC2 costs. We could also use SQL Express and not worry about it.

    I understand where you're going - but my point isn't "moot" - it's debatable at best, but a "moot" point means that it's not worth discussing given the context, so I'd say you're just a little off-base with that :).

    Anyway - the ultimate thing is that I *dont* need to be on the defensive - defending my decision to *not* use SQL Server. I'd like, on the other hand, to be on the offensive: give me one damn reason that I'd want to use it. Give me a reason to pay a single DIME for SQL Server/Windows Server etc over what I have now. Ball's in your court - hit it!

    Cash in your 401K for your startup, then talk to me about licensing for software :). That's when we can have a real discussion....

  • Re: A Glaring Omission

    by Steven Talcott Smith,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I hope you have taken heart and taken the plunge by now and re-written your app.

    I learned Rails in 2006 by porting a large PHP app I'd written for my own business. I imagine most of the PHP was equivalent to your webforms. About 60 database tables were involved. It took me two months from zero rails knowledge to rewrite and pick up new features at the same time. The ruby code was about 1/5 the size of the PHP code.

  • Re: Too much biased article - I agree

    by Brice Cave,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Rob:

    I agree with your comment about the point not being "moot". It is absolutely debatable. My choice of words was too strong.

    I didn't even consider that you would have to be on the defensive. Your set-up is still cheaper than an MS set-up would be hosted on Amazon theor pricing is different per proc time. My point was that there are more options to using the MS platform that are a lot cheaper than what you proposed as the alternative.

    Off the top of my head the support argument comes to mind, but honestly, I haven't had to use MS support all that much on the custom software side of things (mostly on infrastructure issues and that could be mitigated by using a hosted solution...let them worry about infrastructure). Community support has brought me through more troubles than having to "phone home".

    Another argument for using MS platform would be that, personally, I wouldn't have to spend time ramping up on another platform. Given the time I had to write the backend (6 weeks) it would not have been in my best interest to switch platforms. I would not have been as productive. It is possible to start something up on an MS platform that is cheaper than what you outlined in the interview. You don't even have to use SQL Server... Just replace the backend with your choice.

    Ultimately, you should use what's best for you and your business. Just make sure that you compare apples to apples when determining cost differences.

    Brice

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT