DEV Community: Sasha Blagojevic

Go for PHP or Any Other Developer

Sasha Blagojevic — Mon, 27 Jan 2020 10:23:01 +0000

Long time no read! I’ve been quite busy building awesome stuff for our clients so I haven’t had the time to write in quite a while. I still don’t have it to be frank, but this is gonna be a somewhat short read so I managed to squeeze it into my schedule.

TLDR

If you’re not interested in the story behind this list just skip to the end. I highly recommend covering these resources if you’re considering learning GO.^[c]

Why Go suddenly?

I’ve been helping out on an awesome big data / IoT project which is powered by none other then GO! Our client was coming from a Python background and when you add the terms Big Data and Internet of Things to this mix you can clearly see why GO is a natural fit for this project.

It has been really interesting switching from PHP to Go lang. I must admit at the beginning it was a bit of a challenge to wrap my head around all of the different concepts. Not only was I switching from a scripting language to a compiled one, but Go lang is also a functional language, where as PHP supports both the Functional and Object Oriented Paradigm.

To add fuel to the fire GO lang has its own twist with its concurrency model - goroutines and channels.

When your client demands GO lang as the power train you can be pretty sure it’s not going to be a walk in the park, you can expect it to be a high performance / high load type of a project so there will be no cutting corners and optimization needs to be on your mind all the time!

I’d consider my role in this project as kind of a sheepdog since I was setting the path and guiding our junior developers as they do tend to behave like lost sheep sometimes. Client being the shepherd in this analogy I guess lol.

Major Differences between PHP and GO

Aside from the obvious fact that GO is a compiled language these are some of the major differences:

Switch statement does not fall through by default, you have to explicitly add the fallthrough keyword
For is the same as While, that’s the only loop keyword

There are no Classes / Objects, there are Structs which have some of the behaviour, they can have members and methods defined on them
There are no explicit access modifiers like public, protected and private but there is a naming convention. If you declare a variable / type / function lowercase first it will be treated as private on the package level, if you define a member / method lowercase first on a Struct it will not be accessible publicly. On the other hand if you write them uppercase first it will be publicly accessible.
Since there are no Classes there is no Inheritance, but we can achieve Polymorphism because GO has Interfaces.
Interfaces in GO have their own twist and are a bit different than in PHP. While in PHP you have to specify which class implements what interface in GO every data type implements an empty interface{} by default. You can think of this interface{} as something similar to TypeScript’s any. When you create your own custom interfaces you will need to add the implementation of these methods on the desired structs. GO will not check if the interfaces are satisfied during the build process, unlike some other compiled languages, it will be evaluated during runtime when the actual method is called, if you call the method on a Struct that does not satisfy the type hinted Interface your application will fail.
There are no exceptions in a traditional sense, there are no try / catch blocks although there is a proposal to introduce try. What we have though are panics and recover, but recover can only be used to recover from a panic that happened on different goroutine. How do we handle errors then? Well, GO functions have multiple return values. Usually the first value is the desired result and the second value is the error if there is any, otherwise nil.

I’m of the opinion that each language should be written in its idiomatic way, that is the way to get the most out of the language and in addition your code will be easily understandable by the wider community and new developers that might join you or replace you later on.

That’s the whole point behind language style guides, admittedly some have a more strict some less, some don’t have one at all - PHP didn’t have one for a long time before PSRs came into play and our community was honestly a mess, a million of different styles and approaches that just unnecessarily added to our cognitive load.

That being said this is a list of resources that you most definitely should read if you want to write idiomatic Go and follow community best practices:

Must Read / Watch List

1. Official Go Code Review Comments

2. Go Standard Project Layout (Community)

3. Ben Johnson - Standard Package Layout (Community)

4. Go Docs - Package Naming

5. Peter Bourgon - Go Best Practices Six Years In (QCon London 2016)

6. Peter Bourgon - Go For Industrial Programming (GopherCon EU 2018)

7. Ashley McNamara + Brian Ketelsen. Go best practices (GopherCon Russia 2018)

8. Andrew Gerrard GoLand Talks 2014 (Google)

9. David Crawshaw - Organizing Go Code 2014 (Google)

Running multiple versions of PHP on MacOS with Homebrew

Sasha Blagojevic — Wed, 18 Dec 2019 09:09:09 +0000

I'm a big proponent of Baby Steps Doctrine, yep I think I just coined this term. What do I mean by that? Short version I like keeping things simple, now let's get to the long one.

I don't like adding unnecessary complexity if there is no need for that. I've noticed that people often add complexity to their systems and their workflow just because:

Everybody else seems to be doing it
It's a new shiny technology so it means it must be the next best solution (remember the SQL is dead long live NoSQL, now it's Restful is dead long live GraphQL, tomorrow it will be something else, yadda yadda yadda)
Facebook / Google / Some other big company is doing it, therefore, it must be a best practice and I should be doing it

We should be adding complexity only if there is an upside to that trade-off. Just because it works in the case of some big company does not mean it adds value to the mom and pop store you're working for, or the side hustle you're working on.

Does running and configuring Docker really add value if you're working in a small team 1-5 people or even worse if you're working alone and you're not running a distributed system?

Maybe Homestead / Vagrant is enough? Or maybe you don't even need that and can use your local dev machine?

When I start out coding as my first step I like to use my local dev machine, a 2017 Macbook Pro. With time different projects for various reasons required different PHP versions so I had to run multiple PHP versions on my local machine.

Thanks to Homebrew you can do it fairly easy. For newer PHP versions like 7.3 it's just running:

brew install php@7.3

For PHP 7.0/5.6 that are deprecated and not officially supported by the Homebrew team you have one additional step, you need to add a tap:

brew tap exolnet/homebrew-deprecated

brew install php@7.0

brew install php@5.6

When you install PHP with homebrew the default location should be /usr/local/Cellar/php@7.3/ and there should be a symbolic link to /usr/local/bin/opt/php@7.3/. Check out my Stack Overflow response for more info on this topic.

To change the version of the PHP used by your shell you need to add it to your path by running:

echo 'export PATH="/usr/local/opt/php@7.3/bin:$PATH"' >> ~/.bash_profile
echo 'export PATH="/usr/local/opt/php@7.3/sbin:$PATH"' >> ~/.bash_profile

Important: This won't work if you're using the new zsh shell which came with the Catalina update because it ignores .bash_profile and .bashrc configuration files. To continue using bash as your default shell and to upgrade it to a newer version check out this awesome article.

Now, what if you want to use a different version of PHP that's installed on your system? Well, you'd have to manually change your .bash_profile to point to a different version.

export PATH="/usr/local/opt/php@7.0/bin:$PATH"
export PATH="/usr/local/opt/php@7.0/sbin:$PATH"

Doing that manually multiple times a day can be a bit tedious so let's automate that.

Download phpver my small PHP binary script from Github gist
Put it in /usr/local/bin or somewhere else and make a symbolic link to /usr/local/bin
Make it executable by running chmod +x /usr/local/bin/phpver

Now you can change your active PHP version by running phpver {version_number} in your shell anywhere in the system. For example to change from version 7.3 to 7.0 you would just have to run phpver 7.0 and restart the terminal for the changes to take effect.

That's it, hope this comes in handy to someone because it sure did to me.

Have fun and keep coding!

Three Reasons Why You Should Visit Web Summer Camp

Sasha Blagojevic — Tue, 03 Sep 2019 20:35:09 +0000

Yes, I used one of those clickbait titles and no I'm not ashamed, not at all, because now that you've clicked you might as well read it, you obviously have no better things to do.

Web Summer Camp is a place where the nerds go to recuperate from all those Friday deploys, all those just make it work we'll rewrite it properly later, all those if it works don't refactor it doesn't matter it's written in Sanskrit moments or rather should I say decisions that we're left to live with.

At least here, you'll be surrounded by like-minded experts and aspiring professionals who yearn for knowledge and ways to improve their craft. It won't take too much time to find a shoulder to cry on about your legacy spaghetti-monster codebase that you have to deal with daily and if not you're one lucky bastard, you...

Web Summer Camp is that good of an experience that I'm a tad bit selfish about it, it is the only conference I'm a little afraid of promoting and talking about.

Knowledge

Rovinj Web Summer Camp has a really strong line-up. You will be able to attend workshops from industry experts on both software development and project management. You will get your hands dirty and go more in-depth than on regular conferences.

I attended the PHP track because having to deal with a legacy codebase at my job I caught on the DDD(Domain Driven Design) bug because I witness every day what happens when you go the SDD route. It's not a coincidence it sounds so similar to STD because it's as equally bad. I'm talking about Sales Driven Design. A code first - think later approach. Just glue the new feature on top, however you know, as long as we're getting new customers it's peachy. It doesn't matter it's making you're code unmaintainable, for Pete's sake it's increasing the sales! We will think about the maintainability later and this only ever happens when everything grinds to a halt and then, of course, the developers are the ones to blame it's the easy way out.

