Forem: Núria

Fighting impostor syndrome in four easy steps

Núria — Mon, 13 Jul 2020 08:16:37 +0000

If you are anything like me, you have experienced impostor syndrome at some point in your life. If you are really like me, you have to deal with it pretty often. And we both know that sucks. So, for this week's lunch talks, let's try and get rid of it once and for all! *

* Ok, let's be honest. It probably won't work 100%. But if we can reduce it a teeny-weeny bit, we'll have succeeded 🙌

What makes a developer? | Ivana McConnell (29:33 min)

First, repeat with me: "I am a developer". No matter where your background is, no matter what languages you know. Ivana McConnell insists on that, and puts focus on consciously pull away from perceptions that devaluate certain languages or paths into development. It's not you, it's them. You are a developer.

Attitude Determines Altitude: Engineering Yourself & Your Teams | Randy Shoup (43:02 min)

Ok, you now believe you are a developer. Great! But, I know, it's not easy to keep the confidence up. Randy Shoup focuses on the psychological aspects of how our mind works and talks about getting into a growth mindset and gaining trust and confidence.

Mejorando como desarrolladores | Belén Albeza (42:24 min)

Hopefully confidence is building up on you, and you want to keep improving as a developer. But, what to learn next? Many new shiny things come up every day, and it's hard to know what to focus on. Belén Albeza gives us concrete advice (in Spanish) on what to do to keep learning effectively, and how we can make our teammates better as well.

Why you should make useless things | Simone Giertz (11:58 min)

Yay! You are a confident developer and you know how to keep improving. What's next? It's likely your career will be bumpy, and you will fail a lot, but that's ok because you will succeed on other things too. You don't need to build a rocket and save the human race by terraforming Mars to be a great developer. Simone Giertz talks about the importance of making useless things, how it will relieve you from pressure and how it can lead to unexpectedly awesome results. Plus, she is wearing a googly eyes t-shirt.

Stop (ab)using z-index

Núria — Thu, 25 Jun 2020 09:00:00 +0000

z-index: 2147483647

I once saw this in a codebase. The number seemed so random that I thought it couldn't be that random, so I googled it. Turns out it's the highest value that the z-index property supports!

That developer must have been really desperate, but it's very common to see things like z-index: 9999, and if that doesn't work, let's keep adding 9s until it does. You can guess what happens when you try to position something above that.

There are good solutions like creating a z-index scale, which puts a bit sanity into the z-index nonsense, and we use this solution here at Codegram. But most of the time we don't even use the property at all, and when we use it we only use a couple of values. If you find yourself using more, either you have an extremely complex design that is very different from most sites in the internet (not likely), or you are using it wrong.

How z-index works

When working with CSS, we usually deal with two dimensions. However, when elements overlap and we need to adjust their order, we have to deal with a third dimension, the Z axis that the property z-index controls.

Positioning and order

Let's go over the basics: the z-index is a property related to positioning. By default, all elements have a static position. In order for z-index to have any effect at all, it needs to be applied to a positioned element, that means, an element with position relative, absolute, fixed, or sticky.

If you don't apply a z-index, the elements will be stacked in the order they are written in the HTML. Check this example:

The text is not positioned, so it's behind everything. The other elements stack above each other in the order they are written in the HTML.

If we want this to match the design, we could add a z-index: 1 to the illustration, and position: relative and z-index: 2 to the .hero__title element. It's a good idea to always start with the lowest z-index value you can, to keep things simple.

But when working with CSS, it's always best if we can rely on the natural order of the elements and avoid altering the flow ourselves, to keep our code simple and scalable. As long as it makes sense, we could adjust the order of the items in the HTML, placing the text as the last element, and by applying position: relative to it, it wouldn't be necessary to use z-index at all:

Of course, this approach has certain limitations, sometimes it is not possible to change the HTML, and changing the order arbitrarily should only be done to elements that don't have meaning, so we don't alter the experience of users who use screen-readers.

You can read more about stacking without the z-index property at the MDN web docs.

Stacking contexts

Following the previous example, let's imagine that it's part of an external library and we do not have control over the code, we cannot alter its HTML or CSS and, to make things worse, the .hero__title element has a z-index: 9999. Now, let's say we need to add a modal to the same page. Which z-index value do you think the modal should have?

Your first reaction might be: oh dear, I should increase that modal z-index to 99999, otherwise it will fall below the title, and here they come, the bad practises we wanted to avoid in the first place. But we can avoid this: z-index only competes with sibling elements within the same stacking context.

Even if the .hero__title has a z-index: 9999, we can place it inside a container with position: relative and z-index: 1, creating a new stacking context. Each stacking context is completely independent of its siblings: the descendants from each context will not interfere with elements outside. This way, we can position the modal above the hero just by adding a z-index: 1.

