Erik on Software

New Book Review: "Patent, Copyright & Trademark"

New book review for Patent, Copyright & Trademark: An Intellectual Property Desk Reference (11th Edition), by Attorney Richard Stim, NOLO, 2010, reposted here:

Good introduction to intellectual property law, which consists of four separate and overlapping legal disciplines: (1) patent law, (2) copyright law, (3) trademark law, and (4) trade secret law. Following an introduction that provides a high-level overview of intellectual property law, the remainder of the text is broken down into each of these disciplines, with the bulk dedicated to patent law and copyright law. Each of these sections provides an overview of the discipline covered, along with definitions associated with the corresponding discipline and explanations of forms that need to be filed, together with sample completed examples, followed by the actual legal statutes.

While the bulk of what Stim provides here is dedicated to patent law and copyright law, definitions are what carry this text across all of the four disciplines. That definitions comprise a majority of this text is important, because depending on the needs of the reader this may or may not be an effective format. This book is one of a number of self-help legal resources that Nolo provides, and so it is important to realize that this 600-page effort should probably be seen as just a good place to start one's journey in intellectual property. At the same time, it is also likely that the reader will not need to read this book cover-to-cover, because Nolo publishes separate texts dedicated to each of the four disciplines covered here.

Nolo has been updating this text regularly since the mid-1990s, so the reader can be assured that the content that is provided is up-to-date at time of publication. In each of the overview sections, Stim provides several pages under the header "What's new in patent law since the last edition?" that explain the major events in each respective discipline since the last edition of the book was published. In my opinion, this information mainly serves as a reminder that the law continues to evolve, and is probably best used by the reader as a starting point for further investigation, since the legal decisions provided are highly summarized. It is also worth pointing out that the author provides references to abundant web site resources that provide additional information.

The overviews and definitions are written clearly for those new to these legal disciplines. Compared to the last text I read on related subject matter, "Inventing Software: The Rise of 'Computer-Related' Patents" by Kenneth Nichols (see my review), I also find the material that this book provides to be very well organized. As a consultant in the software industry, the definitions that Stim provides for such terms as "algorithms", "software patents", "reverse engineering and trade secrets", and "software and trade secrets" are especially appreciated, and as a blog writer I also appreciated some of the tips that the author provides on copyrighted material. Recommended to anyone looking for an introductory text on intellectual property law.

Past Book Review (July 6, 2007): "Inventing Software"

 Past book review (i.e. posted prior to starting this blog) for Inventing Software: The Rise of "Computer-Related" Patents, by Kenneth Nichols, Quorum Books, 1998, reposted here:

From the first lines of the preface of this work by Kenneth Nichols, it is apparent that what was initially planned to be of more concise scope grew into a discussion of all things associated with software patents, and therein lies the rub. It is interesting that the author notes in just the second sentence that he "came to the conclusion that the particulars of the debate [within the programming community over the desirability and ultimate effect of software patents]...are not that interesting or enlightening". Really? I find it odd that an individual with a J.D. and an M.S. in Computer Science would make such a statement. Of course, his follow-up statement that the "larger and more important story" involves the fact that "software development is a new kind of creative activity, one that defies the neat and mutually exclusive categorizations of intellectual effort as either artistic or scientific" might be true, Frederick P. Brooks wrote extensively on this topic in his classic tome on software engineering long before the USPTO permitted the filing of related patents. Fortunately, Nichols dedicates most of his work to the more boring subject matter, although unfortunately the explanations provided are a bit boring themselves.

Putting aside the fact that this book was written in the late 1990s, however, there is a lot to offer here to the professional software engineer as well as the non-technical management community associated with software interests of this nature. For example, the author's concise 20-page introduction introduces well much of the background subject matter. Nichols also discusses well the topics of algorithms, programming, computer science, software engineering, and how patents fit in with this universe. The heart of the text, the third chapter which presents various software patent examples, however, is very poorly constructed in my opinion, although the explanation in its first few pages on major terms such as "novelty" and "nonobviousness" is concisely written. The diagram provided that depicts concepts related to nonobviousness, written in the style of a Venn diagram, is especially well suited for the discussion. The fourth chapter covers the software patent controversy, and the reader is well rewarded in my opinion when reaching this point in the book after 50 pages of rambling.

