Thoughts of the inarticulate.
My thoughts, which I'm no good at articulating.

Thursday, December 18, 2008

VIM completion is the shit

How good is VIM?

Seriously, how good is it? Pretty fucking good, I say.

There are so many good things about it, but I think the thing that just keeps me from never straying is the completion engine.

It all starts with C-n. And in fact, thats really all I use most of the time. And that baby can complete anything for me across a variety of languages. It completes me.

No other editors that I have come across come even close to VIMs completion, and it would be that hard. It boggles me why other editors can't seem to do it as well.

Forget function completion or variable completion or class completion or keyword completion. VIM completes everything. You've used a function that you haven't written yet, it will complete that, even when you are writing the definition for it. It will complete associative array keys, HTML element ids, files, tags on top of all the regular boring completions you see in other editors. It will aggressively search through your includes in an attempt to please you in some way. And it does it quickly too.

I just used it again. It completed an associative array key name via a couple of levels of includes. Sweet meats my friends, sweet meats.

:help ins-completion

Labels:

Monday, December 15, 2008

Panasonic SC-HT65 with the FX65 Wireless Add On

I picked up a Panasonic SC-HT65 A/V receiver with speakers pack, and the FX65 Wireless add-on for wireless rear speakers.

Its quite a neat, cheap package that has 2 HDMI ins and the option to purchase the wireless add-on pack to remove the need for front of room to back of room speaker wire.

Overall I'm pretty happy with it. Its not fantastic, but its not bad either, and the price is right (I got it for $599, plus $30 for the add-on).

My major, quite significant problem was the wireless speakers interfered with the wireless home network. Seriously interfered. Anything near the A/V receiver and wireless speaker receiver while it was on would lose access to the network (i.e. laptops, PS3).

After much fiddling around with channels on the network, I found that channel 3 seemed to work without a hitch. Problem solved.

I only did this about 30 minutes ago, and so far so good (every other channel had fails immediately) so fingers crossed.

If the interference problem isn't fixed, I couldn't recommend this unit. If it is fixed, then I think this is a very reasonable setup for a reasonable price. Other than the interference with other networks, the wireless works a treat and really does save a lot in not having wires running all over your lounge room.

Anyway, network still working well, and hopefully this is some useful information for anyone else with the same setup having the same problem. It may not be many people though as the FX65 wireless add on wasn't a popular option and is now very difficult to find as all retailers have stopped ordering them. I picked mine up on the bargain table at Dick Smith for $30, their last unit. They usually retail for over $100 I believe.

Update: Unfortunately the interference continues. I'm assuming the FX65 switches between various channels trying to find the rear speaker receiver. There really is no need for it to be so aggressive and so easily completely wipe out the wireless network. The PS3 and laptops can't even come close to connecting to the router.

I'm officially disappointed with the HT65 and particularly the FX65. If you need wireless rears, wait till they work out how to do it well, or maybe try infrared. Would be interested to know what experience other people have had with that.

Thursday, November 20, 2008

Matching HTML tags with VIM

If you have to work with HTML at all, the must-have VIM plugin is Matchit.

Trying to find matching tags in HTML (or often more importantly, missing tags) has always been a head-ache for me and one of the least enjoyable aspect of working with HTML.

Too often has it occurred that I go make some "simple" change to an HTML page, and to my horror when I review my work all of the sudden my once side-by-side columns have become one column on top of another. I know then I'm in for a painful game of tag matching.

With VIM and matchit though, the game isn't anywhere near as painful. Get into it.

Labels: ,

Wednesday, November 12, 2008

The Law of Demeter

The Law of Demeter is something I wish I had learnt early on in my development career. Why isn't at least a whole lecture on this in university? Perhaps there is now.

The best thing about the Law of Demeter is it is short and succinct making it easy to remember:
More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:
O itself
M's parameters
any objects created/instantiated within M
O's direct component objects

There are just some straight-forward rules for developers to follow to keep their software free of unnecessary dependencies and loosely coupled. People often talk about the need to be loosely coupled and to cut down on dependencies, but I just love how the Law of Demeter just lays it down on how exactly that should be done.

Code that doesn't follow the Law of Demeter can quickly bring the development of that software to a slow crawl. The worst situation you can get into when developing software is when everyone is too scared to touch it. Once you are there, the software has hit its peak. Following Law of Demeter (along with unit testing! get into it!) will keep that software moving along like a smooth well-oiled engine or an agile and nimble ninja. And we all love ninjas.

I first learnt this only about 6 months ago in The Pragmatic Programmer: From Journeyman to Master which is a fantastic book all software developers should read. I can't recommend it highly enough.

I guess it was the sort of practice I already knew and was following where possible, but it was good to see it so clearly presented. Great for passing that knowledge onto others as I sometimes struggle to articulate such things.

Labels:

VIM, Python and indentation

So, I enjoy the Python language.  It seems efficient with CPU and memory, comes out of the box with a large amount of libraries, has a lot of support and some high quality web frameworks (such as Django).

