Posts

Machine learning (ML). Artificial intelligence (AI). Internet of Things (IoT). It seems these days there are so many complex terms flying about. In this blog, we’ll break down the basics and share how you’re experiencing these technologies in ways you may not have even realized.

Artificial Intelligence

We can’t talk about machine learning without first discussing artificial intelligence. Long before ML and IoT were commonplace, the concept of AI existed. The term was coined by John McCarthy decades ago in 1955 describing it as, “making a machine behave in ways that would be called intelligent if a human were so behaving.”

Simply put, AI is when machines handle tasks in an intelligent manner in the same ways humans would. Did you know you have AI all around you? Apple’s Siri, Amazon’s Alexa, Google’s personal assistant, and Tesla cars are all examples of AI at work.

Machine Learning

Machine learning is a product of artificial intelligence. Where AI is the ability of machines to handle tasks in an intelligent manner, ML takes it one step further and says that machines should not only handle complex tasks the same intelligent way humans would, but they should also have the ability to learn how to handle the complex tasks themselves. This concept is also decades old, dating back to 1959 when Arthur Samuel coined this term defining ML as, “the ability to learn without being explicitly programmed.”

Do you know that saying ‘all squares are rectangles, but not all rectangles are squares’? Well, the same is similarly true here: all ML is AI, but not all AI is ML.

Interested in the technical aspects of ML, including how neural networks are used? Our software engineer Taylor shared his thoughts and experiences on the blog before.

So how are you experiencing machine learning in your everyday life? Amazon and Netflix recommendations are great examples. As the two learn your buying or watching habits, they make recommendations of what you may be interested in next – and most times, they’re spot on! Or have you ever noticed that as you use your iPhone more and more for texting that it begins to pick up on your common spellings, acronyms and dialects? That’s machine learning.

My name is Ashlee. It’s spelled a little differently than most Ashleys, but my parents spelled it that way when I was born and I haven’t found it on keychains ever since, so what can I do? Apple didn’t program the iPhone to know that when I start typing Ashlee to not autocorrect it to the more popular Ashley, but after several times of me typing and then undoing the autocorrect to change the spelling back to Ashlee, my phone learned that when I type Ashlee, I mean Ashlee not Ashley. That’s machine learning.

And what about Internet of Things?

Artificial intelligence and/or machine learning can converge in the physical world with Internet of Things. IoT is the category of physical objects – like lightbulbs, thermostats, door locks, plugs, etc. – that are connected to the world via the Internet. When those IoT devices also employ ML, like when a Nest thermostat learns your temperature preferences and adjusts the temperature inside your house for you without your action, the two worlds are colliding.

At Oak City Labs, our mission is help businesses and organizations solve daily problems with technology. Utilizing AI and/or ML are excellent ways to accomplish that task. Do you have a problem that you need help solving? If so, let us know! We’d love to chat.

Read more about Computer Vision & Machine Vision here.

During some recent discussions with clients, I noticed we tend to throw around the SDK acronym quite a bit. Today we’re going to simplify what an SDK is, share examples of SDKs and talk through how you might think about an SDK as a potential software product or product extension in the future.

What is an SDK exactly?

SDK stands for software development kit. An SDK is typically a 3rd party chunk of pre-written code. For example, in the majority of mobile apps, a user will need to login and most apps use social logins like Facebook, Twitter and Google. All three companies provide an SDK which a developer “drops” into the mobile application they’re building. That SDK allows the developer to quickly, easily make the right calls (via code) to Facebook for instance to authenticate the user (make sure the user is who they say they are).

Examples of SDKs you might hear used in mobile or even web applications:

Analytics and crash reporting

User Login/Authentication

Notifications, Engagement and Messaging

Advertising

Payments

There are also SDKs available for news feeds, weather data, restaurant reservations, and more.

Potential Downside of SDK usage in mobile apps

SDKs are pretty powerful in terms of speeding up app development. They allow a development team to quickly put a new feature in place without building it from scratch. As always, with great power comes great responsibility. Occasionally, and it’s probably not happening to your mobile app, developers (or product owners) start to integrate multiple ad networks, authentication methods and analytics services. All of these integration points can slow the performance of the app down and also introduce complexity in the troubleshooting process. The SDK will need to be updated when a new version is released by the provider to continue to receive support from the provider. With any new release or change, that update can either introduce or fix bugs. SDKs also introduce a layer into your application that can make debugging (or bug fixing) more complicated. Often times the bug will be in the SDK but the app developers hands are tied waiting for the SDK owner to release an update. Ask yourself these questions before integrating a third party SDK:

  1. Does it provide value to the user of the mobile or software application?
  2. What if the owner of the SDK goes out of business or is acquired (ahem…anyone remember Parse?)
  3. Does it impact the performance and user experience of the app?
  4. Is there clear documentation and support around the SDK?
  5. What security risks will the SDK introduce?
  6. Is the SDK a critical component? If so, are you OK depending on a third party for bug fixes and support?

