Blog

Notes on Course: Microsoft – Advanced CSS Concepts

My notes on the great course Microsoft – Advanced CSS Concepts on edx.

Lesson 01

Responsive Layout

Covers the basics of Responsive Layout.
In essence you use the @media query to figure out what
the width, height, page orientation and resolution of the device is.
Then based on that information you use a different CSS Rule.

To create a consistent Layout you should always design for the smallest device screen – then expand it to the bigger devices.
(Mobile First Strategy).

Base CSS

In General you should use a Style guide to create a consistent look
across your application. They are usually created by the graphic designer.

Typically a website should be suitable for all different types of browsers.
However the CSS implementation and the default styles are different across browsers.
To avoid this problem, you can include a CSS Reset – to ensure a consistent style.

A front end Style guide should help define
* Code standardization of CSS, and HTML
* Consistency of code and design
* More efficient workflow
* Documenting of code practices
* An easy-to-access reference for code and design for new team members

Your style guide will be comprised of:

  • A template: The template contains the basic elements that serve as the foundation for your web page, such as color palette, fonts, headers, footers, body text, navigation, widgets, and grid layouts.
  • Patterns: The patterns for your web page include buttons, logos, images, the font icon library, and form styles.
  • Documentation: The documentation is a record of the style and development pattern of your web page. You can add comments in your code that serve as the style guide or use interactive modals or tool tips.

Media Queries

The most commonly used media queries are:

  • min-width Rules applied for any browser width over the value defined in the query
  • max-width Rules applied for any browser width below the value defined in the query
  • min-height Rules applied for any browser height over the value defined in the query
  • max-height Rules applied for any browser height below the value defined in the query
  • orientation:portrait Rules applied for any browser where the height is greater than or equal to the width
  • orientation:landscape Rules for any browser where the width is greater than the height

The Query information is then used to define breakpoints, points where the layout switches from one size to another.
Example of a set of major device breakpoints:

/* Extra small devices (phones, up to 480px) */
@media screen and (max-width: 767px) {…}

/* Small devices (tablets, 768px and up) */
@media (min-width: 768px) and (max-width: 991px) {…}

/* tablets/desktops and up */
@media (min-width: 992px) and (max-width: 1199px) {…}

/* large like desktops and up */
@media screen and (min-width: 1200px) {…}

Units

Historically the “px” Unit was used, however to incorporate various resolutions it is better to use the “rem” unit.

Going forward

  • Optimize the text for reading
  • Use major device breakpoints, and address content with minor breakpoints
  • Treat your website’s layout as an enhancement
  • Use relative units like rem or em;

Working with images

Images should be resampled to three different media sizes

Note: The alt tag must be set to correctly validate.

Lesson 02

Modular CSS

Modular CSS is:

  • A guideline based approach for breaking down pages into generic reusable CSS code.
  • Based on classes and consistent naming conventions.
  • Easy to read and maintain by teams.

CSS Modules are:

  • Generic, self-contained, and reusable.
  • Modifiable, combinable, and scalable.
  • Can contain or be contained by other modules but stay independent.

What are some common modules?

You will often come across modules such as these:

Example Module

What are the Results of a Module Based Approach?

  • Faster development
  • Flexible and scalable code
  • Code reuse
  • Organized and easy to read code
  • Easier to maintain
  • Team efficiency
  • Decoupled HTML and CSS

Guidlines

  1. OOCSS (Object Oriented CSS) | http://oocss.org/
  2. SMACSS (Scalable and Modular Architecture for CSS) | https://smacss.com/
  3. BEM (Block, Element, Modifier) http://getbem.com/
  4. DRY (Don’t Repeat Yourself CSS)

Font Awesome

