- bleve — A modern text indexing library for go.
- Scientific Consensus Has A Bad Reputation—And Doesn’t Deserve It (Ars Technica) — a lovely explanation of how informal consensus works in science. NB for anyone building social software which attempts to formalise and automate consensus.
- TiVo Mega — 24TB of RAID storage, six tuners for capturing broadcasts. Which is rather like building the International Space Station and then hitching it to six horses for launch. Who at this point would make a $5k bet that everything you want to see on a TV will be broadcast by a cable company?
- runswift — an in-browser client for compiling and running basic Swift functionality.
A step-by-step approach to using Swift with Objective-C.
If you’ve got an existing app written in Objective-C, migrating it into Swift is an excellent exercise for learning Swift, experimenting with Swift, and deciding whether to adopt Swift on a full-time basis. I’ve performed this migration with several real apps, so here are some tips culled from my actual experience.
You’re surely not going to translate all your code into Swift at once; you’re much more likely to translate one class at a time. As soon as you add a Swift file to your Objective-C app target, you’ve got a hybrid target: some classes are written in Swift, while other other classes are written in Objective-C. Thus, declarations in each language will need to be visible to the other language. Before you start, it’s a good idea to understand how this visibility works.
Recall that an Objective-C class declaration is conventionally spread over two files: a header file (.h) containing the
@interface section, and a code file (.m) containing the
@implementation section. If a .m file needs to know about a class, it imports the corresponding .h file.
Visibility of Swift and Objective-C to one another depends upon this convention: it works through .h files. There are two directions of visibility, and they must be considered separately.
A brief introduction to Swift optionals.
Swift is becoming the language of choice for more and more developers on iOS and OS X. It’s fast, simple, clean, and has a number of features that simply aren’t available to Objective-C programmers.
While it isn’t a hard requirement to do so, several projects are being ported from Objective-C to Swift — especially those in their early stages — in order to take advantage of the speed, power, and safety of Swift. One of those projects isn’t actually a software project — it’s the upcoming Swift edition of iOS Games Programming Cookbook. When we began updating the book for Swift, the first thing that we had to do was to rewrite all of the book’s code in the new language. However, a straight re-write from one language into another isn’t enough. Swift behaves differently than Objective-C in very important ways, and that means that your ported Swift code needs to be aware of how Swift does things.
Discover, connect, and transmit data between devices.
Multipeer Connectivity is a means of identifying and connecting services together, and allows for very easy passing back and forth of data with minimal setup. If you are thinking that this seems similar to Bonjour, you are correct; however, Bonjour is for service discovery, not connection or transmission. Multipeer Connectivity handles everything in one neat package.
Multipeer Connectivity is comprised of a few different components, but it works by having applications advertise their services asking if anyone is available to connect. The service browser listens for these advertisements and can request to create a connection between the devices. If the connection is accepted, a session is created with every one inside the session being represented by a peer object.
To demonstrate how this works, we’ll make a simple chat application using Swift, Apple’s new language.
Still reflects conventions going back to original adoption of Objective-C
Like many Apple programmers (and new programmers who are curious about iOS), I treated Apple’s Swift language as a breath of fresh air. I welcomed when Vandad Nahavandipoor updated his persistently popular iOS Programming Cookbook to cover Swift exclusively. But I soon realized that the LLVM compiler and iOS runtime have persistent attributes of their own that have not gone away when programmers adopt Swift. This post tries to alert new iOS programmers to the idiosyncrasies of the runtime that they still need to learn.