Wow. Trac just impresses me more each day.
Today, it's the peer review plugin.
If you looked up the definition of awesome in the dictionary, I'm almost positive that you'd find this mentioned somewhere in the entry.
It's a component that plugs into Trac and allows you to start peer reviews on code blocks in your repository. Users assigned to the peer review can view the source code in the browser and make comments on particular lines of code. There's also a pass/fail mechanism to vote on how to proceed with the code. The truly badass part about it is the GUI implementation.
Here's a screenshot of it in action:
If this isn't the definition of awesome, I just don't know what is.
Great use of AJAX. I did something similar for a different app I wrote recently:
I love this approach for web application design since it's so much less intrusive than opening a new window and offers far better customization of the look and feel of the overall UI. The big problem is that it's probably not accessibility standards compliant; many screen readers will not properly pick up the change in the UI and the newly inserted HTML content. If such domains are not a concern, then such a visual design pattern is definitely the way to go if you're building a web based GUI which requires multiple subscreens.
I feel like a little schoolgirl (and a little perplexed). I've been following Nintendo's next console quite closely for the last few months. Going by the codename of "Revolution", Nintendo has taken what many seem to be a big gamble by going in the opposite direction of competitors like Sony and Microsoft.
Today, we see how Nintendo continues along a path of defiance of the norm; Nintendo's "Revolution" console will officially be known as.....
Check it out for yourself here: http://revolution.nintendo.com/.
As in "we."
While the code-name "Revolution expressed our direction, Wii represents the answer.
Wii will break down that wall that seperates video game players from everybody else.
Wii will put people more in touch with their games...and each other. But you're probably asking: What does the name mean?
Wii sounds like "we," which emphasizes this console is for everyone.
Wii can easily be remembered by people around the world, no matter what language they speak. No confusion. No need to abbreviate. Just Wii.
Wii has a distinctive "ii" spelling that symbolizes both the unique controllers and the image of people gathering to play.
And Wii, as a name and a console, brings something revolutionary to the world of video games that sets it apart from the crowd.
So that's Wii. But now Nintendo needs you.
Because, it's really not about your or me.
It's about Wii.
And together, Wii will change everything.
Wow. Crazy and brilliant at the same time.
Maybe it's just me, but there are some little things that bug me to no end
(my wife thinks I'm slightly OCD).
Lately, it's bad spelling and grammar.
I don’t know, I simply don’t think it’s acceptable in an age when a proper
spell check is only a button click away, why people have to put up with
misspelled words in professional documents and email exchanges.
It bothers me so much that once I see an email or document that has terrible
grammar, misspelling, or punctuation, I am no longer able to mentally process
the document as my mind shifts to pondering what could be so pressing that the
person that composed this document before me couldn’t hit the spell check
button. Most likely, the author simply
doesn’t care? Such documents simply give
the impression of a rushed reply with no concern for professionalism,
craftsmanship, or interest.
Of course, grammar is probably the hardest aspect of written English, so I
tend to not mind grammar errors as much unless they are obvious ones (use of “a”
versus “an”, for example).
What’s worse is that I get emails like this all the time from recruiters regarding positions. Not only from those who speak English as a
second language (I can give some slack there as my mom has terrible spoken and
written English), but it’s even common from native English speakers.
I don’t understand; in such a scenario, wouldn’t you want to be more
professional in mannerisms and communications to assure the possible candidate
of the professionalism of your organization?
I know I would.
As a side note, I'm thoroughly impressed by the written English of many Europeans who do not speak English as a first language, like SNE
Today's entry is Windows Installer XML (WiX for short), an open source project (the first?) from Microsoft that is used internally by Microsoft development teams for building installers for many of their products.
I first used it more than a year ago when I was at Merrill Lynch. I had to build an installer for a Windows Serivce and I wanted the service to auto-start after installation. I was totally baffled by how to do this in the VS installer projects (is it even possible?) and somehow ended up stumbling across WiX. It worked great It was a little rough going because there was so little documentation and Net knowledge regarding usage.
Since then, I haven't really had a reason to look beyond the built in VS installer projects, but I'm working on another complex installer scenario now and decided to check in on WiX again. To my surprise, there still doesn't seem to exist a UI to design WiX installation packages (at least none that I came across via googling).
However, I did find a very well done tutorial.
Of course, Rob Mensching's blog is full of news and developments on WiX.
Rob mentions in his first post on the subject of WiX that:
Internally, teams such as Office, SQL Server, BizTalk, Virtual PC, Instant Messenger, several msn.com properties, and many others use WiX to build their MSI and MSM files today. When someone encounters a bug, the community tracks the issue down and fixes it. Now, via SourceForge.net, you have an opportunity to be a part of the community as well.
I guess it's also good to note that WiX just celebrated it's 2-year OSS status recently.
I don't understand the fascination with using Word documents for internal development specs.
For one thing, a Word document is very inefficient when it comes to conveying matters of code and design. No syntax highlighting. It constantly warns me that I'm misspelling my words. It wants to adjust my indentation and paragraphs for me when I put formatted code into a document.
Even more annoying is the fact that a Word document is essentially a snapshot of what was designed, at some point in time. Past tense. Unfortunately, designs change and details change as developers start to dig into the software at all levels; no one person can forsee all of the challenges in designing any medium-large software product; no one person can predict all of the different, possibly better implementations and architecture. New changes mean I get a new document in my inbox.
Using Word documents, it becomes incredibly tedious to now maintain this constant state of change. Everyone on the team has a copy. Yet, in order to maintain any sense of order, only one person can be the source of all of the change. Useless. Inefficient. Terrible.
There's a reason why typewriters were replaced by word processors.
Enter Trac. It does everything right that Word does wrong for documenting software specifications. The Wiki system links text to existing tickets, source code files, and other documents without effort. It's infinitely malleable and entirely flexible; in a sense, it's "live". It highlights code and allows full flexibility in formatting the code. It offers a view into your source repository. It has a system for creating milestones and linking tickets to those milestones. You work on documenting your part in your Wiki page, I'll document mine in my Wiki page. All the ideas, concepts, and thoughts now sit in a central repository that is constantly evolving as the project evolves.
In short, Trac is damn near the perfect software project management application and its usefulness spans the entire lifecycle of the project, from initial design to maintenance to continuing development.
Unfortunately, I'm the only one on my team using it :-S I don't get it. What's the fascination with Word when an infinitely better solution is available? I set it up and demonstrated it with the hopes that these tech-heads here would dig it and see the awesome potential it has for transforming how the development process proceeds. And yet, here I sit, baffled by why such a tool is laid to the by-ways for Word.
I guess I'm still not there yet...
A certain sense of glee overcame me just now as I was checking the activity logs.
Perhaps one of the most exciting (yeah, I realize I'm exposing myself as a total geek by saying that) things about having a blog (or any website in general) is checking out the activity logs and seeing people coming in and out of your website (hopefully finding something useful).
The idea with my Workshop series is to provide bits of knowledge that I've gained through the various projects that I've worked on in the past in simple, easy to follow and easy to digest chunks (with lots of pictures and code samples to boot).
Imagine my surprise (oh, Joy!) when I tracked a link to my page from Google groups! It's one thing to have searches hit your pages...it's an entirely different feeling when someone actually references your site.
Happy is me.
Yes, I'm a dork. And probably a noob, too
Oh yeah, we're kicking it up with the DevTool entries.
That's typically what happens as I ramp up on a project; I'll end up coming across a whole slew of awesome tools that I end up aggregating in my C:\Program Files directory (my application menu is about to go past the second page...I had to uninstall a lot of stuff previously to get it back down to two pages).
Today's entries are tools to help you think "contract first". I hadn't really thought of XsdObjectGen.exe as a tool that helped you work in a contract first fashion, but Peter Bromberg seems to think so and so does David Truxall.
Unfortunately, XsdObjectGen.exe, as great as it was, is ill suited for .Net 2.0 and the introduction of generic types and lists. I briefly contemplated using it for my .Net 2.0 project that I'm on now, but couldn't bring myself to it; there must be a better way, right? Well, up until now, the only other .Net solution that I had come across was Matias Wozloski's GAT implementation (with slight modification?) of Daniel Cazzulino's (kzu) version of XsdObjectGen. Having looked at that and the new xsd.exe that ships with VS2005, I have to say that I'm sorely disappointed in both since they rely on the XmlSchemaImporter and XmlCodeExporter classes to do their dirty work. The resultant markup is not nearly as nice as the output from XsdObjectGen.exe. As I've mentioned in the past (see the end of my workshop on XsdObjectGen.exe), while kzu's implementation is obviously much more flexibile since you can create new extensions and what not, it is ultimately somewhat clunky and not as easy to work with.
I briefly contemplated extracting the source from XsdObjectGen.exe and rewriting the codebase (it uses sort of an "intelligent templating" approach) to utilize some of the .Net 2.0 code features and generate better code, but after digging through it with Reflector, I realized I didn't have enough time (and I probably didn't have the rights) to extract and rewrite the codebase.
Enter dingo and thinktecture's WSCF. While dingo is still strictly a .Net 1.1 tool, the project leader has a recent news item that claims forward development will continue this summer after some more work on a rules engine (anyone know of .Net APIs for working with RuleML?). WSCF, on the other hand, looks like it's good to go with respect to .Net 2.0.
So have a look at WSCF. I'll be downloading and evaluating it today and keep this updated with my take on it.
Update: See comments.
I installed an updated version of the NUnit VS add-in (aka: TestDriven.Net) today and discovered this little tool called NCoverExplorer. Curious, I started to dig into it and that lead me to NCover. NCoverExplorer is a GUI interface to NCover output files.
What is NCover? It generates code coverage information when it runs your NUnit tests so that you can see how much of your code base your tests are really touching (I perfer the output from Cenqua's Clover.Net, but I guess that's just a matter of using a better XSL transform?).
Both are great tools and should work their way into your development cycle!
It helps to have a simple batch file to run it:
"C:\Program Files\NCover\NCover.Console" "C:\Program Files\NUnit-Net-2.0 2.2.7\bin\nunit-console.exe" "..\bin\debug\SomeProject.Tests.dll"
In an automated environment, you'll want to take out the PAUSE. It's only there so that if you're running it manually, you can watch the result of the run.