Forem: 404answernotfound

A History of Javascript and its evolution

404answernotfound — Sun, 24 Apr 2022 14:15:08 +0000

And here we are with another brand new episode of 404answernotfound Podcast. We just got back from an amazing conference in Verona about Javascript and I just couldn’t hold this episode anymore.

Link to Podcast episode

Before we start delving into today’s topic: yes, this is still a techy podcast but I do love talking about how things work and how ideas and topics came to be in the first place so, here we are.

“Javascript”, “EcmaScript”, “The thing you program the web with script”. Lots of names, a single history to be told and that’s exactly what we will do today because today, it’s all about Javascript.

I’d also like to have a shoutout for the amazing people at Grusp, a community that organizes tech events in Italy and online. Check them out on their website https://grusp.org/. This was not sponsored in any way by them, I just love their work!

My name is Lorenzo and I welcome you again to 404answernotfound Podcast. And now, let’s go ahead and start this episode.

Podcast Intro

Welcome to 404answernotfound, a podcast about the latest technology trends and innovation in the software engineering field and so much more. I am Lorenzo, your host, digital techy nerd creating content for probably unexistent listeners and readers, and a finder of problems to known solutions.

This podcast is hosted by 404answernotfound.eu so if you are interested in technology you should go and check out our new blog posts and see if there’s anything to your liking!

So, we’ve been using it for quite some time now, and each and everyone of us users of this language can go and getElementById any time we like, which is cool, but how much do we know about the history of this language?

Welcome again to this brand new episode where we talk about Javascript History and how it became the language we all love and hate today!

Let’s start with a question. How many days would it take you to develop a new scripting language? That’s one of the things that can make you go mad about Javascript.

Javascript was born out of necessity and marketing from the great mind of Brandan Eich, a Netscape programmer, that created it in just 10 days.

For those of you who are unaware of what Netscape is, it used to be the most used browser of all time back in the 90s, before Microsoft came knocking with Internet Explorer and opened up the market for all the players we have now on the field.

But back to the topic at hand, as we were saying, Javascript was born from a relatively small time effort (again, 10 days) and was at first called Mocha. Lovely name.

Later on it would go and be named “Livescript” and “Javascript”.

As many of you might have wondered, does Javascript has anything to do with Java? The name seems to imply so.

Well, it doesn’t technically but it used to be connected to Sun’s Java language as Netscape felt its market shaking upon entry by Microsoft with its very own Microsoft Explorer. You might not like it now, but back in the day it used to be a good and new browser.

When that happened Netscape thought it necessary to bring on an alliance with Sun Microsystems, who was in 1990 developing Java. Sun’s apparently wrongly thought of Javascript as just a mean to make its own ecosystem stronger, what no one could predict was that this language, which had little to no big usages at the time, would become what we know today as “The language of the web”.

That’s when it happened. Java would be to the computer what “Javascript” would be to the scripting environment of the browser.

It was 1995 when Eich created what today is, arguably, the most used language in the tech world.

What started out as a browser turf war spiked engineering life onto new tech and language possibilities.

The start wasn’t all that good: Javascript was mostly used as a UI glue to be used by designers or engineering teams but it didn’t have all the capabilities we are so much used to today.

A good choice was that made by Netscape to hand over the standardization to a third party body that would allow for the flourishing and engineering advancement of the language of the web.

In 1997 the standardization process for Javascript began as it joined the ECMA family, thus becoming ECMAScript. It had many revisions and changed quite a bit over the years to become what we are using today.

Now, if we were to search for naming issues in the Javascript language and what came out of the standardization, we would probably go mad because it goes from version 1 to version 6 to version 2015 and back to version 7 and so on. Now, this is starting to look like a joke but JS did bring some naming issues on the table. Not that it matters that much, but it does help to know which version is which when we have to choose our next compilation runtime, doesn’t it?

