I have been collecting resources together for everything I come across on Apple Swift. I add these to a new Flipboard magazine called Swift Development. If you come across interesting links you feel should be in the magazine, pass them along to [email protected].
Swift has a very nice Read-Eval-Print-Loop (REPL) for developers to take advantage of and be able to get instant feedback on Swift code. This is great for trying things out without having to use Xcode 6 and a full project.
If you are unsure of what this REPL is, from the Swift web site:
Read-Eval-Print-Loop (REPL). The debugging console in Xcode includes an interactive version of the Swift language built right in. Use Swift syntax to evaluate and interact with your running app, or write new code to see how it works in a script-like environment. Available from within the Xcode console, or in Terminal.
The problem is, it’s not available by default since it’s not in your path. If you have Xcode 5 installed you probably don’t want to have to deal with switching back and forth between Xcode paths.
The solution is pretty simple actually. I wanted to be able to get to Swift from the terminal with a short command, in this case, swift will be the command. In order to setup it up I located the swift binary, yours may be different depending upon where you have the Xcode 6 beta installed. Mine was here:
If you just run that line in terminal it works fine but I want to be able to access this easily. The answer is an alias added to the .bash_profile. Add this line to the .bash_profile:
Restart the terminal app, type swift and you should see something like this:
UPDATE (06/17/2014): Apple released Xcode 6 Beta 2 today and the path changes to where the Swift binary lives, use Xcode6-Beta2.app instead of Xcode6-Beta above.
I haven’t blogged here in a while, sometimes life seems to get in the way.
Last week I was one of many who watched the Apple WWDC keynote and was blown away by many of their announcements. The one to get me the most excited is the new programming language, Swift. No one saw this coming.
I’ve been a long-time Objective-C developer but have never been in love with the language. As Apple developers, we use because it’s the only real option…until now. Swift is introduced as an alternative to Objective-C, not a replacement, and to me resembles Go and C# with many of the language constructs. I’m not going into the language details today but you can find out more from The Swift Programming Language guid in the iBooks Store.
Swift is a type-safe and modern programming language for Cocoa and Cocoa Touch applications, which means targeting iOS and OS X. It’s really nice to see Apple making big changes and offering developers a choice. I’ve read tweets and other reactions to Swift and asking why we need another programming language but I say it’s a good thing. Swift does away with all the square brackets () and pointer references to create a cleaner programming language.
Should You Learn Swift?
Objective-C isn’t going away any time soon. Apple realizes Objective-C has baggage and when looking at adding to the language, there is only so much they can do with it and therefore came up with a language that removes all of the warts on Objective-C. The API’s are the same when using Cocoa and Cocoa Touch so if you are an Apple developer already, you are half-way there.
Apple releasing this new language says a lot; it expresses Apple’s intentions. Swift will be important in the future, whether that’s a year or five, we just don’t know.
Yes, I think you should learn Swift. If you are new to Apple then you have a choice, Swift or Objective-C. Aaron Hillegas, long-time Objective-C proponent, thinks developers need to know Objective-C. He has some valid points:
You can’t do everything in Swift. For example, if you want to use a library of C++ code in your application, you will need to talk to the C++ objects from Objective-C. Swift can call C functions, but I believe that if you are working with a lot of C functions and types, you will want to code in Objective-C.
He claims Objective-C is easier to learn than Swift. I’m not sure I agree with this point:
C is a really simple little language, and Objective-C is a really simple little extension to C. Swift has many rules that Objective-C does not. (I, as an instructor, am already trying to figure out how I will explain the rules around optional variables and the proper use of ? and ! to signal the programmer’s intent around optionality.) These extra rules mean that the compiler can be much more pedantic about enforcing good coding practices, but it also means that the language will take longer to learn.
Objective-C requires programmers to be explicit. The Swift language lets the compiler do more work for the programmer. This is great—less typing for the programmer, right?—but it means that when you look at a line of code, it won’t mean much without a deep understanding of the context in which that line lives. Explicit languages are easier for beginners to understand.
Swift has a bunch of constructs that Objective-C doesn’t have. For example, generics make type checking better in Swift, but it makes that language considerably more complex.
Marco Arment had a good follow-up to Aaron’s post and I tend to agree with him:
The time will come when knowing Objective-C will be like knowing C, C++, or assembly — it’ll be a plumbing layer beneath your application code that almost all working developers will never need to know or interact with. And I bet that time is less than five years away — possibly just two or three.
I have to say that as far as sample code, blog entries and Stackoverflow threads, Objective-C will have the lead for a long time. Finding solutions to problems specific to Swift will be harder to find and you might be a bit of an explorer for a while.
If you are targeting multiple platforms there is always a debate. If you go native on every platform then Swift may be a good choice. If you like the idea of a single-ish code base then maybe Xamarin (C#) or RubyMotion is something to consider.
If you want to play with Swift be aware that you will need the Xcode 6 beta.
I am devouring the Swift documentation and WWDC presentations. Over the next few months I will be blogging about it, now that I have a good reason to blog.
I will not be migrating any Objective-C code bases to Swift…I don’t see the point. I will be writing sample code and creating a new application with only Swift and plan to document the process.
Anyone who deploys their Rails 3.x or 4.x utilizing the asset pipeline and doesn’t precompile those assets yet deploys to Heroku, knows it can take a really long time for your deployment.
I searched around a bit and found a great article on how to shave some time off my Heroku deployments. Alex MacCaw has a nice write up about the process:
If you’re using Heroku, the first step is enabling a Memcache addon. I’ve gone with the
memcachierservice, as they’ve got a generous free plan (which is all we need at this stage).
heroku addons:add memcachier:dev
Then we need to make sure the environmental variables are available to your app during the pre-compilation stage. Usually this isn’t the case on Heroku, but they’ve got a new labs feature called
user-env-compilewhich will do the trick.
heroku labs:enable user-env-compile
Next you’ll need to add the
memcachiergems to your Gemfile. Finally, the last step is to configure Sprockets.
Since I am using Rails:
With Rails, just configure the assets cache store in
And the time savings would be….
An example of time saving with a relatively small project:
Not using the speed-up method, deploy time: 2 minutes 40 seconds
Using the above method: 47 seconds
It is definitely worth the little effort.
It seems more and more web sites are offering users to subscribe to updates delivered by email. If you would rather have posts delivered right to your inbox instead of visiting the site or relying on RSS, you can now subscribe and forget.
Just add your email to the “Subscribe to Blog via Email”, submit and confirm your desire to subscribe in the confirmation email and thats it. You can unsubscribe any time.
Our household has several iPads and iPhones. I use my iPad all the time to surf the web, reply to emails and view my Twitter stream, among other things. Occasionally I find it would be nice to print from the iPad, since it has AirPrint and all, but our Canon MX860 printer doesn’t support AirPrint.
handyPrint™ v5 is a 64 bit Mac OSX application that allow you to print from your iPods, iPads and iPhones on printers that do not support the AirPrint protocol. v5 has been re-designed as a standard application similar to the ones you would find in the Apple App Store. You simply copy it to the Applications folder and run it from there. Once you turn the application switch to ON it will start on its own every time you login to you user account. No need to manually start the application.
handyPrint is a simple download which is a DMG, just click to install. It’s an application needs to be running while the user is logged in on the host Mac. I noticed there’s a Pro version that runs as a service to alleviate this requirement but this didn’t matter to me.
Once installed handyPrint is run and sits in the OS X menu bar after it’s turned on. The user interface is really simple:
A list of available printers shows up and you just select the ones you enable AirPrint support. This particular printer is actually wireless, I just happen to have the driver installed on my Mac.
Printing from the iPad is simple. While you’re in the application you want to print from, just select Print as if you had an AirPrint-supported printer around:
Select the printer and that’s it. handyPrinter works seamless.
Thanks to Eric Davis for pointing it out on Twitter.
I recently had an interesting interaction with a company’s support team and the results were less than spectacular. Originally, I had a much longer post planned that better detailed the problem, brought attention to the company and gave details of how poorly they handled it. I felt the approach was less than constructive.
The bottom-line is I had a need to contact a well-reputed company and faced several of the hurdles outlined by Ian Landsman of HelpSpot recently in his post about customer support. I won’t rehash them here, so you should go read his post right now. Scott Watermasysk of KickoffLabs had bit of follow-up to Ian’s post that you should also read.
I came out of my experience with two additional rules that we follow and you should consider reviewing your work as a person who supports “customers”:
1. It works for me, so it must be you
This one really bothers me, and I’m probably guilty of it over the years. You have a customer who has a problem, you can’t reproduce the problem so you pass it off as not your problem and close the issue.
I have checked the site via a proxy and it’s showing up correctly:
<useless url to proxy removed>
This issue appears to be local. As a troubleshooting measure, I would recommend restarting your computer. If the site is still having connection issues, I also recommend restarting your router as well. Please let us know if you’re still experiencing connection issues after trying those recommendations.
This goes along with #9 on Ian’s post, Listen Carefully. I had provided a trace route to the support team which clearly showed my request was terminating at the host of the company. Had this tech read my email (I sent the trace route 3 times by the way) and listened, he would have seen proof the problem was not local.
2. Passing the buck
It’s really easy to look at problem your customer is facing and not know the answer, saying you don’t know is fine. One response may be to blame the problem on someone else because you don’t want to continue dealing with it and you want it to pass it on. This is the exactly how my problem was handled.
I use a utility which is a graphical client to interact with another service, the utility was timing out. I tried to access the endpoint directly and it was also timing out. A bit of my own sleuthing revealed my requests were being either dropped or blocked. Support finally realized that in-fact my IP address was being blocked for unknown reasons.
The tech involved on the ticket decided the utility I was using must be the problem, even after repeated attempts at telling them it was no longer running. This was their response:
Good afternoon Rob,
Thank you for contacting us today.
The reasons that ******** state on their front page for using ******** aren’t very sound. Why would you “avoid being connected to the internet” to make a post when you must connect to the internet to make the post? ** isn’t making a bunch of data calls back and forth while you’re sitting on the post editing page so the network bandwidth consumption would be negligible even if you had to “be connected” to the internet.
With that said, anything that hits our server with multiple connections too quickly from the same IP will be blocked for attacker like activity. My suggestion is to contact the developers of your software and have them work to throttle the connections down or at least offer the option to do so. If they are unwilling to work with you I would request a refund from them and potentially find another plugin to duplicate this functionality.
If you have any further questions please let us know and we’ll gladly assist you.
Gladly assist me? Hmmm….
The result is a lot of frustration trying to solve this issue. Normally this company provides great service and they have a great reputation in the community but sometimes a company’s growth and not communicating culture can be negative.
Please don’t do this.
Remember folks, choose the right tool for the job…
You can’t read about programming languages these days without Google’s Go programming language being discussed with much praise. I agree that Go is good, but I recently ran across a post addressing some short comings titled Another go at Go…failed! The criticism is constructive and a good read. Bottom line:
- If your problem domain involves patterns that benefit from type parameterization or polymorphism that is easily achievable through inheritance, Go is a poor choice.
- If you find your Go code evolving into having few interfaces but many higher-order functions (or methods) that resort to frequent type assertions, Go is a poor choice.
- Go runtime can learn a trick or two from JRE 7 as regards performance.
I thought it was going to be more bashing by a naive developer but it’s far from the case. It goes to show the point that not all tools are the right tool for the job and not a single programming language is right in all cases.
Developers tend to use a tool, programming language or framework, and try to fit the problem’s solution to the tool. It doesn’t always work that way.
Tim Bray has a great post discussing the state of software development in 2014. I found myself nodding in agreement virtually all the way through this one, mainly about client-side development for mobile and the web.
The client-side mess · Things are bad. You have to build everything three times: Web, iOS, Android. We’re talent-starved, this is egregious waste, and it’s really hurting us.
A bit about mobile:
Mobile sucks · I’m going to skip the differences between Android and iOS here because they’re just not that significant in engineering terms. Anyhow, here’s the suckage.
- First of all, you have to do your mobile development twice.
- The update cycles are slow. Days in the case of iOS, hours for Android (compared to seconds for browser-based apps). What’s worse is that you can’t even count on people accepting the mobile-app updates you send them. Got a critical data-losing account-compromising privacy-infringing bug? Sucks to be you.
- The devices are memory-starved, CPU-starved, and battery-starved.
- There are loads of form factors and it’s getting worse.
- You don’t get a choice of languages; if you hate both Java and ObjC, get another job.
Bottom line, client-side development is a difficult place to live but server-side is more stable. I have felt this way for a long time, client-side makes me cuss and server-side makes me smile.
It’s a good read.
I’ve been using the PostgreSQL Mac OS X app from Mattt Thompson and Heroku for quite some time now. If you don’t know what it is, it’s a drop in app bundle for the PostgreSQL database. There are many ways that work, this just happens to be really simple.
I use PostgreSQL with my Ruby on Rails projects and combine that with the pg ruby gem.
I ran into a situation where the pg gem would not install because it could not find pg_config in a known location on my Mac. The error occurred on Rails 3.2 but 4.0 may show the same behavior.
The error can come up when running a
bundle install or just a straight
gem install pg from the command line. The resulting error may look something like this:
Installing pg (0.17.0) with native extensions
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension
An error occurred while installing pg (0.17.0), and Bundler cannot continue.
Make sure that `gem install pg -v ‘0.17.0'` succeeds before bundling.
I already mentioned the problem is the gem install not finding pg_config during installation. So let’s find it.
1. First, find where pg_config is located. Run this command from a terminal window:
Should display something like this:
2. You can tell RubyGems where your pg_config file is located:
gem install pg -- --with-pg-config='PATH_TO_YOUR_PG_CONFIG'
For example, pg_config is here on my system:
So I would install the gem this way:
gem install pg -- --with-pg-config='/Applications/Postgres.app/Contents/MacOS/bin/pg_config'
The pg gem should now install. I hope this helps.
UPDATE: Scott Watermasysk points out another good solution:
@rbazinet another route that worked for me was to put the pg.app (as a folder) in my path. This allows the config to be properly found.
— Scott Watermasysk (@scottw) December 19, 2013