redactedconcepts

[redactedconcepts]

Credit: artsydoe

[redactedconcepts]

Reading a book about slavery in the middle-ages, and as the author sorts through different source materials from different eras, I am starting to understand why so many completely fantastical accounts of "faraway lands" went without as much as a shrug. The world is such a weird place that you can either refuse to believe any of it or just go "yeah that might as well happen" and carry on with your day.

There was this 10th century arab traveller who wrote into an account that the fine trade furs come from a land where the night only lasts one hour in the summer and the sun doesn't rise at all in the winter, people use dogs to travel, and where children have white hair. I don't think I'd believe something like that either if I didn't live here.

[redactedconcepts]

points have been made

[redactedconcepts]

You know every show that the premise is like “people find out ghosts/monsters/demons are real and are charged with stopping them” appeal to me way more now as a post-graduate not because I believe in ghosts more or whatever but because can you IMAGINE just being handed a job that you don’t even need to apply for? Like just being told “basically there’s this bad thing and all you do is make sure it doesn’t do what it wants” that’s just customer service baby and I worked that for 6 goddamn years! Just TRY getting past “I have a job to offer you” before I can jump down your throat agreeing.

[redactedconcepts]

A Crash Course on Accessibility

Overview

WCAG is a set of guidelines, created by the W3C, for making digital content accessible for all users, including people with disabilities.

WCAG timeline

1999: WCAG 1.0 released by W3C

2008: WCAG 2.0 (current version) released

2012: WCAG 2.0 became ISO standard

2017: WCAG 2.1 draft under public review

2018: WCAG 2.1 became ISO standard

2020: WCAG 2.2 working draft and WCAG 3.0 (called “Silver”) is also in working phase

4 principles

WCAG is organized around four principles often called by the acronym POUR:

Perceivable: Can users perceive the content? This helps us keep in mind that just because something is perceivable with one sense, such as sight, that doesn’t mean that all users can perceive it.

Operable: Can users use UI components and navigate the content? For example, something that requires a hover interaction cannot be operated by someone who can’t use a mouse or touch screen.

Understandable: Can users understand the content? Can users understand the interface and is it consistent enough to avoid confusion?

Robust: Can the content be consumed by a wide variety of user agents (browsers)? Does it work with assistive technology?

Accessibility Levels

After defining the 4 principles, WCAG defined 3 differents levels, the two first being absolutely required for any business and website. AAA level is recommended but not required as it may have bigger impacts on designs.

Levels

Level A (required)

A: This level improves accessibility for most sites by making it easier for browsing readers to navigate a site and translate its content, but it is still pretty basic.

Level AA (required)

AA: This level makes content accessible to people with a wider range of disabilities by providing guidance on elements such as color contrast and error identification. Regulators prefer this level.

Level AAA (optional)

AAA: The highest level of accessibility compliance, this makes content accessible to the widest range of people, but it can significantly alter the design of a site. Government legislation doesn’t typically require this because it’s not always possible to conform.

Resources

Accessibility Conformance Levels: Standards

ARIA (Accessible Rich Internet Applications)

ARIA is a specification from the W3C and created to improve accessibility of applications by providing extra information to assistive technologies, such as screen readers, via attributes which could be added to HTML.

Warning!

Use native HTML elements: Always use HTML elements whenever possible and try to not re-create element adding an ARIA role. Don’t use ARIA as a quick-fix.

Categories

ARIA Roles

ARIA Roles

ARIA States and Properties

ARIA States and Properties

Resources

First Rule of ARIA Use

Introduction to ARIA | Web Fundamentals | Google Developers

Getting started with ARIA - The A11Y Project

An overview of accessible web applications and widgets - Accessibility | MDN

WAI-ARIA: Top 6 Mistakes to Avoid | Deque

WebAIM: To ARIA! The Cause of, and Solution to, All Our Accessibility Problems

A11y testing tools

When we talk about Web Accessibility Tools, we need to differentiate between automated tools and manual tools.

Based on Tenon.io insights, around 49% of tests are automated (using Axe, Lighthouse etc) and 55% are manual (Screen readers, code analysis etc).

Companies dedicated to A11y

Siteimprove, Tenon.io, Deque and The Paciello Group are amount the most famous company working with Web Accessibility.

Deque Systems

Deque developed an engine called axe-core, which is use by Lighthouse, a Web Accessibilty Testing tool, and webhint.

Example of accessibility tools inside Chrome Developer tools

On Chrome (and Firefox), you can find a color contrast checker available when you select an element to inspect.

You can also see the accessibility tree and all properties attached to an element in the right panel of the Google Developer tool.

Screen Readers

Few different screen readers exist. On Apple products, VoiceOver is the one usually used. Jaws is famous but expensive. NVDA is an open source version that is more an more used in replacement to the expensive Jaws windows software.

You can see in the graphic below that JAWS, NVDA and VoiceOver were the most used late 2017.

How to enable VoiceOver on Mac OSX

Go to your preferences

Choose Accessibility

On the VoiceOver tab, choose to enable VoiceOver. I recommend to learn the shortcut ⌘ + F5 to easily enable / disable VoiceOver.

Basic shortcuts for VoiceOver (only on Mac OSX)

You can play to see how VoiceOver works. Here are some important shortcuts, like the Next heading that shows how important it is to have good headings.

VoiceOver ON/OFF: Command + F5 (Mac: ⌘ + Fn + F5)

Start reading: VO (⌘ + ⌥) + A

Stop reading: CTRL

Open rotor: VO (⌘ + ⌥) + U

Next heading: ⌘ + VO + H

Next link: ⌘ + VO + L

Next graphic: ⌘ + VO + G

Screen readers and voice tools

JAWS Screen Reader - Best in Class

NV Access | Download

Vision Accessibility - Mac - Apple (CA)

Dragon NaturallySpeaking - world’s best-selling speech recognition software | Nuance

Resources

Button Contrast Checker | Aditus | Free tool

Web Accessibility Evaluation Tools List

WAVE Web Accessibility Tool

Accessibility testing tools – Updated May 2019 | TPG – The Accessibility Experts

9 Tools for Website Accessibility Testing

Top 25 Awesome Accessibility Testing Tools for Websites

Keyboard Navigation

Some people can’t use a mouse to navigate on webpages. It’s important to test your pages using only the keyboard (some people only use a switch button to navigate and do tasks on a device).

Keyboard Tabbing Order

If you tab to go throw all links in the article page, you will see that the aside comes after the link inside the content. That is not ideal but we will not change it in our example.

Resources

WebAIM: Keyboard Accessibility

Designing for Keyboard Accessibility | Accessible Technology

outline - CSS: Cascading Style Sheets | MDN

I Threw Away my Mouse - 24 Accessibility

Tab order | UX design | Accessibility for Teams

Skip Links

Links that facilitate navigation when the user is using the keyboard. It allows the user to go directly to the most important sections of the page.

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. – WCAG 2.1

Resources

WebAIM: “Skip Navigation” Links

How-to: Use skip navigation links - The A11Y Project

Your skip links are broken - Axess Lab

A11Y Style Guide - Skip Links

[redactedconcepts]

Technical Writing

Technical Writing Overview

Technical writing is an invaluable skill and an excellent way to articulate and share your knowledge. It’s not enough to just be able to code; being able to explain the concepts behind the code proves deeper understanding as well as the ability to communicate with others.

Technical Writing Basics

You will write several blogs during your time as a student. Technical writing pieces are included in both project assignments and as extracurricular assignments from staff.

The general requirements for all blogs are as follow:

Have at least one picture at the top of the blog post

Publish your blog post on Medium or LinkedIn

Share your blog post at least on LinkedIn

Write professionally and intelligibly

Explain every step/concept you know, and give examples – a total beginner should understand what you have written

Please remember that these blogs must be written in English to further your technical ability in a variety of settings

Remember that future employers will see your articles; take your writing seriously and produce something that will be an asset to your future

Blogs are manually reviewed by a staff member, a TA, or a peer and are evaluated on how well they meet the above requirements as well as specific requirements based on topic, which is listed in the associated project.

This should go without saying, but plagiarism is unacceptable.

Technical Writing FAQ

“Why are the blog instructions so vague? How do I know what to write about?”

We do not outline all the requirements because part of these challenges is to teach/learn/experience how to find what needs to be said on a topic that’s new to you. You may not know what needs to be explained to a reader, but your research on the topic should help guide you.

“If the blog should be understood by beginners, why is there an expectation of having in-depth explanations, even to the point of using jargon beginners may not understand?”

Even if your audience is beginners, we must trust that they could understand a highly technical topic if it is explained well. Be sure to not only use appropriate jargon but to define the jargon you use. After reading your blog, the hope is that your audience will know the technical topic at the deepest level possible.

“My reviewer scored me more strictly than others. Can’t we make this more standardized?”

Each student is entrusted to score fairly and to the best of their ability. We understand that there may be a variance between how reviewers score, but it also reflects the interpretation and understanding of a general reader audience.

“Can I write other technical blogs outside of school projects?”

Of course! You’re encouraged to share them with staff and peers as well. If you’re interested in writing more but don’t know what to write about, here are some ideas:

Keeping a devblog for big projects is a great way to document processes, successes, failures, and to-dos.

If you find a framework, SDK, API, etc. has limited or confusing documentation, write a tutorial to help others with the problems that you’ve encountered.

[redactedconcepts]

3 Ways to Make a Portfolio Project Great

This concept is written with many examples of internet applications because URLs are easiest to share, but these suggestions are helpful to keep in mind for all types of software you might develop for your Portfolio Project.

1. The Logged Out Experience

