Global Nerdy

A new year, a new approach to the meetup, and tweaking the format

Photo by Deanna Gray.

Tampa is lucky to have three iOS meetups. In addition to my group, Tampa iOS Meetup, we’ve got:

• Suncoast iOS, run by Juan Catalan, and
• Tampa Bay Cocoaheads, run by Chris Woodard.

Suncoast iOS and Tampa Bay Cocoaheads cover topics better suited for intermediate- to expert-level iOS developers, and they do so quite well. This year, I decided shift the focus of Tampa iOS Meetup towards a different audience: people who were either new to iOS development or who were new to development in general.

With that in mind, the January 2017 session of Tampa iOS Meetup (which took place on Tuesday) was about developing a simple app: a tip calculator. While a tip calculator is a simple application, even the simplest of mobile apps have a lot going on underneath the hood, what with the programming language, the application development framework(s) involved, and the IDE. I covered a fair bit of ground in my presentation, and after a little review, have decided to tweak the format.

Future Tampa iOS Meetups will have two parts:

• A presentation part, where new concepts are introduced, followed by
• a workshop part, where those new concepts are applied.

I think that this approach will be more useful, especially to developers who are new to iOS programming or just programming in general. It would give attendees a chance to try out the concepts while they’re still fresh in their minds, as well as a chance for me to help people with their programming.

I’d like to thank Wolters Kluwer for providing the space in which to hold the meetup, as well as the food (excellent salads) and drinks! Special thanks to John Wang, my go-to guy at Wolters Kluwer, and source of valuable feedback for my presentations.

Building the dreaded tip calculator

Let’s start by building a simple app that will grow into the tip calculator. This one will be simple — it will be an app that says “Hi there” when the user taps on a button. Over a couple of articles, we’ll make changes to it, and in the end, it will be a tip calculator.

First step: Create a new project

Start by creating a new iOS project. Launch Xcode, then use File → New → Project…. This will take you to a dialog window where you’ll choose a template, which is a pre-made set of files that you can use as a starting point for your project.

Think of Xcode’s templates as being the coding answer to templates that Office-style apps provide when you create a new document. Just as PowerPoint lets you choose from pre-made templates so you don’t have to design your deck from scratch and have more time to focus on its content…

…Xcode lets you choose from pre-made templates of code, each one designed to be the basis for a different link of app.

Here’s what the “Choose a template for your new project” windows looks like:

In this window, you should:

• Make sure that iOS is selected in the menu near the top of the window. Xcode can be used to write applications for a number of different platforms, and you want to be certain that the project you create will run on iOS.
• From the Application section, select Single View Application. This is a template for an app that features a single view, which corresponds to a “screen” in the app. The Single View Application template isn’t just for writing apps with single views; it’s just a template with a single view and its underlying code — a view controller — pre-defined.
• Click the Next button to go to the next window.

The “Choose options for your next project” window lets you specify a number of options for your project. For this project, we’ll use it to specify a name for your project, leaving the other settings at their default values.

In this window, you should:

• Enter the name of the app into the Product Name text field. I used Tip Calculator as the name for my app. This will not only be the name of the app, but the name of the folder in which its files will be stored.
• We’re leaving the other settings at their default values, so click the Next button.

You’ll now be at the screen where you specify where the project should be saved. In this window, you should:

• Choose a place on your hard drive where your project’s folder will be stored.
• Make sure that the Create Git repository checkbox is checked, and that My Mac is selected from the drop-down list beside it.
• Click the Create button, which will start the process of generating the files and folders of your project.

Xcode will spend a moment or two generating your project’s files and folders, after which you’ll be taken to a place where you’ll be spending a lot of time: the Xcode main interface.

Xcode’s main interface is divided into 5 general areas:

1. The toolbar, which contains a number of frequently-used controls, including those for running or stopping apps, and for changing the layout of the Xcode interface.
2. The navigators, which take up the left column of the Xcode interface and provide a number of ways of navigating about your project.
3. The editor area, which occupies the central area of the Xcode interface. It’s where you’ll do a lot of work, including writing code, designing your apps’ user interfaces, and editing your apps’ settings and configurations.
4. The utilities area, where you can edit the properties and settings of things that you’re working on in the editor area.
5. The libraries area, which is a repository for user interface controls that you’ll put on your apps’ screens, as well as files, code snippets, and media that you’ll include in your projects.

Right now, we’re going to focus on the toolbar because we’re going to run the app.

