Oleg Andreev

If you define some variables in projects settings that are included in Info.plist (usually, it is build version), you may notice that Info.plist is not always up to date. This is because when you change the variable in project settings, the Info.plist is not actually modified and Xcode may skip its compilation.

If you try to add Run Script phase with “touch $PROJECT_DIR/Info.plist”, it won’t help much because it will always run after processing of Info.plist. At best, Info.plist will be up to date every other run. It is very confusing to say the least.

How to fix:

1. Add a new target “Other” — “Aggregate” with a name “TouchInfoPlist”

2. Add Run Script phase with this line: touch $PROJECT_DIR/Info.plist

3. Go to your actual product targets, select Build Phases tab and add dependency TouchInfoPlist.

4. Edit schemas and remove schema “TouchInfoPlist”. You’ll never need to run it directly.

Enjoy always up to date Info.plist.

Apple has a lot of great documentation: from the very basic guides and tutorials down to particular API references. But for a very long time newcomers were wondering: where should I start?

Now you know the answer:

For iOS: Start Developing iOS Apps Today

For OS X: Your First Mac App

iOS guide is even better: it shows you all necessary areas from the beginning to the end giving relevant links at each step. Just start with first page and move on.

Yesterday you had many great ways to create and digitally distribute your content. First, you could make a website with gorgeous latest web-technologies which is perfectly accessible with every modern browser on all major computer platforms. Or create an ebook based on the open standard Epub, also supported by all major reading software and devices. Third option is to make a movie (encoded in a couple of wildly supported video formats: from FLV to H.264 and Ogg). Finally, you could write a native app for Windows, Mac, iOS, Android etc.

Every platform vendor: Microsoft, Apple, Google, Facebook, Adobe and others work hard every day to give you better ways to create and communicate with people.

Today Apple released three apps: iBooks 2, iBooks Author and iTunes U. Every app is available for free. iBooks now runs interactive books created with iBooks Author and iTunes U integrates books and apps with video materials in a very useful UI.

So today you have one more wonderful option in addition to those listed above. Yet, some people start screaming about “lock in”, how Apple does not care enough about education to make everything open; about many evils of proprietary formats, proprietary apps, proprietary operating systems and proprietary devices.

These people are fantasizing a world where everything is right, cheap and every good is available in an infinite number of options. And at least one of those options is exactly what is right for them (and there must also be a right one for any other person too for fairness’ sake).

Guess what. This is the world we are living in. And everybody has her own idea of the perfect world order and while we are not enslaving or destroying ourselves, our world indeed moves towards better ways to live a life. Nothing is 100% right for you, but it is so for everybody. And this is why we all are working together everyday to make us happier.

Today’s Apple announcement is just one more achievement of human civilization, in addition to iPad, Android, Windows XP, World Wide Web, printing press and alphabet. Choose what you like in any combination and go do something great with it.

I have a single-core chip on iPhone 4 and an app with OpenGL rendering controlled by touch events.

This morning the app was rendering graphics on the main thread. 90% of CPU time was spent on graphics, 10% on gesture recognition and related computations. Overall CPU utilization was about 30%.

These 30% were noticeable: touch events were processed with delays and frame rate was low and not very stable.

In order to make app snappier, I moved the OpenGL rendering into separate serial dispatch queue. Now event loop was much less loaded, and I expected overall improvement. Not a higher framerate, but more stable one and with more accurate touch recognition.

In reality, the rendering was indeed slightly smoother, but touches were still delayed.

Profiler was showing now that 70% of CPU time was spent on graphics (in background thread) and 30% was spent on gesture recognition. Also, overall CPU usage increased up to 50%.

In terms of raw performance of algorithms nothing was changed at all. Threading code that was added is a simple dispatch_async() call consuming almost no time.

Now, I have a theory that explains this. Since the main event loop became 90% less loaded after moving graphics to background thread, it was able to process more touch events per second. Gesture recognition computations increased load on a single CPU core making graphics rendering slower than expected.

In result, framerate was not improved, but became more stable and touches didn’t get much smoother because of the increased pressure on CPU and main thread.

It turns out that rearranging stuff on a single core does not really help unless it is accompanied by actual performance improvements.

In May, 2010 I started experimenting with a UI for staging and committing to Git repository because it’s not easy to “git rm” a bunch of files that are already moved to trash (tab does not help). Also, I was tired of typing “gs” (“git status”) all the time just to see that everything is the way I want. Soon I realized I could make the app much more useful if I could integrate history cleanly without too much additional elements. I’ve spent a couple of days thinking about it and realized that the “stage” is a special case of a commit. I quickly came up with a two-pane window — history on the left and changes on the right. Stage was a special item in the top of the history. Since then a lot of good design decisions were coming quickly. Branches went to the drop-down menus in the toolbar with pull/push button between them.

Gitbox 0.9 looked very simple.

Quickly, everybody at our Pierlis office started using it. Staging, committing, pull, push became much more efficient than in Terminal or any other GUI starting with version 0.1. It was my first Mac app (I’ve already done some iOS projects for our customers), I loved it but still I was shy to release it. In June on WWDC10 my boss told me once more that “real artists ship” and I shipped Gitbox with version 0.9 for free. It looked clumsy and I really worried that nobody would like it.

But it was a success. A lot of people got interested by a concept of “one-button” Git client. Never before version control app, especially for Git, was expected to be “simple” or “minimalistic” yet useful. A lot of people dismissed it for a lack of features. But still many fell in love with it from day one and continued using it daily. For many it became the only way to work with Git repos without exploding their brains.

