With the new year approaching, it feels like everyone is sharing their achievements and setting ambitious resolutions. Social media is filled with milestones, career moves, and personal victories, and it’s hard not to compare. My goal-oriented brain, of course, jumped right into overdrive, making me feel like I’ve done nothing with my life this past year.

I’m still working at the same company, in the same position, as part of the same team, and on the same product. I make relatively the same amount of money, have the same circle of friends, and the most exciting thing in my life is an upcoming trip — which is stressing me out more because of the cost than anything else.

Looking back at the lifelong goals I’ve envisioned for myself, I worry that if I’m not actively moving toward them, I might never achieve them. I shared these fears with my therapist during our last session, and she eventually stopped me to list all the things she believed I had accomplished — like always prioritizing my mental health.

Don’t get me wrong; I didn’t disagree with her. I could see the things she mentioned, but the difference was that I didn’t view them as “achievements.” To me, they felt more like simply “living” my life. That conversation got me questioning my entire approach to thinking about goals and accomplishments.

When we start listing goals and setting timelines, we often reduce those goals to quantifiable, measurable outcomes. This mindset can be incredibly useful in professional settings. But the truth is, this kind of reduction — or what I like to call compression — misses out on many qualities that play a much more crucial role in our happiness and life satisfaction than just the numbers.

It’s like compressing a RAW image into JPEG format. Sure, it’s easier to share and faster to load, but it loses so much valuable detail that created the original image in the first place.

Let’s take my professional life as an example. I’ve been a Senior Software Developer at my company for a little over two years. On LinkedIn, it might look like nothing has changed during that time. I’ve held the same title, carried the same responsibilities, and — on paper — there’s no sign of growth. To a goal-oriented mindset, this might seem like stagnation, especially for someone with great ambition. To that person, I might look like I haven’t been working hard enough, because I’m not hitting new milestones every year.

But the problem with measuring growth purely by promotions is that it overlooks so much more important information.

In the past two years, I’ve become a better-known person within my company. I hosted an internal event that connected me with dozens of colleagues worldwide, creating meaningful professional relationships that are invaluable — and portable — even if I change jobs.

Within my team, I’ve gained the trust of my teammates. They now reach out to me first — even before consulting some of the “bigger brains” in the company. I’ve also built a strong, respectful relationship with my manager, which has not only created a more secure workplace for me but also allows me to take bigger risks, knowing my manager has my back.

All of this growth has happened while I’ve held the same title, earned relatively the same salary, and worked within the same team. So, is it fair to say I haven’t grown? Absolutely not. I know I’m a better professional today than I was when I first got promoted.

What about financial growth? Well, financial growth doesn’t just happen when you get a raise or sign a new contract. People often assume that landing a higher-paying job automatically makes you wealthier, but that’s not always true. A higher salary may give you more room for spending, but spending doesn’t make you rich — saving does.

I’ve seen people earning significantly more than me who live paycheck to paycheck, with no financial safety net to fall back on if they lose their jobs. They may live in fancier apartments or travel more often, but they’re either heavily in debt or one missed paycheck away from financial stress.

I didn’t grow up with money, so it took me a while to have enough to even begin learning how to manage it. But now that I know, I understand that building sustainable, healthy financial habits takes time and effort. I’m not saying that financial growth shouldn’t be a goal for anyone — it definitely is an important factor for a better life — but instead of focusing on growing your income, the focus and goal should be on your general wealth or net worth. The goal should be ensuring that your overall financial health grows steadily over the years.

By now, I think my point is clear. Sometimes, on paper, life seems to stay the same, but building quality — whether in your career, relationships, or finances — takes time. With every step of measurable progress, it’s essential to pause and ensure you’ve gained the strength and foundation you need for the next step. And it’s perfectly okay not to have visible, annual reports of progress to show the world every single year.

This year, I’ve decided to set broader, more meaningful goals for myself, paired with a few actionable steps. Instead of obsessing over the details, I’m focusing on the big picture — and more importantly, on how I carry myself throughout the year. My progress might not always be flashy or visible, but as long as I’m building a life that aligns with my values and priorities, I know I’ll be moving in the right direction.

