DEV Community: Shaquil Maria

Read this before you publish your next post😉

Shaquil Maria — Wed, 19 May 2021 17:29:22 +0000

What's up Dev clan?

disclaimer: this is a "rant" and improvement proposal based on my opinion and experience using the DEV.to platform. These tips can be used on whatever platform you are posting on. All examples used are made-up, do not take this as a personal attack.

It's been over a month since I created an account on this platform and started visiting it regularly to share and read what is being shared. Over this last month I noticed two trends, the type of content that is published and how these posts are written.

To start with the first: Type of content. I realized that these are the main four types of contents I am seeing:

The listicles
The How-To's
The rants
The discussions

There is nothing wrong with your post falling under one of these categories. They make it much simpler to interact with and read about certain topics. Besides the types, there is how these posts are written. And to be fair, in my opinion much can be improved. Let's first list them.

The writing styles I see the most are:

The lazy writing
The unstructured
The critic
The "I'm not a native English speaker"

Why I am talking about these writing styles? Well, I have seen a lot of people saying that they think that the content quality on the platform is deteriorating, but they do not give advice on how to improve the content quality🤷‍♂️. And to some extent I agree. The content on the platform is becoming repetitive and of low quality.

So, here I am, trying to contribute to the community in a way that might increase the quality of the content. This post will go over some general tips that can improve your content in general, and how you can improve your post depending on the type of content you are writing (according to the ones listed above).

General Improvements

Canonical links

A canonical link element is an HTML element that helps webmasters prevent duplicate content issues in search engine optimization by specifying the "canonical" or "preferred" version of a web page.

You would like to use a canonical link to verify the original place of origin of your post in every other place you publish it. If your post was first published on your personal blog and then on dev.to, you are advised to use a canonical link that says that your personal blog is the original post.

I have seen a lot of people create a post with a compelling title: "How these 5 apps will make you a millionaire!". Once you click the post:

You don't see the contents of the post, you see a link pointing to the original post. You might just get frustrated and leave the post.

When you are republishing a post on a different platform, PLEASE don't be that author. You already have the post complete, just copy and paste your post content, and add the canonical link. This will allow your readers to read what they came for, "How these 5 apps will make you a millionaire!", instead of hopping from one platform to another just to read your piece of content.

Preview your content

People of dev. By now you should know that dev use markdown to edit posts and comments. When you are drafting/ writing your post, an advise is to write it in markdown. This will make your life much easier when posting on dev. You can legit just copy and paste your post's content into the dev editor and publish it. BUT WAIT, before publishing, preview your post. Come on, write it down so you don't forget: Preview my next post before I publish it.

By previewing your post, you can see and read the post with the style that it will have on dev. This will allow your to check and double check that everything is looking like how you intended. That your headings are right where they should be, that your images work and that your links redirect to the correct pages. By previewing your post and fixing the things that you think that needs fixing you will automatically increase the quality of your post.

Grammar and vocab

Now listen, like most of you all, English is not my native language. With English as your secondary or n+ language comes the hurdle of translating everything that you want to say to English. This may result in poorly written texts that does not have the right vocab or grammar. Please, do yourself a favor and let someone proofread your posts before publishing. This will allow you to get early feedback on both the content of your post and the linguistic structure of your post. Besides having someone proofread your post, use tools like Grammarly to assist you with the grammar and vocab in your post.

Sources

Oh sources. Whenever you are citing something from a source, the best practice is to write the original link in a reference list. This will give your readers a starting point to further read about a certain topic. This is especially helpful if you are talking about a broad topic, and you are not covering all the aspects of said topic.

By listing your sources you give proper credit to the ones that helped you write your piece of content, without them I'm pretty sure you either would have had a difficult time writing your content or you might have given up on it all together, so show them some love ♥.

With the general tips out of the way, let's take a look at how you can improve your posts based on its type. AGAIN, these are my recommendations, not rules that you should follow.

Listicles

Firstly, you don't need to make a listicle for everything. Nobody cares about a list of pens you use to write down your To-Do's. A more interesting topic would be the system you use to tackle your To-Do's. Nowadays I'm seeing so many listicles about the same topic, that before opening a post I can guarantee that I can predict two or three items on that list.

