DEV Community: Nicholas Mendez

Low code solutions for devs to consider.

Nicholas Mendez — Tue, 15 Nov 2022 17:07:11 +0000

How low can you go

Traditionally as dev's we may take pride in our ability of implementing systems 'from scratch'. We may scoff at tools that seem to provide 'shortcuts' for the work we do, but perhaps this attitude is counter productive.

Low code/no code is a term that refers to a class tech products and services which aim to simplify the implementation of technological solutions. This can be done at various levels and this post will give a breakdown of the eco-system at a glance.

Spreadsheets
Builders
Static Site Generators
Content Management Systems
Backends
Automations

Spreadsheets

You've probably heard it before but the joke "economies and industries run on excel" definitely holds water.

Products like Excel, Google Sheets, Airtable and Noco DB are very effective for organizing data and can be integrated to work as a data source for web & mobile applications.

Builders

These products provide drag and drop interfaces for quickly putting together an application or website. For websites there's; Squarespace, Wix and really recently Canva to name a few.

For building applications there's; oracle apex for that work with larger scaled oracle databases, LiveCode, Microsoft Power Apps and Flutter Flow for cross platform applications built in flutter.

Static Site Generators

These are nifty tools that let you create a fully static build of a website (no server-side code required). Tools like gatsby, eleventy and jekyll allow you to author a website's content with plain text files. Then, you can generate a full web experience from the files.

Management Systems

Content/learning management systems, such as Wordpress, Drupal, Joomla, Magento and Moodle are fullstack web applications that you can configure and customize for course websites, blogs and e-commerce. Many if not all of these options are popular and open source.

Backends

Back end as a Service (BaaS) are products that let you manage various aspects of you applications such as hosting, auth, database, uploads, cloud functions in a very "serverless" way. The most popular one is probably firebase, netlify is vastly growing. Appwrite and Superbase are really cool opensource alternatives.

Automations

Automations are really fun tools that let us create flows with popular products and services without needing to setup api keys and coding. For example you can let a form submission from airtable trigger an automated email campaign in mailchimp. Tools like zapier and IFTTT are very popular and more recently we have buildable.

I will also include Robotic Process Automation (RPA) tools like UI path, Automation 360 and Microsoft's power automate.

Why should devs care about no code?

The proliferation of lowcode shows a clear trend in the industry. There is a growing market of people that don't mind trading off in-depth customization for ease of use.

Meanwhile, as developers we may take pride of our 'from scratch' implementations but are we really doing that?

Yes, you wrote that code but you're using a framework, written in a language implemented on a runtime running on protocol by someone else's design. One can argue that your react.js is just a lowcode wrapper for vanilla JS.

Technology is all about building on top of work done by those before us and low/code is just an extension of that.

My parody of xkcd's purity

Conclusion

Many of these services can be integrated with to save us considerable amount of time. This let's us focus on delivering our core competency rather than stretching ourselves thin over various concerns of a software solution.

Note, this is by no means an exhaustive list. As technologists we need to be aware of all options that are available if we are to build the best solution for our users.

Connection Types In Web Apps

Nicholas Mendez — Mon, 14 Feb 2022 17:26:27 +0000

Making Connections

Web apps have come a long way form being static documents that are loaded into the browser. Here's an overview of the different methods modern web apps can use to send and receive data.

XHR/Fetch

The XMLHttpRequest (XHR) API became standard in 2004 and revolutionized how web apps were build. Before then, presenting new data on a page required an immersion breaking refresh or a redirect.

XHR allowed apps to request data programmatically in the background and then we can manipulate the DOM to present it. This technique of data fetching and updating the page is referred to as Asynchronous JavaScript and XML (AJAX). The fetch API is a newer, promise-based alternative to XHR.

Web Sockets

Image Credit

The Web Socket API is a very popular API for building real time web apps that provide features like tracking and messaging.

It allows web apps to create a keep open connection to the server and transfer bidirectional messages across the connection. Socket IO is a popular library used for building with web sockets.

Server Sent Events

Image Credit

Sever Sent Events is an API that allows application servers to send data to the client over an HTTP connection.

This API is different from web sockets in that it is unidirectional. It is simply a means for a server to push updates to a client.

Web RTC

Image Credit

Web Real-time Connection (RTC) is a standardized API for peer to peer communication. It is available on all major browsers and supports video and voice. Many video calling applications use Web RTC Under the hood.

Push Notifications

Image Credit