It is strange that the seventh chapter is dedicated to a definition of programming, a discussion best suited for the introductory pages of the book, although some of the quotes provided in these pages are quite entertaining, such as the W. Saba quote from an IEEE periodical that "hardware engineers have gone further than their software counterparts because hardware design became a science...Unlike hardware engineers, software engineers still deal in magic and witchcraft". Interestingly enough, it was just recently that The Economist discussed the emergence of computer science as the foundational branch of science. Last of all, while the sixth chapter boldly begins by proclaiming "we've finally come to the good part" because it deals with recommendations for software developers, only 6 pages are dedicated to the subject! If Nichols is to write further on software patents, I recommend an entire book dedicated to recommendations.

New Book Review: "Managing Time in Relational Databases"

New book review for Managing Time in Relational Databases: How to Design, Update and Query Temporal Data, by Tom Johnston and Randall Weis, Morgan Kaufmann, 2010, reposted here:

When this book was published last year, I must admit that the data architect in me was excited that an advanced database text had finally come along that addressed some issues that every data modeler must face (or should face) once they have mastered the rudimentary. The bulk of published database related books discuss SQL, or usage of specific database products. And while more books are beginning to appear on shelves that address topics such as data modeling, this genre is certainly in need of more texts that address the full spectrum of database usage.

Despite the weightiness of this 400-page effort, which required quite the journey (be forewarned), this book is one of the most painstakingly detailed technology efforts that I have read in quite some time that goes to great lengths in making sure the reader understands the material that is presented. No stones are left unturned along the way in the explanations of the authors on how to design, update, and query temporal data. In addition, the introductions that Johnston and Weis provide on temporal data management and asserted versioning in the first 150 pages are unrivaled in textbook publishing.

The authors state in their preface that there are four objectives of this book: (1) to describe how to manage uni-temporal and bi-temporal data in relational databases in such a way that they can be seamlessly accessed together with current data, (2) to describe how to encapsulate the complexities of uni-temporal and bi-temporal data management, (3) to explain how to implement temporal data management as an enterprise solution, and (4) to describe how to bring pending transactions into the production tables that are their targets, and how to retain posted transactions in those same tables.

The authors also note that as this book when to press, they started the process of converting their initial provisional patent application for Asserted Versioning into a patent application, although any non-software-vendor company is granted the right to develop its own temporal data management software based on the concepts presented in this book, as long as such software is for use only by the company and not sold, leased, licensed, or given away to any other company or individual. An implementation of the concepts presented by the authors, the Asserted Versioning Framework (AVF), is also being created by the authors.

Superb illustrations accompany explanations of concepts in all the right places. And the concluding chapter that the authors provide offers more substance than many lengthy white papers, offering an "ongoing research and development" section that presents a partial list of topics on which the authors are working, with topics such as use of AVF via Java and Hibernate of special interest to me. The asserted versioning glossary that spans over 50 pages of fine print and concludes the text is also highly appreciated. Well recommended to all data professionals.

HAPI Announcement: 10-Year Anniversary

Follow-up on a post from June when the HAPI 10-Year anniversary was first anticipated. Received this email announcement yesterday afternoon. Some statistics on website visitors and adoption by organizations have also been posted on the HAPI website.

Hi Everyone,

I just wanted to point out that the HAPI project is 10 years old today. On October 30 2001, Bryan Tripp and a team at University Health Network first registered the project on Sourceforge. The rest, as they say, is history.

I've posted a few words about all the progress this great community has made along the way on our website: http://hl7api.sourceforge.net

Here's to another 10!

Cheers,
James

P.s., A new beta release (1.3 beta1) should be up soon.

Certified ScrumMaster Training: Day 2

Notes taken for posterity during the second of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.

• Release planning was pulled out of the July 2011 Scrum Guide, which returns Scrum to its original definition, but the Scrum Alliance will continue to include.
• Definite delivery dates, cost, and scope are not included in Scrum release planning. Release planning is not the purpose of Scrum. The purpose of Scrum is to be transparent and to determine what is available when.
• Scrum and Extreme Programming (XP) arose from the Patterns movement, because each of these is based on natural practices. Patterns are discovered, not invented.
• A release plan really just indicates which Sprints involve a shipment.
• Estimating is really design, because the clock is not brought into the equation. The conversation becomes more comfortable because the subject matter is more familiar and the entire development team is involved.
• Sometimes "ideal days" are used instead of story points, but for some this brings time back into the equation, which is not the objective. According to the instructor, ideal days in general tends to work.
• Larger tasks tend to be underestimated. The instructor advised not assigning numbers when an estimate is too much of an unknown, because estimates will be thrown off. This forces stakeholders to be aware that these larger tasks need to be broken down in the future. It is the stakeholder's call whether to spend time on one or more Sprints assigning estimates to these larger tasks.
• If there are many small tasks, it is permissible to bundle them as long as it makes sense to do so. In other words, the tasks are related and can be completed within a Sprint.
• Planning Poker sets are typically based on Fibonacci, so the instructor tends to suggest this sequence.

