Kaustav Das Modak

I've been using Ruby on Rails - The Rails Foundation since version 4 released about 10 years ago. Version 7.1 is brilliant. It takes very complicated, and mundane, coding tasks and wraps them in a library that's super easy to use yet really functional. Normally, things like background jobs, automated emailers, encryption, and file management is difficult to implement. Rails wraps this in logic that makes implementation super easy. One of the hallmarks of Ruby is the idea of 'convention over configuration'. Why waste time trying to come up with unique naming schemes or folder structures? If you stick to the convention, it makes life a lot easier. It's also a lot faster to get a workable solution. Rails has had missteps. Version 5.0 was frustrating to use. Sometimes, you get forced into a pattern you don't like. In version 5.0, when you created relationships between tables (i.e., users have a role and users belong to a department), it forced every row to have a valid relationship. Maybe a user doesn't have a department? Or maybe a user doesn't belong to a role? It created problems. The beauty of Rails is when they recognize a change, albeit with good intentions, isn't exactly what a dev wants. Rails changes their system to match what their customers' want (i.e., dev). Brilliant. I use this concept a lot. How do I eliminate unnecessary variations and use convention over configuration wherever possible? By standardizing the mundane stuff, you get a lot more flexibility and scalability.

1

𝗕𝗿𝗼𝘄𝘀𝗲𝗿𝘀 𝗔𝗿𝗲 𝗦𝘁𝗶𝗹𝗹 𝗕𝗲𝘁𝘁𝗲𝗿 𝗮𝘁 𝗡𝗮𝘃𝗶𝗴𝗮𝘁𝗶𝗼𝗻 𝗧𝗵𝗮𝗻 𝗡𝗮𝘁𝗶𝘃𝗲 𝗔𝗽𝗽𝘀 Native apps are getting closer to emulating the browser experience, but there’s still a gap that’s hard to ignore. While the "back" button is present 🚪🔙, native apps often miss two essentials: • A history of visited pages • A "forward" button for quick recovery It’s a reminder that while native apps excel in many areas, they still have some catching up to do when it comes to seamless navigation.

2

NEW: Internal Threads Internal threads allow you to spin up conversations in Slack from Pylon. It's great when you want to start a conversation with someone, but they primarily use Slack (e.g. engineers, product people or anyone who isn't living out of the support system). Common internal threads we are creating at Pylon: 1/ #bugs to report a potential bug 2/ #project channels to ask a team a question about a specific feature 3/ #feedback to report product feedback to the team It's been one of the most game-changing features we've released and we're so excited to share it with everyone. Enjoy!

44

3 Comments

SaaS is dead because one can now craft their own backend, not stack it. Major difference. SeaaS (service-as-a-software) is the way to custom your own backend, at last. And the BigFours need to adapt damn fast or they will be reduced to low-value tasks within the next couple of years. This slide is part of the deck that we've been showing during 2024. Most of the ideas will be echoed during 2025 by your standard BigTech as the future. Well, they are not the future for the most advanced agents of the tech industry - they are our present and already our past. SmallTech 1 - BigTech 0 #smalltech1bigtech0 Let's keep it up!

7

2 Comments

