The Product Blog

Speeding up Daptiv load times

2007-11-26T20:00:00Z

With the power of our new dashboard functionality you can do some pretty neat things, though one of the largest benefits was the ability to create a dashboard with no parts. An empty dashboard should give enormous gains in terms of loading times as you will have a small base page and have the added advantage of not having to download any of the extra images or wait for the loading of the parts themselves.

In dealing with file sizes, your new dashboards page will be around 41k without any dashboard parts. Also if this is your first time to this page you'll have additional files such as scripts and images to download, which could total around 169k for your total transfer time. Typically you won't have to download those extra files, but it’s still something that you might be concerned about.

On other end of the spectrum, your default dashboard (such as mine on our local internal server) which probably has one of all the components, would be around 134k and including its ancillary files can get up to 300k and beyond.

The Daptiv User Experience team is very focused on getting these sizes down; we've implemented compression and new caching systems into our code base to allow you to do your work faster. We'll be reducing the amount you have to consistently download each page refresh these next few months, and in the future we hope the amount of dashboard parts on your dashboard won't be a loading time concern. Until then, we suggest that if you’re not using the dashboard components hide them for your default view, and build some other views to track all your wonderful data.

A Fallen Leaf is Nothing More Than a Summer's Wave Goodbye

2007-11-12T18:32:00Z

In Seattle you always know Fall is here when the dew arrives in the morning and the day brings enviable rain or overcast. At my house the seasonal shift manifests itself in the form of hand sized leaves falling from my larger than life maple tree. For Daptiv and our customers this Fall brings a new UI brand\skin and the the industry's first on-demand Work Intelligence solution.

Work Intelligence (WI) is a set new enterprise class report authoring and dashboard tools. Coupled with project, resource, collaboration and dynamic application data. All on top of our organization's world class SaaS infrastructure. As you can see Work Intelligence is more than a feature or function - it is a holistic solution that will allow our customers to extend the value of Daptiv PPM to new departments, business operations, and end user audiences by providing insight and decision support into all work within IT and the mid-office. If you are interested in finding out more about WI check out this informal demo I recorded last week.

As always, our Fall '07 release contains additional features that continue to extend our existing functionally, quality, and user experience. On Monday, November 18th say good bye to Summer and hello to Fall and the future of Work Management in the mid-office.

Giving some attention to Script

2007-04-19T22:15:00Z

A new initiative that probably means very little to most of you is the development of a Javascript Library here at eProject. They are all the rage these days, with more then a page’s worth listed here at the Webmaster Talk forums.

This is of course not the reason we are implementing said library, having your code in a library has some major advantages. Focusing on re-usability is a big one, so is easy testing. Previous to this initiative we didn’t unit test any of our client script, we actually have people go through every portion of eProject trying to break it. What the unit testing gives us is an instant response into the quality of the code, without having to get monkeys banging on keyboards and monitors for weeks.

eProject has been around a long time, and so has its code-base. We have scripts spread out all over the system, and having each bit go through our process is a time consuming task.

Speaking of the process, each script is getting a full cycle which includes, validation for usage, tests, re-factored, and documented. Part of the re-factoring process includes considerations for cross-browser compliance, performance enhancements, and syntax.

To you this should be reflected in more consistency in the UI components (we realize we have at least 4 different calendar components), greater quality, and hopefully more utilization to make your life easier.

Increasing Performance, via smaller downloads

2007-04-19T00:27:00Z

As a company that competes against windows based applications, and the flashy AJAX products, performance is something that is become more and more of a big deal. As our customers are dealing with larger sets of data, and utilizing our system more and more, we realize that the pauses between pages, and extra clicks are becoming an issue.

Any easy way to make load times quicker is to compress our static files, which is what I spent today doing. After our build process, we run JSCompress and CssTidy which removes redundancy and unnecessary content from the files then re-packages them.

To run CssTidy, you'll need to download the package from thier website and put the exe somewhere accessable. Then you need to add the following lines to your msbuild file.

</ItemGroup>

</Target>

One of the important things to note here is the % sign, this tells MSBuild to do this task once for each item in CssFiles, which since you recusively included all the css files in the website dir (**\*.css) should be all the css files for your project.

At this point, just do a <CallTarget Targets="CompressCss"/> when you want it to fire off, and your good.

The same is true for JSCompress, only its available as a MSBuild task, so we don't have to do this Exec stuff.

Include the task, a member of the MSBuild Community tasks

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>

Then, do as before, build a list of JS Files, and pass them to the JSCompress Task. (Documentation for this is only available offline as part of the MSBuild Community Tasks install.)

<ItemGroup>

</ItemGroup>

</Target>

Hopefully you should see the gains of this in our next release of eProject!

eProjects Experiences with JSUnit, so far

2006-11-06T23:12:00Z

So at eProject, we've recently switched to Scrum for our development purposes and the transition has been, difficult. It was easy to jump off the cliff, but were hitting every tree branch on the way down. I'll have to write another post about all that, because I would never get to JSUnit if I blabbed on and on about Scrum.

To summarize that future post in short, we now have time and the will to accommodate Javascript testing, so off I go to find a nice framework. There was two frameworks nicknamed JSUnit but only one seemed really professionally ready. So I installed, implemented, and experienced. *http://jsunit.net/

This review is made up of two separate but equally important parts, the bad, and the good, these are thier stories.

Da Dummmmm The Bad

Does not allow Remote Execution of local test scripts
- Being a self proclaimed WebDev god, I really should be able to figure this one out exactly, though the only thing I'm able to deduce so far is that the security settings won't let me run scripts from so many domains in the context JSUnit needs. This is a moderate hindrance as I wanted to be able to have the JSUnit test runner application to be run on one machine and I could tell everyone to navigate to this server to use it, but instead I had to get everyone to install the test runner themselves.
- I was able to have the test pages reference the jsUnit application script remotely, this needed to be on every page and so its nice that it was able to be centralized.
Does not allow selection of tests, does not display names of tests run.
- Am I spoiled by NUnit's simple but informative layout? And it does list the names of the failing tests, with a button that you can press to see why it failed. But It still seems like, this should be a nice little UI that would show me all the info I need to get a clear picture on what happened in one glance.
Does
not allow multiple pages to be run.
- I've not digged into how JSUnit works, but being able to cue up a list of pages with tests on them would be very helpfull. This may also solve the issue with refreshing the page and losing the URL to your test page, irritating. Grrrr!
Total lack of ability test an Asynchronous operation.
- This is the 06, I need to be able to unit test an AJAX call. Obviously I can make the call, but I can't validate the results in any way.

The Good, Yaaaay!

Damn, that was kinda easy.
- That great satisfied feeling was still there, it made the code super slim and easy, and it even made me modularize it to just about the right level.
- Installation is almost to simple, I don't think people around here feel like its a solid framework when you just have to setup a virtual directory, unzip and navigate to the test runner. Wheres the configuration file? Don't I have to install some file I don't know exists?
Pat on the back and a blind eye.
- This process has been well recieved, those with a stake in the script have been very encouraging to me to get this implemented. Testing is excited that they will have additional coverage, that they don't even have to write. Management is excited because they actually know the value of unit testing. Everyone else, well they don't have quite the infatuation with Javascript as I do, and thier lust for this framework has been tempered so far. We don't really have a lot of javascript projects going on right now, so that might change as the work comes along, but until then...
It does its job
- For all the points against it for poor UI, its still doing a very good job at its core function, which is to unit tests javascript. I feel more comfortable now then I ever have about script in the past, and its never been cleaner.