Introducing Rails Rescues

RR01

Today I’m happy to introduce Rails Rescues.

Rails Rescues is a service representing years of Ruby on Rails experience organized to help companies who have a Rails application but may be having some problems.

Rails Rescues aren’t limited to a fixed set of services but can include:

  • Scaling your website
  • Resolving site stability problems
  • Upgrading from an old version of Rails to current versions
  • Fixing Broken Code
  • Simplifying an out-of-control code base.
  • Finishing up after your contractor or employee left the project.
  • ….we’ll fix anything holding you back from a successful Rails web site.

I’m happy to offer a $500 finders fee for any referral sent that results in a sign Rails Rescues contract.  Please spread the word and visit the site. I will make myself available via live chat to answer any questions.

 

 

Apple iPad Air 2 – The iPad for Which I Have Been Waiting

When Apple announced the iPad Air 2 at it’s press event on October 16, 2014, I watched with interest to see what the new device had under the hood.  My current iPad Air constantly crashed (out-of-memory errors) running Safari with iOS 7 and I had been hoping they would bump the memory some.  The event disappointed and did not mention anything about more memory.

No where on the iPad Air 2 Tech Specs page can I find a single mention of memory. I decided to order one anyway.  The updated processor, Touch ID and other sensors made it hard to refuse.  I order the 128G space gray model with only WiFi this time, no cellular service.  If I need, I can use my iPhone cell service and save $20 a month.

It came in only 6 days after the announcement and it’s a beautiful device and does not disappoint in the hardware department. Just so other can confirm what rumors have mentioned:

IMG 0017

3 cores

IMG 0018

And most important, 2G memory

It’s a really nice upgrade, lots of little niceties and the one i really wanted.  Thanks Apple.

The Future is the Apple Watch

I’ve been anticipating the official announcement of the Apple Watch since rumors surfaced many months ago.  I’ve spent much time thinking about the features I’d like to see based on my day-to-day routine.  Since I am an avid runner, my main use cases revolved around what I want related to running; no phone required, GPS built in, great fitness application to track my pace, distance and heart rate built in.  I didn’t get many of the things I had hoped.

I don’t even wear a watch today, except when I run.  After the Apple announcement of the Watch, I upgraded my running watch since the Apple Watch met almost none of my running needs and wouldn’t be available until 2015.  The last thing I want to do is run with my new iPhone 6 and a watch.

Apple watch

Witness the Future

Even with the Watch not meeting my set of requirements, I still want one. I think this is a paradigm shift in how we interact with the world.

What we witnessed in the keynote from September 9th introduced a new product platform which will change the future. It’s unlike any wearable to date in the sense that it truly extends the iPhone and delivers only the most important bits of data to the Watch screen.  It acts as a filter we control, where we determine the notifications and data points most important to us and puts them in a convenient location; right (or left) on our wrist.

Today we see many people with their smartphones out everywhere, checking Twitter, Facebook, texts and email.  Tomorrow we could very well see people quickly checking their watches to view these updates. Less disruptive and much more of our attention.

Developers! Developers! Developers!

Applications being available the day the Apple Watch is released is important.  There are plenty developers already chomping at the bit to get started with the Watch. These are the developers who will make a difference, have the ideas that will drive the platform into the future. 

Jeremy Olson of Tapity is one of the those outspoken developers who has described his vision for using the Watch with their Hours application.

The Watch takes this to a whole new level. It means you can switch timers without even taking your phone out of your pocket. Just glance at your wrist and tap. Boom.

We absolutely cannot wait to start time tracking on the Watch and you can bet Hours will be available for Watch on day one.

Jeremy explains it well in a post on Medium, The Apple Watch’s greatest superpower:

For example, my time tracking app Hours could have a unique tap that reminds people every so often that they have a timer running. This kind of notification would be useless on the iPhone because it would result in a lot of obnoxious buzzing that may or may not mean anything related to your time tracking.

Apple Watch White BG

Jeremy represents exactly what I think the successful applications on the Watch will be. Small windows into their bigger apps with a small subset of features. Perfect for a watch.

I don’t think there will be an Apple Watch Store, but rather applications for the watch will be an extension of applications we already have on our phones.  Just the way we now have app extension in iOS 8.

Developers are the ones who are going to make or break this device. Creatives will be the ones who see the potential and extend the great ecosystem we have in the Apple App Store today.