When it comes to greenfield projects (thanks Pim for learning me a new phrase lol) my feeling is that HDD(Hype Driven Development) is the prevalent approach. We need that new shiny thing to be successful otherwise we are doomed! We need the X framework or the Y complex technology because scalability and a certain Z unicorn uses it. Surely with it, we will be as successful as they are, just look at their valuation. There's no other way to solve that particular problem even though we have 1 000 000 times fewer users and a developer team of 3, but John is on vacation so basically it's 2.

Stefan Priebsch did a great job teaching us the core concepts of Domain-Driven Design and his workshop was my favourite. It was an eye-opening experience for me. People, we are doing it all wrong! We are doing the things in the reverse order, we are trying to model the domain so it fits the technologies we decided to use, instead of picking the technologies that fit our domain. Yes I know it's yesterday's news to a lot of you experienced guys and gals, but I'm new to this so bear with me and let me rant a bit.

Kevin Dunglas' workshop plays into the previous sentiments. He and the Symfony team have solved the complex issue of real-time app communication between different clients be they mobile or web by using already available technologies like HTTP's Server Side Events. I didn't even know SSE existed. You see, sometimes we don't need the shiniest new thing SEE existed before Web Sockets. You're welcome for the brief web history lesson lol.

Lastly, I really enjoyed the workshop by Tomas Votruba and Honza Mikeš. They built Rector PHP a great tool that automates the process of refactoring code. It's like meta-programming on steroids. I dared them to try and refactor an old method with lots of nasty if statements and nested array keys and they would've solved it if only the time had allowed it. You should definitely check their tool out or even maybe contribute if you're up to it!

Networking

I've met so many amazing people that I have to keep an excel sheet of their names and pictures because I suck at remembering names and I don't want them to get offended. Ask Pim Elshof if you don't believe me, I called him Tim like a gazillion of times. I'm joking about the sheet of course but I probably should do it.

As Mario Blažek said, "Where would you get the opportunity to play pool with core contributor of Symfony Nicolas Grekas" or when would I get the opportunity to have a romantic dinner* at the beach, on an island with Zoran, Pim Elshof, Claes my Viking half-brother and Honza Mikeš the co-creator of Rector PHP. When I say romantic dinner I mean eating like pigs and drinking beer under candles.

Web Summer Camp is that good of an experience that I'm a tad bit selfish about it, it is the only conference I'm a little afraid of promoting and talking about. I mean don't get me wrong I want them to become bigger and better or whatever the goal of the organizers is, I just don't like sharing things that are precious to me. Aside from knowledge, I like to share knowledge.

Truly, all three days I was feeling like I was visiting relatives at the seaside. I just felt at home somehow.

Fun, lots of fun

Web Summer Camp is a 3 day 24 hours a day event. Don't worry not all hours are mandatory, it's not an introverts hell. The organizers really go out of their way to make you feel welcome and not only facilitate the workshops but also entertain you after the workshops.

What really made an impression on me was the fact that, let's call him Chief Organizer, Ivo personally greets everyone and stops for a chat. The rest of the guys and gals are awesome as well and kudos to them because it must have been exhausting being available to the attendees 24/7.

The off workshop program consisted of:

Beer powered panel with experts,
Unconference,
Two boat trips to nearby islands,
3 drink ups and
Everyday exercises (morning swims or runs)

I mean come on now? Who else offers that level of attendee engagement?

Rovinj itself(bonus reason)

..as if the three previous reasons were not enough to make you start filling up your piggy bank. Rovinj is a go-to place for architecture fans. The old town is breath taking! As a matter of fact, I first found out about the amazing architecture of Old Town Rovinj on a beautiful places kinda Instagram page, as soon as I saw it I knew I had to visit it, and so I did. This was my second time here and still, I had to take pictures of every street, every corner, every building all over again!

I'll end this post with the words of a famous cyborg assassin: I'll be back.

PHP Tuples

Sasha Blagojevic — Sun, 09 Jun 2019 23:47:11 +0000

How do we call a gopher and an elephant dating? A tuple.

Wow, this makes no sense whatsoever...ok, we should move on now...

I've been working in golang for quite some time and I started to pick up some patterns subconsciously. Since golang has multiple return values, which I find quite useful and am a big fan of, I started doing this more and more in php:

<?php

list($items, $count) = $contentRepository->getSlice($page, $perPage, $filters, $sorts);

// or the even sweeter shorthand syntax

[$items, $count] = $contentRepository->getSlice($page, $perPage, $filters, $sorts);

What we are doing here is just destructuring the plain ole' integer indexed array, commonly know in more CS uppity circles as a list. But there is a downside to this approach, arrays are kinda like blackboxes, we don't have a clue what's in them, it could be anything. Let's take a look at getSlice method signature to get a better understanding:

<?php

public function getSlice(int $page, int $perPage, array $filters = [], array $sorts = []): array;
{
    // something, something
    return [$items, 15];
}

You see, we don't know what type the array's members will be and there is really no way to enforce it, so we could easily introduce some nasty bugs if we were to accidentally put some unexpected values.

We can tweak this approach a bit by adding doc blocks to the method signature which will help our IDE and static analysis tools like PHPStan to know what values are expected:

<?php

/**
 * @return array<int,string>;
 **/
public function getTitleAndName(): array;
{
    return ["Supreme Overlord", "Sasa Blagojevic"];
}

Wait, what? Why are we using a different example now? Well, this has its limitations as well, doc blocks only add value if all the array's members are of the same type. In our first example that's not the case. So what do we do now?

Say welcome to PHP Tuples

class Tuple implements ArrayAccess
{
    private $values;

    public function __construct(...$values)
    {
        $this->values = $values;
    }

    public final function offsetExists($offset)
    {
        return isset($this->value[$offset]);
    }

    public final function offsetGet($offset)
    {
        return isset($this->value[$offset]) ? $this->value[$offset] : null;
    }

    public final function offsetSet($offset, $value) {}

    public final function offsetUnset($offset) {}
}

Let's dissect this code snippet a bit:

We've implemented the ArrayAccess interface to make the objects of the class Tuple accessible as arrays
We've left the offsetSet and offsetUnset methods with empty bodies so that our tuples are immutable, we don't want to introduce bugs by accidentally mutating their state
We've made all the implemented methods final so other developers can't override them and break the underlying behaviour of our tuple, except the constructor

This is going to be our generic tuple. To make things more strict and explicit we will make custom tuple classes on per case basis by extending our Generic Tuple class and adding types to the constructor:

<?php

class ContentSlice extends Tuple
{
    /**
     * ContentSlice constructor.
     * @param array<int, Content> $items
     * @param int $count
     */
    public function __construct(array $items, int $count)
    {
        parent::__construct($items, $count);
    }
}

Let's apply this new found knowledge to our first example:

<?php

class ContentRepository 
{
    public function getSlice(int $page, int $perPage, array $filters = [], array $sorts = []): Tuple;
    {
        // something, something
        $items = [Content(), Content(), Content()];
        return new ContentSlice($items, 15);
    }
}

Now if we were to put wrong values in the ContentSlice constructor the code would explode. So what we have achieved now is that we have both multiple return values and explicit and strict code like in golang.

This is why learning new languages is great, you will stretch out your brain and force it to solve problems in a different way that is idiomatic to the new language. This new knowledge will then pay dividens in your main language when you start to apply all the cool concepts that you've subconsciously or conscioulsy picked up. This is a great way to hone your skills.

I had this random thought tonight and wanted to share this with you guys (my imaginary audience). I find this pretty cool and I'm probably going to try it out in a project to see how it fares in real world applications, what are your thoughts about PHP Tuples?

PHP Serbia was a blast

Sasha Blagojevic — Tue, 28 May 2019 23:59:19 +0000

Originaly published at sasablagojevic.com

It's time we talked about the phelephant in the room. *Ba Dum Tss! Get it? This is double wordplay, elephant in the room and php + elephant == phelephant. Ok, I'm gonna stop now...

I wanted to summarise my impressions after the PHP Serbia 2019 conference since this was my first time attending. I thought it might be helpful to those people who are on the fence whether it's worth visiting it.

TL;DR

It is.

PHP Serbia 2019 line-up

The line-up and the topics covered were all really good. Zeev Suraski was this year's keynote and he gave us an overview of the PHP since he joined the band of brothers known as php internals devs and more importantly all the cool stuff that will be included in the upcoming php7.4 and php8. Yep guys, php8 will be coming hopefully by the end of 2020. Oh how the time flies by, I mean I haven't been in this game that long and I witnessed the amazing evolution from php5 to php8.

