Everyone who’s gone through a computer science undergrad has studied these data structures and algorithms in an academic sense. We use at least some of the data structures we learned back then on a daily basis.. lists, queues, stacks, and graphs (to name a few).
A lot of programmers will tell you that they rarely use the algorithms they were taught: merge sort, breadth-first search, binary search trees, etc.. I would be one of those. I believe the number of times I’ve written one of these or a recursive algorithm in general during a professional project is probably < 6 times throughout my entire ~10 year career.
That said! I’ve just completed a pretty thorough review of these computer science fundamentals and I’ve been asking myself if I would have used them more in the past 10 years had they stayed fresher in my mind. And would my code have been better? I can’t answer that for sure, however I do now believe that revisiting these fundamentals from time to time is not only fun… but keeps you sharp.
The primary reason any programmer studies these topics is to be able to design algorithms to solve actual real world problems.
Solving a problem using these concepts requires the ability to:
Understand the problem, input data and expected result
Identify edgecases and test data that exercises those edgecases
Identify the best data structure to represent your data
Identify alogorithmic options that best uses this structure
Identify the efficiencies/tradeoffs of each of those options
Implementing the best one
This is the first in a series of blog posts I’ll write around the above topics. Since anyone who learns these concepts does so to be able to solve actual problems, I want the focus to be on the stages of problem solving, the decisions that need to be made at each of these and the tradeoffs/considerations that come with each decision.
Wow! I’m very excited to release my first major CocoaPod.
What is it?
JiffyLogger is a logging tool that allows you to capture custom events and look at them immediately inside your iOS application.
Logs are stored on the filesystem and writing to the log is buffered and happens on a background thread. Event logging is setup in standard way and is explained further in the ‘Quick Start’ section of JiffyLogger’s github page.
Where JiffyLogger goes beyond your normal logging is it’s in-app viewing and log exporting functionality.
JiffyLogger is obviously not something that you’d release your app with. It’s more a development/field testing tool. It was originally designed to assist with integration of a custom (also under development) bluetooth peripheral.
I developed JiffyLogger while working at goTenna actually. goTenna is custom BTLE hardware device that connects to your phone over BTLE but enables you to communicate with other goTenna users off traditional networks. goTennas setup their own network where communication happens over radio frequency.
At goTenna, we found JiffyLogger useful in the following situation:
goTenna’s firmware engineers used these logs to review BTLE packet and connection information while developing the device’s firmware.
goTenna’s hardware engineers used these logs to recover realtime information regarding various hardware metrics. Temperature, chip settings, etc…
iOS app/peripheral integration
While developing the mobile applications, these logs were integral to implementing the communication protocol agreed upon between the device and app.
Super valuable. Field testing a BTLE device can reveal results quite different from lab testing. For a seemingly infinite number of reasons. We often used these logs to try to understand what was happening in the middle and after the conclusion of a field test.
For more information and to get started using JiffyLogger, head on over to it’s Github page!
I recently migrated my personal blog to Github pages and Jekyll and it was so freaking easy it was really quite shocking. The only real difficulty was was that I had to go around to different sources to find all the information I needed to really make it happen.
I decided to coalate it in one place! This is the that information as of Sept 2015.
This post will cover how to:
setup your development environment
setup github and your website’s repository there
select an existing jekyll theme
overview the jekyll directory struction so that you can make updates to suit your needs
review basic jekyll markdown
overview publishing your website
instructions for linking your domain
##1 - Your development environment.
You need: RVM, Ruby 2.2.3, RubyGems, Jekyll and Bundler. Install as follows:
RVM - follow instructions to install this, once installed, install Ruby 2.2.3
RubyGems - follow instructions to install this, once installed, install Jekyll and Bundler gems
If you want to get off the ground quickly and not roll your own jekyll website from scratch, this is the place to start.
Pick one that works for you. The have themes for personal websites, product websites, service websites…. there are a lot!
Most of them ask you to fork their github repository.. which is fair because that increases their fork count and makes them look good. So, go ahead and fork the one you like. (You could just download or clone it as well.)
Copy the contents of this into the website’s repository you created in step two.
Now you’ll want to run it!
In your terminal, from the directory for this new website, run the following:
If you then go to http://127.0.0.1:4000/ from your browser, you should see the website running on your local machine!
customize the contents of index.html and potentially, header.html and footer.html. (If you want to change things there.)
Pages or page elements are represented with either .html or .md files. Jekyll uses it’s own markdown (which we’ll get to later). The .md files are ones that contain Jekyll markdown But it will just render .html files as well.
All the templates from you download may organize things differently. So you’ll just have to poke around a little to see where they put what.
Many of the templates will give instructions for getting up and running with that specific template. Use those instructions.
##5 Review of Jekyll Markdown
Jekyll do have a good source for this one. Your life will be easier if you use their markdown.
More to fill out here.
##6 Publishing your website.
The way github pages works is the will host basically whatever you’ve pushed on the master branch of you [github-username].github.io repository. So, once you’re happy with it locally, you can commit and push your changes on master. Following this, the website should be viewable at [github-username].github.io.
Whoa! Easy. :-)
As a note, if you’re not ready to push any changes out for the world to see, you can commit them on a branch and push that branch to github and the changes will remain there until you merge them onto master.
Instructions for linking to a domain name.
Once you’re really ready for the world to see your new awesome website, you may want to setup a custom domain name. This is super easy, you just need to add a CNAME file to root of your github repository. Github provide instruction here.
I’ve been working with CoreBluetooth over the last 12 months for my current client, goTenna. The goTenna is a small hardware device that pairs with your phone or BTLE enabled iOS or Android device and allows you to communicate with other goTenna users while off-grid. (The goTenna uses radio frequency to achieve this.)
While at WWDC last week, I was able to get many of our problems in front of a CoreBluetooth engineer and I thought it would be great to document what they said.
These are errors returned after writing a packet to your peripheral’s write characteristic. This error comes in via the following callback
The error happens intermittantly and when you get it, it has the awesomely descriptive text of ‘Unknown Error’.
Apple engineer comments:
This is the peripheral disconnecting during a write (thanks)
This was apparently identified and addressed during WatchOS development and will be available in 8.2+. We should see it less and get a disconnection
When you get it, you should now just the disconnect callback
Happening randomly during a stable connection
Apple engineer comments:
Behind the scenes in CoreBluetooth, there are constant handshakes going on between it and peripheral. What’s likely happening here is CoreBluetooth is not getting a response from one of these handshakes.
Recommendation is to do reconnect logic and attempt to rewrite your data (yay)
Can also gather bluetooth logs and submit them here: https://developer.apple.com/bug-reporting/ios/bluetooth/
Can also debug closer to the bluetooth chip on the peripheral.
Happening immediately following a connection being established
Apple engineer comments:
Occassionally, bluetooth chips can say they are connected when they actually aren’t (great)
Recommendation is to do reconnect logic and an initial write to your peripheral to confirm the connection is established
Happening more often in a heavy bluetooth traffic area
Apple engineer comments:
Yep, it’s a pain, huh? That’s bluetooth for you. (Lol)
No connection can be established
This we observed rarely and a restarting of bluetooth on the iOS device fixes it.
Apple engineer comments:
This was apparently identified and addressed during WatchOS development as well and will be available in 8.2+.
Following being at WWDC last week, and getting lots of introductions to whats new in iOS 9, I thought I’d jot down some of the main areas of interest to iOS developers. There’s some pretty cool new stuff that I can’t wait to dive into and check out.
Can register objects or even placeholders (like a specific view in a specific workflow) in your app as searchable by Spotlight. Saw some pretty cool examples in the media or retail space.
When Auto Layout was first released.. it was a total pain the in ass. Over the last few years, Apple have made improvements to make it easier to use. This is another of these.
It basically allows you to embed many views within one ‘UIStackView’. Previously, you would have had to setup constraints on all the subviews individually as they related to each other and their super view. With stack views, you can tell them how to treat their children without having to set a bunch of constraints on each child.
Sounds great, but will require further investigation.
Many phone or tablet users use these devices for work. Utilizing many apps at a time and switching back and forth.. often quickly and repetitively between the same apps. iOS 9 introduces split view for iPads where you can view two apps side by side.
Also, apparently if your app uses Auto Layout and Adaptive Layout correctly, this is supposed to just work. Pretty cool, but I’d expect to have to do some layout tweaking to allow now both iPad screen sizes to look good.
Definitely a good improvement for users though!
App sizes have grown over the years.. with @1x, @2x, and now @3x image assets, mulitple binaries that are based on the device hardware, ect.. With app thinning, only the resources required for the specific device downloading the app are included in the installation.