| #!/bin/sh | |
| # Converts a mysqldump file into a Sqlite 3 compatible file. It also extracts the MySQL `KEY xxxxx` from the | |
| # CREATE block and create them in separate commands _after_ all the INSERTs. | |
| # Awk is choosen because it's fast and portable. You can use gawk, original awk or even the lightning fast mawk. | |
| # The mysqldump file is traversed only once. | |
| # Usage: $ ./mysql2sqlite mysqldump-opts db-name | sqlite3 database.sqlite | |
| # Example: $ ./mysql2sqlite --no-data -u root -pMySecretPassWord myDbase | sqlite3 database.sqlite |
Этот документ является выражением инциативы расширенного использования заголовка Pragma для указания серверу явным образом возможностей и предпочтений пользователя, касающихся представления и поведения документа HTML.
Этот документ не является нормативным.
Sometimes you want to have a subdirectory on the master branch be the root directory of a repository’s gh-pages branch. This is useful for things like sites developed with Yeoman, or if you have a Jekyll site contained in the master branch alongside the rest of your code.
For the sake of this example, let’s pretend the subfolder containing your site is named dist.
Remove the dist directory from the project’s .gitignore file (it’s ignored by default by Yeoman).
When connecting to a remote server via SSH it is often convenient to use SSH agent forwarding so that you don't need a separate keypair on that server for connecting to further servers.
This is enabled by adding the
ForwardAgent yes
option to any of your Host entries in ~/.ssh/config (or alternatively with the -A option). Don't set this option in a wildcard Host * section since any user on the remote server that can bypass file permissions can now als use keys loaded in your SSH agent. So only use this with hosts you trust.
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <title>Async test</title> | |
| <meta charset="utf-8"> | |
| </head> | |
| <body> | |
| <pre></pre> | |
| <script> |
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.
| #!/usr/bin/env python | |
| """ | |
| Converts Internet Explorer 'capture network traffic' XML to a HAR file. | |
| Turns out that XML is just a HAR file anyways, but in XML form. So this | |
| just converts it to JSON, and Bob's your uncle. | |
| Requires Python 2.7+ and LXML. | |
| """ | |
| from __future__ import unicode_literals |
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.