Your Tips to get rejected here aren't very AI-specific and even have some things listed where the usage of GenAI would actually help with mitigations (i.e. Have typos in your CV, Bullshit language like this).
Equating corporate background to a Company culture mismatch is quite a take tbh. You're a PHP-only shop, yet you see Too much emphasis on dated tech as a reason for rejection? ...an Application send by mail is considered "Applying on side channels"? You're a very small shop and seem very far from a corporate organization (something you yourself seem to despise, see above), so why should anybody care for your rigid application-process? I'd personally expect some resiliency from a team of 4!
I'm only writing this here because I feel that your rant really just feels like any unreflective rant, and you should really consider whether you'd want to put it out there as is.
Thanks. Certainly. Sometimes I like to blog when the pain is fresh. It helps. Potentially also has a lot of typos. Yes. Let's embrace typos as long as we have them.
Corporate experience per se is not bad. Somebody with that experience might help is us to thrive. Yet, somebody who is close to us and our target audience is also valuable. I tend to prefer the later. You can consider us unprofessional tinkerers.
The side channel applications are just too hard to keep track of. I manually need to copy things over.
Why yes, many people is PHP as dated itself. That's OK :)
Consistency is never the sole reason to change something, there's always consistency and at least one of the following:
- coherency
- type safety (shout-out to dynamically typed languages that adapted static typing)
- concurrency
- simplicity
- (and more)
> If it's actually better, others will start following your lead.
A lot of people don't want to improve the quality in their output and for various reasons... some are happy to have something "to pay the bills", some don't want to use a programming language to its full extend, some have a deeply rooted paradigm that worked for 10 years already ("static types won't change that"), others are scared of concurrency etc. For some people there's nothing to worry about when a server can be blocked by a single request for 60 secs.
An old friend once said "Evolution beats Revolution" and that just stuck as mantra in my mind.
> I find that usually (good) programmers enter a new project with idealistic dreams of ripping out the walls; this could be done differently, that could be removed entirely, and so on. Then, later, the longer they stay the more those walls seem familiar, and the idea of changing everything becomes instead a distant memory.
Oh... analogies! In reality those walls will not disappear. Instead, the rooms that have been defined will become inhabited, and you'll notice that you just lack proper resources to remove walls. You'll start questioning whether you're in the construction business, interior designer (walls need decoration!) or just any other tenant for your landlord. You'll never be the needed tornado, so it's just best to hope to discover that the walls are actually made out of cardboard and some tropical storm is coming up after the past dry summer! :D
Fact seems, bad decisions can be done in a heartbeat, and it takes a lot of time and effort to iteratively leave it behind. I estimate that ratio to be somewhere in the 1/1'000'000 - 1/10'000 range and that's where I have some actual hope in LLMs to bring that number closer to 1!
My newest revelation to unwanted walls: If part of your code doesn't need to have a new release-(or life-)cycle, just don't put it in a new repository. The scaling advantages of microservices can be achieved with just a single repository.
A MITM proxy isn't specific to any app, it's a forward proxy for your outgoing network connection. In case of an Android app you'd need to run mitmproxy on a machine in your network and setup the connection as proxy in your Android's network settings. Then you'd need follow http://mitm.it to install mitmproxys root certificate on the Android device (to trust the connection with TLS) and off you go.
Disclaimer: I'm an active adblocker and avoid all social media besides HN, IANAL
> The defence so many influencers employ when advertisers turn out to be doing shady things is "You can't hold me responsible! It's not my fault, how can I know what my advertisers are doing?" but as soon as an advertiser does something that harms the influencer, it's a problem?
Yes, if the damage is directed towards you then that's a case for a defence.
Inluencers are just providing advertisement space like any other media platform (TV, websites etc.). So if a sponsor bought this advertisement space and turns out to be shady, why should influencers, TVs, websites etc. be held accountable? Hasn't their reputation been damaged as well? They usually just don't go after it because it's a tough case to quantify and any legal trouble can be exceedingly tiresome.
> If Influencer A includes an affiliate link for "Expensive Camera" and Influencer B includes an affiliate link for "Cheap Toy" and you click on "Expensive Camera" then click on "Cheap Toy" and then buy the expensive camera, Influencer B is getting paid for that purchase expensive camera purchase, despite Influencer A influencing you to buy it.
It's the last click, yes. There's a difference between [A] you actively clicking an affiliate button to land on a product page and [B] you being tricked into a last button click right before checkout with the (void) promise of free coupons. You stated it perfectly, yet you don't understand the difference?
As for "Expensive Camera - Cheap Toy": What get attributes how is a technical challenge and cookie domains seem to be the solution that gets picked by the affiliate stores. I think there could be a more fine-grained solution that wouldn't be so difficult to implement, agree, but it seems like there's no work being done in this space?
Going off my personal experience I don't see SSE being mentioned anywhere at all. But I always come across some new shiny web framework/wsgi listing websockets as a feature.
The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard.
> The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard.
I suspect the treatment as 'standard' is what thread OP is talking about. See my sibling comment in the thread. Unless you absolutely need websocket, SSE is simpler, and due to that, better.
I suspect the reason many select websocket over SSE is due to its limitations (connection limit under HTTP/1.1, no client->server sends), but SSE for server->client events and normal HTTP requests for state fetching is better architecturally for bog standard apps in my experience.
It might be worth mentioning to the parent poster that SSEs (and Mercure) are unidirectional only (server -> client), whereas WebSockets are bidirectional.
Nowadays that's hardly an issue because SSE is multiplexed over HTTP/2 and HTTP/3 alongside regular requests. In some ways, SSE is today more efficient than websockets too because if you use it with HTTP/3 then you're avoiding head of line blocking which is still an issue with websockets.
(Also in practice many places websockets are not even supporting HTTP/2 because on the server they were implemented on top of raw sockets which is no longer possible with HTTP/2)
Head-of-line still exists in HTTP/3, but on another level. A stream can still get blocked. With websockets the whole connection gets blocked (HTTP/1), but that connection isn't shared with anything else, right?
Worth noting that HTTP/3 seems to recover faster than TCP-based protocols.
> Once the connection is upgraded, you loose all metadata included in the HTTP headers (because it’s not HTTP) and all protections relying on it.
The Upgrade request is HTTP and you can extract all needed metadata from there and store it server side as needed. Those metadata wouldn't change during an active WebSocket session anyway, would they?
The auth headers (Authorization, Cookie) are all passed along, and that's what I want to establish a secure connection from the browser.
For more customized wishes there's always this "ticket"-based flow[0][1] that shouldn't be hard to implement. I might be a bit naive, but what needed metadata and custom headers are we talking about?
A DSL for XState[0] by the co-creator of astro.build[1], cool! But the repo[2] has been archived and there is an active FSM library from the same developer called robot[3].
I'm on my phone right now, so can't try Robot but I'm wondering what the type safety story looks like. For instance, in the example in "Getting started" the variable `users` is defined irrespective of the state, even though it is only available in the `loaded` state.
Instead of conforming to an XML specification created decades ago, Robot takes the best ideas from both academia and real-world usage of finite state machines. This makes state machines easy to read and understand, as there is only one way to do most common tasks.
...is hinting at some disagreements with XState's approach. Would be nice to have a visualization tool, like the kind XState has, for any FSM library (like robot) though.
The visualization tool goes a long way in helping non-developers understand what logic is actually doing, from a relatively wide perspective. It’s valuable for sure
XState famously always conformed to the SCXML spec[0]. It isn't mentioned anymore in the current version anywhere(?), but you can still see it in the v4 docs[1].
Writing a language, even a DSL is a lot of work. It's not enough to just make a good language, there's also a whole world of tooling support that people expect nowadays.
Also ultimately it was hard to sell the idea of living in a different file format from the rest of your code. This is always a tough sell for DSLs. Even languages as good as CSS and SQL struggle with this for a lot of devs.
A JavaScript-only implementation of robot suffers a similar fate as a DSL without proper tooling, as states and actions are just some custom strings that need to be repeated, no? An implmenetation with good types would provide useful autocompletion, and I can see there was a similar conclusion and types have been implemented with generics. Haven't used it yet to confirm the behavior (at a first glance it seems like a few more strings would need to be inferred), but it would be helpful to mention this somewhere for us TypeScript folks.
Equating corporate background to a Company culture mismatch is quite a take tbh. You're a PHP-only shop, yet you see Too much emphasis on dated tech as a reason for rejection? ...an Application send by mail is considered "Applying on side channels"? You're a very small shop and seem very far from a corporate organization (something you yourself seem to despise, see above), so why should anybody care for your rigid application-process? I'd personally expect some resiliency from a team of 4!
I'm only writing this here because I feel that your rant really just feels like any unreflective rant, and you should really consider whether you'd want to put it out there as is.
reply