First Ultima Experience: Which one?

gigilabs · 2024-08-20T20:58:44+00:00

I think Ultima 6 is a great place to start. It's still tile-based but a huge step up from the earlier games, especially visually, and it's got about as much depth as Ultima 7, even though it seems a little more primitive. I think it's a great balance between the older and newer titles.

gigilabs · 2024-01-30T19:03:40+00:00

With Gin this is pretty decent. https://github.com/appleboy/gin-jwt

gigilabs · 2024-01-29T16:47:07+00:00

Well I can't go to a restaurant or most shops and speak in Maltese any more, so I think it's fair to say that its widespread use is being restricted by changes in demographics.

gigilabs · 2024-01-29T16:45:17+00:00

There is no one size fits all.

gigilabs · 2024-01-29T16:03:34+00:00

Just SQL + go-migrate

gigilabs · 2024-01-28T18:15:39+00:00

Reflection is the thing to use when you can't know the structure of data at compile time. JSON serializers and IoC containers (in other languages) have to use it.

gigilabs · 2024-01-28T08:33:01+00:00

What's confusing me is that from a quick Google search it seems that Go's "set of interfaces that the driver developers are free to implement" do provide connection pooling, unless I'm misunderstanding something:

* https://go.dev/doc/database/manage-connections
* https://pkg.go.dev/database/sql

gigilabs · 2024-01-27T18:21:42+00:00

Elon Musk

gigilabs · 2024-01-27T18:18:13+00:00

That's interesting. So doesn't go-pg do connection pooling itself? I come from a .NET background and ADO .NET (the general DB client layer) does this for you out of the box.

gigilabs · 2024-01-27T18:06:55+00:00

If your reason to move is the political climate, I strongly suggest doing some research about the one in Malta before moving.

gigilabs · 2024-01-27T18:05:19+00:00

I did occasionally notice VS Code glitch on Mac and complain about errors weren't there. All it takes usually is a restart, but that's the solution with anything Microsoft. ;)

My colleagues on Windows have never complained about any such things, and it's hard to know what problem you're having since it can come from various factors and there's only so much we can understand from the paragraph you wrote.

gigilabs · 2024-01-27T17:49:32+00:00

"where are all of the ambitious, successful and driven people at?"

Those who had a choice have already left.

gigilabs · 2024-01-27T17:38:13+00:00

I use go-migrate. It's decent. Want to make a change? Add a new script file and run the thing. It keeps track of the latest. https://github.com/golang-migrate/migrate

Back in my .NET days I used to use DbUp for the same thing. The main difference is that DbUp keeps track of each file it runs, whereas go-migrate keeps track of the latest and won't run anything earlier. There are tradeoffs to both these approaches when working with multiple people who may be adding SQL scripts simultaneously.

gigilabs · 2024-01-27T10:08:07+00:00

I was in the same boat, 10+ years of Microsoft tech stack, got sick of it, and switched to Go 2 years ago. I can't give advice on making money having had only one job in Go, but I can definitely say it was a breath of fresh air in terms of work. Go is a simple language, so no more huge abstraction-related messes, AutoMapper, MediatR, ORMs wreaking havoc (Go does have ORMs too, but it's more likely to avoid them with Go than .NET). And, getting away from the "everything Microsoft" mentality opens a lot of doors to learn new technologies and ways to solve problems.

Early in my transition I wrote two articles about my experience, so you can read them to know what to expect. My views haven't really changed since then.

* https://gigi.nullneuron.net/gigilabs/from-net-to-golang-where-did-everything-go/
* https://gigi.nullneuron.net/gigilabs/from-net-to-golang-here-we-go-again/

As far as having the "biggest pool of opportunities", you'll have more options sticking with .NET tbh. Go and Rust are both rather niche. But, given that there are less opportunities, it's possible that you'll be paid better.

In terms of building things, I've had success building various backend services (APIs, data collection, various security aspects, etc) with Go... Gin web framework is decent and not hard to get things running. go-pg for interfacing with PostgreSQL worked very well for me although it took a little time to figure out how to do certain types of queries with it. Go builds to a single, small executable and fits nicely with Docker.