The Push API is a standard web API that facilitates push notifications on the web. It is natively supported on all major browsers except those on the MAC or IOS platform (push notifications can sill be done however using Apple Push).

Push notifications are a neat way to give reminders, updates and alerts to the user to increase engagement once the user has opt-in.

Push notifications are special from the others in that it is the only way for a server to push data to an app that isn't currently open by the user.

You can also have silent data notifications that update your apps in the background.

Web Transport

Web transport is a new specification which serves to be provide a lower latency connection by removing the sequencing delivery that web sockets do. It works on top of HTTP3 to provide and can be used as a client to server alternative to web RTC. It's still very early for web transport (scheduled for release in chrome 97) but it is an exciting development none the less.

Comparison

So which method should you use? Here's a table which summarizes the differences:

Connection Type	Transfer Mode	Common Usage
XHR/Fetch	Client to Server	Most dynamic web apps, pull to refresh, gmail, instagram etc
Web Sockets	Bi Directional	Text messaging applications, broadcasting, real-time applications
Server Sent Events	Server to Client	Streaming data, tracking, timers
Web RTC	Client to Client	Screen sharing, video calling apps
Push Notifications	Server to Client	Notifications, alerts, background updates
Web Transport	Bi Directional	Low latency, unordered messaging, media streaming, online games

Conclusion

Over the next couple of weeks I shall take a deep dive in each methodology. Which one have you used? Are you looking forward to a specific method?

References

Dev in Dev: Issue 1 Nov 2021

Nicholas Mendez — Fri, 19 Nov 2021 04:28:26 +0000

About D.I.D.

The Developments in (Web) Development series is about pulling together interesting updates and developments that come across my radar in web development. This can include product releases, updates conference talks and events.

Transitional Apps?

AJAX and Single Page Apps ushered in a new age of web experiences, however it is not without it's flaws. Transitional Apps is a new paradigm of web apps that proposes a new direction. Rich Harris of Svelte introduces this concept at Jam Stack Conf 2021.

Transitions on the Web

Transitional apps isn't the only effort to improve navigational experiences in web apps. The shared element transition API is a proposal to bring native transitions to the web platform. Some of the goals of this overlap with an earlier proposal called the Portals API. You can try out shared element transitions and give feedback at their github repo.

You can demo this here

Powerful Performance Tooling

One really interesting announcement of Chrome Dev Summit 2021 is the lighthouse user flows. This allows you to audit and profile the performance of an application throughout various user interactions.

Cutting Edge Computing

NextJS recently announced version 12 and with it came a several features and services. One of which is Vercel's edge functions which is basically cloud functions that run on the edge (CDNs). This concept isn't entirely new as Cloud Flare Workers and Deno Deploy have a similar goals. This signifies yet another shift in how we think about building and deploying web apps.

Next level serverless

Serverless Cloud is a recently launched platform that lets build, test and deploy to cloud seamlessly right into your cloud editor!

Conclusion

That brings us to the end of the first issue of D.I.D. What is your favourite update? Do you have one you'd like to share? Please let me know in the comments!

Need More?

I'll be giving a talk at DevFest Caribbean 2021 today at 4:30 pm (-400 GMT) that goes deeper into this stuff. You are welcomed to check it out as well as the other amazing talks at the event.

Backend, for The Absolute Beginner

Nicholas Mendez — Sun, 17 Oct 2021 03:04:22 +0000

Nowadays, it seems that Frontend gets all of the hype in web dev. You build a page with HTML, CSS & JS then let it talk to an API (JAM Stack). However, how do you build an API in the first place? What is server side programming? This is your quick start guide.

History of web

To understand backend, I think it's a good understand how web started first. Luckily, I have just the article for you.

A "Brief" History of the Web

Nicholas Mendez ・ Sep 19 '21

#webdev #beginners #javascript #php

In any case here is the TLDR;

A guy creates a network protocol (it lets computers talk to each other)
Another person creates a language for formatting documents (HTML)
Web browser software is invented that lets you request and loads documents from one networked computer to another
JavaScript is created and it allows for simple programs to be executed after being loaded alongside the requested documents

At this point people thought if you are connecting to a computer anyway why not allow a programs to be ran on that said computer instead of just returning documents.

These programs were called server side scripts and they did things like dynamically build ( or pre-process) the documents before sending them to the client.

Server Side Programming

Now there are two programming environments in the web. The server side scripts that are executed before the response given to the client and then the client side scripts (JavaScript) that executes after.

The following diagram shows how the same experience can be offered with a webpage vs a server side script. Some html is sent to the browser and "hi" is logged to the console.

