I am working on an event driven system that uses a message bus and has a few services that talk to each other asynchronously via the bus.

I'm writing in memory integration tests for one of those services, but I just realised the fundamental flaw here with such tests. I only have 1 application running, but I need several. This is quite a serious flaw I should have seen before.

Anyone else tried integration testing event driven distributed services? I imagine all I can do is stub the message broker...

Today I spent 9 hours trying to resolve an issue with .net core integration testing a project with soap services created using a third party soap library since .net core doesn't support soap anymore. And WCF is before my time.

The tests run in-process so that we can override services like the database, file storage, basically io settings but not code.

This morning I write the first test by creating a connected service reference to generate a service client. That way I don't need to worry about generating soap messages and keeping them in sync with the code.

I sent my first request and... Can't find endpoint.

3 hours later I learn via fiddler that a real request is being made. It's not using the virtual in-process server and http client, it's sending an actual network request that fiddler picks up, and of course that needs a real server accepting requests... Which I don't have.

So I start on MSDN. Please God help me. Nope. Nothing. Makes sense since soap is dead on .net core.

Now what? Nothing on the internet because above. Nothing in the third party soap library. Nothing. At this point I question of I have hit my wall as a developer.

Another 4 hours later I have reverse engineered the Microsoft code on GitHub and figured out that I am fucked. It's so hard to understand.

2 more hours later I have figured out a solution. It's pure filth..I hide it away in another tooling project and move all the filth to internal classes :D the equivalent of tidying your room as a kid by shoving it all under the bed. But fuck it.

My soap tests now use the correct http client with the virtual server. I am a magician.

Today I used NDepend to analyse my new jobs code base. It looks like the classic big ball of mud :(

Can anyone point me to some example of a .net project that doesn't scale because not using async await for IO?

I'm not sure how to measure impact of not doing this...

I tried SOAP for the first time today. It wasn't bad. I had a client for the service built automatically instead of writing my own.

Why is SOAP dead?

!Dev

Bought my first house :) 3 bedroom house to myself. It's insane to me.

Logarithms give me a headache

Learn more about networking, revisit computer science fundamentals, memorise agile frameworks, practice DDD properly, learn about basic property and conveyancing law for my new job, get through 1 tech book every 2 weeks, revisit Linux as it's been a long time, learn the basics of developing and deploying with azure, learn terraform and docker, finally finish building my own product that has been going for 3 years now, continue learning about mobile development and build a mobile app for my new product.

Should be fine xD

Are there any class based JavaScript test frameworks? I dislike the whole describe/it setup. I know it's basically the same thing, but I prefer the class setup in .net with xunit. I like being able to write abstract classes for tests..

Maslow's hammer is my new favourite quote.

Ad-libbing - when one only knows how to use a hammer, a lot of his problems start to look like Nails.

This is so true

"I am not happy with the quality of the product"

*Ignores

"I dislike how I am forced to work here"

*Ignores

"The team does not understand software design and is writing 2000 line single functions"

*Ignores

"I am starting to think the product cannot be saved unless we start focusing on quality"

*Ignores

"I am not happy in my job anymore because I want to work as a professional..."

*Ignores

"All I ever do now is put out fires"

*Ignores

"I quit"

We use a third party paid company to produce a service and give ongoing support for it, which all our revenue streams depend upon. They are shit and their service is shit. Here's how my conversation about testing went today.

Me: 'hey X wrote an integration test project for the service. It shows the service is broken 50% of the time. We should give their team access to it and have them run it as part of CI'

Colleague: 'They are too shit to setup CI'

PM: 'we are stuck with them so there is no point. It is what it is'

Boss: just ignores me. Not even a reply.

Some days later

Head of QA: 'Hey Dev and QA are broken'

Me: 'because their service is broken. I made so and so suggestion before but it was rejected. We will just have to accept Dev and QA are broken 50% of the time'

Head of QA: 'no we cant'

Me: 'ok so we should setup the tests to run by giving them access'

Head of QA: 'No we shouldn't. The tests can only be used by us and if they break it tells us so we can act on it, or choose not to'

Me: 'We would not want to act immediately on all our revenue streams breaking? Yes we can reverse engineer their client and fix errors as they occur, or we could just have them run the tests and a team our company pays for can stop adding breaking changes to their own API every other day. Right now it has been broken for 2 weeks.'

