ron and arlene klein at next money tpa

Click the photo to see it at full size.

Last night, I had the pleasure of meeting inventor Ron Klein and his wife Arlene, at the Next Money TPA meetup. If you’re a reader of this blog, it’s likely that you’ve used at least one of his innovations:

  • The MLS — as in multiple listing service — for real estate,
  • Interactive voice response for banks,
  • a bond monitoring system for Wall Street traders…

…and then there’s the innovation you’ve most likely used — automated validation of credit cards through the use of a magnetic stripe:

He was also an artillery forward observer in the Korean War, where he went on 58 missions. He got hurt during the last one, resulting in a spinal injury, and earning him a Purple Heart. The injury caused him painful spinal stenosis, where the bones in his spine put pressure the spinal cord and related nerves leading from it. He took up exercise, which he found was pain-relieving, and does it so often that he’s participated and won medals in the Florida Senior Games.

ron klein with bike

In the bad old days, credit card validation was done manually. Any merchant that accepted payments via credit card was given a long paper list of “bad” credit card numbers, and would have to “eyeball” the list in order to valid a credit card. I remember when this sort of thing was still done in the early 1970s, and it was slow even under the best of circumstances, never mind during big sales or something like Black Friday.

Klein, then director of engineering for Ultronics Systems Corporation — which would later become part of GT&E Financial — developed a “validity-checking system”, which allowed merchants to enter credit card numbers into a “desk-mountable interrogation unit” that could check against a central store of credit card numbers which would be stored in drum memory. If the account number on the card wasn’t on the “bad” list, the desk unit would show a “credit good” light; otherwise, it would display an error signal.

According to, Klein’s original design for the verifier was such that a bad credit card would be held by the device. “If the credit wasn’t good,” he said, “it locked up the card so that the person didn’t get the card back, because the merchant got credit for capturing negative-account cards.”

At the age of 81, Ron could simply enjoy a quiet retirement, but that’s not his style. “I took three months off, but I got bored,” he said. “I’d rather keep busy, taking on new challenges. I’m not empty yet!”

He spoke to the group for about 90 minutes, regaling us with stories about his childhood, the business world, and his drive to find solutions to problems.

One theme he kept repeating to the meetup group was to simplify. “There’s a fix for everything, a solution for every challenge. The trick is to simplify. Identify the problem, simplify, then be smart, daring, and different.”

Another bit of advice he gave to the group was to “Be a smiling cobra, and never point an unloaded gun,” which I took to mean be nice as much as you can, but be tough when you have to — and mean it. I found him to be quite affable, but if he managed to operate in the world of Wall Street, I can he his need to be a cobra from time to time.

ron and arlene 2

His last bit of advice to the group was to “sell the benefit, not the idea”. This is a good reminded for anyone who’s inventing a product or service — nobody cares about inventions for their own sake, but the benefits they provide. This may seem obvious to some, but as I like to say, there’s great power in stating the obvious.

Ron lives in Sarasota, about an hour and a quarter south of my place. I may have to drive down there sometime, take him and Arlene out to lunch, just so I can hear more stories about the things he created — and is still creating. My thanks to Ron and Arlene for appearing at the Next Money TPA meetup!

next money tpa

Next Money TPA is the Tampa chapter of Next Money, an international group of fintech communities, and the meetup group that brought Ron Klein to speak. Next Money TPA brings together people from the Tampa Bay area to discuss the intersection of finance, technology, design, and creative spaces. Organized by Bruce Burke, the meetup invites “casual, entrepreneurial, inquisitive minds” to gather, share ideas, and meet each other.


location services

If you’re an iOS developer in the Tampa Bay area and looking for something to do this Thursday evening, you’ll want to check out the Suncoast iOS Meetup. This session is called Core Location In depth: Get your location even if your app gets killed!

Here’s the abstract for the meetup:

In this session, I will explain in depth how the iPhone gets your location and which APIs are available in the latest version of iOS.

  • Do you know that the iPhone combines three different radio signals to obtain your location?
  • Do you know how to track the location even when your app is not running?
  • Do you want to get an alert when the user arrives to one specific location?
  • Even if your app is killed or is not active?
  • Do you know how to debug your location code with the iOS simulator?

