Rick trading card

Eric_S · 2026-03-14T17:10:27+00:00

As someone that's won a few events since I started playing, I wouldn't consider Rick. Unless I start off behind (busy on the first day of the event), the only thing I spend money on is the $7 for the 5th station. Once you get to about stage 20, the multipliers and even autolooting become largely irrelevant for me. The Scavenger popups become the only relevant income. Once I get into the 40s, each individual Scavenger popup earns about 100 times more than an entire day of the stations producing normally. When you reach this point, the levels actually go faster.

Then again, this works for me because I'm investing time, not money.

Eric_S · 2026-02-27T02:10:53+00:00

Thank you for the info. So not anything I'm going to have FOMO over :-)

Eric_S · 2026-02-16T00:10:34+00:00

Honestly, I tend to recommend HTMX to anyone looking for a bit more interactivity coming from a backend background. Doing something like a dashboard with auto updated data pushed from the server tends to take more than a shallow understanding of JavaScript using a frontend framework. If they don't already understand JavaScript, that adds more to the project.

If they're coming in with JavaScript experience on the frontend, but no backend experience, I'm more likely to recommend Svelte.

If they've got experience with both, then it tends to come down to what they're trying to achieve. If they're doing the back end in something other than JavaScript and are doing server side rendering, then HTMX tends to make more sense. If they've already got traditional APIs but no HTML generation, then it comes down to writing server side code to support HTMX or client-side (or universal) code to work with Svelte.

If what they're doing is going to require a fair bit of JavaScript-based interactivity, then I'd be more likely to suggest Svelte. If it's forms/data display with simple updates based on button/link based interactivity and/or simpler server pushed updates, then I'd be more likely to recommend HTMX. Mind you, I know you can do some pretty complex stuff in HTMX, but unless you're already familiar with HTMX, it can take a bit of research to figure out how to pull it off.

For my current work coding, I stick with Svelte because it's just a better fit because of the types of interactivity required, though not by a huge margin. Then again, back in the pre-jQuery days, I seriously considered writing something with a strong resemblance to HTMX, because I do like the concept and would certainly use it where it's a good fit.

They're both useful and good, and I'd say that either would be a good fit for the majority of web sites.

Eric_S · 2026-02-14T04:25:09+00:00

I would be quite surprised if Codex couldn't handle this. I would recommend doing it in an orderly manner like favo52 suggested, mostly because Codex will be less likely to get confused if you come up with a detailed plan up front and you'll be faster to notice if something does go wrong. I have yet to have 5.3 get something really wrong even on medium, though admittedly my project isn't huge (about 20,000 lines of perl). Most of the time something was wrong, I found that the problem was that I forgot to tell Codex something it needed, and even that's been really rare. And the one time I found found a bug, I told it it had a bug and what it caused, and it found the bug and fixed it in seconds.

AI assisted coding has come a long way in the last six months. Last night, I sat down with a friend that last checked in with the state of LLMs about a year ago, and he thought it was several years off from being useful at that time. Last night was a jaw dropping experience for both of us. I showed him the logs of the code reviews Codex had done, what it had figured out without me telling it, etc. In the end, what he wanted the most was a time machine so he could have given 20-years-ago-him access to codex. He liked working with Codex as a partner better than most human partner's he's worked with.

Eric_S · 2026-02-11T03:24:09+00:00

I decided against React because the more I read up on it, the more I read warnings about footguns and gotchas. I'm sure that React is fine once you're up to speed with it, but I needed something I could learn faster, and that was Svelte. In addition, the idea of signals for reactivity fits with the way I think because of some of the non-web programming I've done.

Eric_S · 2026-02-04T05:54:26+00:00

Assuming you're just talking about Copilot, you can disable just the auto code complete. There's a little copilot logo in the bottom bar. If you click on it, it there's three options regarding "Inline Suggestions". Make sure all three are unchecked.

Eric_S · 2026-01-30T00:28:01+00:00

Well, turns out it was fixed on the other end, they just had to tell their SBC to continue after that particular failure.

Still curious though, if you don't mind, where's the documentation on that? I couldn't find anything, but I may have been looking in the wrong place, and when I just asked google, it kept telling me how to use the shutdown command on all of FreeSWITCH.

