Writing clean CSS has to be the most difficult thing. This story probably sounds familiar: you start a new project and tell yourself that’s it, this time I’m going to write clean CSS. It lasts a few days and then the code quickly spirals down into a mess.

A lot has to do with the language itself, it sucks and you don’t have a choice. While in the back-end you have several languages to choose from, for the front-end you end up with CSS one way or another. Using supersets of CSS that “compile” into it – such as LESS – alleviates many problems but doesn’t take care of the bad parts: the features that are more trouble than they are worth.

The bad parts are nesting, #id selectors and tying classes to specific HTML elements. Avoiding those dramatically improves code reusability.

Abusing nesting

Nesting is very common. It is often misused to style elements based on where they are instead of what they are.

Let’s use this blog’s CSS as an example: .widget-area .widget li { padding-bottom: 10px; } gives padding to all the list elements in the sidebar. There are a few problems with that:

• It will backfire. If I add another listing in the sidebar it will have unusual padding, which may or may not be what I want.
• It’s not immediately reusable. If I need a new padded list somewhere else I can either wrap it into a .widget-area div (which brings in additional styling) or find the related CSS code and add a new selector. Neither solution is ideal.
• It’s contagious. Let’s say I am adding a new list inside the sidebar, but this one should have no padding. Because of the CSS specificity rules the only way to do it is to write an even more specific selector to override the older one, which makes the situation worse.

You can avoid those problems by styling elements based on what they are and not where they are, for example having .padded-list li { } and applying the class to the parent ul. It is still nesting but in this case it’s acceptable: you are using it to style a padded list, not to style all the lists that happen to be in the sidebar.

#ID selectors

The HTML specification states there cannot be more than one element with the same ID. This by itself kills any reusability of the code: you cannot reuse the styling for any other element.

And sure, there is only one element now, but what if months from now someone adds a second one? You can’t predict the future! Class selectors have no disadvantage whatsoever over id selectors and allow for code reuse, so you should always use the former over the latter.

Tying classes to elements

The Hungarian notation in disguise: h4.sidebar-title. What if you decide the tile should actually be an h3? You have to go find the CSS code and change it, which is frustrating.

This feature is also completely unnecessary as long as the class names are not excessively generic.

Conclusion

Limiting yourself to element and class selectors while avoiding nesting as much as possible gives you a great framework:

• The element selectors give the default look for each HTML tag.
• The class selectors allow you to override the style based on what the element is, which makes code reuse much easier as the project grows larger.

This is the trick to having clean CSS.

A big annoyance in software development is having to wait around for tasks to complete; the larger the codebase, the more common it is. Some examples:

• Compiling and deploying the project.
• Pushing and pulling new code from the version control system.
• Running automated tests.
• Generating and converting assets.

All this waiting around is a productivity nightmare which is sometimes underestimated, especially if the task itself doesn’t take long. On a large ASP.NET project I am working on, the web engine spends roughly a dozen seconds or so on startup tasks before the first page can be displayed. This happens after each compilation.

At first look it doesn’t seem that big a deal: it’s only 12 seconds after all! However – coupled with how often we recompile – those 12 seconds feel like forever while staring at a blank screen. This leads to an urge to do something else, such as checking out Hacker News or watching a video on YouTube, and the next thing I know 30 minutes have passed and I’m reading about spontaneous human combustion with no recollection whatsoever of how I got there. Whoops!

Someone more disciplined than me may prefer to spend that time writing documentation or reading tickets on the bug tracker. Unfortunately that’s still going to a be big productivity hit as the problem is the task switching – we’re just not wired to do that:

Task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code.

If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.

The best way to resolve this problem and live a more productive life is to cut down the time you spend waiting or eliminate it altogether, for example by skipping all non essential startup steps while compiling in debug mode and using top-notch developer machines. This will also make programmers happier because let’s face it: having to wait for the computer is just frustrating.

Some waiting times are however impossible or unfeasible to eliminate. Compile times for large enough projects can take minutes even with the best hardware available, and there is simply not much you can do to eliminate them completely. If this is the case try resisting the urge to do something else and just stare at the screen until the task completes (assuming it doesn’t take an absurdly long time). By doing so you will avoid task switching: the number one productivity killer.

