Monthly Archives: March 2014

Installing MarkLogic on Linux Mint

As a Linux user, when installing the MarkLogic database for the first time you might notice that RPM is the only supported distribution format. This is great for users of RHEL and CentOS, but not so great for users of Debian and Debian-based distributions such as Ubuntu and Mint.

Here is a short guide to installing MarkLogic on Linux Mint.

After downloading an RPM installer from the download page, you’ll need to perform a few steps to converter the rpm to a deb installer.

Step 1: Install the prerequisite libraries

This is necessary to convert the installer from one format to another.

sudo apt-get install alien dpkg-dev debhelper build-essential

Step 2: Convert rpm to deb

This was tested on the CentOS installer for MarkLogic, but it should work with the other distributions too. Of course you’ll need to modify the name of the .rpm if you have downloaded a later version of MarkLogic.

sudo alien MarkLogic-7.0-2.2.x86_64.rpm

Step 3: Install the new deb file

This is just what you would normally do to install a file from the command line.

sudo dpkg -i marklogic_7.0-3.2_amd64.deb 

That’s all there is to it! Now you may continue exploring MarkLogic in the Linux distribution of your choice.

2 Comments

Filed under Software Engineering

Undoing Changes in Subversion

Recently I committed a number of changes to include a critical feature on a branch (that was to be tested and released soon). Almost immediately after finishing, I was informed that the feature would be slipped to the following release because of testing time constraints. It was disappointing that my extra work would not be seen as quickly, but understandable: this is the world we live in and we have an obligation to our customers to release responsibly. But I digress.

We quickly faced the problem: how do we remove all of my changes from the branch so it doesn’t go out in the next release? Other people had committed changes to the same files, and our commit history was intermingled.

Merge It

It’s easy enough to merge the branch to the trunk. But to remove the changes from the branch requires a little thought. Subversion has full documentation on merging, and on cherrypicking (which is what we want in this case). But it’s easier to just see an example.

Let’s say I’ve committed revisions 123, 134, and 137. I later find out that I need to remove these changes completely. We need the latest revision of the code to look like these changes were never made.

svn merge -c-123 -c-134 -c-137

This modifies my working copy as if I had gone in and removed the changes manually. My local files are modified, and on the next commit the changes from those revisions will be removed! Of course the changes and the undoing of the changes still exist in the commit history, but the revision at the head does not contain the changes, and in our scenario the feature will not go out in that branch.

Happy Merging!

Leave a comment

Filed under Uncategorized

Who is the Foreman?

This is a response to a response to a response. Bear with me…

Recently, Robert C. Martin (a.k.a. “Uncle Bob”) wrote an article called Where Is The Foreman. I’d encourage you to read this (and the other links here).

The gist of the article is that a construction site needs a foreman to ensure things are running smoothly, and likewise a software team needs a foreman for the same reason.

This prompted a lot of response, some positive, some negative. Everything ranging from complete rejection of the idea to some hybrid of the idea where the team shares responsibilities.

Bob responded to this with what he felt were some clarifications. He shifted the analogy to that of a coach. To sum up his response, he went through this line of reasoning:

  1. a coach is not a peer
  2. here’s a scenario without a coach: everything falls apart
  3. here’s a scenario with a coach: everything is ok
  4. we need coaches: a coach has commit rights and can revoke commit rights

Here is my response to his response.

A coach is not a peer

I would argue that because everybody has different strengths, every team member is a coach in the context of their strength. The JVM tuning expert can coach team mates on matters of JVM tuning. The design patterns expert can coach team mates on matters of design patterns. And so on… Not everybody is a peer in the same area, but everybody on a team is a peer on the team with the same rights and responsibilities.

Granted, a team is expected to have a spectrum of experience levels. Hopefully senior engineers will have more areas of expertise and do more coaching than junior engineers, but my point is that responsibility of instructing and helping lies with the team, not with a single individual.

Scenario without a coach

Bob (describing this scenario): “Nobody sees the stream of commits that is reducing the code coverage…” I would argue that Bob is setting up a Straw Man argument. He is describing a team that doesn’t have a foreman and proposing that the lack of a foreman is the problem. But if the foreman is the only person doing code reviews, then of course lack of a foreman is a problem… because lack of code review is a problem!