What’s useful to know is that now the versioning of ECMAScript aka Javascript, has abandoned the previous counter to use the “year of release” counter as versioning. As such, what we know as ES6 is really ES2015.

Will this change our ability to use Javascript in our best interest and knowledge? Of course not, but it’s always useful to know where the language is going, isn’t it?

I think that Javascript did a really good job at becoming the standard and de facto language of the internet.

On its own, Vanilla Javascript (the javascript without any libraries and frameworks to change its usability), is not so bad now. With just a few methods and properties we can have total control over browser events and the DOM.

It used to take 20 lines of code to do an XHR request, now lots of people don’t even know what XHR is! And it’s good! We call it Fetch now! The Fetch API!

What about server-side programming? You had to know at least 4 languages and 1 database to be a full stack developer. Now, all it takes is Javascript done right!

Front End? Javascript

Back End? Nodejs, which is Javascript

Databases? Any ORM with Javascript, like Sequelize, TypeORM or my favorite one, Prisma!

What we must be thankful about is surely the amount of ideas, concepts and actual work done by the community around Javascript.

Every day new libraries, frameworks and command line interfaces are born. Every day you get a mix of components that create an entirely new way of programming.

If you are a cook or a food lover, and as an Italian I definitely am, you should know that it’s not just about the ingredients (which need to be really good) but it’s also about the chef, the concept behind the plate, the presentation of the plate and how all the flavors blend together to create the expression of art. Maybe I went a little too far with this example but it does have a point.

Whether you are new to javascript or to programming, whether you are a seasoned developer with experience in other languages or a professional with Javascript and all of its features, one must acknowledge the fact that Javascript is ever changing, evolving also based on the community and also an expressive form of programming art.

So, a good question that any developer new to Javascript usually asks is: where do I start?

Well, I’d advise anyone to start with the basics and if you are already a programmer in other languages, statically typed or not, it might take you a few hours or a few days, depending on your experience on the subject.

The beautiful thing about programming paradigms is that most of them time, if you are experienced enough, you can glance into another language and have an idea of what is happening behind the curtains.

As an example: I am not a Swift connoisseur but if you ask me to read a Swift program, I can probably get something out of it, even without knowing the language. That’s because quite a few modern programming languages all comes from the same roots, or C-like languages, if you will.

But let’s for a moment pretend we have no experience whatsoever about programming, at all. If that is the case, and it can be for someone, Javascript can seem a little bit daunting.

Why, you would ask, would a language built for “everyone” be daunting at all? Well, there’s good and bad in having the biggest tech community ever: everyone gets a say, everyone contributes, everyone can bring something to the tech table. For a seasoned and experienced developer this sounds like a good thing and it is, but at the same time, if you were to not know anything about programming or web programming AT ALL, wouldn’t it be kind of too much to handle?

So, back to pretending we don’t know anything about programming, let’s delve into it:

“How do I start programming for the web? How can I build my own app?”

Billions of pages come out of any search engine search if we are to look for results based on our query, the request we just phrased. Almost 2 billions results by asking “How to build a web app”, and I’ve been practical about it cause I specified that I want my app to be for the web.

If we were to take away the “web” keyword, the results would amount to 4 billions.

I’m sure that can look intimidating for someone approaching the web programming world for the first time.

Not only that! Let’s say you managed to learn the basics, now everyone around you is shouting about the strength of one framework or library over the other!

“It’s react! It’s react!” - shouts the front end developer

“No, it’s gotta be Vue!” - says the other front end dev

“Ahm, guys, Angular has definitely more impact and has all the features you need built in!” - screams another afecionado

Truth is, the world of devs is full of people with preferences and they are more than happy to talk about them, advocate their choices and build communities around them. That’s why Javascript is evolving and changing so fast. That’s also why sometimes Javascript can seem a little bit puzzling in some choices.

So, to answer the question that started this discussion: there’s no easy way. But there is a simple one. Read the docs, talk with people, check out project implementations and see which one suits you and your programming way so that you can enjoy using the language and its features, along with frameworks and libraries.

