Try out these guys, who read an obscene amount of blogs and post the cream of the crop on their own blogs.

• A Continuous Learner’s Weblog (Steve Pietrek)
• Christopher Steen
• Jason Haley - (psst, you smell)
• Larkware News (Mike Gunderloy)

And of course dzone.com which is where I get about 90% of my traffic.

Want to compress your CSS and Javascript files during your build process? Here is what you need.

Download CSSTidy, and add the executable somewhere on your build machine.

Download and install the MSBuild Community Tasks, or you can do just the Jazmin JSCompress task, though I didn’t do that so I don’t have any source XML for that.

To be clean, I added a Property for the location of CssTidy

<PropertyGroup>
<CssTidy>c:\BuildTools\CssTidy.exe</CssTidy>
</PropertyGroup>


Also I registered the MSBuildCommunityTasks

<!-- Required Import to use MSBuild Community Tasks -->
<Import Project=”$(MSBuildExtensionsPath)\MSBuildCommunityTasks\
MSBuild.Community.Tasks.Targets”/>


Then, build a list of all the files you want to compress.
<ItemGroup>
<CssFiles Include=”$(websitedir)\**\*.css”/>
<ScriptFiles Include=”$(websitedir)\**\*.js”/>
</ItemGroup>

$(websitedir) is just a variable for where the website is, obviously I could have used c:\inetpub\wwwroot or whatever instead.

Then I build two tasks, one that calls CssTidy…
<Target Name="compress_css">
<Attrib Files=”%(CssFiles.FullPath)” ReadOnly=”false”/>
<Exec Command=”$(CssTidy) %(CssFiles.FullPath) %(CssFiles.FullPath) –template=highest” />
</Target>

If your not familiar with the %() syntax, this causes MsBuild to iterate over each item in the CssFiles collection and run this tag for each instance. Otherwise I would get a semi-colon delimited list which nothing handles that well.

The Attrib tag makes everything write-able thus the ReadOnly=”false” attribute, this didn’t seem to be an issue for CssTidy, but it was for JSCompress and I put it here just incase it becomes an issue one day.

The Exec Line executes the CssTidy program, with the FullPath of the searched file (this is meta-data of the item), its included twice to represent the input and output. The –template=highest portion just says do your absolute best!

Then the you add one for JSCompress…
<Target Name="compress_js">
<Attrib Files=”%(ScriptFiles.FullPath)” ReadOnly=”false”/>
<JSCompress Files=”%(ScriptFiles.FullPath)”></JSCompress>
</Target>

Attrib we’ve been over, this is really important here, as JSCompress was failing on readOnly files.

Then I tell it to run the JSCompress tag for each of the ScriptFiles. I feel like I’m explaining exactly what your seeing and already understanding. I hate it when people do that.

Then you need to call these targets.
<CallTarget Targets="compress_css"/>
<CallTarget Targets=”compress_js”/>

Not much to it. Hopefully this helps you bring quick loading times to all the web surfers of the world.

Seriously, you stink, your blog is ugly, and I’ve enjoyed your daily reading updates for far to long.

Its likely the rest of you are curious why I’m using my blog to Flame and smear Jason Haley. Well, if you didn’t notice, first read this post…

Were through Jason Haley

Then check out Jason’s post the following day.

04/15/2007 Interesting Finds

Hmmm, so you flame him, then you get on his daily blog read list. Hey I can do that! So if you ever read this Jason, you can bite me! Which shouldn’t be all that unpleasant after that kick ass salsa recipe you helped me find.

To continue the trend, if you flame me, I’ll add you to my OPML!

In a short but sweet post over at Ajaxian, Dion Almaer interviewed John Resig, of Mozilla and jQuery about Javascript Libraries, and the reasons for said libraries.

• Avoid repetition
• In JavaScript: Distance from browser differences
• In C: stdlib distances itself from the platform differences

