The TQL IoT Course for Software Engineers

— by Jane Ren

If you are a software engineer interested in enterprise IoT, you should take Atomiton’s TQL IoT course (TQL101).

TQL is an IoT platform based on Thing Query Language, an IoT programming language. We run this popular training course in batches. Engineers from world's leading technology and industrial companies have taken it.

REGISTER HERE 

To answer your questions: 

Why are you teaching the TQL IoT Course?

People ask me, why are you spending time running classes, not running your company? The answer is very simple - we are merely walking our own talk.

Think Different

Last week we said in the blog IoT Needs a New Programming Language that IoT application is such a paradigm shift that 'learning to program IoT is learning to think in a different way – parallel, asynchronous and distributed.'

As you can guess, changing the habit of thinking for a profession (software engineers) who does thinking for a living everyday is not always a natural thing.

This “re-wiring” is learning; it is about putting down old assumptions; and it is an adventure as well. This video provides a glimpse of it.

Not Reinforcing the Same

If we had told you, learning IoT is as simple as knowing our platform “APIs”, or as easy as using our set of classes and services, we would have been re-enforcing the old paradigm of doing IoP (Internet of People) applications – sequential, synchronous, and centralized. You would have been writing your own Java programs, in the old way, albeit facilitated by some services and frameworks.

That is not why we teach TQL101. We teach to change how people think about IoT applications. 

Not Merely Scratching the Surface

If we had told you, learning IoT is as simple as drag-and-drop from a visual interfaces and entering some data, we would have been providing you an app, not a platform. You would be able to do a few fancy demo apps, but then that’s it.

That is not why we teach TQL101. We teach how to develop enterprise IoT applications.

What are you teaching?

TQL101 teaches three things about IoT: programming, design, and solutioning in TQL.

Programming – how to program asynchronous processes, create parallel executions, and write in distributed logic for IoT. 

Design – how to design so that your IoT applications are extensible, scalable (horizontally and vertically), and components reusable.

Soultioning – how to create dynamic and resilient IoT systems from bottom up, not fragile IoT systems from top down.

See the instructors. 

How do you teach?

Engineers will learn by doing, step-by-step, guided by the instructors.

The course runs through developing a smart greenhouse system, with 5 types of sensors, 4 types of actuators, used in a distributed application running across 30 micro-controllers, 5 gateways, and a cloud instance. Sensing, actuation, complex logic, simulation, and device management are all covered.

See the Greenhouse Tutorial.

Who should be taking the course?

• Software engineers comfortable with hands-on development
• Familiar with enterprise applications
• Motivated to acquire new core competencies in IoT development
• Interested in efficient programming

What are the most counter-intuitive things in learning TQL101 for IoT?

Thinking different means letting go of some old assumptions in order to see the new paradigm. As an IoT developer (not an IoP developer) you will find:

You are no longer a "grand designer".

Your program will no longer be sequential sets of logically dependent instructions that dictate how everything runs (like programming in Java). In IoT, it is simply impossible to dictate how systems of things will behave in runtime (you are not creating control systems).

If you are willing to find a better way, TQL will let you declare the ground behavior rules for each Thing, and then enjoy the power of controlling event flows at runtime to dynamically drive your system. 

You are no longer the "single source of truth". 

Your application data is no longer assumed to be the single source of truth. In IoT, one can very well decide to shut the valve via the application, and yet the real value remains open for some physical reasons.

If you are willing to accept this reality, TQL will allow you to take advantage of this state duality and manipulate things with greater failure resiliency.

You are no longer the bottleneck of interfaces.

IoT will be developed by cross-domain teams more than IoP applications ever did before. If between the Things, the backend, and the front-end teams, every interaction is driven by APIs, most IoT projects will become a monster.

If you are willing to challenge this limitation, TQL will free you from the need to ever provide an API. Your front-end team will be writing as many TQL queries as they want, on their own, which are interfaces to interact with both things and data.

If you are curious to find out more, send me a message on LinkedIn. You can register for the class here or recommend someone using this link. (Class 3 is now half filled).

Read the blog.

See TQL Introduction.