I've been tinkering today. I'm working in Python/Jython on an automated test harness. Typically, I'm standing on the shoulders of giants : the developers who have given me an API with which to test their Java app using a bit of Jemmy magic. I hope to have (relatively) large shoulders for my testing colleagues to stand on, and that means hiding / abstracting the API that I've been given even further. It's going well, but it's not quite there yet. Today I needed to write a very specific test, and there were two approaches that I could take. One was to extend an existing class which takes scripts as Python lists, to be able to do a drag and drop action. The other was to create a new class to allow custom/bespoke tests to be written without resorting to too much reproduction of boilerplate code.
Eventually I got something working. Ironed out some niggles, and was quite pleased. It would have been easy to leave it at that. It was certainly good enough. It seemed a bit clumsy though. There was still a lot of work in subclassing and calling my bespoke test (It's called 'custom', but I already know it'll be called 'bespoke in about 4 hours if I ever get some sleep). I needed to figure out a way of getting boilerplate out of a function that created an instance of a subclass and into the parent class, where it could be forgotten about for all eternity by people writing the tests.
A solution (which may itself be refactored), was to pass a parameter (called 'parameters', containing a Python dictionary, which can be accessed by key, which makes it human readable) into the parent class' constructor, the constructor calls some functions which can be overridden by the subclass. The parent class has a function that calls the test body and records results, and the test body is overridden in the subclass to do the stuff that the test writer wants to do.
It means that the test writer subclassing the bespoke test class now doesn't need give a monkey's chuff about the boilerplate code. He (Sadly we are all 'He' in the lab at the moment) just writes some simple steps and can assume that the environment for executing those steps is initiated and torn down automatically.
Wednesday 25 March 2009
Refator, refactor, refactor.
I didn't come across the term 'refactoring' until relatively recently, but it's something I've always done without realising it. Or at least without labelling it. I don't know of an official definition of refactoring, but it would probably go something like this : "Refactoring is the process of improving code quality without changing its function".
Refactoring is just tinkering until it feels right.
Renaming is the simplest form of refactoring.
Renaming is also the most significant key fundamental form of refactoring. Change the name of a variable, method or class, and it can have massive implications on the design. Get a name right, instead of merely almost right, and clarity ensues; pieces of the puzzle fall into place. Glaring mistakes, omissions, duplications and complications become suddenly apparent.
Refactoring is just tinkering until it feels right.
Renaming is the simplest form of refactoring.
Renaming is also the most significant key fundamental form of refactoring. Change the name of a variable, method or class, and it can have massive implications on the design. Get a name right, instead of merely almost right, and clarity ensues; pieces of the puzzle fall into place. Glaring mistakes, omissions, duplications and complications become suddenly apparent.
MacHeist
There's some argument about the MacHeist bundle. Whether it's good business and whether it's ethical for us consumers to avail ourselves of a bargain.
I think that validity of the business aspect is for the developers to decide. If participating gets the developer a big pile of cash they wouldn't normally get, it gets them a whole lot of exposure that would otherwise be difficult to get (other than with expensive advertising), and it's not going to cause a support nightmare, then where's the problem ?
Marco Arment may think that it’s not a good idea, as conscientious consumers, to accept such steep discounts on the products that we use and love, but while I don't disagree in principle, I think the argument is a red herring. Without MacHeist, an awful lot of people would not pay for or use this software. With MacHeist, an awful lot of people will pay for this software, may install some or all of it, and may even use it occasionally.
I'm a MacHeist customer. The ethical validity hadn't crossed my mind until today. Having thought about it a little, I think I actually paid over the odds for the bundle considering the actual use I'm going to get from it. There's an outside chance that I'll use one of the apps more than twice. An app may become part of my arsenal. If it does, then it's a dead cert that I'll pay the full upgrade price for the next major release. I get some cheap useful software now, and the developer gets a customer for life.
Having this stuff needlessly installed contravenes a number of al3xs rules for computing happiness. I don't care. There are 133 items in my Applications folder. That's way too many. I don't care. I think Apple make great stuff. I think developers on OS-X make great stuff. I don't want Comic Life Magiq on my Mac because I'm into writing comics. I want it there so that when someone says, "Wouldn't it be cool if we could make a comic of that", I can show them how easy it is with great software. I become a cheap and willing salesman for Plasq (and for Apple).
Don't think of MacHeist as exploitatively cheap software, think of it as a quite expensive demo suite.
I think that validity of the business aspect is for the developers to decide. If participating gets the developer a big pile of cash they wouldn't normally get, it gets them a whole lot of exposure that would otherwise be difficult to get (other than with expensive advertising), and it's not going to cause a support nightmare, then where's the problem ?
Marco Arment may think that it’s not a good idea, as conscientious consumers, to accept such steep discounts on the products that we use and love, but while I don't disagree in principle, I think the argument is a red herring. Without MacHeist, an awful lot of people would not pay for or use this software. With MacHeist, an awful lot of people will pay for this software, may install some or all of it, and may even use it occasionally.
I'm a MacHeist customer. The ethical validity hadn't crossed my mind until today. Having thought about it a little, I think I actually paid over the odds for the bundle considering the actual use I'm going to get from it. There's an outside chance that I'll use one of the apps more than twice. An app may become part of my arsenal. If it does, then it's a dead cert that I'll pay the full upgrade price for the next major release. I get some cheap useful software now, and the developer gets a customer for life.
Having this stuff needlessly installed contravenes a number of al3xs rules for computing happiness. I don't care. There are 133 items in my Applications folder. That's way too many. I don't care. I think Apple make great stuff. I think developers on OS-X make great stuff. I don't want Comic Life Magiq on my Mac because I'm into writing comics. I want it there so that when someone says, "Wouldn't it be cool if we could make a comic of that", I can show them how easy it is with great software. I become a cheap and willing salesman for Plasq (and for Apple).
Don't think of MacHeist as exploitatively cheap software, think of it as a quite expensive demo suite.
Saturday 14 March 2009
Scratch from MIT
My son, who is in year 6, has expressed some interest in programming (like lots of kids, he wants to be a games designer). I tried getting him interested by introducing him to Python. I thought he could get used to the language and OOP, without getting heavy with strong typing, verbose, unclear languages. Python gives fairly quick results (faster, probably if you don't use is like an Ada jockey who knows a bit of Java)
I'd looked very briefly at PyGame, and figured that it would be relatively easy to pick up.
Last week though, I followed a link to scratch, and it was very obvious that this was the place to start. I think I was right. I showed it to my son this morning, and with a little guidance, he finished writing a version of Pong today.
There are some aspects of scratch that I think could apply to a real IDE. Drag and drop constructs, statements, objects etc may b e a simplification too far, but the graphical representation of them seems a lot better than simple code colouring …
OK, it's little fisher price, and would need toning down in a real IDE, but it's also clear about what belongs where. It shows scope very well. It's not unlike Python's indentation based scope, but also more explicitly shows the end of the scope of a block with no additional code . There's no reason that this graphical representation couldn't be live generated while typing in a 'real' language. Something like this…
might look like this…
There'd be a problem with the code becoming illegible in deep blocks. (exaggerating)…
I think there's an advantage though. If the code is 15 or 20 levels deep in a single file/class/method/function, then there's some bad design going on there, and it should be refactored. The opacity would become a useful visual representation of the readability of the code.
I'd looked very briefly at PyGame, and figured that it would be relatively easy to pick up.
Last week though, I followed a link to scratch, and it was very obvious that this was the place to start. I think I was right. I showed it to my son this morning, and with a little guidance, he finished writing a version of Pong today.
There are some aspects of scratch that I think could apply to a real IDE. Drag and drop constructs, statements, objects etc may b e a simplification too far, but the graphical representation of them seems a lot better than simple code colouring …
OK, it's little fisher price, and would need toning down in a real IDE, but it's also clear about what belongs where. It shows scope very well. It's not unlike Python's indentation based scope, but also more explicitly shows the end of the scope of a block with no additional code . There's no reason that this graphical representation couldn't be live generated while typing in a 'real' language. Something like this…
might look like this…
There'd be a problem with the code becoming illegible in deep blocks. (exaggerating)…
I think there's an advantage though. If the code is 15 or 20 levels deep in a single file/class/method/function, then there's some bad design going on there, and it should be refactored. The opacity would become a useful visual representation of the readability of the code.
Why the iPod Shuffle is broken
Having pondered the new (3rd gen) iPod Shuffle for a little longer, I think it's broken. I want it to fail. I want everyone who fancies one to reject it. There are two reasons. One I'd mentioned before, as a nitpicking detail: no control on the device itself. the second reason is that there's bloody DRM in the headphones. What it means is that only authorised manufacturers can make replacement headphones or extension cables that include the utterly necessary controls. The little inline remote has an authentication chip in it.
I don't object to the inline remote. I don't object to Apple selling a chip to other vendors that allows them to send the requisite signals to the device to control it. Plenty of devices have proprietary controls like this. Think TV remotes, for example. What I object to is doing this while having no controls on the device itself. Why ? It just feels broken. Headphones go missing, get trodden on, go missing down the back of the sofa. Having the player break at the same time is an appalling design decision. It's either stupid or greedy.
In programming terms, the shuffle ad its controls are highly coupled. They're so highly coupled that they should be one unit.
I've experienced the problem that Apple have introduced to an extent with a couple of televisions. Al functions are accessible from the TV remote, but not all functions are accessible from the buttons on the TV. This is a broken interface. A device, whether it is a tiny MP3 player or a big TV should still work fullywithout the remote, even if the interface by which its functions can be accessed without the remote are less convenient / more fiddly.
Edit: some doubt has been cast on whether the EFF and ilounge reports on the chip in the headphones has anything to do with DRM / DMCA. Maybe they're just trying to grab headlines.
I don't object to the inline remote. I don't object to Apple selling a chip to other vendors that allows them to send the requisite signals to the device to control it. Plenty of devices have proprietary controls like this. Think TV remotes, for example. What I object to is doing this while having no controls on the device itself. Why ? It just feels broken. Headphones go missing, get trodden on, go missing down the back of the sofa. Having the player break at the same time is an appalling design decision. It's either stupid or greedy.
In programming terms, the shuffle ad its controls are highly coupled. They're so highly coupled that they should be one unit.
I've experienced the problem that Apple have introduced to an extent with a couple of televisions. Al functions are accessible from the TV remote, but not all functions are accessible from the buttons on the TV. This is a broken interface. A device, whether it is a tiny MP3 player or a big TV should still work fullywithout the remote, even if the interface by which its functions can be accessed without the remote are less convenient / more fiddly.
Edit: some doubt has been cast on whether the EFF and ilounge reports on the chip in the headphones has anything to do with DRM / DMCA. Maybe they're just trying to grab headlines.
Wednesday 11 March 2009
Thoughts on the new iPod Shuffle.
The voices on the new iPod Shuffle are different for Tiger, Leopard and Windows.
I suspect that the voice isn't produced by the shuffle from the tag text in the sound files. I think it's added by iTunes as audio. This audio could be embedded as a new tag or it could be added as a separate resource file. I assume it'll take a while to process a whole library to add this data.
Edit: the Shuffle needs a new version of iTunes. I think this supports my hypothesis about the metadata.
Overall impression is good, but I'd like to pick some nits nits...
The control is on the headphones. What if you want to use other headphones ? (I never had a problem with the headphones that came with my old iPod, but the ones that came with my new one simply don't stay in my ears).
The control is on the cable for the right ear. What about the sinister left handed people. It would make more sense to have this on the main cable before the split.
The obvious fix is for some third parties to make a cable with an inline control and a headphone socket. The problem that introduces is that the combined cable will be too long, and the position of the control in that length of cable might not be ideal. Of note, the last pair of Sony headphones I bought came with a very short cable (about 18"), and an extension cable which adds another 2 feet.
I suspect that the voice isn't produced by the shuffle from the tag text in the sound files. I think it's added by iTunes as audio. This audio could be embedded as a new tag or it could be added as a separate resource file. I assume it'll take a while to process a whole library to add this data.
Edit: the Shuffle needs a new version of iTunes. I think this supports my hypothesis about the metadata.
Overall impression is good, but I'd like to pick some nits nits...
The control is on the headphones. What if you want to use other headphones ? (I never had a problem with the headphones that came with my old iPod, but the ones that came with my new one simply don't stay in my ears).
The control is on the cable for the right ear. What about the sinister left handed people. It would make more sense to have this on the main cable before the split.
The obvious fix is for some third parties to make a cable with an inline control and a headphone socket. The problem that introduces is that the combined cable will be too long, and the position of the control in that length of cable might not be ideal. Of note, the last pair of Sony headphones I bought came with a very short cable (about 18"), and an extension cable which adds another 2 feet.
Tuesday 10 March 2009
Touch based tablet from Apple.
Maybe.
Think iPod Touch, but with an 8" display. All the better to surf with. Won't be much thicker
Will be a Touch device. Will use the app store. Apps will be full screen. Will not have a desktop.
Think iPod Touch, but with an 8" display. All the better to surf with. Won't be much thicker
Will be a Touch device. Will use the app store. Apps will be full screen. Will not have a desktop.
Monday 9 March 2009
Am I writing Java in Python ?
That's what's bugging me today. Or rather Am I writing is like an Ada programmer would write Java ? It's going through too many filters.
It doesn't really matter, but I've been writing stuff as methods of classes, and maybe they could just be functions. I suspect my code is 4 times the size of a 'proper' Python programmer's code.
I've never used a tuple. I'm using dictionaries, but I fear not in a good way.
I want to overload _init_ all the time.
On the other hand, I'm starting to slip into Test Driven Design. I'm mostly writing unit tests for some code I'd already written, which is to support some functional tests that I'm automating. I had three levels of classes, and at the highest level, it was more of a sketch than an attempt to get it right. Once I started writing and running tests, it all got fixed up and fleshed out. Maybe I'll start with some unit tests tomorrow and then write the code.
It doesn't really matter, but I've been writing stuff as methods of classes, and maybe they could just be functions. I suspect my code is 4 times the size of a 'proper' Python programmer's code.
I've never used a tuple. I'm using dictionaries, but I fear not in a good way.
I want to overload _init_ all the time.
On the other hand, I'm starting to slip into Test Driven Design. I'm mostly writing unit tests for some code I'd already written, which is to support some functional tests that I'm automating. I had three levels of classes, and at the highest level, it was more of a sketch than an attempt to get it right. Once I started writing and running tests, it all got fixed up and fleshed out. Maybe I'll start with some unit tests tomorrow and then write the code.
Subscribe to:
Posts (Atom)
Posts