Don’t go with React just because anyone is, go with React if you enjoy it. Make the technology work for you, not the other way around.

How to become a Senior Software Engineer and beyond

404answernotfound — Sat, 16 Apr 2022 10:17:42 +0000

This article is a written take on the Podcast episode of 404answernotfound, on Spotify. If you would like to listen to the episode directly, go to this link: 404answernotfound Podcast

Image courtesy of @sigmund

So what are the key differences between Junior and Senior level software engineering roles and how can we achieve professional growth?

If you are coming from a more “nerdy” background like I am, I often thought about growth as one does with role playing video games. You have a hero, yourself, and you have to level up and gather better gear to work towards your objectives til endgame.

It is kind of a fantasy style rally to the throne waiting for you to the end of the game, but at the same time one must figure: is it really like this?

The question doesn’t matter as the answer is pretty much stated in the sarcasm of the way we present it.

No, the answer is “of course not”.

When I was at the beginning of my career as a software engineer I thought that I would acquire new skills, new shiny items and augmentations that would allow me to go up the ladder.

It wasn’t like that and it took a lot of effort and change of perspective.

One of the things that we must think about when we fix on changing roles or achieving better results, especially career wise, is the fact that not everything is mathematically proven to work.

Ever heard of soft skills? People skills?

These skills are usually achieved through experience because most of the times you can hear about them but they also cannot be taught like you would any engineering skill.

So how do we differentiate between junior, mid and senior level roles?

If you are listening to this podcast and you are part of a HR department or at a Staff Engineer level you already know a lot about this so I’d highly value your feedback on the matter.

For those of you that are curious, I’d say that a Junior Dev, even if genius, is still thinking in “first person”, that’s my key view on this.

When you get better as a programmer both in technical and soft skills you should acquire a more defined sense of team, structure and value.

Junior engineers, usually, tend to be a little more selfish, which is not an offense, they just lack the experience to scrub away the “I” to empower the “we”, that’s why most of the times people that reach Staff Engineer levels, like Architect, Tech Lead, Engineering Manager and the like, have a strong attitude towards people’ skills.

So, as a Junior you might wonder, how do I make sure that I’m taking care of the “right things” to grow into a more senior role?

First and foremost, it should come natural but you can surely strengthen up a bit on the soft skills side. You are in a good spot if you value your team’s opinions and can be supportive of them even if they are not choosing the tech stack you want, as an example. The important thing here is communication and team play. Your technical skills can grow tenfold if you start to act like a senior before becoming one and that opens you up for more senior roles as well.

So, does knowing 10 different programming languages and building your own version of the meta verse make you a senior engineer?

It does prove that you have deep talent and technical knowledge, sure, but can you lead a team?

Can you take accountability for your choices, both technical and non technical?

Can you consistently deliver what produces business value for your company?

If I were a colleague of yours, would I come to you asking for advice?

Do you have a proven record of people looking up to you as a leader figure, not only technically, again, but in a more humane way?

That’s what I’d consider for a senior role if I were to interview you.

Now, don’t get me wrong, technical assessments are still definitely a thing and they will weight on your future interviews but if you developed your soft skills accordingly you will know that not everything is a whiteboard and the people recruiting you are there for you, not against you, and that puts you in a good spot because you are all working towards the same goal, in a way:

The company needs to hire someone that is good at their job and you want to work at that company. It’s a win-win situation if you let go of the “I” and start thinking with a broader scope.

And you are probably asking yourself: how would that help?

It would, because the recruiter is now your “friend”, in a way and they understand and will be very happy to help you achieve your best results in the interviews you will take part in.

If you take that shift of mindset and work hard on all these skills, there’s nothing stopping you from achieving better results for yourself which translates into better results for your team and for your company. That’s also added value, isn’t it?

To end this episode I’d like you to think of a movie that you might have seen: Marvel’s Avengers Infinity War.

