That’s it, that’s all. Back to being useful.
]]>head
and tail
commands.
The problem here is that most anywhere you look, Python’s version of tail
tends to share the same problems.
Obviously, this can be quite problematic when you have 300mb logs constantly processing. Here is a more efficent version of tail
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
This is of course available as a gist as well.
]]>tail
to follow multiple files, you will notice that it can be a real pain to read what data is coming from what file. Here is some quick perl I use to make it a bit easier:
1
|
|
You can of course extend this to a full out perl script that processes data as follows:
1 2 3 4 5 6 7 8 9 |
|
Now you can just pipe whatever data you want into the above script:
1
|
|
release
branchmaster
branch (after release-1.0
has been merged in)1.0
)Fortunately, these problems are easy to fix. In fact, the fixes simplify the model and allow simpler automation.
So, with these points in mind, here is my modified model:
As you can see here, We have four main components:
develop
branch – A local development branch.release
branch – The Release Candidate (RC) branch, available on the staging environment.master
branch – Identical to what is on production. This branch is what we use for hotfixes.The workflow for this model is similar to Vincent’s process but I find that my model allows for a bit more automation. Having the following two distinct build jobs on your staging environment helps this process immensely:
develop
branch into the release
branch. This job can be automated to run at a short interval.Once these jobs are created, the general flow will consist of two parts I call Development Mode and Release Mode.
Development mode is simple and probably almost identical to what you do now. You and your team develop on a local
environment based on the develop
branch. The automated Merge and Build job allows you to push new code to your staging environment easily.
When you are ready to do a release, a few small changes are all you need to do to enter “Release Mode”:
release
branch.
release
branch should be merged back into the develop
branch.Once you are satisfied that your release branch is fit for production, you should:
release
branch into the master
branch.master
branch.If you are wondering why we don’t just build our production environment from the master
branch,
it is because the tags give us the option of rolling the server back in the rare chance something goes wrong.
With this model, you can easily apply hotfixes to the production environment.
hotfix
branch based on the master
branchhotfix
branch as necessary.hotfix
branch back into the master
branch.master
branch. We use letters to signify a hotfix.master
branch back into the develop
branch.Most developers can tell you, in a small team there is rarely time to waste. This git branching model allowed my team to stop wasting time building servers and focus on what matters: development.
As always, let me know what you think!
]]>When using Linux every day, it is important to find a distribution that works for you. For me, after more virtual machines than I care to count, I settled on Fedora as my distribution of choice. I really like the constant releases and the latest software. It’s also nice to be able to jump on a RHEL machine and feel at home!
So, I get pretty psyched every 6 or so months when a new version of Fedora released. The latest release is one of the bigger ones they have done and, while I am still playing around with it, seems full of great updates.
Since I use it as my development environment, the nicest change for me day-to-day is the update to Gnome 3.4, a WM that I seem to enjoy much more than most developers apparently.
If you have some time, grab the latest Fedora release and check it out! You won’t be disappointed.
]]>I posted a new gist I simply call notify
which allows you to give
custom messages in the message tray in a programmatic way. I often use it in conjunction with kTimer.
I have only tested this script with Gnome 2.x-3.2 but it very well may work in KDE or other desktop environments.
If you find notify
useful, please leave a comment!
Because I like colours and am in the terminal more often than not, I have developed somewhat of an obsession for colourizing all the things I can. I have created two scripts which I find myself using with some consistency. They are alternative, ANSI colour friendly implementations of watch
and cat
. I have created a gist on github for each of them.
I hope you find them as helpful as I do!
]]>