I got quite serious about it. I decided to polish it, add several more important features, streamline the UI (mostly by adding a sidebar for the repos) and released it in the end of November 2010 for $40 with a free version limited by 3 repositories (and no time limit).

It was a success again. Over a couple of days it made about $3000 which was totally unexpected as I was hoping for at least upgrading my notebook. Over months, it was steadily bringing some noticeable profit that helped paying for my wedding and honeymoon later in 2011.

I was amazed that something I designed, wrote, productized and marketed was actually appreciated by consumers. I even appreciate that keygens were released within a week after
each new version release.

I developed a long list of features and tweaks, rearchitectured the whole app several times (hello, responder chain and GCD!), was trying to keep focus and regularly deliver updates with both fixes, improvements and new wonderful features. It is still a “weekend” project, so I don’t have a lot of time to work on it. But what matters more is to keep going and improve it every day, at least a little bit.

Gitbox is still lacking some interesting things like built-in diff viewer, line-by-line staging, tree view or submodules. Those will come soon. But many more important things were already done: very responsive UI, instant full-history search (even by diff contents), undo for common operations like commit, pull and push (and more to be added in later updates), ubiquitous drag and drop and powerful keyboard shortcuts. Also, a lot of stuff was ignored that would cripple and complicate the UI. Some power features were delayed until the right place for them was found.

I consider Gitbox a right UI to do Git version control. The core design principles worked very well so far and allowed me to extend it to more and more new capabilities. UI is still, like in v1.0 very simple and clean, but is able to do so much more and will in the future.

Thank you all.

Some people would love to use proportional fonts for the programming code, but blame languages and text editing software for not being ready for them yet. The problem is that most proportional fonts (e.g. Helvetica, Lucida Grande) make punctuation characters too narrow making many statements hard to read.

Compare:

Monospaced font: if ([link isKindOfClass:[NSURL class]])

Proportional font: if ([link isKindOfClass:[NSURL class]])

Programming languages usually contain a lot of little syntactical features that are important to read and notice. One extra pair of parentheses or a semicolon may change the whole meaning of a line of code. And, unlike the real text, you cannot make a single typo.

If monospaced fonts look clunky, that’s because the programming languages normally require equal attention to every single character.

When you need to do CPU-heavy work, there is a nice pattern using GCD: jump to a background queue to do the work, and then back to caller’s queue to report the results. Do not forget to retain the caller’s queue because it may be deallocated while doing background work. Although compiler inserts retains for the ObjC objects referenced within blocks, queues are declared as opaque C structs (dispatch_queue_t), so they won’t be automatically retained.

dispatch_queue_t callerQueue = dispatch_get_current_queue();
dispatch_retain(callerQueue);

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
	
	// Do the work in the other thread...
	// Example: NSArray* items = parseJSON(data);
	
	dispatch_async(callerQueue, ^{
		
		// Report results to the caller...
		// Example: [self didParseItems:items];

		dispatch_release(callerQueue);
	});
});

Ruby is very similar to Objective-C because both have a lot of similarities with Smalltalk. However, Ruby is a messy language on many levels. Many consider it a mostly a feature, not a bug, but it indeed makes interoperability with Objective-C less nice.

1. Ruby has a messy syntax. It inherits several features from Perl, Bash, Python and C-like languages and mix them together without any clean distinction. You have always many ways to do the same thing and it is never obvious which one is the best. With Objective-C it is much easier to write a lot of boring and obvious code than with Ruby. Of course, this property appeals to coders who love funny things in their code, but it does not play well with people who want to ship huge complex applications and systems in time.

2. Ruby has a messy standard library. Many things in standard library are not well-thought, not consistent with other things, redundant or lacking essential functionality. Things like File vs. FileUtils, Date/Time/DateTime + ActiveSupport extensions demonstrate horrible inconsistencies at some core things.

3. Ruby has a messy culture. Ruby coders *love* smart tricks and hate boring code. Everybody wants to DRY all the code for better or worse or pretend being a cool meta-programming lisp hacker (not the best professional quality in itself). People are not careful about containing their libraries as humble as possible. Many people are okay to inject methods into core classes and do a lot of meta programming tricks and be proud of it. All this leads to maintenance issues and is not compatible with Objective C culture.

These three key things make Ruby incompatible with Objective-C or Cocoa framework.

It’s important to add that all of this is not unique for Ruby, but pretty much for any hobby technology, particularly backed up by some open source community.

Apple clearly puts a lot of effort into making LLVM infrastructure and Objective-C a powerful general-purpose toolkit for themselves. If they miss some feature, they are more likely to add it to LLVM and/or ObjC rather than spinning off additional separate projects. They already have WebKit and JS and that covers a lot of what they want to do. And they are bold enough and smart enough to improve things in both technologies whenever they want or need to.

Forget about MacRuby, MacPython and other languages in that respect, they are clearly are only interesting to people who focus more on typing codes than on shipping products.

I would love to have the following feature in Objective-C:

@property(retain, auto) id something;

Where “auto” attribute would mean:

1) automatic @synthesize (already present in modern Clang compiler)
2) “nonatomic” if not stated otherwise
3) automatic release (if “retain” or “copy” is used) and nullifying of instance variable on dealloc

Xcode 4 slowly replaces Xcode 3 for my projects. Benefits become more important than problems. So here is my list of things I like and dislike about Xcode 4:

Like:

1. Tabs
2. “Open Quickly” with fuzzy search by filename (cmd+shift+O), like cmd+T in Textmate.
3. Jump bar
4. Smarter autocompletion

Finally, the tabs and jump bar turned out to be the single reason to use Xcode 4 despite all of its annoyances. On a complex project window management consumes a lot of time.

Dislike:

