Forem: Leo Melo

Lessons learned from messaging strangers on the internet

Leo Melo — Mon, 07 Aug 2023 15:17:07 +0000

This post is based on a talk I gave at the Geek Sessions meet-up in Faro, Portugal 🇵🇹 on the 28th of June, 2023. The full title for this talk was "Lessons learned from messaging strangers on the internet in a language I did not speak" and the idea here is to draw some parallels between the idea of learning new (spoken) languages and learning new skills in technology.

Back in June 2020 I was very bored and in lockdown, like most folks, and decided that I needed to learn something in order to keep sane. Being the language nerd that I am I decided I was going to learn Spanish.

Since I couldn't just learn the basics and then take a two week holiday somewhere in Spain to practice I needed to decide how I was going to approach it before I could get started.

The Plan

As I am a native speaker of Brazilian Portuguese I thought this was going to be a quick and easy exercise. Just how I thought the pandemic and the lockdowns would be over before the end of summer or by halloween. Boy was I wrong...

So my idea was simple:

I'd exchange at least 50 messages a day with a number of people using language learning chatting apps
Watch videos in Spanish with Spanish subtitles. Money Heist taught a great Italian song (and some Spanish too!)
Start listening to music, and later podcasts, in Spanish

Armed with a sound plan and a fool's confidence, I set my target language to Spanish in HelloTalk and got to work!

How did it go?

As it turns out, knowing Portuguese didn't help nearly as much as I thought it would. Brazilian Portuguese has a much simpler grammatical structure, which meant that whilst I could read messages and take a second to understand which grammar tense was being used, I couldn't really keep up with people's audio messages or Youtube videos and series.

Added to that, whilst there's an overlap of about 90% of vocabulary between the two languages, this overlap doesn't help as much as you'd think. Some words have slightly different meanings, have fallen out of fashion in one language or the other, or just sound straight up embarrassing and you didn't even know it.

I was always looking words up on either SpanishDict or using Google Translate, DeepL and the apps' builtin translation tools.

After about 6 months I was already better at writing and didn't need to rely so much on SpanishDict for verb conjugations of regular verbs and the most common irregulars like ser, estar, ver and a few others.

At about the 9 to 12-month mark I started being able to speak a few sentences without having to write them down first. My accent was horrible but at least I was able to alternate between audio and written messages during my practice.

Then

After about 18 months I started to recall things quicker, expressing myself and having more in-depth conversations with others become much easier. I no longer needed subtitles and became able to listen to audiobooks and podcasts, some even at 1.5 or 2 times the normal playback speed.

Around this same time I also started to develop a kind of intuition for verb conjugations I didn't know, and was able to use some of the less common verb conjugations in speech without the need to look them up in a dictionary.

Now

About three years into this learning journey my language level has oscillated between a good B2 and an acceptable B1.

I've had the opportunity to travel to Spain a few times and spend time there with friends speaking mostly Spanish for a number of days in a row each time. After being in a Spanish speaking environment for about a day I am very much back at my best.

My accent is still inconsistent, I'll very quickly start mirroring whichever accent is spoken around me and then use expressions and vocabulary that may not be as common or native to where I am, e.g. using Mexican or South American words whilst speaking to a Spanish person.

I don't mind this as much as I used to, I would like to have a more consistent accent but I've come a long way and I feel like I have achieved way more than what I had originally set out to achieve.

Parallels between skilling up in technology and learning a spoken language

Now that I've given some context of my learning journey, let's shift our attention to some of the things I've identified in my process that could also be used to improve our experience when learning new skills in tech.

Learning can be a very personal experience and different people will have different ways in which they prefer to acquire new skills, for the purposes of my talk I chose to focus on a few more general points in order to try and make it as useful and relatable to as many people as possible. These are the five points I want to touch on:

1. Identify your goals

Before you start you should identify your goals, this will help you with checking in on your progress along the way. These are a few of the questions you can ask yourself to try and understand:

What do you want to do with this new skill?
How will you know when you've achieved it?
How strict are you about those answers?
Will there be a next level after you're done with this one?

These questions are not comprehensive but should be a great starting point. I find it specially useful to know how flexible I can be with the goal as I progress and how well documented my goal setting needs to be.

