DEV Community: Eleftherios Psitopoulos

Logical assignment operators in JavaScript

Eleftherios Psitopoulos — Sat, 13 Mar 2021 13:49:04 +0000

I just created a video on YouTube about logical assignment operators.

This time, I tried to keep some of the "bad takes" and go with an edutainment video instead of just explaining about the concept.

I'd love to know what you think!

Here's the video

5 tips to help you get hired

Eleftherios Psitopoulos — Mon, 01 Mar 2021 19:48:14 +0000

As almost every developer, I didn't get my first job at day one. In fact, the journey was long and hard, because I don't have a university degree.

Some jobs later, I looked back and compiled a list of things that I was improving from application to application. Things what each time helped me come closer to the end goal.

Truth be told, it's not only about our skills as developers, but the whole picture, define if we will get the job or not.

Watch the video on YouTube

Portfolio review

Eleftherios Psitopoulos — Thu, 31 Jan 2019 21:15:50 +0000

Almost every time I want to get a color from a webpage, I open the dev tools, select any random element and create a color css attribute, setting it to a random color. After that, I click on the small color square that will toggle the eyedropper tool for me to select that color I wanted to get in the first place.

"But this has nothing to do with your portfolio website!" -let me explain! Every time I put a random color in the attribute, I just press a key to get me any color. This key is most of the time "r", which selects the "rebeccapurple" color. Over time, I started liking this color alot, so, for my n-th portfolio redesign iteration, I wanted to use rebeccapurple as a primary color.

I also wanted to convey an "older" feeling, instead of going for an overly saturated design. Something that would remind old video games maybe? I don't know if I got there, but I am feeling great with the end result.

Without further ado, I would like to have my portfolio website reviewed by our awesome community. Here it is

Would you also like your own portfolio reviewed? I would love to take a look!

PS. I also got my CV to match the design of my portfolio. Check it out here

My first steps with YouTube

Eleftherios Psitopoulos — Mon, 03 Dec 2018 12:45:23 +0000

It all started about a month ago when I bought a new camera...

I am a big fan of some great programmer-YouTubers and I was thinking about starting my own channel since 1) there are not many channels of this kind and 2) why not?

Being honest, I have to admit that I was shy at first, not knowing what to say or how to start but as December was approaching, I thought I could start with this popular kind of YouTube videos called Vlogmas. I learned about them from my wife, with whom I spend hours everyday watching YouTube videos, and I noticed that no other programmer-YouTuber does this kind of videos! I don't know why, but I saw a gap and thought about making the start!

It's all going to be about programming, so I thought that Vlogmas is not a great name to go by, since it's labeled by fashion and makeup vloggers. So I thouht about it and chose to name them Codemas! :D

I don't know if this attempt will succeed, but I am surely going to try it out! I do hope though that it's going to be a nice push for other programmer-YouTubers to start doing Codemas videos. After all, it's a great chance to get to know them/ each other better.

Below are the first two videos I have made so far. If you watch them, I would really love to have some feedback! It's a start so, I would like some direction!

Also, feel free pitch ideas for the next videos. Would you subscribe? What would you like to watch?

I really enjoy this fresh start of mine, it's a nice unexplored territory that I hope you come explore with me!

Live: Mark Zuckerberg testifies before senate

Eleftherios Psitopoulos — Tue, 10 Apr 2018 20:12:18 +0000

With all the fuss over twitter with the #deletefacebook movement. The GDPR on its way and privacy in general. It is important to stay up to date with the latest news on data privacy.

Facebook CEO Mark Zuckerberg testifies on Facebook users' data before the Senate Commerce and Judiciary committees.

Watch the video from day 1 here:

Watch the video from day 2 here:

-Edited to add video from day 2

Categorizing your automated tests

Eleftherios Psitopoulos — Tue, 21 Nov 2017 14:51:07 +0000

Is abnormally tedious

Disclaimer: The opinion I formed is based solely on my personal experience. If you disagree (or even if you agree) with any or all of it, please feel free to comment and discuss it.

Automating this and automating that is mainly what we do in our day and age. Manual procedures, when they can be avoided without causing all kinds of havoc, are so very last decade. A natural fit for development, automation tests are all the rage. They have been for quite some time, but are now reaching the tipping point of becoming an essential part of every project, big or small.

