The next morning, we walked all through Tel Aviv. We started by walking down the pedestrian path on the waterfront to Jaffa, which houses the old part of town. This area is also supposedly the location where Jonah was prior to being swallowed by a large fish. We wandered through a flea market and then back up through town. We walked through a large outdoor market that sold food, spices, and clothing that Pam loved, and then made our way north toward the Tel Aviv port. We had lunch at a restaurant on the beach, and then meandered a bit more and back toward our hotel. From there, we grabbed our bags and headed to the bus station to catch the bus to Jerusalem.

We arrived in Jerusalem in the late afternoon and decided to walk down to the Old City. The walls that surround the Old City were amazing and impressive. Inside, the Old City is also a sight to behold — I’ve never experienced a city like it. The buildings are very close together and at times you’re wandering through tunnels. The “roads” are really just paths/steps that also have small ramps for pushing wheeled carts up and down. This description absolutely does not do it justice, and it’s very hard to describe. European cities frequently felt old to me, but this place felt more like a different time and place, if not a different world.

Walls of the Old City

Inside the Old City

Eventually, we ended up at the Western Wall. For anyone who doesn’t know, the Wall is the last remaining part of the temple built in Jerusalem by Solomon and expanded by Herod. The temple is considered the last known location of the Ark of the Covenant (which held the tablets with the 10 commandments). It is considered one of the holiest places on earth and you can find many people there praying. For someone who considers most of the Bible as less than factual, it was cool to see a piece of still existing history that is a part of many biblical stories. After seeing the wall, we grabbed street food for dinner and then headed back to the hotel.

The next morning, we had a not-so-bright and early wakeup at 3:30am for a sunrise tour of Masada. Masada is a mountaintop fortress that also dates back to the time of Herod and is famous as the location of the last stand of Jewish zealots who were fighting the Romans before ultimately committing mass suicide. We hiked the mountain for what is supposedly an incredible sunrise view over the Dead Sea, but the day was cloudy and we saw no sun. Despite missing the sunrise, the ruins on the top of the mountain were awesome to see and well worth the hike on their own.

Next stop on the tour was Ein Gedi, a desert oasis that contains a number of waterfalls. It is known as the place where David went to hide from King Saul. We did some more hiking there and had a light lunch before hopping back into the tour van to head to the Dead Sea. At the Dead Sea, it was only about 60 degrees, but we decided to brave it and get into the water anyway. Due to the high salinity of the water in the Dead Sea, you naturally and effortlessly float. The mud on the bottom is also supposedly very good for your skin, so everyone rubs the mud all over their body. Overall, it was very cool to experience and the water turned out to not be all that cold.

We hopped back on the tour bus and headed back to Jerusalem. The route back took us through part of the West Bank, which surprised me a bit, but we learned that parts of the West Bank are openly accessible to Israelis. After a quick pit stop at the hotel, we headed back down to the Old City. Once there, we headed to the Church of the Holy Sepulchre, which is revered (but disputed) as the location of the crucifixion and burial of Jesus. The church was beautiful and rivaled almost any church or cathedral that I’ve been to, save St. Peter’s.

While we had seen the West Wall on the previous day, we had not yet seen the Dome of the Rock or the Al Aqsa mosque. I was upset to find that the Temple Mount (the area above the West Wall, where the actual Temple existed and where the Dome of the Rock and the Al Aqsa mosque are today) is closed to tourists on Fridays and Saturdays. Despite this, Pam and I were able to wander a bit into what may have been private residential property, but we got some great views that overlooked the Wall, the Dome, and the Mosque.

The Dome of the Rock, The Western Wall, and Al Aqsa

Finally, we headed back toward the hotel one last time, where we found that the streets had been abandoned and the shops & restaurants closed up for Sabbath. While I was disappointed that our timing prevented us from visiting the Temple Mount, it was cool to see Jerusalem during the Sabbath. When we walked into the Old City, the rest of Jerusalem was still bustling and busy. When we walked out, it was a ghost town. Pretty cool to see.