First of all, whats up with #3? Secondly, I’m totally digging points #1 and #2 in the current construction of the library at eProject. Refactoring old code to new code thats twice as good makes me feel so good, like some kind of Ego Building Sundae.

So what do I have to add? That #3 should have been easy test injection.

We’ve been struggling how to implement JSUnit at work for quite some time, testing a function on an ASPX page just isn’t very practical, and a lot of the functions in the old files were intended for a specific usage. Yet, once all the logic from the old pages has been moved to the library, it has been written with re-usability in mind, and writing a JSUnit test page turns out to be just another page in the system.

If you don’t know much about the Dojo toolkit, its a vast Javascript library with some very cool framework features. One feature I liked was the ability to add packages to a page depending on your need, so if you needed ajax, you could add the following script.

dojo.require("dojo.io.*");

This way you only get the bits necessary per page, this doesn’t make sense for something as small as Prototype but as I was building the JS Library for eProject it made sense to include this feature since we have so many packages available.

I’ve just recently been running into a problem implementing a Dojo style dynamic package inclusion system in our companies new JS Library. I didn’t want to dig into the Dojo source code to much, so I implemented a rather crude solution of taking the string to require, converting it to a file system path and appending a script element with that path to the page.

dojo.io.* would become dojo/io.js

This was a really simple solution and worked great in FireFox, but in IE (eProject is only concerned with these two browsers at the moment) , there were loading issues. It appears that unless the file is cached, it took its own sweet ass time loading. Annoyingly this made it seem that all my unit tests were passing when in fact, they only were passing because the dynamically included packages were already cached in most cases.

So after some digging into the dojo source a bit, I’ve discovered how they avoid this irritating little “feature”. The dojo toolkit uses an XML HTTP GET (for cache support of course) call to retrieve the contents of the file from the server, and eval()’s the returnText.

Ever since I read this, I’ve been trying to avoid it, it means I have to write custom XML HTTP Logic in the base framework level, and I have to do eval()’s on large blocks of text, but because I don’t fully yet understand why IE isn’t loading the script files as the DOM elements are being added to the DOM, I’ll need to implement this for now. It does give me the advantage of knowing that any logic I do include via the package inclusion system, will be available after I have exited the call for that package.

If you have any idea behind the lower level occurrences here, please share. Till then, I got some re-writing to do.

Getting information on JavaScript performance really is like finding a female programmer. (No punchline to protect myself from the females.) So excuse me if you’ve heard some of this before, but for those JS Perf virgins out there here’s some of the notes I’ve compiled.

Caching

In Javascript you can copy references to Arrays, Functions, Dom elements, anything and once you have that element cached in a local context, you avoid some icky lookups. having lots of periods in a reference (sys.ajax.enums.serverparsed.transformers.optimusprime) creates a lot of object lookups that will hit you on every lookup. In the grand scheme of things, this isn’t that big of a problem, often you won’t be doing any operation often enough that the milliseconds this call would save in any particular call, but something to keep in mind.

Don’t hit the Dom

The last big script application I wrote was an excel like application, so on some occasions there were 450 x 60 (27,000) cells on the page, which I would have to iterate over and perform some operation. In this application the number one performance gain was to cache the properties of each cell and determine if any operations are necessary based on that cached version. Avoiding .innerHTML for reading, not using getAttribute, setAttribute for storing information about the cell, and don’t store references to script manager objects on the dom object.

Prototype’s

The difference here is memory, you only need one instance of a function, unless for some reason you construct the string of the function, but for the most part, if you use prototypes you’ll only get the one instance of the function instead of an instance for each instance. Got it?

Loop backwards and Duffs Device

Put this in the “Almost to small to care” folder. Looping backwards for some reason, gets you a few milliseconds on your loop. Duffs device is a method of executing the same code while not needing to loop quite as much. Its worth it in loops of several thousand iterations, but overall it hurts readability and bloats the code, so look for gains elsewhere.

