A very interesting interview of the creator of Clojure, Rich Hickey, by Michael Fogus, the co-author of Joy of Clojure1.
If you appreciate this interview, Rich's talk about Value, Identity and State is a must-see for anybody interested in computing and software languages (no knowledge of Lisp or Clojure is required).
This tool is a good idea to find original colors for Web design.
It is also one of the best use of node.js I have seen. I just have one nitpick: I don't understand the fascination with using the hash-bang and what it brings to this kind of web app instead of using Plain Old Stupid URLs...
Interesting move from Apple for the release of Xcode 4: free for registered iOS and Mac developer and $4.99 / 3.99€ on the App Store.
On my spare time, I have been using the various beta releases of Xcode 4 for Mac/iOS development and I really enjoy the streamlined experience.
For Java development, I use eclipse that I know from the inside out after doing a lot of plug-in development some years ago. With every release, eclipse has become more powerful but also more complex and I have not noticed an increase in my productivity.
With Xcode 4 (single window, built-in Interface Builder, Git support with Time-Machine UI, iTunes-like status), Apple developers have managed to simplify the UI, streamline the experience and increase my productivity.
Kudos!
Next week, I will talk about HornetQ and Messaging at the French mediterranean JUGs.
The first talk will be at Marseille on Thursday 2011/03/10 and the second at Nice on Friday 2011/03/11. On the same days, Arnaud Simon from Red Hat will also present AMQP and Qpid.
My talks will be about HornetQ & the Web, how HornetQ embraces the Web and offers messaging features on top of Web technologies (REST, HTML5, etc.). It will also have a (brief) introduction to Messaging and JMS for developers who want to leverage messages for their application (Web-based or not).
See you there!
When nothing seems to help, I go look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before.
I first read this quote from Jacob Riis in an article about the way the San Antonio Spurs front office builds a perennial contender for the NBA championship.
I later learnt that Jacob Riis was a journalist and a social documentary photographer that covered and fought against the living conditions of the poorest New York citizens.
I sometimes think about this quote when I develop software. Every line of code, every commit is a blow at the rock. It takes many of them without noticeable changes before the rock is split and the software is finally released.
I want to have GPS data for pictures taken with my Nikon camera and I looked at different tools to achieve that.
At first, I was using Aperture's Places to manually locate the pictures but this is a long and tedious process. Sometime, I shot a picture with my iPhone (which contains GPS data) and import them in Aperture to geotag my camera pictures. But more often than not, I forget to do that and have to do it manually.
I could add a GPS device to my camera directly but they are expensive, bulky, and drain the battery. Why buy another GPS device when I always have my iPhone with me?
After some research, I settled on using gps4cam and I am very happy with it.
gps4cam comes in two parts:
When I go outside and start shooting, I just need to run the iPhone app and start a new trip. The app supports multitasking, so I can exit the app, put the phone in my pockets and not worry about it anymore. I can focus on shooting instead.
Periodically, the app will capture my GPS location. The app is configurable and you can specify the frequency, to use GSM to triangulate the position instead of GPS (useful when abroad), etc.
At the end of the trip, when I am done shooting, I export the trip which generates a QR Code.
I then shoot this QR code with my DSLR. This picture contains all the GPS information captured during my trip. The fantastic idea of using QR codes is that there is no need to synchronize the iPhone and camera clocks: the QR code generated by the iPhone and shot with the other camera allows to know the clock difference between the two devices and deduce where the camera photography were taken.
The last step to do is to use the desktop application which reads the QR code and put the GPS data in the other pictures' EXIF metadata1.
Finally, I can import the pictures in Aperture or any other software and voila! My pictures are (almost automatically) geotagged.
The iPhone is simple, non-obtrusive and a steal at 1.59€ (or $1.99). It is a pleasure to use it and I haven't noticed a specific battery drain.
On the opposite, the desktop application needs more spit and polish. It is a Java application, I use it on my MacBook and it does not feel at home. The UI is not consistent with the OS (the progress is shown with a modal dialog window instead of a sheet or a progress bar) and it is too slow.
As I understand it, the desktop applications takes 3 steps:
I don't understand why it should take several minutes to perform these 3 steps (for a trip where I took only 40+ pictures). I suppose the performance could be improved by identifying faster the QR code picture. One way could be to let the user chooses the QR code picture (as I propose in the mock screenshot below by using an Image Well):
This would work fine if there is only one "trip" (i.e. one QR code) in the pictures but this will not work if there are many of them...
The desktop application also needs to improve the user experience. I put GPS data directly in the pictures on my SD card before I import them. Every time, the application asks me if I am sure to do that and I must confirm.
Instead, the application should let me check a box to say that I don't want to be warned next time and remember it. If anything bad happens, it is my fault, I explicitly told the application to not warn me anymore.
Pros:
Cons:
I hope that the cons will be fixed in future releases.
But as it stands now, I heartily recommend gps4cam to any iPhone user who wants to geotag automatically their pictures taken with another camera.
David Foster Wallace:
There are these two young fish swimming along, and they happen to meet an older fish swimming the other way, who nods at them and says, "Morning, boys, how's the water?" And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes, "What the hell is water?"
There is no better moment, at the dawn of a new year, to read again this speech from David Foster Wallace made all the more poignant by his suicide and be reminded about what is important in our lives:
The really important kind of freedom involves attention, and awareness, and discipline, and effort, and being able truly to care about other people and to sacrifice for them, over and over, in myriad petty little unsexy ways, every day. That is real freedom. The alternative is unconsciousness, the default setting, the "rat race" - the constant gnawing sense of having had and lost some infinite thing.
[...]
It is about simple awareness - awareness of what is so real and essential, so hidden in plain sight all around us, that we have to keep reminding ourselves, over and over: "This is water, this is water."
Happy New Year. May this year fill all lives with happiness and health.
Kyle Neath:
URLs are universal. They work in Firefox, Chrome, Safari, Internet Explorer, cURL, wget, your iPhone, Android and even written down on sticky notes. They are the one universal syntax of the web. Don't take that for granted.
GitHub URLs are a good example to imitate. I often edit them directly to switch from one project to another.
It is painful to see how some Web sites are not bothered by their ugly URLs.
Don't get me started on the URLs generated by some Web frameworks. I suspect they are ugly on purpose so that you can know which framework is used by a Web site just by looking at its URLs.
In the beginning was the command line, and then came the address bar...
Inspired by the beauty and form of classic cameras from the past, the FinePix X100 combines all the latest technical digital innovations in a beautiful, traditional chassis which oozes class and prestige.
The Fujifilm FinePix X100 turned heads at Photokina 2010 and it looks promising with its classic design and modern features. I am looking forward to holding one and seeing through its viewfinder.
In the mean time, Fuji's advertisement web site is worth reading to get some hindsights on the decisions made by the design team for the lens and the viewfinder.
A few weeks ago, I linked to James Clark's post about "XML vs the Web".
I concluded by writing that:
I believe than XML (and its associated technologies) will end up as an enterprise technology and a opaque content model (e.g. to save OpenOffice documents) and be less and less prevalent on the Web where HTML (with microformats) and JSON are better suited to represent data.
To sum up very broadly: XML for document, JSON for data.
Developers have been bitten by XML shortcomings for data exchange and moved to use JSON instead. It seems the benefits were (rightly) so convincing that there is now a pendulum movement away from XML and towards JSON for document representation. When all you have is a hammer...
Case in point: Apache Avro.
Avro defines a serialization system. It has very interesting features (rich data structures, binary format, schema inlined in the persisted files, etc.) and one shortcoming: it expresses its schema in JSON.
Here is an example from its documentation:
{
"type": "record",
"name": "LongList",
"aliases": ["LinkedLongs"], // old name for this
"fields" : [
{"name": "value", "type": "long"}, // each element has a long
{"name": "next", "type": ["LongList", "null"]} // optional next element
]
}
Today, I spent too much time for the simple task of writing a schema in JSON to represent a map whose values were arrays of strings.
The signal-to-noise ratio when JSON is used to represent a schema is different to XSD or RelaxNG but not better.
Simple schemas are simple to express but the signal-to-noise ratio increases tenfold with the complexity of the schema. Funnily enough, XML Schema have an advantage here: they are very complex for the simplest schema but their ratio increases linearly with the schema complexity.
I don't think JSON is well suited to represent a document schema. A DSL is a better tool for this. For example, Google Protocol Buffers uses a simpler format to define their schema:
message Person {
required int32 id = 1;
required string name = 2;
optional string email = 3;
}
I have not used protocol buffers enough to see how it changes with schema complexity but, at first glance, I expect it to remain more readable that a comparable JSON schema.
The difference between document and data depends on the use cases (you know it when you see it). But using JSON to represent a schema is a general step in the wrong direction to me. A DSL is a better tool for that.
After the "document representation" pendulum will have moved towards JSON too much and expose its shortcomings, I expect it to move again, away from JSON and towards DSL. Time will tell...