Choose Your Poison

When dealing with programs there are almost always multiple ways to write same thing. Rule of thumb is usually to write it in most readable way. And there people start disagreeing what exactly is readable. Let’s take simple condition:

if (object.equals(obj1, obj2)) {
    ...
}

if (object.equals(obj1, obj2) == true) {
    ...
}

Both these statements do exactly same thing. Heck, they even get compiled to same code. However most programmers I have ever met prefer first one. It just makes intention clear in shorter form.

It’s negative cousin would be:

if (!object.equals(obj1, obj2)) {
    ...
}

if (object.equals(obj1, obj2) == false) {
    ...
}

Again, both statements are same. But I can bet that they will do almost perfect split among programmers. Half of them will prefer concise form with other half preferring longer form. Reasons will vary. For some exclamation mark is too easy to omit when scanning code. For some longer form just sticks out for no good reason.

Personally I passionately hate negative statements and I will avoid them whenever I can. If I really need them I am in group that strongly believes that later form, while longer, is superior as readability goes. For me that is worth seven additional characters. Strangely enough, in positive cases, I omit true.

P.S. One more variation of negative case would be:

if (!(object.equals(obj1, obj2))) {
    ...
}

It might as well be in goldilocks zone. It gives a bit more visibility to exclamation mark by enclosing everything in another set of brackets. Of course, given statement long enough, it can look rather crowded.

Selecting a LDO Voltage Regulator

I am in process of creating new USB board for my personal nefarious purposes and I needed nice 3.3V voltage regulator. Usually I just use LD1117DT33TR. It has decent maximum current, works up to 15V and it comes in nice DPAK package that helps to keep it cool. However, for this occasion, it was just too big. I wanted something smaller.

While simplest thing would be to pick one that would suit me in this project. However, I always like to spend a bit more time in order to get a chip that I can reuse in bunch of other projects. Here were things that I desired:

• 3.3 V
• at least 50 mA
• SMD
• LDO
• easily available in Croatia
• very simple
• preferably cheap

First I searched on RS Croatia site for all LDO 3.3V regulators in SOT-23 package. Sorting them by price gave me few candidates. They were AP7313, TS9011SCX, TC1014, SP6201EM5 and MCP1700. All others that were cheap enough were variations of same basic devices. Quick search on DigiKey didn’t find TS9011SCX so it was automatically disqualified. High cost removed SP6201EM5. If I am searching for jelly bean component, I want to have one that is always available and very cheap.

Another odd-man out was TC1014. I haven’t had anything against it’s specifications. They were good enough and in some parts better than chips that stayed in competition. However, it had five leads. I wanted my final choice to be as simple as possible. That left two SOT-23-3 devices in race: AP7313 and MCP1700.

Both these devices satisfy all my needs. And then some. Both have short-circuit protection, thermal protection and both are stable with 1 μF ceramic (nice!) output capacitor. For most parameters where MCP1700 was slightly better they were close enough not to really matter. Great example would be quiescent current. While on first glance there is huge difference in favor of MCP1700 (40x) that only matters in case of extremely optimized battery-powered device. Since almost all devices I do revolve around computer, it is just parameter that I do not care about. For all jelly bean 5 to 3.3 V LDO purposes they are equivalent.

After spending some time going back and forth I decided to use MCP1700T-3302E/TT. Reason was stability. While both regulators work with ceramic capacitors, AP7313 requires output capacitor ESR to be 20 to 200 mΩ. This does cover wide range of ceramics, but for MCP1700 is even better. It’s output capacitor can have ESR anywhere from 0 to 2000 mΩ. That range covers pretty much all capacitor types that I would find on my shelf.

If something comes up where AP7313 would be great fit (e.g. no minimum load), I am fine with that also. You see, AP7313 comes in two different footprints. In case of AP7313-33SRG-7 footprint is same as one that MCP1700 uses. You can mix and match them based on cost and availability as much as your heart desires (just watch for those capacitors!). And that gives real lesson of this post: whenever you can try not to limit yourself to single supplier.

Mercurial on CentOS 6.2

For pure server tasks there is probably no better free distribution than CentOS. What is then more natural than use it as a Mercurial server?

I will assume that CentOS 6.2 is already installed (at least minimal) and DHCP (if used) is already set up. Simplest test would be connecting via SSH. If you can connect, you are ready.

First step would be to install our web server. There is no doubt (ok, there is some) that Apache is way to go here.

yum install httpd
service httpd start
chkconfig httpd on

After installation we need to adjust firewall and test out setup by pointing our browser to whichever address our server has (in my case that would be 192.168.56.101). When you get Apache test page, you can continue further. Until that time, fiddle with settings.

