Can’t upload images?

Have you tried to upload images to your newly installed WordPress site and it didn’t work?

Here is how I solved it! It turned out to be really simple…

I simply added a uploads directory in the wp-content directory, i.e. \wordpress\wp-content\uploads.

If this didn’t help you can try to change mode to 777 on the new uploads directory.

Posted in Software | Tagged | Kommentarer inaktiverade för Can’t upload images?

A programmers dricking song

Music notes

If you are having a party with your geek friends then the following little song by Jack Gannsle might be something for you…

100 little bugs in the code,
100 bugs in the code,
Fix one bug, compile it again,
101 little bugs in the code.
101 little bugs in the code…..
(Repeat until BUGS = 0)

Posted in Software | Tagged , | Kommentarer inaktiverade för A programmers dricking song

An introduction to how to write a commit message

Have you ever looked at a change log in your source control system, such as git, and said to your self…

”WTF is this? What does it do and why?”

This post will outline how to write a good commit message in git.

First of all, we need to understand why we write a commit message at all.

What is the purpose of a commit message?

Having a change log that consists of well written messages makes it easier to understand what is happening and enables you to understand why.

As summarized by the people working with Erlang/OTP, a good commit messages serve at least three important purposes:

  • To speed up the reviewing process.
  • To help us write a good release note.
  • To help the future maintainers of the code to find out why a particular change was made to the code or why a specific feature was added.

Who-T lists three questions that a good commit message should answer :

  • Why is it necessary?
  • How does it address the issue?
  • What effects does the patch have?

Before you commit your changes

There are a number of things that you should do before committing any changes to your git repository.

Logical change sets

Make sure that what you are about to commit is logically connected. If you have been working on several different issues during a time period then you should make sure to not group all changes into one big commit. Instead, separate changes for each issue into separate commits. This will make it easier for others to understand what is happening and it also makes it possible to revert a commit at a later stage should it be needed.

Remove white spaces

It is also recommended that you don’t commit any white space errors, e.g. trailing white spaces at the end of the line which are not needed. Git provides an simple way to prevent this. Simply, before you commit, run git diff –check. This command will identify potential white space errors.

Commit only what is needed

You should only commit files and code that is needed.

If you don’t need a file then don’t commit it.

If you don’t use a certain piece of code then don’t commit it. I.e. don’t commit dead code or commented out code.

Readable code

Before committing you should make sure that your code is readable, i.e. well formatted. If you have some code guidelines that you should follow then make sure that you do.

This will make it easier for others (and your self in the future) to review and understand the changes.

Test and verify the changes

Make sure that you have tests for the bug you are fixing and/or the new features your are adding.

Do I need to say that you make sure that your entire test suite passes? Just so you haven’t messed up anything else.

Once you got all of this under control then it is time commit your changes and write your commit message. So let’s continue with just that…

Structuring a commit message

The most important part is to understand that the commit message is mainly for the other people, so they should be able to understand it now and six months later. With this in mind let’s continue.

A well structured commit message has at least two parts.

  • a single short line in less than 50 character line which summarizes the change
  • a more thorough description to why you’ve done it or what problem it solves

In between these two parts you should have a blank line.

The first line

Some few tips of the first line…

  • Must only be one sentence.
  • Use the imperative present tense in these messages. In other words, use commands. E.g. use ”change”, not ”changed” or ”changes”.
  • Terminate the first line with two newlines to get the blank line.
  • Start with a capital letter unless it starts with a lower-case symbol or identifier.
  • Don’t use a trailing period either.
  • Try to limit you message to 50 characters but don’t exceed 72 characters.
  • Prefix the first line with a tag if it makes it easier to know to which part of the module the commit applies.

The main description