Anyone you show your project to will likely have only a few minutes to take a look. The worst way to spend these few minutes is to throw up a log in screen. Clearly a log in is helpful for tailoring an experience and providing a persistent experience. Let take a quick tour to see how other websites behave.

Logged out experience examples

Many of the most heavily trafficked web sites greet strangers with a locked-out landing page. If you want to experience this, open an anonymous browser and check out Facebook, Pinterest, and Github. These power brands can rely on users flocking to their site with the intention of signing up because they already know they want to use the product being offered.

Other sites are not as well known, and must rely on passive traffic where users come to the site to explore functionality and evaluate whether the experience is for them. Some have a logged out experience, but more clearly demonstrate how their product can be used. Asana and Trello are examples of this. Both landing pages have a demo and helpful information to inform browsers how their productivity might be positively impacted.

Another path is for websites to completely expose their functionality with no requirement to login. Some sites do this because the experience would be no different whether the user was logged in or out, and the author is not interested in the inherent risk of storing credentials. Others do this because the anonymous experience is core to their functionality (like Craigslist!)

The “Quake Tracker” App is a great logged out example:

The app provides a visualization of earthquake events around the world across time. There is no need to log in because there is no additional information the user could provide to alter the experience.

The “Savings” App is another great example:

This app allows you to return to your work in progress by creating a uniquely identified URL. Since the developers chose not to present and capture any identifying information, it becomes perfectly okay to expose savings calculations. Of course, they do not account for an interloper editing your page, but the purpose of this app seems to be as a demonstration of the developer’s engineering abilities (see ToMakeOrNotToMake ) rather than an actual app where your personal savings information should be stored.

Think about ways you can expose the core experience (the “fun”) without requiring a login.

2. A Data-Rich Experience

We want to avoid the experience where an employer or ally might stumble upon your final project, take the time to login and find that they are greeted with emptiness. Take the time to think through how you might populate some presets into your software, or ingest data to populate your experience. Many apps go to great lengths to ensure the logged-in experience feels warm and inviting.

Example: Airtable

Airtable is a relatively complex application (compared to a to-do list) where there may be a learning curve to use the application. The team behind Airtable has added some sample ‘bases’, a default workspace, and pops up a personal message with a tutorial video upon logging in.

This might be a strategy you want to use for your app. You may want to create some default data, or a tutorial to bring your app to life upon logging in.

Example: Findacar

The Findacar app is a portfolio project piece created by Diana Lozano. She has created a single page app to search rental cars by date, time and location. She has sourced the data from the Hotwire API and this has resulted in a fantastic data-rich (and logged out) experience!

Example: Moro

Finally, if you don’t have a web-focused final project, that doesn’t mean you can’t have a rich experience. Take a look at Moro’s demo:

It’s clear there is extra effort to creating some extra text for formatting sake. The documentation is also extensive with rich examples.

3. Showcase yourself

It’s not enough that your Portfolio Project is an interesting and engaging experience. It’s necessary that the viewer of your app understands you created this app as a demo of your amazing skillset. Somewhere on your app’s page, you’ll want to link to the source code for this final project’s Github, or your personal web site. Here are some examples:

Little corner banner

This banner could say “Hire Me” or be more subtle, like this GitHub Octocat in the top-right which links to the source code of this project.

Subtle footer mention

Another obvious place to link to your final project’s github is the footer of the project page. Here’s an example:

Call out in a section, with a photo!

Be proud of your work and put your face on it with an invitation for people to learn more or connect with you through Twitter, LinkedIn, etc.

[redactedconcepts]

Job Search Resources

ReadMe [Regardless of Goals]

Reality of Job Searching

Cracking the Coding Interview we have a few copies of this in the library for you (^.^)

Ace the Coding Interview, Every Time

Fullstack / Backend

Get that Job at Google

Tech Interview Handbook

Coding Tools

The HackerRank Interview Preparation Kit

Top 100 Interview Questions via Leetcode

Front End Specific

Cracking the Front-end Interview

Front-End Interview Handbook

A Very Comprehensive Guide to Front-End Interview Prep

SRE specific

SRE Interview Prep Stuff.pdf (shhh, remember to keep it solely in the redactedconcepts fam)

Guide to Getting into SRE by Tammy Butow

SRE Interview Questions

Project Management

AirTable

Jira

Asana Trello

[redactedconcepts]

Cryptocurrency / Blockchain

Important:

Blockchain and cryptocurrencies are not interchangeable technologies; distributed ledgers (which blockchain is one example of) have many different applications. They’ve been included together here given the frequency with which they are used in tandem, but explore the countless ways they are utilized outside of cryptocurrency.

ReadMe

Read first the More Tech Fields concept page.

Read/Do

Blockchains, Cryptocurrencies & the New Decentralized Economy:  A Gentle Introduction

Blockchain Basics: Introduction to distributed ledgers

San Francisco’s Mitali Sengupta’s Paper on Linux.com

