In an earlier blog post, I discussed JavaScript functions at length. If you found yourself on Team Scar before, hopefully that post made you start thinking about switching sides; conversely, if you already liked JS, I hope I didn’t ruin it for you! I mentioned that I would cover JavaScript scope in my next post, so let’s get on with it!
If you learned C/C++, then went on another C-style language (i.e. Java or C#), then you are very much like me. Scope in those languages is created by { }. In JS, relying on { } to define your scope is just pointless. Functions create scope. Only functions can create scope and anything outside of a function exists as a part of the global object. Most of the frustration towards JS is probably due to developers misunderstanding it. Sure, the language does have some design flaws, but what language doesn’t? Read More…
Have you ever worked on a project that seemed to eat any memory available? If so, chances are you have encountered a memory leak. Memory leaks in SharePoint are very common. For example, using instances of SPLimitedWebPartManager can be a cause of memory leaks. Why? Turns out that SPLimitedWebPartManager instances instantiate their own SPWeb object, but don’t properly dispose of them: a bug in the SharePoint 2010 SDK. It seems that one of the only ways to discover this ghost memory leak is in production. Or a little utility, built by Microsoft, called SPDisposeCheck.
You can run SPDisposeCheck in the command line, but I thought it would be nice to integrate it into a project. These are the steps to integrate SPDisposeCheck into a build: Read More…
Are you a developer who adamantly hates JavaScript and would give up your firstborn before taking on a project that involves said language? If so, you are not alone. JavaScript seems to be one of those languages that polarizes us into two groups:
TEAM SIMBA
Members of this group believe JS is the rightful king of the web (and possibly server). They believe JS is easy and fun to develop with and mature enough to handle anything you throw at it. They praise the language for its impressive developer community and rich ecosystem of libraries.
TEAM SCAR
Members of this group believe JS is a twisted and deceitful language. They are obstinate that JS is a broken language flawed from its conception and mired by designers and the 90s. They see the language and its associated tooling as too “immature” for any real work. Of course, all JS libraries are just the hyena minions sent upon the web (and now server) to ravage and uglify the beautiful landscape that computer scientists have diligently built over the past six decades.
I believe both groups have valid points. JS can be a bit idiosyncratic at times. I have been burned a few times by many of the questionable “features” of the language. For example, double-equals is not equivalent to == present in many C-style languages:
if ("" == 0) //this statement is true...
console.log("Seriously?!")
The above code snippet is known to make minds explode!
If you are like me, you probably learned C or some language based/inspired by it. The reason behind the behavior above is that == actually is an equality operand that performs type-coercion first. But there are also some very neat things going on in JS, and perhaps the best attribute is function-passing. There is great power in the ability to pass functions as arguments — just ask any Scala programmer! While functions are fundamental to JS, they are a topic that confuses a lot of developers, so let’s get started. Read More…
ASP.NET 4.5 has introduced some cool new features and enhancements for web developers using Visual Studio 2012. One of the new features introduced deals with the framework’s Web Forms technology. In previous versions of ASP.NET, if you wanted to display data-bound values in a control, you needed to use a data-binding expression with an Eval statement, e.g. <%# Eval(“Data”) %>.
Using an Eval Statement to display data-bound items
This approach works, but it introduces a few problems. In my experience, the Eval statement approach is prone to developer error. If you are like me, then you have undoubtedly misspelled a member name or tried to bind to a nonexistent member. These mistakes, while trivial, tend to make themselves known only at run-time thus making them more difficult to track. Due to the Eval statement being dynamic in nature, it is impossible to enforce compile time error checking.
With ASP.NET 4.5, we can now take advantage of Strongly Typed Data Controls. These controls allow us to specify the type of data the control is to be bound to, providing us with IntelliSense (which solves another problem for me: remembering which members belong to the DataSource) and compile time error checking. Adding a strongly typed data control requires minimal effort!
In an earlier blog post, I discussed JavaScript functions at length. If you found yourself on Team Scar before, hopefully that post made you start thinking about switching sides; conversely, if you already liked JS, I hope I didn’t ruin it for you! I mentioned that I would cover JavaScript scope in my next post, so let’s get on with it!