Take-aways

To sum up, always keep in mind these tips when positioning elements:

Understand how stacking works, and use the rules to your advantage to avoid using z-index, as long as it makes sense.
Keep z-index values low: you'll rarely need more than z-index: 1 (or less than z-index: -1)
Create stacking contexts to keep things boxed and prevent them from interfering with each other.

JamstackConf: A virtual conference experience

Núria — Mon, 08 Jun 2020 08:03:00 +0000

Last week, Anna, Aitor and I got the chance to attend the Jamstack Conf. It was originally planned to happen in London, and at the beginning of the year we had planned to attend other conferences, like NordicJS and JS Heroes. Due to the COVID-19 situation, those were cancelled, and we were sad at the prospect of not attending any conference this year.

Luckily for us, the Jamstack Conf organizers decided not only to go forward with the conference, moving it to a virtual setting, but they also made it free for everyone! So we took the chance to experience a virtual conference for the first time.

I must admit, I was not thrilled by the idea. For me, a conference is much more than the talks. I'd even say that the talks are the least important thing, as they are usually recorded and made public. What I enjoy the most is the opportunity to bond with my colleagues, meet new people, and of course, get free stickers. So, how does a remote conference compare to the real-life experience? Let's see!

The talks

For some reason, I find it very hard to focus when watching a video. I guess I'm one of those old people who prefers reading to following a video course. Because I know how my mind works, I took extra preparation to be able to follow this conference as closely as I would have if I had attended physically. I marked the day as busy in my calendar, and did not plan to do any work (I consider attending conferences and learning part of my work, but you know what I mean). I turned off my notifications, put the video on full screen, moved away from the keyboard and took notes in a real notebook. From time to time I checked Slack to chat about the conference with my colleagues (that is also part of attending a conference right?), but other than that I tried to stay away from the keyboard as much as possible. It helped, although it was still harder for me to focus than in a real-life conference, I think it went pretty well. By no means would I have been able to follow if I just had the talks on my other screen while doing client-related work.

But enough about me, let's talk about the talks! They were all pre-recorded, which at first I thought this was a bit strange, but quickly saw the value: more relaxed speakers, no demo effect, and the speaker was available on the chat to answer questions while the talk was playing. I found the chat to be very chaotic (there were like 6000 people in the room so you can imagine), and maybe it would have benefited from a bit more moderation — not because of any Code of Conduct violation, but simply noise. Still, it's an interesting tool. To be noted, in-between the talks they had live Q&A sessions which worked great.

In terms of content, I especially enjoyed Christian Nwamba's talk about Jamstack for Emerging Markets, and Erin Kissane's about The COVID Tracking Project. It's refreshing to see a technology we love be put to use to make a positive impact on people's lives, and talk about performance in those terms instead of just being about more visits and making more money.

There were many other interesting talks, and they are already online so make sure to check them out!

The hallway experience

I was really amazed by the tool the conference used, Hopin. They really put an effort into making the virtual conference experience as close to reality as possible, and I'm sure it will be a killer app in the conference space.

As I said previously, it has a chat and there were live Q&A sessions, but that's not all. Sponsor booths were also virtual rooms with a live video feed. I think this suffered in comparison to the real-life experience, as usually when you approach a sponsor booth they always come to you and start talking about their product (which can be a bit annoying, but you are able to fully understand what they do). In these virtual booths, since you might join at any point, it's hard to follow the conversation if you don't know about the product beforehand, and I didn't find it very engaging.

To complete the hallway experience of a conference, one cannot forget the most important part. Networking! I'm a shy person, but I like to meet new people (yes, it's not as contradictory as it sounds). I often find it hard to talk to other attendees in real-life conferences, especially when groups start forming in the hallway and you are there all alone holding your cup of coffee as your only friend. Hopin offers the perfect tool for people like me. There is this chatroulette-like feature where they pair you up with a random attendee and you have a video chat for 5 minutes. No more standing alone trying to find the right angle to approach a group, all you need to do is click a button! Plus, being time-framed, you don't reach that awkward point where the conversation is over and you don't know how to say goodbye. I probably spoke to more people in this conference than any other before.

It's clear that they made an extra effort to match the experience of a real-life conference, so much that they might have missed opportunities to improve on it. For example, to visit the sponsors booths you need to leave the main stage video, which of course makes sense when you cannot be in two places at once in real-life, but in a virtual setting it would be cool to minimize and mute a video so you can check something else, but without losing all context. It would also be cool to have a log of the people you've interacted with, in case you want to connect with them later. Still, for being a platform in early access, it has offered a great experience!

Are virtual conferences here to stay?

