Function names as signaling

In most web applications there’s a host of functions (or methods if speaking in the object-oriented world). It’s widely recognized, that it’s probably a good idea to name them something, which may suggest the purpose or functionality of what the function is doing, but often developers seem to fail at making a stringent naming convention. Before starting on your next big development adventure, here are a three suggested rules for naming functions.

1. It’s more important to have a suggestive name, than a short one.

Never call a function something short but meaningless. Instead use CamelCase and make a sentence suggesting what the function does.

  • Bad examples found in live code: “process”, “fixit”, “cleanup”.
  • Good examples: “saveToDatabase”, “convertIpnumberToDomainName”, “calculateTotalPricing”.

2. Use prefixes on functions

Reserve common names (more if you like) for specific type of functions. Here are a few suggested rules:

  • “get”-functions should always retrieve and return data – never print data.
  • “print”-functions shoudl always print data to “standard out”.
  • “set”-functions should ways set data to an object (and choose if “set” also saves data or not).
  • “save”-functions (if set-functions doesn’t save properties) saves all current properties to the persistent storage (usually database).

3. Reuse data model objects in function names

If you’re data model (or object model) already contains names of entities, reuse these in function names. If a table is named “Travel”, call the function “saveTravelRecord”, Not just “saveDataRecord”.
Make consistent use of the same names, field names, properties and other entities found in the application. Using the same name for the same object all across the application, may seem obvious, but somehow developers seem to find slightly different names for the same object again and again.

While the three above tips may seem simple, do check your code and see how many places they are broken. I’ve seen countless times, and getting it right from the beginning would have cost a small effort, refactoring the code years later is a much bigger effort.

Ubuntu: Changing your IP number

Sure it doesn’t happen that often, but sometimes you might need to change the IP number of your machine running Ubuntu. Either to configure it with a static IP number on your LAN or temporarily to configure a Wifi router – the latter being my case.

The first shot at changing the ip number, was going to the “System” menu, choosing Administration and Network Tools. It sounded just about right – but it’s wrong. Sure you view settings and some statistics, but it’s all read only.

ubuntu-network-connectionsSo, if you want to change the IP number, go to your top panel (in the right side, you’ll find you network icon. Right click on the icon and choose “Edit Connections”. In the window opening, you’ll have access to changing the ip number – to manual configuration, DHCP with ip number only or (as is default) full DHCP configuration.

Choosing “Automatic (DHCP) addresses only” allows you to get an automatic IP, but use openDNS’ DNS-servers – should you prefer them over the DNS servers provided by your ISP.

Your mileage may vary

It’s always fun to read articles with tips and tricks by other developers and see how they figure “best practices” are handled. Most developers do seem to thing they observations and practices are easily adopted by anyone, and should be accepted without any argumentation or reasoning behind the advice.

One of the nice examples of this, was a story called “5 tips and tools to develop php applications fast”, and while it may apply to the web applications developed by the author, it’s one of those where I question who is supposed to be the audience. All 5 tips are often found in many textbooks and other stories on the net, and in my experience they are all wrong (more or less naturally).

1) Use a MVC framework – it’s an industry accepted standard.
MVC as an idea may be accepted, but there are many ways of implementing the MVC – even with the various PHP frameworks. If you know the MVC pattern it may be an idea to look at the frameworks supporting it, but don’t get carried away.

  • If all your old code is non-MVC code and you don’t have any plans to MVC-refactor it, it may cause you maintenance overhead to try a completely different style  on a single project/web application.
  • If you aren’t used to using a (MVC) framework you need to invest time in learning it.

Do keep an eye on the overhead caused by the framework. If you web application has a heavy load and the framework causes 5-10% overhead, it may a bad idea.

2) Ajax Frameworks
Great idea.. but to utilize the power of an ajax framework, you need to learn how to use it. Also Ajax isn’t the holy grail of the internet. Sometimes it’s cleaver to use it, other times it isn’t. By using plain old HTML and reloading the page from time to time, it may be easier to debug the application.

Do also notice, that writing great/professional quality Javascript often requires just as great skills as writing professional PHP.

3) IDEs
An IDE – Integrated Development Environment – can be a great idea if you know your way around it, and use it regularly. An IDE is – like any other tool – something you need to invest time and resources into, if you want something back – and especially if we’re talking a beast like Eclipse-based tools.

4) Database creation/management software
Let me skip comments on database creating management tools. I’ve never really used them and don’t know if they’re a pain or a benefit. I have often seen though, that too easy access to the database, leads to sloppy database design (or at least something, that isn’t thought through).

So far it’s been my experience, that people who knows the command-line clients to databases, often has invested much more time in thinking their data models through and often spend a little more time considering the table layout, the field definitions, indexes and other important aspects, than those who use a nice graphical interface.

5) Object Relational Mapping
Object-Oriented programming isn’t a holy grail, and most people doing OO programming (in my experience) doesn’t genuinely do object-oriented programming – instead they use the OO-facilities in the language to slap functions together in a class.

There’s nothing wrong with procedural programming as such, and trying to force object-orientation into your code – and even abstracting it away through Object-relational mapping, has often lead to slow performance and odd database designs. If you know what you’re doing great, but there’s no free lunch, and trying to utilze ORM without having a pretty solid grip on what’s happening and why, rarely does anything good to your productivity.

I’m quite sure for some developers, using some sort of object-relational mapping might be a gain in programmer productivity, but do keep in mind, that if you’re developing a site with massive traffic, the programmer gains may easily be crushed in added server resource requirements – spending a few minutes extra optimizing and tuning applications, may in some cases save hours and hours of cpu cycles once the solution is deployed.

Getting back to the article, I’m sure the advise is well-meant and thought through by the author, but do always – as with all advise – think it through and see how may apply to your adoptation. In may daily development some of it is quite terrible (as I often work on a site with thousands if not millions of pageviews every week).

I’m wondering what my 5 tips would be for developing PHP applications fast would be. Check back in a few days, and there may be an answer – which may or may not – apply to you.

Database optimization thoughts

If you’re working on heavy duty websites, knowing your database and how to use it best can make a world of difference in terms of performance, and thus you should always optimize the database. That’s pretty much obvious.

The tricky part is how you do the optimization? Often it requires a lot of reading up on how the database works – strengths, weaknesses and other details — and loads of experience. Having a DBA available to help you optimize would be ideal in some cases, but often you need to do it yourself.

So, is there a “free lunch” recipe with guidelines to help you do the correct optimization? Well, no. All database optimizations are usually case-specific, and the optimizations which worked last time may not be applicable in the current case.

There are however some generic rules, which may help you go in the right direction.

  • Database optimization should start early. Think about performance when designing you database scheme – table layout and column types.
  • Consider the transaction types during the data life cycles. Are you primarily doing reads or writes? How many columns is expected?
  • Learn to use indexes – wisely. Too many indexes is just as bad as no indexes.
  • Try to benchmark various table and column layouts and see how they perform – sometimes you might be surprised and other times just confirm theories.