Monday, December 19, 2016

Sex is easy. Love is hard.

My career is not going as I expected. It really isn't. When I graduated I thought "I would like to have my own company. But for now, I better have some real world experience. Plan: I'll work one year at a company, jump to another after another year and so on until I get tired. It's the best way to get experience and make more money". So, my first job was in a small software company. I was working 15 hours a day, doing project management, visiting clients and developing at the same time. VB6 and ASP.NET 1.1 with VisualBasic.NET. Argh... I survived for 1 year just because I was too proud to quit. But I couldn't keep on like that forever. It was easy to quit, no regrets. Like sex. So, sticking to the plan: next! Bad luck. I fell in love with that company. It was one of the best places to work ever. I thought of leaving several times, but I was just too in love with it. I stayed for as long as I could. 6 years! I had a really great time working there.

Well, it's the future that needs oxygen, so, lets move forward. Back to the plan. In business, "always leave your emotions at the door".

Sex is easy, Love is hard

So, I though: The next is it. I'll be there 2 years and done. "No love, just sex!" Guess what? I'm screwed! Two years have gone by and I'm starting to love this company. It's unique in so many ways, it's just from another world! So much for my plan...

But I'm fine with it. Sex is easy. Anyone can do it. Love is hard.
Love what you do. Love the company your work for.

Tuesday, November 22, 2016

Quick guide to generate your mobile app with OutSystems

OutSystems 10 brought low code development for mobile apps to a new level. You can now generate mobile applications in a matter of minutes. Literally.

OutSystems 10 Revolution

The final step to have your mobile application is, of course, generating the apk (application package) or ipa (iOS application archive) to install on your device. But what kind of package/archive should you generate? Lets demystify the several types of builds in a simple way. Developer to Developer. No more than 300 words. Ready?

Android World
Well, you only have two options to choose from: Debug or Release.

OutSystems 10 Revolution Android
(click to enlarge)

