Slow down to go fast.

Too long ago, I was starting a new sport - Dirt bike riding.

Intensive, extreme, physically punishing and amazingly rewarding sport, with lots of skills to learn.

During one of my first rides, in between trees, rocks and trails, one of the riders gave me a tip I do not practice often enough:

To go fast, you also need to learn how to ride really slow.

This actually makes perfect sense. You need to practice every nuance of your ride, do it right and repeat, until doing it fast becomes trivial.

However, if you want to improve, from time to time you need to slow down and review what you've been doing thoughtless - You might find out you're doing something wrong there.

Sometimes you need to go back to the things you do quickly on auto pilot and do them slow and methodic.
You might find out you can still improve.

Deus Ex Machina

AI.
Everybody's talking about AI.
The major issue I have as an engineer is the gap between AI as it is perceived and what it actually is right now.
Rather than being a new life form, with conciseness, AI is actually a specific skill we teach the machine to do for us. Be it drive a car from A to B, perform a specific medical diagnosis or get you an insurance policy, it's a collection of independent features, that even when aggregated, are still features.
The more interesting field, which actually might cause the rise of the real AI, is the regenerative networks. Basically, a regenerative network is one where you teach a computer a skill, and then ask it to perform this skill. Some chat bots are a good example. They learn how people communicate and can then imitate what they've learned.
Another great example, with unexpected results, is Google's deep dream, where the machine paints its associations from the image input.

That's where I see AI evolving into - Not just an imitation of human capability, but a whole new take on how reality is perceived.

(Image taken by me and processed with Google's deep dream engine)

Responsive?

One of the major premises of CSS3 back in the days was "Responsive design".
The ability to dynamically change display object's properties when changing screen size.

Then, with retina displays, came other problems. What is the "real" screen resolution? What should be asset size?

Everyone was at it. Devs were resizing their screens like nuts, measuring ems, rems or whatever. Playing with thresholds.

However, I have yet to see an 'app' website which is more than just a landing/ marketing page/ search result implement responsiveness with success. The good ones I've seen are actually an 'm' design - Which means that mobile users are redirected to a whole different site.

This brings us back to the basics of designing web/ apps. Mobile users have other needs and limitations. You can't just reorder and enlarge elements and expect your solution to work.

This rule counts especially if your desktop web uses a heavy, black magic "modern" web framework - Your mobile users would suffer. Mobile web clients should be as minimal and light as possible, otherwise battery life (Phone heating up) and sluggish response would result in bad conversion rates.

Remember when Steve Jobs threw away Adobe Flash from the first iPhone, thus condemning it to death? That was the exact reason.

Backoffice Matters.

Most b2c companies are busy on making their service great. Delightful, easy to use, cutting edge etc.

Thus, most of the efforts of a startup are concentrated in "the app".
However, as a company scales (Or plans to scale), the backoffice becomes more and more essential to the company's ability to face the growing stream of clients.
Most companies address those issues too late.

Remember to shift your focus at the right point, or else your team will be putting out fires and not scaling your company.

App = Sell, Backoffice = Scale.

The Age of Compute Services

In the past ten years we've seen the "Rise of the cloud".
Almost everyone moved their in house IT and infrastructure to Amazon/ Rackspace/ IBM/ Azure/ Google/ Whatever, got rid of their huge racks and pizzaboxes, and went on with their lives.
Enter the rise of Devops - A caste of people who control the know how of building, deploying and maintaining your servers. Mostly due to poor documentation of the host platform.
Then Docker came along - The ability to create containers for applications, which makes it even easier to run them - However, Docker comes with its own disadvantages (Irrelevant to this post.)

But recent years show a new trend - Where services like Amazon Lambda, Google Cloud Functions are actually code containers (Rather than full blown OSs).

This changes the paradigm even further - No OS needed. Just code, deploy and go. Connect it to a file system (Amazon EFS)/ storage/ database/ whatever as a service, and you've got yourself a full working server with no OS, no deployment, all managed, secured, scaled and charged on demand.

This changes the economy of cloud services, as you actually pay for what you consume, and not for what you MIGHT consume (Even if you scale down during downtimes, it's never immediate)

It also changes the paradigm of programming - No need for security concerns (All managed), just a collection of volatile services.

In this new paradigm, cloud cyber, virtualization and devops businesses should take notice. Soon, their business might be completely irrelevant.

Slides from the Aleph "Summer of bots" event

Though my bot didn't win the challenge, it was a great experience. 20 teams applied, and Ricky was a finalist.

Here are my slides from the final event.

Ricky

Think inside the box!

The cliches of creative thinking could sometimes be counter productive.

As you all probably know, "think outside the box" and "find a creative solution" are common phrases in problem solving. Letting yourself loose of current constraints (Of, sometimes, resources, technology and money), and trying to find a solution outside of your current method of operation.

In our world, this could lead to adventurous, cost and money taking processes. Rewriting something because it doesn't work. Using a new library which solves "everything". Changing and switching components. Redesigning your UX.

However sometimes, the solution is not far away from what you already have.

Take a small piece of paper and jot down all the resources you already have in hand which could be involved with this problem. Now start writing possible solutions USING THOSE RESOURCES AND ONLY THEM.

You might just find you already have a solution inside your box.