How to Build Your Own Tiny Baby Blockchain Tutorial

Learn Blockchains by Building One

What is a White Paper in Cryptocurrency?

Ethereum

Bitcoin

Watch

Understand the Blockchain in 2 Minutes

Blockchain Expert Explains One Concept in 5 Levels of Difficulty

[redactedconcepts]

Artificial Intelligence, Machine Learning, and Deep Learning

ReadMe

Read More Tech Fields concept page first

Read/Do

Introduction to Machine Learning

Eight Different Machine Learning Algorithms and their Implementation

Get Started with TensorFlow

Machine Learning Algorithm Cheat Sheet

Neural Networks and Deep Learning by Michael Nielson

The Difference Between Artificial Intelligence, Machine Learning, and Deep Learning

Watch

What is a neural network?

Machine Learning & Artificial Intelligence: Crash Course

What is Machine Learning?

Deep Learning Playlist

Math

The Mathematics of Machine Learning

Gentle Introduction to Linear Algebra

A first course in Linear Algebra

Linear Algebra Tutorial

[redactedconcepts]

Docker

Readme

What is Docker and why is it popular?

Take note: The following instructions are run in a ubuntu-xenial virtual machine setup using Vagrant. To do the same, you can also install docker in any Vagrant virtual machine, or install docker on your host OS (Windows, Linux or Mac OS)

Let’s first pull a Docker image and run a container:

vagrant@ubuntu-xenial:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES vagrant@ubuntu-xenial:~$ docker run -d -ti ubuntu:16.04 Unable to find image 'ubuntu:16.04' locally 16.04: Pulling from library/ubuntu 34667c7e4631: Pull complete d18d76a881a4: Pull complete 119c7358fbfc: Pull complete 2aaf13f3eff0: Pull complete Digest: sha256:58d0da8bc2f434983c6ca4713b08be00ff5586eb5cdff47bcde4b2e88fd40f88 Status: Downloaded newer image for ubuntu:16.04 e1fc0d4bbb5d3513b8f7666c91932812da7640346f6e05b7cfc3130ddbbb8278 vagrant@ubuntu-xenial:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e1fc0d4bbb5d ubuntu:16.04 "/bin/bash" About a minute ago Up About a minute keen_blackwell vagrant@ubuntu-xenial:~$

Note that docker command will pull the Ubuntu docker container image from the Internet and run it. I let you look at the meaning of the flags using the command docker run --help, the main idea is that it keeps the container up and running.

To execute a command on the Docker container, use docker exec:

vagrant@ubuntu-xenial:~$ docker exec -i e1fc0d4bbb5d hostname e1fc0d4bbb5d vagrant@ubuntu-xenial:~$ hostname ubuntu-xenial vagrant@ubuntu-xenial:~$

If you want to connect to your Docker container and use Bash, you need to use docker exec -ti:

vagrant@ubuntu-xenial:~$ docker exec -ti e1fc0d4bbb5d /bin/bash root@e1fc0d4bbb5d:/# echo "I am in $(hostname) Docker container" I am in e1fc0d4bbb5d Docker container root@e1fc0d4bbb5d:/# exit exit vagrant@ubuntu-xenial:~$

If you want to stop a container, use docker stop:

vagrant@ubuntu-xenial:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e1fc0d4bbb5d ubuntu:16.04 "/bin/bash" 5 minutes ago Up 5 minutes keen_blackwell vagrant@ubuntu-xenial:~$ docker stop e1fc0d4bbb5d e1fc0d4bbb5d vagrant@ubuntu-xenial:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES vagrant@ubuntu-xenial:~$

[redactedconcepts]

Using Emacs as editor

Read the page A Guided Tour of Emacs from the GNU, and go through the Emacs tutorial: Open emacs by typing emacs in your shell. Then type C-h t to open the tutorial and go through it.

Using Vi as editor

Read the page Basic vi Commands.

[redactedconcepts]

Never forget a test

Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not. Testing is executing a system in order to identify any gaps, errors, or missing requirements contrary to the actual requirements. This tutorial will give you a basic understanding of software testing, its types, methods, levels, and other related terminologies.

Code that is not tested can’t be trusted

Bad reputation

“Testing is Too Expensive”: Pay less for testing during software development => pay more for maintenance or correction later. Early testing saves both time and cost in many aspects. However, reducing the cost without testing may result in improper design of a software application, rendering the product useless.

“Testing is Time-Consuming”: Testing is never a time-consuming process. However diagnosing and fixing the errors identified during proper testing is a time-consuming but productive activity.

“Only Fully Developed Products are Tested”: No doubt, testing depends on the source code but reviewing requirements and developing test cases is independent from the developed code. However, iterative or incremental approaches to a development life cycle model may reduce the requirement of testing on the fully developed software.

