Greg MacLellan

September 23, 2008

Google Charts

Filed under: Asides,Code — groogs @ 9:17 pm

I just came across Google Charts API. This is basically a chart rendering engine that lives at Google, that you can use to render any piece of arbitrary data and display it. Very cool, and a quick and easy way to make nice looking charts, without having to install/buy a charting library.

August 15, 2008

The power of jQuery

Filed under: Asides,Code — groogs @ 8:22 am

Jeff Atwood made a post today talking about the benefits of coding using Javascript frameworks. It totally echos my own thoughts and experiences on it, namely that I used to hate writing client-side code because javascript was so terrible. After discovering first Prototype + Script.aculo.us, and then completely moving to jQuery, my outlook has completely changed. I really do enjoy writing client-side code now. It’s easy, and the results are among the most immediate real programming results you can get, because it runs right there in your browser. Using Firebug, you can even test code interactively while you write it.

August 13, 2008

Inheriting constructors in C#, VB.NET

Filed under: Code,Rants — groogs @ 9:24 am

Several times, I’ve come across the need for inheriting constructors in .NET, and I am constantly annoyed that it does not work. I’m writing a business objects layer, and what I’m trying to do is create some constructors in the base class that can initialize the objects in many different ways, eg:


Public Sub New() ' Create new object using default storage
Public Sub New(ByVal storage as Storage) ' Create new object using specified storage
Public Sub New(ByVal conditions as String, ByVal parameters() as Object) ' Load an object by the specified query, using default storage
Public Sub New(ByVal storage as Storage, ByVal conditions as String, ByVal parameters() as Object) ' Load an object by the specified query
Public Sub New(ByVal id as Object) ' Load an object by the specified primary key, using default storage

And so on. I like to provide many different ways in the base classes, to 1) make writing the objects that inherit from this as easy as possible, and 2) make writing client code as easy and flexible as possible.

Unfortunately, since you cannot inherit constructors (except for the default New() constructor, if that is specified in the parent..), you cannot do this. You have to define stub constructors in each inherited object which call the parent constructor, which ends up being a whole bunch of copying and pasting, and even more work if you ever change/add a constructor.

Eric Gunnerson posted a blog entry about inheriting constructors, and there is a good discussion on it in the comments. I completely agree with Darren Oakey who suggests that constructors should be inherited if and only if no constructors are defined.

This fits in with the default behaviour of inheriting the empty constructor, and generally is compatible with existing code. The only time it would break existing code is if you have an object with no constructors that inherits from another with a non-default constructor, and you specifically want your inherited object to have the default constructor.


Public Class A
Public Sub New(ByVal value as Integer)
End Class

Public Class B
Inherits A
End Class

In the implementation right now, B only has the default (no parameters) constructor. If this change is made, B will have New(ByVal value as Integer), so existing code that assumes it has no parameters will fail. The fix for this is to explicitly define a constructor for B as:


Public Class B
Inherits A

Public Sub New()
End Sub
End Class

One of the arguments against inheriting constructors seem to be that implicit operations are bad and confusing – however, in my view, having the default constructor implicitly added in the above case is exactly the same thing. Additionally, as is pointed out in the comment thread in Eric’s post, this is also how methods behave. Why should constructors be different?

Another option is to add a class attribute that would allow constructors to be inherited, eg:


<InheritConstructors(true)> _
Class B
Inherits A
End Class

It would really make the language more powerful, and allow writing simpler and nicer code. In a simple example:


Dim cust as Customer = Customer.Load("id = {0}", 123)

becomes:


Dim cust as New Customer("id = {0}", 123)

May 29, 2008

SvnMergeGui

Filed under: Code,General,Technology — groogs @ 2:01 am

I just created a Google Code project for a quick and dirty little app I built, SvnMergeGui. As you may suspect, it’s a GUI to SvnMerge.

It uses ClickOnce for the installation (because it was really easy to do from VisualStudio), and is pointed at the svn repository for updates – so although I’ve never tried it, the theory is that it will have automatic updates built-in. You can download the install files from the project page linked above.

April 4, 2008

UI First Design

Filed under: Code,Technology — groogs @ 12:24 am

Often when I am writing software I design the user interface first, or at least separately, from the rest of the code. Jeff Atwood describes UI First software development on his blog:

