-
Notifications
You must be signed in to change notification settings - Fork 1
thetradinghall website
- General
- Design
- Hugo
- Jamstack
- Chroma
- ImageOptim
- Nodejs
- Caddy server
- Google analytics
- Google Webmaster
- Gooogle tag manager
- Progressive web app
- Forestry
- Licence
- Resources
All materials are gathered in /sysroot/home/development/
CSS3: http://www.w3schools.com/w3css/default.asp
BEM, Block Element Modifier, is a methodology to develop sites which should be launched fast and supported for a long time. It helps to create extendable and reusable interface components.
.block {}
.block__element {}
.block__element_modifier {}
Blocks, elements, and modifiers are all called BEM entities. Blocks can be implemented in one or more technologies, for example:
- behavior — JavaScript, CoffeeScript
- appearance — CSS, Stylus, Sass
- templates — BEMHTML, BH, Jade, Handlebars, XSL
- documentation — Markdown, Wiki, XML.
The main idea of the naming convention is to make names of CSS selectors as informative and clear as possible. This will help make code development and debugging easier and also solve some of the problems faced by web developers
- block-name__elem-name : An element name is delimited by a double underscore
- owner-name_mod-name_mod-val: A modifier name is delimited by a single underscore
A logically and functionally independent page component, the equivalent of a component in Web Components. A block encapsulates behavior (JavaScript), templates, styles (CSS), and other implementation technologies.
Blocks can be nested inside any other blocks. Blocks can be moved around on a page, moved between pages or projects. The implementation of blocks as independent entities makes it possible to change their position on the page and ensures their proper functioning and appearance
A constituent part of a block that can't be used outside of it.
A BEM entity that defines the appearance and behavior of a block or an element.
NAMING CONVENTION methodology overview css Working with BEM entities requires a knowledge of their naming rules.
Ghost white: #f8f8f8; rgb(248, 248, 255)
Blue: rgb(60, 76, 119) rgb(77, 97, 153)
Grey #4C5670 rgb(76,86,112)
slate red: #670133 TTH red : #96031c (150,3,28) TTH_dark_red #7e0116 rgb(126, 1, 22)
blue letter : #90B3E3
vert: #29417
stick to bottom http://www.cssstickyfooter.com/using-sticky-footer-code.html
Starts with the small-screen styles and layers on the styles for larger widths, rather than beginning with larger-width styles and nullifying them for smaller screens.
“content first, navigation second.”
It’s my belief that in order to embrace designing native layouts for the web – whatever the device – we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out. it should be the content that dictates the media queries.
Vertical Navigation Bar. Options: Always display the navigation pane to the left of the page content. Use a collapsible, "fully automatic" responsive side navigation. Shift the page content to the right, when opening the navigation pane.
Animated Sidenav Example
W3.CSS provide the following animation classes:
In grid layout, the content of a grid container is laid out by positioning and aligning it into a grid. The grid is an intersecting set of horizontal and vertical grid lines that divides the grid container’s space into grid areas, into which grid items (representing the grid container’s content) can be placed. There are two sets of grid lines: one set defining columns that run along the block axis (the column axis), and an orthogonal set defining rows along the inline axis (the row axis). [CSS3-WRITING-MODES]
The capabilities of grid layout address these problems. It provides a mechanism for authors to divide available space for layout into columns and rows using a set of predictable sizing behaviors. Authors can then precisely position and size the building block elements of their application into grid areas defined by the intersection of these columns and rows. By combining grid layout with media queries, rearrange the layout of elements independent of their source order, to achieve the desired layout in both orientations
Unsemantic is a fluid grid system that is the successor to the 960 Grid System. It works in a similar way, but instead of being a set number of columns, it's entirely based on percentages.
inline-block (better than using floats). Floats were originally used for wrapping text, and as such, they can play up when used to align elements. The most well-known issue is that non floated elements don’t recognise floated children. This is due to floated elements being removed from the normal flow of the document.
With inline-block, you can create a grid of boxes that fills the browser width and wraps nicely. This has been possible for a long time using float , but now with inline-block it's even easier. inline-block elements are like inline elements but they can have a width and height. It has been possible for a long time to create a grid of boxes that fills the browser width and wraps nicely (when the browser is resized), by using the float property.
However, the inline-block value of the display property makes this even easier.
inline-block elements are like inline elements but they can have a width and a height.
When using Responsive Grids, you can control how the grid behaves at specific breakpoints by adding class names. Pure's default responsive grids comes with the following class names and media query breakpoints.
SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.
Bitter: Motivated by my love for the pixel I designed Bitter. A "contemporary" slab serif typeface for text, it is specially designed for comfortably reading on any computer or device. The robust design started from the austerity of the pixel grid, based on rational rather than emotional principles. It combines the large x-heights and legibility of the humanistic tradition with subtle characteristics in the characters that inject a certain rhythm to flowing texts.
Hugo is a popular open-source static site generators written in Golang.
There is a rpmpackage for Fedora to install from CLI.
Hugo’s CLI scaffolds a project directory structure and then takes that single directory and uses it as the input to create a complete website. Running the hugo new site
generator from the command line will create a directory structure with the following elements:
├── archetypes
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes
- archetypes: here we define what our content is, we can set default tags or categories and define types such as a post, tutorial or product here
- config.toml: main configuration is in here, we can define all of the websites title, language, urls etc here
- content: the content pages of the site are stored here, sub directories are used for sections to help organize the content, create a content/products for your products content for example
- data: Site data such a localization configurations go here
- layouts: layouts for the Go html/template library which Hugo utilizes go here
- static: Any static files here will be compiled into the final website, total freedom is allowed so you can serve any css,js or image file for example.
- themes: Create new themes or clone themes from github into this directory to use them with your site.
Copy the theme in themes/
directory.
Everything is gathered in /var/home/development/hugo
and the configuration file is /var/home/gabx/.config/hugo/config.toml
. An alias to hugo
command has been created to take into account the file emplacement.
The user can choose to override that default with one or more site config files using the command line --config
switch.
Config file example, config.toml
:
baseURL = "https://yoursite.example.com/"
footnoteReturnLinkContents = "↩"
title = "My Hugo Site"
[params]
AuthorName = "Jon Doe"
GitHubUser = "spf13"
ListOfFoo = ["foo1", "foo2"]
SidebarRecentLimit = 5
Subtitle = "Hugo is Absurdly Fast!"
[permalinks]
post = "/:year/:month/:title/"
NOTE: we use the TOML language to write the configuration file, but Hugo accept .json
and .yaml
.
Hugo use pretty url.
Example:
content/posts/_index.md
=> example.com/posts/index.html
content/posts/post-1.md
=> example.com/posts/post-1/
Hugo uses blackfriday markdown processor.
This is done with editing the config.toml
file.
-
% hugo help
displays all basic commands -
% hugo
renders your site intopublic/
dir and is ready to be deployed to your web server -
% hugo server -t MyTheme -w -D
run a fully functioning web server while simultaneously watching your file system for additions, deletions, or changes. To use directly the command in production, adddisableLiveReload = true
in config file, or runhugo server --watch=false
.
After running hugo server
for local web development, you need to do a final hugo
run without the server part of the command to rebuild your site. You may then deploy your site by copying the public/
directory to your production web server.
To start a server that builds draft content, specify a different directory: % hugo server -wDs hugo/docs -d dev
-d
is for destination, -w
for watch for changes, -s
forsource, -D
for includent content marked as draft.
When the content is ready for publishing, use the default public/
dir:
% hugo -s hugo/docs
When running hugo new
, Hugo create new content files with date
,title
and draft=true
. You can create your own archetypes with custom preconfigured front matter fields as well.
Running hugo new posts/myPost.md
will create a new content file in content/posts/myPost.md
using the first archetype filefound in this order:
archetypes/posts.md
archetypes/default.md
themes/my-theme/archtypes/posts.md,default.md
You can create as many archetypes as you want. When you run hugo new
, just specifie the archetype this way:
% hugo new MyArchetype/MyPost.md
Now edit the file in content/post/MyPost.md
, it will contain something similar to the following by default:
+++
date = "2016-09-26T13:19:03+07:00"
title = "first post"
draft = true
+++
The content inside +++
is the TOML configuration for the post. This configuration is called front matter. It enables you to define post configuration along with its content. By default, each post will have the configuration properties shown above.
the layout Hugo should select from the lookup order when rendering the content. If a type is not specified in the front matter, Hugo will look for the layout of the same name in the layout directory that corresponds with a content’s section. See “Defining a Content Type”
Without any additional configuration, the following will just work:
└── content
└── about
| └── _index.md // <- https://example.com/about/
├── post
| ├── firstpost.md // <- https://example.com/post/firstpost/
| ├── happy
| | └── ness.md // <- https://example.com/post/happy/ness/
| └── secondpost.md // <- https://example.com/post/secondpost/
└── quote
├── first.md // <- https://example.com/quote/first/
└── second.md // <- https://example.com
A Section is a collection of pages that gets defined based on the organization structure under the content/
directory. By default, all the first-level directories under content/
form their own sections (root sections). If a user needs to define a section foo
at a deeper level, they need to create a directory named foo
with an _index.md
file
Example:
content
└── blog <-- Section, because first-level dir under content/
├── funny-cats
│ ├── mypost.md
│ └── kittens <-- Section, because contains _index.md
│ └── _index.md
└── tech <-- Section, because contains _index.md
└── _index.md
Hugo supports sites with multiple content types and assumes your site will be organized into sections, where each section represents the corresponding type.
Hugo assumes that your site will be organized into sections and each section represents a corresponding type. This is to reduce the amount of configuration necessary for new Hugo projects.
If you are taking advantage of this default behavior, each new piece of content you place into a section will automatically inherit the type. Therefore a new file created at content/posts/new-post.md
will automatically be assigned the type posts. Alternatively, you can set the content type in a content file’s front matter in the field “type
”.
The following examples take you stepwise through creating a new type layout for a content file that contains the following front matter:
content/events/my-first-event.md
+++
title = My First Event
date = "2016-06-24T19:20:04-07:00"
description = "Today is my 36th birthday. How time flies."
type = "event"
layout = "birthday"
+++
NOTE :
By default, Hugo assumes *.md
under events
is of the events
content type. If you do not specifically declare content types in your front matter or develop specific layouts for content types, Hugo is smart enough to assume the content type from the file path and section.
Create a directory with the name of the type in /layouts
. For creating these custom layouts, type is always singular; e.g., events
=> event
and posts
=> post
.
_index.md
Go templates provide an extremely simple template language that adheres to the belief that only the most basic of logic belongs in the template or view layer. Go templates are HTML files with the addition of variables and functions. Go template variables and functions are accessible within {{ }}
.
- variable :
{{ foo }}
- function:
{{ add 1 2 }}
. Parameters are separated by space. - methods and fields:
{{ .Params.bar }}
. Access the bar parameterof a page. - parentheses are used for groups:
{{ if or (isset .Params "alt") (isset .Params "caption") }} Caption {{ end }}
This is how you access a Page
variable from a template:
<title>{{ .Title }}</title>
When including another template, you will need to pass it the data that it would need to access. The templates location will always be starting at the layouts/
directory within Hugo.
NOTE: to pass along the current context, please remember to include a trailing dot.
The partial function is used to include partial templates using the syntax {{ partial "<PATH>/<PARTIAL>.<EXTENSION>" . }}
.
Example:
{{ partial "header.html" . }}
Hugo use the range
function
{{range $index, $element := array}}
{{ $index }}
{{ $element }}
{{ end }}
if
, else
, with
, or
, and and
provide the framework for handling conditional logic in Go Templates. Like range, each statement is closed with an {{end}}
.
The most easily overlooked concept to understand about Go templates is that {{ . }}
always refers to the current context. In the top level of your template, this will be the data set made available to it. Inside of an iteration, however, it will have the value of the current item in the loop; i.e., {{ . }}
will no longer refer to the data available to the entire page.
Example of variable independent of context:
{{ $title := .Site.Title }}
<ul>
{{ range .Params.tags }}
<li>
<a href="/tags/{{ . | urlize }}">{{ . }}</a>
- {{ $title }}
</li>
{{ end }}
</ul>
$
has special significance in your templates. $
is set to the starting value of .
(“the dot”) by default.
This means you have access to the global context from anywhere. Here is an equivalent example of the preceding code block but now using $
to grab .Site.Title
from the global context:
<ul>
{{ range .Params.tags }}
<li>
<a href="/tags/{{ . | urlize }}">{{ . }}</a>
- {{ $.Site.Title }}
</li>
{{ end }}
</ul>
Go 1.6 includes the ability to trim the whitespace from either side of a Go tag by including a hyphen (-)
and space immediately beside the corresponding {{
or }}
delimiter.
For instance, the following Go template will include the newlines and horizontal tab in its HTML output:
<div>
{{ .Title }}
</div>
Which will output:
<div>
Hello, World!
</div>
Leveraging the -
in the following example will remove the extra white space surrounding the .Title
variable and remove the newline:
<div>
{{- .Title -}}
</div>
Which then outputs:
<div>Hello, World!</div>
Go templates support {{/*
and */}}
to open and close a comment block. Nothing within that block will be rendered.
The base and block constructs allow you to define the outer shell of your master templates.
The lookup order for base templates is as follows:
/layouts/section/<TYPE>-baseof.html
/themes/<THEME>/layouts/section/<TYPE>-baseof.html
/layouts/<TYPE>/baseof.html
/themes/<THEME>/layouts/<TYPE>/baseof.html
/layouts/section/baseof.html
/themes/<THEME>/layouts/section/baseof.html
/layouts/_default/<TYPE>-baseof.html
/themes/<THEME>/layouts/_default/<TYPE>-baseof.html
/layouts/_default/baseof.html
/themes/<THEME>/layouts/_default/baseof.html
As an example, let’s assume your site is using a theme called “mytheme” when rendering the section list for a post section. Hugo picks layout/section/post.html
as the template for rendering the section. The {{define}}
block in this template tells Hugo that the template is an extension of a base template.
Here is the lookup order for the post base template:
/layouts/section/post-baseof.html
/themes/mytheme/layouts/section/post-baseof.html
/layouts/post/baseof.html
/themes/mytheme/layouts/post/baseof.html
/layouts/section/baseof.html
/themes/mytheme/layouts/section/baseof.html
/layouts/_default/post-baseof.html
/themes/mytheme/layouts/_default/post-baseof.html
/layouts/_default/baseof.html
/themes/mytheme/layouts/_default/baseof.html
The following defines a simple base template at _default/baseof.html
. As a default template, it is the shell from which all your pages will be rendered unless you specify another *baseof.html
closer to the beginning of the lookup order.
layouts/_default/baseof.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>{{ block "title" . }}
<!-- Blocks may include default content. -->
{{ .Site.Title }}
{{ end }}</title>
</head>
<body>
<!-- Code that all your templates share, like a header -->
{{ block "main" . }}
<!-- The part of the page that begins to differ between templates -->
{{ end }}
{{ block "footer" . }}
<!-- More shared code, perhaps a footer but that can be overridden if need be in -->
{{ end }}
</body>
</html>
From the above base template, you can define a default list template. The default list template will inherit all of the code defined above and can then implement its own "main" block from:
layouts/_default/list.html
{{ define "main" }}
<h1>Posts</h1>
{{ range .Pages }}
<article>
<h2>{{ .Title }}</h2>
{{ .Content }}
</article>
{{ end }}
{{ end }}
This replaces the contents of our (basically empty) “main” block with something useful for the list template. In this case, we didn’t define a "title" block, so the contents from our base template remain unchanged in lists.
Hugo does not come with a default theme, so you must set one.
To create a new theme, run hugo new theme MyTheme
.We have created a tth
theme from scratch. To install a themefrom Hugo gallery:
% cd themes
% git clone URL_TO_THEME
% rm -r THEME/.git
This can be done:
- via CLI,
hugo -t MyTheme
orhugo server -t MyTheme
- editing the configuration file:
theme: MyTheme
TTH theme is based on hyde, Port of Mdo's theme to Hugo. Hyde is a brazen two-column hugo theme based on the Jekyll theme of the same name. It pairs a prominent sidebar with uncomplicated content.
To create a new post, run % hugo new posts/first-post.md
The post consists of two sections. The first one is separated by +++. It contains metadata about your post, such as its title. In Hugo, this is called front matter. After the front matter, the article begins.
NOTE: its content is done whith editing the hugo/themes/MyTheme/theme.toml
file.
% cat content/posts/first-post.md
---
title: "First Post"
date: 2018-08-05T17:24:13+02:00
draft: true
keywords: []
description: ""
tags: []
categories: []
author: ""
---
Netlify can host your Hugo site with CDN, continuous deployment, 1-click HTTPS, an admin GUI, and its own CLI.
https://gohugo.io/hosting-and-deployment/deployment-with-wercker/
https://github.com/mindok/hugodeploy
Jamstack is a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.Your project is built with the JAMstack if it meets three key criteria:
- Javascript: Any dynamic programming during the request/response cycle is handled by JavaScript, running entirely on the client. This could be any frontend framework, library, or even vanilla JavaScript.
- APIs: All server-side processes or database actions are abstracted into reusable APIs, accessed over HTTP with JavaScript. These can be custom-built or leverage third-party services.
- Markup: Templated markup should be prebuilt at deploy time, usually using a site generator for content sites, or a build tool for web apps.
TTH website will stick to Jamstack best practices
- Hugo
- npm
- Google Analytics
- Netlify
- GitHub
Chroma is a general purpose syntax highlighter in pure Go. Chroma takes source code and other structured text and converts it into syntax highlighted HTML, ANSI-coloured text, etc.
A convenience function exists that can be used to simply format some source text, without any effort:
err := quick.Highlight(os.Stdout, someSourceCode, "go", "html", "monokai")
ImageOptim makes images load faster.
Yarn package manager replace Bower.
First install repo on Fedora: curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo
.
Install nodejs
then yarn
To start a project, cd project directory and then run yarn init
. You will answer a few questions then a package.json
fileis created with basic info.
- add package:
yarn add [package]
. This will create a directory callednode_modules
with packages inside. - install/update all dependencies:
yarn install
All commands can be found here
Caddy is the HTTP/2 web server with automatic HTTPS.
Search Engine Optimization (SEO) Starter Guide
Track your site's search performance with Google Search Console
https://marketingplatform.google.com/about/tag-manager/
Progressive web apps are experiences that combine the best of the web and the best of apps. They are useful to users from the very first visit in a browser tab, no install required. As the user progressively builds a relationship with the app over time, it becomes more and more powerful. It loads quickly, even on flaky networks, sends relevant push notifications, has an icon on the home screen, and loads as a top-level, full screen experience.
Follow this Google tutorial to create your first web app.
A static CMS that commits https://forestry.io/#/
The SPDX License List is a list of commonly found licenses and exceptions used in free and open source and other collaborative software or documentation. The purpose of the SPDX License List is to enable easy and efficient identification of such licenses and exceptions in an SPDX document, in source files or elsewhere.
Creative Commons Attribution Non Commercial 4.0 International with short identifier CC-BY-NC-4.0