in case you haven't docker installed, please follow this instruction https://docs.docker.com/engine/install/ubuntu/
Create daemon.json
file in /etc/docker
, with content:
{"hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]}
in case you haven't docker installed, please follow this instruction https://docs.docker.com/engine/install/ubuntu/
Create daemon.json
file in /etc/docker
, with content:
{"hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]}
I have used WebStorm at work for the past three years. But last month I used VSCode exclusively for four weeks, because I wanted to learn it. I noted my observations here.
Eventually, as a deadline approached, I switched back to WebStorm. Why? VSCode is very good, and I was impressed. But I still find WebStorm is slightly better at a few things which I use very frequently. These small improvements really add up when I'm trying to get stuff done.
In keeping with the Pareto principle, small advantages with only a few commonly used features are enough to make one editor stand out for me. Specifically, "Go to Definition/References", "Searching" and "Carrying imports" are so important, that just making these more convenient means that all other concerns are irrelevant.
So, for the reader's convenience, these are the first few features I will address below.
<!-- Strip tags from post content and filter through truncate --> | |
{{ function("strip_tags", post.content)|truncate(50) }} |
// Disable Mouse scrolling | |
$('input[type=number]').on('mousewheel',function(e){ $(this).blur(); }); | |
// Disable keyboard scrolling | |
$('input[type=number]').on('keydown',function(e) { | |
var key = e.charCode || e.keyCode; | |
// Disable Up and Down Arrows on Keyboard | |
if(key == 38 || key == 40 ) { | |
e.preventDefault(); | |
} else { | |
return; |
{ | |
"name": "spakkionu/validate", | |
"description": "Validation Test", | |
"require": { | |
"illuminate/validation": "~4.2.9" | |
}, | |
"license": "MIT", | |
"authors": [ | |
{ | |
"name": "Jonathan Bernardi", |
The three design patterns (Adapter, Facade and Bridge) all produce the result of a clean public API. The difference between the patterns are usually due to a subtle context shift (and in some cases, a behavioural requirement).
The primary function of an Adapter is to produce a unified interface for a number of underlying and unrelated objects.
You will notice this pattern being utilised in many applications. For example, ActiveRecord (the popular Ruby ORM; object-relational mapping) creates a unified interface as part of its API but the code underneath the interface is able to communicate with many different types of databases. Allowing the consumer of the API to not have to worry about specific database implementation details.
The principle structure of this pattern is: