DEV Community: Israel Fermín M.

7 tips to be a more productive engineer

Israel Fermín M. — Wed, 06 Oct 2021 03:20:28 +0000

As Software Engineers, we are not measured by how much we know about computer science, data structures and algorithms, at least not after we pass the interview. At the job the story is completely different, we can be the best programmers in the company, we can know our way around the languages we work on and write code with the eyes closed but, none of that matters if we produce no value. Our value comes in many forms, code and working, scalable and robust software is one of those ways, but we can't forget we are part of an engineering team and also keep in mind that Software Engineering is more than writing code

Most of our value comes in the form of working software, performance and resources optimizations, architecture and software design RFCs and so on, these tasks require a high level of concentration which means our ability to produce high value work is constrained by the amount of continuous uninterrupted time we have. Along with that, we also produce value in meetings, by aligning priorities and work with other engineering teams and also within our team when we work with other engineers, by reviewing code and other forms of collaborative work.

Ideally, we need to maximize the amount of high impact work we do as engineers, this usually has to do with the tasks that require a higher level of focus, but we can't neglect the other kinds of work we need to do as well. To do this, we need to maximize the amount of uninterrupted time we have during our working hours.

Here are seven practices that have worked for me, hopefully they will work for you too. Let's get it on:

Have a daily prioritized list

This looks like a no-brainer, right? and yet, a lot of people seems to fail in using them. I love lists, I make lists for almost everything: my daily work, my personal projects, what I need when I go to the supermarket...

I keep a daily TODO list and I manage priorities with colors:

Red: for high impact or urgent work, things that need to be done ASAP or things that, when done, will have a high impact on the projects I'm maintaining
Yellow: for things that will have impact, but not as much and can wait a bit to get some attention, for example, looking into an error that pops out from time to time in the logs or reading about some technology I will need to use some time in the future. It's good to tackle them before they become red.
Blue: for things with low to no impact but would be fun or nice to do.

I usually mark in bold the ones that require deep focus to be done, these visual conventions help me navigate my list easier than P1, P0 and P2 or a numeric approach to set priorities.

I don't finish my TODO list every day, to be honest, there are always a lot of things to tackle and it's impossible to get everything done in one day, plus, every day something new comes up, someone has a new request, someone writes a new RFC I need to read and comment, so, I keep adding tasks to the list as they come up and prioritize them later unless they're explicitly urgent. Whatever I can't finish today gets spilled for tomorrow's list.

I also do my lists in advance, I prepare tomorrow's list today by end of day, that way I don't have to do it tomorrow and I can just review it, and get to it after I have my coffee in the morning.

Of course, you'll need to keep your lists somewhere, for this, really, whatever floats your boat, some people use Notion, some others prefer Evernote, Google Keep also seems to be a very popular option. At Careem
we use Confluence internally as a knowledge base solution for all things documentation, the thing I like about Confluence is that it gives every user a personal space, I keep my daily TODO in my personal space as private notes for myself, it's very convenient because I don't have to have yet another tool, it's work and it's protected by all the security measures
we have at Careem and I'm usually logged in.

This system helps me keep focused and by creating a new page every day, I can look back and keep track of everything I've worked on and when while also making sure I focus only on unfinished tasks and remove the noise of finished tasks from
my view.

Be intentional with your time

Have you ever wondered how it is possible to deliver so much stuff at school or uni and why we're not able to deliver as much at work?, the answer is, we had a routine, more or less. We knew every day we were going to have Calculus I from 10:00 to 12:30, then Algorithms II from 13:00 to 14:30, then 3 hours free, then back to classes from 18:00 to 19:45, it was predictable, we would use those 3 hours to study, work on a project, have lunch, socialize or a combination of those, every day was planned and we could schedule in advance what to do. At work it's a bit more difficult, we have 8 hours of semi-random activities. When I realized this, I thought it makes sense to give some order to that chaos and make a routine for myself so that I could use my time in a more predictable manner.

One book that changed the way I think and reason about time is [Master your time master your life (https://www.goodreads.com/book/show/31287110-master-your-time-master-your-life) by productivity coach Brian Tracy. In this book, Tracy mentions that there are multiple types of time in life and one needs to be able to identify what kind of time you have at the moment to know how you should use it as well as what kind of time a task requires in order to know when to do it.

At Careem we have what we call focus time, which are blocks where no group meetings are allowed, only pairing for problem-solving or making progress on a task, we also have a no-meetings day, so, I schedule all my high-focus work at those times. Before we had these policies, I used to schedule 2 hours every day where I didn't accept any meetings or interruptions, muted all notifications and just focused on that type of tasks, whether it was writing code, working on some architecture or designing a solution to implement it later, I just focused on that during the time I blocked for this high focus work.

Now, I do all my collaborative work on the rest of the time I have, we usually have some time in-between meetings so I use that to read RFCs, review code and sometimes socialize.

Be defensive with time

Do you often find yourself attending more meetings than you feel you should?, or stuck in a meeting having no idea why you're there?. Learning to say no is a skill you need to master, I had some hard time mastering this skill for many reasons, our inner nature is to help others, at least mine, I used to say no very rarely and as a result I was usually swamped with work, meetings and other commitments. Now, if I find a reason to say no, I say no. It's usually for a reason. I have a limited amount of time every day and I have to use it wisely.

For meetings, if I have a clashing event, I directly reject the invitation. All my current commitments take precedence with respect to new requests. If the meeting doesn't have a clear objective or agenda I ask for it to be added, if it's not added, and I have no way to know what's expected in the meeting, I let the organizer know I won't attend. If the meetings are spilling, I call that into attention and leave if I have other things to do. This might seem rude as attending meetings is part of the job but so it organizing and running them, if a meeting has no information about what to expect, it means someone is not doing their job organizing it. If the meeting is spilling, it means someone is not doing their job running it effectively.

Remember, as an IC (Individual Contributor) your time is your most valued resource, don't give it to everyone.

Learn your tools

This might seem an obvious one, but It's incredible the number of people I know who just know the basics of everything they use. I spend most of my time... well...
writing, so, my text editor is where I spend most of my productive time. It doesn't matter what editor you use, whether it's vim or Emacs, vs-code or an IDE, learn how to use the advanced features. I use vim for most of the things that has to do with text: coding, writing docs in markdown, notes, etc. I'm constantly improving my vim config so that I can write code faster and navigate projects more efficiently. For larger codebases I'm not very familiar with, I do use an IDE, we have an IntelliJ license through Careem, so, that's the IDE I use until I'm familiar with the project so that I can navigate my way through the code, it's convenient to learn the key shortcuts.

The other thing I spend most of my time now is the office chat, we use Slack, so, it's also worth learning how to use it properly, all the key shortcuts as well as learning to use the search, it's very powerful and you can find almost anything you can by using the search box instead of navigating through the chats.

By becoming a power user of all the things you use, you can then create systems to help you become more productive, for example, I often mark slack messages with reactions I can later search for, or set reminders on Slack about something
a colleague said so that I can take action about it. Investing some time in becoming a power user at work often pays off.

Take breaks

This might seem counterintuitive but taking breaks makes you more productive just because you give your brain some chance to breath, what does this mean?. Have you ever been working on a feature, debugging an issue and felt blocked? like, you don't know what to do, what else to try or that the next step should be?, this is usually because you're locked inside the problem you're trying to solve, think of it as a box, it's very difficult to find something when you're inside the box, it's better to take some distance and look at it from a different perspective that lets you see what you're searching for. It's very difficult to find a failure anywhere if you're looking at it too closely, you might be looking at the wrong place, taking some distance and looking at it from afar makes it easier to spot anomalies and then just zoom-in there again.

That's exactly what happens when you take a break, you take some distance from the problem, allowing your brain to look at it from afar, your unconscious mind will continue working on the problem while you drink a cup of coffee or read some other material or (if you work from home and have kids) go change some diapers. Once you come back to the thing you were working on, it will be more clear or, at least, you'll have some hints on where to go next.

As I mentioned on a previous post, I often use the pomodoro technique
on my day to day work, I set a timer and I commit to work on a task for, say, 30-40 minutes, I focus on the task at hand and only on that, when the time is finished, I take a 5min break and then come back to the task for another 30-40min block, this way I make taking breaks part of my work routine and avoid dawning myself in a problem.

This also applies to taking vacations, at Careem we have unlimited vacations policy, this is great because I can take 1 or 2 days off whenever I feel I'm burnt out and come back refreshed to work. When you're too tired or burnt out by work, your motivation decreases and your work doesn't come out as easy or with the same quality, this is also when you consider switching jobs. Taking a couple of days off to rest and disconnect from work when a weekend is not enough to recover is a wise time investment, for me, after one of those hard-deadline, time-sensitive, critical projects I try to take extend the weekend, at least 1 day, then I come back fresh and ready for another round. I'm not saying you should abuse these kind of policies, rather use them for your well-being and mental sanity, take a break when you feel you need it, your body and your employer will thank you for it.

Get the most out of meetings

This one might sound odd, if you want to be productive you should actually avoid meetings, right? as long as I'm sitting on a meeting I'm not doing my job, hence, I'm not producing value. We can agree on part of the statement for sure but it's not entirely true, meetings are an essential part of the job, we work with other fellow humans to tell machines what to do, so meeting with other people is essential to create alignment and decide on further steps, and make decisions about the underlying tech we are working on.

Meetings can't be avoided for sure, we can reduce them as much as we want/need but some kinds of meetings are just unavoidable and we need to learn to live with that. Not everything is lost, now that we accepted meetings are part of our life, we can choose to get the most out of them and make them efficient so that we don't have to meet too many times to discuss the same topics over and over again.

This might take a bit of discipline and agreement with your team, but with a few general practices in your meetings you can make them more efficient:

Start and finish on time, don't wait for late joiners, if you're on-time, you're late by German standards.
Have a clear meeting objective and agenda shared previously, this helps everyone know what will be discussed and prepare accordingly. If you receive a meeting invitation without an agenda or at least a description, reject it right away
Keep the conversation on-topic, call out side tracks and bring everyone again to the main topic
Take notes and share them, this avoids the back and forth after the meetings and the traditional questions such as "who was going to do X?", "did we decide A or B?"
Share pre-reads in advance and, if you receive a pre-read for a meeting, make sure you read it before joining

Meetings are a necessary evil, but with discipline you can tame the monster and make them more effective.

Start and stop on time

Yes, this is the most important advice. We often see Engineers working until late evening, it's not about the hours, it's about the quality of the time you put into everything you do, I'd rather work 20min on something but really focused than 4 hours but all over the place.

Work will always be there, it never ends, if you start and stop working on time you're not doing anything wrong, it's just the way it should be. Working remotely this is especially tricky because you don't have the pressure of commuting, you can stretch a few minutes to wrap up, but that's it!, when it's time, close your laptop and go to your family, otherwise working after-hours becomes a habit and you won't be productive during office hours because you'll be thinking on finishing after-hours.

Conclusion

Time management is vital and a very difficult soft skill to develop, it's all about routines and rituals to me, it takes a lot of will power and discipline to actually put these personal processes in place but, in my own experience, it's totally worth the effort, if I miss doing my TODO list one day, I feel bad and a bit lost and I'm not fully productive that day because I don't have a clear picture of the
priorities. Writing everything down helps you take it out of your system and take the tasks one by one without the fear of forgetting something.

The best language I've learned to grow in my career

Israel Fermín M. — Mon, 13 Sep 2021 09:12:07 +0000

English

If you're reading this, chances are you speak it already, if you're not a native speaker improve it, study it and master it. Practice your pronunciation and increase your vocabulary.

This has proven to have much more value to my career than any programming language I know.

Work for a company that puts people first

Israel Fermín M. — Thu, 15 Apr 2021 07:38:53 +0000

The title says it all, easier said than done right? the truth is that it takes a lot of time for some people (and not so long for some others) to find a place where they feel welcomed and belonging, it's a quite cool feeling when people appreciate you and makes an effort in making you feel comfortable at work in every aspect by always taking into account what's important to you and helping you with that.

For me, I've been working in the software industry since I was studying, and I have a lot of stories. Most companies value the business first, and that's completely valid, if the business is OK, everyone is getting paid and everyone is happy. But I feel I don't last long in this type of companies, I value flexibility, every company has its rules and every manager has their values and also set of rules they use to run their teams, but I believe everything needs to be evaluated in a case by case basis, not everyone has the same conditions or priorities in life and this is where this approach fails. Let me share a brief story of my professional life until now and why I've left some of the companies I worked for.

My first job

My first official job, and by official I mean, for a company, with a contract and not doing something kinda freelance for a friend, was with an online news hub, they scrapped news websites and presented all the headlines from different sources in a single place, people could customize which sources they preferred for certain topics and filter based on that. My job there was to build bots to scrape multiple sources, extract the content and store it in our system. I was still doing my undergraduate courses so it was a part-time thing.

Everything was going great! salary always on time for about 3 months, then...

By the end of the fourth month, I didn't see the salary being credited to my account, I didn't pay too much attention, maybe there's a delay with the bank or they didn't process the payroll on time or whatever, I emailed my manager and I got an auto-response that he was on vacation, half-way into the month I email my manager's manager asking what happened...

The answer was yes, you didn't get paid because you're not working with us anymore , I was a bit shocked because no one told me I was let go, they conveniently forgot to tell me that little detail, wait a minute, this gets way better, I highlighted exactly that and the answer was amazing: well, Israel, if you see the contract it says any party can end the employment agreement. It doesn't explicitly mention any notice, technically we didn't do anything wrong . Long story short, I had to threat them with going to the labor authority and report the issue in order to get my last salary... almost 3 months after.

Lesson learned

There's very bad people owning and managing companies, I know I was undergraduate but they even used that fact to imply I should be thankful about them paying me for my work because, and I quote textually, a lot of students would work for free just to get the experience , well, I wasn't one of those students...

My internship, great! until it wasn't

My first professional work experience was on my internship, I did it with a small local OpenSource consultancy firm, I learned A LOT!, the work environment was great and fun, workmates were cool, smart and the kind of people who knows what they're doing. The only bad thing was salary, as I was an intern, my salary was low, but I was OK, at least I was doing things I was into and learning quite a lot.

When I finished my internship, they offered me a permanent position which I accepted, they were aware I was still having academic commitments and they were OK with that. I had to work on my thesis project so, after some time I asked for some time off to do that, they offered me a room at the office where I could lock myself up for up to 3 hours a day to fully focus on my thesis, this was awesome but the only bad thing was it was respected for a bit over a week, after that I started getting constantly interrupted to work on other things, we went back and forth with this for a little over 2 months until I decided to quit so I could focus on my thesis.

Lesson learned

Sometimes your priorities and the organization's priorities are not aligned, and this is fine, when this happens the best thing to do is to part ways. Maybe if I was given that time off to complete my thesis as I initially requests I would still be working there. The company, the projects and the team were awesome.

Fast forward to my first job in Dubai

I won't be talking about how I got a job in Dubai and how I got here, I wrote about it before, I won't write about how cool it was because I already did it but I'll dig a bit deeper on the real reasons behind me leaving that company. I wrote an article before about it, but I wasn't completely honest about why I actually left because I didn't think it was appropriate at that time. By now, I know people have changed and switched places, and everything is different so I won't be at risk of exposing anyone.

The end of the honeymoon

In October 18th 2016 my first daughter was born, and it was also the day that marked the beginning of the end for me at that company. See, here in the UAE, the paternity leave policy at that time was 1 week off, that company gave 2 weeks and nothing more. Everyone knew my wife and I are here alone, the nearest relatives we have are in Spain so we were becoming parents all by ourselves, which is a lot of work, paternity leave is not vacation it's time to support your wife who just pushed a human being out of her body and now has to breastfeed, which is very energy-consuming and demanding.

So, 2 weeks are not enough, 40 days is the recommended resting time for new moms, I literally had to beg for my line manager to approve 2 extra weeks off from my annual leave and coming back, everything was changed.

My line manager started making my life impossible, I got a terrible performance review, which I felt was not fair because an incident from over a year and a half ago was brought up as the reason even though I fixed it in less than 1hr since the bug affecting subscriptions experience was reported.

Then, my in-laws visited in November, they were staying with us in Dubai for three months, until January, so, I applied for 2 weeks off in December so that we could spend some time around Christmas and New Year together and show them around. In December, the guy announces the following: guys!, there's a lot to do, so I won't be approving any vacations this month , my time off request was rejected and then I got to know another colleague got it approved to go back home for a relative's wedding and another colleague was also traveling the same month. I didn't get to spend too much time around either because there was always something to do, one day, at around 17:30, the guy in question starts packing to leave and says Israel!, please make sure you close all the zendesk tickets before leaving . After he left, I checked our support dashboard... over 30 tickets pending for resolution. I was effectively being given all the crappy tasks no one else wanted to work on.

Then I was moved to a different team

Yup, I thought things were going to improve, and they did for a bit, in 2017 I spoke in 2 conferences and several meetups, mostly about things I was working on and trying to attract more talent for the company as well. Before one of the conferences I got a task on a very short notice before traveling, so, I made it clear I might not be able to finish it before flying, but I would complete what I could and leave pointers on how to finish it so someone else could pick it up and I did exactly that, the night before flying I wrote a very comprehensive email explaining the approach I was following and detailing which classes needed to be changed, which methods and why, even left some test cases written to validate the functionality worked correctly. Coming back from the conference, my new manager calls me for a meeting, I thought it was something related to the talk I gave in the conference, but nope... not even close...

He hands me a warning letter, on which grounds?, because I failed to finish a task and left for a week , and he also mentioned your team mates say you're unreliable and they avoid working with you , I was shocked, no one ever told me anything like that. A few days after that meeting I asked my colleagues for feedback and everything I got was positive, so, I figured, either my line manager was lying to me or my colleagues were not professional enough to speak to me directly about work-related things they were not happy about with me. In both cases, I think that's unacceptable in a professional environment, I thought I left all that "talking behind your back" thing back in high school.

Anyways, the performance review time comes and I'm called for the performance evaluation meeting, to my surprise, there's my line manager and my old manager sitting behind the table which I found strange, what was even more strange was that the person delivering the performance evaluation was my old manager and, guess what, it wasn't a good one and quite old things from over 2.5 years ago were brought up, I have to admit I lost my cool in the middle stopped the evaluation, told my manager You'll have my resignation email in a few minutes and left the room, that's when I wrote an email to HR CCing my line manager to start my notice period.

Lesson learned

The minute you feel something is not right, speak up, complain, talk to people, highlight it... if you feel it isn't right, then it isn't right, you don't have take crap from anyone and if someone is giving you a hard time for no apparent reason, the best thing to do is to part ways, to be honest, looking back I feel I took too long to leave.

And I joined Careem

I already wrote about joining Careem and why I joined, so, I won't repeat myself here, but I will point out that I had my second daughter recently (2020) and I was super scared about it, this didn't go too well with my previous employer and I have to confess I started interviewing with several companies at the time, had 2 very good offer letters in my hands and was on the final stages for another 2 openings.

Things were different this time

Well, the only thing which was the same was the paternity leave time, only 2 weeks, I spoke to my manager about getting an extended paternity leave because of COVID, no family was going to be able to come over, airports were closed (it was by the end of 2020) and forget about traveling to Spain and working from there for a while... you know... because COVID... and also because my wife's passport was expiring. Nothing like this was ever proposed at Careem and he was quite new in this being a manager thing so, he did what any new manager would do, he asked me to go to HR and he would be OK with whatever they decide and, if they said no , we would find a way.

So... I went to HR and explained everything, they were super supportive, they said hey, there's no such thing as an extended paternity leave, but you can request time off your annual leave as we have unlimited vacations policy and we will leave a note highlighting this was for paternity extension . I did just that, not only HR and my manager were super supportive, but also my whole team. I got a bit over a full month to spend at home supporting my wife and taking care of our 4yo who was staying at home because of the pandemic so that my wife could breastfeed peacefully, also doing a lot of diaper changes.

Then, coming back to work was super flexible, they gave me quite flexible timing to continue supporting at home while we got back into the routine. I even got a great performance review, I am beyond happy about all of this.

What about the interviews

Well, I understood that very few companies are like this, so... I ended up rejecting the offers and canceling the last interview rounds.

My take about everything

A job is a job, and there's nothing you can do about it, you have it today, tomorrow no one knows. But not all companies are the same, there are some which puts the business first. For example, the first company I worked for... maybe they needed someone cheap to complete the mechanical work of implementing web scrapers to extract the content from those websites and they just stopped caring after it was done, I don't know. The one where I did my internship, well, they had projects to finish for the clients, so, they needed me to work on that, so my thesis and my graduation goal wasn't a priority for them. My first job in Dubai, well, I don't know what happened there, but if they had a "people first" kind of philosophy nothing of that would had happened. Of course, I understand, if the business comes first, it runs, it generates value and revenue and people gets paid.

Then, on the other hand, we have companies like Careem, maybe supporting my wife is not their business or priority, but it was something I needed to do so, they supported me on that. Then, coming back to work and get back into the routine might be their priority, and also mine, but also family comes first, so... if something was happening at home, I had to solve that first and then comes the work. They could have rushed me into work, but they didn't, we went step by step and I took only non-critical tasks for a while until everything was settled both at home and work. They understand that if you put your people first, they will care for the business as if it was their own, and that's exactly what I do. I want to work on a place like this for a very long time, and it's my job to contribute to its success so I can continue here.

Thank you Careem for being Careem.

Choreography and Orchestration in Microservices Architecture

Israel Fermín M. — Sun, 14 Mar 2021 09:44:23 +0000

On a previous article on microservices, we went through the best practices I've seen, which doesn't mean those are the only ones, it only means that those are the ones I've seen work for me and the ones I've tried.

This time, I would like to focus on Choreography over Orchestration and Rely on data, not services because I feel I didn't develop enough on these ones and those are really important these are also the two principles that will help you avoid sync calls, which is usually a good practice for inter-service communication.

But first:

Internal REST services, why not?

Don't get me wrong, I love REST, I like building API*s and I enjoy using a well designed one for sure, but for internal communication I prefer to avoid it unless the communication **needs* to be synchronous, there are some cases where you can't help it and it's not always because of a bad design, sometimes the use case itself enforces that restriction.

If you find yourself using network calls most of the time, something will most likely go wrong. Network is not 100% reliable and, always remember, if something can fail, it will fail.

Increases overall response time

Take a look at the following figure:

Response times are not taking into account the wait time while the downstream services respond. This means, service 1 queries service 2, it does something and takes 10ms to respond. Also, Service 1 queries Service 3 which queries Service 4 and Service 5. Service 4 does something and takes 300ms to respond and Service 5 queries Service 6 which takes 1000ms to respond, then Service 5 does something and takes another 1200ms to come back to Service 3, which has been waiting 2200ms to get all the data it needs to do some stuff which takes 300ms. By this time, Service 1 has been waiting 2500ms for all the data it needs to do a 120ms something and return back to the upstream caller, which could be another service waiting or the end user.

Note that the above flow paralelizes all the needed downstream calls per service, so in this case, the total response time will be constrained by the slowest call chain. If you were using a stack where doing multiprocessing or async programming is not an easy option, you'll have to add up the response time for all of the downstream calls because in reality the service in question is being blocked while waiting for the network call to finish and, only then, making the second call and blocking until it comes back and so on.

There are several ways you can keep the same setup, you can add several levels of cache in between services, you can add a timeout to the network calls but everything comes at a cost. If you're keeping a synchronous approach to answer certain questions it's because you need your data as fresh as possible, so, the more cache you add the more stale your data could be. You could also add a timeout to your calls but, if one of them times out, you'll fail in responding to the upstream caller and it will look like the system is down.

What if someone is down?

Let imagine Service 6 is down because we had a buggy release.

This means, Service 1 will have to wait 1500ms before returning an error upstream, you can mitigate this with a [circuit breaker (https://www.martinfowler.com/bliki/CircuitBreaker.html) approach or returning a cached response for the query you're trying to answer but, again, unless you really need this to be synchronous, you'd be adding more complexity to an already complex system.

Also, what if it isn't a read operation, what if we're actually writing downstream and the last write fails because of reasons. You'll be half way a transaction and you'll have to deal with it somehow, either queuing that last write and hoping Service 6 comes back soon or rolling back the whole transaction which would mean deleting from the other services and returning an error, there are ways to solve this, but usually it doesn't need to be this hard.

When should I go synchronous?

In my opinion, it will depend on the use case you're implementing and how critical it is to return the exact data at the moment the request was done, usually there's some tolerance to return slightly stale data, but things like credit accounting, warehouse availability or anything that was to do with resources being consumed in real time are good candidates for sync calls and all the complexity they involve.

Choreography vs Orchestration

There's a good analogy in the microservices world and how they handle things happening within the system, let's call those things events.

Let's say there are two types of events, those which make the system do something, for example, in an e-commerce website it could be a user bought something, and those which make the system change its status, for example, update some records in the database o send a request to another service. The first ones, let's call them external events because they're triggered by an external actor, maybe the user or an external system consuming our API, these external events are the ones triggering the second ones, let's call them internal events because it's the system updating itself. So, external events trigger internal events.

Now, there are two ways of handling events, we can either do it via orchestration, where we have a service which acts as the master of the transaction, telling all the other services involved in it what to do, what to update. Just like a Conductor does in an Orchestra, it tells all the other musicians (services) when to play they part, how to play it and so on. The other way is more like a choreography, where given an event every service knows how to handle it and how to react to it, just like dancers who know how and where to move or what do do when a certain part of the song is played.

Good architectures are a mix of both approaches and good architects know when to use either of those depending on the business needs and the use case they're modeling. Unfortunately there's no recipe to decide, gaining experience designing systems and making mistakes are the only way to learn, although reading about others experience, having clear concepts on how distributed systems and networks work and a good understanding of the problem at hand we're solving are a good starting point.

Rely on data, not services

We spoke about low coupling and high cohesion in microservices in a previous article, relying on a service to be up in order for some other service to be able to do what it's supposed to do is some form of coupling, you are letting an independent system fail because another is feeling unwell.

For services to be independent, every service should have a copy of the data they need to answer at least basic queries, this doesn't mean you'll directly update the copies, you need to define which service is going to be your source of truth for a specific piece of data and perform all the write operations for it to that service and then, somehow, update the copies. You can rely on internal events to do this, every time an external event triggers an update on the source of truth for a give piece of data, you can fire up an internal event to make the services keeping a copy update their local copies.

By doing this you can still serve a read-only version of the data for some use cases even if the source of truth is down, if it's, for example, an e-commerce and the source of truth for the catalog is, for example, the Inventory Service, you can still serve the catalog even though the users won't be able to purchase anything, they still can save them to their wishlist and browse the website, this lets you gracefully degrade your system if there are problems with some services, you just show an error message or hide the options or have alternate workflows until the systems supporting the degraded use case are back up and running.

What if a service is down and misses some updates from the source of truth?, well, depending on how you propagate the updates, you can do several things. You can use a queuing system like ZeroMQ or RabbitMQ to propagate the updates, so, if a service is down, the updates will be waiting on the queue to be consumed once the service is up, if you're using HTTP calls, you can have your worker retry the failed requests after a back-off time or write the payload to a given location so, when the other service comes up, an init script checks that location, reads whatever is there and marks those messages as consumed, there are multiple ways to deal with this problem, most of them will depend on the technology you're using.

Eventual consistency

When you deal with distributed systems and distributed information, chances are, some copies will be stalled for a period of time, this means, information will always be flowing through the pipes of your system, the only way you will have total consistency is if you stop writing and wait some time. Even in monolithic systems, what you show to the user is stale most of the time, let's say, for example, a website listing used articles for sale, when the search page is served to the user, depending on the traffic, there will be probably 10ths or hundreds of new articles the user won't see unless they refresh the page or we have a pushing mechanism in place. So, how important is it really to show the most updated information available to the user?, truth is, is not that critical in most cases.

For building reports though, you should always query from your sources of truth, this could be tricky on a distributed system where your source of truth varies depending on the information you're looking for and it's not a single database where you can run a SQL query and join everything together. You could rely also on internal events to build a reporting database while the relevant events are happening instead of querying everything when a report is requested, this way you'll always have relevant business data to produce reports on top of.

Conclusion

There's no silver bullet to solve the problems that come with distributed computing, however, there are strategies to help you discover the best way to deal with certain problems for your specific use case, try to use choreography where possible and orchestrate the flows that need to be completely synchronous, always try to find the easiest solution, keep in mind that sometimes the easiest way to solve a problem is the hardest to implement, but benefits will be seen in the future, when you need to debug a failure or scale, or even extend your system with more features or plugging more microservices in.

Also, always prefer choreography and async communication when possible instead of orchestration and sync calls between services, this doesn't mean you should avoid it at all cost as there are use cases that need that approach. A good architect knows that the best way to solve a problem is not following strictly one and only one approach, it's combining different concepts and ways around it and adapting them to the specific problem to achieve an efficient and elegant solution.

Internal Open Source

Israel Fermín M. — Sun, 28 Feb 2021 06:35:13 +0000

OpenSource software has been out there for quite a long time, the idea of people around the world volunteering part of their time to work on free software is very exciting, but also maintaining those projects is very hard. Keeping everyone on the same page so that there's no duplicated work, agreeing on the road-map and what's going or needs to be done, prioritizing bugs, reviewing code, merging and then, everyone updating their local repos or forks. OpenSource software development is a huge human distributed system which, most of the time, uses async communication due to the inability to get every single developer working on the software in a room or, at least, a virtual call for obvious reasons: timezone, everyone works on different schedules so everyone is free at different times and most of the people also work full time for software companies, most of the time on other projects.

OpenSource projects and free software development has tons of limitations in the way they can coordinate and communicate with the entire team, and yet OpenSource projects has higher standards and a higher bar than most close-source projects or corporate-internal software built in-house. This is why, whenever I need to do something at work, whenever I need to research for best practices in how to manage a project, how to manage or coordinate a team, how to do anything with tech, I refer to how the team behind my favorite OpenSource project
at the moment is doing things and borrow as many ideas as possible and see how to adapt them to what I'm working on or the team I'm working with. OpenSource has very complex people problems, team members are scattered all around the globe, if their strategies, policies and practices help them solve their problems, they should also work at a smaller scale in private companies building software.

The cathedral and the bazaar

The Cathedral and the Bazaar is an essay written by Eric Raymond, in this essay he examines two different approaches to Software Development by two different OpenSource projects:

The Cathedral: where the source code is available for each release, this is only the stable code, all the code in between releases and all the work done on top of it is private to the contributors only. In the essay the author cites GCC and GNU Emacs as examples for this approach.
The Bazaar: where all the code and the development process is public to all of the internet, in the essay, Raymond cites Linux Torvalds as the inventor of this approach and the Linux Kernel Development as an example of a project built under this method as well as the Fetchmail project.

I won't go deep into the essay as I think it is a must read for every Software Engineer, so, I'll leave some links so that everyone can have a look at it:

TL;DR; you can check the main points on the essay in its Wikipedia page
You can also find the full version at the official website along with other interesting writings by Eric Raymond

Key points

The key highlights from the article, also mentioned in the Wikipedia page, are summarized in the following 19 lessons:

Every good work of software starts by scratching a developer's personal itch.
Good programmers know what to write. Great ones know what to rewrite (and reuse).
Plan to throw one [version] away; you will, anyhow. (Copied from Frederick Brooks' The Mythical Man-Month)
If you have the right attitude, interesting problems will find you.
When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
Release early. Release often. And listen to your customers.
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Smart data structures and dumb code works a lot better than the other way around.
If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry)
Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
A security system is only as secure as its secret. Beware of pseudo-secrets.
To solve an interesting problem, start by finding a problem that is interesting to you.
Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

My own views

While Eric Raymond's essay covers different approaches to open source development which can be also used in the industry, inside software companies,
I see something very common within open source projects, they all produce high quality documentation, not only because they want people to use it
but also because they want people to be able to collaborate and contribute without taking too much time from active developers who are volunteering
to work on the project. This approach to on-boarding new contributors is very powerful and can benefit a lot any team working on software projects
in any company.

Having high quality documentation can help mainly in two things:

On-boarding new team members

How many times have you repeated yourself over and over and over again when a new engineer joins your team, walking them through
the architecture, the code, setup the local development environment and then helping them ramp up on the tools used in the team.

This walk-through can be easily delegated to documentation pages maintained and updates by the team, just the same way OpenSource projects
do it, they have a section on their docs specialized in helping new contributors getting started, it also explains how to update the docs, so
that if any new contributor finds a mistake, something that's not up to date or something that needs to be documented, they can just edit
the wiki and fix it or add whatever is needed. This way the next person to be on-boarded won't face those issues.

Empower other teams to contribute

It's a common case to have internal services which are only used by other services maintained by other teams, these are called platform services,
they commonly abstract underlying resources needed by public-facing services, also, it's common to have public services relying on each other or
exposing endpoints so that other services request or update transactional data, which means, other teams might require features to be
built in other services by other teams for internal consumption.

In a normal scenario, both teams will have to coordinate and align on deliverable, prioritize and iterate over and over again, often, priorities
change and everything needs to be reevaluated. If you follow any inner source pattern, whether you give access to the stable code or all of it,
plus high quality documentation for new contributors, the other team can easily contribute to the service in question and build the feature they need
by themselves. Of course, you need to also make it easier for them by providing clear guidelines and policies on how to contribute, the code
conventions used in your team's project and making sure the team knows them and enforce them, after all they'll be the ones maintaining that code
after it gets merged.

I've implemented this in some of my teams and the relieve of flipping the responsibilities to support internal use cases to the team requesting the
features is amazing. We've only had to give them links to our docs, help them update it wherever it was not and have them add whatever they thought
could be useful, then, during development it only requires code review, 80% of the effort relies on the team building the feature they need on the
service your team maintains while you only support them with code review and, maybe, QA, but if the feature is with them their QA team should be thew
one having more clarity on the use case and, hence, the test cases needed to be covered.

It's very convenient, it unblocks other teams which need custom features for internal consumption to be built as they don't need to wait for your team
to be free to do it, risking their deadlines on priority changes on your end while also lets your team focus on whatever priorities are there for
them. It only requires some time to put the documentation in place and review the code being pull requested by the contributing team.

Does this sound like something you might want to try?

Guiding principles to build scalable microservices architectures

Israel Fermín M. — Mon, 08 Feb 2021 03:46:03 +0000

There's been a lot of stuff going on these days on Software Engineering, it's hard to catch up on everything I would like to. I try to go one topic at a time and now, also because we are working with this at the office, I'm hooked into microservices.

Microservices is a new word for an old concept, a concept I thought I will never see or play with in real life back in my University years, I remember my Software Engineering and Distributed Systems professors talking about web services and API*s and huge systems at IBM, Sun Microsystems and Oracle, SOAP and REST interfaces and how they interacted with each other and, also, the mighty Enterprise Service Bus with producers and consumers in Java, BPEL and C#, a very abstract concept for me to grasp at that time and I thought **the only place* you could see that was working at huge, corporate companies like the ones I mentioned above.

Nowadays, any internet startup can grow at a huge scale and you can play around with this kind of technologies if you're lucky enough to be part of one of those projects.

I was lucky to be part of the dubizzle team, a classifieds website that operates at a massive scale here in the middle east, the architecture is a huge legacy monolithic application with all of the core functionality and several satellite services surrounding this legacy app. These services are, in my opinion, mostly poorly integrated and fault tolerance is not the rule, sometimes error responses are silenced and bypassed which is quite bad. Also, the integration goes over HTTP, which could be very unreliable even within the internal network and gives you a lot of headaches when you need to integrate more and more services. But the whole point of migrating to microservices is to solve all those issues and have a better engineered platform to keep both product and tech as happy as possible and be able to move faster at the same time.

We dedicated some time now to study best practices for implementing a microservices based architecture and built some proof of concepts and deployed one of them to production here are some of my key learning and good practices taken from what I've read and personal experience actually building stuff at dubizzle and playing around with technology on my personal projects.

APIs should be business bounded

It's a common mistake to build APIs as simple CRUD interfaces for domain entities. This means, all the business logic must be written and rewritten in the clients, so, if you have, for instance, a web client, a desktop application, an Android and an iPhone mobile apps, well, you can count yourself how many times you'll have to write the business logic surrounding those data models with a CRUD API.

You have to build your API to encapsulate business processes, not just the objects creation and manipulation, so a single API call, triggers all the needed processes to fulfill the request or the query the client just gave to the server.

Services must be independent units

This means, you must think of each microservice as a project or a product on its own, this means each service has its own box and its own release pipeline and its own life cycle, but also, they don't rely on each other to function. This means, if your invoicing service is down, your payment service don't need to suffer because of this, you can always accept payments from your users and send the invoices later, when your invoicing service comes up again.

Rely on data, not services

In the previous example you might be thinking "dude, but if the invoicing service is down when the payment service hits it, how will it know it needs to send an invoice to a user?". Well, you need some way to let it know once it wakes up, some data sharing mechanism like a shared database (which is in general a bad idea because it creates coupling between our services) or some sort of caching on the services that needs to consume that data.

In our example, we could make the payment service and the invoicing service share the same database, or, have a good separation of concerns and lower the coupling and, since invoicing needs to know about payments but, payments have no need to know about invoicing, we can just have a caching mechanism in place in our invoicing service and have a copy of the needed data about payments in order to generate invoices, of course, this will add some complexity to our system because we need to be fault tolerant and make sure the data still reaches the cache if the invoicing service is down and we need to put some cache update processes in order to keep it up to date.

High cohesion, low coupling

This is a principle borrowed from Object Oriented Programming, let's remember what they mean

Coupling

coupling is the degree of interdependence between software modules.

Wikipedia

This means, if two modules, functions or services rely too much on each other, chances are if I make a change on one, I'll have to make a change on the other one to compensate, this makes our code and architecture less orthogonal, which means exactly that, a change in one part of the system, will affect other unrelated parts, just like driving a helicopter.

Cohesion

cohesion refers to the degree to which the elements inside a module belong together.

Wikipedia

This means, it's a measure of how much the elements inside a module belong together, not necessarily they rely on each other, but they all work together towards a common objective.

In general cohesion is increased if:

All the elements in the module have much in common. This means, access the same set of data, for example.
The elements in the module carry out a small number of related activities. This means, each member of the module does one and only one thing related to the task without side effects

By keeping related functionality together, we are automatically increasing cohesion and lowering coupling, and this is exactly what we want.

What does this mean in microservices?

Well, it's easy to think of coupling and cohesion withing the same computer program or the same code base, but in microservices this means exactly the same, keep related functionality together so you don't have that logic spread all over the place and duplicated in more than one service. This also mean, keep services using similar or related data together, either logically or physically.

One hit, one transaction

This means, avoid distributed transaction at all costs, they are difficult to implement and even more difficult to debug if something goes wrong, ideally one write operation to your system should directly affect one service, what happens offline could be a different story. For example, we could have our payments service which deals with a third party payment gateway to charge our users' credit cards, to keep things under Single Responsibility Pattern (SRP), we will have a separate invoicing service which handles generating and sending invoices to the users (I know, we could separate things even more by having a separate notification service that handles sending the emails but let's keep it at this level for the sake of simplicity).

So, the only thing my client needs to know is I need to make a payment, whatever happens afterwards it's not my client's problem, it only needs to hit the payments service with the needed payload and get the response to show it to the user. What happens under the hood is my payments service's problem, it needs to somehow notify the invoicing service that it needs to email an invoice to a specific user, this has to happen offline, either we start a separate thread or use a message queue for it and we notify either generating an event or via an HTTP call, but this needs to happen offline and be fault tolerant so we don't keep the client waiting for something that is our internal process, as well as updating the inventory, generating accounting ledger entries, etc.

Choreography over orchestration

This is, to me, one of the most important best practices I've learned then it comes to microservices oriented architecture, when we think of distributed transactions we often have some sort of director or conductor, which is the service that initiated the transaction, it will know, what needs to happen and in which order, also, it will be the responsible to roll everything back if any part of the transaction fails, transactions need to be Atomic, right?. This is a very dangerous approach because, if something goes wrong while performing the transaction, nothing can guarantee something won't happen while rolling it back, leaving the system in an inconsistent state and giving us lots of headaches down the road when having to debug some weird behavior in our system.

The best way to implement these kind of distributed transactions, i.e., business processes that need to update more than one service is through Choreography, if you think about a choreography, there's no conductor, everyone knows what they need to do, where they need to go, the only signal is the music. This means, in microservices, we just need to notify everyone something happened, and the concerning services will react accordingly, either updating their database, emitting another event or sending a notification to the user.

In order to properly implement choreography we need to build resilient services by putting in place fault tolerance logic or processes so, if some service fails to react, it can heal itself or someone gets notified.

Don't rely on HTTP

Peter Deutsch and James Gosling wrote about the
8 fallacies of distributed computing and the first one was

The network is reliable

A million things can happen when you rely on the network, maybe the requests times out, maybe there's a broken link, maybe subnet permissions were changed maybe the host we are trying to reach is unavailable, maybe a rat ate a network cable, lots of things can happen and we are not in control of all of them, even within our own private network.

What I'd recommend instead is to have a communication layer in the form of a message bus, it can be a queue like RabbitMQ or a data streaming pipeline like Apache Kafka of course there will be a bit of network communication between your services and the communication layer, or your services and the database system, but that's being taken care of by the corresponding drivers or libraries or deal with those, so, you can assume they're fault tolerant and the data will reach its destination.

There will be cases where you can't avoid rely on HTTP or any network protocol, for example, you need to serve your website somehow, and you need to query your services somehow too, so, in this case I'd recommend to go for a REST API or whatever protocol you prefer for external communication (third party services and client-server) and using a message bus for inter-service communication.

A note about the fallacies

Some people will say that the 8 fallacies of distributed computing are obsolete nowadays because there are tools already that handle everything for us, replication, secure networking, authentication, networks are sophisticated so, latency is not a problem anymore but, just because someone is taking care of something for us, doesn't mean that something isn't there, imagine building a system without these tools, you'll have to face them anyways, besides, there are countries where the computer networks are not as good as in the US or Europe for example, so, I wouldn't say these fallacies are becoming irrelevant. Even if you're not implementing replication or security yourself, you need to think about it and use something that handles that for you.

Scaling django: measuring your django app's performance

Israel Fermín M. — Mon, 01 Feb 2021 11:27:14 +0000

It's been a while since the first post about scaling web applications using django, last time we spoke about some basic concepts about scalability, buzz words we hear everyday and we also use but always struggle when we need to give a formal definition to someone.

Once we have clear basic concepts about scalability, performance and we are familiar with the Pareto Principle, we are ready to start optimizing and improving our system's performance, right?. Not so fast cowboy!, if you remember the Pareto Principle most of the negative performance impact is coming for 20% of the negative impacters. We need to manage somehow to solve that 20% so we are sure we are making a significant improvement.

You can't manage what you don't measure - Peter Ducker

This means, we need to gain visibility inside our system to be able to detect those bottlenecks and work on solving or easing them. For that, we will need a set of tools to monitor and profile our application.

The tools

There are a lot of monitoring tools for Linux and for django out there, you can use the ones you like the most, but I'm going to showcase some here as a starting point. I'm not going to go deep into how to install them and set them up or customize them because it's out of the scope of this post, but I might post some individual howtos later, here I'll just point you to the corresponding documentation.

django debug toolbar

This is my all time favorite, it's a pip-installable module for django and you'll need to add some settings variables and a template tag and you're done.

As you can see on the screenshot it will give you a lot of relevant information about what happened under the hood to serve that request, it will tell you the missed cache hits, which static files and templates are being served, the current request headers and request parameters but my favorite feature is the SQL viewer, it will show you the queries that ran on that view, with a timeline and their run time so you get to see which ones are taking long time and take action, it gives you also the option to see an EXPLAIN of the query to check what the query planner did.

To install it and use it, you can refer to the official docs

vprof

This is a visual profiler for Python, although it isn't made for django, you can plug it in and take advantage of all the cool graphs it will draw for you out of the box.

A profiler will measure how your code is behaving and tell you where the hot points are as well as your call stack, vprof will give you an insight also on how much memory your program is consuming so it's easier to detect memory leaks.

Here are some of the graphs vprof will produce for you

Flame diagram to allow you see your function call stack
Memory profiler

To set it up you can refer to the official docs

CProfile

Setting up vprof for django might be tricky depending of your application architecture and setup, CProfile is pretty much the defacto standard on Python profilers, it will produce an output on an standard format you can plug into any profiling reporting tool such as SnakeViz to produce cool graphs that will help you understand what's going on.

You can easily set it up in django by using django-cprofile-middleware this app will also add one endpoint any staff user can hit to get data about the performance and, also, CProfile can produce an output file you can pipe into SnakeViz

This is how SnakeViz graphs would look like:

StatsD

This is an external stats collecting system built by Etsy, they blogged about it and how it works and it's also open source, you can set it up in django through a third party app called django-statsd.

Using this is a bit manual, you will need to send out your stats the same way you use log statements to add entries with messages about what your system is going. In this case what StatsD will do is keep a log on counts and timing of the events you are sending stats about.

The coolest thing about StatsD is that you can set it up to periodically flush data to Graphite where you can then produce this kind of graphs on top of StatsD's data

Use the logging subsystem

Logging can save you a lot of time if you do it right, it can also clutter your code with logger.info() statements everywhere if you over do it, you need to log everything so you know what your app is doing at each step of the different processes it performs, but log even more on the critical ones.

These log files need to go somewhere, maybe you're familiar with syslog to concentrate your logs in a single server so you have only one place to go when you need to do some text-processing-fu with sed, awk, sort and grep, but as your system grows and also the amount of different loggers storing messages, it will get trickier and trickier to keep track of every action across all the different modules of your system, an ELK system can help you to ease the search through your log files and also generate reports and graphs on top of your log data using Kibana.

You can read more about the ELK or Elastic stack here

newrelic

If you have some budget to invest on this, newrelic will give you most of these features out of the box just by installing and setting up their Python tracker, it will start pushing data to newrelic and you can see your system's performance in real time, it will show you data such as the average response time as well as response time in percentiles, average throughput, average error rate, error data and even transaction data like the one you get from django-debug-toolbar.

newrelic's main dashboard
Transactions dashboard
Errors dashboard

If you have the budget, newrelic is a no-brainer it will be a valuable tool for you and your team and save you a lot of time when you need to debug a live issue.

Final words

Before you even think of optimizing anything, you need to measure, there is no point in blindly going through the code and, for example, indexing fields in your models if you don't know the impact of that, if any at all. The tools mentioned here are not a definitive guide to profiling django applications but they provide a nice starting point to begging playing with them and choosing which ones work for you and which ones doesn't so you can improve your tool belt, your stack and the quality of the products you're building.

Monitoring and measuring shouldn't be an optional thing, it should be there if not since day one, at least added within the first months of life of your project, that's the only way you get to see inside your application, detect bottlenecks and potential bugs, debug them, measure their impact, prioritize them and be sure that by rolling out the optimizations you will have an improvement of ~X percent in your performance.

Scaling django: basic concepts

Israel Fermín M. — Mon, 25 Jan 2021 06:36:06 +0000

I gave a talk on PyCon Balkan scaling django, obviously on a 35min talk you don't have enough time to outline all the strategies and go deeper, so I thought it might be a cool idea to write a series of blog posts about this topic, not only to help someone who needs to optimize his django app, but also to help myself have it for future reference.

There are a lot of django apps out there, in most cases the default setup and basic deployment strategy would be fine, and your application will perform OK, but in some cases you will need to make it scale to serve thousands or millions of requests per day. There's no recipe for optimization or scalability, but there are a lot of technology or stack agnostic strategies you can use to make your systems scale well, here I'll show how to implement them with django.

Basic concepts

First things first, we need to have clear and solid concepts in mind, we use these words on a daily basis if we're Software Engineers but when we need to say what they mean we sometimes struggle, so, I'll write them down here for future reference.

Scalability

Scalability is the capability of a system or process to handle a growing amount of work or its potential
to be enlarged to accommodate it

Wikipedia

What this means is the amount of work processed by a system must grow in proportion to how much it is enlarged, for example, if I have a cashier at a bank, and that cashier is able to serve 10 people per minute, if I add one more cashier to my system, it should be able to serve rightly 20 people per minute depending on the training of the other cashier and some other conditions. Luckily, servers are more homogenize than people's abilities, for servers or applications, if I have a service that handles 1000 requests per minute, if I add another instance of the same service I should be able to handle 2000 requests per minute.

Performance

Computer performance is the amount of work accomplished by a computer system.

Wikipedia

You usually want to measure performance by some metric, for example:

Response time: which you want to minimize
Throughput: throughput is the rate of processing work, this one you want to maximize
Resource utilization: which you want to minimize, you want to accomplish more with less
Availability: you want to maximize your uptime

The performance metrics are relative to the type of system you're building, for web applications you usually go for low response time and high throughput.

Pareto principle

This isn't actually a concept, but it is incredible how things always turn out like this. The Pareto principle states what follows:

For many events, roughly 80% of the effects come from 20% of the causes

For example, 80% of the work will be done in 20% of the time, the other 80% will be spent on small issues or small tangential work not directly related to the main objective. 80% of the bugs is caused by 20% of the code and, in this case, 80% of the performance impact is caused by 20% of the issues.

This is interesting because it makes you see that not all issues affect your system's performance the same way, there are some issues that are more serious and not necessarily the same issue on a different project will impact it the same way. Find that 20% and gain an 80% on performance, sounds easy, right?, but it isn't.

Takeaways

As a Software Engineer, sometimes I become so obsessed about performance I sometimes write things already optimized, this is a big fallacy and a huge mistake, premature optimization is bad because you don't know if what you're doing is actually going to have a significative impact on your system's performance, blind optimization is worse, because you might have some ways to get data or an insight on how your program is running but you're just too naive or lazy to go get it.

In the following posts, I'll recommend some tools to measure and later on some strategies to make your django site scale, so, what you'll see in part 2 will be a set of tools to monitor your app's health.

Resources:

My talk in PyCon Balkan: https://www.youtube.com/watch?v=k520PnB-xHox

Don't forget to follow me, I'm also in twitter: https://twitter.com/iferminm

Quick and easy user registration with django

Israel Fermín M. — Thu, 21 Jan 2021 17:18:00 +0000

What does 99% of the projects we work on have in common?, what's usually the first or the last thing we start working on when building something, a personal project perhaps?. If you said dealing with users, that's right. On each and every project we find ourselves writing different registration or authentication flows, sometimes we use third party authentication services like Google or facebook via their *API*s, but most of the times I'd say we start by asking our user's to register using their email and a password.

Common approaches

There are several approaches to user registration, we can do it on a single step, or we can do it on 2 steps with a confirmation email being sent to the given address. There are several ways you can structure your registration flow, either two simple questions (email and password) or multiple questions through several pages, you name it, we always write user registration flows.

If you ask me, I've always preferred to write a simple one, ask for an email and a password and ask for the rest of the information I need on a separate User Profile page, things like name, date of birth, country, city, mobile number or other stuff I might need. But you want as less friction as possible on the registration process, especially if you're trying to get your first users, that's why I don't even send confirmation emails when I just launched something. I start asking for confirmation when I already got some users and I have people constantly signing up, otherwise, it's not worth the effort or the network traffic, plus the complexity of sending it asynchronously with a message queue.

Those are the reasons why I thought of writing a reusable django app to solve this, build an app to have django create users and just use it in all my projects. I was working on it for a while, taking the good parts of all the registration flows I've written, until I found django-registration and just switched to that library.

User registration flows with django-registration

This is way better that anything I could have written myself, it's being used by many people, has an active maintainer, works out of the box and supports single and two steps registration flows so, why reinventing the wheel if it's already there?, I'm using it for a couple of personal projects I'll be launching in the upcoming months (or not... you know...) and it's incredible how easy it makes it to implement user registration in django, allowing me to start working on actual features and functionality in almost no time.

Let's get started

Installing django-registration

To install it, you just need to pip it as any usual Python module

pip install django-registration

For the simple one step registration flow or the HMAC Based workflow, you don't need to do anything else.

Registration workflows

django-registration, supports three different workflows:

One step user registration flow

This workflow consists of as few steps as possible, the user signs up by filling the registration form, after submitting, the account is created without any intermediate verification and the user is logged in automatically.

HMAC-based user registration flow

It's a two steps registration workflow that doesn't store any verification key, it sends instead a timestamped HMAC verified value to the user via email in order to verify the account.

Model-based user registration flow

To use this workflow, you'll have to add registration to your INSTALLED_APPS as you will need to install one model to perform the verification step. If you need a two steps account creation because you require email verification, the recommended way is to use the HMAC flow.

The basic one step registration flow is the easiest way to register new users, if you're just deploying something for fun
and it's intended mostly for your personal use but want to allow other people to use it, I don't think you need to verify
email and go through all that hassle unless you get serious about it, so in my case, the intended user for my project is just myself, but if someone else wants to use it, I'm OK with that, I assume if you want to use something you'll just provide a legit email because it's on your own interest.

Setting up django-registration

I decided to go for a one step flow, as I don't really care if anyone provides an nonexistent email, I'm the one who will mostly be using this, so, I guess it's OK, django-registration allows me to restrict new accounts from being created just by adding REGISTRATION_OPEN = False on my settings.py file.

Each registration flow comes with its own set of views and urls and you'll have to create your custom template and form if you needed, you'll most probably end up customizing some behavior, but it's really easy to do, most of the core, boring and repetitive work of creating the registration workflow is done for you and works out of the box.

In this case, for the one step all I had to do was the following:

1. Include the URLs for django-registration

Include registration.backends.simple.urls in my urls configuration

from django.conf.urls import url
from django.conf.urls import include

urlpatterns = [
    # Some url patterns
    url(r'accounts/', include('registration.backends.simple.urls')),
    # More url patterns
]

2. Allow creating new user accounts

Set REGISTRATION_OPEN = True, this is the default value, but better explicit than implicit

3. Setup redirections after user creation

By default, after successful registration the user will be redirected to /, but you can customize this behavior by
subclassing registration.backends.simple.views.RegistrationView and overriding the method get_success_url(), in my case, redirecting to / is fine.

4. Customize the user registration form

By default, django-registration will use registration.forms.RegistrationForm, this can be overridden by supplying your own form_class argument when adding the default RegistationView to the urlpatterns or by subclassing it and setting the form_class attribute or implementing get_form_class(). In my case, I opted for passing an argument to the as_view() method when adding the corresponding url.

from registration.backends.simple.views import RegistrationView

from django.conf.urls import url
from django.conf.urls import include

from .forms import UserRegistrationForm


urlpatterns = [
    # Some url patterns
    url(r'accounts/register/$', RegistrationView.as_view(
        form_class=UserRegistrationForm
    ),
    url(r'accounts/', include('registration.backends.simple.urls')),
    # More url patterns
]

5. Customize the registration template

Customize the registration template, this flow only needs one template called registration/registration_form.html and it will pick it up automatically, the RegistrationView will add the form variable to the context and it will contain a RegistrationForm instance, all for free.

Using django-registration can save a lot of time, setting up the HMAC-based user registration flow is also super easy if you need to, I'd recommend you ro refer to the official docs, linked below, if you want to dig deeper into this django module.

Resources

https://django-registration.readthedocs.io/en/3.1.1/

Working easier with legacy databases

Israel Fermín M. — Tue, 19 Jan 2021 16:12:02 +0000

This will be a short article, recently at work I had to build few reports on top of two legacy databases, to be honest, the whole architecture and the way the data is stored, in my opinion, is not optimal, a lot of things need to change but, as usual, features and business take precedence over technical debt.

The whole stack is based on nodejs on top of typescript, which makes a bit more enjoyable the fact that I'm now working in JavaScript. All the databases were generated using knexjs so, these databases were there already and I only had to connect to them.

I didn't want to spend too much time on the connection and mapping part, so I wanted to see if an ORM would be of use here

The overall idea

Since we will be integrating with other internal tools to generate these reports the implementation I came up with is temporary, so I wanted to make as few changes as possible in the current codebase for several reasons:

Once you add something temporary, it will be difficult to clean it up after it's not needed anymore, the chances of someone building on top of it is high.
I don't like working with typescript, or JavaScript in general so if I could get away with writing in some other language it could be more fun.
The current application is a monolith and the logic is complex, adding more would take longer than implementing something from scratch.

So, I decided to implement the report generating logic in a Lambda function which will be executed periodically, this meant I had to setup the connections to the databases from scratch and map to my domain classes and types in order to have a clean architecture.

Enter Sqlalchemy

Sqlalchemy is the database Swiss army knife in python, it makes it very easy to work with databases by mapping tables to domain classes, but it also works the other way around by introspecting the database's schema metadata and generating stub classes to deal with them in Python.

Automap

Sqlalchemy has an Automap extension, which lets you connect to an existing database and generate a domain model from the existing database schema and operate with it from Python, trigger queries and use Sqlalchemy normally as if the schema was generated by you.

It's very easy and it doesn't take 30 lines of code

import os

from sqlalchemy.ext.automap import automap_base
from sqlalchemy.orm import Session
from sqlalchemy import create_engine


DATABASE_URL = os.getenv('DB_URL')

Base = automap_base()
engine = create_engine(DATABASE_URL)
session = Session(bind=engine)

Base.prepare(engine, reflect=True)

Then you can access the classes with the table name as it is in the database let's say you have a user_profile database, then you can access it as

Base.classes.user_profile

Trigger queries as

UserProfile = Base.classes.user_profile

profile = session.query(
    UserProfile
).filter(
    UserProfile.user_id == 123123
).fist()

And you're good to go.

Of course, code conventions in SQL and Python are different, if you want your code to look more pythonic and have Base.classes.* to be in PascalCase as well, you can write a function to override the table naming when the automap is performed, it will add few lines but still below 20 lines in general

It looks something like this

def snake_to_pascal(base, tablename, table):
    return ''.join([w.capitalize() for w in tablename.split('_')])

Of course, that assumes your tables are named as this_is_a_table and will be converted to ThisIsATable

You can use that function when you call Base.prepare as follows

Base.prepare(
    engine,
    reflect=True,
    classname_for_table=snake_to_pascal
)

And that's it. :-)

If you want to know more about SqlAlchemy, you can always refer to the official docs: https://www.sqlalchemy.org/library.html

New grads survival guide

Israel Fermín M. — Mon, 18 Jan 2021 11:31:30 +0000

OK, OK... I'm sorry, I lied on the title, but please, don't stop reading. I know... I know, we started bad our relationship already but, I can explain it, I swear.

Yes, it says "survival guide", but it's not like that, I'm not going to tell you a recipe to get the job you want, in the company you like and the country you dream, that's impossible, as programmer we all know there is no silver bullet, and it applies not only on software, also in day by day life problems.

What I'm going to share with you, is what worked and still working for me, let me give you some context. I'm a Software Engineer from Venezuela, yes, I know... we're famous for good baseball players, beautiful women and, most recently and sadly, thanks to this guy.

And this other guy...

My country is, obviously, a 3rd world country, we're facing huge and very serious economic and political issues and it's quickly getting worse thanks to those guys, my family is not rich so I couldn't travel or go to another country to study until things get better and, by now, I'm living in Dubai, paying my rent and brought my wife abroad so we have some hope of having the quality of life we dreamed together and have 2 kids, how I did it?, my job is my flight ticket and my passport.

I managed to get out of Caracas, one of the most violent and dangerous cities in the world, and come to Dubai in 2014. Obviously this wasn't with money from my own pocket, a local company hired me and covered my relocation expenses. I'm going to share with you some things I did and still doing, this is not guaranteed to give you the job you want, but certainly will help you increase your chances.

Set up a decent LinkedIn profile

No joke, this helps, a lot of recruiters and companies in LinkedIn, don't underestimate that tool, it's really powerful and you don't need to pay for the pro or premium version to get something out of it. A good LinkedIn profile includes a picture, a description of each job you had, and by description I mean responsibilities and key achievements and responsibilities in that position.

Have a public GitHub account

And actually use it!, I'm not telling you to contribute to a lot of open source projects or to start yet another social auth library or JS framework, just experiment with new tools, build some cool hello-world style projects and upload the code to GitHub, this will show that you're actively learning new stuff all the time.

Have a StackOverflow account

And, again, use it, answer some questions and ask some questions, it's useful and it will help you, trust me.

Be passionate

Love your career, you studied it for a reason. Learn new stuff, experiment with a new language or framework, show everybody the cool stuff you're working on, get ideas from other people and learn from them.

Be pragmatic

Yes, when it comes to work, you have to let your knowledge and logic guide your decisions, not your emotions.

Choose your weapon

And do it early, it's good to be versatile, you're a programmer, not a user of a programming language. But you need a battle ax, the one that helps you solve any problem faster and you feel more comfortable with.

And finally, the one I consider the most important.

Choose your first job carefully

Yes, I mean it, don't let the job choose you, you have to enjoy your job because it's where you will spend most of the day and, trust me, your first job will define your career. If you start developing J2EE applications, people will hire you to do so, because that's the experience you have. Don't be afraid to say no to an offer you're not totally convinced of taking.

In my case, when I was looking for an internship, I turned down an offer from Microsoft in Venezuela because I've always been an Open Source enthusiast and a Linux user, I didn't really saw myself programming in ASP.NET, I decided to take an offer from Vauxoo, a local small company that developed open source modules for OpenERP (now Odoo) and I'm very happy I took that road, I learned Python in that job, which is my battle ax and my main tool by today.

So... yeah!, not a recipe, but some tips I hope will help you on your first years as a professional.

Choosing which languages to learn

Israel Fermín M. — Wed, 13 Jan 2021 14:48:28 +0000

There are millions of articles and blog posts out there trying to tell you what to learn next or which language or technologies are worth your attention, things like Top 10 programming languages or Learn one of these languages and you'll be done with some statistics about language popularity but the truth is, none of those make sense. No one can tell you what to learn and you don't need to study whatever is popular out there all the time.

The truth is, while popular languages are widely used, also, supply is high, hence, salaries will tend to be lower, on the other hand, if you learn the not-so-popular ones, salaries would be higher but you'll end up most likely having a hard time finding a job.

Trends come and go

Whatever is popular today, might be considered terrible in the future as well as what's not so popular today, might be widely used in future, you just have to see the growth trends in whatever languages or technologies you're into.

Few years back, for example, JavaScript was used only for frontend development and JQuery was the best thing out there for it, now almost no one uses JQuery directly, everyone is using react, angular or vue and now you can even find JavaScript on the backend (not that that's a good thing IMO...).

The point is, we should not chase the top 10 most popular technologies, we should try to find a balance, otherwise we won't really fully learn nor master anything.

My view

I think that, the first thing we need to do is, work on what's paying your bills. Few years back, for example, Python was the one paying my bills and it happened to be the first language I worked with after graduating, I became passionate about it,
to the point that I organized meetups and conferences back home in Caracas - Venezuela and after that, I only looked for jobs in Python, it was gaining popularity and growing a lot, I know, I was lucky, but it also makes a point, I was focused on becoming better on a single thing which were the technologies I was working with at that point in time, the full stack was Python, Postgres and OpenERP (now it goes by Odoo).

I think everyone should start by that, just become better and learn more about the stack you're currently working with. My last 100% Python job was at my previous company (dubizzle/OLX), when I joined Careem the stack I worked with changed to Java, Springboot and MySQL mainly, so I started over, learning a new framework and a not-so-new language to me. Then, I switched teams and the stack was Python, Jenkins (groovy) and Terraform, again, learning new things. Then, after almost 2 years, I again switched teams and the stack was Typescript, Express, Node, and both MySQL and Postgres and after few months I was changed to a different team again, the stack also changed and now, this team works on PHP and Go for the most part and MySQL. Whenever your stack at work changes, focus on learning and mastering that.

Once you master whatever is helping you pay your bills, you can use your spare time to learn whatever you want, in my opinion you need to know at least one of those popular languages just to make sure if something unexpected happens
to your current job, you can find a new one quick. In my case, maybe I've been just lucky, I know Python, Java and JavaScript and those are three of the most popular languages out there today. But I also know their popularity won't last forever and that some less popular languages might pay better salaries because supply is less and the skills are more rare.

Everyone is free to learn whatever they want, but this is how I think about it:

Start by what pays your bills: this is important, you need to be efficient at your work and the only way to achieve it is by learning how to use your tools effectively. This will help you do more in less time.
One popular language: well, at least one, if you like more than one, go for it, why learning the popular ones?, this will open the door for more job opportunities, you never know what will happen and it's better to be prepared to hunt (or be hunted) for a new role on a different company.
One high level language: the higher level, the best, I'd go for a language with a dynamic but strong type system, why? to build things quick. Usually high level dynamic languages have a huge ecosystem of libraries and frameworks you can leverage your work on and achieve more writing less code.
One lower level language: you never know when you'll need either more speed or write something at system level or even have more control over how the program will manage memory. Truth is, not all use cases are covered by a High Level object oriented language.

It's not too hard to achieve that, you can mix and match languages in all those buckets, for example, in most of the cases what pays your bills will be a popular high level language, that covers the first three, then you'll only need to learn a lower level programming language to be all setup.

Once you cover that, you can explore other paradigms and incorporate more patterns and practices from those paradigms and other languages into your every day programming style, by learning, understanding and practicing is the only way we become better software engineers.

In my case, as I know JavaScript/Typescript, Python and Java because of previous jobs, maybe not all of them at an expert level but at least a general understanding so that I can tackle most of the day-to-day tasks using them. I'm focusing on learning Rust, it's a language which is growing and implements interesting concepts and I've toyed around with Smalltalk and Haskell to see what's there to learn and incorporate new practices into my coding.

What's currently on your learning list? let me know on the comments box.

DEV Community: Israel Fermín M.

7 tips to be a more productive engineer

Have a daily prioritized list

Be intentional with your time

Be defensive with time

Learn your tools

Take breaks

Get the most out of meetings

Start and stop on time

Conclusion

Recommended readings

The best language I've learned to grow in my career

English

Work for a company that puts people first

My first job

Lesson learned

My internship, great! until it wasn't

Lesson learned

Fast forward to my first job in Dubai

The end of the honeymoon

Then I was moved to a different team

Lesson learned

And I joined Careem

Things were different this time

What about the interviews

My take about everything

Choreography and Orchestration in Microservices Architecture

Internal REST services, why not?

Increases overall response time

What if someone is down?

When should I go synchronous?

Choreography vs Orchestration

Rely on data, not services

Eventual consistency

Conclusion

Recommended readings

Internal Open Source

The cathedral and the bazaar

Key points

My own views

On-boarding new team members

Empower other teams to contribute

Guiding principles to build scalable microservices architectures

APIs should be business bounded

Services must be independent units

Rely on data, not services

High cohesion, low coupling

Coupling

Cohesion

What does this mean in microservices?

One hit, one transaction

Choreography over orchestration

Don't rely on HTTP

A note about the fallacies

Recommended readings

Scaling django: measuring your django app's performance

The tools

django debug toolbar

vprof

CProfile

StatsD

Use the logging subsystem

newrelic

Final words

Scaling django: basic concepts

Basic concepts

Scalability

Performance

Pareto principle

Takeaways

Resources:

Quick and easy user registration with django

Common approaches

User registration flows with django-registration

Installing django-registration

Registration workflows

One step user registration flow

HMAC-based user registration flow

Model-based user registration flow

Setting up django-registration