Record and Reverie

Anyone who uses multiple IDEs along with Xcode recognizes just how far behind Xcode is compared to others. I would even go as far as to argue it is at least half a decade behind Eclipse. Features which I have long grown use to having are completely absent in Xcode. Then, about a month ago, I discovered AppCode and started using it for my Obj-C development at work. I could repeat the feature set mentioned on their website, but instead I’ll assume you’ve read that and outline the crucial parts.

Code Completion and Imports
The code completion causally mentions that it works with CamelHumps, but this is a huge factor in completing code. For example, if I wanted an NSMutableArray, in Xcode I must type NSMutableAr before the tab completion results in a single result. If the tab completion is aware of CamelHumps, I must only type NSMAr before the tab completion has narrowed it down to NSMutableArray alone. Furthermore, the tab completion after the insertion of a colon works better than it does in Xcode.

The killer feature in the tab completion is when the class has not yet ben imported. If I were to start typing the name of a class that is not included in the imports, not only can it complete the class name, it will also import the necessary files to satisfy the complier for the choice I made.

Code Generation
Declare Method in Interface: I used this feature a lot. I had long gotten used to copying a method line in the .m file, and then pasting it into the .h file, with a semicolon at the end, to declare it in the interface. Now, I hit option+enter at the method declaration and tell AppCode to do it for me.
Implement/Override: I use this one a lot too. Too often I am making a subclass or implementing a protocol, and I forget all the method name I may want to implement. Now, I just hit the override shortcut, and select the ones I wish to implement.
Change ivar/property to ivar/property/both: I used to use objectivecannotate for this task, but AppCode does it much more cleanly. I can tell it to declare the property for an ivar, or even make it read only in the interface with it being read-write in the implementation.
Live Templates: Yes, Xcode has their snippets, but these are more powerful because you can define what kind of completion to use for variables in the snippet as well as where the snippet is applicable. Thus far, I have only had to add the one that is a typedef of a block to a nicer type name. Such as:
typedef NSComparisonResult (^NSComparator)(id obj1, id obj2);

Refactoring
I have to admit, I’m scared of the refactoring in Xcode; it gets things wrong. I freely use the refactoring in AppCode and it has yet to screw something up. Often, I am renaming a variable or changing a method signature but two important ones must not be overlooked:

• Selecting a section of a line or a line, and extracting the result to a variable.
• Extracting several lines of code into a method

Unit Testing
I have gotten to creating unit tests to test if my code works (yes, not proper unit tests but I have to make sure it works anyway…). Lately I’ve been developing libraries, so testing in the app isn’t as applicable. The unit testing in Xcode is a bit, uh, pathetic. In AppCode, I’m often telling it to run a single test (selector), and then debugging it while it is running the test to see where things went wrong.

Integration
AppCode reads and writes Xcode’s project files. So, going back and forth is a non issue. I modify the project in one, the other sees it. AppCode also can run apps in the simulator or on the device, as well as debug both.

Deficiencies
AppCode cannot edit xib files or a host of other non-text files in a project. It at least will open Xcode to do this task. It is also limited in it’s ability to edit the project as well as missing some of the more specialized functions. The key-mapping is a bit off, making it feel like a windows application, but this can be mostly fixed by changing the shortcuts.

Conclusion
AppCode makes an excellent editor of code as well as debugging. It’s building doesn’t give as much in terms of a progress indicator, but it does work. Since I spent a vast majority of my time writing code and debugging, I spend more than 90% of the time in AppCode. When I’m doing anything else, I tend to use Xcode.

Now, if only Apple would make Xcode a better editor of code…. Nah, NIH syndrome it too well engrained.

I often use single vendor credit card numbers for my online transactions because in the event of a breach or theft, the numbers cannot be used elsewhere. Many credit card companies offer these under other names, such as Discover who calls these “Secure Online Account Numbers.” These work really well, except for the fact that these do not work well with Amazon purchases. There are a few other cases they fail, but Amazon is the biggest nuisance for me.

The Problem
Why do these fail with Amazon? Amazon has separate vendor IDs for purchases. Purchase made from Amazon are under one vendor where as purchases made from third-parties where Amazon handles the processing is another vendor. While I’ve not seen it myself, I’ve read that Kindle purchases are again another vendor. This means that a single vendor number cannot be used for orders which contain purchases which will be charged by more than one vendor. Furthermore, Amazon likes to save these numbers and if one were to use separate numbers for each vendor, they can easily become confused with one another.

The Solution
I’ve found a relatively simple solution that in my experience seems to solve the problem. Place and pay for orders which would be charged by multiple vendors while retaining the security of not giving Amazon a credit card number that can be used by anyone else.

1. Put items in your cart and build your order to what you want to buy.
2. Do not proceed to the checkout but instead view your cart and click on the link to “Estimate your shipping and tax.”
3. Open a new tab to Amazon’s gift cards, select email, and fill in the amount which will cover your order size. It’d be prudent to add a buck or two extra in case.
4. Put in your own email address and purchase your gift card.
5. When you receive your gift card email, go back to your original purchase and proceed to the checkout. When you reach the payment page, copy and paste the gift card number into the appropriate section.

I’ve placed one order this way and it worked well. Though there was a random fluke where Amazon didn’t ship it for over a week, but they assured me it had nothing at all to do with the use of gift card. In fact, the guy on the phone couldn’t figure out any reason why it was delayed, strange.

I do this because it is an active protection mechanism against theft. Even though I do this most of the time, I did have my credit card number stolen recently and attempted use in Michigan. So, I’ve stepped up my use of single vendor numbers and decided that I will not purchase from Amazon anymore unless I can use them. Does anyone else take these proactive measures to protect their credit card number?

Now, if only this worked with AWS…

Suddenlink seems to think that this is 15Mbps:

I’ve called them at 5-10 times in the past few weeks, and this is still the speed that I get. I have tried changing modems and three separate technicians have said that my connection is good and yet it is no better. This is consistent across nearly every evening. Using these numbers, if I were to extrapolate the speed to the 50Mbps plan, I’d still not get achieve 15Mbps in the evenings.

Just a note for those considering Suddenlink and have a choice with another provider. I used to think that Suddenlink’s service was great, but no longer.

In a few of my recent posts, I outlined some things which I believe that Objective-C can learn from Java, the most recent discussing error handling. In order to avoid the impression that I may not like Objective-C, I figured I should outline some of what I believe are the most important improvements Objective-C has made.

Properties
When properties were first introduced, I read several who described them as simply syntax sugar. While they didn’t initially add much of anything that couldn’t already be done in the language before, they did yield one important feature: generated code. The code necessary in a setter, in particular the releasing of a previous value and setting the new value, was often fraught with errors. Despite code examples on a proper setter from Apple, I saw several cases where a setter failed to release the previous value, or retain the new value, or more commonly, do those two in the correct order. Enabling the compiler to generate this code for the programmer removed many of these errors.

Private Properties
In Java, a programmer can declare a private instance variable and subclasses cannot access it. Furthermore, a subclass can define its own instance variable with the same name and it will be completely separate from the parent’s instance variable. While private instance variables are supported in Objective-C, a child cannot create an instance variable with the same name. Fortunately, an update to properties did bring a way to accomplish the same thing.

A programmer can declare an interface in the .h file, then declare another interface in a class continuation in the .m file. Any properties declared in the .m file will not be visible to other classes, including subclasses. Combine this with the fact that you can create properties which are tied to instance variables which are not declared in the interface, and one can create private instance variables which are not visible to a subclass. There is one caveat though: If a parent class declares a property and a child of that class declares a property of the same name, the “private” property in the parent and the one in the child both reference the one in the child. On the other hand, referencing the instance variable generated by the property references different instance variables, even if the parent and child use the same name.

This little quirk can cause some interesting effects for one who is not aware of how the properties truly work. Accessing properties call selectors, and if a child declares the same property name, it synthesis selectors with the same name as the parent, thus overriding the parent. So, if you wish to have private instance variables which are inaccessible to a subclass, use a property declaration and access the instance variable. Be aware, due to the dynamic dispatch nature of Objective-C, one can still call the setter/getter selectors for the property which cannot be made private. If this is truly a concern, simply override the generated versions to do a different action.

Here is an example of a truly private instance variable.
.h file:

@interface Parent : NSObject
@end


.m file:

@interface Parent ()
@property (strong) NSString *name;
@end

@implementation Parent
@synthesize name = name;
- (id)init
{
    self = [super init];
    if (self) {
        name = @"Parent";
    }
    return self;
}
@end

Do the same in a child class, and you can see that the name instance variables in the child and parent are in fact, distinct.

Blocks
I've derided Objective-C before for its lack of inner classes, but with blocks, it is possible to essentially create an anonymous inner class with a single function. This effectively implements the Java equivalent of Runnable or Callable. I'm not going to go into too much detail, as anyone whose really used inner classes before knows how powerful they can be, but I figured it'd be important to point out that Objective-C has at least obtained some form of inner class. I would like to add that the fast enumeration with a block is really nice because in casses where a programmer needs the index of the current object, the block is given this information instead of having to track it manually.

BTW, I do know a technique for creating an inner class with multiple functions out of a block, but it's just not worth it.

Collection Syntax
I cannot count the number of times I've used [NSArray arrayWithObjects:@"first", @"second", nil], but now Objective-C brings a nicer way to do this: @[@"first", @"second"]. Yes, it is simply just more syntax sugar, but it is really convenient. Note, dictionaries have the same thing, but it is @{@"key":@"value"}

ARC
I saved the best for last; ARC is a big improvement for Objective-C. Not only does it remove a lot of the tedious nature of tracking retain/release, but it also introduces a few new constructs. If one wanted to override the setter for a property, the issue of retaining the new value, releasing the old, and getting the order correct is completely eliminated; ARC does all this busywork for you. Additionally, ARC generates a hard error if a programmer tries to call a selector which is not visible in the current context. So, in the example above, the selector name is implemented by the @synthesize, but it is not declared in the interface. Before ARC, a programmer could go ahead and call it anyway, such as [parent name];, and the compiler would generate a warning but it would work. With ARC, this generates a hard error because ARC needs to know if the selector returns a retained value, an autoreleased value, or no value at all. I view this as a good thing because I have known a few programmers who would call selectors not visible in the current context and then proceed to ignore the warnings. Most of these were simply forgetting the appropriate #include, but in cleaning up these warnings, I often found misspellings just bidding their time, waiting to get executed, so they can spring into action and throw an exception brining down the program. Now, these warnings are errors, so in cleaning them up, programmers should find their true errors more easily and correct them sooner.

ARC also brings in weak references. Just like assignments, weak references do not prevent an object from being deallocated. They are different from assignments in that weak references will never give you an instance which has ben deallocated. I should add that weak references are not as powerful as the ones found in Java, but they do give most of the functionality. I had the task of trying to create a dictionary which holds the objects weakly, but since the keyspace is quite large, it also needs to clean itself up when the objects are deallocated. In Java, this can be accomplished with ReferenceQueues, but Objective-C is missing this feature. I did managed to come up with a more convoluted solution that works, but it's not as pretty nor easy.

Interestingly, ARC now marks the third memory management model for Objective-C. The previous, GC, is now deprecated. I wonder how long till a new one replaces ARC. Maybe it'll be ARC-GC, which combines ARC and GC and eliminates the whole problem of strong cycles.

Conclusion
While I've listed several places for Objective-C's improvement before, it is not remaining stagnant. While I still contend that Java is the superior language, Objective-C does have the ability to change this. I should like to see the language improve even more so it can retain it's position as the most popular langage for years to come.

In the debate between Mercurial and Git, I’ve long held the side of Mercurial. This is mostly due to the fact that Mercurial’s commands are far easier to understand, but I’ve also liked the fact that Mercurial doesn’t encourage rewriting a repository’s history as much as Git does. This has encouraged me to seek to use Mercurial as my favored DVCS, but that’s now changing.

Mercurial has a tremendous advantage in that it’s command structure is easier to understand. I’ve enjoyed this feature having come from SVN, and every time I have to use Git, it makes me want to scream (and has literally made me do so one a few occasions). The usability of the command line is severely relegated when one starts to use tooling present in IDEs, file browsers, and other UIs. In this case, one needs only to go to the command line for very advance operations, in which case both DVCSs require looking up the command structure to understand how to accomplish the task.

So, how does the tooling compare? I primarily use Eclipse for my development, but I also sometimes use Xcode. I was told by an Eclipse committer, well over a year ago, that the tooling in Eclipse is better for Mercurial than it is for Git, but the Eclipse Foundation had elected to switch to Git (from CVS). I wasn’t actually using either but I didn’t like Git at the time (since using it nearly always required the command line). Lately, at work, we’ve been using Git more and more, mostly due to Eclipse using it. As a result, I’ve become familiar with the tooling in Eclipse. Today I decided that I was going to convert one of my Eclipse-based projects from SVN to a DVCS. I tried out the Mercurial tooling and found it significantly lacking. I decided, that despite the difficulty in the command line, Git would be a better choice since it has less difficulty in the tooling. Lastly, with Xcode, Git is built-in where as Mercurial is not.

So, where does this leave the Mercurial v. Git debate? It looks like Git is going to end up being the clear winner, simply for the fact that Git appears to have better tooling for developers. Git’s command line for basic functionality is atrocious (“git reset –hard HEAD .” vs. “hg revert .” anyone?), but in the presence of good tooling in the IDE, the basic functionality accessing a menu item. Additionally, Git’s shortcomings in the command line can be partially mitigated with aliases (I’ve already made one for revert), though this still doesn’t solve the confusion between fetch and pull. So, with a good GUI to cover up the lousy CLI, Git has finally become a viable alternative in my mind.

PS. For those wanting a laugh, read Git is MacGyver / Mercurial is James Bond (Ok, that’s not really the title but it should have been).