DEV Community: Rossella Ferrandino

Beyond keywords: technical SEO wins for developer portfolios

Rossella Ferrandino — Sat, 15 Feb 2025 09:13:22 +0000

Back in 2020, I wrote an article about improving the SEO score for your developer portfolio. It resonated with many, sparking discussions among fellow developers on how to improve their portfolio’s visibility and technical SEO. However, the SEO landscape has evolved since then, and there are even more opportunities to enhance performance beyond just optimizing meta tags and keywords.

In this article, I'll cover some of my learnings on this topic, focusing on technical SEO improvements that not only boost your portfolio’s visibility in search engines but also enhance its overall user experience. My portfolio follows a simple structure, using only HTML, CSS, and JavaScript, but these optimizations can be applied to more complex setups as well—keeping in mind that heavily hydrated JavaScript can pose SEO challenges.

Structured Data: helping search engines understand your portfolio

How to implement Schema Markup for your portfolio

Structured data (JSON-LD) helps search engines better understand the content on your site. By implementing schema markup, you can improve the way your portfolio appears in search results with rich snippets, making it more attractive to potential employers and recruiters. I’ve seen this strategy used effectively in e-commerce websites, where product, collection, and Local Business schemas enhance visibility in search results. For developer portfolios, I am currently testing it out to see if it makes a measurable difference. If you're interested in learning more, you can explore the official documentation at Schema.org and check out their open-source repository on GitHub.

How to implement Schema Markup for your portfolio

Adding structured data can highlight your name, job title, websites (personal portfolio, LinkedIn, Github etc.), and projects. Here’s an example of how you can use Schema.org’s Person schema:

    <script type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "Person",
        "image": "./assets/image",
        "jobTitle": "Front End Engineer",
        "name": "Your Name",
        "url": "https://yourportfolio.com",
        "sameAs": [
          "https://github.com/yourusername",
          "https://linkedin.com/in/yourusername"
        ]
      }
    </script>

Test your structured data using Google’s Rich Results Validator to ensure it’s properly set up.

Core Web Vitals: the metrics that matter in 2025

Google now places a greater emphasis on user experience metrics, including Core Web Vitals. Core Web Vitals are a set of key performance metrics that measure how users experience the speed, responsiveness, and stability of a webpage. Unlike Lighthouse, which provides lab data based on simulated environments, Core Web Vitals are field data, gathered from real users interacting with your site. These include:

LCP (Largest Contentful Paint): Measures how quickly the largest visible content (like an image or heading) loads.
CLS (Cumulative Layout Shift): Evaluates how much elements shift around as the page loads, affecting visual stability.
INP (Interaction to Next Paint): The newest metric that focuses on how fast the page responds to user interactions like clicks and keypresses.

How Core Web Vitals affect your portfolio

A well-optimized developer portfolio should load quickly, feel responsive, and remain visually stable to create a good impression on potential employers. Poor Core Web Vitals scores can lead to a lower ranking in Google search results, making your portfolio harder to find.
To improve your Core Web Vitals:

Optimize images and assets to reduce LCP
Minimize layout shifts by specifying dimensions for media and fonts, therefore improving the CLS parameter
Reduce JavaScript execution time and defer non-essential scripts to improve responsiveness

You can use PageSpeed Insights and Chrome User Experience Report (CRUX) to track real-user performance data. Google also recently added the "Performance" tab in the Google Chrome developer tools, and you can check out your page's LCP, CLS and INP directly from your browser.

One note for low traffic websites, the field data/CRUX will probably return "not enough data", it means that there is not enough traffic to generate a reliable report - in that case I recommend to use WebPageTest to analyse the website.

Preloading & optimizing assets for speed

Here are a couple of recommendations on how to handle assets like fonts and images - optimizing these can be a quick win for performance.

Preloading Fonts to Reduce CLS (Cumulative Layout Shift)

CLS issues often stem from fonts loading too slowly, causing page elements to shift unexpectedly. You can preload fonts like this:

<link rel="preload" href="/fonts/custom-font.woff2" as="font" type="font/woff2" crossorigin="anonymous">

Also, set font-display: swap; in your CSS to prevent invisible text while fonts load.

Lazy loading & optimized image formats

Images often account for the largest portion of page weight, so optimizing them is essential.

Modern formats like WebP and AVIF provide better compression than JPEG and PNG, reducing file size without sacrificing quality.

Implement lazy loading for images and iframes

