First actual feature I'm letting Claude run! We worked the exploration of the updated API together, then it ran with the implementation.
I left this hanging for a long time.... good to finally have it updated!
I'm starting to learn how AI agent stuff works, and a lot of what I'm finding is that rushing them into feature development sets you up for disaster, but that having strong collaboration conversations with helpful context works wonders.
So, I'm starting by creating that context: I had a little "here's the codebase" walkthrough conversation with Claude Code, and it generated these docs as output—which came out solid from the jump, with a few tweaks from me for improved nuance.
My hope is that this can serve both as an improved starting point for human collaborators _and_ if I let future Claude instances play around in here. That's a big theme of what I've found with AI tools so far: don't try to get clever, don't expect the world, just give them the same support you'd give people—and then everybody wins 🤞
Oops, I didn't realize that the MySQL function `SUBSTRING_INDEX` always
returns the full string if the split delimiter isn't found.
This meant that, for series names like "Regal", we read the main name as
"Regal" (correct) and the variant name as "Regal" (incorrect).
This caused sort order to be incorrect for some series, e.g.,
- Prismatic Dawn: Regal
- Prismatic Dusk: Regal
- Prismatic Mirage: Regal
- Regal
whereas the main series name is meant to be first, and *does* come first
in cases like "Festive" where the main name sorts before any of the
variant names!
In this change, we update the variant name definition to return an empty
string. That way, when there's no variant name and it's just the main
series, that one sorts to the top of the series variants.
They made a small change to the API call! Fixed now!
The other NC Mall syncing stuff to get current NC cost is broken, but
that seems like a MUCH bigger change, so I won't bother just yet.
Just a small visual cleanup because I happened to click on item trades
today! We don't need to repeat "This Week" a million times. Just output
it for the first row, then hide it for the following. (We still include
it in screen reader output for semantic clarity; this is just a visual
cleanup.)
Before this change, the "Ornamental Lake with Goldies" item would fail
to preview on the item page: the iframe for the animation layer would
display an error page.
The error was:
```
Invalid Content Security Policy script-src: "https://images.neopets.com/cp/items/data/000/000/497/497366_deca9f2827/497366_HTML5 Canvas.js". Directive values must not contain whitespace or semicolons. Please use multiple arguments or other directive methods instead. (ActionDispatch::ContentSecurityPolicy::InvalidDirectiveError)
```
This is because the URL that Neopets sends us for this JS file contains
an unescaped space character. This isn't usually an issue for e.g.
loading a URL in the browser, but it's *not* valid syntax for inclusion
in a Content Security Policy.
In this change, we update our CSP code to parse URLs into
`Addressable::URI` objects, which enables us to call the `normalize!`
method, which fixes oddities like that.
The URL now correctly appears in the CSP as
`https://images.neopets.com/cp/items/data/000/000/497/497366_deca9f2827/497366_HTML5%20Canvas.js`.
Neopets.com recently added some new security rules that, if not
satisfied, cause the request to return 403 Forbidden.
We figured these out through trial and error, and added them to the
`DTIRequests` library, so they would apply to all requests we make.
We also updated our AMFPHP library to use `DTIRequests` as well, as an
easy way to get the same security rules to apply to those requests.
This change was motivated by pet loading being down for the past day or
so, because all pet loading requests were returning 403 Forbidden! Now,
we've fixed it, hooray!
Sigh, the "Valentine Plushie" series is messing with me again! It
doesn't follow the previously established pattern of the names being
"<series> <color> <species>", because in this case the base color is
considered "Valentine".
Okay, well! In this change we add `full_name` as an explicit database
field, and set the previous full name value as a fallback. (We also
extract the generic fallback logic into `ApplicationRecord`, to help us
express it more concisely.)
We also tweak `adjective_name` to be able to shorten custom `full_name`
values, too. That way, in the outfit editor, the Styles options show
correct values like "Cherub Plushie" for the "Cherub Plushie Acara".
I also make some changes in the outfit editor to better accommodate the
longer series names, to try to better handle long words but also to
just only use the first word of the series main name anyway. (Currently,
all series main names are one word, except "Valentine Plushie" becomes
"Valentine".)
I don't know how reliably people actually know that we support NC
Styles, because the token items aren't searchable.
In this change, we add a little message to teach people about this
feature, if they search for words that match known styles, or the
colloquial word "token" (even though style token items aren't actually
called that on-site).
Previously, we took the incoming date as just an integer, which was
raising a database error when we attempted to save it to a timestamp
field. Now, we correctly parse it into a timestamp.
I imagine we just haven't run the import manually while there's a real
discount in the records before? Weird!
Now that some of these series names are very long (like "Prismatic
Cocoa: Festive"), they can throw off the layout. Let's just use the
shorter one, it's clear enough!
Previously, when opening the pose picker and looking at Styles, the
Cybunny options were sorted like this:
- Default
- Celebratory 25th Anniversary
- Festive Christmas
- Nostalgic Baby
- Nostalgic Blue
- Nostalgic Christmas
- Nostalgic Darigan
- Nostalgic Faerie
- Nostalgic Grey
- Nostalgic Maraquan
- Nostalgic Mutant
- Nostalgic Plushie
- Nostalgic Robot
- Nostalgic Royalboy
- Nostalgic Royalgirl
- Nostalgic Snow
- Nostalgic Tyrannian
- Prismatic Cocoa: Festive Christmas
- Prismatic Cocoa: Nostalgic Christmas
- Prismatic Tinsel: Festive Christmas
- Prismatic Tinsel: Nostalgic Christmas
- Spooky Halloween
Now, they're sorted like this:
- Default
- Celebratory 25th Anniversary
- Nostalgic Baby
- Nostalgic Blue
- Festive Christmas
- Prismatic Cocoa: Festive Christmas
- Prismatic Tinsel: Festive Christmas
- Nostalgic Christmas
- Prismatic Cocoa: Nostalgic Christmas
- Prismatic Tinsel: Nostalgic Christmas
- Nostalgic Darigan
- Nostalgic Faerie
- Nostalgic Grey
- Spooky Halloween
- Nostalgic Maraquan
- Nostalgic Mutant
- Nostalgic Plushie
- Nostalgic Robot
- Nostalgic Royalboy
- Nostalgic Royalgirl
- Nostalgic Snow
- Nostalgic Tyrannian
Note especially the Christmas case, which is all together now! I think
it's also more in line with people's expectations for Halloween to be
alphabetically among the rest, instead of being at the bottom for being
"Spooky".
There's enough styles now that I'm starting to wonder if there's other
UI affordances worth having here, like e.g. only showing (or at least
prioritizing) styles that match the chosen color? But I don't want to
mislead people about compatibility, either.
Oh, right, silly: my previous version of this change still grouped by
zone, then mapped the zones to their labels. This didn't *merge* the
lists of appearances for zones that share the same label; just one of
the zones would win, and the others would disappear.
In this change, I just go upstream and actually group them by label in
the first place, instead of grouping by zone then trying to merge and
transform them.
For example, the "Red Knitted Beanie with Wig" occupies two different
"Hat" zones: one for behind the head, and one for in front. It's not
useful to split them up!
Instead of offering a form to request a different format, we just
render both in the HTML, and use CSS to swap between the two. Love to
see the `:has` filter come through for us!
Before this change, the sort order when searching for
"Prismatic Pine: Nostalgic" showed:
- [Added Dec 18, 2024] Prismatic Pine: Nostalgic Christmas Flotsam
- [Added Dec 19, 2024] Prismatic Pine: Nostalgic Christmas Gelert
- [Added Dec 18, 2024] Prismatic Pine: Nostalgic Christmas Bruce
- [Added Dec 17, 2024] Prismatic Pine: Nostalgic Christmas Scorchio
- <more>
This is because the Gelert was created at 11:37 NST on Dec 19, whereas
the Flotsam was created at 18:11 NST on Dec 18—but in UTC, which is how
timestamps are stored in the database, these are both Dec 19, so the
Flotsam was sorting first alphabetically.
In this change, we do a hacky transform from UTC to NST-ish. I didn't
want to set up the deploy process to pull named time zones into MySQL,
and then have this as a potential gotcha for the dev environment
later—so instead, I pretend `-08:00` is a good-enough specification of
NST.
This will sometimes create slightly incorrect sort ordering when it
*is* Daylight Savings, and a record was created around midnight. I'm
okay with that!
When there's an unlabeled style, previously we'd include the placeholder
value "<New?>" in the search dropdown, even though we don't actually
support searching by it.
Now, we don't! I did this in part by just refactoring how we look this
stuff up, with queries that don't load *all* alt styles into memory,
which will help perf a bit as more of them are released.
Oh oops, Firefox is a bit stricter about interpreting custom elements
as inline elements by default instead of block elements. This messes up
the positioning relative to the container. Fixed!
Just a wrapper for the barrier/semaphore thing we're doing constantly!
I only applied it in the importer rake tasks for now. There's other
call sites to move over to it, too!
Previously, "Then: Go to unlabeled appearance" would always take you to
the *first* unlabeled appearance in our database.
Now, we go to the *next* unlabeled appearance in the list, relative to
this one.
I've known there are bugs in the SVGs pretty often, because they're not
very well attended-to—I noticed pretty quick that the Marble Eyrie, for
example, has its Body asset saved correctly in PNG, but its SVG is just
another copy of the head, oops!
I think SVG is still a nice default for this UI, but I added a little
form to switch to PNG, to give us a debugging method and escape hatch
if it starts to get weird.
This washes out the colors a bit more than necessary on lighter pets,
but helps a lot on darker pets. It really kinda pushes everything other
than the lineart all the way to white, which tbh is a pretty neat
sketch-like effect.
I couldn't find a library for this functionality that didn't require
jQuery, and I don't want to be adding *more* jQuery requirements. So, I
decided to throw together my own!
The `<magic-magnifier>` component copies its contents into a "lens"
element, then uses basic JS to track mouse position, then uses CSS to
move the lens and its contents into a helpful position.
One thing I noticed here is that the zoom is a bit crunchy because
we're using PNG images, and it's hard to zoom in even further than we
already are. I might try switching this UI to use the SVG images by
default instead?
When you hover the row for a layer in the table, it highlights the
corresponding layer in the outfit viewer. And when you click anywhere
in the row, it opens the first link (usually the PNG image).
Sometimes I forget like, what the masc/fem variants of a given pet
actually look like? Some are super obvious about things like eyelashes,
and others use more subtle eye differences.
This is a cheap lil hack to make it easier to open a reference! Ideally
I think it would be neat to like, when you hover over an option, have
it show you the reference variant of that pose? But this is good enough
I think!
If the screen is narrow, many of the bubbles will wrap their text onto
two lines, but "Unconverted" won't. Give it equal height to the rest
anyway, for visual consistency!
We copy the same feature from alt styles, now that the UI is shared via
support form helpers! Easy peasy!
This adds a "Then: Go to unlabeled appearance" checkbox next to the
submit button on the pet appearance edit form. If checked, it takes you
to the first unlabeled appearance in the database, and keeps the box
checked for next time. Slam through 'em!
Realizing that, with the keyword argument spread syntax, I don't need
to do merging, I can just. spread at the right place!
My rationale for the ordering here is: if the caller theoretically tried
to override the builder (even though I don't see why), I think we would
want to respect that. Whereas the `class` argument should be overridden
because we're safely *merging* our `.support-form` class into it.
I want to reuse this for unlabeled pet styles is why! (That's been the
immediate motivation for this refactor, but also I do just like that
it'll make support forms easier to build.)
I think helpers are fine for the simpler ones that are basically *just*
wrapper tags, but once it starts getting into `concat`, I think that's
too unfamiliar of a syntax for developers; let's bail into our usual
templating system!
I'm not sure about putting them in `application/support_form` like this.
That's cute for one-offs like `application/hanger_spinner`, because
`render partial: "hanger_spinner"` assumes the `application` view folder
by default, but that doesn't work once it's nested: it looks for a
`views/support_form` folder.
I think maybe it could soon be time to bail from the strict "view
folders belong to controllers" thing, similar to how we did for
`SupportFormHelper`, and add a `components` folder or similar? Idk, not
sure yet!
Ah right, `> label` doesn't work with how Rails will wrap broken labels
and inputs each in a `.field_with_errors` element. Fixed, and added
some basic coloring!
Instead of hand-rolling HTML, this offers helpers like `f.field`, to
help ensure the HTML is consistent, and to keep the templates more
focused on the unique form elements.
Most notable change here is extracting the pose option bubbles into a
`data-type="radio-grid"`, and pulling that into the `.support-form`
CSS. My rationale is that, unlike most fields, this field benefits from
being 100%-width, and I don't want to specify that as an override if I
can avoid it, because that's fragile-y.
Instead, I extract this into a generic type of field that
`.support-form` can use (it feels pretty reusable anyway!), and require
the caller to specify how many columns they want as `--num-columns`.
Specifically, I'm going for a more-vertical layout, cuz I want to bring
PetState over to it, and the weird grid situation wasn't gonna fit the
big pose label radios.
There's still plenty left, but we have 213 we "manually" marked as
"done" (I think I ran a batch job on everything Chips told me was on
the page and already done), and that should help a lot!
This keeps causing missing-attribute crashes when I change things, and
I don't think the performance benefit is a big deal for how the page
currently runs, esp as we keep gathering more attributes? I feel like
`description` is the main "large" one we're omitting, and like. Shrug!
Been running into the item "Hanging Plushie Grundo Background Item" not
being modelable, because TNT seem to have left its description blank!
Let's be less picky about what data we take in, but keep the intention
of these validations: to ensure that *we* don't make a mistake and
forget a field when importing items!
This is a basic attempt at the Vandagyre logic, but also things like
"Maraquan items released before the Maraquan X was released"!
I also added a new task, `rails items:update_cached_fields`, which needs
to be run after this change, because it affects the value of
`Item#predicted_fully_modeled?`.
Eyeballing the updated search results for `-is:modeled`, this feels
pretty close? I'm guessing it's not perfect (e.g. maybe a pet type we
got modeled late into its existence, or some items that just never did
fit a certain pet), but feels pretty good.
I also know we had the "modeling hints" override in Impress 2020, which
we aren't reading yet. We should probably take that into account here
too!
We're now caching `predicted_fully_modeled?` on the database record, so
we can query by it in the database!
I'm moving on from the model I did in Impress 2020, of writing really
big fancy single-source-of-truth queries based on the assets themselves.
I see the merit of that in terms of theoretical reliability, but in
practice I think it will be *more* reliable to have one *in-code*
definition of modeling status (which we need anyway for generating the
homepage modeling requests), and just save that in a queryable way.
In our tests, I discovered an unexpected behavior where calling
`item.swf_assets << swf_asset` wasn't updating computed fields
correctly.
This isn't something we actually do in-app, I think the modeling system
happened to trigger the callbacks in a way that still worked fine?
But I think this is a good idea for reliability, since caching is such
a notoriously difficult thing to get right anyway! And it makes our
tests simpler and clearer.
Specifically, `compatible_body_ids` references `swf_assets`, which, I'm
kinda surprised, *doesn't* include the newly-added asset yet when the
`ParentSwfAssetRelationship.after_save` hook runs while calling
`item.swf_assets << swf_asset`. Reloading it fixes this!