With that, we started our long journey home. My last major takeaway from the trip is that despite differences and complexities, most people are ultimately the same, just trying to have a decent life and to provide a better one to their children. Our media talks so much about the conflicts between people in the Middle East, but we noticed so many similarities in the people we met — pretty much all good ones. You can find rude people in every country in the world, and you can find friendly ones too. Lumping people together because they happen to live in a particular country or follow a particular religion is not only worthless, it’s probably irresponsible too. It’s hard to remember that in day to day encounters, but trying to do so seems like an unequivocally good thing to do.

The next morning we headed to Souk Waqif, a traditional marketplace that sold clothes, spices, and souvenirs. We wandered around the Souk for a while and bought a hookah to bring home with us. After the Souk, we headed to the W hotel for lunch with Sean and Lara. After lunch, they went to the airport to pick up Sean’s brother, Eric, while Pam and I stopped at yet another mall to pick up a local sim card for our phone (travel pro-tip: if you have an old, off-contract phone, carriers will unlock it for you and you can take it to other countries and buy a pre-paid sim card to get internet access). A bit later, they picked us up again and we headed to Katara, a cultural village area, where we had Lebanese food for dinner. We closed out the night with a couple of drinks at Trader Vics.

The next morning, Sean, Eric and I went to play golf at the Doha Golf Club, where they were preparing for an upcoming PGA tour event. The course was extremely nice, and I hit the ball like I hadn’t played golf in 6 months (I hadn’t). While we golfed, Pam and Lara went for massages. That night, we had an early dinner (or lunch, as the locals call it) at an Indian restaurant and then went to a hookah bar to smoke shisha (flavored tobacco). Lastly, Lara’s cousin Dana took us to the local waterfront hangout, which looked a little (read: very) ghetto, for karak, a sweet, milky tea.

The next day we spent out in the desert, where we rode camels and had a guide drive us through the dunes in his 4×4. He took us on some wild rides up and down the dunes. He called it the “safe” version of the tour, but I think that Pam still lost a few years off of her life. We had planned to ride ATV’s as well, but we called that off due to heavy winds. We made a couple stops on the tour, including one with a view over the border into Saudi Arabia. This video gives you a decent idea of the ride:

After the desert, we were again treated to dinner at Lara’s aunt and uncle’s house, where we had a traditional Qatari meal of chicken and rice. Apparently Qatari food has a lot of Indian influences. After dinner, we went back to the Souk.  Pam had planned to buy one of the decorative plates there, but eventually decided against it. However, a bit later we discovered that Lara’s cousin Dana had gotten it for us as a gift, once again overwhelming us with the amount of generosity and hospitality that we encountered during the trip. We had a night cap at the Four Seasons (all the bars in the country are in foreign hotels, since normal restaurants are not allowed to serve alcohol) before turning in for the night.

The next morning was our last in Doha. We started with a quick boat ride on a dhow for some great views of the city skyline. We then visited the Pearl, a manmade island development, before heading to the airport to catch our flight to Israel.

At the Dunes, Saudi Arabia in the background

Doha Skyline

Over the course of this trip, the thing I’ve enjoyed most is talking to people and hearing their opinions and perspectives on various issues. We’ve talked a good amount about American involvement in the Middle East, the various conflicts in the area, and the general direction of countries in the region. One major thing that struck me is the inherent bias that our expectations seem to have toward maintenance of the status quo. I’m not sure why yet, but we all seem to have an inherent naiveté regarding the potential for (or even inevitability of) change. For example, 15-20 years ago, people in America would probably have had a hard time imagining the legalization of gay marriage, at least on any sort of reasonably short time horizon. Now, states are (thankfully) doing just that. Same story with marijuana legalization. I feel like we’ve run into a lot of similar issues on the trip. No one seems to expect legalization of alcohol in normal restaurants any time soon, but alcohol consumption has already come to the foreign hotel chains and Qatar is creating specialized zones where alcohol is allowed for the World Cup. Is that part of an inevitable march towards relaxing of other restrictions? I’m not sure, and the presence of theistic governments makes it difficult to predict, but it will be an interesting trajectory to watch.

Our first day in Dubai started with an awesome hotel breakfast (including bacon — I couldn’t believe they had it) and walk around the Dubai marina. Everything in Dubai feels (and is) brand new. It is unbelievable how many skyscrapers have been built in the last couple decades. This image gives a decent feel for it:

After walking around the marina, we went to one of Dubai’s famous malls to pick up some essentials, since our bags were still in Amsterdam. The mall felt extremely familiar, even more so than other foreign malls in westernized countries. A huge percentage of the stores are American or western chains & brands. If the signs didn’t also contain Arabic, you could easily convince me I was in an American mall.

One of Lara’s childhood friends, Jamil, picked us up from the mall and we drove onto and around The Palm (a manmade island off the coast of Dubai). After that, we went to The Dubai Mall (one of the largest malls in the world) to pick up our tickets to the Burj Khalifa for the next day, and then ate a late lunch. Once again, I was surprised by the number of American/western chains. We agreed to get a more authentic Middle Eastern meal, but almost had to go in search of a non-western chain. Texas Roadhouse, PF Changs, Red Lobster, just to name a few.  We ended up at a Lebanese restaurant near the base of the Burj Khalifa. After, we argued for a solid 5-10 minutes over who would be paying for it, which is apparently commonplace in the Arab world. I’ve never encountered a group of people who feel so strongly about their hospitality and treating their guests. We then watched a fountain/water show similar to, but larger than, that of the Bellagio. After a pit stop at the hotel, we went to the Burj Al Arab for drinks.The Burj Al Arab bills itself as the only 7 star hotel in the world and is accordingly opulent inside. We tried to visit earlier in the day, but they require a room or restaurant reservation in order to enter the grounds. After heading home, we decided to test out fast food delivery, and had Burger King deliver a late night snack to the hotel before finally getting to bed around 3am.

The next morning, we had a 6:30am wakeup in order to make our 7:30am reservation to go to the top of the Burj Khalifa (the tallest building in the world, designed by Chicago firm Skidmore Owings & Merrill). Views from the top were incredible, and we were surprised at how much undeveloped land there still is in the surrounding area. I imagine that in a few years, that will no longer be the case.   So far, a couple things about the trip have stuck out to me. First, is the palpable feeling of cognitive dissonance. We’re supposed to avoid any PDA, but we’ll walk by a Victoria’s Secret with lingerie openly displayed in the window. Or you think about the amount of anti-American/anti-west sentiment that comes out of the region, but western cars, clothes, and food are very popular among the locals. It’s a little bit hard to describe and not necessarily a bad thing, but it can be difficult to reconcile mentally. I think a large part of it comes from the absurd speed at which the region is developing, and some areas have not yet caught up to others. The second recurring theme that I’ve noticed is the friendliness and hospitality of the people here. American media seems to focus only on the negative sentiments coming out of the region, but all of our interactions have been overwhelmingly positive, both connections through Lara and strangers on the street or in stores/restaurants. We haven’t encountered a single rude person thus far.

In these moments of weakness, I’ve found a simple trick that snaps me out of it and helps me avoid temptation: I turn it into a personal challenge. Instead of playing internal tug-o-war, I ask myself “Am I capable of resisting this temptation? Do I have it in me?” Actively saying those words in my head gives me an instant boost, and I’m usually able to avoid the temptation (let’s be real though, sometimes I still eat the cookie, because cookies really are delicious).

In my opinion, the personal challenge trick works for a couple of reasons. First, it clearly assigns the onus of responsibility. We understand this instinctually and even craft our speech to exploit the concept. For example, imagine a boss who is pressing for an aggressive timetable on a project. His employee might externalize blame for not being able to make the timeline, saying “that timeline isn’t realistic” or “it can’t be done in that amount of time.” He avoids saying “I can’t get it done in time,” because then there is no wiggle room in assigning blame for the failure. Vocalizing a problem as a personal challenge forces you to take responsibility, which provides motivation to be successful.

The second reason this trick works is that it taps into our naturally competitive spirit. For example, last year I co-founded a software development consultancy, Federis Group. By nature, I’m a left-brained code monkey who loves to solve problems with a computer. Being a salesman is not the most natural activity to me. But if I turn it into a personal challenge, my competitive streak kicks into gear. Do I have it in me to go sell our services? When phrased this way, the competitive side of me will always respond, “yes, if other people can do it, then I can do it.”

P.S. If you enjoyed this article, I’d love to hear from you on twitter: @bcroesch

It should come as no surprise, then, that I’ve never particularly cared for going to random events and glad-handing everyone I see. That may work for some people, but isn’t my style. Instead, I’ve found a number of other tactics that better fit my personality.

The Friend of a Friend

Here’s what Chuck thinks of the spray-and-pray approach to networking:

Randomly emailing people in hopes of networking with them is a great way to waste a bunch of time. I’ve had more success with warm introductions (ie. having an existing contact of yours make an introduction). Frequently, my process goes something like:

1. Figure out the profile of the type of person I want/need to meet (e.g. Someone who went to Notre Dame, lives in Chicago, and is involved in the startup world)
2. Google/LinkedIn search until I find a couple people who match said profile
3. Try to find a person who knows both of us
4. Ask that person to make an intro

Step #3 is often the most difficult, but LinkedIn is a great tool for this. If you look at someone’s profile (yes, it will tell them you looked at it – meh), there should be a feature in the right-hand column that shows you common connections. I find these are typically good candidates for an intro. It looks like this:

Once I get an intro, I explain who I am, why they should meet with me (I try to only ask for meetings when I have a reason to meet them, to avoid wasting someone’s time), and offer to buy them a coffee or beer. Some people may end up being too busy, but I’ve found 1 on 1 meetings tend to be much more valuable than going to random meet-ups and dumping business cards on everyone you see. If you have a connection (mutual friend, alma mater, etc.), then most people tend to be willing to help you out.

Your reaction might be “but I don’t want to meet with the scrubs who are one degree separated from me, I want to meet with Internet-Famous-Uber-Person-In-My-Space” (that’s my space, not MySpace). My response would be: If you’re lucky and you demonstrate to the person that you generally have it together, then they might be willing to introduce you to other people they know, and thus your network can start to grow exponentially (and by exponentially, I mean a couple meaningful connections per month).

The Digi-Stalker

They say imitation is the sincerest form of flattery. If that’s the case, the consolation prize goes to digital hero worship, where you excessively stalk the person until you know what bar they went to last weekend, what they ate for dinner last night, and every news article they’ve read in the past month. That way, they will be really impressed with your passion for their personal life and not, you know, call the cops or anything.

In all seriousness, I find that it helps to do some homework about the person’s work and background. You don’t want to make an off the cuff joke at the expense of attorneys/recruiters/punching-bag-profession-du-jour, only to find that the person is or was one. It provides some easy talking points and demonstrates that you’re someone who puts in the work to be prepared.

The Altruist

Patagonia makes top notch outdoor gear and clothes for yuppies who want to appear outdoorsy. Their stuff is high quality and they make good money selling it. What some people don’t know is that Patagonia is also a company that doesn’t mess around when it comes to corporate responsibility. They started “1% for the Planet,” through which they pledge 1% of sales to the preservation and restoration of the environment. They are extremely dedicated to fair labor conditions in their supply chain. In 2012, California created a new corporate structure called a “Benefit Corporation,” which allows companies to legally prioritize social missions over profits. Patagonia was one of the first companies to sign up.

Some people don’t think that profits and social good can co-exist symbiotically within a single entity, but Patagonia shows otherwise. In a similar way, I think volunteering and career-ambition can not only co-exist, but benefit from each other. Many successful people have personal causes that are important to them. I think that volunteering to help out with these causes can have numerous benefits. You get the benefits that most people associate with volunteering. You get to feel like a good person. You get the catharsis that comes with helping others. It’s simply a worthwhile cause and activity. But you also get some other bonuses, such as exposure to the successful people leading the charge. It can be a great way to gain the trust and endorsement of these people, which can help in your other endeavors.

P.S. I’d love to hear from you on twitter: @bcroesch

• New web/app servers
• Database migration
• Application data/image migration
• Email migration
• DNS Transfer
• Day-of Playbook

Our plan called for setting up the new enivronment in its entirety, beating on that environment for a while to work out any kinks, and then having a final cut-over where we actually started pointing the inklingmarkets.com domain to the new servers.

New Web/App Servers

The first thing we did was set up new web/app servers. As part of the transition, we decided to switch from our old apache/haproxy/mongrel setup to nginx/unicorn. In addition to getting onto a newer and hopefully faster stack, this allowed us to cut out the haproxy piece from our puzzle. While installing nginx and unicorn is pretty straight forward, we did run into one application-related snag. When serving up user-uploaded images from the application, our app would add an X-Sendfile header to the response headers. This would result in apache serving the file directly, instead of having the mongrel servers do it. Nginx doesn’t support X-Sendfile, but fortunately it has a similar feature, called X-Accel. So instead of adding an X-Sendfile header, we changed the rails app to add an X-Accel-Redirect header, containing the path to the file.

Database Migration

The database migration and cutover was probably the biggest single piece of the transition. If you’re interested in how we handled it, I wrote up a separate article that covers it in depth, which you can read here.

Application Data & Image Migration

Our app included some user generated images that are saved on disk. To migrate this data, we used rsync. From the destination server, we used a command that looked like this:

rsync -aiv deployuser@source.server.ip:/path/to/images/dir/ /path/to/images/dir/

To minimize downtime at the time of the actual transition, we ran this when setting up the servers to move over the bulk of the files. We then ran it again on the day of cutover, and then again after we put up maintenance pages on our old servers. The subsequent instances only needed to move the changes since the last time we ran the command, so they were fast relative to the first time.

Email Migration

Moving our outbound email was another major piece that merited its own post. You can find it here.

DNS Transfer

When the day of cutover came, we had a number of tasks listed that had to get done, but the one that made the switch “official” was updating our DNS settings to point to the new servers. The process for this, while suspenseful, was pretty simple:

1. Lower the DNS TTL (we put it down to 30 seconds) far enough ahead of time that the old records will expire. (ie. if your ttl is 30 mins, lower it more than 30 mins before you want to make the switch)
2. Once the other tasks are complete and the new servers are ready to start getting traffic, update the A records to point to new load balancer
3. Verify that things are working correctly on the new servers
4. Once satisfied, increase the TTL back to the previous value

Day-of Playbook

If anyone is going through a similar process, there’s a final piece of advice that I’d give. For our migration, we put together a day-of playbook that listed, in sequential order, all of the tasks that needed to be completed. Where pertinent, it included specific commands to run and where to run them. This helped the migration go smoothly and quickly, and I would highly recommend it.

Check the Existing Reputation of the Server’s IP

If you’re using cloud servers, you could easily end up with a recycled IP address that was previously used by another server. And what type of person needs to constantly move to new servers with new IP addresses? Spammers. The first IP that we got for our jobs server turned out to be one that was recently used by someone for sending a bunch of email spam. I used MX Toolbox to check blacklists for our IP, and it was on several. The good news is that we could spin up a new cloud server and get a new IP. I would recommend checking this as soon as you get the IP, before wasting any time on configuring the server.

Set Up an SPF Record

SPF (sender policy framework) records verify that a server is allowed to send email for the given domain. Our new jobs server was going to be responsible for sending our email, so we simply needed to add a DNS TXT record like: v=spf1 ip4:jobs.server.ip.address

For verifying spf records, I found http://www.kitterman.com/spf/validate.html very useful. If you use gmail, you can also open a message and select “Show Original” from the dropdown menu on the right. There should be some SPF info in the headers, which will show if the server that sent the email is designated as a permitted sender.

Set Up a Reverse DNS (PTR) Record

A normal DNS A record points a domain to an IP. PTR records do the opposite, pointing an IP to a domain. Many email servers use PTR records as another signal that the given IP is allowed to send email for a domain and may reject email from servers that don’t have one. These are typically set up with whomever provided you with the IP address (ie. the server provider, in our case Rackspace). So if you send email from a server with an IP of 123.123.123.123 (and your A record is mydomain.com -> 123.123.123.123), then you’d want to set a PTR that points 123.123.123.123 to mydomain.com.

Warm Up the IP

In the email world, there is a concept known as “warming up” an IP address, which was news to me. The idea is that if a new server pops up and starts sending massive quantities of email, it is probably spam. To avoid this, you can gradually ramp up email sending by the new server over the course of several days. This was a tricky piece for us, since we planned to have a single-night cutover where we switched everything from our old environment to the new one. Fortunately, a large proportion of our email was generated by cron jobs. We gave the new jobs server access to the old db server and, over the course of a week, we started turning off cron jobs on the old server and enabling them on the new jobs server. This allowed us to gradually ramp up the volume of email coming out of the jobs server until the day of cutover, when all of our email starting running through it.

If you found this post helpful, I’d love to hear from you on twitter: @bcroesch

The general outline of the plan was:

1. Set up new db server as a slave of the old master
2. Put up a maintenance page for our app and let the new db finish replicating old master
3. Promote the new db server to master
4. Profit!!!

In our old setup, we had one server acting as master and one replication slave. To start, I spun up a new db server, installed the same version of mysql that was running on our old servers, and added firewall rules to allow the new db server to talk to both the master and slave. On the new server, which was going to serve as our future master, I configured it to have binlog on, relaylog on, and log-slave-updates off. In our case, the config settings look like this (log-slave-updates is off by default):

log-bin=/usr/local/mysql/var/newhostname-bin-log
log-bin-index=/usr/local/mysql/var/newhostname-bin-log.index
relay-log=/usr/local/mysql/var/newhostname-relay-log
relay-log-index=/usr/local/mysql/var/newhostname-relay-log.index

With this setup, the new db server can be run as a slave of the old master, but will not log the updates it gets from that replication in its binlog. However, since its binlog is on, it is ready to be promoted to master in the future (ie. when we made the actual transition to it being our production db).

Since the plan here is to have the new server start out as a slave of the old one, I added a replication user to the old server for the new server’s ip. On the old server:

mysql> CREATE USER 'repl'@'new.server.ip' identified by 'repl password here';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'new.server.ip';

Next, I stopped mysql on the new server and set server-id=3 in its config file. In order to get data over to the new db server, I stopped the replication on our old slave:

mysql> STOP SLAVE;
mysql> FLUSH TABLES;
$ /etc/init.d/mysql stop

And used rsync to copy over the mysql data directory from the old slave to the new db server:

$ rsync -avz user@old.slave.ip:/usr/local/mysql/var /usr/local/mysql/var

I then turned the old slave back on and let it catch back up to master:

$ /etc/init.d/mysql start

And to verify the slave there is working (you can run this command twice and Exec_Master_Log_Pos should be increasing):

mysql> SHOW SLAVE STATUS\G

Next, some files in the data dir needed to be renamed and/or updated. MySQL names some of the files according to the name of the host it is on, so they needed to be changed from the old host name to the new one. You’d need to replace newhostname with the name of your server:

$ cd /usr/local/mysql/var
$ mv oldhost-relay-log.index newhostname-relay-log.index
$ mv oldhost-relay-log.##### newhostname-relay-log.#####
$ sudo vim relay-log.info (change path & name of the relay log on the first line to the new location & host)
$ sudo vim newhostname-relay-log.info (change path & name of the relay log on the first line to the new location & host)
$ sudo vim master.info (make sure the replication user and pw are correct)

Once I fired up mysql on the new server, it immediately began pulling updates from the old server, since the data directory was copied directly off our old slave. Now, the actual switch over to the new server.

I put up a maintenance page on our web servers, so that no new requests would go through to the application. Then, I locked the tables on the old server so that no new updates could be made there:

mysql> FLUSH TABLES WITH READ LOCK;

And then waited for the new db server to finish processing updates. You can verify this by checking the process list (on the new server), which should say ‘Has read all relay log.’

