“Integrating JSLint more tightly into NetBeans” and other links…

Posted on 9/7/2009 by rasx()

ekschi.com: “…I still had to navigate to each JavaScript issue manually. This is a huge pain, something that I haven’t done since my earliest days as a developer, before I learned about Emacs’ next error functionality. NetBeans also has a really nice “Next Error” function that automatically navigates the user to the next error detected by the compiler. Unfortunately, NetBeans didn’t recognize the native output of JSLint. This got me thinking about building a custom wrapper around JSLint so I can transform the output to whatever NetBeans would be happy with.” This article leads to jslint4java.

“Netbeans, JavaScript, Ant, Hudson, and JSLint: Oh my!”

Ari Shamash: “…there is a lot developers can do to make the experience with JavaScript a whole lot better. Don’t get me wrong, JavaScript can be amazing, but it can also be a nightmare. Part of the nightmare is that the development environments and tools for JavaScript are not yet on par with other environments. My current project involves writing a whole lot of JavaScript. We’ve gone through the usual JavaScript cycles—we’ve been burned by both programming errors as well as deployment errors. …This blog entry describes how we’ve integrated JSLint into our Continuous Build/Integration environment, so we can better control the code that we write.” This little investigation of mine leads to a case where Mozilla’s Rhino is actually useful to me.

“Manifesto for Agile Software Development”

The Poetry of Kent Beck and Company:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Songhay Design or Just Buzzword Soup? …the Input Data Object

Posted on 9/2/2009 by rasx()

Coming out of the J2EE Java camp we have the business object (the fat one), the data access object (the classic one) and the data transfer object (the skinny one). The revolt against J2EE (which produced Spring and, I think, Hibernate) brings us the term object-relational mapping famously.

None of these terms recognize the existence of a central problem of my life as a developer: the reception of external input and transforming it into native types. What Java people and Microsoft people do is expect their external data to be auto-magically transformed into natives. In my Microsoft world, we have the ‘gift’ of Server Controls (and the proxy stub for Web Services). Until the arrival of ASP.NET MVC (and JSON), my rejection of this wonderful gift from Microsoft has been met largely with suspicion and flippant disrespect. So instead of getting too angry at this, I’m going to look at the term ‘input data object’—knowing full well that someone thought of this before me but has a famous name for it I have yet to discover.

What I am calling the input data object is an object that has one responsibility: take external input and transform it into data defined by a contract. This ‘contract’ is, of course, an interface. So the presence of my input data object implies that there must a backing data transfer interface (data transfer contract). That I would actually bother to define these interfaces means that I have finally discovered that the Extract Interface command can be used to generate interfaces from classes generated by LINQ.

Now some random points:

I am using the term ‘input’ when the term ‘message’ might be appropriate. However, input looks to me like the superset containing the message.
The success of implementing the input data object concept is that all code concerned with external input is centralized. The backing data transfer interface represents the results of the work of the input data object—these results are passed to other classes, decoupled from how this work is done.
My use of data transfer interfaces suggests the design by contract approach (Contract-First development). I am certain that my approach here is underpowered.
This rather historical article is interesting: “Data Access Object (DAO) versus Object Relational Mapping (ORM)”
“Business objects are sometimes called domain objects… A business object often encapsulates all of the data and business behavior associated with the entity that it represents.” Rocky Lhotka’s CSLA Framework is the king of making such Swiss Army knives possible.
This idea comes to me from looking at the source code for a CodePlex.com project called KiGG.

Dropping More SharePoint Links into My Blog Bucket

Posted on 7/10/2009 by rasx()

Influenced by recent events, I’m taking SharePoint links off of my active TODO list. My strategy is pathetically simple: don’t do a thing with SharePoint until the next version comes out based on the forlorn hope that the next version will come with a big apology for all previous versions in the form of new, pronounced levels of usability and elegance. Meanwhile, these:

“Imtech Fields Explorer Visual Studio 2008 plugin”—from Waldek Mastykarz: “Imtech Fields Explorer is one of the tools we really use a lot. It all started with the inability of exploring properties of Site Columns and Content Types and the Internal Names in particular. We needed a simple tool which would allow us to quickly find the field names we need to enter in CAML queries and controls.”
“SummaryLinkFieldControl Members (Microsoft.SharePoint.Publishing.WebControls)”
“The MossyBlog Times: Controlling your Silverlight Installation Experience”
“Development Hole: Move or Copy SharePoint Document Library Files Programmatically”
“Five Simple But Powerful PowerShell Functions/Filters for SharePoint”
“Getting Intellisense in your SharePoint XML for Visual Studio”
“Access Microsoft Access Database From Java Using JDBC-ODBC Bridge”—not really SharePoint but any Office application is related to SharePoint.
“Other SharePoint Development Tools”
“Windows SharePoint Services (WSS) 3.0 & Search Server 2008 Express”
“SharePoint Links out of the TODO List”

“Joel Spolsky is wrong about my work” and other links…

Posted on 7/7/2009 by rasx()

JUnit Max: “In a recent podcast, Joel Spolsky makes comments that make clear his lack of knowledge of what I do and what I say. His work has not afforded him the opportunity to evaluate the quantity or quality of my work as a programmer. The second edition of Extreme Programming Explained, Implementation Patterns and my recent work on Responsive Design are not checklists. …I would rather not respond, but if I don’t then public perception becomes what he says by default. He has worked hard to become famous, but he hasn’t figured out that along with notoriety comes responsibility. He is a bright, experienced guy and certainly capable of more accurate, thoughtful, and constructive conversation.”

“An Open Letter to Joel Spolsky and Jeff Atwood”

objectmentor.com: “I understand that this was a podcast, and that you were both just jawing. However, your podcasts are a product that you ship to everyone in the world. The content of that product can do great good; but it can also do great and permanent harm. One would think that you’d want to be careful with such a product. Yet in the intensity of the moment you got a bit careless and spewed some crap instead. That’s fine, everybody makes mistakes. But then you shipped it! You shipped a product that had a huge bug in it. You should have had tests!”

“What 2 questions would you ask Kent Beck?”

ISerializable: “If you had an hour to talk with Kent Beck, a proud father of eXtreme Programming, and you could only ask two questions, what would you ask? …I’ll be interviewing Kent as part of my audio interview series this week. I promise to take into consideration any good questions that come up in the comments. One of the things we plan to talk about is the whole notion of ‘BDUF’ (‘Big Design Up Front’) in agile projects, and we’ll also touch on the column that Joel On Software wrote on this subject (and all the responses to it).”

“10 reasons why GNOME is better than KDE” and other links…

Posted on 3/12/2009 by rasx()

Jack Wallen: “What replaced the ever-popular KDE 3.5 was something unstable, hardly usable, and as configurable as Windows Vista. Gone were the days of configuring KDE to your exact specifications. KDE was (and is) the first-ever “Microsofting” of the Linux desktop. The developers released something that was painfully worthless and refused to listen to the users when the users gave feedback. On the other side of the battlefront, you have GNOME, which is steadfastly moving forward — the same direction it has been moving for years.”

Because KDE has a reputation for being more complex and Linux power-user ‘friendly,’ it’s quite a surprise to find KDE morph into something that can be accused of emulating Microsoft, Vista-era designs.

Alternative to KDE and GNOME

Julian Coccia: “The fact that GNOME is getting heavier and more unreliable is not my main problem. The big issue I have is that it depends on the Linux implementation of .NET (Microsoft’s framework) called Mono. THAT’S WRONG, PLAIN, SIMPLY WRONG. Mono used to be optional to GNOME, but now it is a dependency. To make things worst, more and more applications are migrating to Mono, which means that, soon, most of GNOME will be built on Microsoft’s .NET. That seems to be very necessary for a lot of people, especially Microsoft. I, for one, don’t want to have any Microsoft junk in my computer.”

My other lousy assumption was that GNOME would not get any where near Mono—because Miguel de Icaza can be charged with the “crime” of leaving the GNOME project to lead Mono development. More truth stranger than fiction…?

Measuring the true success of OpenOffice.org

Michael Meeks: “the statistics show a picture of slow disengagement by Sun, combined with a spectacular lack of growth in the developer community. In a healthy project we would expect to see a large number of volunteer developers involved, in addition – we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux’s recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective.” This one comes via Jeff Atwood.