All about imports

Have you ever used packagist? What about PyPi? If you are like most developers, well at least the sane ones, the answer is a resounding yes!

What however may not be as unified in response is how to actually arrange the imports.

Thankfully a best practise exists. Here we go.

Top level

First things first, here you should import any standard library import. That is packages that ship with your language of choice.

from math import sqrt
from os.path import abspath

Mid level

Right below you should import any third party libraries you use. This include any libraries that ship with your framework.

use App\Http\Controllers\Controller;

Lowest level

This is where you put in any code that you are reusing from within the app.

import payroll.Employee;

That is as a general heuristic import first items nearer to the core language.

How do you import in your own application? Talk to us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Yes you should version your database

There is one major process that your team is likely ignoring that holds a large stake in your application, can you guess what it is?

Did I hear someone say Database migration woop woop top of the class!

More often than not, we properly version code but deploy the database as one big sql dump. Practically all teams I have interacted with during deployment present a .sql file with instructions that Mysqldump or a similar tool should be put to employ.

The biggest disadvantage to this method is that the database and the application don’t remain in sync for the various versions available. At first glance this may not seem like that much of an issue since most of the time we are only concerned about the final version of the db. However when you think about it you realize that if the version of db you have is only the latest, then earlier versions of the code are practically unusable since they work with the implicit assumption of how the schema of the database is structured.

Application <-> Database mismatch maybe your biggest problem but other problems quickly become apparent when you deploy and need to scale your app. Since the entire db is just one big dump, you can not easily automate the task of scaling it over the cloud.

Well now that we have talked of the evils of the dump, what can we do?

The easiest option is to store diffs of the database. Here I don’t mean in the sense that git does but rather storing ALTER scripts in an orderly incremental manner in a folder called migrations. Sample contents would be:

  • 001_Users.sql
  • 002_Products.sql

And when say we alter the users table then:

  • 001_Users.sql
  • 002_Products.sql
  • 003_Altered_users.sql

etc

We then commit the files to our code repository of choice.

This ensures that at whatever point you checkout your code, you can also be able to generate the necessary schema.

Other considerations

For those who work with frameworks, your framework probably ships with a schema builder in one form or another. For those cases you may wish to version the schema files rather that the sql file.

For those of us who prefer the db to be framework agnostic, the following tools can be a great help to help you run your diffs

How do you manage database migrations within your own team? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Ignore them at your own peril

A big problem exists in the tech industry. Specifically that it seems that software development is considered analogous to coding. This misconception is very dangerous and may very well be the reason your next project fails!

Lets start by looking at what the definition of coding is:

    Coding is the mechanical translation of preexisting design into a computer language.

By that definition we can already tell there is more to software development that just coding, so what is this more. Steve McConnell to the rescue! In his epic book Code Complete aptly nicknamed The Bible by software designers, Steve lists other processes that relate to the building of software, below is the listing;

  • Problem definition
  • Requirements development
  • Construction planning
  • Software architecture
  • Detailed design
  • Coding and debugging
  • Unit testing
  • Integration testing
  • Corrective maintenance

As you may have noted, coding is way down the list!

Going through all this steps might seem like a lot of bureaucracy and that doesn’t play quite well with us techies who most got into technology to avoid it. Still you should consider the steps for all non trivial projects.

The reasons are many but below are samples:

Scheduling

Scheduling is a pain to even the most experienced practitioners in the field. In a previous blog post Simple Software Estimation we talk about how to estimate the time it will take to write software. However the client/market cares about how long the entire process of software development takes. By having a more holistic view of the processes. You will be able to give better estimates.

Usability

Users of your application care only if the product meets their needs, by giving proper credence to earlier stages of the development process, you are more likely to build a product that the market actually wants not what you think they want.

Resource management

Administrators in the project can get a better view of the entire project and see what resources they will need when they will need them and level which they will need them. This helps avoid last minute rushes hunting for talent.

Code quality

The single most effective way to boost the quality of your code is to work on the design. The benefits of front up design are many, I will likely cover it in another post but suffice it to say planning architecture of your code helps you avoid writing Spaghetti code

Emphasize all tasks

If you don’t make a conscious effort to consider the other phases, you are likely to simply ignore it and jump straight to coding! Properly considering all aspects ensure that they all get their spot on the table.

What is the software development process in your own organization? Talk to us in the comment section below

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Wicked Problems

There are many types of problems in software and we developers love to solve them all. However there exists a class of nefarious problems that all teams must go through and they are no fun at all, welcome to the world of Wicked Problem

A Wicked Problem is defined as a problem that could be clearly defined only by solving it or part of it.

For most problems we first understand the problem then find ways to tract it, Wicked Problems offer no such luxury.

Essentially the only way to solve such a problem is iteratively by first coming up with a tentative solution which helps you define the problem then solve it again to come up with a solution that works.

To know wether you are smack right in the middle of a problem Conklin in his book Dialogue Mapping: Building Shared Understanding of Wicked Problems shares what characterizes a wicked problem:

  1. The problem is not understood until after the formulation of a solution.
  2. Wicked problems have no stopping rule.
  3. Solutions to wicked problems are not right or wrong.
  4. Every wicked problem is essentially novel and unique.
  5. Every solution to a wicked problem is a ‘one shot operation.’
  6. Wicked problems have no given alternative solutions.