Now if you decide that your post must be a listicle, let's dive into it.

No need for a long list

Come on, deep down you know it. You know that your 100 item list is not really worth it. People might start reading it, and at the 25th item just bookmark your post and move along with their day. Never to come back and finish reading the list. Long lists only makes it more difficult to get value out of your list. You are giving too much options. Next time you want to write a listicle and find yourself writing a long list, take a break. Analyze your content and be critical about it. Is each item on this list really that important? If your answer is "no", then remove that item from the list.

At the end of the day you will have a better curated list that is straight to the point and more importantly short and easy to read.

Don't just add links

I've seen this. "5 Play Store games to increase your mental capacity" (total bs example). When you click the post, it's just links to the games on Play Store. No image, no description, no intro to the post, nothing. If you are doing something, do it good or don't do it at all. If you are creating a list of whatever, give the reader a reason to read it. If your list is about cars, for each car on that list elaborate a little about it, what's the good of it, what's the bad and why they should care about it. After giving them a reason to GAF about the car, you give them a link to the car.

Give your list a personality

Like I've mentioned before, I am seeing a lot of lists about the same topics. If you want to make another list about VS Code extensions, go for it. Just realize that there are a thousand out there already, and they all might have the exact same extensions listed as the ones you will be listing. Just take this advice: Make it your list. Create a list about the extensions that you use, how they are of use to you. When I read your listicle about these extensions I should understand what your opinion is on these extensions, what you like and what you don't like about them. Why you are recommending them.

While I am at it, I should say this. Create lists based on things you've used or are planning to use. Don't just find a list out there and:

Rants

Rants, we all like them. We all have things that we don't like and want to express our frustration about them. This post started as a rant about poorly written posts😅. But while we each have a right to express our opinions, we should be aware of the consequences of doing so.

CoC

Most platforms have a Code of Conduct, a list of rules that you should follow to help keep the platform healthy and inclusive. These rules help both you and the readers have a place where you can feel comfortable. Here is the CoC of dev.to, take a look at it. Please as a writer, help enforce the Code of Conduct. In your rant posts, don't attack a certain person, attack the problem. Don't write a post attacking one specific individual, attack the action that the individual did. This will allow for a broader discussion about the topic, rather than discussion about the individual or what they posted. Do you see where I am getting at? Your rant should encourage a conversation on the bigger picture, not that one issue you encountered.

Your rant, your opinion

Remember that your rant is purely based on your biases and your opinion. This means that people might agree with you, but at the same time, they might strongly disagree with you. When you choose to go on a rant, remember that you are putting yourself in a difficult position where you might become the one getting criticized. Choose wisely what you put out there, and the approach you take when critiquing something.

How-To's

How-To's, they vary from tutorials, to people convincing you that you too can become a millionaire in 7 days. Point is, these should be posts giving you a detailed walkthrough on how to achieve a certain result. And yet, I see some that don't do that.

Explain your point

If you are writing a tutorial, explain who is it for, what knowledge is required to follow it, and what they will earn from it. This will allow your audience to know exactly what they are getting themselves into. after making clear who your post audience is, tell them what they will be doing, and give an example of the finished result.

For you guys that are writing about how you achieved something and other people can do it too: tell them the whole story. Don't just be telling the start and finish, the highlights. Tell them about the "sacrifices" it took you to get there. You became a millionaire in 7 days? Tell them where you were before achieving that, tell them that you didn't sleep for 7 days, tell them about the tools that helped you get there, tell them it is extremely difficult, and you are lucky that you achieved that.

If you are writing a post explaining something, explain it in the more details possible.

Less self promotion, more how to

Don't write a post on a how to and just 90% of the time be advertising what you did. Write about how to achieved it. If you want to advertise your product, do that and use a title that reflects exactly that. Do not give it the disguise of a tutorial or a How-To.

Discussions

Discussions, the posts where you can let your soul go wild in the comment section. These types of post rely on the interaction of the reader with the post. You as a reader give the post its importance. Your comments allow for the post to be called a discussion. And you as an author, should encourage the reader to comment on the post.

Give the reader a reason