Lazy loading defers the loading of images and iframes until they are about to be viewed. This drastically improves initial page speed:

<img src="project-thumbnail.jpg" loading="lazy" alt="Project Preview">

Internal linking & site navigation: boosting discoverability

Search engines rely on clear site structure and internal linking to understand the relationship between pages. If your portfolio has multiple sections—such as an "About" page, a "Projects" page, and a "Blog"—proper internal linking can help search engines crawl and index your content more efficiently.

Best Practices for Internal Linking:

Ensure every page is accessible within a few clicks from the homepage.
Use descriptive anchor text when linking to other pages (e.g., instead of “Click here,” use “View my latest React project”). Non-descriptive links can also lower your Lighthouse SEO score, so ensuring clarity in your anchor text benefits both usability and search rankings.
If you have more than 5 pages in your portfolio, add breadcrumb navigation to help users and search engines understand your site hierarchy.
Include an HTML sitemap or footer navigation links to reinforce discoverability.

Note: Since my portfolio is a two-page site, a sitemap may not be necessary in this case, but for multi-page portfolios, it can be highly beneficial. I will implement it if for example I decide to host my blog on my portfolio website

Conclusion & key takeaways

SEO for developer portfolios goes beyond just adding keywords and meta tags. To stand out in 2024, focus on:

Structured data to enhance search engine visibility.
Core Web Vitals to ensure a smooth user experience.
Optimized assets and lazy loading to boost page speed.
Internal linking and clear navigation to improve search engine crawling.

Thank you for reading, I hope this list can be helpful.
Here is the link to my portfolio website

Feel free to ask questions and add any other recommendation you think might be useful ⚡️
_
[Cover image Photo by Nick Morrison on Unsplash]_

Automating Dropoff Point Retrieval in Shopify with Mechanic

Rossella Ferrandino — Tue, 04 Feb 2025 11:16:00 +0000

Originally published on Nama Studio’s blog, sharing here for the dev community!

If you're looking to streamline your workflows in Shopify, the Mechanic app is an essential tool.

It allows developers to automate tasks, saving time and simplifying operations. Mechanic provides a complete library of pre-built tasks, but we often use it to implement custom logic. When integrating external APIs, it's crucial to properly structure the tasks to manage asynchronous requests, ensure API scope detection, and follow best practices for better reliability and maintainability.

In this article, I’ll show you how we built a Mechanic task that retrieves the Poste Italiane pickup point IDs from ShippyPro, an advanced shipping and logistics platform—and saves them as metafields in Shopify orders.

What this task does

When customers select the local pickup option in Shopify, the pickup point ID is not automatically saved in the order details. This was an issue for one of our clients, who needed to integrate ShippyPro to manage deliveries more efficiently.

ShippyPro is a premium platform that integrates with various carriers, providing tools to automate shipments, tracking, and pickup point management. By using one of their premium APIs, we can retrieve the correct pickup point ID for an order and save it in Shopify’s metafields.

Although ShippyPro and Shopify offer a native integration, due to our client’s ERP structure, orders are transmitted from Shopify to ShippyPro via API, rather than through the standard integration. This custom solution ensures that orders follow the business logic set by the ERP, while still benefiting from the advanced features of ShippyPro.

How does this task work

Here’s a general overview of how our Mechanic task works:

Order Monitoring: The task monitors new Shopify orders with a specific shipping method for local pickup.
API Call to ShippyPro: It makes a request to ShippyPro to retrieve the available pickup points.
Saving the Pickup Point ID: If a pickup point matches the customer’s selection, the ID is saved in the order’s metafields.

Lessons learned

During the creation of this task, we learned a lot about working with external APIs through Mechanic, particularly regarding managing asynchronous responses and correctly detecting API scopes. Let’s go over some of the key lessons we learned.

Managing API Scopes in Mechanic: The Role of Event Previews

One of the main challenges in creating tasks in Mechanic is ensuring that the task has the correct API scopes to perform specific actions. Shopify requires apps to declare these scopes during installation, and Mechanic detects them by analyzing the task's code before execution.

However, there’s a challenge when a GraphQL mutation (such as metafieldsSet) is executed only under specific conditions. If these conditions are not met during the preview, Mechanic might not recognize that the task needs write access to the metafields. This can lead to the task failing during execution because the necessary permissions weren’t granted during installation.

To resolve this issue, we leveraged the concept of event previews. During the preview mode, we provided dummy data to ensure the metafieldsSet mutation was executed even during testing, allowing Mechanic to recognize the need for write permissions (write_orders) before actual execution.

