Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)

So based on this requirement I assumed that the code to do this would be common and widely available; much to my surprise there are rather few samples that do this, and of those I found they only showed the last four (which when you are handling a lot of credit cards, searching for an account by the last four isn’t all that helpful) and were often rather fragile.

So I whipped this up, hopefully it’ll be useful to others.

public static string MaskCreditCard(string value)
{
  const string PATTERN = @"\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|" +
    @"6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|" +
    @"[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})\b";
 
  var replace = Regex.Replace(value, PATTERN, new MatchEvaluator(match =>
  {
    var num = match.ToString();
    return num.Substring(0, 6) + new string('*', num.Length - 10) +
      num.Substring(num.Length - 4);
  }));
 
  return replace;
}

The regex pattern is from Regular-Expressions.info and should detect most major cards.

Happy 20th Birthday Visual Basic!

My, what a journey it’s been. Almost fifteen years ago I randomly bought a copy of “Visual Basic 5: Deluxe Learning Edition” – I was just 15 at the time and wanted a new hobby, and writing software seemed like it would be fun. In those early days, I had no idea what career I would choose, and really didn’t intend for software development to become the dominant force in my life – I just wanted a better, more productive way to spend my time during the summer.

In the years that have went by, I became passionate about the field, and all it encompasses (possible obsessed, if you believe my wife) – it’s been the driving force in my life. Today, I manage a team of 6 developers, and have a fun start-up with some friends (that someday won’t cost me money every month) – and all because I bought that book. Overall, I have a lot to thank VB for, it really did get me started in this field.

