Continuous Integration with Rails, Github and TravisCI

After 25 failing builds I finally managed it! My app works just fine with continuous integration provided by Travis CI.

Here my travis config using postgresql for test environment:

Happy testing!

PostgreSQL Rails migration – how to fix DatatypeMismatch error

So recently I made my very first blog app (you can watch this awful creation here) and while uploading to Heroku was as expected stress free, migrations weren’t.

The error was

[readolog_blockquote ]

PG::DatatypeMismatch: ERROR:  column “category_id” cannot be cast automatically to type integer

HINT:  Specify a USING expression to perform the conversion.

[/readolog_blockquote]

I could imagine this would cause a problem, because initially “category_id” was named plain “category” and was a string instead of an integer.

By simply creating a new migration

I thought to have it done until I stumbled upon the error.

My first search led me to this awesome article – check it out http://makandracards.com/makandra/18691-postgresql-vs-rails-migration-how-to-change-columns-from-string-to-integer

(You basically need to follow the HINT and convert your data as following:

However, after adding a new migration… the error still occured. Until I watched carefully the error logs

As you can see, not the new migration is causing problems, but the old one! So if you encounter the same problem as I did, please check your older migrations – you just need to change this line in the old migration as well:

 

The Software Development Edge – Book Review – Part II/IV

Let’s continue where we left last time.

Modelling

It is important that you are able to explain your software to non-coders. This however involves other techniques than showing code (when abstracting a bit, showing code might be the worst way to explain software).

The other extrema – typically found in “management level” PowerPoint presentations, showing absolutely nothing useful at all. Avoid it.

Writing code

As a it project manager you should be familiar with the language your team is using. Even if you come from a different language and were a professional coder yourself, it doesn’t always mean that you will know which problems the team using that specific language will encounter.

Since beginning by reading books is quite terrible and boring idea the best way to learn a new language is to write a program that covers a lot of topics (and in turn, this topics could lead to serious problems). You need a standard program.

Standard problem

It should cover:

  • (Console) line in / output
  • Retrieve data entered by user
  • Simple algorithms
  • Long term data storage
  • Standard data structure like linked lists
  • How to deal with exceptions
  • How will the program scale, will it adapt to new requirements

A wonderful solution is provided by the animal game (I’ll cover that on an extra page).

Get out!

Each product has only one goal – to suffice the customer’s demand.

Even the smallest projects tend to grow and expand. If you omit integration process the entropy will finally win.

Convince your superiors to provide you with best people possible for the integration process. Every project needs its “king of deployment”.

Continuous integration and version control are your tools to go – someone messed something up? Just revert his/her commit. You need a build every night with all tests up and running? CI is your friend.

Avoid “we’ll write a script for this problem” at any cost. Scrips are fragile and are hard to debug. Your road to hell is paved by scripts that got out of control.

While integrating there are only few ways to do things right and a lot more to mess stuff up. Take the integration seriously, invest every possible minute in it.

Compromises

The two most important thing you’re obliged to do as project manager – keep your project within initial borders and don’t let it die a slow feature-death.

I think everyone knows the basic triangle – volume, resources, time (pick two). Marasco however adds a fourth dimension – quality (nobody will care a year later on if you delayed your project or exceeded budged, only quality will remain).

At this point a small digression – Marasco now translates this thoughts into some mathematical formulas. Although I’m not a fan of stuff like “If we assume normal distribution we can calculate the probability of our project to fail…” – please don’t do that. If you ask every team member “can we do that project?” – their answers is your best probable guess, not some distribution. However some conclusions are to be considered:

Like Brooks said – most project fail because of lack of time compared to all remaining reasons combined(!).

You can’t compensate lack of one parameter by the other (in big volumes).

You should adjust parameters equally (you can’t add a ton of quality with just one week development time)

Time estimation

As a project manager it is your duty to create an atmosphere of confidence – nobody should be punished for not being able to give a perfect time estimation. This only leads to defensive mechanisms and developers will often increase the estimation to be on the safe side which in turn is bad, because you can’t rely on this numbers.

What is the main source of all evil project problems? Basically every project manager sees the working time estimation (for the whole project) as a working document, while their superiors see the time plan as a contract. Often it arises two types of time plans – one for the outside world and one for the inner development. This is a little fraud and Marasco recommends using one honest time plan.

What are main reasons for bad planning? First of all – there are almost never known all connections between certain software parts. Just use some simple combinatorics – if there are two parts that needed to be connected, there are only 2! = 2 ways of doing that. If there are three parts we have 3! = 6 ways of combining them. Let me just tell you, that n! increases really fast… You can prevent that by using small iterations, because by forcing to release a working product at the end of an iteration you can reveal hidden dependancies.

Second main reason is that delay may sneak in unnoticed. Brooks said – a delay by a year starts with a delay by one day.

If time estimation was given honestly your usual project delay should be around square root of remaining time. Let’s say you are at time point 0 and your project is estimated by 16 weeks. This means that you will probably finish between 16 and 20 weeks from now on. If you are in week 12, meaning that 4 weeks are remaining (and everything went fine so far), project delay should be around 2 weeks, meaning total development time between 16 and 18 weeks.

If you end up being faster than square root of a given estimate – you have a typical example (and problem) of someone being too defensive. The only right thing to do is to fire those people.

So basically you have following: ideal time estimation = ITE = good.
ITE +1*sqrt(remaining time) = help required.
ITE – 1*sqrt(remaining time) = excellent.
ITE +/- 2*sqrt(remaining time) = both cases very bad

How to achieve honest and objective estimation? Note every estimation (good thing is, nowadays every task tracking software supports such features) then write down each result based on given estimation. This will help you calibrating your project and the work of each individual project member.

Remember – not the result is important but rather its predictability.

Project rhythm

Just like a lot of stuff in our lives, even software projects follow certain rhythm. Compare it to a learning curve – at the beginning development process is slow – you are planning a lot of things, organize them and do research. Then you gain speed – the main process begins. When reaching the end state you might encounter speed decrease because a lot of little problems pile up and now is the time to solve them.

I bet you can confirm it on an intuitive level – projects start heavily, then accelerate and then stick in sort of swamp. Sometimes a feeling arise that you cross the finish line barely walking.

If we translate this into iterations we can encounter that there is negative “force” at transition points. This is where you as a PM should invest your energy to get the project curve up again.

Some interesting derivative information from that research – about 60% of required knowledge you receive during the first 40% of the project, but at that point only about 25% is effectively done. It lowers the risks (because you are investing time in planing and research), but on the downside you can’t show a real progress. To discuss the importance of the “learning” with your superiors you should prepare for example a list of risks and how the learning might reduce or even completely remove such risks.

Right now, as I’m finishing the second part I realize that it just takes too long to write such a detailed summarization and, what bothers me even more is that it makes it even harder for my rare visitor to follow such an analysis. Therefore I will switch from now on to shorter, more personal articles.

Coders at Work – a book review

So here I finished this work. While being sometimes entertaining, sometimes delivering useful thoughts and sometimes being boring ass stories I found it overall… decent. Just as the last book –  by Robert Glass –  this one falls a little bit after it.

As for now I want to give you a more scientifig approach on rating book if it please you – an idea I grabbed from one of other book’s publisher. I will rate the usefullness of the ideas. How will I perform such a task? Well, clearly subjective, but nevertheless I will try to mark every interesting idea, then divide the amount of pages by the number of interesting ideas. An ideal book may reach far beyond 100% by having multiple impressive text passages… but this percentage rate appears rather imaginary. I guess some values above 20% will indicate a lecture worth your time and thus, reading.

The most appealing thoughs and ideas I will quote directly so you can make a clear picture rather to believe and agree with my view or not. Let’s start with “Coders at Work”.

Short opinion

As with Fallacies by Robert Glass this book comes a bit… outdated. Yes, one should never judge by youth and appear but only by inner values, however reading every chapter (as the author asks almost same questions) about PDP-10, DECsystem-10, IBM 1130 and so on and so forth

Calculating the worth

I started to mark worthy ideas by page number 280. Given the total amount of pages to be 525 it makes 245 pages difference. I counted 13 useful text passages. This leads to 0,0531 or about 5.3%. It may not seem to be very much, thus, leading to a bad overall rate, on the other side, in turn, I liked the thoughts that much, you could easily double the value if you find them impressive too. Since 13 is a good number and not a big one, following you can find all of the parts at once.

Job interviews – seeing the spark

Important on job interviews – it’s not nessesary a good sign if a person can solve logical puzzles. It just shows that they can solve logical puzzles. What is however more important – how attendants deal with technical problems. How do they think? How do they work with someone? Did they do their homework – are the basics on an acceptable level? Can they say “To solve this problem, I need A, B and C. This is how I would use those approaches together (explains it). Maybe I should look up about part C more, but I’m sure this leads us towards a right solution”. Until now you should get a rough idea about the interviewer as a technical specialist. And of course you should ask him or her to write down code on a peace of paper or blackboard. They should know their ABC without Googleing it every time. Additionally they should be – of course – able to work in a team.

Ask people about what they’ve done, what they’re mostly proud about. If they truly went through hell and back for a project they will be passionate about telling you such a story. Let them take the wheel, be initiative. The most important part here is not only letting them tell you what they’ve done, but although how.

If interviewers can’t tell you anything they’re interested in (it has not to be only about professional treats) they probably won’t show any performance in your project either.

Thinking

The ability to think stepwise makes us more adaptable to the outer world. And you don’t need any programming skills for that. There is a difference between – “Oh, our cabinet door won’t close. Let’s take a look – here, a screw is missing” and “Door won’t close. Let’s call someone!”.

Project leading

A good project leader should know the goal – if you are self-confident about what you’re doing it will fall easier for others to accept you and to follow you. This self-confidence widens out to the whole team, whole project which leads to a complete win-win situation for everybody. However be alarmed not to take too much care of everything as it may drive away the motivation – why put any effort in this if it’s all clear anyway – just sit back, relax the reigns in such case.

To put it short – know what you’re doing, don’t interfere, but be technically educated so you can give adequate feedback.

In chapter 14 I encountered again same thoughts. Additionally there was this one – project revisions. Each team member has had to present their part of work. And the goal was to get the part where the declarator wasn’t sure about. Sure, it sounds like an examination at the university, but the clever trick behind it – get company’s best minds to review your work. This is turbo mode help.

Interfaces

The bigger your programs are, the more you need to care about interfaces. How will this connecting link between those two program parts look like? What’s the input? What’s the output? Which part of the task should be solved by which part of the program?

Documentation

Proper documentation should be regarded as the same kind of art as programming itself. Most of the time it’s either too sparse or too filled with unnecessary details. Bringing together right amount of information and in right form takes a lot of time and invested time should be considered same as for writing code.

Good code, bad code

Thrifty definition of good code – if you need to add some functionality, you do it in just one place, while bad code leads you to changing dozens of places.

A bit about talent

In the middle aged reading and writing were regarding as special talents granted only to the chosen. In the beginning of the 20th century same could be said about art – creating films, writing books, making music was a prerogative for selected people. This is why learning about informational technology is important for everyone – like reading and writing earlier. Computers just extend our creational possibilities, enabling more and more people concentrate on what they really like to do.

Optimizing

Don’t be too clever. Sounds harsh? Do not spend weeks or months to increase some algorithm efficiency if this algorithm will only trigger once in a while in your program. You may even do worse by trying your best, since your program will become more and more difficult.