As I said, all the talks were good but the ones that stood out to me and I recommend you watch when the organizers share the videos are the following (in no particular order):

Hello my name is "if" by Sebastian Feldman, not only did he dance like a madman and put Michael Jackson to shame, but he also gave us a low-level insight and deeper understanding of how different types of if statements work under the hood in php, yes you might have thought that a ternary if statement is just a shorthand way of writing a regular if statement, but when it gets converted to opcodes it's actually not, and the same goes for using the null coalescing statement.

Git legit by Pauline Vos explained the difference between git rebase and git merge strategies in an easily digestible way, even by dummies like myself. Now we can finally put this feud to rest and just pick one that aligns with us philosophically because this is the same shit as OOP vs FP, one is not better than the other they both have their trade-offs. There is no silver bullet in software development no matter how strong we try to find it!

You're not a {framework} developer! - if you are a Symfony or Laravel fanboy you might strongly disagree with this one :D, but Thomas Dutrion gave a good starting point on how to abstract and protect ourselves from the framework. There were some really good examples for both Symfony and Laravel frameworks on how to abstract at both the Model and Controller level. Our domain logic shouldn't know about our infrastructure (framework), this is my key takeaway from this talk, at least that's how I understood it and it makes perfect sense to me now. For those of you who are saying But how often do we change a framework? we are not necessarily going to change the framework itself but we need to protect ourselves from future updates of our framework as well. Each major version will have breaking changes and choosing not to update will compromise both performance and security of our codebase - that's how we get legacy codebases that everybody hates working with.

Making architecture explicit by Herberto Graca, we all know that organizing code and folders can be a pain in the ass and a huge liability if done poorly. Well, Herberto had some great charts and breakdowns on organizing code the DDD way.

I highly suspect that Marcel Pociot's talk Getting started with WebSockets and Damien Seguy's Top 10 PHP coding traps were awesome as well but unfortunately, I did not attend them.

This is me winning a free ticket for PHPSerbia 2020 and a Phelephant on the conf quiz :D

Venue and organization

The venue is a big theater in Zemun, there were two tracks A and B, B being the smaller one obviously. Well, it was quite smaller compared to A, so what happened was that all the people that were interested in a talk at track B could not fit in or chose not to stand. This only happened two times though. Gauging the audience's interest and which speaker should get the short stick end is tricky, so maybe, as Damien Seguy suggested, attendees could vote somehow, when the lineup is known, which talks they're interested in so the organizers at least have some estimate.

There were food and beverages in abundance. I was well fed and watered like a plant xD. I must highlight that the food was really tasty and the Conferences' craft beer as well. What I also really liked compared to other conferences I attended (that being Webcamp Zagreb times two lol) they had a real espresso machine so I could get my daily 37 doses of macchiato, yes I'm an addict and I'm not ashamed. I basically didn't spend a dime the whole day throughout the conference there was really no need to.

In general, the organizers did a great job and they were very welcoming, you just felt at home from day one.

My only pet peeve is that maybe the talks could be a bit shorter so we have a small pause in between them to reset our brains, chit-chat, drink a coffee or whatevz or maybe I'm just spoiled by WebcampZg.

Final verdict

I give it a solid 9/10 just because I'm afraid if I gave them 10 they'll get lazy. Now is the time for you to stop thinking and start preparing for the next one!

P.S. Thanks to my company JSGuru for paying the ticket, I mean who doesn't like free stuff!

Originaly published at sasablagojevic.com

Why You Should Care What You Npm Install

Sasha Blagojevic — Thu, 20 Dec 2018 13:36:52 +0000

As if we haven't learned anything from the Left-pad debacle on November 26th the Javascript world was shaken once again.

A popular Npm library with over 2 million installs had a backdoor. Wait, what?! Yep, you heard it correctly the event-stream library which was not archived at that time and was used all over the place from your garage script kiddie to enterprise systems was infected with an obnoxious back-door, a crypto miner /stealer/something. From now on we will call it the C - virus for dramatic effect.

Damn crypto hype, it's high time the bubble burst and let us go on with our lives. - Me, December 2018

But, how did it happen? Well, a combination of unfortunate circumstances and the author's faith in people led us here where we are today.
The author stopped using and maintaining the library a long time ago. Since it wasn't archived over time it became a dependency of many projects and lo and behold one day a good Samaritan slid into his inbox and offered to take the burden of maintaining the library upon himself and to carry the torch onwards, but he was not good, was he now.

// Detect dark theme var iframe = document.getElementById('tweet-1067124100332744704-828'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1067124100332744704&theme=dark" }

The author transferred the rights of the Npm module to this kind stranger but left the module's code on his Github account since there were some problems with name conflict when he tried to transfer it to the stranger's account, or so he says, but I suppose they weren't accidental either. This Samaritan was one nefarious schemer.
As soon as he got hold of the library he removed the publishing rights of the old author, added the flatmap-stream module which contained the C-virus, did a minor version bump and finally a new release on Npm.
The event-stream library was updated to the new minor version all over the world.
As soon as he planted the C-virus, he removed the flatmap-stream module from the library and then he did a major version bump and once again a new release on Npm. Quite smart isn't it? Now there was nothing suspicious in the codebase but since it was a major version update most of the systems wouldn't update to it because they are version locked to the previous major version thus they would still have the infected code.
Even one of my coworkers got infected, barely anyone noticed, but Kevin Beaumont.

// Detect dark theme var iframe = document.getElementById('tweet-1067125660014051330-270'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1067125660014051330&theme=dark" }

That was a brief summary and I probably missed a step or two but you get the picture.

SHORT NOTICE:
We shouldn't blame the author, he probably didn't really think it through that much but maintaining open source software is a real hassle and can be really mentally draining on the authors, especially in today's entitled society where people expect everything for nothing. So let's not put the blame on him.

Now let's get back on track! Oh, here's another gem by Kevin Beaumont

// Detect dark theme var iframe = document.getElementById('tweet-1067130326395351040-919'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1067130326395351040&theme=dark" }

Hallelujah, praise the Lord! Preach! People didn't come up with this meme for no reason:

Key takeaways from this mess:

Sometimes we take for granted and don't think what we Npm install/composer require/yarn add
Developers have become lazy. We have started taking "don't reinvent the wheel too literally", instead of writing a few extra lines we'd rather require a library, sometimes even for the most trivial of tasks (especially in the Javascript World this seems to be the trend)
You should always put careful thought in what you require as a dependency, more dependencies can sometimes mean more technical debt
Add a layer of abstraction and design an interface as a bridge/adapter between your domain logic and libraries, so you can swap them more easily if the need arises
When a library stops being maintained we now own that code and it is our responsibility to fix it as part of our codebase or find a suitable replacement for it

These lessons were once again learned the hard way by many businesses this November.

Thanks for reading my long rant!

Before you go…

If you enjoyed reading this post please share it. You should check out our other publications, you might like them too! We write from time to time about software development, tips and tricks, and how to become a better developer and business person in general. Join us on the journey of constant improvement!

Originally published at jsguru.io.

Object Oriented Programming

Sasha Blagojevic — Sat, 15 Dec 2018 10:09:23 +0000

Originally published at sasablagojevic.com

The aim of this article is to break down the major concepts of OOP for newbie developers in a more digestible format and I hope they will have a better understanding of the Object-Oriented Paradigm after reading it.

We all know the majority of newbie developers prefer to get their hands dirty than to read so I'll try to cut the bullsh*t to the minimum. When I was a newbie to programming myself and when I was first delving into the world of OOP, learning what a Class is and what an Object is was the easy part. Applying them to the real world problems I was trying to solve was the tricky part.

How do I structure my code?
What should my Class be concerned with?
Should I split this Class into more?
How should the public API of my Class look like?
How should the methods be named in conjunction with the Classes' name?
Should this method be static?

Those were all the questions that I asked myself.

Since I'm a self-taught developer, I lacked some theoretical knowledge, so I decided to read more about OOP and design patterns. Previously I have been doing things more intuitively and it has done me well. I was on the right track, I've advanced in my career and nobody complained about my code, on the contrary, but there comes a time when you need to get a deeper understanding, how things "work under the hood" to take both your knowledge and career to the next step.

The aim of this article is to break down the major concepts of OOP for newbie developers and I hope they will have a better understanding of the Object-Oriented Paradigm after reading it. It is intended as a cheat sheet they can come back to and freshen up their knowledge and not only them, myself included ;)

All Roads Lead to Rome

