DEV Community: Miguel

I am publicly committing to the #100DaysOfCode!

Miguel — Sat, 04 Apr 2020 17:13:57 +0000

Commitment

April 5, 2020: I am committing to the #100DaysOfCode challenge!

My reason for taking part in this challenge is to sharpen my skills in tech that I know and love.

I want to create flow between the day-to-day and build momentum towards making coding a habit outside of work.
I want to use this time to develop my portfolio and showcase my work.

Plan

For the challenge, I want to see a project from start to finish. I will build a mobile app using Vue and Quasar to solidify my skills as a Vue developer while also learning a new framework at the same time.

The app I will work on would be Budgetier, an expense tracking app.
I will track the time I spend on the challenge.
I will use Notion as my project management tool.

Goal

By the end of the challenge:

I will have finished Budgetier and deployed it to the Play Store.
I will not have skipped a day.
I will have a portfolio up.
I will work on the challenge without compromising my health and relationships!

Tips on interviewing junior devs?

Miguel — Tue, 14 Jan 2020 16:41:45 +0000

Hey guys,

Our company will be hiring new devs in the coming days, and I volunteered to be involved in the hiring process, specifically with face-to-face interviews.
For background, I am also a software engineer and am taking on additional responsibilities for the growth of both our company as well as myself.

Do you have any tips on what to look for when interviewing junior devs?
Are there any red flags that I should be wary of? How about green flags?
What questions can I ask that would tell me a lot about a developer? We do have an extensive list of questions prepared but I would like to see if we might have missed any good ones.

Thanks!

A House is not a Home: Vue Slots Explained

Miguel — Wed, 03 Jul 2019 17:15:32 +0000

Cover from Design vector created by freepik - www.freepik.com

Vue slots are a way of telling Vue where to place any content we write within a component's body. Today, we will be building houses to learn about Vue slots!

Before we begin, let's imagine Vue components as houses. For us to be able to enter a house, we would need to use a door; In our component, our <slot> tags would serve as a door for our other components to enter. Let's make our first house!

We use the slot element to tell our component where to display content. If we were to include our HouseComponent into a village component like so:

We see that our component placed all its child elements into the living room. Vue does this through the default slot.

Adding Rooms with Named Slots

Having a house with just a living room isn't a comfortable place to live in; let's introduce more rooms into our house component using named slots!

We can add the name attribute to our slots to, you guessed it, name them. This gives us the freedom to position parts of the content within our template.
Let's refactor our HouseComponent by adding more rooms and placing other elements within those rooms:

Let us notice two things about our new House:

First, we added a named slot called dining-room at line 8. To put content into this slot, we use the v-slot syntax in line 22. From here, we can see that chubbs and food are both placed between the two chairs in the dining-room: exactly where we placed our slot.

Second, everything else between the <house-component> tags that are not part of the named slots were rendered at the default slot, ie. within the living-room.

When this is rendered onto our page, it will look like this:

As we can see, we can use named slots to define layout for our markup. This makes components easy to compose and reuse. However, let's take it a notch higher, and introduce the concept of scoped slots to further improve our humble home.

Adding Furniture with Scoped Slots

Rooms in a house are not only defined by their position within the building, but also the activities that can be done within them! In the same way, Vue slots are not only a means of composing your components visually, but may also be used to expose interactions and data. This is done through scoped slots.

Components can bind data or methods to slots, like how they would with props. This allows the parent to interact with the component through the scoped slot. Let's add interactions to our HouseComponent to really call it a "home".

There are a few things we should dissect before moving on.
First, notice that we added v-bind directives to our named slots. These will allow the parent component to access anything bound to the slot as slot props. We added the <script> portion of the component to define our methods and data. Let's now add furnishings to our new home!

As we can see, we still use the v-slot syntax; however we appended a value to it. Each of our v-slots have access to different slot props, each containing the methods we bound to them in our HomeComponent. This means we can have different houses with different layouts, elements, contents, even components! Yet they all still have access to the functions of our HomeComponent; in our case, switching the channel, watching TV, and eating together.

Way Back Home

To conclude, we learned about Vue slots: how we can use named slots to lay out and compose our components (define our rooms), and how we can use scoped slots to expose functionality (add furniture).

I hope you found this article informative and easy to understand. Please do let me know if I have any errors in grammar or lapses in information that the reader would find helpful.

Thank you for reading, and good luck in building those houses!

Quick Vue Tip: Cleaner Data Fetching

Miguel — Tue, 07 May 2019 10:43:45 +0000

Quick Vue Tip: Fetching Data

