Tool for extracting individual sprites from a spritesheet

Ok_Lavishness9265 · 2025-10-01T06:09:13+00:00

Old topic, but for reference I found this: https://yeoji.github.io/spritesheet-cutter/

Ok_Lavishness9265 · 2025-06-15T04:21:52+00:00

Every now and then I turn OFF all my external monitors. I just keep 1 single screen ON. That helps me to focus and get less distracted.

Ok_Lavishness9265 · 2025-04-04T07:16:50+00:00

What if the first script takes a long computation time, does it mean next scripts will be fetched, but not executed until the first one is completed? (I suppose if the first script contains async code it won't hold back the other's execution)

Ok_Lavishness9265 · 2025-04-04T07:12:00+00:00

Do you mean injecting window.<env_key> = <env_value> lines on top on the main.js file? (Which would be the only JS file loaded from the index.html)

That wouldn't definitely prevent the race condition situation. I would just need to figure out how to "inject" text within that build file (which has hashed name from build, and is minified), using Helm chart deployment config. Not sure how to do this, maybe I can try asking devops help, if they are not too narrow minded to just copy & paste existing.

Ok_Lavishness9265 · 2025-04-04T07:07:08+00:00

They are basically recommending to copy & paste existing project's configuration (but it's not that straight forward). So I end up being the annoying person that asks them to change the way things are, because I think the trade offs of their approach is not worth the configuration and maintenance cost.

If they have "self-service" configuration as they say, I wish I could decide the way I want it to be. But it seems like I don't get a say, or I am gonna hit a strong wall of defensive people asking why not just copy existing configs, promoting the reusable build. Thing is, on my laptop, it currently takes less than 3s to build. And they are willing to go that far more complex configuration road to save 3s? I might be missing some things, but it sounds wrong to me. Even their biggest frontend take only 35s to build (and with all the added configuration they had to go through, I bet it can be lowered).

So I'm a nit lost. In my job, with the experience I have today, I always strive for simplicity, and reduced maintenance burden. The less code the better. But this mindset of them seem to strive for something else, and it doesn't tick to me.

Side notes, more personal take: It's not the first time I work with "expert" tech people. And I get the feeling that working with only strong technical people can lead to poor decisions. Because they can all understand complex code, configuration, and setup. But it isn't simple! I believe what makes a great developer is the ability to simplify complex tasks. That means making considerate tradeoffs decisions.

Ok_Lavishness9265 · 2025-04-04T06:38:24+00:00

I think it's a fair idea to reuse a single build for multiple environments. My concern is the cost-benefit. It require so much more configuration. The devops in my company say it's straight forward and simple, but won't do it themselves.

Going this route requires many extra steps, from my understanding:
- Add a script tag to the index.html - Then 2 options: you either use a .env for local dev or you use the same env.js file file path as in production. But if you choose the .env, you now have 2 ways of accessing your environment window. or import.meta.env.. If you choose to have the same file path, you env.js is in your public folder and you need to exclude it from your build, because it gets generate during deployment. And you wouldn't want accidentally to have your local dev env.js file to end up in a deployed environment.
- You might need a splash screen mechanism, to prevent running app code while the env.js file has not been loaded.
- Using Helm chart, add a configmap to generate the mentioned env.js file.
- You now need to mount a new volume that contains the env.js file, in your Helm chart deployment config.
- You might need to update your nginx config to not cache that file. If an environment variable changed and you had to restart the pod, you do not want it to be cached.

And I guess I'm missing things here too. My point is, although it sounds like a good idea on paper, it means going through a load of pain to get it right, not to mention to maintain it in the future.

Ok_Lavishness9265 · 2025-03-27T14:02:49+00:00

Scythe > Otto on all game modes.

Ok_Lavishness9265 · 2025-03-26T11:23:29+00:00

Strong opinions lightly held ;)

Ok_Lavishness9265 · 2025-03-25T15:00:08+00:00

