TL;DR - Here is a demo of what we are going to achieve. Once you have this basic implementation you can use it in many defferent ways - in a View, to send notifications, etc.
Things you should be familiar with:
In my previous article I promised you to show you how to properly unit test Celery tasks. Since I keep my promises every time, this is the target of the following article.
You had better be familiar with the mocking technique in the unit test practices before dive into the article. If you are not that sure in your knowledge - check this article.
I'm going to expand my previous article so you had better take a quick look at it. If you already read it you can take a look at its demo.
Unit testing is essential part of our daily struggles as a programmer. Therefore, if we want to be better in our work we have to advance in this approach.
In the article we are going to look at the mock module of Python's unittest library. In the end you will end up with levelled up unit testing skills.
This is actually a test technique that allows you to isolate parts of you code and unit test them. You can easily fake function calls in your tests wherever needed.
TL;DR This article is targeted at programmers who have very little or no experience with fakers and factories. If you are already skilled in the topic this article may not be that interesting to you.
In our Django apps we have the M(odel)T(emplate)V(iew) structure (mostly known as MVC). When we want to test its functionality we usually have to create some model instances and work with them and the database.
A nice and easy approach for doing so is to create fake data in our tests in the form of factories and fakers.
In the following article we are going to look over some practical examples and techniques. This will improve your tests readability and behavior.
Recently we've started a new SPA (single-page application) project with Redux, React and React Router (v4).
Until now I've been working mainly on the backend part of apps so this was a new challenge. In this blog post I will share my knowledge with you.
TL;DR You can check this demo project that uses the Webpack configuration that we are going to achieve.
In my previous article I promised you to write about how we split our webpack configurations for production and for development. This post is a continuation to the previous one and I will use the webpack.config.js
file from there. You had better check it out if you haven't yet!
Well, like the most things in programming you may want to use a different configuration for your production files and for development. If you think your webpack.config.js
is good enough for both cases then this article is not for you.
If you are from the ones that want to have different configurations - like minifying your bundle file only for production and stuff like that - then let's dive in!
#!/bin/bash | |
# USAGE (cd utility/ first!): ./create_container.sh -n <CONTAINER_NAME> -a <ACTION_1> (-a <ACTION_2>...) | |
RED='\033[0;31m' | |
GREEN='\033[0;32m' | |
NC='\033[0m' | |
SRC_PATH=../src | |
CONTAINERS_PATH=${SRC_PATH}/containers |
function* authenticate(credentials) {
try {
const {data} = yield call(requestLogin, credentials);
storeAuthToken(data.token);
yield* [
put(loginSuccess()),
put(storeMe(data.me)),
import re | |
from typing import Dict, Callable, Optional | |
def to_camel_case(snake_case_str: str) -> str: | |
""" | |
Transforms snake_case to camelCase | |
""" | |
components = snake_case_str.split('_') | |
titled_components = ''.join(x.title() for x in components[1:]) |
As you may know from my other blog posts I am mainly working with Django and React at the moment. In this article we are going to take a look on how to solve one bothering problem - the cases mismatch.