This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
I recently received a survery from Xml.com and thought I'd share some of the information here. As my regular readers know, I use XML on a regular basis in a variety of ways, but I'm not sold on it being the Silver Bullet as some people seem to think.
The most striking question of the survey was along the lines of "What XML technology do you think 'will make it big' over the next 12 months?"
Here's my answer: Whatever technology *doesn't* get the marketing dollars.
As and example, let's look at RSS. If you don't know about RSS, it's that nifty little orange "XML" that you've probably seen on this site and many others. It's a quick way of letting users know when a site has been updated and often provides the updated content itself. Anyway...
Except for the last 6 months or so, RSS was a pariah in the media. Most people didn't - and probably still don't - have a clue what it is, what it does, or how to use it. It was thoroughly embedded in the real XML guru's consciousness, but the technology consultants and marketing dollars simply weren't there. Those people were focused on BPEL, SOA, and a variety of other things. Now, RSS is everywhere and BPEL and SOA pundits are still having to explain exactly "what they do". Now, all of the serious browsers support integrated RSS readers in addition to having dozens of sites which aggregate feeds for you. Hmm.
Does this model hold everywhere? I don't think so, but I think it's reasonable enough to build a few assumptions:
First, marketing budgets != technology acceptance != useful tools. For a decade, there has been the argument of "the best technology doesn't necessary win out, the biggest marketing budget does", but I think this is steadily being weakened for two reasons: distributed decision makers and too much to do. Many companies still believe "we don't use Linux anywhere" while the people who actually do the work use whatever fits their requirements.
Next, technology decisions are not made from the top down. The marketing dollars are focused at the CIO's and the CTO's who are believed to chart the overall direction of the ship, but they're not the ones manning the oars. Once again, we go to the line-level geek, developer, admin who is going to use the best tools they can find to get the job done.
Finally, many of the high dollar consultants who come in and evangelize these technologies simply don't have a clue. They may know their given industry, but it's nearly impossible to know the details of the day to day operations and it is quite likely that they've been "out of the game" for years. Therefore these people will often be ignored and mocked. Though most geeks are polite enough to do this afterwards.
So "What XML technology do *I* think 'will make it big' over the next 12 months?"
Whatever makes it big with the people actually doing the work. I suspect this will be something along the lines of using XML as an output format to talk to other applications more and more, but I'm just one guy, not an XML guru, so take that with a block of salt.
Update:No further work is being done on dotProject. Instead, check out the heavily-redesigned up fork known as web2project.
Sometimes living in Washington, DC gives you a skewed view of the world. I think this applies at numerous levels, but it also seeps into the language. First of all, we have "The Beltway" which is the I-495 loop all the way around the city. Then we have the "Beltway Bandits" which are the multiple hundreds of little contracting companies in the area which support the various government agencies, groups, corporations, and just about anyone else.
Good or bad, I'm not getting into it here, but I've noticed that most of the dotProject feature requests which come from these groups don't reflect the feature requests and requirements of the core group and those who frequent the dotProject forums.
I have to admit that I've been following fellow CodeSniper Ben Bryant's discussion of XML with just a bit of misplaced glee. I have been working with XML extensively since mid-2001 at organizations ranging from US Goverment Departments to a handful of developers and a maniacal boss with improper desires for XML and have seen it all. No, I'm quite serious, I've seen it all. Or atleast every day, I pray I have.
While I was at the Library of Congress, I had the opportunity to build some XML schemas from scratch. It was a great experience as we had a literal "clean slate" that every developer dreams of along with people who had huge amounts of domain expertise. They were sharp people all the way around and it showed. The Schemas were huge, verbose, complex, but amazingly complete in terms of the data and metadata we were able to capture.
The main problem we faced was that the XML hype was just beginning and the support of the tools was mediocre at best. We found ourselves having to write much of our own infrastructure before we could implement our great ideas. Most of them worked and we managed to develop - what we believe - were the first WebServices within the US Federal government and I believe my name/initials are still in some of the Schemas.
Fast forward a few years and the XML hype machine (aka Microsoft) is going full speed and it turns out that XML is going to solve all your problems with legacy systems in addition to make your coffee and end terrorism. I'll never forget when my boss said "we're going to build 100% XML applications!" I'm not even sure what that means. Do you mean that we'll be able to open up Notepad, draw some nifty brackets, and the system will understand and implement our business logic? This is from an organization that when I left wasn't even using source control. I left a copy of the Joel Test on the wall when I left. Score: 0-1
XML or BPEL might be able to do that someday, but I simply don't see it yet. XML is reasonable for things such as Ant, but we can't even agree on what RSS is, how can we figure out the best way to do real development. But I digress...
Fast forward a bit farther and *some* people have learned where XML is and isn't appropriate.
On a recent project, I was the lead in building a system which would poll a number of different content providers and download all the new content. There are two well established XML standards for this and so from the 5 providers how many XML formats would you expect?
Any guesses? Come on, I know you have one.
How about seven? Yes, five organizations each present the same type of information in seven different ways despite the fact that there are two established standards. This was a perfect place for standardization and collaboration since it's the same TYPE of information with all of the same data represented pretty much the same ways, but alas... And it gets even worse as three of the organizations regularly provide documents missing required elements or ill-formed XML. Simply stunning.
So what did we do? First, we dump the ill-formed XML. Next, it made little sense to build rip each of those apart. Instead we chose a simple name/value pair structure - which is quite similar to one of the standards - and perform an XSL transform to all of the documents using a variation of the Two-Step View. Finally, we rip apart the name value pairs, scrub the data and insert it into the database. This provides the XML to the importer in exactly one way and allows us to support additional XML standards by simply writing a new XSL Transform.
This is where XML serves a great purpose. It allows us to pull together the otherwise disconnected datasets and do something with it. It allows our code to ignore their changing XML structures. If they move a field, we tweak the corresponding XSL and move on with life. If we get a new structure, we tweak some XSL and move on with life.
Would I call the system and "XML Application"? No, but I would say that it makes reasonable use of XML where it makes the most sense.
The only time I call a company is because I have a question which can't be answered on their website. I'll dig around their site for a while, search their forums, and if I can't find something within a couple minutes, I immediately go to Google. If I'm calling a company, it's because I have already tried the paths which seem obvious to me - and I'm a relatively smart guy - so don't tell me to go "check the website".
For example, after calling a hosting company of a customer, I was assured that "Your call is important to us, the current waiting time is 15 minutes" and was promptly greeted by a human... 35 minutes later. I asked my question, got my answer, and it took a total of 30 seconds. The worst part was that the customer actually worked for this hosting company.
Or I call my (former) cellphone company and put in my phone number. Then once I get a human, I give it again. There seems to be little intelligence* in these systems. Why are each of you asking me the same question over and over? You are the phone company, I'm calling into your system... it seems like you should have the ability to use the information already available to you. [The highly esteemed Duane wrote about this recently and gave a link to a IVR cheat sheet.]
Or I call my current cable company about our non-functional cable modem. The modem had been provisioned and the configuration had not changed since the last time it was used, so I assumed the problem was on their line. After seeing that we couldn't even watch cable television, I was 99.999% sure that the problem was on their line. When I called, the answer was - and I'm not joking - "have you looked at the troubleshooting area of the website?" Huh?
To any company who reads this, your customers are your friend. In fact, they're more than your friend, they are your lifeblood. Unless you can force them to continue paying for your services (via physical force or lack of alternatives), customers will determine if you have a job. If they're calling you, you should assume that they've probably already tried to find the information online. You should assume that they have a brain. Your customer service staff should deviate from the script as necessary.
We can be your emissaries or your enemies.
* Disclosure: We're still in the middle stages of a Proof of Concept, but CaseySoftware is working to make this problem a little bit better. We are working with an IVR company to inject some additional intelligence into the situation via a simple linkage to the Open Source Customer Relationship Management System SugarCRM. We are already retrieving some basic customer information to give to the service staff, but soon we hope to return Order information to the customer via touch tone interface.
I've previously mentioned Ruby On Rails over on CodeSnipers and I simply wasn't convinced. I have seen and heard the hype but it just didn't appeal to me. In fact, in some ways I was mentally fighting it. I know ASP, Java/JSP, PHP, and enough of a few other things to be dangerous. Well, Dave may have turned me with his demonstration and presentation.
Therefore, I'm going to give it a try.
My main concern that I see at this point is the fact that there are huge existing codebases of Java (my biggest customer), PHP (dotProject, SugarCRM, Mantis), etc that I interact with on a daily basis. In order to utilize this underlying functionality (ie. investment), I will have to figure out ways of calling this code (SOAP? REST? other?). For systems that are new from the ground up, the requirement isn't there, but that is a rare occassion. Fortunately, I've already heard a bit about jRuby and how it may bridge the Java/Ruby gap for me.
I'll update this space regularly with my experiments, successes, and failures.
Due to a whole series of events, chaos, etc, I have been incredibly lax in blogging this month. Last month I averaged about 4-5 posts/week and this month I'm at about 1/week and it's mostly been discussing a new product we have available... not exactly exciting stuff.
Over the past week, I've spent a bit of time thinking about why I blog. Sure, blogging helps my searching rating for terms like dotProject, SugarCRM, and even vtiger which works out conveniently as we do quite a bit of work with dotProject and Sugar. Sure, the Google Ads are another source of revenue, but that's... well, let's just say I should be able to get dinner and a movie at this point. Blogging gives me a chance to be famous. Right. No, I blog for three fundamental reasons.
First, it's a great chance to practice my writing skills. I spend quite a bit of time working with customers to figure out exactly what they're looking for and attempt to capture that on paper. Blogging forces me to attempt to communicate just one or two points without a great deal of blathering. One of my former teachers called it "precise but concise" and I think blogging focuses on this.
Second, it forces me to practice communication in general. I believe most blog readers don't have the time or attention to spend 15 minutes reading an article. It's not from a lack of intellect or anything like that, it's simply a matter of time/attention available. Therefore, I figure I have about 15-30 seconds to draw people in and give them a reason to continue reading. This has caused me to think even faster on my feet in person and give someone a reason to continue the discussion.
Finally - and most importantly - it gives me an outlet for my thoughts. Running a small software shop where most of our customers are remote can be a lonely experience. I don't always have a technical or business person handy to bounce my thoughts off of. Blogging is my chance to put my thoughts in front of the entire world - or atleast the three of us ;) - and see what people think. Some may call me a moron, some may harass me because of my opinions, but others will actually say "wait, have you looked at this" or "wow, I hadn't thought about that" and hopefully we both walk away with something new.