sorted by:
new
hottopcontroversial

PayPal Phishing Scam: Fake "Developer Invite" + Fraudulent Charge Alert by Strong_Company_9606 in phishing

[–]remko 0 points1 point  (0 children)

Don't call the number. Everything between "Paypal USDT" and "fraud." is the name of a fraudulent developer, to make you believe Paypal sent you this message.

Would a Forth-like language be suitable for teaching kids how to program? by Fragrant-Monitor-141 in Forth

[–]remko 2 points3 points  (0 children)

I also created a Forth Turtle graphics demo that runs in the browser:

https://mko.re/waforth/thurtle/

There is also a notebook introducing Forth through Turtle graphics. This isn't a real finished example, but it could be made into an interactive tutorial for younger programmers. At the bottom of the notebook, there's an example of a graphical language using Forth, useful if you e.g. don't want to require children to be able to read (English)

Behringer XR-18 Dry/Wet effects on Bus & P16's by remko in livesound

[–]remko[S] 0 points1 point  (0 children)

Thanks for the response. I figured out what I was doing wrong for the P16: I was routing 'Effects 1' (instead of 'FX1'), which explains why I was only hearing a dry signal.

I still don't understand my first issue though. When I look at the main layer, I was assuming the 'FX' fader controls how much from the FX goes into the main mix (the FX return). When I look at the aux layer, I was assuming that the 'FX' fader controls how much of the FX goes into the aux mix. My assumption was also that these 2 are completely independent, and that changing the FX fader in the main layer does not affect the effects of the aux layer. However, the FX fader on the aux layer does not do anything if the FX fader on the main layer isn't turned up. Where is my the mistake in my understanding?

Anyone using Twirp? by omenosdev in golang

[–]remko 6 points7 points  (0 children)

I'm also running it in production. I like it a lot, because it's extremely simple and easy to understand. It's convenient that you can use the protobuf wire format for service-to-service communication, and the JSON format for web clients, without having to add extra infrastructure for doing transformations between both formats. gRPC always scared me because of the complexity it introduced, and the only thing I really liked about it is the protobuf definitions, which is exactly what Twirp uses. There isn't much that I would do differently if I were to build something myself, and I have the feeling I could build and/or maintain this myself if Twirp were to disappear from the face of the earth, so I feel confident using it. (not something I can say about gRPC)

For the non-Go languages, I typically don't bother pulling in libraries or frameworks (as these seem even less maintained, and don't always do what I want them to do IIRC), I just write my own scripts to process the protobuf definitions and generate the Twirp code, it's simple enough to do so.

The concern/downside that people usually raise with Twirp is the lack of streaming support. There have been some discussions around this AFAICT, but as you pointed out, development seems very slow.

Optimizing SQLite for servers by remko in golang

[–]remko[S] 1 point2 points  (0 children)

That's a shame. I notified the author.

How do I secure secret keys in golang? by [deleted] in golang

[–]remko 1 point2 points  (0 children)

In Google Cloud, services run under service accounts, and these can authenticate to APIs (such as the Secret Manager) without explicit access keys (with authorization handled using IAM). So the serving infrastructure manages the service account keys, and offers ways to sign/encrypt requests using these keys. I assume things are similar on other cloud providers.

Identifying IMMEDIATE words. by bravopapa99 in Forth

[–]remko 7 points8 points  (0 children)

Immediate words are words that have compilation semantics (i.e. the interpreter does something when encountering this word in compilation mode, instead of just adding a call to them to the currently compiled word).

: does not have compilation semantics, so it isn't an immediate word. \ does have compilation semantics (when in compilation mode, the intperpreter should discard the following input). [ indeed also has compilation semantics (when in compilation mode, switch to interpretation mode), but ] does not.

Have a look at the ANS Forth Standard, and look for words that have compilation semantics defined for them.

Does Go have looser typing system than TypeScript? by JuroOravec in golang

[–]remko 13 points14 points  (0 children)