Of course, UI is hard, far harder than coding for developers. It’s tempting to skip the tough part and do what comes naturally — start banging away in a code window with no real thought given to how the user will interact with the features you’re building.

Remember, to the end user, the interface is the application. Doesn’t it make sense to think about that before firing up the compiler?

I found this particularly interesting and timely in light of the topic being the brunt of a recent April fool’s day joke on The Daily WTF. When I read that post, I actually found it surprising that programmers would think it satirical to consider designing the user interface first. Of course, the rest of the post gets a bit more crazy but I won’t touch that part.

Jeff talks more about the benefits of paper prototyping:

Paper prototypes are usually pitched in terms of doing low-fi usability studies, and rightly so. But I find a paper prototype tremendously helpful even if I’m the only one that ever sees it. I need to create an image in my mind of what I’m building, as it will be seen by the world, before I start pouring the concrete to make it real.

Figuring out the GUI definitely helps you get into the guts of what you need to accomplish in the end, and so it is definitely a helpful task. I think there is another tremendous benefit that to this however: developing a nice user interface.

Okay, so this seems like a less than earth-shattering revelation. Many programmers totally miss the mark on this though. Consider the traditional approach: write a command-line app or hardcode everything in, get the code working, and then write a GUI on top of it to expose to the end user. By doing this, you automatically box yourself into writing a GUI based on your underlying API or database layout.

I think there is a big benefit to taking a step back, totally forgetting about all the underlying API stuff you did, and think up a design for the best possible UI that you can for the problem you’re trying to solve. Pretend you’ll be the one using it every day for the rest of your life.

What you come up with may be totally incompatible with your API; that is okay. In fact, it may even point out fundamental flaws with the way you’ve done things (hence the benefit of the initial paper prototype..). It may work exactly with your code. It may require a translation layer of sorts, to convert what the underlying code is doing to how things are represented in the UI. It may also require compromises in the UI to be able to write a translation layer. All of these are good outcomes though because the end result is you generally have a much nicer UI than you would get if you just stick a pretty face on the raw API.

To use a simple example, consider the Google MyMaps interface. Underneath, the database is storing locations using their latitude and longitude, and assigning a name to them. The ultimate simple interface to this would be:

Simple "add a point" UI

Of course, what Google actually did makes much more sense – even though it involves a whole lot of code that translates mouse clicks on the screen into map pixel offsets, and then those into latitude/longitude:

Good "add a point" UI

In a lot of situations, the success of your software can come down to how nice and/or easy to use the GUI is, regardless of how powerful it is underneath (I’m sure you can think up many examples of this .. perhaps in say, the operating system world). Whether or not you actually design the UI first is inconsequential – ultimately you need to design the UI for the end users, not for the API.

January 17, 2007

PHP mail() logging

Filed under: Code,General,Technology — groogs @ 12:33 pm

I’ve posted my php sendmail wrapper before, but I just noticed that Ilia Alshanetsky has written a php mail logging patch that essentially does the same thing, but from within PHP itself. This is nice because it can log the full path of the file and line where mail() was called, whereas my script can only log as much info as PHP passes to sendmail (which isn’t very much) and what it can get from the environment. The downside is since it’s a patch, it requires recompiling – my script can be dropped into any installation (PHP4/5, and maybe even 3) and just requires a simple php.ini change.

I should also point out that if you’re using this, you should be sure that you don’t “whitelist” localhost in your mail server, or otherwise people can just connect to your SMTP server locally, and send mail without requiring a username or password. If they use SMTP you can’t see what script or virtual host sent the mail either way, but at least if you require authentication you can see what account is being used if it becomes an issue.

July 23, 2006

MythTV + PVR150

Filed under: Code,General,Technology — groogs @ 10:21 pm

I have been using MythTV in my living room for the last couple of months, and it’s quite a nice setup. Originally, I got it as a media player after the DSM-320 didn’t live up to my expectations (it’s still usable, but it’s been relegated to the 13″ TV in the bedroom).

MythTV main menuWe don’t actually subscribe to cable, and only get a few network channels that ‘leak’ through from the cable internet, so I never really intended it to act as a PVR. One day I happened to see a good deal on a Hauppage PVR-150 that included a remote, so I figured what the heck.