I see a lot of posts with the discussion tag and a question as a title. When I open the post to find out more, all I see is a one-liner. One question. "Are you a developer or are you a software engineer?". As a reader what am I supposed to comment under this "discussion"? I don't have any idea where this is going.

As an author, you should lead your readers to a conclusion. Your listicle should lead them to use at least (or avoid) one of the things on the list. Your rant should lead your readers to the conclusion that you don't think that something is right, and that should let them think critically about the topic. Your discussion should lead them to share their opinion. In order to lead them to share their opinion, you should first give them a base to start with.

When writing a discussion, give your readers a context. This context helps the reader understand what the discussion is about, it leads them to the specific topic you want to discuss.
"Are you a developer or are you a software engineer?" Start with why you have this question, Are you trying to clarify the definition of the two job titles? Are you trying to see where you fit? Or are you looking at what the general public thinks about being the one or the other?
Your context guides the discussion.

Oh and by the way, I said give the discussion a context, do that. But don't write a lengthy context, you will loose your reader along the way. A paragraph explaining why you created the discussion is enough.

Yes or No is a no no

Do you write with pen or pencil? What would your answer to that question be? "I use pen" or "I use pencil". Et voila, your discussion is over. When creating a discussion, formulate your question (or "food for thought") in a manner that it does not simply elicit a yes or no answer from the audience. If you want a discussion, you need to have a conversation. To have a conversation you need more than just yes or no. You need a more in-depth answer. "Why do you use pen or pencil when you write?" Give your readers a reason to write more than just one word. It will make your discussion more engagement-friendly and you will (hopefully) get answers that add value to the discussion.

A discussion is not a one-way street

Have you ever encountered a post where there are lots of comments but the author is nowhere to be seen? Well, don't be that author. Engage with your readers when they comment. Your discussion is your playground to see how people think about a certain topic. If they comment, show them that you read their comment. If you want a little more explanation, ask them to elaborate further. Show your readers that you are interested in the discussion and in them.

Well, this is all I have for you guys. I hope that after reading this post, you will create and post the best content of your life. Go on, write your posts, share them and thank me later🤣

By the way, if you're reading this, like this post.

Git-flow, non-technical intro.

Shaquil Maria — Tue, 11 May 2021 12:56:10 +0000

Photo by Yancy Min on Unsplash

Howdy DEV clan?

We've all heard of the recommendation and best practice: "Use a version control for your project." While this is true, it might save you from F*CK-ups, not many blogs proclaiming the use of version control mention how to use it or the best way to use it.

Here comes Git-flow. Git-flow is a git workflow you can use to streamline your use of version control for your whole application. In today's post, I'll go over the basics of Git-flow and how it can improve your git-flow.

What is git-flow?

Git-flow is a git workflow proposed in 2010 by this post. This workflow is supposed to help you with your software development and DevOps practices. Git-flow defines a branching strategy and releases management for your software.