If you have not seen the movie you don’t want to listen to this, spoiler alert!

At the end of the movie you might remember Benedict Cumberbatch in the role of Doctor Strange. At that moment he envision and sees into all possible futures dependent on the actions that people would take.

That’s how I imagine a Technical Leader thought train.

Knowledge, experience and support. That’s all it takes.

You finished your Bootcamp. Now what?

404answernotfound — Tue, 12 Apr 2022 09:06:52 +0000

Original article first posted at 404answernotfound.eu blog

The developer's job market and Bootcamps

Anywhere you go, in any nation in the world we live in, one might encounter this problem: the job market.

Yes, the job market can be problematic and only a few professions are safe, to a point. What do I mean by that?
Well, speaking in Layman's terms, there are jobs that require a vast amount of knowledge even just to get access to them. Now, don't fret, I'm not talking about the "family first, safe jobs for family" kind of thing, I'm referring rather to those that most of the times ensure that entry is allowed only to the more knowledgeable individuals.

Don't get me wrong: I do strongly believe and stand firm by the idea that some professions ought to be opened only to those that studied hard and proved that they can do it. I'm thinking medical school, aerospace engineering and so much more.

But with the continuous development and evolution of our jobs and the ways we work, some jobs are opening up where they didn't not long before. I'm talking about programming, web development and so much more.

You go back a few years and not even that many and you can definitely see how only a nerd was capable and able to do the programmer's job correctly. Heck, developers weren't even that much of a rockstar back then, so what happened? People did.

Programmers are surely not a new thing, Internet as well has its own age already but what stands out is the fact that from 2006* and on, more and more people joined the Internet revolution, building our world as we know it now, and the more people there will be on the Internet, the more programmers will be needed to build what satisfies the human nature through algorithmic and digital solutions.

From this a thing was noticed: there was opportunity, there was lack of labour and need for solutions.

So a story was told and spread throughout the globe: we need more programmers, we need more people that are able to write code because that's where humans are going. If you ask me, this story is kind of pushed a little bit too much, but I can agree with the fact that technology will be part of our life more and more with every passing day. And to use technology one should better know technology, because as any good instruments, it is yet another one that needs mastering.

So this lead us to where we are today: a world with a prosperous economy (and right now, also a few wars) and so many self labeled programmers that showcase their bootcamp experience on every profile they own, be it LinkedIn, Twitter or any other.

Now, if you are one of those self labeled programmers you might feel a little bit offended, but trust the reading a bit further and you shall be surprised.

I'm a self taught developer, which means that I didn't exactly go to a school that would prepare me to become a good programmer but I do find that I am a decent one indeed. Hopefully this is also shown by the fact that at the moment of this writing I'm entrusted with the position of Head of Development at my current company.

One might argue: self taught doesn't mean that you studied three months and hoped to become a rockstar developer. Indeed, you would correct, I study everyday for hours to update on my current technology stack and to know more technologies and even newer ones.

It doesn't take three months to become a good programmer but it can take three months to start being a programmer. This is everything you need from this blog post but I will be writing a little bit more.

Programming is an art, and as any artists that fall in love with the subject, you, the programmer, will try and try again to better yourself. The first drawing of your code will probably be not much of a piece of art, but that will not stop you from pursuing your dream career and that's the exact moment you will know that you were always a programmer, a code artist, a logical tinkerer. Those are the keys to the kingdom and you will need nothing else.

Be wary of those that will tell you otherwise, but also be very aware that three months of code school will not always open golden doors. It takes effort and it takes time and it will take a toll on you every time you feel like failing and succeeding and failing and succeeding and it will happen a lot, so don't ever think that you are not enough. It just takes time.

As per the topic, the job market will be open to you if you will be a good candidate for the jobs that are offered. And for our older programmers, like myself, we should not fear new people joining us, because they will bring fresh views, more professionalism and lateral thinking, which is pure gold and you know it.

