Undo-ing ‘git reset hard’

February 4th, 2013

Chances are, you’re here because like me, you ran git reset --hard HEAD on your last hour or two’s worth of work. If you’re lucky then hopefully you ran git add . or added your files to the staging area. Providing a git clean (git gc) hasn’t been run, there may be light at the end of the tunnel!

$> git add .

Lots of lovely work added to your commit – then you decide, for whatever reason, to not commit. In my case probably down to lack of coffee or that I suddenly decided to slip back to the SVN way of things ; ).

$> git pull origin master

From this pull I got merge problems (obviously due to the lack of a commit). Then cleverly I decided to run:

$> git reset --hard HEAD

Oops! Panic - I’ve just reset my last two hours’ worth of development!

 

A quick search revealed this stackoverflow post and then a look in the git fsck man page shows that we’re going to need:-

--cache
Consider any object recorded in the index also as a head node
for an unreachability trace.

 

--no-reflogs
Do not consider commits that are referenced only by an entry in a
reflog to be reachable. This option is meant only to search for
commits that used to be in a ref, but now aren’t, but are
still in that corresponding reflog.

 

--lost-found
Write dangling objects into .git/lost-found/commit/ or
.git/lost-found/other/, depending on type. If the object
is a blob, the contents are written into the file, rather
than its object name.

$> git fsck –cache –no-reflogs –lost-found

Checking object directories: 100% (256/256), done.
Checking objects: 100% (571/571), done.
dangling tree 9f43ffdc200878fefaab63b7c15c58f1da73ba5d
dangling blob 837052b45a69934c822e832d5d01f81bb7cde437
dangling blob b1d0f0ceb214ba28f16826103d2a85ed6f90838b
dangling blob da70731ebc23a477994cf65dd51f951b5546cedd
dangling blob 09312824523012ba5ea0aab54093eb8df567ffc4
dangling tree 25f11f2af6addf4e6c4004481b34f5017cbc052e
dangling blob cc3a137f831e26e091265cdce3c6f7d224cf8961

 

$> ls -l .git/lost-found/other/
-rw-r--r-- 1 alex alex 2230 Feb 4 13:44 09312824523012ba5ea0aab54093eb8df567ffc4
-rw-r--r-- 1 alex alex 41 Feb 4 13:44 25f11f2af6addf4e6c4004481b34f5017cbc052e
-rw-r--r-- 1 alex alex 1714 Feb 4 13:44 837052b45a69934c822e832d5d01f81bb7cde437
-rw-r--r-- 1 alex alex 41 Feb 4 13:44 9f43ffdc200878fefaab63b7c15c58f1da73ba5d
-rw-r--r-- 1 alex alex 17281 Feb 4 13:44 b1d0f0ceb214ba28f16826103d2a85ed6f90838b
-rw-r--r-- 1 alex alex 20586 Feb 4 13:44 cc3a137f831e26e091265cdce3c6f7d224cf8961
-rw-r--r-- 1 alex alex 20855 Feb 4 13:44 da70731ebc23a477994cf65dd51f951b5546cedd

 

Now you should have reasonable success in identifying which file is which and you can diff them to check that these are indeed your changes.

Good luck! And don’t do it again.

Tips for creating a website development specification

August 16th, 2012

For anyone who’s worked in the website, software or application development industry for more than five minutes, I don’t need to explain the need for a really good specification.  It ensures that all parties – both developers and clients – are fully aware of what will be delivered, and it gives you something to refer back to when additional functionality is requested, to prevent scope creep within the project.

We’ve all seen projects where the slow but inevitable process of adding features to satisfy each new idea or new stakeholder causes the whole thing to flounder in a mass of mismatched expectations – developers work harder only to result in lower client satisfaction. No-one wins.