My Experience of learning React.js in less than two months

I have been working as a Vue.js developer for two years straight. And I can not lie about how much fun I had with Vue.js, developing all kinds of websites. But in my new job, I have been asked to learn React.js. As a frontend developer you should always know that frameworks come and go but what always remains is HTML, CSS, and Javascript. So I need to learn React.js for this new job and I had to do this fast and start my work as soon as possible.

For learning new concepts I usually start with a video tutorial and learn the basics and then make some playing-around-simple-projects to feel more comfortable with the new API. Later, for a deeper understanding of each concept, I search online and read more in-depth articles.

But with the React.js, I was already familiar with lots of the basic concepts like components, V DOM, reactivity, etc. Also, I had enough experience in developing web applications like SPA and SSR apps that makes a React.js crash course too boring for me. Besides this time I didn’t have time to take a 30 hours course. So I came up with a new approach that unexpectedly gave me the knowledge to start my work as a React Developer in a short time.

In this article, I am going to share my RoadMap and link to some of the resources that helped me throughout the past couple of months to learn React and start my new job confidently.

Step #1: Overview

In my mind for learning any new frameworks or languages, there are two phases of learning and I gave them these two names: Learning the Concepts and Learning the Syntax.

For example, learning the definition of components in Vue.js is a concept but learning how to write a component in Vue.js is in a syntax category. I usually learn both of these sides synchronously. But this time, as some of the concepts were pretty similar in both frameworks, I’ve decided to learn the concept before the syntax.

First, I did general research about the highlights of React.js as a library and learn the most famous terminologies.

So your first step is to pick a pen an a notebook and jot down the answers to these questions (Keep the answers short and right to the point):

• How React works?
• What is JSX?
• What is ReactDOM?
• Class Components vs. Function Components?
• State vs. Props?
• What are the lifecycle methods?
• What is a Higher Order Component (HOC)?
• What is Redux?
• What is setState? Why is it an async function?
• What is render() method? What does it return?
• What is Create React App?

You can find the answers to most of these questions on the React documents and/or on other articles or videos on the web.

Here’s one of the articles that provide a good short answer for the questions above:

Frequently asked: React JS Interview Questions and Answers

Keep in mind that this step shouldn’t take more than a day. The main goal here is to understand the general concepts.

Step #2: Map your knowledge

Now that we know React more than a title let’s take a moment and compare React and Vue in our mind and map what we know from Vue.js to what React has in common:

1. Hopefully, they both have components. Although there are some fundamental differences between components in React and Vue, they both use components as building blocks of a frontend application.
2. Components in React and Vue receive data from parents using props.
3. Similar to Vue, props can have a default value and validations in React components.
4. States in React components are pretty similar to data in Vue components. But states shouldn’t be mutated in React and instead, they should be updated by setState.
5. React doesn’t have directives and modifiers.
6. They both have lifecycle methods.
7. …

As you have noticed so far there are a lot of similarities between React and Vue in concept.

Step #2: Let’s write some React

Now that we know React more than what we thought, let’s jump into the code and get our hands dirty with some real React code. At this point, your best friend is going to be the React documents and Stack overflow. As a warm-up exercise, you can follow these steps:

• Create a new project with Create React App and build your very first function component, that says “Hello World!”.
• Now pass a name to your component from props, so that your component can say “Hello” to any provided name. Set “World” as a default value for your name.
• Now pass a list of color codes to your component from outside and make sure you always receive a list for colors and make it required. (Hint: Props Validation)
• Read about React hooks and useState.
• With the knowledge, you have from the previous step, add a button to your component that changes the text color randomly to one of the colors you are receiving from the props.
• Read about useEffect and dependencies.
• With the knowledge, you received from the previous step, change your component so that it prints “Welcome to this Component” only the first time it renders.

Great job! Now you know React components even better than before.

Step #3: More Studying

