I was looking for a way to have that classic “pull down to reload” functionality, but without the actual reloading part. I wanted to extend a UIScrollView to have an embedded view above it where I could put some buttons and detail information and which would lock to displaying the sub-view when over a certain threshold. The result was a class I called ScrollLockView, which does what its name entails. You attach it to a UIScrollView and when that view is scrolled beyond a certain point it will lock the scroll, displaying the attached view for all to see (and interact with). I took cues from a PullToRefreshView I found on GitHub and built something more generic.

The following example is pulled from the readme file and should work if inserted into the ViewController::viewDidLoad function of a single-view application:

// A full-sized text view
UITextView *textView = [[UITextView alloc] initWithFrame:self.view.bounds];
textView.text = @"Why, hello there!";

// The lock view will be full width and 100px high
ScrollLockView *lockView = [ScrollLockView viewWithHeight:100.0 aboveView:textView];

// Make it red so we can see it
lockView.backgroundColor = [UIColor redColor];

// Add some buttons and junk here...
//[lockView addSubview:[UIButton ...]];
//[lockView addSubview:[UILabel ...]];

// Add the scroll view to the main view
[self.view addSubview:textView];

Keep in mind that the code is built for using iOS5′s Automatic Reference Counter.

Source on GitHub

The iPhone has one screen resolution, no matter what. Even the “retina display” just allows for larger images while the effective screen size is the same. This makes it a breeze to build the user interface for a utility app where you want pixel-perfect control. Building an Android app requires you to take the various screen sizes and aspect ratios into account, which pushes you towards building fluid layouts that move and stretch accordingly. Mixing the two worlds is asking for trouble.

Titanium

Titanium is my favorite app development framework, as it allows you to write cross-platform code but relies on native controls and UI, meaning that your application will feel natural in whatever device it is built for. You code the whole app in Javascript, using a special API that builds the UI controls:

var window = Titanium.UI.createWindow();
var button = Titanium.UI.createButton({
    title: 'Click Me';
}); 
window.add(button);
window.open();

The result of building a responsive design in Titanium

This works well, and with the recent addition of CommonJS modules, the development of an app is fast and can be remarkably modular and structured. However, trying to merge the two worlds of UI building comes with a few problems. Titanium has built-in functionality to handle automatic stretching of controls and automatic layouts, but it’s clear from their tutorial videos that the Android and iOS are too dissimilar to use the same UI code for both platforms. Not only do they have different screen resolutions and aspect ratios, but they also don’t have the same controls and a selector on iOS is a giant spinner that takes up 45% of the screen whilst the Android platform has a more classic drop-down control. If you’re intending to build an app using Titanium then you have to create separate UI modules that communicate with the same core.

Note: Nothing against Titanium, per sé, but I spent a long time building a copy of the dice app in Titanium only to have it fail when I tried it in the Android emulator. There is a chance that I was using some code that the Android didn’t like and I hadn’t noticed because I had only been testing in the iPhone.

PhoneGap

PhoneGap works as wrapper of sorts; it encapsulates an HTML5 website in a native “web view” whilst giving you access to hardware features via a Javascript API. This allows you to take all the benefits of using the DOM (stretching and positioning elements in a logical hierarchy) while crafting an app that can be installed via their respective marketplaces and has the same features as a natively-build application.

Running in PhoneGap using the standard jQuery Mobile theme.

One negative aspect of using websites is the lack of the native look and feel of controls, and if you want to create an app which at least looks right in accordance to the platforms, then you’d be best off using a Javascript/CSS framework built for such a task (jQuery Mobile and Sencha Touch comes to mind). Another problem I’ve discovered is that you are in essence masking the presence of a website by removing the toolbars, and the same functionality is there under the layers of mobile-style goodness. For example, a long hold on a link will cause the “open in a new window” popup to appear, which does break the illusion a bit.

Note: I tried building the app using jQuery Mobile and I was experiencing a definite lag when switching between the main and settings views. I probably wouldn’t have thought much about it if I hadn’t seen how fluid and fast the native app is.

Native Code

Last up is building the app using the respective native tools, Objective-C in XCode for iOS apps and Java in Eclipse for Android apps. If you’re already familiar with how the applications work on their separate platforms, then you’re probably better off doing it the “manual” way, as trying to learn how things work in Titanium or PhoneGap involves forgetting a lot of things. Without formal knowledge however, you are setting yourself up for months of learning and lots of failures. When building the original app I had gone through the Lynda.com video program on iPhone development and had restarted the project 3-4 times before finally getting a product that worked.

