Thursday, July 28, 2016

My dev curses

From my posts so far you can already see some of my developer curses. The first curse is I want to have a control over my software experience, which either means the program has to be highly customizable, or if the task is somehow simple, I want to create the program myself.

Sometimes I'm only curious, how hard can it be, but even I usually learn a lot during the process, it also cost a lot of time. Also I'm that kind of guy who if wants a bread, he doesn't go to bakery, but opts for wheat seeds and learns how to mill.

Obviously I don't have much spare time, because if I'm not experimenting, I'm working, only because I persuaded somebody to use some of my unfinished creations (which looked quite finished to me before the pitch).

The second curse is I'm a “forker”. I like to start new projects, but I don't have the endurance to deal with the hard stuff afterwards. As a result, most of them remain unfinished, also because I often treat them more like an academic endeavour and I prefer to have everything thoroughly thought thru, than glue it somehow together.

I like starting new projects also because in the beginning everything is small and simple and I like that. After a year of development the source code is huge and bloated, with technical debt here and there, so it gets messy and I start to lose motivation to work on such project any longer because of it.

When dealing with difficult problems, that requires a lot of time and effort, I have a tendency to procrastinate. Other times I figure out a better way how to do it during the development, so my motivation shifts to reengineering and hey – new project! Tada!

When I did a roadmap for Quiky, it was quite nice, but it wasn't effective enough. I created the WPF version, which I still heavily use, but my needs exceeded what was easily achievable and now I'm in the unfinished state once again, currently because I'm having hard time syncing changes between the app, a server and a mobile version.

The third curse is I'm a performance freak, I want my code as much microoptimized as possible. Last year's ECMAScript 2015 (ES6) added great new features, but in most cases it's just a syntactic sugar, that in general is slower, than older constructs (as performance tests are showing).

Array.forEach is slower, than plain for loop; array.push(x) is slower, than array[array.length-1] = x; promises looks slower, than callbacks; classes and modules have bigger overhead than plain functions.

I also order clauses in IF statement, so the fastest one is evaluated first, and I prefer OR over AND, because while in AND all clauses are evaluated, if one OR clause evaluates to false, it skips the rest, saving some CPU ticks.

This goes hand in hand with my dislike of various third party frameworks, which in fact may be my fourth curse.

Wednesday, July 13, 2016

Registration process

If you want to personalize user experience and store user's preferences, you need to uniquely identify the user. This is obviously done by user accounts, for which you need a registration, also called “sign-up”, process.

You should want to require as few things from the user as possible. That's why many services use e-mail address instead of username.

The most streamlined process I encountered so far was: enter your e-mail address and you're immediately logged in as an user. If you want to log in later, click on a link/button in the confirmation e-mail first. Then you'll be prompted to enter your password and maybe even an username.

You may require the user to confirm his e-mail address before he can start creating content. Until then there's only a sandbox or samples for him to play with.