DEV Community: JeffD

Testing: the hidden side

JeffD — Mon, 20 Mar 2023 07:59:36 +0000

Testing is an activity with a very wide scope. We should test all critical components of our project, and it goes much further than the software features.

Let's remove two misconceptions about test:

All tests are not code (unit or functional test) and automated. Test may be a simple script started on demand or a visual check.
Tests have different frequencies: some may be run once a day only or for each release according to the risk. The test flow follows the development flow, it starts from developer workspace (pre-commit, git hook) and ends in production so some test may be outside the continuous integration tool and not be run for each commit.

Now let's focus on the target of our tests: WHAT to test ?

Testing Input and Output

In our project, you should test all input and output of your system, user input is generally well tested, but some internal features are not. It may be hidden code provided by an external library or written in a different language. Let's analyze the code to find code-related critical features.

Here are some examples:

Telemetry (logs, metrics and traces): do we really want a new release that doesn't write any logs ? If no, then we should probably find a way to get alerted if the telemetry brutally stop (Prometheus endpoint unavailable or empty record)
Alert: we can raise alert to a warning level to ensure production outage will be reported. This kind of test may be done in a QA or staging environment.
Automated process (scheduled job or database stored procedure): all critical job's execution must be tracked, any lack of the launch should raise an alert.
Package: ensure the package contain the right content (config files for all environment) and doesn't contain sensitive data. For this kind of test the best place is in a pre-commit rule to avoid these secret were versioned.
Release: smoke test ensure the release is valid, but we can add test to ensure retro-compatibility; for example checking the new application works with the old version of the database (if this case may happen). This test is more complex than a simple unit-test, but it was greatly simplified by containers.
Resource's policy: ensure your service can access to all required resource (storage, database, message queue...) and read/write data. These cases are probably already present in the functional test suite.
Security procedure: this document list all the steps to be taken in response to an incident. To ensure all the step are correct and everyone in the team understand it, you should simulate commons incident and test your process.

Code tests

Back-to-back testing

This vocabulary term is used when we run the same test launched on two different versions of the code, for example when we use git bisect - To learn more about this Git feature, read this short but efficient introduction.

Canary test

A Health check is a constant call to a production service to ensure the service is up. This kind of test must be quick, it uses specific endpoint with basic response and it cannot guarantee that all is OK (such as the database).

A canary test is a sequence of actions that simulates a real user behavior of the service. In return for its longer duration, this test guarantees that all major components are alright. We can furthermore use the metrics of this test to follow reliability and detect problems (duration, latency).

Hypothesis testing

A new kind of testing framework (like Hypothesys for Python) allow defining the type of the input instead of defined a fixed value. At run, values used in the test will be randomly generated. These tests are not repeatable, it means the same test run twice will not use the same input data.

It's a good way to find edge case, but you should use hypothesis tests in addition to classic unit tests to ensure nominal and specific data are well tested. Furthermore, for some complex and specific cases, this kind of test may rise some false-negative.

Fault seeding

Deliberately adding a new bug in the code and monitor the detection by the test suite. This can be done with a Mutation testing tool which modify your code (for example the value in a conditional statement) and run all tests to ensure this modification (called mutant) is found.

This kind of test consume a lot of resource, use it only for small and critical algorithm.

Security testing

Security is a big topic, let's review the main points:

Consider OWASP Top 10 security issues and tools like BURG or OWASP ZAP to test your code.
Take a look at Static Application Security Testing or Dynamic Application Security Testing tool like Arachni to find vulnerabilities.
See OWASP SAMM to find unsecure practices beyond source code.

Privacy testing

Privacy is related to security but because this topic is often forgotten, I put it in a dedicated section.

In the case who some features are implemented to mitigate data leaks (hashing, database encryption or column level security) these features must be periodically tested. See OWASP's recommendations to protect data everywhere and add a test for each countermeasure present in the project.

Domain-specific test

Depending on your application you may add some tests for usability, localization, accessibility or performance for web application.

Architecture tests

Endurance test

Endurance test is a load test during a long time because if the load test duration is shorter than some cache or TTL specified in your system, maybe you'll miss something. Using real-life context and usage, you will increase tests quality.