For professional goals we're usually required to have a more detailed description and be more strict with our definition of done. Personal goals can go from a mental note to a full blown schedule, depending on what it is that you're aiming for.

2. Take small steps

Now that you've determined what the end of the journey should look like, let's go back to the start. For almost any skill in technology it pays off to really understand the foundations of what you're learning—you should learn to walk before you try to run.

If you're learning a programming language you should focus on the basics of its syntax and peculiarities first, e.g. understand the basics of Rust's ownership system, or Javascript's asynchronous nature.

It's also a good idea to start with some tutorials or books that will walk you through these basics and then start to experiment with the simpler examples that you see, exploring things in your own way.

If you're trying to learn a new skill that is more role specific, like DevOps, then perhaps you can start with understanding the basics of Docker, Kubernetes and what it takes to deploy a "hello world" style app using such technologies. The main goal at this point is to start small so you can find your pace. Learning shouldn't be overwhelming, nor boring.

After the talk we had a small QA session and one of the questions was about how can we know whether we're doing too much or too little when trying to learn. A good analogy I came up with for the case of spoken languages was: if you're dreaming in your target language, you're good, if you start losing sleep over it then it is too much.

I don't expect anyone to measure their learning effort of Rust or Haskell by how much they dream about these languages but this is still a good analogy in terms of the levels of exposure to the thing you're trying to learn and how much you should make it a part of your daily life.

This takes us to the next point...

3. Practice regularly and immerse yourself in the technology

In order to learn a new skill effectively you need to be able to incorporate as much practice as possible into your daily life. In the case of spoken languages this is obvious and easier to define. You should be listening to music, watching videos in the target language and speaking to natives or fluent speakers of that language as much as possible. For technology things can be a little bit trickier.

It is unlikely that you'll be able to get a job utilising a skill that you've just started to learn when it comes to tech, in order to counter that you'll have to find other ways to immerse yourself into the tech area you're trying to learn.

The most obvious way to get exposure to the thing you're learning is by practising it. Building low stakes projects will be the most effective way to achieve this as you can try different things out without running the risk of having a bigger impact on things around you. Then after that I would recommend listening to podcasts, reading blog posts, books, developer documentation, watching conference talks (online and in-person if possible), joining communities online around the topic that you're trying to learn (more on this later).

These are all great options and you should try and mix and match them as and when you can, so long as you incorporate some kind of daily practice on your routine you will see the value in this effort in no time.

4. Embrace your mistakes

Mistakes are a very natural part of learning. Regardless of whether we're just getting started or have been practising for a little while, it's obvious that we will make many mistakes along the way. You should learn to be comfortable with your mistakes early on, in order to avoid frustrations.

As briefly alluded to in my previous point, having low stakes settings for your practice is one way to help you be more comfortable with making mistakes. Another point that is worth noting is that mistakes can also be used to give us more perspective on what we're learning.

Whenever you make a mistake, be it one that makes it so your code doesn't compile or something that someone else is telling you shouldn't be done in that way you can ask yourself why is it that this is not how it should be:

Did you break a hard rule by making a syntax error or referencing a variable or file that doesn't exist?
Did you not follow best practice and are now running into unexpected behaviour?
Did you rely on a feature of the language you're learning that you didn't fully understand and now don't know why it isn't doing what you hoped it would?

Mistakes in programming and other aspects of technology can come in different shapes and forms but they're a great way to help us understand what it is that we're lacking in terms of knowledge so that we can work to fill that gap.

Another great way to use our mistakes as a positive part of our growth is by having a mentor or community that can help you to keep moving when you're struggling to understand something or to get it to work as intended, this takes us to the last point I want to touch on...

5. The importance of focused communities

There will always be other learning or using the same things you're trying to learn, if you can find a good group of people to learn with or at least exchange some of your experiences the synergy it creates can drastically improve your learning journey. Furthermore, by participating in communities you will likely start to meet people that could eventually help you on a professional level too, or that you may be able to help them.

I strongly recommend trying to find local communities for this as well, for offline meet-ups and events. These will usually have an online side to them but being able to get together and meet people, join hackathons or other events where you also get to do things alongside others can really help the immersion part of learning.