“Complete Testing is Possible”: It becomes an issue when a client or tester thinks that complete testing is possible. It is possible that all paths have been tested by the team but occurrence of complete testing is never possible. There might be some scenarios that are never executed by the test team or the client during the software development life cycle and may be executed once the project has been deployed.

“A Tested Software is Bug-Free”: No one can claim with absolute certainty that a software application is 100% bug-free even if a tester with superb testing skills has tested the application.

“Testers are Responsible for Quality of Product”: It is a very common misinterpretation that only testers or the testing team should be responsible for product quality. Testers’ responsibilities include the identification of bugs to the stakeholders and then it is their decision whether they will fix the bug or release the software. Releasing the software at the time puts more pressure on the testers, as they will be blamed for any error.

“Test Automation should be used wherever possible to Reduce Time”: Yes, it is true that Test Automation reduces the testing time, but it is not possible to start test automation at any time during software development. Test automaton should be started when the software has been manually tested and is stable to some extent. Moreover, test automation can never be used if requirements keep changing.

Basic

This standard deals with the following aspects to determine the quality of a software application:

Quality model

External metrics

Internal metrics

Quality in use metrics

This standard presents some set of quality attributes for any software such as:

Functionality

Reliability

Usability

Efficiency

Maintainability

Portability

Functional Testing

This is a type of black-box testing that is based on the specifications of the software that is to be tested. The application is tested by providing input and then the results are examined that need to conform to the functionality it was intended for. Functional testing of a software is conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements.

There are five steps that are involved while testing an application for functionality:

The determination of the functionality that the intended application is meant to perform.

The creation of test data based on the specifications of the application.

The output based on the test data and the specifications of the application.

The writing of test scenarios and the execution of test cases.

The comparison of actual and expected results based on the executed test cases.

An effective testing practice will see the above steps applied to the testing policies of every organization and hence it will make sure that the organization maintains the strictest of standards when it comes to software quality.

Unit Testing

This type of testing is performed by developers before the setup is handed over to the testing team to formally execute the test cases. Unit testing is performed by the respective developers on the individual units of source code assigned areas. The developers use test data that is different from the test data of the quality assurance team.

The goal of unit testing is to isolate each part of the program and show that individual parts are correct in terms of requirements and functionality.

Limitations of Unit Testing:

Testing cannot catch each and every bug in an application. It is impossible to evaluate every execution path in every software application. The same is the case with unit testing.

There is a limit to the number of scenarios and test data that a developer can use to verify a source code. After having exhausted all the options, there is no choice but to stop unit testing and merge the code segment with other units.

Integration Testing

Integration testing is defined as the testing of combined parts of an application to determine if they function correctly. Integration testing can be done in two ways: Bottom-up integration testing and Top-down integration testing.

Bottom-up integration: This testing begins with unit testing, followed by tests of progressively higher-level combinations of units called modules or builds.

Top-down integration: In this testing, the highest-level modules are tested first and progressively, lower-level modules are tested thereafter.

In a comprehensive software development environment, bottom-up testing is usually done first, followed by top-down testing. The process concludes with multiple tests of the complete application, preferably in scenarios designed to mimic actual situations.

System Testing

System testing tests the system as a whole. Once all the components are integrated, the application as a whole is tested rigorously to see that it meets the specified Quality Standards. This type of testing is performed by a specialized testing team.

System testing is important because of the following reasons:

System testing is the first step in the Software Development Life Cycle, where the application is tested as a whole.

The application is tested thoroughly to verify that it meets the functional and technical specifications.

The application is tested in an environment that is very close to the production environment where the application will be deployed.

System testing enables us to test, verify, and validate both the business requirements as well as the application architecture.

Regression Testing

Whenever a change in a software application is made, it is quite possible that other areas within the application have been affected by this change. Regression testing is performed to verify that a fixed bug hasn’t resulted in another functionality or business rule violation. The intent of regression testing is to ensure that a change, such as a bug fix should not result in another fault being uncovered in the application.

Regression testing is important because of the following reasons:

Minimize the gaps in testing when an application with changes made has to be tested.

Testing the new changes to verify that the changes made did not affect any other area of the application.

Mitigates risks when regression testing is performed on the application.

Test coverage is increased without compromising timelines.

Increase speed to market the product.

Acceptance Testing

This is arguably the most important type of testing, as it is conducted by the Quality Assurance Team who will gauge whether the application meets the intended specifications and satisfies the client’s requirement. The QA team will have a set of pre-written scenarios and test cases that will be used to test the application.

More ideas will be shared about the application and more tests can be performed on it to gauge its accuracy and the reasons why the project was initiated. Acceptance tests are not only intended to point out simple spelling mistakes, cosmetic errors, or interface gaps, but also to point out any bugs in the application that will result in system crashes or major errors in the application.

By performing acceptance tests on an application, the testing team will deduce how the application will perform in production. There are also legal and contractual requirements for acceptance of the system.

Alpha Testing