Apple will need to get a Watch SDK and devices to developers long before a release.  I’m hoping for a Watch Kit that will give us a device and all documentation to start creating this next generation of applications.

If we don’t get these kits then applications will only be from Apple and key partners at first.

Finally

The Apple Watch represents the future.  We are all bombarded with data looking for our attention everyday and when we look to our phones it can be overwhelming where to turn our attention.

A device like the Apple Watch will help filter out the noise and focus our attention to what we feel is important. Developers who get this will be the successful ones on this platform and help guide others.

I’m excited to see what comes to the Watch.

Greener grass

I ran across an interesting post this morning from Frans Bouma, of LLBLGen fame.  He is a long-time .NET developer who felt a bit complacent in the work he had been doing on .NET and ORM development. Frans decided to explore some of the recent cool technologies to see how green the grass was on the other side of the technology fence.

After I finished LLBLGen Pro v4.2 this summer, I fell into the usual ‘post-project’ dip, where everything feels ‘meh’ and uninteresting. Needless to say I was completely empty and after 12-13 years of doing nothing but .NET / C# / ORM development, I didn’t see myself continuing on this path.

I found myself in the very same place a few years ago.  Microsoft felt wrong, it felt boring. No, I didn’t know everything about .NET but I felt I had experienced everything there was about the part of the ecosystem that effected me.  I left .NET and haven’t returned but a piece of me does think back with some fond memories, like I left part of my life behind.

Frans did what so many do, pickup something that seems everyone is enjoying, in this case Go:

I already knew this of course when I went into this journey, so learning Go was, in hindsight, more of a ‘let’s do this, see where it leads me’ kind of thing than a real move to Go. After learning the language and working with the tools available I realized it wasn’t the world I wanted to be in. The main reason was that I develop and sell tools for a living, I’m not a contractor and Go’s commercial ecosystem is simply not really there. After my Go adventure I had learned a new language but nothing of what I needed to get past my problem.

Then try something else, Objective-C on OS X:

To learn a language and platform, it’s best to use it in a real project. Some time ago I had an idea for an app for musicians (I’m an amateur guitarist) on OS X. This was the perfect opportunity to learn a new language and platform, so I did the radical move to learn Objective-C with XCode, targeting OS X. I have to say, this was a true struggle. XCode was ‘OK’, but Objective-C was something I hated from the start.

In his case he discovered something in these other languages and frameworks that opened his eyes to something he could explore and use in .NET, where he ended up going back to:

My little journey brought me back to .NET without realizing it, to find back the love of writing code by finding motivation in an element that’s a core part of an OS I don’t use in my daily work. It opened the route out of the rabbit hole by showing a new path I could take without leaving my life’s work behind; on the contrary: it opened my eyes to completely new opportunities and ideas.

The reason this post interested me so much is because how familiar it sounds for me personally.  I seem to continually am bored lately with the technology I work with and I venture to try new things.  Trying new things, exploring unfamiliar territory is good.  It opens your eyes to something that may send you down an entirely new path.  It’s easy to stick with what you know, to not get out of your comfort zone but you miss out on many opportunities.

The post is a good read and I recommend you read it.

Swift Development Magazine

View my Flipboard Magazine. 

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].

Setup Swift REPL and Access from the Command Line

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:

/Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift

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:

alias swift="/Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift"

Restart the terminal app, type swift and you should see something like this:

Swift term

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.

Welcome Swift, I’ve Been Waiting For You

Swift hero

I haven’t blogged here in a while, sometimes life seems to get in the way.

Bombshell

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.

The Future

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.

Speeding up Heroku Deploys

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 memcachier service, 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-compile which will do the trick.

heroku labs:enable user-env-compile

Next you’ll need to add the dalli and memcachier gems to your Gemfile. Finally, the last step is to configure Sprockets.

Since I am using Rails:

With Rails

With Rails, just configure the assets cache store inconfig/environments/production.rb.

config.assets.cache_store =:dalli_store

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.

Subscribe to Posts Via Email

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.

Subscribe

AirPrint Where You Couldn’t AirPrint Before

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.

Enter handyPrint….

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:

HandyPrint

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:

IMG 0001

Select the printer and that’s it.  handyPrinter works seamless.

Thanks to Eric Davis for pointing it out on Twitter.