How Using jQuery’s $.get() Can Cause Subtle Bugs in Single Page Apps

While working with a single page app I inherited the other day, I ran upon a few very subtle bugs where I would save data on the screen and it would update in some places, but look like it wasn’t being updated in others. It was maddening, and it ended up just being the difference between getting information from the server via the $.ajax() function vs the $.get() function, which I’ll explain after the break.  Subtle bugs are the worst, but they’re even harder when you’re using a lower level library like jQuery to build a single-page webapp when there are special-built libraries like Angular.js, Ember, and Knockout designed specifically for this purpose. Even still, sometimes you may want to use jQuery to add some dynamic-ness to your app, so I won’t judge!  If you do, you HAVE to remember this difference: Continue reading…

3 Ways to Web Test that will Change Your Life

As a web developer, it’s important to make sure our web apps and sites have a great experience for users no matter what browser they’re using. One of the ways we can do that is adhering to web standards. When we don’t write standards-compliant code and markup, we’re basically betting that all browsers will just magically guess what we meant and somehow do the right thing.  Once you’ve run your markup through http://validator.w3.org, and made sure to use feature detection instead of browser sniffing, which doesn’t work anymore, the next step is to test on actual browsers.  If you only have a Mac, though, how do you even go about testing IE in the first place?  For starters, that sounds expensive…getting a Windows license, maybe hardware, not to mention different OS licenses for IE11, IE9, etc.  What if I told you that you can test IE for FREE (any OS/version combination that’s relevant today)?  Here’s 2 different ways how: Continue reading…

Productizing Software Components

One of the most fun things as a software developer is building really awesome components and APIs that other developers will use.  With the current popularity of Github that capitalizes on this love, and with NuGet, we’ve seen an explosion in the ability for components to become popular and be reused by other developers.  The only problem is that this trend is lagging behind in the enterprise.  On top of that, reusable modules in the enterprise setting typically consist of random project references using svn:externals (yea, I didn’t know what that was either, but apparently some people use it for dependency management), .dll includes from who knows where, or worse.  Components may seem awesome to the developer that made them, but are they really reusable?  The true test of reusability and maintainability is after you’re gone, when there’s no documentation and someone new has to use (or worse, modify) the code.  That’s why I’m proposing you productize your components.  Here’s how… Continue reading…

[MSBuild output] CSC : fatal error CS2008: No inputs specified

Today I was setting up an automated build using TeamCity and came across an issue where the build of the solution kept failing.  The only reason that was given was this:

[MSBuild output] CSC : fatal error CS2008: No inputs specified

Turns out that MSBuild actually fails the whole build when you’re running it from the command line like this if there’s not a file that it can build.  The project in question was actually just full of XML and configuration files that other projects referenced and got published with a NuGet package to our private feed.  To fix it, I just added a simple .cs file, so that MSBuild had something to do.  :)

Here’s the code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Configuration
{
class MSBuildBugFix
{
// MSBuild has a bug where if no source files are found, the build fails when
// running from the commandline (or in our case, TeamCity). This file is only here
// to allow the build to complete.
}
}

 

IE11 Brings Long-Awaited, All-New Developer Tools for Single Page Apps

Today at Build 2013, Microsoft announced IE11 that ships with Windows 8.1.  Actually, before I go any further, I want to say that they should have named this release Internet Explorer 12. Like a smart kid that skips a grade in school, this version brings so many features (WebGL!!!!) in compatability, performance and an all-new completely awesome dev tools (yes, you heard me right!), that they should just skip to the next version number.  This is literally the version of IE that developers have been screaming for since IE8.  I’m not kidding.  For the first time in a long time, IE is now a DEVELOPER’s browser. From IE9, MS has focused on performance and interoperability to the point where developing a standards-compliant site literally means it just works (99.9% of the time in IE).  In fact, JQuery 2.0 now has more fixes to support bad standards implementations in Chrome, Safari, and Firefox than IE (true story). Here are my favorite updates for IE11: Continue reading…

How the Xbox One lost me, and then won me back with 24-Hour DRM and the cloud.

I love my Xbox 360.  Or, 360s, I should say.  I’ve had 4 over the last 8 years with some dying and some traded in for newer models.   I’m an Xbox fan, but mostly, I’m a fan of technology and progress (and my PS3, too).  I love console release years because of all the new upgrades, and especially the graphics.  This is the first real year where we’ve had innovation in the online space by everyone, and it’s very exciting.  This week I was appalled by the 24 hour check-in.  I even tweeted that I’d cancel my preorder if they kept it.  I was serious. Here’s how Xbox won me back. Continue reading…

IE10 on Windows 7: Happiness for the Web

Today is a great day for the Web.  IE10 has officially been released for Windows 7 (Sorry, XP, you’re what, 12 years old now?).  This release will play a significant role in getting the majority of the web up to the latest version of Internet Explorer, which is THE release we’ve been waiting for as web developers for years now.  IE “just works”.  With huge strides in interoperability, a 60% increase in supported web standards over IE9, IE10 allows you to write standards compliant HTML and JavaScript and know that it’ll work across all modern browser, including IE10.   This DRASTICALLY reduces development time for web applications and makes the web the best platform for delivering apps (IMHO, of course).  Not to mention it’s the fastest browser on Windows 7 now.

With great power comes great responsibility.

Ok, now that IE10 is standards compliant, there’s no more excuses for web developers.  It’s now on US to write standards-compliant code.  If we do things like checking for IE across the board and serve up IE7 JavaScript, then you are making the web worse, not IE.  If we were to check for Chrome, and run a totally Chrome-specific version of code, that would be unnecessary complexity, and a degraded user experience.  Nowadays, the best practice is feature detection.  By that, I mean doing checks like “does this browser support feature X?” instead of “Is this browser IE9?” Even checking for a particular version can introduce issues if there is a bug or a patch that comes out mid-stream, for example.  So, make sure you use things like Modernizr to ensure you check for features specifically.  In addition, this makes your code work better across even MORE browsers, not just IE, Chrome, Firefox, and Safari.

IE 10 Auto-updates Incoming

Most users will auto-update to IE10 over the coming weeks/months, though if you’re on Windows 7 and want to get rolling sooner (like, now), then you can download IE10 here.  If you want to have a little fun, go play Minesweeper (yes, THAT Minesweeper) in IE9 and look at the performance, then go download IE10 and check it out to see the performance improvement.

Happy browsing!