To get a better understanding of OOP and what issues people were trying to solve with it, we will briefly go over some of the different and most common programming paradigms. While most of the modern languages have a multi-paradigm approach at some point in their lifetime they might not have had. It has been an iterative process to come where we are today, it is a long road from Assembler to PHP.

Programming paradigms

Imperative
- Procedural
- ...
Structured
- Object-oriented
- ...
Declarative
- Functional
- ...

In imperative programming, we give instructions to the computer what to do and in which order to do it. Every time we tell the computer to remember something by storing it in a variable we are using statements to change the global state of the program. You can already see how this could get messy in big programs with lots of developers because all of them are directly changing the global state the chance of making bugs and overriding data is high.

Procedural programming, although often used as a synonym for imperative programming, is actually an extension of the imperative paradigm. In procedural programming, we group aforementioned instructions into procedures, also known as subroutines or functions. Procedures are just a set of instructions, a modular unit, that we can reuse in our program just by calling it without having to rewrite the specific steps all over again. But at this point, you already know this ;) Procedural programming brought us the concepts of blocks and scopes, which gave us a new type of state, local. Local state means that is valid only in the context of that specific procedure.

As we can see the focus of procedural programming is to break down the computer instructions into variables and subroutines/functions, whereas in object-oriented programming it is to break it down into objects.

Objects expose their behaviour through methods (class/object functions) and have their own internal state in form of members/attributes. Both the methods and attributes may or may not be accessible to the outside world depending on their visibility.

So you see, both procedural and object-oriented paradigms were trying to solve the same issues: the issue of mutating the global state and breaking down complex tasks into smaller modular units (subroutines/functions vs. objects), in their own respective ways.

Object-oriented programming in its core is all about sending messages and responding to them.

In procedural programming, a process is expressed in one place in which a series of instructions are coded in order. Whereas in OO, a process is expressed as a succession of messages across objects. (David Chelimsky in Single Responsibility Applied to Methods)

In my opinion, this is best described by the Tell don't ask principle.

Don't ask for the information you need to do the work; ask for the object that has information to do the work for you. (Allen Hollub - Hollub on Patterns)

Let's expand on this a bit in layman's terms. Contrary to procedural and functional paradigms where we would pass data from a function to function, manipulate it and return it, in OOP we want the object that encapsulates that data (has it in its internal state) to do the manipulation for us. We achieve that by sending it a message. After receiving our message the object will determine based on its internal knowledge and methods what it will give us as a response.

In even simpler terms, messages would be our method calls and responses the data those methods return. Bear in mind that methods can be void, meaning they don't return any data, they just change the internal state of the object, but you get the gist of it.

So to put that in practical terms it would look something like this. *Disclaimer* This is a highly simplified example just for illustrative purposes.

function mark_as_read(array $email) 
{
    $email['is_read'] = 1;
    return $email;
}

$email = [
    "from" => "Marry Doe",
    "to" => "John Doe",
    "subject" => "Dear John",
    "body" => "I\'m leaving you"
];

mark_as_read($email);

// vs.

class Email {

    protected $from;

    protected $to;

    protected $subject;

    protected $body;

    protected $isRead;

    public function __constructor(string $from, string $to, string $subject, string $body)
    {
        $this->from = $from;
        $this->to = $to;
        $this->subject = $subject;
        $this->body = $body;
    }

    public function markAsRead(): Email
    {
        $this->isRead = 1;
        return $this;
    }

    public function isRead(): bool
    {
       return $this->isRead === 1;
    }
}

$email = new Email("Marry Doe", "John Doe", "Dear, John", "I'm leaving you.");

$email->markAsRead();

There is a good metaphor by one of the fathers of OOP Allan Kay, he says that objects are like cells in our bodies, small self-contained units that make up our human being.

Ok, just because we know now how to cram functions and data in a class does not mean we know OOP, let's make everything a class now is a common newbie pitfall. There are a few more things we need to keep in mind! :D But before talking further let's just briefly go over the last two paradigms.

In contrast to the imperative paradigm, the declarative paradigm tells the computer what we want, not the steps how to get it. A perfect example of a declarative programming language is SQL.

Functional paradigm is a subset of the declarative paradigm and it uses declarations/expressions unlike statements in the imperative family, but like its counterparts, it also tries to solve this issue of manipulating the global state. In functional programming, programs are thought of as a collection of pure functions. Pure functions are functions which take input and always return new values. They never have side effects, they never mutate the state and they are always expected to give the same result given the same input. So in the functional paradigm, the state is immutable.

@AnjanaVakil puts it more eloquently in her Programming Across Paradigms keynote at WebcampZG 2017, I recommend you watch it.

Basic OOP Principles

Single Responsibility

A class should only be concerned and handle one aspect of a complex problem we are trying to solve. It doesn't mean that a class should literally have just one responsibility, it's not a function for Pete's sake, it can have multiple but they all need to be a part of one broader task. When we say single responsibility we are talking from the context of our business/domain logic. For example, let's look at the PHP's built-in SplFileObject, that class is responsible for:

reading the file,
writing to the file,
checking if the file exists,
checking if the given path is a file or directory, etc.

But all these actions are under the umbrella of one broader task, interacting with the files.

Abstraction

Abstraction, in this case, is an umbrella term for Interfaces and Abstract Classes. In PHP those are the two main abstraction mechanisms.

Interfaces are contracts for behaviour. We use them to define the public API of a class, and ensure that when a message is sent to a class instance (object) which implements that interface, the object will always respond according to the definition otherwise the program will fail. In other words, the interface defines the methods a class needs to implement in order for our program to work otherwise it will break.

Interfaces can't be instantiated
Interfaces can only have method signatures
Interfaces can't have properties declared on them (although PHP allows them to have constants)
Interfaces can only have public methods

Abstract Classes are also contracts for behaviour, but they are more than that. Unlike Interfaces, Abstract Classes can also, like any other Class, have concrete methods and members/attributes (state) defined on them.

Abstract Classes can't be instantiated
Abstract Classes must have at least one abstract method
Abstract Classes can have concrete methods
Abstract Classes can have members/attributes (properties)
Abstract Classes can have all visibility levels (public, protected and private)

Program to an interface, not an implementation.

What does this mean? In plain words, this means: Type Hint your variables/properties to Abstractions (Interfaces/Abstract Classes) not concrete Classes.

By programming to interfaces, you are decoupling your code's design from its implementation. This enables you to replace pieces of your code more easily down the road if a need arises. Yep, your code's maintainability just skyrocketed. This will also make your code more testable because you will be able to mock certain parts of your system just by implementing the interfaces and replacing the "production" behaviour with the "testing" one.

Abstractions shift our focus upwards, from the methods' underlying implementations to their signatures, because in a sense they don't concern us, as long as Abstractions' method signatures and their definitions (arguments and return values) are being respected everything will work. This allows us for a more robust and flexible codebase. Let's take a look at the following examples.

Good example - Since we programmed to an interface and not an implementation, changing the storage method is just a matter of changing the class we provide through the App's constructor, we are changing just one line of code.

// Storable Interface
interface Storable {
    public function store(array $data): bool;
}

// Database Storage
class Mysql implements Storable {

    protected $conn;

    public function __construct(PDO $conn)
    {
        $this->conn = $conn;
    }

    protected function insert(string $table, array $data): bool
    {
         $columns = implode(',', array_keys($data));

         $placeholders = "?".str_repeat(",?", count($columns) - 1);

         $values = array_values($data);

         $sql = "INSERT INTO $table($columns) VALUES($placeholders)";

         $stmt = $this->pdo->prepare($sql);

         return $stmt->execute($values);
    }

    public function store(array $data): bool
    {
        return $this->insert('emails', $data);
    }

}

// File Storage
class File implements Storable {

    protected function write(string $file, array $data): bool
    {
        $file = new \SplFileObject($file.'.txt', 'a+');

        if (!file_exists($file.'.txt')) {

            $columns = implode(', ', array_keys($data)); 

            $file->fwrite($values, strlen($values));  

        } else {

            $file = new \SplFileObject($file, 'a+');
        }

        $values = implode(', ', array_values($data)); 

        return (bool) $file->fwrite($values, strlen($values));
    }

    public function store(array $data): bool
    {
        return $this->write('emails', $data);
    }
}

// Client
class App {

    public function __construct(Storable $storable)
    {
         $data = [
             'from' => 'foo@mail.com',
             'to' => 'bar@mail.com',
             'subject' => 'Hello',
             'body' => 'World'
         ];
         $storable->store($data);
    }
}

// Databse App
$dbApp = new App(new Mysql(new Pdo(...$config)));

// File Storage App
$fileApp = new App(new File());

Bad example - Imagine we wanted to change the storage method in this example, now this would amount to more effort than the previous one.

