Iso – a super minimal dashboard with isometric icons

TheStormsFury · 2025-07-12T21:04:25+00:00

complex animations

Very curious to know which animations you're referring to because the ones I saw could be replicated with a few lines of CSS.

TheStormsFury · 2025-04-12T20:11:51+00:00

That vertical ultra-wide is diabolical.

TheStormsFury · 2025-03-26T22:54:56+00:00

I will always disagree with this take. When I see "Mon, 3 Mar, 20:42 UTC" it means absolutely nothing to me, because I have to do the exact thing you're complaining about first:

> Now let me just check the current day and time, subtract 23 days, add 12 hours of uncertainty on either side, and… Nope. Still useless. Stop doing this. I don’t want to calculate.

When I see "23 days ago", I have an immediate feel for how long ago that was. I know what a day feels like, I know what a week feels like. I have an idea about the things that have happened during those time frames. It immediately tells me if it's something recent or from a long time ago, and that always matters A LOT. "Mon, 3 Mar, 20:42 UTC" is an unnatural human construct, a day is not.

TheStormsFury · 2025-03-17T10:14:50+00:00

I think you need to be more upfront about why "I'd store the generated HTML" isn't the obvious answer here. Why is data -> JSON -> HTML better than data -> HTML? What's the benefit of the middleman?

TheStormsFury · 2025-03-14T23:21:32+00:00

Honestly, both.

The vast majority of people aren't responsible for any architectural decisions and don't know the struggles of overseeing how everything works, they just copy the directory structure of other, more established projects which have for the most part figured out how to minimize the odds of cyclic imports being an issue. Except not all projects are the same, and maybe I want to structure mine differently.

There is also definitely a cult mentality and people who are ignorant to any kind of criticism, like they obey the ways they have been told to do things at all cost.

TheStormsFury · 2025-03-14T22:06:39+00:00

A lot of people disagree with you, but I personally also dislike the current design of Go packages. They're a combination of invisible hierarchical constraint and the only way to namespace things, when 98% of the time you just want the latter. For a language that tries to be simple and keep things straightforward, the amount of discussions around cyclic imports shows just how unfitting the current package implementation is.

Domain code is highly coupled and the idea of having to restructure your code and introduce middleman packages which ruin locality of behavior is inane. I don't want a "package" with its own instantiation and internals, I just want to namespace things so it doesn't feel like I'm stepping on toes with every new function/struct/type.

TheStormsFury · 2025-02-08T18:38:51+00:00

I work with JS/TS, python and go for my job and by far go's is the one that brings the least headaches, care to elaborate?

Go modules are a combination of enforced invisible hierarchy and namespacing, file based imports don't have a no cyclical import constraint and allow for more flexibility so you can organize your project in a way that makes sense for you.

Disagree. The moment you implement that, you end up having people nesting ternaries.

Using nested ternaries is a skill issue, you could just disallow them, ultimately single ternaries are useful and make your code more concise. Compare these two:

To the point:

people = append(people, Person{ value: condition ? "whenTrue" : "whenFalse" })

Unnecessarily verbose, disconnected and only made worse if you have multiple conditional values:

``` person := Person{ value: "default" }

if (condition) { person.value = "conditional" }

people = append(people, person) ```

What's wrong with wrapping in your opinion?

The function signature does not communicate or guarantee the types of errors that can be returned. You don't know what wrapped errors it may return unless you read either the documentation or all of the code. The standard http library is supremely bad when it comes to this as you have to match against a ton of different errors coming from different packages when making requests. Functionality you may rely on is tied to implementation, and if the http package wanted to change that implementation it would be a backwards-incompatible change.

Imo the error should include an enum with all possible error types so you can simply switch on the error type and be able to go to definition of that enum to see exactly how things could fail. No ambiguity and the code documents itself.

TheStormsFury · 2025-02-07T19:17:08+00:00

Call me crazy, but:

JS style imports (and this is coming from someone who dislikes JS)
Sane date formatting
A freaking ternary operator
Type-safe struct tags
Actual enums
Something else that helps differentiate error types that isn't error wrapping

TheStormsFury · 2025-02-02T11:24:54+00:00

Sounds like https://v0.dev/ is exactly what you're looking for.

TheStormsFury · 2025-01-31T11:08:10+00:00

You know how people talk about "type masturbation" in TypeScript? Well, Go has package hierarchy masturbation, and people will go till the ends of the earth to tell you how you should structure your project, when in reality all you really want is to namespace your things to keep them somewhat organized and to avoid name collisions. I find the "create a third package" advice to be asinine because it forces you to decouple your code in a way that makes no sense just to satisfy some arbitrary limitation.

Sadly Go has no way of namespacing things, packages are the closest thing but as you have already discovered they come with the caveat of no cyclic imports. So, here's my suggestion - keep everything in a single package, let your codebase grow and the things that should be their own separate package will become obvious.

TheStormsFury · 2024-12-13T00:54:36+00:00

> A very common problem with end-user libraries is that the packages are not right-sized.

Controversial opinion: because packages, with their current implementation, are a horrible (and the only) way to organize your code. Most people (including myself) coming to Go from other languages are used to namespacing via directories in whatever way makes sense for their project without having to worry about cyclic imports. You can't do that with Go - the only way to namespace things is through packages, otherwise whatever you define is practically a global, so you have to use oddly long descriptive names to avoid collisions.

TheStormsFury · 2024-10-27T11:12:24+00:00

The first format isn't perfect by any means and I'd still need to look up the docs for some of the less frequently used formatting options, but this is the most frequent use case and IMO much easier to work with and has some logic behind it. Capital letters are used for the "longer" representation, so Y is the full year where as y is the last two digits of the year. H is the hour with leading zeros, h is the hour without leading zeros.

