Anybody who's worked with it for any length of time knows that the charts contained are good enough for jam session purposes but either contain inaccuracies when compared to the canonical versions of songs or may have been based on the "wrong" (according to some) canonical versions. Working this out means developing your ears and listening both to the original recordings and to the musicians you're playing with in a given situation. Many people end up in a place where they're just using their ears and memory to skip the book entirely, which in some situations is an essential skill.
Most level-headed people I think regard the book as a useful tool, a step in the growth journey. As egos and insecurities enter the mix you'll occasionally find somebody who'll proclaim that the Real Book is purely a crutch and you should start and end with the ear-training bits or you're "doing it wrong".
Most canned foods are heated as part of the canning process, aren't they? There are a handful of things that intentionally contain live cultures -- yogurts, some sauerkrauts & similar -- but otherwise I'd expect almost any canned food to have been packed hot or heated in the container during canning in order to kill food-spoiling organisms.
Given the timing the remaining 32 could plausibly just be the set of people who are hard OOO for the (US) Thanksgiving holiday week -- on airplanes, in cars, or otherwise indisposed and out of touch with 'work news' for a few days.
Imagine going on vacation from your extremely well paid silicon valley AI job, just to find the company gone and that everyone around you quit a few days ago. I'm sure that happened a few times already but it's not a situation I'd like to find myself in.
I suspect I'm not alone in saying this, but having started my "tech" career in marketing/eCommerce agencies, I have _definitely_ worked in organizations where the sales team would sell absolutely anything they could get somebody to agree to buy -- fully ignorant of whether it had been (or even COULD be) built.
sell absolutely anything they could get somebody to agree to buy
Yes. In my humble opinion, selling a non-existent product is really just a scam --- being perpetrated against the customer as well as the producer/seller in some cases. The sale isn't complete until the product is delivered.
But the salespeople don't care --- and apparently, neither do the execs who reward them with bonuses for their fake sales numbers. If the non-existent product doesn't materialize on schedule, it's obviously not the sales person's fault.
Just further illustrates the inherent bias that I mentioned.
oh dear, I thought that was common only in my own marketing-in-tech career! My solution was to move away from the agency and to the agency's vendors, instead. Worked so far, a decade on!
I work on sales/customer facing side of a non-tech industry, but my experience has been different than root comment. My industry is engineer/finance driven, with sales as more of an afterthought or necessary evil. I try to stay tied in with the development/production side as much as possible for sales, but the mismanagement and culture rot on the development/production side has me looking for a new job as it spreads through the company. It’s tough seeing top performers leave/forced out and petty politics and mismanagement take over. It makes my job much harder. The rot has eventually trickled down to other departments, so I think it’s time to make an exit.
> It doesn't throw a bunch of alien syntax at you, expecting you to decipher it like an ancient scroll
Sounds promising, but the first examples contrasts a React `useEffect` hook (a simple function call, into which you pass a callback and a dependency array) with
- Oh, is `$` a label? [I googled this to confirm it is]
- I thought JavaScript didn't have a `goto` statement? [I googled this to confirm it doesn't]
- How does this ever get invoked? [I still don't know the answer to this question -- MDN says that labels can only be used with `break` and `continue` statements]
- Does it get invoked only when `count` changes?
- If so, how?
- If not, how do I specify the dependencies?
It might 'just work', but it's also not 'just JavaScript'.
Initially the same way it would without the $: { ... } wrapper - that is true both for Svelte and vanilla JavaScript.
> Does it get invoked only when `count` changes?
It's invoked whenever a named variable that is mentioned in the block is explicitly assigned to.
That's the whole "magic" here really. It's "just" JS in the sense that there's no additional syntax introduced that would make it incompatible with any of the available JS parsers, so by extension TS parsers as well.
Sure -- I did run that code in a JS REPL and saw that it invoked the block immediately, but that isn't necessarily what I want if I'm writing reactive code. I then tried typing `break $` and `continue $` and got SyntaxErrors for my trouble, confirming my hypothesis that this couldn't be plain JavaScript of the sort I was familiar with.
> It's invoked whenever a named variable that is mentioned in the block is explicitly assigned to.
This makes sense in the sense that it's a contract that I can accept and use, but it does imply the existence of a parsing pipeline & runtime of unknown (to me) complexity & capabilities -- exactly the sort of thing a prospective user of the framework would need to learn about sooner or later.
Well, yeah - there's a reason why it's called a framework-compiler.
In any case you can always just look into the unminified output where you'll see how your code is instrumented - it even includes comments detailing which variables are being dirty-checked.
JavaScript syntax, yes, but with Svelte semantics rather than JavaScript semantics. Everything else follows from that point. It gets invoked by the Svelte compiler transforming it. In order to work, `count` must have been defined as a property (`let count` or `export let count`), so that the compiler can run that code again when `count` changes. Reactive dependencies are specified purely by mention of their names. (Well, there’s stores too, via the $ prefix on variable names.)
> It might 'just work', but it's also not 'just JavaScript'.
Via magic: Reactive blocks are ordered via simple static analysis at compile time, and all the compiler looks at are the variables that are assigned to and used within the block itself, not in any functions called by them.
Goto is control flow. You can’t do control flow with function calls in the sorts of languages we’re talking about, so goto has to be built into the language, typically as a statement.
(In some of these languages you can do awful hacks like using hooks intended for debuggers <https://entrian.com/goto/> or rewriting bytecode <https://github.com/snoack/python-goto>, and frankly what Svelte does is quite similar, just implemented as a compilation step rather than at runtime.)
One could just as easily say that "[foot] traffic flow is more important than being able to [drive] anywhere you want", and in some locales that attitude may serve to benefit more people than the inverse. It's not a given that cars must be the default mode of transportation, but the idea that this _is_ a given is ingrained in the public conversation about infrastructure due to precisely the sort of propaganda the original commenter in this thread was talking about.
> Do vim users know if there was anything like Select next occurrence in vim?
As noted in a sibling, you can press * (shift+8) in normal mode with your cursor over a word to find the next instance of the word. This also updates the search pattern so you can use n and shift+n to navigate forward and back between matches.
If you combine this with other bits of the vim "grammar" (which I do think encourages a kind of feature discovery, although I agree there's a large learning "hump" to get over to take advantage of it), you can use something like cgn to change the currently-focused search match, n to navigate to the next search match, and . to replay the command.
So while it's not exactly the same as multi-cursor, you can achieve something very similar (and just as fast) with the following sequence:
1. In normal mode, place the cursor over the symbol you wish to edit
2. Press key: \* (read: "find the next occurrence of the current symbol and update the search pattern to be that string")
3. Press keys: cgn (read: "change the search match under the cursor")
4. Type the new symbol
5. Press ESC to return to normal mode
6. Press keys: n. (read "find the next occurrence of the search pattern [set in step 2] and repeat the last command [the edit from steps 3-5]")
7. Repeat 6 until all symbols are replaced
Or, in raw keystrokes, I might replace all six "foo"s in a document with "bar" by typing the following sequence of characters (having placed the cursor over a "foo"): *cgnbar<ESC>n.n.n.n.n.
It may seem complex compared to something like multi-cursor editing, but the nice thing here is that there are concepts here that are extensible beyond the scope of that specific edit, and can yield similar "speedy" workflows but on a much wider set of tasks.
- c[something] is a pattern that means "change [the given region]", so you could construct similar commands with different regions (`ciw` to change inside the current word, `ca{` to change the current curly-bracketed region (inclusive), and so on)
- [something]gn is a pattern that means "[do something] to the next search match", so you could delete it with `dgn`.
- . can replay many types of commands, so if I have a more complex sequence of edits to apply starting at a search match, I could do that too (not just simply replacing the symbol).
I've seen fairly commonly in developing suburban scenarios something like "a through street with a new -- but very low-traffic -- intersection with a cross street". People are accustomed to driving fast on the through street, increasing the risks of the conflict at the intersection, but 99% of the time there is no conflict.
The easy solution that's often chosen is to add a stop sign to these intersections, but this tends to result in largely-unnecessary stopping and starting, which then tends to increase the number of conflicts (because the traffic on the through street tends to congest at the new stop rather than passing quickly through it).
A better solution would address the nature of the risk -- speed -- more directly. Traffic calming techniques like narrowing the road, or deflection (manufactured bends in the road or speed humps) would improve outcomes for all road users more than a stop sign that creates congestion (and therefore conflict).
I set it up a couple of months ago as well and as I recall I went from zero to "up and running" in an hour or two — I usually wake up a little earlier than my wife and I'd finished setting it up by the time we were ready to make breakfast. The ArchWiki page (https://wiki.archlinux.org/index.php/Pi-hole) was a useful reference for the few snags I encountered.
Given that he started publishing games before he was 20 and had produced Commander Keen, Wolfenstein, and a couple of Dooms before he was 25, I'd guess he was well on his way in his teens.
Not to say that success correlates with skills, I suppose, but he's fairly well-regarded as an innovator from an early age. Odd choice of example from the article's author.
Most level-headed people I think regard the book as a useful tool, a step in the growth journey. As egos and insecurities enter the mix you'll occasionally find somebody who'll proclaim that the Real Book is purely a crutch and you should start and end with the ear-training bits or you're "doing it wrong".