Check many different URLs in jenkins with a simple bash script for uptime monitoring

This is a simple script to check whether URLs are reachable over HTTP(S). This comes in handy for example when a project has many different (secondary) domains that redirect to the main domain.

#!/bin/bash


urls=(
    "http://domain1.com",
    "https://domain1.com",
    
    "http://domain2.com",
    "https://domain2.com",
    
    "...",
) 

# remove commas
for i in "${!urls[@]}"; do     
   urls[$i]=${urls[$i]//,}
done

#for i in "${!urls[@]}"; do     
#    echo "$i"
#    echo "${urls[$i]}"
#done
#exit 0


for i in "${!urls[@]}"; do
    echo "Checking status of ${urls[$i]}"
    code=`curl -sL --connect-timeout 20 --max-time 30 -w "%{http_code}\\n" "${urls[$i]}" -o /dev/null`

    echo "Found code $code for '${urls[$i]}'"

    if [ "$code" = "200" ]; then
        echo "Website '${urls[$i]}' is online."
        online=true
        sleep 3
    else
        echo "Website '${urls[$i]}' seems to be offline. Waiting $timeout seconds."
        echo "Monitor finished with failures, at least one website appears to be unreachable."
        exit 1
    fi
done

echo "Monitor finished, all good."
exit 0

Great Handovers between Designer and Developers

Traditionally, in any kind of publishing business there has always been a big gap between designers and implementation. We come from a world, where after the designers were done, whoever needed to implement designs had to spend a lot of work importing the artwork into his work environment.

In modern web development, for the first time in the history of mankind, smooth, integrated handovers between designers and developers are in our reach! Here is how.

Common design handover pitfalls

For website projects, the handover between the design phase and the development phase can be difficult and time consuming. Here are a couple of reasons why:

  • Size: Some designs look smaller when looking at them as mockups than after they are implemented as websites. This is then a big surprise for customers. If this happens, sometimes a complete redo is needed!
  • Grid: Design mockups that dont respect a standard grid like bootstrap4 are hard to implement!
  • Tools and Formats: Source file formats that are not intended for web design (such as Adobe Indesign) cause severe headaches amongst frontend developers.
  • Assets: If not all the assets are available in the quality required (vector shapes such as SVG icons, high-res images, webfonts, etc.) or the assets are not exportable from design tools, the frontend developers need to ask back, causing delays and unnecessary communication loops.
  • Process: Frontend development is really challenging when there are last minute changes and many feedback iterations, because frontend development requires a lot of time and therefore is costly.

Read on to learn how we resolve these issues.

1. Size Matters

Have you ever read “Objects In The Mirror Are Closer Than They Appear” on a side-view mirror? The same happens to mockups. They often look smaller than they will appear once implemented in code. Also, designers often work with very big screens 19 or 22 inches, while clients often use their business laptops at 13 or 15 inches.

Recommendations for Designers:

  • Use 1920px (wide screen version) and 1440px (normal desktop screen version) for the artboard width itself and 1170px for the content width. A suitable sketch template can be found here.
    • This setup allows a frontend developer to see what elements should stretch out to full screen width, and what elements are limited by the content width.
    • The 1170px content width will allow the client to preview the design in its full width even on smaller screens and in general is aesthetically pleasing.
  • Main body content should be between 16px and 20px, and other sizes (e.g. H1) should be relative to that
  • Show the mockups to the client in a way that is not zoomable. Use a design hand-off tool (see below) – why? It doesn’t auto-scale the mockups based on the window width of the browser. If you use images or PDF, the content of the window is auto-scaled based on the window width of the browser or image preview tool on the client’s computer. Alternative: Send the client an HTML where the mockups are added as background image of the body element (<html><body style="background-image: url('img/mockup1.jpg'); height: 3500px; background-repeat: no-repeat; background-position: center top;"></body></html>)

2. Design Grid

These days, most websites are implemented using a responsive grid. Using a grid ensures that websites are readable and look good on many different devices and screen sizes and makes web frontend programming more efficient and robust.

The most commonly used grid is part of the Bootstrap v4 frontend framework, but there are also other grids on the market. Creating website designs and mockups that are compatible with such grids is a industry wide best practise.

Recommendations for Designers:

We recommend that you always use a standard 12 or 24 columns Bootstrap v4 grid. There are many templates that facilitate designing for a responsive grid, here are some examples:

3. Tools and Formats

These days, Designers that would like to provide assets to frontend developers overwhelmingly use Design Hand-Off Tools – see here for an intro: Design Hand-Off Tools.

Legacy or print software is a huge headache for Frontend Developers, as assets are rarely exportable in a quality / format that is apt for web development.

Recommendations for Designers:

Use a Design Hand-Off Tool that has a web interface. There are currently these options:

Further Notes:

  • Permissions: Make sure you assign permissions so that the web-based inspectors are available to frontend developers. Beyond link-sharing it’s best to invite frontend developers with their email addresses and assign all available permissions to them.
  • Exportability: shapes (such as SVG icons), images and text should be selectable separately, and exportable in high quality.

4. Assets

Even when using such a tool, hand-offs remain tricky, because it’s not always intuitive for designers to organise designs in a way that makes single images and shapes exportable.

Recommendations for Designers:

Images: Images need to be exportable from the web inspector in an optimized format (jpg or png) – make sure transparency still works!

⚠️ Pay special attention to use the sRGB color space! Browsers may not fully support color spaces other than sRGB.

Text: text properties (such as text size, text decoration, text style, font-family, etc.) should be properly displayed in the tool, when selecting the text. Text copy should be selectable for copy and paste.

Styles: it’s important that properties such as border radius, shadows, height, width, etc. is properly displayed in the tool, when selecting a box or other type of layout.

Gradients: If the design has almost-unnoticeable gradients (eg for visibility of the text on top of bright images) – mention them explicitly during the hand-over, otherwise they might go unnoticed and end up being excluded from the project estimates.

Source files: Upload source files (.xd or .sketch) to Google Drive.

Non-exportable assets: If the inspector doesnt allow to export some assets, upload and share them on Google Drive.

Do not use tools that provide links that expire after some time, as information might get lost that way. Think about vector shapes (SVGs), images, stock photos, videos and web fonts

File names: Please give your assets speaking file names so that the frontend developer doesn’t have to rename assets.

Fonts: Please use a Google Font. If that’s not possible, help us by uploading a zip file of the web fonts to Google Drive. If you only have .ttf fonts you can create a web font package on https://www.fontsquirrel.com/tools/webfont-generator

Paid Assets: Normally, the client is purchasing any paid assets directly via credit card. While working on a design proposal that includes assets that need to be purchased, you can use preview or trial material, other sources (i.e. fonts you have already installed, etc.) for the mockups. Upon design approval you can create a gitlab issue on the respective Gitlab project, asking the client to purchase the corresponding assets. Please include the direct links to the items to be purchased for the convenience of the client.

Google Drive: In order to enable frontend developers to work efficiently, it’s important that all your source files are in the project’s Google Drive folder and that you keep them updated at all times so that the frontend developer always have access to the latest version.

If you dont have access to the project’s shared folder on Google Drive request access with the responsible project manager

Do not change the file name after updating a source file (i.e. do not add a version or date to the filename). Google Drive automatically creates a new version of the file if the file name is the same. The old versions are still accessible via the context menu (right click on the file).

5. Process

Frontend designers expect signed-off, highly accurate (pixel-perfect) design mockups that leave no room for interpretation.

Recommendations for Designers:

First Steps:

  1. Join the team on Slack! As a designer you are a crucial part of every project. Therefore please join the project channel on the what-digital slack organisation
  2. Join the project! Please ask for access to the gitlab project where all the tasks are managed.
  3. Join Google Drive! Also ask for access to the project’s shared folder on Google Drive so that you have A) access to any existing design assets and other briefing material and B) can upload (and keep up-to-date) the source files you create.