And they can be, even for a small project, so many of them. So many in fact that without proper categorization their management would probably require a separate set of automation tests. Now, anyone who undertook the task of creating and managing a bunch of those tests will tell you about the pure madness categorization brings to the table.

This is my take on everything I read and tried out when it boils down to categorizing your tests neatly and efficiently.

Unit test, integration test, functional test.

Unit tests are the smallest and quickest tests you will have running. They will always test one very specific component. In an ideal world, where things are as they should, unit tests will be blazing fast and require no component to component interaction. Unit tests, again if done correctly, will render the debugger use needless. If a unit test fails, you know exactly what failed.

Integration tests will scope up a bit and include two or more components. Do they interact as they should, do they work when interacting? Such questions that boggle the mind are answered here, but the scope -even scaled up- does not go all out crazy to include a whole bunch of components. How many? Well, I was really not able to find a definitive limit. Let’s just keep it to a couple of them.

Functional tests, on the other hand, do go crazy. Since their purpose is to ensure an application function works as it should. Thus it is the least unusual for many more than two components to be included across the duration time of the test. Heavy use of debugging will occur once failed tests rear their ugly head since there is no way to easily detect the failed piece of code.

Acceptance test, end to end test.

If the above seems quite easy to grasp, here things get derailed fast. According to CodeceptJS, a family member of the rather widely used testing framework Codeception, end to end tests and acceptance tests are the same thing. That was a startling claim. I was not able to find anyone else backing up that point of view, I admit. They may exist, but I certainly was not able to locate them.

End to end tests are mostly about the testing duration as a direct result of all-inclusive testing. If for example, you want to test the user registration of any web application you will test each and every step (obviously testing both functionality and UI) until you conclude the registration process.

Acceptance, on the other hand, has more to do with whether or not the implemented functionality (that we already tested) is actually what the user wants. It is more of a business to end user and back to business again relationship. And it confused the world wide web out of me, at first.

It confused me because not everyone agrees on what they truly are. And even if they did, this distinction still seems rather cloudy especially when put next to the others that I mentioned above.

Google to the rescue.

As logic seemed to flee, Google decided to step in. Google testing blog is a great place to visit. Since they have to run and maintain a huge amount of tests, they always aim for simplicity over unnecessary complexity. It was there that I found a distinction that actually made sense. A distinction based on mostly concrete traits instead of abstraction and subjectiveness. Time.

Small tests are our unit tests. Each will run almost instantly, and it will retain all unit tests properties as already mentioned above.

Medium tests are our functional tests. They will run for more time than unit tests and will touch more than one components.

Large tests will be our end to end based on whole scenarios. These will include a large number of components and will -in turn- perform the slowest of them all.

And there you have it. Of course there will be more properties to classify among these three categories, and the time limits are not set in stone, but it all makes sense. So that is what I decided to follow when I set my tests apart. A system that everyone will simply understand.

Originally posted on Thanpa

Hello world, I am a ticket!

Eleftherios Psitopoulos — Sun, 19 Nov 2017 14:01:31 +0000

In IT business someone could say that tickets are similar to stars. Not because they are countless nor because of their romantic perspective, but because they are born, they live their lives until they finally die. The following text will describe a specific example of the life of a ticket.

The birth of a ticket is connected to a problem. A ticket is a way to describe an issue. It can be about a bug, an improvement or a new feature. The issue is described shortly in the title with more details given in the description. It has a priority that determines its importance among the other tickets. Usually, a newly created ticket is not part of the running sprint (see the previous article about SCRUM).. It waits in the backlog until the team decides the best way to implement it, and estimate how much time the developer needs to do the job.
When its time comes, it is assigned to a specific person of the team and waits in the queue for the sprint manager to decide in which sprint it is going to be. Only when the ticket is about something really important, it is being discussed by the team right after creation and is assigned to someone to work on it immediately.

Each ticket has a status that describes in which part of its life circle it is. Here is an example of the workflow that contains all possible ticket statuses.

When a ticket is created the first status it gets is “Development ready”. It means that the ticket is ready for the developer. From this state, it can follow two different flows. The first is that the ticket won’t be implemented, and gives it the status “Done”. This means that the ticket is not needed anymore because the issue it describes is already fixed or because it is duplicated by another ticket. The second flow is that the developer starts working on it. This leads to the next status, “In progress”.