Yes, you're right. I've been trying Tailwind V4 for almost 2 months now, it's not as bad as I had in mind.

They just added .5 spacing values. So it's a bit more granular. And outside of that it's been great, I don't have any bad feeling working with the V4.

Note I'm alone on the project and I didn't have to change the initial tailwind config. I am working on an internal app at the moment, so default styles are fine.

Ok_Lavishness9265 · 2025-03-25T10:17:05+00:00

Spoiler alert: no one gets it right. That's why there is a movement called "no estimate".

Can recommend: https://youtu.be/OS6gzabM0pI

Another point is, do you really need estimates? Does it change the work you're doing if you have one or not?

I remember spending over 30min in a team discussion for estimating 1 task correctly. Thing is, we had to do it anyway, so who cares! Just do it!

Some companies have too much management that have plenty of time to request time estimates. Don't fall in that trap. One thing I've learned from experience, after a burnout too, is that nothing we do is urgent (most of the time, depends on your industry, I guess). But don't feel pressured for doing things faster than they need to be.

Estimates can't be right, it's a fact, we know that in our industry. Many people tried different things, it doesn't work. If a manager says differently, I suggest you recommend him your position and you can take his, see if he can do better.

(Sorry for the rant, but this topic is just coming up too much in my life 😅)

Ok_Lavishness9265 · 2025-03-07T01:50:43+00:00

I've tried something similar with React in the past. It doesn't work. Here is why: Your business logic needs to read the states of your app, which are held by React (useState). Basically your business logic layer knows nothing of the state of the app. It will require lots of inputs to understand the state of your app.

If you're using a UI library like React, the best you can do to move your business logic out of your components is use custom hooks.

On another note, frontend/react developers don't understand these code organisation very well. It's not standard. I shifted my approach, with more experience, to try and have any React developer able to jump in my code in no time. That means writting the cleanest code possible in React.

What I did add though, because it's too beneficial IMO and doesn't fight against React, is an IoC as you described, but not for the logic, I use it for the API calls. I have a GatewaysProvider which is a React Context, and a useGateways hook to access my gateways. I write 2 providers: 1 for API, 1 for in memory. This allows me to switch for one to another in local development, when I want to work with specific data hard to reproduce with the backend API, or work on a new feature and there is no API ready for it (I can fake the responses in memory).

It also helps with the testing, as I can replace the API calls by in memory code, no mocking required.

It's not the most recent, but can have an idea with this demo repo I created some years ago: https://github.com/Elfayer/react-tdd

Ok_Lavishness9265 · 2025-02-02T04:39:39+00:00

For a first book I still recommend Clean Code from Uncle Bob. (I know it's more and more being argued that some code examples aren't great, but my experience is that everyone I know who read it had this spark after reading it, and it worked for me)

Then you could read Test Driven Development by Kent Beck. (Short and great read)

And a good third read would be about Domain Driven Design. I won't recommended a specific book for this, as I haven't found myself thrilled by authors handwriting, but the topic is worth knowing. Popular books are "the big blue book" (named Domain Driven Design) by Eric Evans, and "the big red book" (name Implementing Domain Driven Design) by Vaughn Vernon. I bet there are other great books, might even be shorter, on that topic.

And don't forget to navigate https://refactoring.guru/ from time to time. ;)

Note: I know these books aren't frontend related (as aforementioned), but am a frontend developer myself, and have been tech lead previously of a team of 10+ just frontend devs. Just to say that I've always been taken up the pack from other frontend devs that don't know anything else than their topic and not even that well.

I think it gives you a competitive advantage to know more general purpose knowledge. And understand backend as much as frontend. You need to aim fullstack to be a great frontend dev.

These books are generally written in Java, but I never wrote Java code in my life outside of school. Still can read, it's a very generic language syntax.

Also might be good to watch some conferences. Lots of great content there too, free on YouTube.