A popular set of icon fonts is Font Awesome (http://fontawesome.io/)

Example for a like button

Posted by happyneal in Blog, Web Technologies, 0 comments

Web Tooling and Automatisation using gulp 4

Now working with Gulp you will discover that you run into a couple of minor problems. Especially in sequencing the different types of tasks.
Lets take a simple clean task, it should run before all of the other tasks. However Gulp will run all tasks in parallel.

The team that is working on Gulp has been working on a solution for this problem and in Gulp 4.0 we will get gulp.series() and gulp.parallel(); to distinguish between these two types of operations.

Sadly it looks like that currently the release of Gulp 4.0 is delayed. However you can use the current Alpha version prior to its release.

Installing Gulp 4

You can simply install the next version of Gulp with NPM (A git client is required, as the package is not in the npm repository and will be cloned from Github)

Updating the gulpfile.js

The syntax for tasks has changed, so we need to rewrite parts of the file:
Our exisiting Gulp 3 task

Needs to be rewritten with gulp parallel as such:

However we should not stop there and improve upon this task, by running the clean task before all of the other tasks. To ensure that it runs before the other tasks we use gulp.series().

Improving on the production flag

With gulp.series() we now can stop using the –production flag. We simply define a production task.

As first operation we pass in a function that simply sets the production boolean to true:

The function uses “done” to signal gulp that the function has completed.

Hiding Tasks

Another improvement of Gulp 4.0 is that you can pass functions, as well as tasks to gulp.series and gulp.parallel.

This in turn lets you write normal functions that are hidden from the command line, ensuring that everybody on the project runs the default build task instead of only the html task.

Here is now our improved Gulpfile.js:

Package.json

Posted by happyneal in Blog, Web Technologies, 0 comments

Continuous Integration (CI) for Gitbook using Gitlab and Gulp

Gitbook is a static site generator, that converts a collection of Markdown files into a HTML Site. Alternatively it can also convert the markdown files into a PDF or ebook.
If you are not writing a book, it is also a great tool to create a quick documentation for a project you are working on.

Initial set up

We will need gitbook. Gitbook does not automatically generate a SUMMARY.md file, however there is an existing gitbook-summary tool to take care of that.

Gulp will be our taskrunner.

I will deploy to my server via FTP. Since you are only serving HTML Files, there is usually no need for server restart etc.
To integreate it into Gulp I will be using vinyl-ftp.

Gulp

Create a file called gulpfile.js and define your gulp tasks.

You should test especially the “deploy” task locally if everything is working correctly.

Gitlab CI Integration

You need to create a YAML File called .gitlab-ci.yml. Gitlab will recognise the file and run the commands in it.

That’s it. If you push something into the master branch, it will automatically run the commands in the yaml file and deploy your static website to your server.
When the build completes, you will recieve an email, telling you if everything went as planned.

Posted by happyneal in Blog, Web Technologies, 0 comments

CodeWars Kata: File Path Operations

The quick Code Wars Kata I am taking a look at the Kata File-Path-Operations.

My approach to solving the kata was, first to figure out what skills are needed to solve the problem. Since all three problems are similar and try to find a specific pattern in a string, the obvious answer is: Regular Expressions.

The fastest way to learn, create and test your Regular Expressions is using Regex 101.

I solved the Kata using Typescript and this is my final code:

This piece of code would not be suitable for production. It does not take into account of malformed filenames, it would not work for windows;
It would have problems with folders that contain a “.” etc.

If you would be using NodeJS you would use the existing functions in the Path Module.

Posted by happyneal in Blog, Programming, Typescript, 0 comments
Elementary OS: Things to do after installing Elementary OS 0.4 (Loki)

Elementary OS: Things to do after installing Elementary OS 0.4 (Loki)

When you start out with elementary OS there are a couple of useful things that you should do to have  a better experience working with your system.

General

“Software & Updates” for Additional Drivers

The easiest way to install the proprietary NVidia Drivers (in Ubuntu) is to go to System Settings > Additional Drivers and then simply select the driver.

This option is not available in Elementary. However by installing the package software-properties-gtk you can get the program.

sudo apt install -y software-properties-gtk

Now by clicking on Applications on the top right, and then type
“Software & Updates” you can access the Settings.

Easy way to add PPA

With the command line tool add-apt-repository you have a quick way to add additional PPA’s. To get this tool you need to install the package

sudo apt-get install software-properties-common

Add a Minimize Button to Windows

Some of the Elementary Windows do not have an easy way to minimize the window.  With Elementary Tweaks you can add a button to the windows.

Officially the elementary team does not encourage users to use the tweaking tool, since it also exposes switches to functionality that could mess up your system, so use the tool with caution.

sudo add-apt-repository ppa:philip.scott/elementary-tweaks
sudo apt install elementary-tweaks

Microsoft Font Compatability

sudo apt-get install ttf-mscorefonts-installer

Replace Screenshot tool

sudo apt remove screenshot-tool
sudo add-apt-repository ppa:shutter/ppa
sudo apt-get update && sudo apt-get install -y shutter

Chrome

wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list'
sudo apt-get update
sudo apt-get install google-chrome-stable

Skype

wget https://go.skype.com/skypeforlinux-64-alpha.deb
sudo dpkg -i skypeforlinux-64-alpha.deb

Office

sudo apt install libreoffice

Graphic Editors

sudo apt install gimp inkscape shutter

Video

Video Lan

sudo apt install -y vlc

Codecs

sudo apt-get install ubuntu-restricted-extras ffmpeg

Other

Redshift

A simple program to prevent Eye Strain

sudo apt install redshift gtk-redshift

Laptop Battery Saver

sudo apt install tlp tlp-rdw

Last Steps

Remove Programs

sudo apt remove pantheon-mail -y
sudo apt remove maya-calendar -y
sudo apt remove epiphany-browser -y
sudo apt remove audience -y

Update your system

sudo apt-get update && sudo apt-get dist-upgrade

Posted by happyneal in Blog, Linux, 0 comments
Notes on MITx: 6.005.1x Software Construction in Java (Week 2)

Notes on MITx: 6.005.1x Software Construction in Java (Week 2)

This week the course is covering another two very important topics: Testing and Specifications.

LECTURE 3: Testing

Testing is a very important part of creating functionally correct programs.

Testing will be always incomplete

You will try to test your program using three methods:

  1. Formal Reasoning, essentially you manually verify that your program works correctly
  2. Code Review: Another Programmer takes a look and says everything is ok.
  3. Test Suites: Essentially you write another program (which can have its own bugs) to test your program. You define the inputs and the expected output and compare them.

The course mentions again the residual defect rates of 1-10 defects/kloc(1000 lines of code). Again this does not cite where this number actually comes from. Especially when using Industry Standards and Test Suites this high number would drastically drop to an much lower number. However in the end it only would remain to be an assumption since the actual number cannot be determined.

You testing your program for every possible input (Exhaustive testing) is not feasible. The strategy to simply take a look and see if it works (Haphazard testing) will also not reveal all bugs. The same is true for “Random” testing. All of these test methods cannot be used to test software.

Write Tests

When you are writing tests you should think about how you can make your program fail. Test drive development takes the following approach.

  1. Specify what you want to program
  2. Write tests that would test the specification
  3. Write code so that your code passes the tests

The specification is key to define what inputs are possible and which outputs will be produced. (This also includes throwing errors)

Blackbox testing only focuses on the input and output of the function. These tests do not take into account how the algorithm actually works.

The alternative is Whitebox testing takes into account how the program is implemented.

Test Coverage

Now that you have written tests for all of your code, did you also test all of your code? Coverage takes a look at if all Statements and all possible paths through your code are covered.

There are various Code coverage tools available that you can run and then visually see which part of the code is covered by your tests.

In reality you should try to achieve a coverage of 70-90% of your code achieving 100% is usually not possible due to time constraints. Of course this is not the case if you are using Test Driven Development.

Running Tests

Usually you would create a Testsuite of Unit Tests. You should integrate these tests into your build process to ensure that the tests run automatically. Especially when you modify existing code this will ensure that your modifications will not accidentally break something unintentionally.

When working with multiple people you should add hooks to your git repository that it rejects code that does not pass your test suite.

 

LECTURE 4: Specifications

This lecture is going to cover preconditions and post-conditions in method specifications, and how to write correct specifications.

What is a specification?

The lecture defines a specification primarily only concerning how the interfaces are defined and how the specification document essentially is used as communication device to talk to the client.

Now this actually assumes that the client is another programmer that wants the module/system to do a specific functionality. In my work experience usually the client has no technical background and expects the programmer to know what he wants.  Yes the specification is the key document on how to negotiate which features etc. the client requires, it is however not exactly defined which functions or how interfaces should be created, this is usually the task of the programmer.

The course actually is more talking about a documentation document how and which interfaces exist in the code you are programming for the client. The documentation is key whenever other programmers need to use the code you have programmed.

In either case, the specification document is a key document. It defines the work that needs to be done. The document shields the programmer from the client, if the client forgot to specify something, thus the programmer did not implement it he can prove it was the clients fault. At the same time the programmer is bound to the document that he actually implements all features. (or negotiates, talks with the client that the functionality is unfeasible, or not possible to be implemented)

Pre and Post Conditions

For each function you require the preconditions (what inputs) and postconditions (what outputs).

The inputs may have to have a specific structure, cannot be a certain value etc. These need to be checked.

The function also will have various outputs. This is of course the result, and how the result should be structured, the method also can throw errors.

Write test cases

Essentially if the specification of the function is well defined it is very easy to write the test cases. You simply follow the specification write tests to get the expected correct results and willfully pass wrong arguments into the function.

The rest of the lecture covers how to throw Exceptions. Which to use when.

HOMEWORK

Again another batch of “Java Tutor” exercises. They were as exciting as the last batch…

However this time they also provided a “warm up” problem set. The warm up is just to implement the mathematical “quadratic roots formula”.

The straightforward implementation of the formula will not pass all the Unit Tests. You need to take a deeper look at Java to actually figure out why the last Unit Test fails, and how you can change your code to make your code pass the test.

Posted by happyneal in Blog, Java, 0 comments