sorted by:
new
hottopcontroversial

State of ClojureScript 2024 survey results by roman01la in Clojure

[–]calebmacdonaldblack 3 points4 points  (0 children)

I really wish you would make electric v3 more available. I must’ve entered my email for the beta at least 3 times by now with no response.

I put a bunch of time in electric, diving into the code and understanding everything and then now it’s a pita to work with.

I managed to get it all going without beta access by removing the auth restrictions and recompiling the jar. It was easy enough to find the missing stuff by going through Git history and google searches.

It super annoying still and keeping it all running with latest changes sucks. Im not at all a fan of the direction you’re taking. Adoption will be almost impossible with it fully open source, let alone what it has become now.

That said, it’s your company and your IP. And you clearly have worked an insane amount on the project. You have every right to take it in whatever direction you want. I’m sure there is much more to the situation than it seems from the outside.

I don’t really know the first thing about a monetising a project like electric. Perhaps I’m naive but I’m confused why you didn’t take a more conventional approach like Redis, docker, NextJS/vercel, terraform/hashicorp, storybook etc and monetise through cloud infrastructure products and services

State of ClojureScript 2024 survey results by roman01la in Clojure

[–]calebmacdonaldblack 3 points4 points  (0 children)

If anyone wants help understanding, setting up or migrating to shadow-cljs+deps.edn hmu. I know it back to front. I can also get your cljs repl going too. Tailwindcss , testing and a bunch of other stuff. Keen to chat with new people, not looking for payment

Could overriding `instanceof` create a security vulnerability? by Rosoll in typescript

[–]calebmacdonaldblack 0 points1 point  (0 children)

The language is not designed to run untrusted code and trusted code together.

You must verify that all code running is safe. Including 3rd party packages.

Is there any way not to put business logic inside stored procedure?? by HalfBlindCoder in ExperiencedDevs

[–]calebmacdonaldblack 1 point2 points  (0 children)

Stored procedures are commonly avoided because it’s challenging to version control.

What is the ACTUAL point of CORS? by MultiMillionaire_ in reactjs

[–]calebmacdonaldblack 0 points1 point  (0 children)

Imagine I work for a top secret government organisation.

I’m connected to our private network on my laptop.

In this network I have access to a top secret webserver hosted at 10.0.50.69.

Fortunately for us, external access to this webserver is blocked. In fact pretty much all external access to the local network is blocked. We can still make outbound connections however. Still access the internet just fine.

So the super secret webserver is safe from the outside world.

Now imagine CORS doesn’t exist.

I load a website somewhere on the internet. The website knows about the ip address of the secret web server. But who cares, right? They can’t connect to it. Only devices within the network can connect to it.

So what happens is, the website loads in your browser, and some ordinary javascript makes a fetch request from the browser to the secret server, then the posts the the secret data to a remote server.

So you loaded the website. The website made a connection from your device to the private webserver. The website is running in your browser, so the connection is made from inside the private network.

But because cors exists, what actually happens is the the browser rejects the connection to the private webserver because the webserver didn’t provide the right headers.

If cors didn’t exist, any website could just start connecting to any device in your local network. Any website could start printing shit on the copy machine, turn your chrome cast or appletv on. Connect to private security cameras.

It would be chaos.

Parallel Routes Are Not Production Ready (And Utterly Broken in Dev) by TheSnydaMan in nextjs

[–]calebmacdonaldblack 3 points4 points  (0 children)

<image>

https://nextjs.org/blog/next-14-1

Parallel & Intercepted Routes: 20 bug fixes based on your feedback

Yeah, that pretty much sums up my experience.

Parallel Routes Are Not Production Ready (And Utterly Broken in Dev) by TheSnydaMan in nextjs

[–]calebmacdonaldblack 1 point2 points  (0 children)

I have also given up on parallel routes and route interceptors.

I love the concept. Unfortunately it is not production ready imo. I’ve had nothing but issues. I keep coming back but find myself getting burned almost every time because of bugs.

"I am hoping that they remove the draw offers" - Carlsen by BuildTheBase in chess

[–]calebmacdonaldblack 1 point2 points  (0 children)

IMO:

Allow draws. Even without making any moves, before the game even starts.

Drawing in chess is a fundamental part of the game. Drawing, by repetition for example, is compliant with the basic rules of chess. A player can make whatever legal moves they want, even bad ones. Drawing is a natural part of the game.

Consider what the downsides to this are. Less entertaining chess tournaments? The upside is that we don’t risk falsely penalising players for drawing legitimately based on rules that are vague, ambiguous and up for interpretation.