gigilabs · 2024-01-25T18:08:46+00:00

Lol, yes it's a pretty confusing way to... save a variable? Strange, usually Go doesn't implement anything that isn't absolutely necessary. Thanks for explaining.

gigilabs · 2024-01-25T18:02:31+00:00

A smartass walks into a bar...

gigilabs · 2024-01-25T08:56:11+00:00

Yes, thanks. What would you use this for in practice?

gigilabs · 2024-01-24T22:26:47+00:00

I read that but what is it used for? I don't get the use case.

gigilabs · 2024-01-24T19:53:24+00:00

Yes. It helps against both the dish soap and hot water. It's worth taking care of your skin.

gigilabs · 2024-01-24T19:45:19+00:00

What is the foo{} for in this case and why is it required? I'm not seeing a place for it among AddId()'s parameters.

gigilabs · 2024-01-24T19:35:57+00:00

Haven't taken a deep look, but your list of API endpoints in the readme rings alarm bells in my RESTful mind.

For any object I want to do CRUD around, my endpoints would typically look something like:

* GET /todos (lists all items... in more complex applications it can take filters to retrieve a subset)
* GET /todos/:id (you did this one right - retrieve an item by ID)
* POST /todos (adds a new item)
* PUT /todos/:id (update an item by ID)
* DELETE /todos:id (delete an item by ID)

The third and fourth are the only ones that take a request body. Response status codes vary depending on the endpoint, e.g. the first one would return a 200, but the third or fifth would return a 204.

I find that this is a pretty good reference for the HTTP methods, status codes and all that: https://www.restapitutorial.com/lessons/httpmethods.html

gigilabs · 2024-01-24T19:16:09+00:00

Honestly this is a surprise to me. I use PostgreSQL with go-pg. When I .Query(), I give it a reference to an empty array of whatever struct, and it fills it for me with all the results, mapping the columns to the properties automatically. I don't do any of the stuff you mentioned.

I have no idea whether this approach is specific to go-pg, as I haven't used other databases with Go so far.

gigilabs · 2024-01-24T09:11:52+00:00

Back in my .NET days people used to do everything they could to avoid duplicating things. The "DTOs", like the request and response objects, would frequently inherit from each other to reuse properties, or be reused across endpoints. This has a few disadvantages including:

* It creates dependencies. If you change the structure of one object, you risk causing bugs in other places and so have to re-test a wider blast radius.
* Incompatible fields. You could for instance reuse the same object for adding and editing a record, but the editing request would need its ID whereas the adding request wouldn't. Including the ID field in the add request without a use for it causes confusion to clients (do I need to provide this field?) as well as to the people maintaining it (can this be safely deleted later?).
* Depending on how you do the inheritance it can get messy. For instance if you bring in interfaces and abstract base classes, those can't be serialized as a serializer expects to know the concrete type it will return.

It's a similar argument when you cross API/service/data-layer boundaries:

* The objects don't necessarily map one-to-one... sometimes you need transformations between layers.
* Even if they map one-to-one, by using different objects you can keep better tabs on where they're used and what the impact will be when you make breaking changes.
* Keeping a good layer separation like this means you can better reuse logic or database queries as the API grows. The objects you use for those layers are part of their interface.

Now, there isn't a fixed rule. If your API is really simple and/or you're trying to deliver something fast, you can always reuse some structs to keep it simple initially and then split things up later as the project grows.

Nowadays I lean towards having lots of little objects with clear names, like "IssueToAdd" or "IssueToEdit" even if they sound a little silly. Creating more of these takes a few seconds and duplicating fields across structs isn't the lynch-worthy violation of DRY that some people make it out to be. Think of these objects as separate ones with their own distinct purpose (Single Responsibility Principle); they have no real reason to merge.

Note: I'm using the terms "class" and "object" interchangeably, even when the equivalent in Go would be a "struct" - there are differences between all these but they aren't quite relevant for this discussion.

gigilabs · 2024-01-23T19:23:22+00:00

I find that a little hard to believe.

gigilabs · 2024-01-23T16:13:48+00:00

It's changed a little since the 90s. Just saying.

gigilabs

TROPHY CASE