Stress test

Unavailability (full or partial) of one or more resource (application server, database, LDAP...) to ensure queues or high-availability is working.
These target may be randomly disconnected like for chaos engineering or we can only add latency (partial unavailability) in some server to see application behavior and check degraded mode.

To learn more you can look at the principles of chaos engineering.

Incident-proof testing

Because ransomware or disk crash sometimes happens, you can do recoverability test to check your service can restart after incident or data corruption.

We can also mention spike test which ensure ability of the service to work after peak loads and scalability test which check the system can get more worker to deal with increasing load. This work is usually done by an orchestration tool like Kubernetes.

Resources

API

A lot of tools have an API. For example, to check monitoring, we can use CURL and call Grafana and Prometheus APIs. Remember, learning about these APIs is a great way to automate things later.

Cause-effect diagram

Writing a good test require to find the right problem you want to avoid.

When you're stuck with a production problem, an interesting methodology to find the root causes is fishbone diagram or Ishikawa diagram.

You can browse and look at the other "problem-solving" methodologies explained by Untools.

ISTQB Glossary

On this testing certification website you can find terms used in software testing. The full list of terms is no longer available.

Exploratory testing

This methodology provide good resources to find edge case for some tests. You can find some Test Heuristics Cheat Sheet to extend your test cases.

Conferences

To learn more about this fast-growing topic, I warmly recommend watching the conferences on the subject. FOSDEM has a Testing track and this subject is present in Devoxx.

Stop coding to improve your code and soft-skills

JeffD — Tue, 07 Mar 2023 09:30:00 +0000

Building software is a great activity, a passion for a lot of us. Practice is a great way to mastering subject. I love discovering new software, programming langages and platforms however spending time on another activity helps a lot for our work. This is a little list to get some soft-skill.

Read History books

Horse Troyan, Enigma, penicilin discovery, or worst technology failures. History is a fun way to learn how humanity solved problems, or how little problem caused big failure. Cryptography history learn us how people try to find failure, first in the cryptographic system, and then in our "language" itself (letter occurrence, word probability). Code book from Simon Singh is a great read on this subject and you can do it away from a blue light screen.

Hackathon

Close your IDE, take a pen, a paper and listen. Ask questions, formulate a solution, debate, try to understand your interlocutors, the context, the problem, the constraint. And you can talk friendly, without fear, it's very different from the usual crazy customer. Hackathon put you out of your confort zone, to be free and build a very helpful solution, it's something really pleasant. I enjoy Hacking-Health but "Code for YourContry" may be very interesting (feel free to list other initiative in the comments).

Visit industrial museum

It's very interesting to discover how people dealed with information without computers: presence of employees, production results, wages... Sometimes a good organization can be done with only paper and pen. We can learn from Ford and Taylor but we can learn from before because industry started in antiquity, and old recipes can still works for our problems. Moreover you can discover fun facts, like this one: in Glenturret Scotland distillery, you can find a statue to honor a cat, Towser, because cat is a easy way to prevent mice from eating cereals used for wisky.

Talks & write

You have to write, search deeply, resume complex subjects for junior and be interesting for experts. Talks are a great way to share knowledge and try to find another point of view to explains things. People will ask you questions so you have to search about problems or usages you've never had. Your audience will add some usefull comments, this is always interesting. And this is a way to present a tool, or a language, with a very original approch (like "Docker as fast-food restaurant" or "Scrum as a MMORPG game"). If you're affraid about speaking in public, blogging is a great alternative.

Translating documentation

A more technical activity: you will learn a lot of things translating the documentation of your stack. You can discover specific modules, unknow arguments, useful functions and awesome community. Moreover we use organization and tools similar to write documentation and code (versionning system is included in a wiki-like solution...) so it's easy to start and very helpful for non-english native people.

Volunteering

When you work in event organization you'll need a tool to organize tasks, a tool to communicate in real-time, a tool to make feedback and so on. You'll deal with problems, you'll need to communicate a lot, with speakers, with public, with your team. You'll deal with urgency, think about diversity and people with disabilities, and theses ones are useful for empathy. You'll learn a lot outside of your technical domain. Be volunteer encourage organization to continue year after year, it sometimes makes it possible to make the event free, so this is a good action (and there is always a good mood).