We are all familiar with URLs: the string uniquely identifying the requested document. However, we don’t always consider they are more than that: URLs are user facing and should be considered important UI elements.

They should be clean, understandable, semantic, hierarchical and not excessively long.

If the URL looks like garbage people won’t click it

A study conducted by Microsoft found URLs play a vital role in assessing the security and credibility of a website:

Edward Cutrell and Zhiwei Guan from Microsoft Research have conducted an eyetracking study of search engine use (warning: PDF) that found that people spend 24% of their gaze time looking at the URLs in the search results.

We found that searchers are particularly interested in the URL when they are assessing the credibility of a destination. If the URL looks like garbage, people are less likely to click on that search hit. On the other hand, if the URL looks like the page will address the user’s question, they are more likely to click.

(source: URL as UI)

After all the URL is one of the first things you see when visiting a new website, and first impressions are important. A clean and understandable URL simply looks professional.

Not only clean, but semantic and hierarchical

URLs must have meaning and be hierarchical. Search engines just love semantic URLs and it’s also a usability matter: URLs can serve as a navigational aid, sort of secondary breadcrumbs.

Let’s take the amazon page selling the mirra chair as an example. The URL seems written by someone rolling their head on the keyboard: http://www.amazon.com/gp/product/B0002K11BK/ref=sr_1_5?ie=UTF8&qid=1348439859&s=home-garden&sr=1-5. Now compare that with http://example.org/furniture/desk-chairs/herman-millers-mirra-chair.

Not only does the latter look good but it also communicates you are in the Furniture > Desk Chairs category. There is also an added bonus: it’s just begging to be hacked. It’s intuitive you can go to the list of all furniture just by removing parts of it, http://example.org/furniture/.

Meta information

URLs can contain information about the page contents before they are even clicked. This is very advantageous in some communication mediums, such as chats, IMs, tweets, emails and forums.

Compare someone linking in a chat https://news.ycombinator.com/item?id=5489039 versus https://news.ycombinator.com/5489039/if-the-earth-were-100-pixels-wide. The former tells you little to nothing, the latter gives you a good idea what it’s going to be. This makes you more likely to click it if it sparked your interest.

Hello, it’s 2013

Clean URLs are certainly more popular than they used to be but it’s still somewhat rare to find websites meeting all the characteristics listed above.

We also have a huge black sheep: Google. Even in 2013 we still have https://www.google.com/search?q=characteristic#hl=en&safe=off&sclient=psy-ab&q=example&oq=example&gs_l=serp.3..0i20l2j0l2.14456.15234.3.15346.7.4.0.3.3.0.84.292.4.4.0…0.0…1c.1.8.psy-ab.N7EClFK_p4g&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.44770516,d.ZGU&fp=9d62ffac663ef7ec&biw=1920&bih=944. The reason for that monstrosity is a mystery, especially considering https://www.google.com/search?q=example produces exactly the same page.

Put the effort required to make your URLs user friendly; it’s worth it and usually doesn’t require a lot of work.

Suggested reading

• URLs as UI
• pushState, the new alternative to location.hash in multi-state pages.
• mod_rewrite for Apache.

There is a large number of cryptographic hash algorithms out there and it’s not always obvious which one should be used. I’m going to talk about the most popular ones: Md5, Sha1 and Sha2.

Md5

Md5 should never be used as it is not secure. From wikipedia:

The security of the MD5 hash function is severely compromised. A collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor (complexity of 2^24.1). Further, there is also a chosen-prefix collision attack that can produce a collision for two chosen arbitrarily different inputs within hours, using off-the-shelf computing hardware (complexity 2³⁹).

This is not news by any means. Recommendations against its use first starting appearing in 1996, almost two decades ago, and yet its usage is still widespread.

Sha1

Some collision attacks against Sha1 exist but are not currently practical as the CPU power required is estimated as costing almost $3 million for each hash.

Even if Sha1 can be considered acceptable for most uses, Sha2 is all-around a better alternative: it is just as fast, more secure, and the only potential downside is the larger space required for storing the hash. If for some reason this is a concern (we’re talking about 32 bytes instead of 20) truncating Sha2′s output is still more secure than using Sha1.

The only reason Sha1 should be chosen is for interoperability reasons.

Sha2

Sha2 is the successor of Sha1 and has 4 different variants, each with a different digest size (output size):

