Like everybody else, I spent a few hours this week updating my personal projects to Swift 2.2 which was released with Xcode 7.3 a few days ago. Updating to Swift 2.2 was important in my case since 2.2 version is basically an intermediate release between Swift 2.0 and the upcoming 3.0 version. This prompted me to take a few moments and write about the changes I had to implement in my code. There is a nice write up about the changes on www.swift.org if you are interested in more details.
Swift needed to happen. Objective-C had no future. I know this is a harsh statement, but this is the conclusion I came to this week after writing purely in Swift for a few months now. It is hard to admit, especially after spending most of my software development career writing in Objective-C. There is a chance that a lot of you will disagree with this statement, but let me mention two things I find lacking in Objective-C that are extremely important when it comes to writing good code.
Objective-C by its nature is a much forgiving language (and I am using this term loosely). It allows developers to get away with bad code. It does not impose requirements for handling errors. It allows for nil return type where a specific type is expected. It does not guarantee immutability. It requires extra work to declare true constants. Block syntax (should I say more)?.
I was pretty surprised at hearing about Parse shutting down. I was sure they are to stick around after being acquired by Facebook a few years back. I even built a few production apps that rely on their backend to work… oh well.
A few days ago I received an email “Your Own Parse Server on AWS and Heroku” and decided to give it a go by setting up ParseServe on AWS; after all, I only have 11 month to migrate my apps somewhere, right?.
This will be a short tutorial on how to deploy your own instance of ParseServer on AWS with a few Swift examples of making GET, POST requests. Quite honestly, I never worked with AWS until this week. My choice for backend was always Parse (ironically), most recently CloudKit (great solution provided by Apple), Heroku, or personal server running Node.js.
Here is what I like about Swift the most… it forces me to think in terms of what I can only describe as decoupled behavior. Behavior or implementation that doesn’t depend on any specific type. This can be clearly observed with higher order functions, protocol oriented programming or just Swift in general.
So what are they? Higher order functions are functions that take other functions as parameters. And even though the implementation of these functions can be, as any implementation, verbose and easily replicated, the advantage of using higher order functions is the fact that they promote a much succinct and easier to understand code by eliminating clutter. Some of these functions even have a default behavior (sort(_:) for example will sort elements in ascending order) which is very useful.
Aaaaaand I am back from the holidays… Christmas was great. I got a chance to spend time with my beautiful wife and two sons visiting “The German City” – Leavenworth. It was great to just chill for a bit… slay ride with kids was amazing. Seeing horses brought all my childhood memories back.
Anyway, I would like to kick off this year by spending a bit more time talking about Swift protocols. We’ve already covered it briefly here. Take a look if you are interested in what i cleverly titled as “Practical Protocol-Oriented Programming”. Even if you think you already know what protocols are, take a few minutes to read this article. There are some cool things I bet you didn’t know about.
Instead of writing another article, I’ve decided to simply publish a sample project demonstrating interactive transition between collection view layouts. It’s quite nice. See it in action here.
You can find sample code on my Github.
Feel free to submit pull requests when improving on this code base.
Weekends are awesome. I don’t get up super early and most of the time get an opportunity to work on personal projects, read up on new advances in Swift, catch up on news, etc.
Today I needed to migrate my Core Data model to a new version. Fortunately for me, light weight migration was enough and I didn’t have to perform the migration using a Mapping Model. Renaming attributes however is a bit more involved than simply adding attributes. This, of course, meant I would have something to write about… although, admittedly, I had another topic in mind for this week’s article.
Light weight migrations are pretty straight forward; Core Data takes care of everything by inferring mapping model from differences between the source and destination models.