1. The major problem with Xcode 4 is performance: switching between tabs, opening sidebars, autocompletion — all happen with noticeable delay even on iMac with i7 processor and 8 Gb of RAM. Bonus track for the latest Macbook Air: sometimes Xcode 4 eats 150-200% of CPU doing something (no matter whether debugger is launched or not). And when the debugger is connected to iOS Simulator fans just never stop. I hope this will be resolved with next updates.

2. No retina display mode yet in Interface Builder (but IB 4 is slow as hell, so I use IB 3 instead anyway).

3. Stupid (== “too smart”) assistant editor. When I choose another file manually, it is sometimes reset to some counterpart. And Open Quickly always opens in the left pane. Assistant editor has no value to me until these issues are fixed.

4. LLVM and LLDB. Turns out, the latest LLVM compiler has subtle bugs with nested blocks (sometimes self becomes an incorrect pointer) and LLDB does not display values for properties which were declared without corresponding ivars.

There are some things about Xcode 4 I don’t really care about:

1. Git support. I have a Gitbox anyway, which offers complete set of operations (committing from Xcode is a nightmare and pushing is simply not possible). Surprisingly, I’ve never used blame or in-editor diff. Those features sound useful, but in practice are rarely needed and feel sluggish.

2. IB drag-and-drop to source code to create actions and outlets. Xcode is slow and produces some awful code which needs cleanup anyway. Same thing goes for code snippets that take more time to find/drag/edit than to simply type the stuff.

3. iTunes-like status panel. I usually collapse the toolbar anyway, so I don’t see all those distracting animations.

When you develop some interesting software, you care to make architecture simple, boring and flexible as much as possible. When you think hard about user interaction or work around some weird system integration, the code should get out of the way . Whatever language you choose, you try to stick to some limited set of features and use them predictably and consistently. Ninja tricks are interesting on their own, but better not get mixed with an actual product.

As the complexity and amount of stuff to be designed and improved grows, you are becoming more conservative about any language or technology you use. All the sudden, discussions about C++ template complexities, braces styles etc. look completely strange and irrelevant.

Your code is so simple, you wonder why you should write it at all. Most of the typing is spent on defining objects, giving names and connecting things together. Every interesting algorithm is carefully packaged out of the evolving structure and is rarely touched again.

File system tree does not feel expressive enough. You need some sort of rectangles on the screen to lay out the components and hide some parts within the others for goodness sake.

You become even more productive if some of those rectangles provide immediate feedback, e.g. user interface elements in the Interface Builder.

The future of software development is not the language or syntax, but the interactive tools with instant feedback and sophisticated data organization.

Why are people so obsessed with the NFC buzzword?

The only safe and understandable way to conduct the payment with a phone is with the protocol like this:

1. Shop sends a payment request to your bank (via shop’s bank or directly)
2. You bank pings your phone and waits for confirmation.
3. You take your phone out and confirm the payment. You can do this securely over Wi-Fi, 3G, EDGE, Bluetooth, NFC and any other communication technology which lets you to speak TCP/IP and finally (after going through all the proxies and routers) connect to the Internet.
4. When bank gets the confirmation, it acknowledges the transaction and tells the shop about it.
5. Shop issues a ticket and you walk away.

This protocol is safe (contrary to modern credit card processing) because you never trust someone else’s device (you trust only your phone) and you never give away any secret information (like credit card number or a PIN code).

The only tricky thing here is how to give the shop your banking ID (which can be a phone number), so they can send it to your bank which will contact you for confirmation. This can be done in many different ways:

0. Tell the ID to the shop assistant - simple to understand, but needs remembering and typing in. Since we need a phone to confirm payment anyway, we don’t even count it.

1. Show the barcode on the phone’s screen and scan it. You need to launch a payment app anyway. Why not to display you bank ID as a barcode on the first screen so you can simply scan it.

2. Use NFC to announce your ID to the shop. This like barcode scanning, but without optical scanning. It has its issues, though. If you have many devices nearby, the receiver may confuse your device with someone else’s, or recognize your slower. Everybody knows how slow bluetooth is.

3. Do it in reverse with NFC: the shop will publish you bill and (if you are lucky) only your phone will see it, so you can send it to your bank.

To me, the most usable ways to conduct payments are #1 and #2. And #1 seems to be simpler and faster (but feels “lo-tech”).

Bottom line is: NFC is not a requirement for payments with a phone. You need any communications tech to connect to your bank and can use different ways to announce your banking ID.

I also hope, that the phone payments won’t be done in the same way as credit card processing is done. That is, by giving away secret codes and trusting the shop to confirm the transaction.

Gitbox started selling in November using old-school method: download a free version from gitboxapp.com, then upgrade to a paid version by buying a license.

Today Gitbox is available on Mac App Store as well. What this means to you?

If you have already purchased Gitbox, you don’t need to “connect” it to App Store. First, it is impossible to do for free: you’ll have to buy it again, from Apple. Second, you won’t miss much. Gitbox is a single-version application: there is no “lite”, “full”, “appstore” or “non-appstore” variant. The functionality is all the same. (Only difference is that binary in appstore has different autoupdating and license checking mechanisms.) Gitbox already provides automatic updates for free. There is one nice feature of the non-appstore purchase: updates can be released within minutes instead of a week.

Note that App Store marks the app as “installed” if it sees it on disk even if it was never downloaded from Apple. If you want to purchase it from Apple (maybe you have not yet purchased a license), then you should drop the app to Trash and restart App Store: the purchase button will become available. Your preferences won’t be affected.

So how do you decide where to purchase an app? Both distribution channels are great: appstore is more controlled, but sometimes much more convenient, another one is more flexible, but less integrated into OS. I believe it is important to keep both options available to you, but I want to avoid any confusion. So here is my policy:

1. Prices and discounts will always be the same and synchronized for both stores. The app is the same, hence the price is the same.

2. I will do my best to release big updates synchronously on both stores. I usually don’t release more often than once a week or two, so it is very possible to adjust to the appstore review delays.

3. In case of security updates or critical bug fixes, I will post an update immediately even if the appstore does not publish it as quick as I do on my website.

Enjoy Gitbox and buy it where you like. You will get the same support and love everywhere.

How do you add a view (spinner, text field, button etc.) into the cells of NSTableView or NSOutlineView?

Simple:

1. Keep a reference to the view in your NSCell.
2. In drawInteriorWithFrame:inView: you should create the view if needed and add to the controlView if needed. controlView is provided as a second argument to this method.
3. Position the view according to the cellFrame (first argument to the drawing method).
4. Do not forget to retain or nullify the view in copyWithZone method. Remember that copy and copyWithZone copy instance variables as-is without retaining object pointers when you might need that.

Correction on January 6th, 2011:

There is no point in keeping a reference to a view in the cell. After the cell is drawn it is often deallocated immediately, so the view will stay visible forever. You need to keep the reference to the view in some external non-volatile object: a view, a view controller, or a model.

I’m happy to announce that Gitbox reached its first major milestone: a first commercial release. It is a great version control app for working with Git repositories. Instead of cutting down the powerful, but complicated concepts of Git, Gitbox embraces them with a truly elegant user interface. Many people start actually using branches in Git thanks to Gitbox.

Download Gitbox 1.0 now. Use coupon GITBOXNOV before December 1st to get 30% discount.

Since the last preview version, a lot of things have changed. I have worked out a strong vision of what kind of product I want to create. As a part of it, I have redesigned the user interface and reengineered the underpinnings. Now all the repositories live inside a single window and the app itself is running on Grand Central Dispatch (GCD) on Snow Leopard. Translation: Gitbox is faster and easier to use.

A couple of thoughts on licensing policy: usually commercial software comes in two flavors: a full and a trial. Here’s the problem: when I download a trial version it is usually limited to 14-30 days of free use. I may try the software for a couple of minutes, then put it aside and forget about it until I have a real need in it (or some very handy feature is released). When I come back to the newer version, it appears I cannot try it any longer!

Gitbox does not do that. You may try it right now and for as long as you want. You also have all the features available with only one fair limitation: only one repository opened at a time. Why is it fair? Because if you don’t find Gitbox useful enough to pack it with all your repositories and use it every day, I don’t want your money. Instead, I would be happy to listen to you and make it better.

When you do buy a license, you get more than you paid for. First, all updates are free (some really cool features are coming soon). Second, you may use the app on all your machines without any sorts of spyware, activation etc. The only limitation is that the license is for personal use. If you want to buy Gitbox for a group, you should buy an appropriate number of individual licenses. Contact me if you’d like to get a discount in that case.

I will release new features and incremental design improvements regularly in a form of free software updates. As the app becomes more powerful and better designed, the price is likely to rise. Since the updates are free, this idea should convince you to buy a license early at a lower price ;-)

I’m very thankful to my family, colleagues at Pierlis and all the folks who were using preview versions and giving a lot of priceless feedback.

Let’s get it started.

In a software business, the functionality is an asset, but code is a liability. The less code needs your attention, less costs and risks you have.

OOP is all about making stuff work, packaging it into an object with as small interface as possible, and building other stuff around without going back and tinkering with that package. Note to Java people: it does _not_ mean the object should fit everything. It should fit at least a single task and be reliable at that task. The point is in reliability, not reusability.

This concept is called “incapsulation”. It is not the way to make the code nice. It is the way to minimize your costs and risks and finally ship.

“All normal operations on a binary search tree are combined with one basic operation, called splaying. Splaying the tree for a certain element rearranges the tree so that the element is placed at the root of the tree.

A top-down algorithm can combine the search and the tree reorganization into a single phase.”

http://en.wikipedia.org/wiki/Splay_tree

The splay tree modifies itself every time it is searched becoming more and more efficiently organized over time.

Everyday as a software developer you have to invent some abstractions. Simply speaking, you have to decide where to put the new code. After you decide this, you write more code and repeat the process. Sometimes the earlier decisions need to be changed and you refactor the existing code. Now you decide where to put the old code.

I really need a hint. The OOP folks teach us to model the real world. Just look at the problem domain, they say, and you will see where the things belong. It works great until you hit some system-specific pure abstractions and there is no natural metaphor to help you.

Try another approach. Since the initial question is where to put the code, and the refactoring is about moving the code around, why not to make the code itself easily movable? How about making the code copy-paste friendly?

The first idea which comes to your mind is to wrap it in the object. Yes, it might solve the problem. But at what cost? Creating an object means defining the interface (class, protocol, whatever) which creates another entity in the program and eats a part of your brain. Not always a good idea when you are already stuck finding out where’s the best place for just ten lines of code.

When you are trying to solve a problem, do not hurry creating another one. Relax, put the code somewhere where it is easier to move from and make it depend on the nearby code as little as possible. Usually you do so by putting the dependent data in some local variables. You can later transform them into function arguments or object properties.

When you make the code movable, you can (sic!) move it around and isolate more and more over time. Maybe 5 minutes later you will discover you don’t need it at all. Or that it should be simplified and moved in a function. Or that it should have more functionality and become an object. Or that it should be split in two different tasks. All of these questions become much easier to answer when you keep the code simple, stupid, light and isolated just enough. Just enough to copy and paste it.

1. Breaking an article into multiple pages.