Sport (or manual activities)

Physical activity is great for health, but it's great for spirit too. Doing sport helps you to forget your problems, bugs, deadlines. You will have a better sleep, it's a good break enabling to restart studying your problem from zero and finally find the bug. Some exercices are great to break our to many hours sitting position, see this post. Physical and manual activities are great to get away from stress and pressure. You can do it in solo or in a team, the last one is good to become humble about our knowledge and abilities.

Meditation

Meditation helps you to work in a noisy environment and reduces stress. It's a great activity and a lot of ressources exists on this subject. Ask Daragh if you need some help.

Another major benefit: meditation help you to stay calm and to distance onself from something and this is very helpful to communicate softly with people. It's a good activity to avoid conflict and improve teamwork.

Cooking

Interruptions are hell, but because we can't delete them completely at work we have to deal with it. We have to learn to list our work in progress, treat one point after the other, finish them completely before starting another one, had to be concise and precise, so we have to learn to stop and resume work.

So a good exercice is coding while preparing a meal: you put timer for the cooking of your meal and start to code. When it's riging you have to stop your work directly, put a status-note somewhere and go treat your meal before it burns. When you'll come back at work you sould read this status-note, remember all and restart coding. This is a trick I like but be aware of your personnal and professionnal time balance, this may become a bad habit and can develop burn-out. Take care of yourself.

Improve your existing tools

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
Abraham Lincoln

Some tools helps you to do more with less code. Sometimes it's a library (as a ORM), sometimes it's a little CLI tips (like !$) or a tool to search security issue, format code, prevent missing documentation. It's always interesting to look at how other developer works and which tools they uses. For this task you can browse on dev-to posts, or looking at Github, in big projects README, which process and tools are used to be efficient. Another way is to ask about it when you meet new people in any technical event.

Thanks for reading, It's hard to cut this post and keep it short, I hope to deeply write about all all theses activities later.
What's your favorite non-coding activity which helps you in your life ? Feel free to leave a comment ⌨️

Python: code a Flake8 plugin to check your own rule

JeffD — Sat, 04 Mar 2023 11:00:00 +0000

Conventions is not only a code style guide. If you include some rules to ensure security then you add some work for the reviewer. It may be interesting to automate this check with some code.

Flake8 is a tool to ensure your code follow some rules. You can add plugins and it's easy to create your own. This post is the textual version of this very good Youtube tutorial by anthonywritescode.

Non-syntax conventions

You can use pylint or Black to reformat and uniformize your code but conventions may contains some other rules:

Security: your company may ban some function like os.popen() or forbid a call to request.get() without the cert attribute.
Log message: you may have some rule to have explicit and descriptive log entry, for example logger.critical() must contains some specific keywords (error uid, tracing span...).

Automate your conventions checks

Building a flake8 has two major advantages:

the review checklist is getting thinner because the continious integration tool take this job.
the developer can be alerted by this noncompliance and fix-it himself instead of waiting pair-review.

If you want to forbid the add of a controler class without documentation, you only have to ensure the docsting is set: It's easier for the reviewer to detect empty docstring than looking at each controler class if they contains documentation.

Automate the first part of the checks (the existence) to help the reviewer to focus on validating the content. So some rules can only be partially automated but it still reduce the mental load of the reviewer.

Follow your technical debt

If you have many projects and you decide to migrate from library A to library B you can use flake8 to alert you about remaining library A usage.

Once your internal_conventions plugin is set and running it's easy to add some rules with some new error-code.

Create Flake8 plugin

It's very easy to check your own rules with a Flake8 plugin (not only because we don't have to use regex), the bootstrap is small.

In this example I write a plugin to check every call to logger.info() contains mandatory_arg. So logger.info("abc", mandatory_arg=1) is valid while logger.info("abc") is invalid.

