I’m over in Holland at the moment. staying with some people I met via SharpE coding — pretty cool, eh? We do meet in real life sometimes! So far it’s all been really good fun.

A couple of days ago we went over to Amsterdam and pretty much wondered around the place. We went to some, ehm, coffee-shops and to watch I-Robot (some Dutch culture, some not). Rest assured the Genuine Amsterdam Coffee Shops were better than I-Robot. I-Robot was okay, but I don’t think that I shall be exactly rushing to buy the DVD. We went to this really cool chilled out coffeeshop after the cinema. The weirdest thing was that just sitting next to us were three guys from the UK. Even weirder was that two were from places within twenty minutes drive of where I grew up and the other was from Bristol, which is where I go to university! Small world, isn’t it.

It isn’t too much of an understatement to say that Eclipse’s refactoring capabilities have changed the way I code. Not by much, but a little. Mainly it’s little things; I have certain things I do now with regularity that I’d have be worried about doing before. Anyway, here goes:

1. Renaming variables/methods/classes/etc. I use this too often to mention. Find you’re doing something with a variable you didn’t think about before and its name isn’t too helpful anymore? Alt-Shift-R it! Makes my code that bit more readable. Of course, all references to the item in your source tree is changed, a major time-saver.
   
2. Breaking out methods. Yeah, so I know you’re meant to have things in small methods, but sometimes it seems that code just comes in long splurging methods. Don’t worry! Break it out into a method with the refactoring tools ‘cause they’ll figure out what you need to pass and return. Seems pretty clever in that Eclipse will find where you’ve used the same code path in other places in the class and change them into calls to the new method.
   
3. Inlining methods. Find you didn’t need to break out that method in the end? Too much of a bind to put it back again? Refactor->Inline code to the rescue!
   
4. Moving methods around. Strictly, this isn’t refactoring, but I’m going to put it here anyway. Dragging and dropping methods around your source outline is pretty useful, especially to put all the methods you’re working on in one place for a while.
   
5. Moving variables to fields. Sometimes it’d just be useful to have global access to a variable, but you’ve got it stuck in a method somewhere. No problem, click it and send it to field status. This helps cause you don’t have to bother working out where the variable was declared. Note that this isn’t perfect yet, e.g. Eclipse doesn’t remove places where you’ve passed the variable as a parameter.
   
6. Taking long statements that you’ve passed as a parameter and making a local variable out of them. Also changes other places where you’ve used the crazy long sequence of method().method().method()… Generally most helpful in debugging, though sometimes a well named variable does wonders for readability of your code.
   
7. Moving things around. You can also move entire classes and packages and have the rest of the project update. Maybe not so good for CVS because you’ll lose your history for the file; useful as hell, however, at the beginning of a project where you want the code to be more malleable.
   

So, I originally planned for ten items, but these are the only ones I could remember without opening Eclipse up to see what I tended to use. Still, a pretty useful list of things you can do, in my opinion. Bring on hardcore refactoring, I say, what we’ve seen so far has just touched the surface!

So, I’m just about to go on holiday. Should be a good holiday, quite a few bands playing that I’m really looking forward to. Hopefully will get some photos posted.

Anyways, my Dad forwarded me details of the holiday insurance we have. As soon as I saw the word “Insurance” in the subject, my pointer rushed straight the the Report Spam button. Ouch, muscle memory for spam deleting!

Yup, I’m now an official, card-carrying, t-shirt wearing member of Daring Fireball =) T-shirt and membership card arrived in the post today.

Why, you ask, given I’m a Linux user, did I choose to support a Mac pundit site? I’d have to say it is simply because I enjoy reading the material on the site.

John Gruber’s articles are consistently well researched, well written and well, darn good reading. When he put up a request for sponsoring, I saw an opportunity to support a guy that I enjoyed reading. Support him in a venture to see if enough capital could be generated to make Daring Fireball a full time occupation. I’m not sure whether that target was reached, but I’m pleased to have supported the effort and the milestone it could represent in internet one-man publishing.

In a way, I suppose I’m fairly lucky. A common complaint brought up whenever I advocate the use of an alternative browser is that one site or other — that is essential to the person I’m recommending the browser to — doesn’t work in a browser other than IE. This is especially prevalent with online-banking sites, I am told. (Usually, upon visiting such a site, one is told to “upgrade” to a “more secure” browser. Don’t get me started on that, we’ll be here all week.)