Annie Vella

As promised, new workshops are here, geared specifically for junior developers! They're not free but hopefully affordable given then return on investment that these workshops offer. https://lnkd.in/g2RAfZ2d But first: If you're a junior or early-career developer and need a "lifeline" to solve a bug or learn something new, check out my Friday office hours! $30 for 45 minutes to tackle a problem or talk about anything that would be helpful (not free, but far below my professional consulting rates in order to reach more folks that need a hand.) And now, about the workshops: Both workshops assume you've already tried to learn something on your own or via bootcamp, but things aren't quite clicking. These workshops demystify the most common areas that stop beginners from learning more. The Rails course is a 4-day "casual yet immersive" centered on really understanding Ruby, and HTTP request cycle, how Rails routing works, what controllers are really for, and seeing the real connection between "models" and your database. Rails should be fun! We'll make it fun! The React course starts with vanilla JavaScript and covers the essentials you need to master in order to get the "why" of React. We cover just the React framework itself, so you'll feel confident in continuing with other frameworks as well. Questions? Comment here or email me: [email protected] PLEASE SHARE to reach as many junior devs as we can :-)

9

1 Comment

Great journalistic piece and very fair article in The Register today by Richard Speed which concisely covers all the major issues in the software world which have been top of mind for me. (Still on a social media break so won't be responding to comments.) https://lnkd.in/ei6ynjQf Data tables of the opinion research mentioned in the piece for anyone curious (conducted by Survation on behalf of me late last year): https://lnkd.in/edYUiXha

6

Feeling the disconnect between your tech team and business stakeholders? I’ve been there. That’s why I’m passionate about Domain Driven Design (DDD). → It’s a game-changer for aligning tech and business goals. Here’s why you should consider learning DDD for your next project: Reduces Miscommunication → Develop a shared language. → Ensure everyone is on the same page. Boosts Project Success → Aligns tech solutions with business needs. → Reduces risks and misunderstandings. Promotes Collaboration → Continuous dialogue between tech and business teams. → Better understanding leads to better solutions. That's one big surprise and AHAH moment in this: You can start benefiting from everything listed above even before applying techniques and practices. Stop for a moment and think: - Not having a common language - Being not on the same page - Having tech solutions not aligned with business needs - Having misunderstandings Everything comes from miscommunication. Hence, if you start working on how you communicate & how you foster a shared understanding and collaboration, You're on the road to DDD. In my 25 years of experience, I’ve seen this approach and DDD transform projects, bridging gaps and fostering collaboration. As a solopreneur, I offer consultations and training on DDD and what practices you can use to start now. If you’re ready to bridge the gap and boost your project’s success, let’s connect. Have you applied DDD in your projects? --- That's it! 💬 Comment your experiences 🔗 Share this post 👍 Like if you agree 👥 Follow me for more insights

6

Still super hyped about Rails 8, Kamal 2 and Hotwire Native. So, this weekend I'll attempt implementing all 3. The challenge? Build a basic Point of Sale system, that can record a sale. Web first with an Android front-end backed by a SQLite database. Deployed to Hetzner. Will be adding everything to the below repo #WeekendCodingChallenge #Rails8 #HotwireNative #Kamal2

5

How do you adapt to new technology? Software developers learn in three ways: 1. from walk through videos 2. from documentation 3. from doing I think walk-through videos can show you that you can do something, provide confidence. I find they go too slow most of the time (but the bit you need is glossed over). Documentation has to be well written. The docs I have been reading lately are excellent. Doing is the best way but you have to start somewhere. The best way to learn is to combine all three. ➡️ Gain confidence it can be done, watch walk through videos. ➡️ Learn all about the intricacies and details, keep reading again and again ➡️ Do it. Do it again. Do it again, again. The best way to learn a new system is to start again a few times. Gain confidence. Chat to AI, but only ever get AI to write code that you already understand. You will get completely wrong answers, too. Nothing beats understanding and doing. Gain confidence. Feel free to DM me with any questions about software development.

12

7 Comments

If you’ve ever worked with end-to-end testing frameworks, you’re likely familiar with the frustration of brittle tests tightly coupled to implementation details. Whilst we endeavour to minimise this, some coupling between test and implementation detail is often unavoidable, and this can lead to tests that are prone to break from small, irrelevant, and non functional changes to the UI, whist the behavour is still working as expected. Brittle tests have great potential to introduce unnecessary delays in release cycles. This happens because end to end tests are broad in scope and it’s impossible to know if the rest of the functionality works as expected if a test fails early in the process. This is expecially burdensome as E2E tests are often performed late in a release cycle to their high cost. For this reason the developer feedback loop can be significantly hampered, and the maintenance cost can be substantial. Large Language Models (LLMs) offer a promising solution to this inherent problem. Test cases can be defined at a high level, and then LLMs can dynamically interpret the DOM at runtime, then create appropriate test scripts based on the current state of the UI based on the test objective. This means that anyone, regardless of their programming skills, can write these test cases. Instead of relying on implementation details, these tests interpret with the UI like a user would, and determine the most appropriate way to test the current version of the UI based based on test requirements, thus avoiding all unnecessary coupling to implementation detail. While there is some inherent complexity in such a solution, such as the context size of the HTML representation of the DOM, and other challenges notably around performance, the potential for more robust and adaptable testing is significant. I have seen promising results from optimization techniques such as Retrieval-Augmented Generation (RAG) search on a custom render tree representation of the DOM, enhanced with computer vision classification of bounding boxes. Given the success of universal scraping solutions leveraging LLMs, the idea of stable end-to-end tests might just be within our grasp. Imagine a future where end-to-end test cases are so robust that they not only survive multiple iterations of a UI but could even operate across platforms where the functionality is the same, such as testing the search functionality of different search engines. This prospect invites us to reconsider not just how we test, but the very resilience and adaptability of our testing frameworks, making them accessible to a broader range of contributors. #Testing #EndToEnd #LLMs #Automation #SoftwareDevelopment #AI

3

One of the foundations of micro service design is "owning state". Yet... engineering teams and organisations fail to follow this tenet. I see this all too often. The most common manifestation of a badly createf micro services architecture is the shared database. This is one where the product is split into "micro services", each having its own repository in GitHub. The have teams that are maintainers of those repositories, that evolve "independently" yet share the same database as all the other micro services (ie repositories) 🚫 What it is not - A micro service is not separate repositories. - Its not having different teams maintain different code bases. - Its not having different subset of APIs and prefixing them with a service name. ✅ What it is - A micro service is a logical, self reliant, independently evolvable set of technologies that work well with other parts of the product ecosystem and are not coupled (ie bogged down by) other parts of that ecosystem. - Micro services are meant to encapsulate business domains, databases, caches, message schemas etc and expose them via public interfaces. For anyone not maintaining the micro service, it is merely an API that defines a set of behaviours (or functionality) with clear inputs and outputs. Thats it. It is a blackbox and a change in one service MUST NOT necessitate a change in another service. Unless there is a significant change in the public interface. #microservices #saas #softwareconsulting #systemarchitecture #goodpractice

3

1 Comment

Agile is the first firm we've talked to that understood this stuff Agile Networks: Architecture Firm Referral - First Conversation Snippet AN = Agile Networks AFR = Architecture Firm Referral AN: So you have speed and file space issues - ok AFR: Yeah, Yeah - We just keep spending so much money every 3 years and we're tired of re-inventing the wheel each time AN: So what are you using for Rendering? Rhino or Max? AFR: 3DSMax AN: OK - and I'm assuming Vray and Swarm AFR: That's right AN: And are these Render nodes or just User stations AFR: It's a mix of both AN: Great - so just get a list of your graphics cards so we can make sure they are certified and updated AFR: OK...... Um, I just want to say that Agile is the first firm we've talked to that understood this stuff and didn't have to figure this out, and then charge us for it. AN: Mind if I post that? Agile Networks - IT for Architects

7

Great opportunities

8

Slides from my talk at last night's Christchurch Ruby meet-up. As developers, we encounter cryptography all the time: SSH keys, SSL/TLS certificates, password hashing, JWT signing, and so on. There are plenty of tutorials and libraries to help us. But we're often cargo culting, instead of understanding, and that creates risk. In this talk, I want to try to make cryptography more approachable and intuitive, focusing on the concepts rather than the maths.

9

Important read.

10

"In this three part article we will look into the three exes of technically possible, ethically and/or morally right and legally acceptable and how they can work in tandem or against each other.." It's a good one from Lena Pejgan Nyström. https://lnkd.in/eB-dViZU

3

My favourite here is Number 3 - (Not) Serving as an Umbrella for Your Team. My take: + For the best solution, and motivation, everyone needs to know why, not pull tickets. + Engineers need to meet stakeholders to they have an appreciation for the human side of things + Junior devs might say "all I want to do it code", but they best gift you can give them, personally and professionally, are soft skills, time/project management skills etc. + No one works in a bubble. Shits hits fans, and lessons are learnt about working on your main project *and* managing to lend a hand putting out someone else's fire. It should be done willingly, not as a credit for the day you'll need them to do it for you, which they will. https://lnkd.in/eKvrRyFh

I’ve never met a good developer who gets micro-managed. While I know there are plenty of micro-managers out there, it’s become a cliche and we never talk about the other side of the story that can trigger that behaviour. Good developers don’t often get micro-managed because they: - Clarify their understanding - Validate their approach very early - Regularly iterate Developers who get micro-managed tend to: - Repeatedly fail to demonstrate understanding - Work in a silo - Disappear for days at a time If you feel like you have to micro-manage or feel like you’re being micro-managed, ask yourself which of the above does the situation look like? 90% of problems will go away if the first scenario becomes the case. ---------- Adrian G Ward - A technical partner to startups and SMBs. Feel like you’re having to micro-manage? I can help you fix that.

22

27 Comments

MVPs shouldn't go to the bin, unless the business pivots to something else. Way too often I've seen agencies & devs building MVPs in a 'poor' way (and that's a nice way of putting it), because 'who cares, it will go to the bin anyway when you get PMF and fundraise'. I disagree. There's absolutely NO reason that your MVP should go to the bin, unless your business model or product change dramatically. And even then, a lot of boilerplate (like signup, subscriptions management, emails, etc) - can and should stay the same. If done right, that should be a given, with 0 extra effort on the dev side. If someone's quoting you to do a poor job, don't work with them. You can stay agile & lean (as a startup should) without compromising on quality, and forcing yourself to rewrite the next version of your app. When you're investing in something, especially at an early stage when money is tight, it's important to NOT buy garbage.

10

2 Comments

One of the qualities that impresses me the most in a tech lead/architect (and others at a similar level) is to recognise their impact on group dynamics. I am ok with leaders having opinions and challenging others, it's necessary for achieving better outcomes. But often, leaders create a sense of superiority that discourages others in the group from contributing. Small things like encouraging others to share their thoughts, and following up after a meeting to ask for feedback, can make a big difference in how people behave around you. Evelyn van Kelle, Gien Verschatse, and Kenny Baas-Schwegler have written a brilliant book on this topic. Highly recommended if you're a tech leader who wants to get the best out of the whole group and not just yourself. https://lnkd.in/eqDAStsM

137

5 Comments

✍🏼 BACK TO WORK WITH COPILOT IN ONENOTE Hands up if you take scrappy notes whilst multitasking… Try Copilot in OneNote 1️⃣ Create a to do list from the information on this page 2️⃣ Rewrite my notes making them clearer and more concise so I can share them with colleagues 3️⃣ Generate a list of pros and cons from my brainstorming session 🔹 Find it here 👉🏼: https://lnkd.in/g43fSVGh! 🔹 Learn about it here 👉🏼: https://lnkd.in/g7JYxMsv 🔹 Top tip👉🏼: Dictate your notes into OneNote and then use 2️⃣ Have you tried Copilot in OneNote? Comment below! #Copilot #Productivity #AI #Microsoft365 #BackToWorkWithCopilot #MicrosoftUK #MSFTAdvocate

4