Make it pink

There is always interesting time, when new project is on the board. This time it was a mobile application and me and my coworkers were tossing ideas left and right. So a discussion got a turn to what color scheme should user interface use. Mostly out of fun (and some out of envy), I claimed: “Pink. It should be pink.”

Back then, I thought nothing of it. The statement was meant as a joke and the color was picked based on what would be most inappropriate for this project. Coworkers took it as a joke as well. As a (more and more annoying) joke I threw at them every time, the discussion turned to UI for some reason. But, as things go, the project was ready to be presented to prospective customers. Naturally and understandably, sales pushed for customer company brand color scheme for each demo. Although coworkers did a wonderful job on the project, it still took some fiddly last-minute work to sort the new color scheme and base it on a theme.

At that point, I started figuring out, that as dumb, as my “idea” was, it would be beneficial to the project, if the UI really did use pink color. Reasoning is pretty trivial. When creating a project from scratch, there is usually so much work with basic mechanics, feature implementation and testing, that UI implementation is almost an afterthought. Hence, to solve glitches as quickly as possible, we, developers, tend to use line of least possible resistance and do something stupid like specify color or font inline. I admit, I did it numerous times on other projects. I know it is wrong. Heck, I knew it back then. But I just justified it with the fact that there just wasn’t enough time.

Now, if I made one of those project pink, I am pretty sure, I would do everything in my power to not use cheap corner cutting techniques and to make darn sure that I could swap color scheme faster than you can say cookie with mouth full of, well, cookies. This applies to all other areas as well. Want to make sure that you do not have static text in your project? Use upper case text for everything. Want to write data somewhere? Store it to file on floppy instead.

Thus, the next time you are about to do something, make it pink!

 

 

API pr0n

I doubt that anyone serious about tech could avoid hearing at least a little bit about NPM “disaster” in recent weeks. Some say, it is developers ego, that caused entire ecosystem to crash down. Others blame NPM for caving in to capital instead of open source. But the problem lies elsewhere.

In recent years, a phenomena started to occur in software development cycles, that I like to call API porn. It is caused by a fact that services, such as npm, bower, nuget and such, make it as easy to add APIs to projects as it is snapping your fingers. Don’t get me wrong, I love code reuse, but this has crossed every possible edge of reason.

Let me explain why. One of most challenging and difficult things for developer to do is an API. Why? It needs to be open just enough that another developer can use it, but not in irregular way. It needs to capture every single edge case, just for the fact that a memory leak does not make you reboot your app every 15 minutes. Or, that your application does not crash, when your users are entering unicode characters. Talking from experience, this takes a lot of thinking, tweaking, debugging and testing.

In that retrospect, there are more than 500.000 APIs on NuGet alone and I am guessing NPM can beat that without a sweat. Half a million APIs.  Have developers became so much better at writing APIs or is it that we publish just about everything nowadays? As much as I would like to believe it is former, quantity wins.

Back to NPMs little problem. The package that did most “damage” was left-pad package. Let that sink in for a moment or two. Left-pad package is nothing fancy (no offense to the author). It is a simple JavaScript function that adds custom padding in front of a given string.  Yes, that is correct. We have come up so far, that people actually think, it is better to include 3rd party left padding extension than it is to write your own. Specially, when it will take about 35 minutes, inlcuding a lunch break. And this same people are now blaming developer and NPM when their projects don’t compile/deploy? Somehow reminds me of people that copy and paste first StackOverflow solution (without reading) and then complain it does not work.

This must stop. Now. I know, that package managers open entire world of possibilities, but “with great power comes great responsibility” and as it was obvious from NPM crash, most developers just cannot be trusted with it.

Quick tip: Cache busting in ASP.NET revisited

Anyone that tried to cache static files eventually got to a point where cache caused more problems than it solved. After all, telling all your users to press Ctrl + Refresh in their browsers is not exactly how one should do things on the web. Two years ago Mads Kristensen presented us with a solution in his article Cache busting in ASP.NET. The solution uses Fingerprint class, that basically updates cache object every time a static file is changed.

All fine and well. So why do I jab about it now? The solution, in my opinion has two glitches:

1. It is tightly bound with URL Rewrite IIS module.

2. It always links static content to root URL.

