Ben Langhinrichs

Photograph of Ben Langhinrichs
E-mail address - Ben Langhinrichs






June, 2017
SMTWTFS
    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.


Tue 20 Jun 2017, 02:19 PM
As software vendors or application developers or anyone else who documents software or processes, we often face the need to come up with an example. The goal of almost any example or documentation is to be simple enough for the uninitiated to grasp while being complex enough to show the possibilities. This is often accomplished with more than one example, so that we can show both how easy it is with one example and how powerful and flexible it is with another.
 
But there is an interesting question of responsibility raised by examples. Are we responsible for those people who just grab the example and go with it, even if they should be modifying it? A classic, and rather extreme, case might be when your example includes "YourServer" or "YourDB.nsf" or even "Firstname Lastname". While it might lead to an embarrassing support call, the implications of someone actually using such an example verbatim are slight. Most likely, the process or software won't work until they plug in an appropriate value.
 
There is one class of example which is different. This is the case of somebody using an example with a password or encryption key that is intentionally weak. I read today that 15% of IoT users leave the default password, and we have all known users who use 12345 as a password or key. While it is clearly the responsibility of the user to be more secure, do we have a responsibility to encourage security? It is not a simple question, as even if we do, and use a complex password or key, that password or key is usually static in the documentation, and so inherently insecure.
 
The following comes from the OpenSSL wiki. It comes with a clear warning not to use that key, which is good, but it intentionally uses one of very few weakest DES keys, which seems an odd choice. Since the user is not meant to type the example exactly, why not use a more random secure key? But if they did, would that be false security since it was static? In a perfect world, the key used in the example might be random and generated on the fly so that every viewer saw a different key. Then, if the example were copied and pasted, a "good" key would be used. But is that really the responsibility of the documentation writer? I don't know.
 
Inline JPEG image
 

Copyright © 2017 Genii Software Ltd.

Mon 19 Jun 2017, 04:02 PM
I'm excited to announce I'll be speaking at MWLUG 2017 in Alexandria, VA on data analytics, extraction and visualization.
 
Finding the Gold in Them Thar Hills
They say everyone should visit their own region as a tourist, with eyes wide open to the treasures visitors see easily which we no longer notice. Likewise, those who have used IBM Notes/Domino for many years may not easily see the value embedded in data buried in various databases over these years. Patterns, trends, connections, all hidden in plain sight. In this session, we will explore the kinds of hidden treasure you may have, and different ways to extract/expose that treasure for data analytics and data re-purposing, as well as ways to use data visualization to make the gold you find shine.
MWLUG has proven to be a consistently excellent conference, and I'm delighted to have a chance to speak there again. But even more, I look forward to seeing all of you. If you'll be there and want to hang out, don't hesitate tweet at me or contact me through Facebook or email or phone. Anything but a brick through the window will work. If you'd like a meeting to talk about any of our products, especially our new CoexLinks Migrate, CoexLinks Journal and AppsFidelity Migrate, let me know in advance of your interest so I know not to bore you with talk of my latest novel. (Which will be awesome when I finish it.) If you want to hear about my novel, be forewarned that I can be obsessive.

Copyright © 2017 Genii Software Ltd.

Thu 8 Jun 2017, 04:48 PM
More than 17,500 documents in 110 seconds.
 
With a simple command from the server console, CoexLinks Migrate exports all email documents from a Notes email database into MBOX or EML format, both standards-based formats used by many email products as well as data warehouses and email vaults. Our high speed engine renders even complex rich text emails with high fidelity and accuracy.
 
But why not try for yourself. Request an evaluation license today.
 
 
As usual, closed captions are available.
 

Copyright © 2017 Genii Software Ltd.

Technorati tags:

Tue 23 May 2017, 12:31 PM
"After a migration, it is essential that the original content, context and intent are clear, as there is usually little recourse to checking the original source. In our experience, approximately 5‒10% of emails suffer from some form of fidelity issues, while 1‒2% suffer serious data loss or corruption due to rendering issues. These numbers may range much higher for organizations who have a long history of integrating Notes mail with their applications." - Mitigating Risk of Data Loss – Migrating Notes Emails
 
