Ok, I have some cool code bits, announcements, and other such things. Some of the code bits will be here “Developer Document”, the blog entry for the first example I’ve written up is here “SDK, ADO.NET DataTable/DataSet, and Code Bits”, and then of course the regular sundry of my writings.
There has been an on and off demand internally for some additions to the Webtrends SDK for our DX Web Services offerings, so I added some bits. The following are a list of the features:
Map to DataTable/DataSet from Data Transfer Object. Alright, I’m going to do a little explaining on this topic. The DataTable is the standard, years old ADO.NET DataTable that someone can put in with other DataTables in the DataSet. It basically provides the data pulled from the DX web services in a flattened easy to use DataTable format.
Profile & Report Listing Factory. I added a profile and report listing factory for pulling lists from the DX web services. This seemed like a no brained, it just needed to be available.
I also refactored the Report Factory Methods to accept a string or Uri Object Parameter to retrieve a report from. This way, if another tool creates a Uri then it can be used directly instead of parsing it apart only to hand of the values to have the factory parse it back together.
Last but not least, available in bite size assembly format. Check out the Webtrends Developers’ Website for the bits.
This is a serious smackdown ad, I LOVED it. I’ve been pondering dropping the iPhone as it has never felt robust, but the Windows Mobile was just a disgrace. Now though, WOW! Between the ad & the seriousness of Android coming to other phone platforms I am honestly getting pretty stoked. The development environments are better (I mean, Object C, come on), there are multiples to choose from, the platform is open. Sounds like Windows stomping Macintosh those years ago. Cept’ this time it is Google vs. Apple. It is about time this battle got real!! I’m looking forward to it with bated breath. 🙂
So with that, it just kicked off the motivation to start doing some real Mobile Dev. Yes, I will probably get some iPhone Apps built, but my focus will definitely be Android.
Amid all the things written in those articles and entries, I will leave just as they are written without comment. Everything written in these conversations are pretty much similar ideas, about how it is truly an odd purchase. That is great from my perspective, I am a Webtrends Employee and I enjoy the work very much. I find the competition growing and lively. But there is one thing I want to comment on, and it is mostly a technical observation that I would love for non-technical people to take heed of.
The one thing I want to comment on is this mythic idea Microsoft may be or should be scooping in at the last second and bidding on Omniture. There was even some statements that Microsoft should have bought Omniture. The major issue with this is two fold; Omniture & Microsoft are built, generally, on completely different technology stacks. Microsoft uses, well, Microsoft‘s Technology Stack and Omniture uses a deluge of non-Microsoft Technology (with a few MS Products here and there, like their Excel Tools). So even if that was a match, it would have been really bad for Microsoft, as the publicity for not dog fooding their own technology after this mythic purchase would have been huge. The cost for Microsoft to rewrite the entirety of almost every tool Omniture has would have been overwhelming, even for Microsoft. The cost, in the end, would absolutely not be worth it for Microsoft.
I won’t venture about our technology stack at Webtrends, nor Adobe & Omniture‘s Stack, other than to say from the technical perspective Adobe matches Omniture‘s Tech Stack far better than a Microsoft & Omniture stack. Adobe has a fine history of taking disparate ? specifically non-Microsoft technologies ? and getting them to work together.
…and to a great 09′ and improving economy for everyone, Cheers!
[beware, random interspersed doses of sarcasm below]
After watching these two talks, I have decided on a new path I am going to take. I am going to start mistrusting and hating agile. You know, so I can fit in and stuff.
I recently watched a video presentation of Alistair Cockburn, who is a fairly major name in the Agile Development Community. It pushed me to put this entry together for future discussion that I intend to kick off (at least on this blog & the few readers I have). I have worked on the following Agile Projects:
My most recent project utilizing Agile Processes was at Webtrends for my stint in Engineering late 08 and earlier 09. I worked on a team to build web services for Webtrends data access for customers.
The team consisted of three people, one being a team lead. Our primary use of Agile was somewhat limited as it was a new process for the team. We performed continuous builds via Team Foundation Server and test driven development when feasible. We were limited in using TDD to some degree as a large part of the work was configuration based for server configuration and required a large degree of integration tests more than isolated unit tests. In addition to TDD we also utilized user stories, burn down charts, and to some degree kanban style prioritization. The project was a rocking success, and is now offered as a Webtrends offering and documented, discussed, blogged and continuously maintained and advanced. Even though I am on a different team now working directly with customers to implement integrations with these REST based web services, the engineering team continues forward with more Agile practices being used daily, including paper prototyping, furthering the unit testing majority of the teams, and more.
After* and before* the Webtrends engagement I helped to initiate Agile in a development group of 4 people at Axiom Group (now Axiom EPM) to build a Excel UI to SQL Server for accounting data storage, manipulation, analysis, trending, and retrieval. I helped get the group kick started, and the software that was released is now called Axiom Planning.
The team of 4, split into two pairs, and we did pairing & individual development. Other agile software methods used were rapid learning, extensive test driven development, continuous integration (w/ TeamCity), unit tests in builds w/ good coverage (the logical kind), mocking (for databases), self organizing team, paper prototyping, and direct daily communication with customer representatives. We also as pairs and as a team used refactoring heavily. In addition heavy utilization of design patterns and domain driven-design was used in close collaboration with the customer.
In 06 & 07’ I worked with Centerstance Consulting on a project which started Waterfall and moved to Agile during the course of the engagement. We started off a team of 5 developers, grew to about 16 at one point, and shrunk down toward the completion of the overarching architectural design to about 8-12 again.
The teams ranged from 4-5 people per team with a team lead, to two teams with two sub-teams split with a team lead each doing their own respective stand ups (SCRUM style), a continuous integration was setup, unit & integration testing was eventually put into place across a wide spectrum of the code base. Mocking, faking where appropriate, and general unit testing took place, with business analysts acting as customers.
For Ghallt Enterprises I served as CTO with a business partner, leading efforts among remote teams, utilizing Agile practices (yeah, remotely, I know, it seems crazy) to develop social media software. Methods included continuous integration, build management, pair development, code review & refactoring on a regular basis, and other practices. Even though this is a company that a friend and I started, it served to provide a catalyst for me to push forward extensively into Agile Processes. The level of progress, quality of code, and other characteristics that are inherent to effective Agile Processes were of a level that left no reason to endeavor toward traditional style project planning or Waterfall style approaches.
I?ve worked with others to mentor and experiment with pair development, continuous integration, unit testing, and other processes to enhance and streamline the software development life cycle.
* I write after and before Webtrends because I left Webtrends in 08’ to work the Axiom effort, upon kicking that off, I then headed back to Webtrends to work on the then new Web Services with REST Architecture Project.