Another, possible less obvious, benefit of being part of more focused communities is that it helps with staying motivated. Very often in our lives things will happen that will force us to set things aside for a short period of time or deprioritise something in favour of a more pressing issue. When this happens, being part of a community and attempting to stay active will serve as a reminder of your learning journey and how you should continue to try and learn as much as your available time allows.

Conclusion

That's it! I understand that this is by far not a comprehensive list but I hope it helps you when you next try to learn something from scratch or even on your current learning journey.

You can find the slides for my original talk in here and the source code for the slides on my Github.

Share in the comments below what sort of techniques or tips you keep coming back to when learning and what you are trying to learn now. Me, I'm currently trying to learn more of the Rust programming language, as it's a compiled, lower level, language and I've never really done anything with compiled languages before.

Taking React and Redux to the next level with Typescript

Leo Melo — Mon, 02 Sep 2019 18:26:32 +0000

Prologue

If you ever used Redux before you know that much of the ways we write Redux logic and why it works relies on us knowing the shape of our state ahead of time. That need is very much inline with how good typescript code forces us to define the shape of our functions and variables before we can build the output JavaScript code.

As I'll be making heavy use of Redux in the near future and I haven't done much with it for some time, I decided to go through Level Up Tutorials' (LUT) React and Redux For Everyone course to refresh my memory on the many concepts around Redux. To add some spice to it, and because I love TS, this time I decided I'd write the tutorial app in Typescript.

This post is a collection of thoughts and highlights of my experience.

Some example code

You can see the code for the course, and each step of my way via git tags, on my github. I've also created a CodeSandbox which contains a minimal setup for react-redux and a connected component using Typescript.

You're free to look through them or use them as inspiration for your own code. I'll mostly use the repo on Github here to illustrate some points.

Defining the global state and root reducer

In my repo I had two reducers being merged by combineReducers, their state is defined as follows:

movies

export interface IReduxMoviesState {
  movies: IMovie[];
  moviesLoaded: boolean;
  moviesLoadedAt?: number;
  movie?: IMovie;
  movieLoaded: boolean;
}

toggle

export interface IReduxMessageState {
  messageVisibility: boolean;
}

With our reducers returning each of these states, we can define the global app state like:

const rootReducer = combineReducers({
  toggle,
  movies
});

export type AppState = ReturnType<typeof rootReducer>;

This makes the AppState look like:

type AppState = {
  toggle: IReduxMessageState;
  movies: IReduxMoviesState;
};

This is great because everywhere our redux state is used, we know exactly what it looks like and what we can reference from it when connecting components.

Defining action creators and action type constants

It's common practice in Redux to have action types being defined as constants. Because we're using Typescript, we can make use of enums and extending interfaces to make our code more descriptive. In my repo I have the following enum for action types:

export enum EReduxActionTypes {
  GET_MOVIE = 'GET_MOVIE',
  GET_MOVIES = 'GET_MOVIES',
  RESET_MOVIE = 'RESET_MOVIE',
  TOGGLE_MESSAGE = 'TOGGLE_MESSAGE'
}

If you're familiar with Typescript you'll see that I made the enums have defined values. This is to avoid the enum keys being assigned numerical values which could possibly make the code less resilient. Either way, this will make defining our action creators a little easier.

I defined the actions basing myself on an interface with a more generic type value, it is pretty bare bones but it allows for great scalability:

export interface IReduxBaseAction {
  type: EReduxActionTypes;
}

For example, in the case of the movies reducer, there are a few different actions that can be dispatched:

export interface IReduxGetMoviesAction extends IReduxBaseAction {
  type: EReduxActionTypes.GET_MOVIES;
  data: IMovie[];
}
export interface IReduxGetMovieAction extends IReduxBaseAction {
  type: EReduxActionTypes.GET_MOVIE;
  data: IMovie;
}

export interface IReduxResetMovieAction extends IReduxBaseAction {
  type: EReduxActionTypes.RESET_MOVIE;
}

As with many things in Typescript, you don't need to know how the values for data are defined, all you need to know in this case is that each action will contain the correct type of object or array for the data property of our action.

By aggregating those types into a union type, I can write my movies reducer like the below:

type TMoviesReducerActions = IReduxGetMoviesAction | IReduxGetMovieAction | IReduxResetMovieAction;