Come to the session and you’ll get the answers.

This session will be a presentation with some slides and some short demos with Xcode. No prior knowledge is necessary. Everyone is welcomed.

juan catalanSuncoast iOS Meetup is organized by Craig Clayton and Juan Catalan, both of whom write apps for a living. I’m going to catch this one, partly because it’s been too long since I last attended a Suncoast iOS Meetup, partly because I’ve never seen Juan present, and partly because I can’t answer “yes” with complete certainty to all the questions in the abstract.

This meetup will take place this Thursday, July 28th at 7:00 p.m. at Tampa Bay Wave, located in downtown Tampa (500 East Kennedy Boulevard, 3rd floor). Attendance is free, but you should register to attend!


The Pokémon Go developer roundup for July 23, 2016

by Joey deVilla on July 23, 2016

Pokémon Go is the number one app for iOS and Android

[via Polygon] On Friday, Apple confirmed that Pokémon Go got more downloads in its first week than any other app in the history of the App Store, which opened just over eight years ago on July 10, 2008. Apple won’t get any more specific than that, Nintendo are referring all inquiries about download statistics to The Pokémon Company, and nobody’s heard anything from them. The “mium” part of “freemium” means that Pokémon Go still makes money — anywhere from $1 million daily (according to Business Insider, or whomever they’ve semi-plagiarized) to $2.3 million daily (according to Superdata Research).

top free apps

At the time of writing, Pokémon Go holds the number one position on the “Free” and “Top Grossing” charts of both the App Store and Google Play. Nicolas Beraudo, the EMEA managing director for the mobile analytics firm App Annie says that “I can easily envision a run-rate of over $1 billion per year with less server issues, a worldwide presence, and more social and [player vs. player] features.”

A Pokémon Go utility is the number 3 free app on the App Store

poke radar tampa

As I write this, the number 3 free app on the App Store is a third-party Pokémon Go utility app called Poké Radar. It’s a crowdsourced Pokémon location database that lets players find or submit Pokémon encounter locations worldwide. The image above is a screenshot from Poké Radar that shows user-submitted Pokémon encounters in my stomping grounds, the Tampa Bay area.

This likely won’t be the last third-party Pokémon Go utility; the current Pokémon craze and potential $1 billion pie means that even a small slice of the business is too big an opportunity to pass up. If you’ve got the time and the resources, you should try developing a Pokémon Go helper app.

Where to go if you’re thinking about writing a Pokémon Go app


Not surprisingly, a number of online resources for developers interested in building Pokémon Go tools have appeared online. This is a hot new topic, and you should expect to see new resources spring up quite often for the next few weeks, but here are the three best starting points that I’m aware of:

A word of warning: Some of the code pointed to by these resources appears to use not-necessarily-approved access to data streams between devices and Pokémon Go servers. All the standard “I am not a lawyer” and “Caveat implementor” warnings apply.


just enough react title slide

I had the opening presentation in the “Miscellaneous and Open Source” track of Tampa Code Camp 2016, which took place on July 16th. My presentation was titled Just enough React to get you into trouble, and was designed to be an introduction to building user interfaces using React.

In 50 minutes, I introduced React to the audience mostly by live-coding a simple React application in a JSFiddle playground. For those of you who missed it (or saw it and wanted to review it), this article walks you through my presentation. Enjoy!

Playing around with React in a JSFiddle playground

I spent most of my presentation live-coding some a simple React application in JSFiddle, a “playground” that lets you quickly try out web development ideas in your browser and save them for later use. A saved “playground” is called a fiddle, and you can fork other people’s public fiddles for your own experimentation.

JSFiddle has four key areas — HTML, CSS, JavaScript, and output, as shown below:

jsfiddle diagram

Click the screenshot to see it at full size.

JSFiddle lets you enter the HTML, CSS, and JavaScript into the corresponding areas and then see the result in the output area by clicking on the Run button located near the upper left-hand corner of the page. It even lets you import a number of JavaScript and CSS libraries.

In this exercise, we’ll work using a base fiddle that imports the libraries necessary for a React application, and we’ll do all of our coding in the JavaScript area.

Let’s start with a simple React fiddle

Let’s start by navigating to the fiddle that I set up as the starting point for the presentation. I forked it from the React base fiddle, and if you set up your own JSFiddle account, you should fork it for yourself.

The fiddle features one of the simplest React applications that you can write: “Hello, world” for React. Here’s the JavaScript:

And here’s a screenshot showing the output:

hello world

Let’s take a closer look at what’s going on in the JavaScript code…

1. First, we create a React component named Hello.

React is all about creating user interfaces by assembling modular, composable components. For this first example, we want to create a component named Hello, which is made up of a single <h1> heading. We do this by creating a class named Hello, which subclasses React’s React.Component class:

Our Hello class has a single method, render. React component classes can implement many methods, but must implement a method called render, which returns a value that shows how the component should be drawn onscreen. The value returned by render depends on the kind of React app we’re working on:

  • In a web application, the render method returns a single HTML element. This single HTML element is allowed to contain other HTML elements.
  • In a native mobile application, the render method returns a single view. This single view is represented in a dialect of XML whose elements represent native mobile UI elements. This view is allowed to contain other views.

(For now, we’ll stick to React web applications. I’ll look at React native applications in a later article.)

Here’s the value returned by the render method:

You’ve probably noticed that it’s not in quotes as you might have expected. That’s because render‘s return value isn’t a string that contains HTML.

Instead, its return value is JSX, a dialect of XML whose name is short for “JavaScript XML”. It looks like HTML, and it’s meant to — it’s a shorthand for the value that the render method actually returns, which is a React element — a JavaScript object. This fiddle — and many React applications — includes a extension that preprocesses JSX into JavaScript that generates a React element.

Here’s what render really returns, once the JSX has been processed into JavaScript:

In fact, you can have render directly return a React element. Try changing the render method so that it looks like this, then click the Run button to run the app:

The output should look like this:

hello world the hard way

Click the screenshot to see it at full size.

Generally, React developers prefer to work with JSX. It’s preprocessed, so using it doesn’t affect your application’s efficiency, and it’s much easier to read, especially as you work on more complex React projects.

2. Then we render the Hello component onto the page.

Here’s the line that renders the Hello component onto the page:

The ReactDOM.render method takes two arguments:

  1. A React element to render. In this case, the react element is the output of Hello‘s render method, which we request by using the JSX tag <Hello />.
  2. The DOM node where the React element will be rendered. In this case, we specify that it should be rendered in the node whose id is app. If you look in the HTML area of the fiddle, you’ll see it at the very end:

This is one of the two things you should take away from this tutorial: At its core, building user interfaces in React is about defining components and then rendering them onto the screen. Everything else builds on this basic principle.

Let’s continue. If you changed the render method in Hello to use JavaScript instead of JSX, change it back. The code in the JavaScript area of the page should look like this:

Pass information to a component with a prop

Suppose we want our application to be a little more flexible in who it says “Hello” to. Let’s change the component so that it can be passed a name parameter, and then says “Hello,” followed by that name.

Update the code in the JavaScript area so that it looks like this:

Let’s first look at the ReactDOM.render line. Note that we’ve added an attribute to the Hello element:

The use of XML attributes in React elements allows us to pass values to the corresponding components. In the Hello element, we’re using an attribute called name to pass the string “Kate” to our Hello component.

Within the Hello component’s render method, we access that value by using the component’s props (short for properties) object and assign its value to a variable…

…and then we use that variable within the JSX returned by the render method. Note that the variable is delimited by { }:

When you click on the Run button in JSFiddle, here’s what you should see:

hello kate 1

Click the screenshot to see it at full size.

For components, props are read-only — they can take in props and use their values, but they can’t change them. They’re meant to be used to set up components.

Using multiple props and rendering more stuff

Let’s change our app so that it says “Hello, Kate!” followed by a greeting:

If you click the Run button right now, the output area will contain…nothing:

hello kate 1

Click the screenshot to see it at full size.

In many cases, when the output area is blank when you don’t expect it to be, it means that there’s an error in your code. In this case, it’s the fact that the render method is supposed to return only one HTML element, but our returns two:

While render is supposed to return a single HTML element, that single element is allowed to contain other elements. The fix is to take our two elements and enclose them in a <div> like so:

Here’s what your code should look like now…

…and here’s what things should look like when you hit the Run button:

hello kate 2

Click the screenshot to see it at full size.

Introducing default props

In addition to passing values to React components using props, we can also create default values through the use of default props. Change the code in the JavaScript area of the fiddle so that it looks like this:

Note that the <Hello> tag in the ReactDOM.render call doesn’t contain any attributes. This means that we’re not passing any props to it, which in turn means that our Hello component will use the default props defined in this line of code:

If you run the application, you’ll see that the Hello component uses the default props, addressing the user as “stranger” and using the greeting “Please press the button”:

hello stranger

Click the screenshot to see it at full size.

However, if we change the <Hello> tag in the ReactDOM.render call so that it has name and greeting attributes, as shown in the code below…

…when you run the application, the Hello component uses the given props, addressing the user as “Kate” and using the greeting “Welcome to Tampa Code Camp”:

hello kate 3-2

Click the screenshot to see it at full size.

Adding state and interactivity

As I mentioned earlier, as far as components are concerned, props are read-only. They can only be set by attributes in the tags that invoke them and in the statement that sets their default values. With only read-only data like props, components themselves would also be read-only. What we need is data that components can change in response to user input or events, and that’s what state is for.

State is represented by the state object, which every React component has. Like the props object, it’s a “dictionary” that components can use to store values. However, there are two key differences between state and props:

  1. Unlike with the props object, the state object is read-write. Components can change the values within the state object by using the setState method.
  2. Any change to a component’s state object causes its render method to be called.

That second difference is key; in fact, it’s why the library is called “React”. The name is a nod to reactive programming, which is often defined as being “oriented around data flows and the propagation of change” (in fact, Wikipedia uses his definition). A greatly simplified way to describe it as “programming code that responds to changes in data”.

And now, here’s the second of the two things you should take away from this tutorial: Making changes to React components is all about changing their state. Or, if you’re into snappy rhyming mantras or hip-hop, remember it this way: Change the state to make it update.

Modify the code in the JavaScript area so that it looks like this. Don’t worry about any of the unfamiliar stuff; I’ll walk you through it in a moment:

When you press the Run button, you should be greeted with “Hello, stranger!”, an invitation to press a button, and a button, as shown below…

hello stranger 2

Click the screenshot to see it at full size.

…and when you press that button, the name you’re referred to and the message below it change:

hello stranger 3

Click the screenshot to see it at full size.

Let’s take a closer look at the code. We’ll start with the render method, which is often a good place to start analyzing React components:

The main difference between this render method and the previous one is the addition of this form code:

The onSubmit attribute of the <form> tag is set to {this.onSubmit}, which means that when the form is submitted — which in turn that means that the user has clicked the button — the class’ onSubmit method is called. Let’s look at onSubmit now:

Two things are happening in this method:

  1. First, the event.preventDefault method is called. This stops the page from reloading, which is the default behavior when a form is submitted (it also explains the name of the method).
  2. Then, the setState method is called, which changes the properties of the state object so that:
    • name‘s value is changed to “button-presser”, and
    • greeting‘s value is changed to “Thanks for pressing the button”.

And since we’ve changed state, the render method gets called, which in turn causes it to display the new state values.

Finally, let’s take a look at the constructor:

Here’s what’s happening in this method:

  1. The props argument that constructor takes contains the properties that were passed to Hello via the <Hello> tag’s attributes. As with constructors in many other programming languages, we pass this argument to the component’s superclass with super(props).
  2. The onSubmit attribute of our form specifies that the this.onSubmit method should be called when the form is submitted. The problem is that within the JSX, the this in this.onSubmit is undefined. We solve this problem by binding the onSubmit method to this specific instance of the Hello class, so that the this in this.onSubmit points to this instance (if you’re skeptical, comment out the line this.onSubmit = this.onSubmit.bind(this) and try running the app). You’ll need to do this sort of binding for every method that you call from JSX.
  3. And finally, we update the state object, which in turn causes the render method to get called, redrawing the component with the new values.

A little more interactivity

Let’s add a text field to our application, and change the code so that we first run, it looks like this:

interactive 1

If you leave the text field blank and click the Enter button or hit the Return key, the output area should change to display this:

interactive 2

If you type the name “Zaphod” into the text field and click the Enter button or hit the Return key, the output area should change to display this:

interactive 3

Here’s the code that does this:

Let’s take a closer look at the code. We’ll start with the render method:

The only difference between this version of the render method and the previous one is the addition of a single line containing an <input> tag:

It looks like a standard <input> tag, but it has a strange attribute called ref. That’s short for reference, and it a way for other code to access this tag. Think of it as being similar to HTML’s id attribute, but for React. We access refs that we define in JSX via the refs object, which is similar in structure to the props and state objects.

The onSubmit method isn’t all too different, either:

Some notes:

  1. We’ve created a new constant, nameTextField, which holds a reference to the element whose ref is nameTextField — the text field into which the user enters his/her name.
  2. We fill another constant, newName, with the contents of nameTextField, trimmed of leading and trailing white space.
  3. We clear the text field.
  4. If the user entered something into the text field, newName‘s length will be greater than 0, and we change the state so that the newly-entered name becomes the value for the state key name and “Pleased to meet you” becomes the value for the state key greeting.
  5. If the user entered nothing into the text field (or entered nothing but white space into it), newName‘s length will be 0, and we change the state so that the value for the state key name is “stranger”, and “Seriously, please enter your name” becomes the value for the state key greeting.


So far, we’ve created a single component, Hello, for our application. For a simple tutorial app, this approach — sometimes called the Big Ball of Mud — is a workable one. You wouldn’t want to use it for an app of any appreciable size, as it becomes hard to code, manage, and maintain. Ideally, a React UI is supposed to be made up of small components that collectively form a larger whole.

Let’s break up our simple app into components as shown in the diagram below:


Note that in the diagram, the UI is broken into three components:

  1. Greeting: This displays the name and greeting.
  2. NameForm: This displays the form, which contains our text field and button.
  3. Hello: This contains both the Greeting and NameForm components.

Greeting and NameForm present UI components, and are thus called presentation components. Their job is to present user interface elements that are visible to the user.

Hello is used as a container for other components, and is hence called a container component. Its has a couple of jobs:

  • To act as a container for other components, Greeting and NameForm in this case, and
  • To contain the user interface state and logic for itself and its child components (again, Greeting and NameForm).

Let’s start by coding the Greeting component, one of the presentation components:

It’s a pretty simple component: it expects two props — name and greeting — and displays them appropriately. Nothing new here.

Note that Greeter doesn’t make use of any state; it simply accepts two props and displays them. It doesn’t do any “thinking”. You’ll see this approach in a lot of React code, where presentation components don’t have much logic them and a primarily concerned with the display and input of information.

Think of this as the mantra for presentation components:

youre not paid to think

Let’s now code the NameForm component, the other presentation component:

The only really different part is the if statement in the onSubmit method:

In the previous version of our onSubmit method, both branches made changes to the state object. This time it’s different:

  • If the user entered something into the text field (i.e. newName‘s length is greater than 0), it calls a method called onNewName, which is stored in the props object. It passes newName as an argument to onNewName.
  • If the user entered nothing or just white space into the text field (i.e. newName‘s length is 0), it calls a method called onNoName, which is also stored in the props object.

Note that both onNewName and onNoName are stored in NameForm‘s props. This means that NameForm has very little built-in logic for dealing with user input, but instead receives this logic from an outside source through its props. As with Greeter, NameForm doesn’t make use of state. Once again, this is an approach you’ll see in a lot of React code — presentation components doing as little “thinking” as possible.

Both Greeter and NameForm receive their props from their container component, Hello. Let’s look at its code:

Let’s look at its render method first:

Note that the <div> it returns has two component tags and nothing else:

  1. Greeting: We pass the current name and greeting to it via the attributes, which it receives as props.
  2. NameForm: We pass it two methods — handleNewName and handleNoName — via attributes, which it receives as props.

Let’s take a look at handleNewName and handleNoName:

Note that:

  1. handleNewName does just one thing: change the state so that the value for name is set to the contents of newName, and the value for greeting is set to “Please to meet you”. Changing the state of the Hello component causes its render method to be called, which in turn causes the Greeting and NameForm components to be redrawn, which causes them to call their render methods as well.
  2. handleNoName also does just one thing: change the state so that the value for name is set to “stranger”, and the value for greeting is set to “Seriously, please enter your name”. Changing the state of the Hello component causes its render method to be called, which in turn causes the Greeting and NameForm components to be redrawn, which causes them to call their render methods as well.
  3. handleNewName and handleNoName are passed as props to NameForm, which uses their logic to perform tasks based on what the user enters or doesn’t enter into NameForm‘s text field. It appears that while Hello doesn’t present any user interface of its own, it does a lot of the “thinking”.
  4. Note that Hello‘s methods, handleNewName and handleNoName, are passed to NameForm as props with the names onNewName and onNoName. This is a naming convention used in React:
    • When defining a function that will be passed to a child component, prefix the function name with handle. A name beginning with handle implies that we’re defining a response to a specific event.
    • When passing a function to a child component as a prop, prefix the prop name with on. A name beginning with on implies that we’re calling on a defined response to a specific event.

Let’s take a closer look at the constructor:

The constructor sets up the app’s initial state based on the default props. It also binds the handleNewName and handleNoName methods to the current instance, so that they can be called when they’re passed as props to the NameForm component.

Speaking of default props, here’s the function that sets Hello‘s default props:

That’s the complete definition for the Hello component.

We’ve just reviewed all the code in the app piece by piece. Here’s the complete code:

Looking at the entire application, note that the Hello component, as the container component, doesn’t display any UI of its own; it simply displays its child components. However, it also contains all the “smarts”, maintaining the state of the application and passing its child presentation components any information they need:

  • Hello passes data to the Greeting component, namely the name and greeting it should use, and
  • Hello passes instructions to the NameForm component, namely what it should do if the user entered a name (handleNewName) and what it should do if the user left the name text field blank or filled with white space (handleNoName).

In the meantime, the Greeting and NameForm components present their parts of the UI and do what they’re told as specified by the props passed to them.

You’ve probably noticed that this arrangement ensures that the flow of information in this application is one-way, starting at the top and going down…

flow of information

…with the top-level reactDOM.render method calling on the Hello component to render itself, and the Hello component providing data and instructions to the Greeting and NameForm components and calling on them to render themselves. The information doesn’t flow the other way — The Greeting and NameForm components don’t send any information to the Hello component, and the Hello component doesn’t send any information to the code>reactDOM.render statement. This one-way flow of information simplifies development and is a basic principle of React.

Next steps

next steps

You’ve probably suspected that this is just the beginning. You’re right — there’s only so much you can cover in a 50-minute presentation, and React is already a large topic, and it’s continuing to grow. Here are some resources you might find handy:

  • The official React site: Sooner or later, you’ll have to go to the mothership, and that’s what this site is — the official source of the React code, and home of the official documentation.
  • The React base fiddle: If you want to play around with React code in a fiddle (an online playground), this is a good place to start.
  • build with react: This site describes itself as “a periodical of tutorials and advanced articles for the react.js library”.
  •’s React.js tutorial:  If you learn better from video tutorials, you should find this one helpful. This is the first in a series of tutorials.
  • Questions tagged “reactjs” in Stack Overflow: If you have a programming problem, chances are that many other people have (or have had) the same problem, and it may have already been solved. That’s what good ol’ Stack Overflow is for!
  • The ReactJS Tampa Bay Meetup: If you’re local to the Tampa area, there’s a React meetup that meets twice monthly! They alternate between “lecture” and “lab” formats every two weeks, the group is friendly, and you’ll learn a lot.


slightly-off sink

“We’ll fix it in the next sprint.”


Why you should attend Tampa Code Camp this Saturday

by Joey deVilla on July 11, 2016

tampa code camp

What’s Tampa Code Camp?

tampa code camp logoTampa Code Camp is an annual community learning event for programmers in the Tampa Bay Area. This year’s edition takes place this Saturday, July 16th at the KForce offices, located just on the edge of Ybor City.