Recordings screenIt’s nice to have it record a few shows every day, and the “only keep x episodes” feature is handy. I even have it recording the local 6 o’clock news (and only keeping 1 episode) since I never usually watch it at that time. It’s also nice to always have a few episodes of The Simspons to pick through.

Media Library screenI’ve never been a slave to the TV schedule, I’d rather just not watch something than re-arrange the rest of my life around a tv show. For shows that interest me enough, I’ll download them and watch them at my leisure, and never miss an episode or watch them out of order. Having a PVR to do that just makes things easier.

Live TVOverall, myth was fairly straightforward to get working. I installed it on a Debian Sarge box, from source, along with ivtv and lircd.

Program GuideI wanted to post some of my config files, particularly for the remote setup, since it was very difficult to find the files for these, and for some unknown reason almost no one has posted complete configs (that have all the buttons configured) for the remotes.

  • /etc/lircd.conf – Remote definitions for various Hauppage remotes
  • /home/mythtv/.mythtv/lircrc – Mapping of remote buttons to MythTV commands

Caller ID on screen displayI also have asterisk and FreePBX installed to run my phones (I’ll write another post about that another time). One of the nice things about it is I have an on-screen popup when someone calls. I’ve written instructions on how to set up freepbx with mythtv osd on the FreePBX documentation wiki.

It does take a bit of reading and a bit of playing around, but it’s well worthwhile to setup MythTV as a PVR.

By the way: sorry about the crappy quality images for the live TV, it’s from my cell phone camera. I couldn’t take a screenshot of the video output (it just came out blue, like in the program guide picture).

April 18, 2006

CodeIgniter

Filed under: Code,General,Reviews — groogs @ 8:13 pm

I’ve been playing with a sweet PHP framework called CodeIgniter, and I have to say: I love it. It uses the MVC pattern, which I’ve never much cared for, but does it in a nice way: by staying out of the way. The models are incredibly basic, and really, you don’t even need them. The views are PHP templates done the way PHP templates should be done; with PHP.

Something many frameworks miss: the documentation is amazing. There is a great tutorial video on their website, and after watching it, many people say they’re hooked. The user guide is even better: well laid out, and it even has a slick interface and look that makes it pleasurful to use. What’s missing is pure API documentation, but there is a reference (that I now have printed and posted just above my desk) and most of the calls are outlined in the manual.

Unlike many other frameworks, it doesn’t impose any strict methods of doing anything. You have a controller that is a class with a bunch of functions. There are ‘helpers’, ‘libraries’, ‘plugins’, that all have a common way of loading ( $this->load->library(‘session’); for example). These can be core libraries, or application-specific (installed in the application/ folder). The directory layout is very intuitive, and it can all go underneath an HTTP root folder (not requiring certain files inside/outside of a web-accessable folder — double plus for people using shared hosting with open_basedir restrictions).

I started experimenting with it for the second version of web interface I’m writing, and I actually decided to port another application I had 75% done to it. It’s still in-progress as I write some user authentication routines, and I decided to write a “SuperModel” class (yeah, kind of dumb name) that builds forms and validates them – because I hate manually building forms.

If you’re a PHP developer, I highly recommend checking this framework out. It’s only been around publically for a couple months and has been aparently downloaded over 5000 times, and has a growing and active community in the forums.

December 16, 2005

Sendmail Wrapper

Filed under: Code,Technology — groogs @ 11:30 am

We had some spam problems last week, one of them caused by a form that wasn’t properly escaped. While that problem was fixed, the real problem was that it was hard to figure out what script had the issue.

To solve this, I wrote a sendmail wrapper for use by PHP (though really it could be used by anything) that logs the message along with the date, a message id (also inserted in th e headers) and the current directory (which gives the location of the original script).

It also extracts out the domain name from the current directory, but this is server specific so you’ll need to change the pattern to match your file system.

Eventually I’d like to include support to check for a maximum number of recipients, and maybe some other heuristics to check for spam.

You can get the script at:
http://gregmaclellan.com/php/sendmail.phps 

You should save this file as /usr/local/sbin/sendmail_logged.

The reporting script is at:
http://gregmaclellan.com/php/mailreporting.sh

There are instructions in this file for how to add it to cron.

Let me know if you have any comments, suggestions, do any improvements, or find any bugs.