This guide refers to Instantclient Version 12.2.0.1.0
Download the latest Oracle Instant Client and SDK from the Oracle website (Yeah, fuck you Oracle, you need to create an account to download the files).
http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html
If you haven’t worked with JavaScript in the last few years, these three points should give you enough knowledge to feel comfortable reading the React documentation:
- We define variables with
let
andconst
statements. For the purposes of the React documentation, you can consider them equivalent tovar
. - We use the
class
keyword to define JavaScript classes. There are two things worth remembering about them. Firstly, unlike with objects, you don't need to put commas between class method definitions. Secondly, unlike many other languages with classes, in JavaScript the value ofthis
in a method [depends on how it is called](https://developer.mozilla.org/en-US/docs/Web/Jav
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
{ | |
"workbench.startupEditor": "newUntitledFile", | |
"editor.fontSize": 16, | |
"editor.lineHeight": 1.8, | |
"javascript.suggest.autoImports": true, | |
"javascript.updateImportsOnFileMove.enabled": "always", | |
"editor.rulers": [ | |
80, | |
120 | |
], |
-
When writing a string of multiple utility classes, always do so in an order with meaning. The "Concentric CSS" approach works well with utility classes (i.e,. 1. positioning/visibility 2. box model 3. borders 4. backgrounds 5. typography 6. other visual adjustments). Once you establish a familiar pattern of ordering, parsing through long strings of utility classes will become much, much faster so a little more effort up front goes a long way!
-
Always use fewer utility classes when possible. For example, use
mx-2
instead ofml-2 mr-2
and don't be afraid to use the simplerp-4 lg:pt-8
instead of the longer, more complicatedpt-4 lg:pt-8 pr-4 pb-4 pl-4
. -
Prefix all utility classes that will only apply at a certain breakpoint with that breakpoint's prefix. For example, use
block lg:flex lg:flex-col lg:justify-center
instead ofblock lg:flex flex-col justify-center
to make it very clear that the flexbox utilities are only applicable at the

[alias] | |
ci = commit | |
co = checkout | |
cm = checkout master | |
cb = checkout -b | |
st = status -sb | |
sf = show --name-only | |
lg = log --pretty=format:'%Cred%h%Creset %C(bold)%cr%Creset %Cgreen<%an>%Creset %s' --max-count=30 | |
incoming = !(git fetch --quiet && git log --pretty=format:'%C(yellow)%h %C(white)- %C(red)%an %C(white)- %C(cyan)%d%Creset %s %C(white)- %ar%Creset' ..@{u}) | |
outgoing = !(git fetch --quiet && git log --pretty=format:'%C(yellow)%h %C(white)- %C(red)%an %C(white)- %C(cyan)%d%Creset %s %C(white)- %ar%Creset' @{u}..) |
You first need to undestand the concept of frontend tests.
You should not test the implementation but the behavior
You test like the end user
For instance, imagine a login screen with email and password inputs and a submit button
The test should input the email and the password, then click in the submit button.