WWDC is over and we are left with the latest and greatest toys to try. One of the most amazing news comes in the flavour of a brand new development language called Swift and the ability in Xcode 6 to play with it in a simple and accessible way. This is called Xcode playground. With this new feature it is super easy to write and test code without having to create a new project every time. I have been developing for a decade and each and every machine I got had at least one folder called tests and there was nothing to do with TDD in it!
Anyway, the ability to write some test code is only one of the interesting features of playgrounds. Far more intriguing is the ability of writing documentations that contains some example code that can be run and changed on the spot. As I see it every github swift project in the future will have a README file as well as a playground one. This was the first intent when I wrote MarkdownToPlayground an utility written in swift to convert markdown files to playground documentations.
In order to achieve that I had to understand how playgrounds work:
A playground is a a bundle directory which contains all the files that are needed for running the playground itself. Specifically you can find:
That’s an easy one, is naturally the swift file with the source code you want to play with.
This is the folder that contains the
HTML and the
CSS files that are rendered in between the swift source code. The
HTML files contains not only the tags of the content section but full pages representation, so even if there is only a single title on top of your swift code that would be incapsulated inside an
body tag - and an
head as well. I didn’t play too much with the
CSS to see how far can be pushed, however there seams to be a minimum requirement on the
section top and bottom padding otherwise the HTML documentation seams to be rendered on top of the swift code. Finally of course, a reference to the CSS file need to be imported in all the html header files.
This is an
XML file format containing the reference and the order of all the pieces of documentation and swift code that have to be rendered on the playground. It will look something like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <playground version='3.0' sdk='macosx' allows-reset='YES'> <sections> <documentation relative-path='section-0.html'/> <code source-file-name='section-2.swift'/> <documentation relative-path='section-2.html'/> <documentation relative-path='section-3.html'/> </sections> <timeline fileName='timeline.xctimeline'/> </playground>
This file is not present at the beginning, nor is its reference on the contents.xcplayground file. It will appear as soon as the playground get modified by writing code into it. As a result of playing with pieces of code on the playground the swift files will be duplicated and a reference to the original file kept.
Working on the HTML and CSS for a custom playground could be quite a frustrating experience. At the moment of writing XCode 6 is not production stable and further more a change on the HTML/CSS source will not automatically trigger changes to the playground. The solution seams to be to close and reopen the playground file altogether. However there is a way to trigger the playground refresh by opening the Project Navigator
(cmd + 1), adding any other file to it and then switching between them.
At the moment of writing there doesn’t seam a way of importing external classes or frameworks to the playground. Sam Marshall and Boris Bügling are trying crazy things to
dlopen frameworks inside it but with no easy solution.
Very recently Marco Arment released his news stand app the-magazine with the clear intent of selling articles on subscription leveraging his tech competence as well as the one of many others in the tech community - Guy English, Jason Snell, Alex Payne, and Michael Lopp in the first issue alone. It seams odd to pay for articles in the internet age, and this is especially true for tech articles, so why Mr. Instapaper decided to go this way? If you know Marco Arment, either because you read his blog or listen to the 5by5 podcast he hosts, the path he chose makes a bit more sense. Why? I guess because it removes complexity from the business model and it is more transparent with users.
Here it comes the theory: If you pay for the contents you are the user and the customer. If you don’t pay, revenues are generated by sponsors or ads, at which point the customer is the sponsor and the users are just eye balls. From the publisher perspective, this massively complicate things as now he/she needs to balance attentions between those two entities. Now balance is the tricky and deceptive part of it. If the user is not the customer with interest on the article, the article itself becomes a tool and not the product, so effort in the form, or precisely the better form, is put instead of the content. You can argue that good writers keep producing good articles, but then nobody can escape from being polluted by the evolution of styles and formats. Text messaging and further more Twitter had changed the way people write. At the same level bloggers and writers drift slightly everyday to the format led by colleagues writers, which is not necessary driven by the content of what they write. And so on, shifting the balance at tiny bits.
So that is what I think is the idea from which Marco and Co. are trying to stir away. I agree with that, every time in my life I had the possibility to see behind the production curtains of the media machine, be it a website, paper, radio or TV, I always felt that sense of being part of a scam, that somehow all the professional work that was driving so many among me was mislead to the wrong effort of squeezing another ad in instead of creating a better user experience. A penny for every time I heard the sentence “you know, advertisers pay the bills/your salary!”.
I think this is a noble effort, maybe it will not work, but it will be still worth failing trying. Marco itself writes in the first editorial “If it doesn’t turn a profit within two months I’ll shut it down.”. Let’s hope not.
I know it is wrong to put NSLogs everywhere in the code, as they usually just clutter the console log at the point of losing its purpose (or at least part of it). Sometimes however you just want have an easy way to get some feedback in the order of: Is this method even being called?
Well, to do that I device a macro which is printing not only the classic log text but also from which function it is coming (in the style of [Class method]) and the line on the file.
#define MYLog(err) NSLog(@"Log: %s (line n' %d)\n%@", __PRETTY_FUNCTION__, __LINE__, err)
Unfortunately __PRETTY_FUNCTION__ is not defined in C++, in which case you are better off with something like this:
#define MYLog(err) NSLog(@"Log: [%s %s](line n' %d)\n%@", __FUNCTION__, __FILE__ __LINE__, err)