// Database Storage
class Mysql implements Storable {

    protected $conn;

    public function __construct(PDO $conn)
    {
        $this->conn = $conn;
    }

    public function insert(string $table, array $data): bool
    {
         $columns = implode(',', array_keys($data));

         $placeholders = "?".str_repeat(",?", count($columns) - 1);

         $values = array_values($data);

         $sql = "INSERT INTO $table($columns) VALUES($placeholders)";

         $stmt = $this->pdo->prepare($sql);

         return $stmt->execute($values);
    }
}

// File Storage
class File implements Storable {

    public function write(string $file, array $data): bool
    {
        $file = new \SplFileObject($file.'.txt', 'a+');

        if (!file_exists($file.'.txt')) {

            $columns = implode(', ', array_keys($data)); 

            $file->fwrite($values, strlen($values));  

        } else {

            $file = new \SplFileObject($file, 'a+');
        }

        $values = implode(', ', array_values($data)); 

        return (bool) $file->fwrite($values, strlen($values));
    }
}

// Client
class App {

    public function __construct(Mysql $mysql)
    {
         $data = [
             'from' => 'foo@mail.com',
             'to' => 'bar@mail.com',
             'subject' => 'Hello',
             'body' => 'World'
         ];
         $mysql->insert('emails', $data);
    }
}

Of course, both of these are trivial examples but imagine if these classes had many more methods that are being called deeper down in the code, it could give you quite a headache.

Encapsulation

Encapsulation and Tell don't ask principle go hand in hand. As we already said, objects should manipulate their own state. Allowing other objects to directly change the state of our object should be avoided. Once more:

Don't ask for the information you need to do the work; ask for the object that has information to do the work for you. (Allen Hollub - Hollub on Patterns)

By preserving encapsulation we are writing less bug-prone and more debuggable code because we are being explicit and we only change the objects' state when we send him a message.

We also use encapsulation to hide the complexities and intricacies of our abstractions and their implementations, this way we just keep the "simple stuff" available to the outside world, all those gory details are left hidden.

Visibility/Accessors are the way we ensure our objects stay encapsulated. There are three levels of visibility in PHP as in many other languages:

public - methods and properties are accessible from the outside world. When it comes to public methods they are what make up the public API of our class, those are the methods we want other developers and/or objects to interact with.
protected - methods and properties are accessible only from within the class and its children (other classes that extend it)
private - methods and properties are accessible only from within the class in which they are defined

Getters/Setters also known as accessors and mutators give us the ability to keep our objects encapsulated while at the same time having the ability to access and mutate their state, just instead of accessing it directly we do it through getter/setter methods.

// Without getters/setters
class Article {
   public $slug = 'foo';
}

$article = new Article();

// Imagine we wanted to check for equality
// but forgot to add the second '='.
// See, a simple typo could introduce a bug.
if ($article->slug = 'bar') {
    // Do something awesome here
}


// With getters/setters
class Article {
   proteceted $slug = 'foo';

   public function getSlug(): string 
   {
      return $this->slug;
   }

   public function setSlug(string $slug)
   {
      $this->slug = $slug;
   }
}

$article = new Article();

if ($article->getSlug() == 'bar') {
    // Do something awesome here
}

Inheritance

Inheritance is self-explanatory, an object will inherit all of the super (parent) classes' methods and attributes unless the visibility of the method is private and we achieve that by extending a class. You might have come across the phrase "Favour Composition over Inheritance" or some go even further and say that inheritance is evil. In my humble opinion inheritance is not bad, bad inheritance is though. Now how do we distinguish between good and bad inheritance?

Good inheritance is "is a (special case of)". The keyword extends also supports "taxonomy" which objects do better than classes, and "code re-use", which composition is far better for!
— Pim Elshoff (@Pelshoff) November 26, 2018

As @Pelshof perfectly said in his tweet you should look at inheritance as a special case of. We should look at a child class as a special case of its superclass, it has all the behaviour of its parent and then some. Good inheritance is shallow, you shouldn't go deeper then one level if you really must not and you should inherit from Abstract classes except in those cases where extending a concrete class makes sense, e.g. a concrete BaseController of a framework where you want to abstract a bit from the framework or add some common behaviour.

When you are extending classes you should always have the Single Responsibility Principle on your mind, use it as a litmus test, if you're breaking it by extending it's time for Composition.

Composition in simplest terms is breaking down a complex task into multiple reusable classes, instead of inheriting multiple levels deep. Composition vs Inheritance is in a sense like horizontal vs vertical scaling. With composition, you are breaking down your task horizontally, whereas with inheritance you are doing it vertically.

This illustration makes it more clear, on the left-hand side we have a parent File Class and its child and grandchild Reader and Writer classes respectively. So we broke our example file interaction task vertically.

On the right-hand side, we have the File Class and its dependencies*, two independent reusable classes Writer and Reader which we will inject to the File Class through its constructor. In this case, we expanded the responsibilities of the File Class horizontally.

Polymorphism

Polymorphism in plain English means that objects which implement the same interface can do different things "under the hood", as long as they adhere to the interfaces' definitions, thus the polymorph part.

We already covered this a bit when we talked about the Abstraction principle, the complexities and intricacies of the method implementations are hidden underneath the Interface - our one "single" point of entry and exit. We can implement a method in an infinite number of ways as long as we take the defined number of arguments and return what is expected, we're all set.

If you jump back to the Good example in the Abstraction section you will clearly see that it is also polymorphism at play. We have a Storable Interface and two classes which implement it and do two different things. Mysql stores to a database and the File writes to a CSV file.

Rome

I was speaking mainly from the perspective of a PHP developer, but all of these concepts can be applied to any programming language that supports the Object-Oriented paradigm. To prove my point let's compare how we would apply the Abstraction principle in PHP and Swift for a second.

In PHP we have Interfaces and in Swift we have Protocols, they are the same thing just a different keyword, no issue here, but when it comes to Abstract Classes Swift does not support them.

Although Swift has no notion of Abstract Classes they have a different language construct that allows us to have the same behaviour, namely Protocol Extensions.

Protocol Extensions allow us to extend the protocol and add additional methods and/or properties to it so we can achieve the same behaviour as Abstract Classes in the following way:

protocol Animal() {
    func sound();
}

extension Animal {
   func numberOfLegs() -> Int {
       return 4;
   }
}

class Cat: Animal {
   func sound() {
       print("woof");
   }
}


class Dog: Animal {
   func sound() {
       print("woof");
   }
}

let dog = Dog();

dog.sound(); // woof

dog.numberOfLegs(); // 4

See, these concepts are "languageless" ;)

We should all strive to adhere to these principles, but what these 2.5+ years of working professionally as a developer have taught me is that we should never be too dogmatic and that every rule has an exception.

* Dependency is a broad software engineering term used to refer when a piece of software relies on another one. Coupling (computer programming) In software engineering, coupling or dependency is the degree to which each program module relies on each one of the other modules. Program X uses Library Y.

Webcamp Zagreb 2018

Sasha Blagojevic — Thu, 04 Oct 2018 17:36:00 +0000

Is anyone from dev.to besides me going to Webcamp Zagreb tomorrow? :D

SEO Guide for Websites

Sasha Blagojevic — Mon, 01 Oct 2018 13:46:01 +0000

This guide will cover a very important topic for every digital business, search engine optimization. SEO can sometimes appear as a black box, there is a lot of magic behind it and it's constantly changing and evolving. In this article, we will try to dispell it by leading you through some of the SEO best practices.

Besides the latest Google algorithm updates, working on our company’s website SEO and trying to battle through the avalanche of information is what prompted me to write this guide, if nothing as a reference for future self.

This is by no means a comprehensive guide, I will go over the SEO fundamentals you need to cover if you want a shot at appearing on the Google's first page and we all know how it is in practice, if you are not on the first page, it's as if you don't exist, let's be honest, how often do you go to the second or the third page? Yeah, thought so…

If you are interested in the history of the Google's algorithm and how it changed over the time the guys and gals at Moz have organized it in a nice searchable list.

Let's start from the beginning, what is a search engine?

You know how your website has different pages, and it has a navigation bar that links to every one of them? Well, you can look at Google, or any other search engine for that matter, as the internet's navigation menu. Google "collects" all the websites from the world and indexes them. But how does he collect them?

Well, there are three ways how Google can discover your website:

From DNS registries - if you're not familiar with the term DNS, I recommend you read this article. While we're at it, did you know that Google itself is a DNS registrar although they do not sell domains?
If other websites link to your, Google will follow those links and discover you (unless there is a rel="nofollow" attribute on them). Those links are called inbound links and they are one of the major factors that determine your SEO ranking.
By adding your website and sitemap to the Google Search Console you are basically telling Google "Hi my name is so and so, and this is my address, here you can see my living room, and that is my kitchen, oh I almost forgot about the porch…" ;).