I must say, I still prefer the real-life experience in many ways, especially for team-building. But, while I thought that virtual conferences (for me) were just a temporary thing while we are dealing with the COVID-19 situation, I'm now sure that I will be attending more of them. We need to keep in mind that virtual conferences are more accessible to everyone (or should be — Hopin doesn't support captions at the moment), and also more environmentally friendly, something that is essential to fight climate change (we talked about that in the first issue of our newsletter). Having more virtual conferences is in everyone's best interest, so if you were skeptical like me, I really recommend you try it!

Oh, and the stickers? RedwoodJS mentioned that they would email them to any attendee that wanted them. Here we go, the conference experience is complete.

Kill the back-end: Bring user-generated content to Jamstack with GitHub Actions

Núria — Tue, 12 May 2020 12:09:00 +0000

Static sites have been making a comeback these last few years. Deploying to a CDN is easy and cheap (or even free!), and nothing beats a static site with SEO, security, performance, and scalability. Of course, dealing with a lot of static pages used to be a nightmare, but not after the Jamstack approach arrived. It's not about specific languages or frameworks, according to Mathias Biilmann (CEO & Co-founder of Netlify), it's "a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup". Using a static site generator like Gridsome or Gatsby, we can statically generate sites with lots of content, like a blog, and deploy them in a matter of minutes. You can read more about Jamstack it in this excellent post by Josep Jaume.

Here at Codegram we love the Jamstack, but we are aware that it comes with its limitations. One of them is that you need to be in control of the content. In the case of the blog, a common scenario is committing the content in your repository as markdown or JSON files. This is the approach we follow for this very same site where you are reading this. After all, most of the team is familiar enough with technology to write a markdown file, commit and create a pull request on GitHub.

But when working with clients, we often find that the people writing the content is not very technical and they prefer to work with a UI. In these cases, like Davis Cup Finals website, we usually rely on a headless CMS service like Prismic or Contentful.

If you need more flexibility and features than these services provide, like letting users submit their own content and publishing it, you can always write your own backend, if you have the time, knowledge and budget. But wouldn't it be nice to keep things simple and avoid having to worry about servers?

Imagine we are organizing a conference and want to have call for papers. We want users to be able to fill a form with their proposal, and then we as organizers review the proposals and display the accepted ones on the website. Maybe even list the ones that are pending review, if we want to keep the process really open. But how on earth are we going to handle user submissions without a server or a database!? Well, you can check the final site, and read on to know more about how it works… 🍿

GitHub Actions

Let's take a small break and introduce GitHub Actions. You have probably heard about them already, but if not, they are simply a way to automate software workflows. Think CircleCI or Travis but completely integrated with GitHub. Running tests and linting when a PR is opened, and building and deploying when pushing to master are the most typical flows that will probably come to mind, but you can run any piece of code you want, and there are many ways to trigger a workflow. We have this repository of useful workflows if you want to take a look.

As you can imagine, the ability to run any script opens a new world of possibilities for Jamstack sites. So in this post we'll see how we can turn GitHub into our own Content Management System that will receive user submissions from the client-side application, validate them and publish them, all without any backend server involved! 🤯

Jamstack with user-generated content

So let's get on it and build our CFP application. We will be using Gridsome because we love Vue, and we will be deploying to Netlify. Users will be presented with a form to submit their talk. On submit, we trigger a GitHub workflow that generates a pull request that adds a JSON file to the repository. Once this PR is merged, Gridsome generates the site statically listing all the accepted submissions, and it gets deployed to Netlify. The result is a 100% static site that is able to handle user-generated content! Feel free to check out the repository, but if you want to understand how it works, let's review the submission process in a bit more detail:

Trigger a workflow from your client-side app

So a user visits our client-side application and wants to submit a talk. To make it easier to set up and play with, we will not be adding any authentication method, but you could connect the app with a GitHub OAuth app or similar to prevent abuse. So for now, the users will just fill in the details and submit the form. We want this form to open a pull request in the repository with the talk information. As we've seen before, we can use GitHub Actions to create a PR. But how can a form trigger a GitHub Actions workflow? There's a way to trigger a workflow externally, using the repository_dispatch event.

function submit(data) {
  const owner = "codegram";
  const name = "jamstack-cfp";

  return axios.request({
    url: `https://api.github.com/repos/${owner}/${name}/dispatches`,
    method: "post",
    headers: {
      Accept: "application/vnd.github.everest-preview+json",
      Authorization: `token ${process.env.GH_TOKEN_PERSONAL}`,
    },
    data: {
      event_type: "handle-submission",
      client_payload: {
        name: data.name,
        title: data.title,
        description: data.description,
        date: new Date().getTime(),
      },
    },
  });
}

