Jakob Guddas

Ready to learn some practical DSP? If so, we invite you to join us for tomorrow's The Audio Programmer Meetup! We will be joined by Musik Hack Co-Founder Sam Fischmann. Sam has had great success with well known plugins such as Master Plan and Fuel. We will be talking about useful DSP. Including... ✅ Filter basics, frequency and phase, not just frequency! ✅ Filters, when to use (IIR/FIR/linear/minimum phase/biquad forms/svf) ✅ Filter shapes, when to use (bessel, butterworth, chebychev 1+2 , elliptical/cauer/Linkwitz Riley/clamping) ✅ Filter implications for null tests and parallel processing ✅ Oversampling + aliasing ✅ Desmos for testing and comparing saturation techniques ✅ Saturation myths: Harmonic and inharmonic distortion ✅ Basic compressor/limiter design This will be a great conversation for anyone who is seeking to gain an overall understanding of how DSP algorithms work, and how to use them. Tune in here: https://lnkd.in/e9wxeA9h

57

8 Kommentarer

“For every developer I’ve worked with, code is the holy grail.” That’s what Ben Sufiani said in a podcast on Die Produktwerker. 🎧 https://lnkd.in/eyvjQrPs It made me stop and think: 👉 Does that apply to me, too? The answer: yes — but in a different way. It’s not about where the curly brackets go, or whether you use 2 or 4 spaces for indentation. It’s about how the code is organised — because the code is the application. Of course, you can hand full control over to AI. The app will still work — and users might not notice any difference. 🚗 But imagine building a car from parts of different models: an engine from one brand, a gearbox from another, axles from somewhere else, and a body that almost fits. It might run. It might even look fine on the outside. But under the hood — it’s a Frankenstein of components. What about reliability, safety, repairability? AI doesn’t care about modularity or reuse. It just writes what’s needed for the current prompt. It doesn’t check if similar code already exists, or if refactoring would make sense. That’s fine for simple apps. But for complex systems — it’s a recipe for chaos. A patchwork of functionality with no architecture behind it. 💬 What’s your experience with Vibe-Coding? Have you ever looked into the AI-generated code? Do you still care about the code — or just about the speed? #SoftwareDevelopment #AI #VibeCoding #CleanCode #ProductDevelopment

3

2 Kommentarer

Developers don’t become leaders by accident. When I first stepped into leadership, nobody handed me a playbook. I had to piece it together by watching the managers around me — the great ones, the average ones, and the ones who taught me exactly what not to do. That’s when it hit me: the skills that got me here weren’t the skills that would help me succeed next. I had to learn how to: – communicate with clarity – influence without authority – set direction instead of diving into the code – coach instead of fix – deliver outcomes through a team, not through my own keyboard. None of that was obvious at the start. But once you see the shift, you can’t unsee it. If you’re a developer stepping into leadership, you’re not alone — and you don’t have to figure it out the hard way as I did. What have you had to figure out as a manager?

9

Together with Erik-Jan Westendorp, we developed a modular extension for Umbraco 16+ that enhances Umbraco Forms cleanly and flexibly. The idea was simple: make forms more powerful without making them more complex. By keeping everything modular, you can enable only what you need and extend it further when required. What the extension helps with: - Extending Umbraco Forms without touching core functionality - Adding reusable, modular building blocks for form logic - Keeping implementations maintainable and future-proof - Making it easier for teams to adapt forms to project-specific needs This kind of work comes from our shared passion for Umbraco and the opportunity at ilionx to apply that knowledge in real client solutions. Curious about the technical details and the thinking behind this approach? Read more here: https://lnkd.in/eTFs_Tvm

25

🚀 Why E2E Testing with Playwright Matters I was recently testing our “Create Fixed Shift Template” feature, and I ran into a tricky issue. Even though certain items were clearly visible on the UI, Playwright sometimes couldn’t detect them, causing the test to fail. At first, it was puzzling everything looked fine to the eye, but the assertions kept breaking. 💡 What was going on? After reviewing the CI/CD test video recordings carefully and paying attention to minor details, I realized the problem was UI lag when rendering a large number of shifts at once. In production, users usually have fewer shifts, so this never happens there. ⚡ How I solved it: I implemented a pagination and virtualization so that only the visible items are rendered at a time. The results were immediate: 1. Tests became stable. ✅ 2. UI performance improved. ⚡ 3. Users got a smooth and responsive experience, which also builds trust in the system. 💪 ✅ Takeaways: 1. E2E tests catch issues that unit tests often miss. 2. Virtualizing large lists and rendering only visible items boosts the user trust, while keeping the app fast. E2E testing isn’t just about catching bugs it’s about ensuring your users have a smooth, consistent, and trustworthy experience every time they interact with your product. #Playwright #E2ETesting #ReactJS #UserExperience #CodingBestPractices

19

5 Kommentarer

I hope that this encourages organizations to explore inviting programmers into a more participatory role in developing the entire product. I worry that less-experienced programmers will become stuck in these "paid to write good-enough code" jobs and never develop the skill and interest in taking a greater role in product development. Meantime, the programmers who can do this well will all die or, like Justin here, grow tired of the industry, then quit. Not everyone who writes software wants to become a product-oriented entrepreneur. For example: I don't.

21

3 Kommentarer

Day 1 – Understanding the Cascade Many frontend teams underestimate how much time they could save by better understanding the CSS Cascade. The Cascade is not just a set of rules, but the core mechanism that determines how browsers make decisions. Those who understand how Importance, Origin, and Specificity interact write CSS that is more consistent, predictable, and resilient in the long run. The Cascade is not an opponent to be outsmarted – it is a system to work with. Solid CSS starts not with frameworks or tools, but with understanding these foundations. #CSS-Advent-Calendar #CSS #Web-Development https://lnkd.in/ePCBq6Us

7