I've been trying to setup a working instance using container apps, web apps for containers and ACI, but it remains finicky. Do you know of a bicep or deployment script that does this properly?
I can tell having ai write small scripts and translating formats has made it more difficult for me to recognise the small differences between languages. I can tell i often get confused about how to do simple things like for loops http requests and file Io in c#, kotlin, rust, go , JS, pwsh, bash, Lua, pythong, groovy etc..
It's not necessarily a bad thing, but it is noticable the languages make less and less of a difference..
Edit: I think it's a similar thing as having a full featured ide with tons of code completion and suggestions. When writing stuff from scratch without prompts you kinda get lazy.
That's interesting. One of the problem for onboarding new engineers is they miss any domain knowledge of our product and building that end-user sensitivity is difficult. Embedding devs with sales,support etc does address this.
What are some problems you've experienced with this approach?
It's difficult problem to solve. Lemmy's stack is a bit unconventional. The rust backend is not idiomatic and the ui is based off a template of an isomorphic not-quite-react framework. Its not impossible, but it will take a while for alot of programmers come onboard.
That being said, there's more to it than writing code. Better bug reports, reproduction, updating docs and triaging/managing the issues is possibly more important than writing PRs. Don't be discouraged!
I just hope they figure out how to fix Azure Functions' isolated mode with the new runtime.
I'm responsible for the engineering department at a midsized SaaS company. In the last two years, we grew from 5 to 20 engineers. We have divided our landscape in separate domains, each treated as a separate product with an API that the other domains interact with. Each domain has a dedicated development team. The end-user domains have POs assigned and the more platformy domains take requests from the other teams.
We lean heavily on automation. Each team is responsible for the development, quality control, security, delivery and monitoring. We don't have a dedicated DevOps or IT role but lean on fully automated self-monitoring systems.
We keep growing and we see that the need for specialisation arises. I'm not one for mandating a certain structure and procedure top-down, so the tools I mentioned above have helped us map out how our org has grown organically so that we can detect human bottlenecks. This we can make the boundaries of responsibilities clear and make choices that minimise the amount of 'syncing' and maximise the amount of decision-making.
Right now I see that the need for dedicated security officers, IT pros, DBAs, and analysts is starting to arise simply because full-stack devs' skills are limiting. Still, I'm unsure if it's best to reinforce the existing silos with specialists, or have a team of specialists that the rest of the org can turn to.
I also see that the complexity of our ecosystem has made it a challenge to onboard new young engineers. Additionally, the separate domains give the teams a great amount of autonomy. Our metrics show that this has dramatically improved the stability of our products in the long term. Still, it has made it more difficult and laborious to organise projects across teams.
These are just a few of the challenges I'm thinking about. Our situation obviously does not apply to everyone, but I am fishing for ideas from people in similar situations or who have seen this phase before. In my experience, every software org has unique challenges and unique solutions with unique outcomes, but I'm certain ideas could inspire other experienced programmers :)
Hey! Why don't you try to build a basic github action from scratch and deploy it 40 times before it's green, waiting 10 minutes between builds to discover how each task creatively interprets directory path notation!
Hey, if the answer is: there's no obvious solution, than at least i don't have to feel too bad 😂
Withought being facetious. It's genuinely important to understand what problem you're trying to solve. If stakeholders are running wild, then critical thinking and good communication is important. If engineers are muddying up progress, then more optimistic and enabling mindset, could be what's needed more.
I agree, but let's just connect now the most effect way so we can figure out the whos and whats of hosting and so we can help @snowe a bit. I agree that we can then take the time to setup Matrix and mailing and all the other stuff. We can migrate from there :)
I think that would be great! I started working on a Azure Functions bot and started a DI dotnet client that I put on nuget https://github.com/ydinkov/Lemmy.Net
It's super wip right now, but Ill be adding more models, tests and error handling.