Forem: Pablo Marcano

The Weekly Animation - 1 + 1/2

Pablo Marcano — Wed, 11 Nov 2020 12:41:22 +0000

In the previous article We learned how to animate the non-interactive part of this animation From Lukas Kus using GSAP Timeline. Now in order to completely replicate what was done on the dibbble it would be cool to simulate the user dragging on what we did previously to reveal an image, and that's exactly what we're doing today.

Again, here's the end result.

Setting up the background image

We'll need to carefully set up the background image behind the main circle, this will depend heavily on how you first positioned your SVG on the canvas. On the example above it's done by wrapping everything on the same divand absolutely positioning it using thetop and left css properties. You can see it on line 58 of the css tab.

I used Lorem Picsum to fetch a different image of the height I wanted everytime to get a nicer result as well.

The draggable interaction

In order to make the image move and then fade away after reaching certain threshold I'll be using a GSAP Draggable which simplifies the process of making any DOM element Draggable.

First of all, let's arrange our SVG in a way we could move all elements we want to be movable at the same time, as currently the Draggable plugin does not support moving non-nested elements at the same time natively.

To do so, I added a <g> to surround the fill part of the main circle and the small orange dot that remains. See HTML line 7.

After that we need to create the actual function that makes the element Draggable. It's done on line 84, let's go over the main parts of it.

  const dg = Draggable.create("#movable", {
    type: "x, y",
    edgeResistance: "0.8",
    bounds: ".inner-circle",
    inertia: true
  })[0];

The Draggable.create function targets everything inside the tag with id #movable.

The type parameter defines the axis we want to move on, in our case we want to freely move around so we use both x,y.

edgeResistance is a value between 0 and 1 that defines how much does the image can go outside the boundaries and the 'strength' the boundaries apply to bring the main item back.

bounds is the query of an element that should contain the element we provided when creating the draggable. It's important that the element is bigger than the draggable, and that it contains it at least visually so we can actually see our animation. In this case is the inner circle we draw with the animation.

inertia gives a sense of smoothness to our draggable when manipulating it with the dom.

const el = dg.addEventListener("drag", (e) => {
    if (shouldOpen(dg) && isActive) {
      closingTl.play();
      isActive = false;
    }
  });

To make the background image appear after we pass a certain treshold we should track whether the draggable element moved the way we wanted, so we listen whenever the element is dragged and check if the position is inside the boundarieswe difine within shouldOpen.

function shouldOpen(dg) {
  const threshold = 25;
  const isOutOfXBoundaries =
    dg.x < dg.minX - threshold || dg.x > dg.maxX + threshold;
  const isOutOfYBoundaries =
    dg.y < dg.minY - threshold || dg.y > dg.maxY + threshold;

  return isOutOfXBoundaries || isOutOfYBoundaries;
}

The shouldOpen function simply receives a draggable event and checks if it's within a range i arbitrarily designed, not too much to see here.

If the image is outside the range we defined then we trigger a new animation that fades out the SVG and brings up the image itself. And we're done!

The point where it all connects it's on line 9 where we define

const tl = new TimelineMax({ repeat: 0, onComplete: addDraggable });

We're using the addDragable function only after the animation completes, since we don't want the user to be able to move the animation while it's still playing.

It may look like a lot of code and orchestration at firts, but just think of how much more complex it would have been using plain css animations and js. Also, by tweaking some values you could make the animation play backwards, or replay it on demand as I've done on the code example.

If you liked this post, make sure to leave a like and follow me on DEV.TO and twitter as @stiv_ml

The Weekly Animation - 1

Pablo Marcano — Mon, 09 Nov 2020 12:49:38 +0000

In my journey to add tools to my belt as a web developer, and find fun and nice looking projects to do on the way, I came across two courses on Frontend Masters that caught my eye.

Creative Coding by Matt DesLauriers and SVG essentials and animations by Sarah Drasner

When completing them I was stoked and excited to apply my new knowledge on something practical, so I went to dribbble and looked for a nice animation to remix. As I learned a lot along the way, and plan to keep doing a similar process for some time so I decided to share my experiences on a weekly installment, following Shawn's learn in public approach.