Git-flow uses git as its base (it's in the name!). Git was proposed for its distributed nature and "ease of use". Git allows for a simpler branching and merging mechanism compared to some other version control systems. More on git here.

Git-flow branches

When you create a project and initiate git in it, you have by default your main branch (go on, try it don't be shy). In git-flow, this main branch HEAD (latest changes committed) should always contain the production-ready software.

You might be asking: If the main branch is for production-ready code, in which branch should I develop the application then? You guessed it! Your main development branch is called develop. The develop branch should always contain the latest changes that are ready for release (ready to be sent to production).

source

To make sure that your develop branch only has the code that is ready to be sent to production, you need to separate your development into phases that work towards release. And guess what, git-flow has a solution for that.

Git-flow consist of three types of branches:

Feature branches
Release branches
Hotfix branches

On a technical level, each branch is the same as the other. But for usage distinction, each type of branch has its specific use and is bound to strict rules for their originated branch (which branch they can be branched off) and their merging targets (which branch they are allowed to branch into).

source

Feature branches

Feature branches are used to develop well, features. Do you want to develop the login feature of your software? You do that in the feature branch. You use feature branches to develop the features you want to add to your software, for a new release or a distant one (maybe you just want to set the base to develop and publish later).

The feature branch should always branch off from the develop branch. Why? So that you have the latest version of your to work with. Likewise, the feature branch should always be merged into the develop branch, this will make the feature ready to be released.

Release branches

Release branches, well they are there to do final tinkering on a release before it goes to production. In these branches, you make minor fixes and final tinkering. Why do you use a release branch if your develop branch has the latest code?

Glad you asked (even if you didn't), this is to separate the release from the concurrent development. Let's say you finished three features at the same time (thus merged them into the develop branch), but you want to release only one. You create a release branch for that specific feature, do the final tinkering, and merge that to the main branch. Easy peasy lemon squeezy, you separated the release of the feature while keeping your develop branch available to changes from new features.

Since you are working with code that is ready for release, you can only make a release branch by branching from develop. When you are done with the branch, you must merge it into the main branch and release the code and into the develop branch (so that your develop branch has the latest changes).

Hotfix branches

Finally, we have hotfix branches. They have the same functionality as release branches, prepare your code for production, but they are used specifically for unplanned changes/ improvements.

Imagine you tested your software against the major ways your software can break, and it passes them all and you released the new feature. Just a day or two after the release, your users start complaining that they get X instead of Y when they click on a button.

To fix that bug, you don't need to create a feature branch, then merge it into develop and create a release branch. No! you create a hotfix branch from your main branch and fix that bug, hence hotfix. After fixing the bug in your code, you must merge the changes into the develop branch and the main branch for production.

So, there you have it. Git-flow is a very strict workflow for version controlling your project, and to some, it might look over-engineered and daunting. I recommend to not follow it to the letter, pick bits and pieces, and Frankenstein your way to a development structure that you and your team can easily work with and integrate into your projects.

I hope that you learned something from this post. Go on and structure your side projects!🤟

Twitter, Instagram, or ...?

Shaquil Maria — Fri, 07 May 2021 19:08:19 +0000

Photo by Prateek Katyal on Unsplash

As I was reading @technoglot 's recap of one of the sessions of the last Hashnode bootcamp I started wondering, What is the best social platform for software engineers to engage with each other?

Which is the platform where developers, designers, and everyone in tech have the floor to share their projects and views on specific topics? (Besides dev.to of course)

I personally use Instagram on a daily basis, and to be honest, I don't think it is ideal for sharing projects or having a discussion. It's more suitable to share short informative posts. Twitter is where I see most developers tweeting their hearts away, but I find its UI too cluttered and that makes it difficult to follow a thread.

What are your views on the different social media out there for developers? Which ones do you personally use and enjoy?

And drop your handles, let's connect!✌

CI/CD, a non-technical intro.

Shaquil Maria — Tue, 27 Apr 2021 12:52:10 +0000

Photo by Clayton Robbins on Unsplash

Imagine this. You have a great app idea, you started the development and now you are ready to launch the beta version. You launch it to your waiting list and the first thing you see is that you have a bug when people are trying to log in.

You go into your code and you realized that it was a silly mistake you did. One piece of code you added recently crashes another. In order to avoid that in the future, here comes Continuous Integration & Continuous Delivery/ Deployment.

What is CI?

Continuous Integration (CI), is the first step of the DevOps coding philosophy and set of practices that streamline your application delivery. Implementing and executing CI means that you merge your code changes into your project's main branch and the changes will be validated against different tests. It can also be a specific branch for the different environments: testing, acceptance, and production.

Your application should be up to date, and more importantly with minimal bugs. How do you make sure that you have fewer bugs in your code? You guessed it, by testing your code. The same thing needs to happen when you make a code change. You need to test your code change to assert that everything is still working accordingly after the change.

Implementing Continuous Integration means that at the end of each code change, you test the change against your whole application, make sure that nothing is broken. If something is broken, then you know beforehand and you can fix the bugs. This will reduce the chance of your application getting built and distributed with bugs. CI automates this whole process into a pipeline that automatically executes if the conditions are met ( e.g. you commit to the right branches).

Continuous Integration consists of four simple but important phases:

Push your changes regularly.
Test the application with the new changes.
Fix any emerging merge issues or bugs that were introduced to the code.
Once the code passes the tests, merge it with the main branch

With your CI pipeline in place, you can go ahead and make code changes to your heart's content. Once you have CI implemented for your project, you will be able to see that you can identify bugs and fix these bugs easier than before, and this will improve the quality of your application and since the testing is automated it will make your development process more efficient.

But you are not done yet. At the end of the CI pipeline, your code runs without any or minimal bugs, but you still have to deliver your application to the users. What good is updating the code without them getting the update in the app?

That is where the second part of CI/CD comes in. To handle the delivery of your application to your users you have two options: namely Continuous Delivery & Continuous Deployment.

Continuous Delivery

Most times when people are talking about CI/CD, they talk about Continuous Deployment. While CD stands for Continuous Deployment, it also has another meaning, namely Continuous Delivery. Continuous Delivery is the direct step after CI.

Continuous Delivery takes the tested code changes merged within the main branch and automatically builds the application and makes it ready for deployment. This automates the whole release process for your application. By automating the delivery of the updated application, you can choose how frequently the code update is pushed as a new release of the application to your different users (or environments). At the end of your Continuous Delivery pipeline, you have a compiled & build version of your application, and you can manually publish.

Continuous Deployment

Are you the type that wants to automate everything? then Continuous Deployment is for you.

Continuous Deployment goes one step further than Continuous Delivery. While with Continuous Delivery you decide when you deploy the new version of the application at the end of the pipeline, Continuous Deployment takes care of the deployment of the new version of the application to the users automatically.

This part of the CI/CD pipeline takes care of building and deploying the final updated version of the application to your different environments without any human intervention. This increases your productivity since there will be no need for you to plan a release date and everything is automated. The only time that the application is not deployed to the different environments is when a test fails in the CI.

Continuous Integration & Continuous Delivery/ Deployment sounds all good & dandy and in a real-world scenario, it will save you a lot of time in the long run. But one thing to notice is that it relies heavily on writing and using tests. In case you do not have the slightest idea of what tests are, check the previous post I created explaining Test Driven Development in a non-technical manner.

TDD, a non-technical intro

Shaquil Maria ・ Apr 18 '21

#devops #beginners #testing #todayilearned

I hope that you learned something new from this post and that you get an idea of how CI/ CD can improve your development process.🤙🏿

How to plan for a successful side-project. The Kortiku chronicles.

Shaquil Maria — Wed, 21 Apr 2021 15:28:58 +0000

Photo by KOBU Agency on Unsplash

In case you missed it, check out the first post about Kortiku.

Kortiku eps1: Intro

Shaquil Maria ・ Apr 6 ・ 3 min read

#showdev #beginners #php #laravel

After a couple of weeks of slacking off, I decided that it's time to continue with Kortiku. The logical step is to start coding right? Well.. no⛔. First I decided to try to create a plan for this project. Some of my other projects started with coding and were never finished. This one will be different! (Hopefully😅) After reading some articles on how to start a side project, I got an idea of how to start planning the project for success.
(I highly recommend these posts by @peterlunch & @ms_yogii ):

How to Plan and Build a Programming Project – A Legitimate Guide for Beginners

Peter ・ Apr 12 ・ 7 min read

#beginners #codenewbie #programming #webdev

5 Tips to work on your side project while working full-time.

Yogini Bende ・ Apr 6 ・ 4 min read

#webdev #productivity #career #startup

First I created a more complete description of the project, what would be its features, and what they would solve. Then I estimated how much time it will take to create an MVP (Minimum Viable Product). After that, I jotted down the first set of tasks that are needed to get started. For that, I used epics and user stories. More on that here.

Below you can see the description of the project and an example of how I set up the tasks.

Short Description

Simple and minimalistic URL shortener web application that lets you short multiple URLs. Besides that it allows you to create a link-in-profile where you can share multiple URLs in one link.

Problem Description

In this day and age, people are sharing a lot of URLs with each other. This comes with the added issue of sharing long URLs that are too long and complex or that you would have to share multiple separate URLs increasing the URL confusion that already exists.

Solution

A URL shortener allows you to create alias URLs that are shortened and more readable. By creating a collection of URLs and giving them a description, it becomes easier to share URLs. That is what Kortiku offers. While you can share the alias URLs, Kortiku also allows for the creation of QR codes for easy sharing.

Project Phasing/Timeline

Estimated Development Time

3 months

It will take 4 weeks to create an MVP, 2 months to have a production-ready application.

Start: 21 April 2021
MVP: 14 May 2021
Initial deployment: 30 June 2021

MVP

The Minimum Viable Product of Kortiku will consist of the following:

Ability to create unlimited shortened URLs
Ability to generate a QR code for shortened URLs
Ability to sign up & login/ sign out
Ability to create Link-in-Profiles
Ability to generate QR codes for LIPs

Nice to haves

Some nice to haves for the deployment of Kortiku are:

Customizable LIP backgrounds
Customizable user profiles
Analytics dashboard
Action buttons in LIP

Stack

PHP/ Lavarel → backend
MySQL → storage
Tailwind CSS → styling
Laravel (Blade)/ TBD → frontend

Below is an example of how the tasks for this project will look like.

US name: Homepage
Created: Apr 20, 2021
Deadline: Apr 30, 2021
EPIC: USER_INTERFACE
Status: Backlog

User Story:

As a developer,
I want to see the homepage of Kortiku.
So that I can understand what the product is
And how I can benefit from it

Using user stories, you can create tasks that are descriptive enough to get you going. Now, I am no planning and productivity master, this whole planning and sticking to plans part is a challenge on its own for me. To assist me in this endeavor, I will be using the kanban method and Notion as my tool to manage tasks and monitor the progress of the project.

I created a gist with a template for the project description and task US. Feel free to use them for your own projects.

It's game on now!👨‍💻 Let's start getting these tasks from TODO to DONE!

What if?

Shaquil Maria — Tue, 20 Apr 2021 14:18:40 +0000

Photo by Emily Morter on Unsplash

Most of the time, people ask: What would your dream job look like? Or, what is the ideal company you would like to work at?

One thing I rarely hear people asking is this:

Imagine an ideal world that you didn't have to worry about money, thus didn't have to work.

What would be the dream project you'd be working on?

As a developer, maybe there is this one side project that you always wanted to work on, but never got that far. What is that project, and why is it important to you?

TDD, a non-technical intro

Shaquil Maria — Sun, 18 Apr 2021 15:32:30 +0000

Photo by Christopher Gower on Unsplash

As I am finishing my degree in ICT, I had to do an internship at an ICT company. I was interested in software development, so I decided to apply to a local software solutions company: Ictual N.V. After some talks to get to know the company and their products it was time to decide on an internship assignment. I choose the path of least resistance and decided to work on a web application, a portal for one of their products. Web dev is what I was doing at that time for a year so I was pretty comfortable with the choice of assignment. Then we started discussing their requirements for the assignment and they hit me with this: "This portal should be developed in accordance with the team's workflow, it should be developed according to Test-Driven Development."

My jaw dropped... WTF is that, I've heard about tests before but Test-Driven Development? Never. So That was a challenge for that internship. I learned something new, and I hope that this high-level explanation will shine a light on TDD for you, if like me you've never heard of the term.

Test Driven Development, what is it exactly?

Well, TDD is a software development approach where you write test cases that explains your code before the actual code. For example, if you want to create a calculator, you will have to write tests for each functionality of the calculator (summation, subtraction, multiplication, division, etc.). After writing those tests then you will be writing the minimal code to pass those tests. In the case of summation, you will write the code, to sum up two numbers.

Test-Driven Development can be done in five basic steps:

Write a test.
Run the test and see it fails.
Write the simplest code to satisfy the expectation of the test.
Run the test again and see if the written code passes the test. If it passes refactor the code and if not change the code.
Repeat

When talking about TDD, we can talk about two different levels of tests:

Acceptance TDD (ATDD) - you write a single acceptance test that fulfills the behavioral specification of your project. Behavioral specifications describe how the different classes and modules in your application with each other. This is also known as Behavior Driven Development. The aim of ATDD is to specify the requirements of your project. Most times this is achieved by working with User Stories and Use Cases.
Developer TDD (DTDD) - you write a single test that focuses on every small functionality of your project. DTDD is simply called TDD.

Now that we have an idea of what TDD is, the next logical question is: WTF are tests anyways?

Tests

For every time that the word "test" was mentioned, let's take a shot of... water 🥤, we should be sober for the next part.

Tests are assertions that you write about the functionality of your software, "It should sum up two numbers". In a test, you describe the functionality and what you expect from it when it is executed. For example:
description: "The calculator should sum up two numbers", expectation: "2 + 2 = 4". That just now was a Unit Test. Unit tests allow you to set descriptions and expectations of one specific logic in your code.

The general rule of thumb is that for every Unit Test, you write a function. This simplifies your code and makes it easier to debug and reuse in the future.

In software development, there are a ton of different forms of software testing, but the most important tests you will be writing as a developer are Unit Tests and Acceptance tests. For you, front-end developers, end-to-end (e2e) testing will be pretty important. In e2e you will be testing the UX of your application. How all the components flow and work with each other.

Important best practices when creating tests

Use descriptive names for test functions, by the name of the function you should know what you are testing.
Separate testing code from implementation code but keep testing classes in the same directory as the implementation code.
Limit the number of assertions in a test, write more test functions if necessary. If you need to test multiple assertions (expectations that the code really executes what it is intended to execute) it is recommended to create a test for each one of them. This makes debugging easier and the testing code cleaner to read.
Write the simplest code that would pass the test. Separate your logic into different and write the simples code to pass each test at a time. At the end of the test suite, your code will be executing the complex logic because each individual section works as it should.

Now, let's write a test for our summation example. I will write this in the format of the tool Jasmine. Jasmine is one of many testing tools developed for the language JavaScript. Jasmine comes preinstalled in your Angular project, which is what I used for my internship. While depending on your programming language and tool the syntax may vary, the general gist of how to write a test is the same.

// import dependencies for testing
import { ComponentFixture, TestBed } from "@angular/core/testing";
import { ComponentName } from "./component-name.component";
describe("CalculatorComponent", () => {
  // create component instance
  let component: ComponentName;
  let fixture: ComponentFixture<ComponentName>;
  beforeEach(async () => {
    // import and declare dependencies for the component
    await TestBed.configureTestingModule({
      declarations: [ComponentName],
    }).compileComponents();
  });
  beforeEach(() => {
    // initialize component instance
    fixture = TestBed.createComponent(ComponentName);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });
  // test that should be run on the component code
  it("should calculate a sum", () => {
      const expectation = 4;

    expect(component.sumNumber(2,2)).toEqual(expectation);
  });
});

Again, the code above is specifically for Angular. Your mileage may vary but that right there is a working example of a test to assert that the function called sumNumber returns the sum of 2 + 2.

You will first import the tools you need to test your code and the piece of code you want to test. Then you start writing your test suite. Your test suite is all the tests you will execute for a specific part of your application (software 🤷🏿‍♀️). Your test suite lives in a describe function. The first parameter will describe the part of your application that you are testing, the second part will describe the function that will contain your tests.

Then you write the beforeEach. In your beforeEach function, you write what should happen, well, before each test case. Here you create a new instance of your piece of code and pull in every dependency for your tests.

After that comes the fun part, the tests. The tests have an almost human language type of syntax. All your tests will be in the form of an it function. The first parameter will be the description of your test, what exactly are you testing? What should it (your code) do? The second parameter contains the function that will execute your code and run it against your expectation. In that function, you need to set all that is necessary for the logic to function properly. In our summation case, call the function with the two numbers we want to sum.

Remember, the first time you are running your tests, they should fail. The test should be written before the code.

With your tests in place, go on and start developing the best application you can. Using Test-Driven Development will encourage you to think critically about your code and allow you to write cleaner code. The benefits of cleaner code are endless. Your code will be easier to understand, easier to reuse, easier to add new developers to the project, and easier to debug among other things.

I hope that you learned something new from this post and that you will consider using this development approach for your next million-dollar application idea.🤙🏿

For the ones that use tests regularly or even TDD. What does a test look like in your programming language of choice?

What courses do you recommend for blockchain development?

Shaquil Maria — Wed, 14 Apr 2021 13:58:20 +0000

Photo by Hitesh Choudhary on Unsplash

Lately, the new trend is blockchain technologies. Everybody is developing some sort of smart contracts and decentralized applications nowadays. As technology advances and the hype increases, more and more companies start to consider blockchain for their projects. This means an increase in the demand for dApps developers and resources to learn about the technology.

What courses did you follow, if any? Where do you keep up to date with the developments of the blockchain space?

Let's create a list of interesting courses and resources for blockchain development.

Old enough to code, too young for the next step?

Shaquil Maria — Tue, 13 Apr 2021 14:50:58 +0000

Photo by Luke Porter on Unsplash

disclaimer: this is based on my opinion

Over the last couple of years, I've been seeing a lot of young YouTubers (-20 y/o) creating videos about how they made thousands of dollars online. Now that I joined dev.to I'm seeing that there are a lot of young (13, 14, 15 y/o's) web developers that are emerging and asking about freelancing and making money.

I have no issue with kids learning to code, I actually encourage it. But my main concern is that they are way too young to be worrying about the financial aspect of the field. Most of them only know the basics of web development but are trying to make a fortune by freelancing. When I was 12 y/o my concerns were about winning games and my grades, nowadays their concerns are about making money as fast as possible.

Now, I am no expert in psychology, but I'm seeing on every social media platform that there are a bunch of young people that have some sort of mental illness, either depression or whatever. And I'm starting to think that there is a connection between their priorities to act like grown-ups before their age and their mental wellness. Kids should enjoy the simple things in life and learn, not worrying about making a fortune and be financially independent at the age of 15.

My questions to us adults (+18):

What do you think about this new trend of kids trying to make money from an early age, and worrying about all sorts of problems they cannot solve as youngsters?
What advice do you have for the upcoming generation?

My questions to the young devs (-18):

What is your motivation to dive into the tech world and what is your ultimate goal?

I really want to hear your thoughts on this topic, it's something that has been bothering me for a while now. Let's have a healthy discussion about it.

Kortiku eps1: Intro

Shaquil Maria — Tue, 06 Apr 2021 13:35:22 +0000

Howdy, welcome to the first episode of Kortiku. My name is Shaquil Maria and I am a junior developer working my way through my bachelor degree in Information & Communication Technology. I was interested in technology since I was a little kid playing with hot wheels and remote controlled cars. I always used to disassemble them to see what was inside, and as I grew older and started messing with phones and computers I became more interested in how they function and the software that run on them.

During the different classes of my bachelor I learned different programming languages and different concepts, but I never actually made a complete application that I can say is production ready with that knowledge. At some point during my study, I started working as a part-time web developer at a local company and there I sharpened my skills of frontend development, design and JavaScript. That is when I decided that it was time to turn my know how into practical use. I started working on different small time projects like clones and todo apps, but then again they were not full projects that you can publish for everyday use.

So what is kortiku then? 🤔

Kortiku means short in my native language Papiamentu. I guess you can already imagine where this is going. Kortiku is a URL shortener that I developed in JavaScript with MongoDB as database and EJS as frontend templating engine. You can check it out here. While I was satisfied to have created something that is on a level that I think is respectable, it was still just a simple JavaScript project, nothing complex.

I decided to add more features to the project, like a link-in-profile (like Linktree). I thought: "the more complex the app, the more I can learn". Like the development process of a production-ready (an app that goes live) application and development methodologies. So I decided to refactor the codebase of the project and switch from JavaScript to PHP, more specifically the Laravel framework.

Why PHP?

Well, like I mentioned before, during my bachelor I learned a couple of languages. Java was the primary programming language of the study, but I also learned some PHP, JavaScript, Python, and Dart in order to create applications and projects for certain classes. Since I haven't used PHP in a while, this is the perfect opportunity to sharpen my skills in the language.

So.. What is this blog about?

This post is the first of many (hopefully). This first post is the introduction to the Kortiku series, where I will be building the application in public, so that I can hold myself accountable, and share things I learn along the way. This series will go about the actual development of the application and about methodologies and architecture patterns that I implement and learn about, like Test Driven Development and Scrum.

Thank you for reading this intro post, and hopefully you join me on this journey. If you have a project that you wanted to work on, mention it in the comment section below and let's support each other so we can all learn and finish our side projects.

If you have any experience with PHP and Laravel, what is something that you like about it and what should I pay extra attention to?

See you next time.👊🏿

Photo by Mike Tinnion on Unsplash