Month: September 2014

Robert C.Martin wrote an interesting article about a set of metrics that can be used to measure the quality of an object-oriented design in terms of the interdependence between the subsystems of that design.

Here’s from the article what he said about the interdependence between modules:

What is it that makes a design rigid, fragile and difficult to reuse. It is the interdependence of the subsystems within that design. A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules. When the extent of that cascade of change cannot be predicted by the designers or maintainers the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate. Managers, faced with such unpredictability, become reluctant to authorize changes. Thus the design becomes rigid.

Continue reading “Abstractness vs Instability: Neo4j Case study”

OSGi became very popular today, thanks to its modularity approach and its capability to enforce logical boundaries between modules.  Many known applications chose it to enforce the modularity, we can enumerate eclipse, GlassFish and Oracle JDeveloper.

To understand OSGi concepts we will try to go inside eclipse IDE, which uses equinox as OSGi container. Continue reading “Go inside the Eclipse IDE implementation to understand how OSGi works”

Few years ago, after releasing the CppDepend product, many users ask us for a Mac OSX version to analyze the Objective C code base, last year we decided to develop XClarify, the CppDepend like for Objective C.

Our GUI was developed using .Net and porting all the code to Objective C has the big drawback to maintain two versions, time for our  developement team to make some research on how to reuse our .Net code for the Mac OSX version?

What’s the solution to port a .Net code base to Mac OSX?

When searching for all possiblities, the trivial one was to use Mono, it wasn’t an easy task, specially because we use DevExpress which is not compliant with Mono due to the overuse of P/Invoke calls.

In our first version we used the Mono Winforms implementation to avoid big changes on our code base, and we finally released our beta version. After contacting some Objective C developers to give XClarify a try, we discoverd our big mistake, and here are some feedbacks from Mac OSX users:

Having an application that looks like Visual Studio on OS X is enough of an insult.

I’ve downloaded your product for the trial but when I’m trying to run it it is asking for X11. I’ve read a couple of things on line that says that installing this X11 over Apples could cause instabilities – what are the risks in doing this and why is it needed?

Thanks to beta users we were warned about the biggest mistake we have done and time for us to quickly find another solution to correct this, so how to make a product that meets the Mac OSX users requirements?

The solution was to use the cocoa framework, and fortunately a cocoa porting to Mono is provided by Xamarin which offers the MonoMac library, but using MonoMac will impact all the Gui code base, and we can’t have anymore one codebase to maitain. but we learned well the lesson, what’s more important is not to have one code base to maitain but what the user is waiting for when he uses the product.

We decided for our second version to use MonoMac and remove all dependencies with System.Windows.Forms and System.Drawing libraries to use Cocoa instead.

Concerning removing the dependency with System.Drawing, there’s the following library, but it’s not mature yet, and some blocking bugs will encourage you to not using it.

To make the porting easier, we needed a good Gui library which simplify the Gui developement, and we found a powerful library, named Eto. Its developement team is very active and the library is stable.

After releasing our second version, we had to package the product to a standalone application which must be easy to install without installing other requirements. The MonoMac library is not sufficient for that and you have to use Xam.Mac which is not free.

As conclusion if you want to port your .Net application to Mac OSX, an interesting solution is to use Xamarin Studio, Xam.Mac and Eto libraries, and especially avoid using System.Windows.forms.

Two years ago, our support team received a request from a customer, which said that our product doesn’t works in a specific machine.
After further investigations we found the problem, but it was very difficult to detect what’s exactly make this machine different from others and which configuration cause the problem?

The source of the problem was this registry key :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\fipsalgorithmpolicy

What’s fips in this registry key is related to?

From Wikipedia:

Federal Information Processing Standards (FIPS) are publicly announced standardizations developed by the United States federal government for use in computer systems by all non-military government agencies and by government contractors, when properly invoked and tailored on a contract. The purpose of FIPS is to ensure that all federal government and agencies adhere to the same guidelines regarding security and communication.

The FIPS 140-2 is used to accredit cryptographic modules. And MD5 is not FIPS compliant.

By default the FIPS mode is disabled in windows machines, however the user could enable it if he want, and if so, your software will stop running as expected if you use the MD5 hash algorithm.

Microsoft doesn’t recommend enabling FIPS as explained in this article, but the possibility to enable it still exist and we cannot force our customers to disable it.

In our case we are lucky that the customer helped us to understand this issue, but in many cases it will be very difficult to understand its origin.

As conclusion it’s better to avoid the MD5 hashing algo for windows developement.