Yesterday, we deployed build #82 of the Sun Software Library into
production, and two weeks ago, we deployed build #81 into production, enhancing the library functionality in the following areas:
- New Artwork: We have some new artwork:
Other sites that want to link to the Sun Software Library can use this artwork. - Request to be a Content Manager includes a message: One of the reasons we had to change our Terms & Conditions is to allow the users to better communicate with other users. In this release, we have added the ability for a content management requests to include a message, enabling the user to tell the current content administrators why they are requesting access. ⁞ For small organizations, "where everybody knows your name", this may not seem like a useful feature, but for large organizations (e.g. think of companies the sun of Sun Microsystems), this is especially useful.
The next few releases will include more functionality, enabling users to communicate with one another via the library. - New Terms & Conditions: As mentioned earlier, we wanted to add new functionality in the Sun Software Library, enabling users to anonymously contact publishers (and vice versa). If you log into the Sun Software Library, and have previously accepted the terms and conditions, you'll see this popup, informing you that new terms and conditions are in place:
Click "Accept" to continue.
We've added this language to the Privacy section (section 6). You can view the entire terms and conditions at https://library.network.com/terms.html.
“You acknowledge and agree that Site Offerings may enable You to
allow to be contacted by Sun other Users, and may enable You to
submit personally identifiable and other information to other
Users. You consent to such contact by other Users (unless Sun
expressly gives You notice and an ability to opt-out from such
contact), and to the unrestricted, non-exclusive use by such
other Users of any such information You choose to submit to them,
and You assume (and Sun disclaims) all liability and
responsibility arising therefrom or related thereto.”
- Internet Explorer support: IE is our most popular browser, some 55% of our users use it. As such, we need to support it - all 3 versions of it (IE6, IE7, & IE8). However, we do pay for that support, in terms of engineering time, both in testing, and in fixing bugs. Primarily because of Firebug and our Mac desktops, Firefox continues to be our primary development and debug platform, with Safari being a close second. We do fully test on Windows platforms, but find that what typically works on the other two browsers breaks on IE. Recently, we've spent a significant amount of time debugging IE8, while maintaining functionality for previous versions of IE.
It's hard to estimate what our actual cost is for supporting IE6, but it is relatively high. As such, we support efforts to get users to migrate away from IE6. - We are 100% JSLint "The Good Parts" compliant: After we integrated JSLint with NetBeans, we got to work making sure our own Web UI (written in JavaScript) passed JSLint. This took us a while, given the amount of JavaScript code that we have. The first decision we had to make was what options we wanted to JSLint to enforce - we decided to leverage The Good Parts, written by Douglas Crockford. Given that this is our entry in build.xml:
<jslint4java haltOnFailure="${cqs.build.jslint.failonerror}" options="${cqs.build.jslint.options}"> <formatter type="plain" /> <filelist id="jslint.filelist" dir="${basedir}/web" files="${cqs.js.jslint.files}"/> </jslint4java>We then set this option in our project.properties file:
cqs.build.jslint.options=white, onevar, browser, undef, nomen, eqeqeq, plusplus, bitwise, regexp, strict, newcap, immed
After we cleansed our JavaScript code, we set our builds to fail if JSLint detects any errors:
cqs.build.jslint.failonerror=true
This approach has already paid a dividend: One of our developers wrote some code that worked perfectly on Firefox and Safari, but would have created issues on IE, due to IE's more stringent syntax checking. Normally, we would have caught this error during our Quality cycles, but JSLint picked up the issue by causing our Continuous Integration build to break. The issue was fixed in minutes at a relatively low cost, rather than in hours at a much greater cost at a later period in time.
This incident alone has validated our investment in integrating code inspection tools into our Continuous Integration builds.
And, no, our feelings weren't hurt! Humbled, maybe, deflated our egos a bit, definitely, but not hurt.
- Cobertura integration: In the spirit of integration of code inspection tools into our environment, we integrated Cobertura into our Continuous Integration system. We've run Cobertura before, but always manually, on an as needed basis. Now we always have an up to date code coverage report. Combined with Hudson's Cobertura Plugin, we configured our builds to measure code coverage taking into account all of our automated testing: Web Services based functional tests, Selenium based Web UI tests, and jUnit based traditional unit tests. This way, we can measure the effectiveness of our testing strategy in realtime. We still have some work to do in this area, but at least we know where we stand:
- And as always, lots of bug fixes and minor enhancements here and there...
