more info ⬇

@amattn

subscribe for more
stuff like this:

SW engineering, engineering management and the business of software



2014 04 02

Useful Objective C Macros

A short treatise on snippits of indispensable utility.

Four broad categories of macros end up useful enough to find a home in the highly coveted precompiled header file.

  1. Convenience
  2. Logging
  3. Assertions/Sentinels
  4. Utility

For the sake of brevity, just the names of the macros are listed here, but you can find the full source at https://github.com/amattn/AMNGlobalUtilities/blob/master/GlobalUtilities.h

Convenience/Utility Macros

You should have your own set of useful macros that tend to follow you around. These are the one useful enough that I bring them along to new projects.

// Quickly make an NSError
#define AMN_QUICK_ERROR(error_code, error_description) 

// Quickly get portrait mode
#define AMN_ORIENTATION_IS_PORTRAIT 

// Profiling Macros
// Will log total time elapsed as from START_TIME to CHECK_TIME within a method.  The tag must be equal.
#define AMN_START_TIME(tag)
#define AMN_CHECK_TIME(tag)

Log Macros

Debugging is great. But sometimes you need log statements to get a better sense of flow through code. LOG_OBJECT and LOG_METHOD in particular get lots of usage.

These implementations not only log the value of the variable, but the name of the variable as well. LOG_OBJECT(self.id) prints out:

2013-05-08 11:52:45.615 ExampleApp[71311:c07] self.id 3716426951 SomeController.m:91

There exist variations that are far more flexible, but I prefer being explicit about type.

// standard types
#define LOG_BOOL(object)
#define LOG_CHAR(object)
#define LOG_INT32(object)
#define LOG_UINT32(object)
#define LOG_LONG(object)
#define LOG_ULONG(object)
#define LOG_INT64(object)
#define LOG_UINT64(object)
#define LOG_FLOAT(object)
#define LOG_DOUBLE(object)

// platform dependent
#define LOG_INTEGER(object)
#define LOG_UINTEGER(object)

// Various Cocoa/Objective-C log macros
#define LOG_OBJECT(object)
#define LOG_KIND_OF_CLASS(object)
#define LOG_METHOD
#define LOG_END_METHOD
#define LOG_METHOD_NAME
#define LOG_METHOD_THREAD
#define LOG_CLASS_METHOD

// Various Cocoa struct log macros
// NSRange
#define LOG_RANGE(range)
// CGPoint
#define LOG_POINT(point)
// CGSize
#define LOG_SIZE(size)
// CGRect
#define LOG_RECT(rect)
// CLLocationCoordinate2D
#define LOG_COORD2D(coord)

Assertion/Sentinel Macros

Assertion macros are very good for tightening up extremely rare edge cases. You shouldn’t be using assertion as general error handling in Cocoa. In fact, you shouldn’t be using try/catch at all in most Cocoa code; it is not idiomatic. However during development, macros such as ASSERT_IS_CLASS, SHOULD_NEVER_GET_HERE, and ASSERT_NOT_NIL represent a quick, readable way to explicit about intention and also noisily alert during testing.

This particular implementation first prints out an easy to spot header, then follows up with file, line number, object info and an indispensable stack trace.

If you’d like support in the debugger, “Show Breakpoint Navigator”, click the little plus in the bottom left of the window, and then “Add Exception Breakpoint…”. The default values will then cause the debugger to pause upon encountering any assertion.

// Standard Assertions
#define ASSERT_NIL(x)
#define ASSERT_NOT_NIL(x)
#define ASSERT_ALWAYS
#define ASSERT_TRUE(test)
#define ASSERT_FALSE(test)
#define ASSERT_WITH_MESSAGE(x)
#define ASSERT_TRUE_WITH_MESSAGE(test, msg)
#define ASSERT_FALSE_WITH_MESSAGE(test, msg)

// Useful, protective assertion macros
#define ASSERT_IS_CLASS(x, class)
#define SUBCLASSES_MUST_OVERRIDE
#define SHOULD_NEVER_GET_HERE

Utility

Lastly, just a couple of utility functions that are too useful to leave out. This is kind of a junk draw to be honest.

// Unabashedly cribbed from Wil Shipley (of Delicious Monster fame)
// http://www.wilshipley.com/blog/2005/10/pimp-my-code-interlude-free-code.html
static inline BOOL isEmpty(id thing)
// UUIDs are uuuseful.
static inline CFStringRef createUniqueString(void)

Again, you can find the full source at: https://github.com/amattn/AMNGlobalUtilities/blob/master/GlobalUtilities.h

2014 04 21

Notes on Chapter 1 of Authority by Nathan Barry

I was fortunate enough to receive a hard copy of Nathan Barry’s Authority. I’m going to try something new and post notes on the chapters as I read. If you want a quick recommendation, the answer is: Yes, you should buy this book.

Chapter 1: On Writing

An interesting side-note the author just threw in there:

Rather than having to continue high school for a set number of years, I was given a fixed amount of schoolwork I needed to complete to graduate. I saw that as a checklist and dove in.

If I recall correctly, he finished high school by 15 or 16 years of age.

Reading in between the lines, the author starts the book off talking about writing. Specifically, when to write (consistently) and what to write (write so that people learn). There is some incidental contact with the whys of writing, but later chapters delve more on the whys & hows of writing.

2014 04 23

Developer Catnip

At some point, nearly every new datastore, programming language or pre-launch platform has been placed on a pedestal of glory somewhere on the internet. These glory stools often show the tech enveloped with rays of sunshine and perfectly placed drops of morning dew highlighting the ideal surface. Every new tech needs promotion to flourish. Yet indiscriminate adoption of solutions that seem relevant to your pain points typically results in that feeling you get when you bite into a warm soft chocolate glazed donut with rocks inside of it. The short-sighted lusting of new hot tech ends up resembling some infernal combination of The Grass is Greener syndrome and blind faith pseudoscience.

It could also be reduced into a somewhat destructive form of optimism.

Your knowledge of your own toolset includes all the warts and melancholy involved with the realities of software development. The difficult-to-source internet quote: “comparing your behind-the-scenes with other’s highlight reels” comes to mind.

When we believe that a new tool will solve all our problems, we fall into the trap of optimistic information asymmetry. We read the blog post or listen to the 45-minute conference talk on how successful a person was in a specific situation, but rarely do we get an equally detailed and realistic discussion on the slope of their learning curve, the anti-patterns or the other myriad of pitfalls.

What does this mean? Should we never use new tech? Of course not. Otherwise, we would be using giant stone pillars for calendars and writing webapps via CGI scripts in perl.

Skepticism, not Cynicism

Optimism is critical to making progress in the face of incomplete information. However, it must be tempered with a healthy dose of skepticism. It is equally important to avoid the pitfalls of cynicism. The Skeptic’s mind can change in the face of evidence. The Cynic is just a narrow-minded pundit who thinks everything sucks.

Remember that unless you are hunting werewolves, there are no silver bullets.

Do your due diligence. Look for that evidence. Allocate time and manpower for research. Talk to experts or other people who have used the  catnip   new hot tool/language/environment before. In the age of Twitter, you can usually talk to the people who made the new hot thing.

As the evidence and your familiarity grows, start with small trials of isolated components. Don’t start a company and broadly proclaim that technology X will be the foundation of your new empire – unless you are competing with whatever I do. In that case, please do so. I also have more hot technologies you should know about.

Lastly, always factor in the risk/reward ratio for any new tech. Do the calculus on age, reputation and usefulness of the project. Use your best judgement. Measure the after-effects and don’t be afraid to change course.

Don’t skip the measure part. It is unequivocally the most important part of the feedback loop. Your job is not to use the hot tool - your job is do the best possible work you can.

The internet laughs at the world’s drug-addled cats, not with them. Don’t be a drug-addled cat developer.

2014 04 25

Notes on Chapter 2 of Authority by Nathan Barry

Continuing my experiment of publishing notes on what I read. Previously: Chapter 1.

Chapter 2: Basic Marketing

Before you spend months of your life creating something, you may want to test for some demand.

Content

You’d be surprised how little it takes to become perceived as an expert.

Why Email?

He also goes into detail with two case studies:

Summary

Teaching is Marketing. Test demand. The classic, recommended method is to use a Wordpress landing page on the internet. Write three epic blog posts. That is enough to begin building trust and expertise. Use email as a second-level filter for customer demand. Love email. Dispense with any preconceived notions you have about email. Email has a lot of mechanical and historical advantages.

Other posts in this series:



the fine print:
aboutarchive@amattn
© matt nunogawa 2010 - 2017
back ⬆