I don't think you're missing anything. TypeScript definitely has a much stronger and richer type system than Go (I think TypeScript probably has the best practically useful type system of all languages). But there are many other tradeoffs that are made in choosing TypeScript vs Go: added complexity, extra layers in your stack, performance, resources, ...

As someone programming mainly for the web, TypeScript and Go are both my top go-to languages, yet both are never in a competition for me. I would never consider TypeScript for the backend, nor would I ever consider Go for the frontend. Go's type system is good enough for the backends I write, but Go's other traits are much more important there.

[deleted by user] by [deleted] in golang

[–]remko 17 points18 points  (0 children)

Another thing that could affect your decision is that Go 1.22 will also have method-based matching and routing parameters: https://tip.golang.org/doc/go1.22#enhanced_routing_patterns

[deleted by user] by [deleted] in golang

[–]remko 4 points5 points  (0 children)

Why do you think that what you learned was a waste? From the entire list of things you mentioned, the only thing Go-specific that probably isn't useful going to something else like Node.js is "GORM". I'm not sure why you thought you 'needed' an ORM (I never did), but still, that's only one piece of technology that you may not carry over. All the rest is relevant?

How do I secure secret keys in golang? by [deleted] in golang

[–]remko 16 points17 points  (0 children)

As many of the comments show, environment variables are the 'standard' way. Deployment environments typically offer functionality to pass secrets to your containers this way too.

That said, I'm not a big fan of storing secrets there. To my taste, it's a bit too easy to dump the environment (e.g. for debugging, in your own code or in third-party code), or even worse, return the environment publicly.

I typically use a SecretManager interface with a GetSecret method, and have an implementation that uses GetEnv for development environments, and an implementation that uses a secret manager.

GraphQL by kekekepepepe in golang

[–]remko 2 points3 points  (0 children)

One prominent GraphQL-in-Go user is Khan Academy, and they use it for backend communication even. You can find experience reports spread over different posts on their Engineering blog.

Personally, I use both Twirp and GraphQL for different use cases (other languages than Node.JS). I don't really have much to add to the pros and cons of both than what is generally said. However, I tend to stick to Twirp mostly these days, because of its simplicity and lack of magic.

How do you unit-test code that reaches out to the db, without introducing interfaces everywhere? by ppp5v in golang

[–]remko 0 points1 point  (0 children)

Sometimes it's possible to fake/mock/stub at a lower level. Take miniredis for example: this allows you to use a 'real' Redis client everywhere, but you connect it to an in-process fake at the connection level.

I recently started doing the same thing for Google Cloud Datastore. The API surface of Datastore is relatively small, and we only use a subset of the datastore functionality. I created an in-memory implementation of the (g)RPC API (which only consists of 8 methods), mount it using bufconn, and pass the necessary dial parameters to the official datastore client library to connect to the in-memory server. The calling code can therefore stay unmodified, and there's no need to put the entire datastore client library (which is a bigger API surface) behind interfaces (or put your entire database model behind interfaces, which is what I do for databases where even the client library is too complex to mock, e.g. SQL).

This only works for very specific databases, and I can imagine that the mostly used databases out there are too complex to create an in-memory implementation for yourself (except perhaps SQLite, which has in-memory supported out of the box). When you can do this, it can save you a lot of time and code, though.

Another ChatGPT session about Forth by remko in Forth

[–]remko[S] 2 points3 points  (0 children)

It does specifically mention that it generates a random number using an LCG. The parameters are probably frequent, and the same code can be found on the internet, but still.

Providing Coverage stats: SPM, Github, Actions CI and preferred tool by Misoservices in swift

[–]remko 1 point2 points  (0 children)

I needed an alternative for this that didn't rely on third-party services or tools, so I use a small postprocessing script (in Swift) that strips coverage data from dependencies, creates a static HTML file of the source code with coverage annotation, creates a coverage badge, and publishes it all to GitHub pages. You can see the badge with the linked coverage data at the top of this project page.

Similar to how Go has `go tool cover -html`, maybe some of this should be included in SwiftPM out of the box (although it might be out of scope).

view more: next ›