Page is a physical limitation of a paper medium. Sometimes the text does not fit and you have to drop the last paragraph on another page. On the screen you have plenty of vertical space and there is no excuse to cut the reader’s context.

2. A lot of iPad newspaper apps simulate multi-column layout. They shouldn’t.

The purpose of a multi-column layout is to make articles’ layout more flexible on a big newspaper page. On a wide page you can fit a couple of articles and an ad. But the screen is not that wide.

Narrow columns also require small font size, which is a problem on a display of a resolution under 300 dpi.

Narrow columns require manually-tuned hyphenation and sometimes font width-adjustment. It is a requirement for the books as well, but a more narrow column looks even worse. Unfortunately, it is not the case for the digital media today.

If the column does not fit the screen, you constantly have to scroll down and up when reading a page: down when finishing the first column and up to proceed to the next one.

You can scroll and zoom the page on screen. If you make a single scrollable and zoomable column, you don’t need to provide font size control or worry about how much of content is visible. The reader can choose the more comfortable size of the page for herself.

3. A lot of people use footnotes on the web. This is horrendous: you have to leave the current line and scroll down. And even if you scroll by clicking a footnote number, you then have to scroll back. And even if you have a link from the footnote back (like in a wikipedia article), browser doesn’t scroll exactly to the position at which you were before.

On the screen you have a plenty of vertical space. And if you don’t use multiple columns (which you should not), you have some space on the side. That means, you may put some notes in the block of smaller font right below the paragraph, or on the side.

Summary

Do not break articles in pages. Do not break text in the columns. Make text column scrollable and zoomable. Make the footnotes immediately under the paragraph, or put them on the side.

There are some predictions or wishlists floating in the tubes regarding an anticipated update to Mac OS X. Some of them are more probable, some less and some are just plain crazy. Let me give you my predictions and some commentary.

1. The next cat name is likely to be “Lion”. This is based entirely on a single picture from the invitation picture and also is the least interesting prediction. I don’t think it is going to be the “last” release in any sense.

2. The merge with iOS. First, Mac OS X already has some UI features borrowed from iOS: navigation buttons in Dock stacks, iPhoto and iTunes. There will be more of them. Maybe scrollview will be updated with more flat scrollbars, maybe some bouncing will appear (and if so, it will be off by default for the existing software).
No way there will be a touch-controllable UI for the existing applications. The apps are not designed at all for the multi-touch and the size of the finger. Even if Windows 7 supports this, there’s no reason for Apple to follow the same path. However, taking in account the dual-mode touch screen patent, it seems more probable that Mac OS X might be transformed into iOS device on demand. But Apple does not favor dual-mode UIs: this just creates confusion for users and developers. The Front Row is a rare example of a second UI mode (transforming Mac into a focused media player). But the iOS is considered more or less a full-feature environment with far reacher user interface then the Front Row and at least as rich as Mac OS X. It is very unlikely that the iMac or MacBook will have two personalities which complete with each other and cooperate badly producing a huge confusion.

So believing in a strong movement towards touch UI everywhere, we may expect not a dual-mode, but per-window fusion of the iOS apps into Mac OS X. This has it’s issues also: still the file sharing is not as smooth as what we expect on a desktop OS, the iPad screen in portrait mode does not fit in the MacBook screen. And again, if you can touch and drag the iOS window, why not to touch and drag other windows? And if you can touch and drag all the windows, why not touch all the buttons? And the screen should be oriented horizontally just as keyboard or trackpad today. This is not easy to solve.

So the UIKit multi-touch will eventually show up in some version of Mac OS X, but it is not as easy as some may believe. The less improbable prediction: the Mac OS X will have a very conservative, slow introduction of touchscreen with emphasized limitations to minimize confusion as much as possible.

3. AppStore for Mac OS X. This is a really good idea in pure form, but once again has some conceptual difficulties. Apple will not lock the Mac OS X as they did with iOS, so it will compete with other distribution channels and may be forced to lower their 30% cut. At the very same time they would have to retain approval process to filter out crappy software they will sell. Developers who are not happy with the commission and the approval process, will go distribute the apps on their own. But this is very hard to debate because there’s still no third party app store for Mac, so the place seems vacant. Or it is vacant because no one could build a viable store business yet. Anyway, the Apple is the most likely company to succeed at this, and if executed perfectly, it will attract a lot of developers and make themselves and Apple much more money, and drag the Mac even further in the market share race.

4. Resolution independence (making UI 1.25-1.5 times bigger). Mac OS X team works on resolution independence for more that 4 years already. And still, on Snow Leopard the implementation is buggy and far from being anywhere close to “beta” status. The conceptual problem here is that this technology is aimed at scales of 1.25 and 1.5, not 2.0 like on iPhone. And this is not as simple as multiplying everything by two. I guess the displays with 2x higher resolution (for MacBooks at least) will become affordable before the 1.25 scale will be fixed for all the shipping apps.
Oh, do not forget that the “retina display” approach does not make things bigger for people with poor vision, it makes them sharper. The sharper text somewhat easier to see, but not as easy as 1.5x bigger one. Apple may realize that system-wide smooth resolution scaling is not worth tinkering with and full screen zoom is just enough for solving vision problems. My bet is on retina displays and old resolution independence framework being put on the shelf.

5. Finder improvements. Some folks dream about tabbed Finder. The problem is that file system is hard enough already. Adding tabs just complicates the look of the Finder and makes file system even scarier. Even if the tabs find their way into Finder, they will be disabled by default. Just like the tabs in the earlier versions of Safari were disabled.