Essentially, good planning, and the ability to write a solid, specific and clear specification is often the key difference between a successful development project and an unsuccessful one. But good specifications are tough to write, so how do you get one that works?

  1. Keep costs fluid until the spec is complete.
    All costs are estimates until the specification is finalised. They have to be. The very process of writing the spec finalises the development requirements, and until those requirements are finalised, the cost cannot be fixed.  A builder won’t issue a quote until he’s seen the architect’s drawings, you can’t issue a final quote until you have your spec.
  2. Understand what kind of specification you’re trying to write.
    Typically in development projects there are two types of specification – functional and technical.  And there are two different types for a reason – they fulfil two separate roles, so understanding which one you’re producing and keeping them separate is critical. A functional spec tells you what, but not how. It lists user features, sometimes known as stories, to outline what the user will be able to do on or with the website or application (“user will be able to view outstanding orders”). A functional spec, or a partial one, is sometimes produced by clients as part of the briefing process.  A technical spec, on the other hand, outlines how the features will be delivered, and should cover everything from the coding language, platform and system architecture to sitemap, wireframes and URL.
  3. Information gathering first
    A lot of larger development projects will involve a huge amount of information gathering before a specification can be finalised – be it reviews of existing solutions,  briefings, brainstorming with stakeholders, research and focus groups, or usability studies.  Some will just require a list of required user features to be written up into a functional spec and then translated into a technical spec. In either case, ensure you’ve gathered all the input before you start trying to create the spec – otherwise it’s a movable feast from the word go.
  4. Be consistent in outlining basic requirements
    Writing specs is time-consuming because they are typically so bespoke, but you can make things easier by ensuring you’ve got the basics in a template. This not only gives you a starting point but ensures that the basics don’t get missed. Examples of this are the combinations of platform and browser support undertaken, hosting requirements or expectations, accessibility compliance  etc.
  5. Be specific & measurable – don’t ignore uncertainty!
    Specification. The clue is in the name. If it’s not specific, it’s not doing its job. Be specific when documenting everything. If a deliverable cannot be quantified into a set of numbers, or a defined goal, then refine it until it can be – and this may mean breaking down large chunks of development into smaller bite size chunks until they can be realistically documented. There absolutely will be the temptation to gloss over things, thinking “we’ll sort that out later” or “there’s a couple of ways we can handle that, let’s see how it goes”. But those are traps for the unwary which will almost certainly catch you out at a later date. If something can’t be made specific, go back to your client and ask questions as to how they’re expecting it to work, or back to your developers and ask how they’d recommend delivering it, or both, and discuss until you have a specific answer.
  6. Work through the user journey using flowcharts and wireframes
    For most website development projects, a specification is not complete until you’ve documented the various key user journeys with a flowchart (or series of flowcharts), starting with the homepage and running through all the key processes identifying the key pages or stages of user interaction. Once the key pages/stages and their relationship to each other have been defined, you can also produce very basic wireframes for each key page/stage, blocking out not how the page will be laid out, necessarily (that’s a design decision), but certainly what’s on the page and how it relates to other pages.
  7. Consider risks & mitigations, assumptions & dependencies
    These may not go into the specification document but should be written into your development plan alongside your spec.  As you look at each stage of what needs to be delivered, consider and document the risks, how you can mitigate the risks, the assumptions upon which your spec rests, and any dependencies. So, your client has said that they will be setting up a brand new hosting environment for the project to an agreed specification by the end of this month. Your project specification assumes and depends on that server environment being available on time and being as per the agreed spec. The risks are that it is delivered late, or that the hosting environment is not as expected. You might mitigate around these elements by requiring that the client to deliver the hosting platform two weeks before you expect to need it, so that both timescales and platform shortfalls can be addressed.   Learning to recognise dependencies, assumptions and risk factors is an essential skill… brainstorm these with the team and ensure you’ve planned for them as far as possible.
  8. Use plain English
    Yes, your specification is a technical document, but it’s also the document that outlines the agreement between you and the client as to what you’re going to deliver. You need your client to understand what’s in the document, and sign off against it – so baffling them with technical language is not going to get you any closer to a good clear understanding on both sides of what’s being delivered.
  9. Have someone CHECK your SPEC for specificity and certainty
    Whether your spec document is authored by the project manager or the lead developer or a combination of the two, the key thing is to have it checked by someone else once it’s finished (and before it goes to the client!). Someone who hasn’t been involved in writing the spec should check it, actively looking for holes, unanswered questions, and undocumented assumptions. Anywhere where there is uncertainty, resulting in questions such as “will it do this?” and “how will that work” must be flagged and reviewed. For the spec to be fit for purpose on final check, you must be able to use it to create a solid agreement as to what is being delivered within the project cost, and to prevent scope creep. Can your spec do that?
  10. Document change requests!
    Once your spec is complete and signed off, everyone needs to be clear on what happens when, inevitably, someone wants to change something.   Be clear in the spec that change requests will be documented, analysed, and costed – and implications on timescales and delivery discussed.
  11. Remember to look for lessons learned
    It’s an old management training adage – but if you keep doing the same things, you’re going to get the same results. So, after each project, take time to review your planning and delivery. Did it come in on budget? Did the specification do its job? What lessons were learned?