My project name is flake8_check_logger, flake8_ is a prefix for flake8 plugin (this good naming convention help us to discover plugin on Github). We use the error code LOG042 with message "Invalid logger". By the way use a prefix not already used by your flake8 plugins.

Setup

setup.py:

from setuptools import setup
setup()

setup.cfg:

[metadata]
name = flake8_check_logger
version = 0.1.0

[options]
py_modules = flake8_check_logger
install_requires = 
    flake8>=3.7

[options.entry_points]
flake8.extension =  
    LOG=flake8_check_logger:Plugin

flake8_check_logger.py

import importlib.metadata
import ast
from typing import Any, Generator, Type, Tuple


class Visitor(ast.NodeVisitor):
    def __init__(self):
        self.problems = []

    def visit_Call(self, node: ast.Call) -> None:
        # TODO we write our test here

        self.generic_visit(node)


class Plugin:
    name = __name__
    version = importlib.metadata.version(__name__)

    def __init__(self, tree: ast.AST):
        self._tree = tree

    def run(self) -> Generator[Tuple[int, int, str, Type[Any]], None, None]:
        visitor = Visitor()
        visitor.visit(self._tree)
        for line, col, code, message in visitor.problems:
            yield line, col, f"LOG{code} {message}", type(self)

Discover AST (and astpretty)

Instead of using regex we will use Abstract Syntax Trees. AST transform any python source code to an object representation.

We will install astpretty with pip for development purpose only, it's not a requirement to add in our plugin.

Then you can use it on your terminal:

astpretty /dev/stdin <<< "logger.info('msg', mandatory_arg=1)"

And we obtain some information like

Expr(
            value=Call(
                func=Attribute(
                    value=Name(id='logger', ctx=Load()),
                    attr='info',
                    ctx=Load(),
                ),
                args=[Constant(value='msg', kind=None)],
                keywords=[
                    keyword(
                        arg='mandatory_arg',
                        value=Constant(value=1, kind=None),
                    ),
                ],
            ),
        ),

Write the test

from flake8_check_logger import Plugin

import ast
from typing import Set


def _results(source: str) -> Set[str]:
    tree = ast.parse(source)
    plugin = Plugin(tree)
    return {f"{line}:{col} {msg}" for line, col, msg, _ in plugin.run()}

def test_valid_logger_call():
    assert _results("logger.info('msg', mandatory_arg=1)") == set()

def test_invalid_logger_call_no_mandatory_arg():
    ret = _results("logger.info('msg')")
    assert ret == {'1:0 LOG042 Invalid Logger'}

You can add more testcases: logger.something_else() or a local function with similar name info() should not require this argument, test an empty line, etc.

Write the check

I split my test in two parts for lisibility, this code could be refactored but I prefer to use very basic syntax for this tutorial.

def visit_Call(self, node: ast.Call) -> None:
        mandatory_arg_found = False
        is_right_function = False

        if hasattr(node.func, "value") and node.func.value.id == "logger":
            if node.func.attr == "info":
                is_right_function = True

        if is_right_function:
            for keyword in node.keywords:
                if keyword.arg == "mandatory_arg" and keyword.value.value != None:
                    mandatory_arg_found = True

            if not mandatory_arg_found:
                self.problems.append((
                    node.lineno,
                    node.col_offset, 
                    042,
                    "Invalid logger"
                ))

        self.generic_visit(node)

Local test

We install our plugin with:

pip install -e .

.

And you can check flake load this plugin with

flake8 --version

.

Go further

Your can find more information on the flake8 documentation with a link to the very helpful video tutorial (30 minutes).

With python you can access to something with code: __doc__ for documentation or __bases__ for parent class. Theses dunder function can help you to write some specific rules.

You can learn more about existing flake8 plugin thanks to Jonathan Bowman article and read the source-code of theses plugins to help you if you are blocked by a complex case.

Backup Essentials (Additional informations)

JeffD — Thu, 16 Sep 2021 19:52:26 +0000

I read a lot about backup but the most important points that I noticed throughout my life as a developer are rarely listed.
Backup is a mix between security, automation and low-level understanding of your application (and OS). It's a good exercise for every developer.

Why ?