---

During the discussion, I had mentioned Powers of 2 as being popular, but the instructor tends to think that the numbers in this sequence increase too quickly. In speaking with some colleagues, we agreed that Fibonacci and Powers of 2 are similar if capped at say 16, and I later distributed a presentation I delivered a couple years ago that included several slides on how Powers of 2 were used for story points and how spikes were used on my project to assign story points to the building of proof of concepts with unfamiliar technologies that were planned to be used on the project. But since it is not always reasonable to cap at a certain number in the sequence, in retrospect I will be considering other sequences such as Fibonacci in the future, especially since we enjoyed using a traditional card deck to play Planning Poker (Ace = 1, 2, 3, 5, 8, Jack = 13, Queen = 21, King = 34).

During an exercise where the class broke down into 2 teams, we used Fibonacci to estimate tasks associated with kitchen remodeling.

The points that my team assigned to each of the tasks are listed on the left. Points are relative, and we did not see any tasks as being far removed from the others in terms of points. However, we did not end up assigning any points to the last task listed, because of the disagreement that ensued regarding the work to be completed. This task is an example of where a portion of a Sprint might be assigned to additional estimating.

The other team viewed the first two tasks as being relatively far removed from the others in terms of points, and in this case it is understandable how Powers of 2 might not be appropriate. As discussed by the teams following this exercise, the points assigned are either a reflection of unfamiliarity of this type of work, or the relative difference in skills between the individuals on each of the 2 teams.

---

• This type of estimation is really qualitative, not quantitative. Affinity Estimation enables quantitative estimation and is the fastest way to estimate a product backlog. The rule is that if a story estimate changes 3 times, it is set aside. Not only is time removed, size is removed. Affinity estimation is relative. The Fibonacci series is then applied afterward. The team quickly develops collective intuition.
• XP introduced the "courage value", which takes the lower number, rather than a conservative higher number, in the case that a team does not reach a concensus.
• During a class exercise that involved measuring velocity, the instructor pointed out that the team that is participating needs to be involved in estimating. Those not involved are not qualified to interpret past velocity activity.
• Use of Scrum is always forward looking by evaluating the past. What the instructor refers to as "Point Accounting" comes into play as tasks are not completed and work needs to be forwarded to the next Sprint. One strategy is to figure out how to complete a subset of the task in the first Sprint, and then forward the remainder. Another strategy is to move the entire task to the next Sprint and then count the points for the whole task. The instructor does not necessarily like this latter method, but for a services company like ours it might make sense.
• The Sprint is the only timeboxed item that cannot be changed.
• Part 2 of Sprint planning is where the bulk of planning occurs. The first part of planning tends to go quickly because much of the work is performed in the prior Sprint.
• Velocity should be used to determine what the development team thinks it can complete in a Sprint, not what it needs to complete in a Sprint based on expectations.
• It is rare that developers will sign up for risky tasks.
• Be careful about assessing importance based on the task name in itself, because for example the task might be associated with strategic work that is trying to set the stage for future Sprints.
• The Burndown Chart tracks how many hours remain, not how many hours have been applied to tasks. Keeping track of how many hours have been worked can be separately maintained elsewhere.
• The "truck number" is sometimes used to communicate how many people need to be run over for a particular skillset to be lost. A truck number of 1 is obviously never desired.
• It is a good idea to reserve a portion of points in each Sprint for support activities.
• It also sometimes makes sense for the experts on the team to be assigned no points in order to raise the skillsets for the rest of the team.
• Kanban is really an evolution of Scrum where work needs to fit into more traditional phases.
• It is not the purpose of the daily Scrum to report to the ScrumMaster. The purpose of the daily Scrum is for individual developers to share status with the rest of the team.

---