What would be really cool is a merge of the Dock Stacks with the Quick Look and a merge of Quick Look with other apps. This is a pure speculation. Have you noticed how easy it is to jump through the folders in the Dock Stack? Buttons are big and once you find the file you want, the window disappears automatically. The Quick Look also disappears easily. Finder on the other hand, creates clutter: you have too many individual Finder windows all over the desktop. The tabs do not remove the clutter, they just organize it. Maybe what we need is not organizing it manually, but having something like a “recent folders” list and jumping through them using Quick Look.

How many times you’ve started a movie in Quick Look and played it way too long to forget that it is not a stand-alone player? And then you do something with Finder and the movie disappears! Take a look at the iCal: if you open an event, the popover window will appear with details. This window behaves much like the Quick Look: do something else and it disappears. But if you move is a little bit, it will transform into a stand-alone panel which will stick on the screen until you close it. The same idea can apply to Quick Look. It will be super-useful to transform a folder preview into a Finder window, a movie preview into a Quick Time window etc.

6. iChat with FaceTime, iCal like in iPad, iLife, iWork updates: this all is possible. The question is the timing: maybe not all of that will be tomorrow, but only some. I don’t expect super-cool features here, but more like an evolution and improvements.

7. Macs won’t support blu-ray drives. I haven’t heard about blu-ray from any of people I know. Those who really need it may buy an external drive.

8. There won’t be NTFS mounts or built-in VM for Windows. Not because there is a fight with Microsoft. Apple simply doesn’t have time for the features most people don’t need. BootCamp was an important thing in 2006 to bring more customers. Nowadays Apple does not mention “switching” anymore. There is already a plenty of ways to communicate with Windows, both built-in and supplied by third parties.

9. Mac OS X distributed as a free software update. Recently Apple has lobbied an accounting rules change to be able to distribute free updates of iOS for non-subsidized products like iPod touch and iPad. This makes the platform more vibrant and much more devices stay up-to-date. Making Mac OS X update free, Apple can accelerate adoption of their technologies and bring better and more exciting applications to the Mac.

Edit: forgot to add that a lot of goodies from UIKit, MapKit, EventKit etc. might well be ported to the Mac APIs. The NSTableView might learn about recyclable views from UITableView.

Don’t tie external resources lifetime to object lifetime (for instance, file descriptors). Never start any process in constructor/initializer. Have “start” and “stop” methods (or “open”/“close”) dedicated for managing the resource.

Don’t mix data construction and performing a procedure. Whenever you have a method which takes 10 arguments, it is time to create a separate object just for that procedure. Give it 10 properties and a “start” method. Later you’ll be able to add more configuration options and alternative invocation APIs to this object in a clean way.

In general, when you begin understanding OOP, you tend to treat everything as an object. Data structure, complex procedure, network connection, physical device — all become objects. The trick is while you incapsulate all those things into objects, you shouldn’t confuse the *object* with the *thing* it manages. The object is a manager, driver for the thing, but not the thing itself. Object may have language-oriented API and thing-oriented API. Don’t mix them. First API lets you to create, initialize, inspect, destroy object. It must have no impact on the thing. To manipulate the thing, you write thing-specific methods.

Quick test for compliance: you should be able to instantiate a valid object, set properties in any order, inspect it and destroy without any effect on other objects and things around.

Gitbox is a nice little interface for Git. I wrote it primarily for myself and my friends to optimize everyday operations. Go download the app from the website and come back here for details.

Gitbox displays each repository in a little separate window. Each window has 3 parts: branches toolbar, the history and the stage.

Toolbar makes branch operations a lot simpler. You always see which branch you are on and which remote branch is associated with it. Branch menus let you checkout existing branch, a new branch, remote branch or a tag.

The history shows commits for both the current local branch and remote branch. Commits which are not pushed yet have a little green icon, so you will never forget to push your changes. Commits on the remote branch which are not yet merged (pulled) are marked with a blue icon and a light-grey text. And you may switch remote and local branches to compare them.

Stage shows the changes in the working directory. You may stage and unstage a change using checkboxes or just select changes you want to commit and press “Commit” button.

Gitbox updates stage status every time you focus its window and fetches remote branch commits while in background.

Gitbox will be free for a limited amount of time. Prices and conditions will be announced later. Check for updates regularly!

Follow Gitbox updates on twitter @gitboxupdates.

Please send questions, bugs and suggestions to my email address: oleganza@gmail.com (or twitter)

Knight’s Principles

— Never do any work that you can get someone else to do for you

— Avoid responsibility

— Postpone decisions

— Managers don’t do any real work

— Premature optimization leaves everyone unsatisfied

— Try not to care

— Just do it!

— It’s not a good example if it doesn’t work

— Steal everything you can from your parents

— Cover your ass

“Each object will do a seemingly insignificant amount of work, but somehow they add up to something much larger. You can end up tracing through the system, looking for the place where a certain calculation happens, only to realize that the calculation has been done and you just didn’t notice it happening.”

Tony Albrecht, Technical Consultant at Sony, tells a story about memory performance and object-oriented programming style.

If you read the story carefully, you will notice that the performance problem was actually solved by writing class-specific allocators (that keep each object of the same kind in a continuous array) + doing recursive algorithm in two passes.

Tony knows very well what happens on hardware level, but he is not good at object-oriented programming. Let’s see what is wrong with his code.

In the beginning, their code is not well organized: instead of multiple distinct objects with small independent data structures they had fat nodes with matrices, vectors and other structures built-in. Because of that, the various kinds of data were interleaved and didn’t play well with the cache.