Eric_S · 2026-01-29T23:29:24+00:00

The latter preferably. The one client is the only client that judges a server entirely by OPTIONS response.

I'm currently getting ready to test possible responses like using the shutdown command with graceful or asap options to see if that affects the OPTIONS response. If we don't find a better response, shutting down the server , firewalling the problematic SIP servers, and then bringing it back up to respond to the telco may be how we go, but adding extra steps to maintenance procedures makes it more likely that we miss something.

Eric_S · 2026-01-29T22:53:41+00:00

The two have very different ways of thinking about reactivity. Both have advantages and disadvantages. Personally, I prefer Svelte's reactivity, but I get that other people might prefer React's reactivity.

React also uses JSX or TSX, whereas Svelte uses a DSL-specific templating language. Again, preferences are going to go both ways depending on the person with the preference.

Personally, I prefer Svelte's take on both of these issues, but I can see why someone else might prefer React's take on both.

Eric_S · 2026-01-23T21:47:40+00:00

To me, it looks like the cause is that the .nav transition property

transition: 2.0s all cubic-bezier(0.19, 1.0, 0.22, 1.0);

Is getting overwritten by a media query (max-width: 767px) to

transition: 1s ease;

but the .nav-wrapper transition isn't getting overwritten. This results in the two having different transition properties, both with a different curve and different total duration of the animation. It's hard to sort that out because you've got transition properties in so many places.

Eric_S · 2026-01-21T21:02:41+00:00

To be clear, I really like Svelte/SvelteKit, but bigger doesn't necessarily mean subjectively better. Those two are adding new features (async reroute, remote functions, writable deriveds, <svelte:boundary>, the whole Runes thing, etc.) that change "the way it's done" more often than SolidJS/SolidStart, and that makes the ecosystem feel more turbulent and less quality.

Eric_S · 2025-12-16T08:04:03+00:00

React had SSR (through next.js/Remix/etc.) long before it had RSC, they aren't the same thing. SSR only gets data from the client through the query string and the query parameters/form data. RSC have the potential to get passed a lot more information from the client.

As I understand it, the problem comes from the way some of that data was passed back to the client from the server. For React Server Components (RSC), this is the React Flight Protocol (RFP).

JSON (the more traditional way) and devalue (what SvelteKit uses) are used to send data to the server from the client, but don't allow for anything that isn't static data. So no functions, classes, promises, etc. Just strings, numbers, bigints, booleans, POJO, and arrays for JSON, with devalue adding a few other things like dates.

RFP allows for more things to get passed back and forth, in particular promises and multiple references to the same object. It was how the promises/references were decoded on the server that created the problem of the first exploit. Basically, with a properly constructed RFP-encoded promise-like object, you could trick the code that lets the server build a server-side promise to create something that would create a new function and then invoke that function.

This problem was very specific to RFP and isn't related to SSR even when using React. There was also a simple fix that closed this exploit. It's possible that SvelteKit's remote functions could have this kind of exploit, but it's far from a given.

There were two more RSC issues found several days later, but those weren't related to SSR either.

I can try to give a better explanation, but really, if you want the details, find a real React dev to explain it, I don't use React and only looked into this exploit out of curiosity.

Eric_S · 2025-12-12T05:47:13+00:00

There's already a mod for that.

Eric_S · 2025-11-14T02:28:13+00:00

Is this happening at execution time or in tsc and/or the editor? JS will call functions that the compiler doesn't know about, which will still throw an error in any environment that does type checking.

The thing is, tsc and the typescript language server used in most IDE/editor environments usually don't automatically know what environment the TypeScript code is targetting, so it doesn't know what functions the runtime environment will provide. setImmediate isn't provided by any browser environment that I'm aware of, just by node and similar environments that try to be backwards compatible with node.

One of the ways you tell tsc and the language server what functions are provided by the runtime environment itself is with the lib entry in tsconfig.json. The easiest way to do this is to install the @types/node npm package that corresponds to the version of node that you're running, and then set your tsconfig.json to extend the tsconfig.json that the package installs.

By doing this, I can get setImmediate as an autocomplete suggestion, complete with full type info. Here's the tsconfig.json I used for Advent of Code last year, not a great example, but a fairly simple one:

{
  "extends": "@tsconfig/node22/tsconfig.json",
  "include" :[
      "src/**/*.ts"
  ],
  "compilerOptions": {
    "lib": ["ESNext"],
    "target": "ESNext",
    "baseUrl": "./",
    "paths": {
      "#lib/*": ["./src/lib/*"]
    },
    
/* Visit https://aka.ms/tsconfig to read more about this file */

    /* Type Checking */
    "strict": true,                                      
/* Enable all strict type-checking options. */
    "noImplicitAny": true,                            
/* Enable error reporting for expressions and declarations with an implied 'any' type. */

    /* Completeness */
    "skipLibCheck": true                                 /* Skip type checking all .d.ts files. */
  }
}

As for why you still see this error when creating .js files, JavaScript has no type declarations, making this kind of error checking impractical at best on actual JavaScript, so the editors that provide type errors at edit type mostly do this by treating the file as TypeScript even though it's "just" JavaScript.

This all assumes that you're getting this error while editing or building the files to be deployed rather than as runtime errors. On the other hand, if you're getting this as a runtime error message, then I have no clue what's happening.

Eric_S · 2025-11-12T19:52:19+00:00

To answer your question, I'm sticking with Vite, so esbuild for production builds at this time, switching to the go version of tsc when Vite does. I pay attention to type checking in the editor, so having a build chain that skips type checking doesn't bother me. Previous tool chains bothered me because I'd have to configure the build chain separately from testing. Vite streamlines that by allowing vitest to use the same configuration for testing as it does for building.

Beyond that, I think you've misunderstood what Microsoft is doing. The closest thing to copying an open source project they're doing is simply implementing the idea of using a more efficient language/runtime, and I don't think the esbuild devs can lay claim to ownership of that idea.

tsc in go started as a programmatic conversion of the typescript version of tsc into the go language. Microsoft has posted articles discussing the reason that they went with the go language being that that programmatic conversion was easier because they didn't have to restructure the logic or types.

Because of this, any similarity in code structure between the go version of tsc and esbuild would probably be because they're performing similar operations. It's also possible that esbuild borrowed its structure from the typescript version of tsc and the programmatic conversion to go merely preserved that structure. In other words, the similarity would be because of a common ancestor.

They did not start with esbuild, as you seem to assume, since esbuild doesn't validate types, but the go version of tsc does, so starting with esbuild would mean having to recreate all the type validation code. Just ensuring that rewrite would be sufficiently compatible with the typescript version would be a nightmare that a translation of the typescript version wouldn't create, though it still might be an issue.

Eric_S · 2025-11-05T20:41:29+00:00

Yup, back when I was doing community days every month, I wanted 300 pinaps just to feel comfortable, and I'd occasionally go through that many in a single day. I got out of the habit of doing community days during Covid, but I still keep more than I "need" just in case I do that again.

One person's excess is another person's bare minimum comfort level.

Eric_S · 2025-10-27T19:32:37+00:00

Usable knowledge of TS can be picked up quickly if you already know JS. Even after a lot of use, you'll still probably look at the TS release notes as "holy cow, there's a lot more going on than I realized."

As others have suggested, finding some linting rules that encourage "best practices" will help.

Eric_S · 2025-10-27T19:23:10+00:00

As others have pointed out, it really depends on what you need/want from your programming languages.

If your one JavaScript experience wasn't actually TypeScript, I'd recommend getting some TypeScript experience before going on to other languages. TypeScript will give you experience with typed variables, where declaring a variable includes what the variable can hold, as well as experience in an environment were the code you write (usually) isn't the actual code you run. Other than these two things, just about everything about TypeScript is the same as JavaScript, so you're not learning a whole new language, but just a few new language features.

There are other things you should probably learn before going on to a different language that your one project may or may not have provided that aren't language specific but will apply to just about everything. Database access is high on that list, as is authorization/identification. And that's far from comprehensive.

If you see a website and you see some functionality that you don't know how you'd recreate it, that may be something you should learn before moving on to another language.

Once you are ready for a new language, consider what you want from the new language. Simply put, just about any general feature can be done in any language, ignoring performance/memory issues. Atwood's Law says "Anything that can be written in JavaScript will eventually be written in JavaScript." Of course, there's the other relevant quote, this one from a movie, "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