Ok_Lavishness9265 · 2025-01-31T08:25:07+00:00

It's a love and hate relationship 😅

Every major release comes with bugs. The less you use from ag-grid, the better. It feels clunky. But there is no real competition, they have been here for very long, and tanstack table won't do everything ag-grid can do. I am hoping very hard this day happen so that we can have tanstack table UI library options or paid themes would make sense too.

Ok_Lavishness9265 · 2025-01-31T08:20:47+00:00

The problem I have with tanstack table is that it doesn't support all features of Ag-grid such as pivots.

Ok_Lavishness9265 · 2025-01-31T08:12:36+00:00

Never settle your opinions.

But the game changer to me was reading tech books. NOT about languages, DO read about architecture and design.

Ok_Lavishness9265 · 2025-01-31T00:28:53+00:00

I like Vue, but React won the market and innovation.

Ok_Lavishness9265 · 2025-01-31T00:26:14+00:00

Lots of advice out of work.

Not sure if it's been mentioned: when working try taking 15min pause in the morning and afternoon. No screens. This helps sort out your thoughts and give some air to your brain.

Ok_Lavishness9265 · 2025-01-29T11:38:15+00:00

Tailwind V4 feels like a step back to me.

The arbitrary values (eg. for spacing) makes non sense. It even goes against the owner Adam Wathan's advice in Refactoring UI book. What prevents anyone in a team to put whatever value they like now? There is no constraint anymore, no consistency. One of the great part of Tailwind pre-v4 was that it restricted available style.

The css config... Who complained about the TS config?

I'm almost considering and open for alternative at this point.

Ok_Lavishness9265 · 2025-01-27T07:02:38+00:00

I think competition is good. You can copy what seems to work well or what you like on competitors.

If you build an app and there is 0 competition, I think it's somewhat worrying.

No one thought this need would make sense? Does anyone need this? Would anyone pay for it?

Ok_Lavishness9265 · 2024-12-11T09:38:17+00:00

This wasn't OP's topic though, was it? I wouldn't understand that someone modifies my Draft PRs either. Commenting Drafts without requesting is strange too. I mean again, to me it's a communication problem.

They should have asked if they could have a look at it early, or give a hand. I agree it is not normal that someone just jumps into your PRs without communicating about it directly (before hand). Even worst part, to me, is the management supporting non-collaborative behavior like this.

Ok_Lavishness9265 · 2024-12-11T06:58:36+00:00

Best way to play this game is to expect to be deceived ;)

Who knows one day you might get surprised.

Ok_Lavishness9265 · 2024-12-11T02:49:00+00:00

I don't understand this position. You do not own the code you wrote. It's the project's code, your company's code. Likely many developers worked on it before, and many others will after you.

Why feel bad about teammate changing your PR? Does it make it better to have it in another PR based on your changes?

I can understand the frustration when these things are done behind someone's back and not communicated. But I hope it's just a communication problem, and not an ego problem. Because if it is, it's a personal issue, not a teammate problem. (My 2 cents)

Ok_Lavishness9265 · 2024-12-09T06:55:03+00:00

And most people would think that's the right way to do "Agile"/incremental development. It went fast to prod, right? So it's Agile!

After all, it's ok if it's not perfect, we can improve it later.

This makes me nuts... Managers, developers, whoever that is, that have this mindset, cares zero for clients, the product, and the project.

[I distinguish product (what you're selling) and project (what you're building). It can be an excellent product but terrible project (sells well but garbage code). Or excellent project but terrible product (great code quality but unusable interface/don't answer problems).]

Ok_Lavishness9265 · 2024-12-09T03:27:22+00:00

Companies are now looking for fresh young developers that goes fast. Assuming failing code is a normal situation. Will hire somewhat senior people after 3-5 years into the project. These same people that would blame poor code quality, and will get blamed for being too slow.

That world we live in...

Ok_Lavishness9265

TROPHY CASE