sajidnizami

People who were fired for being flash developers came back and designed the same stuff with Ajax/JavaScript.

We're still stuck with badly designed sites. At times you can just use a simple hyperlink to open a document and don't need a JavaScripted window that breaks apart on mobile browsers with small screen size.

Your argument makes most sense around here :)

Always find maps.nokia.com better on my iPhone. Best part is it works even in places others fail. e.g. UAE.

Odd. Every other place in Middle East is listed, except the one with the most tourist attractions. Where is Dubai?

In my opinion, just like politicians are worthy of public scrutiny, the people in power should be too. If a person's actions and views affect population, they should be known to the people who it effects.

Having said that, it becomes difficult to draw the line. Stuff like this does have potential to create anarchy, which doesn't benefit anyone.

There was an old vision that machines would do the stuff for you somewhere back in the day.

Sad that we've got to a point where we can make this possible but won't because we can't trust pie in the sky.

Torn between the two options and can't decide!

Is this the difference between US and UK market?

I remember reading something different for US:

http://articles.businessinsider.com/2011-10-06/tech/30250041...

Wow :) The resounding one.

Here is another market. Pakistan, India's neighbor did similar thing three months back. Good to see that as internet penetrates this region it is with a good capable browser.

http://gs.statcounter.com/#browser-PK-monthly-201106-201108-...

It is difficult to develop when rendering on all browsers is different.

I do agree with him, one platform that did what we told it to. All hacks were documented.

However I don't miss it. Plenty of capable platforms out there that can help build browser compatible sites quickly. Besides if you have to resort to bold inside an option tag, your design has some other flaws.

My favorite is still web kit. I hope it gets more share.

Edit: try putting image tags inside option. I believe only FF renders it. I could be wrong though. It's been a while I've worked this deep with HTML. The DTD never allowed yet FF renders it.

Edit: I was right, he is using option tag to do something it is not supposed to. http://www.w3.org/TR/html-markup/option.html I suppose he missed IE6 for a reason ;)

I am just curious. What .Net libraries do you find messed up?

I don't think this should even be a discussion. If it covers costs well and your solutions work, discussing this doesn't matter.

I started with using .Net for a startup four years ago. Back then there were no Redis, NoSQL wasn't even a invented as a term, cloud servers were just a concept and scaling wasn't anybody's primary concern. In four years the only optimizations I ever did were done via SQL Server profiling or just by modifying a bit of code. I pretty much learnt .Net during this time and the sites I work for get pretty hammered at their peak times and handle well.

So yes from experience .Net is a good starting point. If you know the internals you can probably write and architect code that scales well too without falling back on NoSQL services. You won't need to go looking for complicated PHP cache solutions etc, you won't need to get in the trouble of selecting complicated frameworks. The whole setup gives you ease of mind.

No arguments against LAMP or other environments. Just that I always found .Net to be easier to work with!

I am with you. I've just written powershell scripts that work in the following manner.

1. Make a dated folder and copy the new build to the folder on all servers. 2. Point IIS to the folder on all servers.

Just in case a backup powershell script is kept. It works by just pointing to the previous dated folder of the build.

Not sure why this is such an issue. Solutions can get complicated and I don't think any tool can work properly in all scenarios especially when downtime is a concern. Thats why scripts exist.

Currently my solution is on Amazon, and if there was a way I'd integrate the load balancer with the scripts so that when a server is being updated load balancer doesn't send requests to it. However IIS is fast enough so this is just part of a wishlist.

Sorry. My mistake. :)

Gap of about 20ms between compiled Linq2SQL and this looks enticing. I guess this can be used at hot spots with optimized SQL queries using existing LINQ2SQL entities.

Definitely not for everyone. The whole reason it exists perhaps is to kill SQL translation time and avoid dealing with data readers.

Kudos for making it OSS.

Also, Entity Framework takes about 800ms unoptimized. That is almost a second to execute a query. I can't begin to imagine what the performance of its solution would be in the hands of a new developer.

Edit: I misread about the EF performance. Sorry about that.

Exactly.

Initially they weren't using anything OSS but moved to HAProxy and Redis. They even help update HAProxy from time to time.

http://nosql.mypopescu.com/post/2669915777/powered-by-redis-...

They are part of Bizspark program so they got free licenses. They don't even have much hardware.

Important part isn't caching. You can just create HTML copies off a page and serve them through a fast server, that is a very easy cache.

Difficult part is smart caching, cache getting updated when they need to be and persisted properly to the DB. These guys have nailed it in my opinion.

I often lookup these guys and optimize my own sites and have been following them since their beta phase.

SO is the best case study of a startup scaling with .Net. Whenever I read their infrastructure stuff I cringe I am not in their team.

You are right about candidates.

I had the same reaction to SEO at first. See SEO guy is partially right. It involved page load times. Larger viewstate means longer load time and that gets penalized by Google.

I remember Velocity and articles on it initially. Thanks for the help. I am looking up AppFabric now.

See I prefer sticking with one flavor of tools because its easier for developers to adjust. TBH MS does supply almost everything from grounds up. I only had to look elsewhere for advanced distributed caching frameworks. In fact before switching to Amazon EC2 our old datacenter was running MS VMM and our stack still didn't have anything other than MS software.

Thinking that would help is a mistake. Take it from someone who went to optimize SQL Server 2008 R2 to its limits.

Cache framework's are absolutely necessary. The whole idea is to avoid a SQL Server hit and return a cached data object in memory. I think Stackoverflow is the best case study here.

All these new frameworks are designed to work with OSS tech. So lets say some better NoSQL platform comes out, it supports OSS technologies first. .Net comes later and sometimes it is difficult to decide which client library to pick to connect to the NoSQL service. OSS client libraries would mature early and .Net libraries would take a little time.

Connecting OSS tech and MS stack is getting easier but still leaves you with a lot of uncertainty.

This is an example: http://wiki.basho.com/Client-Libraries.html These guys have Erlang client but there is no support for .Net.

StackOverflow's architecture these days is not just Microsoft stack. They are using Redis and whole load of other OSS tech to get things working. Here it is interesting to note that this is what they started with: http://blog.stackoverflow.com/2008/09/what-was-stack-overflo... and this is what they are currently using http://meta.stackoverflow.com/questions/10369/which-tools-an...

I find it sad that these days MS is laggin behind. It is difficult to get Cache frameworks and other infrastructure working with MS Stack if you got a high performance website.

Web forms were designed back somewhere around 2002 to compete with the likes of JSP etc. They still work well for their domain, which is intranet portal etc.

MVC however is designed from grounds up to deliver speed and web standards compatibility. Building for web these days with Web Forms is just wrong. But yes, most to actually bend Web Forms to deliver requires wizardry.

It does but I think you misunderstood the point.

Most .Net developers are working on intranet sites. They don't have problem with large footprint pages.

When they move to internet and public domain websites, they are newbies. It takes them a while to adjust to the way internet sites are written. SEO optimizations, CDN usage, Ajax calls etc are pretty important on internet site than on intranet site.

Imagine using a Update Panel to code for an internet website. It would create enough junk javascript to delay a page load but it works fine on intranet. To fix this jQuery or some other Javascript framework must be brought in.

Longer page would increase page load time. A longer page with viewstate at the beginning would delay loading of content. Google penalizes pages that load slower.

http://googlewebmastercentral.blogspot.com/2010/04/using-sit...

Something like this: http://stackoverflow.com/questions/1185984/is-viewstate-bad-...

Yes I talk to them that we have a high traffic site and we lose them because they don't know about building them. Besides you won't find many Microsoft stack sites dealing with scaling issues. I personally looked up Stackoverflow scaling case studies to design my solutions later.

Back in 2005/6 URL rewriting was still pretty difficult. I started out back then. I converted to MVC completely when 1.0 version came out specifically to address the SEO concerns.

But I guess our discussion is swinging to technical side :)

I too work with sites hitting high visitor count but I have to agree there with the article. Most .Net people I've interviewed think page load speed doesn't matter. They write code to satisfy the requirement and are quite good at it, but it ends there.

Remember when people used ASP.Net web forms and it was hard to get rid of viewstate in the rendered page, and only the people who knew internals of platform well could fix it. It drove SEO's mad and they started to recommend staying away from web forms.

I agree with you on the staging and testing servers. Not having them is planning for disaster.

Scalability is relatively new hiccup; given the fact that only in past few years users have swarmed the internet. Sites never expected that and developers weren't prepared. They learned mostly by trail and error and reading case studies and then figured out what to do. You would find inexperienced PHP devs who don't know scaling just like you would find .Net devs.

I think the article has the right notions. Stack doesn't matter, a team of highly motivated devs who can milk the technology involved is more important.

I support your statement.

Read up on the author too. He was voted bigot of the year last year and has a cred. I am not sure why this even got attention in this place.