top products

So, a few days ago I released Cards, a freeware application for the iPhone to manage credit card. Is really easy to use and has little features, I have mostly coded it for myself but then I’ve been asked to put it on the AppStore. So, I lazily posted it on the AppStore, without doing any webpage and stuff like that.

Worst decision ever.

Apparently, a lot, and I mean a lot of people thought about something which didn’t even cross my mind: that the application may call home and report data! Indeed, there was no good reason to trust “Michele Balistreri” (I was sure I used Briksoftware name, but whatever). Now I quickly setup a page and wrote this blog post in the hope to stop triggering paranoid alerts. Thanks to the (few) ones who decided to just trust Michele Balistreri and probably Apple’s review procedure. I hope those enjoy the benefits of the application.

For those of you wondering about the purpose of the application, I’ll just say one thing: I kept my PIN codes in my addressbook under strange names because I would forget them. Not only thats not secure, but I kept forgetting which card had a certain PIN, which created awkward situations in stores.

Today we released what we call Snapplr Beta 2. In practice we’ve been releasing many updates but we now have reached some important milestones. We have simplified the first start wizard, to avoid confusion induced by the “firewalled” status that would show up quite often (correctly, but it didn’t mean that Snapplr wouldn’t work).

Now, on Leopard, Windows screenshot include shadows and we have optimized performances in Area screenshots.

We have been receiving a lot of feedback this days. I’d like to thank everyone for their support and we’ll do our best to satisfy all requests!

Yesterday we released Snapplr’s beta. We thought 100 users would have been enough to gather enough feedback, and we surely wouldn’t get him in less than a week. It turns out we were wrong, there are already 200 registered users, and we think we will not pull the signup page too soon to allow more people to test the application.

Thank you very much for your interest in Snapplr!

Briksoftware is proud to announce that after months of work we finally opened the beta to our brand new tool Snapplr. Snapplr is the first product that Michele and I developed together.

Basically Snapplr is a total replacement for the system’s screenshot facilities. The only difference is that screenshots are instantly uploaded to Snapplr.com and the link is put on the clipboard. If you have a static IP and don#t want to use Snapplr.com, you can also host the images locally via the build in web-server. The images will be stored for 1 day currently, after that the images will be deleted automatically. We’re not sure about the time interval though, but typically you don’t need to share snaps that are older than a day.

Another very nice feature is the Live mode which allows you to choose an area, a window or a whole screen for capturing. The url is put on the clipboard and whenever you open this url it will take a screenshot and send it to the browser, perfect for showing someone what you’re working on without setting up a whole vnc session or what not.

The beta is limited to the first 100 people that sign up, so if you want to give it a try, go to snapplr.com and register

Press Release

This year’s Esug Conference (the 16th!!) is going to be in Amsterdam from 25-29th August.

The weekend before Esug is Camp Smalltalk, a meeting with others from the conference where you can exchange ideas, code together with others or just hanging out with other Smalltalkers.

This is, besides C4, one of the reasons to hope the summer passes by quickly :-D.
On the other hand there’s also a bunch of parties to hope that the summer doesn’t pass by too quick 😉

Anyway, I hope to see some of you guys at one or both of the conferences!

Karsten

Sorry for the bold title, but I’d like to clarify some issue that occurs in latest stage of application building: linking.

Static and dynamic symbol references

When you link your application, the Mac OS X static linker, ld tries to resolve (ie, find) every symbol you reference to in your code. This creates a table which tells the dynamic linker which symbols to bind to at runtime. What happens if you reference a symbol which the static linker cannot find? Build fails. This can happen if you reference symbols defined in loadable bundles or custom frameworks/dynamic library.

A common solution to this is to add the option “-undefined dynamic_lookup” which delegates the job of both finding and resolving references to the dynamic linker (dynamic linking happens at runtime). Although this is an easy solution, it can give many headaches. One problem with this approach is that any mistyped function name won’t result in a compilation error (the same is true misspelled variables and constants declared as extern) but will result in a crash at runtime. As the crash may not happen at launch time you may have an hard time spotting the problem.

Although we’ll see many ways to avoid having to leave symbol lookup to the dynamic compiler, the best way to handle dynamic lookup is to handle it programmatically were needed instead, following the direction found at this ADC article.

Avoiding dynamic symbol references

So here you can find a few quick tips to avoid dynamic symbol lookup where possible.