Some tips for the more thorough description

  • Make sure the commit message is meaningful.
  • Include a motivation for the change and contrast its implementation with previous behaviour.
  • Use normal prose, normal punctuation and capital letters where appropriate.
  • Can be empty if the change is self-explanatory. E.g. ”Add DOAP file”.
  • Just as the first line, use the imperative, present tense.
  • When committing code on behalf of others use the –author option, e.g. git commit -a –author ”Joe Coder <joe@coder.org>”.
  • Add a ”Signed-off-by: Your Name ” line to the commit message (or just use the option ”-s” when committing) to confirm that you agree to the Developer’s Certificate of Origin

A commit message template

Tim Pope has created the following template:

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Further paragraphs come after blank lines.

– Bullet points are okay, too

– Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here

– Use a hanging indent

 

 

Posted in Software | Tagged | 1 Comment

Unit testing your WordPress themes and plugins

The Beginner’s Guide to Unit TestingWP tuts has created an interesting three part tutorial on how to use test driven development when writing themes and plugins for WordPress.

The first part introduces the concept of unit testing and it explains what is needed to be able to write unit tests for WordPress. The second part continues by introducing how to write a testable plugin and the third part looks at how to write a testable theme.

What to do you think? Is this something that you are using when writing you plugins and/or themes? Are you using another way of testing your code? Maybe you think this is over doing it?

Let us know! Leave a comment!

Posted in Software | Tagged , , , | Kommentarer inaktiverade för Unit testing your WordPress themes and plugins

10 tips for managing project risk

Do you need some tips on how to avoid your project to fail?

If so, here are 10 great tips that you can use to avoid failure of your project.

  1. All projects has risks associated with them. As a project manager you need to be aware of them and pro-actively make sure that they are removed before they occur.
  2. Risk management requires continuous effort to identify, quantify and eliminate the risks.
  3. Perform risk analysis with the entire team and possibly others that have experience with similar projects.
  4. Collect all possible threats and risks that can effect the outcome of the project. Try to be very specific when writing them down. Make sure to include risks that are related to the context in which the project is executed in, such as stakeholders, funding etc.
  5. Estimate the likelihood that risk/threat occurs
  6. Estimate the consequences of the risk/threat occuring.
  7. Try to answer the following questions…
    • What causes the risk?
    • Which warnings signs do we have?
    • How much time do we have before the damage is done?
    • How can we reduce or eliminate the risks?
    • Can we take any pre-emptive actions?
    • What should we do today?
  8. Create an action plan for those risks that are deemed in need of such.
  9. Present the result of your risk analysis to your customers and stakeholders.
  10. Make sure to continuously make new risk assessments though out the project.

What do you think? Does these tips add value to you? Do you have any other tips on how to manage risk? Let us know and leave a comment!

Posted in Management | Tagged , | Kommentarer inaktiverade för 10 tips for managing project risk

13 tips for setting project goals

Project goals
In a recent post I high lighted 18 ways to successfully get started with your project.

Once you get going it is important that you know where you are going, so here are 13 tips for setting project goals.

  1. The sooner you have gained approval for the goals for the project, the greater the likelihood is for the project to reach its goals.
  2. Remember that goals are future desired results and not tasks to be performed.
  3. The project goals are the foundation for how tasks are perceived, planned and evaluated within the boundary of the project.
  4. The best goals are created when the entire team is involved in creating them, at the same time it increases the understanding for the project within the team.
  5. Keep in mind that formulating relevant and clear goals takes time.
  6. Express the expectations on the project in clear impact goals and make sure to get a agreement from the customer.
  7. Formulate the project goals as one main goal and several sub-goals.
  8. Make sure to define create clear project boundaries to identify what is not expected from the project.
  9. To ensure that you have not missed anything essential group the requirements according to their importance, e.g you could use the MoSCoW method.
  10. Discuss with the customer and document how to prioritize between resources, performance and time.
  11. Define how success will be measured.
  12. Keep in mind that the impact goal(s) are the most important goal(s) to achieve and as a result other goals may change during the project.
  13. Only tasks that contribute to fulfilling one or more project goals should be performed within the framework of the project.
Posted in Management | Tagged | Kommentarer inaktiverade för 13 tips for setting project goals

Prioritizing requirements with the MoSCoW method

