Ben Langhinrichs

August, 2014
     01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Search the weblog

Genii Weblog

Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.

Wed 27 Aug 2014, 10:03 AM
In my previous post,  In which I kick myself, I pointed out the rather obvious but belated point that databases, especially samples, that use the Midas LSX should recognize whether Midas is installed and make that point rather than simply failing. That may be a simple realization, but it took a lot of work to fix in a reasonably elegant and comprehensive way. Fortunately, the code may be useful to others, especially those who have an LSX to install. One thing I don't show in the video is that the page with instructions could easily include the appropriate files to install. That would not make sense for the samples, but might make a lot of sense for a customer who wanted to add the script and page to a database using Midas or another LSX.
The video is only a minute and a half, or you can download the Export to CSV sample from the Midas LSX samples page to see this in action, or check out the code at
Best viewed in HD. Closed captions will be provided shortly for following in English or improved auto-translation.

Copyright © 2014 Genii Software Ltd.

Mon 25 Aug 2014, 03:42 PM
I fancy myself to be fairly good at listening to customers and solving their problems. But that is not always a good thing.
One of the hardest things to do when supporting users is to stop and really listen to both them and to yourself. It is relatively easy to simply answer the question or address the concern, basically to "fix" the problem. Honestly, it is very much the same experience men often have in relationships. How do you step away from identifying and trying to fix "the problem" and instead think about the underlying situation and what it really means? What are the underlying causes and currents you are missing which led to the issue, as that is often more important that "the problem" itself.
A Midas customer wrote today with a problem running the Export to CSV database, basically due to a version issue. I gave her a solution, and she wrote back to say it worked. Case closed, right? Well, not really. We are working very hard to make the Midas LSX, and particularly the export functionality, easy enough to use for non-developers, and by that measure we failed. The person who wrote was perfectly capable of re-compiling the agent, but shouldn't have needed to. In looking at the situation, I realized that the approach we take with samples assumes that the user has already solved the problem of getting the software, getting the evaluation license and installing them. But what of the developer who downloads the sample and tries it without getting an evaluation license.
This is where I kick myself. It should be insanely obvious that if the user doesn't have the Midas LSX installed, the sample should inform them of that and show them how to get the software and evaluation license. How can we not do that?
So, mea culpa, mea culpa. We are on it, and soon the sample databases will identify whether the software, and the correct version of the software at that, is installed. It may take a few days or longer to develop the right code and roll it out, but we'll get there. In the meantime, <ouch>.

Copyright © 2014 Genii Software Ltd.

Thu 21 Aug 2014, 08:48 AM
At Genii Software, we usually promote our products using simple videos or straightforward blog posts. But it occurred to me, what if we promoted software like Buzzfeed?

So, let's see what it might look like.
6 Questions You Didn't Know To Ask About Genii Software's Products
1. How many Notes developers does it take to export your whole database to CSV using Midas?

2) What will your customer do if you send a printed catalog instead of an eBook he can read on his tablet? (Midas can make customized eBooks instantly)

3) When might your CEO realize his/her email looks embarrassing to clients? When should you get CoexLinks Fidelity to fix that?

4) How will IBM respond if you demand they fix email rendering (like CoexLinks Fidelity does)?

5) How will your boss respond if you waste time trying to export rich text without Midas?

6) What is it like for Notes shops migrating email systems without CoexLinks Fidelity?

On second thought, perhaps we'll stick to blog posts and video demos.

Copyright © 2014 Genii Software Ltd.

Wed 20 Aug 2014, 12:14 PM
There is a philosophy called YAGNI that many software developers and programmers will recognize. The acronym stands for You Aren't Gonna Need It, and it has been popularized along with the ideas of extreme programming and continuous refactoring (see YAGNI definition). The basic idea is that you shouldn't build anything until you actually need it. It probably even helps a lot of developers and teams, but at Genii Software, we go the opposite direction. A good part of what we build is not currently necessary, is purely speculative, or is sufficiently far ahead of what customers want that it could be considered a waste of time.
Yet we virtually always need it, and we seldom have to the time to create it at the time it becomes necessary. While this is mostly true of smaller parts of the code which nobody externally will see, it can also be seen in the larger, more visible efforts, such as:
CoexLinks Fidelity: Most of the functionality and development was done in 2009 as part of iFidelity, but the world wasn't ready. Now, after more enhancements protecting against data loss (see 4 minute demo) and the addition of the Message Store (see 3 minute demo), companies large and small are lining up to take advantage of the product whether because they are moving to Outlook or Gmail and need better rendering of application emails, or simply have the budget available now to enhance their outbound email without a huge commitment. If we were to recognize that need now and start development, a finished product would be two years away.
Exporting to EPUB - Building on even earlier work to manipulate and process XML and zip files for Open Document Format, we put a lot of time in 2011 to export rich content to EPUB format so that a customer could make an instant eBook. I posted the results of this a few times in 2011 in posts such as Viewing Notes/Domino fixes on a mobile device, though the functionality was not released until Midas LSX V5.00 in November 2013. We kept working on it, winding up with a fairly elegant and powerful solution (see 5 minute demo). At first, nobody paid attention. The video only has 65 views, yet we have had five companies buy Midas for the Export to EPUB feature in the past three months, and three more are evaluating it. The main reason seems to be that the mobile devices, especially iPhone/iPad, have added native support for EPUB files, so sending customized on-the-fly polished eBooks to customers is more and more appealing. Again, if we saw that need now, we'd be years away from a polished product.
So, YAGNI? Not so much. More of IYBITWCE (IYou Build It, They Will Come... Eventually)

Copyright © 2014 Genii Software Ltd.

Tue 19 Aug 2014, 11:34 AM

The high fidelity email rendering provided by CoexLinks Fidelity 3.6 is often viewed as primarily about appearance, but it is also about preserving data integrity. This 4 minute demo shows a number of examples where actual data loss occurs when certain elements are sent via email and rendered by either the IBM Notes 9.0.1 client or the IBM Domino 9.0.1 server. (None of these data losses started in 9.0.1 - earlier versions were even worse). Problems shown have all been reported by Genii Software customers in rich text rendering, although the examples are contrived for effect.
Data issues fixed by CoexLinks Fidelity and shown in the demo:
  1. Image resources (disappear with both client/server rendering)
  2. Text and cell colors (light green/dark green confusion in client rendering)
  3. Table borders and cell borders (table borders disappear in both client/server rendering, cell borders rendered poorly in server rendering)
  4. Section titles (disappear completely in client rendering, render poorly in server rendering)
  5. Layout regions (disappear completely in both client/server rendering)
  6. Stored forms (not rendered by client except Body field if present)
  7. Buttons (disappear completely in both client/server rendering)
Best viewed in HD. Closed captions will be provided shortly for following in English or improved auto-translation.
To try out the new CoexLinks Fidelity including the Message Store, fill out an evaluation request or contact us for more information at

Copyright © 2014 Genii Software Ltd.

Fri 15 Aug 2014, 09:49 AM
I was very interested to read Paul Withers' article, 10 Reasons All Companies Should Use Open Source. I agree with many of its points, but wanted to bring up one caveat that seems too often ignored. If I might throw some caution on his first point, 1. Good Developers Write Good Code, Great Developers Steal Good Code, it would be to remind people that great developers can steal bad code as well.
As the Goto Fail vulnerabilty, and even more the Heartbleed Bug should remind us, the fact that code is widely used or open source, even widely used open source, does not absolve a company using it from testing. It should be assumed to be buggy, insecure and incomplete until proven otherwise. Personally, I think any open source library added to your own software should be treated as if it were written by the most junior developer. It might be great, but it also might have glaring holes that are waiting to trap the unsuspecting. As I wrote when the Goto Fail vulnerability surfaced, the great failing was not that the code had a bug. All software has bugs. The great failing was that Apple's QA didn't adequately assume it might be vulnerable and try to attack it to see if they could get through. As the Heartbleed bug proved shortly thereafter, the problem was even more prevalent when the code was open source, as it seems that many companies trusted OpenSSL when a relatively straightforward QA test should have shown that the vulnerability existed.
Trust but verify. Open source code (and your own code for that matter) may be very, very good, but you should test it as if it were buggy, insecure and incomplete. Do not trust "the crowd" to do your verification for you. In fact, with open source code you should add the element that a nefarious somebody may have planted a subtle vulnerability, so you should push the limits and assume the worst.
Note: If you find any problems, especially security issues, you should make sure the open source code is fixed and submitted to the originator as well.

Copyright © 2014 Genii Software Ltd.

Technorati tags: