Pontus Wiberg

Knowledge Sharing: Day 22 Breaking change if you are planning to upgrade your compileSDK to Android 15 or higher 📢 If you use Kotlin's list.removeFirst() or list.removeLast() extensions in your Android app, then, after bumping compileSdk to 35, your app will crash at runtime on older Android versions. #android15 #android #behaviour #development Kaara

34

3 kommenttia

Traditionally, API management platforms combined different features (like gateways, analytics, and developer portals) into one big package. But this approach has limitations - it isn't very flexible or scalable. Shift toward unbundling API management allows organizations to pick and choose the specific components they need. This way, they can create customized solutions that fit their requirements. However, this approach also comes with challenges, such as dealing with complex integrations and managing different vendors. Feel free to explore the full article for more in-depth insights! https://lnkd.in/eag23q3s #APIDesign #APILifecycle #APIManagement #APIs

5

3 kommenttia

For years I managed to avoid code tests. I manually tested the software against the input and felt that the tests were not what I was getting paid for, I was getting paid for results. The last few years I have shifted my position. Part of the change was that I was no longer a solo developer - I was working with other developers and my changes could impact their code. And I no longer had 100% comprehension of the entire code base as we had other developers writing code. I broke down and even started adding tests to my personal projects to get my feet wet. And it turned out that my tests uncovered issues in the code, code I did have a 100% understanding of. While it was an edge case, it did improve the codebase. I am in the middle of rewriting older legacy code from an out-of-date Rails application to a .NET Core layered application. While I tried to add more testing to the legacy application, it is two versions behind and there are a lot of band aids and dead code. We decided a complete rewrite of the functioning parts would be simpler and actually faster than attempting to update the application. Part of this new code is testing, and I am happy to say that testing in .NET is working out well for me. I’ve already uncovered several edge cases that could have caused issues once we release this to production. Where I am still somewhat ambivalent on is mocking: I worry that the underlying dependency may change and as we are mocking responses, the tests may become invalid. On the other hand, mocking is working out great for the controller tests, and the mocking set up uses those dependencies. Any changes to those interfaces would cause the tests to break, so that alleviates some of my concerns. In the end, as a developer I am paid to create useful code, and the tests are just another tool to help ensure that the code does what it is supposed to. While they take some time up front, they will inevitably save time later on if they are done well. And for fun, I passed the above through Copilot and got the following (there was more but there is a word limit): It sounds like you’ve had quite a journey with testing! Your experience highlights a common evolution many developers go through, especially when transitioning from solo work to collaborative environments. Here are a few suggestions and thoughts based on your experience: Embrace Testing as a Safety Net: You’ve already seen the benefits of testing in uncovering edge cases. Think of tests as a safety net that ensures your code remains robust as it evolves. This is especially crucial in a collaborative setting where multiple developers contribute to the codebase. Balancing Act: It’s important to strike a balance between writing tests and delivering features. Prioritize critical paths and high-risk areas for thorough testing, and gradually expand your test coverage. Your shift towards embracing testing is a positive one, and it sounds like you’re already seeing the benefits.

8

Let's talk about Trust. Recently I just finished my skipper courses, and you know what - it's so much a software development. You're - a cross-functional team of 2-8 people - with a delivery idea of moving the vessel from point A to point B. But yet, that's an extreme sport - and as with every extreme team activity - Trust is key to success. A team member has the Trust if - believe other members are doing their best in their work - believe other member's estimations/promises are true - believe other members will raise a flag once trouble appears > We can fail, but fail quickly and learn. But how do you build that in the team? The first thing you do - you become such a person. You always do your best. You try to keep your word and promises. You fail and talk about that openly. You are - the Trust deliveryman. > As a leader, you need to trust your team first to be trusted. So what do you think? - Do you have a Trust-specific task in your backlog? - How do you measure the Trust in your team? - Did you have an experience where a lack of Trust became a blocker? inspired by https://lnkd.in/dGQCPi9v #LifeIsASoftwareDevelopment

20

2 kommenttia

Highlights of Copenhagen Developers Festival: ⛅ Liz Fong-Jones: Using serverless functions for real-time observability. Liz described how honeycomb.io built a custom cloud-native database using AWS Lambda to the limits of the service. She showed how to achieve low-latency on read. She also discussed in details various strategies for cost optimisation: capacity planning (yes, on Lambda) and using cheaper CPUs. ✳ Phil Nash: Total ReDoS: the dangers of regex in JavaScript. Well described cases of regular expressions taking down popular services (StackOverflow, CloudFlare). Phil not only showed the regexes, he also explained why they take so long to process and finally gave hints to optimise them. It was good to meet another regex afficionado! 🔊 Katarzyna Dusza: Modern & secure adaptive streaming on the Web. Speaker's experience in building media streaming in Spotify distilled into a highly technical and engaging talk. Katarzyna showed (and demoed!) step by step how to go from a regular download to encrypted streaming with adaptive bitrate. It was the kind of enlightening talk leaves the audience with two thoughts "wow, that sooo obvious" and "but... I didn't know that". 👩‍🏫 Emma Burstow: When will you learn? A Teacher’s Guide to Developer Learning. Interesting take on how adults learn, supported by a life story of the speaker. The main takeaway: no pain - no gain. To learn something you need to put real effort. Besides: take one approach and stick to it, reflect, collaborate/share. NDC Conferences #cphdevfest

8

2 kommenttia

𝐂𝐨𝐧𝐬𝐮𝐥𝐭𝐚𝐧𝐜𝐢𝐞𝐬 𝐯𝐬 𝐏𝐫𝐨𝐝𝐮𝐜𝐭 𝐜𝐨𝐦𝐩𝐚𝐧𝐢𝐞𝐬 I've worked in 𝐬𝐭𝐚𝐫𝐭-𝐮𝐩𝐬, IT 𝐜𝐨𝐧𝐬𝐮𝐥𝐭𝐚𝐧𝐜𝐢𝐞𝐬, from niche to mid-sized to Large, the IT dept of non-software companies, and software 𝐩𝐫𝐨𝐝𝐮𝐜𝐭 companies. Let me share some 𝐩𝐫𝐨𝐬 and 𝐜𝐨𝐧𝐬 about working in the different ones. 𝐂𝐎𝐍𝐒𝐔𝐋𝐓𝐀𝐍𝐂𝐈𝐄𝐒 I'll be honest: consultancies have a strong hold over the tech sector in Norway, as there simply isn't many or any big software product companies to speak of. Only small/start-ups. So, a lot of the talent pool is working in consultancies. I eventually left my home country to work in a Software 𝘱𝘳𝘰𝘥𝘶𝘤𝘵 company 🏡 💼 🛫 🌍 😁 𝐏𝐫𝐨𝐬: ➕ Work with experts & technology specialists ➕ Access to great training programs, technical and non-technical ➕ Exposure to many different industries! - Public and private sector. Retail, airports, energy, agriculture, government - etc! 𝐂𝐨𝐧𝐬: ➖ Tech > Problem-solving: You're sold as a <insert tech> dev. ➖ Process & Red tape - Pre-defined deliveries/contracts means things can be slow or difficult to change ➖ Little to no ownership of the product ➖ Certifications > Impact - Consultancies wants you to be easy to sell. Certs works as a proof of your skills. 𝐏𝐑𝐎𝐃𝐔𝐂𝐓 𝐒𝐭𝐚𝐫𝐭-𝐮𝐩𝐬 I had an internship in a start-up as a CS student. This experience was invaluable. I later worked as a software engineer in a start-up, and worked on some very cool projects. Had a lot of fun, learned a lot. 𝐏𝐫𝐨𝐬: ➕ Fast paced, not boring ➕ You can and must wear many hats ➕ Could be career making 𝐂𝐨𝐧𝐬: ➖ Little to no structure or process ➖ Potentially nowhere to grow ➖ A big risk that might not pay off. If you're in a start-up, make sure to get something out of it even if the start-up doesn't succeed. 𝐍𝐨𝐧-𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐩𝐫𝐨𝐝𝐮𝐜𝐭 𝐜𝐨𝐦𝐩𝐚𝐧𝐢𝐞𝐬 I worked in television(!) As a Business Intelligence dev & analyst. Basically a data engineers & Data scientist. ➕ Can have big impact on the product/business ➕ Exposure to potentially interesting domain ➕ Help non-technical stakeholders ➖ Not solving for the core business, not prioritized ➖ Slow to adopt new tech. ➖ Lonely - No dev community. Things like Code quality, CI/CD, DevOps, DevEx... is up to you/your dept, or nonexistent. 𝐒𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐩𝐫𝐨𝐝𝐮𝐜𝐭 𝐜𝐨𝐦𝐩𝐚𝐧𝐢𝐞𝐬 I might be biased here as I currently work in a Software product company, something I wanted for a long time. ➕ Have a big impact on the core business and or for customers ➕ Win by solving interesting & challenging industry problems in smart ways over use <insert tech> by all means. ➕ Ownership of product over time ➕ Career growth opportunities ➖ Working in a high performance environment can be stressful ➖ Bias for action or bust ➖ Learn how to deal with Ambiguity or have a bad time Please let me know what you think of this!!!

30

9 kommenttia

Daily Quick Tip: Tomorrow, when you start your workday, check if the services delivered through HTTP are providing the content in a compressed format. Depending on the traffic, this can save a significant amount of money and only add a small amount of latency, typically around 10-20ms. If you're using a cloud-native load balancer or tools like Traefik, it's very easy to enable compression. If not, you can implement it using a library in your development language or platform. Don't forget to check out the complete benchmark around HTTP compression that Paul Calvano did in his post https://lnkd.in/dVzBFj6n . His research and findings were extremely helpful in providing the insights that can potentially save you a lot of money on data transfer costs. #aws #compression #costs #cost_saving #traefik #cloudnative #tip #quickwin

9

Software-Engineering-Bits #2 - The theme of today's post is: distributed systems. Event Modeling Anti-patterns, Oskar Dudycz 🔗 https://lnkd.in/dRSREurE ➡ A superb talk on Event Driven Architecture. I've read two books on this topic, so I thought I wouldn't be surprised. But it turned out, that the insights, the conclusions, and the way it was presented... it just impressed me. You can see Oskar's hard won project experience. (It's a pity the video is not available on YouTube though. I hope it won't be deleted from Confluent in the future). Light and Dark Side of the Event-Driven Design • Oskar Dudycz • Devoxx Poland 2021 🔗 https://lnkd.in/dZhMwCjX ➡ This video is a predecessor to the one above. Highly recommended if you haven't seen it yet. Software service granularity: Getting it right, Neal Ford and Mark Richards, Thoughtworks, 🔗 https://lnkd.in/d8nuQ2mb ➡ A podcast from Thoughtworks about modularity vs granularity. I liked it because it underscores that term "microservices" doesn't mean that the service has to be very small, and that lambdas can easily turn into "grains of sand" anti-pattern. Untangling Microservices, or Balancing Complexity in Distributed Systems, Vlad Khononov 🔗 https://lnkd.in/duXGyJdr ➡ The podcast from Thoughtworks reminded me of this outstanding article from Vlad Khononov. His concept of "Global vs Local complexity" (which is really a consequence of Tesler's Law) is very appealing and easy to use as an argument. More importantly, this concept/law works on every level of Software Design (from methods to systems). Real-world Engineering Challenges #8: Breaking up a Monolith 🔗 https://lnkd.in/dZB_Bqem ➡ "A deep dive into how Khan Academy took a 1 million-line Python monolith and split it into ~40 Go services in a more than 3 year-long project.". It's the kind of article that caused the explosion of Pragmatic Engineer's popularity. [Polish only] Boiling Frogs 2020 - Łukasz Szydło - DDD w systemach rozproszonych 🔗 https://lnkd.in/d2Gf7qX4 ➡ I watched it some time ago, but it kinda fits the theme of this post. I like it that it goes down to the code and describes problems that might result from the blind adoption of some popular application architectures. [Extra] The sensible defaults playbook - Thoughtworks 🔗 https://lnkd.in/dCqjH62Y (direct link: https://lnkd.in/dtyfR9gM ) ➡ Thoughtworks again. It's not related to distributed systems, but this guide has insightful and sensible (sic) advice on Software Engineering practices. Software-Engineering-Bits is my little knowledge sharing initiative. I share resources I find interesting and valuable. #distributedsystems #softwaredesign #newsletter

3

About 6 months ago, my role changed. As a result, coding is no longer a part of my day job. This has been challenging for me because I have come to identify myself as a coder. Unfortunately, this just hasn't been true for the past several months.   I want to get back into the habit of coding, and this is my challenge to do it. For the next few weeks, I am going to post a few of the code repositories I worked on in my last role. My hope is that this will create a habit of talking about and interacting with code, which will hopefully inspire me to write new code.   This first project I'm sharing is the last project I worked on in my previous role. It is a script that uses the Meraki APIs to pull the allowed clients lists from Meraki networks and then generates an Excel spreadsheet report from the results with columns for the MAC address of the client, IP address of the client, the date and time the client last connected, whether the client is currently online or offline, and the name of the network the client is connected to. I wrote this script because a Meraki customer requested a way to quickly generate reports that showed the last time a client from the network allow list connected to the network so that they could remove clients from the list with extended periods of inactivity. While creating this script, I learned that Meraki only saves the data of clients who have connected to the network in the last month. This makes it difficult to keep track of clients who have not connected to the network in an extended amount of time. I also learned that some of the libraries I used in this script needed to be updated to newer versions in order to work with Python 3.12 😅. If I were to add new features to this project, I would look for a way to keep track of clients for longer than the 31 day limit that currently exists. To do this, I think I would need to create a database that stores the activity of the clients periodically so that I am not completely reliant on the Meraki dashboard APIs and their limitations. You can find the source code of the project on my GitHub here (https://lnkd.in/eU7E9Nen). Feel free to download it and test it yourself if you're a Meraki user. Let me know what you think and what you would like from the script!

51

4 kommenttia

☕ The Coffee-Driven Code Review Manifesto: A Sleep-Deprived Guide to Excellence [Everyone talks about clean code, but let's be honest - most of our best reviews happen after that third espresso shot] 🌅 6 AM: First Commit Code looking pristine Tests all green Documentation spotless Reality: Haven't written a single line yet ☀️ 9 AM: The Morning Stand-up Revelation "Wait, did I just promise to deliver this by EOD?" Frantically opens IDE Types while drinking coffee Spills coffee on keyboard Git commits anyway 🌮 12 PM: The Lunchtime Code Review PR Comment: "Interesting choice of variable names. Is 'pizzaTime' really the best name for a payment processing function?"  Me: "I was hungry when I wrote that..." 🌙 5 PM: The Final Push git commit -m "Fixed everything (hopefully)"  git push origin please-work  git prayer --recursive 📊 Our Revolutionary Metrics: Bugs Found vs Coffees Consumed (1:1 ratio) Time Spent Reviewing vs Time Spent Making Memes About Code Number of "LGTM" Comments That Actually Meant "I Trust You” 🎯 Pro Tips for Sleep-Deprived Reviews: If the code works on the fifth try, it's probably production-ready Comments like "Magic. Don't Touch." are perfectly acceptable documentation If you can't explain your code, blame it on the keyboard 🤔 The Real Code Review Checklist: Does it work? No one knows why it works But it works Ship it! 💭 Question for fellow night owls: What's your record for most consecutive hours staring at a PR before realizing you were looking at the wrong branch? #CodingLife #TechHumor #SoftwareEngineering #DeveloperLife #CodeReview #CoffeeDriver Development #TechMemes

2

Who do I know that uses or has used Apache Beam it looks pretty interesting after the talk from Oleksandr Saienko at #PyConIreland i would love to talk more about it with anyone experienced.

2

Oh wow 🤔 New LLVM will be compiled on Mac with EH off by default (like in other package managers). Note: EH stands for exception handling. https://lnkd.in/dggVsUhb #LLVM #clang #homebrew #rust

4

Embedded developers with niche skills are like gold dust. If you find one, don’t hesitate... hire them quickly. I see over and over that these specialists are often snapped up by companies that understand their value. That means your hiring process needs to be not just fast, but also enticing. Competitive salaries, interesting projects, and a clear path for career growth are essential if you want to attract and retain this top talent. Speed and flexibility in hiring can make all the difference 🙏 The companies that adapt their recruitment strategies to move quickly are the ones that will come out on top.

3

There is a talk about 10x developers in one of threads. I guarantee you, they do not exist. 10x better than competent, not in anyhing, and I mean anything. World record sprint 9.58 by Mr. Lightning himself Usain Bolt. I do not run, at all. I am pretty sure I can do 10 meters in 9.58 seconds. Heck, I will not even run, maybe a brisk walk. That is not to say Usain Bolt is not the GOAT, because he is, and his record will stay I think for ages. This is only to explain what 10x mean. 10x competent, you have not seen 10x competent, that does not exist.

6

29 kommenttia

Great breakdown from Benjamin Drury of DearFlow (Techstars '24)! Give it a read and then go check out their AI assistant!

2

Remember: Most of what we build in software is waste. Users don’t care about: • That complex microservice architecture. • How “innovative” your tech stack is. • Fancy dashboards no one asked for. Focus on solving the right problems.

1

New blog post! https://lnkd.in/dSWpwKv5 "Raise and Release" is a technique I've used whenever I see failure coming and can't do anything about it. Have you experienced something similar? How have you dealt with something like that?

6

1 kommentti

𝐋𝐞𝐭 𝐦𝐞 (𝐫𝐞)𝐢𝐧𝐭𝐫𝐨𝐝𝐮𝐜𝐞 𝐦𝐲𝐬𝐞𝐥𝐟! I've seen an influx of followers as of late, and passed 5k followers on here, which I still have no clue what to do with. Nevertheless, let me (re)introduce myself! I'm a Norwegian based in Amsterdam. - A Software Engineering Manager with one foot planted in AI/ML/Applied Science, and one foot firmly planted in Software Engineering. Which includes System Design, Distributed Systems, and lots of Computer Science that fall outside the scope of AI/ML. - Because even if Computer Science and Software Engineering has fallen in the shadow of AI lately, the most impressive Deep Learning models in the world are nothing without the Software Engineering that goes into serving it to customers in an efficient and enjoyable way. You wouldn't be able to appreciate Netflix's awesome recommender algorithm if videos were stopping all the time because the system couldn't handle millions of concurrent users. AI 🤝 Engineering Aside from being driven to solve problems by applying AI and engineering best practices, I'm 𝐏𝐀𝐒𝐒𝐈𝐎𝐍𝐀𝐓𝐄 about being an awesome leader to the teams and engineers I manage. Which is easier said than done because people problems are 𝐚𝐫𝐠𝐮𝐚𝐛𝐥𝐲 𝐡𝐚𝐫𝐝𝐞𝐫 𝐭𝐨 𝐬𝐨𝐥𝐯𝐞 𝐭𝐡𝐚𝐧 𝐦𝐚𝐧𝐲 𝐭𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐩𝐫𝐨𝐛𝐥𝐞𝐦𝐬. If you don't agree, then I bet you 1 brunost that you're a smug IC, maybe a Tech Lead, who has never actually had the people management responsibilities of a large team 😉 I love it, though. 𝐍𝐢𝐜𝐞 𝐭𝐨 𝐦𝐞𝐞𝐭 𝐲𝐨𝐮! - Who are 𝘠𝘖𝘜??! And what would you like me to post about?

118

28 kommenttia

A new blog post: "Proptest: property testing in Rust" https://lnkd.in/dhnYiwBX In the post, I give a real-life example of using property testing in Rust with Proptest with step-by-step guide. #Rust

15