• If you are referencing symbol found in a dynamic library or framework, link to it using (respectively) the flags “-l” or “-framework”. If the library/framework isn’t available system-wide make sure that their install path is relative to the application bundle (usually @executable_path/../Frameworks for frameworks). If you only have the framework/library available in binary form, but you are allowed to redistribute it, you can adjust its install path using “install_name_tool”.
• If you are writing a loadable bundle, and reference symbols defined in the host application, use the “-bundle_loader” option (followed by the path to the host application’s executable) which will cause ld to search for symbols also in the referenced executable.
• If you are referencing symbols found in a loadable bundle instead, you have to look them up dynamically. In Cocoa you can usually do it through NSBundle. CoreFoundation also provides CFBundle-related functions for this task.

Compatibility and graceful degradation

If some symbols, referenced either statically or dynamically are not found at execution time, the application will crash. We might see this, for example, running an application using Leopard features on Tiger. What if we want to retain Tiger compatibility? We may conditionally reimplement some system provided capabilities or disable some features on the older OS. The Mac OS X linker provides an extremely classy way to handle this kind of situations through correct choice of SDK and Deployment Target.

A common mistake is to use the SDK of the oldest OS we want our application to run on. This isn’t generally a good idea and becomes a problem as soon as we reference symbols defined in newer versions of Mac OS X (ld will fail).

A better idea is to instead use the latest SDK and set the Deployment Target to the oldest version of Mac OS X you want your application to run on. This will cause the static linker to mark references to symbols not defined in system frameworks as of your deployment target of choice (but found in the used SDK) to be marked as “weak references”. Weak references are mostly like regular references, but if binding the symbol fails at runtime, the reference is set to NULL. This gives you a great way to check if a certain symbol is available at runtime and avoids nasty crashes (this does not work for selectors because they are handled by the objective-c runtime, you can check for those using respondsToSelector:).

For your information, weak references are created adding the __attribute__((weak_import) directive to a symbol declaration (usually to externs) but usually don’t need to declare them explicitly (the system frameworks have preprocessor directives to do that automatically based on deployment target).

In the last years we’ve seen many SCM trying to replace SVN (which in turn replaced CVS in many places). Git, Mercurial are two examples of that. I never really looked into them as they mostly sounded like “SVN with this” or “SVN with that”. 

Then I discovered darcs and I never went back. Sure, XCode has no integration with darcs, but one can live without that. What made me switch from SVN to darcs is the “theory of patches” it is based on. It makes redundant most concepts like branches, revision and even tags are different (they are an empty patch depending on all patches that were in the repository already). This way it is really easy to branch (if XCode had any integration, it would make its snapshot feature incredibly powerful) and merge back. I also found it easy to handle conflicts (except on project.pbxproj files, be careful with those).

For Cocoa developers (like us) it is also really welcome that darcs puts only ONE directory (called _darcs) in the main project folder (unlike svn putting a .svn folder everywhere) so you are unlikely to mess things up, for example by copying nibs to localize them or things like that (which was plaguing me as PDFKey Pro is localized in many languages and I kept doing the same mistakes over and over with SVN).

Currently, a Darcs GUI for Mac OS X is in the works, is called Darcheology. It is already quite neat but is in dire need of contributors, so if you got some spare time, it is surely worth to take a look at it!

For the first time me and Karsten are collaborating at a new super-top-secret-no-dude-i-really-cannot-tell-you-about-it-seriously project.

As you may know, we don’t live in the same building, or not even the same country, so we had to setup some sort of protocols.

After the initial logistic problems, we have our darcs repository in good shape and learned to avoid conflicts.

Now the process mostly goes: one implements a feature, the other makes it work properly and viceversa. This leads to this kind of dialogs:

Today I was pointed at bla.st. I think is a really cool site, surely not the first to try this kind of marketing, but looks pretty much well done.

So, I felt the urge of creating a card there as well. The process was really easy, although their 30kb limit looks a bit too restrictive to me. Choosing categories is also a bit counter-intuitive, but then again I’m not really used with tags yet 😀 .

Advertising there is very inexpensive, currently in the software category a free submission will do! Hurry up while it lasts 😉

Doing some tool that uses a NSTask to launch shell-scripts, I ran into a very annoying bug these days. The script were bash scripts and as soon as they were started, all output written by NSLog didn’t go to Xcode’s console, but rather only to console.log. This problem only seems to happen when using bash to execute the scripts, so switching to zsh did the trick and now NSLog works as charming as always. Thanks a lot to Michele for the hint with Zsh, I didn’t know that it uses the same syntax as bash and thus the only changes to the scripts were changes to the first line!

thanks a lot for the folks that found this out!

Karsten