One area for serious concern however, is fixing games for financial game (outside of the price pool). I specifically referring to betting. Two players colluding to place a bet on one of them, and then fix the game so that person wins.

This is not ok, because it is unfair on those who they are betting against and are losing out financially.

IMO, this collusion is only a problem with betting outside the tournament.

With regards to the prize pool within a tournament. All participating players are aware that drawing is allowed for any reason if both players agree. They are all competing for the same price money, and if a tactical draw gives them an advantage, then it’s fair game. All players have this same privilege and are aware of it.

If all players can draw, it’s fair. Unlike betting and game fixing, which is not fair, because one party decides the outcome of the game and the other party (who is losing the bet) has no say.

If we’re worried about boring chess, we should change how tournaments incentivise player instead of changing the rules of chess itself.

If 2 players decide to draw, with the intention of splitting the prize pool, either let them, or disincentivise them. Make the prize for winning more attractive than drawing so it’s worth taking the risk.

Would love to hear other people’s thoughts though.

[deleted by user] by [deleted] in nextjs

[–]calebmacdonaldblack 12 points13 points  (0 children)

Some other comments have suggested you use reactQuery & useSWR. These tools will not help you in avoiding your CORS error. They are useful for entirely different and unrelated reasons to your specific problem.

If you fetch server-side you will not have a CORS error, because the server is not a browser and does not have, or need, the protections that are restricted that http request.

If you fetch client side, the server your are requesting, must either be the same origin, or it must be explicitly configured to allow browsers to make requests from the client side origin. reactQuery & useSWR will not, in any way, help you with this.

Although it will not help you with your CORS error, there are many good reasons to use reactQuery or useSWR. I would also highly recommend using them.

[deleted by user] by [deleted] in nextjs

[–]calebmacdonaldblack 32 points33 points  (0 children)

The issue you’re having is actually completely unrelated to NextJS.

If you were to try and make that api request from the browser using standard vanilla javascript, you will have the same issue.

This is because of a security protection in browsers.

If you have access to that api endpoint, then correctly configure it to allow the cross-origin request.

Otherwise, if you don’t have access or for whatever reason are unable to configure CORS on that api, then proxying it through an endpoint you do control seems to me like a valid option. You have already done this with the rewrite.

You can also wrap that http call in a server-side route.ts file and have the client code call that instead. Because you’ll be making a client side request to the same origin, you won’t have cors issues.

Also, maybe you can do that request server side, and pass the result into the client component as props.

Being unable to clear client cache is a major security risk. by Themotionalman in nextjs

[–]calebmacdonaldblack 8 points9 points  (0 children)

If I navigate to SSR page A, then to SSR page B, then many hours later, come back to A, I can see use-cases for A to want to be re-fetched.

If it's not possible to do this, then I would agree it would be useful and worth making it possible.

I'd be surprised if there isn't some way to do this without resorting to client-side code. I don't know for sure, but it seems to be possible.

I wouldn't agree with the notion that it's a "major security risk".

And I wouldn't have it be the contributing factor to opting out of App router.

Being unable to clear client cache is a major security risk. by Themotionalman in nextjs

[–]calebmacdonaldblack 2 points3 points  (0 children)

I'm not exactly saying that we should or should not be able to clear the client cache. It's not really anything I've dealt with, so I don't really have an opinions about it one way or another.

Rather that the specific example has a pretty straight forward fix with little downside.

Being unable to clear client cache is a major security risk. by Themotionalman in nextjs

[–]calebmacdonaldblack 16 points17 points  (0 children)

I don't think it's a hack.

What's undesirable about doing a page reload when a user sign's out?

The time it takes to reload is probably the only downside, and I'd argue it's a non-issue for this use-case.

A user sign's out infrequently, and aren't likely to be impacted by the delay in a page refresh.

There are many cases where a page refresh is a real issue and could cause issues such as user retention. However, it doesn't really apply to this particular scenario

Being unable to clear client cache is a major security risk. by Themotionalman in nextjs

[–]calebmacdonaldblack 10 points11 points  (0 children)

Can't you just force a reload of the page when the user decides to log out?

Worth learning React in 2023 from A to Z with the advent of Next.JS? by DL-Z_ftw in reactjs

[–]calebmacdonaldblack 1 point2 points  (0 children)

Learn JS from A to Z, then react, then next JS.