The server side script in this case simply returns what otherwise would have been the contents of an html document.

Unlike the client side JavaScript code, the server side scripts are never downloaded to the browser. This enabled server-side scripts to perform more security critical tasks like connecting to databases and thus be used to build dynamic web applications.

TLDR What really is backend then?

Backend programming is simply writing code to be executed when a request is sent to a server side script. The output of said code must be some text that will finally be sent back to the browser.

The following is an example of a server side script written in Nodejs using the express framework.

const express = require('express');

const app = express(); //initialize express

//code to run when the url "/" is requested by the browser
//req object lets us get details of the request like the url path
//res object lets us set details for the response
app.get('/', function (req, res) {
    res.send(`<h1>Hello</h1><script>console.log('hi')</script>`);
});

app.listen(8080, function() {
    console.log('Server up!');
});

Routing

URLs play a critical role in the web. It determines which page on the webserver that we want to retrieve. In the case of back end programming, the concept of routing relates to what code we execute in response to the URL path of the request. For example we can setup another route that does something different when /index is requested.

const express = require('express');

const app = express();

app.get('/', function (req, res) {
    res.send(`
    <h1>Hello</h1>
    <a href="/index">Go to /index</a> 
    <script>console.log('hi')</script>
  `);
});

app.get('/index', function (req, res) {
    res.send(`
    <h1>This is a second route</h1>
    <a href="/">Go to /</a>
    <script>console.log('hi')</script>
    `);
});

app.listen(8080, function() {
    console.log('Server up!');
});

You can see this code in action here

Did we just build a Web Server?

This is a common misconception. This script can also be called a node web application but some may call it a node web server. However, the proper term for this program is application server. Application server's do respond to http requests but they are not web server software.

Web Server Software are usually standalone applications that host static files and can be configured to do many things. Two popular web server software are Apache and Nginx. When we deploy a node web application we let browsers connect to a webserver which then forwards along requests meant for the application server (Reverse Proxy). This setup is shown in this article's first diagram. This isn't to say a webserver cannot be implemented in node but most use cases we use it to build an application server.

Conclusion

And that's basically what backend is about, setting up routes to be executed based on the path of the URL. I hope this article has proved to be informational for some.

A "Brief" History of the Web Part 4

Nicholas Mendez — Sun, 10 Oct 2021 02:50:28 +0000

In this final post of the series, we shall cover some of the popular developments in web since 2017 to today. Whether it's Web Assembly, PWA, SSR or the JAM Stack let's take a look at web dev today and possibly, the future.

Integrations

Image Credit

Web services, 3rd Party APIs and Software Development Kits are resources that let you integrate 3rd party solutions and services into your product. APIs allow you build on top of existing products like PayPal, Google Services, Facebook etc instead of building everything from scratch.

The Single Page App

The rise of AJAX gave birth to a new kind web application architecture. The single page application is a web app that rewrites the content of the page instead of redirecting an entirely new one.

The core mechanic that allows this is routing, whereby JavaScript code is used to alter the URL and change the view to simulate navigating to another page. The following article gives a nice overview on this.

Routing in SPAs

Marco Monsanto ・ Jun 24 '20

#webdev #javascript #routing #spa

Many of the popular web frameworks provide some means to perform routing.

Server Side Rendering

However, in the craze of SPAs, many apps became too JavaScript heavy which resulted in long load times on lower-end devices and slower networks. Hence, many teams returned to the server side to once again take on view logic.

Server Side Rendering allowed you to use the JavaScript Frameworks you love but on the server side. Projects like Next JS render the first page of your react app on the server resulting lower load times.

Image Credit

After the first page load, JavaScript code would then be ready to handle subsequent routes. This handover is often called hydration. I go into more details about SSR in the following post.

Understanding Rendering in Web Apps: SSR

Nicholas Mendez ・ Jan 14 '21

#ssr #html #javascript #webdev

JAM Stack

As 3rd Party APIs and web services evolved, it suddenly became evident that 'static sites' can provide full app experiences which we thought were only possible with a full stack approach.

Today, you don't need to manage your own database or write any backend code! Instead you can integrate with an API or a backend as a service (BaaS) like firebase, appwrite or hasura.

Image Credit

You can build a static site as a SPA using something like React or using a Static Site Generator like Eleventy that will generate your website from markdown files. Projects like Gatsby and NextJS lets you statically generate your site and still use react.

Headless Content Management Systems like Strapi and Netlify CMS let you manage content for your applications and make them accessible to your static sites via an API. The following talk gives a really good idea of how the JAM stack providing a new way to address old challenges.

Progressive Web Apps

In 2015, the term Progressive Web Applications (PWAs) was coined to describe next generation web applications that use cutting edge browser API's like the Service Worker to provide native like app experiences.

In 2019, widespread adoption of the service worker was achieved and since then the capabilities of web applications now seem limitless. Now web apps can offer native like feature such as:

Offline Mode
Push Notifications
Background Synchronization
OS Hemiscreen Integration
File System Access
Web Sharing

And much more. PWAs bring the capabilities of mobile to the reach of the web and its adoption and growth does not seem to be slowing down anytime soon. You can check out the PWA Summit 2021 to get an idea of some of the recent developments of PWAs.

Web Assembly

Web Assembly is an open standard for a portable low-level code for executable programmes in the browser. It can also be compiled from other languages such as C/C++, C# and Rust. This made porting all kinds of applications to the web possible at near native speed. You can also use web assembly modules in JavaScript!

One game changing application of web assembly is Stackblitz's web containers.

Image Credit

The StackBlitz IDE now loads an entire node.js environment right into your web browser so you can execute server side code.. in the browser!? This innovation allows you to run and debug node.js servers right in the browser going full circle with JavaScript.

Web 3

Web 3 is a proposed next evolution of the internet. It proposes moving to AI driven services, decentralized data via the blockchain and edge computing infrastructure. It will facilitate decentralized applications that may offer more privacy than current platforms ran by large corporations.

While there is good reason for scepticism, there is a lot of buzz going around web 3 as many believe that it might be the next big thing. web3.js is a JavaScript library that allows you to build apps on top of the Ethereum blockchain.

You can learn more about Web 3 below.

Conclusion

Writing this proved to be considerably more challenging than I thought. Even in this 4 part series I've left out so many other important developments like REST, SOAP, languages like ruby & pearl etc. Nevertheless, I hope you enjoyed this trip through memory lane and maybe you got a peek on what's to come.

A "Brief" History of the Web Part 3

Nicholas Mendez — Sun, 03 Oct 2021 01:53:38 +0000

It was 2006, AJAX was being widely adopted to build dynamic web experiences. As web apps became more complex, there was a need to make building them simpler. Thus the dawn of the framework wars began.

The First Generation

I can't talk about the first frameworks/libraries without mentioning jquery of course. In this wave, libraries mainly focused providing some UI widgets, DOM manipulation, and AJAX. Dojo Toolkit appears to be the first framework ever released in 2004. jQuery was released in 2006, along with mootools and yui. However, that fact that you probably only recognized jQuery is testament to its domination.

The Second Generation

In 2009 JavaScript was updated to EcmaScript Version 5, with growing platform capabilities and user expectations a second wave of frameworks began. Frameworks likes Angular in 2009, Backbone JS in 2010, Ember and Meteor in 2011 were on the rise. Two-way data-binding and templating were the features you would typically see in these frameworks. React was released in 2013 and two promising frameworks called Vue and Polymer were released in 2014.

Image Credit

On the server side, an interesting development happened in 2009. Nodejs was released as the first server side runtime for JavaScript. Now you can write your sever-side scripts and your client side code in JavaScript!

The Third Generation

EcmaScript version 6 was released in 2015, this brought many quality of life improvements like arrow functions, template literals, let & const, promises and the fetch API.

In this generation much attention was paid to state management, building UI components an optimizing their rendering with concepts like virtual DOM in the case of react. In 2015 Ember had a major update and in 2016 Angular JS was 'rebooted' to Angular much to the dismay of many dev teams.

One may argue that the framework fatigue really began to be felt here. Many developers were overwhelmed at the amount of diversity and the of fear having to learn a new framework ever so often was real.

In 2016, interest in React surpassed Angular and Vue's popularity saw steady growth. Popularity in Aurelia was also on the rise. By 2017 Angular took a clear 3rd place behind Vue and React at the top.

Conclusion

While there were still new frameworks appearing, many took solace in how things seem to have settled down at the top. In the next post we shall catch up to the web today.

Have you been in dev during these years? Perhaps you have been burned by the Angular Upgrade? Did you use Redux with React? Please share!

References

A "Brief" History of the Web Part 2

Nicholas Mendez — Sun, 26 Sep 2021 03:58:16 +0000

In the last post in the series, we left off around a bit after 1993. Dynamic data-based applications were possible via the use of server side scripts.

CSS Standardization

In 1994 Cascading Style Sheets (CSS), a language for affecting the presentation of HTML documents, was proposed by Håkon Wium Lie.

The World Wide Web Consortium W3C was founded in 1994 as the standards organization of the Web and is still led by Tim Berners-Lee up to the time of writing.

Additionally, in 1994, HTML version 4 was published with CSS support and CSS became recommended by the W3C.

The Rise JavaScript

At this time webpages could be described as 'dynamic' but only until they were loaded in the browser. Until the next page load, the experience was static. There was great desire to add interactivity to webpages after being loaded.

Hence, In 1995 the first version of a web browser was released with support of a new programming language created by Brendan Eich. That language later came to be known as JavaScript.

JavaScript running in the Netscape Browser

Now, we can manipulate the page, alert and prompt the user without performing a page navigation!

In 1997 JavaScript was standardized as ECMAScript Version 1, ushering JavaScript to be supported across all browsers.

AJAX

Using JavaScript, web pages became more interactive but more was left to be desired. If for instance, some data was changed in the database our page must be reloaded to retrieve it and see those changes. Additionally, when submitting a form; a page navigation must be made to the script handling the form data.

Browser vendors experimented with various methods for having the browser make http requests in the background (or asynchronously) and then update the page with the response. In April 2006 the World Wide Web Consortium W3C standardized the XMLHTTPRequest (XHR) Object as a means to achieve this.

This was big, now there was a standardized method for developers to have their web applications send and receive data without page loads! This revolutionized web application experiences. App-like sites like Gmail were now possible.

The term Asychronous JavaScript and XML (AJAX) was coined to refer to this method of building dynamic web applications using XHR.
Instead of returning HTML, some of our server side scripts can simply return our data as XML/JSON. Our JavaScript will request it then perform templating on the browser to display the data.

Nowadays this is referred to as Client Side Rendering as opposed to Server Side Rendering when templating was done by the server side script.

Almost There

I'm sure the technologies and methods in this article are familiar to the modern dev. We shall finish this series in the next and final post.

References

A "Brief" History of the Web

Nicholas Mendez — Sun, 19 Sep 2021 03:59:54 +0000

Looking back on how web apps started can give us an insight on where it's going.

Birth of the WWW

While working for CERN in 1989 a British scientist of the name Tim Berners-Lee invented the World Wide Web. The idea was to create a world wide network of computers to form a global information system.

The first Web Webserver, Web Browser and Web Page

It wouldn't be until late 1990 where Berners-Lee deployed the world's first web page. A web page is a text document written in a special formatting language called the Hypertext Mark-up Language(HTML).

The world's first web server Photo Credit.

Web servers are simply computers connected to a network that exposes a portion of it's filesystem to any web browser that connects to the web server's IP address.

How the web works Image Credit

When web browser software running on a networked client computer connects to the web server; it downloads and displays the server's documents according to the formatting specified in the document's HTML code. The network protocol that governs this communication is the Hypertext Transfer Protocol (HTTP).

The Start of the Dynamic Web

The Common Gateway Interface

There was a demand for webpages to be 'smarter'. Since web servers are just computers why not execute programs on it? Hence the Common Gateway Interface (CGI) was created in 1993. The CGI lets us configure our webservers to execute a program/script on the server as opposed to returning an html page from the filesystem when responding to a request.

Initially CGI was specified to execute scripts written in C. Support for shell scripts and other languages such as Perl, Ruby, Java Server Pages, Active Server Pages and PHP followed. But, what did these scripts do?

Templating

Before server side scripting, websites were static read only experiences. When a web page was visited in the browser, the same content will appear unless there was an update by the author. If you had many pages of a website that shared common, styles or sections, they had to be individually written and updated on each page.

Templating was the solution to this problem. This made building large websites significantly easier as you can reuse part of pages and use loops and if statements to generate html code.

How a template engine works Image Credit

void print_file(FILE *f)
{
    int c;
    if (f)
    {
        while ((c = getc(f)) != EOF)
            putchar(c);
        fclose(f);
    }
}

int main()
{
    FILE *content = fopen ("/var/www/cgi-bin/hello-world.html", "r");
    FILE *header = fopen ("/var/www/cgi-bin/header.html", "r");
    FILE *footer = fopen ("/var/www/cgi-bin/footer.html", "r");

    printf("Content-Type: text/html \n\n");
    print_file(header);
    print_file(content);
    print_file(footer);
    return 0;
}

A CGI Script written in c credit

The server side script interpreters come with a Template Engine. Template Engines interpret script commands for pre-processing html in the server before being sending them to the browser.

At this point, large websites were easier to make and we can change our page content based on form submission data from a previous page.

Handling Data

Now that an execution model has been established on the server, long term data storage could be integrated into web experiences. By having our server side scripts connect to databases and apply templating, web pages can become more dynamic.

Now, the data on a page can be separated from its formatting.
We can use a script to connect to a database, retrieve some data, then apply template syntax to display the data on a page. This allows the content of pages to be dynamically altered without updating the page itself but rather by altering the data source instead. This was the start for many interactive web applications.

Stopping for now

This post is turning out to be much longer than I imaged. Maybe it's not so brief after all. I think I shall make this a series instead and explore this further in the next post. Until next time!

Update (25/09/2021)
Many thanks to Jackub for the suggestion about expanding on CGI. I have updated this article to expand on it.

References

Computer Science vs Software Engineering

Nicholas Mendez — Sun, 12 Sep 2021 03:44:38 +0000

Computer Science and Software Engineering are often compared with each other. While there are overlapping skills in both fields let's take look at how their approach to programming differ.

What is Computer Science 💻👩🏽‍🔬?

Computer Scientist are typically preoccupied with developing new theory and technologies. This can be the next ground breaking Machine Leaning model like GPT3 or the next version of HTTP.

Computer Scientists often work in Academic Institutions or Research & Development departments researching the building blocks of tomorrow's technology.

What is Software Engineering 🛠📱?

Software Engineers apply traditional Engineering theory for developing to not only develop software products, but deploy, maintain and manage the people involved in the process. Software Engineering applies established theories and methods for building and maintaining software products under constraints.

Picture of SCRUM which is a popular agile development methodology

Software Engineers can not only be found behind any software product but even in companies that do not sell software as their main product or service.

How does a Computer Scientist Code?

All scientific fields strive to push the known theoretical boundaries through research and innovation. As such, when it comes coding, computer scientist are very much concerned with maximizing the efficiency of their programs and models. Computer Scientists place much emphasis in the design and the empirical analysis of their algorithms.

How does a Software Engineer Code?

The goals of Software Engineers are much different to that of the Computer Scientist. Software Engineers spend time in various activities other than development such as software specification, validation and evolution.

Often Software Engineers find themselves in a tricky balancing act between deadlines, stakeholder expectations and the non-functional requirements of the product. To such an extent that even code efficiency can take a back seat if the returns are not worth the effort. Instead, more focus is given to the quality of the code, so that it is easy to extend and maintain.

Software Engineers clearly specify the goals of their code and minimize the effort spent in achieving them precisely.

Should Engineers care about Algos & DS?

We all hear about the dreaded code interviews of the big FAANG companies. Some devs are of the view that such focus on algorithms and data structures is unnecessary because they have never need to write something like a binary tree for production.

I think this criticism is misplaced. The reason FAANG requires mastery of algorithms and data structures is not only for their implementation sake, but rather for you to posses the profound analytical and problem solving skills you gain with them. It also helps with cutting down their huge application pool. You can say that these companies prefer a software engineer with a strong set of Computer Science skills.

However, this is for really big tech companies. You may very well find yourself in an software engineering job without a CS background, but I argue that the best engineers are likely to have it.

Conclusion

Of course there's some nuance to this as it really depends on what you work on. If you are an engineer that never looked into Algos and DS, I am in no way saying you are bad at your job. The good news is if you are interested about learning CS theory there are many online resources that are freely available.

References & Image Credit

How well do you know DOM JavaScript?

Nicholas Mendez — Sun, 05 Sep 2021 03:50:49 +0000

HTML and JavaScript have been around awhile, with its age there are some very nuanced tricks and hacks that aren't very well known. Let's take a look at some of them and when they are appropriate to use.

But first... the BOM

The collection of JavaScript objects & methods that let use access the features of the browser is referred to as the Browser Object Model.

The Document Object Model which is the hierarchy of elements on a page that is accessed from the window.document object. The DOM is really just part of the wider Browser Object Model BOM.

The BOM then forms part of the wider set of Web APIs which allow us to tap into the wider features of the web.

I often like to access a form and its element via their names and the document object as shown below.



    <form name="myform">
           <input type="text" name="username"/>
           <input type="submit" value="submit"/>
    </form>
    <script>

       //you can access myform from the dom using document.forms
       const myform = document.forms["myform"];

       //you can access a form's element using form.elements
       const username = myform.elements["username"];

    </script>