export default function(state: IReduxMoviesState = initialState, action: TMoviesReducerActions) {
  switch (action.type) {
    case EReduxActionTypes.GET_MOVIES:
      return { ...state, movies: action.data, moviesLoaded: true, moviesLoadedAt: Date.now() };
    case EReduxActionTypes.GET_MOVIE:
      return { ...state, movie: action.data, movieLoaded: true };
    case EReduxActionTypes.RESET_MOVIE:
      return { ...state, movie: undefined, movieLoaded: false };
    default:
      return state;
  }
}

This reducer is one of my favourite parts of this TS and Redux implementation.

Because I use different values of EReduxActionTypes for each action. when I get action.data within the different case's, Typescript already knows that data is of the correct type, i.e. Imovie for IReduxGetMovieAction and IMovie[] (an array of movies) for IReduxGetMoviesAction.

This is a VERY POWERFUL THING.

In my tutorial app, the reducers are fairly simple but we can already see that scaling this wouldn't be much of an issue and wouldn't really increase the complexity of our store that much.

This is specially true if we take into account the excellent developer experience that VS Code offers to us for Typescript.

Connecting components and using our store's state

To connect our movies state with a MoviesList component, the code used is as follows:

const mapStateToProps = (state: AppState) => ({
  movies: state.movies.movies,
  isLoaded: state.movies.moviesLoaded,
  moviesLoadedAt: state.movies.moviesLoadedAt
});

const mapDispatchToProps = (dispatch: Dispatch<AnyAction>) =>
  bindActionCreators(
    {
      getMovies
    },
    dispatch
  );

export default connect(
  mapStateToProps,
  mapDispatchToProps
)(MoviesList);

There's quite a bit of code and re-assignment of values in here. Usually this could lead to some confusion as to which props are going to be available to our MoviesList component but Typescript will make sure that doesn't happen by letting us parse the type definitions of mapStateToProps and mapDispatchToProps and use it when creating our component:

class MoviesList extends PureComponent<ReturnType<typeof mapStateToProps> & ReturnType<typeof mapDispatchToProps>, {}> {
  // Code for the component goes here
}

We could even simplify things slightly by creating a MoviesList props type like so:

type TMoviesListProps = ReturnType<typeof mapStateToProps> & ReturnType<typeof mapDispatchToProps>;

class MoviesList extends PureComponent<TMoviesListProps, {}> {
  // Code for the component goes here
}

Now, if we try to reference anything from this.props inside our component, we will have full visibility of all the properties supplied to us by mapStateToProps and mapDispatchToProps.

Conclusion

Even though managing state with Redux and following its standard practices can lead us to spread logic through a number of files and/or add, an arguably large, amount of boilerplate code. By making use of Typescript, we can greatly increase the readability of our code and likely make it easier for anyone that may not be as aware of the ins and outs of a complex application, what each of its parts is responsible for and what they expect to receive from other components.

The tutorial application may not be the most complex one and maybe I didn't make the most elaborate use of Typescript. I still would like to think that it highlights some of Typescript's power and why more and more people are starting to look into it recently.

What do you think about Typescript and how it can change our developer experience when creating and scaling applications? Feel free to comment below or reach out to me on social media, details can be found on my website: leomeloxp.dev.

One last thing. When writing this app I tried to keep the code as close to the original code written in LUT's React and Redux for Everyone course as possible. If you like to learn more about the course or Level Up Tutorials in general feel free to visit their website.

This post was not sponsored by Level Up Tutorials, I just really like their content.

What is JAM Stack

Leo Melo — Sun, 13 May 2018 13:57:01 +0000

This post was based on a talk I gave at a local web development meetup in Jersey 🇯🇪 on May 4th, 2018. Enjoy!

JAM Stack

JAM stands for Javascript, API and Markup, an acronym with a nested acronym. 🤓

jamstack.org defines JAM as modern web development architecture based on client-side JavaScript, reusable APIs, and pre-built Markup.

Defining what JAM means doesn't really gives us enough depth though, is there any secret behind it?

Let's take a look at the file structure for an example JAM website:

As you can see, there's no magic behind it. Just a set of files that we're all used to seeing in the front-end aspects of our projects

Based on that file structure some could even try to argue that Space Jam's website is a JAM site (spoiler: it isn't, it doesn't even use CSS 😂).

