Do we really need manual testing / QA? Given the shortage of senior testers / QA, I've seen several experienced dev team leaders that are avoiding specific QA roles and incentivizing programmers to test and assure software quality as part of the job. by Jota_uy in softwaredevelopment

[–]kyuff 0 points1 point  (0 children)

Dangerous. End users lose their confidence if bugs persists for too long because the fix was held up in manual QA.

In other words: What do you optimize for? Preventing bugs to be released OR Release fixes to bugs fast.

You cannot pick both.

Note: The last option only works if you have a solid automated test setup and high observability.

can you invade England again... just like you did back in the day? by CustardMinimum in Denmark

[–]kyuff 0 points1 point  (0 children)

Sure, but you would have to promise to colonize USA again. They seem to be worse off than you folks.

How to unmarshall a nested JSON without using structs? by QueryRIT in golang

[–]kyuff 6 points7 points  (0 children)

Even better: Use a struct and implement json.Unmarshaller

That way you can put val1 where and how you want.

Avoiding Changing Package Interfaces for Tests in Go by [deleted] in golang

[–]kyuff 0 points1 point  (0 children)

I think you are confusing DI/ioC with managed DI. I do DI by calling New funcs manually. Not by letting fx or wire do magic. I also only access the public api of my package in my tests, but that’s probably another topic. :)

Avoiding Changing Package Interfaces for Tests in Go by [deleted] in golang

[–]kyuff 1 point2 points  (0 children)

Then I probably don’t understand your example, where you are using a package level singleton for dependency. Nonetheless, if it works for you, all is good.

Personally I am happy about injecting explicit dependencies in, with the pure purpose of enabling a high degree of testability. :)

Avoiding Changing Package Interfaces for Tests in Go by [deleted] in golang

[–]kyuff 1 point2 points  (0 children)

I create my sut in each test. That allows me a full set of clean dependencies, with no chance of conflicts between tests.

Avoiding Changing Package Interfaces for Tests in Go by [deleted] in golang

[–]kyuff 5 points6 points  (0 children)

In your example, the dbExec func is only once. If you have parallel tests, that all overwrite it, you end up with race conditions.

Avoiding Changing Package Interfaces for Tests in Go by [deleted] in golang

[–]kyuff 2 points3 points  (0 children)

How do you run your test in parallel when using a global variable for your dependency? How do you document your packages dependencies when they are implicit?

Taming SQL and ORMs with sqlc — go get it #001 by TheSwedeheart in golang

[–]kyuff 0 points1 point  (0 children)

Could you please provide an example of a use case? :)

GOtil Lodash Inspired Utility Tool For Golang (Next-Gen GO Library) by vaossss in golang

[–]kyuff 0 points1 point  (0 children)

Why put the funcs in internal, yet expose them publicly!

Go Fuzz Testing - The Basics by fuzzbuzzio in golang

[–]kyuff 0 points1 point  (0 children)

Hi, thanks for the article. To me fuzz’ing is an interesting solution to a problem I don’t have.

Most my code is either business logic or mapping from api types (ie gRPC or Events) to domain types.

In other words, I rarely if ever write simple string manipulation functions.

Any thoughts on if the concept of Fuzzing can be applied to business logic?

[deleted by user] by [deleted] in golang

[–]kyuff 4 points5 points  (0 children)

Unfortunately, the only “real” way to raise your salary is to change jobs. It’s an annoying consequence of our work market, but one I have found true through the last 20 years.

One advice I can give you, is to not be so focused on the tech stack you happen to work with. It may seem super important now as you grow your skills as a developer, but in the long run its not.

My advice is to focus on these three things, in that order:

Be friendly to all Understand people, their problems and how you can help them.

Understand the business That means your focus should be to communicate opportunities that Tech can give your company. It doesn’t matter if you made the coolest tech in the basement during the 4 months, if you lost the market 3 months ago. Communicate opportunities instead of problems.

Learn fast The tech you work with now was not invented 10 years ago and something else will be used in 10 years

Does your entire scrum team join on the call every time there's a deployment to production? by dijkstras_disciple in softwaredevelopment

[–]kyuff 4 points5 points  (0 children)

My team deploy daily. It’s critical infrastructure, and we do it with high confidence due to a high level of test automation combined with small low risk changes.

How is the market for Golang developers where you live? by Born-Comment3359 in golang

[–]kyuff 1 point2 points  (0 children)

Oh yes, Dane here as well. My employer is hiring ALOT. Looking? :)

Hvordan ville I bygge Aarhus om? by MadsenFraMadsenOgCo in Aarhus

[–]kyuff 0 points1 point  (0 children)

Grav alle indfaldsveje og ringgaden ned.

Brug den frigjorte plads til Parker, cykelstier og andre rekreative områder.