DOM Elements

Every other html element can be accessed in JavaScript by using document.querySelector(). The attributes of the HTML element can be accessed as a property of it's corresponding element object.



      const link = document.querySelector('#mylink');
      console.log(mylink.href);// https://google.com

      const username = myform.elements["username"];

      //access html attributes via properties
      console.log(username.name);// username
      console.log(username.type);// text
      console.log(username.value);// value entered into text field

Window and Global Scope

Global functions and objects declared with var can be referenced via the window object. Note, that doesn't work with block scoped variables declared with let and const.



    <script>
        var myVar = "foo";

        let bar = "bar";

        function baz(){}

        console.log(window.myVar);// foo
        console.log(window.bar);// undefined
        console.log(window.baz);// [function: baz]

    </script>

DOM nodes and ID

Any element with an ID will create a JavaScript object named after that ID. innerHTML is a very useful property that returns the contents of an HTML tab. Though it seems to behave quite differently across various browsers so you're probably better of using document.querySelector().



    <h1 id="myheading">My Heading</h1>  

    <script> console.log(myheading.innerHTML)</script>
    <!-- logs "My Heading" -->

JS in html attributes

Some html attributes can allow JavaScript to be executed. The most popular use case is probably calling a function in an event attribute.



   <button onclick="btnClick()">My Button </button>
   <script>
       function btnClick(){
           console.log('button clicked!');
       }
   </script>

You can also execute JavaScript in an anchor tab by specifying JavaScript in the hrefs value. This can supposedly work with elemetets that have the src attribute as well.



   <a href="javascript: console.log('hello')"> Say Hello</a>

Data attributes

Data attributes are custom attributes we can add to and element and are a great way to provide contextual data to an event handler. You can create a data attribute by supplying your custom attribute with a data- prefix. Then you can access the value by using the dataset property.



   <button data-name="john" data-age="17" onclick="logUser(event)">John Button</button>
   <button data-name="mary" data-age="18" onclick="logUser(event)">Mary Button</button>
   <script>
      function logUser(event){
         const button = event.target;
         console.log(button.dataset.name); // logs john | mary
         console.log(button.dataset.age); // logs 17 | 18
      }
   </script>

Here we used event.target to get the elment that the click event occured on. This can only work if event is passed to event handler logUser.

Editable Content

I'm updating this post to include this section as I literally just came across this. You can add the coententeditable attribute to any element to allow the user to edit the text of the element on the page.



   <h1 contenteditable="true">Text 1</h1>

   <h1 id="heading2" >Text 2</h1>

   <script>

     const heading = document.querySelector('#heading2');

     // can also be set via contentEditable property
     heading.contentEditable = 'true';

     // the input event fires anytime content id edited
     heading.oninput = function(){
         console.log('Input received');
     }
   </script>

You can also apply this to the entire page via the window.document.designMode property.



    window.document.designMode = 'on';

Conclusion

I hope you've learned a few new things in this post. Are there any lesser known tricks that I may have missed? Please share!

References

Degree vs Self Taught vs Boot Camp

Nicholas Mendez — Sun, 29 Aug 2021 02:37:45 +0000

It's been a long ongoing debate. With the prevalence of widely available information online, many wonder if a degree is still worth it for getting into the tech industry. My programming journey started self taught but I am a CS graduate and currently teach CS Courses at the University level. Here's my take on the matter.

The Criticisms of a college degree

The most obvious disadvantage of a degree is the cost. Cost in terms of time and finances. Tuition in US based Universities appear to be on the constant rise. For many people, finding the time to do a 3 or 4 year degree may simply be infeasible especially when trying for a career change.

There will always be a gap between the cutting edge developments of industry and academic curriculum. A common concern is undergoing the sacrifices of pursuing a degree only to learn irrelevant or outdated material.

Challenges of being self taught

We live at a great time for dev, there's so much free content, communities and mentors that can be of great help. However, the caveat is that the sheer amount of content can be overwhelming. Often, it's hard to know where to start or what to learn as there are so many differing opinions in web development.

Secondly, many traditional firms still require a degree programme for even entry level tech jobs. Even when a degree is not required, you often hear stories of self taught devs being condescended by their formally educated colleagues. The good news things like this seem to be on decline as the industry focuses more on outcomes and portfolios rather than just grades.

The dangers of Boot Camps

Boot Camps, nano degrees and courses are a great way to seek focused shorter term education dedicated to mastering a specific subject. Unfortunately, there are some predatory boot camps out there offering poor quality education or making false promises.

I've seen Boot Camps that rush content and you end up learning a specific framework as opposed to programming and web development in general. A web developer should have other skills like communication, project management and software design. A boot camp typically focuses on the technical skillset.

Advantages of being self taught

Good self taught developers will always have my respect. It takes so much motivation, discipline and courage to take on web dev like that. The self taught devs I've worked with are passionate people and are generally happy to help others as they can empathize with newbies.

The only advice I'd give to self taught devs is to look into some computer science and software engineering concepts to round off their knowledge. Things such as algorithms, data structures, requirements gathering, agile, design patterns and SOLID principles.

Advantages of a Degree

When it comes to the degree discussion I think people often undermine some of its value. Yes, you will get a paper at the end, but the university experience offers much more. The life-long colleagues you will make, networking, internships and other student opportunities that offer profound personal growth and development also await. People don't describe college as the 'best time of their life' for no reason. For those who can do college, it's ultimately up to you to make the best of your time there.

New tech comes and goes all the time but a good degree programme instils a balance of solid, immutable foundational concepts and modern methodologies & technologies. Additionally, a Computer Science degree will cover more than just web development, you get alorithms & data structures, operating systems, databases, devops, software engineering, cloud, networking, AI, cyber security etc so there are other career options as well.

When it comes to cost, you may want to consider Universities based outside of the US where tuition can be as much as 50% cheaper!

Advantages of a Boot Camp

Like a degree, boot camps provide a set curriculum and ensures you cover content via lectures, labs and assessments. For many, it's easier to rely on this structure a rather than finding the motivation for self study. A good boot camp can get you up to speed without the commitment of a degree. I know some talented devs who have transitioned into tech via a Boot Camp.

If you are doing a Boot Camp, try to go for one recommended by an experienced dev, ideally one without ties to the camp itself. Additionally, you may also want to seek out online courses or Nano degrees to cover Computer Science and Software Engineering concepts to compliment your technical knowledge.

Conclusion

At the end of the day, no matter what the path, learning never ends as that is the nature of Technology. This stuff can be intimidating but that's what your community is for!

Please feel free to @me on twitter if you have questions on career guidance or just need of general advice, I'd be happy to help out!

I promise you, if you really want it you can make it no matter the path, you just need to keep striding. What path are you on or have taken? What advice would you give for that path? Please share in the comments!

The Async Series: Async Functions

Nicholas Mendez — Sun, 22 Aug 2021 03:50:26 +0000

The long awaited async function

In the last post, we covered promises and promise chaining with .then(). Promise chains provided an improvement over nested callbacks but in this post we'll cover something that does even better.

A Recap

Recall our favourite async library lib from previous posts in this series. We saw how we can use the .then() method on promises to form a promise chain.


    printBlue("Blue")
    .then(()=>printGreen("Green"))
    .then(()=>printRed("Red"))
        .catch(err=>console.log(err));

The promise chain synchronises the async calls so that they execute in the intended order.

Async/Await

However, ECMAscript 2016 released the Async/Await syntax, it allows us to declare async functions. In async functions we can use the await keyword. Await lets us block asynchronous promised based calls and get the value that the promise resolves to instead of using .then(). The following is previous code snippet converted to an async function.


async function printFun(){
    try{
      await printBlue("Blue");
      await printGreen("Green");//doesn't execute until printBlue finishes
      await printRed("Red");//doesn't execute until printGreen finishes
    }catch(e){
      console.log(e);
    }    
}

Notice we use a top level try catch block instead of the .catch() method. Async functions lets uses easily synchronize promised based APIs in the top level.

It all adds up

Let's see how we can use this with the async add() function.


async function  addAll(a, b, c, d, e, f){
   let res = await add(a, b);
   res = await add(res, c);
   res = await add(res, d);
   res = await add(res, e);
   res = await add(res, f);
   return res;  
}

The one thing to note however, is that Anything returned by an async function will be wrapped in a promise. So if we wanted to log the result of the last function we would have to do the following.


//call .then() on the promise
addAll(6, 2, 42, 11, 20, -1)
  .then(function(res){
    console.log(res); 
  });

// OR use another async function

async function printSum(){
  let res = await addAll(6, 2, 42, 11, 20, -1);
  console.log(res);
}

printSum();

Conclusion

An that's it for the async series. Async functions really makes things easier to work with async calls but just remember they return promises. I hope this series helped you get to grips with async code in JavaScipt. As always here is a REPL to try out the examples yourself.