So, without further ado, I present you with “upgraded” solution that avoids both issues and works with relative URLs (relative to application URL anyway). In-page usage remains the same.

This code is also available as gist.

Memory leaks in .NET?

In olden times, when I did C and C++ development, memory leaks were a common thing. From time to time I still wake up from nightmares in which I debug, trace and try to locate and plug memory leaks (of course, as this is nightmare, I fail to do either, or it wouldn’t be a nightmare). Thankfully, in unmanaged code, memory leaks can be spotted in a debugger (or a plain old segmentation fault) and if you are paying attention, you can plug the leak right after you made it.

Then came Java and .NET, JIT compilers and a great thing called garbage collector. And we were told, we can forget about memory allocation, deallocation and pointers as a whole. We now have a garbage collector that will do this for us. And it does, if you know how to use it. But now, we became so reliant on garbage collector, that we just assume it will do everything for us. These days, it seems developers think that just because application is written in .NET it will somehow obtain immunity to memory leaks.

Boy do I have news for you! It won’t. Just last week, I spent most of my time debugging, tracing and removing a memory leak that caused otherwise stable windows service to throw OutOfMemory exception in 90 minutes. As .NET code is managed, tracing the leak gets tricky and the fact that code was not mine only made it worse.

If you write a one-off trivial application, memory leaks are nothing to worry about, as garbage collector will release the memory, when application is closed. And since application runs only short period of time, unless you do something completely moronic, you are fine and users might not even notice.

But, as soon as you start writing serious applications and applications that have to run 24/7 (e.g. Windows Service), things change. Any serious application has to assume, that, if object is not disposed correctly, it will accumulate in memory until the application is closed or it crashes. Preferably on Friday at 3pm when you are about to head for your well deserved vacation.

So what can you do? Personally, I stick to one simple rule that removes a risk of good portion of possible memory leaks. Any object that implements IDisposable interface has to be either encapsulated in using statement or disposed explicitly. Preferably in finally statement of try-catch block. It also helps to go the extra mile and remove reference to objects used as soon as possible and thus allow garbage collector to do its job properly.

And our memory leak? With great cooperation from our customer and some good fortune, we obtained enough information to locate the leak. It was caused by opening a Stream object about 1 million times without ever closing it.

Absolute minimum you need to know about storing passwords

In 2013 Forbes reported that approximately 30,000 sites across the globe are hacked each day. Yet, for some odd reason, in 2015, I still see web applications that employ questionable password storing mechanisms e.g. storing passwords in plain text or just hashing them with md5. With 30,000+ sites hacked a day, there is a strong chance that your site will be hacked next.

[Read the rest of this entry…]

Mobile app development: A pain in the b…

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.

[Read the rest of this entry…]

Advice to young developers

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:

  1. Think first, code later.
  2. Learn how to use version control and bug tracking software.
  3. Listen to your elders.
  4. Question everything.
  5. Get out of your comfort zone.

[Read the rest of this entry…]

Annoyed people quit

I’ve been meaning to write this post ever since I read Rands post entitled Bored people quit (and I apologise to the original author for blatantly stealing the title). As far as I agree that boredom is important factor when people decide to quit, years of observation and experience brought me to conclusion that there is one more important reason to quit. Annoyance. Pure and simple annoyance.

[Read the rest of this entry…]

Issue tracking for beginners

I first met Trac several years ago at my previous gig for a cloud project we were developing at that point. Prior to that, we used some in-house support tool developed in Lotus Notes. Prior to that, I used Notepad. And let me tell you, everything you use for issue tracking is fine, as long as you write it down. In these days, Trac seems a bit archaic. After all, there is Jira, there is FogBugz, there is Redmine, there is TFS, to name a few. But the issue here is not in what you use, the problem is how to use it. Issue tracking and project management systems are only as good as users using them. This simply means that the best tool in the world won’t help you, if your users do not know how to use it. [Read the rest of this entry…]

Crunch-time development

Remember the last time your boss roamed into your office/cubicle and asked you to add this one tiny feature to your project in a week? You were tempted to say it is not possible to do it in the time frame, but then you took into account that it looks and sounds as a small feature and it will probably take you only half the time to do it anyway. Also, it is difficult to say “No” to your boss, right? So you said: “Sure boss, I can handle it.”

In the end, what could possibly go wrong?

[Read the rest of this entry…]