MoscowHave you ever needed a way to prioritize your requirements?

One way of prioritizing your requirements could be to use the MoSCoW method, which is a simple method to apply.

Let’s have a look at the method…

As you can see, MoSCoW is spelt with a mix of lower and upper case letters. Now, this is not done so by mistake. They all have a meaning.

The M stands for MUST and indicates a requirement that must be achieved to be considered a success.

The S stands for SHOULD and indicates a high-priority requirement that should be achieved if it is possible. These requirements are considered as important requirements but not as important as the must requirements.

The C stands for COULD and indicates a requirement which is considered desirable but not necessary.

The W can stand for two things. Sometimes stands for WON’T and sometimes it stands for WOULD (or even WOULD LIKE). When it means won’t then it indicates requirement that the requirement has been agreed with the stakeholders to not be implemented in a given release, but may be considered for the future. When it means would that it indicates that the requirement is a nice to have feature that might be included in the delivery based upon if there is time or not to include it. Regardless of which, these requirements has the lowest level of priority.

Finaly, the lower case o‘s. The lower case indicates that they don’t stand for anything and they are simply added to create a pronounceable word.

So what you think? Are you using the MoSCoW method? Maybe you are using a different method? Leave a comment and let us know!

Posted in Management | Tagged , | Kommentarer inaktiverade för Prioritizing requirements with the MoSCoW method

18 tips to successfully start a project

Project start up checklist

  1. Make sure that you give your self the time to do it right from the beginning.
  2. Starting up a new project requires both resources and time, it can take from a day to several months, so make sure to use them wisely.
  3. It is at the beginning of the project that you have the greatest opportunity to effect the project.
  4. Make sure to inform the team working on the project about the projects background, the expected effects from the project. Also inform the team about any prerequisites of the project that may exist and past experiences from running similar projects in the past.
  5. Create a clear goal together with the team.
  6. Identify the stakeholders of the project, their expectations and how they can influence the projects execution and out come.
  7. Create needed structures for the project that shows the complete picture of the project which in a foreseeable way communicates the project.
  8. Secure that the required competences exists within the team and that they have allocated time to the project. Also secure that you have access to supporting resource if you need them.
  9. Organize the project with regards to the current project, not some old project or just because you have always do it in a certain way, to achieve the best possible result.
  10. Create a time plan for the project which contains milestones and/or checkpoints that help you assess the progress.
  11. Identify any critical tasks that has to be started directly and get a confirmation from the customer that it is so.
  12. Secure the required resources by creating a deal with those responsible for the resources.
  13. Make a budget for projects, this includes both costs and incomes that are generated by the project.
  14. Analyse the risks and create a pre-emptive plan to avoid them.
  15. Consider how collaboration and communication will be performed within the project and create a meeting schedule (plan) for the near future.
  16. Set routines for following up, documentation and reporting.
  17. Make sure that the ambition level of the project is in line with the expectations of the customer and available resources. Anchor the out come from the project start up with your own organization and other partners that you might have.
  18. Finally, make sure that you believe that the project will be a success.
Posted in Management | Tagged | 1 Comment

The 3 Steps to Finding Win-Win Solutions

As mentioned earlier finding win-win solutions in business, as well as in your private life, is a key to making good decisions.

The people over at enlightr.com listed three steps to finding win-win solutions that are worth having in mind when looking for win-win solutions.

The steps are..

  1. Take your negative emotions out of the equation.
  2. Focus on the solution.
  3. Explore the context and options.

What do you think? Are these steps taking you to a win-win solution? Let us know and leave a comment!

Posted in Business | Kommentarer inaktiverade för The 3 Steps to Finding Win-Win Solutions

Be gentle with the earth, think green and be friendly to your environment

Always try to minimize your negative impact on nature. Try to consider if you really need to have the latest thing on the market. If you really do need a new, can the old can be reused somehow?

Use the technology and innovations at hand with this in mind. As an example, if possible use online video conferencing tools instead of travelling long distances with air planes.

Posted in Business | 1 Comment