Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Re:Google Picasa 3 (Score 1) 259

My only quibble with Picasa is that it the Mac version doesn't have proper retina support yet (which you REALLY want in a photo app). I'm sure it will be fixed eventually.

But otherwise Picasa is fantastic. Very good at using the actual files and filesystem rather than a proprietary database.

Whatever you chose, make sure it encodes metadata IN the actual file or filename, so you can shove a subset to whatever other app or platform you like and it will tag along with no process required. Given the choice, in-file is better than filname, so that sync tools can match up different revisions of the same image.

Submission + - Poll: Do you worry about the singularity?

famebait writes: - No, it's bollocks
- It is inevitable eventually, but so are lots of things
- Sure, I expect it to become a real problem in my lifetime
- It is already happening
- No, it'll be fun.
- The singularity should worry about me

Comment Re:Almost makes me want to live there (Score 2) 77

Nope, the EU 'government' created the damn thing in the first place. The EU *court* struck it down.

OTOH, at least the whole scheme was out in the open, as opposed to the plain illegal surveillance in the US.

OTTH, who knows how many of the national goverrments are doing that as well.
There is also the neat trick (used by the UK among others) of turning a blind eye to, say, US surveillance of european citizens in return for access to the data. That way noone is offiically spying on their own citizens, but the net result is the same.

Comment Re:Minimise state (Score 1) 373

No, I love objects.
But language features should be used where they bring value, not randomly because they're there.

First of all, I have no problem with immutable stuff, I don't even consider that state.

Mutable object state is fine too, as long as it in fact reflects the behaviour you're modelling. But it should be pared down to that. Not absolutely religiously, but it is a good ideal to strive towards, right up there with high cohesion and low coupling.

Many litter their objects with instance variables that do *not* model the core state of the object at all, but rather serve as a 'nifty' way to pass data to functions with less typing. This makes the object more stateful, which just makes life more difficult all around: you need to know what has happened before to predict what a function will do, and so you depend on many more places in the code to be certain that any one piece does what it should. The logic becomes less readable, more bug prone, harder to alter without introducing bugs, and harder to verify with tests. And that's not even going into thread safety and parallelization.

Fighting all this is not fighting object orientation. If anything, some solution approaches can be considered *more* object oriented: if that param-list starts getting too long, rather than abuse instance fields as lazy params, group the params into sensible value objects, and you may find the new abstraction yields additional benefits: an avenue for better expressing function and intent, implementing validation and constraints, encasulating calculations and query logic from the client code where it only constitutes noise, into self-explanatory functions on the data object.

Comment Re:Minimise state (Score 2) 373

Caching is an optimisation that does indeed introduce state, and all the problems that comes with it in full.

Like all optimisation, it constitutes buying performance in exchange for increased complexity (of some sort). The cost of complexity is high, and the tradeoff should be qualified by a solid cost-benefit anaylis, and by extension pertain to a demonstrably real performance problem.

That said, I certainly accept that 'true' changing state can be part of a good model, and I don't consider that caching. Just keep it under control, make sure it actually delivers value, and don't sprinkle it around lightly.

Comment Re:Comment your damn code (Score 1) 373

I was intentionally overstating it a bit.

There are of course cases where comments are warranted, and properly justified optimizations may be just such a case. The others also usually fall under the broader umbrella of "exceptions" to how things might normaly be done. Just don't use it as an excuse to make the code less clear than it could be given the perfomance constraints, and beware of premature optimisation, which is a prime cause of brittle and unreadable code, with frequently no real benefit to offset the cost.
And always consider if you could say some of it with code too.

As a general rule, though, I still think it is wise to keep in mind that since the comment is not executed, there is no guarantee that it reamains correct, if ever it was.
I sometimes make a hobby out of trying to find at least one error in every comment I see. It doesn't always pan out, but tre percentagewhere it does is both staggering and frightening - I warmly reccommend the practice to everyone.

A good supervisor can step on your toes without messing up your shine.