A warning, to the younger devs (younger as in profession age, not human age): not a lot of people get to work for Google, Facebook, Amazon, Netflix and all those amazing places. If you don't get there, it doesn't mean anything. Always remember to do your best, study hard and bring results. That's what matters, the rest is fun, because programming is fun, creating things is fun and everything is art.

The goodbye

Here are two interesting articles that you may find useful on your developer's journey:

➢ An imposter syndrome analysis, for programmers by a programmer

➢ How to learn programming, as easy as possible

I hope you found this article useful and to your liking and if you have any requests, drop a message on one of my social media accounts or open an issue/start a discussion on github, on this repository!

As always you can find me on Twitter, listen to my Podcast on Spotify and add me on LinkedIn to talk professionally (yeah, right)

Fake data makes for great programmers. A first timer approach to Mockaroo

404answernotfound — Thu, 10 Mar 2022 08:34:46 +0000

What is Mockaroo

It is a great day the day that you find out you can speed up your development environment with just a few clicks on a random web application with a really good name.

Mockaroo, or crazy fast development data seeding for friends, is a web application, a Software as a Service or SaaS, so to speak.

With Mockaroo you can implement a digital twin of your data schema (what your data looks like) with ease, having a ready to use dataset with thousands of rows per table.

Say your database has 3 tables: users, networks, offices.

You could create three fake schemas that represent your data, along with their types, as you can see from the screenshot, and Mockaroo would take care of the data to seed to your datasets schemas depending on how the schema was represented.

You can then save, preview or download the fake data that will be generated for you in different ways, as you see fit.

The datasets that will be generated with 1000 rows can be used to your liking to speed up the development process of your applications, so have fun with your new found powers!

This tutorial was small, I know, not too many memes either, but sometimes you just need to get your hands dirty and who am I kidding, I'm in bed after a long day at work and I just wanted to show you how cool Mockaroo can be and how satisfying it is to see data populated with ease and without any seeding effort.

The goodbye

As always you can find me on Twitter, listen to my Podcast on Spotify and add me on LinkedIn to talk professionally (yeah, right)

`git pull` and `git fetch`, a subtle difference

404answernotfound — Wed, 09 Mar 2022 09:38:15 +0000

Let's start with a primer on both commands

How would you evaluate the usage of those commands if you were tasked to do some commits in a team?

Which of those commands is more destructive than the other?

Read on to discover and if you enjoyed this article, leave a like or a unicorn or whatever makes you happier and it will surely make me happy aswell!

Also, you can find similar blogposts in my main blog 404answernotfound.eu where I write about technology, innovation, programming and most importantly, memes.

`git pull`

In it's simplest usage, git pull just wants you to be happy and up-to-date with whatever changes occurred to the remote repository. Any changes, anything at all will be pulled from the remote repo and automatically merged into your cloned local repository.

See where I'm getting at? It can be problematic, especially the automatic part.

`git fetch`

To make sure that we are up-to-date with remote changes but without the fear of destroying the subtle existence of our local changes we can do git fetch which will (you guessed it!) fetch any commits that were done remotely and do not exist on your local repo, keeping you repo up-to-date without merging the new changes with your current branch, making it safer to update without worrying too much about disruption brought by merging conflicts and so on.

The difference between pull and fetch

So, what's the big time difference between those two commands? Usage and timing.

git pull actually does a git fetch followed by a git merge, so, if you just want to keep your repository updated while working on your own local commits, make sure you do a lot of git fetch(es) to avoid changes in your refs/heads (where you are working) but still keeping your refs/remotes up-to-date.

Goodbyes

I hope you enjoyed this content and found it useful for your daily activities at work or for your hobbies. If you have any requests, drop a message on one of my social media accounts or open an issue/start a discussion on github, on this repository!

As always you can find me on Twitter, listen to my Podcast on Spotify and add me on LinkedIn to talk professionally (yeah, right)