Even though you haven’t yet written a single line of code or created a single user interface, you already have a working app. The Single View Application template that your app is using as its basis already contains enough code for an application that will run.

We’ll run the app in the Simulator, which comes with Xcode and can simulate any supported Apple device. It’s useful for quickly testing an app without having to load it onto a device, and handy when you want to test your app on a type of device you don’t have.

To run the app:

• Select iPhone SE from the menu to the right of the Run (the “play” triangle) and Stop (the “stop” square) buttons in the toolbar. This tells the Simulator to simulate an iPhone SE. It’s one of the smaller-screened iPhones, and as such, it’s good for testing interface designs. If your app is usable on an iPhone SE screen, there’s a very good chance it’ll also be usable on larger-screened devices like the iPhone 6 and 7, and especially the Plus versions.
• Click the Run button to start the app.

The simulator will take a couple of moments to start up, after which you should see this:

It’s not much to look at, but that’s because we haven’t built a user interface or added any code yet. Now that we’ve confirmed that our template runs, stop the app by clicking the Stop button:

Draw a simple user interface

It’s time to work on our app’s user interface. In order to do this, let’s take a closer look at the left column of the Xcode interface, which is where the navigators live. We’re interested in the Project Navigator, which lets us navigate through all the files that make up a project:

To show the Project Navigator, do the following:

• Make sure that the Project Navigator is currently displayed. You can do this by clicking on the folder icon from the set of icons located at the top of the left column. The Project Navigator will display a set of files and folders that make up your project. For now, we’re interested only in the files in the Tip Calculator folder.
• You should be able to see the contents of the Tip Calculator folder — these are files such as AppDelegate.swift, ViewController.swift, Main.storyboard, and so on. If you can’t see them, make them visible by clicking on the disclosure triangle to the left of the Tip Calculator folder.
• Inside the Tip Calculator folder, you’ll see a file called Main.storyboard. Click on it once; this will cause the main storyboard to appear in the editing area in the center of the screen.

The storyboard is where you draw the user interfaces for the screens (or more accurately, views) of your apps. The term “storyboard” is borrowed from filmmaking; in that field, it’s a way of graphically organizing the scenes of a movie. Here’s an example — an early storyboard for a film that eventually became Star Wars: A New Hope…

In Xcode, a storyboard is a way of graphically organizing the views of your app. It’s where we’ll define the user interface of our app, once we’ve done a little housekeeping.

Near the upper right-hand corner of the Xcode interface, you’ll find a set of buttons that determine what the Xcode interface shows. We’ll want to make sure that the both the left and right sidebars are visible:

Do the following:

• Make sure that the left and right sidebars are visible by ensuring that their buttons (see the screenshot above) are selected. You’ll know that the buttons are selected when they’re highlighted blue. Feel free to click on them to see what happens, just as long as you’ve got the left and right sidebar buttons selected at the end:

Now that we’ve set up Xcode’s sidebars, let’s set up the storyboard so that its views are iPhone SE-sized. Xcode has a feature that makes it easy to design for various screen sizes, and it’s located near the center of the bottom of the Xcode interface:

Do the following:

• Click on View as: near the center bottom of the Xcode interface. This will cause a menu of various devices to appear. If you hold the cursor over each device’s icon, its name will appear. Select the icon named iPhone SE.
• In the menu of orientations — located to the right of the menu of devices — choose the portrait orientation.

These steps will cause the storyboard to display iPhone SE-sized views in the portrait orientation.

Now that we’ve set up the view, let’s look at the objects we’ll put into it. Look at the libraries, located near the lower right-hand corner of the Xcode interface:

Of the libraries that are available, we want to make use of the Object Library, which contains user interface objects that we can put on our app’s views. Do the following:

• Make sure that the Object Library is selected. Click on its icon (the round one), to make sure it’s selected. Feel free to click on the other Library icons to see what happens, just as long as you’ve got Object Library selected at the end.
• Scroll through the Object Library, where you’ll see all the objects it contains, and their descriptions. When you’re done exploring it, scroll through the list so that you can see the Button object.

It’s time to put user interface items onto the view. The first user interface item is a button:

• Drag a Button from the Object Library and onto the view. Place it near the upper left-hand corner of the view. As you bring the button close to that corner, Xcode will cause a couple of guides to appear. Line the button up with those guides.

• Double-click on the button to edit its title. The text in the button will be highlighted, which indicates that you are editing it.

• Change the text in the button to Tap me.
• Click anywhere outside the button to stop editing it.