• Sha-256 should be chosen in most cases where a high speed hash function is desired. It is considered secure with no known theoretical vulnerabilities and it has a reasonable digest size of 32 bytes. For things like hashing user password, though, a function designed to be slow is preferred: a great one is bcrypt.
• Sha-224 uses the same algorithm as Sha-256 (except for the initial seed values) simply truncating its output. It was created because its digest size has the same length as two-key Triple DES keys which can be handy.
• Sha-512 is different, using 64 bit numbers and having 80 rounds (versus 32 bit numbers and 64 rounds of Sha-256). Its digest size – 64 bytes – is very large and it is probably overkill for most uses.
• Sha-384 is the same as Sha-512 (again, except for the initial seed values) but truncated to reduce its digest size.

Performance

I ran a benchmark of all the hash algorithms available in the .NET framework. I found that all hash functions are very fast with the slowest computing over 100,000 hashes per second and that sha-256 is actually faster than sha-1.

Conclusion

• Do not use any of these functions for passwords; use instead functions that are designed to be slow such as bcrypt.
• Never use MD5. It was broken many years ago.
• Use Sha1 only if you must for interoperability reasons.
• Use Sha2 in all other cases. Of its variants, Sha-256 is usually the best alternative; Sha-384 and Sha-512 are probably overkill but can be chosen for added precaution.

While using WinSCP – an application that lets you transfer files between computers – a user came across the following dialog box:

Oh, man.. There are so many things wrong with it I don’t even know where to begin.

• “Never ask me again” is evil. Once you check it (usually by mistake) you are doomed for eternity. To uncheck it you have to go through the settings and, if this dialog is any indication, I can’t even begin to imagine what that will look like. I shiver just thinking about it. Reformatting your PC is going to be easier.

• Buttons should be able to stand on their own. The label “Yes” forces you to read the text at the top while “Overwrite” immediately communicates what it does.

• The choices must be mindless and unambiguous. If “No” skips the file what does “Cancel” do? If I choose “Append” will my local file be appended to the remote file or vice versa? Which file will be kept if I choose “Newer only” (they have the same date)? Not only the choices are difficult, they are ambiguous too.

• The help should be helpful. Users typically turn to the help only as the very last ditch effort (they hate to read) so the help should be short, pertinent and to the point. WinSCP instead greets you with yet another cryptic dialog box, adding to the frustration.

• The less choices the better. Keep only what is really needed – in this case “Overwrite” and “Skip”. Anything else is better handled by a dedicated tool.

Windows 8 has the same dialog and it couldn’t be any better. Good job, Microsoft!

We developers are at a disadvantage: usability problems are not obvious to us.

• We are the ones who create the software and know all about it.
• We are more technically proficient than the average user.
• To us the software is the goal; we use it mainly to test it. To the user the software is the means; they use it to do something else. They have considerably less tolerance than us when the software gets in the way.
• We take a sense of pride in our creation and sometimes we want to implement features when they are not really needed.

Usability is extremely important: it’s what makes or breaks your product. Getting it right can be simplified down to don’t make your users think. They’ll love you for it.

A few months ago I bought the 15-inch MacBook Pro Retina laptop planning to run Windows on it almost exclusively since I work on the .NET platform (and I’m also not crazy about Mac OS).

I found that running Windows on the MacBook has quite a few quirks, an aspect rarely touched by the existing reviews, so that’s what I will be talking about.

The Retina Display

Let’s start right away with the retina display: its greatest strength and also greatest weakness. The 2880×1800 resolution is stunning but the UI elements are very tiny. And by tiny I mean literally unreadable – even with perfect vision.

Rather than decreasing the resolution – which causes a loss of quality – the recommended way to enlarge UI elements is to increase the DPI leaving the actual resolution at the native 2880×1800. The DPI settings can be found in the Control Panel’s Display section and out of the box Apple’s Boot Camp sets it to 150%, but even with that you will quickly find out the text is too small. I found the optimal DPI to be 168%: the text is big enough to be read and small enough to not take up too much screen real estate.

Unfortunately a surprising large number of applications have problems with high DPI, varying widely in severity. Usually the higher the DPI the more severe the problems, which is why I don’t recommend going higher than 168%.

