everything e-diotic

Alexander Simakov has created a general script for use as a pre-commit hook in Subversion integration Perl::Critic, he describes it in his blog.

Elliot have previously discouraged this in his blog, so this of course got mentioned on twitter.

Going over the documentation of: perlcritic-checker.pl in relation to Elliot’s point of view, the following stood out.

# Emergency commits: {0|1}. There are situations when you *do* need
# to commit changes bypassing all checks (e.g. emergency bug fixes).
# This featue allows you bypass Perl::Critic using “magic” prefix in
# comment message, e.g.: svn ci -m “NO CRITIC: I am in hurry” FooBar.pm
allow_emergency_commits => 1,

# Magic prefix described above can be customized:
emergency_comment_prefix => ‘NO CRITIC’,

So Alexander actually supports commits which does not necessarily live up to the local standards implemented and configured in Perl::Critic.

Whether polluting your code base for an emergency fix is a good idea, is another discussion and taking Elliot’s example:

## no critic (RegularExpressions::ProhibitEscapedMetacharacters)

Would or at least should do just as fine, I think, without having tried it out.

I treat most of my no critic statements as #TODO points, points to be revisited later. Perl::Critic to me is lot about controlling technical debt, so hooking this mechanism into Subversion is in my opinion a good idea.

Alexanders script does even support different configurations, so you could let your pre-commit policy hook be a check for the most basic things, so your code base does not get too deep in technical debt and emergency fixes become day to day business, Perl::Critic was implemented to avoid that (see also my little Perl::Critic success story)

After all Subversion and Perl::Critic are just tools to help and assist us and our colleagues as developers.

I was reading an article on the Guardian about the dark side of the Internet. When my eyes fell on the ads on the page, one stood out:

The top banner said (translated using Google Translate):

“Congratulations!
You are our 99999 visitor!
You are at. 20:37:19 been selected as a possible winner of a new: iMac, iPhone 3G or IPAD.
If selected, click here: www.fritvalg.com”

Behind the link you have:

http://ad.adserverplus.com/

click2,CY80AGfQDACUlUcAAAAAALowEwAAAAAAAgAAAAYAAAAAAP
8AAAADFWymFQAAAAAAcTgaAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACknAYAA
AAAAAIAAgAAAAAA1B-
oiCgBAAAAAAAAADM5ZjgxNGFlLTVkMmMtMTFkZi1hMmY4LTAwMjQ4
MTI2YjQzNQCZOzEAAAA=,,http%3A%2F%2Foptimized-
by.rubiconproject.com%2Fa%2F7845%2F12580%2F22638-2.html
%3F,http://
www.planet49.dk/cgi-bin/wingame.pl?
partner_pk=6&wingame_pk=41&sub_id=100326

Check the cgi-bin path: wingame.pl

Hmmmm… Perl can be used for many things…

I have lately turned my interest towards C and Objective-C, looking into iPhone application development.

So I my continued quest to get my tools box for this defined I am monitoring some interesting mailing lists to pick up stuff as it appears.

The other day somebody write to the official Apple Xcode list inquiring about using gcov and generating HTML data. My brain started spinning, I felt like I had read something about this on CPAN.

After a quick search on search.cpan.org I located: gcov2perl a part of the Devel::Cover distribution.

I have been a long time fan of Devel::Cover, having worked as a Perl programmer for many years, so I was happy to see that this particular tool might scratch this itch.

So I threw together your normal example helloworld.c

Code block

#include<stdio.h>
main()
{
    printf("Hello World\n");
}

I skimmed a tutorial on gcov to see how it would normally work.

Compile with options of using gcov:

% gcc -fprofile-arcs -ftest-coverage helloworld.c

Run the executable produced:

% ./a.out

Turned to gcov2perl and followed the manual here (changed it to reflect my own example):

Creates a single gcov file in our case:

% gcov helloworld.c

Transform data to Devel::Cover’s format:

% gcov2perl helloworld.c.gcov

Create the report:

% cover

Open the report in your browser:

% open cover_db/coverage.html

And by clicking the filename you get this report:

The helloworld.c example is very simple, but it proves a point – that it actually works.

I am only scratching the surface of what can be done and I have not fallen into any pitfalls – everything worked fine and looks good, but I am sure it can become more difficult.

Have fun covering your C code and presenting in using a very nice Perl tool.

jerakeen
  
Snow Leopard terminal tabs titles can be set with xttitle. SOLD.

carlmasak
  
“OS X 10.5 includes a command line audio player (in /usr/bin) called afplay.” Ooh, I didn’t know that! Neat. http://bit.ly/dsvrso

Cleaning up my reading list I feel over an article on BoingBoing on a service being asked to cease and desist http://boingboing.net/2009/10/06/royal-mail-uses-lega.html.

I am very interested in post codes so I had it bookmarked for some time, since I wanted to read it at some point.

Then on twitter I see that a fellow programmer has developed a service to lookup you post code in the UK based on location data. http://whatismypostcode.appspot.com/

I immediately wrote him with a link to the article, without reading his service disclaimer.

Apparently the data has been opened to the public, please see: http://www.ordnancesurvey.co.uk/oswebsite/opendata/

So now I know what I want for Christmas, or perhaps even sooner – I want a similar initiative in Denmark.

Please…

Handy tip from TUAW for us who still have the memory limited versions of the iPhone

iPhone 101: Save space on your iPhone without removing a thing

Pretty interesting infographic…

“A clever new infographic from gigaom.com shows how the App Store puts more than 100,000 apps at your fingertips — and generates millions of dollars for app developers worldwide.”

