Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000
fizz = function f() { | |
fizz = function () { | |
fizz = function () { | |
fizz = f | |
return "Fizz" | |
} | |
} | |
} | |
buzz = function f() { |
Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000
This entire guide is based on an old version of Homebrew/Node and no longer applies. It was only ever intended to fix a specific error message which has since been fixed. I've kept it here for historical purposes, but it should no longer be used. Homebrew maintainers have fixed things and the options mentioned don't exist and won't work.
I still believe it is better to manually install npm separately since having a generic package manager maintain another package manager is a bad idea, but the instructions below don't explain how to do that.
Installing node through Homebrew can cause problems with npm for globally installed packages. To fix it quickly, use the solution below. An explanation is also included at the end of this document.
By default when Nginx starts receiving a response from a FastCGI backend (such as PHP-FPM) it will buffer the response in memory before delivering it to the client. Any response larger than the set buffer size is saved to a temporary file on disk.
This process is outlined at the Nginx ngx_http_fastcgi_module page manual page.
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
{ | |
"name": "my-app", | |
"version": "1.0.0", | |
"description": "My test app", | |
"main": "src/js/index.js", | |
"scripts": { | |
"jshint:dist": "jshint src/js/*.js", | |
"jshint": "npm run jshint:dist", | |
"jscs": "jscs src/*.js", | |
"browserify": "browserify -s Validating -o ./dist/js/build.js ./lib/index.js", |
# read more at https://terrty.net/2014/ssl-tls-in-nginx/ | |
# latest version on https://gist.github.com/paskal/628882bee1948ef126dd/126e4d1daeb5244aacbbd847c5247c2e293f6adf | |
# security test score: https://www.ssllabs.com/ssltest/analyze.html?d=terrty.net | |
# your nginx version might not have all directives included, test this configuration before using in production against your nginx: | |
# $ nginx -c /etc/nginx/nginx.conf -t | |
server { | |
# public key, contains your public key and class 1 certificate, to create: | |
# (example for startssl) | |
# $ (cat example.com.pem & wget -O - https://www.startssl.com/certs/class1/sha2/pem/sub.class1.server.sha2.ca.pem) | tee -a /etc/nginx/ssl/domain.pem > /dev/null |
This is a short overview on how to completely remove any old mysql server installs in OSX and upgrade to MariaDB without conflicts. Things can get a bit weird when you have various old installs of MySQL server floating around, and utilizing homebrew to install and upgrade MariaDB as a drop in replacement for MySQL has worked well, especially if you're used to managing MySQL installs via yum in linux.
Backup all of your current databases with mysqldump
This isn't a tutorial on backups, and there are many ways to do it. You should know how to backup your data anyway. For this example, we'll do a full backup of our InnoDB databases.
Одна из лучших вещей в написании кода - очевидность хороших практик, ведь если им не следовать, возникает раздражение. Очень надоедает, когда вам нужно писать одну и ту же вещь снова и снова. Когда вы чувствуете себя недовольным из-за повторения одних и тех же вещей, наступает время абстракции.
В типичном приложении вы, вероятно, имеете множество Репозиториев для работы с вашей системой хранения. Когда вы используете Laravel, вы проводите много времени работая с Eloquent. Тем не менее, поверьте мне, когда у вас есть множество Репозиториев, вам быстро надоедает многократно писать одни и те же методы для доступа к данным.
В этом руководстве я хочу рассмотреть некоторые паттерны для абстракции основных методов, которые вы больше не будете повторять в каждой реализации ваших Репозиториев. Я также покажу, как мы можем использовать гибкость Eloquent и его Query Builder для написания действител
# Backup | |
docker exec CONTAINER /usr/bin/mysqldump -u root --password=root DATABASE > backup.sql | |
# Restore | |
cat backup.sql | docker exec -i CONTAINER /usr/bin/mysql -u root --password=root DATABASE | |