Phabricator – code review, browser, bug tracker, and wiki

Phabricator – code review, browser, bug tracker, and wiki

Phabricator is an open source collection of web applications which makes it easier to scale software companies.

For those people who can’t afford GitHub, this should be a pretty good alternative.  Developed at Facebook.  All you’ll need to do is setup your git repositories.

P.S.: The best product descriptions ever (for parts of the Phabricator).

SmartGit — The Easy-to-Use Git+Hg+SVN Client

SmartGit — The Easy-to-Use Git+Hg+SVN Client

Personally, I prefer command line tools that allow me the greatest flexibility and control.  However there are many people who feel more comfortable in graphical environments.  For them, SmartGit looks like a good option.

SmartGit is an easy-to-use graphical user interface for Git, Mercurial and Subversion with optimized work-flows. SmartGit supports all Git and Mercurial features needed for every-day work in software development projects:

  • Local working tree operations
  • Status, diff, log
  • Push, pull, fetch (for all protocols)
  • Tag and branch management
  • Merge, cherry-pick, rebase, revert
  • Submodule support
  • Stash management
  • Remotes management
  • Advanced SVN support (use SmartGit as SVN client)

Integrating RT3 with Subversion

As I have mentioned a few times before, I am a big fan of using BestPractical RT3 for all sorts of things, including, but not limited to, bug tracking during project development.  I see a great benefit in having a single system for both technical support and development departments.  Bugs can be reported by customers, investigated by technical support department, passed on to developers, fixed and tested, and then passed back to technical support department to verify with the customer and resolve.

Needless to say, integrating RT3 with Subversion can be of great benefit.  In this case, not only you will have full history of bug reports, but you’ll also see which code changes were made for each bug report.  Learning from previous bug fixes and having a quick way to see why something was changed is priceless.

Read more to see how RT3 can be integrated with Subversion.  You can also easily adopt the same approach to other version control systems.

Continue reading “Integrating RT3 with Subversion”

Subversion has changelists

Several times a week I recommend to different people to actually go and read The Subversion Book.  Obviously, not enough people do it.  Including myself.  So sometimes I have to fish out a tasty bit from that book to get people interested.  Today is just such a day.

Have you heard about Subversion changelists?  If you haven’t, chances are you aren’t utilizing your time properly.  Here is a brief introduction.

Subversion 1.5 brings a new changelists feature that adds yet another method to the mix. Changelists are basically arbitrary labels (currently at most one per file) applied to working copy files for the express purpose of associating multiple files together. Users of many of Google’s software offerings are familiar with this concept already. For example, Gmail doesn’t provide the traditional folders-based email organization mechanism. In Gmail, you apply arbitrary labels to emails, and multiple emails can be said to be part of the same group if they happen to share a particular label. Viewing only a group of similarly labeled emails then becomes a simple user interface trick. Many other Web 2.0 sites have similar mechanisms—consider the “tags” used by sites such as YouTube and Flickr, “categories” applied to blog posts, and so on. Folks understand today that organization of data is critical, but that how that data is organized needs to be a flexible concept. The old files-and-folders paradigm is too rigid for some applications.

As wonderful as they are, changelists do have some limitations.

Subversion’s changelist feature is a handy tool for grouping working copy files, but it does have a few limitations. Changelists are artifacts of a particular working copy, which means that changelist assignments cannot be propagated to the repository or otherwise shared with other users. Changelists can be assigned only to files—Subversion doesn’t currently support the use of changelists with directories. Finally, you can have at most one changelist assignment on a given working copy file. Here is where the blog post category and photo service tag analogies break down—if you find yourself needing to assign a file to multiple changelists, you’re out of luck.

But even with this limitations, changelists are extremely handy.  So I urge you once again to read the book.   Or just the changelists section.

Subversion is not dead

Git is on the rise right now, especially in the Open Source Software development circles.  Some even went as far as predict the death of Subversion.  As much as I appreciate git (here is a link for you, if you don’t) and what it is doing for the Open Source Software, I have to agree with Brandon Savage:

Corporate America needs a centralized version control system. Subversion still offers this: Subversion centralizes the repository and simply checks out a working copy (versus Git, which gives you a complete repository). Corporate America still needs to have cannonical version numbers, and the ability to see the progress of a product over time as a single line – not a bunch of branches and independent repositories.

And this is true not only for the corporate America.

Web statistics and visitor tracking : things you need to know

First of all, just to make it clear, I don’t recommend writing your own web statistics / analytics / tracking application.  Google Analytics can track and report pretty much everything you will ever need. Period. If you think it can’t do it, chances are you just don’t know how.  That’s much easier to correct than to write your own tracking / reporting application.  I promise.  In case though, Google Analytics doesn’t do something that you need, grab one of those Open Source applications and modify it to suit.  While not as easy as learning Google Analytics, that would still be much easier than doing your own thing from scratch.