Sign-off: In order to avoid loops and work done multiple times, get a full design sign-off based on your finalized mockups before handing them off to the frontend developer. The Frontend Developer doesnt expect the designs to change anymore.

Pixel-perfectness: As a designer, be aware that Frontend Developers will take your mockups literally. Make sure you are 100% accurate in every aspect of the design before you your work over. What you see is what you get.

Technical Requirements Documentation: Ask the developer to share his technical requirements documentation. Developers specify their point of view on the business logic and how they would like to solve certain challenges. By providing feedback on the developer view you can push the project in the right direction from the start.

Hand-over Meeting: Organize a hand-over meeting (we use Slack or Google Meet for online meetings) so you can go through your designs with the Frontend Developer. The “sound track” helps to provide context and avoid misunderstandings.

Responsiveness: Sometimes designing only one breakpoint (i.e. only desktop, or only mobile) saves a huge amount of time and avoids over-specification. Frontend developers are used to create responsiveness websites and can extrapolate your designs independently.

Design Review: Ask the frontend developer to schedule a design review with you once he’s done so that you can give feedback, resolve open questions and influence the final touches, before the work is handed over to the client for approval.

Create a Google Account on your existing non-gmail email address

What?? Yes, it’s possible!

You can log into Google services like Google Drive or Google Photos with your existing your.name@your-business.com or your.name@gmx.de email address.

Some context: A Google Account and a gmail address are not the same thing. A Google Account is required to log into Google services such as gmail, google drive, youtube, etc. Login with Google even lets you use your Google Account (instead of a username and password) to log into third-party services that support it.

Note: When you create a gmail address a Google Account is automagically created with it.

