WFH part 2

image of man working from home office computer
Part 2

How to Make Working from Home
Work Better for You

It’s important to start by stressing that there’s no one right or wrong way to establish your work from home practices and environment. What works for some people may not work for others. Some people like utter silence, while others thrive in a buzzing atmosphere. It’s also worth noting that it can take some time to fall into a groove with working from home. If it feels unnatural or awkward at first, don’t be surprised – this is the stage where many prematurely decide working from home isn’t for them. Small changes can make a significant difference in the quality of your experience though, and any effort you put toward improving that experience is well spent. It’s equally important for employers to grant employees who are new to remote
work a little extra slack as they learn the ropes. As you embark together on this WFH journey, please remember to show some extra patience for technical difficulties, kids or pets in the background, and a little general disarray at first.
It will get better. With that in mind, I’m going to cover a broad range of strategies, tips, and techniques for getting your best work done at home.

GIT part-2 Concepts and architecture


Git uses three-tier tree architecture for its repository’s files and commits, which is very handy. The illustration (a) below shows a typical two-tier tree set up which other version control systems use. The working depository is a root folder, which you have set up on your computer too manage your files this is done through setting up a root folder navigating to it through the command line and then initialising it as a repository i.e. git – init

When we wish to receive files i.e. clone or fork a repository we check it out from the repository into our working repository or copy.
When we wish to make changes or send files to the repository we call it a commit.
The reason we have two different repositories is that the files don’t have to be the same when you make changes to your working copy, you save them and they are saved on your hard drive, both different copies are saved, and until you choose to…. You can commit those changes to the repository. If the repository is a shared one there can be many different people working on it.


Three Tree architecture

As I mentioned earlier Git uses a three-tier tree, which adds another area called a staging area. See illustration b) This allows us to have 10 different files in our working directory (for example) and allows us to prepare five which we wish to add to our staging index in preparation for a commit. When we are happy we commit those five files with a message to our repository where git will track it.
Conversely we can pull or checkout our files to our working directory or staging index. more often than not you will pull them straight to your working directory.

What is GIT?

Octocat GIT

Understanding version control

Git is software for keeping track of  changes in files and directories , particularly text changes. Git gives you the ability to store (for example)
three different versions and allows you to compare different versions, move between different versions, and control them. This is referred to as a Version control system or VCS. Git was not the first version control system by any means, but all have been designed with the purpose of tracking computer code. They wanted to be able to track changes over time fix bugs and update source code. Ninety Five percent of VCS is used to track source code  hence the name, source code management or SCM, these terms are almost interchangeable. You may well of as a designer, used non source code version control to name files like Budget_4.xls, or logo_v2.png so that you can keep track of changes over time. You have done this by changing the text at the end of the file. Think of the History palette in Photoshop this palette shows each change you have made to your file and allows you to view your image at different stages. You can even roll back your image to an earlier time, this is a primitive example of  version control.

URL Types

When attaching an external JavaScript file to a web page, you need to specify a URL for the src attribute of the <script> tag.  A URL or Uniform Resource Locator is a path to a file—like another web page, a graphic, or a JavaScript file—located on the Web. There are three types of paths:

  • absolute path
  • rootrelative path
  • document-relative path

All three indicate where a web browser can find a particular file.  An absolute path is like a postal address–it contains all the information needed for a web browser located anywhere in the world to find the file.  An absolute path includes http://, the hostname, and the folder and name of the file.  For example:  A root-relative path indicates where a file is located relative to a site’s top-level folder–the site’s root folder.  A root-relative path doesn’t include http:// or the domain name. It begins with a / (slash) indicating the site’s root folder–the folder the home page is in. For example, /scripts/site.js indicates that the file site.js is located inside a folder named scripts, which is itself located in the site’s top-level folder. An easy way to create a root-relative path is to take an absolute path and strip off the http:// and the host name. For example, written as a root-relative URL is just /index.html.

A document-relative path specifies the path from the web page to the JavaScript file. If you have multiple levels of folders on your website, you’ll need to use different paths to point to the same JavaScript file. For example, suppose you have a JavaScript file named site.js located in a folder named scripts in your website’s main directory. The document-relative path to that file will look one way for the home page–scripts/site.js–but for a page located inside a folder named about, the path to the same file would
be different; ../scripts/site.js–the ../ means climb up out of the about folder, while the /scripts/site.js means go to the scripts folder and get the file site.js.

Here are some tips on which URL type to use:

  • If you’re pointing to a file that’s not on the same server as the web page, you must use an absolute path. It’s the only type that can point to another website.
  • Root-relative paths are good for JavaScript files stored on your own site. Because they always start at the root folder, the URL for a JavaScript file will be the same for every page on your website, even when web pages are located in folders and sub folders on your site. However, root-relative paths don’t work unless you’re viewing your web pages through a web server—either your web server out on the Internet, or a web server you’ve set up on your own computer for testing purposes. In other words, if
    you’re just opening a web page off your computer using the browser’s File→ Open command,  the web browser
    won’t be able to locate, load, or run JavaScript files that are attached using a root-relative path.
  • Document-relative paths are the best when you’re designing on your own computer without the aid of a web server. You can create an external JavaScript file, attach it to a web page, and then check the JavaScript in a web browser simply by opening the web page off your hard drive. Document-relative paths work fine when moved to your actual, living, breathing website on the Internet, but you’ll have to rewrite the URLs to the JavaScript file if you move the web page to another location on the server.

Material Design- Materialize

Created and designed by Google, Material Design is a design language that combines the classic principles of successful design along with innovation and technology. Google’s goal is to develop a system of design that allows for a unified user experience across all their products on any platform. check out specs here ;


Developed by a crew of students Materialize is a framework  (similar to bootstrap ) using Material design see I would be interested in other people’s thoughts and experience with it.