In the world of software design, non trivial projects are inherently wicked. This follows from the following facts:

  • Requirements are almost certainly guaranteed to change
  • Different designers can come up with different designs all of which are correct
  • The design process is full of false starts
  • There is no way on the onset to know if your chosen design is good enough
  • A good design is usually subtly different from a bad one.

While I would wish to conclude this article with nice algorithmic solution to this class of problems, the best advice I can give is when you come across such a problem, iterate and iterate first. It’s far cheaper to correct design mistakes at design stage than when you have a full blown coded project.

Have you dealt with a wicked problem before? How did you handle it?

Facebooktwittergoogle_plusredditpinterestlinkedinmail

JUMP STARTING YOUR PHP MOJO

Guest Post by Nelson Ameyo

 

Hello guys. My name is Nelson and I love hacking new stuff with PHP. I have been developing PHP applications for about 4 years now. In that duration, I have learnt a lot , made some rather expensive mistakes, but most important of all, I have experienced personal growth. Back from writing poorly designed school projects for a few bucks to building scalable modular enterprise apps for the corporate scene.

One important lesson every novice developer learns is choosing your strategy wisely. For the next few paragraphs, I will be ranting passionately about my life with PHP. Take this as a chance to explore different development paradigms and tricks that will make you a guru fast.

Choosing your strategy
Sawa. If you made it to this section, it means you really want to do your thing in PHP. It is only fair for me to give you a quick guide to picking a sane strategy. You do not want to go to a fist fight with a cannon. Neither would you want to enter a gunfight with a stick. When you want to roll out a PHP application, there are 3 major avenues to take.

  • The procedural (line by line) way
    This is where you will write a dbconnect.php and always require it in every PHP data-enabled script you write. This approach is good for minimal tasks e.g. whipping up a simple school project or showing ur spouse how cool you are. NEVER ever roll out a ‘serious’ project this way. There are no well defined code reuse patterns for procedural programming. (I know what you are thinking. And no. Functions just wont cut it. Too many of them are messy). It is like that old t-shirt you sleep in everyday. Never wear it to work. One more gotcha with this method is it is easily accessible with very old APIs. By old I mean really old. Old APIs don’t mix well with good  performance or security.
  • Roll your own (RYO) kit
    About 3 years back, I was at this level. I had just made my first 3 sock from doing a dbconnect.php file for some undergrads at campo. And it took me several days to roll it out. My fire for quick money was burning. Surely there was an easier way to make like two 3 socks in a day. So I export the login table to a .sql file to make sure I never have to design that ugly table again. I also throw together a few functions to connect to the DB and login a preset user. I had successfully optimized my production rate with functions, so I set a target of 2 ‘clients’ a day. But business was hard back in the day. I managed 1 ‘client’ a day and was able to reduce my wages to one chwani (150) since I was ‘mass-producing’. As more jobos came my way, I decided to offload some functions to class methods. This move made my work very easy. I could roll out user authentication in a day or so. However, I lost a majority of my ‘clients’ who could not explain the OOP concepts I had used on their projects to the tutor. They lost marks and I lost revenue. Business collapsed and I was back to eating at the cheap madondo dunga-points around campus. That was my intro to OOP concepts.
  • The OOP / framework (object oriented programming) way
    OOP is the best thing ever since the invention of sliced bread in 1928. It is just  a bunch of amazing runtime juiciness rolled into a twenty-something MB package (linux users know this). I guess the size is bigger on Next Next Finish (Windows platform). Object oriented programming now got me from the 1 chwani developer to a ninja in a little over 8 months. This is where life got exciting. I actually got to code right, code in large teams, build apps I mostly dreamt about and sweet of all, I made good money doing it. Object oriented programming introduces several principles which are really key to entering guru paradise. These are classes, objects, polymorphism, constructors, destructors, inheritance, accessors etc. etc. I urge you not to pay attention to the fancy words. They are really simple once you get to get their vibe. Here is where I will get into frameworks. Wikipedia defines a software framework as follows:-

A software framework is a universal, reusable software environment that provides particular functionality as part of a larger platform to ease development of software apps, products and solutions.

This said, I am a very lazy coder. I TOTALLY love PHP frameworks since have been designed by other lazy coders So instead of rolling your own (RYO) framework, you can pick one of the many  listed in this Mashable post.
I am an ambassador of CodeIgniter specifically because they pay attention to 2 things I value most in tech; performance and flexibility on a very memory and small memory footprint.
If you feel adventurous, you can download CodeIgniter and give it a test-run. It is very easy to learn. I personally got it in a little over 2 weeks back when it was in version 2.0 back in 2010. I have been using it ever since (now @ version 3).

OOP over functions
I have been hearing a lot of murmurs why functions are ‘awesomer’ than objects. Well, here is my very scienific take on it that will be sensible to all of you. Functions were invented to fix the issue of code reusability back in the 90s. I actually think Rasmus Ledorf was thinking functions when he wrote the PHP language. We are no longer in the 90s. We now have faster processors and better computing hardware. Requiring functions file everyday is a lil bit stressful for a daily coder. We now have cool OOP features that functions can’t just match. This doesn’t mean they are not relevant. They are very much in use today. Except they are now being used as class methods so that they can get a piece of OOP goodness just the way they are. This thread on StackOverflow is awesome at capturing this

Recap
PHP is the most popular language on the Internet
Never roll your own framework on ‘serious’ projects
Favour a framework for accelerated developemnt times

Facebooktwittergoogle_plusredditpinterestlinkedinmail