When a ticket is in progress, it means that someone has started working on it. So every other person it the team knows that they should not deal with this ticket. While working on the ticket there are two possible flows. The first is that the developer may need to change to a different ticket. In that case, the ticket should return to its previous status “Development ready”. The second is that the ticket is ready and it should continue the next step of the workflow which is “Automation test”.

“Automation test” is a rather literal status. It means that an automated process is run, that tests that the developer didn’t break anything while trying to fix something. The result of this process can be successful which leads to the next step, and the next status “Code review”, or failure which leads to “Issue found” status.

“Issue found” means that something is not right with the ticket. Maybe it is not working as expected or maybe it breaks something, somewhere in the project. Either way, this status declares that further work is needed. When the developer decides to fix the issue, he changes the status to “Development ready” and then to “In progress”.

“Code review” status means that the automated tests couldn’t find any problems so the code should be reviewed by another developer or the software architect. If the reviewer decides that something is not as it should, the ticket is rejected and this results to “Issue found” status. If the reviewer is happy with the code, the ticket is approved and proceeds to the next status, “Quality check”.

When a ticket is in “Quality check” it is time for more testing. This time it is not automated, but it is done manually by a tester. When the tester starts testing, the ticket should have the status “Testing”. If everything works as expected the ticket is approved and gets the “Approved” status. If something is wrong, then it is rejected and gets the “Issue found” status.

An approved ticket is ready to be merged with master. So what status could be more appropriate than “Merging” for this process? If merging is successful the ticket gets the “Merged” status and waits for the next release. If something goes wrong, the ticket gets the “Issue found” status.

After a ticket is released to production it gets its final status, “Done” which means it is officially dead.

So if I were in a ticket’s shoes, assuming that tickets have shoes, I would chose to be a low priority and highly prone to bugs and issues that would lead me to “Issue found” and extend my lifespan a little bit longer, while making someone’s life a little bit harder, hehe.

Originally published on Thanpa.com

Why do programmers drink so much coffee?

Eleftherios Psitopoulos — Thu, 19 Oct 2017 21:49:05 +0000

One of my habits is sitting late, reading stories regarding the world of technology, stories of developers and so on. Lately, I stumbled upon an interesting article tampering one of the most spread diseases of the development world; programmers wearing headphones when coding!

This article got me thinking, I am one of those too, but what is another stereotype in our circles? What is the typical image of a developer who wears headphones? Drinking coffee; a heck lot of coffee!

Is there a reason behind that or do we just do it because it’s kawl? I don’t know, maybe a good dose of both is the right answer, but why not break it down and look for some good reasons to use as nicely stated excuses to the next person who is going to say “coffee is bad for you”.

It makes you smarter and more energetic

I’m not saying that you will hit 200 on your next IQ test but it has been scientifically proven that when caffeine travels to the brain through blood circulation, it blocks an inhibitory neurotransmitter called Adenosine. When this happens, there is enough room for other neurotransmitters like dopamine and norepinephrine to increase. This leads to enhanced firing of neurons.

Caffeine improves many brain functions that affect mood, cognitive function, concentration, reaction times and energy.

It helps ease the pain

Programming is having thousands of lines of perfectly written and organized code destroyed by a missing semicolon. How many times have you had just because of this? Back in 2007 scientists found that coffee helps reduce pain by 48%

Prevents retinal damage

Even though most developers wear glasses (because we are hipsters above all) studies have shown that drinking coffee can prevent retinal damage. This time the hero is not caffeine but chlorogenic acid which is another strong antioxidant the coffee bean contains.

It just makes you happy

This is another thing that caffeine is not the culprit of. The National Institute of Health has found that people who consume coffee are less likely to be depressed by ten percent. As I said, this is not because of caffeine as coke also contains high amounts of caffeine yet it’s linked to depression. Scientists believe that this benefit of coffee comes from the antioxidants it contains.

Even its smell does wonders

Another interesting find is that the aroma of coffee stimulates the brain to produce proteins that are known to protect nerve cells from stress-related damage caused by sleep deprivation. Remember that next time you stay awake all night long working on your next project!

Drinking coffee is one of the most common habits of our niche. It is not us who set the trend though. You can find a cup of coffee in almost every profession that requires concentration and clear mind, just look at novel writers.

No, it’s not us who set the trend but we are “labeled” with it just because programming is a common thing in our days. After all, a cup of coffee is just great to enjoy.

Let me know what you think down in the comments section! Do you have anything else to add?