Interestingly enough, the role of the ScrumMaster in the daily Scrum was one of the topics that lingered during hallway chats while back at our client the next day. In our experience, it is common that ScrumMasters will address the rest of the development team one at a time during the daily Scrum, reminiscent of status reports to a project manager, but this should be taken care of prior to the meeting itself so that developers can share with each other. In my opinion, reverting back to the traditional status report format with which many are familiar is common when trying to create a Scrum hybrid that blends Scrum with current state client project methodologies, but should be relatively easy to steer away from when there is common understanding across the development team as to the purpose of the daily Scrum.

---

• The Burndown Chart should not be updated during the daily Scrum. The team should update before the meeting so that it does not lose its purpose.
• There should be a common vision coming out of Sprint planning that the team has a shared commitment. The purpose of the daily Scrum is not to focus on your own work as an individual.

---

Another topic that was discussed periodically the next day was the Ball Point Game exercise in which all attendees participated as one big team. For this exercise, we were to pass tennis balls to each other in a way where everyone touched each ball before it was placed in the bucket. But there were stipulations which stated that air time was required between each person, that balls could not be passed to direct neighbors, and that the person that passed the ball first also must be the person that touches the ball last.

And it so happened that I was the individual that was the one that passed the ball first and touched the ball last. By the nature of this position, I was also the one that kept count of how many times balls entered the bucket. Very challenging. Everyone remarked the next day how I was the one with the hardest task. Much like the ScrumMaster. Two of the many take-aways were that we found rhythm as at team after the first few Sprints, and that time spent on Agile Retrospectives is very small compared to the rest of each Sprint.

The exercise ran for 10 Sprints. During the first 3 Sprints, our velocity increased. Following the first 3 Sprints, I suggested we create a new formation and so velocity decreased while we were finding our rhythm again. Other suggestions on formation ensued, and velocity rose again until we found a more optimal formation in which velocity continued to accelerate. It is probable that had we run the exercise for additional Sprints we would have continued to increase velocity prior to reaching our limit.

Certified ScrumMaster Training: Day 1

Notes taken for posterity during the first of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.

• The course started by individual attendees identifying 5 of 22 provided topics that we thought might be important take-aways, followed by the class breaking up into pairs in order that one might convince the other to switch one of the 5 chosen to another topic.
• The 5 topics I had chosen were items I had not yet encountered to any significant degree in the workplace or graduate school, such as specific artifacts and distributed Scrum. The plan was then to apply post-it notes to each of the 5 topics as they were covered in class.

---

Of the 22 take-away concentrations, the following 5 were the most popular in this class session (all written intentionally in the form of user stories):

7- I can describe how to use the Scrum framework on large projects using Scrum of Scrums and/or other approaches to scaling.
6- I can facilitate the team through the Sprint.
6 - I can advocate for Scrum teams to be colocated, but also help a team overcome the reality of distributed teams.
5 - I can explain the importance of complexity and its impact using empirical or defined processes.
5 - I can describe the responsibility of the ScrumMaster.

These types of exercises tend to interest me, because much of the value add for me in corporate training tends to come from the interactions between colleagues rather than the material itself.

---

• The latest Scrum Guide released 3 weeks ago was included in the handout workbook. The instructor noted that the release planning portion was removed from the previous Scrum Guide.
• Development of the Certified Scrum Professional from the Scrum Alliance had its origins in the failure of the Agile Software Development with Scrum text by Ken Schwaber and Mike Beedle and the desire to help realize Scrum practices in its readership.
• According to the instructor, worldwide there are about 160k Certified ScrumMasters, about 10k Certified Scrum Professionals, 130 Certified Scrum Trainers, and an unknown number of Certified Scrum Coaches and Certified Scrum Developers.
• The instructor also noted that there is some redundancy between Certified Product Owners and Certified ScrumMasters. Although Certified ScrumMaster Professional is the drive right now, it is not a certification that should be called out in one's email signature etc because it does not represent skills or experience, just understanding.
• In Scrum, "programmer" is not equivalent to "developer". The development team is comprised of the programmers, architects, business analysts, testers etc with which we are familiar, and all are developers. In addition, the Scrum team is comprised of both the product owner and the development team.
• Deliverables are intended to be in a shippable state at the end of each sprint, but not necessarily shipped or deployed to production. To release to production is a business decision.
• Identified tasks are not an explicit requirement of Scrum. The development team determines how this is to be done. Even though tasks are the most common method to plan, this requirement was removed in recent releases of the Scrum Guide.
• Project resource needs are starting to be requested in terms of Scrum teams of x people for x months.
• During our discussion of Scrum motivations, we discussed at what point project tasks are performed during traditional Waterfall and Scrum project timelines. It was amusing for the my colleague and I to find ourselves working through estimation, requirements, analysis, and design, and then working backward from production deployment to fill in the rest of the activities for traditional Waterfall.

---

During class, I recalled to my colleagues the practices that one of my project managers followed early in my career following the implementation of an enterprise-wide project dashboard. The project manager would spend considerable time each week tweaking the project plan until it would turn green, and consistently trimmed estimates provided by my colleagues in order that they would fit in the predefined timeline, not unlike the Waterfall portion of this exercise.

---

• Scrum is similar to Extreme Programming (XP), except XP has more constraints around how programmers are to perform tasks.
• Project complexity is really the driver to determine whether to take an empirical approach. Requirements and technology (and maybe organizational complexity) determine complexity, not factors such as team size and colocation of team members etc.
• Of the 3 pillars that uphold every implementation of empirical process control (transparency, inspection, and adaption), adaption is usually the most difficult. The question ends up being: What is the most tolerable empirical approach for my organization today? And agile hybrid approaches are common.

---

After discussing project complexity and empiricism, we broke up into teams of 3 and 4 to discuss the 12 principles behind the Agile Manifesto, and chose 3 principles that we thought can be removed, and 3 principles that we thought are the most important.

Across the teams in this class session, the following 3 were the most popular for principles we thought are the most important:

3 - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
2 - Working software is the primary measure of progress.
2 - Business people and developers must work together daily throughout the project.

The following principle was the only one that managed to get any hits for being removed from the Agile Manifesto:

2 - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The instructor indicated that some of the writers of the Agile Manifesto have indicated that some of these principles would have been better left out, but that coming to agreement on these principles during a relatively short meeting 10 years ago was a huge achievement. That said, this exercise resulted in considerable debate.

One principle that generated debate was as follows: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." One team argued that "requirements" is often assumed to be business requirements, but the term can also be assigned to technical requirements, and so they argued in favor of this principle.

Another principle that the teams did not generally agree upon was as follows: "Business people and developers must work together daily throughout the project." The term "daily" was the catalyst of the disagreement, because of the mandated frequency of working together.

My team chose the following principle as being one of the 3 we thought are the most important: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly." Speaking from my experience, I have witnessed the value that the Agile Retrospective provides, having used them on multiple projects throughout my consulting career.

---

• One problem that the instructor has witnessed is that few Certified Scrum Trainers have been product owners. Most have been programmers and project managers.
• According to Scrum, only one person is intended to be product owner, but in practice this is very difficult.
• There appears to be a move in the Scrum community to replace "prioritizing" with "ordering" the Sprint Backlog, and "committment" language has been replaced with "forecast" in Scrum literature, although the instructor prefers the original verbiage.

---

Unfortunately, I introduced the term "semantics" as part of the discussion on prioritizing versus ordering. What I had intended to convey was that "prioritizing" seems to communicate business needs or wants, whereas "ordering" seems to communicate the order in which tasks need to be completed, perhaps because of dependencies between tasks.

---

• A lot of discussion surrounded the term "shippable" during the portion of our class session working on an exercise where we broke out into teams of 3 and 4 to talk about our current projects and what we can do in each Sprint, what we would like to do in each Sprint but are not able to do today, and what tasks should not be considered as needing to be completed in a Sprint.

---

The term "shippable" is intended to convey that a deliverable is in shippable state. In other words, it can be released to production or shipped to customers, but is not for any of a number of reasons. For my contribution to this exercise, I indicated that during my upcoming project, I might consider refactoring a task to be done as part of a Sprint, but tasks such as load testing probably fall outside the Sprint, and that I may like to include testing on counterparts to the proprietary appliances that are expected to be used in production, but will probably not be able to do so. 

---

• In addition, the instructor said jokingly that "what goes on in the Sprint stays in the Sprint", meaning that hand-offs between programmers and QA for example within a Sprint should not be counted as defects. Remaining defects go back in the Sprint Backlog if not resolved during any particular Sprint. In Scrum, a defect is just work prioritized by the product owner.

Liquibase in the Enterprise: Part 4

About a month ago, I completed my second Liquibase project, one of a portfolio of four projects I managed for the client CTO, and an extension to the project first mentioned in my third post in this series. The first Liquibase project that I had completed for another client, although sizeable, paled in comparison to this project.

Now that I have two such projects under my belt, I thought the development community might like to hear about some of the technical lessons learned between these two projects, which were similar in some aspects, but each with its own set of challenges.

While the first Liquibase project involved 6 database instances of DB2 9.5, the second Liquibase project involved 2 database instances of Oracle Database 11g R2. Additional constraints associated with the second project are what complicated matters.

I created 30 schemas associated with 8 application environments across these 2 database instances due in part to Oracle licensing costs, whereas the 6 database instances in the earlier project were each only associated with 1 schema each.

Because database schema names, which are actually users in Oracle, need to be obviously unique within a database instance, the hard-coding (something which I typically frown upon as a consultant architect, although in this case it made sense to do so) to which I was accustomed in the first project was no longer possible.

Initially, it had been requested that I use Apache Ant for the Oracle project, and because of this I had to set up an elaborate series of build scripts that corresponded with a lot of in-line properties due to all the different schema names. Later, I was fortunately able to move to Maven, and automated the entire setup with the profile and filter features that Maven provides.

Although it took time to migrate from Apache Ant to Apache Maven due to experimentation and thorough testing to make sure nothing had broken, I was able to successfully redirect the development team using this project with enough time left prior to my roll-off.

During my presentation of this technology while on the architecture board, I had been asked quite a few questions by the various client sites that had dialed in for my talk. Some questions were centered around Liquibase being an open source rather than commercial product, and one in particular asked whether I had run across any issues with the product.

At the time, I had not run across any issues with the product, but during my Mavenization of the Oracle project I ended up encountering 2 issues during my second round of testing, one with Liquibase 2.0 RC 5 (and presumably Liquibase 2.0.1), and one with Liquibase 2.0.1:

• Reverse engineering an Oracle 11g R2 database schema using Liquibase 2.0 RC 5 does not recognize column defaults of SYSDATE.

Because reverse engineering is typically a one-time process, and is obviously only a concern when a database is not initially created via Liquibase, the likelihood that this will be an issue for readers is probably low.

However, this issue needs to be kept in mind for those deciding to incorporate database change management using Liquibase sometime after initial creation. In my case, awareness that this was an issue did not arise until I tested the Java web application against a new database created with the Oracle project, following a data migration from the corresponding environment database I had also performed.

The simple solution for this issue was to add a series of changeSets to the applicable changeLog, each corresponding to a column in the legacy database which had such a default value defined. For example, adding a default value of SYSDATE to table column USER.CREATED_DATE can be performed as follows:

<addDefaultValue columnName="CREATED_DATE" tableName="USER" defaultValueDate="SYSDATE"/>


This workaround works perfectly, but I needed to fill in the development team why I needed to retroactively insert these changeSets to the project trunk and previous snapshot, especially because it takes some developers getting used to when merging Java code is often done, but in many cases not possible in situations like the one at hand, because Liquibase acts sequentially.

• Creating or updating an Oracle 11g R2 stored procedure or package with Liquibase 2.0.1 is unreliable.

Bundled along with the Oracle project migration from Ant to Maven, I upgraded the JDBC driver to the most recent version, and also upgraded to the latest version of Liquibase, from 2.0 RC 5 to 2.0.1, hoping to move to a "stable" release of the product. While there were no issues with the JDBC driver upgrade, after several arounds of thorough testing there appeared to be no remediation available for the resultant missing segments of PL/SQL, and so I unfortunately settled with Liquibase 2.0 RC 5. This bug was not apparent until I tested the Java web application, because the PL/SQL compiled successfully. It was only after diffs were performed between the code in Subversion and the code in Oracle when the issue was found.

---

Liquibase in the Enterprise: Part 1

Liquibase in the Enterprise: Part 2

Liquibase in the Enterprise: Part 3

Mono in Transition; C# or Objective-C?

Funny that although I have been trying to cancel my "InformationWeek" magazine subscription for quite some time, just as the publisher threatened that the June 13, 2011 issue "may be one of your last unless you revew now" comes an article, ".NET Alternative in Transition", that finally peaks my interest, partially because the publisher beat some of my other traditional sources of technology news, but partially also because of the relevance to the cross-platform mobile development project I started earlier this year and discussed in a series of blog entries.