This year, Tampa Code Camp will feature 28 presentations across 4 tracks — cloud, web/mobile, .NET, and miscellaneous and open source — presented by local developers who are volunteering their time to share their knowledge. Tampa Code Camp is free to attend (but you need to register) and provides free donuts in the morning and a free lunch to attendees, thanks to the generosity of its sponsors.

Why should you attend Tampa Code Camp?

hands on laptops

Developer and author of AngularJS in Action Lukas Ruebbelke wrote in What I Wish I Could Tell My Younger Programmer Self that the three things he wishes he could tell his younger self are:

  1. Surround yourself with programmers
  2. Surround yourself with better programmers
  3. The community’s success is your success

He’s right. Learning to program is enhanced when conversing and collaborating with other programmers. It’s even better when you can find peers from whom you can learn, and who challenge to become better (Mom was right — you should choose your friends carefully). And finally, the time and effort you invest into the local developer community often pays off with interest.

For Tampa Bay developers, Tampa Code Camp is a great way to follow Lukas’ advice to his younger self. It’s a great way to meet your industry peers, and from my experience at past code camps, you’ll always find people from whom you can learn. The connections you make at code camps can greatly benefit both your personal and professional life. And finally and most importantly, events like this — events that educate, support, connect, and strengthen the developer community — help to build Tampa Bay’s tech social capital and make it a better place for developers to live and work.

What’s being presented at this year’s Tampa Code Camp?

joe darkoTampa Code Camp opens with a keynote by a person of note. Last year, it was Mayor Bob Buckhorn, who talked about the importance of helping grow Tampa’s technological sector, especially for small businesses and startups.

This year’s keynote speaker is Joe Darko (pictured on the right), Program Manager Evangelist with Microsoft. He’ll open this year’s Tampa Code Camp with a talk about community and what it means to Microsoft.

The day’s 28 technical presentations will start at 9:00 a.m. and will be arranged into four tracks:

  1. Cloud
  2. Web/mobile
  3. .NET
  4. Miscellaneous and open source

A free lunch (usually sandwiches) will be served from 11:50 a.m. to just before 1:00 p.m., and there will be an after-party sometime around 6:00 p.m. at a nearby location to be announced.

Here’s the schedule, broken down by track:

Cloud track

Web/mobile track

.NET track

Miscellaneous and open source track

Who’s behind Tampa Code Camp?

Tampa Code Camp is a volunteer, labor-of-love effort by and for the Tampa Bay developer community. It’s pulled together every year by Greg Leonardo and Kate Leonardo, with the generous help of these sponsors…

…and of course, the presenters and volunteers who help run the event.

How do I sign up to attend Tampa Code Camp?


Go to Tampa Code Camp’s registration page to register. Please do so — it helps the organizers plan for space, food, and other amenities, and it’s the least you can do since the event is free.

I’ll see you there on Saturday!


first but not last

One of my goals for this year was to finally build a finished app (well, as “finished” as any software development project gets, anyway) and put it in the App Store. That happened this week when I finished coding Aspirations Winery’s Wine Crush — like Candy Crush, but with wine — and submitted it to the App Store for approval Tuesday evening. The approval came Wednesday afternoon, and by Wednesday evening, it was available from the App Store!

The app runs on iPhones, iPads, and iPod Touch devices running iOS 9.0 or later.

Rather than tell you what Aspirations Winery’s Wine Crush is like, let me show you in a video that runs exactly one minute and thirty seconds:

Here are screenshots of the first four levels in the game. Each one is slightly more challenging than the last:

wine crush - first 4 levels

Aspirations Winery’s Wine Crush is free as in “it will not cost you a thing, ever”, and not free as in “freemium”:

south park freemium

If you’d like to get your hands on this app, you can click on the graphic below, which I am now allowed to use…

download on the app store

…or you can simply fire up the App Store on your iPhone, iPad, or iPod Touch and search for Aspirations Winery or Joey deVilla.

My thanks to:

  • Bill and Robin Linville of Aspirations Winery for going along with my “Hey, let me make an app for your business”, and for rewarding me and Anitra with their friendship and a fair bit of free wine to boot,
  • Robin Linville for creating most of the game’s graphics, and
  • my wife Anitra Pavka for her testing, occasional prodding to finish the app, and suggestions.