The great benefit to coding an iOS app using the official tools is by far the visual program designer. So much of the settings and tweaks for specific controls can be set in a WYSIWYG editor that connects to the code in a surprisingly easy way. It also lets you create specific views for portrait and landscape modes, as well as the iPad layouts. It is more focused on custom-building the UI for the four different possible ways of viewing it, and the designer makes it easy to do without having to write code and constantly compile to make sure you’ve moved things correctly.

XCode is a beautiful looking piece of software.

On the Android side of things you have the means to build the interface using XML layouts, where you define the controls inside layout types that will position and scale the controls appropriately. One of the formats, RelativeLayout, is geared towards compensating for vastly different displays as it lets you specify how “heavy” a control is, meaning it will take up more of the relative space available, growing and shrinking other controls appropriately. The XML layouts are the best way I have found so far of mixing variable and fixed sizes and is clearly built with the intent on being distributed on devices where the screen resolution is unknown.

Both of the native tools are built so specifically for their target platforms that trying to replicate them in a cross-platform framework would be foolish, and the end result is that you are left with a half-way point that doesn’t really play on the strengths of either. I’m still going to stick to Titanium for now, but my frustrations are pushing me back towards the native way of doing things. I’ve already gone through the hassle of learning Objective-C, and Java is a part of every schooled programmer’s repertoire, so maybe focusing on building apps that look and feel like native constructions rather than going for some deformed halfbreed is the best way forward.

The Joel Mike Test

1. Do you use source control?
2. Can you deploy the site in one step?
3. Do you deploy to a test server first?
4. Do you use a project management tool?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have automated tests?
11. Do you learn from your mistakes?
12. Does the client participate in continuous testing?

The idea behind this test, in case you didn’t bother reading Joel’s original article, is to ask these questions to a prospective employer, or to your own team to see how healthy the development environment is. They are simple yes/no questions and answering “yes” to every single one is a sign that you’re doing things right. Joel claimed that a score of ten or less “yes” answers was a warning sign, but it all depends on what you put weight on.

1. Do you use source control?

This is a no-brainer in large production teams, but even if you’re the lonely coder on a project it doesn’t mean you should get away with not using a source control tool such as Git, Mercurial or CVS. If you’re in the mood for basic guidelines on how to use Git from the view of a single individual working on personal projects, I wrote about that too.

2. Can you deploy the site in one step?

Deployment of a site can be a hassle, especially if you have a server farm behind a load balancer and some caching servers, so being able to run a script that takes care of it for you saves a lot of time. However, just because you only have to upload files via FTP to one server doesn’t mean you should. Having to constantly push minor changes, which are plentiful when dealing with clients, will tug on your nerves and waste an unnecessary amount of your time, so this part of the process should be a “fire and forget” procedure that runs an automated script which moves the files to the correct spot, preferably from your source control database so it doesn’t have to copy the files from your local development environment.

3. Do you deploy to a test server first?