This test is the first stage of testing and will be performed amongst the teams (developer and QA teams). Unit testing, integration testing and system testing when combined together is known as alpha testing. During this phase, the following aspects will be tested in the application:

Spelling Mistakes

Broken Links

Cloudy Directions

The Application will be tested on machines with the lowest specification to test loading times and any latency problems.

Beta Testing

This test is performed after alpha testing has been successfully performed. In beta testing, a sample of the intended audience tests the application. Beta testing is also known as pre-release testing. Beta test versions of software are ideally distributed to a wide audience on the Web, partly to give the program a “real-world” test and partly to provide a preview of the next release. In this phase, the audience will be testing the following:

Users will install, run the application and send their feedback to the project team.

Typographical errors, confusing application flow, and even crashes.

Getting the feedback, the project team can fix the problems before releasing the software to the actual users.

The more issues you fix that solve real user problems, the higher the quality of your application will be.

Having a higher-quality application when you release it to the general public will increase customer satisfaction.

Non-Functional Testing

This section is based upon testing an application from its non-functional attributes. Non-functional testing involves testing a software from the requirements which are nonfunctional in nature but important such as performance, security, user interface, etc.

Some of the important and commonly used non-functional testing types are discussed below.

Performance Testing

It is mostly used to identify any bottlenecks or performance issues rather than finding bugs in a software. There are different causes that contribute in lowering the performance of a software:

Network delay

Client-side processing

Database transaction processing

Load balancing between servers

Data rendering

Performance testing is considered as one of the important and mandatory testing type in terms of the following aspects:

Speed (i.e. Response Time, data rendering and accessing)

Capacity

Stability

Scalability

Performance testing can be either qualitative or quantitative and can be divided into different sub-types such as Load testing and Stress testing.

Load Testing

It is a process of testing the behavior of a software by applying maximum load in terms of software accessing and manipulating large input data. It can be done at both normal and peak load conditions. This type of testing identifies the maximum capacity of software and its behavior at peak time.

Most of the time, load testing is performed with the help of automated tools such as Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.

Virtual users (VUsers) are defined in the automated testing tool and the script is executed to verify the load testing for the software. The number of users can be increased or decreased concurrently or incrementally based upon the requirements.

Stress Testing

Stress testing includes testing the behavior of a software under abnormal conditions. For example, it may include taking away some resources or applying a load beyond the actual load limit.

The aim of stress testing is to test the software by applying the load to the system and taking over the resources used by the software to identify the breaking point. This testing can be performed by testing different scenarios such as:

Shutdown or restart of network ports randomly

Turning the database on or off

Running different processes that consume resources such as CPU, memory, server, etc.

Usability Testing

Usability testing is a black-box technique and is used to identify any error(s) and improvements in the software by observing the users through their usage and operation.

According to Nielsen, usability can be defined in terms of five factors, i.e. efficiency of use, learn-ability, memory-ability, errors/safety, and satisfaction. According to him, the usability of a product will be good and the system is usable if it possesses the above factors.

Nigel Bevan and Macleod considered that usability is the quality requirement that can be measured as the outcome of interactions with a computer system. This requirement can be fulfilled and the end-user will be satisfied if the intended goals are achieved effectively with the use of proper resources.

Molich in 2000 stated that a user-friendly system should fulfill the following five goals, i.e., easy to Learn, easy to remember, efficient to use, satisfactory to use, and easy to understand.

In addition to the different definitions of usability, there are some standards and quality models and methods that define usability in the form of attributes and sub-attributes such as ISO-9126, ISO-9241-11, ISO-13407, and IEEE std.610.12, etc.

UI vs Usability Testing

UI testing involves testing the Graphical User Interface of the Software. UI testing ensures that the GUI functions according to the requirements and tested in terms of color, alignment, size, and other properties.

On the other hand, usability testing ensures a good and user-friendly GUI that can be easily handled. UI testing can be considered as a sub-part of usability testing.

Security Testing

Security testing involves testing a software in order to identify any flaws and gaps from security and vulnerability point of view. Listed below are the main aspects that security testing should ensure:

Confidentiality

Integrity

Authentication

Availability

Authorization

Non-repudiation

Software is secure against known and unknown vulnerabilities

Software data is secure

Software is according to all security regulations

Input checking and validation

SQL insertion attacks

Injection flaws

Session management issues

Cross-site scripting attacks

Buffer overflows vulnerabilities

Directory traversal attacks

Portability Testing

Portability testing includes testing a software with the aim to ensure its reusability and that it can be moved from another software as well. Following are the strategies that can be used for portability testing:

Transferring an installed software from one computer to another.

Building executable (.exe) to run the software on different platforms.

Portability testing can be considered as one of the sub-parts of system testing, as this testing type includes overall testing of a software with respect to its usage over different environments. Computer hardware, operating systems, and browsers are the major focus of portability testing. Some of the pre-conditions for portability testing are as follows:

Software should be designed and coded, keeping in mind the portability requirements.

Unit testing has been performed on the associated components.

Integration testing has been performed.

Test environment has been established.

Test Plan

A test plan outlines the strategy that will be used to test an application, the resources that will be used, the test environment in which testing will be performed, and the limitations of the testing and the schedule of testing activities. Typically the Quality Assurance Team Lead will be responsible for writing a Test Plan.

A test plan includes the following:

Introduction to the Test Plan document

Assumptions while testing the application

List of test cases included in testing the application

List of features to be tested

What sort of approach to use while testing the software

List of deliverables that need to be tested

The resources allocated for testing the application

Any risks involved during the testing process

A schedule of tasks and milestones to be achieved

Test Scenario

It is a one line statement that notifies what area in the application will be tested. Test scenarios are used to ensure that all process flows are tested from end to end. A particular area of an application can have as little as one test scenario to a few hundred scenarios depending on the magnitude and complexity of the application.

The terms ‘test scenario’ and ‘test cases’ are used interchangeably, however a test scenario has several steps, whereas a test case has a single step. Viewed from this perspective, test scenarios are test cases, but they include several test cases and the sequence that they should be executed. Apart from this, each test is dependent on the output from the previous test.

Test Case

Test cases involve a set of steps, conditions, and inputs that can be used while performing testing tasks. The main intent of this activity is to ensure whether a software passes or fails in terms of its functionality and other aspects. There are many types of test cases such as functional, negative, error, logical test cases, physical test cases, UI test cases, etc.

Furthermore, test cases are written to keep track of the testing coverage of a software. Generally, there are no formal templates that can be used during test case writing. However, the following components are always available and included in every test case:

Test case ID

Product module

Product version

Revision history

Purpose

Assumptions

Pre-conditions

Steps

Expected outcome

Actual outcome

Post-conditions

Many test cases can be derived from a single test scenario. In addition, sometimes multiple test cases are written for a single software which are collectively known as test suites.

[redactedconcepts]

Load Balancer

Ever wonder how Facebook, Linkedin, Twitter and other web giants are handling such huge amounts of traffic? They don’t have just one server, but tens of thousands of them. In order to achieve this, web traffic needs to be distributed to these servers, and that is the role of a load-balancer.

Readme:

Load-balancing

Load-balancing algorithms

[redactedconcepts]

REST API

REST API is a software architectural style for Backend.

REST = “REpresentational State Transfer”. API = Application Programming Interface

Its purpose is to induce performance, scalability, simplicity, modifiability, visibility, portability, and reliability.

REST API is Resource-based, a resource is an object and can be access by a URI. An object is “displayed”/transferred via a representation (typically JSON). HTTP methods will be actions on a resource.

Example:

Resource: Person (John)

Service: contact information (GET)

Representation:

first_name, last_name, date_of_birth

JSON format

There are 6 constraints:

1. Uniform Interface

Define the interface between client-server

Simple and can be split in small parts

HTTP verbs

GET:

Read representation of a resource or a list of resources

POST:

Create a new resource

PUT:

Update an existing resource

DELETE:

Remove an existing resource

URIs - resource name

A resource representation is accessible by a URI:

GET /users: path for listing all user resources

GET /users/12: path for the user id = 12

GET /users/12/addresses: path for listing all addresses of the user id = 12

POST /users: path for creating a user resource

PUT /users/12: path for updating the user id = 12

DELETE /users/12/addresses/2: path for deleting the address id = 2 of the user id = 12

HTTP Response

In the HTTP Response, the client should verify the information of two things:

status code: result of the action

body: JSON or XML representation of resources

Some important status code:

200: OK

201: created => after a POST request

204: no content => can be return after a DELETE request

400: bad request => the server doesn’t understand the request

401: unauthorized => client user can’t be identified

403: forbidden => client user is identified but not allowed to access a resource

404: not found => resource doesn’t exist

500: internal server error

2. Stateless

The server is independent of the client. The server doesn’t store user client information/state. Each request contains enough context to process it (HTTP Headers, etc.)

Some authentication systems like OAuth have to store information on the server side but they do it with REST API design.

3. Cacheable

All server responses (resource representation) are cacheable:

Explicit

Implicit

Negotiated

Caches are here to improve performances. In a REST API, clients don’t care about the caching strategy, if the resource representation comes from a cache or from a database…

4. Client-Server

REST API is designed to separate Client from the Server. The server doesn’t know who is talking to it. Clients are not concerned with data storage => the portability of client code is improved. Servers are not concerned with the user interface or user state so that servers can be simpler and more scalable

5. Layered System

Client can’t assume direct connection to server. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.

6. Code on Demand (optional)

Server can temporarily:

Transfer logic to client

Allow client to execute logic

Example: JavaScript

[redactedconcepts]

CI/CD

The lean/agile methodology (See: Twelve Principles of Agile Software) is now widely used by the industry and one of its key principles is to iterate as fast as possible. If you apply this to software engineering, it means that you should:

code

ship your code

measure the impact

learn from it

fix or improve it

start over

As fast as possible and with small iterations in days or even hours (whereas it used to be weeks or even months). One big advantage is that if product development is going the wrong direction, fast iteration will allow to quickly detect this, and avoid wasting time.

From a technical point of view, quicker iterations mean fewer lines of code being pushed at every deploy, which allows easy performance impact measurement and easy troubleshooting if something goes wrong (better to debug a small code change than weeks of new code).

Applied to software engineering, CI/CD (Continuous Integration/Continuous Deployment) is a principle that allows individuals or teams to have a lean/agile way of working.

This translates to a “shipping pipeline” which is often built with multiple tools such as:

Shipping the code:

Capistrano, Fabric

Encapsulating the code

Docker, Packer

Testing the code

Jenkins, CircleCi, Travis

Measuring the code

Datadog, Newrelic, Wavefront

[redactedconcepts]

On-Call

Being on-call

(of a person) able to be contacted in order to provide a professional service if necessary, but not formally on duty. “our technicians are on call around the clock” synonyms: on duty, on standby, available “Dr. Merton is on call this evening”

-Google

Users and consumers expect their favorite websites and services to be constantly accessible. Have you ever seen Facebook, Amazon, LinkedIn, Ebay down? Probably not. Any downtime means users frustration and potentially millions of dollars in loss. That’s true for the big players but also for any company where its online presence is crucial, which is the case for a lot of businesses.

This does not happen magically. Software engineers are building reliable systems that are supposed to be up and running 100% of the time, but sometimes things go sideways and the issue needs to be fixed as soon as possible. To achieve quick resolution time, companies are putting in place monitoring systems to detect any anomaly and alert the employee who is on-call. This sometimes happens during working hours, but also at 3am or at night.

Setup

To be on call you need at least 4 components:

A service or website you want to monitor

A monitoring tool

An oncall management system

A software engineer (that’s you)

A service or website you want to monitor

You can monitor thousands of things:

Is my website returning HTTP 200?

Is my website loading in less than 500ms?

Is my webserver daemon up?

Is there more than 50% free disk space on my server?

…

A monitoring tool

You need to configure one or multiple monitoring tool(s) to your on-call system, they are the ones that will actually detect any anomaly and report it to the on-call platform. Check out the Monitoring concept page for recommandations.

A on-call management system

A lot of home tools can be used for that, you can for example in Nagios define on-call periods and then hook this up to a 3rd party service that can send a text message for you. This is fine when you are alone on-call but become very complicated when you have a team. That’s what a company started in 2009 is doing in the Cloud: PagerDuty. It’s a service that allows you to define on-call teams, escalation policies and services integration.

On-call management system flow

Let’s get a bit more into detail about the flow of an on-call management system such as PagerDuty. First of all you have to understand that PagerDuty is not monitoring your website, it acts as a gateway between your monitoring tools and the software engineers that are on-call. Its goal is to alert, as soon as possible, as reliably as possible and as efficiently as possible the person or team on-call. That’s a very hard duty because if PagerDuty goes down then many sites or services going down at the same time won’t be fixed because the alerts won’t reach the on-call persons.

Let’s get into a simple and typical workflow: 1. An incident has been detected by an external monitoring tool that notifies PagerDuty. 2. PagerDuty creates an incident and assigns it to the on-call person, the alert is in a “triggered” mode. 3. The on-call person gets notified and acknowledges the alert meaning that the software engineer is looking into the problem. 4. If the engineer cannot solve the issue, she/he can escalate it (pass it on) to another co-worker. PagerDuty also allows automatic escalation in case the on-call person does not acknowledge the alert (which means that for some reason the on-call person is not available - no battery on the phone, not hearing the ringtone and all sorts of good stuff :-)) 5. A brilliant software engineer (most likely a Holberton School member) solves the issue and marks the incident as solved. Depending on the type of alert and service that notified PagerDuty, it can be auto-resolved.

On-call teams are usually rated on 2 metrics:

MTA (Medium Time to Acknowledgement): The time between an alert/incident is created and an on-call person acknowledged it (which means that he or she is working toward a solution)

MTR (Medium Time to Resolution): The time between an alert/incident being created and this same incident/alert being marked as solved

You obviously want these mean times to be as low as possible. MTA basically tells how good engineers are at answering their phone. MTR basically tells how good engineers are at solving issues.

PagerDuty

We made a partnership so that Holberton School students can utilize PagerDuty for free. For every student a team is created (team of one), we will also have teams for group projects later on.

Every PagerDuty team has an automatically created and linked: - Escalation policy - Services (which are monitoring tools, we can add more services upon demand to Holberton School staff)

We advise you to create accounts with the recommended monitoring tools and to connect them with PagerDuty using the pre-created services.

Also make sure to configure your profile to fill in your contact information and define the Notification Rules