Here’s the code we used:

{% if event.preview %}
  {% action "shopify" %}
    mutation {
      metafieldsSet(
        metafields: [
          {
            ownerId: "gid://shopify/Order/6483826147655",
            namespace: "custom",
            key: "dropoff_point_id",
            type: "single_line_text_field",
            value: "1234"
          }
        ]
      ) {
        metafields {
          id
        }
        userErrors {
          message
        }
      }
    }
  {% endaction %}
{% endif %}

How to work with external APIs in Mechanic

Since operations in Mechanic are executed asynchronously, the results of API calls are not immediately available within the Liquid task that initiated them. To manage this, Mechanic provides a structured approach using the event subscription mechanic/actions/perform, allowing the processing to continue based on the results of the previous task.

To ensure continuity between the steps, we use the meta parameter to pass additional information from the first event to the second, such as the order_id and shipping address, enabling the second event to correctly map the API response to the original order.

The correct approach is to split the task into two steps:

First event (shopify/orders/create):

Extract relevant data from the order with GraphQL
Make the HTTP request to the external API
Pass extra data using the meta object

Second event (mechanic/actions/perform):
Capture the external API response
Process the response
Save data to Shopify (e.g., update order metafields)

{% if event.topic == "shopify/orders/create" or event.topic == "mechanic/user/order" %}
  {% capture query %}
    {% comment %}
      Build your query here
    {% endcomment %}
  {% endcapture %}

  {% assign result = query | shopify %}

  {% assign order = result.data.order %}
  {% assign shipping_address = order.shippingAddress %}

  {% if shipping_address %}
    {% assign shipping_method = order.shippingLines.edges[0].node.title %}
    {% if shipping_method == shipping_point_method %}
      {% capture parameters %}
        {
          "Method": "GetDropOffPoints",
          "Params": {
            "city": {{ shipping_address.city | json }},
            "zip": {{ shipping_address.zip | json }},
            "country": "IT",
            "couriers": ["CourierName"]
          }
        }
      {% endcapture %}

      {% action "http" %}
        {
          "method": "GET",
          "url": {{ endpoint | json }},
          "headers": {
            "Authorization": {{ ENCODED_API_TOKEN | json }},
            "Content-Type": "application/json"
          },
          "body": {{ parameters | json }},
          "meta": {
            "order_id": {{ order.id | json }},
            "order_shipping_address": {{ shipping_address.address1 | json }}
          }
        }
      {% endaction %}

    {% endif %}
  {% endif %}

  {% elsif event.topic == "mechanic/actions/perform" %}

    {% if action.type == "http" %}
      {% assign response = action.run.result.body %}
      {% assign order_id = action.options.meta.order_id %}
      {% assign order_address = action.options.meta.order_shipping_address %}
        {% if matching_point_id %}
        {% action "shopify" %}
          mutation {
            metafieldsSet(
              metafields: [
                {
                  ownerId: {{ order_id | json }},
                  namespace: "custom",
                  key: "dropoff_point_id",
                  type: "single_line_text_field",
                  value: {{ matching_point_id | json }}
                }
              ]
            ) {
               metafields {
                id
               }
               userErrors {
                 message 
               }
            }
          }

        {% endaction %}
    {% endif %}
{% endif %}

Conclusion

Properly structuring Mechanic tasks that interact with external APIs allows you to create powerful and reliable automations. With this solution, orders with local pickup are linked to the correct pickup point through the ShippyPro API, improving logistics efficiency and ensuring a seamless workflow.

If you'd like to learn more about working with Mechanic and external APIs, check out the official app documentation.

Automating your Shopify tasks with Mechanic

Rossella Ferrandino — Fri, 12 Mar 2021 02:39:13 +0000

Running an e-commerce store on Shopify is not only selling products through various sales channels and interacting with customers.

A big part of the process involves manual and repetitive tasks, like creating products, managing inventory, or fulfilling orders.

Enters Mechanic, a Shopify App that allows merchants to automate tasks. It was written by Isaac Bowen, a person I admire a lot, and it has a very active community of developers. I have started working with Mechanic last year, but I was mostly modifying tasks already created by other developers in my team.

In the past few weeks, I have been diving into the Mechanic documentation to understand how to build tasks in their entirety and on my own. There are a lot of new concepts I am encountering, mainly related to building GraphQL queries to get information about Shopify objects, as well as mutations to modify those Shopify objects.

