Feel free to contact me at [email protected] or tweet at me @statisticsftw
This is a rough outline of how we utilize next.js and S3/Cloudfront. Hope it helps!
It assumes some knowledge of AWS.
Feel free to contact me at [email protected] or tweet at me @statisticsftw
This is a rough outline of how we utilize next.js and S3/Cloudfront. Hope it helps!
It assumes some knowledge of AWS.
#elC - The elementary OS Combobulator - There are many issues within the community that tend to come up a lot. | |
#I know many of them are open bug reports, but until they are patched we can provide a consolidated list of work-arounds. | |
#I think this will be helpful for newcomers and veterans alike | |
#enable ppas | |
sudo apt install -y software-properties-common python3-software-properties python-software-properties | |
#install elementary tweaks | |
sudo add-apt-repository -y ppa:philip.scott/elementary-tweaks | |
sudo apt update -y |
Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.
My 3 developers team has just developed React.js application with 7668
lines of CSS (and just 2 !important
).
During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.
Here are main principles we use to write CSS for modern (IE11+) browsers:
FROM alpine:3.3 | |
MAINTAINER Tom Maiaroto <[email protected]> | |
# Install packages | |
RUN apk --update --repository http://dl-3.alpinelinux.org/alpine/edge/main add \ | |
freetype-dev \ | |
libjpeg-turbo-dev \ | |
libpng-dev \ | |
libwebp-dev \ | |
php7 \ |
sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024 | |
sudo /sbin/mkswap /var/swap.1 | |
sudo /sbin/swapon /var/swap.1 | |
sudo chmod 600 /var/swap.1 | |
# Add to /etc/fstab | |
/var/swap.1 swap swap defaults 0 0 |
Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.
I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a
beforeEach
. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern
that gives great defaults for each test example but allows every example to override props
when needed:
React.createClass
, extending React.Component
and also stateless functional components.renderOnError()
in a compalias accio=wget | |
alias avadaKedavra='rm -f' | |
alias imperio=sudo | |
alias priorIncantato='echo `history |tail -n2 |head -n1` | sed "s/[0-9]* //"' | |
alias stupefy='sleep 5' | |
alias wingardiumLeviosa=mv | |
alias sonorus='set -v' | |
alias quietus='set +v' |
Redux has brought the notion of reducer back into the awareness of many developers for whom they are a novel concept. In fact they are quite simple, and used all the time in such things as SUM
aggregations in databases, where they compute a single value from many.
It's great that Redux has made reducers known to a broader audience, though they are relatively ancient concepts in programming, in fact. But the particular way Redux illustrates a reducer in its documentaion is, in my opinion, with a coding style that is harder to extend and read than it should be. Let's distill reducers down to their essensce, and build up Redux reducers in a way that lowers complexity, and helps separate Redux idioms from your business logic.
A reducer is a pure function that accepts more arguments than it returns. That is to say - one whose "arity" is greater than 1. It 'reduces' the two things you pass it down to a single value. Here are two reducers, in a map