Archive for the 'Debugging' Category

Much Faster CryptoJS SHA1

May 17th, 2014
Spencer Nielsen Follow snielsen42 on Twitter

400px-SHA-1

SHA1 is a pretty crucial part of my current startup, Ultralink. We need to be able to have (relatively) decent uniqueness calculation and change detection and need to be able to do it really quickly on a lot of content. We picked SHA1 because it is widely supported, simple to implement and fast. For the portions of Ultralink that run in Javascript, we needed to include CryptoJS, a third-party library. CryptoJS appears to be the go-to library for cryptographic functions in Javascript and seemed to fit our bill perfectly. Development was humming along and everything was fine. We would occasionally do performance passes and stress tests on desktop web browsers and the SHA1 calculation wasn’t even on the radar for perf offenders. Once we started taking a look on iOS devices though, specifically Mobile Safari, then it was a completely different story… (more…)

Proxying on iOS 7

January 27th, 2014
Spencer Nielsen Follow snielsen42 on Twitter

tethering

A large number of the world’s wireless carriers enable internet tethering by default for no extra charge when using an iPhone (because data is just data after all). In the United States, no major carrier has had the good sense to do it even with data caps and throttling. Any way you look at it, paying for tethering is a bad deal. So what then are your options when you want to use your phone’s internet connection on your laptop? You can always jailbreak and enable iOS’s built-in tethering (marketed as “Personal Hotspot“) using a tweaked carrier profile or install a stanadlone tethering app. However, jailbreaking has known risks associated with it and some US carriers have stated that they will cut your service if they detect tethering without the requisite contract on their end (exactly what detection methods they employ and how much work they have invested in enforcement remains unclear). What then are we left with? Proxying. (more…)

CloudFlare as a DB Read Cache

September 14th, 2013
Spencer Nielsen Follow snielsen42 on Twitter

cloudflareBadge400

CloudFlare is a popular, DNS-level proxy service that has layered on tons of useful features over the years like asset optimization and denial of service attack mitigation. Probably the most prominent service they provide though is caching. This caching functionality is primarily geared towards webpage content. Out of the box, CloudFlare’s caching settings work great and it intelligently decides what kind of files to cache (images, css, javascript) and what not to cache (html or other files that could contain dynamic content). You can tune CloudFlare’s settings to fit your specific needs and do a lot to lighten the load on your server. I started to think about all the interesting things I could do with a distributed caching layer that sits in front of my servers. I was designing the back end of ultralink.me at the time and thought: “Gee, CloudFlare might actually make a pretty decent read cache!“.

Now I have to start this article with some caveats. Using CloudFlare in this manner will not solve all your problems or even be appropriate in many cases. But if you do have a certain kind of workload and can expose the interface to your database in a specific way, it can really do a lot to absorb your database read traffic. (more…)

Present.app

December 30th, 2012
Spencer Nielsen Follow snielsen42 on Twitter

Both my own siblings and my wife’s siblings have had a Christmas present exchange for the past couple of years and although the gifts are never extravagant, we always try to make them thoughtful. This year we thought it might be fun to give our siblings a choice of which present they wanted. We thought of making a card with the various options printed on it but then I came up with the idea of making a custom app that could serve the same purpose.

But I didn’t want it to simply be a card analog. It would have to take advantage of some of the unique features of iOS and do things that a normal card could not. Maybe we could somehow sneak it on to their iPads without them even knowing and surprise them with it! I was really excited about the idea and so I immediately sat down and started cranking it out. Thus, Present.app was born. (more…)

iOS 6 Predictions

March 6th, 2012
Spencer Nielsen Follow snielsen42 on Twitter

It is always fun to try and guess what Apple is going to do next. You can guarantee that there will always be surprises and sure bets, letdowns and magical moments. The Apple rumor sites do a decent job of soliciting leaks, reading between the lines and making educated conjecture. As a developer, I often like to take a good look at where Apple’s technology is right now and make logical extrapolations as to where things are headed. Oftentimes, when Apple announces some new feature or technology it seems obvious in retrospect if we had only connected the dots. Based on 2011′s release schedule, it is a fair bet to say that Apple is going to announce iOS 6 at WWDC sometime this summer and distribute a developer beta. That means that in the coming months little trickles of information are going to get doled out to the rumor sites about what kind of changes and additions we can expect. Just for fun, I wanted to get my own predictions out in the open before any of that started. Here is my very developer-oriented prediction list of what we might be expecting in iOS 6.


UPDATE: WWDC and the iOS 6 beta have come and gone. Some of my predictions now have conclusions. You will notice however that most of the predictions have not yet been updated. That is because there is the potential for Apple to be keeping a few more surprises up their sleeve for the fall when iOS 6 goes GM. Inline below are the results so far.


UPDATE2: iOS 6 GM is here which means that the NDA has lifted! Check down below to see how well I did. (more…)

Death to .DS_Store

December 24th, 2011
Spencer Nielsen Follow snielsen42 on Twitter

The “.DS_Store” file is an abomination and must be stopped. You know what I’m talking about. I regularly rant about how this annoying file gets in your way, dirties things up and just screws with your stuff in general. Today I decided to do something about it. Before we get to that, lets quickly review what it is and why it sucks.

