Email Validator

Often I need to validate emails so I go online and figure out the regex needed in order to validate it. Recently I came across a class from Microsoft –

As we all do, I figured I could do a better job and refactored it into this:

public class EmailValidator
    public bool IsValid(string emailAddress)
        if (string.IsNullOrEmpty(emailAddress))
            return false;

            emailAddress = Regex.Replace(emailAddress, @"(@)(.+)$", DomainMapper,
                                  RegexOptions.None, TimeSpan.FromMilliseconds(200));

            return Regex.IsMatch(emailAddress,
                  @"^(?("")("".+?(?<!\\)""@)|(([0-9a-z]((\.(?!\.))|[-!#\$%&'\*\+/=\?\^`\{\}\|~\w])*)(?<=[0-9a-z])@))" +
                  RegexOptions.IgnoreCase, TimeSpan.FromMilliseconds(250));
        catch (RegexMatchTimeoutException)
            return false;
        catch (ArgumentException)
            return false;

    private static string DomainMapper(Match match)
        IdnMapping idn = new IdnMapping();
        var domainName = match.Groups[2].Value;
        domainName = idn.GetAscii(domainName);
        return match.Groups[1].Value + domainName;

Don’t get me wrong.

Recently I received an email and it went a little something like this:

This article makes a compelling case for Enterprise Architects as active participants in sprints and as close partners to developers:

Some of the points I got from the article:

As part of the development team, architects primarily act as customers

In the traditional setup, an “us versus them” attitude often exists between the architecture team and the rest of the development organization

By working together, the architects and developers can begin to appreciate their respective objectives and openly deal with conflicts when they arise.

I didn’t see anything that mentioned joining sprints. This articles speaks to the involvement from all personnel in the system delivery effort. This is a Lean principle “all hands on deck” and it advocates the inclusion of everyone right from the beginning. Enterprise Architects are not called to be involved in the physical implementation of the system but to “act primarily as customers”. This means handing down requirements and helping decided on the priority of the requirements.

I often think that the term “Enterprise Architect” is misunderstood as the “super duper technical lead”. Expecting an “Enterprise Architect” to actively engage in the development cycle and the business cycle is unrealistic. Enterprise Architects would engage at the same level as the Product Owner. Due to the diverse nature of Enterprise Architecture, technology lag can be created and having an EA trying to ramp up during development will cause more annoyance than benefit, especially when certain teams are focused on one technology and other teams are focused on a completely different technology. This is made quiet clear with the statement:

The architecture team must have a much broader perspective, because it must balance a particular application’s needs against those of the entire enterprise portfolio.

“This level of cooperation requires the same kind of resource commitment as that expected from business users.” – this is a key point.

The article is a little frustrating in that it talks about “Enterprise architects” and then uses the generic term “architect”. Each architecture discipline requires a different skill set and level of commitment. The Enterprise Architect is probably the furthest from the development effort in terms of commitment to time spent implementing, with the solution architect and software/application architect progressively getting closer to being actively involved in the development effort.

(This is not a rant on the content of the literature previous provided, just a note regarding the fact that the definitions of architecture roles has been changing over the years with other architecture roles introduced to fill the gaps.) The article is dated 2005 and “what” an enterprise architect is has changed significantly since then. A more up to date article is probably required.

A pretty accurate and slightly less dated article:


We also need to bear in mind that “Agile” is a concept and “Scrum” is an agile project management discipline. Too often we think because we are using “scrum” we are agile. The only way to measure if you are agile (according to the definition produced by the term’s founders” you subscribe to:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

This applies at all levels of the effort: architecture, analysis, requirements gathering, implementation. The primary driving force behind agile is trust. A group of people does not a team make – even if they are trying to deliver the same thing.

ERROR: relation “hibernate_sequence” does not exist

Recently while working on a Spring Boot project, I grabbed a fresh copy of the source from our GIT repository. After importing the Maven project I attempted to run the test suite attached to the code base. The unit tests ran fine but as soon as it hit the portion of code responsible for testing the integration with the RDMBS, which is Postgresql, I was met with the following error:

org.postgresql.util.PSQLException: ERROR: relation “hibernate_sequence” does not exist

After a bit of investigation into the code that was attempting to run, it appeared that the issue was coming from an annotation. The following line attached to the Id was the culprit:

@GeneratedValue(strategy = GenerationType.AUTO)

After a little more digging, it became apparent that the database had initially been set up manually and this sequence had been generated during the creation of tables. When Hibernate was tasked with creating the tables in a fresh database, it couldn’t seem to find what it was looking for.

To resolve the issue, simply changing the annotation value got it returning the expected behaviour:

@GeneratedValue(strategy = GenerationType.IDENTITY)

While looking at this, it became apparent that we needed to start doing two things:

  1. Rely less on Hibernate to create the tables
  2. Perform the integration tests against multiple database vendors to verify that we have met our mandated condition to make the application vendor agnostic.