iOS 7 Wishes

Federico Viticci from MacStories wrote a piece on what he'd like to see in the next version of iOS.

Being an international user myself, I can feel his pain regarding using different language and regional options for different workflows.

As a developer, I'd love to see Core Data syncing with iCloud fixed, or replaced by something less ambitious but that does work reliably.

Get out of my lawn

From iMore's Google offers iOS developers a way to treat Chrome almost like the default browser by Richard Devine.

Google has released code that gives developers the ability to have links open directly in Google Chrome instead of Apple's built-in Safari browser, and return users right back to their app with a single tap. A developer has to add Google's code -- a URL scheme with x-callback -- to their app, and you have to have Chrome installed on your device, but the execution is seamless.

What is interesting about this is that it should not be the developer's to call to decide which app will handle links or e-mail for an user.

The ability to set default apps is a long time feature request by "power users" of the platform. It is also clear that the lack of this possibility undermines the experience of those who use Chrome as their default browser on iOS. However the closed and inflexible solution which is the current system wide behavior is far better and more reliable than the almost anarchic alternative in which each of the apps in an user's phone might treat another app as the default target of a given action, unbeknownst to the user himself.

On launching The Magazine, Marco Arment had implemented similar functionality by assuming that whenever someone had Chrome installed, what they wanted was to use it to browse the web in all situations. While a fair assumption, it proved itself wrong very quickly. Marco then added what should be the actual behavior app developers should adopt: In the absence of system wide default overriding, allow the user to choose in the application's settings which is the app that should handle each action. This is a far less agressive solution, as it allows users to decide if and when they actually want to use anything different than Apple's defaults on a per app basis, rather than having the developers of their apps have the decision for them.

Launching Marklit

It is been about a week now since I launched Marklit, so this is not really a launch post. In fact, I submitted its first update today with a few minor UI tweaks to the search page.

Launching this app has been to a large extent a "scratch my own itch" kind of endeavor. I am constantly listening to podcasts and reading, and very often something will come up that will trigger the desire to do a web search. However, I normally don't want to pause the show I am listening to or stop reading immediately to research something. Ultimately, this usually led me to open a tab, enter a query and leave it there so I could attend to it whenever it was convenient. Generally this behavior would leave me with a lot of open tabs with searches that I had started but did not finish. Sometimes I would even open a few results that seemed relevant and that would leave me with an even greater number of open tabs. Saving the relevant results to Instapaper didn't really help, since by the time they were stored in my queue, I'd lose context of which search each result belonged to. Clearly, this workflow could be improved. 

Enters Marklit

Marklit is an app that allows for quickly saving search queries to a queue, viewing  the results for those queries later and saving relevant results to a "Leads" section, which is associated with the query. Basically it attempts to bring time-shifting properties to the content discovery (through search) experience 

As of today, Marklit is available in the iOS App Store with an iPhone only version. I have plans to add iPad support in the near future, where the experience of browsing and saving relevant search results will be more complete than the iPhone can provide. There are many cool features I will launch in updates as the product matures.

Hopefully, Marklit will scratch itches other than my own for a long time.

So you don't want to be a programmer after all

Interesting piece by Jeff Atwood on career choices that aren't programming roles per se but which are technology related, and where a programming background can be an useful edge.

I believe though that in Brazil, the situation described in Jeff's article seems to be the rule rather than the exception. Graduating in Computer Science or other technical/programming related fields will, most of the time, drive professionals towards less technically oriented careers. In fact, it is way easier as an engineer to end up working in Business Consulting or Investment Banking than it is to actually go on to engineer things. Even inside engineering companies, management, sales and executive positions tend to draw the attention from most of the talent.

Quit and Analyze

Great episode of one of my favorite shows.

Marco seems to be able to move on from more projects than most people are able to start. I really miss Build & Analyze and I believe it is among the best materials out there to learn about developing real products in the iOS platforms (which goes way beyond coding). Instapaper won't be missed at all, since it is not going anywhere, and I am positive the service will remain great since there is a very good groundwork well set and a lot of thought seems to have gone into choosing Betaworks as its new home.

Here's hoping Marco will soon bring out yet another great thing.

First things first

Writing the first post for a blog is weird.

I always thought it wasn't great to start with a meta post - i.e. blogging about blogging - so I was never really confortable with writing an introductory post. On the other hand, I have had the domain up for a while now, and I've been taking notes on some things I'd like to write about. But, I've always felt weird about just dropping some random post here and eventually realized this was putting a lot of strain on what that first post should be. That is why I am going with the meta option.

On this blog I will write about stuff I care for, mostly related to my personal projects and hobbies, i.e. "My own things". The idea for this website's name came from an old piece by Marco Arment.

Don’t try to shove yourself into a particular bucket when it’s a crappy fit. If you don’t want to be a blog, don’t wedge your identity onto Wordpress. If you can program and design, don’t work as a “Software Engineer II” at a big company. Free yourself from other people’s perceived presets.

Do your own thing. It’s great.

I will just end with that, since it is certainly better and way more inspiring than anything I could add to this first post. Hopefully, getting this one out of the way will allow more to come.