What Is It?

The .DS_Store is a Finder metadata file created primarily by Mac OS X’s Finder.app. Because of the dot (“.”) prefix it is typically not visible in many file browsers and most Mac OS X users are probably not aware of it. It is regularly created when the Finder accesses filesystem directories. It contains directory information about icon locations, view options, silkscreen configuration and the like. The functionality that it provides is moderately useful, but becoming less and less relevant over time. In any case, a long time ago the horrible decision was made to store that Finder metadata in an actual file (.DS_Store) in the filesystem within the relevant directory. We have been paying for it ever since. Over time more and more metadata relating to files and the filesystem has been added to Mac OS X, but thankfully those have been stored in saner places (extended attributes, etc). For the time being though .DS_Store is still here with us and still causing trouble. What’s so harmful about the file you might ask?

(more…)

Zurp 1.0 Postmortem

December 15th, 2011
Spencer Nielsen Follow snielsen42 on Twitter

Last September I wrote a blog post introducing Invader Zurp which revealed a little of the back story on how I came upon this new game idea after it’s first 2 months in development. Fast forward to 3 months later and Invader Zurp had just hit the App Store! I thought it would be useful to sit down and review the last 5 months of development, kind of plan out where I want to go from here and go over the events and insights that I thought were most influential during development.

The Story So Far…

So to recap the original blog post a bit, it was the middle of the summer (2011) and I had been working my brains out on Cannonade for the previous 6 months. I was a little discouraged at that point because progress wasn’t coming quite as quickly as I had hoped. Reception from my testers (just friends and family at that point) hadn’t been as positive as I had wanted either. I still had a very clear vision of what I wanted Cannonade to be and still believed that there is a ton of untapped potential for multiplayer-only games on iOS. But there was only so much I that could do as a one-man team and testing a multiplayer game can be quite time consuming. I took the family on vacation in early July and was able to step away from things for a while. It was then that I got an idea for a single player experience that distilled the core gameplay mechanic of Cannonade down to it’s essence. Thus Invader Zurp was born. Within two weeks I had modularized the Cannonade game engine, re-written the graphics sub-system in OpenGL ES 2.0 and had a working prototype. And it was fun! I found myself on very long “testing” sessions playing even after I had verified my fixes. I seeded the first alpha version in early September and wrote the introductory blog post. Then began the journey of finishing the game and kicking the darn thing out the door. (more…)

Application-Specific Bullet Physics Optimization

December 13th, 2011
Spencer Nielsen Follow snielsen42 on Twitter

In developing Cannonade and Invader Zurp I have invested a fair amount of time becoming familiar with the Bullet Physics Library and trying to milk every bit of performance out of it as I can. Realistic physics simulation plays a crucial part in both games and is also the performance bottleneck in the majority of gameplay scenarios with both. When trying to optimize for performance I generally see myself using two kinds of approaches. One is a higher level algorithmic approach that tries to see ways to create less work or avoid work in order to keep things going fast. Once I have nailed down as best I can, the minimum set of work that I really cannot avoid doing, then comes the work of getting down and dirty and speeding up the routines that actually do that work. When I initially approached the problem of speeding up Bullet, I first simply treated it as a black box (work that I wouldn’t be able to avoid) and explored what kinds of compiler configurations I could leverage to create the fastest possible execution of the physics simulation work. Later, after I had nailed down the gameplay mechanic for Invader Zurp I was able to start specifically attacking the set of physics simulation work needed for the game and whittled it down to a much smaller amount using some simplifications, accuracy compromises and psychology.

(more…)

Invader Zurp Progress

October 27th, 2011
Spencer Nielsen Follow snielsen42 on Twitter

Above is some footage from the current Invader Zurp alpha (apologies for the bad exposure). As you can see, things have come quite a ways since I released the first video! There are a lot more visual effects, 5 music tracks from Monte ‘Trance’ Emerson, a new gameplay mechanic, an in-game currency system and tons of other little advancements. I must say that I feel like things are progressing quite nicely! I still have a ways to go though and so I am going to continue cranking away with my head down until it is finished.

What are your thoughts on how development is going? Let me know in the comments. Also, a huge thank you to all of my testers who have given me invaluable feedback on all the builds thus far.

iPod Touch Server: iOS 5.0 Edition

October 12th, 2011
Spencer Nielsen Follow snielsen42 on Twitter

Achievement Unlocked: iOS 5 NDA

In a previous blog post I outlined my need for an iOS server. I had found a sufficient but non-optimal solution for iOS devices running iOS 4.X. I mentioned at the end of that article that I had found an optimal solution utilizing some new features in iOS 5. Now that iOS 5 has gone gold master and the NDA has been lifted I can outline in detail how to get your own iOS server up and running. To review, the three requirements for setting up a server in my situation are that it must:

  1. Be able to receive push notifications (so it can get it’s work)
  2. Have it’s display turned off (to save energy and avoid things like screen burn-in/fatigue)
  3. Require no human interaction (needs to be completely autonomous)

In the previous article I outlined why these were in conflict with each other on iOS 4 devices. However, there is some new functionality and behavior policies that allow all three requirements to be fulfilled.

(more…)

Entries (RSS) and Comments (RSS).