Work on open source project Mono, originally started by Ximian in 1999, continued to flourish after being acquired by Novell in 2003, but Novell was in turn unexpectedly acquired by Attachmate in November, 2010, the sale of which completed in April, 2011 alongside a sale of "certain intellectual property assets" to CPTN Holdings, a consortium led by Microsoft, that included Mono. Attachmate fired the entire team of Mono developers in May, 2011, and although it retains intellectual property rights for Mono, much of which is copyrighted by Novell and available under an open source license, lead Miguel de Icaza moved quickly to form a new company, Xamarin, with the core Mono development team.

De Icaza's first goal is to push ahead with Mono on mobile devices, specifically Apple iOS and Android, with development in Microsoft C# (which he describes as a "beautiful language") on mobile devices as the first priority. True portability between these two platforms and Microsoft Windows Phone is the goal, and Xamarin Studio is set to be released later this year. De Icaza clarifies this direction in an interview with "Application Development Trends" magazine. Because Novell owns some of the technologies that the Mono team has already built, such as MonoTouch and Mono for Android, Xamarin needs to build some of its initial products from scratch, including new .NET incarnations for Apple iOS and Android. De Icaza:

At Novell we built both open source and proprietary products. The open source code is, well, open source. And the proprietary things are owned by Novell. We need to rebuild those things if we want to be in the market with similar products.

In response to de Icaza's original blog entry, it is apparent that there is a lot of discussion surrounding pricing, because Xamarin offerings are planned to be commercial. Of course, the other common discussion point is the viability of these products, which Xamarin currently plans to release as a suite. As one commenter to de Icaza's blog entry mentioned, Android already has Java, and Windows Phone already has C#, so C# for Apple iOS might be seen as one of the only real benefits being offered here (i.e. no need to program in Objective-C, which does not have a reputation for being a "beautiful language"), even given the fact that platform portability is what is being sold.

HAPI Announcement: Anniversary and Community Survey

Another round of recent HAPI (HL7 Application Programming Interface) announcements this past week mentioned its 10-year anniversary, in response to which I offer the team congratulations, as well as a survey it offered to its open source developer community to get a better guage on its user base:

Hi Everyone,

This October, HAPI will be 10 years old!

In anticipation, we are thinking it would be nice to take the pulse of the HAPI user community and see who is using it for what. The survey is very very quick, it's one page and 8 multiple choice questions. Your answers will help to set priorities for the future, and also help us to decide whether to switch from CVS to a different version control system.

You can find the survey here: https://sourceforge.net/apps/limesurvey/hl7api/index.php?sid=69291&newtest=Y

Cheers,
James

Offering a community survey is a great idea that more open source software projects should offer their users. As much as I integrate open source software into my projects alongside both custom development and COTS software packages, this was the first survey from an open source developer community I have ever received in all my years in consulting.

The following are my responses to survey questions:

• Who are you? Check any that apply.

Software developer developing software which uses HAPI or embedding HAPI into another product

• Are you currently using HAPI?

I have used HAPI in the past

• Where are you located?

North America

• Organization - Describe your organization or company, if applicable. Check any that apply.

Medium software development company (21-100 developers)

• Do you check out a local copy of HAPI's source code? We are considering a move to a new version control system (VCS). If you are interested, tell us which one you think we should use. Check as many boxes as apply.

I would like to see the project using Subversion (SVN)

• HL7 Version 3 - We are considering beginning work on suport for HL7 version 3. Please share your thoughts. Check as many boxes as apply.

I would like to see HAPI adding HL7 v3 support

• Getting help on HAPI - Check any that apply.

I subscribe to the HAPI mailing list

I would like to see an online forum section on the HAPI website

I would like to see better documentation on the website

HAPI Announcement: Version 1.2 Beta Released

Readers of this blog know by now that I have used HAPI (HL7 Application Programming Interface), an object-oriented HL7 2.x parser for Java, with such a high level of success that I am compelled to pass on significant announcements. The release of HAPI 1.2 Beta was announced via email two days ago:

Hi Everyone,

Just a quick note to say that HAPI 1.2-beta1 has been posted for testing. This release should be finalized within two weeks.

This release has no new features, but corrects a number of issues. In particular, several issues relating to the handling of the Varies type (OBX-5) are corrected.

See the changelog for more info: http://hl7api.sourceforge.net/changes-report.html. Thank you to everyone who contributed!

Download it here, or update your maven POM to reference version "1.2-beta1".

Cheers,
James

Ps, if you haven't already, fill out the HAPI survey!