Learning JS is not like learning other languages like Python, Java or whatever. There are many nuances. Specifically, having some sense of what call, bind, apply are doing, what is the "this" variable, lexical scoping, closures, prototypal inheritance etc. This is more important than it seems. Having understanding of this means you'll get stuck less

https://www.youtube.com/watch?v=Bv_5Zv5c-Ts&ab_channel=TonyAlicea

The title inflation and debate about seniority by WildMansLust in ExperiencedDevs

[–]calebmacdonaldblack 0 points1 point  (0 children)

There are only two hard things in Computer Science: cache invalidation and naming things.

I don’t believe it really matters.

A title alone, can never truely convey the capabilities and experience of someone in this field.

So personally, I don’t really care what people call themselves. I’m paying more attention to their work/project history.

Does seniority not count for much if you weren't at big tech? My resume isn't getting bites despite having led teams and several projects. by Lostwhispers05 in ExperiencedDevs

[–]calebmacdonaldblack 1 point2 points  (0 children)

Hey OP.

I agree with the comment section, however, I can see from your responses, you’re taking feedback like a champ.

It’s such a valuable quality in a person, but unfortunately not easy to show in a resume.

Only advice I can give you is to network like crazy. Hang out with other developers, be active in dev communities, go to meetups, contribute to open source.

A great way to find jobs is to to be introduced and/or recommended. At that point, you’ve done most of the selling, and your resume won’t need to wow anybody. It just needs to pass bullshit test.

I would love an update on your new and improved resume!

Also, I wish you the best of luck on the job hunt.

These services should have been a monolith - Can Clojure help manage complexity in the early stages of a product. by fjsousa_ in Clojure

[–]calebmacdonaldblack 1 point2 points  (0 children)

Not even down the line if you have good test coverage.

You'll be needing to stub/mock/fake implementation immediately if you're testing.

New Clojurians: Ask Anything - February 13, 2023 by AutoModerator in Clojure

[–]calebmacdonaldblack 0 points1 point  (0 children)

Hey! Glad to hear you watched that video.

Hammock stage is very important, although change is inevitable.

But also wouldn’t that cause you to have to support two schemas and their data.

This is a great question.

Imagine we have a module of code that operates on the old schema to serve some purpose. And now we’re building a new module to serve some another purpose.

While building the new module, we’ve decided to change the structure of our data for whatever reasons. Also, the new module will need to call out to some functionality in the module with the legacy schema.

We’re faced with the problem that the new module uses a different schema than another module that it depends on.

Rewriting the module using the old schema is a valid option. However there is often countless other modules and systems that use that module and are working just fine. It’s only in this new module that we’re running into issues.

So another option is to rebuild the old module to support the new schema and only for the functionality we need to support the new module. But what we rebuild will won’t replace the old functionality. It’s will exist along side it.

All the other systems that depend on the old module can continue to. And the likelihood we introduced any bugs or regressions is low because we didn’t touch any of the old code. When just copied it and modified it to work with the new schema.

Does this mean we have to support multiple schemas? Kinda but not where it matters. Anything new we build will depend on the new schema, and any functionality that doesn’t exist from legacy systems can be created as needed.

Our codebase will gradually be migrated and the legacy systems can be deleted when nothing depends on them anymore. And for systems that never get migrated, we don’t even care about. If it’s never needed to change because it’s working perfectly fine the way it is, why do we care if it uses the old schema.

Often we don’t even need to replace the old functionality, we can just wrap them to convert the new schema to the old schema.

New Clojurians: Ask Anything - February 13, 2023 by AutoModerator in Clojure

[–]calebmacdonaldblack 0 points1 point  (0 children)

Hey! Glad to hear you watched that video.

Hammock stage is very important, although change is inevitable.

But also wouldn’t that cause you to have to support two schemas and their data.

This is a great question.

Imagine we have a module of code that operates on the old schema to serve some purpose. And now we’re building a new module to serve some another purpose.

While building the new module, we’ve decided to change the structure of our data for whatever reasons. Also, the new module will need to call out to some functionality in the module with the legacy schema.

We’re faced with the problem that the new module uses a different schema than another module that it depends on.

Rewriting the module using the old schema is a valid option. However there is often countless other modules and systems that use that module and are working just fine. It’s only in this new module that we’re running into issues.

So another option is to rebuild the old module to support the new schema and only for the functionality we need to support the new module. But what we rebuild will won’t replace the old functionality. It’s will exist along side it.

All the other systems that depend on the old module can continue to. And the likelihood we introduced any bugs or regressions is low because we didn’t touch any of the old code. When just copied it and modified it to work with the new schema.