What makes JAM so useful for us is on its Javascript and API aspects

Javascript + API =

If we look at one example of a JAM website built using Gatsby JS, Rachio Smart Sprinkler, we can see that for the end user, there are no immediate visual changes, this website is statically built and still offer full ecommerce and checkout journeys, with the help of APIs.

Why should I give myself the trouble?

Even if the end user won't really have any immediate advantages, there are a number of reasons that will encourage you to consider the JAM approach on your next project. Let's visit some of them:

Load speeds

No database querying: As your website's markup is built on build time, there is no database queries being done at every page request. This saves both on server load as well as overall response times.

No template parsing: Depending on your stack, chances are you have a template file in your code base that gets parsed and is used to build the HTML that gets sent back to the browser on every page request. With a static site that wouldn't happen, meaning you can also save on server loads and response time by taking this aspect out of the request/response flow.

Separation of concerns

Front-end takes care of all presentation

With front-end frameworks increasing in popularity and capabilities, having your website/application's presentation decoupled from any backend framework means you can harness all the power that your front-end stack gives you, and in turn deliver a better experience to your end users.

Centralised/focused UX design

Equally relevant, if you don't need to worry about how the backend of your application handles its data and business logic, you can focus more of your efforts ensuring that your user experience is at the level you want and your end users expect, without have any potential constraints imposed by backend solutions.

Frequency of content update

How often do we really update ALL our pages?

This is a point that is very often overlooked. For a number of our pages, content is rarely ever updated, eg contact pages, terms and conditions, blog posts.

You may update such pages a few times soon after they're published to fix potential typos or inconsistencies but once that period is gone chances are you will never edit that page again so why not have it statically built and save your server the hassle of having to compile this page on every request?

Frequently changing content can use APIs

If you have pages that still need to provide dynamic or time sensitive content, you can use APIs to update that content once the page has loaded and maybe cache that content on the client-side or (less optimal) include that content after the page has loaded.

No need to implement everywhere

There is no need to move your entire application to JAM all at once.

JAM Stack your blog

As mentioned above, certain pages are less likely to change after they've been published so making them static would provide you with increased performance and better experience for end users.

User authenticated areas could remain non-JAM'd

If your application has some sort of authenticated area where things need to be kept dynamic, you can skip that section when JAM'ing your application.

Progressive migration to JAM

The takeaway from this section is that you can slowly migrate your content to a static build, and bring in more API backed dynamic content as you identify the opportunities in your application for a JAM approach.

Tie in with service workers, SPA's and animated page transitions

JAM stack makes it easier for us to include new web workflows onto our applications, such as Service Workers, single page application frameworks and animated transitions between pages.

Offline support

With service workers you can make some or all of your website's content available to users when they're offline. This is a great feature, but specially important if your core market involves tourists or users with less than optimal internet connections.

Push update to service workers on build time

As I said earlier some pages would rarely change their content after being published, but when they do, you can use service workers to revalidate your content based on your needs. This will ensure your end users always have the most relevant content on their devices.

Page transitions make UX sleek (like on native apps)

This may not seem like a key feature of static and JAM based sites, but if you take a moment to think about how nice some native apps transitions between their different areas, it is really exciting to think that we can do the same on a web based application. See Sarah Drasner's page transitions example if you need some inspiration.

Caching

Lastly, caching a statically built site is even more efficient than a dynamic one as you can cache all aspects of your site and depending on your content type your cache can be set to extremely long expiry dates.

For any portions of your site that need to be dynamic, you can use the Javascript and APIs aspect of JAM to pull in content after the page has loaded.

Caveats

As with most things in our area, there can also be trade-offs or at least things that you should keep in mind when crafting your JAM based application. I already touched on these above but for the purpose of having all of these under one section, a few caveats to consider when building JAM apps are:

E-commerce and extremely time sensitive content

If your content is extremely time sensitive and relies heavily on a backend solution, JAM may not be the best option. One way to circumvent this would be to use APIs to update the content on the front-end, but this may not be possible all the time.

Must implement SSR

There are many reasons behind this, but it's always recommended that you implement some sort of server side rendering logic at least at build time, for your content.

Ensure no JS support if relevant and SEO best practices