In this article you will find some general information to get started with Mechanic. The app documentation is really good, but I was very lost at the beginning so my notes might come in handy to other Shopify theme developers.

Tasks and events

As a developer, I use Mechanic to write tasks, pieces of code that respond to events. There are many types of events available in Mechanic and they might be coming from Shopify, from incoming email, from webhooks, etc. You specify the event your task responds to in the "subscriptions" field of the Mechanic task. When the event happens, it triggers the Mechanic task, which in turn will execute the actions defined in the code.

Here are some basic events available for Mechanic tasks, I'll explain each one in a couple of sentences.

shopify/orders/create
mechanic/user/trigger
mechanic/scheduler/tuesday+9.hours

The first example shopify/orders/create triggers the Mechanic task each time a new order is created. It responds to a Shopify webhook and the event will have information about that specific order, which you can then use in your task.

If you want to allow the user to trigger the task by clicking on a button, you should use the mechanic/user/trigger subscription. For example, I have used this event subscription, in addition to a scheduler event mechanic/scheduler/daily to run a bulk scan of all the products in my store every day at midnight and check that all their variants have a price. This way my client can rely on the scheduled task, but can manually run it whenever they need.
If you want to schedule a task for a specific time of the day, or a specific day of the week, you can play around with the mechanic/scheduler event - the last example mechanic/scheduler/tuesday+9.hours runs every Tuesday at 9am.

You can find a comprehensive list of the events available in Mechanic here

Querying Shopify

Many of the tasks I have worked on required gathering data about a specific Shopify object and then, if the object met the specified criteria, perform an action on said object.
Generally speaking, Mechanic offers three ways of fetching data from Shopify:

Liquid objects
GraphQL
GraphQL bulk operations

Liquid objects return data from Shopify's REST admin API, while GraphQL and GraphQL bulk operations return data from the Shopify GraphQL's API. The key difference between the two APIs regards the way data is fetched: GraphQL queries the endpoint knowing already what data to expect, while REST retrieves all data available for that specific object.

