-
Open the Terminal
-
Use
mysqldumpto backup your databases -
Check for MySQL processes with:
ps -ax | grep mysql -
Stop and kill any MySQL processes
-
Analyze MySQL on HomeBrew:
brew remove mysql
| #!/bin/bash | |
| # | |
| # Purpose: manually associate missed renames in merge conflicts | |
| # | |
| # Usage: git merge-associate <our-target> <base> <theirs> | |
| # | |
| # Example: After a failed rename detection A/a -> B/b which results | |
| # in CONFLICT (delete/modify) for A/a and corresponding "deleted by us" | |
| # messages in git status, the following invocation can be used to manually | |
| # establish the link: |
| var isoCountries = { | |
| 'AF' : 'Afghanistan', | |
| 'AX' : 'Aland Islands', | |
| 'AL' : 'Albania', | |
| 'DZ' : 'Algeria', | |
| 'AS' : 'American Samoa', | |
| 'AD' : 'Andorra', | |
| 'AO' : 'Angola', | |
| 'AI' : 'Anguilla', | |
| 'AQ' : 'Antarctica', |
When [Markdown][markdown] appeared more than 10 years ago, it aimed to make it easier to express ideas in an easy-to-write plain text format. It offers a simple syntax that takes the writer focus away from the formatting, thus giving her time to focus on the actual content.
The market abunds of editors to be used for help with markdown. After a few attempts, I settled to Sublime and its browser preview plugin, which work great for me and have a small memory footprint to accomplish that. To pass the results around to other people, less technical, a markdown file and a bunch of images is not the best approach, so converting it to a more robust format like PDF seems like a much better choice.
[Pandoc][pandoc] is the swiss-army knife of converting documents between various formats. While being able to deal with heavy-weight formats like docx and epub, we will need it for the more lightweight markdown. To be able to generate PDF files, we need LaTeX. On OSX, the s
| import * as mongoose from 'mongoose'; | |
| export let Schema = mongoose.Schema; | |
| export let ObjectId = mongoose.Schema.Types.ObjectId; | |
| export let Mixed = mongoose.Schema.Types.Mixed; | |
| export interface IHeroModel extends mongoose.Document { | |
| name: string; | |
| power: string; |
| .rounded-corners-gradient-borders { | |
| width: 300px; | |
| height: 80px; | |
| border: double 4px transparent; | |
| border-radius: 80px; | |
| background-image: linear-gradient(white, white), radial-gradient(circle at top left, #f00,#3020ff); | |
| background-origin: border-box; | |
| background-clip: padding-box, border-box; | |
| } |
This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:
- TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
- In the wild, we're seeing
(async main(){...}())as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems - Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.
I'll leave the rest of this document unedited, for archaeological
Follow-up to Top-level await is a footgun – maybe read that first
Here are some things I believe to be true:
- Static module syntax is beneficial in lots of ways – code is easier to write (you get better linting etc) and easier to optimise (tree-shaking and other things that are only really possible with static syntax), and most importantly, faster to load (it's trivial for a module loader to load multiple dependencies concurrently when they're declared with a static syntax – not so with imperative statements like
require(...)orawait import(...)). - App startup time is perhaps when performance is most critical. (You already know this, I don't need to cite the studies.)
- If you're in favour of constructs that jeopardise app startup time, you are anti-user. Top-level
awaitis such a construct.
A lot of people misunderstood Top-level await is a footgun, including me. I thought the primary danger was that people would be able to put things like AJAX requests in their top-level await expressions, and that this was terrible because await strongly encourages sequential operations even though a lot of the asynchronous activity we're talking about should actually happen concurrently.
But that's not the worst of it. Imperative module loading is intrinsically bad for app startup performance, in ways that are quite subtle.
Consider an app like this:
// main.js