03/07/2012

Craig Schumann on Source Control - Part Two



In Part One of this three-part interview, Craig discussed what you really get in Domino 8.5.3, whether this is enough for a typical Notes environment, and why you should have a source control method in place.

Below, he explains how DXL plays a major role in Domino's source control enablement feature (included in 8.5.3), and how that can impact source control methods. He also provides some guidance on which source control method could be right for your organization. Read on!

What are the most important things to consider when determining what type of source control is needed?
It’s important to know that all of the new source control enablement features in Domino are based on DXL.

For those who don't know, DXL is just an XML representation of a Domino document or design element. There have been a lot of improvements to DXL over the past few releases, but there are still issues with how things, especially rich text fields and form body elements, are exported. (Keep in mind that XPages are already stored as XML in a database, so this issue does not affect them). The upshot of this is that the element’s DXL representation isn’t the same as the way it was stored in the database. This might not be a showstopper for a lot of people, but it’s a huge issue for highly regulated industries where version control, change control, and accountability must be maintained at all stages of development. You can talk to anyone in the finance or medical industries about that!

But this doesn’t just affect management and auditors. It poses a major problem to any developer trying to implement a source control system, because it means an element cannot be rolled back to a previous version. This is the round trip or full fidelity problem.

One of the more important features of any source code control system is the ability to roll back to a previous version of a resource. The issue with DXL is that when you export something small, omissions in the design of the element will be silently stripped out if the exporter doesn’t understand them. Later, when you try and re-import them, even more things may be omitted. To make things even more complicated, this all assumes that the version of Notes that you used to export and import are the same. But if they are not, even more problems can be introduced. This makes it problematic to reliably roll back to any design element, especially if the version of Notes has changed since the element was checked in. IBM, to its credit, does offer an option to work around this deficiency by exporting the design elements in a binary format. This addresses the problem, because the DXL exporter and importer does not have to understand the XML structure; all it does is convert the binary data back into a binary field on the design element, so you don’t lose anything. Unfortunately, though, this poses a problem for a source control system. When you are reviewing changes between checkins, you very often need to do a diff of the 2 versions. But storing the design of a form in a binary format makes this impossible, since the diff tool can’t understand the data.

Along with all of this, you will also need to decide the kind of SCC tool you want to use. As I alluded to above, SCC tools are are basically broken down in to two types of workflow.

The most traditional is a locking type with a check out/edit/check in method. This is the way most source control tools like Subversion work. A user checks out a resource, makes a change, then checks it in. Until the user checks the resource back in, other developers can’t make changes to it.

The second is a distributed method with an edit/merge/commit style of working. Distributed tools, like Mercurial and Git, are all the rage right now, but I think they have a slightly steeper learning curve for people new to the source control world.

The way distributed tools work is that you can edit any resource as much as you want, because you are only changing your copy of it. When you are ready, you merge your changes with the changes that other developers may have made, then commit your changes to the main repository. The key difference here is the merge. Distributed systems do not prevent  other developers from changing the same elements. It’s up to the developer to sort out any conflicting changes before anything can be submitted. Depending on the size of the project, or the number of developers working on something, this can get pretty tricky, and it’s the reason why I don’t usually recommend these tools for Domino development. Unless you spend a lot of time in the source pane when you do XPages development, the merge might be the first time you actually see the source code for your XPages, and this is a bad time to learn how to read XML. Most of the XML diff tools are really good these days, but no matter how good they are, it doesn’t make any of the decisions for you, so you really have to know what you are looking at. Certainly, if you are the only developer working on database, you won’t ever run into this problem - but that would defeat the purpose of this type of tool, since the term “distributed” doesn’t really apply in the first place.

This is why I think the more traditional approach of check out/check in works best. It’s a little more cumbersome to work with, since it requires a higher level of communication within the team, but it also enables you to avoid the merge problem.

We welcome your comments and feedback on Craig's insights above. And look out for the conclusion to this interview (coming soon) in which Craig shares the source control methods we've developed and use here at Teamstudio.



O Category :

03/07/2012

Craig Schumann on Source Control - Part One



Below is the first of a three-part interview with Teamstudio Senior Developer Craig Schumann. In the interview, he discusses all things source control: What you really get in Domino 8.5.3, whether this is enough for a typical Notes environment, and why you should have a source control method in place.