Before you start underestimating React complexity, let me give a long list of concepts that you need to master, before starting a real project.

• Read about conditional Rendering and loops in JSX
• Learn hooks more deeply
• Learn about Context and it’s use-cases. Learn how to use Context with Hooks.
• Learn Redux and more importantly the Redux terminology and structure.
• Learn about routing in React applications.
• Review the whole concept of this in JavaScript before you create your first Class Component.
• Read about React performance and what is an enemy for that.
• Install and discover the React Devtool.

For learning these concepts you can either read the official documents or any other sources that suit you. At the end of this article, I will list some of my recommended resources.

Step #4: Now you know better

This point is not the end but the starting point of learning React.js. Comparing headlines of this article with React documents shows how little we have covered so far, but from now on you know enough of basics to decide what you need to learn next. Besides, you can start any simple project at this point and keep on learning while you are developing a React application.

I hope my roadmap of learning React enables more Vue.js developers to add this new skill to their toolbox.

My Recommended Resources

• Complete Intro to React by Brian Holt (free)
• Getting Started with Redux By Dan Abramov (free)
• Kent C.Dodds Blog (free)
• Frontend Masters: React Learning Path (paid)
• Frontend Masters: State Management with Redux & MobX (paid)

A React.js Roadmap for Vue.js Developers was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Git without a doubt is one of the essential tools for every developer. As helpful as Git is, not following best practices will make it completely useless. That’s why there are different standard workflows to make most out of Git and its awesome features.

For a long time, my inception of Git and GitHub was a tool that back-ups the codes and let us access them online; Which was not completely wrong, but there are so much more about them that I didn’t know until I start my work as a developer in YasnaTeam.

In our team, about 10 developers are actively working on the same repository. Having the same habit and so-called culture is necessary to avoid conflicts and chaos. With over 100 commits per day, things could get out of hand very soon. To avoid such problems we implement a modified version of Gitflow.

How it works

Instead of having one single master branch, we have another extra branch nameddev. These both branches are locked and no one can push directly into them.

master is reserved for production only. ‌After testing new features, the repository owner updates master before each release.

dev is the default branch that all of the developers create a branch from and merge back into. dev is always ahead of master and it’s the only branch that will be merged into master, frequently.

Naming Branches

We have a pattern for naming our branches.

[Module Name]-[Type]-[Detail]

// Example
users-fix-attach-roles-issue#765

Module Name

Since we have a modular structure in our code base, changes related to each module should be committed on a separated branch with the module name. This part could be removed if you don’t have such structure, in your project.

Type

According to the type of task, developers should choose between one of these types:

• feature
• enhance
• cleanup
• refactor
• fix
• hotfix

Type hotfix is for urgent fixes on the master branch and won’t be used that often.

Detail

The detail is a short description of what is going to be delivered by the branch.

This branching rules force us to separate each task to meaningful chunks and merge frequently into dev and always have fresh branches. One great side-effect of this approach is to minimize conflicts.

Commit Messages

In order to have clean and descriptive commit list, we also have a naming rule for commit messages (I love rules!).

[[Module Name]] [Commit Message]

// Example
[users] add fetch users endpoint

Having the module name in each commit message might seem redundant since we have the name in our branch, but the truth is after merging all branches into dev (or master), looking at the commits history you cannot say which branch each of the commits was belonged to. Because right now they are all belonged to the dev (or master) branch. In order to filter through all commits easily, we need to have the module name somewhere inside the commit message.

The commit message itself should complete the sentence “This commit will…” grammatically.

Pull Requests

Title

Title of the pull request is automatically filled with the branch name. In case the branch name is too generic, more details are expected to be added.

Body

The body should contain details about the pull request. In our workflow pull requests are usually related to an existing issue. We create an issue for each bug or feature. So we link to the related issue inside the pull request body. We also mention highlights of the changes that are made inside the pull using bullet points. We have created a template for our pull requests, to facilitate the process.

Review

Code review is one of the most important parts of our daily job. Once a pull request is created, the creator should choose two of peers to review the code based on some prespecified criteria.

