Ad break.

Recommandé par des Influenceurs

Strange Safari behaviour...

For a few weeks now my Safari has hung on startup. Spinning beachballs of doom and everything. I figured it was something I'd done to it (I'm tracking the WebKit nightly releases and tend to hack around a bit with my OS) but never really had much time to figure out what exactly was going wrong.

Until now. I knew it was hanging on opening a file (I assumed the PubSub database and had tried deleting that to no avail), but this morning I decided that the PAIN of using firefox was too great to not spend half an hour fixing Safari.

After a bit of tinkering with lsof and gdb I discovered a couple of caches that I didn't know about on my machine these were..

/private/var/folders/gc/gcMtdPw4FY4KstxwBSOd7U+++TI/-Caches-/com.apple.Safari/Cache.db

and

/private/var/folders/gc/gcMtdPw4FY4KstxwBSOd7U+++TI/-Caches-/com.apple.Safari/SafeBrowsing.db

They were also huge. I've no idea what they were but I do know that when either Safari or Webkit starts up it tries to read them and on my machine this was causing it to hang (perhaps they were corrupt).

Anyway, the fix was to delete them (and the pubsub database for good measure). Steps below.

1. sudo rm -rf /private/var/folders/gc/

2. rm ~/Library/PubSub/Database/Database.sqlite3

After these two steps both Safari and WebKit work and I'm finally out of Firefox purgatory. I hope this comes in useful if anyone else has Safari hanging on startup.

Yahoo! BOSS and Java

A while ago we had to use the Yahoo! BOSS API to search and link to news stories related to various topics.

I had a quick google (no point re-inventing the wheel) but I couldn't turn up any code in Java for this, there's plenty of Javascript/Python/Ruby/etc. code. But we needed to use Java in this instance so I quickly dashed out a simple wrapper for BOSS.

A while later, it was tidied up (a bit) there's still some rough edges, but it's working perfectly well for us.

And yesterday, we decided to release it under the Apache 2.0 License so that in the future anyone Googling for Yahoo! Boss and Java should have something to help.

The buildable source is available at http://code.google.com/p/javaboss/

At the moment it has dependencies on org.json.jar and junit.jar which are included in the repo, I expect at some point we'll move those out and either use maven or ivy to resolve this sort of thing.

This keeps coming up.

Petition to stop software patents in Europe.

I don't think it'll ever go away actually, introduction of patents would probably make a few people and corporations happy and a lot of lawyers very rich.

Worth reading the studies that point to the conclusion that this is a pretty bad idea before signing :)

I wish I had a screencap of this...

I've got Bloomberg buzzing away in the corner for a bit of company (freelancing can be lonley) and they just flashed this across the screen.

Bloomberg INSIGHT : Global trade slowdown bad for growth.

Is that really so very insightful? Do traders still pay a few thousand a month for terminals to recieve helpful updates like that? Perhaps I should ditch this coding lark and consider a career in financial journalism.

Watch out where the huskies go...

This is interesting.

The iPhone Dev Team are largely responsible for the genius software that jailbreaks and unlocks iPhones. I use it because I live in a fairly remote region of France with intermittent mobile coverage and had a UK iPhone. So, rather than paying international mobile rates or waste time and money signing up for an Orange (France Telecom) deal it was just easier and cheaper to get a pay as you go sim and run pwnagetool (the software that removes the carrier restriction on the phone).

Works perfectly.

Anyway, a few people have taken the freely available work of the Team and packaged it up as an 'unlocking solution' and are selling it. Selling it for £50 no less! This, despite the iPhone Dev Team not accepting donations and having a license clearly stating that the code is freely available but should NOT be used for commercial purposes.

It's an interesting case because I presume the offender (I won't give them the google karma of linking to their site) is assuming that as it's a legally grey area they won't have any recourse. However, I'd argue that the Dev Team have a pretty good case and here's a couple of reasons why - I'm not a lawyer though, just an interested geek...

1. As far as I know unlocking phones is not illegal. As long as you fulfil your contract with the carrier, the phone is not stolen and you legally connect to a new network I don't think there's a problem. Unlocking phones for profit may be an issue, but that's not the fault of the software and is more likely to count against the person selling the software, not those giving it away.

2. The Dev Team can prove that they wrote the software and released it under a non-commercial license and they can also prove that the people that stole it have hardly made any attempt to obfuscate the fact. So, they can't say, for example, that they looked at the source and wrote their own version and even if they could they'd still be on dodgy ground. In fact, all they seem to have done is hacked a few properties strings around and changed the odd copyright message.

3. If the Dev Team or users of the software have somehow violated any of Apples terms and conditions that's a separate issue and would be the case if you used the £50 (still can't get over that figure) copy of the same software anyway. So it's irrelevant to the case.

The Dev Team are looking for legal advice :

Also if there are any UK based lawyers or student lawyers that could help us with this, then please contact us at blog@iphone-dev.org of course student lawyers can’t give us specific legal advice, but even your informal opinion helps.

So if anyone who reads this can help, I'm sure you know what to do. Finally, I'd like to thank the Dev Team for spending their time and money hacking on this and I'd like to spend a little time frowning in the general direction of people who rip off their (and other open source) work for profit.

La Philosophie pour les Nul(l)s...

As the dark, cold nights are drawing in I've been throwing logs on the fire, sitting in a comfortable chair with a glass of Cardhu and thinking a little about null values work (or should work) in Java. For example, if you define a method as returning a String, conceptually speaking, what should it do? Should it return only String instances, or should it return either an instance of a String or null.

I've long been used to the way Java happily passes null around and have developed a hell of a lot of code over the years that checks for null, as I'm sure have most people. But, wouldn't it make more sense if the implicit contract of the return type specified by the method were adhered to?

Recently, in some cases, we've been writing what I guess you could call 'null-safe' objects (all fields pre-initialised and setters that don't allow values to be nullified). This on the face of it seems conceptually valid, the methods return what they say they'll return and there's a lot less null checking to do when using them. Objects written like this are ideal for e.g. sticking into freemarker templates as then the template designers don't need to care about checking whether or not values exist because they always do.

Problem solved?

Not really. There is an obvious conceptual difference between zero and nothing for a Long value, or between 'no string at all' and an empty string. And if you're going to 'protect' your objects like this, how do you signal that you've done so to other users of your API?

I think most people are comfortable with a certain synonymity between a null string and an empty string, but it gets trickier for other types (and let's not even get into primitives - which can't ever be null in Java). The problem seems to be that Java has no proper way of handling null other than throwing an unchecked exception when you accidentally encounter it.

Microsoft's venerable .NET has the concept of nullable types which (at least for value types, structs and enums) allows you to specify that a type can, infact, be null e.g. int? j = null; But this, with the exception of allowing nullable value types is little more than a syntatcially nice way of doing null checking (or, indeed the 'null-safe' object approach I identified above).

Is there a better way?

Well, it appears that other languages may have a more cromulent approach. Haskell, Scala etc. avoid the use of null (well, technically Scala does have null, but generally it's not used).

Scala prefers instead the use of a simple 'Option' monad that has two sub-classes 'Some' and 'None'. Option is type-safe, so you can have an Option of any type (but only of the type you define it to be). 'None' is essentially a type-safe null (a singleton object, like Nil in Ruby) and 'Some' is a holder for the actual value. Combined with Scala's filtering and pattern matching, we can explicitly exclude 'None' values from operations or act differently (insert a defult value instead, perhaps) depending on how we want to proceed. I'm no Scala expert, but this does seem a saner approach.

Another similar approach is taken by Objective-C, in which Nil is an object. The nice thing about the way Objective-C handles Nil (and objects in general) is that you can happily send messages to Nil and nothing bad will happen. Unexpected things may happen, but nothing bad :)

Oops *oops = nil;
NSLog(@"Oops is doing %@", [oops doSomething]);

This will probably, from memory, print out something like "Oops is doing (null)", not brilliant. But surely better than a runtime exception?

So, in short, I don't really know what the answer is here... In some cases you need to know about null, nil and empty values and in other cases you don't, that's a given. And you can, kind of, achieve this duality in Java but it's annoying that null itself is a special case. It's not an object, it isn't a proper type and calling methods on a null object throws a runtime exception. You could, I suppose, almost say that this approach was similar to Scala's, in that every java Object is implicity an 'Option', 'Some' is the value (if any) and null is synonymous with 'None' (except it's not type-safe etc. etc. etc.) and you do all the pattern matching and checking yourself and if you don't, or get it wrong the whole thing blows up in your face.

I can't help thinking there could have been a cleaner way to handle all of this.