Enjoy, and let us know your thoughts!

What are the real-world capabilities of the source control enablement support in Domino 8.5.3?
This is a new feature that lets you use a file based source code control system with your Domino applications. By file based source control, I mean applications like Subversion (CVS), Perforce, Source Safe, Clear Case, or even Mercurial and Git.


The way it works is by storing and syncing your NSF (either on a server or local) to a local copy represented by DXL. This can then be seen and controlled with your source code control (SCC) tool. At that point, it’s up to your tool of choice to provide the features you need. So, just to be clear:  Notes doesn’t have source control built in, but it makes it easier for third party tools to work with Notes databases, which wasn’t that easy in versions past.


Is this sufficient for a typical Notes development environment?
It might be. It really depends on your goals. First and foremost, tools can only support a policy of source control. What I see happening a lot is that organizations bring in a source control tool in order to establish control over their development process. But a tool alone cannot do this. Source control is not always easy, especially when you introduce distributed development teams. It’s not that the tools are at fault, it’s just that the problem is really hard. The job of the tool is only to make the necessary actions easier to manage or perform. If you don’t have 100% commitment to make the process work, from developers to management, no source control solution will work for you.


Why is it important for organizations to implement a source code control method?

There are a number of good reasons to implement source control. As a developer myself, I couldn’t imagine not having it as a part of my everyday routine. Not only does it provide a safety net when I need to roll back, but it also automatically documents all my changes for me as I commit them. I add detailed comments to go along with each change, so when I look back, I always know when a change was done and why I did it. For me this is hugely important, since I usually have trouble remembering what I ate for dinner last night, let alone why I rewrote some bit of code.


Beyond simple developer productivity, many companies operate in highly regulated environments where tracking changes to production applications is a matter of law. For example, in the US, the Sarbanes-Oxley act carries very stiff penalties for the executives of public companies who base financial decisions on systems that don’t have adequate internal controls. We’ve helped many companies that were at risk of failing to comply with SOX, because their Notes applications were not covered by a source control system.


What are the most important things to consider when determining what type of source control is needed?
If your company already has a source control tool in house, then sticking with that tool might make the most sense. However, there are still many things to consider.


If you don’t have a source control system in place, there are several cloud based offerings:


- For SVN-style hosting there is Google and SourceForge
- For Mercurial and Git you have bitbucket.org and github.com respectively - however, since they are hosted solutions, you will need to consider the security implications.

The really big thing to consider, though, is what kind of development you're currently engaged in. If you work mostly on new projects, with XPages and the like, you’ll be fine. However, if most of your time is taken up with “traditional” Notes development (Forms, Views, Outlines, etc.), then you need to think about a few things first: Namely, choosing the SCC tool that's right for you, and DXL and the complications it can introduce into your development environment.


Up next: Part Two, in which Craig will explain the pros and cons of DXL, and provide some guidance as to how to choose the best source control method for your organization. Stay tuned!






O Category :

03/05/2012

Unplugged for iOS is now available



With the Unplugged XPages Engine and HTML5, we’re introducing a simple yet powerful way to extend your Lotus Notes and Domino apps to iOS devices!

Unplugged works with Domino Designer to create mobile apps for iPhones and iPads, which update via mobile sync to Domino servers.And, the HTML5-based architecture of the Unplugged XPages Engine unleashes the full creativity of the mobile user interface designer – so you can create touch-optimized, visual, customized mobile apps for iOS that look every bit as good as consumer apps.

For more information on Teamstudio Unplugged, and all our mobile solutions, visit
http://unplugged.teamstudio.com.

Let us know what you think!



O Category :

02/13/2012

I will show you mine if you show me yours



I'll show you mine if you show me yours...

Okay, I'll go first.  This code is so bad I had to share it.  And let me be clear - this code is from R3 days.  But that means it may have been looked at many times AND LEFT ALONE!  We can all help Notes suck less if we stamp out code like this whenever we see it.

In this first example, the only line in this entire block that did anything IS COMMENTED OUT!  Just delete the entire block.

        If oppDoc.iprgWonPercent_SS(0) <> prvWonPercent And revType = "Configured Software" Then
                 
                  prvWonPercent = oppDoc.iprgWonPercent_SS(0)
                  If prvWonPercent <> 0 And prvWonPercent <> 1 Then
  '                        Call UpdateNextStep(oppDoc.RMReplicaID(0), oppDoc.imctContact_SS(0), revType, Format$(oppDoc.iprgWonPercent_SS(0), "0.#0"))                        
                  End If
                 
          End If
 

