Before you run off and make a framework, it can be helpful to do a bit of brainstorming and plotting or scheming first. For this part I pulled out a sweet notebook and my fancy pencil. After some doodling and discussion with a friend of mine, I came up with this:
I wanted the idea of a channel to be a first-class object rather than an interface where you send along the channel name as a string and say "hey send this message to this channel". Directly having a channel object to send messages to sounded nicer to me.
With this vague idea in mind, I started writing tests. This way I could work out exactly what the API would look like by attempting to actually use the API.
After some debate with myself and discussion with a friend, I wrote a test to flush out the API I planned:
func testConnectingToServer() {
let user = IRCUser(username: "sgoodwin", realName: "Samuel Goodwin", nick: "mukman")
let server = IRCServer.connect("irc.freenode.org", port: 6667, user: user)
struct ServerDelegate: IRCServerDelegate {
}
let serverDelegate = ServerDelegate()
server.delegate = serverDelegate
let channel = server.join("clearlyafakechannel")
struct ChannelDelegate: IRCChannelDelegate {
}
let channelDelegate = ChannelDelegate()
channel.delegate = channelDelegate
channel.send("Hey sup everybody")
}
A user needs a few different pieces of identifying information, so I grouped them into an IRCUser struct. Next I identified the two important conceptual pieces: a channel and a server. In most IRC apps, you're able to connect to multiple servers and join multiple channels. I thought treating each one as a separate object would be easier to work with than having a single global object and needing to use functions that say things like, "Send this text (a string) to this channel (also a string)" and to have delegate methods that say things like, "You got this message (a string) from this channel (also a string)". Whoever uses this library later would have to do more work to keep up with which channels and servers a user is connected to and I didn't like that so much. With separate objects, a developer could hand each channel and server object to a different controller responsible for displaying the information from that one object. It was also reassuring to know that this doesn't need to be permanent. I can change anything later and I'll have tests to be confident it still works.
Of course this test won't even compile right away. I needed to make the classes and protocols mentioned in the test so the compiler wasn't sad they don't exist.
struct IRCUser {
let username: String
let realName: String
let nick: String
}
class IRCChannel {
var delegate: IRCChannelDelegate?
func send(_ text: String) {
}
}
class IRCServer {
var delegate: IRCServerDelegate?
static func connect(_ hostname: String, port: Int, user: IRCUser) -> IRCServer {
return IRCServer()
}
func join(_ channelName: String) -> IRCChannel {
return IRCChannel()
}
}
protocol IRCServerDelegate {
}
protocol IRCChannelDelegate {
}
At this point I only filled in the minimum required bits. This wouldn't actually do anything, but the shell of a working thing was there. Now I just needed to cram some innards in there and make it walk.
This is a continuation of the article published yesterday: How To Write IRC: Part 2 Defining the API Before you run off and make a framework, it can be helpful to do a bit of brainstorming and plotting or scheming first. For this part I pulled out a sweet notebook and my fancy pencil. After some doodling and discussion with a friend of mine, I came up with this: I wanted the idea of a channel to be a first-class object rather than an interface where you send along the channel name as a string and say "hey send this message to this channel". Directly having a channel object to send messages to sounded nicer to me. With this vague idea in mind, I started writing tests. This way I could work out exactly what the API would look like by attempting to actually use the API. After some debate
This is a continuation of the article published yesterday: How To Write IRC: Part 1 Spike! When I write a framework, I don't start by making a framework. First I mess around and build what you might call a "spike" to get an vague idea how things work. I was fairly familiar with the IRC protocol when I started, but not this new API from Apple. Writing something right off the bat with tests is quite difficult if you're not even very sure what you need to make your code do. After some time to play around, I had a better sense of direction and could be confident writing tests. Walking Skeleton Last thing I needed before I could write any tests was the skeleton of an app. You can see what I wrote in this initial commit on Github. Mostly it is Xcode's new-project template for a Mac app,
IRC is a fairly old protocol for chatting with people on the internet. It's not super popular these days because even more technical people have migrated to things like Slack or Hipchat which may or may not be more friendly to use. Still, I decided to try to write a library for interacting with IRC for a few reasons: I think a big reason for Slack/Hipchat popularity over IRC is the clients. Every IRC client I've ever tried seems fairly technical and does not try to simplify the experience very much. The library and my writing explaining it can serve as nice example of how to make a framework and how to write Swift in general using tests. Even if it never gets used in an exciting IRC client. The library can also serve as an example for implementing support for an internet protocol that isn't already supported for
In the next chapter of the tutorial, I went through the steps to enable raw mode. In a typical command line app, you print some things on the screen and maybe wait for input for the user on the next line. The terminal is setup by default to send your program this input one line at a time which means waiting until the user hits return/enter. For a text editor where we want to handle things like keyboard shortcuts and special characters, this isn't good enough. Fortunately, the terminal can be told to change its behavior and send each individual keypress to your program one at a time. Unfortunately, it takes several steps to do this. Also, since you're changing the behavior of your terminal for your program, you need to make sure you turn the settings back to normal when your program is done. Many of the functions
There's a bug with Core Data such that if you have two entities, A and B, with a one-to-one relationship between them, that relationship will not be setup properly. This bug doesn't care wether you do your work in Objective-C or Swift or both. The steps to reproduce are as follows: Create two entities, one A and one B. Give each a property, such as name. Add a one-to-one relationship between the two. Generate the class file for each by any method you wish. Doesn't matter which. In your app, create an instance of each and link them by their relationship property. let context = persistentContainer.viewContext let a = A(context: context) a.name = "I'm alive" let b = B(context: context) b.name = "I'm also alive" a.thing = b try! context.save() Fetch all A entities and print out their B's. Do the same the other away around too. let context
Some time ago, I read about AntiRez writing a text editor in C. This dude is pretty hardcore in C and does things like maintain Redis, an in-memory database nearly every startup you ever heard of is using or will soon use. It was super cool to flip through and read about the editor. I was especially impressed by his ability to add search and syntax highlighting even. Some time later, Snaptoken wrote a very thorough tutorial explaining how to make the editor step by step instead of browsing through Antirez's final product. At this point I thought it might be interesting to follow along with the tutorial, but to do it in Swift and write about the differences. Maybe the Swift version will take less lines of code? Maybe more? The differences between the Swift and C versions of this editor start right at the beginning of this tutorial.
Everyone around you right now, all those people who intimidate you or make you feel like you're a fraud have been where you are now. Nobody leaped from a test-tube as a fully-formed senior developer. They all had to start with no clue and find out how to move forward. Many of those people remember what it's like to be where you are and will be happy to help get you moving. The others you can ignore because they're either heartless monsters or drowning in their own issues. Even those of us who have been at it for a while experience what we call "Imposter Syndrome". That's where you're an experienced developer and still feel like maybe you have no clue what you're doing and everyone around you might soon figure that out. A career in software development can mostly be a career spent starting things you don't understand (mabye
The people I looked up to when I learned to program are now getting to about 50 and I've seen many of them suffer from stress and endless sitting. I've seen some try to do something about it and several succeed even. This has motivated me to make sure I take care of myself. In high school I was forced to play sports (which turned out to be a good thing). In college I discovered skateboarding and loved doing it so much that I never had to think about keeping active. Lately I've taken specific action to make sure health and strength don't just accidentally happen. I've tried working with a personal trainer, capoeira training, and velodrome training, and have arrived at my own calisthenics plan which continues to make me stronger. This time last year I could not do one pull up, for example, to save my life on
Last week Vim 8.0 came out. I was pretty excited because, among other things, Vim now supports asynchronously running code in plugins. Until now, if your plugin code took time (like compiling your project or some auto-completion code) it would cause Vim to freeze until it was finished. No typing, no moving the cursor, you could do nothing. This has been one of the things that sucked about Vim compared to the many other good editors that exist. There are projects like neovim which are attempts to make a version of Vim which could handle asynchronous plugins, but the last time I tried this it caused a kernel panic (I'm sure that's fixed by now). Now that Vim supports it out of the box, I was excited to dig in and see if I could live my dream of doing iOS development in Vim. There are a few things
A keyboard big enough to have all the possible letters and symbols you would need to type when coding or even writing an email would need to be huge. You'd need a key for every letter, lower case and upper case, including the letters less common in English like é or æ, every symbol like , and ; and "", and other useful keys like return and backspace. Back in the day we figured out that this was going to be a bit absurd and different systems developed different ways to allow you to type all these things without a board with 200+ keys. While these systems differed, they converged on some similar concepts. In order to type more symbols with less keys, we started making use of modifier keys. Using one or more modifier keys in concert with other existing keys, you get many more letters and symbols than you get on
One of the signs of an expert programmer is a thing I call transference. I learned about it while reading a book about learning to play music and it applies to programmers as well. A novice musician is hard at work studying exactly what to do with their fingers and exactly the patterns necessary to play a piece of music. With enough practice even, they can play pieces perfectly and beautifully. An expert musician, however, sees past the exact patterns and sees the bigger picture: the keys and the chords. Learning a piece of music becomes much faster because they recognize the similarities between that piece and others they have already learned. Many popular songs from the last 39 years, for example, use the exact same chord progressions and are maybe just played in a different key or speed. When a musician makes it past that initial barrier of simply
Recently I have been super pumped on mechanical keyboards. I found one small enough to easily use when I'm on the couch or in a café which made it easier to spend most of my time using one and get used to it. At this point it feels weird and uncomfortable when I use my regular laptop keyboard! Keyboards can be a bit of a rabbit hole. Once you get into it, there are opportunities to tweak and change things for quite some time. Something even as simple sounding as changing the caps, maybe for a popular set like this can bring on many choices. What kind or material do you want your caps made out of? Do you want letters printed on the top? the side? not at all? what color? what shape? so many choices! I went even further down and decided that, instead of choosing a keyboard
As a developer, I spend quite a bit of time typing. Typing code, typing email responses to clients and recruiters, typing jokes in Slack. As a child, I was fortunate enough to have access to a computer at home and the internet. Our computer was not fancy enough though to play any of the games the other kids were playing, like Starcraft or Counter Strike, so I spent quite a bit of time playing text-based games instead. No need for graphics cards when all your computer needs to do is show text scrolling by. No need for a fast internet connection even. Playing these games involved so much typing I could not help but get faster. I had no formal typing training, so my methods were far from conventional, but they worked. Years later I read articles like Why You Should Use a Mechanical Keyboard and bought a fancy new
Today I assigned my students (I teach a bootcamp now) to write 400-500 words about one of the topics we have covered in class, so I thought I would do the same. Here goes! Classes and structs are similar. Both can have properties, both can have methods. This can make it a bit confusing for developers who are new to Swift. Understanding the difference between the two can help to make choosing between the two easier in your code. Inheritance Classes give you the ability to make use of inheritance, much like you would expect from other languages. While most developers will discourage you from using inheritance to solve your problems, they're still useful sometimes. Structs cannot have "substructs" or whatever you might call them. They are effectively final. class Subclass: SomeOtherClass { // This is just fine } struct SubStruct: SomeOtherStruct { // This will get you compiler errors, not possible! } References vs values
In Apple's block-based API's, you'll often see a pattern like this: func dataTaskWithRequest(request: NSURLRequest, completionHandler: (NSData?, NSURLResponse?, NSError?) -> Void) -> NSURLSessionDataTask The function expects you to provide an NSURLRequest and a block and promises to execute your block later with some info. Inside your block you might get some data, you might get a response, and you also might get an error. Optionals help to make this more clear than it was in Objective-C by forcing you to consider that each parameter might be nil. To handle all the possible combinations, you might have to do something like this: if data == nil { if error != nil { print("Didn't get any data, but instead got this error that might explain why: \(error)") } } if let data = data, let response = response { print("The server responded with these headers and code \(response) and this data: \(data)") } This involves learning which combination
Up to the day I am writing this, Semitones has earned me 122$ in proceeds. That's after Apple's 30% cut from sales through the App Store. That's not much, but it is already more than my last app made in it's entire lifetime. Semitones has a simple business model: an up-front price of 4$. No in-app purchases, no ads, no subscriptions. Just pay up front and get straight to the music practice. The app is intended for people who are serious about studying music: students and teachers. It is not mindless entertainment (which is not bad, by the way, it's good to have a way to let your mind relax and recharge a bit). I assumed the sort of person who was interested in my app would not want to be delayed by in-app purchases for each exercise or have ads attempting to divert their attention from the exercise at
In the last few years, I've started taking my bass playing more seriously. I've found a teacher, joined in on jam sessions, and sat in for bands like Airplane Mode. In my search for ways to help me improve, I found inspiration for my next app. Becoming a better musician includes some level of music theory study. Learning about different intervals, chords and scales make it easier to play music along with other people or recordings. At my first jam session, I had people shouting things like, "F minor!" at me and at first I had almost no clue what they meant. Thanks to my teacher, I not only understand what they mean when they shout "F minor", but I can also start to hear it and play it before they even open their mouth. This is where the new app comes in. It isn't enough just for you to
Some of you have been asking what I'm working on lately, so here's your answer. Practicing music. Teaching programming. Developing my music app. 1. Practicing music. In middle school and high school, I played bass for the school orchestra. I played cello for that first year, but I like to pretend that didn't happen. I stopped playing music after that. Partly because I didn't own my own instrument and partly because I went to college somewhere with a basically non-existent music program. I started playing again after college when I moved to NYC. A skateboarding accident broke all three bones in my right ankle (the price you pay for turning your foot around backwards) and spent many months unable to walk or even stand. This is when I realized an electric bass was not that expensive and, while I maybe couldn't take music classes, I could at least own my
If any of you happen to do some backend work and iOS work at the same time or work on a team that does, this might be a helpful tip for you: Let's say you have a Rails app that uses the Paperclip gem by Thoughtbot to handle file uploads. Then let's say you have an iOS app that wants to upload photos to the server. You've tried building a multi-part request with something like AFNetworking since Alamofire doesn't support multi-part requests and NSURLSession isn't quite convenient enough to do it alone. In your Rails code, you'll do something like @photo.image = params[:image] and you'll get a vague error about invalid characters. The problem here is, Rails has failed to properly detect the file in your multi-part request and then Paperclip can't do its job either. You're trying to send some JSON parameters and an image file and you're
As Apple recommends in their Interface Guidelines, apps should try provide functionality without requiring a login. Ideally, an app would only ask for your login information when you get to features in the app that does need it. Unfortunately, there are a great many apps that simply lock you out of the entire app until you have successfully logged in. Sometimes this is even necessary: like if you are making a private-messaging app. For the times when this is necessary, I'd like to explain a pattern to implement this. Your main entry point to your app will now be a special controller I call the Gateway View Controller. It will be the parent view controller of all others in your app. It will need a few handy functions: private func embedFullScreenController(controller: UIViewController){ controller.willMoveToParentViewController(self) controller.view.frame = view.bounds view.addSubview(controller.view) addChildViewController(controller) } Embedding a child