Most of the serious problems can be fixed with some tweaking; an example is Firefox. Firefox doesn’t support DPI scaling at all and greets you with unreadable tiny text, but this can be resolved using the Default FullZoom Level addon. Not everything can be easily fixed though: the address bar will remain very tiny, and so will FireBug.

Another problem is if you attach an external screen the increased DPI will stay in effect and changing it back to 100% requires you to log off for some reason, even in Windows 8.

Widespread lack of support for non-default DPI is a big deal; do not underestimate it. A lot of applications won’t “just work” out of the box anymore. Even after tweaking the settings, it usually won’t be perfect.

Fortunately extremely high resolution displays are becoming more and more widespread and developers have begun working to fix the issues in their applications. Skype and Chrome had serious problems back when I bought the laptop but now work perfectly.

Battery Life

The MacBook Pro comes with two graphics cards:

• The power-saver Intel HD Graphics 4000, integrated into the motherboard, which is used when you are not running any graphics intensive applications.
• The powerful, power-hungry Nvidia GT 650M.

On Mac OS the laptop automatically switches between the two graphic cards but Windows always uses the power hungry Nvidia card, eating up your battery very quickly. In fact on Mac OS the battery lasts almost twice the time it does on Windows.

The Nvidia card also runs considerably hotter. Even while simply browsing the internet the laptop can get really hot to the point of being actually painful to touch in certain places.

We can only hope Apple will work on a bootcamp update to support graphics cards switching under Windows.. But I’m not holding my breath!

The Keyboard

The Alt and Windows keys are swapped on the Mac keyboard with the windows key (labeled as ⌘) to the left of the alt key rather than to the right. This can be easily fixed using AutoHotkey and a script to swap the Alt and Windows keys.

The Good

I focused mainly on the bad but the MacBook has plenty of good – even when using Windows:

• The performance is really great. Compile times are fast, Visual Studio runs smoothly, and overall as far as performance is concerned it beats all the other laptops.
• The trackpad is the best in the world. You can do some serious programming even without a mouse, something that I cannot say for any other trackpad I have ever used.
• Even with all its problems, the retina display is great. It’s smooth and crisp, it has great colors and watching movies on it is a pleasure.
• The looks: with its unibody alluminium enclosure and the attention to detail only Apple is capable of, the laptop looks modern, simple, elegant and robust. It’s just beautiful.
• BootCamp works well and is very simple to set up. It works with Windows 8 too, although you need some tweaks to run its control panel.

Conclusions

The MacBook Pro is not necessarily a bad choice for Windows programmers but don’t underestimate the problems you will run into. The experience is not seamless and not everything will “just work”. If you can deal with some tweaking and accept some minor problems and annoyances go for it, otherwise there are plenty of other laptops to choose from.

Microsoft’s SQL Server 2008 isn’t exactly the easiest software to install and the documentation for the setup process is enormous and confusing. It’s also fairly useless if all you want is install the damn thing on your development machine as quickly as possible. This is where the guide comes in.

Just follow the steps and you’ll have a working SQL Server running in no time.

1. Start setup.exe. If you are using Windows 8 you may see a dialog warning you that “This program has compatibility issues”; just select “Run the program without getting help”.

2. Select Installation on the left sidebar and then click New installation or add features to an existing installation.

   

3. Keep clicking OK, enter the product key (or select a free edition), accept the License Terms, and install the Setup Support Files (yes, there is an installation for the help files that explain how to do the installation).

4. In Setup Support Rules click next; in Setup Role, select Sql Server Feature Installation.

5. In Feature Selection enable the following features:

   • Database Engine Services
     • Full-Text Search
   • Client Tools Connectivity
   • Management Tools – Basic
     • Management Tools – Complete

   

6. Continue clicking next until you arrive at Server Configuration.

7. In Server Configuration use the built-in Network Service account for the SQL Server Agent and the SQL Server Database Engine.

   

8. In Database Engine Configuration click Add Current User and choose whether you want to log in using Windows authentication mode or Mixed Mode. The former lets you connect exclusively using your Windows account credentials, the latter lets you connect with your windows account or with the entered system administrator password.

   

9. Keep clicking Next until you reach Ready to Install and then finally start the installation.