If you have a “fire and forget” script that does the deployment, it probably shouldn’t go live without some sort of testing first, preferably in an environment that replicates the live server as closely as it can. This step may seem tedious, but saves you a lot of trouble with minor problems that come up when you’re moving from development to production. You should always test out your code locally first, but having a sandboxed testing location as a stopping station between your computer and the live server is a great way to catch small oversights and bugs before they are exposed to the public. This is also a great place to get your client in to see the changes before it goes out (see #12).

4. Do you use a project management tool?

I’m not saying that everyone should throw a lot of money on a complicated, overpriced ticketing system, but when it comes to building projects where the specification is never set in stone, it helps to have a centralized place to gather all the tasks that need to be done. Even if it’s just a spreadsheet on a shared server, it’s still a lot better than every developer/designer/manager walking around with private todo lists in their heads or on sticky-notes on their desks. A phone call from a client becomes a task in the system and can be dealt with at an appropriate time by the right person.

5. Do you fix bugs before writing new code?

I didn’t have a better way of formulating this, so I just copied Joel’s question. Fixing bugs and catching up on “technical debt” is never prioritized high enough when the clients are knocking on the windows, wondering where their website has gone. However, long periods of neglect can result in bugs accumulating in unsurmountable heaps that hang over the heads of the development team. Being able to stop and take care of the housekeeping before running off to complete the next task is a great way to keep the machinery running smoothly and ensuring that the code monkeys are happy.

This applies also to the progression of the development environment and the tools that the coders use (see #9). If you’re meaning to update the server software, but you’re bogged down by client requests, you should probably just take a step back from the workload and get it done. Waiting until it crashes is not good planning and if you can spend a week to save five minutes of every hour in the future, you shouldn’t delay getting it done.

6. Do you have an up-to-date schedule?

One of the worst parts of the fluid nature of a client site specification is the inevitable feature creep and minor tweaks that sneak their way into a project while it’s being developed. I understand that it’s hard for clients to know everything they want in the pre-project planning period, but when they suddenly remember that they want to enable facebook login, have an interactive image gallery, add some more red on that border or any other tidbit, the end result is usually that the project gets bloated with new tasks without it changing the release schedule.

This is dangerous and stupid, but not really the fault of anyone involved as the changes are small and infrequent but eventually compound the complexity of the project. A good rule of thumb is that any change, no matter how seemingly trivial, gets the project pushed back some amount of time. Moving a frontpage widget a few pixels down adds a few hours to the final deadline and adding any form of custom functionality that wasn’t previously specified should involve asking a developer how long time it’ll take and then doubling that.

Obligatory kitten to break up the wall of text — Courtesy of placekitten.com

7. Do you have a spec?

Ah, the illusive specification, that we all know is going to be out of date in a few months, and usually doesn’t seem to be necessary to write at all, is something that should be demanded by every development team, even if the site is just a personal blog for a local politician’s dog. The specification can be as complicated or basic as you’d like, but the idea behind it is to protect yourself from any later changes that can greatly delay the development period (see #6). If a client asks for something that wasn’t a part of the original agreement the specification will stand as witness to this, and you are free to ask for more time/money/bananas to get it done.

8. Do programmers have quiet working conditions?

This one is a hard question to justify in an environment where communication between the different segments of the development team needs to be frequent and easy, but trying to get anything done in a room full of distractions is a disaster waiting to happen. The general idea is that if a developer can put his headphones on and be able to focus without worrying that someone is going to tap him on the shoulder (or throw a paper plane in his face), then that’s good enough to ensure that work will be done. Communication over email or IM is an easy way to prevent any loss of efficiency from the constant stream of people who may need some information from one of the coders. It may not be a perfect solution, but is a good enough compromise to get stuff done.

9. Do you use the best tools money can buy?

If I have to wait half a minute to login to a page I’m developing because the database server is a decade old then I am more likely to avoid having to wait by visiting YouTube. And since I’m already on YouTube I should probably check out that drum cover my friend told me about. Suddenly 30 seconds turns into five minutes and I’ve lost the groove I was in.

10. Do you have automated tests?

Automated tests are a great way to catch small problems that might otherwise find their way into the live code by way of lazy, tired or stressed developers. Although we would all love to make unit tests for everything we build, that’s usually not how the real world works. However, having an automated script that kicks in when trying to push your code upstream (see #1) which checks your code for debug outputs, kill commands or lack of proper indentation will go a long way to avoid silly and embarrassing mistakes.

11. Do you learn from your mistakes?

Any rational human being can tell you the benefit of learning from your mistakes, but its sometimes hard to see where things went wrong in a lengthy project, especially if there are many people involved. Learning from your (or others’) mistakes would involve a retrospective analysis of the project where you focus on what went wrong and what went right and make a conscious effort to change those aspects of your development process. If you intend on spending weeks on metrics analysis and status meetings, then this point is hard to justify, but usually an hour-long post-morten meeting where you all agree to play less Minecraft and write more comments in the code should suffice.

12. Does the client participate in continuous testing?

You’re building this page for somebody, usually somebody not directly connected to the development team, so if you work in a vacuum with no interaction with the client until the product is finished then you’re setting yourself up for a lot of changes and tweaks after the release date. The client should have access as early as possible (see #3) and should be able to come with feedback in a non-intrusive way (see #4) that doesn’t break the development plan (see #6 and #7). This will ensure that the final result is something they are happy with and it’s easy to keep them appeased if they are aware of the constant progress and don’t have to send a frustrated email before they get to see any changes.

These questions all have their benefits and drawbacks, the major one being the time and effort required to put any of them into practice, but there is always something to be gained from trying to make the way you work better, by however measly amount. All projects are different, all project teams are different, and you’ll quickly find what aspect is important to you, but taking a step back every now and then and tweaking the machinery can’t be a bad thing.

Thanks to Joel Spolsky (of Stack Overflow fame) for the inspiration for this post.

The latest iteration runs on my Sections framework (gotta eat that dog food) and is based on the Foundation framework, which I have fallen absolutely in love with. The greatest part of the framework is how it adapts to the size of the screen and means that the website will work on mobile devices without me having to do anything.

Well almost, because having a layout which responds to the size of the screen means that you need to take into consideration where you apply padding, borders and margin so that when the content is shifted around it doesn’t break the style or you see the dreaded horizontal scrollbar. Mobile browsers have thrown a wrench into web design conventions, but with a responsive style framework and some forward thinking we may come up on top.

What the gallery looks like

Another thing I had to deal with was that everything was going to come from my brother’s flickr account, so that he can take pictures and put them up there without having to worry about his dumb stupid website that his geeky brother had thrown together for him. Also, instead of insisting on him only uploading images of a certain size, I just built a simple GD-based resizing script that would take any new images, resize them to the right formats and then save them in folders on the server. Now I had a steady stream of pictures that fit perfectly into the design I had built. Thank science for modern web development libraries!

I’m pretty happy with the result and my brother doesn’t have to do anything outside the usual to keep his website up-to-date.

Joachim Enger

Made by designers for designers.

My initial response to the discovery that IE was behind these two projects was disbelief, followed by doubt, and then more disbelief. I grew into a web developer in the midst of a chaotic time for web browsers, where majority control over the masses of web-surfers was wrestled away from Internet Explorer 6 over the course of 6~7 harrowing years. I’ve spent countless hours tweaking and downgrading my designs, hacking at a wall of bugs and generally tearing my hair out to get things to work with IE6 and now Microsoft is trying to promote HTML5/CSS3 features as if they were never standing in their way to begin with.

I am aware that we have come a long way since IE6, but Internet Explorer’s story isn’t exactly the greatest example of forward motion in the history of application development. IE7 was released in 2006, five years after IE6, and at the time felt like a direct response to the introduction of Firefox, which came out of nowhere and exploded in popularity with its countless extensions and tabbed browsing. Since then, every new version of Internet Explorer has been promised as the “one they get right” in terms of following defined web standards and exploring new undiscovered territory, but it has come short every single time. IE is the best example I have seen of the narrow-mindedness of enterprise-focused software:

• Littered with proprietary features
• Focused on innovation-stifling backwards compatibility
• Long and obscured development cycles

I hope you’ll forgive my aggressive stance, but you must realize that I learned the basics of web development in an environment where everything I did in terms of following the guidelines for HTML and CSS was usually counteracted in some unholy and incomprehensible way by IE6. Later incarnations proudly proclaimed their superiority, but the few changes and lackluster support for internationally-accepted standards felt like a joke and, being the one shackled with the task of tearing apart my work in search of the one thing that IE misunderstood, I took it like a personal insult. Every new version of IE still required a conditional CSS stylesheet and at some point, just when IE9 came out, I stopped caring and decided that people still stuck with Internet Explorer would see a broken, ugly version of the website. The browser had gone from a nuisance, to a problem and was finally disregarded as nonexistent.

It's a good looking game.

My hyperbolic examples aside, I will argue that the mentality behind the decisions on where to take Microsoft’s flagship browser is counter-productive to the modern environment around development. Open source projects have gotten huge and aren’t going anywhere and people are getting very used to small, incremental updates and a transparent development cycle and it amazes me that it took Microsoft over 5 years to realize this.

That said, past my initial response of rolling my eyes and thinking that this was a shallow attempt to regain some ground with developers, I can’t help but think that this is a great thing. Both of the websites work damn well (in Opera and Firefox) and are examples of the web moving forward to provide more varied content. Also, Internet Explorer 10 is being developed with preview builds and updates from the development team and is getting a warm reception from the community. I am not changing my browser anytime soon, but maybe I’ll stop judging people as the enemy if they’re using the browser that came with their Windows system.

Edit: It has come to my attention that Microsoft are using slightly underhanded methods to promote their new browser. Maybe things aren’t that different after all.

Another edit: Microsoft seems to know how we feel (from Reddit).

I based the theme of a WordPress variant of the Foundation framework created by Drew Morris and I must say that it’s the best CSS framework I’ve had the pleasure to use. I’ll be sticking with this from now on.

PK Bloggin’!

The current app lineup (of which the official We Are Hunted app is by far my favorite) showcases some of the cool things that can be done with the API, which lets you not only get the currently playing tracks, but create play queues from within the app, allow for dragging of tracks/albums/artists into your app and even have direct control over the music player.

Chromium's inspector open inside Spotify

The API was fascinating and all, but what caught my attention more was the idea that it was a fully-functioning Chromium-browser inside the program. This is nothing new, as Steam does something similar (using Internet Explorer, I think), with the application interface mirroring their main website, and PhoneGap has a way to wrap your website in a native shell which will run on mobile devices while giving your app access to hardware and system functions. However, I was fascinated by the possibilities it presented and I had to dig deeper to see what I could make.

I built a small app that fetches flickr pictures based on the currently playing artist, which took about evening of coding and taught me a lot. I am now of the firm belief that HTML/JavaScript is the future of app creation. Where I was once a stout supporter of native code using native UI, after building a website that runs inside of another application, I have completely reversed my opinion on the issue.

Spotify is a platform which doesn’t have built-in UI elements, doesn’t support multi-core processing and can’t run complied code at a-billion-calculations-per-second, but it doesn’t have to. The only thing it needs to support is letting you interact with the application itself and using a compiled language or going down the dangerous route of making their own scripting language would only have needlessly complicated the process and created an enclosed space with high barriers to entry. Sticking to HTML and JavaScript worked like a charm and given my long experience with building websites I was able to take an idea and build it in shorter time than it would take to get my app through Apple’s App Store Approval Board*.

What really blew me away, which in hindsight really shouldn’t, was the fact that it was a fully-functioning web browser, which meant that any code that would work on the web would work inside Spotify. I gave this a test and my aforementioned app experiment uses jQuery to perform the ajax call and DOM-selections, and follows a lot of the JavaScript coding conventions I learned while working on the Endless YouTube project.

What makes me think that the future of apps lies in HTML and JavaScript is mostly because of how prevalent it is and how easy it is to insert a sandboxed instance inside your application nowadays, opening up for anyone who has built a blog or made a drop-down menu to create apps that integrate with the program as if they were a part of the native code. The future of web development isn’t on the web, it’s taking what works on the web and shoving it anywhere you can find room.

As a final test to see if this web-to-app idea really holds weight was to try to see if a canvas-based game I built with some of my coworkers would work inside Spotify.

It did, and I didn’t change a single line of code to do it.

* Not trying for any subtle commentary here, just providing a useful and humorous metric.

Unfortunately there is no way to share apps just yet, but if you have a preview version of Spotify and a developer-enabled Spotify account (it’s just one email away) then you should grab the code and see how much can be done without any prior knowledge.

Source on GitHub

Doesn’t look like much, but it gets the job done. After some more tweaking I felt that there was a game in here somewhere, so I recruited a coworker of mine to create some nicer graphics and he came up with the idea of ninja vs samurai. A game is born.

You control your ninja and have to get to the escape hole without being seen by the samurai, who have a dramatically limited field of vision, but who will kill you instantly if you are spotted. Along the way you will find scrolls you can pick up and you can try to complete levels in a limited amount of moves.

The game is available from IndieDB for Mac and Windows and the source is on GitHub.

Ninja vs Samurai

Source on GitHub

In my short history of using Git I have crafted a few guidelines that I follow to make my personal development experience just a little bit better. These guidelines aren’t complicated rules, but more of a description of the mindset I am in when using Git for my personal projects. These reflect a methodology which has evolved over a period of working on my own and I find them useful in keeping myself on track and having some quality control over my own work even when there is nobody else there to scrutinize it.

A small byword before we begin: I’m not sure about the true definition of iterative development, but in my mind it means that you start off with a small project and slowly but surely add components and features, each time ensuring that your modifications don’t break what you are working on. This could mean that you start off with a tech demo and work towards fulfilling a specification or it could just be adding to an existing product to create new and better versions of it. The topic is broad and my personal interpretation is vague and undefined, but in lieu of wasting everybody’s time explaining everything I’ll just leave it as: cutting a big project into smaller tasks that are done one after another.

There is But One Master Branch

What is the master branch anyway? Is it just the branch named “master”? Is it the single branch which all branches merge into before deployment? Is it the single branch that all branches are based on? Sure, it can be all of that, but in my mind it represents the final product. I don’t have a habit of working on multiple branches, especially because I am working by myself, but the master branch is the only one that I push to GitHub and the only one I can really depend on when it comes to showing what I’m working on to others.

In most projects all work is done to reach a single goal, the final product, which should be reflected in the way that Git branches are treated. Working on a separate branch should be done with the intent to merge it into the master branch at some point and you should never have multiple branches that reflect different versions of your program or different final projects that are part of a single ecosystem. When I migrated my Endless YouTube Player from PHP to Javascript there was a temptation to create different branches to hold the different versions, but in the end I understood that the move from PHP to JS was a part of the evolution of the project, and holding on to a stunted PHP version in its own separate branch would just create the illusion of an unfinished new feature being left to die. This is a task that is best left to tags, which are great for keeping track of previous versions of the project for whatever reason.

Push/Merge Only When You are Finished

This makes sense, right? You only merge back into the master branch or push your changes to the central repository once you are finished with what you’re working on. It’s of course up to you to decide what “finished” means, but for me it was when I was working on a specific feature which took me a few hours to complete, spanning over multiple commits.

I use GitHub’s Issues tracker to keep tabs on what fancy features I want to add to the various projects I’m tinkering with and it makes sense to leave any changes I have done in concordance with one of the issues on my local computer and wait until I’ve completed the task before I push it up to GitHub. This only really makes sense when the tasks are small enough to not span over several weeks, because losing my laptop or having the harddisk spontaneously burst into flames would be devastating if I had a month’s worth of work without a backup. However, if you’re breaking up your project into month-long chunks then I can’t really help you.

Every Commit is a Finished Product

This is probably the one which will either incite ire or have you cheering on my pedantic view on iteration; commits, no matter how big or small, result in a finished product that could be deployed and released into the world. This might be a little hard to explain, but it ties in with the previous guideline in the sense that whatever changes you’ve made to your code will not result in any unfinished function or pending changes left for subsequent commits.

If you’ve added a new feature then the feature is ready to be used, even if there is no way to trigger it. If you’re fixing a bug which requires you to change two parts of the program, then one part is changed and made to work with the rest of the program before the other change is implemented. Let me try with an example:

One of the features I was trying to implement in my upcoming puzzle game was the addition of collectibles scattered around the puzzle boards. A part of this feature was to change how the game keeps a player’s score, allowing it to keep track of the amount of moves the player had used to reach the goal as well as the amount of collectibles the user had picked up in that particular level. First I changed the scorekeeping to allow for multiple variables associated with a level, making sure every piece of the game which referenced the scoreboard was aware of this change. This was then committed (with an appropriately descriptive comment) and I moved on to adding the collectibles counter to the scoreboard which was then added to a separate commit.

This may seem like overkill, especially on such a small feature where the difference between the two commits was about 10 minutes of work, but it encapsulates the primary mentality I have when it comes to iterative development. Every task can, and should, be broken down into smaller sub-tasks which are completed sequentially and without affecting the rest of the project. Commits are just a simple way to create a symbolic separation between the sub-tasks and having the commits never break existing functionality or leave an unfinished gap to be filled in later is just good form. Good form results in better code and happier coders. That’s a scientific fact, look it up.

Tagging = Deployment

Depending on what type of project you’re working on, the concept of “deployment” can have many different meanings, but a good rule of thumb is to define it as any time where the project can be seen by people who aren’t directly involved in its creation, whether that be showing it to a client or putting together a demo to post on a social game development website.

The idea behind this guideline is to define the points where the project is production-ready and create a tag on only those instances, as those are the points in time which is it interesting to look back on. You can always go back to any commit you’ve created, such is the beauty of versioning, but, much like the previous guideline, this is a symbolic gesture of “it’s done” that ties in with the iterativeness of the project.

Those are the guidelines I follow, at least so far, and they have served me well, crafting a neat and logical Git history for me to follow. That said, these are based on my experiences with working by myself, so I won’t guarantee that they’d work in large teams that have to deal with bug fixing alongside feature development or some other crazy stuff that geeks get stuck doing when they’d rather be micro-managing their commit messages.