Ok, I must admit, I lied. This process should not be done completely from the client-side. To trigger a repository_dispatch event you need to use a token with repo scope of a user that has write access to the GitHub repository (you can generate the token in your GitHub settings). Doing this on the client-side means that everyone could see the token, and that's no good! We will be handling this bit of logic in a serverless function. Luckily, with Netlify functions writing and deploying a serverless function is super easy. You can check the full function code in the repository.

Create a pull request

When the form is submitted and the Netlify function has done its job, the workflow is triggered on our jamstack-cfp repo. This workflow creates a JSON file with the talk details, then opens a new pull request to add this new file to the repository:

name: "Handle Submission"
on:
  repository_dispatch:
    types: handle-submission

jobs:
  create-pr:
    name: Create PR
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Use Node.js ${{ env.NODE_VERSION }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ env.NODE_VERSION }}
      - name: Create json file
        run: |
          node actions/process-input.js
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v2
        with:
          token: ${{ secrets.GH_TOKEN_PERSONAL }}
          branch-suffix: random
          title: "feat(submission): ${{ github.event.client_payload.name }} - ${{ github.event.client_payload.title }}"
          body: |
            # ${{ github.event.client_payload.title }}
            ## by ${{ github.event.client_payload.name }}
            > ${{ github.event.client_payload.description }}
          labels: submission

As we said before, when running GitHub Actions we can run any bit of arbitrary code, and that's what we are doing on the Process input step, adding the logic to create the JSON file with the payload we received from the repository_dispatch event:

const fs = require("fs");

const { client_payload } = require(process.env.GITHUB_EVENT_PATH);

fs.writeFileSync(
  `submissions/${client_payload.name}-${client_payload.title}.json`,
  JSON.stringify(client_payload)
);

With this, we have the main functionality of our app ready! You can try and see this in action by submitting the form and then checking the running workflows. Once the workflow finishes, you will be able to see the open PR with your submission. Once PRs are merged, the application will list them in the accepted submissions section.

On next posts we will be seeing how to list the pending submissions by integrating the GitHub GraphQL API to Gridsome, and how to add another GitHub workflow that automatically validates and merges or closes the PRs. There's still a lot of potential to take this further!

Have we really killed the back-end?