What do they mean?
Debug: Want to play around and install on your device? Troubleshoot some error? Just pick Debug, choose your app id (uniquely identifies your app) and you're ready to go. 2 minutes and you'll have your app. That simple.
Release: Second use case, share it with some friends or publish to Google Play? Pick Release. Fill the signing information (it's all free until this point) and that's it. More info about how to sign your app in "Signing Considerations".

Android - Done!


iOS World
Of course, it's more complicated. In the Build type dropdown, you're presented with four options. Lets go through them one by one.

OutSystems 10 Revolution iOS
(click to enlarge)

In-House: forget it. This type is used by enterprises that have an Apple Enterprise Account (which costs some money and has strict policy rules). As a personal developer, you won't be using it. If you do want to know more, check the link at the bottom.
Development: It's the only build type that will allow you to connect your iOS to a mac and troubleshoot issues. So, if in an initial development phase, it's a good pick.
Ad-Hoc: Allows you to install your app without going through the Apple store. However, different from the Android World, you can't just share the IPA. The devices of your friend or whatever must be pre-registered in Apple's Center.
App Store: Nothing to add. It's the only way you'll put your app into the Apple Store. You won't be able to install it in any other way, so, this will be the final step after you've developed and tested your app.


If you want to better understand both these worlds, OutSystems has a great article in the Engineering blog that will bring more light to this: Cruising through the Complexities of Signing Native Mobile Apps

Monday, November 14, 2016

Macs are like Sushi

I've always been a Windows user. The first version I had in my Desktop was 3.1 and, until Windows XP, I kept up to date. Windows 95, then 98, then XP. With Windows XP, I stopped the upgrade process. No Windows Vista or Windows Seven. Why? Well, I use a PC to perform some task. So, if Windows XP was providing me everything I needed to be productive, why go to Windows Vista or Seven? Just because "You should always upgrade"? I didn't. I kept using Windows XP until Windows 8.1 because I didn't feel the need to change. I was productive with Windows XP.

With Macs it's the same thing: every time I have a task to do and I try to use a Mac, my rhythm slows down and I get irritated pretty fast because I'm taking so much time to perform simple things. But it should be fine because I'm not an experienced Mac user and I don't know the shortcuts nor the intrinsics of the Apple world. And quickly the Windows Vista and Seven Syndrome comes to my mind: Why? Why should I adapt? I'm productive using Windows, so why go through the learning curve to perform the same tasks? "Because the Macs are better", they say. Are they? I've been in these type of discussions a million times. Some will tell you that Volkswagen is the best car manufacturer in the world. Others will argue it's Honda. Some will say Nike produces the best shoes, others will say Adidas. Is it .NET better than Java? You get the point...

The best laptop to me is the one that allows me to be more effective and efficient. That's it.

Mac and Sushi

So, bottom line: Macs are like Sushi. Some people like it, love it. Others don't. The ones that do like Sushi will argue that you never tasted really good Sushi and they know "a place" that will make you like it. It never happens. I like other food. It's "Ok" to like sushi. It's "Ok" to like other food. It's pointless to discuss why you don't eat Sushi. It's pointless to discuss why you don't like Macs.

Notes: This post could be "Windows is like sushi." And I do like iPhones.

Tuesday, October 18, 2016

Submitting your app to the stores – Some tips

Recently, we had to publish an app to both the Apple Store and Google Play. At first sight, this seems an easy task right? Well, wrong. Assuring that your app will be available on date "x" on both stores is tricky. Here's some advice:

stores

Apple
  – Plan carefully: Apple's approval process is unpredictable. And when I say this I'm not saying that it's random, but it's not fully predictable. If you comply with all the guidelines you should be fine, but even in that case you cannot be sure how much time it will take them to approve the app. It might take 1 day or 6. Although recent reports claim that Apple were speeding up the approval process to one day only, it's still not predictable. We recently had one that took 3 days, other that took just one. So, plan carefully and leave a good amount of slack to account for this;
  – Expect the best, be prepared for the worse: again, if you comply with all the Apple guidelines, you can have considerable amount of confidence that the app will be approved. However, if it's not, then you have a "tennis game" of messages to play with Apple, fixing issues and resubmitting. It might take time. Again, plan and leave a buffer.
  – Small mistakes, big impact: A simple thing like "not stating the countries where your app sells" will automatically remove it from the store. No problem. The problem is that the e-mail you receive says no information at all (it's generic stating your app has been removed) and it's hard to troubleshoot what's wrong. So, be very focused when going through this process;
  – No updates before it's live: This was a big WTF. Submit your app for the first time. It's approved. You find a bug. No, you cannot release an update. You have to cancel and resubmit the app or make it live and then submit an update.

Google
  – Protect your keystore: Apple's Certificates and Provisioning profiles can be easily retrieved from the developer's site. And you can even create new ones for the same app. With Google, you cannot download your keystore. You can't even submit an app to Google Play with the same id but different keystore. So, if you have an app in the store and you lose the keystore, that's it: no more updates. It will be a new app for your users. (Quick Reference: Secure your private key).
  – Be careful with the devices you say you support: there's probably 2153543534534 possible screen resolutions on the Android world. So, stating that you support Android 4.4+ is a bold claim. Be prepared for the "rooted Xiaomi" and "super-crazy car-device".
  – "Weird test flight": Apple's test flight works fairly good. Google's Beta is a bit weird. If it's an update, you must have the original app installed and then you go to Google Play and hit update and... It's not a seamless process.

Having said all this, I'm not saying the Apple process is better or worse. It's just different and more bureaucratic. If the advantages of all the bureaucracy compensate the risk or not that's a matter of opinion. I do like the way Apple is trying to improve (Example: 6 months ago they required screenshots for all flavors! Nowadays, just give screenshots for iOS 6 and a big iPad and that's it!)

Just a final note, I also like Microsoft's "open speech": What is the certification process.
Just be clear.
Happy submissions!


Sunday, October 9, 2016

Low-code mobile app development

I admit. I was skeptical when I first saw OutSystems. I was a recent graduate and I was a code freak. Looking at that "low code", drag-a-ball kind of doing things was weird for me. So, I ran away from it in those days. I wanted to code and code and code. I'm now the complete opposite. As you get more and more real world experience, there's one sentence that gets really tattooed all over your brain:

"Technology is just a means to an end."

It truly is. It's fun to code, I love it. But, nowadays, I just want to give life to my ideas. I'm not interested in how the CLR manages memory and uses the heap or stack depending on the underlying type of...! I want my idea to become real. I want people to use my apps! And this is the part where I became an OutSystems fan. I just love it. It is the ultimate best low-code platform ever if your focus is results! With OutSystems, your ideas don't stay just on your dreams! And it's still fun to code.

outsystems

OutSystems 10 is out. And it brings Mobile apps to a new level. Check what's new and get some ideas here. Also, check the Awesome Demo of OutSystems 10 at the NextStep.

Friday, September 23, 2016

Building iOS apps without a Mac

Have you ever though "Now I'll need a Mac to build my new App and put it in the AppStore... damn!". Well, in a recent project we needed Macs to build our customer's applications without the need for everyone to have a mac. It's a kind of "build as a service". The customer provides all the info to build an iOS app and the result is an IPA file ready to publish to the Apple Store. How? Welcome to "Mac Clouds".

e-mail

"Mac Clouds" are, just it says, macs you can have in the Cloud. After a thorough analysis, we chose MacStadium. The name might sound "funny" the first time you hear it, but the work they do is great. They have lots of services, but we just use them as a "Mac Cloud Provider". It's really easy to setup and use. Does this post sound like I'm selling them? Well, I AM! The last year working with them has been a truly great experience. What they have to offer, the availability and, above all, the support is just everything you would expect from a really 5 star service.

Did you know that OutSystems uses MacStadium as a cloud provider? Check the full article here:

Thursday, August 11, 2016

The MVP curse

When I was working in the Services industry, the concept of Minimum Viable Product (MVP) was far away from my dictionary. I basically had projects with a (sometimes) well defined scope that normally had whatever was needed to answer a client's need. Although the triangle of project management has "scope" (also present in the project management star - PMBOK), this wasn't normally a point were we would change: normally, the client would pay for what he needs and didn't want to cut scope.

complicated

Now, when working in the Products Industry, it's a different story. The acronym MVP is everywhere. And is one of the most important things to have written in the back of your head all the time. Particularly, if the product you're developing is complex and has lots of impact, the issue is even more relevant. All the time you get pinged with quotes like "it should have this", "it's missing this part" or "users will want this". More relevant, Alpha, Beta, whatever testers will start to throw feedback at you saying "this feature is mandatory, we need it". Even when there's a workaround, they'll say it's fundamental. And that's when you have to stop and rationalize: Yes, I understand that the feature is really important. BUT, should it be part of the MVP? What will we have to leave behind to implement this (because we want to stick to our release date)? This is crucial. If you don't do this exercise whenever some feedback comes in, it's complicated. Your backlog won't stop growing and growing and growing.

So, when you look at a product and think: "Why... why didn't these guys just implement this? It was so simple!". Just rationalize: "It probably wasn’t because they didn't think of it. They just had to balance between this feature or some other very important that you are using."

Why, Why?!


Friday, August 5, 2016

Why I read e-mails while on vacations

Everyone has that colleague that can just "switch off" from work as soon as he leaves the office. It's like when they leave the office, they don't have any memory of where they work. I totally respect them. And not only because it's the right thing to do but because it's healthier. I feel the same way: for me, "I work for living and not live for work". I LOVE what I do, but if I had 10 million in a banking account, there's 34234 things I would like to do in my life other than work. Even in IT, I can think of 340 technical books I would like to read, 700 technologies I would like to learn just for fun and 890 systems I would have the time of my life implementing. Just simple things like an automation system for my home or smart traffic lights that know when an ambulance is nearby and switches the lights to give it priority. It would be fun! Nevertheless, I LOVE my work!

So, I can totally relate to my beloved coworkers that have the "switch". I don't have. I'm that guy that goes home thinking "why was that algorithm not working", "what can I do to improve the team's spirit" or "why didn't we do it the other way". Is it better or worse than the switch? It's just a different way of connecting to your work.

e-mail

Vacation time is just a little different. I think about work anyway, but in a more scattered way. I do read e-mails every day. Crazy? Well, no. I know that my team can live without me with no problem. I know they won't bother me unless it's critical. But I read e-mails. I read e-mails because I have a team. Because even though I'm not physically near them, it's still my team. Their success is my success. Their happiness will make my life better. If there's an e-mail that they can answer, I'm not answering. But if there's an e-mail that I know if I answer I'll help them be more efficient (because I know something more about the topic or whatever), then I'm stepping in and dropping my "2 cents" to help them. And by team, it's not just the ones closer to me. It's the whole company.

So, is it better than the switch? Again, it's just another way to look at work. I would like to have the switch, but unfortunately I don't have. I do have a huge respect for the ones that have it.


Stress is not the problem: it's how you deal with it that makes the difference.

Saturday, July 30, 2016

THE Mobile Team

Here goes another personal post:


We're growing. A lot! Join the Mobile Team: Careers @ OutSystems

Monday, July 25, 2016

Devices... Devices everywhere!

One of the biggest challenges when developing mobile applications is to ensure that your creation will run on a wide variety of devices (ideally, all devices out there). While Apple produces fewer models than you have fingers on one hand, the Android ecosystem is a different world. If you look at a fragmentation report from OpenSignal (2015), you can see that it's really scattered:


Okay, we just state that "We support Android 4.4+ because what we're interested is the underlying Operating System". True. In some way. But Android "x" can behave differently when running on a Samsung versus a Xiaomi. So, although you state that you "support Android 4.4+", you'll want to:

   Test your app in a number of devices that provide a good sample of your target audience (not just one device with Android 4.4, another with Android 5.0 and so on);
   Assure that if a client calls and says that the app doesn't work on a Xiaomi "some crazy model" with Android "whatever version", you can troubleshoot the issue;

Back to where we started, does this mean you must have all the possible combinations of devices and operating systems? Surely not. Welcome to Amazon Device Farm! Amazon Device Farm allows you to "Test your app in parallel against a large collection of physical devices." It will also provide you "remote access to a real device in real time". It's basically a hardware abstraction layer but now for Mobile phones. It's great because this will keep you away from all the constant hardware changes and having to manage hundreds of devices.

How does it work?
To test your application, you must first program the tests you want using one of the supported frameworks. Then just upload the tests and the application you want to test and you'll have everything tested in real devices in minutes. And if you're thinking about "automation", they do have an API for it. Just check the documentation because it is really good! There's also a blog where they have step by step instructions.

(click to enlarge)


Now, for remote access, it's even simpler: just choose the device you want with the capabilities you'll need and you're ready to go!

(click to enlarge)


Is it all perfect? Well, no. First, it's a paid service, of course. But this is not the issue. The real issue is that it seems expensive compared to other services offered by Amazon. The second downside of it is that although there's a fairly amount of supported testing frameworks, it's still limiting. And the final downside is that if your application uses IoT (e.g.: beacons) it won't be a solution for you. Maybe in the future when we have tele transport or something like that and you could send your beacons to them.

Bottom line: even considering these small issues, it's AMAZING! I love it!
If you're in a Mobile Development Business, give it a try. It's worth it!


Take a look at the list of available devices here. Devices... Devices everywhere!

Tuesday, June 21, 2016

Let’s make it legendary... Are you in?

This blog has 8 years (!) and I have never written a post that mentioned where I work. So, this is the first personalized professional post ever! And I do it because I've gotten to a point in my life where I believe it's really worth it. Really. Why? Simple. I'm from the Mobile Team and we are hiring. It's that simple. It is! I'm looking for people that WANT to do something from another world!

"Big deal. Everyone says the same. There are 3724 recruiters that sent me a message on LinkedIn saying they have exciting projects."

True. But I'm no recruiter. I'm just part of the best team ever! It's not the perfect team, but we are the best! I'm here, publicly stating that I love what I do at OutSystems. I'm screaming out loud that what we do is monumental, sensational, absolutely mind blowing! Sounds crazy? It's not!

So, challenge accepted? Let's make it legendary... Just drop a message to me on LinkedIn.
Tech to Tech! Come work with me!

OutSystems iOS app

Have you seen the NextStep Demo?
Want to know more about working @ OutSystems?

Disclaimer: No, I don't have stocks from OutSystems. But I do get to do magic that most people in the world cannot do...


Thursday, May 12, 2016

There's an app for that!

Nowadays, it seems like there's an app for everything. Anything you can think of, it has already been done. But is this really true? Instead of discussing the topic, let me guide you to one of the most amazing and relaxed technical presentations ever. It's the living proof that IT can be all about fun! It happened at OutSystems NextStep 2016 Conference (Lisbon). It will be worth it, grab a beer and click the image below.



So, the question is really "what will YOU create next?" No idea? Again, let me guide you to another presentation where you will witness how cool it is when technology it at our service. A peek into the future will inspire you to build the next amazing digital experience. Grab another beer...



So, "now it's not about technology, it's about your imagination"!
Curious about the OutSystems Platform 10? Take a look at the demo in the mainstage. It was legendary, it will certainly get you excited about the product. Did you know you can build a native app in minutes? Third beer, but it's worth every second:



You can see all the sessions here (filter by year).

Monday, April 11, 2016

Amazing facts

Did you know that the Rubik's Cube has 43.252.003.274.489.856.000 possible combinations?


Monday, April 4, 2016

The myths about submitting feedback

Most "mature software" nowadays allows you to submit feedback, either when everything is running smoothly or something goes wrong. However, most "humans" don't submit feedback. It's really strange. Why not say to the people that are making your life harder that something is wrong? There are many reasons why this happens, most of them are myths. I'll try to kill those myths and, hopefully, you get a different idea about feedback.

Feedback Myths

Myth: "Nobody will look at this."
This is the most common. And I feel really bad about this one because it's only around due to communication failures. Real companies do have support, maintenance and development teams looking at issues that are submitted. If there's a "crash in an app and that bug is submitted", it will end up in some team's backlog. Most of the time, that bug you reported gets fixed, you just don't get notified of it. And that's the missing piece: contacting the person who submitted the error and letting that person know that it was worth it. So, myth busted: Somebody does look that what you report, you just don't get notified of the result.

Myth: "They should have found this bug before releasing."
Well no, they shouldn't have. A relative complex program is composed by thousands of lines of code and resources. Companies have unit tests, regression tests, end-to-end tests, real tight quality assurance processes in place. Even manual QA. They spend a considerable amount of money to ensure software quality. However, it is impossible to test every single scenario with the close to infinite combinations a user might have. It might be that virus you have that's breaking everything, maybe it's that Xiaoming with a rooted version of Android that's killing other apps. It might be that free Antivirus that blocks a network connection. It might be one of the 336533 mobile devices that we cannot test. It's almost impossible to test every combination millions of users can have. So no, they shouldn't have found every simple possible bug that could happen on all the different combinations a user can have.

Myth: "Somebody must already have reported this."
Why? How do you know this? Assumptions are dangerous so as "following the group". This actually fits in the Asch conformity experiments or the Asch Paradigm. In the 1950s, Solomon Asch studied "if and how individuals yielded to or defied a majority group and the effect of such influences on beliefs and opinions". Basically, how humans "go with the flow". Like, if there's a fire and there are 20 people looking at it, is it safe to assume that someone already called the fire department? It is not. What if all the other 20 people thought the same? You can see the Asch conformity experiments here (phenomenal, a must watch). Bellow is a funny example. So, no, somebody might not have submitted the issue. Do submit.



Myth: "It just happened one time."
For now. Software is, in essence, a series of instructions that directs a computer to perform specific tasks or operations. Normally, these instructions don't change that dynamically. So, if you do the same actions, the computer will to the same… expect the same output. There's a sentence attributed to Albert Einstein about the definition of insanity: "Doing the same thing over and over again and expecting different results." So, although it's not accurate that the problem will happen again, it's there and the probability it gets "automagically" fixed is low.

Myth: "It only happened on my machine."
How can you be certain of this? Just because you're not witnessing a problem it doesn't mean it doesn't exist. Do submit feedback even if it appears to only be happening on your machine.

Myth: "It will probably be fixed in the next version."
If you don't submit, you can't have this expectation.

So, bottom line, always submit feedback. Even if your issue is not fixed in the next version, even if nobody replies thanking you for the feedback, please, submit. It is invaluable information for the people developing the software. Raise the flag. Help others help you.

Friday, April 1, 2016

Installing a valid certificate on a dev environment

HTTPS is everywhere. We don't even notice it anymore. But, having a valid certificate in a development environment isn't always that easy because the Certificate Authorities normally charge to issue a valid certificate and you must comply with a few requirements. That doesn't necessarily mean you can't have a valid certificate for your Dev environment really quick and for free.

Here's how: Installing a Valid Certificate on a Dev Server (OutSystems Engineering)

The Talkdesk example

Talkdesk is a Portuguese startup that, in essence, provides a cloud-based call center software. One of the co-founders, Cristina Fonseca, did a quick interview to TechCrunch. If you look at that interview carefully, you'll notice she gives lots of hints on what's it like to be an entrepreneur:

"Build a prototype in 10 days" (MVP concept)
"We received good feedback"
"Here's an opportunity we never thought of"
"We were naive enough to take the challenge"
"Disruptive companies"
"We would pick up the phone at any time"
"Not because we assumed it, but because we had to"
"You do what you have to do at the beginning"
"We did a lot of mistakes"

You can see the complete interview below. It’s worth it:



Just because you fit in

It's one of the simplest and coolest images I've seen lately

Fit

Never settle for something just because you're comfortable.

Tuesday, March 1, 2016

Go hybrid or Go home?

Not rarely I see people complaining that hybrid applications are bad. That having something hybrid is just "outdated". I do think it's the other way around. Hybrid applications follow the very simple principle:

"Technology is just a means to an end".

In our current world, transforming at an outstanding high rate, we want things fast. We want technology to solve problems. We want to have that super hyper cool app for that event coming in 2 weeks ready to go. We want that app to support our yet to be release product really quick or we'll miss that business opportunity (and the cost of opportunity is huge). We want to answer business needs, real world use cases. We don't want to be concerned that Apple enforces 3746 provisioning profiles to have an app distributed and Google has "xpto" signing key. We don't want to know what an "ipa" or an "apk" is. We don't want to know that you have to write Objective-C to access an iPhone camera and Java to an Android phone. Oh, wait, missing Windows Phone. That's not why we should have technology. We want an app that can reach the wider audience possible to transmit a message, to give power to clients. We should take advantage of technology and not be servants of technology.

Is hybrid bad? It depends! It depends on all the requirements you have to comply with. Maybe hybrid is the right path for your needs.

Android

Thursday, February 18, 2016

iOS 9 blocks while loading resources

Update: Only happens using WiFi.
Update: Might not happen with 9.3 Beta (to be confirmed).

In devices running iOS 9+ (until iOS 9.2.1 - latest at the time of this writing), Apple changed the way web applications load resources (JavaScript, images, CSS, fonts). While retrieving all page resources, the browser "stalls" for around 10-30 seconds. This affects both Safari and applications using Web Views (webkit). This is non-deterministic and there are several ways to reproduce the problem (refer to some more examples at the end of the post), but here goes a simple and curious one:

Create an HTML page with the following content (you can open the HTML here or try it live here):

Index.html
(click to enlarge)

Name it index.html. Place 6 images in the same folder as index.html. The images can be 1x1 pixel (same image, just different filenames). Create an empty file and name it EmptyJavaScript.js (if you want, put an alert or some JS code in it, but empty file will reproduce the problem). Place it in the same folder. Now host the page on any webserver you like (I tried IIS, WebLogic, JBoss and Apache). Open the URL in Safari and "flop":

iPhone Stalled
Image using an iPhone running iOS 9.2.1


Same problem happens with an iPad:

iPad Stalled
Image using an iPad running iOS 9.2.0


"Stalled". Exactly 30 seconds (it's local). If we inspect the network timeline, it's pretty obvious:

iPad Stalled
Already going for a hang here


iPad Stalled
30 seconds to load 6 resources


After the "block" it loads all resources and we have our page displayed:

iPhone Stalled

You might be thinking: "but... all those sites out there with dozens of resources don't stall". Well, yes. As I said, this is non-deterministic and I was unable to find the pattern, but some suffer from this issue, others don't. Some apps with webviews will suffer, others won't. My goal was to reduce the issue to the simplest example I could find. I can't figure out the rationale behind this behavior. I imagine it was either a security issue (some edge case they tried to solve) or just a poor performance design. As people update their iPhones, iPads and so on, this will become more obvious. I've reported the issue to Apple but no response or fix yet (nor have they given any prevision date).

Don't believe me? Try it here!
Do you have any information? Share it with me!


Some more info:
    – I was able to reproduce the problem using an iPhone, iPad and iPad mini;
    – It doesn't have anything to do with the server hosting the page; I've tried more than one server and I've confirmed with Wireshark that the request doesn't go out, the delay is not server-side;
    – The issue happens using both HTTP and HTTPS (with valid certificate);
    – If we add "n" more resources, the problem remains;
    – Adding extra HTML in the middle "might" solve the problem;
    – The issue might not happen all the time in this example due to cache hits. Just refresh a couple of times or clear the cache and you'll hit the issue.
    – Using RequireJS or JavaScript to inject script tags might reduce the probability of the issue happening;
    – Some more use cases: 6 empty Javascripts inside the head tag with one CSS using a @font-face or @import; Using one CSS with several fonts that need to be dowloaded and one JavaScript file; Anything that implies different resources and one JavaScript;
    – Only happens using WiFi. If you use your 3G or 4G connection, it won't happen.


Is the issue affecting you? Report to Apple


Thursday, January 28, 2016

We could be moving so much faster

A few years ago in a public presentation on the Arduino Day I asked the audience a simple question:

"What is the best Database Management System (DBMS)?"

"Is it Oracle? SyBase? MySQL?". Can YOU answer this?
Some yielded Oracle, others MySQL and so on. However, the really good answer, like almost anything in the software industry, is "it depends". Just like that. Take a look at the list of currently available Relational DBMS. And this is ignoring other Database Types like NoSQL. So, based only on the question I asked it would be hard to say which one is the best. If I added that "cost is a priority factor" or "it must guarantee ACID properties" or "must be relational", than you could narrow down the answer.

Nevertheless, keep your focus on that list I linked about Relational DBMS. Can you identify the main problem with that list?

Well yes: It's HUGE!

It's basically a lot of software that, in essence, solves the same problem. And here goes the "speed block". So many engineers developing "the same idea" just in different flavours. We live in a competitive world instead of being in a cooperative world. And this is scattered everywhere: Android, iOS, Windows Phone... You name it! On top of this, so many engineers having to know lots of different ways of working with the same basic concepts. Sometimes it's just syntax. All this reminds me of the cables every single phone manufacturer had years ago. If you had a Nokia, the connector of the charger was one. If you had a Sony, another.
"Hey, there's micro USB!"

Technology is just a means to an end.
Humankind could be moving so much faster.

Cooperative VS Competitive

Wednesday, January 20, 2016

The one essential task in my calendar

I recently changed functions inside the company. That's good news for me, new challenge! Excited to embrace a new challenge, I want to outperform myself. I want to make the people that gave me the opportunity proud of their decision. I want them to look back and feel good, thinking "great decision, that was THE man for the job". However, there's a problem: the project is rolling and on an important phase, so, what that means is I have to catch a train that already left the station.

How to manage the gigantic amount of new information coming in every second and still be productive? In these first weeks it's not easy. So, nowadays, the most important meeting in my calendar was created by me and I'm the only participant in the room:

Google Calendar Refocus

Daily refocus. After just two days, I realized that in this initial phase on a rolling project I would have to "refocus" on a daily basis. With so much information scattered around, not stopping for a moment would imply something would get lost. No can do! Every day from 19h to 20h it's my time. I revisit the day, reorganize notes, review documents, review my personal notes and reorganize thoughts. Some of the information is not that important. Some is crucial. Never loose focus on what you really need.


(Ignore the brand - the message is just brilliant)