This next example is just sad.  I mean, who hasn't used @Select before?  Ever wonder why your application seems sluggish in December and snappier in January?   Try evaluating this expression in December.

monthdisp :=@If(months=1;"Jan.";months=2;"Feb.";months=3;"Mar.";months=4;"Apr.";months=5;"May";months=6;"Jun.";
months=7;"Jul.";months=8;"Aug.";months=9;"Sep.";months=10;"Oct.";months=11;"Nov.";months=12;"Dec.";"");

And this last one even says V2 in the code - come on people!

@If(@IsDocBeingLoaded; @If(TotDisc=""; 0; TotDisc); @V2If(@IsAvailable(Disc); Disc; 0) + @V2If(@IsAvailable(Disc_1); Disc_1; 0) + @V2If(@IsAvailable(Disc_2); Disc_2; 0) + @V2If(@IsAvailable(Disc_3); Disc_3; 0) + @V2If(@IsAvailable(Disc_4); Disc_4; 0) + @V2If(@IsAvailable(Disc_5); Disc_5; 0) + @V2If(@IsAvailable(Disc_6); Disc_6; 0) + @V2If(@IsAvailable(Disc_7); Disc_7; 0) + @V2If(@IsAvailable(Disc_8); Disc_8; 0) + @V2If(@IsAvailable(Disc_9); Disc_9; 0) + @V2If(@IsAvailable(Disc_10); Disc_10; 0) + @V2If(@IsAvailable(Disc_11); Disc_11; 0) + @V2If(@IsAvailable(Disc_12); Disc_12; 0) + @V2If(@IsAvailable(Disc_13); Disc_13; 0) + @V2If(@IsAvailable(Disc_14); Disc_14; 0) + @V2If(@IsAvailable(Disc_15); Disc_15; 0))

I think my eyes are actually bleeding!


O Category :

02/02/2012

There is more than one way to skin a cat



Americans sometimes use a funny little expression: There's more than one way to skin a cat.

This is a (kind of creepy) way of saying that there are several different ways to accomplish a given task. And this is my challenge. My developer side says to do it one way, but my admin side might have a different perspective.  In the end, a decision must be made one way or the other. Case in point:

Recently, I completed the first part of a source code control and build process management implementation (FYI, Teamstudio knows quite a bit about source code control). The team included Chris Blatnick of Interface Matters fame, Kevin Petitt of SuperNTF fame, and Jamie Magee of Martin Scott and NoteMan Tools fame.  It really was special for me to be able to teach these guys anything.  

All of us are familiar with other tools, as well, like the ones from Ytria. The point here is that you can be so much more productive if you invest in some tools. Of course, we all prefer that you choose *our* tools, but what we really want is to help you deliver the best solutions for your users in the most cost effective way possible. At the risk of repeating myself, that generally means you need to invest in some tools.  (For what it's worth, I definitely like the 'free' ones, but you should always keep in mind that you get what you pay for).

Anyway, here's the challenge.  I came across an agent that created a document collection by doing a search.  My first reaction (from the developer side of my brain) was to just create and use a view.  Further review showed that the agent ran once a week and only took 20 seconds.  That's when my admin side took over, and said: Why have the server maintain the index for this view all week long, when it would only be used once a week?  

Any thoughts?  Is a search always bad?  How much overhead is noticeable when maintaining the view?  Multiply this by dozens of databases.  How would you decide?


O Category :

Feeds

Custom Button Custom Button

Category Cloud

Disclaimer

The views expressed by the authors on this blog do not necessarily reflect the views of Teamstudio, those who link to this blog, or even the author’s mother, father, sister, brother, uncle, aunt, grandparents, cousins, step relations, any other blood relative - and sometimes not even the author himself or herself.

Comments on this website are the sole responsibility of their writers and it is assumed those writers will take full responsibility, liability, and blame for any libel or litigation that results from something written in, or as a direct result of something written in, a comment. The accuracy, completeness, veracity, honesty, exactitude, factuality and politeness of comments are not guaranteed. Oh, how they are SO not guaranteed.