Head of QA: 'in an ideal world we would have an internal team so you're wrong'

Me: :)

I really don't understand how they can come to such a conclusion. Am I missing something or am I surrounded by total fucking idiots?

My colleague told me today that companies with shit code quality, complete chaos, no tests of QA of any kind, and poor security practices still make loads of money and are extremely successful so it's all a waste of time.

I detest this idea and I refuse to work like that anymore. But I also think he's right :(

I'm thinking about doing a Phd in AI. I'm a software engineer.

Anyone done similar have advice?

I login this morning

Everyone going crazy as prod is broken in a million ways. 2.5 million exceptions In 24 hours.

We talk for 1 hour and solve nothing.

I diagnose the 2 biggest sources of exceptions and explain every step I took with screen snippets to reach my conclusions

The one other competent person on my team agrees. Otherwise complete silence.

I'm told not to fix the issue because I am leaving in 6 weeks and other people have to start taking responsibility.

No one fixes the issues. Instead they leave early. Now it's the weekend and the product is fucked.

Fucking useless people. Can't wait to leave.

It is easy to believe something is over-engineered as a junior. You open a solution and get slapped in the face with a wet fish of many classes, with strange names, doing very little, with everything coming together in ways you don't understand.

My advice is to learn about design patterns, clean code, clean architecture, and model driven design. Until that point I don't think you can make such a distinction. And indeed once knowledgeable of patterns and techniques as well as the domain, the same solution can look obvious, elegant and readable.

In a field where everyone is saying 'dont over-engineer', one must be able to tell if something is actually bad, or just uses techniques you don't recognise.

Telling your senior you think something is over done just because you don't understand it is not good. First learn techniques, understand the code, then form opinions that are at least relevant then.

From someone who committed that crime.

Robert Martin says in clean code, or maybe clean architecture, that one should separate the tests into what is hard and easy. GUI tests are hard and therefore brittle and so we should test against view models.

However on clean agile he says a story is not done until it passes automated acceptance tests which in my experience are always brittle and grow so large and brittle that things grind to a halt.

What am I missing? Are stable acceptance tests possible on the GUI? Should we test only an API?

I just read Robert Martin's chapter on the Single responsibility principle in Clean Architecture.

In it he explains that stakeholders, or actors, that require their own functionality that may be similar to others should have separated code. This is because 2 actors == 2 potential reasons for change.

But this seems to run counter to DRY. Am I mistaken?

Need advice guys

Where I'm working now I'm the tech lead, but I'm not happy. I want to get deeper into infrastructure and DevOps but I have no scope for that.

I have an offer from another company. A very small raise. Supposedly will lead to tech lead in 6 months after I help them recruit a team. Offered mid. I went back and said because of uncertainty about where the role would head, and coming from where I am, I would accept the offer with the title so I have more confidence about the future of the role.

They came back with a senior role, not tech lead, saying there's no scope for that yet. They also said they envision giving me architecture control and letting me train and drive the cloud process.

But this is all heresay. I could take the role, the project is postponed, there is no team to be a tech lead for, and so no pay increase or opportunity to learn.

Opinions?

Angular universal is the bain of my professional life.

Technical interview to solve a fairly simple problem. I proved that I am an idiot.

Really don't want to work for a company that doesn't test new hires well and hires idiots. Ironic :D

Today I created some reusable clean decent code to replace the random chaos in a huge project and then realised I had 3 options:

1. Sort out every instance to use the new code. This is very high risk because the project is both a shit show and has no tests. I don't have time to manual test or write unit tests on so much stuff.

2. Move over only some so that I can manually test. Still no time to unit test (management is fucked on their priorities). This will fuck the project even more since i will never get time to revisit this and adds yet more inconsistency and chaos to a project on its last legs and has this problem in droves.

3. Leave the project fucked

\_(^^)_/

I'm veering towards option 3 these days.

Has anyone ever worked on a project with no architect or team lead? And where no team member has knowledge of OOP or functional, or restful design, or deep framework knowledge or deep language knowledge? And where the accepted best practice for all devs is to copy paste everything so that there is no area you can change and cause breakage elsewhere? And people regularly commit 1000s of lines methods and have never unit tested before?

Because I do right now. Feel free to ask questions of you want.

Colleagues cannot seem to grasp that allowing a user to manually update a field via an Api, that only business process should update is a bad idea.

The entire team of around 10 'software developers' cannot grasp that just because the frontend website won't set it doesn't mean its secure. I have tried many times now...

Just an example honestly... Our project follows a concrete repository pattern using no interfaces or inheritance, returning anaemic domain models (they are just poco) that then get mapped into 'view models' (its an api). The domain models exist to map to 'view models' and have no methods on them. This is in response to my comments over the last 2 years about returning database models as domain transfer objects and blindly trusting all Posts of those models being a bad idea due to virtual fields in Ef.

Every comment on a pull request triggers hours of conversation about why we should make a change vs its already done so just leave it. Even if its a 5 minute change.

After 2 years the entire team still can't grasp restful design, or what the point is.

Just a tiny selection of constant incompetence that over the years has slowly warn me down to not really caring.

I can't really understand anymore if this is normal.

Idea - possibly a bad one - visual studio extension that hits a database to display possible values to supply as a method argument. With caching of course..

I'm thinking along the lines of permissions in a database that at some point have to be hard coded against code to enforce them. Stuff like that.

Possible or beyond stupid?

My team lead thinks using a double Not operator in javascript is too confusing and not readable.

Opinions?

Msal.js. I give it 3/10..

The docs are duplicated, and in various states of out of date. Half the library seems to be undocumented based on how many edge case bugs I've hit, it offers a popup login but you have to have a set specified white list of urls you can launch the popup from which makes a popup login pointless...

Ontop of that my colleagues shat the bed on it and fucked the whole implementation including the azure b2c setup... We do not even have a backend app listed in the azure b2c apps. The redirect also won't work if you don't instantiate an object in a hidden iframe of your own website that fetches a token... This does not make life easy when you use a SPA framework and you have already implemented a whole pipeline abstracting the creation of this object behind layers dependency injection.. Nice.

After sifting through endless shit I finally have a solution. What a week.

We did a small automated review on our code base at work. We discovered that multiple single functions written by my colleagues have a cyclomatic complexity of over 420.

I can't think of words to describe how shit that is.

Today after 1 year of taking shit I sat down with my manager and completely tore the whole fucking company apart.

I absolutely slammed my colleagues, obliterated my team lead, went on and on about how no one understands the basics and how everything we have is copy paste procedural code and the only way to fix what we have is to delete it. I then insinuated I want to quit because I cba with the struggle anymore.

Result? Fat promotion. Not sure what just happened here lmao.

I like the people I work with although they are very shit, I get paid a lot and I mostly enjoy the company but..

Our scrum implementation is incredibly fucked so much so that it is not even close to scrum but our scrum master doesn't know scrum and no one else cares so we do everything fucked.

Our prs are roughly 60 file hangers at a time, we only complete 50% of our work each sprint because the stories are so fucked up, we have no testers at all, team lead insists on creating sql table designs but doesn't understand normalisation so our tables often hold 3 or 4 sets of data types just jammed in.

Our software sits broken for months on end until someone notices (pre release), our architecture is garbage or practically non existent. Our front end apps that only I know the technology have approaches dictated by team lead that has no clue of the language or framework.

Our front end app is now about 50% tech debt because project management is so ineffectual and approaches are constantly changing. For instance we used to use view models for domain transfer objects... Now we use database entities, so there is no commonality between models but the system used to have shared features relying on that..sour roles and permissions are fucked since a role is a page regardless of the pages functionality so there is no ability to toggle features, but even though I know the design is fucked I still had to implement after hours of trying to convince team lead of it. Fast forward a few months and it's a huge cluster fuck to enforce.

We have no automated testing of any sort or manual testing in place.

I know of a few security vulnerabilities I can nuke our databases with but it got ignored.

Pr reviews are obviously a nightmare since they're so big.

I just tried to talk to scrum master again about story creation since any story involving front end ui as an aspect of it is crammed in under one pointed story as sub tasks, essentially throwing away any ability to calculate velocity. Been here a year now and the scrum master doesn't know what I mean by velocity... Her entire job is scrum master.

So anyway I am thinking about leaving because I like being a developer and it is slowly making me give up on doing things to a high standard and I have no chance of improving things, but at the same time the pay is great and I like the people.