There is already a Mercurial package included within CentOS repository but it is rather old version (1.4). We will go with newest and greatest. At time of writing that would be Mercurial 2.2.2.

rpm -Uvh http://pkgs.repoforge.org/mercurial/mercurial-2.2.2-1.el6.rfx.i686.rpm

Now let’s create directory structure:

mkdir -p /srv/hg/cgi-bin
cp /usr/share/doc/mercurial-2.2.2/hgweb.cgi /srv/hg/cgi-bin/.

Next we need to edit /srv/hg/cgi-bin/hgweb.cgi. Find line that has config parameter and replace value with “/srv/hg/cgi-bin/hgweb.config”. Then create /srv/hg/cgi-bin/hgweb.config and write:

[collections]
/srv/hg/ = /srv/hg/

[web]
allow_push = *
push_ssl = false

Those settings will allow for HTTP-only operation where everybody (authorized) can push changes. For small networks this might be suitable, but you should probably be looking into at least enabling HTTPS. Guides for that can be found all around. You can find even (Ubuntu-specific) https guide on these pages so feel free to adjust and configure.

Last change will be to /etc/httpd/conf/httpd.conf. At the very bottom we will add following text:

NameVirtualHost *
<VirtualHost *>
    DocumentRoot /srv/hg/cgi-bin/
    ScriptAliasMatch (.*) /srv/hg/cgi-bin/hgweb.cgi/$1
    <Directory "/srv/hg/cgi-bin/">
        SetHandler cgi-script
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>
    ErrorLog /var/log/httpd/hg.log
    <Location />
        AuthType Basic
        AuthName "Mercurial"
        AuthUserFile  /srv/hg/.htpasswd
        Require valid-user
    </Location>
</VirtualHost>

Short restart later (another service httpd restart) you should be greeted with 403 forbidden.

Turns out that there are few more things to do. First one would be to create new user (testuser).

htpasswd -c /srv/hg/.htpasswd testuser
 New password:
 Re-type new password:

After that is sorted out, we need to adjust directory rights:

chown -R apache:apache /srv/hg/
chmod a+x /srv/hg/cgi-bin/hgweb.cgi

Last setup step would be to adjust SELinux security a bit. Easiest way would be to disable it completely (check /etc/sysconfig/selinux). Proper way would be to just load module which allows actions that we need. While you can troubleshoot this yourself, I have also prepared pre-compiled SELinux module (only httpd-mercurial.pp is really needed, other file is for reference). After unpacking, just execute:

semodule -i httpd-mercurial.pp

And that is it. Now you will be able to access your repositories at 192.168.56.101 (replace IP with yours) and do with them as you please.

P.S. To create repository all you need is to:

cd /srv/hg/
hg init TestRepo
chown -R apache:apache TestRepo

WordPress Noindex

As I was checking search for my website I noticed that Google would return essentially same page multiple times in search results. One result pointed to post, second one pointed to same post but within categories and third would be same again but in archives. Not what you can call great search experience.

On WordPress platform (that is used here) solution is really simple. All pages that I don’t want shown I can block from Google via robots meta attribute with content “noindex,follow”. Simplest way to do this is to directly edit header.php file and, below

<?php
    if (!is_singular()) {
        echo '&lt;meta name=&quot;robots&quot; content=&quot;noindex,follow&quot; /&gt;';
    }
?>

If page is singular in nature (e.g. post, page, attachment…) nothing will happen. If page is collection, one simple html attribute is written.

While this is simplest solution, it is not upgrade-friendly. For each new WordPress version, same change will be needed. Better solution would be to pack this into plugin so each new version can continue using it without any change. Creating plugin in WordPress is as easy as filling some data in comment (e.g. plugin name, author and similar stuff) and then attaching to desired action. In our case full code (excluding plumbing) would be:

add_action('wp_head', 'nonsingular_noindex_wp_head');

function nonsingular_noindex_wp_head() {
    if (!is_singular()) {
        echo '<meta name="robots" content="noindex,follow" />';
    }
}

Whole plugin can be downloaded here. Just unpack it into wp-content/plugins directory and it will become available from WordPress’ administration interface.

VHD Attach 3.40

Most noticeable change for this release will be new icon. Not a huge change, but a colorful one. Considering that last icon was gray-scale, I see it as a good change.

Other visible change would be New disk dialog. It is changed a bit in order to allow for more flexible size entry. Finally you can create 0.1337 GB hard drive that you always wanted.

Under the hood there were many changes. While some were bug-fixes, most of them were focused on drive management. This will finally give possibility of drive letter change in next version (currently being tested).

Download is available from within application or via program pages.

P.S. If someone is interested in checking drive letter management beta all you need to do is to send me a mail.