Forem: Danny de Vries

I'm Danny de Vries, Web development lecturer at the Amsterdam University, Ask Me Anything!

Danny de Vries — Tue, 12 Feb 2019 16:44:08 +0000

I'm a lecturer and researcher Communication and Multimedia design at the Amsterdam University of Applied Sciences.

I mostly lecture about web development in the technical courses of our program such as Back-end or Project Tech which are courses focussed on HTML, CSS, JavaScript & Node.js. Besides that I teach people about Web Animation during the Minor Visual Interface Design which focusses on keyframing, transitions, processing & SVG.

Apart from teaching in front of a classroom I've coached lots of students helping them navigate the design and agency field:

I've helped them with their portfolio's to land internships.
I've improved their soft skills like presenting and communicaton.
I've helped them to choose what skills to focus on during their studies.
I've had 1-on-1 sessions to set goals and actually reaching them.
I've given constructive feedback and design critique on work students handed in.

I'd love to chat about these topics or give any feedback!

Challenge: CSS Navigation

Danny de Vries — Thu, 11 Oct 2018 13:30:38 +0000

Here's a quick challenge I came up with the other day. A very common navigational pattern is to put the logo on the left side and the list items on the right.

Recreate the layout of this navigation with as little html and css as possible.

My personal solution uses flexbox with 7 lines of html and 13 lines of css. Is it possible with less?

EDIT: This is wat I came up with: https://codepen.io/anon/pen/wYebQg

Best advice for a junior software developer?

Danny de Vries — Mon, 08 Oct 2018 16:08:51 +0000

Based on the posts of Ted Hagos and Sergio Tapai I wanted to share my two cents (literally) on the topic. There are a lot of small little things that can help you get further. Instead of a long 143 items list with small things I wanted to point out two general principles I apply every single day, even outside of coding.

1. Find a balance.

You won't learn how to code by just reading books and watching courses. With actually writing and putting it into practice comes extra obstacles you can solve. These can help you in future similar situations. The opposite is also true, building things is great but always question your own workflow and see if there are any other ways (Shoshin) for solving the same problem.

2. Don't ride the bandwagon.

Learn the fundamentals first. HTML, CSS and JavaScript aren't going away any time soon. That doesn't mean learning frameworks and libraries is a bad thing but dive into one to broaden your skill set and if it seems relevant to you, not because it's what all the job listings tell you.

On a last note, I highly recommend you watch this video about 'The Gap' by Ira Glass. It fundamentally changed the way I look at other people that try to code for the first time.

Thanks for reading! You can follow me on @dandevri and feel free to reach out to me if you have something to say!

100 Days of Code Takeaways

Danny de Vries — Mon, 01 Oct 2018 15:27:27 +0000

About a year ago I made a promise to myself: spend an hour every day learning new stuff. In the weekends I would watch a course or read some articles but the time devoted on 'learning' was really inconsistent. That's when a couple of months later I started my 100 days of code challenge.

What is 100 Days of Code?

You've probably seen this hashtag a couple of times but here's a quick primer.

Code for at least an hour every day for the next 100 days. Make this a public commitment and track your progress.

Some personal extra rules:

Aside from the code I will create a log and update it each day.
The code examples and log are pushed to GitHub.
I code at work but that time doesn't count towards this challenge.

Goals

The 100 days were focused on improving my core JavaScript knowledge. My first thought was: I don't have the discipline to keep it up for a 100 days and why should I even bother? After finishing the Minor web Development at AUAS I started noticing that I was still struggling with even basic JS concepts. From not knowing enough to not knowing at all.

It was this moment that I realized that these 100 days might be useful to force me to actually learn these concepts and start taking action.

That coding for an hour evolved around three main pillars:

Refresh my basic JavaScript knowledge (e.g FreeCodeCamp)
Learning new syntax (e.g ES6 for Everyone)
Solving real world problems (e.g JavaScript 30

Takeaways

After coding for about 100+ hours I wanted to share some takeaways and the upsides this challenge can have.

You form a habit

This one is a bit obvious but I really felt it. You just have this solid goal at the end of each day that you have to complete this. I used Trello for daily tasks and just made a reminder task everyday.

You can do more than you think

When I first started I put some resources in the readme and thought that those kept me busy for at least 100 days. In the end I worked my way trough far more resources than originally thought. After almost 30 days I did all the resources I wanted to do when I started.

The form of the resourcedoes matter

I couldn't just read for a whole hour in a book I had to switch from time to time. Use different types of resources: read a book one week and watch a video course the other week. Switch it up.

Split up time

The first week or two I just sat down for an hour straight but after I started noticing that I was more focussed by splitting up the time throughout the day. Maybe two sessions of 30 minutes or even three of 20 minutes. Mornings were pretty good for reading while the evening was more suited for video's.

Track your time

Look at your tracked time to get a grasp of how you're progressing. Maybe the mornings you finish more resources than in the afternoon. It also gives you credibility, you can make the logged time public if you want to.

Repetition isn't bad

Covering the same topic or same concept multiple times isn't bad. It's a nice refresher and most of the time the person handling the topic has a different way of explaining so you get multiple views on one specific topic.

It was worth it. You feel more confident while writing JavaScript, you become better at explaining concepts to other people and the code you write becomes more explicit because you make thoughtful decisions based on the knowledge you gained.

Thanks for reading! You can follow me on @dandevri and feel free to reach out to me if you have something to say!

Why is HTML linting not a common practice?

Danny de Vries — Wed, 26 Sep 2018 17:55:39 +0000

We use linters such as ESLint and Stylelint all the time but why is linting HTML not a common practice?

I occasionally see people use the W3C Validator but never see specific HTML linters in a build process / pipeline.

Why is that?

The definition of APIs

Danny de Vries — Mon, 24 Sep 2018 16:29:24 +0000

You can’t have a conversation with a developer without the person mentioning the word API at least 50 times. In this post I want to explore what the definition of a API is and what types of APIs there are.

The Definition

Connectivity is an amazing thing. How do different applications and devices connect to each other? It’s the Application Programming Interface.

APIs create connectivity between applications and devices.

Most computer programs provide data for humans in the form of a User Interface, to make the consumption of the data as enjoyable as possible. Operating Systems all provide GUI’s (graphical user interface) to interact with the system. The user doesn’t really care about the technical stuff. Similarly an API provides a simpler way for developers to interact with other kinds of software. The data needs to be consumed by another program instead of a ‘user’.

As with a UI tailored to humans, software needs an interface that makes it easy to consume data and/or functionality.

The API is the messenger that takes requests and tells the system what to do and returns the response. You can for example access the database of another company. The API has an interface and can ask for information about other systems. You can say that the API is the middleman to communicate between different programs.

The API layer help standardize the coding process. On the web that might be a JavaScript based API, it’s an abstraction of the underlying process.

The Wall Socket Analogy

The programmable web published a great series; what are APIs and How Do They Work? They have a great little analogy that I want to refer to:

You can think of an API in the context of a wall socket. The electricity is the service and the device is the consumer of that service. The consumer in this case is outsourcing its power requirement to the provider of a service. Electrical sockets have predictable patterns. The plug is standard and the power it delivers (volt) is consistent and mostly the same value. Likewise, an API specifies how software components should interact with each other.

Imagine how you would get power without such a standard.

The Benefits

APIs can not only help developers to write better programs, it can help the community around the program as a whole because of the API infrastructure:

If the API is public everybody can plug into it and start working on projects.
Other programs can easily be moved, the data remains the same.
It adds a layer of abstraction to the underlying service.
APIs make developers more productive (they don’t have to start from scratch)

On the web this means you can outsource functionality to the browser and add data from other services. Browsers offer a standard way for web applications to access, cameras, audio & Bluetooth for example. This is the same for services / apps such as Slack or Twitter. You can use the Real Time slack API to send messages without the Slack interface with just a few lines of code.

Types of APIs

You can ask for specific information by calling endpoints with specific parameters. You basically ask for subsets of the large database from the service. There are no rules of how developers should connect their own applications to an API but several standards have rised.

The first distinction to make is if the API is public or private.

If the API is fully public you can request data without any additional information.
If the API is public you can request data with a public key provided by the service. By adding the key when you make the request you are allowed to make API calls. Be aware that with a public key most APIs will have limitations. If the API is private you will need a key as stated above but the key isn’t publicly available. The service will personally need to provide you with a key.

Authentication

If you want to manipulate data from a specific user (the user has to sign in) most APIs use the OAuth open protocol.

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications

It allows you to interact with protected data from a specific data of a user. For example; add playlists to a specific Spotify account without using a Spotify interface.

Rest API

Most interfaces on the web make connections using the HTTP protocol. You can ask for data using the API endpoint addressable over the web with the HTTP protocol. (GET, PUT, POST & DELETE) You can make a request to a specific endpoint and because an HTTP request is always a round trip you get back the response for use in your own application. On the web most of the time this response is in .json format.

RTM API

Some services take a slightly different approach and instead of using the HTTP protocol they use a WebSocket-based API which allows you to receive events in real time. Instead of asking for information the API can push information to you.

You can achieve a kind of similar result with a Res API by Polling. (Simply calling the endpoint very frequently) Polling is kind off the same as a refresh button. It works but it isn’t the best solution.

Web API

To be clear; most of this post cover APIs from other services to request data. There are also specific Web APIs. They are used for manipulating the DOM and can be accessed using JavaScript with object types. The Web APIs extend the functionality of a web browser and thus are browser specific.

Standard JavaScript APIs. These are the same core JavaScript and DOM APIs that you can use in standard web apps.
HTML features and other emerging APIs which are browser specific.

Hope this post clarifies some of the concepts around APIs, why should you use them and why they are awesome⚡️ in general!

Thanks for reading! You can follow me on @dandevri and feel free to reach out to me if you have something to say!

Using GitHub as a team

Danny de Vries — Mon, 17 Sep 2018 14:53:01 +0000

Using GitHub for the first time has a steep learning curve. To use GitHub with a team is a whole different ball game. Here are some best practices I’ve come to know during my team projects.

Throughout the various OSS projects that I contributed to one thing always takes up more time than I expect. Setting a Git(Hub) standard for working on a repository (or repo as the cool kids say it). Below are some best practices that really helped me along the way.

Protect your branches

The first thing that prevents headaches in the future is to protect the master branch and make a develop one right away. It disables force pushing and prevents branches from being deleted. A great way to protect you’re project and make sure that you don’t have to 🚑 hotfix anything if you use continuous integration for example.

Consistent branch naming

With the master branch protected contributors can’t push straight into master. They have to use branches and make pull requests. Coming up with a naming convention for the branches is very helpful. One of the things is to use prefixes:

fix/...
feature/...
enhancement/...

In a quick overview you can see what each branch is for and they have consistent naming.

Pull requests

Make sure PR’s can’t be merged without a required review. If you protect a branch you can also enable Require pull request reviews before merging. Every PR that comes in has to be reviewed by another contributor.

So, merging is blocked by default. A contributor has to manually navigate to the PR and hit review changes. You then can either:

Make comments for general feedback. (No explicit approval)
Approve the changes and the PR can be merged
Request changes, things that have to be fixed before merging.

A great way to get a quick quality check before the code get merged.

It keeps the overall quality of the code on point.
More eyes 👀 are better. Somebody else can spot a mistake you might have missed.
And personally, I think it’s a good way to learn by looking at somebody else’s code.

Commit messages

Oh god, commit messages. Always a painful topic to talk about. Everyone has a personal / preferred way to do it. Chris Beam has written a great post about this in 2014. It are some general rules but most people find them acceptable.

You should definitely read the full post.

Ideally your commit title would look like this:

Add styling for navigation bar

Usually these rules are outlined in the contributing.md and examples are given.

Plan your commits

Guilty as charge of commiting a large blob of code. But, planning your commits is also a good strategy to keep yourself in check. Before you go straight into building that feature try to break the feature down into small steps. Each step then represents a commit. Here is a quick little post on dev.to about this.

Coming up with a consistent GitHub standard and flow may take some time but it’s worth it in the long run. It makes the repo far more maintainable and has saved me from panic situations.

Thanks for reading! You can follow me on @dandevri and feel free to reach out to me if you have something to say!

What do you think of static design tools?

Danny de Vries — Thu, 13 Sep 2018 18:29:16 +0000

Designing in the browser is all the rage. 'Should designers code' is a long running meme. What do you think of the static design workflow that is very common in the agency world from a development perspective?

Especially the last couple of years the landscape for design tooling got pretty scattered. We have at least 5 major tools: Sketch, Figma, Adobe XD, InVision Studio and just recently Framer X launched.

If you design something for yourself, you go straight into the browser or first explore some options in static design tools? It's not really about which tools is the best but is there still a place for these tools in the design workflow?

Back to JS Basics

Danny de Vries — Mon, 10 Sep 2018 18:38:04 +0000

JS is here to stay, without you I got trouble. To understand you here is a quick refresher on the basics of JavaScript.

We all read this article from a couple of years ago. (NO!? you've been living under a rock or something?) It's easy to get caught up in a JavaScript library and never get out. I've seen people know more about React and jQuery than pure vanilla JS.

When I started the Minor Web Development at the University of Applied Sciences Amsterdam I had (what Buddhist call) a beginner's mind.

It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

People around me would sit behind their keyboard and start writing line after line of complex JS code. I would come in, and curious as I was, would ask 'simple' questions like;

Where does this function gets invoked?
What are the initial arguments of this function?
Where do you declare this variable?

And what bothered me is that some people couldn't give me straight up answers so I could learn from them. Don't get me wrong, most people are really great at handling complex JS stuff (and libraries) but to me it feels like they get caught up and lose sight of general JavaScript (programming) concepts.

So with this in mind I wanted to write a quick (yeah, you can call it a cheat sheet) refresher on basic JS concepts.

Programming vs Scripting.

People argue about if programming or programming language is really the correct term to describe JavaScript. JavaScript doesn't stand by itself, it needs to use a interpreter. In most cases this is the browser or a standalone JS engine. It isn't native machine code (binary 01010) but it needs to be compiled and that's where the browser comes into play.

To play it safe I would call JavaScript a scripting language which falls under the larger category programming language.

Variables.

Variables store data and manipulate it. They do this by using a label to point to the data. In JavaScript data can be one of the following 7 data types:

undefined
null
boolean
string
symbol
number
object

They can store different values at different times.

To declare a variable: var keyword with myVarname of the variable.
Store value in a variable with the assignment operator: =
Initialize the variable with a data type: 19 (in this case a number)

var myVar = 19;

A variable that is only declared but has no initial value has the value of undefined.

var a; // value is undefined

Functions.

You can divide up your code in reusable parts by using functions.

function myFunction() {
// do stuff
}

You can call or invoke the function by using the function name and place parentheses behind them.

myFunction()

parameters are basically variables that act as placeholders for the values that are to be input to a function when it's called. You pass a value as input to the function. Many people use the term parameter and argument interchangeably but there is a slight difference.

function myFunction(param1, param2) { // These are parameters
   console.log(param1 + param2);
}

myFunction(1, 2); // These are arguments

Values that are passed into a function when it is called are arguments. The placeholders are parameters.

Arrays.

With arrays you can store multiple data types in one variable. You declare it the same way as a variable but you put [] around the values and seperate each one with a comma. Every value in an array is called a entry.

You can access data inside array using indexes. Arrays use zero-based indexing. So the first item in the array starts with a 0.

Objects.

Objects are similar to arrays, except that instead of using indexes you access the data in objects through what are called properties. Every property is made up of a key and a value.

var dog = {
  "name": "Peter",
  "legs": "4"
}

The stuff above is a basic outline of some of the core JavaScript terminology. Some of the stuff that I need to remind myself of on the daily. Stuff that people, IMHO, need to refresh more often. Hope this helps and next time you want to sound cool; try to use the right terminology. 👌

Thanks for reading! You can follow me on @dandevri and feel free to reach out to me if you have something to say!