Category: Programming

A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.

Migrating Twitter Bootstrap 2.3.2 to 3.0

For those of us who are starting to look into Twitter Bootstrap 3.0  for new projects and possible migration of old projects from Twitter Bootstrap 2.3.2 to 3.0, I found a couple of good resources.   Firstly, this very brief StackOverflow discussion on what has changed between the versions.  And secondly, this really nice migration guide.

If only there was an automation tool that works for me… A few were mentioned in this StackOverflow discussion, but none did anything sensible on my projects.  I guess I’ll have to roll out my own, or use some manual labour in combination with powerful search-and-replace tools.

Sentry – an event logging platform focused on capturing and aggregating exceptions

Sentry – an event logging platform focused on capturing and aggregating exceptions.  Most of the code is Open Source (except for a few proprietary plugins), in case you want to run your own hosted version.

sentry

Supports Ruby, Python, JavaScript, Java, Rails, Django, PHP, iOS, node.js, .NET, and more.

PHP Fine Diff – PHP library to diff strings

PHP Fine Diff – PHP library to diff strings.  I’ve tried a few different implementations and all of them either required an external diff program couldn’t render HTML, or failed to due to enormous resource usage.  PHP Fine Diff does all I need and does it fast.   It’s also rediculously easy to use:

$fineDiff = new FineDiff($strOrig, $strNew);
$htmlDiff = $findDiff->renderDiffToHTML();

Found via this StackOverflow discussion.

Git branch names support forward slashes

Oh. My. God!  I’ve been using git for years now and I only learned this today – git branch names support forward slashes! How awesome is that?!  You can do things like this:

$ git checkout -b feature/foobar

Grouping branches like this is much easier indeed!

I came across this while reading CakeDC’s CakePHP Plugin Standard.  Searching around to find more details, I see that there are a few potential issues with this naming convention, as tools occasionally break (composer, IDEs, etc).   However, these problems are fixed by tool vendors.  Looking into it even further, I found the following description in the book “Version Control with Git: Powerful tools and techniques for collaborative software development” (Google Books preview):

Dos and Don’ts in Branch Names

Branch names must conform to a few simple rules.

  • You can use the forward slash (/) to create a hierarchical name scheme.  However, the name cannot end with a slash.
  • The name cannot start with a minus sign (-).
  • No slash-separated component can begin with a dot (.).  A branch name such as feature/.new is invalid.
  • The name cannot contain two consecutive dots (..) anywhere.
  • Further, the name cannot contain:
    • Any space or other whitespace character
    • A character that has special meaning to Git, including the tilde (~), caret (^), colon (:), question mark (?), asterisk (*), and open bracket ([).
    • An ASCII control character, which is any byte with a value lower than \040 octal, or the DEL character (\177 octal)

These branch name rules are enforced by the git check-ref-format plumbing command, and they are designed to ensure that each branch name is both easily typed and usable as a filename within the .git directory and scripts.

So, as you can see, you aren’t even limited to the single forward slash. Even things like this work just fine:

$ git checkout -b Leonid/ideas/feature/foobar

But remember, just because you CAN do something, doesn’t necessarily mean you SHOULD.  Have a look at this StackOverflow discussion about git branch naming best practices for more understanding on what you should and shouldn’t do.