Google lets you create a Google Account for any email address, specifically for your work address.

Why does it matter?

Other people might want to add you to Google services. If you don’t have a Google Account on your work address, these people will see this error, here is an example from Google Analytics:

It’s recommended to use your official work address for Google (and other) services you use for work, instead of your private (or secondary) gmail address. This way, system administrators can identify individuals when looking at a list of authorized users which increases security for everybody at your company. Nobody knows who frank_82@gmail.com is, but everybody can recognize frank.mueller@yourcompany.com.

How? Here is how to create a Google Account with your non-gmail email address:

  1. Go to https://accounts.google.com/signup/
  2. Click on Use my current email address instead
  3. Enter your official work email address
  4. Finalize the registration providing the required information

If Google complains that there is already a Google Account for this email address, then please click on Sign in instead and sign in, use the Forgot password? link to recover your password if necessary.

Now your work email address (respectively the Google Account attached to it) can be used by other people to add you to Google Services, for example Google Analytics.

Django and Security

Many people have asked me: Is django secure?

Luckily, with django we don’t have to worry about basic security at all. Here is a list of basic security stuff that django supports right out of the box.

  • Cross site scripting (XSS) protection
  • Cross site request forgery (CSRF) protection
  • Full CORS support
  • SQL injection protection
  • Clickjacking protection
  • SSL/HTTPS
  • Host header validation
  • Session security

On top of this we lock down production deployments as follows:

  • Set SECURE_HSTS_SECONDS. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
  • SECURE_CONTENT_TYPE_NOSNIFF set to True, so your pages will not be served with an ‘x-content-type-options: nosniff’ header. You should consider enabling this header to prevent the browser from identifying content types incorrectly.
  • SECURE_BROWSER_XSS_FILTER set to True, so your pages will not be served with an ‘x-xss-protection: 1; mode=block’ header. You should consider enabling this header to activate the browser’s XSS filtering and help prevent XSS attacks.
  • SECURE_SSL_REDIRECT set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
  • SESSION_COOKIE_SECURE set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.
  • Set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token.
  • DEBUG set to False in deployment.
  • X_FRAME_OPTIONS set to ‘DENY’. The default is ‘SAMEORIGIN’, but unless there is a good reason for your site to serve other parts of itself in a frame, you should change it to ‘DENY’.

Additional Security Features

django features a range of third-party open source modules that improve security, for example access logging and application firewalling: https://djangopackages.org/grids/g/security/

The life and death of conventional Content Management Systems – and why django CMS is more sustainable

I was recently asked to compare the django ecosystem with the drupal ecosystem. Drupal is widely known as a huge open source CMS success with a massive community behind. 

However looking at Google Trend to my biggest surprise I realized that this is not true in 2019 anymore. The django ecosystem is bigger and on top of that, growing in a sustainable way.

Django (red) vs Drupal (blue) – Since 2016 django has surpassed Drupal. Shockingly, the decline in the interest in the Drupal CMS ecosystem is sharp.

Google Trends 2019

It is my experience that most CMS come and go across the years. The django ecosystem appears to be much more robust than any CMS ecosystem because it doesnt just cover CMS functionality, as a web application framework it covers a much broader scope, with the django CMS package covering the CMS part.

As you can see here, Django is amongst the top three open source web technology ecosystems and it is on a continuous growth path:

Google Trends 2019

django CMS itself is much leaner than other CMS, as it sits on the shoulder of a giant: django – this makes it more long-living and much more maintainable than other CMS projects.

I hope I could give you some insights into the advantages of django + django CMS. Please let me know if you have any questions.

For more information about the technology stack, I’d also point you to the slightly technical articles I wrote about django and django cms.

Disclaimer: At what.digital django and django CMS is our main backend technology stack.

Would you like to contribute to this article? Please let me know. For example, do you think Google Trends is a good way to look at how future-proof a technology is?

Why we use divio.com for django / django CMS hosting

Divio is the company that originally founded django CMS a couple of years ago and that still contributes to developing it further together with the rest of the django CMS community.

Divio is a professional, modern cloud hosting company specialized in hosting python / django / django CMS projects in a highly secure, performant and efficient way.

Divio relies on data centers in Europa and North America via Amazon Web Services (AWS) and in Switzerland – its hosting is fully scalable, meaning that we could host websites with Divio that would be used by hundreds of thousands of daily users.

Amongst Divio’s customers are small to large enterprises in Switzerland and across the globe including S&P Fortune 500 companies and global financial institutions.

Divio is headquartered in Zurich, close to Hardbrücke and has offices in New York City and Stockholm as well as a technical team distributed around the world to be able to respond to support requests around the clock (24/7).

At what.digital what we like about divio.com hosting is:

  • simplicity of the divio.com control panel to launch and maintain projects for our clients
  • very competitive pricing
  • simple backup
  • quick responses from their support staff
  • robust developer tools for django and django CMS projects

Why Django – the Web Application Framework for perfectionists with deadlines

Django is a modern web application (backend) framework with lots of support to scaffold web applications.

Django was designed to help developers take applications from concept to completion as quickly as possible.

https://www.djangoproject.com/

The main advantages are:

  • Secure: Django has built-in state-of-the-art security.
  • Efficient: Django has some of the best scaffolding tools to build web applications fast and efficiently (ORM including fully automated database migrations, admin interface, form generation, user authentication, management and permissions, REST API support, and much more). This means that applications can be developed quicker and more cost-efficiently, and the maintenance cost is lower in comparison with other web frameworks.
  • Popular: Django is very popular and has a huge community. Looking at Google Trends, Django emerges as a top-three web framework next to Spring and Laravel. Being so popular, Django has tons of well-maintained modules. These modules are well organized – check it out at https://djangopackages.org/.

By the way: Django also has very good Content Management (CMS) support via projects like Django CMS or wagtail.

Django CMS – A hands-on Introduction

Introduction

Why Django CMS? Django CMS is a good choice for companies that depend on their website to drive business and generate user value.

For Editors and Marketing Managers: Django CMS empowers editors to select from custom-made page templates and content elements without any dependency on developers. Watch the video below:

django CMS is user friendly and has a very intuitive drag and drop interface.
It’s built around the needs of multi-lingual publishing by default, not as an afterthought: all websites, pages and content can exist in multiple language versions

https://www.django-cms.org/en/

Full list of django CMS features:

  • Frontend Editing
  • Modular Content Management. Editors can choose from…
    • content elements (plugins)
    • templates for a whole page
    • templates for just parts of a page (sections)
  • Full Multi-Language Support
  • Simple publishing process (draft / published)
  • Multi-Site Support (manage different sites with different domains in the same project)
  • Support for all aspects of SEO and Social Media cards / integrations
  • Full-fledged admin interface and site settings
  • different levels of permissions for editors
  • Full-text search
  • Undo / Redo / Revert to published version for editors
  • … and more

For Developers: Developers can use the full power of Django, a top-three open-source web framework which is also at the core of Django CMS, to build state-of-the-art applications (such as an online course booking tool) that integrate smoothly with the rest of the website. Moreover, developers can include CMS functionality in their applications, creating a perfect blend between application logic and manageable content.

Demo

Here you can create your own demo web server with Django CMS and a demo theme installed out of the box. No setup required.

The demo theme consists of standard components. It allows you to build your own page templates. Components include image sliders, text and images in one or multiple columns, tabbed content and much more.

First Steps: In Django CMS, all content can be edited right on the website itself. Append ?edit to the current URL and hit enter. Now you should see the admin bar where you can log in with the admin username and password that you received (or if already logged in, just hit the ‘Edit’ button). Then try double-clicking on a text anywhere on the page and an editor window will open.

The Structure Mode

The structure mode allows an editor to insert content elements (a.k.a. plugins) and to change their order on the page. Try it out! Here is how to use the DjangoCMS structure mode.

More Admin Tools

There are some additional admin tools that allow you to publish / unpublish pages, manage multi-language, etc: Read more at http://docs.django-cms.org/en/latest/user/reference/page_admin.html

Here is the link to the full documentation for editors: http://docs.django-cms.org/en/latest/user/index.html

What’s next?

If you have any questions about Django, Django CMS or CMS in general please get in touch with mario@what.digital

Firebase Dynamic Links and Marketing Campaign Attribution

The goal: What the app marketer would like to do: Prepare links with Google Analytics utm parameters that lead the user to the app (either via download & install through the app store or directly to the installed app) and then use these links in online marketing campaign across the board (email marketing, social media marketing, search engine marketing, display advertising, etc.)

The Solution (experimental): Firebase Dynamic Links

Here is how you can create such a Firebase Dynamic Link manually and here is the debug view of an example of a Firebase Dynamic Link: https://example.page.link/?link=https://www.our-client.com&d=1&utm_source=google&utm_medium=cpc&utm_campaign=summer-campaign

According to the official documentation, these links will work on both iOS and Android, whether the app is installed or not. Google Analytics utm_parameters appear to be fully supported.

Dynamic Links work across app installs: if a user opens a Dynamic Link on iOS or Android and doesn’t have your app installed, the user can be prompted to install it; then, after installation, your app starts and can access the link.

When a user opens one of your Dynamic Links, if your app isn’t yet installed, the user is sent to the Play Store or App Store to install your app (unless you specify otherwise), and your app opens. You can then retrieve the link that was passed to your app and handle the deep link as appropriate for your app.

https://firebase.google.com/docs/dynamic-links
This is an example of what a Firebase Dynamic Link is capable of doing in different situations.