However, if you still decide to roll out your own tracker, here are a few things that you need to know.

  • Use the bicycle, don’t reinvent it. Most of the tracking applications that I’ve seen use some form of JavaScript, which is appended right before the end of the page markup.  Said JavaScript collects as much statistics as you need and generates a request to an image on the remote server (your tracking application), passing gathered statistics as parameters to the image.  On the server side, your tracking application gathers sent parameters, merges them with whatever else you can get from the server side, and saves in the database or in your data storage of choice.
  • Keep ad blocking applications in mind. Many ad blocking plugins for different browsers block 1×1 pixel images from remote servers.  Be a bit more creative – use a 2×1 or a 1×2 pixel image.  If it is a transparent GIF at the bottom of the page, nobody will notice it anyway.
  • Gather as much as you can from the server side. It’s simpler, and you minimize the chances of breaking things with an URL which is too long (your GET request for the image with all parameters can run pretty long, especially if you pass current page and referring page URLs).
  • Minimize the length of your parameter names and values when you pass them to image GET request. Again, this is to avoid extremely long URLs.  You can sacrifice readability in your JavaScript and instead document parameters in the server side tracker application.
  • Record both client’s IP address and possible proxy server’s IP address. That is available for you in the request headers ($_SERVER[‘HTTP_X_FORWARDED_FOR’] in PHP for example).  Once you got the IP addresses, use GeoIP to lookup the country, region, city, coordinates, etc.  It’s better to do so at the time you record the data.  There is a free GeoIP service as well, but it will give you much less information.  The commercial one is not that expensive.
  • Record client’s browser information. Browsercap is very useful for that.  However, it’s better to parse user agent string with browsercap at the report / export time, not at the request recording time.  This will guarantee that you always have the most correct information about the browser in your report.  Browsercap gets updated with new signatures pretty often.
  • If you are tracking a secure site (HTTPS), chances are you won’t have referrer information available to you.  Apparently, that’s a security feature.
  • If you use both JavaScript and PHP to figure out the referrer, keep in mind that JavaScript uses document.referrer, while PHP uses $_SERVER[‘HTTP_REFERER’].  Notice that one is spelled with two Rs, while the other – with one.  That might save you some troubleshooting time.
  • It’s better to use the same JavaScript code snippet across all your sites.  To avoid SSL-related security warnings, your JavaScript need to figure out if it’s in HTTPS web site or in plain HTTP one. See Google Analytics example on how to actually do that.   It doesn’t hurt to have a signed SSL certificate for the HTTPS hosting of your tracker application.
  • Don’t forget about HTML and URL escaping / encoding. Check that everything works properly for you in different browsers.  JavaScript is still hard to nail right sometimes.
  • Keep the version of tracker application in every request log entry. This will much simplify your migrations later.  One of the ways to keep this automated is to use tags / keyword substitutions in your version control software (here is how to do this in Subversion).
  • Make sure your tracker spits out that transparent image no matter what. Broken image icons are very visible and you don’t want those on your site just because your tracker database went down temporarily.
  • For the best cross-site tracking, start tracker session, which will remain the same when visitor will go from one of your tracked web sites to another.  If your tracked web sites use sessions, pass their IDs to tracker, so that both tracked and tracker session IDs could be logged in the same request. This will help you link stats from several sites together, as well as do all sorts of drill-downs into site-specific stats straight from the bird-view reports.
  • Don’t be evil! There is a lot that you can collect about your visitors.  Make sure that you tell them exactly what you are collecting and how you are using it.  Aggregate and anonymize your logs to prevent negative consequences.  I’m sure you know what I mean.

Once again, think really good before you decide to do one yourself.  It’s not an easy job.  And even if you grab all the data you want and save it in your database, there is an incomparably bigger issue to solve yet – reports, graphs, export, and overall visualization and analytics part of that data.  Why would you even want to go into that?

Static Subversion for Red Hat 6.2

I’ve heard a few harsh words about Subversion before. Mostly these came from sysadmins who complained about all bits and pieces Subversion requires to work properly. Some mentioned that it is not trivial to compile with the set of options that is different from the default.

Today I spent about three hours together with The Master of Strace trying to make Subversion command line client svn work on one of our old machines that runs Red Hat Linux 6.2. The only way to success, it seems, was to compile the static version of svn. Since we needed support for https:// URLs, we had to build with OpenSSL. OpenSSL is not trivial to compile statically too, because of it enourmous love of Kerberos5. While trying to make it work we also jumped through a number of versions of Subversion and other components.

Finally, we managed to build everything. In case you’ll ever need a statically compiled version of svn (from Subversion version 0.17.1 (r4503)), you can get it here (the binary is about 7 MB):


As far as I am concerned it works just fine. It runs on Red Hat Linux 6.2 and can work (import, checkout, commit, etc) with repository running on one of the recent versions (1.1.4 if I recall correctly).

Needless to say that today I’ve heard a few more not-for-kids-ears words and phrases towards Subversion developers.