Google Sheets is a well-known service and online spreadsheet. Google Sheets can be more than just a spreadsheet, it can be used as a back-end or a database for applications. For example, Glide uses Google Sheets as a database for its mobile applications. Glide allows to build a mobile application without any code connected to Google Sheets. It’s incredible how fast you can build a real app, .
I was building an app in Glide that displays the latest news using News API. I connected the app to a Google Sheets spreadsheet where I entered a number of news stories manually. The app looks like this:
Glide app
This is how the Google Sheets spreadsheets looks:
Data for Glide app in Google Sheets
If I need to update any news I can manually edit the Google Sheets spreadsheets and the Glide app will be updated.
In the context of Developer Relations, a Lunch & Learn event is a lunchtime developer education event. It’s very similar to an evening meetup but hosted during the lunch hour. While a meetup can have different formats (hands-on, lecture, panel, etc), this particular event has a lecture-style format. Developers come to the event, get to eat a delicious lunch, learn something new, ask questions and network.
So now the question is – why run an event during the lunch hour. I’m going to share why a Lunch & Learn can add value to your developer relations program. I want to mention this is not to run instead of evening events but in addition to evening events.
Many developers don’t live in San Francisco. They come to San Francisco for work but don’t want to stay in San Francisco after work to attend a developer event. Many want to get home to their families, significant others, friends or just to relax. So we thought why not host an event when developers are here during the day. People have to eat lunch anyways – right? So why not combine developer education and delicious food. And that’s how we started hosing Lunch & Learn events.
Four weeks ago (this week) I attended the Serverlessconf in San Francisco. The following are my notes, observations, opinions and pictures from the conference (in no particular order).
Serverless Awesome 😎
Serverless is awesome because:
Build apps faster
Development focused
Serverless architecture offers the most productivity and agility
Never think about servers
Never think about cost (🤔)
Never think about performance
A common message that I have been hearing (and reading) is that serverless allows to concentrate on app business/logic. And that’s true. You write the code and the cloud platform simply runs your function, it ensures virtually unlimited scalability and you only pay when you function is running. No need to worry about servers, maintenance, deployment, etc.
As a side note, I find “allows to concentrate on app business/ logic” message interesting because every new technology/software/framework in the past had the same message.
AWS Lambda is the Leader
AWS Lambda is no doubt the leader in the serverless space right now. Probably because they were the first to introduce serverless on their cloud. I think most non-Amazon speakers mentioned or used AWS Lambda. They are closely followed by Microsoft with Azure Functions, then Google Cloud Functions and then IBM Cloud Functions.
Contaners vs. Functions
A number of talks mentioned containers vs functions. It’s not really one vs. the other. Functions are easier and give you higher abstraction. Containers give you more control and flexibility. It depends on the context and the problem you are trying to solve. In general this is how it looks:
March 26-27 I attended a Developer Relations conference hosted by Evans Data in Palo Alto, CA. I was a good conference, with great content and speakers. The conference probably had about 100-150 people which I really liked.
These are my notes from sessions and keynotes I attended. Again, these are my notes and what I was able to write down and not necessary what the presenter said/showed.
Anatomy of an Amazon Alexa Evangelist Paul Cutsinger, Amazon – Head of Alexa Voice Design Education
You have to love to teach
You have to love to travel
Workshops == training
Send internal newsletter to show what you have been doing
User feedback loop
Important to be in meeting with product and tell them what works and what doesn’t work
Virtual Event ROI: Experiments and Learnings Cliff Simpkins, Microsoft – Director, Azure Developer Marketing
Developer events
What has worked well
Focus more on in-person value, less on deep content
Do lecture for an hour
Do 15 minutes lab
Setup your labs so that developers get the “ah-ha” moment
Community events
Bringing engineers/experts to places that don’t usually see them
Anti-hackathon
Tell about the hack upfront and help with the last “mile” of the project
Learn how to build your first IoT application using Node-RED and IBM Watson Services. This workshop will begin with an introduction to Node-RED, a browser-based graphical flow editor of drag-n-drop blocks (called a node) of functionality. Node-RED (nodered.org) is an open-source community project built on top of the Node.js runtime. The workshop will dive into the Watson IoT dashboard to visualize data and Node-RED dashboard to build a UI interface.
AGENDA
12:00 – 12:50pm: Registration and Lunch 12:50 – 1:00: Intro/welcome from Max Katz, IBM Program Director, Developer Advocacy (@maxkatz) 1:00 – 1:30: Let’s Learn about Node-RED, JeanCarl Bisson, IBM Developer Advocate – Bluemix/Watson Developer Ecosystem (@dothewww) 1:30 – 2:30: IoT Starter Lab 2:30 – 3:00: Break 3:00 – 4:00: Watson IoT Dashboard 4:00 – 5:00: Node-RED Dashboard and Advanced Topics
Many organizations that are building mobile apps need to connect and reuse existing (internal) systems. One of the most common system is a relational (SQL) database. The question is — how to a relational database from a mobile app.
I have prepared two short videos that will show you how to do that using Appery.io API Express.
API Express connects to a relational database and exposes the database tables via REST APIs. Once the APIs are created, the mobile app can easily consume the APIs.
The first approach automatically generates CRUD-like APIs to work with a database table. In many apps, this is close to 80% of what an app might need. This automatic approach also comes with very sophisticated offline support. In other words, you app can work offline and sync data with a remote database when a connection is reestablished.
With the second approach, you get full control as you write the actual SQL query (or Stored Procedure) that will be executed. With this approach, you can use a visual service editor to orchestrate the REST API. In addition to the SQL component (connector), you can use connectors such as Web Service (WSDL), REST and others.
An Appery.io developer posted a question on the Appery.io Facebook page on how to write a Server Code script to query two different collections in the database. This post will show you how to do that.
In general, querying two database collections is better to do on the server-side than from the client. Doing it on the server is a lot faster and provides you with the option to update the search without impacting the client. Plus, you can add any logic when needed. Doing it from the client would require two REST API calls to the database.
Let’s jump into the example.
First, there are two collections in the Appery.io Database. They look like this:
ProductName collection:
ProductName collection.
This collection is simple. It has a name and a code.
This is the ProductData collection:
ProductData collection.
The code in this collection links the product name to the actual product (Android or iOS device).
The input to the script is the product type: Android or iOS. Based on the input, you lookup the code for the product (a or i) and then run a second query to find all iOS or Android phones in the ProductData collection. Here is the script.
var product = request.get("type");
var dbId = "367e9e77......";
var params = {};
var result = [];
// Search for object with the provided 'type' (iOS or Android)
params.criteria = {
"name": {
"$eq": product
}
};
result = Collection.query(dbId, "ProductName", params);
// Find all objects with code 'i' or 'a'
params.criteria = {
"code": {
"$eq": result[0].code // Either 'i' or 'a'
}
};
// Run the query
result = Collection.query(dbId, "ProductData", params);
// Script response (API response)
Apperyio.response.success(result, "application/json");
This script first searches the ProductName collection to find the id for iOS or Android devices. Then it searches the ProductData collection to find the actual devices.
Moving this logic to the server is a good idea as you query two collections (or even more) with a single request from the client.
The Appery.io Tester app is a core component in the Appery.io platform and makes it simple and fast to test your hybrid app without installing it on the device.
When you are creating a hybrid mobile app you need to test the app on the actual device. Using simulators is usually slow. Installing the app directly on the device each time you make a small change is also very time consuming. To solve this problem, Appery.io provides a special Tester app. When you sign into the app, you will see all the apps that you have created in Appery.io. You tap any app and launch it directly on the device. For example, if your app uses a native device API such as the camera, then you can easily test the app and the native API.
Make any change to your app, simply tap the app again in the Tester and the updated app will be downloaded and launched.
One way to sign into the Tester app where you see all the apps you have created. Another option to share the app with anyone, even if they don’t have an Appery.io account is to create a special share code.
As a developer, you can create a special share code, send it to your customer and they will be able to run and test the app by just entering the code. They don’t need to have an Appery.io account, they only need to download the free Tester app for iOS or Android.
You can create any number of share codes and also set expiration date for the code. For example, you can create one code for your external testers and another code for your internal test team, with different expiration dates.
This video shows who to test the app using the Tester app.
Appery.io API Express make it fast and simple to connect to an enterprise data source and expose it via a REST API. With API Express you can quickly create an API for:
Relational database.
WSDL service (SOAP).
REST API. Connecting to an existing REST API allows you to apply logic to the response. For example, you can filter the result and only return the data needed to the client.
In this tutorial I’m going to show how to expose an existing WSDL service as a REST API and then build a mobile using the API.