Scenario with a coach

Next Bob describes a scenario where there is a coach/foreman who recognizes problems and can intervene. I counter that this happy path is what would happen anyway if 1) all code was code reviewed by team members as part of the definition-of-done, and 2) team members raised concerns with each other first and escalated concerns to management as needed. Hopefully management is paying attention anyway! If there needed to be a larger conversation with an offending coder about declining performance, management is better equipped to have a conversation like that.

If you were the foreman for a dozen developers, and it was your responsibility to review every commit, it would literally be your full time job to do nothing but read code all day. That approach does not scale, and it is not sustainable. Maintaining the quality of the code, performing code reviews, and raising issues with team members and escalating to management as necessary is everybody’s responsibility.

Again, we grant that a team is expected to have a spectrum of experience levels. Junior engineers reviewing each other would likely result in missed bugs. But junior and senior engineers reviewing each other allows junior engineers to learn and senior engineers to catch quality issues. And at the top of the skill chain, there should be peers at the same skill level and qualifications able to review each others’ code.

Coach can revoke commit rights

Bob: “The foreman can revoke commit privileges.” We already have someone with this power. This person is called “the manager.”

Conclusion

Software engineering is a team effort, but it is not a sports team and it is not a construction crew. Maintaining code quality is the responsibility of the team and of every individual on the team. I propose that everything Bob describes about a foreman is something we should already be doing but maybe shaped a little differently: distributing responsibilities across the team (including development and management) as opposed to concentrating them in one or few individuals.

Leave a comment

Filed under Software Engineering

Principle of Least Astonishment

The Principle of Least Astonishment is well put by Wikipedia: “People are part of the system … the principle aims to exploit users’ pre-existing knowledge as a way to minimize the learning curve.” This principle is often demonstrated with UI design, but equally applies to API’s and programming models.

Let’s look at this principle in action for programming models.

Let’s get some Context

In Android, there’s a way to bind a click listener in the UI xml to a method in the code. This is the same functionality provided by HTML elements and Javascript, by the way, so this is a pretty normal paradigm that pre-dates Android. You can see from the Android documentation:

“you can assign a method to your button in the XML layout, using the android:onClick attribute. For example:”

 <Button
     android:layout_height="wrap_content"
     android:layout_width="wrap_content"
     android:text="@string/self_destruct"
     android:onClick="selfDestruct" />

“Now, when a user clicks the button, the Android system calls the activity’s selfDestruct(View) method. In order for this to work, the method must be public and accept a View as its only parameter. For example:”

 public void selfDestruct(View view) {
     // Kabloey
 }

So far, so good, right?

Android Fragmentation (No, Not That Fragmentation)

Recently I was converting some of my Android Activity code to use Fragments. I had a number of elements in the UI bound to methods in my Activity via “onClick”, so needed to copy those over into my new Fragment classes.

Let’s play fill in the blank:
The onClick in the layout bound to an Activity calls a method in that Activity.
The onClick in the layout bound to a Fragment calls a method in that ________.

What should we put in the blank here? If you are a new Android developer (like me), you might say “Fragment”. That’s what I thought, and I was wrong. If you are an experienced Android developer, you might say “… Fragment’s containing Activity” which would in fact be the correct answer.

Surprise, Surprise

I’m not the only person who got that fill-in-the-blank wrong. This scenario comes up from time to time.

Now, the solutions are easy to understand and implement. And I’m sure the Android development team had good reasons for this particular programming model. But I would argue that whatever those reasons were, the tradeoff was a violation of the Principle of Least Astonishment.

We were surprised that the first approach we thought of didn’t work and instead blew up with an Exception.

We were surprised to discover that the structures that apply to programming Activities did not apply to programming Fragments (which share many similarities with Activities).

We were surprised that the correct approach was a different programming model: programmatically assigning click listeners instead of using the onclick attribute.

Conclusion

Keep the Principle of Least Astonishment in mind as you design user interfaces, API’s, or programming models. An unsurprising piece of software saves your users time and frustration, which in turn saves the software company time and frustration (and money). This makes everybody happy!

Leave a comment

Filed under Android, Software Engineering