10. If all went well, you should now have a working SQL Server. It wasn’t so difficult after all, was it? Let’s test it out. Start SQL Server Management Studio from the start menu (it was installed along with the server), use “localhost” as the server name and click Connect. You should be now connected to the newly installed SQL Server.

Geotargeting is the practice of delivering different content to different visitors based on their location (usually obtained through their IP Address). For example visiting google.com using an IP from Romania redirects us to google.ro and delivers a Romanian page.

I don’t know about you but I certainly don’t speak Romanian! As if this wasn’t enough, local search results are pushed to the top:

Google’s goal is to return the most relevant and useful sites in response to a user query. As a result, the results we show to a user in Ireland may vary from the results returned to a user in France.

Some visitors certainly find this behavior handy but there are better ways to do it. Three different hints indicate the language preference:

1. The address entered. Visiting google.com and not google.ro clearly indicates the desire of seeing the English version. However Google automatically redirects to the localized domain – second guessing the user – unless /ncr (which stands for No Country Redirect) is appended to the address. This trick is rarely known and poorly documented.
2. The Accept-Language HTTP Header. “Accept-Language: en-US” is a very strong indicator the user either has an English browser or went through the trouble of changing the default settings, again indicating a preference towards viewing English pages.
3. The IP address. The only hint the user has no control over.

There are several reasons someone may want to visit google.com while outside the U.S.:

• They are working in or visiting another country.
• They do not speak the native or official language.
• They prefer English.
• They want the best search results possible without local results pushed to the top.

Google is just one example; the practice of making assumptions based on the IP Address is very widespread. While it’s never a good idea some bad ideas are worse than others:

1. You see a page in the local language with a sidebar offering to switch to the English version instead, making geotargeting a simple annoyance. Fortunately most sites fall into this category. High profile examples include Google, YouTube, Yahoo! and MSN.
2. You see a page in the local language but the control to change language is not easy to find. Sometimes the control is even a few pages away (none of which are in English) making changing the language difficult to impossible. Sites in this category include PayPal and Microsoft.
3. You cannot change the language. The only mainstream site with this huge flaw is Apple’s App Store. You are forced to use the language of the country tied to the entered credit card information; there is no way whatsoever to change it. As if this wasn’t enough English app reviews and ratings are filtered out.

Let’s put an end to geotargeting; don’t use the IP Address to assume the user’s preferred language.

Reviews for the new Visual Studio 2012 seem overall positive. I tried it out and I like all the improvements. One thing I especially appreciated is the backwards project compatibility: Visual Studio 2012 and 2010 share the same project files format meaning each developer can decide when to upgrade (or not), rather than the entire team having to upgrade at the same time or keeping two sets of project files as was previously the case. About time!

However there is one thing I didn’t like one bit: the user interface is atrocious. Everything is monochrome. The new icons are small, not intuitive and difficult to spot (without colors they all look alike). All the menus are UPPERCASE.

Andrew Binstock said in his review of Visual Studio 2012 (which is a good read – I recommend it):

Speaking off the record, a Microsoft employee with the Windows 8 team confessed that the Metro team was “very surprised” when they saw how the Visual Studio team had interpreted the Metro guidelines.

If you didn’t get a chance to see how the interface looks like here it is:

Fortunately with a few tweaks you can make Visual Studio 2012 look like VS 2010.

Step 1: Changing the icons and making menu items lowercase

The icons are embedded in the DLLs and there is no known way to change them through a simple plugin; you have to replace the newer icons with the older ones by directly patching the DLLs. Fortunately Visual Studio Icon Patcher allows us to do just that.

It should take only a couple of minutes:

• Prerequisite: have both Visual Studio 2010 and 2012 installed.
• Make sure you have no open instances of Visual Studio (either version).
• Download the icon patcher and start VSIP.exe.
• Type in the console:
  • extract: Extracts the old icons from Visual Studio 2010.
  • inject: Injects the previously extracted icons into Visual Studio 2012.
  • menus: Makes menus lowercase.
  • x: Quits the program.

We made some progress but we are not there yet. Everything is still too… gray.

Step 2: Changing the color theme

For this we need another small application: the Visual Studio 2012 Color Theme Editor. Using it is straightforward:

• Download and install it.
• Open Visual Studio (or restart it if it was previously open).
• You should see the Color Themes window (if not, open it by going to Tools => Customize Colors).
• Select the blue theme.