Today, we're going to be remixing this animation From Lukas Kus

Prerequisites

I've used GreenSock's Draggable, and TweenMax DrawSVG products, which are usually paid, but can be used freely on codepen. I also used Adobe Illustrator for preparing the svg, but any editor that allows creating and exporting SVGs.

That said, some basic knowledge on greesock and css animations could be helpful along the way, but it's not something too big to worry about.

What We'll be doing

The setup

The first thing I did to work on the animation based off the original video was recreating all of the elements I can distinguish from it. I identified 2 main groups, the outer circles that load across the center and the ripple.

Making sure everything it's present and correctly grouped simplifies the work a lot on the animation phase, so make sure you're setting everything up properly! (I had to start from scratch 3 times after animating because I forgot a piece of the svg, so do as I say not as I do). Also, don't worry about hiding things in this phase, that's something we can handle later.

Make sure you export the image as an SVG, and copy and paste it into codepen, you should have something similar to this

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 450 400">
    <g id="all">
      <g id="circles">
          <path class="cls-1 fill-circle" d="M357.26,187.32a165.19,165.19,0,1,1,0-5" transform="translate(-19.57 -10.81)" />
          <path class="cls-2 outer-circle" d="M357.26,187.32a165.19,165.19,0,1,1,0-5" transform="translate(-19.57 -10.81)" />
        <path class="cls-1 inner-circle" d="M357.26,187.32a165.19,165.19,0,1,1,0-5" transform="translate(-19.57 -10.81)" />
      </g>
      <g id="ripple">
        <circle id="center" class="cls-3" cx="337.73" cy="171" r="10" />
        <circle class="cls-4" cx="337.7" cy="171.07" r="30" />
        <circle class="cls-4" cx="337.7" cy="171.03" r="50" />
      </g>
    </g>
  </svg>

The friendlier the names of your layers and group in Illustrator are, the easier it would be to work with them.

I like to separate my css from the html, so i'd paste whatever is in the <style> tag embedded in the svg on the css tab

.cls-1 {
  fill: none;
  stroke: #000;
  stroke-width: 0.5px;
}

.cls-1,
.cls-2 {
  stroke-miterlimit: 10;
}

.cls-2 {
  fill: none;
  stroke: #ff911f;
  stroke-linecap: round;
  stroke-width: 20px;
}

.cls-3,
.cls-4 {
  fill: #ffa20a;
}

.cls-4 {
  opacity: 0.3;
}

svg {
  width: 500px;
  height: 500px;
}

The animation

Here's where most of the hard work happens, since you'll do a lot of tweaking to the animation times/easings/durations. First of all, start by isolating parts and animating them individually. This will make it easier to debug if something breaks or doesn't work as expected.

Make sure you included the GSAP, DRAWSVG and Draggable plugins into codepen JS Tab

Step By Step

The inner circle only job is to go around the main fill color, we can achieve this behavior using DrawSVG plugin.

tl.from(innerCircle, 1.2, {
  drawSVG: "0%",
  easing: Power2.easeOut
})

At the same time, the fill circle animation grows to fill the line boundaries, we use the scale transform property. Make sure transformOrigin is set to 50% 50%, else, your animation may start from the top left corner.

.from(
  fillCircle,
  1,
  {
    scale: 0,
    opacity: 0,
    transformOrigin: "50% 50%",
    easing: Power2.easeIn
  }
)

The animation from the outer circle is similar to the inner one, but it starts from a different point and fades in as it moves instead of just filling the path. For this, we can use the fromTo GSAP method, that takes an initial and ending argument.

.fromTo(
    outerCircle,
    1.2,
    { drawSVG: "20% 30%", easing: Power2.easeOut, opacity: 0 },
    { drawSVG: "99.9% 100%", easing: Power2.easeIn, opacity: 1 },
  )

With the DrawSVG plugin, you can fill just a section of the path by indicating two separate values within it, "20% 30%" represents that we just want to fill 10% of the path then.

We also don't want to close the whole path and make it disappear, since it will aid the animation of the ripple appearing, that's why we leave it on 99.9% for the second value.