Which API is more appropriate to the task you are looking to build? In short, you should use Liquid objects when your Mechanic event is already returning an object with the data you need (for example in the case of shopify/orders/create already returns the order) or if you are querying a small amount of data (if you are querying shop.customers and you only have a few hundreds customers in your store).
On the other hand, you should use the GraphQL if you have a large amount of data to scan (GraphQL bulk operations if it's very large) and if you already know what information you want to retrieve for that specific object.

Let me walk you through you a couple of examples.

Example: REST API

My task needs to tag a customer after he orders. In this case, my best option is to use Shopify's REST API and subscribe to the shopify/orders/create event topic.

The task will run every time a new order is created in Shopify and it look for the customer id within the order. Then, I using Resourceful REST, the task will perform a "shopify" action and it will add the tag "ordered" to the customer.

{% action "shopify" %}
  [
    "put",
    "/admin/customers/{{ order.customer.id }}.json",
    {
      "customer": {
        "tags": {{ order.customer.tags | add_tag: "ordered" | json }}
      }
    }
  ]
{% endaction %}

Example: GraphQL bulk operations

My task needs to scan all products of the store and apply a tag if any of the product variants have a specific metafield.

In order to achieve this, I am going to use a bulk operation, which sends Shopify a query that might return a large amount of data. As mentioned in the Mechanic documentation, "when the query is complete, the Mechanic task is notified (with a "mechanic/shopify/bulk_operation" event), and the task then processes the query's results."

My task subscribes to the mechanic/shopify/bulk_operation as an additional event topic.

mechanic/user/trigger
mechanic/shopify/bulk_operation
mechanic/scheduler/daily+8.hours

Within my task, I have setup the script to watch for this event topic, using the bulkOperation variable to access the bulk operation's results.

I will go into more details of GraphQL and bulk operations in my next article, but here are some helpful links if you want to take a look at the documentation:

How to split a string in Handlebars template

Rossella Ferrandino — Wed, 25 Nov 2020 11:51:40 +0000

Sometimes Shopify themes will use Handlebars for components like the Shopify predictive search or the ajax cart. Handlebars compiles templates into JavaScript functions, and makes the template execution faster.

So for example you could see in a theme a snippet called predictive-template.liquid, which loops through the products returned by the search and outputs html including their title, price, an image etc.

This is what a Handlebars template will look like - I got this from a paid Shopify theme I was adding custom functionality to today:

<div>
    {% raw %}
      {{#if products}}
        <div data-type-products>
          <div class="grid grid--uniform">
            {{#products}} 
          <div class="grid-product__meta">
            <div">{{title}}</div>
          </div>
          {{#if image }}
           <img class="image-fit lazyload"
             data-src="{{image}}"
             data-widths="[180, 360, 540, 720]"
             data-sizes="auto">
          {{/if}}
         </div>
     </div>
{% endraw %}
</div>

Variables like title or image are returned from the get request to the endpoint search/suggest.json, which is made in a JavaScript file like theme.js.

What I wanted to do today was manipulate the product title string to remove the first 10 letters. In order to do that in Handlebars, I created a helper, which I then added to the JavaScript file that was handling the template compilation. The documentation on how to use registerHelper in Handlebars is here
This is my code:

Handlebars.registerHelper('sliceTitle', function(passedString) {
  var theString = passedString.substring(10,100);
    return new Handlebars.SafeString(theString)
});

Handlebars.SafeString(string) is a built in helper that prevents string from being escaped when the template is rendered.
Finally, I modified the Handlebars template to use the helper just created.

<div class="grid-product__meta">
  <div">{{sliceTitle title}}</div>
</div>

And that's it, this is how I created my custom Handlebars helper to manipulate the results returned from the predictive search and outputted using a Handlebars template.

Planning your first technical workshop

Rossella Ferrandino — Mon, 23 Nov 2020 10:47:13 +0000

While I was learning how to code back in London, I used to attend the workshops organised by Codebar, where junior developers were paired with a mentor and going through their tutorial/projects with the help of an expert developer.
After I moved to Tokyo, I started attending the events organised by associations like Women Who Code, or coding bootcamps like Le Wagon and Code Chrysalis. There are just so many good events happening in the tech industry that I didn't want to miss anything.

I have received so much by participating to technical workshops and attending networking events. So this year I decided to start giving back to the tech community that has given so me so much. I signed up as a volunteer with Women Who Code Tokyo, where I have helped organising a couple of their events and even contributed to their open source project SpeakHer.

So when a colleague recommended me for a technical workshop organised by Le Wagon, I decided to take a leap and contact the event organiser to host the workshop.
Sasha, the community manager for Le Wagon, is also an active member of Women Who Code, so it was the perfect opportunity for me to have my first tech talk in a supportive and familiar environment.

Together we discussed the broad topic of the event, focused on Customising a Shopify store using the templating language Liquid. It's a great topic for me because it's what I do for a living.

I want to use this post to put together some of the things I learned while preparing this technical workshop. They might be helpful if you are going through the same thing, and I check them out again if I decide to host another workshop.

Plan for your target audience

The topic of the workshop is usually set by the event organisers, but as a speaker you can approach that topic from a specific angle. Have a type of target audience in mind, as well as what you would like them to take away from your workshop. I really appreciate people investing their time in learning something new, listening to a tech talk and actively participating in the discussion, so I wanted them to get something valuable from the hour they decided to spend with me.

I planned the practical part of my workshop around 3 learning outcomes I wanted the listeners to achieve by the end of the talk. And I prepared a specific slide that I discussed just after the agenda, so that it was clear to everybody what the practical outcomes should have been.

Have a clear structure

One hour is a lot of time and you need to make sure you keep the audience's attention level quite consistent throughout the whole presentation. I broke down my workshop in two main parts, one focused on introducing the topic and give some theoretical background, and the other one focused on building something together, so that the concepts introduced in part 1 could be applied straight away. This is the agenda I put together, sections from 1 to 3 were focused on theory, sections 4 and 5 on live coding, and then the last section was where I wrapped things up and recommended some resources to continue learning about the topic.

Slides

This is a topic I learned a lot about, thanks to the "Intro to public speaking" workshop organised by Women Who Code Tokyo. Here are some small takeaways I applied to my presentation:

Use Plain colours that don't distract the audience too much
Use the same pattern/slide type to break down each section of the workshop, like you had listed in the agenda. So in my case, I had a slide with the same background throughout the whole presentation, with just the title of the new workshop section
Don't use too many words on the slides, so people will listen to what you have to say instead of reading the content

Write a script for the whole talk and rehearse it

In the weeks leading up to the workshop, I worked on my presentation, created my Shopify store, uploaded products for the demo, as well as coded the necessary parts I was going to go through during the practical theme development part.
In my head everything was ready, but when I started rehearsing, I realised I wasn't really prepared to present. I knew what I wanted to say but I didn't know the best way of expressing it. What really helped was writing down a script with everything I wanted to say and then read it so many times I could actually deliver it convincingly.

Have your code snippets ready

This is something I had never noticed with all the workshops I attended, but instructors usually have their code snippets ready on another window/screen. The audience doesn't really want to see you type large chunks of code, but you can paste the code you already have ready, and then go through each line and explain what that code does and why it works.
During my workshop, I had two screens: one with the presentation, as well as my code editor and browser windows to edit the themes, and another one just with the code snippets, each opened already in a different tab.

Relax, you are the expert here

One final key takeaway is not to stress out too much before the workshop. You are prepared and you are donating your time to teach other people something you know well. You know more about that specific topic than the other people in the room. I have learned from someone wise that, if there are difficult questions in the Q&A session, it's ok to say "let's take this offline".

Thank you so much for reading, feel free to share some more recommendations for first time public speakers in the comments.

Making the world a better place with open source

Rossella Ferrandino — Sat, 10 Oct 2020 05:20:33 +0000

About a month ago, I submitted my very first pull request to an open source project on Github. It felt like using my coding "superpowers" for the greater good. Let me tell you a bit more about my journey and how I found a good first project to contribute to.

Why open source

I have been trying to contribute to open source for about two years now. That's right, two years. I had always read that this is one of the best ways to step up your coding skills. It allows you to learn how to work collaboratively, to read code written by experienced developers and to meet people interested in similar things. I had the drive and motivation, all that was missing was a project to contribute to.

I searched for issues using the recommended issue aggregators such as Up For Grabs or Code Triage, I had even bookmarked a Github search with a filter for all issues tagged as "good first issue", which I checked regularly. But every time I went through a specific repository, I was overwhelmed with self doubt and intimidated by the code base, so I got discouraged and eventually gave up.

This year, I got more involved in the Women Who Code Tokyo community. I had attended their events for almost two years and I decided to step up and help organize some of the upcoming workshops and events.
Then I heard about SpeakHer, made by three amazing women in this network and for a really good cause, so I decided to give open source another go.

SpeakHer

SpeakHer is a bilingual database of public female speakers in Japan and it has the purpose of reducing the imbalance of presenters at conferences and other events. It allows event organizers to search for female speakers and fellow speakers to connect and support each other.
The project is a serverless Vue.js site hosted on Netlify and using Airtable as database.

As I was already part of their network, I joined a Zoom call with the project maintainers, explained my background and got assigned to a couple of good first issues. The purpose of this type of Github issues is to allow new contributors to get familiar with the codebase and to make a minor improvement to the site. I really admire the project maintainers for their passion and patience in mentoring new contributors to the project 👏
This is SpeakHer Github repository if you would like to check it out.

What I am learning

I have now made two contributions to this project, mostly focused on form validations. The skills I am improving are definitely communication skills, as I need to explain why I am making a certain type of changes to the code and technical skills such as navigating a new codebase, using following consistent naming conventions and reading documentation to implement what is required.

In conclusion, I would recommend contributing to open source, not only to leave your mark in projects that could have a positive impact on people, but to also learn and improve technically.

SEO tips for your developer portfolio

Rossella Ferrandino — Mon, 31 Aug 2020 13:47:15 +0000

As a front-end developer, I am often working on client websites to optimise their SEO. This week, I applied some of these strategies to my developer portfolio, which now has a 100 SEO score on Lighthouse 👩‍💻.

I will share some advice with you here. By all means, this is not an exhaustive list but it's a good place to start. If you want to check out my portfolio, I added a link to this at the bottom of the article.

Title, language and viewport

Probably quite obvious, but your portfolio should have a title. You can specify this in the html head as <title>My portfolio</title>.
What is not so obvious is that defining the language and the viewport on your site will impact your Lighthouse score. The language is important for those users that utilise screen readers, while the viewport meta tag will optimise your app for mobile screens.

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1, 
      shrink-to-fit=no"
    />
  </head>
  <body>
  </body>
</html>

Meta tags

Meta tags are snippets of code that give search engines information about your website. The basic ones are title, which I already mentioned, and description. This is the information that is displayed in the Google search results, so it should be concise and to the point. You can also add keywords to your page, but I haven't implemented this yet.

<meta name="description" content="JavaScript wizard, chaotic good">
<meta name="keyword" content="portfolio, javascript, developer">

Meta tags for social media

This is not 100% necessary, but it is a nice to have if you want to share your portfolio on Slack, Twitter, etc.
These meta tags turn your web pages into graph objects through the Open Graph Protocol.

<meta property="og:title" content="Myrtis Beaverdam | Front End Web Developer"/>
<meta property="og:description" content="JavaScript wizard, chaotic good" />
<meta property="og:image" content="https://example.com/image.jpg"/>
<meta property="og:url" content="https://example.com" />
<meta property="og:type" content="website" />

Twitter has its own set of meta tags. You can either use the summary card (title, thumbnail image and description) or the summary card with large image, which is the one I prefer. This is an example markup:

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Myrtis Beaverdam | Front End Developer" />
<meta name="twitter:description" content="JavaScript wizard, chaotic good"/>
<meta name="twitter:image" content="https://example.com/image.jpg"/>

If you want to check what your Twitter card will look like, you can use the Twitter card validator here: https://cards-dev.twitter.com/validator

Accessibility

Two important points related to accessibility impact your SEO score, however Lighthouse reports have many more insights on accessibility, which I highly recommend checking.

Images need to have descriptive alt attributes. If the alt attribute is just an empty string, this will be removed from the accessibility tree.
Another point related to accessibility that I discovered with this portfolio iteration is the that each anchor tag should have some descriptive text. Using anchor tags with icons (and not text) for my social media profiles was negatively impacting my score, and I discovered that attribute aria-label resolves this particular issue.

Favicon

This is a bonus tip and it is not really related to SEO (but it's a nice to-have). You can include a favicon in your project. This is what will be displayed in the browser tab, just before your website title. This is how you add it to your code:

<link rel="shortcut icon" href="./assets/favicon.ico" type="image/x-icon" />

Thank you for reading, I hope this list can be helpful.
Here is the link to my portfolio website

Feel free to ask questions and add any other recommendation you think might be useful ⚡️

Learning Ruby: check equality

Rossella Ferrandino — Sun, 16 Aug 2020 10:01:15 +0000

There are different ways to determine whether two values are the same in Ruby.

Equality operators: == and !=

The equals operator == will return true if the values compared are equal.

string_one = "Cookies"
string_two = "Cookies"

string_one == string_two   #Output: => true
string_one != string_two   #Output: => false

When we compare numbers of different types (float and integer), the equals operator will return true if both have the same numeric value.

7 == 7.0   #Output: => true

eql?

The eql? method checks both the value type and the exact value it holds. So an integer and a float that have the same numeric value will not be equal.

7.eql?(7.0)   #Output: => false

equal?

The equal? method is the strictest form of comparison in Ruby. It checks whether both values are the exact same object in memory.

a = "Cookies"
b = "Cookies"

puts a.object_id #Output: => 47343105968220
puts b.object_id #Output: => 47343105968200

a.equal? b  # Output: => false

Things are a bit different for numbers, because of the way computers store integers in memory. 7 will always point at the same object id, so if we assign the number 7 to two different variables and use the equal? method on those two variables, the result will be true.

a = 7
b = 7

puts a.object_id # Output: => 15
puts b.object_id # Output: => 15

puts a.equal?(b)  # Output: => true

The spaceship operator <=>

Differently from the previous operators / methods, the spaceship operator does not return true or false, but it returns one of three numerical values.

-1 if the value on the left is less than the value on the right
0 if the value on the left is equal to the value on the right
1 if the value on the left is greater than the value on the right


7 <=> 8 # Output: => -1
7 <=> 7.0 # Output: => 0
7 <=> 7 # Output: => 0
7 <=> 1 # Output: => 1

This operator is mostly used for sorting functions.

Learning Ruby: string concatenation

Rossella Ferrandino — Sat, 08 Aug 2020 07:13:08 +0000

I have been practicing my Ruby beginner skills on Codewars this week and I just came across this interesting Kata which taught me something new about concatenating strings.

The description of the Kata is as follows:

Given 2 strings, a and b, return a string of the form short+long+short, with the shorter string on the outside and the longer string on the inside.
The strings will not be the same length, but they may be empty ( length 0 ).

For example:

solution("1", "22") # returns "1221"
solution("22", "1") # returns "1221"

At first, I tried using the concat method, similarly to what I would do in JavaScript. I was surprised when the output of my function was:

def solution(a, b)
  puts a.length > b.length ? b.concat(a).concat(b) : a.concat(b).concat(a)
end

solution("a", "bb") 
# returns "abbabb"

As a matter of fact the concat method in Ruby will change the initial string, and that is why the last .concat(a) was concatenating an incorrect value. The same happens when you use the method <<, which is equivalent to concat.

In order to resolve the Kata, I used the + operators, which does not mutate the initial string.

def solution(a, b)
  puts a.length > b.length ? b + a + b : a + b + a
end

solution("a", "bb") 
# returns "abba"

Summary

In Ruby, there are various ways to concatenate two or more strings:

+ operator

Strings can be appended to one another using the + operator, like in JavaScript and other languages. This will not modify the initial string.

concat method

This method will change the string instead of creating a new one.

<< method

This is an alias for concat and it also mutates the initial string.

Learning Ruby: naming conventions

Rossella Ferrandino — Wed, 05 Aug 2020 13:03:23 +0000

Ruby has specific naming conventions that make it easier to write and read code. I would like to summarize them here in a cheatsheet format that is easier to refer to.

snake_case:

files
variables
methods

#files
my_first_ruby_file.rb

#variables
programming_language = "Ruby"

#methods
def make_an_example
  #do stuff
end

UPPERCASE:

constant variables

Constant variables represent values that will not change during your Ruby program.

ID = AB123456
FAVORITE_FOOD = "Pizza"

CamelCase:

classes

class Person
end

class Movie
end

Additional note

When working with do/end blocks, it is preferable to use { } when the code can fit in a single line

characters = ["Eleven", "Mike", "Dustin", "Lucas", "Will"]
characters.each do |character|
  puts character
end

characters.each { |character| puts character }

👩‍💻 Learning Ruby: first impressions from a JavaScript developer

Rossella Ferrandino — Tue, 04 Aug 2020 14:53:07 +0000

I have just finished the last class of the "Le Wagon - Programming for Everybody" online learning series. This was my very first dip into the world of Ruby... and I must admit, I was surprised to discover how developer friendly and humanly readable this language is.

Why Ruby

You might be wondering, why did a professional developer decide to join a beginner course about Ruby? First of all, a little bit about myself. I am a self-taught developer and I got a job as a front end developer after learning how to code on Freecodecamp, Codecademy and just building projects.

I wanted to experience a structured learning course with a real instructor, where I could ask questions not only about the syntax, but also about best practices and why Ruby does things the way it does. By the end of the course, I also realised that learning a language like Ruby can make me a better JavaScript developer.

Ruby and JavaScript: some observations

Object Oriented Programming

Ruby is an Object Oriented Language, which means it manipulates programming constructs called objects. If you type "Ruby", you are creating an instance of the class String. As a class instance, your string will inherit methods like .length, .capitalize etc., that you can use to manipulate your string.

JavaScript, on the other hand, is not a class-based Object Oriented language, but with prototype based inheritance and constructor functions, it has ways of using Object Oriented Programming (OOP).

Data types

To determine what type of value something is (a number, a string, an array), in Ruby you append .class at the end of the object, since you want to find out the class of the object it's called on. There are classes like Integer, Float, String, Array, Hash... even True and False are their own class!

true.class
# TrueClass

false.class
# FalseClass

In JavaScript, you use typeof before your data, and this will return whether that element is a string, a number, a boolean, an object etc.

typeof true
# boolean

typeof false
# boolean

Method naming conventions

In Ruby, I saw for the first time methods ending with "?", a naming convention used to indicate that a specific method will return either true or false. For example, if you have a hash (a key value pair data structure) with tv show titles and ratings, you can use the simple method .key? to check if the hash contains a certain key.

tv_shows = {
  "Friends" =>  10,
  "Community" => 10,
  "The Witcher" => 9
}

puts tv_shows.key?("Friends")

In JavaScript, functions can't end with punctuation but can be named semantically so that their name will describe well what they do. If you are curious to know how you can check if an object has a specific key in JavaScript, this is how you do it:

const tv_shows = {
  "Friends": 10,
  "Community": 10,
  "The Witcher": 9
}

tv_shows.hasOwnProperty("Friends")

There is more than one way to do something

Ruby is built for usability. I was surprised to discover that for example the methods .map and .collect do exactly the same thing and that collect was just created in order to make Ruby feel more intuitive.

Where to go from here?

I plan on continuing learning Ruby until I am able to contribute to my company's projects that use this language. That's how I would like to reinforce this initial knowledge and put it into practice:

Codewars kata
Build a scraper - apparently this can be done only with a few lines of code in Ruby
The Odin Project learning track