I know this may sound a bit dated, but implementing no JS support can be very relevant depending on your target audience or the percentage of users you want to deliver your application to. It's worth mentioning that no JS support could be slightly limited when compared to the full application, but it's important to give no JS users at least some sort of consistent experience.

Depending on the type of website or application you will also want to ensure that you're covering your grounds in terms of SEO. Having a great website could mean nothing if no one can find out about it.

Authenticated areas of your app

Authenticated areas of your site may not always be compatible with the JAM approach. Again, APIs can help you here, but it's up to you to make that call for each individual case.

A few suggestions on this would be to SSR the chrome of your site, and maybe add some placeholder markup to indicate that the user specific content is still being fetched with AJAX/APIs.

How can I join the JAM Stack hype train?

Now that you have seen some pros and cons of JAM, you may want to try it out for yourself. There are plenty of ways you can build a JAM based website and most of these have some sort of static site feeling to them.

I compiled a list with some options you could try, but this is by no means a comprehensive list, just things that I came across or used myself in the past.

React JS

React is probably the most widely used front-end framework these days and if you know React you probably know all these options. Either way, these are a few tools that you can use to build a JAM stack:

create-react-app: Great zero config React application scaffolder with the possibility to eject your app once more custom features are needed.
GatsbyJS: A static site generator for React with a built in GraphQL data layer and the ability to built static HTML from your React components on build time.
Next.js: A framework for server-rendered React applications with support for static sites.

Vue.js

Vue is also a front-end framework that has been increasing in popularity and adoption very quickly. If you're using Vue, these are a few of the tools you can use to build JAM apps:

Nuxt: Universal Vue JS application framework, often said to be the Vue equivalent of Next.js,
VuePress: Static site generator for Vue.
eagle.js: A hackable slideshow framework built with Vue.js (used to create my talk's slides 🤓).

Other options

Jekyll: Ruby based static site generator, widely used for GitHub Pages.
Hugo: Go lang based static site generator.
StaticGen: StaticGen offers a list of static site generators that you can sort and filter based on your preference or needs.
Build your own: NIH syndrome aside, if you have a very specific set of features that you require, you can always build your own static markup and integrate it with your APIs in a way that suits your business and needs.

JAM friendly backend solutions?

One other important aspect of JAM stack is ensuring that your backend solutions integrate well with front-end frameworks and provide APIs that you can harness from the front-end/client-side of your application. A few examples of frameworks and services that can help you with that are:

Headless WordPress: Using WordPress as your CMS doesn't necessarily mean you need to use it to generate your website's markup directly. API-first/Headless WordPress is something that is increasing in popularity and plugins and libraries to help you get started are out there.
Netlify CMS: A file based CMS that can plugin in directly into your version control and build workflow.
Prerender : SEO friendly plugin to your application that ensures your website can be crawled correctly by search engines
Your current framework of choice: This may not be as obvious for all CMS/frameworks but chances are you can already build a JAM website and integrate with your current backend solution, possibly by using REST and/or GraphQL.

Conclusion

Thanks for reading my post. JAM stack is awesome and I believe it's the most efficient way forward for us. When you get to your next project, consider giving JAM stack a try, or maybe consider rebuilding portions of your current set up using JAM, you won't be disappointed. 😉

There are probably tons of things that I didn't talk about (and consequentially are not part of this post), feel free to mention things I may have missed in the comments.

Some inspiration for my talk was taken from another dev.to post on JAM Stack and I recommend you check it out:

What is JAMstack and why you should try it

Gift Egwuenu ・ Apr 16 '18

#jamstack #staticsites #netlify

The slides for my talk can be seen here, you can also check out the Github repo with the slides' code. Cheers 🤓

Hi, I'm Leo Melo

Leo Melo — Sun, 02 Apr 2017 09:59:36 +0000

Hi ðŸ¤“

I have been coding for over 5 years, mostly web development involving PHP and many aspects of front and backend JavaScript, my favourites probably being: React (Native and Web), Node and three.js. I also really enjoy tinkering with Linux based systems, be it servers or user focused.

On my free time, apart from more coding I also enjoy gaming, specially JRPGs and Rhythm games and music, from RHCP to Math Rock and a lot of things in between.

You can find me on:

See ya o/