Rafts! Bridges! It’s a team building day.

August 13th, 2012

On Wednesday we took a trip outside of the office for a team building day. Squinting in the bright Dorset morning (we don’t get out much), we travelled down the Jurassic Coast to Brenscombe Outdoor Centre, in the shadow of Corfe Castle.

After a much-needed breather for tea and coffee, we got underway with the team building activities, which progressed from simply getting the team through a hoop, hitting numbered cones, and then on to crossing a rickety bridge over a raging river below. The last part was imaginary, but we were sure to take it moderately seriously.

The culmination of the previous challenges came when we drove down to the sea in a van full of barrels and wooden poles. Yep, we were about to make rafts. Now we might be kick-ass web developers and designers, but shipwrights we are most definitely not.

And we took to the sea with our rafts! We sailed them majestically, if your definition of majestic involves lots of splashing about. No one fell in though, no matter how shaky one of the boats looked…

The day was a fantastic and fun experience, one that really helped us gel better as a team and understand people’s way of working. It helped us better understand new channels of communications and the challenges in bringing someone new onto a project and communicating needs to them over barriers.

And it finally proved that back-end developers can’t build a boat properly.

Better passwords that you can actually remember

July 20th, 2012

The protection of data is key to the internet. Here at Freshleaf we have put a great deal of time into making our password protected areas as secure as possible using the most up-to-date and trusted techniques. However we can only do so much… in the end it’s all down to the quality of a user’s password that determines the security of their information.

I’ll try and avoid getting stuck into the really technical side of password security here. What I will do however is share some quick tips on how to improve your password security…

Over the years in a bid to get their users to make better passwords, many sites have forced you to create a password with at least one capital letter, special character and/or number. This is done in an attempt to make computers take a lot longer to guess your password. Having capital letters doubles the number of possible combinations of letters, and adding numbers and special characters increases the number of possibilities further. However not all passwords are not easy to remember, as humourously illustrated by this xkcd.com illustration:

Top Tip #1: don’t use “correcthorsebatterystaple” as your password.
Almost everyone who has read that comic now has that password stuck firmly in their heads.

xkcd shows that there’s also a lot of maths you can do to calculate the ‘entropy’ of your current password which I may cover in another post later on. There are also plenty of fun online tools that can tell you how many hours/days/months/years it may take a computer to figure your password out.

Top Tip #2: Try not use a password that you have typed into a password security calculator or any other password generation site.
Any of those sites could just be there to collect passwords, and all it takes is one of them and your password is compromised.

So how do we make a password that is both secure, and memorable?

As the comic suggests, a long password can be more secure than a short password with numbers and characters stuck in-between and also more memorable. One definite is that a longer password is a more secure password, and multiple word passwords are better than single word. So really we are now making passphrases instead of passwords.

Unfortunately from here on some of the suggestions I have are not always possible, as some websites force you to put numbers and special characters in. Some also limit the max length of your password to something small like 10.


Top Tip #3: Sites that specify the length of your password are less secure.
This is because if a hacker knows that passwords can only be between 6-8 characters for example, it instantly reduces the number of possibilities (entropy) their program will need to attempt.

With that in mind, providing you’re not forced to build your password in a specific way, heres are some examples of ways you can make a memorable password.
These are only examples, I am not suggesting you use any of the ideas below as your password security is your responsibility not mine. However they might give you some ideas.

A common one is to add numbers or dates, but this is getting a little too common
Example: iliketomakepasswords1890

Add 10 dots to the end of all your passwords:
Example: iliketomakepasswords……….

Put brackets around your password:
Example: [passwordsarereallyfun]

Add emoticons:
Example: :=)thisismyfavouritepassword:=)