1. Google Search Console

This should be your first step on your path to SEO glory. Go to the Google Search Console, add your website and go through the verification process, and now you are at your first crossroads. You have two options:

You can either add both of your website versions, a non-www and www version (e.g. https://jsguru.io and https://www.jsguru.io) and choose a preferred one. In our case, we set the preferred one to be the non-www.
Or you can add only one version to the Google Search Console, whichever you prefer, and configure your server to redirect from the other version to your preferred one (e.g. add only https://jsguru.io to Google Search Console, and redirect from https://www.jsguru.io to https://jsguru.io). It must be a permanent redirect so your HTTP Response Code should be 301.

Either way, you must handle both of the domain variants, if you just leave them in the wild, without handling them as previously described, there is a high probability Google will treat them as duplicate content, and duplicate content is penalized.

On the other hand, it would be really bad user experience and detrimental to your brand if you served only one domain variant and your website errored out on the other one.

2. Sitemaps

Sitemaps are, as the name already says, a map of all your website pages represented in a format Google or any other search engine can easily digest. It is a collection of all your links, usually in an XML document, but it can also be in a different format such as HTML for example. Look at them as a skeleton of your website.
There are a lot of free online tools that can generate them for you. After you've done that you should submit it to Google Search Console under the Sitemaps section. This will allow Google to index you more easily, but still, be patient, it can take time.

If you have a publishing website like a news magazine or a blog, it would be best if you could find a way to automatically update them to reflect the changes on your website.

Since you can submit as many different sitemaps to Google Search Console as you want, a good approach would be to have at least two sitemaps, one for the "static" part of your website that doesn't change that often and another one for the "dynamic" part of your website which is updated frequently, like the blog section for example.

In our case we have two sitemaps, one that covers our main navigation and contains links to the pages like Home, About Us, What We Do and so on, and another one for our blog where we publish articles every two weeks.

3. HTTPS vs HTTP

From July 2018 Google Chrome has started to mark websites without HTTPS as non-secure, which could negatively impact your traffic, users might decide to leave your website because they perceive it as insecure, or they might get worried that it's some kind of a scam, in addition, HTTPS websites are reported to have a slight ranking advantage over HTTP websites.

In the early days of internet getting an SSL certificate and securing your website with HTTPS was a tedious and expensive process, but thanks to the open source community and Let's Encrypt Foundation it is now both free and easy to set up.
Follow these links for a detailed tutorial on how to add HTTPS to your website:

4. Meta tags

Yes, meta tags are still a thing!
The description meta tag allows you to customize the brief description which will be shown in the search results, otherwise, you're leaving it up to Google to determine what's important and what will be shown, which can lead to some nasty and completely unrelated descriptions. Traditionally, the description length was capped at 155 characters, but recently Google started to allow more, so to play it safe your description should be between 50 and 300 characters.

Although the keywords meta tag has been obsolete for some time, I still included it, because the SEO tool I use bugged me that it was missing and since I'm a bit OCD I just had to add it.

The og, not to be confused with original gangsta, meta tags are used by Facebook, LinkedIn, and other social media to determine what content will be shown when someone shares your page. Same goes for the twitter meta tags.

<meta name="description" content="JSGuru is a high-quality software development shop where clients come first. We build your desired products and provide excellent, long-term customer support so that you can focus on the core of your business.">

<meta name="keywords" content="software development, web development, mobile development">

<!-- Facebook-->
<meta property="og:url"                content="https://jsguru.io">
<meta property="og:type"               content="website">
<meta property="og:title"              content="JSGuru">
<meta property="og:description"        content="JSGuru is a high-quality software development shop where clients come first. We build your desired products and provide excellent, long-term customer support so that you can focus on the core of your business.">
<meta property="og:image"
      content="https://jsguru.io/img/jsguru.png" />

<!-- Twitter -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@jsguru_software">
<meta name="twitter:creator" content="@jsguru_software">
<meta name="twitter:title" content="JSGuru">
<meta name="twitter:description" content="JSGuru is a high-quality software development shop where clients come first. We build your desired products and provide excellent, long-term customer support so that you can focus on the core of your business.">
<meta name="twitter:image"
      content="https://jsguru.io/img/jsguru.png">

5. Canonical Links

What are canonical links? For all of you who are not familiar with the term, canonical links are HTML tags that you put in the HEAD of your document and their purpose is to point to the original source of the content.
Canonical links can point to a different page/ link from the current page you are on, or they can be self referencing, meaning they can point to the same page you are currently on.

When Google comes across a canonical link that points to a different page it says to him "Hey don't index this page, the actual source you should index is there.".

If the canonical link is self-referencing, that signals to Google "Ok this is the definite root of the content". If Google were to come across the same content again on a different website he would definitely know that your content is actually the original.

<head>
    <title>JSGuru - What We Do</title>
    <link rel="canonical" href="https://jsguru.io/what-we-do">
</head>
<body>
 ...
</body>

Do you remember how I mentioned earlier that we should handle both the non-www and www version of our domain? Well, be careful not to mix them in your canonical links, choose one preferred version and stick with it!

6. Localization - hreflangs

What if you have a multilingual site and you want different language versions served depending on the country of the visitor? How to go about that?

A common, but a discouraged approach is to geolocate the user by his IP address. This is usually done by storing the IP tables in your database and comparing them with the user's or using a third party service like Ipinfo.
After determining the user's location you would store it in a cookie and serve the appropriate language.

This seems like a sensible approach, doesn't it? But why is it discouraged?

Well, firstly the geolocation by IP is not that precise, especially nowadays when people value their online privacy and are using VPN's more and more, additionally, some internet providers themselves use proxies when giving out dynamic IPs.

Secondly what if the user is a German but he is in England on a business trip? He would get the English version and we don't want that.

Thirdly you are taking away the possibility to manually choose the language version from the user.

Last but not the least, you are preventing Google from properly indexing all your website versions because their crawling servers are mainly in the US.

Now that we went over what not do, let's go over what you should do!

First and foremost, the pages your hreflang links are pointing to should have the same content just in a different language, they should never have a completely different content, that is a NO NO.

When it comes to actual linking, you have two options:

a) Add hreflang link in the head of the HTML document

<!-- English (default) language page -->
<head>
    <title>JSGuru - What We Do</title>
    <link rel="canonical" href="https://jsguru.io/what-we-do">
    <link rel="alternate" 
          hreflang="x-default"  
          href="https://jsguru.io/what-we-do" />
    <link rel="alternate" 
          hreflang="en" 
          href="https://jsguru.io/what-we-do" />

    <link rel="alternate" 
          hreflang="de" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-ch" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-at" 
          href="https://jsguru.io/de/was-wir-tun" />
</head>
<body>
 ...
</body>

It is important that you add the hreflang links on all pages not just your default language page.

<!-- German Language Page -->
<head>
    <title>JSGuru - Was Wir Tun</title>
    <link rel="alternate" 
          hreflang="x-default"  
          href="https://jsguru.io/what-we-do" />
    <link rel="alternate" 
          hreflang="en" 
          href="https://jsguru.io/what-we-do" />

    <link rel="alternate" 
          hreflang="de" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-ch" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-at" 
          href="https://jsguru.io/de/was-wir-tun" />
</head>
<body>
 ...
</body>

Be careful not to combine hreflang tags with canonical links which point to different pages, as well. Hreflang tags can only be combined with self-referencing canonical links.

In our code example, we included the canonical link only in our English (default) language page, that's because that is the original source of our content, the German page shouldn't include the canonical link because it's the same content just in a different language, if we were to include it we would just confuse the Google crawler.

b) Add hreflang link to the sitemap

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://jsguru.io/what-we-do</loc>
    <xhtml:link rel="alternate" 
                hreflang="x-default" 
                href="https://jsguru.io/what-we-do" />
    <xhtml:link rel="alternate"
                hreflang="de"
                href="https://jsguru.io/de/was-wir-tun"/>
    <xhtml:link rel="alternate"
                hreflang="en"
                href="https://jsguru.io/what-we-do"/>
    <lastmod>2018-08-28T09:24:19+00:00</lastmod>
    <priority>1.00</priority>
  </url>
</urlset>

IMPORTANT - you should always provide the full link including the protocol (also known as an absolute link) to the canonical or hreflang link tags!

You can read more in-depth about localization, hreflang tags and an additional approach to localization I didn't cover here.
Here are some tools which can be helpful:

7. Images and Videos