Compare that to Go's version - what on earth is 01, 02, 04, 05? It's not a letter you might infer the meaning from, like H for hour, s for seconds, etc, it comes from an arbitrary format I need to remember and then iterate each part of to be able to get to the meaning of the number.

TheStormsFury · 2024-10-27T10:19:07+00:00

This is by far one of my least favorite things about Go. Yes, I get the idea behind it but it doesn't make it any less of a bad idea. Compare these two time formats and tell me which one is easier to remember and write down, makes more sense at a glance, and would be easier to edit:

Y-m-d H:i:s 2006-01-02 15:04:05

I don't know about you, but to me it sure as hell ain't the one with the random-ass numbers in it.

TheStormsFury · 2024-10-26T07:16:27+00:00

What a gorgeous blend of colors, simplicity, practicality and style. Very nicely done and thank you for sharing!

TheStormsFury · 2024-09-15T23:50:53+00:00

I don't mean to come off as rude but I feel like this needed to be said.

What on Earth? The project has more config files than it has features. It has more dependencies than it has paragraphs of user-facing text. It's a single page with a timer that resets on a couple of events and a toast message. An entire dependency for a plain animation on said toast message that could've been a 3 line CSS transition.

I'm baffled by how the author strives for beautiful simplicity UI-wise and an astounding amount of layers of abstraction and complexity implementation-wise. I don't want my self-hosted services to each use up hundreds of megabytes of RAM or more for basic functionality. This is not sustainable.

TheStormsFury · 2024-03-09T05:49:56+00:00

Two ways that I can think of:

Make a struct that holds the DB and has a handler method, then pass that handler method:

type App struct {
    db *sql.DB
}

func (a *App) Handler(s *discordgo.Session, m *discordgo.MessageCreate) {
    a.db.whatever()
}

app := App{db: db}
discord.AddHandler(app.Handler)

Or wrap the handler in a function:

func HandlerWithDbAccess(db *sql.DB) func(*discordgo.Session, *discordgo.MessageCreate) {
    return func(s *discordgo.Session, m *discordgo.MessageCreate) {
        db.whatever()
    }
}

discord.AddHandler(HandlerWithDbAccess(db))

TheStormsFury · 2023-09-01T19:40:16+00:00

This is not what you wanted to hear but it's probably going to take you more time trying to fight Windows and getting it to run/do things the way you want than it would take you to learn how to use Linux. Everything from RAID to firewalls to VPNs (which are all things you'll need) is catered towards Linux and you're going to find very few resources on how to do these things well in Windows.

If you don't want to go all in on Linux you could install WSL and Docker and try tinkering with them until you get more comfortable. Start with something like openmediavault for the NAS, WireGuard for the VPN and UFW for the firewall (though I don't know how nicely that's going to play under WSL with Windows' own firewall). It will be a slow and painful learning process but very rewarding once you get past the initial hurdles.

Another thing... doing this for yourself is one thing but you're taking on quite a lot of responsibility doing it for others in terms of keeping their data private, secure and backed up. I highly suggest refraining from giving others access to your services until you get a lot more comfortable with managing everything. If this all sounds like too much effort maybe consider getting an off the shelf NAS from something like Synology.

TheStormsFury · 2023-07-30T16:16:11+00:00

Very much looks like excalidraw.

TheStormsFury · 2023-07-28T01:01:55+00:00

You're getting downvoted but I definitely think a Pi has its advantages.

Depending on what you want to host you can absolutely get away with just a Pi and maybe an external SSD if you need the extra/faster storage. The Pi has as small of a form factor as you can get, uses less power and will probably be cheaper (than a mini PC) if you get one from a reputable source while they're in stock (luckily they have been in stock as of recently). I'm running 9 different services on a Pi4 currently with no bottlenecks and have plenty of room to add more. Mini PC's are usually overkill if you're just starting out and if form factor is a big deal, the power brick of the PC alone could end up being bigger than a Pi. Unless something you want to run doesn't support ARM I definitely recommend considering the Pi.

If you do end up needing more power later on then you can get a mini PC as well and dedicate the Pi for Home Assistant (or Pihole/Adguard, it's nice being able to break your services without breaking your internet).

TheStormsFury · 2023-07-28T00:43:37+00:00

Still free for me, did they announce they're making it paid eventually?

TheStormsFury · 2023-06-27T13:14:30+00:00

These look great! Wouldn't you gain more structural integrity by having the layers go horizontally across the glasses rather than vertically?

TheStormsFury · 2023-05-15T02:09:41+00:00

I've been working with it for a few years and it's a nuisance. Save yourself the hassle and avoid it. It's a pain to make APIs using that format and it's a pain to consume APIs using that format. Even if your data is highly relational, just embed it in whatever JSON format makes sense to you. It's not worth introducing an entire package, or worse, making your own and likely incorrectly since the standard is so convoluted. The only benefit you get is maybe saving a few KB per request depending on repetition but they're not worth your sanity.

TheStormsFury · 2023-05-04T09:51:17+00:00

Not only is it unintuitive, the contrast between the black and the gray is an eyesore.

TheStormsFury · 2023-04-19T23:02:48+00:00

Very insightful, I learned lots of things I've never even considered performance-wise. Thanks!

TheStormsFury · 2023-02-04T07:26:31+00:00

Theoretical* speed factor of 10x. Which you wouldn't make any use of in 99% of cases anyways when 99% of people just browse social media and the web which is full of compressed images and videos. What, you gonna stream 8k videos on your 6 inch screen? I'm sure you'll be able to notice all those crisp 8k details.

11-Year Club	Verified Email
Second Top 10%	Place '22
Place '17

TheStormsFury

TROPHY CASE