>I'd put easter eggs all over it, just ot remind people there were people on the other end of the line
Most people won't come across your Easter egg since it's hidden. The ones that do encounter it will likely stumble over it, as did the OP, who had their CI pipeline broken. I think easter eggs are a poor tool to "remind people there were people on the other end of the line".
I guess you could have an integration test that validates that your installer puts the man pages in a directory that man searches in? It's a bit far-fetched but also not entirely outlandish.
Agreed. I'm really trying but failing to come up with a non-screwed-up scenario where this Easter egg legitimately breaks a well-planned testing suite.
Running `man` without any arguments is a fine place to put an easter egg, though. I'm glad this at least stayed there and was only removed from `man -w`.
It's weird. That seemed to have been their selling point. Plus black? I don't know about others, but my all my black keyboards acquired some gray parts pretty quick (tiny ones, I like my keyboard clean, but that's precisely why it hurts the aesthetics).
>No surprises here. I used to use Plausible, but that costs money and you can't beat free. Monthly cost: $0.
Thanks hard pass. I checked and Plausible starts from 9 Euros a month. This is hardly what I'd consider advertising material. But likely I'm just not their target audience.
There's also no consent banner, so this doesn't seem GDPR compliant
Edit: I must have phrased this in a confusing way. They are NOT using Plausible but GA. I'm well aware cookie-less analytics does not require consent
Even if you are using Google Analytics, you can skip the consent banner by denying on behalf of the user. GA will then update your counters without doing anything that would require consent.
ad_storage='denied'
> Requests are sent through a different domain to avoid previously set third-party cookies from being sent in request headers.
> Google Analytics will not read or write Google Ads cookies, and Google signals features will not accumulate data for this traffic.
> IP addresses are used to derive IP country, but are never logged by our Google Ads and Floodlight systems and are immediately deleted upon collection. Note: Google Analytics collects IP addresses as part of normal internet communications.
I was referring to "There's also no consent banner, so this doesn't seem GDPR compliant". They explicitly state that they are GDPR compliant without the need for a consent banner.
> There's also no consent banner, so this doesn't seem GDPR compliant
Plausible uses this one weird trick where they don't use cookies and don't store PII, and thus don't need consent (neither for cookies nor for GDPR). You lose some data because you can't track users across visits, but you gain accuracy (because you can track every visit, not just people who agree) and don't have to annoy your visitors.
Basically. Except that htaccess logs won't correctly track page visits on your fancy react page, so you still need a bit of JavaScript.
And once you have that you can also track visit time a bit better, or track goal conversions like how often people click some specific button. But other than that it's basically a more modern webalizer.
And Plausible won't correctly track visits for users who block their JavaScript :)
Also, last year I found a bug in Plausible's script which silently stops it working on some pages, so your data won't be accurate in those scenarios either.
> There's also no consent banner, so this doesn't seem GDPR compliant
I'm not sure what you mean by "consent banner". If you're referring to an annoying "allow us to track everything you do" pop-up, that's probably because Plausible doesn't attempt to track everything you do.
They have plenty of privacy information on their site [1].
You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now. You also better have stellar internal documentation because onboarding developers is going to be a pain otherwise.
99% of cases people are better off using a boring conventional web framework and implementing their actual business logic on top of it.
This has always been the sticking point for me when I am wanting to try out new frameworks. When starting a new project I used to get excited on the idea of using a lean barebones framework, only to realize later on the boring bits that I had to figure out/implement or rely on some third-party library that may not stay up to date with best security practices in the future.
"You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now."
In Go, not necessarily, because net/http actually is what many languages would call a "minimalist framework".
There's a sense in which pretty much everyone here is right. You do need a framework in the general sense; you can't expect to just throw someone a TCP socket and get reasonable work out of them because the web is very complicated nowadays. But the reason why you can "do without a framework" in Go is that it is already a minimal one of its own, and in particular, that "minimality" focuses on providing a mechanism for composing various bits of HTTP code together.
I think calling Go "no framework" is kind of misleading, because I get what you're saying, but the standard library is not the "no framework" option. The "no framework" option is more like using https://github.com/valyala/fasthttp , which is its own server implementation with an incompatible API that does in fact remove you from the community code, other than the code that works only with that server.
Don't over-read my post. I am merely saying that Go essentially ships with a minimal framework and so it is misleading to say or think of it as being "frameworkless" (and that is a criticism of the original link, yes), not that it is mandatory to use only that "minimal framework" and all other things on top of it are a bad idea. There are times and places to want large, preconfigured packages of additional functionality. But if there are times and places where it is not desirable, Go does come with a minimalist option by default. It is a pretty good, not-very-opionated option suitable for a standard library, where development is slow and there's not much room for experimentation in what a "full" web framework should look like.
The standard library minimalist framework even makes the other frameworks pluggable. You can, for instance, write an API website, then realize that if you need a conventional HTML website, you can plug in a framework for that part, but leave the API part as-is, simply by routing the API URLs to the existing API code while routing the HTML website to the http.Handler provided by the framework. Even "not using an additional framework" is not the commitment it may be in other environments, because the net/http foundation is still there.
Well said. The 'no big framework' thing works for Go because the Go standard library defines a common way for dealing with HTTP. The difficulty, then, is identifying 3rd party packages that play well with the rest of the ecosystem.
You can see the opposite in projects like Echo, Gin, Beego, etc., that eschew the standard library to various degrees and try to build the kitchen sink themselves. Sometimes this works! Echo is very popular, despite having nonstandard handlers and context. An absolute Go newbie is probably going to have an easier time using it than trying to pick out the best collection of libraries themselves.
I agree with you that not using a framework requires you to think more about these things, but if you’re using a routing library like chi or gin there are plenty of libraries adding such functionality to them.
I think that actually depends on the programming language. With golang, such a task is much harder because integration is more errorprone and requires more plumbing, e.g. due to missing generics (until recently).
Unless you're hiring 3-4x the engineers, then this doesn't scale. I would much rather occasionally be paged at night than have to be on call all or even most of the time.
Even if that "on call" was only 9-5, getting distracted and losing half a day to tracking down the latest flaky test or owner for a failing dependency really adds up and makes it significantly more difficult to do my day job. When I'm oncall, I'm oncall 24/7 for a week (30 minute SLO) and the expectation is that the amount of non-oncall tasks I'm able to get done that week is significantly impacted. I'm fortunate to work on a team that acknowledges that reality; I know many people, even at large software companies who should know better, whose management is far less reasonable.
It's true but most people do not have the luxury of being able to focus on a single task each day until done. If that is a requirement for you I'm not gonna knock it but I feel it is rare to get.
Plenty of good devs open to competitive offers down here in APAC.
I joined a US company as part of a follow the sun model. Although ironically I seem to support people who are up at midnight in Europe more than in my area of the world.
Happy to have a chat, see if I can offer any useful feedback :)
Salaries in the EU are not what they were and have improved dramatically. I've found most companies to be wildly off the mark when making offers. Perhaps you need to recalibrate.
It’s true, and it’s sad to see. A long time high performer on our team based in Germany makes a pittance compared to more Junior US based folks. Alas, I cannot do anything about it.
Most people won't come across your Easter egg since it's hidden. The ones that do encounter it will likely stumble over it, as did the OP, who had their CI pipeline broken. I think easter eggs are a poor tool to "remind people there were people on the other end of the line".
Edit: at least outside of entertainment software
reply