In an attempt to understand the technical side of the cryptocurrency craze, I read the book, Bitcoin and Cryptocurrency Technologies (http://bitcoinbook.cs.princeton.educeton.edu). It was a great book and I’d highly recommend it. What follows is somewhat of a book report on the beginning chapters, a look under the hood at what a blockchain is.
There are a lot of APIs out there, a lot of networking layers, a lot of abstractions, I’m going to offer just one way to start building Swift models backed by a RESTful API. Out of personal preference, PromiseKit will be used instead of callbacks and ObjectMapper will be used to convert between JSON and Swift objects.
When building an iOS application there are times when the best solution for a particular view or screen is to build it as a webpage and then embed it into the app using a UIWebView. There are certain things a webview can do really well that are otherwise hard to replicate, and while not as sexy, web development can be much quicker than native iOS development. The specifics of when to use a webview and when to go native I won’t dive into, but if you decide to use a webview, the first major question you’ll probably wonder is how to communicate between the native app and the webview. For full integration into the app, being able to send messages from the JavaScript to Objective-C and back is critical, and luckily it’s quite easy.
In addition to outputting lots of useful information, the Rails logger can be a useful debugging tool. But debugging with the log file can become frustrating as it will be cluttered with default content. The solution to this problem is to create a custom logger and log file for such output.
The easiest way to do this is to create a global log function, enable it in your development environment, and make sure that calls to it don’t do anything in other environments.
Much of programming is writing code with an obvious solution, it’s being a code monkey. You lay things out, you move them around, you wire it up, but you don’t really need to stop and think. I’d estimate that everyone is about equally good at this. But some of the work is also spent solving problems you’ve never seen before. This is where bugs are introduced, bad decisions are made, schedules are thrown out, and things go wrong. These problems are the really defining part of being a great programmer.