Leadership Team Building

A team is only as good as the individuals composing it...

Lately, we have been facing tough circumstances that shaken and tested our values, as a team. While it's normal to be in an argument, disagreement and debate -- if it becomes too often, it will burn everyone out without anyone noticing it. If not taken care of "properly", the misunderstanding would eventually split people apart and the ideology of "working collaboratively" would no longer be observed and embraced in the work environment.

We have been into that hole.. and it wasn't good.. neither did it do good to anyone..


Fixing ourselves by knowing others more
As leaders, we act accordingly at the same time act freely and be ourselves. We've identified that most of our misunderstanding and disagreements came from the fact that each one of us have different perspective on things that matters most to us -- and since we all came from different angles, it's hard(er) for us to settle down to ones idea.

During our team building activities, we've made sure that we, as a whole, gets more and in-depth insights as to how each one of us differs from one another. As for myself, here are my take-away.

• People are not evil - When people speak their perspective about things, it's actually true and right from their standpoint. One could argue about it, go along with it or even challenge the idea. If one is questioned as to "why", he/she should respond as to why and why not. A well crafted answer will surely lead to great exchange of conversations and ultimately get people into an agreement. Communication is the key.
• You cannot change people - When you present them your perspective, most react according to their beliefs and what they think of it. You cannot change how they react and respond to the thought but you can change how they understand "the thing" you're trying to picture out. It's your responsibility to make people see the outlook you're eyeing, so they could lock down their buy-ins. It's merely impossible for you to change someone, yet, it's possible for you to influence someone and let them be the one to change themselves. There's nothing either good or bad but thinking makes it so. - Shakespeare, Hamlet
• One's act is only a reflection of who molded them - When people do such thing (anything), it's sometimes not them acting the deed. Most of the time, they become the vessel of the actions of the person who molded them. This is why, it's important that one needs to know ones up-bringing. Consider this factor and you shall see the gem in people's actions rather than the lapses they're about to make. You'll have better understanding of their reasoning and the motivations behind every actions -- you'll empathize more, you'll be more kind.
• Some principles are shared - People takes different stand on all matters, as they have considered different principles in making such decision. Respect is when you know how to value their stand (regardless if you think it's right or wrong).
• We all have something to say about someone - Good or bad, we all have something to say about someone. You'll know if what one is saying is true, by their sincerity. You know they care, if you feel like being intimately told.

Hardships pushes the team to work, sparks teamwork

Usually, hard moments break the weak and bring strong people together. Most team building happens in the beach or some places where people could relax and take a break -- we had ours at the peak of Mt. Puting Bato, Samal Island. Going up is one hell of a kind experience, especially if you're carrying good amounts of load (physically and emotionally). Keeping up the pacing to catch-up with everyone at the same time, waiting patiently if one needs to rest -- is what we've observed on the climb. At least, even without talking, we've shared and felt the team spirit.

Mt. Puting Bato, Peak (facing Davao, Mt. Apo)

Mt. Puting Bato, Peak (facing Cannibad, Samal Island)

Retrospect to improve

We just can't be more thankful that we've been disconnected from work for two days and a night. This gives us focus on the things we're all up to and make sure we attain the objective of the team building session. As far as I can see, feel and tell -- we're much better now, we're a bit stronger, we're even bolder. Knowing ones self is very rewarding! Thanks to these wonderful and awesome folks, I call family.

Try it with your team sometimes.. actually.. do it more often.

Onerent Engineering & Growth Leaders

Understanding Beyond Libraries [Matrix Multiplying]

As engineers, we always go for something easy -- something reusable -- and this is the reason why libraries exist and play a great role in programming and software development in general.

To most, understanding the underlying formula for every calculation executed by the code is not that "important" and some doesn't even care at all -- as long as they see something is shown as output. This is why I wanted to take time to at least try my best to explain, why one needs to be curious enough to validate what a program does and tell.

This sample lines of code uses the python library numpy to calculate the output of c = a * b

The output of that equation is:

Now, while that answer is true and correct -- one might wonder, why? Well, I'm glad you asked.
Let's dissect the equation and see how numpy performs the calculation.


NOTE:

• In multiplying matrices, make sure that the number of columns is equal to the number of rows. Ref: https://en.wikipedia.org/wiki/Matrix_(mathematics)
• In multiplying matrices, order matters. (ie. Where c = a * b will not show the same result as c = b * a).

EXPLANATION:

• (i) Take the first column set of a and multiply it with the first row set of b. (ii) Then take the first column set of a and multiply it with the second row set of b. The output should look like 
• [[-1(-1), 0(-1), 4(2)], [ -1(1), 0(3), 4(4)]]
• Where [-1(-1), 0(-1), 4(2)] is the output for i and [ -1(1), 0(3), 4(4)] is the output of ii
• When we calculate this, i will result to 1, 0, 8 = 9 and ii will result to -1, 0, 16 = 15
• Thus, making the answer [9, 15]
• (iii) The the second column set of a and multiply it with the first row set of b. (iv) Then take the second column set of a and multiply it with the second row set of b. The output should look like
• [[2(-1), 0(-1), 0(2)], [2(1), 0(3), 0(4)]]
• Where [2(-1), 0(-1), 0(2)] is the output for iii and [2(1), 0(3), 0(4)] is the output of iv
• When we calculate this, iii will result to -2, 0 , 0 = -2 and iv will result to 2, 0, 0 = 2
• Thus, making our answer [-2, 2]
• This is how numpy achieves the correct answer [[9, 15],[-2, 2]] -- in a much faster and accurate way.

Some references in dealing with numbers:

• https://en.wikipedia.org/wiki/Negative_number
• https://en.wikipedia.org/wiki/Scalar_(mathematics)
• https://en.wikipedia.org/wiki/Algebra
• https://en.wikipedia.org/wiki/Linear_algebra

Personality Check

What makes an organization great is the "culture" that everyone embraced and I cannot give more emphasis to it -- as to what I've written on my earlier post.

The hardest part of working is not about the technicalities, nor about the management, nor about the daily routine but about dealing with people. People with different backgrounds, different outlook, different perspective, and vision. For a company that value people's inputs and thoughts, it's hard to get to a point where you want everyone to be empowered and have the courage to say what they have in mind and at the same time, be reprimanded when they offend someone regarding what they were saying.

The idea of transparency and openness is not new especially to organizations founded in the modern web days. While it's hard to keep an environment where everyone can openly discuss and challenge one's idea -- I still believe that it is somewhat necessary for an organization to have some sort of maturity; where people can take on a higher level of communication; where "respect" is the common denominator to everyone who'll be a part of the conversation. Respect in the sense of:

• Do not play as the victim, we all have a unique DNA which defines us of who we are.
• Do not act as if your being attacked, we all have the rights to say what we need to say and we all have the rights to respond if ever we need to.
• Do not incorporate emotion, delivery is important and sometimes, people mistakenly take that negative emotion alongside with what they are doing. If you're reading something and emotion takes over your composure -- it will sound like as if the person who wrote those lines have a special message to point out. But in reality, it was plainly said. Assumptions, especially wrong ones give a bitter meaning of words in a sentence, thus, making other people's thoughts wrong from your standpoint.

When do you compromise and when do you take no for bullshits?
Respect is easier said than done. When one comes to you and tell you about your ways of doing things is wrong -- I believe, it's your right to ask them back if it was really your doing that's wrong or how they see it that makes it wrong. Often, perspective plays a great role when interpreting an idea or thought and most of the time, people don't see things the way you see it and live with the same mindset as you, in which you and your actions get misunderstood.

Realization takes time, especially the one we call "self-realization". When that particular happening occurs, you'll be in limbo and either (1) you live by other people's words and adjust your ways of living and become the "not-so" you -- and live with guilt day by day or (2) you continue acting being you and let people see that they're the one who misunderstands you and your intentions. While the choice is too narrow as you only have to choose between two options, your selection time will really be tough. If you ever bump into situations like this, always go for the second option.

When Elon Musk was misunderstood by Mark Zukerberg, arguments took place and things now falls on how you explain your side of the story. This is what we call a healthy discussion.

Lesson: you should be prepared to be misunderstood and be prepared to explain what people needs to know.

I bump into this diagram as I search for wisdom. I hope you find it useful and meaningful as I do.

Don't be afraid to speak up, just speak up

Einstein said, "Don't be a man of success, be a man of value". This line is really powerful for me and it has served as a guiding star as I go along in life. As for a man who haven't had a formal education, settling down with the little knowledge is a dangerous move... thus, learning has been a key aspect for me to pursue what I want to achieve and do. While you move up and try to excel from the rest, it's important to be guided as to what limitations should you view as your pillars in order to balance between having your head up high and keeping your feet on the ground.

Personally, I like what the 7 deadly sins portray. If you study how it was collated and embraced, you'll see the evolution of the idea and how wise men helped shaping it. I love the narrative, from how the idea was introduced to how it was arranged to how it was accepted. Imagine if no one spoke about this idea -- the wisdom it gives won't exist and mankind will miss these valuable knowledge.


The more you know, the more you sympathize
It's hard to know more about yourself and others, this is the reason why most of individuals resort to neuroscience as that's the only way bias is eliminated. It's most of the time correct -- and from knowing it, you'll now have the idea of why people act, speak, think the way they do. A better understanding of how their mind is wired and how their thought process works.

I hope this test will help you as it did to me. It's called MBTI Test.

The Culture Of Fixing What Is Broken

Engineering, a realm of smart people working together, trying to prove something to themselves, to the company and to the society. Challenging what's merely possible, simplifying what's complex, enhancing what's good enough -- a true story, daily!

While it's nice to see everyone working in harmony, there will be a time where the processes, workflows, and practices no longer suffice what is needed to stay in the game. And this is where chaos starts to arise between teams and members. When your organization reaches that point in time, the only thing that can save you and everyone is "culture". So at the early stage of your company, always make sure you have a great culture in place that is being followed, respected and observed by everyone working inside the organization; while admired by those who are seeing the organization from the outside.



Before we dig deep into the broad representation of culture, let us first define what composes a culture.

People
People are the actors and authors of the cultural playbook. A company always starts with an empty sheet of rule-book and as the company grows, it's everyone who'll define what is supposed to be written into the sacred sheet. People are the ones who'll evaluate, deliberate and contest what will be proposed -- then judge what is rightful to the greater good.

Principle
While everyone is unique, principles could be common to a number of individuals. Depends on the background and preference -- these "principles" could vary within the organization. Principle will serve as a guiding star when making a decision and in crafting a proposed solution (to any given situation).

Practice
Another vector that is a variable and not unified across the organization. This might vary to the groups, department and individual working on their designated task and scope. It will be "practice" that will serve as the reasoning of every individuals in coming up with the decision and as to why the solution was crafted that way (to the given situation).

Pulse
Inside an organization, not everyone is privileged enough to have a voice and be considered in the decision-making process. However, it's still important that people raise concerns and be counted as a factor of consideration when making a decision and proposing a solution. While it's true that you can't make everyone happy, it's still everyone's obligation to treat anybody as human, hence, they should be heard.



Now that we know who plays what in building a culture, we can now start talking about some of the "cultural" problem every organization is dealing (both internally and externally). Note that we will not tackle any specific "problem" but instead generalize what is common. Here are some thoughts to take note when you are on a mission fixing a broken culture.


> You cannot fix a broken culture by replacing it. 


Today, we are in a time that when something is broken -- we immediately replace it with something new and better. While this approach is proven working (at some point), applying this to "culture" will just worsen the scenario. One should be smart enough to realize that a good culture is chosen collectively and agreed upon the majority. One cannot just simply walk into a group of people and mandate something to be changed.


> You don't go to the capitol to complain, everyone knows the problem. Propose a solution and wait for the people to decide.


People in general is not evil, they are just busy and it takes some realization to convince someone that something needs to be changed. If you're driving for a change, it's your obligation to constantly remind everyone about the severity of the issue and how much time are we looking before it fully impacts the entire organization. It takes time to drive a change, especially if it requires everyone's participation. It takes courage to initiate changes, it takes patience to wait and see the results. Changes within the cultural playbook doesn't happen overnight -- it's an incremental improvement.


> Numbers don't lie. Yet, not all that can be counted counts.


Never stand against the crowd without gathering any facts. Numbers represent a lot when discussing something that is "bad". Backing up your stories with data, avoids perceptional bias and helps people understand what you're up to and what is it in them if they buy-in to the idea/solution. Convincing people with numbers is easier than merely just words (people are now smarter these days and at some point, lies are easily spotted).


> Always challenge the system


The only way to improve is when people think outside the box and tries to break what is being implemented. There are good and bad in performing exploitation -- we just have to know the bad and eliminate it from the picture. When someone is telling you to stop challenging the system, ask them back "Have we come-up with a great culture in place?"


PS: Some people thinks they are above the cultural playbook, hence, they try to decide by themselves in-behalf of the group. When you meet people who are like this, tell them that "Whatever they change in the culture, they now owe an explanation to everyone and it's everyone's right to ask for one".

AWS Community Day 2018 (APAC) - The Vietnam Experience

It's another time of the year for AWS APAC Leaders to gather around and spend great times with one another, sharing knowledge and experience, keeping up with every user-groups vision and mission, celebrating success and archived milestones -- many more!

 For 2018's AWS Community Day, AWS User Group - Vietnam hosted the event.

We're privilege to have a great tour in Vietnam for a day. We went to great places, enjoyed good food and experience boat riding across the Vietnam river (plus dress-up like a Vietnamese Army).

AWS APAC Leaders taking a boat ride across Vietnam river

As for my personal milestone, my topic once again qualified to the track and I feel great being one of the guest speakers for the gathering. Everyone who took part of the AWS Community Day tracks have talk a lot of amazing things you can work-on within the AWS Cloud -- indeed, a great set of tracks prepared by all guest speakers.

Standing up in front of a crowd is not easy! I'm thankful that I've delivered the message to everyone -- loud and clear! Being able to coin a new term for BC/AD (which in the modern days "Before Cloud" and "AWS Deployments").

After a successful day, we gathered around and the night's food kept us all well while bonding. Too much goodness on every serving! Especially, dishes with seafoods.

Dinner at the long table

I hope to see everyone in the next AWS Community Day! 2019 is waiting..

Vietnam says, xin chào!

An Actual Team Building Event

Long planned, yet, it was only last week that we happened to have our team building.

The so called "competitive" pose

Just 4months ago, we managed to hit a milestone of being able to completely rebuild Onerent's platform within 6months time. Though it was a mission accomplished, we haven't had time to celebrate (big time about the achievement) as lately, everyone in engineering and growth team had been busting our ass off to address the key asks from our operations team and implement all the deliverables.


Our way of team building
Since this would be our first official team building, we don't want to waste the chance to make it a remarkable and memorable one -- especially that the venue is very conducive for almost every team building activity you can think of.

During the day, we stick to our program. More than just the regular team building games, we have very challenging activities in place -- which requires team effort to be completed.

During the night, we spare some time to gather around before heading to bed. More than just the beer times, we had the chance to know more about one another. Something personal, something valuable, something precious we will keep for a lifetime.


Getting a piece of everyone's life
If there was a thing I am proud most about our team building, it was be the fact that it brought us closer to each other. A better understanding of one another. A refreshed connection to the link that binds us together.

Our stories will always have a mark within one's self. Our shared experiences will always have a room in one's life. Our common values will always keep us genuine to our relationship.


Having the privilege
As it was all a success, being the one to facilitate the activities and program -- I couldn't be more thankful. Being able to deliver what needs to be done, bring joy to me (inside out). I thank the team for allowing me to impart something that I once experienced. I thank the team for believing in me and what I could come-up. I thank Onerent for investing in their people.


Here's a summary of our 3 days 2 night stay at Hof Gorie, Samal Island.

Questions That Makes Sense

Have you been in a situation where you had a one-on-one conversation with someone who's in a higher rank than you? Might it be the company CEO, CTO, COO, CMO, CFO etc. or one with a VP, Director, Senior title? How was the experience talking to them?

More than just "how are you?", "how have you been?", "what's new?" is the intention to connect and speak with intimacy. This type of conversation is rare and expensive, especially if you're someone who's in the bottom of the food chain. Some might have to wait for a long time before getting a chance.. Some might just gets denied upon making such request.. Some might only end up with nothing as they lack the courage to formally ask.

If ever you'll get this opportunity, make it worth..

I am not an expert in communication, however, I was privilege enough to have many of these circumstances throughout my career. My purpose for sharing this insights is not for you to feel prepared on every conversation but rather for you to be mindful of your thoughts, your words and obviously your phrases.


Time is limited, get to the point
Don't waste someone's time by talking about senseless things. By the time both of you sat down, either party can start talking. One of the mistakes I've made before is trying to control the conversation and shifting it to the wrong side, causing the discussion to be out-of-place and so, someone loss the interest of talking. Think of the things you most care about, it's somewhat a good way to think of a topic..

Provide a history, how you came up with the question
In case you have some questions in mind, always prepare your reasoning with you. This is the most important thing to backup what you're questioning and it will also help the person you're asking compose his answers. It's been my practice that when I ask, I then follow it up with "... the reason why I'm asking is". As for me, It gives more flavor to the question!

Ask something personal (ie. habits, thought process, guiding principles)
If you happen to look up to the person you're speaking with, this is a great chance for you to know more of him and his practices. I'm pretty sure that the person you're talking to won't have any reasons not to answer these questions, especially knowing that it's only you who's listening to what he's about to say.  
 
Share your outlook, plans and reflections
Not all the time, one-on-one's are purely work related talk. At some point, it's good when you share topics like planned vacations (talk about the place and occasion), how you view life and everything that is yet to come, personal take on certain topics, perhaps your preference..

Having this discussion on the table, you're basically giving the person more idea about you and your perspective.

Always ask them if they have other questions
You might not know it, but always give people the chance to think if they still have questions for you. Always ask them, prior to ending the conversation. This is also a great form of courtesy and for sure people will appreciate it.


Bonus: In asking question, the thing that makes it more enticing for someone to answer it is -- sincerity! If you're not sincere, people can tell. If you're not sincere, why ask?

I hope you will have that smile after every one-on-one... I always want the best for everyone!

What is Startup's Greatest Advantage?

If you haven't been a part of a startup company before, you might not believe what I am about to say. But before we jump-in the discussion, let me first give you a bit of background about my career journey.

• Worked on Dreamscape Network
• Worked on Prometsource
• Worked on Juwai

The time I joined Onerent Inc. is actually my first jump from a corporate setting (enterprise scale) to a startup environment. And just like any other newbie, I was fascinated how things are run "the startup way".


Execution is important, speed is everything...
So the whole idea of startup is moving workloads into sprints where we treat everything as moving parts -- it's all about how much time you'll be able to release something for your product or service.

While we push for speed, observing quality is something we didn't take for granted. Trust me, we move fast and take marginal step to avoid massive breakdowns.

How do we make sure we got everything covered from development, to deployment, to production releases, to regression?

As I mention before, we trust we hired the right people, thus, first-principle thinking is what we follow inside the engineering workforce. Now, making sure that the testing ground for everyone's code is in good state, embracing devops will be a key component in cultivating the engineering culture.

Devops, in a sense of:

• TDD is applied
• CI/CD is applied
• Boxing Environments is applied - Separating Staging, Beta and Production
• Staging - Code Testing for Developers (pre-deployment state) 
• Beta - All sorts of testing for QA Engineers (PR merged to master)
• Production - Code passed QA and now ready for the release
• NOTE: Theses environments have a production-like setup, this way, we know that if something doesn't work in staging -- it will not work on production. Same as if something works in production, there's no way it will not work on staging/beta. The only difference between these systems is the data it's reading and database it's connected.
• Centralized Access is applied
• Everyone is free to play on the Staging server (SSH access allowed with sudo permission). This is to avoid bottlenecks and overhead.
• Restricted Beta/Production environment. ACLs are configured.
• Automation is applied
• Heavily utilizing Ansible playbooks to everything in operations
• Post-mortem is applied
• We talk things out. We improve our process if we spot an area that needs more muscle or brain. We make sure we won't commit the same mistakes as we believe that -- once is enough.

While not everyone loves to write, it's important that as a Devops Engineer, you encourage people to document what they are doing. This is the only way for you to enjoy vacation without being called for an issue. Documentation saves life!

Speed is the priority.. next to security

When we apply speed in whatever we do, it's normal to say that not everyone will be able to manage the workload overnight, especially for those who are new to the startup mechanics.

People need to pick-up the slack and navigate through the shallow waters of opportunity. Everyone in the team needs to know that time is the greatest opponent in building the next big thing for your market. Reminding everyone, that there are other players trying to acquire more market share overtime is vital -- it's an advantage when everyone is in-sync and on-track.

How do we observe security within our work?

• Using of password manager within operations
• Each services, servers are running it's own AWS IAMs with specific ruling to a particular service
• We separate internet and intranet
• Internet is for public access
• Intranet is only accessible via Office Network or VPN
• This mostly applies to our development and beta environments, including internal tools
• We implement jumphost

While it's hard to influence everyone in the organization to adapt to best practices to better observe security, as a devops engineer, it's your duty to set the standards and never get tired of reminding them about it.

So startup's greatest advantage is always, speed!

Meeting An AWS Evangelist - Great Times and Topics with Donnie

It was a success! It's a privilege to be visited by Donnie and actually getting the experience of the learning Serverless straight from an expert.

I was lucky enough to be selected as the lead for AWS User-Group Davao and organize a meetup session that involves a talk from an AWS Evangelist.

If you happened to miss the event, don't worry..
Donnie spent some time to arrange and organize the slides in a way people can just go-over the contents and somehow grasp the knowledge about his topic. Also, I've made my slides public so everyone can see what we've been planning for the community as well as the people behind other AWS User-Group Chapters.



Aftermath:

After the session, Donnie and I had a chance to dine and talk. Topics of the discussion ranges from Devops, to Serverless, to AWS, to coffee and beer, to life in-general and other stuff about Philippines and the places he'd been.

Donnie's words of wisdom opened my eyes in a broader scope as for my career and personal-development. The things he shared to me are too valuable not to be kept.

It's great to know that the AWS Community for Asia Pacific has a great person, looking after it. Thank you for the time and learning Donnie.



Bonus:

We haven't anticipated the number of attendees, and for the record -- we have to transfer to a bigger room just to fit everyone for that night. Shout out to Globe Telecom for sponsoring the venue.

Keeping Commitments And Valued Service

It's been a month since we launched Onerent's new platform and I thought, this would be a great time to reflect and see what are the things that met our expectations and what are those of sub-standards. Prior to making the platform live, we had made it clear across every engineer that infrastructure is something we will be focusing on. This is to make sure that uptime is well observed, scalability is achievable and maintainability is easy.

Personally, I believe that "uptime is king....". By uptime, I mean, application and server (might it be the web or database server)

In storytelling, many prefer to talk about the things needed to be improved and in the latter part are the things that were excellent. I'll be taking this approach too.


So what are the things we identified that needed to be improve?

(1) Since the system is new, there were a lot of familiarity issues upon transitioning from Podio (legacy CRM) to Salesforce. Though training is conducted, I'll take an amount of time for people in our operations to fully embrace the "Salesforce" way. We are aware that time is one great factor we overlooked and has made poor estimates on the timeline. If only we've allocated more time in training, it'll be a bit smoother for people to jump into their daily routine by the time we live the new system.

(2) Knowing that we've built the new platform by gluing Salesforce and Mainstack via Heroku Connect, it was a pain-in-the-ass tracking the changes. Literally, there's just too many moving parts -- and if you're working in parallel with other engineers, you can't avoid the fact that your changes might break someone else's code (that was once working well).

(3) Accountability was somehow neglected. It was somehow neglected not because everyone is evil but for the reason of "everyone was just trying their best to work things out within the timeline". When issues are found, there was no acknowledgment as to how come it happened, rather, people just fix what are "known issues".

(4) Documentation is outdated. While we've got a lot of accomplishment on the programming side, the documentation section was not being updated along-side with the changes. And we all know that documentation from a backtracked information could potentially cause incomplete notes.


So what are the things we identified that are excellent?

There are tons of things we can be proud of, however, I would be more specific on the points I'll be sharing on this blog.

(1) One great outcome was when we plan to separate the node application worker process and taking the path of cronjob from host rather than the nodejs cron approach. This gives us more room to control the process resources, depending on the host resource.

Imagine if we didn't separate this processes and host it on the same server where the application is running. What would you think will happen? For sure, hammering of resources will take place as concurrency will become a factor in resource allocation. Worst, a process might die or become stale (zombie process) due to resource limitation -- which means, application errors and timeouts are expected from time to time.

(2) Our Backend APIs are designed in a modular way (if you want to know how we are architecting our platform, you can read more about it here). Which means that changes for certain functions won't be affecting other models, limiting issues in having additional feature requests.

(3) Fully utilizing the content-delivery-network offering of AWS (Cloudfront) and Cloudinary, our Frontend and Wordpress landing pages have extremely increased the loading and response time of our website assets. Known to affect SEO rankings and better user engagement -- we expect to have great conversion rate (which at the moment, proven "working" as per the numbers shown on Google Analytics).

(4) Moving away from Hubspot and custom website templates while embracing Wordpress is another thing we've feel accomplished about. The idea was first doubted as we all know that Wordpress is prone to vulnerabilities if not managed well. However, if the trade-off it offers is autonomy of our Growth Team to work on their stuff and avoiding overhead and bottlenecks from Engineering Team -- I believe it's a decision worth risking. Now, the obligation of securing it will be a shared responsibility amongst everyone in Engineering, DevOps and Growth.

(5) Incorporating tools like Rollbar and Jenkins has been a winning decision for us. This helps everyone isolate an issue and mitigate "unknown" errors. Along side with the TDD approach we've observe in crafting our backend/frontend applications. We've also created automation deployment scripts via Ansible (triggered via Slack command -- chatops), which made it handy for engineers to work on their code and test in different environments.


So what are the initiative we've implemented knowing the lapses?

3 weeks after the launch date, we've huddled for half a day to talk about everything about the past 6 months of working building the platform. This was a sort of a retrospective + postmortem session to everyone inside Engineering.

Here are some agreements we've come up:

• Giving everyone the freedom to experiment and innovate but at the same time, held them responsible for whatever the code will do (accountability matters more, now).
• Documentation will always be up-to-date. Classification of notes should also be considered. Like user-specific, developer-specific, code-specific and overview-of-everything (for our board of directors and stake holders).
• Rules and Guides should be in black-and-white. Rather than relying on someone's greater knowledge, we aim to avoid human biases and make sure what's agreed are written down and followed. Inside Onerent's Engineering Department, no one is above our engineering bible.

There are still a lot of things we're planning to add to shape our Engineering Culture.

I'll be a matter of time for us to nail down what is best for us, but at least -- there's an improvement from time to time.

At the end of the day, it's all about delivery. Keeping our promise to our customers, clients, investors and everyone working at Onerent is our fuel in building more advancements on the platform and it's always a work in progress.

The Story of Hardships and Triumphs - Breaking and Rebuilding Onerent's Platform

TL;DR

Summary: Onerent Engineering made it! We've crafted the new and enhanced platform that supports every customer, client and staff's need. Mission accomplished!

Have you tried building a platform from scratch that requires a heavy interaction with a CRM? How was the first release of the MVP?

In Onerent Inc., we've been busy crafting the new hybrid system, to have a revolutionized platform in order to enhance the user experience (both internal/external). As a startup company, innovation is what we always keep an eye on. While the objective is clear, trying to combine two different systems to glue an ultimate solution -- is not a straight and flat road. It wasn't easy but we managed to work-it-out and we know it's still a long way to go for bug fixing and feature request.

As we share our experience to the world, we hope that it gives everyone a better understanding about system architecture in general. We've spent so many hours of planning and weekend hackathons just to fail fast and apply what we've learn along the way. We specifically allocated time to test our hypothesis and ideas, thus, had caused us a long WIP (work in-progress) hours compared to what we normally consumed and accept in the engineering department. Discoveries and learning is so valuable that we never feel bad about the huge time investment in R&D (research and development).

Weekend Hackathon, a crucial planning session..

 

The mission impossible
Our main objective as we start our mission on rebuilding the Onerent Platform is to drive efficiency and apply innovation to all operational processes. The legacy system has served its purpose and this year, it's all about transformation.

What do we know about this mission?

• We will use Salesforces as our CRM
• We will use Nodejs, GraphQL, React/Redux, PostgreSQL and Heroku Connect to our mainstack
• We will use AWS for our infrastructure

What do we care about on this mission?

• Scalability
• Efficiency
• Usability
• Product-Centric
• User-Centric
• High-Availability
• Data-Driven

The warlords and champions
In a critical mission, you don't want people messing up the objective. Selecting the people to work on the project/component/tasks needs to be knoweldgeable about what he's doing or at least know how to ask if he's lost.

For our case, there were 5 major teams involved (1) Mainstack Engineering (2) Salesforce Engineering (3) DataOps  (4) Marketing (5) Business Operations. Each giving out there best, performing the work they will brag to the world.

How does these department play the role in the crafting process?

• Business Operations - Where used cases are opened and gathered.
• Marketing - Where UX/UI is studied and designed (includes context and optimization)
• DataOps - Where infrastructure are planned and estimated
• Salesforce Engineering - Where internal processes used cases are being translated to work pipelines
• Mainstack Engineering - Where external processes used cases are being translated to product feature/component

With the teams that we have, we're aware that we've pretty much covered everything. And ofcourse, our Business Executives and Advisors that gives us the "strategic plan" for execution.



The baseline (magic number)
With the objectives set and teams being rounded up, setting the baseline as to "when we can say that the mission was a success or a complete failure" is crucial. Most startup companies die for not doing good with time projection (..timing is important) and they've only realized it on the 11th hour which gives them no time to alter the course (too late reaction).

We don't want to commit the same mistakes as the others, so we keep things on a tight deadline but realistic. With the commitment of everyone who are involved in this mission, by a rough estimate -- we were given 6months to craft the improved platform. Shocking? While 6months is kinda challenging knowing the scope of the project, no one ever doubted what we could do (we are just very excited to see what we can offer to our customers/clients).

How was the 6months consumed (outside development)?

• Hiring more people for Salesforce Administration/Development
• Added 2 more heads to work on Mainstack
• On-boarding the 2nd hire for UX/UI (Marketing)
• On-boarding our QA Engineer
• Scouting for data-scientist

Within the time period, we are all aware that the holiday season was fast approaching and people are looking forward for the vacation. We don't have other chance if we won't make it to the 6months period, it was a "do or die" scenario we need to face.

The humps and bumps, things are now on fire
First weeks of development shows a great progress for everyone in different team. Things are rolled out smoothly, ideas being discussed, different solutions being evaluated, different technology being tested and meetings has been covering most of the things we needed.

Well, that was on the first few weeks...

Days past and slowly, the momentum has been shifted. Neither of us realize if we got everything covered and if we will be able to come-up with the "platform" everyone -- from our customers, clients and staff has been waiting for. Though, everyone is still aiming for the deliverables.

Some big blocks of learning we've faced, along the way:

• Challenges on Marketing
• Migration of Web Content (Improving Context as we migrate to the new platform)
• Retaining SEO standing on the new platform
• UX/UI Improvement (time-bound delivery)
• Branding and Style Guides
• Challenges on Mainstack Engineering
• Technical debt on Salesforce architecture and process workflows
• Technical debt on Heroku-Connect
• Technical debt on the Payment System (Workflow)
• Technical debt on the legacy system architecture
• Challenges on Salesforce Engineering
• Technical debt on the business model and process workflow
• Technical debt on best Salesforce practices and standard approach
• Insufficient workforce (lack of manpower)
• Challenges on DataOps
• Data Sanitation
• Data Engineering (source of truth)
• Data Migration (tooling)
• Salesforce (architecture) Triggers and Required Fields
• Heroku Connect (Usage and Best Practices)
• Challenges on QA
• Time-Bound Deadlines
• Technical Debt on System Architecture
• Tooling and Automation

For a team that's well oriented with the work that needs to be done, no blocker can ever hinders what needs to be delivered. Everyone who'd been part of this digital transformation has made a statement, "Challenge Accepted!" loud and clear.


Controlling the quality, delivering the fix
This is very common to every organization, though, no one ever had the chance to perfect it. Here in Onerent, we believe that there's no perfect system. As a system is only good as the business processes and models -- it keeps changing for it to be innovated and improved. Quality is king for us and we only care on the things that brings value stream to the table.

We have a list of what should not break and what people can play and hack around. We do not restrict everyone to break things to improve it, rather we tell everyone to "challenge" the system for it to be improved.

Things that should not break:

• Payment System and Database
• Mainstack System and Database
• Salesforce
• Heroku Connect (Production Env)
• DNS (FQDN)
• Mainstack Platform

Things people can play and hack around:

• Everything inside Staging Infrastructure (Application/Database)
• Microservices
• Data Analytics (Models and Toolsets)
• Wordpress Landing Pages
• Monitoring (SRE)

We are very proactive on Site/Service Reliability and Scalability. Thus, these make us set all this guiding rules in the operations.



Claiming the throne! Rewards and Shoutouts!
In reality, we didn't made it to the 6months period. However, we've managed to nail it down on the 8th month from the time the project started. On the additional two months, we've included the "Transfer of Knowledge" about Salesforce to our Operation's people as we don't want our frontliners to face issues navigating the new dashboard.


Architectural Beauty, Onerent's Stack
Here's how our stack looks like from the application layer. Grouped by component, the 1st on the diagram is the Frontend Stack, composed of Nodejs, React and Apollo. The 2nd one is the Backend Stack, composed of Nodejs, Redis and Graphql. The last on the diagram is the Data Stack, composed of Postgresql, Heroku Connect and Salesforce.

Overall Transformation, An Improved Onerent

The changes we've performed is not only limited to the Mainstack and Salesforce Dashboard, we've also included a total makeover of the Onerent website, from our Landing Pages to Blog Pages. Bringing more on-boarding and user interaction in the table.

In about 24hours from now (04-02-2018 7:16PM Asia/Manila), Onerent's makeover will be available to public.

Thanks to everyone's effort for making this project a success! Onerent is king!

My next blog will probably about how we celebrated this massive success! In Onerent, we work hard and party harder..

*****NOTE*****

We launched 2 days delayed to address some hiccups on our implementation. Today, it's live!

Data Migration 101 (An Introduction to Talend) - Survival Guide (Part 2.1)

Doing data migration is really risky and tideous, especially when you are not using a tool that helps you create a pipeline for the data migration process.

Data migration is all about tooling and pipelining. So if you're ask to do data migration, your first question will be -- "Which tool should I use that best fits my need?".


The ideal tool for doing data migration should support the following:

• Supporting multiple sources and type (sql, nosql, file, crm, api, 3rd party-services)
• Parsing Mechanism
• Market Standard (Healthy/Active Community)

After doing our homework and research, we have selected Talend to be our ETL tool for data migration.

For the times we've touchbase with the tool, we've managed to get things rolling and had perform the data migration successfully. Within those times as well, we've encountered trivial issues we thought might confused other users and so we've jot it down.

This will somehow give you an overview (starter-kit), on how things work "the talend way".


PRELUDE:

• I strongly advise for you to be on Windows or OSX, there are unexplainable errors on the linux compiled version of the tool. 
• Do not use a Windows Virtual Machine, file corruption and saved versioning is inconsistent for this kind of setup
• In OSX, there are problems regarding the "JDK" versions compatible with talend version.
• OSX High Seirra, should use JDK 1.8 151 release
• OSX High Seirra, if page hangs and stops on the license loading screen -- try launching the tool via the terminal

NOTE #1:
PostgresDB in Heroku have SSL enabled setting. Which Talend at the moment, doesn't support. To work around the issue, here's the additional line you'll be adding on your connection string. See screenshot for a detailed instruction.

?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory&tcpKeepAlive=true

NOTE #2:

By the time connection is established to the database and schema is retrieved, talend will be parsing the schema as:

SELECT "database_name?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory&tcpKeepAlive=true"."database_table"."database_column" FROM "database_name?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory&tcpKeepAlive=true"."database_table"

NOTE #3:
If you try using any "table" on a StandardJob  (ie. PostgreSQL (table) > Talend (tMap) > Target Host (table)) running it generates an error message of:

ERROR: cross-database references are not implemented

Googling, doesn't help much on this. Even with the right keyword. Most likely, you'll be seeing search results pertaining to the PostgreSQL limitation or talend "general knowledge" pages. The workaround is altering how the "Query" is automatically set by Talend upon it retrieves the PostgreSQL schema.

It's useful to have the "Query" on the base form:

SELECT * FROM database_table

NOTE#4:
In mapping database fields from source to target host, be aware of your fields specially when it contains "isDeleted" in the naming, you can just remove it on Talend "Job Design Board" so it won't be read as it will generate an error.

NOTE #5:
Sometimes, you'll also bump into errors even when your mapping is right. If you have 10 fields from source and 30 fields on the target host and you map the 10 fields to the target host, remove the 20 unused field on "tMap".


BONUS:
Doing data migration is very time consuming -- especially when you have a slow internet connection. It's best for you to run your ETL tool on AWS Workspace or something like Paperspace.

Hope you'll be able to perform the data migration task using this powerful tool!
And maybe we can share more technical in-depth details regarding the "data migration we've performed".

Happy administration!

Handling Data And What To Take Note - Survival Guide (Part 2)

Let me remind everyone that data engineering is not equal to data science but both are part of "Big Data". This article mainly focuses on data engineering and how to store data to be more useful for analysis.

The process of storing data into a single place is called warehousing and data warehousing is within the scope of data engineers. Preparing data so it gets served when it's needed is crucial for data-driven companies, thus, making sure nothing is missed and messed up is the top priority in performing data engineering.

The realm of databases:
Modern applications are relying heavily on databases to store information.

Before even starting to build your platform, it is necessary for developers to evaluate which database they should be using. As database plays an important role not only for data storage but also integration, missing the key element (which is optimization and scalability) on the implementation will bring a negative impact to the entire operation.

After the selection process, what you need to be aware of?

• Normalize Data - Not unless you have enough computing power, always normalize the data before you store it in the database. This is to make sure that records are "uniform" as it gets warehoused.
• Treat "numbers" correctly - When you store "numbers" in the database, make sure to classify the representation. Numbers can be in a form of money, coordinates, occurance and etc.. Set the data types accordingly.
• Single format for "dates" - There will be times that on a database, multiple tables handle "dates" and if those tables are not created at the same time, setting the "date" data type might be different (normally caused by negligence, lack of documentation or wrong documentation).
• Using TEXT over VARCHAR(xxx) - While there's nothing wrong with using VARCHAR, it's important that one should be aware of limitations and usage. Say you have a field named "notes" or "reminder" and you set it to VARCHAR(255). If a user is very explicit about his "writing" and jots all the details, since your field only accepts 255 characters -- who's to be blamed for the lost data? The user who's too keen on the details? The application that only receives 255 character? The developer who sets the limitation to the field?
• Be careful of using "id"- While "id" is human-readable, the time it gets stored in the database -- it then causes someone confusion. Be more specific when you store IDs (name it like internal_app_id or app_id and avoid the naming convention id1 or id_1).
• Follow the basics - Do not name any field with a "reserved keyword". Guidelines are set to be followed and not to be ignored. This is the best part in  learning your database of choice.
• Support JSON - modern databases including SQL supports JSON. This is powerful when used properly and accordingly. At the same time, if data is not well presented/structured, it'll make your record a whole lot of junk.

The realm of files/documents:
Support legacy systems too! Flexibility is the key to every modern application.

Storing data in a file/doc format is still rampant even in today's web era. Not because of lack of innovation but because of complexity and overheads. Every data is valuable and so every source (ie. CSV, EXEL, XML) should be supported.

If you plan to support these on your platform, what you need to be aware of?

• Increased limit - Most legacy systems keep everything in a single file. The file might be around >10G in size and your app might timeout while in the process of acquiring the data from the source "file/doc".
• Parsing Mechanism - It's vital to have a safe play when supporting files. Tell your application when to treat a "blank" as null and "blank" as "double quotes". Tell your application when to remove a space and when to leave it as is.

The realm of data analytics:
While databases are a great place to store data, it's not substantial to address massive query being batched by "analytics tools". Especially those that supports real-time data streaming.

Setting up a database engine to run data analytics tasks, has been made easier by cloud providers. Players like Google's Spanner, Amazon's Redshift, and Azure's Data Warehouse have been widely used by many and has been widely supported by most of the analytics tool providers.

In using a cloud solution, what you need to be aware of?

• Check for data integrity - Upon syncing the data from the database engine (ie. Postgres/MySQL) to these cloud services, it's important that data remains as it is -- in terms of structure, size, and format. Using native applications like what Amazon's Data Migration Service to migrate RDS data to Redshift is an advantage (rather doing it manually or via 3rd party tools).

I've seen many lapses as I perform data migration. I hope these pointers will matter to you, the next time you setup a data storage for your application.

It's All About Self Motivation

What can I become with what I have?

This is the question that keeps me rolling since the very moment my eyes opened to the world of -- hardships, struggle, short-comings, pain, rejections, disrespect and humilation.

Everyone has their story to tell, their story to sugar coat, their story to mask, their story to embrace. Every time I look back and see myself in the mirror, I can't hide the fact that I still feel the "impostor syndrome". Almost 9 years in the IT Industry; 2 years of call center experience, 4 years of system administration and 3 years of devops -- sums up my skill sets. While on the other hand, 25 years of hustling; 3 years of staying in an orphanage, 1 year of schooling (ended a dropout), 7+ years of learning the street language and 5 years of being a father -- sums up my attitude.

No matter how you look at life, I say the proper way of looking it will always be moving forward. Which tells everyone that life doesn't care of what you are today and who you were way back, because by tomorrow it'll all be part of the past. Life is all about what you want to become and how bad you want it.

People always appreciate you when they are (1) amazed, (2) thankful, (3) motivated, (4) inspired by your acts, your words or your ideas. I have no rights to tell you which is the path to greatness but I know how you could get started with your journey. I personally applied this myself, so if you see me as someone who is successful (which means it somehow works), then it should work for you too.

Again, life is all about what you want to become and how bad you want it. On top of this, you should be aware that there's no such thing as "something for nothing". So you should be willing to sacrifice whatever it takes to achieve what you've been wanting.



Don't give unacceptable reasons
Excuses is a big "no no" but most of us loves to reason-out.

Here's one scenario I hope will open your eyes to opportunities. The "→" represents me telling you what your option is.

I cannot learn programming because:

1. I have no internet connection on our place → Use office resources
2. I don't have a computer/laptop → Use your smart phone
3. I have no smart phone → Read books
4. I don't have a book / can't borrow → Print out e-books
5. I have no money for the print out → Go back to #1 (Use office resources)

NOTE: If you can't use the company resources, ask someone to do a printout for you. Out of your friends, I am sure there's someone who can pledge for that.

Resources for learning "programming" is already in the internet. Utmost of them are feel. It only requires you to invest one thing to learn programming and that's your "time".


Imagination is the key
Einstein said "Logic gets you from A to Z, imagination gets you everywhere".

As you start reading, there will be times that you see yourself lost rather than being enlighten. Well, that's normal! Because the things your reading is something you don't have any experience.

Prepare all your theory, gather as many as you can because in the "application" state, that's where you test which one is right and from those correct  theories which one is best. In the application state, that's where you ask people about your questions and doubts.


Simplify what you've learn
Einstein said "If you cannot simply explain it, you don't understand it well".

The test of knowledge will not be what you've read or what you've known. Acquiring the learning is just a half of knowledge, imparting it is the other. Well you might ask, why should I simplify what I know for others? It's for them to understand the "thing" the way you understand it. Verify your knowledge from those whom you teach.


Always give back
Einstein said "Don't be a man of success, be a man of value"

For what you've learn is yours, it's always good to empty your cup all the time. Give your learning to those who wanted it, invest in others so they will do the same. Learning is a continuous process and you'll never runout of topic in your lifetime. 


Don't be the guy who knows-it-all
When Einstein was asked "How does it feel to be the smartest person alive?". He replied "Ask Nicola Tesla".

Even the smartest will not claim that he is. Don't think your smart enough, don't think your good enough, don't think your tough enough. Life has so many aspect and there's always that "someone" who is better than you.



I hope this gives you the fuel you need to jumpstart your career growth, personal development and goal-centric life for 2018. Be better each day, not by comparing yourself to others but who you were yesterday.

Reminders And Updates - A UX/UI Note On Security

The predection for 2018 is all about security and the implementation of AI/ML/DL to enhance the counter measures for different exploits and threats.

While security is a broad topic and is been innovated throughout the entire web2.0 era. For this modern web days, it is vital that "users" takes part of the responsiblity of securing their information in the public domains (internet/web).

Providers should be aware of this...
Not only limited to acquiring the information from the users but also making sure that the data on the records are up-to-date.

What are some of the approach you can use?


Experiment #1:
Trying not to bug and annoy your users, it's important that you flag an alert or notification in an event basis. This way, you'll be able to send your users your personal note and envelop a probing question.

Credits to: https://dribbble.com/shots/1315388-Dashboard-Web-App-UI-Job-Summary

If you're somewhat minimalist, you can try adding a symbol that catches ones attention. Applying a "mouse hover" function that enables a bubble text to pop-up asking the same question.

Credits to: https://dribbble.com/shots/1315388-Dashboard-Web-App-UI-Job-Summary

Experiment #2:
Amazon is very good at this. If you've seen the AWS Dashboard (Console), under IAM Service, there's a section where they tell you how old is the credential(s) attached to a particular account -- giving users/admin the heads-up of what needs to be done.

Experiment #3:
Who says email is dead? For something this important, sending an email to users will be more appreciated than none. Just make sure you use proper wordings and explain briefly what the email is all about.

In the modern web, security is a shared responsibility. Providers should be the one initiating what needs to be done and making sure users will take part of it. There's no perfect system but there is a -- somehow perfect security protocol.

Remember the basics in security "A chain is only as strong as its weakest link."