Tips on Learning new Algorithms

Someone on Quora recently asked What is the most important skill to develop in algorithms? Here is my response.

Read Zaki Shaheen‘s answer to What is the the most important skill to develop in algorithms? on Quorahttps://www.quora.com/widgets/content

Window management for Developers in Mac OS X

If you are spending 8+ hours a day on a computer, you will invariably wonder how you can optimize those for productivity. While you might have installed a few good productivity tools, one of the biggest productivity killer is a psychomotor context switch.

The most common psychomotor context switch is moving your hand(s) between your keyboard and mouse. Even if you are using a laptop with a large trackpad, mentally you still have to switch from using more than a hundred keys to using 3 keys but able to precisely move the pointer. Think about how many times you do that everyday. For developers, that happens a lot more than they can like.

To improve this situation, I use a window management tool: Slate. Slate lets you define how you want to layout your windows and assign keyboard bindings for common operations that you perform. While it may look intimidating at start because it does not have a GUI, starting small helps.

Slate requires a .slate file to be existing in your home (~/) directory. You can make a simple configuration for or a JS based configuration file. Slate has a good wiki page to detail both ways. I based mine on a blog post.

At work, I use a 3 monitor layout. I sometimes move to conference rooms where I switch to 2 monitor layout and finally when I am home or in a cafe, I am in 1 monitor layout. It can be quiet painful to (every time) rearrange half a dozen application windows exactly where you like them for the current monitor layout in their exact sizes. By using Slate I don’t even have to think about it. I can make it detect automatically when new screen is attached and how to rearrange my software so that they are at their appropriate place. Zero context switch.

For instance, here is how I define the 3 monitor layout:

# 3 monitor layouts
layout 3monitor 'Calendar':REPEAT ${full} 0
layout 3monitor 'Spotify':REPEAT ${full} 0
layout 3monitor 'Finder':REPEAT ${topleft} 1
layout 3monitor 'Wunderlist':REPEAT ${topright} 1
layout 3monitor 'Google Chrome':REPEAT ${full} 1
layout 3monitor 'Textual IRC Client':REPEAT ${full} 1
layout 3monitor 'Messages':REPEAT ${topleft} 1
layout 3monitor 'Sublime Text 2':REPEAT ${full} 1
layout 3monitor 'Xcode':REPEAT ${full} 1
layout 3monitor 'Instruments':REPEAT ${full} 1
layout 3monitor 'iTerm':REPEAT ${topright} 2
layout 3monitor 'Simulator':REPEAT ${topright} 2

Here,  I am telling slate to throw Calendar and Spotify on Screen 0 (the laptop’s smaller screen). I don’t see them often but like them around just when I need to. Then Finder, Wunderlist, Chrome, Textual, Messages, Sublime, Xcode and Instruments stay on screen 1. iTerm and Simulator are on screen 2. I have also defined size variables like $(full) and $(topleft) so that the windows are moved in the apropriate place too.

Another neat ability that slate provides is to bind applications to specific keys

bind r:cmd;alt focus 'Calendar'
bind x:cmd;alt focus 'Xcode'
bind w:cmd;alt focus 'Wunderlist'
bind f:cmd;alt focus 'Finder'
bind g:cmd;alt focus 'Google Chrome'
bind t:cmd;alt focus 'iTerm'
bind s:cmd;alt focus 'Sublime Text 2'
bind u:cmd;alt focus 'Textual IRC Client'
bind p:cmd;alt focus 'Spotify'

So I don’t have to use a mouse to activate a screen and I can even bypass Cmd+Tab as well. To switch to Spotify from anywhere, I only need to press cmd+alt+p.

You can find my slate dotfile here.

How I investigated an Xcode slow down

One of the most frustrating problem for a developer is when something comes between the machine and the ability to write code. IDEs are notorious in this aspect and we all have a love-hate relationship with them. Unfortunately, for iOS/OSX developer there aren’t many options to explore from except Xcode. So what to do when Xcode limits your ability to write code? Instrument it!

I am running Xcode version 7.0.1 (7A1001) on OS X version 10.10.5. Hardware is MacBook Pro (Retina, 15-inch, Early 2013) with 2.7 GHz Intel Core i7 and 16 GB 1600 MHz DDR3.

The problem

Lately I was experiencing slow file switching in Xcode while working on a project. The project is a big one with lot of pods and has approximately 2000+ classes written in Objective-C. It was taking more than 2 seconds to switch between files. Even opening the corresponding .m or .h file was taking a lot of time. I was suspecting the large size of the project but the culprit was code coverage reports and here is how I investigated it.

Learn more about setting up code coverage for Xcode.

Strategy

Usually, such problems with Xcode just go away by cleaning the build or deleting the ~/Library/Developer/Xcode/DerivedData subfolder(s). But first, I wanted to investigate why exactly is Xcode slowing down. I wanted to see what is Xcode doing all this time when I open a code file.

I fired up Instruments with Time Profiler and attached it to the running instance of Xcode. Once I hit the record button, I switched between several files in Xcode Navigator. Here is the screenshot for Instruments report.

debugging Xcode

I selected a time range for a single file open action (the repeating pattern you see is file switch operations. There are three rows because I sampled 3 times) to see what goes inside it. You can try different settings to suit your need but usually inverting the call tree helps.

It turned out that Xcode is spending a lot of time reading the Xcode Test Coverage Reports. See it on top of the call tree as IDESchemeActionCodeCoverageFile class. There is a whole bunch of Code Coverage related work going on. Look deeper and notice that its the Source Editor that is trying to get the coverage data. This is because I was tinkering with the IDE Text Editing settings in Xcode, I turned on the option to “Show iteration count” for code coverage (at the bottom). This option shows in the right gutter of the text editor the coverage information.

Show iteration count for code coverage

The reason why Xcode is slowing down is because its trying to open/parse the code coverage report every time I switch to another file and tries to display the coverage information.

It turns out disabling this option does not fix the problem.

There are several other places where code coverage is mentioned so I also tried disabling the Project > Build Settings > Code Generation option to “Enable Code Coverage Support”.

Enable code coverage support

It turns out disabling this option also does not fix the problem.

One last place to disable coverage is in the Scheme > Test settings.

Generate coverage data

Turning this off did not fix the problem either.

Finally, I resorted to zapping the DerivedData folder (I have a handy short cut on my Finder side bar for it) and voila, the problem was solved. Xcode keeps several files generated to support code coverage in there and this resets everything. Now my Xcode is faster. 

Are you experiencing slow Xcode? Perhaps run it through Instruments and see what is going on. There is a good tutorial on Instruments here. You can read the official Apple guide about Instruments here.

Update: This issue reappeared after a couple of days. I suspect the test-coverage to Code Editor binding is not immediate for some reason. YMMV.

#instruments, #profiling, #xcode