Mike`s Blog - Work

How to implement password policies using business rules modeling

info@mhaller.de (Mike Haller) — Sat, 29 May 2010 13:34:46 +0200

We all know that passwords ought to be strong - strong enough to withstand common attack vectors, such as brute-force dictionary attacks or plain guessing. Most software systems with identity management also incorporate some kind of password policy enforcement and their configuration options (here, here, here and here).

There are even commercial standalone tools focusing on enforcing password policies. For example, the Password Policy Enforcer by Anixis or Specops Password Policy. Many of these products enable administrators to define policies and configure rules to prevent users from chosing weak passwords and comply to corporate security policies.

In this blog post, I'd like to show the principle steps in implementing a password policy enforcement component using flow rules, decisions and scoring (bonuses and penalties) to calculate the strength of a given password using Visual Rules. In contrast to commercial tools, which often already integrate with domain controllers, this example only shows the rules, not how it could be integrated into the Windows domain or into a web application.

Continue reading "How to implement password policies using business rules modeling"

Our score at The Joel Test

info@mhaller.de (Mike Haller) — Sun, 18 Apr 2010 19:19:00 +0200

How does my company/my team score at The Joel Test?

Let's see...
1. Do you use source control? YES
2. Can you make a build in one step? YES for most products, NO for others.
3. Do you make daily builds? YES
4. Do you have a bug database? YES
5. Do you fix bugs before writing new code? NO
6. Do you have an up-to-date schedule? NO. Either it changes too often, or stuff gets moved, or we're behind the schedule because we forgot something to do.
7. Do you have a spec? NO
8. Do programmers have quiet working conditions? NO. Coders interrupt each other very often.
9. Do you use the best tools money can buy? NO. The only good commercial tools are PL/SQL Developer and JProfiler. All others are open-source or other free tools with bad usability or incomplete integration (e.g. The Gimp, M2Eclipse)
10. Do you have testers? NO
11. Do new candidates write code during their interview? NO
12. Do you do hallway usability testing? NO. Occasionally we do, with at most 1 other "user".

Final score: 4/12

According to Joel, that's above average, but still too bad. We'll have to work on that.

The things i'm going to change next:
5) - fixing existing/known bugs before writing new code/new features.
2) - making all our high-level builds automated, not only single artifacts.

What concerns me most is point 7), although I haven't got a clear idea why and how to write a spec for something which is already being built. The current plan is to use the user's manual and developer's manual, extract abstract information and then detail it out into an architectural overview documentation.

Dynamic Applications

info@mhaller.de (Mike Haller) — Mon, 16 Feb 2009 00:15:00 +0100

What are Dynamic Applications?

It's the software-way of putting the business people back in charge. Today, changes to enterprise business software takes ages to get into production. Endless analyze-redesign-implement-test-deploy cycles affecting multiple stakeholders: IT, QA, vendors and of course the sponsor.

How would it feel if the first three stakeholders could be removed from the process, once the application has been finalized in its initial state? How about giving the sponsor or business department the ability to adapt and change applications on their own? How about giving them the ability to change complex business logic, fine-tune parameters and model work flow to reflect the reality when and as soon as it changes?

Continue reading "Dynamic Applications"

Atwood System of Real Ultimate Programming Power

info@mhaller.de (Mike Haller) — Sat, 14 Feb 2009 13:45:48 +0100

With Coding Horror, Jeff Atwood has one of the best programming blogs ever. Yesterday he blogged about The Atwood System of Real Ultimate Programming Power, which I find so great that I need to repeat it here, for the sake of marketing:

DRY

KISS

YAGNI

I would really like to inspire my collegues. I want them to read blogs, to read programming books, to improve themselves all the time. Some of my team's members are doing this. Some don't. And as Jeff wrote, the guys who really need improvement are not the ones reading blogs at all. They just don't care.

Late Friday evening, just before Kai and me went off to get some beers in Markdorf, another team's member told me that his day had gone really bad. He wanted to do a pre-release for his customer and the day ("Freitag 13.") seems to have put all kinds of strange errors on his way. Like Maven not resolving dependencies, Hudson not building for two days, ActiveMQ losing connections etc. I was shocked that he didn't try to find the root cause of his problems and fix them (like learning how to control Maven and do real releases, instead of pretending to do releases and just do it manually), but he put in most of his effort to work around the problems. Fixing symptoms never helps.

He spent hours to work around all kinds of errors, instead of fixing his release process and to get it right once and for all. I bet that his team will have the same problems on the next release anyway and that they'll start crying at Maven all over again. Just for the sake of "I don't care how this complex software engineering thingy is supposed to work, i just want to get my crappy code packaged somehow so I can send it to the customer, forget about it and get home asap."

Enemy #1 is Time

info@mhaller.de (Mike Haller) — Tue, 13 Jan 2009 07:39:00 +0100

Yesterday was a tough day in some way. Just when I thought we would finally get some time to work dedicated on the project, clean it up, implement new features, updating the documentation etc, a call from management interrupted .. well, the whole working day. The project had some interesting life time so far, as it's used for various specific solutions and each time we created a new branch for the customer, so the project teams working on that version can make their changes, patches, updates without disturbing anyone else and vice versa.

However, each time we created a new branch of the software library, the administration gets more and more complex and chaotic. And now, we're going to have yet another branch due to a tight timeframe. We can't settle on the current HEAD and work on it until it's done - that'd probably just take too much time and the customer-projects need it within a couple of days.

It could be worse though. (And yes, it's going to be worse, I dare to predict that.) It's not that we haven't got any tests or not have continuous integration etc. We've got all that. But that alone doesn't make it work right. And to make life even more interesting, the team's increasing. We'll have to find some time to instruct the new developers and they need time to familiarise.

Please wish us luck

Enterprise Instant Messaging

info@mhaller.de (Mike Haller) — Tue, 28 Oct 2008 21:56:47 +0100

Yippey! Today is the time for celebration: we officially got Instant Messaging at work. Forgotten are the days of using Outlook or network shares to send logfiles, screenshots and snippets back and forth. Also it's really nice to be able to react to messages while hanging on the phone.

We're using Jabber (OpenFire server) and i'd like to integrate the build server.
Thanks, IT Infrastructure team! I owe you

The Platform: Java Business Integration

info@mhaller.de (Mike Haller) — Tue, 14 Oct 2008 10:00:00 +0200

We're going to bring one of our frameworks - The Dynamic Business Application Framework - to the Java Business Integration (JBI, JSR-208) world.

Today, The Platform provides components, services and core functionality vital to any business application. Based on top of that, The Platform shall become more open for reusability, flexibility and modularity. One of the many topics is to hop onto the Web 2.0 and SOA wagon. Our developers/users will be able to quickly get their dynamic applications created by The Platform connected to any services-oriented architecture and integrate it with existing corporate IT landscapes.

So, while peeking a quick look on the whole JBI topic in general, i found some worrying statements by James Lorenzen:

"I believe the biggest failure of JBI has been communicating clearly what JBI is and how to use it. It took me many months until I felt like I actually "understood" JBI."

"many months" is not exactly what I've planned to invest, just to find out what JBI is and how it works. Actually understanding a technology must occur very quickly. Else, the time lost with investigation may harm the whole project. Being able to quickly adapt and understand new technology is vital to technology-oriented projects/frameworks/people. A business-oriented project may chose whatever technology is already settled. That's plannable and fine for the project. A technology-oriented project needs to be much quicker, as there's no "meat" in the project itself. It only consists of infrastructure.

"With XML being so verbose I believe SM or OESB would probably dislike a 3 MB XML file getting pumped through it."

Someone who "actually understands" JBI and used it for months (and probably years by now) thinks that a 3MB XML will be too large for ServiceMix or OpenESB? I wonder what the implementors of those JBI containers were thinking of what we (the users) are going to put through JBI. I mean, come on, i'm going to send data and lot's of it. I'm sure that "Hello World" works well, but did you guys ever thought about that HelloWorld is only the start and if they wanted us to really do business with it that we would stick with small data sets? Business is about data. Payload - and really lot's of it.

"I remember the first video I watched when the light bulb finally went off. It was a video on how to use the Sun SMTP BC and creating a Service Assembly with Netbeans. After I watched that video everything just came together for me and my co-workers."

That sounds like a good hint. I'll try to find that video about Sun Simple Mail Transfer Protocol Binding Component (i expanded the abbreviations on purpose).

The Platform: First Contact

info@mhaller.de (Mike Haller) — Mon, 13 Oct 2008 10:00:00 +0200

At the very same time as the financial crisis 2008 is happening, I've been working on software development projects in the credit risk rating area. As one of the developers of the Credit Risk Rating Platform, my goal is to give our customers (the banks) the ability to manage credit risks and the ability to quickly adapt to changes in the rating calculation. Our customers want to be able to change the logic how ratings are calculated. And they want to be able to do that on their own and very quickly.

Formerly they all used a bunch of proprietary pieces, put together into ugly Excel sheets and Visual Basic spaghetti code. This looks fine in the books and every business guy can do it or at least change some formulas in there. However, lots of different Excel documents with lots of sheets and lots of colors and lots of different mathematical and statistical functions and lots of macro code and lots of cycling dependencies between cells ... well, you get the point. It just becomes plain unmanageable and chaotic. ("Which LGD excel sheet was used for customer X? I cannot find the latest version on the network drive...")

"The Platform" let's customers change the way the software behaves after it has been rolled out. "The Platform" is the core of our Credit Risk Rating Platform. With The Dynamic Business Application Platform, any new logic can be brought into the application by the customer without the need for a software developer to change a single line of code. (Of course, this only applies to the core application. The systems usually are solutions with additional features which are not based on the DBAF.)

Experts like financial analysts can now model how the program should calculate. They do it visually, transparently and well-documented with tool support. What has once been deeply hidden somewhere in a formula cell near the end of some Excel sheet is now visually describable, versioned, documented and tested. And it looks much better. Compare for yourself, how the two concepts look like:

Before: (with Excel)

After: (with Visual Rules)

The graphics do not show the exact same, i just wanted show how they're conceptually different. For example the Excel formula G10:=NORMSINV(B10); will probably be very similar in Visual Rules, something along the lines of DefaultThresold[10] := normsInverse(ProbabilityOfDefault[10]);.

One of the advantages is that the formula can now be expressed with more meaningful names, it can be described (the name of the blue assignment note is "Calculate PD" instead of "C10" in Excel) and documented. And you can see loops and decisions directly in the visual model. This is really good and helps to navigate quickly in complex rating models, even after months and years. Just think of the times where you have looked at some Excel formulas after years and wondered: "Did I write this garbage?! I don't remember what $G$I is and how the heck this all works. It'll take weeks to understand it again."

New project

info@mhaller.de (Mike Haller) — Fri, 02 May 2008 22:45:11 +0200

Started to work on a new project and in a new team today.

After having an interesting and nice time at the last project in Switzerland, i'm looking forward to new challenges. Having spent a couple of years in an enterprise service oriented architecture landscape, with plenty of integration tasks, interaction with (business) people and support tasks, the new project is self-contained and seems to be pretty straightforward. It's going to be a plain JEE Web Application and incorporates the latest cutting-edge technology of business rules modeling.