In general it's not a big change. You should only turn on YJIT for long-running jobs -- the prod Rails server, plus probably background workers if you have them. YJIT does nothing unless you turn it on with the --yjit flag.
YJIT's going to affect memory usage, so it'll change your optimal number of processes and threads for your Rails server - play with it for your app specifically, because the percent speedup and mem expansion vary a lot from app to app. YJIT works fine with Puma and Webrick. I don't think anybody's tried it seriously with less-common servers like Falcon or Thin, but I'd expect it to work -- file a bug if it doesn't, because it should.
YJIT does speed up Rails - we're seeing about a 20%-25% speedup on little "hello, world" Rails apps (see: https://speed.yjit.org/), and about 11% on Discourse for a single thread. We don't have good multithreaded or multiprocess numbers yet, but it's in the works. YJIT scales with multiple threads/processes just like existing CRuby.
(All speed numbers are accurate as of right now, but may change over time.)
I would probably not use it in dev mode. While YJIT has pretty good warmup numbers, Rails throws away all existing application code for every request in dev mode. That's going to make YJIT a lot less useful. Play with it -- maybe I'm wrong for your app, especially if you use a lot of non-reloaded code (e.g. methods inside gems.) But I wouldn't expect great results in the development RAILS_ENV.
For deployment the short version is: add --yjit as a command line parameter in production mode and (probably) for your background workers. You can do this with "export RUBYOPT='--yjit'" or use your local preferred way.
Where I give weaselly-sounding qualifiers like "probably," that's because it can depend on your config. If you have plenty of memory but are often CPU-bound, YJIT is usually good. If you have really limited memory and your server CPUs are mostly idle, YJIT is usually bad. YJIT is also currently x86-only and runs on Mac and Linux but not Windows.
There has been a lot of historical demand for a Ruby config for servers: something that uses more memory to get faster operations, and that is optimised for long-running processes. YJIT is aimed directly at that. Non-JITted CRuby is mostly the opposite: fast startup, modest memory requirements, doesn't get significantly faster over time.
It may work a bit better now, but it's still very much not tuned for that. The result would probably still be slower than not JITting, for the same reasons mentioned for 2.6 in that link.
Nope, that's not what Bootsnap does. Bootsnap caches the pre-parsed .rb files as ISEQs (bytecode buffers.) It's conceptually a bit similar but not the same.
Weekly one-on-ones are pretty common in companies I've been part of, and GitHub has a lot of remote workers. Weekly one-on-ones seem more likely than not, in general.
Consider just-you personal retrospectives. Do them at the end of sprints or projects, and consider a weekly one. I do this both professionally and for personal stuff.
Where are you at geographically? I've never had good luck with the local recruiters in Silicon Valley, but maybe they're better in places with less info about market rates?
That's a very solid list of submissions. Every fourth-or-so submission has hundreds or thousands of points. If you feel that's not great... Dunno. You're using a different yardstick than I am. That looks a lot like people consider his name to add credibility.
I got a raise of around $30,000 as a result (ish, hard to measure) of writing my technical book. I'm also sufficiently well-known that I'm unlikely to ever have trouble getting a Ruby job. That's hard to quantify exactly, but I think it's fair to say it's worth $5,000-$10,000 annually, as a rough equivalent.
(My book sells for around $30-$40 rather than $15, but the math is similar.)
At his price point, he'll probably get a continual trickle of customers. I sell a book called "Rebuilding Rails" -- not as successful as his, but I've also made a few tens of thousands of dollars, so not nothing. And I reliably make a few more thousands of dollars yearly, years after I wrote it.
After Ruby is a "hot" language (years ago), it becomes a legacy language where companies will pay money for assistance with their products. In the $10-$15 niche, you need individual engineers to think a language is neat. In the $40-$10,000 niches, you need companies to think they can save some engineering time.
If they've prepared a counter at $140, there's a decent chance they're (quietly) allowed to haggle up to some larger number, say between $145 and $160 depending on how much they want you and how much they expect you to negotiate.
They won't tell you what this higher number is under any normal circumstances, and may lie about it, but it probably exists.
They do. But separating those two roles and having two different people make those decisions tends to result in less-than-optimal decisions. It's the same kind of problem as "let's have the tech done by engineers and the business done by business people," and then your business gets bulldozed by a competitor whose CEO does understand engineering.
Call/cc is actually used by Sinatra for its error handling. There's not a good way to get its syntax without doing it that way.
(Is the syntax worth using call/cc? Eh, good question. But Sinatra's killer feature is, literally, its syntax, so I don't think I get to tell them "don't do it that way." Rails has an ugly workaround for not using call/cc that bites many, many app programmers who forget to return after calling render().)
If you read the article, there are a number of characteristics of Zika that make it a lot easier to vaccinate against. Also, apparently they do have vaccines against some strains of Dengue.
Cassandra, for instance, makes it possible to query your join-type tables in relatively manual chunks using slice queries. You have to do a lot more of it in the application so you wind up with weird partial failures...
But at scale, weird partial failures, results as they are found and eventual consistency are usually preferable to a really long DB query that never returns.
Above a certain scale, big joins are simply not usable. NoSQL's manage-it-yourself approach is good for getting partial results where full results are too expensive.
You can think of it as applying a heuristic approach where an exact approach is too expensive, if it makes you feel less like NoSQL sullies the purity of databases :-)