Docker is like, my favorite utility tool, for both deployment AND development (my replacement for Python virtual environments). I wanted to hear more of why I shouldn’t use it also.
I find Go to be a great language. I read a couple of books on Go as I started learning it, and I learned about some of the items that the author is complaining from those books ahead of time (rather than encountering them as some sort of surprise or bug).
None of the author’s complaints with the language gained traction with me. I understand the complaints, but my reaction certainly wasn’t “I’m lying to myself about this so I can enjoy this language.” Perhaps it’s because my exposure to Go has been more limited than the author’s, or maybe Go is a great language and these complaints are just language features or trade offs that are good to be made aware of. 🤷♂️
…one of my early uses of Go was making libraries to be consumed from in a different language’s runtime. This was something the author made sound horrific, but something I was doing as a relatively new person to Go. I had to learn “how” to do it, but it certainly didn’t leave me feeling like it was “extremely hard.”
First thing: Ubuntu is the right choice. As far as I’m aware, having run Linux as my main desktop OS for almost a decade and playing with several flavors (…which includes Arch btw 😎), it’s the most polished out of the box desktop experience for someone completely new. It will also likely be the OS with the most Q&A existing on the web for problems you won’t be the first to have encountered.
Secondly, and maybe this should be first, and it sounds like you’ve already got this part down: you have to want to do this. Linux is just not mainstream for the majority of desktop computer users. If you’re not really wanting to do this, you’ll be frustrated when this isn’t the same experience as Windows. (but it sounds like you’re sick of the Windows experience. That’s what started me into Linux years ago.)
Lastly, as far as my quick Lemmy comment goes: Embrace the terminal! You can get around for a while as a Linux n00b on Ubuntu without opening that terminal, but at the end of the day, the *nix shell commands are what make working with Linux great.
The switch will take time. You’ll occasionally need to look up how to do stuff that may have felt simple in Windows… and that will usually be installing and running software that targets Windows only. However, the support for that sort of stuff gets better and better with time. Wine🍷 has come a long way.
It’s worth the journey IMO. For me, I was a PC gamer and I jumped straight into Linux with 0 experience. I learned a lot, spending a lot of time trying to make my Windows games run on Linux. Friends at LAN parties would joke about how I’d spend half the LAN party trying to get my games to run right.
The jokes were a good laugh, but my career shifted since then and my Linux experience carried right over into software development. Everything I deploy is on Linux servers or in Docker containers. All those years fooling around and tinkering with Linux as a PC gamer were loading me with experience that people would pay me for one day.
Single responsibility principle: is your GetData() function responsible for getting data? Or is it responsible for creating a new database connection and also using that to go get the data?
Start naming your functions by what they really do. When you see the word “and” in your function name, you know your function is responsible for too much.
Dependency injection is the difference between CreateDatabaseConnectionAndGetData() and GetData(connection ConnectionType).
In the first example, that function will always connect to the specific db that you hard coded in it. It probably has to also read in a config file to get the connection details. Maybe you should name it ReadConfigAndCreateDatabaseConnectionAndGetData()?
In the second example, I can pass in a MySQL connection or PostgreSQL connection, or some dummy connection for testing.
Keep all that nasty dirty untestable code in one place and spare your business logic from owning all of that.
Go programmer here: What does Go’s simplicity have to do with dependency injection? What does a language itself have to do with dependency injection?
Reading your post and not being personally familiar with your work, I do wonder, perhaps your “extremely complex projects” wouldn’t be so extremely complex if you practiced dependency injection?
How do you unit test your extremely complex projects if your business logic carries the additional responsibility of creating objects?
Question: does anyone here expect a giant billion(s) dollar company to notembrace, extend, extinguish regarding this protocol which these federated services are built upon?
My condolences. This is the stuff Robert C. Martin talks about in his book “Clean Architecture”; database vendors locking you into their tech.
Your boss isn’t just a developer, he’s a *db developer *. From his perspective, the database is a god rather than a means to store information.
I should add onto my original post that the queries should strive to be as database agnostic as possible. This alleviates a lot of pain when the company decides to move from one DBMS to another.
Is it safe to assume your stored procedures have lots of DBMS specific functions and syntax sprinkled among the code?
In my experience, 9/10 times a stored procedure is code that should just be SQL executed from your application (as in, your application sends the query text to the db, rather than that text being stored in the database and executed via calling a stored procedure).
If it’s necessary for performance, sure, go for it. Satisfy your requirements. If it’s not necessary for performance, ask yourself why it needs to be a stored procedure deployed to the database.
CodeBlooded @ CodeBlooded @programming.dev Posts 1Comments 98Joined 2 yr. ago
What makes you say that?
My team relies on Docker because it is reproducible…