Of course, not all my books are in Delicious Library yet. Specially since Amazon doesn’t carry most of my books in Spanish. But this is, anyway, a representative sample.
]]>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.
]]>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?
]]>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.
]]>As opposed to previous releases, there’s no competitive upgrade from previous versions or from Parallels. The price for everyone is going to be $50 (for a limited time, then it’ll go up)
I have used both Fusion and Parallels and, from my POV, Parallels slows down more the performance of the rest of the Mac. If you’re only going to be on the virtual machine it‘s not so important but, if you try for example to develop a web app on the Mac and test it on a virtualized Windows, the development task will be easier if you’re hosting the VM with Fusion rather than on Parallels.
]]>Octopress also has niceties for hackers, like powerful code embedding options. It’s still a bit difficult to blog from a smartphone, but that is just a matter of time, in my opinion.
So, over the following days, the archives will be markdown-ified and the comments will be enabled. But let’s mark today –a day almost, but not quite, entirely unlike any other in the year- as the day of the reboot.
]]>I will let the old domain expire, as I’m not interested in it anymore, and will set up redirections so that people looking for the old web pages, or sending mail to my old addresses can find me meanwhile. This will cost me in google rank, but I don’t care particularly since the low posting frequency had made it already low anyway. At least I won’t be getting spam for a while… I hope.
I think this new name more accurately reflects my identity and personality, and while it clearly marks me as a geek (as I can’t pass for a Saint Helena citizen), it also brings the opportunity of starting a fresh stage.
]]>I’ve enjoyed my stay at Polymita. I was currently in a support analyst position and, while not having the glamour of R&D or the hectic pace of the operations department (which I’m not sure I like anyway), it was rewarding all the same because everyday was different, I didn’t know beforehand what would the cases be like. But lately, with the product being so stable, my mad skillz were going unused (and please excuse my hubris, that’s how we geeks are). I hadn’t planned to leave or anything, but I was offered this new position last year and my inner engineer started to see lots of potential directions this tech could go to. Even so, at first I didn’t clearly see the way the technology could be monetized (that’s what reading TechCrunch will do to you). I didn’t hear back from this people until some weeks ago, where they presented me some changes that could make the product a hit. While I had figured out that my next job would involve Rails or Cocoa, looks like I’ll be sticking with Java (for the time being at least) on this new company. Still, the development platform of choice in the new company are MacBook Pro’s, so there’s still hope. I could do some internal tool with Cocoa or an iPhone client, who knows?
So, I decided to switch jobs in this crazy economic climate. I’m abandoning the stability and job security that Polymita provides me and diving head first into the dangerous waters and stressing climate of a true web startup. While some people have commented that I must be mad, some others have complimented me, and I think this is a golden opportunity to learn first-hand all an entrepreneur has to know. If the progression holds, my next job could be on my own company and I would need this knowledge. And anyway, I’ll get to work on lots of interesting stuff, there might even be some parsing involved (making this site’s motto relevant once more).
It could also be that this idea flops, but then again, I’m not overly stressed by this possibility. After a handful of interviews looking for new staff, I realized how difficult it is for companies to find competent engineers. I know that I wouldn’t be on the dole for too long.
]]>Ok. That’s about it, I think. Let’s review this list in a year or so…
]]>Here is the first one: Dave Hill: Jedi Master
]]>This site is powered by Mephisto. The servers are hosted at Joyent (née TextDrive) and powered by Solaris.
]]>Unfortunately, some time ago the powers that be at Textdrive decided to limit the resource consumption of their shared accounts, and since then, rails applications on Textdrive are often killed due to their excessive memory usage (for values of excessive starting at 48MB). Since the blog is powered by Mephisto, a rails application, it often occurred that I had to abandon editing a new entry, or updating the design.
However, not all is lost. As it turns out, Texdrive is massively migrating their FreeBSD accounts to their shared Accelerators, powerful Sun servers running OpenSolaris, and with much broad resource limits. According to users who have completed the migration, the new servers fly!
So, this post is mostly to announce that, until my account is moved to the new servers, I’ll refrain from updating the blog. I hold a Premier account, so I’ll be in the first lot of customers to move, though I’ll still have to wait, since the order is alphabetical and my account begins with ‘v’. Please be patient and stay tuned.
Update 18/10/2007: If you can see this, it means I’m on the new server
]]>
Of course, not all my books are in Delicious Library yet. Specially since Amazon doesn’t carry most of my books in Spanish. But this is, anyway, a representative sample.
]]>I use the ruby from MacPorts (formerly known as DarwinPorts), so I can’t use the binary that one can download from RubyCocoa’s site, since that is for the ruby that comes with Mac OS X Tiger. If that were your case, just download the biinary, but be warned that Apple’s ruby is buggy.
Installing the bridge is as simple as
sudo port install rb-cocoa
The system will fetch and install the newest version available from the bridge. If a message like this appeared
Error: Target com.apple.activate returned: Image error: /Developer/Documentation/RubyCocoa/build.en.html already exists and does not belong to a registered port. Unable to activate port rb-cocoa.
it means that you already had the package installed for Apple’s ruby and in trying to install it, it finds some conflicting files (while they are installed in different places, some files do indeed go to the same place, such as documentation and XCode templates). In that case, you will have to use the following command to activate the port:
sudo port -f activate rb-cocoa
To check that it’s working, we’ll invoke the interactive interpreter:
$ irb
irb(main):001:0> require 'osx/cocoa'
=> true
rb_main.rb script has been created, that is called from the entry point (in main.m); and the RubyCocoa framework has been added as well. If we build and launch this project, we can see that it runs normally.
If we look closely at the generated code, we’ll see that main.m, instead of calling NSApplicationMain, is actually calling RbApplicationMain and passing it the script name as an argument.
The script, for its part, looks somewhat more complex:
require 'osx/cocoa'
def rb_main_init
path = OSX::NSBundle.mainBundle.resourcePath.fileSystemRepresentation
rbfiles = Dir.entries(path).select {|x| /\.rb\z/ =~ x}
rbfiles -= [ File.basename(__FILE__) ]
rbfiles.each do |path|
require( File.basename(path) )
end
end
if $0 == __FILE__ then
rb_main_init
OSX.NSApplicationMain(0, nil)
end
The first thing the script does is require the Cocoa libraries (for Ruby). Then defines a function, rb_main_init, that is called if the script it’s the same as the one that was passed as a parameter, proceeding then to call the method NSApplicationMain, which loads the NIB files and begins the main Cocoa application loop.
What does this function do? It iterates over the package (the bundle) files, looking for all the ruby scripts within, and require them all, presumably so that they are available before being used from the application.
Having seen this, we can proceed with the application, launching Interface Builder and defining the interface, as explained in the book. Once the main application window is created, we are expected to define a class Foo with an outlet and an action, and then have XCode generate the code for that class. But XCode does not yet generate Ruby code, so the only thing we can obtain from it is Objective-C code. I have done this in order to convert it to Ruby, but you can skip this step and use the following code:
#
# Foo.rb
# RbRandomApp
#
# Created by Victor Jalencas on 18/02/07.
#
require 'osx/cocoa'
class Foo < OSX::NSObject
ib_outlets :textField
def generate(sender)
end
def seed(sender)
end
end
Now we’re ready to instantiate Foo. If we look at the Connection inspector, we’ll see that there is an outlet, which is there thanks to the class method we used to declare it, ib_outlets (which is, actually, an alias to attr_writer). However, there isn’t yet a method for declaring the actions, so that our only course of action is adding them by hand in Interface Builder. I’ve heard rumors that it will soon exist such a method, though.
Next, we’ll connect the outlets and actions as normally. Then it’s just a matter of implementing the methods we had declared:
#
# Foo.rb
# RbRandomApp
#
# Created by Victor Jalencas on 18/02/07.
#
require 'osx/cocoa'
class Foo < OSX::NSObject
ib_outlets :textField
def generate(sender)
generated = (rand(100))+1
@textField.setIntValue(generated)
end
def seed(sender)
srand(Time.now.to_i)
@textField.setStringValue "Generator seeded"
end
end
If we build and launch the project now, we’ll see that it works perfectly. Where in the original code we would have called C functions (random, srand and time), I have now used the ruby counterparts.
We’ll also see that the outlets are used as instance variables, and that there’s no need to convert ruby strings to NSString (that is one of the few automatic conversions RubyCocoa offers us)
To finish the example, we’ll add the awakeFromNib method:
def awakeFromNib
now = OSX::NSCalendarDate.calendarDate
@textField.setObjectValue now
end
And with this, the application is finished. We could run the Ruby and the ObjC applications side-by-side and we’d get the same results, save for the fact that in Ruby, if you don’t seed the random number generator, it’s by default seeded with a value that depends on the time and the PID, while the C function random does not and will always repeat the same sequences if it’s not properly seeded.
That’s why I’m starting this new section. I’m gonna follow the exercises in Aaron Hillegass’ book, Cocoa(R) Programming for Mac(R) OS X
Even better if, in doing this, some reader can benefit from it. Likely, having the book will be a requisite to follow the posts effectively, but I will try to make them self-contained. Let’s see how I fare…
]]>Lately, I have been interested in giving microformats a spin, so I have launched SpotSpotting, a site where TV commercials are reviewed (as if they were movies), and am preparing another site for reviewing and recommending restaurants worldwide.
I hava also started a new section, Choclit, in which I try to learn Objective-C and Cocoa in public, sprinkiling in some Ruby and C# so as to make it more palatable.
]]>It’s a bit annoying somehow. I migrated to mephisto because I suspected typo’s bloat would have something to do with the problems, and now I am missing some features that mephisto doesn’t yet implement (I don’t doubt it will, mephisto is very young still). And yet, I won’t go back, since I’m interested in hosting multiple sites with a single instance of whichever rails app will do that, and just now, only mephisto does it. If it stays stable for one more day, I’ll deem the issue –closed– vanished and try this feature (yes, I haven’t really tried it yet)
]]><macro:flickrshow set=”72057594082061447” />
]]>