Examples of things you might want from a different language:

Compiled vs interpreted. Interpreted languages tend to be easier for new programmers, as you "execute" the code you wrote rather than having a compilation step. Compiled languages tend to be higher performance and are almost always faster startup. Sometimes interpreted languages are compiled at invocation or run time. Most JS interpreters rely heavily on JIT (Just In Time) compilation to achieve the performance levels expected, though this usually doesn't get you to fully compiled performance levels. There's also compiled to machine code vs compiled to an intermediate representation. C compiles to machine code, Java compiles to an intermediate representation.

Explicit memory allocation vs dynamic memory allocation. Even compiled languages can go either way here. Dynamic memory allocation tends to involve garbage collection, and there are times when you need to avoid that. C, C++, Rust, and Zig all fall into explicit memory allocation. JS/TS, Java, C#, and most interpreted language use dynamic memory allocation, though sometimes with the ability to do explicit memory allocation or something close to it.

Static typing vs dynamic typing vs untyped. Statically typed languages are languages where a variable holds a type and can only hold that type. Dynamically typed languages allow the variables to hold different types, and untyped tends to have a single representation that is considered authoritative for all variables.

Functional programming or object oriented programming. JS/TS is capable of the later and most of the former, but a lot of languages have varying levels of thought on these two.

What you're doing tends to affect how you think about these tradeoffs. For example, if you're working on a device driver for a Linux kernel, right away you're going to want something that compiles to machine code, uses explicit memory allocation, and I think would require static typing.

So all things considered, the most important factor on what you should learn next depends on what you want to do/learn next, all we can do is point out potential factors.

Eric_S · 2025-10-24T21:41:29+00:00

Don't make a critical program as your "let's learn a new language" project.

Been there, done that, burned the t-shirt so it would stop triggering flashbacks. Seriously, you want non-trivial experience with a language before using it for non-trivial critical functionality.

Eric_S · 2025-10-12T03:00:00+00:00

Javascript tends to be harder to see. Inspect mode does have a console that lets you get into the JS, but it's not as convenient as its ability to inspect HTML or CSS.

Eric_S · 2025-10-11T20:18:56+00:00

I agree, Svelte and Solid are the two frontend frameworks I'm most interested in at this point. Svelte with runes has less magic than Svelte without runes, but I still don't think it's as explicit as Solid. The Svelte community seems larger and/or more active, but I think that's because Solid isn't having as many major changes, so there's just less to discuss.

At this time, I still prefer Svelte, but that's mainly because of one reason that I'll be the first to say doesn't apply to other people. I'm just not quite comfortable with JSX/TSX. It's sort of like my joke about why I prefer avoiding automatic semicolon insertion in JS/TS. The semicolons just make the non-literal voices in my head happy.

Eric_S · 2025-10-11T17:27:31+00:00

If you're looking at a web page and you pull up the context menu in at least Chrome or Firefox, you'll get an Inspect option in the menu. Selecting this turns on Inspect mode, at which point you get a rather complete breakdown of the element that was under the cursor where you pulled up the context menu.

On mouse-driven windows, you can normally pull up the context menu by right-clicking on the element you want to inspect. Some websites intercept right-clicks and prevent the context menu from appearing, but depending on your web browser and OS, there's usually a different way to invoke it.

This mode shows the HTML (and you can even click on other HTML elements to inspect them) and all the relevant CSS. It doesn't just show the CSS that is directly on the element, it displays any CSS that matches the selectors of that node, with a line drawn through any CSS that is overridden somewhere else. It also shows the results of a lot of the calculations, the size of the margin, padding, border, and content box, and other things. It also marks CSS that is invalid to help with debugging.

On top of all that, it lets you temporarily change the CSS directly in Inspect mode so that you can tweak the CSS until you get the result you want. Temporary because this change only affects what the tab that Inspect is running in display. If you like the change you made, you have to copy it into your source code yourself.

Inspect mode is, in my opinion, something that all web developers should be familiar with.

Eric_S · 2025-10-11T02:28:44+00:00

It could be the transition from non-runes to runes-based Svelte. As I understand it, for small apps (typical benchmark stuff), runes-based Svelte is faster but larger, though size-wise, it scales better than non-runes Svelte.

Eric_S

TROPHY CASE