Charts are from different sources and thus colors are inconsistent, please carefully read the chart's legends.
Like this? Check React Native vs Flutter: https://gist.github.com/tkrotoff/93f5278a4e8df7e5f6928eff98684979

version: "3.6" | |
services: | |
my_sql: | |
image: mysql:5.7 | |
volumes: | |
- ./data:/var/lib/mysql | |
secrets: | |
- my_secret |
Charts are from different sources and thus colors are inconsistent, please carefully read the chart's legends.
Like this? Check React Native vs Flutter: https://gist.github.com/tkrotoff/93f5278a4e8df7e5f6928eff98684979
This is a simple way of importing MySQL database in Docker.
In you Dockerfile you must have a shared folder. Shared folder is a directory in your host machine that is mounted to Docker instance.
Put the exported sql file in the shared folder.
Login to your Docker instance via docker exec -it DOCKER_CONTAINER_ID bin/bash
.
Login to MySQL via mysql -u USERNAME -p
.
<?php | |
class DateTimeImmutabilityExample | |
{ | |
private $date; | |
/** | |
* Intentionaly no type hinting so you can test with both DateTime and DateTimeImmutable | |
*/ | |
public function __construct($date) |
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log
in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
node { | |
echo 'Results included as an inline comment exactly how they are returned as of Jenkins 2.121, with $BUILD_NUMBER = 1' | |
echo 'No quotes, pipeline command in single quotes' | |
sh 'echo $BUILD_NUMBER' // 1 | |
echo 'Double quotes are silently dropped' | |
sh 'echo "$BUILD_NUMBER"' // 1 | |
echo 'Even escaped with a single backslash they are dropped' | |
sh 'echo \"$BUILD_NUMBER\"' // 1 | |
echo 'Using two backslashes, the quotes are preserved' | |
sh 'echo \\"$BUILD_NUMBER\\"' // "1" |
Hi there! Since this post was originally written, nvm
has gained some new tools, and some people have suggested alternative (and potentially better) approaches for modern systems. Make sure to have a look at the comments to this article, before following this guide!
Trickier than it seems.
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
select.form-control + .chosen-container.chosen-container-single .chosen-single { | |
display: block; | |
width: 100%; | |
height: 34px; | |
padding: 6px 12px; | |
font-size: 14px; | |
line-height: 1.428571429; | |
color: #555; | |
vertical-align: middle; | |
background-color: #fff; |
Note: I've left some of the full package names in tact to show exactly where the class comes from. | |
#### Pull dependencies in using composer #### | |
//Example composer.json | |
{ | |
"require": { | |
"symfony/config" : "2.1.0", | |
"symfony/yaml" : "2.1.0", | |
"twig/twig": "1.9.0", |