Once the pull is approved by reviewers, the creator can merge into dev and delete the branch.

We have been using this workflow for more that one year and update frequently based on our needs. Do you use some other git workflows on your team? Let me know how they are.

Access to XMLHttpRequest at ‘http://backend.test/api/data' from origin ‘http://localhost:8080/' has been blocked by CORS policy.

You can watch this article’s video on YouTube.

This error has been my nightmare during the past two months. I tried different solutions available online, from Installing extensions on my browser to altering .htaccess file of the backend project locally, but none of them was ideal. Last night when I was messing around with my Apache configurations I found out that this error could be handled simply by Vue config file provided by Vue CLI 3. If you are struggling with the same problem, you are reading the right article.

To understand the problem and the solution better let's talk a little bit about the error.

Why do we get CORS error?

Browsers protect web applications to interact only with apps that are from the same origin. This is a policy called same-origin. But sometimes it is required to send requests to another server. CORS or Cross-Origin Resource Sharing is a standard that makes cross-origin requests possible by setting specific headers for requests.

In my case, I was serving my Vue application using Vue CLI serve command on localhost:8080 and my backend project was running by apache on a virtual host; Completely against same-origin policy. If somehow it was possible to send Ajax request to the same origin, the problem was solved. There are different ways that we can achieve this behavior by touching server configurations. Since we are frontend developers and server configuration might be different in production, we need some solution that is applied only during development and could be handled in the frontend.

So, how to have the same origin?

Hopefully, Vue CLI provides some properties to achieve this behavior. First, we need to set our Ajax request domain same as our frontend application; In my case: http://localhost:8080/ .

To configure the Vue CLI server, we need to create a vue.config.js file in the root of the frontend project right beside package.json, containing:

// vue.config.js
module.exports = {
  // options...
}

Inside the module.export you can add configurations for your development server using devServer object. Now we want to configure our development server to proxy API request to the backend domain.

devServer: {
        proxy: 'http://backend.test/',
    }

The proxy property is a string of the backend host.

This will tell the dev server to proxy any unknown requests (requests that did not match a static file) to http://backend.test/ __ Vue CLI Configuration

Now you need to serve the app again so that the new configuration applies to the server. And TADA! Your requests don’t need CORS headers anymore.

RECOMMENDATION: I highly recommend using variables inside .env file for storing backend and Ajax base URLs, since the value will be different during production.

How to deal with CORS error on Vue CLI 3? was originally published in Vue.js Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

One might need to use some external static data written in a JSON file, in their application. One simple solution is to place the JSON file inside your src directory and then import it into your js file; Using this method you can not access your JSON file and change it in the production mode; Because the JSON will be included into the bundled JS by Webpack.
But sometimes what you need is a JSON file separated from your app.js, so that you can change the content anytime in future, without rebuilding the whole application.

In Vue CLI 3 document, it has been offered to place such static files in public directory, hence the file won’t be processed by Webpack and will just be copied after building the application. But importing a JSON file from the public directory is a little bit more tricky.

1. Install Axios

Accessing the data of a JSON out of your application is basically similar to reaching out to an API and getting a response. The only difference is, you are requesting a file placed right inside your own public directory. So the first thing we need here is an Ajax handling tool. I will use axios in this article but feel free to use any other alternatives.

npm install axios

2. Create an env file

Create a .env file in the root of your project and add your own base URL to the file:

VUE_APP_BASE_URL=http://localhost:8080/

3. Get base URL in your component

Inside your component, create a data property to read base URL from .env :

data() {
    return {
        baseUrl: process.env.VUE_APP_BASE_URL,
    }
}

4. Fetching data

Import Axios into your component.

import axios from 'axios'


export default {
...

Now You can create a method for fetching your JSON data:

methods: {
  fetchData(){
     axios.get(this.baseUrl + 'test.json').then(response => {
        console.log(response);
     })
  }
}

You can escape step 2 and replace the this.baseUrl with a simple ‘/’, but it is recommended to use the .env file.

The last step is to call this method wherever you need, Like when the component is created:

created(){
    // Fetch Data
    this.fetchData();
},

The response of the Ajax call contains your JSON content.

I am a front-end web developer. I had started learning the basics of the web about more than two years ago when I knew absolutely nothing about programming. The day I started learning HTML I even had no idea what the difference between UI design and development is. Being a programmer never was on my wish list. I always wanted to be an astrophysicist. That’s why I choose physics at university. In this article, I’m going to talk about my challenges during this path of changing my life and profession.

I always was good at math and physics. But at university when I started studying physics academically, I realized that I don’t want to spend my whole day reading physics books. I enjoyed the classes, and I never missed any. But at home, I didn’t want to study more, and that didn’t seem right.

In fact, I had a misunderstanding about my interests and purposes. I enjoyed learning physics, but in action, I didn’t like to be a physicist. I got bored so fast. There was some part of me looking for a job to solve problems with creativity and then be able to show off the result like a piece of art, but in physics, I couldn’t think of that type of job. With that, I shouldn’t keep studying physics any further. Studying would eventually end, and I need to look for a job that I could do 9 hours a day and don’t hate my life every Monday.

Be Honest and Realistic

Facing this fact wasn’t easy for me because after years of planning, now I had no plan for my future. I didn’t want to believe that physics is not for me, but I didn’t have more time to waste. I need to find my best job before it’s too late. So I came up to a formula for myself:

1. I made a list of my interests and abilities realistically.
I was good at solving problems, and I had a taste for art and design. I always kept myself close to technology and had an undiscovered enthusiasm for working with my computer.

2. I start looking for attractive jobs and then consider their prerequisites. If the job is not interesting, it’s out of the list.
I am interested in photography, but as a job, it was rejected, because I didn’t like to discuss prices with customers, about my beloved photos.

3. I imagined myself doing the job for a constant 9 hours a day. Boring? Not my job.
I crossed out astrophysics because it consists of days of data analyzing for finding something valuable, although the astronomy itself was always attractive to me.

The process of filtering jobs took me almost one year until I finally came to the answer of web development. As a programmer, I need to solve problems every day and to work in client-side gives me the chance to be involved with the design and creative ideas. The job was interesting, and learning materials were mostly available online. And last but not least I never get tired of working with computers. That seemed to be a good choice.

Next Step, family, and friends

Making a big decision that would influence your life and future, will probably involve more people than just you. Family and close friends would definitely react to your new decisions, so convincing them is unavoidable. To be honest, I believe it’s even good for yourself. Convincing my mom for giving me a one-year timeout to study at home and not applying for a master degree, actually helped myself realizing how decisive I really am about this change.

But don’t forget you don’t need to talk about your new plan to everyone. Some people will judge your decision anyway, but they will be convinced once you achieve your purpose and succeed. During that one year that I was studying at home, I was always getting messages of worried relatives who wanted to find me a job and get mad when I refuse to apply.

Giving up is part of the show

I cannot count how many times I gave up and end up crying. I was entering a field that I had no experience. Every concepts and techniques were new to me. Each article I was starting to read has led to a bunch of other googling for finding the meaning of an unknown term. But at the end of the day, I knew I was one step closer to the best job I could have.

Sometimes giving a couple-days break to yourself will help to recover the energy and eagerness. I tried to keep atmosphere fun with playing music while practicing and even dance-coding which is my invented method of coding _Whatever keeps you away from the stress. I deactivated my Instagram account to prevent comparing myself with others who were having their routine life with no turning point; Instead, I started a new twitter account and followed new people to create a new environment of people around myself.

Making a big decision for changing your job is hard by itself, it’s even harder when you are in the middle of doing something else. But having a job you love can change your entire life and moral. You will spend the most efficient time of your days, most of the year, at work. If you don’t enjoy what you are doing, you can’t enjoy your life. If you feel like that you need to change something, change it now. Don’t live your life for weekends, live every day of your life.