mysql> SHOW PROCESSLIST;

I made a copy of the data directory, just to be safe:

$ cp -r /usr/local/mysql/var /usr/local/mysql/var_backup/

And then promoted the new db to master:

mysql> STOP SLAVE;
mysql> RESET MASTER;

After a few other non-db related tasks, we changed our DNS entries to point to our new servers, and the process was complete.

If you found this helpful, I’d love to hear from you on twitter: @bcroesch

Now that we have these deep links, we wanted to be able to share them with people around the web. However, sharing links that look like ffprophets://leagues/22/join is confusing to people and isn’t necessarily clickable/touchable in many cases. To make it easier to share deep links in the app, I added a quick and simple snippet to our nginx config that redirects deep link url’s to open inside the app. It looks like this:

location /deep_link/ {
  if ($http_user_agent ~ iPhone) {
    rewrite ^/deep_link/(.*) ffprophets://$1 permanent;
  }

  rewrite ^/deep_link/(.*) /deep_link.html last;
  break;
}

Now, we can share urls like http://55prophets.com/deep_link/leagues/22/join (download the app, visit this page on your iPhone and try it out!). When people access the url in mobile Safari on their device, it will redirect them to ffprophets://leagues/22/join, which will open in 55Prophets. If they access the page from a computer, it will show them the deep_link.html page, which informs them that the link needs to be opened on a mobile device with the app installed and gives them a link to download it.

P.S. If you found this helpful, I’d love to hear from you on twitter, @bcroesch.

To start, I created a class called ErrorCollection. It is relatively simple and the header file looks like this:

//  ErrorCollection.h
#import <Foundation/Foundation.h>

@interface ErrorCollection : NSObject

@property (nonatomic, strong) NSArray *messages;
@property (nonatomic, strong) NSString *message;

-(NSString *)messagesString;

@end

The implementation is also simple. It looks like this:

// ErrorCollection.m
#import "ErrorCollection.h"

@implementation ErrorCollection

-(NSString *)messagesString{
    if (self.message) {
        return self.message;
    }
    else{
        NSMutableString *str = [[NSMutableString alloc] init];
        for (int i=0; i<self.messages.count; i++) {
            NSString *msg = [self.messages objectAtIndex:i];
            if (i==self.messages.count-1) {
                [str appendFormat:@"%@", msg];
            } else {
                [str appendFormat:@"%@\n", msg];
            }
        }
        return str;
    }
}

@end

Our back-end rails app either returns json in the form of {"errors": ["error1", "error2" ... ] } or {"error": "error message" }. In the case of the former, we want to map each error string in the array to a string in the messages array of an ErrorCollection. In the case of the latter, we want to map the string to the message property of the ErrorCollection. Then, we can use messagesString method, which will give us a single string to present to the user, containing the error message or messages.

To get RestKit to use the ErrorCollection class, we need to add a response descriptor for it. Wherever you set up your response descriptors, add something like this:

RKObjectMapping *errorMapping = [RKObjectMapping mappingForClass:[ErrorCollection class]];

[errorMapping addPropertyMapping:[RKAttributeMapping attributeMappingFromKeyPath:@"errors" toKeyPath:@"messages"]];
[errorMapping addPropertyMapping:[RKAttributeMapping attributeMappingFromKeyPath:@"error" toKeyPath:@"message"]];

[[RKObjectManager sharedManager] addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:errorMapping pathPattern:nil keyPath:nil statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassClientError)]];

Now you can access the error collection in the failure block many of the methods of the RestKit object manager. For example:

[[RKObjectManager sharedManager] postObject:someObject path:@"/object_path" parameters:nil
  success:^(RKObjectRequestOperation *operation, RKMappingResult *mappingResult){
      // handle success
  }
  failure:^(RKObjectRequestOperation *operation, NSError *error){
      ErrorCollection *errors = [[[error userInfo] objectForKey:RKObjectMapperErrorObjectsKey] lastObject];
                
      NSLog(@"%@", [errors messagesString]);
  }];