It help to learn how your applications and system works. For each application you should find where is the data, which format is used (and why) and which tool you can use to get plain-text version of the data. You can learn a lot about your OS, web browser and games.
You can duplicate your dev workstation easily: save your developer setup on a USB key allow you to access your Linux alias, IDE configuration, bookmarks, notes and snippets everywhere. It's an easy way to share you tips with your peers and work on someone else computer.
Hardware and Software failure: your SSD is not invulnerable and despite all the tests, any application or OS can corrupt data during update or running. If you are developer maybe you know that unit test covers application functionality and rarely data consistency after migration.
And the most famous: ransomware, thief, revenge, house in fire or under water, emergency evacuation, small child, fall of a magnet on your HDD, accidental "rm -rf" etc.

The solution requirements

There is requirements you should keep in mind:

You must be able to restore/access the data with any other computer (and/or another OS). The perfect solution is a backup file you can restore with Live OS (boot on USB key).
Software should be easy to install on your host (computer/smartphone) and easy to use.
The output file format should be common: so you can write an automated test on your backup pipeline: backup folder containing one text file, verify the file is present and the content of this file.

Many tools may be good for this job and by the way you can build your own backup script with Python (or any shell language), rsync and cron jobs.

Check the job is well done

Set up alert when backup fail. A good way is to configure a independent CRON job to verify the most recent backup file is not older than 2 days.
Test your data restoration frequently in real condition (using VM or container).
Cryptography is essential for personal data but remember to ensure you can restore data easily in any context (another OS/platform and version).
Automation is the key (cron) but beware this automation doesn't silently delete data. One of your duplicated should only add new files and never repeat (on the remote) the local deletion of a file.
3-2-1 rule: see this post - Remember something like 4-3-2 is better :)

Personal advice

I often use USB key and SD card: they are compact (portable), waterproof, shockproof and easy to put in a little fireproof vault. Moreover it can be full-time connected to your computer as simple RAID1 solution against hardware and software failure.
Ransomware infects all device connected to network so NAS and RAID1 solution, it's why an off-site and offline storage is important. Cloud storage is a good alternative if your hosting company pass your privacy requirements :)
My backup strategy is divided into 2 channels: personal data (rarely updated and encrypted) and work data (modified everyday but doesn't need crypto). So I have two distinct process and allocated storage to avoid my every-day backup doesn't raise problem to my important.
Install and test recover software (for example PhotoRec) it may be helpful.

Bonus: Data checklist example

Personal data: pictures, phone-numbers, scanned files
Internet data (browser relative data): bookmarks, passwords, important e-mails and/or downloaded files
Online services: a copy of everything you create directly online (without copy on your local host) like blog post.
Game level backup ;)
Development stuff: projects, IDE configuration, gitconfig, Linux alias (bashrc), git hooks, API keys, docker-compose files, paid resources (icons, libs, ...)
External data: data stored in databases
External support: backup is necessary for your 2AF solutions like Yubikey, or have a fallback for Android application without degrading security level.
OS configuration: firewall rules, SSH keys ...

Better applications with Unix Philosophy

JeffD — Tue, 14 Apr 2020 16:41:55 +0000

Unix system works with command, a small program with a lot of possibilities, and we will take a closer look at their use.
Because this ecosystem is based on a philosophy very useful for any software and web application.
Note: 5 and 6 are not directly related to Unix philosophy :)

1. One tool do one job done 🔬

It's sound like Single Responsability and it is,
in Unix system you find chown to change owner of a file, but if you want to create a new user, you should use useradd.
So, rights management is divised into many commands.

In his book Rework, Jason Fried regrets that the applications became heavy, with so many features:
it's difficult to maintain, and the user is lost.
We have plugin architecture, we use it in our browser (and IDE and it helped them get their groove on).

So start with minimal functionality and add feature with plugin.
A good example is this todo app by johannesjo.
You can read this article by arcanis (Javascript).

2. Tools are cumulative 🔗

In Unix this is pipe: result of the first command go in the second command.
For example grep to search a keyword: history | grep keyword: data returned by history are filtered by grep.
This compatibility allow a command to be used with another.