I just discovered Test::NoPlan (http://search.cpan.org/~duncs/Test-NoPlan-v0.0.4/lib/Test/NoPlan.pm)

It goes over you test suite to see if you have any no plan statements – very nice and useful.

So I have added the following test (file: t/test_plans.t) to my growing arsenal of distribution tests:

Code block

use Test::NoPlan qw/ all_plans_ok /;
all_plans_ok();

I once read an article on a new implementation of an autopilot system. My colleagues and me found it quite amusing that it used a dog-bites-man strategy, in the sense that the expert system would guide the pilot and warn him if he was doing something stupid or hazardous acting as a watchdog over human actions and interventions.

The above story is somewhat relevant to a pattern, which have seen at my workplace. To begin with we have increased the number of techies, also meaning more developers and I am one of the newest kids on the block (or the mill is perhaps a better term). After my start and much driven by me we have addressed our processes quite intensely.

We have relaunched the concept of version control since the existing system was not really put to use – it was just used by a single developer and not for everything. So we set up a new server and updated the version control system (Subversion) and migrated the existing projects from the old server.

In addition we made the same exercise with our ticketing system, we had an old Request Tracker installation. We set up a new one in parallel and started creating new issues (RTs) there – the old system had not been maintained and the number of tickets were quite low, so an update or migration seemed like a lot of work for almost nothing, the old version has been phased out now – and we don’t miss it.

So with the two corner stones in place, we have seen a lot of good practices being put to use. Our RT processing has been integrated with or Change Management process (based on an old version of Twiki – which is next in line to be updated IMHO). Our Change Management “system” is based on a list of Change Requests (CRs). We set some guidelines and to act as watchdog perimeters for changes to production environment components.

In addition to a high number of RTs (and lower number of CRs), our change process and work flow are both slowly falling into place. Control over what we do and what we need to do is also improving.

I have printed out the poster from ‘Ship It’ and put this up next to my desk. It is not the complete truth, but it is at such a high-level that it is difficult not to agree with it’s take on the good practices it lists.

So on the infrastructure side we now have the following established:

- Version control (Subversion)
- Feature tracking (RT)
- Issue tracking (RT)

We are a bit behind on the use of Subversion, but I guess we will get there eventually. For the techniques, we have the following:

- Technical lead(s)
- (working from) The list
- Code Reviews

The old dogs in our company are good technical leads, since they now the business by heart and have been employed for a long time.

We have had some basic code reviews, which have demonstrated the power of code review, we have basically used these as sort of daily meetings, just bi-weekly and focus has been more on security and general architecture, digging more into what should be the development process – I will get back to this later. I hope our code review process will be able to support QA more in the long run, but for now this is working great.

We have become really good at structuring our tasks in RT and communication are happening in the RT system instead of in diverse misc. media like email and jabber (well it does, but the essentials are propagated into RT), so we are all basically working from the list, which is perhaps one of the best practices. It gives us an idea of: who is working on what and how much we are actually doing, we are not into micromanagement, but it is a good idea to visualize the pressure under which you technical department is, workload wise

I myself is a heavy user on the version control system, working primarily as a developer and with source code. The page for our homepage (a Typo3/PHP setup) has also been put under version control. For that part we have seen a number of practices evolving out of thin air.

- Release management
- Scheduled (monthly) releases

This is great, we are much more in control of what features are released and they are actually put through an acceptance test cycle before final deployment, which has also proven quite good – slow, but good.

This all sounds incredible! – but we have problems. I have mentioned some of these already, but here is an accumulated list, with some new ones added.

1. Not all systems are under version control
2. Not all people are using version control, so we have differences between components in production and components in the central repository
3. Our project model is practically non-existing so we do not work as a team
4. Ad hoc changes are made to systems in production, see also 2.

Which leads me back to the story I began this block post with.

It is of outmost importance that we are very strict on our change management. I am all for ad hoc changes to the code as long as you do not break anything or introduce bugs, so regression test is quite important and you test the changes before releasing them to production.

We have on one occasion seen changes to a component, where it impacted an imminent release. I was working on a new release of a component, where some logging would be enable a minor thing, I was then notified of a change in production, I requested a diff, evaluated it and it looked all good so I applied the changes – missing a single aspect of the diff. It broke backwards compatibility.

So when I released, my non-intrusive change, it did not work. It took some time for me to fix the bug and get it right. This is of course my own fault and that is what happens if you apply changes in the 11th. hour. So I got my release up and running in another environment with both the change from production and my own change.

A few days after I was talking to another user of the component on another system, the system where the change had been made to production directly. He had not been notified of the change either so his use of the component was also broken, this had nothing to do with my release, since it had not been deployed to the system he was working on, but the issue fell back to me because he knew what I was working on, all I could do was enlighten him on the changes I had applied to make it work.

Apart from my little stray release, our main problem here is changes made for no apparent reason, but the good idea. The change was not in our list of changes to make so nobody could prepare themselves for the change. 2 people spent a lot of time working on correcting things, because somebody had an good idea about a change to an API.

So in retrospect I have gathered that we need to move on with some of the best practices we need to apply and a few other things, here is the short term list:

1. Tighten up our policies about changes to production
2. Code change notifier (RSS feed on our subversion server)
3. Script builds
4. Write and run tests

I had actually scripted the build and written tests, but making the change directly in production does not necessarily require these to practices to be executed and my test suite should have caught the API change – bummer.

So it is back in the saddle…

This is my first post written on the iPhone. I have had the WordPress app installed for a long time, but I have never really gotten around to use it.

So here goes, my first post written entirely on the iPhone. I normally use MacJournal, so I will have to synchronize these entries back to MacJournal, a feature which should work out of the box.

Next test must be to include an image, lets see, lets take a screenshot