We believe 2019 saw our most successful web design and development competition ever. We held this in Louisville, KY, during the last week of June. Our competition is one of 103 individual competitions at SkillsUSA Nationals. Competitors must win first place in their respective states for the opportunity to compete nationally. We also choose one winner from these competitions to represent the US at WorldSkills. That competition is held every two years (and the next will happen this August in Kazan, Russia).
Our on site team
We are so appreciative of the massive efforts by so many members of Web Professionals to make this competition a reality. We have our team on site for almost an entire week. They conduct the interviews of competitors (and these mimic real interviews as many of the individuals conducting the interviews hire web professionals as part o their daily jobs. They also review the process each team follows as they provide solutions to the business problems posed in our competition work order. They also make certain the server and network environment is running smoothly and that all tams can access their individual server, cloud storage, and editor. This can be a particular challenge when some teams bring school computers which have been so locked down one can not even access the Windows Control Panel. Our team also develops the competition project/ work order and configures the environment before the competition. We are so thankful for all the help and could not do it without you.
Our judges
We run two separate competitions (Wednesday is for high school students). We had 52 individuals competing this year. Our Thursday competition is for college students. We had 20 individuals competing this year. When the competition ends each day, we transfer all the work by each team to a secure location on one of our web servers. Judges from other states can then review the work of each team. Our judges are practicing web professionals and we have more than one judge review the work of each team. Each judge focuses on a specific area (such as accessibility). All scores are collected and finalized by the following morning. We could not achieve all this without our off site judges. If you are reading this and would like to help (or would like more information), please contact us. We can always use more judges.
If you are interested in overall comments from our judges, we provided a summary for competitors to review on our separate Web Design Contest site.
The competition environment
For those who would like to learn more about the environment we utilize, we prepared a couple of articles on our Web Design Contest site. These are listed below.
An overview of the server environment covers the fundamentals of how the server is configured using containers so that the work of each team is separated and secure.
An overview of the network environment covers the fundamentals of how competitors access the local resources. Given the logistics of where the event is held, it is simply not feasible (nor cost effective) to offer actual Internet access to competitors.
Training
Before the competition begins, we offer training to competitors and their advisors the day before (Tuesday). This is our opportunity to make certain everyone has a solid understanding of current industry best practices as they relate to web design and development. It also gives competitors and their advisors the opportunity to ask questions and develop a better understanding of what the competition is all about. In the photo below, Jonathan is discussing process best practices.
WorldSkills Competitor
We also had our WorldSkills Web Design and Development competitor (Matt Vreman) speak to competitors and their advisors before the competition began. He discussed his background (he won gold at one of our prior competitions). Matt reviewed his progress as he prepares to compete in Kazan, Russia in August, 2019. I will be accompanying him as his advisor in that competition (each country is allowed to bring in one expert to help their competitor). There will be roughly 50 countries competing in Russia in web design and development.
Contest Impact
This was our 16th year running a national web design and development competition. A lot has changed in our industry over that time. We like to think that our competition has kept pace with changes in our industry. Over these years, we have had the chance to speak with roughly 2,000 competitors and their advisors/ teachers. We believe that we are making a difference in that competitors and their teachers see what current best practices are and many have adjusted their curriculum accordingly. We see these trends continuing based on the feedback received this year (particularly from advisors). We could not do this without the help of our members; they serve in many roles (including judges and on site team). However, members also provide the funding (through their annual membership dues) to help us achieve our goal of insuring that the next generation of web professionals is following current industry best practices. We couldn’t do this without your support. If you are reading this and have not yet become a member, we encourage you to support us in this endeavor.
Best always, Mark DuBois Executive Director and Lead Community Evangelist
After a long break let’s take a look at another Static Generator – Hexo.
Hexo is powered by Node.js and is mostly aimed at blogging. It has a deploy integration for GitHub which makes it a great fit to build a documentation site for a GitHub project as well. If you are a JavaScript developer, the setup should be relatively easy. Like many other general purpose generators, you’ll probably want to write your content in Markdown. The default templating engine is Swig, which is once again well suited for JavaScript developers. However, Hexo is extensible to allow other templating engines to be used if you want.
The Hexo website includes a range of pre-built themes for you to try out, and one especially popular feature of the tool is its support for single-command deployment.
Installation of Hexo
Installing Hexo is quite
easy. However, you do need to have a couple of other things installed first:
We reviewed static site generators when we began this series of articles. If you need a quick review – a static site is a collection of pages contained in basic HTML files. A static site generator (SSG) is a compromise between using a hand-coded static site and a full CMS. You generate an HTML-only website using raw data (such as Markdown files) and templates. The resulting build is transferred to your live server. Static site generators are systems that compile templates into static HTML pages. There is no server processing or rendering, so static websites tend to be very fast and lightweight, saving you and your users precious time and bandwidth. This increased efficiency is reflected in lower costs (including lower maintenance costs) and, potentially, higher revenues.
What is the difference between WordPress and Hexo?
When talking about performance, one must think about caching. Although there are multiple techniques for caching WordPress, this is not usually a straightforward task, unlike caching static files. Serving cached files is more performant than serving actual files from the server and it can save time when loading websites.
Advantages of Hexo
Hexo has
many pros:
it is blazing fast,
it is easy to deploy to GitHub pages or any other host with one deploy command,
it is powerful with solid Markdown support,
it is highly extensible,
it is open source and there are many open source themes, and
there are available free plugins.
With Hexo, one can create markdown files and HTML layouts which will be converted to static HTML files when deployed. Hexo provides a deploy configuration which builds our static files into a GitHub branch. This means one can maintain documentation as markdown in our project’s master branch and deploy it, with one command, to gh-pages.
My experience working with Hexo
I decided to create a blog post for Hexo without any graphics. I found creating the blog post in Hexo to be easier than Jekyll. Readers may recall that I discussed Jekyll as part 2 of this series. The default theme also looks good on the site. I decided to just run the site locally. If time permits, I may post some of these examples on a Web Professionals server and link to them. In the interim, here is a screen capture of the results. I did not encounter any major issues when working with Hexo locally.
Final Thoughts
During my course of study as a Web Developer I tried many CMS systems and installed a lot of software. I found working with Hexo a little easier than most. It also has a little learning curve. One must use the command prompt to run different commands. I was able to get desired output to display locally with not that much effort. Each time I made changes I had to run ‘hexo server’ command on command prompt. That is the essence of static site generators (one must remember to constantly update the resulting web pages when changes are made).
One may find it simple and easy to build sites using Hexo or one may face problems initially installing and running and deploying. It all depends how the computer configuration/set up is. I am curious as to your experiences with Hexo. What did you like/ dislike? Please update the comments with your experiences.
Recently, I was asked to document how we develop our certification exams. I thought it might be helpful for visitors to this blog to better understand the process as well. We always try to keep our certifications in line with what is happening in the industry. We offer a number of certifications (ranging from novice to professional levels) in web design, web development, mobile and app development and a number of related areas.
Background
We have been offering our certifications for roughly two decades. Obviously, our processes have changed over that time. For example, when I served as Director of Education, we met in Las Vegas (in person) for several days to identify specific areas of focus in our certifications. Nowadays, we hold most of our discussions via email and teleconferences. Here is a bit about our internal process. Frankly, I have personally been involved with many certification efforts over my many years of experience in this field. I have worked closely with companies such as Adobe and Microsoft. Given what I have observed, I can attest that our certifications are comparable and follow roughly the same set of processes. Of course, there is one key difference – our certifications are vendor neutral.
Anyone working in this field understands that technology changes rapidly (and this churn means we need to keep our certifications up to date). This is why those who have earned a certificate from us need to have it renewed every two years.
Our process
Essentially, the process involves periodic review of the current domains and subdomains we cover by individuals in business, industry, and education. We also use this information to keep other initiatives (such as our national web design competition) up to date. Once we have identified that changes need to be made, we have individuals with significant experience in writing questions develop appropriate questions (which include distractors and other features to help confirm individuals really understand the technology). These questions are then reviewed/ revised and eventually end up in question pools. We pull questions from these pools when an individual takes an exam. Obviously, different questions are developed for novice and beginning certifications and for professional certifications. As an aside, we also ask anyone taking a professional level certification to provide documentation they have worked in the industry for at least two years.
We believe it is important that individuals who work in our field consider holding a professional level certification. We believe it is also important those aspiring to work in our industry hold entry level certifications. This is confirmation you have a base level of knowledge and skills for our industry. Of course, we also believe individuals in our industry should be part of a professional organization and collaborate with others. We also ask members to sign a code of ethics. We even include a link to agree to our code of ethics for non- members [it is posted near the bottom of our home page.] It is only through our combined efforts we raise the bar of professionalism in our industry.
Become involved
If you would like to be part of the group which periodically reviews our domains and subdomains, please leave a comment below. By providing your email address, we will know how to contact you. We encourage you to consider helping us (and our industry) by providing your insights periodically as to what matters in today’s rapidly changing field.
I look forward to your comments (and hope you consider assisting us and providing your insights into our process).
Best always,
Mark DuBois
Executive Director and Community Evangelist
Jekyll remains the most widely used static site generator. With Jekyll, you’ll typically work with content in Markdown, a lightweight markup language designed for text formatting. The Liquid templating engine is used to place this Markdown content into the HTML template, and to combine templates representing various parts of a page (say, header, footer and content) in a modular and re-usable manner. It also has support for Sass for those with a preference for CSS pre-processing, and it’ll play fine with libraries like Bootstrap. Also included with Jekyll is an HTTP server which can be used to easily deploy and test your static pages locally.
Importers is a feature which enable an existing site to be migrated to Jekyll with relative ease. For example, you can take an existing WordPress site as a starting point with Jekyll using one of the importers.
If you have a GitHub repository, you’re able to create a GitHub pages site for free using Jekyll. This can be a convenient way to give a polished landing page to your GitHub project.
The big downside of Jekyll – and this applies to most generators – is that it can seem complex at first and is a new technology to master.
You first need to install the Ruby DevKit or you will experience errors. If you are installing Ruby only for the purpose of running Jekyll, Portable Jekyll will give you a full working Jekyll install in less than 5 minutes.
Few easy steps:
To set up your site locally with Jekyll, follow these steps:
Create a local repository for your Jekyll site.
Install Jekyll using Bundler.
(optional): Generate Jekyll site files.
Build your local Jekyll site.
Keep your site up to date with the GitHub Pages gem.
Configure Jekyll.
Does Jekyll generate valid HTML?
Jekyll essentially a parser that converts plain text content written in a special formatting language called Markdown into HTML. These content blocks get inserted into one or more templates to build final output for a static page or a post. Markdown is a styling language used to prepare written content such as blog posts in Jekyll that can eventually be converted into HTML. Markdown allows user to focus on content by using an easy-to-read and easy-to-write plain text format, which can then be converted to valid HTML.
My experience working with Jekyll
Jekyll is widely used Static Generator. I tried working with Jekyll. I followed easy steps to install and run a Jekyll post locally. I first installed Ruby, then used the command prompt to get the desired Jekyll output locally.
Here are some screen captures to get an idea how the site look like. It is a simple blog post without any graphics.
I transferred all generated files and also post I created via FTP to a server. It didn’t give the desired output shown in above images. For example, the link to the CSS file appears to be broken upon transfer.
During my course of study as a Web Developer I tried many different CMS and installed different software, but working with Jekyll is little different. It has a bit of a learning curve and I think someone before working may need someone to have a little technical background. I am still trying to see what I need to change in the background code when it is transferred to a server. Clearly, something did not work properly.
These are my initial observations on using the tool. You may have different experiences and we look forward to your comments. The biggest issue with using any static generator is that you must generate the entire site each time you make updates (so all the links work). You would then need to transfer the appropriate files to the server each time. In my opinion, there are other tools (such as WordPress) which would seem to be more efficient (although less secure as they interact with a database).
A static site is a collection of pages contained in basic HTML files. A static site generator is a compromise between using a hand-coded static site and a full CMS. You generate an HTML-only website using raw data such as Markdown files and templates. The resulting build is transferred to your live web server.
An Introduction to Static Site Generators article was published a few years ago. The basic concept has remained constant. It explains the popularity of static site generator. It also help people of all skill levels understand exactly what static site generators are, acknowledge their advantages, and understand if their limitations are a deal-breaker or if, on the contrary, they can be overcome.
How static sites work?
The proposition of a static site is to shift the heavy load from the moment visitor’s request the content to the moment content actually changes. Using a news kiosk metaphor, think of a scenario where it’s the news agencies who call the kiosk whenever something newsworthy happens.
PHP is a commonly used language for web sites and web application development. It is a general purpose, server-side scripting language run a web server that’s designed to make dynamic pages and applications. PHP is mainly focused on server-side scripting tasks, such as collecting form data, generating dynamic page content, or tracking session state. PHP also does much more.