@ethmarks

I added the code walkthrough!

• I used Nueglow for the syntax highlighting because it’s quick and easy and I like it.
• I only annotated the two most relevant files because I didn’t want to flood the page with a bunch of walkthroughs of tangentially-related code snippets, so I had to draw the line somewhere.

I have mixed feelings about MathML.

I’d never used MathML before, and I was a little worried that it would be extremely complicated and difficult. But really, it was just tedious and verbose. The opaque syntax took a while to get used to, but it’s fairly straightforward.

I added a new section to the site, which renders the formula step-by-step using MathML, substituting the percentile and mult from the other tools.

So when you change the calculator, it also updates the formula. Once I implement the graph, moving the point along the graph will update the calculator and the formula. So it’ll all be unified.

Anyways, now I have a 340+ line Svelte file mostly comprised of a bunch of repetitive MathML tags. Usually I want to refactor really long files, but I don’t think I really can in this case.

I implemented the mult formula!

• I added the percentileToMult() function which basically just reimplements the Ruby code in TypeScript
• I added the multToPercentile() function, which performs the exact mathematical inverse of percentileToMult()
• I added 25 tests to make sure that my formula implementation was correct. I’m glad I tested it, because on my first attempt at the inverse function, I used a logarithm instead of a root 🤦
• I made a Calculator.svelte component and put it on the site, which uses the functions I made

Next I think I’ll work on the annotated Ruby code walkthrough. I also have an idea to use <math> tags to render the steps to compute the formula, which I think would be interesting.

I’ve started working on the site!

You can check it out at https://ethmarks.github.io/sdmu/

I decided that I am going to use SvelteKit, because it gets the job done and I have the most experience with it.

As usual (if you’ve seen any of my other projects, I do this a lot), I’m using a classless CSS stylesheet for the base site styles. I decided to try out Bahunya this time, because it fits the aesthetic that I’m going for.

So far, the only actual functionality is that I embedded the Desmos graph as an iframe. I plan on replacing it with my own graph ASAP, but it’ll stay for now.

Next, I think I’ll work on re-implementing the formula in TypeScript. It’s like 5 operators of basic arithmetic, so it shouldn’t take long at all, though I’ll try to make the code modular so that later I can easily implement the modifiers like blessed and cursed.

Do you wish there was a way to predict how much Stardust your project will get?

Well look no further: @The_Craw made a tool to do that over two months ago: https://www.desmos.com/calculator/ww5xp3gi52. It’s been mentioned literally multiple dozens of times in the Slack.

But do you wish that the graph had more features? No? Well too bad, because I’m making it anyways.

Here are some of the planned features of Stardance Mult Utility:

• Interactive graph of percentile vs multiplier. Like the Desmos graph, but not using Desmos. Idk what I’m going to use instead. Probably some kind of graphing component.
• Exact/direct calculator. This is for if you want an exact value rather than just estimating via the graph. If you want to know what multiplier a specific percentile will earn, then you just type it into the little box and it’ll output an answer. But it also works in the other direction, if you want to know what percentile you’ll need for a specific multiplier.
• Annotated walkthrough of the actual Ruby code that the Stardance codebase uses, so you can learn exactly how it works behind the scenes.
• Percentile calculator. I’m only like 70% clear on the exact method that Stardance uses to calculate percentile from the category ratings, so I’ll have to look through the codebase more thoroughly to figure it out. But once I do, I hope to have a way that you can convert the ratings in each category (Originality, Technicality, Usability, Storytelling) into a percentile, and then into a multiplier.
• Blessed/cursed/viral modifiers. These will modify the other tools to show what’ll happen if your ship is blessed, cursed, or viral.
• 30x max mult simulator. Did you know that the max mult used to be 30x before they changed it to 20x when they added blessed/cursed/viral modifiers?

I don’t know what tech stack I’m going to use. I haven’t thought that far ahead, lol. It’s definitely going to be a web project, and I’ll probably use SvelteKit. but I don’t know what library/component I’ll use to make the interactive graph, because I’ve never done anything like this before, so I’ll have to research it along the way.

Final devlog before ship #2

• I added difficulty ratings for each puzzle
• I moved the logic/linter output (aka the checklist) right above the “run” button because it makes more sense there
• I updated the README and added some screenshots

How the heck did this take 2 hours…

All that I did in this devlog was improve the Conway’s Game of Life puzzle a bit. I rewrote some of the starter and solution code for simplicity (I can’t believe I forgot about the .flatMap() method), and I also wrote a bunch of comments that explain the starter code and solution code.

Next, I think I’ll add a difficulty indicator for the puzzles. I think I’ll probably be ready to re-ship after that!

Hi! It’s been a while. Again.

The highlight of this devlog is the new puzzle: Conway’s Game of Life. In the feedback on my first ship, several people mentioned that they wanted more challenging levels. Well, here ya go! This puzzle is much more complex, and it also doesn’t lend itself well to functional programming, so you have to get creative in order to make the linter happy. Personally, after I designed the puzzle and wrote the starter code, it took me over 45 minutes to write the solution code. It’s pretty difficult, so hopefully it’ll satisfy the users who want a challenge.