First optimization: they made the code object-oriented by factoring big data structures like Matrix and Vector out of the Node. Then, they used the incapsulation (fundamental principle of OOP) to provide custom allocators with continuous memory zones. This is only possible in a proper object-oriented code when objects of one kind do not interfere with objects of another kind other than with explicit messages. So you can optimize memory layout for Matrices, provided their behavior is not changed, and you will not break some other part of the code. OOP helped to gain 35% of performance.

Second optimization: they splitted the recursive update procedure into two phases to avoid going bottom-top adding WBS (world bounding sphere) more than once per parent node. This would save about 25% of CPU time (assuming binary tree and no overhead on leaves). But they actually got about 50-60% increase because they used continuous allocator for nodes like they did with matrices and vectors.

This is all understandable. But there are two design decisions which are not justified:

1. In the first optimization Tony claimed that “excessive encapsulation is BAD” (slide 20) and thus decided to put raw pointers to the array of matrices and vectors outside of their respective nodes into the loop which iterates over the nodes (slide 89):

for (int k=0; k < innerSize; k++, wmat++, mat++, bs++, wbs++)
{
*wmat = (*parentTransform)*(*mat);
*wbs = bs->Transform(wmat);
}

Do you see those wmat, mat, bs, wbs pointers? These are private things pulled out of node objects under the claim of “excessive encapsulation is BAD”. Now object does not control its data and once you’d like to add another special-effects matrix over the node, you’ll have to learn not only the Node class, but the entire rendering codebase!

This is how it should be done actually:

for (int k=0; k < innerSize; k++)
{
children[k]->updateWithParentTransform(*parentTransform);
}

Where updateWithParentTransform does the job involving wmat, mat, wbs and bs and gives you guarantee that this is the single file where these variables are accessed directly.

Also note that this method will be perfectly inlined by C++ compiler or smart dynamic Smalltalk/Self/JVM system, so the result code will do the same operations and memory accesses as the manually inlined code with “naked” private pointers.

2. The second claim is to “Make the processing global rather than local” (slide 73). This is also awfully wrong. Tony suggests splitting the tree of nodes into arrays of nodes sorted by level. It is not only inflexible (or requires quite complicated algorithms to maintain the invariant), but is also pointless.

We already have these class-specific continuous allocators which put nodes close to each other. We already have extracted huge data structures from the nodes, so that we may keep a lot of nodes in just a fraction of the L2 cache while the rest of it is used for matrix operations. And we already split up the algorithm so that the parent’s boundary is not updated too often. But still, he claims some performance gain out of the fact that nodes are not traversed recursively, but rather linearly using quite a brittle memory layout.

There is no point in that since node objects are so small that most of the data you need to update children using parent’s transformation matrix is already in the cache. And for the cached data there’s no difference how it is positioned: the access time is constant.

But he did not only traded nothing for more complicated code, but also made his life harder to move from a single CPU to multiple CPUs (say, GPU): only recursive algorithms and encapsulation may give you an option to parallelize computation. By flattening algorithms and breaking encapsulation Tony cut himself a way to scale the performance horizontally (or, equally, made it harder to automatic parallelizing compiler to do its job).

It is very important to know how things work on low level, but is also important to know how to incapsulate low level complexity and free your mind for greater deals.

Update: Tony replied showing that I’m not entirely right. (March 18, 2010)

In last two months I had an opportunity to build two versions of the same application: on iPhone and Android. Both applications are basically navigation/tableview-based browsers for existing French website. Absolutely nothing extraordinary about the whole thing, but it is interesting how similar features could be accomplished on competing platforms.

The Good

First of all, you don’t have to register or pay a fee in order to start developing and testing on a device. Also, you may work on Windows and Linux, but I have not tried that out.

There’s a very flexible layout framework which allows you to position elements relative to each other, to the parent and to the content. You may wrap layout around its content, but also tell it to fill N% of free space. Or fill the whole parent width (or height). Android layout are much more flexible and still simple comparing to Cocoa and even HTML+CSS. Even though the Eclipse IB-like plugin sucks, XML layout language is easy to learn and is not hard to type.

Layouts seem to be simpler and more light-weight than iPhone views: in iPhone I have to render tableview cell by hand (all these tedious pixel calculations: paddings, margins and conditional layout depending on missing text) to maintain smooth scrolling; on Android an straight-forward XML layout for a cell was enough. This is a real time-saver.

Resolution-independent metrics are very powerful: you have regular points and pixels (device-dependent), device-independent points (dips) and device- and textscale-independent points (sips). Elements with dip-dimensions will be sized equally on different screens and elements with sip-dimensions will scale according to user preferences.

The Bad

The first bad thing about Android is Java. Though it is not a language or VM. It is the way people write Java code. They do it fundamentally complicated in every single place. My application does not have any sophisticated features. It is damn simple. And iPhone has simple tools for that. Android and Java have tools to build a space shuttle.

Every single thing in Java (and I’m speaking about both legacy java.lang.* and modern android.* APIs) makes you use a couple of classes and a couple of interfaces. The classes themselves usually inherit 4 levels of superclasses and countless interfaces. In sake of code reuse, the core functionality which you use on a single object is usually split across several classes which makes you switch between various doc pages enormous amount of times. This creates a great pressure on developer’s brains: in process of building a 5-minute feature you have to load your head with almost useless hierarchical structures.

Java developers would say that on the other hand you have a rich reusable toolkit. In fact, the simple thing like network connectivity (parse url, asynchronous download over http, setting and reading http headers) could not be done using a single doc. In iPhone I’ve build a little handy OAHTTPQueue around just a couple of Cocoa classes: NSURL, NSURLRequest and NSURLConnection. I was learning Objective-C and Cocoa from scratch and it took just a couple of hours to implement a descent queue. When I switched to Android I already knew what I’m going to build and how should it work. But it took almost three days to get through 3 (!) huge independent packages android.net.*, org.apache.http.* and java.net.*. Each package had some useful bits on its own, but none was easy to take and build something right away. None contained a simple asynchronous API. Finally, I got to take single thread executor from java.util.concurrent and use a blocking HTTP API from org.apache.http. Other options were as high-level as writing to a socket by hand. The devil of Java is very well illustrated by apache HTTP library: not only it has tons of classes and interfaces, these classes are scattered across 10 sub-packages. In Cocoa you can do all the same things with about 20 NSURL* classes, using 3-4 (!) of them 90% of the time.

In average, for each Cocoa class there are 10 classes and interfaces in Android providing about the same functionality. In other words, Cocoa is 10 times more productive than Java.

Android lacks good programming guidelines. With that amount of options Java spits on you, the guidelines are absolutely a must.

It seems, Google does not care much about the phone. I got lots of stupid errors in MapView. It also lacks built-in pins, annotation pop-ups and callbacks for region-changing events! I had to implement pins and pop-ups by myself. And without useful callbacks, there’s a repeating timer which polls MapView properties and triggers a callback after user stopped dragging/zooming the view.

The Ugly

UI is slow and does not feel right. Scrolling momentum is not natural, every screen opens with a noticeable delay, maps are slow and some screens are 16bit. (Hello, it is 2010 already!)

Android device has physical buttons. Only 2 of them wake device from sleep: “menu” and “hang up”. Others are no-op. Very confusing.

Every application has a hidden menu. It pop-up when you click a “menu”, which is a physical button. And then you have to click a screen button. And to go back from wherever you are you have to tap a physical button again.

Android is over-engineered and under-designed platform. It has interesting model of multitasking stack of activities, but it fails completely when it comes to actual UI. There are “back” and “home” physical buttons. Pressing “back” removes current activity from the stack. Pressing “home” pushes Home Screen on top of the stack. All running activities remain in memory. And when you tap application icon from the home it opens the top-most application activity.

There are 3 lists of the applications: on the home screen, on the “placard” which slides over home screen and somewhere in the Settings (where you should go in order to remove an app). When you remove an app from the home screen it is not clear that you are not going to erase it completely (same issue with Dock on the Mac).

I gave HTC Tattoo phone to several people around me: everyone got confused by the navigation.

The End

Android UI is ugly, slow and complicated. Google is happy to put its apps and a search box in the system, but they are not interested in phone sales. Mobile carriers are interested in having an iPhone competitor, but they do not produce anything. Finally, manufacturers from China do not care about UI and global market strategy, they just produce devices.

Apple, on the other hand, is interested in both device sales and app sales. And they care about the whole chain: from hardware to end-user services.

Android seems to be dying already.

The average web-based shop works like this: there’s a front and a back. The front is sexy, the back is not. One group of people goes to the front to buy stuff, other group goes to the back to manage that stuff. These groups of people intersect only when those who go to the back pretend they are buyers. But still, there’s a huge distinction.

On the other hand, the real shop also has a front and a back. But those who sell stuff do not stay in warehouse all day long turning knobs to rearrange stuff on shelves. They actually go to the shop room to put things in place, see how they look and how customers explore them. In other words, a physical shop is more WYSIWYG than a web-based one.

My suggestion is to outsource to warehouse pages as little functions as possible. The shop owner should have a control on what is presented to the people. He should be able to immediately update prices, titles, rearrange things and see some basic stats which help to decide how good something sells.

I’m using Safari because it is fast, simple and not ugly. But it has several annoying issues:

1. It does not return allocated memory back to system (however, it recycles it internally and does not leak). I end up with Safari eating 1+ gigs and multiple windows with multiple tabs opened. And it is not easy to restart Safari due to a second issue:

2. It does not remember opened windows and tabs automatically. If I opened 10 tabs to read later (or to work with), I have to save them in a bookmark group. And it is not easy to remove/add new pages to that bookmark group.

3. Even if I have enough memory and Safari does not crash too often, I still have multiple windows and tabs, and hidden tabs. It is hard to switch between them, especially using a keyboard.

Let’s see what we can do about it.

First, I turn to other applications I use every day: Mail, TextMate and Xcode.

In Xcode and TextMate I have a quick access to any file using a Cmd+T shortcut: I press Cmd+T, a small window pops up with a search field. I type a portion of file name and it appears in the list. Press Enter — and here it is.

Cmd+T is useful for rare switching. For more frequent switches there’s Alt+Cmd+Up to switch between .h/.m files and Alt+Cmd+Left/Right to navigate through tabs in TextMate.

In Mail I have an Inbox and the folders. Inbox contains unread/undone messages. Everything else is in the folders.

In Mail I also have a single window with a single list of items. If I want to open a particular message in another window, I double-click on an item.

With some background I may draw some requirements for a browser useful at work:

1. It should always remember all windows positions and opened websites. If it crashes, it should restore all pages as they were opened before crash. (Just like Opera did for many years, by the way.)

2. It should have a Cmd+T menu to have a quick keyboard access to all open and bookmarked pages.

3. It should remember history for a page even if it is opened in a new window or tab.

4. The unread pages should be marked so.

5. There should be a context menu item “Read Later” which puts the link into Inbox and marks it as unread.

6. It should cache all the bookmarked pages on disk (in a form of webarchive) for indefinite amount of time. Each new version should be stored as well, but not overwrite the previous one. I want to access exactly the same content I’ve once seen.

7. Closed pages should be easy to reopen. (Safari lets you reopen a window, but not a tab).

Next step is to make some UI mockups to see how silly (or not) these desires are.