Obviously, this approach has some limitations, so all back-end devs out there, don't worry, you still get to keep your jobs! So, when to use this approach? The submission process can take a few minutes, so if you need immediate feedback it's probably not a good option. Same if the amount of submissions you need to handle in a short period is very high. There's also a privacy issue: if your repository is public you shouldn't store any sensitive data (I'm not sure if storing it in a private repository has any legal issues). As a rule of thumb, this is a good use-case for a proof of concept, MVP, or small application. We've successfully used this approach in production, reaching around 700 submissions, and we were very happy with the result!

If I've convinced you of giving it a try, fork the repo, and let us know your experience! You can reach us on Twitter, we will be very glad to hear it!

Cover photo by Etienne Boulanger

Promisifying Phaser

Núria — Sat, 09 May 2020 10:58:41 +0000

Working on web development, promises are a basic tool I use every day, and I feel that the old days when everybody used callbacks are long gone. Except when I'm working with Phaser!

For example, at the start of the game, I want to move the camera around so the player gets a sense of their surroundings, and then start playing the game. Phaser cameras have a pan method to do that, and this method receives a callback which is called on every update. In order to wait and call another method once the effect has finished, you need to check if the progress has reached 1:

create() {
  this.cameras.main.pan(
    this.survivor.x,
    this.survivor.y,
    4000,
    'Linear',
    false,
    (_, progress) => {
      if (progress === 1) {
        this.cameras.main.startFollow(this.survivor)
        this.play()
      }
    }
  )
}

This approach might be useful if I want to do something while the pan is running, but most of the time I want to wait until it's done, and it's a bit tedious to keep writing the callback, not to mention if you want to chain multiple effects: you easily run into callback hell.

So, I decided to turn this kind of Phaser methods into promises:

cameraPan(x: number, y: number, time = 1000) {
  return new Promise((resolve) => {
    this.cameras.main.pan(x, y, time, 'Linear', false, (_, progress) => {
      if (progress === 1) {
        resolve()
      }
    })
  })
}

This way, thanks to async/await, the previous code looks much simpler and easier to understand:

async create() {
  await this.cameraPan(this.survivor.x, this.survivor.y, 4000)
  this.cameras.main.startFollow(this.survivor)
  this.start()
}

The improvement is even more obvious when you are using several camera effects, tweens, and other methods that would require callbacks. Imagine how this code would look without await:

async endScene() {
  this.cameras.main.stopFollow()
  await this.cameraFade('fadeIn')
  await this.cameraPan(0, 0, 4000)
  await this.createDialog("How strange to see northern lights so far down south.")
  await this.cameraPan(this.survivor.x, this.survivor.y, 4000)
  await this.cameraFade('fadeOut', 2000)
}

You can still use the original Phaser method at certain points when you need more control over the progress, but I've found this is a quick and easy way to make your Phaser games a bit more readable. Hope it helped!

Using BEM in components

Núria — Wed, 29 Apr 2020 13:49:00 +0000

Front-end development has changed a lot in the last 10 years. The most common scenario back then was to have all your site CSS in global styles. On a big site, the number of CSS classes could become unmanageable: it was hard to keep them ordered, you run into class name collision easily, and using !important as a quick fix (that stayed in your codebase forever) was quite common. BEM and similar methodologies (OOCSS, SMACSS, Atomic CSS…) were created to help mitigate those issues. And it worked, if you applied them well.

In case you haven't heard about it, I recommend checking out the documentation. To sum up, BEM is a naming convention for your classes, it stands for Block Element Modifier, and it looks like this:

/* Block */
.card { }

/* Elements */
.card__header { }
.card__button { }

/* Modifiers */
.card__button--disabled { }

Having a strict convention to write class names makes the front-end code more explicit and easier to work with. It also avoids class name collisions, making the code more robust and improving scalability. But of course, using BEM has its drawbacks: class names tend to be very long, which makes your HTML harder to read. For a long time the pros outweighed the cons, but is it still true?

Using BEM today

Nowadays, when styling web components, we can make use of Shadow DOM to make the styles encapsulated in that component, preventing them from affecting outer elements. Similar approaches exist in Angular, Vue or React, either using Shadow DOM as well or appending unique attributes to the class names, to ensure that the styles are scoped to that component.

Since class collision between components is not a problem anymore, a lot of devs consider now BEM obsolete. But I believe that BEM offers more than that, and at Codegram we still use it in our projects.

A component is not a Block

If you check the first sentence in the official site, it says "BEM — Block Element Modifier is a methodology that helps you to create reusable components". But now we already have the reusable component part solved! Imagine a Product component. With the traditional approach, we would think of the product as the Block, and end up with classes like this:

.product {}
.product__header {}
.product__header-title {}
.product__header-subtitle {}
.product__image {}
.product__image-description {}

It's not bad, but is it really necessary to specify in each class that it applies to product? We are already in the product component, and styles will not be applied anywhere else. If a component doesn't necessarily translate to a single Block element, we can use several Blocks inside a single component. We do not need to worry about class collision, so we can keep class names short but meaningful:

.product {}
.header {}
.header__title {}
.header__subtitle {}
.image {}
.image__description {}

Now the responsibility of each class is much clearer just by looking at it, it's easier to split the component later if needed, and overall it's much easier to read.

A convention

You might think that, based on the previous example, you could just skip BEM altogether, and classes would still be short, meaningful and manageable. And you would be right. But still, I find BEM is useful in providing a convention for our class names. In JavaScript (or any language of your choice), it's common to have a convention for the names of the variables. It does not matter which convention you choose, as long as the team agrees on following it. So why should CSS be any different? It's still a language, it's a crucial part of frontend development, and if we forget to apply best practices to it, that's when it becomes cumbersome to work with. Just because the styles don't leak out to all your site anymore, it doesn't mean you should hide all the mess inside your components. So use BEM, or skip it, but make it a conscious decision and put effort and thought when writing CSS.

Cover image by Caleb Angel

Phaser: Loading assets in a saner way

Núria — Sun, 19 Apr 2020 08:46:35 +0000

It's been some time since I talked about the code of the game, so I thought I'd share some of the changes I've made to make my life easier, in the shape of short posts. Today's turn is…

Loading Assets

As you may know, to add an asset to a Phaser scene, you need to call a load function with a key and the asset path as parameters. If the asset is a sprite, you also need to pass the frame width and height.

this.load.spritesheet('enemy', `/images/enemy.png`, {
  frameWidth: 50,
  frameHeight: 160
})

As you can imagine, when you have a lot of sprites, the preloading of all the assets becomes very verbose, and if you use the same sprite in different scenes, having the width and height hardcoded is tiresome and a potential source of bugs (if you change the size of the sprite, it's likely you forget to update it everywhere).

So the first step to improve this is to move all this hardcoded data to a constants.ts file. We've solved an issue but it's still quite verbose. This is how a scene preload function looked like at a certain point:

public preload() {
  this.load.audio(AUDIO.FIRE.KEY, `/sound/${AUDIO.FIRE.FILE}`)
  this.load.audio(AUDIO.STATIC.KEY, `/sound/${AUDIO.STATIC.FILE}`)
  this.load.audio(AUDIO.DROP.KEY, `/sound/${AUDIO.DROP.FILE}`)
  this.load.audio(AUDIO.BANG.KEY, `/sound/${AUDIO.BANG.FILE}`)
  this.load.image(
    IMAGES.BUILDING_BG.KEY,
    `/images/${IMAGES.BUILDING_BG.FILE}`
  )
  this.load.image(
    IMAGES.BUILDING_BG_2.KEY,
    `/images/${IMAGES.BUILDING_BG_2.FILE}`
  )
  this.load.image(IMAGES.FLOOR.KEY, `/images/${IMAGES.FLOOR.FILE}`)
  this.load.image(IMAGES.LADDER.KEY, `/images/${IMAGES.LADDER.FILE}`)
  this.load.image(IMAGES.BOXES.KEY, `/images/${IMAGES.BOXES.FILE}`)
  this.load.image(IMAGES.BUCKET.KEY, `/images/${IMAGES.BUCKET.FILE}`)
  this.load.image(IMAGES.WOOD.KEY, `/images/${IMAGES.WOOD.FILE}`)
  this.load.image(IMAGES.CLOTH.KEY, `/images/${IMAGES.CLOTH.FILE}`)
  this.load.image(IMAGES.DROP.KEY, `/images/${IMAGES.DROP.FILE}`)
  this.load.image(IMAGES.ROCK.KEY, `/images/${IMAGES.ROCK.FILE}`)
  this.load.image(IMAGES.METALBOX.KEY, `/images/${IMAGES.METALBOX.FILE}`)
  this.load.spritesheet(
    IMAGES.ANTENNA.KEY,
    `/images/${IMAGES.ANTENNA.FILE}`,
    {
      frameWidth: 160,
      frameHeight: 504
    }
  )
  this.load.spritesheet(
    IMAGES.FIREPIT.KEY,
    `/images/${IMAGES.FIREPIT.FILE}`,
    {
      frameWidth: 84,
      frameHeight: 60
    }
  )
}

I have a BaseScene with some common methods that all scenes inherit, to I created a loadAudio, loadImage and loadSprite functions there that receive the sprite constant as a parameter:

public loadSprite(SPRITE: SpriteAsset) {
  this.load.spritesheet(SPRITE.KEY, `/images/${SPRITE.FILE}`, {
    frameWidth: SPRITE.WIDTH,
    frameHeight: SPRITE.HEIGHT
  })
}

So the preload function ended up looking like this. It's actually loading more assets than before, but it's way easier to read:

public preload() {
  // Preload audio
  this.loadAudio(AUDIO.FIRE)
  this.loadAudio(AUDIO.STATIC)
  this.loadAudio(AUDIO.DROP)
  this.loadAudio(AUDIO.BANG)

  // Preload images
  this.loadImage(IMAGES.BUILDING_BG)
  this.loadImage(IMAGES.BUILDING_BG_2)
  this.loadImage(IMAGES.BUILDING_NIGHT_BG)
  this.loadImage(IMAGES.BUILDING_NIGHT_BG_2)
  this.loadImage(IMAGES.FLOOR)
  this.loadImage(IMAGES.WOOD)
  this.loadImage(IMAGES.CLOTH)
  this.loadImage(IMAGES.DROP)
  this.loadImage(IMAGES.ROCK)

  // Preload sprites
  this.loadSprite(SPRITES.METALBOX)
  this.loadSprite(SPRITES.LADDER)
  this.loadSprite(SPRITES.BUCKET)
  this.loadSprite(SPRITES.BOXES)
  this.loadSprite(SPRITES.ANTENNA)
  this.loadSprite(SPRITES.FIREPIT)
  this.loadSprite(SPRITES.BUGGY)
  this.loadSprite(SPRITES.STRANGER)
}

There's still room for improvement, for example I could have all the audio, images and sprites a scene needs in a constant, and load them all in a single call. But for now it's more than enough to make the code a bit more readable!

Visiting Radio Liberty

Núria — Sun, 19 Apr 2020 08:41:56 +0000

Originally published at Medium on Jul 21, 2019

Ok, this post has not much to do with the development of the game but… I visited Radio Liberty! Or what’s left of it, anyway.

It may be a bit sad to have it all just go to waste like that, but for my game it couldn’t be more perfect, it has the exact post apocalyptic vibe I’m looking for. It’s a shame that the game will be quite small and that I’m not a great pixel artist, because those scenarios would shine. Hope you all like the game and some big studio wants to fund me to do a remaster.

This is begging to become a game puzzle

No, the game won’t have any zombies in it but this is priceless

Please note! As a police officer kindly reminded me of, Radio Liberty is still private property so you shouldn’t go there. I won’t do it again, promise.

A DevRel in a digital product agency

Núria — Wed, 08 Apr 2020 17:00:00 +0000

You've probably heard about Developer Relations or Developer Advocacy before. You probably know someone with that job title, or maybe you are one. But, what does a DevRel exactly do? A quick search will give you answers along these lines: "Developer Relations is best defined as building relationships with the developer community" (from Introduction to Developer Relations), or "the interface between 3rd party developers and the engineering and product teams building the underlying platforms" (from The Core Competencies of Developer Relations).

Codegram is a digital product agency, we build products for clients (check out our case studies if you are curious), but rarely for other developers. So, at first glance it doesn't look like the type of company that needs to have a Developer Relations role. But we respectfully disagree!

Give back

We use a lot of open source to make money, so it seems only fair to give back to the community. The most obvious action is contributing to open source, but it's not the only thing. We like to explore new technologies and we learn a lot in each project we make. It's a shame to keep this to ourselves, so sharing knowledge is important for us. We've been doing so in our blog, but also speaking at conferences, organizing Full Stack Fest, the Full Stack Cast, and more to come (stay tuned!).

A shared responsibility

Our industry has issues, and it's everyone's responsibility to solve them. Not only to make the industry a better place for everyone, but also to improve the products we build. Creating accessible websites and apps is very important and often neglected. Respect for the users' privacy is forgotten in favor of getting the maximum profit out of their data. A single developer can only do so much, but companies have a lot of power to change that.

We believe in our values, and we think it would be positive if more companies worked like us. We've worked hard on making our team more diverse, and we want to communicate that there is a different way to do things. Not only would this help solve the problems mentioned before, but it's also more profitable for the company: we have a very low employee turnover rate, and in this industry that's very rare.

A DevRel's job

Everyone at Codegram is aligned with these values, but combining our work for client's projects with contributing to open source, writing blog posts, speaking at conferences, etc. is hard, and not everyone's cup of tea. So a DevRel's job is to coordinate these efforts and ensure this keeps happening and we contribute in a meaningful way. And of course, be a public face for the company, so say hi on twitter if you want to chat, you can find me on my personal account, or Codegram's as always 👋

Phaser meets Vue

Núria — Sat, 22 Feb 2020 09:39:04 +0000

Originally published at Medium on Jul 6, 2019

As you may or may not know, before I started working on Radio Liberty I made a couple of videogames using Vue, a JavaScript framework (and talked about that at WTM Barcelona — talk is in spanish). Obviously it has some limitations when it comes to the complex interaction you usually need for a videogame, but, being a framework for web applications, it also makes UI things much more simpler. If you have some CSS knowledge, you will see the pain that it represents aligning something with Phaser, compared to using flexbox, absolute positioning, or even floats.

I started working on an inventory UI for Radio Liberty, sort of a grid to list all the items, possibly with the need to scroll or paginate if you have too many items to fit in the screen.

Obviously I couldn’t stop thinking how much easier would it be for me to do it in CSS. And then I thought… wait, Phaser is JavaScript, it’s running on a website, what’s stopping me from using Vue?

I created a new project with Vue CLI, moved my phaser files into src, copied the old webpack config into vue.config.js (that’s my favourite part about the Vue CLI: no need to eject to provide full webpack configuration!), added an extra div to the index.html file, and that’s it. It was that easy.

Now I can display the inventory easily and I can reuse the water, food and health stats component that I had done for a previous Vue game.

Obviously, the Vue app and the Phaser game need to communicate between them. The player picks up an object on the Phaser game (handled with a collision), the Vue inventory needs to update. If any of the stats reach 0, player must die and Phaser game must respond accordingly. But hey, it’s all JavaScript! They can communicate easily via Events.

Right now there are a bunch of events sent and received through many files, but in the future I’ll probably create a service to manage those, and all (or most) of the game state will be centralized in the Vue store, managed with Vuex.

Here you can check the current status of the game, with stats and inventory: https://www.youtube.com/watch?v=mbqEcUb4k0Y

With the inventoy and the stats solved, I have all the basic pieces to build the game. Now, it’s time to focus on doing a lot of pixel art (oh no), sound, and build the remaining scene to finish Chapter 1!

Phaser: Moving to TypeScript

Núria — Tue, 11 Feb 2020 16:46:47 +0000

Originally published at Medium on Apr 17, 2019

I’m not a fan of TypeScript. Anyone that has worked with me, follows me on Twitter or been near me has probably heard my rants. It’s not that I’m against statically typed languages, but I feel that TypeScript tries to fix something that is not broken. Yes, I strongly believe that JavaScript is not broken. Most people that keep complaining about JavaScript has not taken the time to understand the language.

But yeah, TypeScript. It’s supposed to make your code more robust, avoid bugs, blah blah blah. I’m a bit skeptical about all those blanket statements. And I’m not alone on that, as Eric Elliott mentions on The TypeScript Tax:

“Type safety doesn’t seem to make a big difference. TypeScript proponents frequently talk about the benefits of type safety, but there is little evidence that type safety makes a big difference in production bug density.”

By now you might be thinking “but wait, wasn’t this post titled Moving to Typescript?”. Yeah, despite all this ranting I moved the game code to TypeScript, and I don’t regret it.

The reason I switched to TypeScript, the main benefit I see over JavaScript and the one I see least mentioned when people say nice things about TypeScript, is developer experience.

You see, Phaser 3 doesn’t have the best documentation. It’s quite cumbersome to find something there, and most of the time I find it really hard to see how everything is connected. Plus, Phaser itself does not make things too easy for the developer(like functions with a lot of parameters, instead of using an object with keys which makes the code much clearer).

TypeScript really helps making this way easier and reducing trips to the docs dramatically. I can see what kind of parameter a function expects, in which order, and what is returned. Which are the available properties of a Sprite, or a Scene. It’s true that you can have type checking with JavaScript without actually having to use TypeScript in your files, but if you are doing this I think it’s worth to go all the way and use TypeScript at its fullest.

It’s not all nice and good, the truth is that Phaser and TypeScript don’t work that well together, there is even less documentation, and at the time there are no Phaser types in DefinitelyTyped (so you need to manually add them to your project, and remember to update them if you upgrade the Phaser version). But overall, it’s totally worth it.

Does this mean I want to use TypeScript in all my projects now? Hell no. If you are using a simpler framework with good documentation, I don’t think it adds as much. But for Phaser, TypeScript has saved my sanity.

I haven’t been posting on the development diary lately, but this doesn’t mean I haven’t been working on the game! If you are curious about the progress, that’s how it looks so far:

https://www.youtube.com/watch?v=i5tFT-5p_0U

Graphics and animations are not final, but they give a guideline about how it’s going to look. I’m pretty happy!

Pixel art and the art of doing nothing

Núria — Mon, 10 Feb 2020 16:37:18 +0000

Originally published at Medium on Sep 23, 2018

So, summer has just ended. I’ve hardly felt like staying home and work on the game these past months. I don’t feel too bad, I’m doing this for fun if something else sounds more fun, well, so be it. Also, if I’m being completely honest, I’ve been dreading a bit the next step I had planned: start working on the art. It’s funny, because I actually have a design background, and I’ve always liked to draw.

As I mentioned in previous posts, I had planned for the game to be pixel art, for a few reasons. One, I like it, and two, I thought it would be easier. Right? WRONG. I really haven’t done any pixel art before, unless you count my first game for Ludum Dare. And one would think that pixel art is just any other art, just drawn in a smaller space. Oh boy.

The tools

So, pixel art. It’s just big pixels. You basically only need pen and eraser. Without softening, good old sharp edges. Layers would be a plus. Any program should allow you to do this in a super easy way, right.

I’ve always used Photoshop for graphic editing, but it’s not an option for me anymore, because I really dislike the subscription approach Adobe is using, and I don’t want to download it illegally when there are so many alternatives. I’m just going to skip the rant about Gimp and the sad times I spent searching for alternatives. Just buy Aseprite, it’s great.

The art

Did I mention it’s basically my first time doing pixel art?

So, after realizing I don’t know shit about pixel art, I started gathering a few resources to learn, like Retronator and Pixel Art Academy 101, MiniBoss Pixel Art Tutorials, Slynyrd’s blog and of course, kept staring at Pixel Dailies and Pixels Huh.

And then back to work:

That’s a little bit better

I’m having a hard time with backgrounds and colors, so I also did some gray scale backgrounds to practice

The doing nothing

But really, these past weeks I’ve been mostly doing nothing. It kinda breaks your motivation, when you are stuck doing something that you don’t particularly enjoy and you keep not seeing any good results. I feel it’s the point where most projects just get abandoned. I’ve felt like ditching this a few times. But I also found a few ways to keep the spirits up.

One is sharing with people what you are doing, the ideas you have. It’s a good way to remember why you started the project, plus when people know you are working on something, there’s a small pressure there — the good kind of pressure, I think — that keeps you going.

Another is to switch tasks and do something else that is less frustrating. Sure, it’s good to have a plan and actually finish tasks, but it’s no good if you are so stuck you want to throw everything away. In the moments when I really didn’t feel like doing pixel art I’ve been working on the story, and it’s been great because I’ve gotten really excited about certain scenes or characters, and that brought back the will to l̶i̶v̶e̶ draw.

So, still a lot of artwork to do but summer has ended and I’ve managed to get some of my motivation back, so I’m hoping to start working on the game more often now.