I also made a few smaller changes:

• I removed dev.css’s light mode, because all the rest of my styling is meant for dark mode
• I set Maple Mono as the preferred font, but I intentionally made it only work if you already have Maple Mono installed, because I know that not everybody likes it
• I added a special message if you try to run empty code

Next, I think I’ll start adding comments to some of the starter code and solution code. I think it’d be helpful for users who aren’t as familiar with JavaScript or function programming, so that they can more easily get acquainted with the starter code, and so that they can learn how the solution works if they choose to use it.

I made a new puzzle! The puzzle involves implementing a Caesar cipher. That’s it, actually. It’s certainly not a very difficult puzzle, but it does contribute to puzzle variety.

Also, do you notice the new favicon? No more Svelte logo!

…i think the user would have more feedback/satisfaction if upon completion, something else happens to let them know they successfully completed a puzzle, something like confetti, or even just the “run” button changing color/text

When the puzzle states changes to “passed” (meaning the logic test and linter both passed) from some other status, I made it trigger a confetti effect via canvas-confetti and made the run button turn green.

Next, I’m probably going to make a favicon.

One thing: I can just cheese everything by changing the output manually. I recommend you use multiple test cases so i can not just type “return 6” and complete the task.

I added secretInput values to the rest of the puzzles to fix the hardcoding cheese. I also mentioned the anti-hardcoding in the README.

Next, I’m going to work on adding some confetti and whatnot for when the user’s code passes both the logic test and the linter.

Hi again! It’s been a while. I’m coming back to No Let because when I shipped it the first time, the lovely people who rated it took the time to write really thoughtful feedback and suggest great actionable improvements. So i thought it’d be fun to implement your suggestions (and also I was bored).

Here are some excerpts from the feedback I got:

One thing: I can just cheese everything by changing the output manually. I recommend you use multiple test cases so i can not just type “return 6” and complete the task.

Anyway, my biggest critique would be the lack of levels. I think that adding tiers of difficulty, along with 10-15 more levels would take this project to the highest possible level.

…svelte favicon ;)…

…i think the user would have more feedback/satisfaction if upon completion, something else happens to let them know they successfully completed a puzzle, something like confetti, or even just the “run” button changing color/text

I intend to fix/implement each one of these. With the exception of the “10-15 levels” one; that’s a bit more than I’m willing to make, but I will add some new puzzles.

So far, I’ve started implementing the first suggestion. I’m creating secretInput values for each puzzle, and in the test function, after it evaluates the input (which is publicly displayed), it runs the code again using the secretInput.

If the code passes the input check but fails the secretInput check, it fails the logic test with this message:

Failed secret anti-hardcoding check. You need to generalize your logic.

I’ve only added secretInputs for two puzzles so far, so the work is still ongoing.

This devlog was written using deci!

watch the devlog video to watch me type it

• install deci from https://github.com/ethmarks/deci/releases
• enjoy!

v1.0.0 release! Yay!

I added the following stuff:

• a new screenshot gallery to the site
• --version and --help commands to the CLI
• small tweaks to the readme
• text in the center of the header that says what file is open

I’ll write the next devlog using deci.

I finished the README, did some bugfixes and refactors, and made a demo gif using VHS.

Unless I think of more features to add, this will probably be my second-to-last devlog. I’m still planning on writing my final devlog before shipping using deci.

I wrote a first draft of the README. I’m pretty happy with it so far. I still need to add a “How it Works” section, though.

Oh and I also expanded the help screen to add more info.

I added undo and redo!

Basically, every mutative keystroke (e.g. space or backspace) makes a snapshot of the current lines and editor position and adds it to the history slice. When you press ctrl+z, it decrements historyIndex and replaces the current lines and cursor position with history[historyIndex]. ctrl+y does the same thing but the opposite.

Oh and I also added word-skipping cursor movement. If you press ctrl+left or ctrl+right, the cursor will move in that direction until it reaches a delimiter (e.g. a space or a punctuation). It took embarrassingly long to get it to work perfectly. There’s a bunch of little edge case behaviors for cursor caret movement that are really subtle and kinda unintuitive, but which you’re so used to from writing text on computers that you can instantly spot if it’s not quite correct.

I think that next I’ll start working on the README.

I added markdown previewing!

Just press ctrl+p, and it’ll switch to a new screen and render the current editor content as markdown with Glamour. The screenshot for this devlog is what the current README looks like when previewed.

It obviously works best with markdown files, but I’ve been unable to make it throw an error, even when I try to render .go files and whatnot that are definitely not markdown. I guess markdown is a pretty permissive spec.

I also added goreleaser, so it should automatically build binaries and release them for each new version now. You can check it out at https://github.com/ethmarks/deci/releases.

I think that deci is pretty close to finished. I honestly can’t think of much more to add. I still need to add that undo buffer that I promised in the first devlog, and write a README and better docs, but that’s basically it. How exciting!