A common misconception is that a computer guessing passwords can guess part of a password. Unless there is a particuarly sophisticated method I am unaware of, this isn’t true. Each attempt at guessing a password is validated on the entire password. Websites don’t come back and tell you that part of your password is correct, or tell you that the last two characters are wrong like a slot machine. So even if your password was joebloggsapple and the guess was joebloggspear, the computer would have no idea that it was close to getting it correct.

So now you have a password that is hopefully easier to remember and yet secure. Or is it?

Regardless of how much entropy your password has and how many years it may take a computer to guess, your use of the password is just as important if not more so. A password that has 100 bits of entropy can be less secure than a password with 8 bits of entropy if poorly managed.

There are people on the web who make money from collecting username/email and password combinations and sell them on. All it takes is those details to be recorded somewhere once by someone untrustworthy and that’s it, you’re on a list. Once your details are on a list, someone can buy your password and hack your account.

There’s not always a lot you can do about this. Looking for certificated sites or secure connections to sites can help stop your password being intercepted in data transfer which is key to online banking for example. But even if the site you are signing up to has those, how can you really be sure? The answer is you can’t, not completely. You could be signing up to, as in the recent case with LinkedIn, a site that was used by millions that hadn’t secured their passwords enough and all those passwords were leaked on a list.

This is particuarly a common occurance on old sites that have been long forgotten about, like that image uploader that you used once and haven’t been back to since. If you used your usual password on that and the same on your Paypal, then you could be at risk.

If you assume that one day your password will be compromised, this will allow you to take steps to limit the damage.

Top Tip #4: Never use the same password for different sites.
But nobody wants to remember hundreds of different passwords. We all know this is a bad idea but how many of us actually use a separate password for each site?

Heres some tips on how you can use the same password, but make it different for each site: (again, these are just tom spark ideas, don’t necessarily use these)

Add the name of the site into your passwords
Example1: facebookjoebloggslikestoshop
Example2: linkedinjoebloggslikestoshop
Example3: twitterjoebloggslikestoshop

Now an argument against this is that a real person looking at your password could look at it and work out what you were doing here but a computer wouldn’t. Using a site’s name isn’t particularly clever, so heres another example:

Add the main colour of the site into your passwords
Example1 (last fm): joebloggslovesthecolourred
Example2 (facebook): joebloggslovesthecolourdarkblue
Example3 (twitter): joebloggslovesthecolourskyblue

If you were to tell someone the pattern you use, they would still need the common bit (e.g. joebloggslovesthecolour) of your password to know the full password.

There’s lots you can do so have fun and make your own pattern.

Top Tip #5: Ultimately, the best way to be secure is to use long passwords, but also be original or atleast be different
invent your own method, that way you are not remembering passwords, just a pattern.

I hope this has helped give some ideas on how to make creating passwords and remembering them on the internet less of a headache.

Own a colour, save a child’s life

June 20th, 2012

Dulux launched a website initiative with Unicef in which users are asked to buy one of the 16.7 million colours that a smartphone screen can display in order to help the charity. This unique effort works on the belief that small acts can combine collectively to save the lives of many children, one child at a time.

Thanks to the funds available as a result in our Charity Programme, we have just donated to Unicef using the OwnAColour.com website by buying our Freshleaf green colour: http://www.ownacolour.com/#79c52f

Just a small donation can buy enough vaccinations to protect 50 children against measles, one of the biggest killers of children worldwide.

We think this is a great idea, and a simple concept everyone can be part of. Share this through your social networks and get your own colour.

UNICEF’s Own A Colour, with Sir Roger Moore

We’re recruiting!

April 11th, 2012
We have now finished recruiting! both of our developer and designer roles have now been filled. We will be posting about our new team members in the near future

 

We’re on the hunt for an experienced PHP developer, and a rock-solid front-end designer to join the team.

For the developer we’re looking for an in-depth knowledge of PHP, MySQL and modern coding conventions such as OOP, MVC and other frameworks. For the front-end designer we’re looking for an expert in HTML and CSS, and able to create eye-catching, functional and usable web layouts.

Full information on both roles is available on our jobs page.

Students blowing a Raspberry in the new year

January 16th, 2012