Building your own SDK

It might make sense for your business to build an SDK depending on your product and market. For example, one of our clients came to us with a connected device for motorcycles (think IoT – Internet of Things). We’ve built an SDK that handles the communication between another mobile application, an IoT platform and the hardware device itself. The SDK is a part of the product and necessary for device operations.

In the case of Facebook or Twitter, the SDK is a free extension of their product that allows the social network to grow and also acquire data on the users. Whenever a Facebook or Twitter SDK is integrated into an app, it potentially allows the app developer to access data about the user and also share that data back to the social network. Yes, if you have an app on your mobile phone, you are likely being tracked for advertising purposes.

Here are a few more examples of potential market opportunities for an SDK:

  1. Connected devices (IoT) where you might want other developers to also integrate your product. Something generic like bluetooth beacons are a great example.
  2. Products that provide a general utility. Analytics services, data services, or “platform” specific products that house data from your application. For example, you might build a platform product that handles user reviews for consumer products. You could provide an SDK that allows a developer to easily pass user reviews from the application to your review platform that centrally stores the user reviews. The platform could then provide analytics on the review data. In that scenario, you might need to gain as many reviews as possible for data analysis and would consider giving the SDKs to developers for free and then sell the data to product companies.
  3. Unique app features that would take a developer extensive time and resources to build on their own, for example unique maps or even making an app screenshot-proof!

SDKs present opportunities and challenges for mobile and software applications. A discerning developer will help you choose wisely and also help you understand if there are potential market opportunities to expand your product. Along with APIs, they can be a pretty powerful tool in the software developers arsenal. If you’d like to chat more about SDKs or any software development project, drop us a note!

health app and website development

Today we’re sharing an overview of the Xively platform. Xively is an IoT platform that utilizes the MQTT protocol (Message Queuing Telemetry Transport) to allow devices to communicate in a lightweight and efficient manner. For instance, one might use Xively to connect a network of temperature sensors in a factory. There are a plethora of tutorials and documentation on the Xively site, but today we’ll focus on an overview of the core concepts.

As mentioned, Xively utilizes the MQTT protocol, which uses the publish-subscribe pattern to allow devices to communicate with each other. Devices are represented in the Xively platform as “reflections,” which consist of fields that store device state. Devices in Xively have the default properties listed here, four default custom fields (deviceVersion, location, name, and purchaseDate) and additional custom fields that you define. You can create device templates, devices, users and groups using the Xively web app or using the Xively HTTP API.

The Xively MQTT broker handles communications, allowing devices to publish updates to device state and subscribe to be notified of changes in device state. Devices connect to this broker with device credentials to publish and subscribe. The four default topics for each device in Xively are _set/fields, _updates/fields, _rejected, and _log. The full topic names are set up using the following template:

xi/blue/v1/<accountID>/d/<deviceID>/<topicName>

Publish to the _set/fields topic on a device to change the device reflection. Your message should be in JSON format, with a “state” field in an enclosing JSON object like so:

Subscribe to the _updates/fields topic on a device to receive changes in its reflection. Upon subscribing, you will receive all of the device state in the state JSON object in a message on _updates/fields. After that, changes in state will send only the changed fields in the state JSON object.

Subscribe to the _rejected topic to be notified when an attempted update to the device’s reflection fails.

To connect to the Xively broker, use the Xively device id you would like the connecting client to identify as (there needs to be an existing device in the Xively platform with that ID) as your username and your clientId and use the password for the device in the Xively platform (needs to be generated) as the password. The client will also need the Xively account id to construct topic names. The Xively HTTP API isn’t the focus of this article, but administrative tasks like creating new devices and generating device credentials (as you might do when registering a new device) can be done using that API, which is documented here.

We’re currently in the process of working on a client project that utilizes the Xively platform. We’d love to hear from you if you’ve worked with Xively before! What has your experience been? And if you’re a client looking for support with your IoT solution, be sure to contact us today!