A common use-case we encounter is needing to show data fetched from an API using a Vue component.

For example, say we have a Vue component called ViewAvenger.vue which shows the information of an Avenger based on its id. A common way of doing this is by passing an id prop to our component. The actual API call is then handled by the component itself via a method call getData.

Loading data upon mount

Say we want to get our data immediately when the component mounts. We then add the mounted lifecycle method into our component.

Re-load data if the `id` changes

This works fine, but what if our id prop changes? There would be no way for us to call getData. To do that, we would need to watch the id prop for changes.

By defining a watcher, we tell our component to call the getData method whenever the id prop is changed.

Refactoring for simplification!

Our component works just fine as it is right now. However, how can we rewrite it to be more concise?
We use watch props!

Watchers can have the immediate prop, which tells the component to fire the handler method immediately. This means that we can get rid of the mounted method, saving us some lines of code.

Finally, we can simplify this even further! We can move our whole getData function into the watch handler. As an added bonus to readability, we can remove the this. prefix from the API call since we can simply use the id argument of the handler function!

And just like that, we effectively saved ourselves some more lines of code.
I hope you found this tip useful, and thanks for reading!

Music vs Podcasts while coding? Any recommendations?

Miguel — Wed, 13 Mar 2019 05:04:45 +0000

I understand that developers listen to different things while coding. I want to expand my audio palette for my code sessions, and would like to get your opinions!

So, do you listen to music or podcasts when you code?

What specific genres / playlists / artists / shows do you recommend?

3 Changes that Helped Me Become A More Productive Developer

Miguel — Sun, 10 Mar 2019 18:47:20 +0000

Short Introduction

Hello and welcome to my first post on Dev.to!

I've been freelancing for two years, and when I first started out, I really enjoyed the freedom of having almost complete control over my own time. I can basically work whenever and however long I want!

However, as any former young, wide-eyed, free-spirited professional can attest, not having any sort of routine for your work would only lead to the cake hitting the fan. I had really slow days when I just could not code, and would churn out really sloppy work.
On the other extreme, I also had 13-hour days where I was sitting at my desk programming from 10am to 1am. This quickly and predictably led to burnout which not only harmed my mental health, but also affected by relationships with other people.

It was then I decided that things had to change.

Today, I would like to share the 3 changes I made in my work day that not only helped me break out of burnout hell, but also continues to boost my productivity.
Let us begin!

Kick off: Perform a simple task first.

I heard this tip from a lot of blogs and podcasts; The idea is that being able to achieve even a simple task at the beginning of your day would get the ball rolling for more complex tasks later on. This may not be necessarily related to coding. Personally, I begin every day by first making my own bed. Not only will this act get me out of bed, but it would also eliminate the stress from having a disorganized room.

Whatever you decide to do, the important thing is to perform the simple task mindfully; you are getting into the mindset of preparing for your day, and not just going through the motions of doing a chore.

Clock in: Choose a productivity technique and commit to it.

Once you've had your morning coffee and warmed up, its time to actually churn out code. During this stage, I find it very helpful to follow any sort of productivity technique. There are many methods that work for a variety of folk; what is common among them though is that your work flow is not a single 8-hour stretch of hacking at a keyboard. These methods usually involve a period of focused work, wherein you shut out everything else and work on whichever task is at hand, but then a period of short rest follows. I personally follow the pomodoro technique using an app with 35-minute work / 5-minute rest intervals. Whichever method you choose, what matters is that we have a plan for doing work, and that we commit to it.

Wind down: Respect your down time.

Finally, one of the hardest parts of development is knowing when to stop. As I mentioned in the introduction, we programmers have a tendency to spend long periods of time working on our code because we become so attached to our creations; It is by our hands that these things have come to be, after all! We are solving an ever-growing puzzle, and sometimes we have a difficult time knowing when the time for our work day to end has come.

I used to stress out about the time I spend not doing work because I felt I was wasting my time. There will always be another bug to fix. There will always be that small styling for that button that just seems a bit off. There is always something that needs to be done.

However, we must remember that there is more to us than just our code. We still have relationships, hobbies, and our own physical and mental health to care about. We must not take these things for granted because these are what ultimately ground us and make us holistic and productive developers.

Final Words

To summarize, the three changes I mentioned all boil down to discipline. Development is a tough and mentally-challenging work, and yes, we will need to put in the occasional all-nighter sometimes. However, we don't need to break our backs over our work on a daily basis. What matters is to have the willingness to do so, and the discipline to take control of our day.

Kick off, clock in, and wind down.
Thank you for reading!