I've been thinking a lot lately about ways of structuring IaC code, specifically - should this code be separate from application's code, or they can (should) be kept close to each other. When writing backend code, my rule of thumb about managing transactions (and other resources, like connections) is that a method or class cannot interfere with its (transaction's) state if that transaction has been started somewhere outside of that code. In simple words, only a piece of code that started a transaction should make a decision to commit or roll it back. Looks like this model can be applied to codifying infrastructure as well. If an application owns the lifecycle of an infrastructure resource, it is okay to put them in one source code repository. Short unpolished writeup on this topic: https://lnkd.in/emzDC9Nn

2

Top learnings from my discussion with Kishore Gopalakrishna - Language choice for system development should balance team expertise, hiring potential, and ecosystem maturity. A well-implemented system in a familiar language often outperforms a poorly implemented one in a "faster" language. - Distributed systems are complex - they can fail in unexpected ways, making your own computer useless. This challenge is often underestimated. Understand the failure modes. - When building new systems, design for the long-term (10 years) but plan for the near-term (2-3 years). Implement for current needs while keeping the architecture flexible for future growth. Design for long term, plan for short-medium term. - Testing distributed systems requires going beyond known test cases. Develop test frameworks that generate new scenarios automatically to uncover unforeseen issues. - Cost optimization in data systems often involves trade-offs. Kafka, for example, sacrificed transactionality and exact-once delivery for higher throughput and lower cost per log. Its all about the Trade-offs. You get some, you lose some. - When approaching problems, start with first principles. Understand why something is expensive or inefficient before trying to optimize it. Don't jump on a solution. Understand the real problem first. - Open-source success relies heavily on community building. Foster respectful communication, clear processes for resolving conflicts, and a culture of helpfulness to grow a strong contributor base. There are many communities, but only the ones with good culture thrive. - Real-time analytics can significantly boost user engagement. Even small reductions in data latency can lead to measurable improvements in user experience and product value. - When considering real-time analytics, focus on how it can improve your users' lives rather than just technical capabilities. Many support issues can be eliminated by giving users direct access to real-time data. Product isn't useful if it making users' lives better. - Innovation in data products often comes from changing perspective - instead of asking "Do we need this?", ask "How can this improve our users' experience?" This shift can uncover valuable use cases for real-time analytics. Asking the right questions will help you reach the right answers. - When building data products, consider the long-term evolution of technology. Design choices should anticipate future developments, such as improvements in network speed or storage capabilities. Keep your design extensible. - As users become more data-savvy, there's increasing demand for self-serve analytics tools. Empowering users with direct access to data can reduce support overhead and enable more informed decision-making. Empower users to do more with data quickly. ———————————————————————— In case you haven't watched the episode yet, you can watch it here: youtu.be/SmLlJmU9Daw Also subscribe if you like such discussions.

41

3 Comments

Check out our latest Substack post by Anne Steiner and find out why you should ask your engineers, “What do you do here?”

2

Talking about dependency updates...something interesting that Abhishek Anand and i discovered talking to large(ish) companies is that: 1. Upgrading base containers is kinda easy(almost hear many companies doing this at a regular frequency) 2. Updating runtime packages is tough but still doable. 3. Upgrading VMs is the most challenging though...especially kubernetes nodes...some enterprises even taking as much time as 3 months to rollout kubernetes updates. What's been your experience around this? Abhisek Datta

17

2 Comments

Everyone knows the potential of a good #mobileapp. However, few know about the different types of apps and which would work best for them. This Capterra article provides the clarity that #businessleaders need to make that choice. It explains the #prosandcons of web, native, and hybrid apps and how each one could benefit your business. It’s well worth 12 minutes of your day. Some mobile app examples included in this article: Netflix Trello Facebook Spotify Microsoft Office 365 Airbnb Waze Uber WhatsApp Pokémon GO Hub Amazon App Store Evernote Twitter Google Gmail eBay Chime #Mint PayPal Venmo #SoFi Duolingo Udemy Coursera #Sololearn Khan Academy

1

🌅Happy Monday and hoping everyone has an amazing week! 🌅 🪖 🧒🏾💻 If y'all aren't aware, I have a new blog called, "The CodeHer Report: Tech Insights from an Army Veteran’s Perspective, Welcoming All Who Are Curious." and I just recently created a blog post about deploying a Rails 8 app with Kamal I'm excited to share my latest blog post: "Affordable and Scalable Deployment of Rails 8 Apps on Hetzner Using Kamal, Thruster, and Docker." This isn’t just a technical exploration—it’s a mission-driven one. I’ve been playing with different deployment strategies to see how much I can reduce costs for a non-profit project aimed at helping veterans. Keeping costs low while ensuring scalability is key to making sure resources are focused where they matter most: supporting those who’ve served. What’s inside? 🎖️ An overview of Kamal, Thruster, and Docker 🎖️ Step-by-step deployment strategies 🎖️ Tips for minimizing costs while maintaining performance Would love for you to take a look and share your thoughts! #Rails8 #Hetzner #Kamal #Thruster #Docker #TheCodeherReport #WebDevelopment #ScalableDeployment #VeteransSupport #NonProfitTech #Army #Veteran #SoftwareEngineer #ComputerScience #ForeoverLearner #Academic #KnowledgeSharing #Innovator #DHH #RailsWorld2024 #RubyGirlie #FullStack #EveryoneWhoWantsToBeInTechBelong #ThisIsWhatSWELooksLike #DiverseMindSolveDiverseProblems #Grit #ComputerScience #CodeHerReport #StayCurious

5

Caching can make or break the experience. I’ve seen sites soar with the right strategy and struggle when caching is overlooked. It’s not just about speed; it’s about keeping readers happy and your site running smoothly. https://lnkd.in/eUgqYRzG

2

The new GitHub Copilot Extensions are looking like a super smart move. Having access to resources inside Copilot means a lot less context switching. Now to find out how we can get our own Arkahna extension 🤓 https://lnkd.in/gi8ErHJw

9

An update for November 2024 on behalf of the .NET Foundation Project Committee... The most active Community projects for the past month were: Pull Requests: Orchard Core (101), OmniSharp VS Code (88) Commits: Stride (531), TorchSharp (275) New Contributors: Silk.NET (5) Downloads: Polly (25.4M), AutoMapper (17.4M) Full list: https://lnkd.in/eMAQi76S The most active Microsoft projects for the past month were: Pull Requests: .NET Runtime (391), Azure SDK for .NET (272) Commits: Roslyn (873), .NET Runtime (288) New Contributors: Azure SDK for .NET (10), .NET Runtime (10) Full list: https://lnkd.in/eT53-gDp #opensource #dotnet .NET Foundation

23

James Stanier has a good argument for why deadline-driven development is so… difficult → https://lnkd.in/gz3rvj2s “Given that non-technical people don’t understand why software is hard, dates become the stick that they beat you with when you don’t deliver on time. Don’t ask me why, it’s just human behavior. I’m sure you’ve done it when roadworks have taken longer than were specified on the sign, or if a delivery of a package was late. Dates mean something to people, so handle them with care. In fact, perhaps we could do something entirely different instead.” What’s the “something different”? “So, instead, you should take a forecasting approach that follows the uncertainty curve that we outlined above. You start wide, and you taper in. At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.” This is why I will always advocate for time horizon roadmaps → https://lnkd.in/gN8VSYZc

13