Posted 9 months ago
Posted 1 year ago

A reverse take on software design

Posted 1 year ago
Posted 1 year ago

the-magazine app, the newspaper underdog

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 EnglishJason SnellAlex 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.

Posted 1 year ago

Taken with instagram

Posted 1 year ago


John Cleese - “A Lecture on Creativity”


John Cleese lectures on the topic of creativity.

Per Back to Work #62: Cultural Molasses.

Seriously: this wonderful video has had a huge impact on how I think about creativity. For years.

Unfortunately, the copy I’ve had and repeatedly enjoyed “fell off the back of a truck,” so I had no way to share it.

Now, (via danforth), I can finally share and highly recommend it.

And, I really, really do encourage you to watch it. Really. All the way through. It’s just terrific.

Extremely connected with something a bit newer by Jonah Lehrer:

Posted 1 year ago

Fixing my NSLog() habit abuse. Sort of!

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)

Posted 1 year ago

@Tommaso | .Questo non è un Blog.: 10 validi motivi per cui le infografiche sono un male assoluto di Internet (peggio dei gattini!)


Colto dal classico raptus di psicologia inversa dopo il post di gluca, ho deciso di mettere nero su bianco le motivazioni che guidano la mia idiosincrasia per ogni tipo di infografica. Quelle enormi immagini colorate che raccolgono, nella maniera scientificamente più scomoda ma…

Posted 1 year ago

Unit testing while interacting with blocks

Unit testing is brilliant, it automates things and give you the peace of mind that nothing is going to break in the code you write - at least nothing you know of!

Another brilliant thing are blocks. Since their introduction in iOS4 I started to do a massive use of them; they just make everything more tidy and they solve some implementations that would be otherwise almost impossible. Also they make easier to work with background threads.

Unfortunately blocks with background capabilities do not work well with unit tests, at least out of the shelf. This is happening specifically for the reason that the assert methods implemented inside the block may not even being called because the entire suite of tests got the end before it.

As solution for my projects, I have defined a parent test class from which all the other test classes inherit with the only intention of having a boolean attribute and then I have a while loop which is checking for that boolean in the tearDown method. Inside the block I change the boolean to YES and in the next runloop the tests exists.

By default I set done to YES in the setUp method so for all the tests that do not use blocks I do not need to bother about the done variable.

Here is the code:

Parent Test Class:

#import <SenTestingKit/SenTestingKit.h>

@interface MainTests : SenTestCase

@property (nonatomic, assign) BOOL done;



#import "MainTests.h"

@implementation MainTests

@synthesize done;

- (void)setUp


    [super setUp];

    done = YES;


- (void)tearDown


    while (!done) {

        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:   [NSDate distantFuture]];



    [super tearDown];



Another children Test Class:

#import "MainTest.h"

@interface AChildrenTests : MainTests

- (void)testFeeds;



@implementation AChildrenTests

- (void)testFeeds {

    self.done = NO;

    [AClassWithBlocks collectionForUserName:@”username” completed:^(id data, NSError *error) {

        STAssertNil(error, error.description);

        STAssertTrue((data && [(NSArray *)data count] > 0), @”Feeds shouldn’t be nill or empty”);

        self.done = YES;




Posted 2 years ago

Create an Injection testing environment through the definition of custom C flags

As iOS developer I do tests most of the code I write, but sometimes, in order to test a piece of functionality you have to recreate the environment of the user actually using your app for a certain period of time. This is true for most of the apps out there and even though the majority of the bugs would show up at any stage of the user iteration for other is necessary just, well, use the app. I am thinking about components like charts, multi user controllers etc.

Of course you can and should use testers to do that, but sometimes is easy to lose yourself in all the back and forth between you and the tester until the bug is really fixed.

In order to avoid this problem there is a good programming technique called data injection, where you programmatically populate your application with some fake data in order to be able to check the result of some operation ready after the app has been compiled and installed.

What I have found fascinating is that in Xcode you can create a specific target for this purpose, or better you would duplicate your active target, rename it in something more suitable like “Your App name Injection”. Then select your newly created target, go to the Build Settings, search for Other C Flags and enter something like:


Once you have created your flag everywhere in your code you can then create conditional pre-compiled statements like:


    //your injection code here


Now, only if you compile and run the Injection target this conditional statement will be compiled, leaving the application save for all the other targets - as it should be.

As precaution it is wise to add the C flag only to the debug option, so that it is actually impossible to submit the application with the injection bit.