Here we go! We now have an interface that is very similar to Visual Studio 2010.

Final result:

Hassle-free registration and login pages can be quite difficult to create. Here are 10 tips any website should follow.

1. Make signing up completely optional if you can. The list is not in a specific order, with one exception: this. Users resist registering and they see it as a chore especially if it’s their first visit.

   Think if registration is a real need; avoiding it altogether will make user participation surge. For example removing registrations increased revenue by $300 million for an e-commerce website, and 30% of constructive Wikipedia edits come from unregistered users.

2. Request only the information you need. Users are reluctant and suspicious giving out personal information if the reason you need it is not obvious for them. Because of this it’s a good idea to explain why you need the information:

   

   Cutting down the fields will also make the registration process faster and the page less cluttered. For this reason avoid optional fields altogether; place them in the “Account Settings” page instead.

3. If the submits the form with an invalid value do not clear the password field, except if the problematic field is the password itself.

   This one is a personal annoyance of mine. If I forgot to enter my email why do I have to retype my password (twice)? There are no security reasons preventing the password from being sent back to the browser. It’s in no way less secure than when the browser sent the password in the first place. And yet this practice is almost ubiquitous! Coupled with the lack of client side validation it will probably result in the user punching the screen.

4. Log users in automatically after they register or reset their password. How many times have you seen the message “Thanks for signing up! You can now login with your username and password”?

   Why not log the user in automatically? They just entered their login information seconds earlier, and now they have to do it all over again. The same applies for password resets:

   

5. Do not limit the maximum password length. This practice screams “We don’t hash our passwords” and “We don’t know what we’re doing”. Once hashed it always takes the same amount of space in the database and the longer it is the more secure, so there is no reason whatsoever to put an upper limit on its length.

   

   Extreme limits (such as 4,000 characters) put in place to prevent having to hash extremely long passwords clearly entered as part of a DDoS attack are fine.

   Additionally, tailor the password complexity requirements based on the type of the website. If it’s a forum about cars do not require a mix of uppercase, numbers and symbols; and if you do, make sure the requirements are clearly spelled out and located next to the field.

6. Take advantage of client side validation. jQuery validate makes client side validation trivial and the form more user friendly.

   For fields that must be verified server side (such as whether the entered username is already taken) make an ajax call and report back to the client while the form is being filled.

7. If you add a password strength meter, make sure you know what you are doing. Length is what makes a password strong, not the character set used. A long password made up of lowercase letters is much more secure than a short password with alphanumeric characters and symbols.

   

   L4$$so!:) is a terrible password; not “very strong” at all! How Secure is my Password reports that with it would take a desktop computer only 20 days to crack it, and this with a brute force attack. Considering it’s a common english word with common substitutions (a => 4) – that any half decent password cracker attempts – it will get cracked in considerably less time.

8. Be careful with GET requests. Every time a request has a side effect (such as logging the user out of the website) it must be a POST, not a GET.

   The HTTP standard states GET requests must be idempotent (a fancy word meaning “this has no side effects so you can do it more than once”). Based on this requirement browsers are not afraid to perform automatic GET requests, for example to fetch an image. If the logout page accepts GETs and you visit a page containing <img src="http://example.org/logout" /> bam! You are logged out.

9. Do not overly validate email addresses. RFC 2822 is the official standard that dictates the syntax email addresses adhere to. And it’s not as simple as you may think. Did you know "hello@world!"@example.com is a perfectly valid email address?

   You can use a 426 character regex, reject potentially valid email addresses, or not bother validating them beyond checking if a ‘@’ is present. The last choice is typically the best. If your users don’t want to disclose their real email there is little you can do anyway.

   If you use .NET however I suggest to construct a MailAddress object with the entered email – new MailAddress(email) -; if it throws an exception you should refuse the email as there’s no point in accepting email addresses, even if valid, if you can’t actually send email to them.

10. Do not limit login attempts. Sometimes you can’t quite remember your password and getting locked out of your own account after the third try is not nice. If the system locks the account itself and not the IP address it can also be a serious security risk: malicious users will be able to lock someone else’s account by entering the wrong password on purpose several times.

    A better alternative is to require the user to fill a CAPTCHA after a certain number of attempts instead.