switch (count %   /* count > 0 assumed */ { case 0:        do {  *to = *from++;

case 7:              *to = *from++;

case 6:              *to = *from++;

case 5:              *to = *from++;

case 4:              *to = *from++;

case 3:              *to = *from++;

case 2:              *to = *from++;

case 1:              *to = *from++;

}  while ((count -=  > 0);

}

Manager Objects

In this aforementioned excel like application, I adhered to an object oriented methodology, which turned out to be neurotic. This application ended up having thousands of objects in memory just to manage each cell. It would have been much smarter to have one object that manages all these thousands of cells. This also allows for removing the reference on the dom object to their individual script object instance. Instead I would put just a string identifier on the object which I would use to get from a hash.

var scope

This should be in the obvious section, but if you don’t use var when declaring your variables, the JS engine searches up the chain looking for a property to set, and if it doesn’t find it, then it uses a global variable on the window. At which point references to the variable become global property lookups.

Leaky Memory

Memory holes are causes by circular references that confuse the garbage collector. Namely, DomElement -> Script Object -> Dom Element. Avoid at all costs, if you need, save a string id on the Dom element, and use that to retrieve the script object when you need it.

function Obj(xEl) {

 this.Ref = xEl;

}//--- Memory hole in the making

document.getElementById("el").xScript = new Obj(document.getElementById("el"));

eval()

Everyone knows this is already a performance hog and you shouldn’t use it. Not sure why? Well, when the page loads it goes through all the Script on the page, parses it and loads it then shuts down so the page can go about the rest of its business. When you eval, you start this loading engine again, and this is as heavy a process as it sounds. While not as evil, the new Function(”") constructor is just as evil, it uses an eval to construct a function from a string value. Never eval to get a variable reference, you can use the bracket structure to pass the name of the variable to its parent object

window["location"]["href"] = "http://www.blackbeltcoder.net/"

If you can think of any others, please post a comment and we’ll get those added. I’ll probably add a part 2 as I remember a few other tricks.

Sashimi, in the Scrum religion is a term used to indicate a bit of completed functionality. Yet the meaning of completed in this instance is up to some debate, according to Ken Schwaber an old veteran and founding father of Scrum…

This introduces the concept of sashimi, a slice of the whole equivalent in content to all other slices of the whole. For the Daily Scrum, the slice of sashimi is a report that something is done. “Done” implies accepted engineering practices that indicate that done means coded. Or maybe it means coded, unit tested, checked in, built, and acceptance tested. Either way, there must be a common understanding; otherwise mistakes may be made as various team members inappropriately adapt based on incorrect assumptions of what they inspected. Similarly, the increment created every iteration must be well-defined and similar every time. In Scrum, each increment is an increment of potentially shippable product functionality.

-Ken Schwaber (http://www.coldewey.com/publikationen/conferences/oopsla2003/KenSchwaber.pdf)

So at the end of each iteration, you should have shippable product consisting of the sashimi of the last sprint. If you think about this in terms of pieces of fish and dinner, everything works great, if you think of this as programming the next version of Windows, your not going to have shippable product after a single iteration, does this mean Scrum won’t work for large projects? Or even projects that will take longer then one sprint? Not if we refine the definition of Sashimi.

• Development Sashimi

This is the amalgamation of all the completed work from the last iteration. This may not be shippable, but you can see the value of the time spent on the iteration, so its important to keep cranking these out. If your sprint is as short as a week, you will have quite a few of these before reaching the all important product owner sashimi.

• Product Owner Sashimi

At some point you will complete an iteration and the collection of the development sashimi iterations will be shippable. This is the milestone thats super important, up until this point your feature is in limbo and cannot be shipped. Its important to get here as soon as possible, the longer your in limbo you issues and can’t get all the full benefits of the normal scrum process. You can’t shift priorities (as all the previous work is wasted), you can’t ship your active source tree and you have the ability of feature/scope creep.

This seems to imply that you should never do a sprint that you couldn’t get PO Sashimi from, which is highly favorable but impossible for more reasons then I have time to document here. Just keep on the lookout for these stages, and scrum away.