Recently, I started to learn how to do mobile apps. Instead of classic ToDo app, that everyone is so fond of, I decided I will do a bit more realistic application. It would include, for starters a first time initialization, that would run (what a surprise!) at first run of installed app. This initialization would check connection, register account on my server (using web api) and use SQLite as local persistent storage.
This might be a bit of a d’oh, but if you decide to handle exception, handle it properly. What do I mean by saying “properly”? Have you ever seen code like this?
var myClass = new MyClass();
This code is stupid. Exceptions are a sign of exceptional or unpredicted behaviour. Thus, they should be treated with all seriousness. The code above works fine, if no exception is thrown. However, we live in unpredictable world. Internet connection may die. Hard drive may crash. Computer can run out of memory. And, in the case above, as soon as exception is thrown, neither you nor user will have the slightest clue of what went wrong.
There are two ways to solve this:
- Re-throw exception using
throw;statement and handle it later on or
- Handle it in
catchpart of statement.
I understand that sometimes you just don’t see the need to handle an exception, but the least you can do is write the exception to log file.
In asp.net world, creating custom server controls has become some sort of a standard. In fact, it is so easy to create a server control, that developers usually do it without thinking. The problem is, that server controls are a bit more complex than an average Joe would think. There are bunch of things you need to take care of, like handling client and server-side validation, handling control when view state is disabled etc. A developer must pay attention to these things, or weird bugs can start happening.
I don’t know about you, but I still have a vivid memory of the time before internet actually became useful. In those days, learning how to solve your problem included a lot of trial and error attempts and eventually a trip to local library. If finding a book on correct topic wasn’t enough of a challenge, finding a solution usually meant reading most of 800 page bible.
The easiest way to obtain serial number of a certificate is to go to Internet options -> Content -> Certificates and double click the desired certificate. In the Details tab, there is a property list control with a row containing “Serial number” label in first column and value in second. When you click on it, the serial number is displayed in field below the properties list.
On Windows 8 and Server 2012 , selecting entire field content, pressing Ctrl + C and pasting it into Notepad or Notepad++ will display only text, without leading spaces. The problem is, the text contains special hidden characters in front and/or at the back of the pasted string. Characters are invisible to text editors, but are still there. You can see it, if you paste directly to Command prompt window.
On Windows 7 and Server 2008 and below serial number has visible “spaces” that represent those same hidden characters (as depicted in image of certificate details above) and user can select only real content of serial number field. Funny enough, if you access the field with code, there are no special characters in the value.
As it is so easy to copy hidden special characters and as this “feature” caused major problems at one of the projects I support (not to mention hours used for debugging the issue), I created a small windows application that allows you to copy major properties (so far: Issuer, Issued to, Expiration date and Serial number) from all installed personal certificates in either Local machine or Current user certificate store to your clipboard. Source code of the application can be found on GitHub.
In the olden days, when I was just starting my foray into the programming world (you know, late 80s, early 90s) we had this programming courses at our school. In this courses basic programming idea and knowledge was passed to us from old guys (you know in their 40s) with glasses and white lab coats. We also did a lot of programming, but there was a little twist. Each and every programming task had to be done on paper first.
Spell checker? Really? Really. When I look at the code, pages, error messages etc. full of spelling mistakes, my first assumption is that people behind this piece of software just don’t care about their customers and/or code. You can’t tell me you are passionate about your product, when you don’t care enough to make it readable to others. Would you hand out an essay filled with spelling mistakes in high school? I thought so. So why on earth would you tolerate poor spelling and syntax in your code?
I hope that in this day and age we all agree that project documentation is a must and not just an afterthought. No? We should be. But in case you work at one of those places where documentation is frowned upon (“Why waste time writing documentation, when you can code. Right?”), just take my word for it. Investing in project documentation will help you great deal now and in the future. You don’t believe me? Check this out. Better?
You kn0w, I am amazed by abundance of videos and tutorials out there that show you, how “easy” it is to create a mobile app. Sure, creating a “Hello world!” example with a few fields and a progress bar is not difficult, but that is hardly a representative app. In real world, you would want user to authenticate, you would want to store some user data (you know, in case he or she decides it is time to wipe the phone and then regret the decision), you would want to offer some payable services to those users and differentiate between free and pro users etc. etc. Yet, you don’t see tutorials for that. And you know why? Because those things are hard to do right.
In last few months I have been assigned as a mentor to young developer who wanted to work as a student for our company. This is my first foray in being a mentor to someone, let alone a prosperous young talent. The first thing when I was told about this, panic kicked in. But then I started thinking about the time when I was a young developer starting out. What would I want to know? What would I want to learn?
Teaching someone a specific technology is pointless. So what could I teach my apprentice that he can, hopefully, take with him for entire lifetime?
I narrowed the list down to four points. So, to you young-lings, I’ve got this advice to offer:
- Think first, code later.
- Learn how to use version control and bug tracking software.
- Listen to your elders.
- Question everything.
- Get out of your comfort zone.