Let’s now add a label, which is a container for read-only text that can neither be selected nor edited by the user:

• Drag a Label from the Object Library and onto the view. Place it a short distance below the button. As you bring the label close to that view’s left edge, Xcode will cause a guide to appear. Line the label up with that guide, so that its left edge lines up with the left edge of the button.

Since this is a simple app, we’re done drawing its user interface. Time for the next step…

Connecting the interface to the underlying code

Run the app right now, and you’ll see this:

However, if you tap on the Tap me button, nothing happens. In our simple app, we want the text in the label to change to Hi there! when the user taps the Tap me button.

As its name implies, the Single View Application template that we’re building our app on comes with a single view. We just placed a button and label on that view. However, that view doesn’t do very much because we haven’t yet written any code to control that view. This view-controlling code that we’ll write will go into the view controller file, which is very conveniently named ViewController.swift in our project.

We’re going to connect the button and label in our view to the underlying view controller in this step. In order to do this, we’d like to have both the view (which lives the in Main.storyboard file) and the underlying view controller code (which lives in the ViewController.swift file) visible at the same time. This is possible with the Assistant Editor feature, which makes it possible to view two files side by side.

The Assistant Editor button is located near the upper right-hand corner of the Xcode interface. Do this:

• With the main storyboard visible in the editor area in the center of Xcode, click the Assistant Editor button. Xcode tries to be “smart” about which file you want to edit, and in this case, it should “assume” that you want to look at the app’s only view’s view controller code.

You should see something like the screenshot above. You may want to expand the Xcode window so that it takes up the entire screen.

Let’s connect the button to the view controller code first:

• Select the Tap me button on the view in the main storyboard, then control-drag (that is, drag while holding down the control key on the keyboard, or if you have a mouse, right-drag) from the view to the ViewController.swift code.
• Let go of the mouse in the empty spot between
  ViewController: UIViewController {
  and
  override func viewDidLoad() {

A pop-up will appear. This pop-up lets you define the type and details of the connection between a user interface object and the underlying view controller code. There are two types of connection, and we’ll use both in this simple app:

• Actions: An action is some code that’s run in response to an event. In the case of this app, we’re going to define an action that runs some code when the Tap me is pressed.
• Outlets: An outlet is a reference to a user interface object, which allows the underlying code to affect that object. In this app, we’ll define an outlet that will allow us to refer to the label, which in turn will allow us to change its text.

Since we’re dealing with the button right now, we’re defining an action connection:

Do the following with the pop-up:

• Select Action from the Connection menu.
• Give the action a name: enter buttonPressed into the Name field.
• Note the default selection in the Event menu, but don’t change it: Touch Up Inside. This is one of the user interaction events that a button can respond to. Touch Up Inside is an event that gets raised when the user pushes down and then releases on a button with their finger still inside the button’s bounds (which is a very precise way of saying “when the user presses the button”).
• Click the Connect button.

The following code will appear in the view controller:

@IBAction func buttonPressed(_ sender: Any) {
}

This is a new method (that’s another term for a function) named buttonPressed, and it will be called whenever the user pressed the Tap me button.

Do the following:

• To make the code easier to read, add blank lines before and after the newly-created method.

Let’s now define an outlet connection for the label:

• Select the label on the view in the main storyboard, then control-drag (that is, drag while holding down the control key on the keyboard, or if you have a mouse, right-drag) from the view to the ViewController.swift code.
• Let go of the mouse in the empty spot between
  ViewController: UIViewController {
  and
  @IBAction func buttonPressed(_ sender: Any) {

Another pop-up will appear:

Do the following with the pop-up:

• Select Outlet from the Connection menu.
• Give the outlet a name: enter replyLabel into the Name field.
• Click the Connect button.

The following code will appear in the view controller:

@IBOutlet weak var replyLabel: UILabel!

This is a new variable named replyLabel, and it will be used to access the label in order to change its contents.

Do the following:

• To make the code easier to read, add blank lines before and after the newly-created variable.

Let’s make it work!

There’s just one thing left to do: write the code that changes the text of the Label to “Hi there!” when the user presses the Tap me button. We already have a method — buttonPressed — that gets called when the button is pressed; all we have to do write the body of that method.

All it takes is one line of code to get what we want. Add the following line to buttonPressed…

replyLabel.text = "Hi there!"

…so that the method in its entirety looks like this:

@IBAction func buttonPressed(_ sender: Any) {
  replyLabel.text = "Hi there!"
}

Run the app. It should look like this:

Now press the Tap me button. You should see this:

As you can see, Hi there! got shortened to Hi t…. That’s what happens when a label doesn’t have enough space to accommodate the text it contains. There’s a simple fix…

Do the following:

• Stop the app.
• In the main storyboard, select the label. Grab one of the “handles” (the squares that appear around the label) on the right side of the label and use it to widen the label.
• Run the app.

You should now see the full Hi there! when you press the Tap me button:

Wait, wasn’t this going to be a tip calculator? (or: What’s next?)

After all, the app’s name is Tip Calculator. Don’t worry — in the coming installments in this series, that’s exactly what this app will become. I thought it would be a good idea to start with a simple exercise first, in order to get you comfortable with Xcode and creating simple apps.

In the next article in the series, we’ll look at getting input from the user with text fields.

Download the project files

Although this is an extremely simple project, I’ve made its files available for download — click here to get them!

The call for a co-maintainer

Swift Algorithm Club — an open source project of the great iOS (and Android) tutorial site RayWenderlich.com to build implementations of useful algorithms and data structures in the Swift programming language — is looking for someone to help maintain it.

While they have two maintainers on the project (Kelvin Lau and Vincent Ngo), they could use some help, since it’s a popular GitHub project with almost 11,000 stars, over 800 watchers, and over 100 contributors. Hence their call.

The successful candidate will have the following responsibilities:

• Deal with issues, pull requests, edit and code review submissions.
• Help keep build server functional, especially as new submissions come in.
• Occasionally submit new algorithms or find people to make ones we need.
• Write a tutorial on raywenderlich.com based on something from the Swift Algorithm Club every 3 months.

If you’d like to apply, you should email Kelvin Lau with your answers to these questions:

• Why do you want to be a co-maintainer on the Swift Algorithm Club?
• Please tell me a little about your experience with Swift.
• Please tell me a little about your experience with algorithms.
• Please link to any articles/tutorials you have written online.
• Please link to your GitHub account page.

My answer to the call

It takes great confidence to pose for a pic like this…
…the kind of confidence a co-maintainer needs!

I’m interested in the role, and emailed an application to Kelvin Lau. In the spirit of openness and collaboration, I’ve decided to share what I sent. Give it a look!

---

Hello, Kelvin!

I’m Joey deVilla, and I’d like to become a co-maintainer for Swift Algorithm Club!I’m a technology evangelist by day, and rock-and-roll accordion-playing mobile developer and bon vivant by night, as well as a long-time reader of RayWenderlich.com. I think I’d be well-suited for the role, and as proof, I have submitted my answers to the questions you posed in the article calling for co-maintainers.

Why do you want to be a co-maintainer on the Swift Algorithm Club?

I’ll admit it: a big part of my reason for wanting to be a co-maintainer on the Swift Algorithm Club is to be able to say “The first rule of Swift Algorithm Club is…to get ’em as close to O(1) as possible.”

But seriously, I’d like to be a co-maintainer of the Swift Algorithm Club for the following reasons:

• I’ve been a big fan (see all the references on my tech/programming blog) and beneficiary of RayWenderlich.com over the past few years and have always wanted to join the gang.
• I’ve been doing tech evangelism since 2000 (you can see my LinkedIn profile here), and in my current position as Technology Evangelist for Smartrac (an RFID company pivoting to an RFID-plus-software-platform kind of company), establishing good relations with the developer community is part of the job. I’d even be able to contribute to Swift Algorithm Club on company time!
• I like helping out developers, which is why I’m in my line of work. Some evidence:My Stack Overflow profile, where my reputation score puts me in the top 6%.
• As a tech evangelist, I don’t work directly on code with my company, and they currently don’t do iOS development anyway. Working on Swift Algorithm Club would give me a chance to keep learning, exercise my coding skills, and work with a language I love.

Please tell me a little about your experience with Swift.

• I love iOS programming and Swift to the point that I run an iOS developer meetup in Tampa Bay.
• I’ve written a number of Swift articles (see below).
• Last year, I took the RayWenderlich.com Cookie Crunch app, which was then written in Swift 1, and:
  • Updated the Syntax so that it would compile under Swift 2,
  • Added all sorts of tweaks, including multiple levels, a “hint” button, and a theme designed to promote a friend’s winery,
  • Put it on the App Store as a free app,
  • and posted the code on GitHub.

Please tell me a little about your experience with algorithms.

The boring stuff: I have a degree in Computer Science from Queen’s University, which is one of Canada’s nicer schools. I learned algorithms and data structures from Dr. Robin Dawes (4.2 rating on RateMyProfessors), and we’ve stayed in touch. I know my depth-first searches from my breadth-firsts, I can pronounce Euler properly (it’s “oiler”), and I know where the word “trie” comes from (retrieval).

I once had to explain to some art students why they couldn’t represent all the possible states of their game using individual QuickTime cells. It was a “Virtual Bubble Wrap” game with 95 bubbles, which meant that it would take 2^95 cells to represent every possible state (for comparison’s sake, the estimated number of photons in the universe is a smaller number: 10^89).

The more interesting experience: I am “internet famous” for using P=NP to figure out that I was dating a con artist. The story is on my personal blog under the title What happened to me and the new girl (or: “The girl who cried Webmaster”), and ended up in print in an anthology titled Never Threaten to Eat Your Co-Workers: Best of Blogs. 

Please link to any articles/tutorials you have written online.

I’ve been blogging since November 2001, with my personal blog, The Adventures of Accordion Guy in the 21st Century. I started my personal tech blog, Global Nerdy, in August 2006, and since then have written over 3,000 posts which have acquired over 8.6 million pageviews.

Here’s a small sampling of what I’ve written:

• Swift
  • Demonstrating map, filter, and reduce in Swift using food emoji
  • How to work with dates and times in Swift 3
    • Part 1: Dates, Calendars, and DateComponents
    • Part 2: DateFormatter
    • Part 3: Date arithmetic
    • Part 4: Adding Swift syntactic magic
  • Swift 3 text field magic
    • Part 1: Creating text fields with maximum lengths
    • Part 2: Creating text fields that accept only a specific set of characters
    • Part 3: Creating text fields that ban a specific set of characters
  • How to build an iOS weather app in Swift
    • Part 1: A very bare-bones weather app
    • Part 2: A little more explanation, and turning OpenWeatherMap’s JSON into a Swift dictionary
    • Part 3: Giving the app a user interface
    • Part 4: Introducing geolocation
    • Part 5: Putting it all together
  • Better to be roughly right than precisely wrong: Rounding numbers with Swift
  • How to fix the common “no sound from AVPlayer/AVAudioPlayer” problem in iOS/Swift programming
  • Sprite Kit actions tutorial
  • Simple “Shoot ’em up” game with Sprite Kit
    • Part 1: Code for the complete game
    • Part 2: Code organization and vector math
  • How to execute a block of code after a specified delay
  • A first look at Swift’s new access levels
  • You can use Swift’s “private” access modifier to limit the reach of overrides and extensions, but not monkeypatches
  • Updating RayWenderlich.com’s “AFNetworking Crash Course” for iOS 6
• Objective-C
  • Magic 8-ball tutorial
  • Simple weather app
  • A Step Forward (or: Objective-C Doesn’t Need Forward Declarations Anymore)
• C / old-school smartwatches
  • The inPulse Magic 8-Ball: A Beginner’s Tutorial for Programming inPulse Smartwatch Apps
• Miscellaneous
  • How GPS works, and how to make the most of it
  • Getting married, and getting my 2011 MacBook fixed
  • Staying sharp: Maintaining your development skills
  • Apple TV UX presentation
  • Just enough React to get you into trouble
  • A quick test run with the new Xamarin Community for Mac
  • Hello, Kodu!

I should also mention that while working at Microsoft as the Windows Phone evangelist (the second-hard evangelism job in mobile), I had a short-lived children’s show, complete with puppet co-host. Here’s the first episode: How to create your own games with Kodu

Please link to your GitHub account page.

I’ll admit that it’s not as fat as I would like, but here it is: https://github.com/AccordionGuy

If you have any questions or need additional information about me and my qualifications, please feel free to contact me!

— Joey

Another of my goals for this year is to considerably raise my proficiency with a programming language I thought I’d never use again, despite its ubiquity: Java.

Until last year — and by “last year”, I mean 2016 — I hadn’t done anything with Java since I looked like this…

…and since the preferred Java IDE looked like this…

…and was distributed via something like this:

That all changed thanks to the Tampa iOS Meetup, a regular gathering for people interested in learning how to develop iOS apps:

Angela Don and I started Tampa iOS Meetup in October 2015, fresh off a successful “Intro to iOS Programming with Swift” presentation at BarCamp Tampa Bay. The BarCamp presentation in turn was the result of our meeting at Ybor Tech OpenHack, a monthly gathering of programmers for conversation over beer at New World Brewery, one of Tampa’s better beer pubs.

The moral of the paragraph above is one I’ve been touting for years: if you want opportunities, you’ve got to network. One of my goals this year is to turn up my outreach, not just in the Tampa Bay area where I live, and not just nation-wide, but globally.

Java homework, after 16 years

At one of the meetups, one of the attendees asked me for help with an assignment for a Java course he was taking. I told him that I’d be happy to help, but warned him that it had been over a decade since I’d written anything in it. While C# (with which I have more recent experience) is similar to Java, it’s not the same thing. He was undeterred, and we arranged to meet at a coffee shop, where I could help him as he did the assignment.

Our meeting never happened. Between putting in a lot of overtime at work and tending to his family in the remaining time, he didn’t have any time to do the assignment and didn’t even have any idea of where to begin.

“I need it by tomorrow. Could you do it for me? Just tell me your hourly rate, and I’ll pay you,” he said.

“Look, let me see if I can even do it first,” I replied. “We can talk money later.”

“I’ll send you my assignment,” he said, “and it has to be done using JavaFX.”

“JavaFX it is,” I said, making a mental note to Google the term.

The first assignment

After spinning my wheels for what felt like an eternity trying to get a project using JavaFX (which turned out to be a GUI library) running using Eclipse (a.k.a. the worst IDE ever), I switched to NetBeans and had a simple “Hello World!” program operational in a few minutes.

With what remained of the evening, I now had to do the actual assignment: given a full filename that the user enters, read the contents of that file, and then display all the words in that file in an alphabetically-sorted list.

A couple of hours later — and some Googling for reference material on Java Lists, file operations, and JavaFX UI elements — I surprised myself with a working program:

After cleaning up the code and adding some Javadoc comments in order to make it academically complete, I emailed him the code (for the curious, it’s on GitHub). A couple of days later, he told me that he got full marks for the assignment. I was pleased with myself, and thought that this would be my last encounter with Java.

One good assignment deserves another

A couple of days later, he made a second call for help. I gave him a couple of pointers to put him in the right direction, but after a number of impassioned pleas, I ended up coding the whole thing. This time, it was a “states and capitals” quiz, complete with pop-up windows for right and wrong answers:

I used an Iterator to “step through” the set of states and capitals, which were stored in a Hashmap. I worried that using it might have been beyond the scope of the assignment, but it greatly simplified the code. My friend got full marks for the project, which you can find on GitHub.

The third time’s the charm

Good things come in threes, and with two assignments that earned full marks, my friend asked for help with the final assignment: the clichéd-yet-mandatory “access a database and display some of its contents” assignment. Here’s the text of the assignment, which for some reason was set in Comic Sans, which I’m sure is not the official font of Serious Database Work:

Create a JavaFX GUI that allows the user to retrieve records from the customers table in the “pcparts” database. The GUI should allow the user to specify desired fields, desired order, and a where condition. Display only the desired fields in the desired order for the desired where condition. You may display the records in the GUI in any way you wish.

This time, there wasn’t even any pretense that I’d provide tips and he’d write the program. I just told him to check his inbox later that night.

Here’s what my implementation looked like:

Once again, you can see it on GitHub.

As with the other two assignments, it was an evening’s worth of work, most of the time spent Googling for information about JDBC and Java ObservableLists. With the completion and submission of this assignment — and the full marks he got for it — my friend successfully completed his Java course.

“And that,” I thought, “will likely be the last I’ll see of Java for a while.” I decided that the projects shouldn’t go to waste sitting on my hard drive and posted them to my GitHub account, which needed some fattening anyway.

A headhunter comes a-callin’ (with a test)

A couple of months later, I got an email from a recruiter. Thanks to my online presence, I get these on a regular basis, but this one was intriguing:

Hi Joey,

I’m an IT Recruiter with [recruiting company], I came across your profile and was impressed with your skills and background so I wanted to reach out to you regarding an exciting opportunity!

Our client is looking to hire a Developer Evangelist to join their growing team based out of Baltimore, MD. They are looking for someone that is passionate about technology and can provide code samples, white papers, blog postings, and other educational content in order to demonstrate the power of our client’s platform. The role is 50% travel but in between trips to trade shows and conferences all of the work would be remote.

Unlike most of the recruiting emails I get, this one seemed worth replying to, and a day later, I had a phone interview. It went well enough for them to ask me for a resume, references, and — horror of horrors — take a timed online Java proficiency test.

“And this is where I’ll get taken out of the running,” I thought. There’s been at least one time when I’ve failed a test on a language that I was comfortable with and used regularly; how the hell was I going to pass test for Java, which I’d made a career of avoiding and with which I hadn’t worked with in 16 years, with the exception of those homework assignments?

I still went along with the process and took the test. I managed to answer a number of its questions, and a lot of that was thanks to the Java practice I got from doing my friend’s assignments. Despite that, I figured I’d get the “Sorry, you didn’t make the cut” email in a couple of days.

Instead, I got a call: “Congratulations! The platform architect and product manager would like to schedule an interview with you.”

The interview

All my interviews were conducted via Skype. The first and most crucial one was with Product Manager Jason Rusk (to whom I report) and Platform Architect Robert van Voorhees. During the interview, Robert asked if I had anything posted on GitHub, especially in Java. I pointed him to the assignments, and he gave them a quick once-over.

“Good clean code, easy to follow, nice notes,” he said, nodding approvingly.

Approved!

On the 15th of September, I got an email that started like this:

Hi Joey,

Congratulations again on your offer from SMARTRAC. I have attached a copy of your contract for you to look over. They would like to offer you an hourly rate of $[ask me in person over a beer]/hr and a conversion salary of $[again, ask me in person over a beer].

Moving forward

Smartrac’s Smart Cosmos platform is largely written in Java. While I’m not likely to contribute code to it, I’ll most certainly help partners and customers integrate with it. Furthermore, many of these other people may be coding in Java, and I’ll need to provide code samples in their language. Hence this year’s push to go back to Java after studiously avoiding it for nearly two decades.

Luckily for me, Smartrac hooked me up with IntelliJ IDEA Ultimate, a Java IDE that’s light-years better than NetBeans (and thousands of light-years better than Eclipse)…

…and I’ve been making the most of my spare moments getting Java practice in the form of Android development. Even at the airport, when my flights are delayed by hours:

None of this would’ve come about had I not helped my friend with his homework, so I suppose another one of my 2017 plans should be to help people learn to code when I can. You never know how it’ll pay off!

Creative Commons photo of Z566M nixie tubes displaying 2, 0, 1, and 7 by “Hellbus”.

As of the start of 2017, I’ll have passed the traditional 90-day probationary period as Smartrac’s Technology Evangelist. So far, it’s been an enjoyable, exciting, and challenging whirlwind.

It helps that I’m working with some brilliant people with all sorts of experience, ranging from electrical/radio engineering to biophysics to good ol’ computer science, to having been in the Navy and Homeland Security, and who’ve contributed to some open source frameworks that you may have used if you do front end web development.

I am the dumbest guy in the room, and that’s all right with me.

One of my goals for this year is to make the most of my proximity to all these smart people, and all the knowledge, chances to learn, and access to opportunities that they provide, and in return, showcase their brainpower and works to audiences both technical and non-technical.

The experience has been made even better by the sweet gear that I’ve been assigned…

…as well as the travel opportunities I’ve been in my short span of time at the company, including Asheville, North Carolina, where Smartrac has both an office and an RFID tag and inlay manufacturing facility…

…three trips to the Baltimore office, where our core platform development team works (well, we’re actually in Columbia, just outside Baltimore)…

…a partner visit in London at the start of December, and an upcoming trip to New York…

…where I’ll be working our booth on the exhibit floor at the National Retail Federation’s Big Show 2017, a conference that will be in its 116th year:

Another goal for 2017 is to make the most of the opportunities presented before me, whether in the form of the material support that I get from the company, as well as the chances to travel all over the U.S. and the world to meet customers, developers, partners, prospects, and talk about Smartrac’s technology. In the rush and general busy-ness of working in a fast-paced business where the stakes are high, it’s all too easy to forget that with this line of work come some pretty rare opportunities.

At the heart of Smartrac’s offerings is the Smart Cosmos platform, a data virtualization technology for real-world objects and their interactions that is built around something that we call the TRIM metaphor.

Hey, we’re a tech company, so of course TRIM is an acronym:

If you combine Smart Cosmos with a technology to make real-world objects detectable by processing power — such as the RFID technology that was the original basis of Smartrac’s business — you’ve got the basis for a lot of applications, from manufacturing to retail to healthcare and more.

A technology like Smart Cosmos needs to be explained to a number of parties, from technical decision-makers and the developers who have to integrate Smart Cosmos with their organization’s systems and workflows, to non-technical decision-makers who need a layperson-friendly explanation of the technology they’re counting on to drive their business. That’s where I come in.

As far as Smartrac is concerned, my big goal for this new year is to spearhead the revision of our library so that both technical and non-technical people who want to find out more about our platform, from the broadest, high-level strokes to the finest details of its API and inner workings, can do so quickly, easily, and accurately. A lot of this will be the wholesale updating of the Smart Cosmos site, writing and editing the blog, case studies, white papers, documentation, and creating documents that aren’t limited to writing, but also audio (in the form of things like podcasts), audio-visual (in the form of videos) and even interactive tools. As far as I’m concerned, as long as what I produce helps our audience understand our platform, the sky’s the limit.

It’s going to be an exciting year!

Over the past little while, Apple has been telling iOS developers that by January 1, 2017, in order to be in the App Store, any app that made a connection to a server could do so only via a secure one — that is, only HTTPS and not HTTP connections would be allowed. They’ve just announced that “this deadline has been extended and we will provide another update when a new deadline is confirmed.”

Starting with iOS 9, apps allowed only HTTPS connections by default. However, many servers — including OpenWeatherMap’s, which powers a number of weather apps, including the one featured in my tutorial — don’t accept HTTPS connections. That’s why they still offer the option to let your app make connections over plain old HTTP by changing the default App Transport Security settings in the app’s info.plist file.

You could allow apps that you were developing to use plain HTTP connections by editing their info.plist files in its text form and adding this snippet…

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSAllowsArbitraryLoads</key>
  <true/>
</dict>

…or do it the graphical way:

While requiring that all connections be secure ones helps to keep network data secure and reduce the probability of unwanted access, a large number of web services are still not using secure connections. This is probably the reason for the deadline extension.

You have a reprieve, iOS developers, but the sooner your apps’ connections are secure, the better.

For the new year, I’ve decided to try a new approach with Tampa iOS Meetup, the regular Tampa Bay gathering that I run, where I cover developing apps for the iPhone and iPad. Instead of focusing on a single programming topic, each Tampa iOS Meetup session in 2017 will cover the highlights of developing a single app, starting with the concept, then look at the features, technologies, and libraries that we’ll need in order to build the app, and then show you how to bring them all together and turn the concept into a finished, working app.

The reason I’m going with this new approach is that I’ve been asked the same question again and again, and it goes something like this:

“I’ve been studying iOS development for some time, and I’m still having a problem writing apps. I know how to program specific features in iOS, but I don’t know how to turn a bunch of features into an app.”

It’s one thing to go through tutorials that show you how to program a specific feature. It’s a completely different thing to take the knowledge from those tutorials and then write an app. My goal for Tampa iOS Meetup in 2017 is to show you how to make that leap by walking you through the process of making apps.

Tampa iOS Meetup’s 2017 sessions will start on Tuesday, January 31, 2017 at 6:30 p.m. at the offices of Wolters Kluwer’s Westshore office (1410 North Westshore Blvd, suite 400) with a relatively simple app: the dreaded tip calculator.

Why “dreaded”? That’s because it’s a relatively simple app, and a lot of people — especially in the App Store’s early days — made their own version. There are a few nice ones, but most of them are pretty sad. Our goal for the meetup will be to cover the many ways to make a tip calculator app that you wouldn’t be ashamed to put in your developer portfolio.

In the session, we’ll cover a number of topics, including:

• Making the most of user interface controls
• Animations and other visual effects
• Using rounding functions
• Useful hints for the Swift programming language
• Taking advantage of those little things that make an app feel more solid and professional

This session will be suitable for newcomers to iOS development. If you’ve done some simple JavaScript development, you shouldn’t have any problem following along. If you’re new to programming in general, but have always wanted to make an iOS app, this is an ideal first project.

You’ll come out of this session with a better understanding of the app development process, as well as source code and notes that you can use in writing your own apps.

Does this sound like something you’d like to catch? Find out more on the Tampa iOS Meetup page, where you can sign up to attend. Once again, the session takes place on Tuesday, January 31, 2017 at 6:30 p.m. at Wolters Kluwer’s Westshore office (1410 North Westshore Blvd, suite 400). I hope to see you there!

Click the comic to see the full version.

Toggl, the people who brought you the hilarious (well, hilarious to us developers, anyway) comic How to save the princess using 8 programming languages, have come up with a new one: IT jobs explained with a broken lightbulb.

I’ve posted an except above, which shows the 4 major roles that I’ve played, in one form or another, throughout my career. My current job as Smartrac’s Technology Evangelist mixes all of them together, which pleases me greatly.