When it comes to images you should always add the alt attribute which contains the textual description of the image. The benefits of adding alt attributes are twofold, firstly it will make your website more accessible, the visually impaired people will get the description of the image, and secondly Google will be able to understand the context of your images which will, as a result, increase your visibility in the search results both on the general search and image search.

Same goes for the videos as well. No matter whether you are adding them directly on your website or on platforms like Youtube/Vimeo you should always provide transcripts. Google can't process images and videos, the only way search engines can discern their content is by textual descriptions.

8. Google Structured Data

If you ever thought about SEO being a black box, wait 'till you start with Google Structured Data, that is a black Pandora's box. There's no closing this lid when you open it.

This is such a vast topic that it deserves a whole new blog post in itself, but I'll try to cover the basics here and provide you with some helpful links.

Google Structured Data is an implementation of the Schema.org standard for rich data. Google uses this data to fill it's Knowledge Graph, and show you rich search results a.k.a. Google Rich Cards.

What's more, you can do everything right and your structured data might still not appear in the search results.

Using structured data enables a feature to be present, it does not guarantee that it will be present.
The Google algorithm tailors search results to create what it thinks is the best search experience for a user, depending on many variables, including search history, location, and device type.
In some cases, it may determine that one feature is more appropriate than another, or even that a plain blue link is best. - per Google's Policy

You can provide the structured data in three formats, but Google recommends JSON-LD so we will concentrate on that format. Here is an example of how it looks:

<script type="application/ld+json">
    {
         "@context": "http://schema.org",
         "@type":"LocalBusiness",
         "address": {
             "@type": "PostalAddress",
             "addressLocality": "Manhattan",
             "addressRegion":  "NY",
             "postalCode":"10036",
             "streetAddress": "400 Broadway"
         },
         "description": "This is your business description.",
         "name": "Craig's Car Repair",
         "telephone": "555-111-2345",
         "openingHours": "Mo,Tu,We,Th,Fr 09:00-17:00",
         "geo": {
             "@type": "GeoCoordinates",
             "latitude": "20.75",
             "longitude": "13.98"},
             "sameAs" : [
                 "http://www.facebook.com/example",
                 "http://www.twitter.com/example",
                 "http://plus.google.com/example"
             ]
    }
</script>

Here we have an example of LocalBusiness entity which is a subset of Organization entity. You should always try to be as specific as possible with structured data and use the most narrow definition of the entity as in this example. Additionally, you should always try to provide all possible attributes.

You can find example snippets that have been tried and tested by the community on this link, just replace the values with your own.

I also recommend Merkle structured data generation tool for starters, and later when you get a better understanding of how everything works you can expand on the generated data with additional properties.

Another option is to use Data Highlighter, it is a tool within Google Search Console under Search Appearance section, but it is currently only visible in the old view! Google is currently rolling out a new Search Console so I'm not sure about the future of this tool, it is to be determined.

Where should you put your structured data?

Structured data should go in the head of the HTML document.

<head>
    <script type="application/ld+json">{...}</script>
</head>

There is one general rule of thumb that you should adhere to, all the data that you've put in the script tag should be actually visible on that page. For more info, you should consult the Google Guidelines.

Here are some links that could be helpful, as well:

Intro to structured cards
Guides
Rich Cards Search Results Testing Tool (currently in beta and limited to following entities: Job posting, Recipe, Course, TV and Movie, Event)
Google Structured Data Validation Tool
Google's Simple Tutorial on How to Add Rich Cards

9. Google Local Business

Google Business, among other things, is essentially a more user-friendly way of adding LocalBusiness structured data, and you should definitely do it!

If your business has multiple locations you should add all of them. It is best to combine this method and adding structured data manually because if Google's Knowledge Graph is populated with your social media pages and B2B platforms like Clutch it will automatically link them to your business and your reviews will be shown in the rich results.

There's nothing much to add here, let's move on!

10. Blog

Blog is still the Holy Grail of SEO and Digital Marketing. Despite the over-saturation with articles on many topics, this is still the best organic way to build links and increase traffic to your website.

You should try to publish regularly, but you shouldn't sacrifice quality over quantity, Google's algorithms have shifted more towards quality vs. quantity in recent years. Not only do they look for quality in the content but the quality of the links that lead to it as well.

When it comes to the blog the only dilemma you can have is whether to host it on a subdomain e.g. blog.jsguru.io or a subfolder jsguru.io/blog.
Well, actually it's not a dilemma, you should host it in a subfolder because subdomains are treated as different domains by Google so they will need to build their own reputation independently of your main domain. There is no value added to you with this approach.

When it comes down to the implementation of the blog you should still, at least partially stick to the old-school server-side rendered approach because Google indexing is two-pass, the second pass is for JS only websites which is a week after the initial pass, especially if your business model is centred around publishing. This has been confirmed by a Paul Kinlan on Twitter:

Paul Kinlan

@paul_kinlan

@HenrikJoreteg Indexing is delayed for pure client side sides. Google indexer is two-pass, first run is without js, then week later it's with is (or there abouts)

12:26 PM - 12 Sep 2018

11. Google Page Insights

Performance is one of the major factors of your ranking. The lower the load time of your website the higher your ranking will be, especially when it comes to mobile devices.

One great tool you can leverage when it comes to performance tweaking is Google Page Insights.

Some basic and common ways of improving your website performance are:

Minify your javascript and css files.
When adding jpg/jpeg images compress them to 80% of the quality, the difference will not be visible in the web environment but their size will significantly decrease.
If possible use a cookieless (stateless) domain to serve your static assets like images. Serving different images for different screen sizes. There is no need to load a 1920x1080px image on a 320px wide screen.
Lazy loading images - loading images only when they enter the viewport of the device.
Gzip compression and browser caching (images, javascript, css). Here's a nice tutorial for improving your page insight rank for ngnix servers. If you're using apache you should look up mod_deflate and mod_expires extensions.
Use script defer and async.

12. Mobile Responsive and Mobile First Indexing

More and more internet users are coming from mobile devices, actually, they have surpassed the desktop users in general, and according to this trend, Google has shifted its focus on mobile devices several years ago. If you remember Google used to show a tag mobile-friendly in its search results.

Nowadays there is no need for it, and having a mobile-friendly website that offers a pleasant experience on all screen sizes is a no-brainer. In order to offer a better mobile UX, some people have sacrificed the content in the mobile versions of their websites.

With the latest changes to Google Algorithm, now they might pay the price for it. Google has started mobile first indexing, but what does that mean?

Previously Google would crawl the desktop version of the website for indexing, from now on, the mobile version will be used for indexing. So if you left out content to fit everything nicely in the smaller screens, your SEO might suffer.

13. Summary

If you've come this far I congratulate you, it has been exhausting for me to write all of this, I can only imagine how it is to read it! Yes, you deserve to pat yourself on the shoulder.
If I wanted you to take anything from this article it would be the following.

The three most important factors for good SEO are:

quality content,
quality traffic and
quality links.

As with everything in life quality trumps quantity, long gone are the days where you could just pay for links on some obscure websites or churn out shallow articles that barely touch the topic they are supposed to cover.
And lastly, have patience, these things take time, Google has no infinite amount of resources, and indexing new websites is not really on the top of their priority list, so it might take a few weeks or even months, to start having some real results.

OMG! I almost forgot I highly recommend you watch this Q&A with Riva from Digital4Startups we had the privilege of hosting her in our offices. The video quality su*ks but the audio is the important part anyway!

Before you go…

Leaving the Old Ways - jQuery vs React

Sasha Blagojevic — Thu, 16 Aug 2018 15:21:30 +0000

Contrary to popular belief, React’s biggest use cases are not SPAs, it’s the hybrid apps that are most common, and the best fit in my opinion, in this post I will cover how and why I went from a React hater to a React fanboy, and why React is a perfect replacement for jQuery.

I used to have some kind of an inner resistance when React and Vue first started to gain traction and were becoming the de facto standard for building modern UIs.

Yes, I’m purposefully leaving Angular out, even though AngularJS was the pioneer of the front end revolution that brought us web 2.0.

Angular is philosophically on the completely opposite side of the spectrum, it’s a full-blown SPA framework, whereas React is just a view library, and I’m still not convinced SPAs are the right way and personally I prefer the hybrid approach.

For all of you that are thinking right now - “And what about Vue?” , Vue would be somewhere in between these two extremes.

Contrary to popular belief, React’s biggest use cases are not SPAs, it’s the hybrid apps that are most common, and the best fit in my opinion. Don’t believe me? Well look what Facebook’s Dan Abramov had to say:

It’s interesting that React became associated so much with SPAs but Facebook isn’t using it for SPAs (except for the Instagram website and some internal tools) - @dan_abramov

One of my major pet peeves was Webpack and all the tooling they brought with themselves.

I held a strong opinion that they were introducing unnecessary complexity to the front end, yes they made us developers feel like rocket scientists with the amount of tweaking we had to do and the number of levers and gears we had to pull and turn to make them run, but at the end of the day, did they really add value to the business?

Did they improve the product and the user experience to warrant a higher maintenance and development cost and a higher barrier of entry for new bloods, when we could have done the same with plain ole jQuery, or even better, vanilla JS?

After I found out React introduced react-cli I decided to give it another go, and boy oh boy was I pleasantly surprised.

With the introduction of react-cli (and vue-cli) all that nitty-gritty tooling and those build steps that were equivalent of getting a PhD in Computer Science were out of the way for 80–90% of use cases, although you still had to roll up your sleeves and mess around with webpack for some edge cases.

Sure if you’re building something fairly simple, may it be a contact form with an Ajax submit or something entirely different but that is simple enough, vanilla JS is, in my opinion, a sound approach, there is no need to roll out the big guns. You can even go with jQuery, but there is really no need for it in today’s world, but that’s a completely different topic.

Keep it simple - this should always be your mantra.

In that case, if you were to use a framework, 90% of your code would be the frameworks infrastructure and the rest would be your actual logic. That is a major overkill, you are introducing unnecessary boilerplate and increasing your bundle size which directly impacts performance. Bigger bundle means a lot more bytes have to be sent over the INTERNETZ, so you’re actually costing your business, just because you wanted to use that shiny new thing.

Oh, you think those milliseconds don’t matter much? Well they can quickly add up, especially on high traffic sites, just because today’s machines are powerful doesn’t mean we should be reckless and throw anything at them, we need to be conservative with our resources.

Look at it like this, it’s as if you are building a foundation for a ten story building only to put a tent on it.

React, versus the old way, really comes to shine when you are building complex UIs.

With React the simplicity of development increases with the complexity of the UI you are building, or in other words, the cost of development is inversely proportional to the complexity in comparison with the vanilla JS/jQuery approach.

Here’s a little graph for all you visual types.

Talk is cheap, let’s get our hands dirty with an example from the real world.

We have an invoice form, aside from the general data like the date of the invoice, the due date of the invoice, subject etc., the user needs to be able to add/remove invoice items.

Invoice items, on the other hand, have the following:

name and/or the description of the product/service you’re invoicing,
it's quantity,
price,
any discount you may give,
any penalty interest that incurred,
then we might have VAT tax or sales tax depending on your country’s laws

and finally, all the calculations that go with the aforementioned.

You see now how a seemingly simple thing can get complicated quickly?

With the old approach, you would have to have a lot of things on your mind, you would need to:

Add change event handlers on all the different input fields, and some of them would additionally need to cancel each other out so you would need to track when to detach them.
Every time an invoice item is added or removed you would need to manipulate the DOM, by either adding or removing child nodes or writing HTML as a string.

No matter the choice, you’d need to concatenate some HTML and fill it with variables, which can get unruly pretty fast. ECMA 6 string literals do ease this a bit, but still, it can get cumbersome.

Imagine a designer changes something, on how many places would you need to changes all those bits that you’re glueing together in your vanilla JS code?

Another thing you would need to keep in your mind is that if you manipulate DOM as a string you’re killing all the event handlers on those particular DOM elements. Yep, another gotcha moment.
Calculations - every time an invoice item is added or removed you need to calculate its particular values and in addition update the invoice’s subtotal, tax, total, etc. Essentially you would be creating your own state store.

I probably might have missed a thing or two that would pop up while trying to handle this use case the old way, as it usually is, everything sounds simpler on paper until you start to implement it and a whole new spectrum of cases that need to be handled appears.

Using React requires a slight shift in your mindset, in a nutshell, you only need to be concerned with one thing, the state. This simplifies the logic immensely, you are only concerned about your state, that is the only thing you need to manipulate, and your invoice input fields and invoice items will be re-rendered according to the changes in your state.

Let’s take a look at our simplified code example, this might give you a clearer picture.

import React from "react";
import ReactDOM from "react-dom";
import PropTypes from "prop-types";

class InvoiceItemForm extends React.Component {

  constructor(props) {
      super(props)

      this.state = {
          itemInput: {
              description: '',
              quantity: 0,
              price: 0,
              subtotal: 0,
              taxRate: 0.17,
              tax: 0,
              total: 0
          },
          invoiceItems: []
      }

      this.handleInputChange = this.handleInputChange.bind(this);
      this.addItem = this.addItem.bind(this);
      this.removeItem = this.removeItem.bind(this);
  }

  handleInputChange(e) {
      let input = (e.target || e.currentTarget);
          input.subtotal = input.price * input.quantity;
          input.tax = input.subtotal * input.taxRate;
          input.total = input.subtotal * (1 + input.taxRate);

      this.setState((state) => { return state.itemInput[input.name] = input.value; });
  }

  addItem() {
      let state = this.state;
          state.items.push(state.itemInput);

          // Clear the last input
          for (let key in state.itemInput) {
              switch (key) {
                  case 'description'
                      state.itemInput[key] = '';
                      break;
                  case 'taxRate':
                      state.itemInput[key] = 0.17;
                      break;
                  default:
                      state.itemInput[key] = 0;
                      break;
              }
          }

      this.setState({itemInput: state.itemInput, items: state.items});
  }

  removeItem(e) {
      let rowIndex = (e.target || e.currentTarget).parentNode.parentNode.rowIndex;

      let items = this.state.items.filter((item, i) => { return i !== rowIndex; });

      this.setState({items : items});
  }

  renderCells(item, rowIndex) {
      let cells = [<td>{rowIndex + 1}</td>];

      let i = 1;
      for (let key in item) {
          cells.push(<td key={i}>{item[key]}</td>);
          i++;
      }

      cells.push(
          <td>
              <button onClick={this.removeItem}>
                  {'Remove Item'}
              </button>
          </td>
      );

      return cells;
  }

  render () {
    return (
        <React.Fragment>
            <div>
                <input
                    name={'description'}
                    value={this.state.itemInput.description}
                    onChange={this.handleInputChange} />
                <input
                    name={'price'}
                    value={this.state.itemInput.price}
                    onChange={this.handleInputChange}>
                <input
                    name={'quantity'}
                    value={this.state.itemInput.quantity}
                    onChange={this.handleInputChange}>
                <input
                    name={'taxRate'}
                    value={this.state.itemInput.taxRate}
                    onChange={this.handleInputChange}>
                <input
                    name={'subtotal'}
                    disabled={true}
                    value={this.state.itemInput.subtotal}
                    onChange={this.handleInputChange}>
                <input
                    name={'tax'}
                    disabled={true}
                    value={this.state.itemInput.tax}
                    onChange={this.handleInputChange}>
                <input
                    name={'total'}
                    disabled={true}
                    value={this.state.itemInput.total}
                    onChange={this.handleInputChange}>
            </div>
            <table>
                <thead>
                    <tr>
                        <th>Item no.</th>
                        <th>Description</th>
                        <th>Price</th>
                        <th>Quantity</th>
                        <th>Tax Rate</th>
                        <th>Subtotal</th>
                        <th>Tax</th>
                        <th>Total</th>
                        <th></th>
                    </tr>
                </thead>
                <tbody>
                    {
                        this.state.items.map((item, i) => {
                            return (
                                <tr key={i}>
                                    {this.renderCells(item, i)}
                                </tr>
                            );
                        })
                    }
                </tbody>
            </table>
        </React.Fragment>
    );
  }
}
export default InvoiceItemForm

Vuoala, that’s it!

Hey, do you have a jQuery app you would like to migrate or are you just trying to figure out which framework would be best for your next million dollar idea? Contact us at info@jsguru.io, and let that be our headache.

Before you go…

Originally published at jsguru.io.

Online NPM downloads calculator

Sasha Blagojevic — Thu, 21 Jun 2018 14:51:35 +0000

Hey guys, long time no read!

Besides being a T-shaped full stack developer at JSGuru (a fancy and made up term I identify with now), additionally I work as part of the sales team and I'm also one of the people that manages our open source efforts.

All these responsibilities mean that I have quite a few meetings over the week and I need to produce numbers so we can track our analytics, and that includes the number of downloads of our open source projects.

To make my life a bit easier I made an AI bot that calculates all downloads for a given NPM package and given period... lol just jokin', it's not AI, it's just a few if statements and a function here and there. ;)

A really simple tool but it gets the job done.

Try it out, it might come useful to you as well. I have a few ideas for new features, I'll be adding them from time to time. :)

Javascript needs competition on the front end. Thoughts?

Sasha Blagojevic — Sat, 02 Jun 2018 14:18:37 +0000