Today though, my language of choice has moved on to newer options – I prefer bleeding technologies when I can use them – but VB will always have a place in my heart, and I’ll always follow its progress as it continues to transform and adapt to an ever-changing world. As the most popular .NET language (contrary to what many of the C# developers think), it plays a vital role in the development of the framework and the ecosystem.

In the conversations I’ve had with Anthony about the future of the language, I greatly look forward to writing about its 25th birthday; I expect those will be exciting times for the language and the entire .NET ecosystem.

But for all of the wonders we are responsible for, there is one thing we can’t do (no matter what amazing powers some executives think we have to make them look better or earn them more bonuses):

You can’t fix stupid.

I’ve often described development as being a professional problem solver, and we are often tasked with rather challenging problems to solve. Sometimes the problems are purely technical – making something new possible that previously was impracticable or even impossible, sometimes it’s all about efficiency, other times it’s about image and controlling how people see a company. When the problem is the user though, you know you’re in for a rough day.

I was recently given such a task – the users weren’t listening to their supervisors and they wanted the software to force these users to do whatever it was that management told them they should be doing. I was given less than a week to find ways to make people that don’t want to work, work.

Basically, users fall into three simple categories:

• Power Users – these users understand software, and require little, if any instruction – more than anything, you give these users a tool and stay out of their way.
• Average Users – odds are, your mother or father falls into this category. They understand enough to get by, and with a little instruction they should have no trouble.
• Idiots* – odds are, you work with one of these users. You lead them by they hand, and show them exactly what to do – just in time for the boss to walk by and praise them for doing a good job (and 10 minutes later you find them playing in traffic, somehow defying Darwin in the process).

For users of the last category, there’s just not much you can do.

I always do my due diligence while building software; doing all I can to make it simple to use, flexible, and forgiving of user error. I always use extensive data validation, carefully worded instructions and dialogs, and do my best to follow the various best-practice guides for UI and UX; yet for all this effort and design – I can’t write software that thinks for people or makes judgement calls based on business rules that only they know (probably because they make it up as they go).

No matter how helpful or intelligent an application is, or how idiot-proof you think you’ve made it, reality is that you simply can’t fix stupid – you can’t take an incompetent person that refuses to think for themselves and turn them to into a great, productive asset. After years in this industry (which has made me just a little cynical [in the way that Sol only seems little when compared to Betelgeuse]), I’ve come to understand something rather disturbing: idiots keep getting better.

Somewhere, right now, idiots are working to build even better idiots – and that’s a really scary thought.

We can make a user more efficient by automating tasks, providing better information, or helping to manage their workload – what we can’t do is make them smarter, make them think through their actions, or force them to do what their managers tell them. Yet we are, at least on occasion, asked to fix this problem. 

Despite our best efforts as professionals and passionate developers; if a user won’t think – we just can’t fix it.

* – I define an idiot about the same way I do someone that’s lazy; they have no medical issues or legitimate handicap. They just don’t want to think or work (probably both). Those that are handicap or have learning or medical issues are a very different story and not the target of this article; I donated time and services to charities that served the disabled for a number of years, I highly recommend that all developers do it – it’s a very rewarding experience to see your work make somebody’s life better and it teaches you quite a bit about how people interact with technology.

In a message on their Development Talk group entitled “consistency and ecosystem opportunities” – they make their position clear: we no longer need you. To demonstrate this, let me point out a couple quotes that deserve attention:

Twitter will provide the primary mainstream consumer client experience on phones, computers, and other devices by which millions of people access Twitter content (tweets, trends, profiles, etc.), and send tweets.

and this gem:

More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience.  The answer is no.

Independent, 3rd-party developers have driven the progression of Twitter from an extremely simplistic group SMS service, to a massive and near ubiquitous communications system used by millions of people.  As Twitter fought whales and struggled to keep servers running, outside developers were busy building new and better ways of using the service; now that Twitter has gone mainstream and is doubtlessly looking at revenue options, they’ve told these passionate users that they are no longer needed. The users that evangelized the service, and promoted it in countless ways, suffering through long stretches of downtime remained loyal and energized, pushing the service to become ever more. Twitter, it seems, has no such loyalty to these champions and flag bearers of the service.

If you want to build an application in the Twitter ecosystem now, you are pushed to the outskirts; building integration as a feature of a separate system (such as instagram), or building for vertical markets which by definition have a far more limited market potential. This is a dangerous time to be invested in an application that relies too much on Twitter; there’s no telling what or who they will ban next.

Twitter did make it fairly clear that existing applications can “continue to serve your user base” - there was an air of a threat in the statement, and given their willingness to ban a major player, I can’t help but think that they will be looking for chances to kill off other clients, to further solidify their control of what users see.

If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service.

At best Twitter has alienated passionate users, at worst they have inspired new competition with the goal of being what many of these users wanted Twitter to become, before they shifted their strategy away from the core service, to controlling and enforcing a sub-par user experience.

Step 1: Modify your PATH to include the bin folder of the JRE. Mine looks like this:

C:\Program Files\Java\jre6\bin

Step 2: Set the ANDROID_SWT variable (you’ll probably need to add it) to the \tools\lib\x86_64 folder of the Android SDK. Mine looks like this:

C:\Android\SDK\tools\lib\x86_64

With these two changes, everything seems to work as expected. Why this is required on 64bit but not 32bit I’m not sure, but this does seem to solve the problem.

Perhaps I’m more aware of this because I maintain an internally developed shared library that my company uses in every application; but regardless of the scope of the project you should always assume that someday you will hand the project off. Many developers think little about what happens to their code after it passes on to another; what other developers will have to deal with, or how their efforts will be perceived.

When I’m training a new developer there are a few points I try to reinforce as much as possible:

1. Code is only good if other developers can work on it without extensive training. If it takes days or weeks of introduction to get a new developer up to speed, then you’ve done something wrong¹.
2. Clever solutions are no better than an ugly hack if it’s not clear what you are doing. If the code isn’t clear then it’s not maintainable, if it’s not maintainable then it’s junk.
3. Assume you’ll be hit by a bus. Always write code with the assumption that you won’t have the opportunity to cleanly pass the code off to a new maintainer. Never assume that you’ll have time to come back and clean things up later.
4. Always perform design reviews, no matter the size of the project². Once you have a design in mind, talk it through with a at least two other developers. Just because you think it’s clean and clear doesn’t mean that others will see it that way as well.
5. Be consistent, always. I’ve seen more projects ruined by people doing things “their way” than anything else. Match style and design when working on an existing project. Be careful when adding new techniques, technologies, or methodologies to an existing project; unless you are willing to update the entire code-base, you can easily create a minefield without realizing it.

If you want your work to be seen positively after you move on, start thinking about your heirs today. The opinion they have of you will be almost entirely based on what they see in your code – not the stories or memories left behind.

¹ – There are always exceptions; these are generalized guidelines, not hard and fast rules.
² – This includes “throw away” projects, many projects that are intended to have a short life end up living far longer than intended. This is the most likely place that your heirs will find code that makes them question the quality of your work.

Open Atrium is new on the scene, with beta 1 being released just 4 days ago – though it’s already rather polished and seems to work well. While there are some hiccups with the installer and a disappointing lack of documentation, it’s still very easy to install and takes only a few minutes to get running.

It has all the major features that you would expect, plus a few extras such as a twitter-like shoutbox system. Here are the highlights:

• Blogging
• Calendar
• Dashboard
• Document Storage
• Task Management

Being open source and self-hosted adds some nice benefits; unlimited customization, full control of your data, and my favorite: can be installed on a non-public web server. Having you project management system sit behind a VPN is a great way to avoid data leaks and embarrassments.

I’m still debating which is best, Basecamp or Open Atrium – but if you want to save some money, Open Atrium is worth looking into.