.to(
    innerCircle,
    0.7,
    { drawSVG: "100% 100%", easing: Power2.easeInOut }
  );

Once we finish with the animation for the outer path, the thinner path also closes

.staggerFrom(
    ".cls-4, .cls-3",
    0.5,
    {
      scale: 0,
      transformOrigin: "50% 50%"
    },
    0.1
  )
  .staggerTo(
    ripple,
    0.5,
    {
      opacity: 0
    },
    0.1
  )

With staggerFrom and staggerTo we can animate all matching query items with a delay from one another, that's really useful for adding a ripple effect once our paths close. Here we're making the circles grow and then disappear.

At this point our whole animation should be close to done, but something is wrong. Things appear one after another, and that's not how motion works. That's why we need to tweak the starting times for our animations in order for them to look natural. Feel free to take a look at the codepen and copy the values I've used for this. If you have any doubts on how this work, you can look at this page

Next Steps

At this point our animation should look pretty smooth, but in order for it to completely replicate the video we need to add some interaction to it. This would be covered on the next post in this series, since I don't want the experience to be overwhelming.

Extra practice

Feel free to change the values of the timings and animation properties and see if you get to a result you like more! (If you do so, send me a link. I'd love to see it!)

Go on dribbble and find an animation you would like to remix, if you're having trouble reach out to me and maybe it could become a Weekly Animation blog as well!

If you liked this post, make sure to leave a like and follow me on DEV.TO and twitter as @Stiv_ml

Over-engineering in React

Pablo Marcano — Thu, 20 Aug 2020 15:28:29 +0000

React can be so simple and so powerful that it is one of the first choices when it comes to building a web app nowadays. But with great power comes great responsibility. Being so widespread and used, it's easy to find tons of results when looking for solutions that fulfill developer needs, but the most popular solution may not always be the best for every case.

In this article I’m going to cover some common patterns and tools developers tend to blindly stick to without assessing whether they actually apply to their specific use case or not.

Using a Library for State Management

Don’t get me wrong, correct state management is a fundamental part of building a reliable, scalable, and futureproof application. It’s particularly important to take it into account early on in our projects, but you might want to think twice before just starting with a template based off of [insert popular state management library here]. There are a several reasons why I think this way:

It forces you to think and model your application in the library's way of doing things, instead of making choices that could reflect the business reality in a more accurate way. Whether you use redux or mobx (or nothing at all) should depend on if it makes sense for your use case, and not simply on what’s trendier.

You may be making your app less performant. Bundle sizes and performance on lower end devices are metrics that we as developers tend to gloss over, but can end up making a huge difference on the way your users interact with your product. Also, there’s more library code that when used incorrectly may lead to unwanted re-renders, thus making your app less responsive.
At the end of the day, it’s something new you need to learn, document, teach, maintain, and upgrade over time. This is the key factor when deciding to use a state management library or not: will it save you enough time and make your life that much easier in the long run that it’s worth teaching it to every new developer that joins the project? Will you have the time to document a specific scenario where you do things differently? Are you willing to upgrade all of your codebase because of a breaking change? If the answer to all of these questions is yes, then go ahead.

Creating Too Many Files/Folders

If you come from a framework like angular, you may be familiar with the idea of creating a couple of files and a folder just to organize your independent UI components. Add modules, routing files, indexes, and services and you’ll end up with a lot of boilerplate to make things work the way you want in any given scenario. Boilerplate is not a bad thing per-se, but with React we’re not required to have this much ceremony in order to build our apps.

Now, I’m not saying you should go and delete all of your .js files and bake everything in the same file, but embracing the flexibility the framework gives you will help you create apps that are easier to navigate through, and therefore, are more maintainable. The official React documentation even encourages this approach, and provides us with some guidelines to take into account when laying out our app structure.

Here are some things I do to avoid unnecessary nesting/file creation:

Don’t create boundaries where there are none: While it’s pretty common to consider that everything apps are made of is screens and components, what actually differentiates one from another? What you think of today as a component may become a screen down the road, or vice versa. Whenever your domain makes it clear that some things should belong to a folder, then go for it. Creating an extra file folder before the need comes up just creates extra work. Dan Abramov talks more about this in this article where he clarifies the difference between presentational and container components—but beware! You’ll actually find a disclaimer where he talks about how his views have changed since the writing of that article.
Leverage the power of hooks: You may be tempted to create new files as new complex components start forming, and eventually you might want to put together components that share similar logic in a folder. The thing is, you may be able to avoid all of the added complexity of similar-yet-specific components by using hooks to properly reuse your logic.
Use Styled Components: Styled Components can help keep all the styling and the logic related to it within the same file most of the time. This depends greatly on each use case, but they’ve gained popularity because of their flexibility and simplicity to setup, read, and maintain across my apps.

Testing the Wrong Places

While a robust testing suite should be a priority whenever you ship a product that will continue being developed in the future, testing the wrong places could be the source of many frustrations and time wastes, especially on the frontend. Let’s first define what these “wrong places” are and aren’t.

Kent Dodds writes in How to know what to test

“When writing code, remember that you already have two users that you need to support: End users, and developer users. Again, if you think about the code rather than the use cases, it becomes dangerously natural to start testing implementation details. When you do that, your code now has a third user.”

In this post we’re talking about how to make the “developer users” happier. If you’re able to write tests that will actually detect bugs in the future, you’ll inevitably be happier. How do you achieve this? By testing your app the way the users would, avoiding high-effort/low-value code chunks, and writing concise and understandable tests.

Let’s break these down one by one:

Testing the way users would use the app: Here I strongly recommend reading Kent Dodds Testing Implementation Details, who elaborates on how testing implementation details can lead to error prone tests that aren’t actually very useful for catching bugs.
Avoid high-effort/low-value code chunks: If you’re solely using code coverage as your metric to determine the quality of tests (which has its own problems), you’ll often find there’s some code dependant on a third party library that doesn’t quite work as you expected and drags the coverage down. In this case you’ll have to weigh how critical the feature is to the application vs the amount of time you’ll have to spend coding, maintaining, and replicating the functionality across several sections of your app.
Write concise and understandable tests: The more simple, explicit, and understandable a test is can reflect how well a functionality is written. While you should avoid making your implementation more complex just to simplify the tests, if your test can describe what the end goal of a functional piece is, a new maintainer might find it easier to read and make changes to the codebase.

While there are no rules set in stone for writing perfect React code, following these guidelines has saved me time and spared me from bugs and unnecessary meetings in my career. I hope it does the same for you.

Do you have any examples of over-engineering in your favorite framework? How do you usually solve them? Feel free to reach out to me with your examples or with any questions!

Photo by Science in HD on Unsplash

Writing e2e tests for React Native using Expo

Pablo Marcano — Fri, 15 May 2020 17:00:36 +0000

End to End (e2e) testing is a technique that helps ensure the quality of an app on an environment as close as real life as possible, testing the integration of all the pieces that integrate a software. On a mobile app, this could be particularly useful given the diversity of devices and platforms our software is running on top of.

Due to the cross-platform nature of React Native, e2e testing proves to be particularly messy to work on, since we have to write all of our tests with this in mind, changing the way we access to certain properties or query elements no matter the tool we use for connecting to it. Still, tools like Appium and WebdriverIO allow us to work over a common and somewhat standard interface.

The following instructions assume we already have a React Native app built with expo, and use Jest for our unit-testing solution.

Disclaimer: The following instructions are based on a windows machine running an android emulator, output/commands may vary slightly on different architectures.

Setting Up Appium

Install required dependencies

$ npm i -D webdriverio babel-plugin-jsx-remove-data-test-id concurently

WebdriverIO will work as our “client” for the appium server in the case of JS. More to come on how to use other clients such as python.

babel-plugin-jsx-remove-data-test-id will help us remove unwanted accessibilityLabels from our app, since that’s the preferred way of targeting elements for both IOS and Android platforms

concurrently will help us automate the running of appium and jest to do our e2e tests

Install Appium Doctor

$ npm install appium-doctor -g

This will help us identify if we have all of the needed dependencies to correctly run appium in an emulator.

Run Appium Doctor

Depending on the host OS we want to test in, we could run

$ appium-doctor --android

$ appium-doctor --ios

For this particular case I’ll be running the android version. This will prompt us with some output on the console, if we have all the required dependencies installed we should see a message similar to the following:

If not all necessary dependencies are met at this point, instead of checkmarks before any given item you’ll see a red X symbol. Check the end of the input for more information on how to fix the particular Issues you’re prompted.

We’re not going to fix the optional requirements that appium-doctor prompts us for the time being, feel free to go over those once you have the testing solution working.

Run Appium

By this point, you should be able to run appium without any issues, in order to do so just type

$ appium

You should see something similar to

If you do so, Congrats! you have correctly set up appium.

Now, lets set up our tests.

Write tests once, run in any platform

One of the key features of react native is its ability to write code once and run it in both iOS and Android, so we want our tests to behave in the same way. There are some limitations for this, since the only way we can write a selector for both platforms is through the accessibilityLabel attribute in react native. This may become an issue if your app depends on accessibility features, make sure to use correct, semantic and descriptive accessibility labels at any place you intend to use them.

If a great accessibility is not on the scope of your current project (it should), you can use accessibilityLabel as a perfect target for querying your elements, just make sure you don’t accidentally worsen the experience of people using screen readers or any other assistive technology. In order to do this we’re going to configure our babel setup to remove the accessibility labels whenever we build for production.

/// babel.config.js

module.exports = function() {
  return {
    presets: ['babel-preset-expo'],
    env: {
      production: {
        plugins: [
          [
            'babel-plugin-jsx-remove-data-test-id',
            { attributes: 'accessibilityLabel' },
          ],
        ],
      },
    },
  };
};

Let’s write our first test now:

I’ve created a called LoginTest.spec.js inside a new folder called e2e, inside the file I have the following:

// myapp/e2e/LoginTest.spec.js

import wdio from 'webdriverio';

jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000;

const opts = {
  path: '/wd/hub/',
  port: 4723,
  capabilities: {
    platformName: 'android',
    deviceName: 'emulator-5554',
    app: 'my-app-name.apk',
    automationName: 'UiAutomator2',
  },
};

describe('Expo test example', function() {
  let client;
  beforeAll(async function() {
    client = await wdio.remote(opts);
    await client.pause(3000);
    const pack = await client.getCurrentPackage();
    const activity = await client.getCurrentActivity();
    await client.closeApp();
    await client.startActivity(pack, activity); //Reload to force update
    await client.pause(3000);
  });

  afterAll(async function() {
    await client.deleteSession();
  });

  it('should allow us to input username', async function() {
    // Arrange
    const field = await client.$('~username');
    const visible = await field.isDisplayed();
    // Act
    await field.addValue('testUsername');
    // Assert
    expect(visible).toBeTruthy();
    expect(await field.getText()).toEqual('testUsername');
  });
});

That may be a lot of new code to digest at once, so let’s go line by line:

import wdio from 'webdriverio';

First, we import the WebdriverIO client. This is the main package that will include the functionality we need to query elements from the app and simulate events on the emulator.

jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000;

This will tell our test runner (in this case jest) to make the tests error after a certain amount of ms has passed. Here we’re setting it explicitly in the test, but if you’re using jest you can modify the testTimeout property on your jest configuration. If you’re using any other test runner I’d recommend going through their documentation, most of them have a similar property.

const opts = {
  path: '/wd/hub/',
  port: 4723,
  capabilities: {
    platformName: 'android',
    deviceName: 'emulator-5554',
    app: 'my-app-name.apk',
    automationName: 'UiAutomator2',
  },
};

These are the configurations for our driver to know what to look for when using the appium interface to query for elements and save elements. You can read more about them here.

You can get the device name going to your emulator > help > about

In order to generate an apk from expo, you have to run the command

expo build:android

And wait in the queue for it to build.

In this case, I placed the downloaded apk in the root folder for my project, and renamed it my-app-name.apk.

Since we’re using WebdriverIO, the automationName will be UiAutomator2, since that’s how appium recognizes it.

Since lines 18-33 is mostly setup, we won’t focus on that for now, next part focuses on line 34 and forward

Writing the actual test

The idea of this test is just to showcase a normal flow on a test, therefore we will be dealing with a fairly simple use case: Checking that we have a valid username input

const field = await client.$('~username');
const visible = await field.isDisplayed();

The first line allow us to query an item by accesibilityLabel as I previously mentioned, for more information about specific selectors go to the appium documentation and the WebdriverIO documentation.

The second line checks whether our previously selected item is visible on the current screen, more information here.

await field.addValue('testUsername');

This line simulates user typing into the selected field, in this case, we’re inserting the ‘testUsername’ text inside the previously selected username field.

expect(visible).toBeTruthy();
expect(await field.getText()).toEqual('testUsername');

Lastly, we use Jest to check that the field is indeed visible on our Login Screen, and that the text on the given username field is the same as the one we wrote in it.

Running the test

Since we’re using Jest as our test runner on our react app, I’ve set up a command on my package.json to run both the appium server and run Jest in watch mode, it looks like this:

Here we’re using concurrently, a simple npm package that allows us to run several npm scripts at the same time, in this case we run the appium server and jest in watch mode, add their names and different colors to easily recognize them in the console, and pass the standard input to the jest command, so we can narrow down our tests or do things like run coverage reports.

With this done, we simply have to run npm run test:e2e on our console, and expect something like this

to be run, and something like this

to be the output. If so, congratulations, you’ve correctly set up your integration tests for your react native app

Wrapping up

While we’re far away from calling it a day on our e2e testing solution, the main setup It’s done. Next steps include integrating it with a CI/CD pipeline, and making it work on IOS platforms.

Speed Up Your Web Development: Sass

Pablo Marcano — Thu, 06 Sep 2018 22:30:03 +0000

This is the first of a series of posts that aim to make your life easier and enhance your productivity while developing websites, by giving you useful and industry proven tools and tips.

The scenario is simple, you're developing a website or web app, and for sure you want it to look as good as you can, which is obviously accomplished by using CSS. Then you find yourself repeating tag names, properties, colors, and having a gigantic main.css file (or maybe a lot of <src rel="stylesheet"> tags in your HTML header?). And what if you want to change something as the main color of your website? Dozens of lines changed just because #7a19a8 seemed slightly better than #7211a0.

Is there even a difference?

Well, to solve all of this and more, in 2006 the Syntactically awesome style sheets were created, Sass for the friends. Sass is a preprocessor scripting language that is interpreted or compiled into simple CSS. What all of this means is that Sass extends the CSS syntax, using a similar structure, with a lot more fuctionality.

Usage

All installation steps are covered in Sass' official install guide. In this post, I'm going to show you some basic syntax so you can make your CSS better since day one.

Variables

Variables are a core part of Sass, the premise is that you declare any data in the form of a valid data type in Sass, and you can use it all along your stylesheet. Here is the syntax:

Nested Selectors

With Sass Selector nesting we can transform this:

div {
  // Some properties for a div
} 
div span {
  // Some properties for a span tag inside a div
}
div p {
  // Some properties for a p tag inside a div
}

Into:

div {
  // Some div properties

    span {
      // Some properties of a span tag inside a div     
    }

    p {
      // Some properties of a p tag inside a div
    }
}

Basically, you can nest selectors within selectors to avoid repeating tags each time you may need to go deeper in order to win specificity.

You can also add pseudo elements and modify parent selectors inside themselves with the & symbol, this way:

div {
  // div properties
  &.steve {
    // properties of a div with steve class
  }
}

Mixins

A mixin is a Sass feature that allows you to define reusable pieces of code, and even allows parameters, just as functions, in order to modify its behavior without having to draw upon semantic classes as .margin-box-size-1. Let's see them:

@mixin box-size($size: 1em) {
    margin: $size;
    padding: $size;
}

You define a mixin by using @mixin, then you name it, in this case is box-size and write down the parameters it will receive, if any. In this case we also have a default parameter $size: 1em. The variables will be replaced with their value at build time, and everything inside the mixin will be placed wherever is used across the stylesheet. You call the mixin function by using @include followed by the mixin name.


div {
    @include box-size(3em);
}

// Will be replaced by

div {
    margin: 3em;
    padding: 3em;
}

Control Directives

With Sass we can bring common programming sentences into stylesheets, with control directives as @if, @for, @each and @while, we can sort out, repeat and take from a map or list any piece of code. Lets take a brief look over each syntax.

`@if`

The @if directive takes any SassScript truthy or false expression and executes whichever code sections applies:

@if (true) {
    // This code will always run
} @else {
    // this code will never run
}

`@for`

The @for directive is pretty straight forward, it runs the code inside the braces for a determined amount of times. The syntax is as follows:

// We declare a variable $i for the iterator, which starts at [from] and ends in [trough] values
@for $i from 1 through 6 {
    margin: $i+px;
}

`@while`

The @while directive works pretty much as the @for directive, with the difference that the condition of the loop to execute is entirely on us, and not only an incremental operator.

$execute: true;

@while ($execute) {
    @debug($execute);
}

Tip

@debug() will print out any value to the console while building, as its name says, its awesome for debugging!

`@each`

Last but not least, @each works slightly different from the other directives, as it goes trough a collection such a map or a list instead of simply a condition, and exposes the current value for you to use.

$colors: red green blue;

@each $color in $colors {
    background: $color
}

And that's it! With this easy tool you can start to write cleaner and more maintainable CSS from now on.

If you have any doubts you can find me on twitter as @stiv_ml. I will be more than pleased to answer any question!

This post was originally published in Kaizen Softworks Blog, that also happens to be where I work at! If you want to check more of my content you can click here.

How to get started on functional programming?

Pablo Marcano — Wed, 05 Sep 2018 03:34:47 +0000

I do not know anything about FP, and have done OOP all my developers life. I thought it would be a good idea to explore other paradigms just to learn. Could you give me some resources to start learning Functional programming? Which language should i use to do so? I have a background in Js and C# .Net.
Thanks!

How to get rid of the junior mentality

Pablo Marcano — Thu, 14 Jun 2018 00:55:05 +0000

Hello there!

Who are you?

I've been working as a developer for around 1 year professionally, i'm currently studying CS and always loved the idea of making things work as i wantby writing code. My current stack at work is mostly JS (Angular 2+, Node), and have worked with C# (.Net).

As a young developer being in the industry since so early, i've been really curious about how we developers define ourselves by 'Ranks', when do you become a senior developer? how do you do it? what you should do/know?, I still don't have answers to those questions, but i realized there's a key factor that influences every developer carreer, no matter how much time and experience they have...

Mentality

When I was just starting, i had to fight with the overwhelming ammount of things that seemed necessary to learn in order to call myself even a developer, let alone working as one. This takes us to the first point:

Don't be afraid of what you don't know

Nobody knows everything, and this is specially true in programming. No matter how many years of experience or how many languages a developer claims to know, what really matters is how do he/she approaches learning new things. And this is an attitude that will open you a huge ammount of opportunities. Don't be afraid of spending hours on a problem that might seem the simplest of them all, just because you don't know how does x thing work, as long as they are spent researching and actively working on understanding it. In the end, you might have learned more than what you were first looking for. It's also important to have in mind that ...

Things may take time

As every other discipline, being proficient as a developer will take time, understanding some things will take time, and making things work will take time, but you should always loow forward to complete what you're doing, because stress and fatigue may come, but will always pays off in the long run. You will be a better developer, and may be able to complete any similar task in a better faster and cleaner way sometime in the future.

Ask what needs to be asked!

And I can't stress this enough. Asking other developers when you're new into programming is one of the best and most enriching things you can do, because most of the time people will be eager to help you and you may learn a whole lot of things in a way it's really hard to reproduce any other way. Most experienced developers also make questions all the time. Not knowing something doesn't make you less of a developer.

What else would you add to this list? when did you stopped feeling as a junior?Leave it in the comments!

Pablo Marcano
Full Stack developer Working @ Kaizen Softworks in Montevideo, Uruguay