1. Captain Marvel saves Tony Stark — this was heavily alluded in the trailers so it wasn’t a big reveal. However, seeing Captain Marvel’s glow as Tony lies in helplessly in Benatar is still a relief.
  2. Captain Marvel destroys Sanctuary 2 — When Thanos tried to turn the tide against Avengers by “making it rain”, it was a brief scary moment. Then Captain Marvel swooped in and easily demolished the Sanctuary 2.
  3. Cap wields Mjolnir — this is arguably the best fan service moment in the movie. Thanos nearly killed Thor the same way Thor nearly killed him in Inifinity War. Out of nowhere, Mjolnir hits Thanos. Everyone is momentarily stumped; waiting for it to swing back. Then  Cap catches it.
  4. Iron Man stole the Infinity stones from Thanos — this was such a Starksian move. Of course he made Mark 85 able to wield the Infinity stones. Of course he reshaped his suit’s nanotech to yank the Infinity stones out of the second gauntlet. Of course he has a witty response to Thanos’ “I am inevitable.”
  5. “On your left” — Iron Man is down. Thor is down. Cap’s shield is broken and Thanos’ legion is moving in. It seemed like all hope is lost. Then Falcon’s voice crackled, “on your left”—a playful nod from Captain America: Winter Soldier—signalling that reinforcement is here. Then the orange portal appeared peripherally. Goosebump inducing. 

I’m a big believer of thin controllers. Here are some of the things you can do prevent your controller from bloating.

Move non-HTTP concerns somewhere else
This is sort of a given but it’s worth repeating over and over again. I view my controllers as an HTTP conduit. It ties my presentation to my business logic. For that, I am very particular what I put inside controller and in effect, handlers (methods). They usually fall into two main groups: request handling and session management. Everything else, I move them somewhere. Business logic usually morph into a service class while HTTP helpers turn into, well, helper classes. 

Use Partial Classes
About a year ago, we developed a habit to group controller’s handlers into partial classes. This creates clarity. For example, we group them by Views (ActionResult). So any method related to ‘/products/create’ like ‘/products/get-suppliers’ and ‘/products/get-categories’ will belong in one partial class. Altogether, ‘/products’ belong in one controller. You can create a “shared” partial class where common properties (or methods) are placed.

Model Binding is your best friend
I won’t go into model binding but simply put, you should be doing it. This forces you to move some validations to your presentation layer. Additionally, control the number of your handler’s parameters. My magic number is three, if it exceeds that, I wrap them to a class. 

Catch server-side validations
For server-side validations, I let controllers catch the errors instead of throwing them. For example, when saving a product, throw validation errors in your service class and have your handler catch it. 

One of our clients wants to integrate their e-commerce app to Lazada. Lazada has two ways to integrate to their API, you can download and use their offical SDK or make HTTP calls. I often stay away from built-in SDKs as they usually not worth the headache. It’s just an additional layer that you have to wrestle with.

Like most API calls, you need to sign and include your signature as part your request. Part of the signature are the path, request parameters, and the handshake credentials (application key, secret key, and authorisation code).

So, using .NET’s native HttpClient client, I set the base URI:

https://api.lazada.com.ph/rest/ 

and the path of the API:

/auth/token/create

Then I attached the parameters together with the signature and made the call. First, I got a 404 error. Upon inspecting, the whole URL request looked like this:

https://api.lazada.com.ph/auth/token/create 

`/rest` was omitted. I dug a little and found out this little nuance on how HttpClient BaseUri works. So I adjusted accordingly.

BaseUri: https://api.lazada.com.ph/rest/ (with trailing slash)
Path: auth/token/create (no leading slash)

And it was a success! I got 200 this time. However, another curious error popped: “The request signature does not conform to lazada (sic) standards.” This is weird because I was confident that my signature was correct; it was their code. I took it directly from their documentation.

Turns out that the trailing slash in the path is the culprit. The API expects you to sign the path with trailing slash in it.

The Verge

… what’s happening to trucking is the same thing the happen to Blockbuster, travel agents, grocery store cashiers, and dozens of other jobs. They are being replaced by a piece of software. Which means the first model is expensive but all the copies are basically free. In the business world, they call this the Zero Marginal Cost which means you can add more users and revenue without spending more money. 

As an ISV, we are at the forefront of software automation. We help our clients by implementing customized software solutions to reduce cost, increase efficiency and drive up scale. This is in no way eliminates or even reduces workforce. On the contrary, improvements in these areas typically mean more work. They open up areas for growth. Growth means more opportunities. More opportunities means more people.

If you’re an entrepreneur or a decision-maker in a company, software automation must be part of your DNA.

TechCrunch

Since 2016, Facebook has been paying users ages 13 to 35 up to $20 per month plus referral fees to sell their privacy by installing the iOS or Android “Facebook Research” app.

Horrible.

I’ve grown tired of Facebook. At this point, it is something I have to but dreading to use. I’ve been trying but I still can’t leave it behind. All of my friends and families are there and it’s their default way of communicating. Additionally, communities like my children’s school or my cycling group rely on Facebook heavily.

In the mean time, I am slowly edging it out of my life. Here’s how you can, too:

  • I stopped and removed Login via Facebookit from all sites I use
  • I removed all my personal details in the platform (city, work place, relationships, etc.). I even unlinked my phone number to the app
  • I am cautious in giving the Facebook app permission to access resources in my phone such as photos, camera, and microphone
  • I limit the information of every post I make: no location, less photos, etc
  • I blocked all in-app games and quizzes

 

 

One of our clients was spammed earlier this week. In just a few hours, the website racked up thousands of user registrations. The client-side validations and anti-spamming measures proved to be too basic. We watch the horror as the user count rose to a few thousands more. We were forced to recommend to put the site under maintenance while we look for a solution.

reCaptcha
It may sound simplistic but implementing a clean & effective spam prevention tool like reCaptcha can be daunting. The avalanche of libraries that “simplifies” the implementation is overwhelming. Additionally, libraries are typically superfluous. They add too much cruft that complicates the implementation. Instead, we decided to implement our own from ground up. We followed the guidelines and conventions set by Google. Used their APIs and viola! We had a working solution in under a day.

Coming up with a quick fix was nerve-wracking and probably the closest thing I’ve ever done to a Hollywood-esque computer hacker movie.

DFA:

“Because previous contractor got pissed when terminated it made off with data. We did nothing about it or couldn’t because we were in the wrong. It won’t happen again.”

Backed up data are like fat pants. You’re just glad you don’t have to use it.

On a serious note, it’s comically baffling that DFA runs into this problem. I just cannot fathom it. I’m gonna go out on a limb here that this is a symptom of an even bigger problem in terms of their internal processes.

2018 has been a tremendous year. Rather than focus on the things I am thankful for, here are the things that I learned this year.

I learned Swift
One of my goals in 2018 was to learn another language. I didn’t realised that it will be another programming language. However, I’m really glad I did as I’ve been itching to do mobile app development. Swift is a modern programming language that can be used to build mobile apps.  

I learned (some) Italian
With our Europe trip this year, I forced myself to learn a little Italian. Predictably, I did not become fluent with it. However, I learned enough for us to go around Italy and interact with the locals. I am planning to pick it up and learn more this year.

I learned that I have a great endurance
I accomplished one of the things I sought out to do in 2018 which is to become a Super Randonneur in long distance cycling. The event is hosted by Audax Philippines. Basically, it is a series of long-distance cycling events you have to complete. The whole series culminates to a final ride of 600-km long distance that must be completed within 40 hours. Proudly picked the 17th spot.

I learned that the best thing money can buy is time
This year, I got to spend more time with my family. I went on a vacation with friends. I also reconnected with some old acquaintances. Lastly, I afforded myself with things for my personal growth. The thing I am appreciative the most are not the material things or the experiences, it’s the time. I get to make meaningful time for my family, friends, and myself.

Quartz:

We keep thinking technology will naturally make things democratic. Maybe we’ve been thinking technology the wrong way. Just like in any superhero story, a new power can protect the little guy, but it might just end up making the big guys stronger.

Quartz discusses in the video how the democratisation of cryptocurrency empowers every one—including the government. You could easily juxtapose any technology in the video and could arrive the same conclusion.

One of my biggest pet peeves is seeing people fumble their way to their phone. So I want to share my method in arranging apps so it isn’t such a chore.

Arranging your apps might seem obsessive but it really pays off in the long run. It creates clarity and predictability. The main idea is to categorise your apps into three main groups: the often-access apps, the must-access apps, and everything else. I’m using an iPhone but this method should be easily applicable to any phone.

The Often-Access
These are apps you often use: messaging, browser, map, etc. You group them under one screen—the first screen—with no folder. This way they are readily accessible. I limit the number of apps to the number of apps the screen can contain: in iOS it’s usually around 20 or less. I position the apps according to how I often need them. The bottom-left corner will be the most used (this is Facebook for most people—no judging). The less I use the app, the higher they stay on the screen, since they will be out of reach for my thumb.

The Must-Access
These are apps that you must have access to but might not use often. For example, the camera app, a note-taking app, or a voice recorder. They reside on the dock since it is always present on any screen. This makes them very accessible specially in spur-of-the-moment situations like taking a picture, sending an important message, or even capturing the title of that fleeting song (Shazam!). In my case, I have 3 types of apps that must be available all the time: messaging, capturing, searching, and phone. 

"IMG_1894.jpeg

Everything Else
The rest of my apps are on a separate screen, grouped by classification. These are apps I barely used such as banking apps, utility apps, games, etc. I just find them using search—which in iOS is just swipe down from home screen.