Of course, one cannot mention Python without mentioning indentation.  Initially it was one of the things that drew me to Python, as I liked the idea of consistent indenting producing more readable code across the board.  After plenty of experience with not so readable code with crazy source code formatting (please don't put your body of an if on the same line as the if! :P) this appealled to me.

However, it has taken some getting use to, and early on almost made me give Python away.  And some issues still mean I'm not 100% convinced, but I'm still enjoying using Python and will continue to use it.

So, just some things you should learn if you are new to Python and don't want to pull your hair out using it and its strict indentation:
  1. First, if you are using VIM, download this indent plugin for python.  The default is awful.
  2. How to show whitespace in your editor to find where indentation might have gone wrong (Python will tell you about it).  A common example is a tab mixed in with spaces.  In VIM this is accomplished with ":set list" (and :set nolist to turn off again).
  3. How to indent and unindent the current line.  In insert mode in VIM, the default is C-D to unindent, C-T to indent.  These are a must and save muchos time!!! In normal mode it is "<<" and ">>".
  4. Do NOT reindent big chunks of code unless you know what you are doing (e.g. in VIM using "=" on selections).  With Python you really shouldn't need to, since indentation actually affects how your program runs.
  5. Be careful even reindenting single lines automatically (using "=" in VIM for example).
This brings me to the point that I'm trying hard to get over.  I'm use to being able to select a whole file (of PHP for example) and getting VIM to reindent for me.  Or using a source code formatter to reformat the file.  Now, with Python this isn't necessary, considering file will always be properly indented.  I've have done it out of a reflex action, and the consequences weren't fun.  Just don't do this :)

However, if you in the middle of making some changes (e.g. removing a level of indentation) sometimes you do want to reindent a chunk of code.  Unfortunately, there just isn't enough information in the source code for an automatic reindenting algorithm to know how to correctly reindent.  Without being careful, this can cause significant changes (most likely errors) in your program.

e.g.


1 if foo == bar:
2 print "foo equals bar"
3 if foo == zoo:
4 print "foo also equals zoo"
5 print "end of foo equals bar test"

If you use "=" in VIM on line 5 it will reindent it to the same level as line 4. Obviously this is an error.  I guess this is VIM reindent being too aggressive, but the point is such a subtle change can cause drastic changes in a programs execution.  Imagine a much more complicated example than above with more code at each indent level and (heaven forbid) more levels of indentation.

The fact that a developer NEEDS to be so careful about such a subtle thing with major consequences if they aren't, makes me wonder if Pythons handling of indentation blocks is really the best way to go about it.  Bad indentation in other languages makes it look like a mess, but still work.  Bad indentation in Python still looks ok, but won't work as expected.

That said, what it does encourage is less levels of indentation, and less code per indentation, which is what we should be all doing anyway.  

So to continue on, on how best to manage it, which are useful tips for all languages:
  1. Keep levels of indentation within a function to a minimum (I think keeping to 2 or below should be easy enough)
  2. Keep lines of code per indentation to a minimum.  This raises an interesting question about how many lines of code this should be.  I would say under 10 is ideal, 10 - 20 acceptable, and getting more than that means perhaps you need more functions.  I'm certainly guilty of that, however thinking of my nicest, easiest to work with code, under 20 lines seems like a good number to aim for (this is why squiggly brackets on a new line is the way to go people! Stop complaining about your wasted space and write concise functions! :P)
  3. Be very very careful when reindenting existing code.
  4. Write unit tests! They'll pick up any fuck ups. :)

Labels: , , ,

Friday, August 08, 2008

Montastic is not so right? ...

I had a feeling I wrote my last post too early. Although Montastic is not bad, its not particuarly good either.

On the site it says:
How often does the system monitor my sites?
We try to do it every 10 minutes at the minimum. This varies depending on the system load.


However I've found there to be at least 30 minute delays in the change of thats from what I've seen. Thats getting up to delays that make the service pretty useless for my purposes. I want to feel secure that if my site goes down, I'm going to know about it within 10 minutes at the most.

Anyway, I can't complain about a free service. It does seem like I'm going to have to pay to get a decent service. $50 a month still seems too much though. $10 - $15 I'd probably be willing to do. Although often it is worth shelling out the bucks for peace of mind.

Labels:

Thursday, August 07, 2008

Montastic is right!

I was using HostTracker to monitor the websites I look after, and it worked pretty well. I liked the touch of having a GTalk client able to message me if a site when down. Coupled with the fact that any offline GTalk conversations went to my gmail and therefore my phone, it was a good setup. They had upgraded their interface recently which I found more time-consuming to use.

However my trial period expired, and I found that the pricing for what I needed it for seemed ridiculous. $54.99 a month to basically ping test 25 servers? It seemed to me the cost for them to do it for me should be a lot cheaper. Its certainly a service I would pay some amount of money for, but not that much.

After searching around a while for alternatives, I came across Montastic. I've only just signed up, but its looking good. It doesn't have all the features of something like HostTracker, but its quick and easy and should do what I'm looking for. They seemed to have the same mentality as me. To quote their site:

Why is it free? Is there a catch?

There is no catch. We developed Montastic for us and the cost of development was minimal. Montastic is 100% automated and adding servers to monitors costs virtually nothing. So, we wanted to share its usefulness and its fun with others.

Labels:

Sunday, April 27, 2008

Simple Vegetarian Curry

This is a very simple curry I just made on the fly the first time. Everyone who has had it loves it, so here it is:

Curry
- 1 can of chickpeas (400g), drained and rinsed
- 1 can of baked beans (400g)
- 1 can of diced tomatoes (400g)
- 3 tblspns of korma curry paste
- 1 tsp of brown sugar
- 1 onion, chopped
- 1 tblspn of vegetable oil

Rice
- 3 cups of brown rice

Directions:
- Start cooking the rice whatever way you wish
- Heat oil in a large pot
- Put in onion and cook for 2-3 minutes
- Put in curry paste and brown sugar. Cook for another 2-3 minutes, stirring well
- Pour in chickpeas, beans and tomatoes, and simmer for about 10 minutes
- Serve with rice. Add a dollop of sour cream and/or a dollop of mango chutney and you are set! Highly recommended.

About 4 substantial servings. Enjoy!

Labels: