Liopic on Tech – Page 6 – software engineering for evolved monkeys

Good password trick

· You shouldn’t use the same password in different places.
· You should change your password from time to time.

Despite these 2 basic rules, most people has just 2 or 3 passwords, and use them everywhere. So I’d like to share the following trick, that I heard from my former boss:

good password = your usual password + first character of the website/place’s name + last digit of the year

For example: if your usual password is “sadshoes”, and you are setting it on facebook, your new password should be “sadshoesf3” (“f” from facebook and “3” from 2013).

This will be far more stronger than just “sadshoes”, and if somebody breaks your password, he will only be able to enter in facebook. This will also force you to change your password every year.

Other stuff about passwords:
· Do not think that somebody will try “manually” to break your password; nowadays a bot will try to break your password using a long list of common words used as passwords.
· Never use pure words, or concatenated words, alone: bots also try these.
· Moreover using common text-to-digit translations, like “LOVE” to “L0V3”, is not secure: bots also try these!

10 years to master

You need 10 years to become an expert on a field. No more, no less. 10 years of continuous effort. Think about a famous musician, a famous athlete or even a professional Go player. There is at least 10 years of hard-work in almost all cases before he becomes a star.

Looking at this video by Danny MacAskill, I imagine those 10 years he spent improving his technique!

When you start with a subject, you experience different statuses, from novice to expert. But there is a key point that only an expert can do: he makes it look easy. As if you can take your bike and do same things showed in the video. Actually I could say I have 8 years of experience on Go, and perhaps 10 years on PHP, but I feel there is still a lot to learn. Despite sometimes people see that expert magic on me.

I wonder which new expert skills I’ll have in 10 years. Things that you start now doing often can become key points of your life. Things that perhaps you don’t really consider, like gardening or doing DIY. So, be sure to avoid wasting your time, and focus on practicing interesting skills. We’ll see what happens in 10 years.

Telecommuting: when good forms are forced

Currently I’m working for a company, at home. It’s a small company: my boss is located in Mexico, I’m (project leader) here in Spain, and there are 3 developers in India. We just use Skype, Google Docs and email, and we have no big problems, just the ones related to the time zones.

“When you work remotely you work less”, they say. Actually this is the usual excuse for bosses to avoid telecommuting, because they feel they can control you less. But this idea is totally wrong!

Let me explain an interesting effect. Imagine a man working in a office with fixed time (like 9am to 5pm); when he sees the clock marking 5pm he stops working and runs home (except just in case of a final deadline for a project). That is, he doesn’t really take care about finishing the job. Perhaps he has not done a lot of it, and instead he spent a couple of hours with minesweeper! Meanwhile, I don’t have a really daily schedule: but I usually do something like 9am to 6pm, with some stops. The thing is that when I see 6pm in the clock, I do NOT stop, just think “is the task (scheduled for today) done?”. Usually it’s not done, so I work a couple of hours more. Of course it depends on each person, but usually remote working make you more implicated with the job.

On the other hand, the company is forced to have a really good system to schedule tasks. Other methods to control the work that everyone is doing are welcomed as well. Things like an updated calendar for tasks, good version control system and code reviews, ways to verify the quality of software, job reports, etc. The company has to firmly use methods of control in order to survive. But this is a good thing: the work is better organized! In my case, we usually have a meeting on Friday (evening, morning) to set the tasks for each single day of the next 2 weeks, and review the tasks done during the current week.

So, the real benefits of telecommuting, from the company’s perspective: no need to rent an office (and no need to pay its bills), better organization of the work, and happier employees. Sounds good, specially nowadays with a economic crisis around. The only real problem is the communication with the team, but with video-conferences you can reach a just enough level of interaction. However, this doesn’t work for all kind of people, but you can train them (even remotely!) to work with the discipline needed to telecommute effectively.

Software metrics (PHP focused) part 2

In part 1 I spoke about lines of code and average of lines per day. Two indexes that are quite naive. Let’s see some better metrics, most of them object oriented programming focused.

Third stop: Tests and code coverage
If you have unit tests you can easily control that nothing vital is broken in each contribution. A unit test stress a class, so if there is some change in it, you can verify that the expected behavior remains the same. Moreover you can get an analysis of which lines of the code are actually executed in a test suite: that is, the code coverage of the test. You will see high values in well tested classes and low values in classes that need more tests.

Tools? Of course, PHPUnit, with the help of xdebug to get the code coverage.

Four stop: Cyclomatic complexity
Cyclomatic complexity is just the amount of different paths the execution can go throughout. For example, in our main project we have a total of 3048 paths. This value can be interesting to detect places in code that have become too complex and maybe need some cleanup.

Five stop: Pure OO software metrics
There are some interesting software metrics for object oriented code organized in packages, used basically to value which packages (groups of classes) are of better quality than others. Values that show the relation among classes, dependences, the resilience to change, etc.

Last stop: Ratios
Combining some of the previous values you can get interesting ratios. For example:
– Cyclomatic complexity per lines of code: 0.2, a very good value.
– Lines of code per method (class function): 22.02, a normal value that we have to lower.
– Method per classes: 8.25, a good value.
– Average number of extended classes: 0.4, a good value.
– etc…

Tools? The excellent pdepend is used here. Have a look at the end of its example page to see the amount of data (and funny but interesting diagrams) you can get.

Finally, all those values and tests are compiled each single time a programmer sends a commit to our code repository, and I get a mail with all the details, including the lines added, the author’s name, and all the values that change. So with a quick look I can assure that the contribution is ok, or there is some code to improve. I wonder how many companies (which develop in PHP) use something like this. I bet less than 100 in the world!

Blog