Apparently TextDrive finally shut down and they didn’t even bother communicating to their customers. I’ve switched to Amazon S3 in haste. Will try to get backups of the old content there :(
This week, O’Reilly ebook storefront welcomed Packt Publishing, the british publisher of technical books to their virtual aisles. Coincidentally, they asked me to review their latest RubyMotion book, RubyMotion iOS Development Essentials, which I will gladly do. They generously provided me with a review copy and I will be reading it during my vacation, and post the review when I come back, but you can follow my progress, as always, on Readmill. Be sure to follow me there to get valuable insights on this and many other books, both technical and fiction.
It is again that time in which I announce here on my blog that I am changing job. I think I came to a point in which I wasn’t learning much new things, and I was starting to not see the point in staying at ISIS.
So, I looked around a bit. And, possibly in part because I was working until now for a foreign company and became spoiled, and possibly because of the Spanish crisis, I couldn’t find a decent iOS development job in Barcelona that had a decent salary. So I started to look for foreign companies that would allow me to work from Barcelona.
To tell the truth, for all the talk that you hear about how easy it is in XXIst Century to work remotely –perhaps I listen too much to the Wide Teams Podcast– I couldn’t find many companies interested in hiring a remote iOS developer. Perhaps I wasn’t searching in the proper way, I don’t know.
Finally, just a few days ago, I learned about a position doing iOS development for Stella & Dot. They are setting up a remote team in Barcelona, just a mere 10 minutes from my current workplace. I applied and before I knew it, I landed the job and I am starting next month. I get the benefits of working for a remote company, but I don’t do it alone, there is an office where all the team works from.
The position is in fact, as an independent contractor, since they have no fiscal presence in Spain yet, so I will become a freelancer and invoice the US company directly. This is all new ground to me, but I’m excited about the prospect.
If you don’t know what is it that Stella & Dot does, check this couple of articles:
My team will be developing the mobile app that will allow stylists to sell and share in social networks with even less friction.
I am very excited about this job and can’t wait to get started! It is true that I will miss the best team that I’ve ever worked with, but I’m sure we’ll keep collaborating either in open source projects, beta-testing each other’s apps or in any other ways.
I already published this on coderwall so might as well publish it here:
In order to be able to log in to a remote server over SSH without needing to provide the password everytime, you need to generate a couple of keys, and then copy the public one to the server.
Since this is a process that you only do once (per server, that is) and is prone to errors (because you need to remember the right key file, set the permissions right and so on), it is better to use the
The simplest way to use it is as follows:
$ ssh-copy-id remoteuser@remoteserver
This will copy your public key file (by default,
~/.ssh/id_rsa.pub) to the remote server
~/.ssh/authorized_keys file, creating it if it doesn’t exist, or appending to it if there are already existing keys.
If you need for some reason to provide a different key, just pass it on with the
There is a site which I discovered recently, which lists common UI patterns for iOS apps, as implemented by several popular apps. It is a great resource for inspiration and for reference. It is made of screenshots (so, no animations) but for most patterns this will suffice. Go see it at pttrns.com
I learned recently that Red Hat Inc. acquired one of my former employers, Polymita Technologies, as a form of acquiring the BPM technology that they developed.
Congrats to Erik and the rest of the team, for what this means as validation of the good work done.
A few days ago, former Apple engineer Laurent Sansonetti released RubyMotion to the world. RubyMotion is a MacRuby implementation and toolchain for iOS, with a few key differences that allow for apps developed with it, first, to work; and second, to be allowed on the App Store.
The technical differences between RubyMotion for iOS and MacRuby for the desktop lie principally in the memory management (while MacRuby uses Garbage Collection, RubyMotion uses something similar to ARC) and the compilation model (MacRuby is interpreted, though it can be compiled, while RubyMotion is all statically compiled, that is, it generates a monolithic binary that can run on iOS). Apart from that, the syntactical rules are mostly the same, so any knowledge you have about MacRuby will certainly be useful when is time to work with RubyMotion.
I purchased RubyMotion a couple of days after its release, when I had had opportunity to read about it and considered that it might be useful to me. I haven’t had the opportunity to play too much with it yet, but I already have formed a preliminary opinion and I’d thought I’d share my thoughts here, and perhaps see how they change after I play with it a bit more. Specially since RubyMotion is evolving very rapidly, so some considerations need to take into account the moment they occurred: for example, when initially released, the interfaces for iOS apps were expected to be coded purely programmatically, there was no support (other than using
ibtool for compiling them manually) at all for using Interface Builder to design them. Nowadays, the
Rakefile already takes care of compiling them for you.
I have a background in Ruby, even though I haven’t used it professionally as much as Objective-C. I was also eager to learn how to use Cocoa from Ruby, first with RubyCocoa, and later with MacRuby. Part of my motivation for doing so was partly to avoid the steep learning curve of Objective-C and Cocoa, and partly to be able to use Ruby’s natural expressiveness and terseness.
Nowadays I know better. No matter whether you develop in Ruby or in Objective-C, the hardest part is getting intimate with the Cocoa frameworks. There’s no way around it. The way the Cocoa framework is architected, you have two ways to work with it: swim upstream, or go with the current. If you go with the current, easy things are easy and hard things are still hard, but doable. If you pretend to go against the current, you’ll have a hard time just to make the simplest of things.
And so, working effectively with either MacRuby or RubyMotion requires knowing the Cocoa frameworks. Now, this means you either leverage your existing knowledge of them with Objective-C, or you learn on the fly how to use them with Ruby. And my opinion is that the later will be harder, since most of the documentation and examples are created for Objective-C, and the syntax changes Ruby has made to accommodate Objective-C’s method signatures makes it difficult even for (or specially for) experienced rubyists.
So, my guess is that RubyMotion will be more useful to accomplished Cocoa practitioners, which may find Ruby syntax and terseness very accommodating, than to expert rubyists which will find themselves a little disoriented, moreover when the gems they are familiar with are not available in RubyMotion, and they have to learn the new Cocoa ways of getting things done.
I am sure a lot of rails developers will flock to this new platform, since no doubt their customers are demanding mobile clients for their existing apps, and they find themselves at ease within the confines of the higher design standards of Apple. But I’m afraid that, finding themselves in unfamiliar territory, they’ll have to fall back to snippets, recipes and library wrappers (training wheels, if you like) created by the minority among them that already do develop for Objective-C, just as it happened when Ruby on Rails exploded in popularity. And some of them won’t find the effort worth doing in learning the Cocoa frameworks, and thus deeming RubyMotion inadequate for their development needs, when it is more than adequate for most kinds of applications.
My advice? If you have a Mac and are already familiar with both Ruby and the Cocoa Touch framework, and are willing to pony up $150, give it a try. If not, try first with MacRuby before paying for a tool that you won’t use.
Personally, I already have an app in mind which could leverage the expresiveness of Ruby code and simplify what could potentially be lengthy and cumbersome (and error-prone) Objetive-C code. But that is the matter of another post.
Last time I talked about my day job, it was in 2009, and a few things have happened since, so I think an update is in order.
So, I taught myself how to do it (actually, I had started learning Cocoa when I got my Mac, but wasn’t really serious about it until Apple released the iPhone SDK), and on the summer of 2010 I saw an ad about a company looking for iOS developers. I interviewed there and finally was hired, without actual working experience – though I passed a coding test. I started on Puck Solutions on November 2010.
Being able to spend my full work day working on nothing but CocoaTouch really did wonders for my skills. The very first few days I was still using cheat sheets, but I was soon on top of the learning curve and speeding ahead. At Puck Solutions I did mostly client apps for their cloud software offerings. I learned the ins and outs of the Core Plot framework, among other things, and of the (crappy, in my opinion) Force.com API client library. Thankfully, I was able to use the RestKit library instead. Still, Salesforce OAuth implementation is as backasswards an implementation as they come :(
Anyhow, client work for the iPad apps I was doing dried up, so I was made redundant on October of last year. After a few weeks interviewing mostly with 4 companies, I joined ISIS Papyrus on December of last year. The company is headquartered in Vienna, but they have a R&D lab for mobile development in Barcelona. Two of my pals from the Barcelona NSCoder Nights already worked there, so this was an incentive for me in deciding to join the company, since the kind of development work they talked about in the interviews didn’t seem too enticing at first: it’s mostly implementing the iOS version of a cross-platform widget platform.
However, I’m happy I joined for a few reasons. One of them is the working times, which allow me to spend more time now with my family. The other is being able to work with the aforementioned Cocoa devs, Jose Antonio, of 85% Cocoa fame (incidentally, one of the best Cocoa podcasts in Spanish language); and Guillem, one of the drivers behind the NSCoders España association, and our resident C++ guru.
In the month I’ve been working there, I’ve already stepped out of my comfort zone in a few ways. I’ve started diving into Objective-C++ and C++; and I’m working on a huge cross platform code base. I think I will be getting a ton from this gig, specially surrounded with such a team.
Anyway, that’s it for the update. Let’s see how it goes.
Yesterday, Tim Cook, Apple’s new CEO, announced the last device in the iPhone family, the iPhone 4S. It features a new dual core processor, a new GPU, a new camera, and a new antenna design. It will debut with iOS 5, which will be available for existing hardware starting October 12. And it will have an exclusive assistant app, Siri, featuring voice recognition, that is supposedly capable of understanding natural speech and carry on instructions.
The naysayers have been talking about disappointment. But, tell me about other phones that can do this:
Copyright © 2011 Apple Inc. All rights reserved. I just transcoded it to make it play in more browsers.
Of course, we’ll have to see if the voice recognition is as good as portrayed. And, non being a native English speaker, I’ll sure have problems using it (or, wait until Spanish is supported). But it is a technical feat nonetheless.
Siri used to be a normal app available in the App Store, which worked on all iPhone devices, not just the 4S. But it relied on external servers to do the processing of the natural language, as opposed to the new Siri feature, which while using Apple’s massive datacenter in North Carolina, needs a lot of RAM on the device itself to work. Apple bought the company and made the technology a feature of the operating system itself.
While I’m very happy with my iPhone 4, I’ll probably upgrade to the 4S, as my wife’s 3G is showing its age, and that way she’ll inherit my current one. And then she’ll be able to enjoy the features of iOS 4 (and 5) on adequate hardware. Also, being a professional iOS developer, it just makes sense to get test hardware, doesn’t it?
There’s a turmoil on the internet regarding Facebook’s lubed (frictionless) sharing and how it means that Facebook will go all Big Brother on you and be aware of each and every movement you make online. And no service exemplifies it better than Spotify, which recently started requiring that you connect your Spotify account with your Facebook one. So, everything that you listen to, everything that you search for (possibly), and every user library that you browse, will be sent to Facebook for later analysis and correlation.
I was already concerned about the attitude of Facebook regarding privacy. But this is taking it too far. This is downright intrusive. And Spotify’s actions are a big bet on their part. I was the one who always played devil’s advocate, advising people to get a paid membership in order to ensure Spotify’s viability in the future. So, it doesn’t surprise me that much that they’re now in bed with Facebook. They need to keep the money flowing from somewhere, and if conversion rates are not that great, well, they’re more or less justified on having done that. Spotify’s free and open users shouldn’t be complaining now, as they’re not paying users, so they get what they pay for.
But, as a premium user, this is really annoying. If Spotify had a bit of sense, (and Facebook policies had allowed for that, I’m sure they do not), they would not have this requirement in place for paid users. That could even improve their conversion rates. But they did not, and now the common sentiment among paid users is that of being betrayed. And that’s never a good feeling to foster in your client base: their support forums are raging with righteous users announcing the cancellation of their subscriptions. When I went to open the Spotify client yesterday, I encountered a popup that could not be dismissed, and that required me to connect to Facebook in order to use Spotify. Fortunately, the Spotify application uses the same permission system as the other apps in Facebook, so I could log in and deny permission to the Spotify app (which had it previously, so now they’re the worse for that). But I suspect frictionless sharing is still enabled, even if the explicit sharing is not.
As it is right now, I am considering accelerating the cancellation of my Facebook account –I barely use it nowadays, but would hate to lose contact with some school friends and relatives, after all it took to bring it back–. If that would mean the disruption of my Spotify service, so be it. That’s 10€ more I will have for iTunes, DVDs or books each month. I want to be the customer, not the product, and will gladly pay for that. But if you want me to pay for the privilege of being the product, you’re dead wrong.