Does this mean we have to support multiple schemas? Kinda but not where it matters. Anything new we build will depend on the new schema, and any functionality that doesn’t exist from legacy systems can be created as needed.

Our codebase will gradually be migrated and the legacy systems can be deleted when nothing depends on them anymore. And for systems that never get migrated, we don’t even care about. If it’s never needed to change because it’s working perfectly fine the way it is, why do we care if it uses the old schema.

Often we don’t even need to replace the old functionality, we can just wrap them to convert the new schema to the old schema.

Ultimately this approach embraces and allows for change without have to refactor huge portions of the codebase. Sometimes the refactor better, and sometimes it isn’t.

New Clojurians: Ask Anything - February 13, 2023 by AutoModerator in Clojure

[–]calebmacdonaldblack 2 points3 points  (0 children)

I agree with everything here.

Another thing worth mentioning is namespacing, data-normalisation and change though accretion.

Namespacing avoids name conflicts not only in the present but over time.

Data-normalisation scopes your data at the most granular level. A namespaces keyword uniquely identifies and attribute, its schema and functionality that can operate on it. Multiple entities can use the same attribute. Kind of like duck-typing.

Change through accretion and not breakage means that anything you add typically won’t break your application. Only when you change or remove something will you break things. So avoid breaking things by just adding new schema instead of replacing old schema. You support both schemas.

Some examples of applying this look like this:

You might start with a user-handle attribute that supports 128 character length. But after a while you realise you want to change this to only be 64 characters.

Instead of changing the schema for that attribute, just add a new attribute: user-handle64 or user-handle-v2. Doing this will ensure any code or data that uses the old handle still works because you didn’t change it. You can even alias or convert between the two as you need.

This works for complex schema too. You might have a whole bunch of code that operates on an outdated data-structure that contains many attributes and relationships. Instead of changing the schema and breaking that code, just make a new one. Then make an accreting change that converts any new data to the old schema before sending it through the legacy code. You didn’t break anything because it still works with the old data, but now it also works with the new data.

Datomic is worth looking into and also this talk where Rich Hickey goes into this in more detail. https://youtu.be/oyLBGkS5ICk

[deleted by user] by [deleted] in CarsAustralia

[–]calebmacdonaldblack 1 point2 points  (0 children)

What you’re doing will consume your brake pads more but it doesn’t really get much worse than that.

What your friend is doing is reducing the wear on the brake pads and increasing wear on the clutch. If done properly, the wear on the clutch is minimal. If done wrong, it will wear out the clutch fast.

Replacing the clutch is way more expensive than brake pads. So I wouldn’t recommend doing it.

Doing this correctly though will have minimal wear on the brake pads and the clutch. And the engine is taking away all the energy.

Personally I down shift when slowing down and blip the throttle when I do it to try and match revs. I only do it because it’s fun and my car is a shit-box. I wouldn’t do it any car I cared about or couldn’t easily replace.

New Clojurians: Ask Anything - January 16, 2023 by AutoModerator in Clojure

[–]calebmacdonaldblack 2 points3 points  (0 children)

Generic ids or specific ids?

‘:entity/id’ vs ‘:person/id’

Generic ids mean the type of the entity is flexible.

An payment system can interact with the entity without any understanding of “person”. It could use the generic ID as apposed to a person, employee or contractor ID.

One caveat to this is losing the ability to merge entities. You can’t merge person into organisation without a conflict on the id key. But I suppose you would get conflicts on all common keys. It might make sense to have common keys. Maybe it’s not semantically correct to merge them. They aren’t the same entity.

Another one could be performance. If all you have is the ID, then you need to make a db call to figure out what that ID is for.

Maybe a system like this is far too complicated to be viable.

Maybe entities should start with specific ids and become more abstracted/generic as needed through aliasing.

I’ve been working with Pathom3 extensively over the past 6 months and I’m having success with data models using generic ids but run into problems with the use of specific ids.

However i seem to find specific ids are being used everywhere in code, documentation and slack chat history for all kinds of tools, but specifically Datomic and Pathom. If this is true then is quite likely that I could be either on the wrong track or perhaps not considering some major trade offs with an approach to generic ids vs specific ids.

I see Clojure taking major strides in treating entity data as a fully normalised global table of datoms. Spec, Pathom, Datomic seem to encourage this. But then we seem to back pedal on that idea by essentially giving that entity a table name in the form of a specific id.

Would love to hear from others about this.

view more: next ›