Click on the link to read about ten problem areas, and how we help mitigate your risk.
 
CoexLinks Migrate - Whether you are converting, archiving or migrating, we ensure the integrity of your company's email. (Application data migrations also available.)
 
 
If the data matters, you want it preserved. If the data doesn't matter, why are you migrating it?
 
Inline JPEG image
 
 
 

Copyright © 2017 Genii Software Ltd.

Wed 3 May 2017, 01:17 PM
If you work with customer/client companies who currently use or are moving away from IBM Domino, and you might be interested in reselling any of our CoexLinks products, don't hesitate to contact me. Opportunities available in most regions of the world. If you work for an email vault or data warehouse company which might be interested in expanding to ingest Domino emails, either archived or live, from client companies, I'd be interested in talking with you as well.
 
CoexLinks Fidelity is for outbound/mobile/web email fidelity. All three products use out proprietary rendering engine for the best fidelity available. (Applies to Notes/Domino/Traveler/iNotes.)
 
CoexLinks Migrate is for either converting mail in place (for Verse) or migrating it out to disk or elsewhere for use in archival systems or new email systems where all email is desired in a single place.  (Applies to Notes/Domino/Verse)
 
CoexLinks Journal is for journaling email into a secure vault or data warehouse for compliance, surveillance or analysis.  (Applies to Notes/Domino/Verse)
 
Below is an example of the importance of the high fidelity rendering. Whether you are sending email to clients, journaling or archiving it for later retrieval, or migrating it to another email system, you should expect at a minimum that it contain all the information in your email and that it look roughly similar. If you sell a CoexLinks solution to a client, you can have confidence that the fidelity will be top notch, and the data will be retained.
 
 
 

Copyright © 2017 Genii Software Ltd.

Wed 3 May 2017, 11:54 AM
I posted this over on Facebook, but though I'd share it here as well. We've been doing some performance tuning on CoexLinks Migrate, which let's you export your email, both MIME and rich text, to high fidelity standardized formats including MBOX and EML and Exchange Mail Journal Envelope format (basically a wrapped up EML file with all the recipients and such in an envelope.
 
Performance tuning is fun, but it isn't sexy. You take Software A which creates End Product B, work incredibly hard to make sure it still creates the exact same damn End Product B, but faster. Same input, same output, less time. Not sexy.
 
But it can be satisfying. Here are the results from my test this morning (run on an old PC, so your mileage may vary, but it is likely to be better).
 
Inline JPEG image
 
Performance tuning seems to be helping. This is exporting to MBOX format, which is much faster than individual EML files, but 6000/minute means averaging 1/100 of a second per document. Wow. This generated an MBOX file with size 0.93GB from a mail db of 1.62GB, for what it is worth. When I ran the same test on the same database generating EML files,  it did about 2600/minute and generated 1.8GB in total EML files. That's overhead for you. 
 
In case you wonder the practical needs for this kind of speed, we have a client with 5TB of archived email. Using a very rough approximation based on my own mailbox, that would take about 96 hours (approximately 4 days) generated to MBOX. It would take roughly 220 hours for EML format (approximately. 9 days). 
 
When we started tuning, it averaged 950/minute for EML (we didn't measure for MBOX then). At that rate, it would have have taken 602 hours (approximately 25 days). Now, because these are separate databases, you would either run it on multiple processors or multiple machines, but even dividing these numbers by 10 machines/processors would take 9.6 hours, 22 hours and 60 hours respectively. The longer it takes, the more chance of something going wrong and having to start that part over. In short, speed matters. Fast enough, and you can even re-do the whole thing if some assumption turns out to be wrong. Slow enough, and a mistake can make you miss deadlines.
 
But as thay say on Reading Rainbow, you don't have to take my word for it. Request an evaluation license today and give it a spin.

Copyright © 2017 Genii Software Ltd.