To make this, input or output of your application must be compatible with another application,
this is why so many application allow to export (or import) in a standard format (csv, xml, json etc) and it's great, we can export data, treat them with another software, re-import them, you should always give this possibility to your user.

3. Norms and conventions 🌐

In Unix they're some conventions (not always respected):

return code (0 for ok, 1 for minor erreur, 2 for fail)
arguments (-h for help, -v for verbose...)
paths (config, binary, logs, user profile files)

It's helpful for debug, for integration, backup, and to learn and understand application. For example, command and keywords in docker are similar to Unix ones (ls, ps, commit, env), it's easy to remember them. If your user already know keywords (from another application) for the same usage, it will facilitate learning curve to use the same.

Another example: IDE allow to use keyboard shortcuts of another IDE, it's perfect, your user can keep his habits.

And if your system recommand some rules, please respect them, and your user won't be looking during hours where is the log file :)

4. Extendable with configuration 🎲

In Debian system apt is the tool to manage packages (softwares and os updates).
You can create a Debian package for anything you want, for example a simple configuration file.
So if you set up a personal package repository link in apt configuration file you'll get theses packages.

Application working with file don't care if theses file are local, on usb key, on a network or on web hosting.
They expecting a file and don't care about the source.

So if your application can read data from many sources without problem, allow a configuration for it.

5. Intuitive usage 🙂

Unix an comand line interface are not so friendly but autocompletion helps a lot.
If you can implement some helper or search query builder it's always appreciated.

Alias is a command to make a personnal shortcut:
for example alias cgst='clear && git status'.
It's a favorite shortcut, for example in a transportation app, user can choose a geographical point as favorite (home, work place, library, ...).

In Unix system you can find the command wereis to locate binary of another command, whatis to explain a command,
man to show documentation, whence to show if alias is used, etc.
This is great because it help user to have a fast overview of a software, where it is, what it do, how to use it.

6. Attractive Documentation 🎠

Unix system has man pages and so many documentation online (great community).
So manual, wiki and FAQ or QA forum are some basics, but there is some idea for more attractive solutions:

Readme: with common usage and frequent problem. See How to write kickass Readme
Tutorial/Cookbook: advanced usage and usage categorized by needs/profile user/...
cheat sheet: a list with all command or and annoted screenshot of the interface
sandbox mode: allow user to dive into dangerous command without losing real data or web tool like Git School.
changelog with Gif: look at VSCode changelog or vscodecandothat
alternative list: do a comparative listing concurrent alternative, because when we are looking for an alternative to Trello we type trello (rarely kanban). so it's great for SEO (especially on Github).

Conclusion:

Start with minimal interface and add features in plugin
Allow to export (and import) in standart format (json, csv, ...)
Respect the OS norms, conventions, habits
Allow configuration to extend your application usage
Help user (autocompletion, favorite shortcut)
Write attractive documentation

Learn more:

The (real) Unix philosophy
You want to start working with Linux/MacOS command line: see IBM free articles and the explainshell webtool

Thanks for reading - Stay safe.
Sorry for the typo and mistakes (#french #confinmentDay30)

Some free-time ? Some ideas !

JeffD — Fri, 27 Mar 2020 19:36:37 +0000

I live in France so my work were stopped during this Covid-19 crisis. I don't do remote work because you know, the book Remote (by 37signal) were not translated to french (or maybe here big company loves managers and physical employees). So I'm at home, with 8 hours per day available and a limited internet access. What can I do ?

Hack-Covid 🦠

A lot of hackathons are emerging to help medical and emergency services. I can speak a lot about Hacking Health but there so many initiatives (from associations to companies and countries). It's great because you meet some people with various skills and you can work on a new technology.

Start a long-time project 🔧

Do you remember this awesome idea you got years ago ? Now you can try ! We regrets things we didn't try more than bad ideas.
I have Arduino and Micropython board and I didn't do anything with it. So now I'll probably burn out some LEDS and write something about a dream: transform an old (1940) typewriter to an external keyboard for computer (it's an experience for an awesome gift for my sister).

Write 🖊️

I will write a Jitsy tutorial for my family to promote visio-call and probably continue to translate some article on Mozilla Developper Network. Maybe I'll write here an simple introduction to web-certificate because there nothing on MDN. You can write that tutorial you wish you'd had in the past (all the point of view are welcome on complex subject).
It's very important to share knowledge and if you have no idea, you can write the best life lesson for your children or nephews and nieces.

Boring stuff: backup and mails 🧹

You know spending some time to automate today will make you gain some time later.

Ransomwares are still dangerous, so I decide to seriously work on automated backup and find a solution to simplify backup on temporary connected hard-disk (stored at different places outside my home).
Delete spam, unsubscribe to some newsletters, remove all attachment... I really love to have a clean mail box. Clean workspace is a good thing.

Learn (Read, talks, MOOCS) 📚

I started to learn subjects more deeply, I'm very happy to discover this free ebook about cryptography. And I read other paper-book because you know, blue ligth...
I'm volunteer to many conferences so I miss very interesting talks. Fosdem and Pycon contains so many interesting subjects (but you need a fast internet access and no data limitation). If you are french CNIL published a great MOOC about RGPD. And next you can write a blog post about your new skill.

Starting new habits 🗓️

When you have a lot of time you can easily allocate some time to a new activity and build an habit (I think it takes 20 occurrences). So I plan one to do Yoga, piano and meditation. And I love to start poping some blog post from my to-read list.
You can start contributing to something like take one picture per day and publish it on Wikipedia or Unsplash, add content on openstreetmap, learn a new language, etc.

Design (work without computer) 🧶

I draw some sketches for my new desk (not really a desk, something very special). Doing something different from a software is a very interesting task with new constraints and workflow, I definitively recommand it. You can conceive a new board-game, a new cook recipe, a new children activity, an infography on any subject, etc.

Think 🤔

I finish with this point. Viruses are not new, but Covid19 is (sadly) very special. Many things have helped to spread it and we need to think on all problems we are meeting right now and take some time on the causes. We should anticipate remote work, massive usage, learn to be more forward-looking about health problems, find solutions to coordinate people all arround the world, both block viruses and respect privacy, educate people to avoid fake-news. Technology won't solve everything and logic we developped as engineer can be apply to food supply and medical problems, so don't stick to computers, development, AWS and blockchain. When we can help we must help.

Spend time with your friends and family, call them, and take care. 💜

Thank you

7 advices after 10 years of development

JeffD — Wed, 11 Sep 2019 21:00:46 +0000

Write 🗒️

This is the first and best way to communicate (persistant and remote-friendly). So write all the things you can:

meetings: decisions, questions and answers, work in progress and pending subjects...
problems: hardware failures, bugs and their solution, software weakness, code to refactor...
conferences: draw or write but keep trace to essential content, references, tools, books ...
code snippets: CORS, http headers, dark options or regex...

Find a tool you can easily share with your team, accessible everywhere (if needed). This knowledge will be available for a new coworker, even if you are on holiday, even if you leave. This is a valuable practice.
Notions, Wiki, Evernote there are many solutions, I use plain text files (with rsync and git).

Learn efficiently 📗

Know yourself: learn at morning, learn at evening, look schema, listen podcast, write and search that's work the best for you because you'll spend a lot of time to learn it's very important to find your best way to aquire knowledge.
Learn:

when in the day you can learn efficiently
if graphics, illustrations helps you
how long time you can be concentrated on reading articles or any technical book
how long time you can be concentrated on writing code

Allocate time: one hour once in a while (make a habits) to read blog posts.
Use long period (2 or 3h) to practice and write code

Read documentation before writing code (ideally the day before and a few hours before)
when you'll be stuck you'll know:

where to search solution to any problem.
if it's possible to do that you want (and if it's a good practice or not).
better ... because it helps memory to read twice!

Don't try to learn all (really) ❌

List ten subjects you want to learn, split up to atomic objectives. Choose objective one by one, all interesting articles or tools should be put in a "later" list.
Start with basics (HTTP, SQL, security, design patterns, language internal ...) they are evolving more slowly than EcmaScript/JS.
Learn the possibilities of your tools, starting with OS and IDE because many build-in tools are awesome.
Stop learning deprecated lib, even if you made something with long time ago. Your mind should be clear and not overloaded (like your resume). Sorry JQuery.

Avoid boring stuff 🤖

Automate your backup, bills payment, domain names renewal, OS updates, let computer do it alone, test that it's work fine and forget about it.
Use RSS to get news, less ad, less distractions than in classical websites.
Newsletters are awesome, you'll lose less time than looking at Twitter and content are very relevant.
Want to try a new tool or language, look at awesome pages on Github, you'll find a lot of ressources about a lot of stuff.

Refactoring - Unit-test - Debug 🧩

Refactoring: I'll write about this soon. 📝
Reading open-source code to get new way to write code.
Learn about your debug tool and TDD.

When a bug occurs ask you theses questions:

What: define the probleme with the more details you can find.
Where: which server, which database, which microservice, which part of the code, are any external lib involved ?
When: date (day saving time), version (app, software), server status (memory usage), duration of the transaction, it is just after any activity like cron ?
How : how this state arrived here: what's happend before, are the previous data correct?

Of course subscribe to:

#testing Follow

Find those bugs before your users do! 🐛

Learn security 🔒

Security is not a feature, it should be the backbone of your app.

Because of privacy and because it can cost a lot of money:

Start with Victoria's post then learn OWASP top ten threat.
Remember threat evolving all the time (homographs attacks, JSON hacking, ransomware, *coin-mining).
Ask your friend, teammates to hack your app in exchange for a beer or chocolate.
Learn with vulnerableApp like security shepherd.

Be open-minded 👥

To all domains because we can learn from processes used everywhere like medical team, restaurant or classical factories. Remember Kanban comes from traditionnal industries (car manufacturer Toyota).
To people from another country, age, skill level because the way they learn or analyze a problem are very interesting.
To other tools, OS's, programing languages because we are not ennemy.

Understanding your users will help you to build better apps. Get empathy will help you to be a better human.

Thanks for reading - Have a nice day.

PS: it is obvious that you should also read:

Following Cooking Recipes Makes You a Clearer Writer

Amara Graham ・ Jul 17 '19

#devrel #documentation #developerrelations

Article No Longer Available

How do you imagine Joel Test 2019 ?

JeffD — Mon, 18 Jun 2018 20:27:46 +0000

One day, Joel Spolsky defined the "12 step to better code". It's Joel Test. It was writted in August 2000, a long time ago when "CVS was fine" :) There is the list:

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

So, what do you suggest for the Joel Test 2019 edition ?

Here is mine:

Do programmers have quiet working conditions?
Do you make daily builds?
Can you make a build in one step? (include tests and deployment)
Do you use decentralized source control?
Do you have a wiki?
Do you use tools chosen by the team? (include OS & IDE)
Do you have time allocated to improve internal tools or process?
Do you have time allocated to learn something new? (Not just lunch & learn)
Can you do remote-work one day in the week?/Can you choose your work-hours?
Can you sleep or make sport during lunch time? (Quiet room/shower available)
Can you meet or talk with your final users? (best feedback and empathy source :) )
Do you use any agile methodology?

(In my opinion the agile methodology is not something perfect, it could be something like "Can the team refuse the chief assignment/work/idea ?", something about hierarchy, humans interractions, democracy in the team, I'm a little bit fuzzy about this step).

Please, feel free to share your "Must-have" ideas :)
Thanks for reading, enjoy your day !

Any rules, tips and tricks for commit message

JeffD — Mon, 16 Oct 2017 19:18:35 +0000

Reading commit messages is a great way to understand software evolution without reading all the code.

I use the following rule:

start with an action verb: Add, Fix, Remove, Update, Refactore...
include the concerned domain (if != code): test, documentation, config, scripts...
a description to explain the "Why?" or "How?"
and a reference to ticket or bug

To obtain:

Fix tests for Linux platform: filesystem was hardcoded - #123
Add configuration: support article pagination - #345
Refactore customer subscription service to improve performance - #898

And you, do you use any rules to write better commit message in your company or open source project ?