Raspberry Pi Logo
The new year may be a time for post-holiday blues but there is optimism in the air; the next generation of secondary school students are ditching ICT and learning something far more useful: programming. Considering the UK’s economy is becoming more serviced based, programming in the curriculum is a welcome move and will help the UK stay competitive. The new year also started with news of Nick D’Aloisio, a schoolboy from London, creating his own app for simplifying web searches. As a corporate website design agency we are continually adapting to new technologies and best-practice principles, and as we discovered after our recent search for a high-calibre PHP developer, there’s currently a shortage of good developers in the industry. A new generation of tech-savvy graduates could provide a welcome influx of new blood into our field, as well as changing the way people interact with technology. Maybe, Alexandra Robbins: The Geeks Shall Inherit the Earth, should be on the school book list!

To help facilitate a new generation of programmers, Raspberry Pi, a Cambridge based UK company, has started manufacture of their $25 computer. The computer is credit-card sized and can be attached to an HDTV, making computers more accessible to a mainstream audience—as well as making it an I-want-one-of-those gadget for the tech-geeks among us. The Raspberry Pi computer will be many people’s first taste of using a Linux based operating system for everyday tasks, such as browsing and document publishing. Low-cost computers are going to allow children a kick-start in their career development in lucrative games and media industries; the UK exports many Games developers but is not good in retaining the knowledge within the UK market. Low-cost computers may become thin-clients (computer using another computers processor) to powerful cloud based computers; phones are starting to follow this pattern.

The arts/science divide is slowly closing and could be the key for a long term economic growth strategy in the UK. Freshleaf will be following Raspberry Pi’s progress closely.

What makes a good strapline?

September 9th, 2011

A strapline is supposed to encapsulate everything your about business, telling customers about who you are, what you do, and more importantly why that’s great for them – in just a handful of words. You may never have thought about straplines, but if you look around, they’re everywhere – some brilliant, some misguided, and some utterly forgettable.

I have been working with one of our (b2b) clients this week to help them establish a strapline for their business… and being honest, coming up with the right strapline for the job isn’t as easy as you might think. Good headline/strapline writing is a real skill – but the information you need to come up with the right strapline already exists within your business, so with the right information and the right process, it is possible to nail it.
what makes a good strapline
Read the rest of this entry »

Website content – mind your Peas and Queues

July 14th, 2011

Writing website copy: it’s an essential part of the process of creating a website, but in some cases it’s a bit of an after-thought. Sometimes we – as a web design agency – even end up supplying suggested copy for sections of the site which have been overlooked, copy which ends up going into the production site because no-one seems concerned enough to review it.

But the copy on your website is important. It should be laboured over, drafted and re-drafted, and honed into a thing of perfection. But then I would say that, because I love words. But there’s evidence that not paying sufficient attention to the basics can end up hitting your bottom line, something that every business should take seriously. The BBC news website today carries a story about ‘online entreprenuer’ (what is he when he’s offline?) Charles Duncombe, who contends that a single error in the spelling or grammar used on a website can halve its revenue.

check-your-spelling

Photo credit: CookieDuster, Flickr

Mr Duncombe, who runs a number of e-commerce websites selling everything from mobile phones to clothes and travel, measured the performance of one of his sites before and after a simple spelling error was corrected. The results, he claims, are shocking – the revenue per customer doubled once the error was corrected. Mr Duncombe doesn’t share with us his methodology nor his exact figures, but the implications are obvious.

While older generations bemoaning the quality of written English in school and university leavers is seriously old news, the figures speak for themselves – and it makes perfect sense. Whether you’re selling online or communicating your core business competencies and values, how can you expect anyone to want to do business with you if you haven’t taken the time and trouble to write well structured, interesting and above all grammatically correct copy?

Note to the eagle-eyed and the pedantic - any spelling or grammatical errors in this post are entirely intentional, and were included for the sake of irony. Any errors in the remainder of the website can be notified here.

Start-ups, mergers and acquisitions – the lifecycle of a corporate website

July 12th, 2011

We recently lost one of our well established clients – Icera – when the company was swallowed up by a larger tech giant, Nvidia. We were sorry to see them go, but that’s the way it goes with technology websites – mergers and acquisitions are a part of the life cycle.

Because most of our client relationships are long-standing ones, managing websites from first steps through mergers and acquisitions is something we’ve become very familiar with at Freshleaf.   We’ve done our fair share of integrating branding, products, content and messaging from one website into another – and it can be a challenging process.
Website mergers and acquisitions
Read the rest of this entry »