iiinova — where your digital self keeps evolving

👆 Visit beamdevs.com and subscribe for updates and/or early access as Alpha and Beta tester. 🎯 My target is 1,000 subscribers by the end of March. Otherwise, I will assume the community doesn’t have enough interest in the project. If you want it to become a reality, just hit that subscribe button

100

👆 What actions would you like within the BEAM Devs Network❓ For example, follow, connect, share and ... ✅ Don't miss your chance to shape BEAM Devs with your suggestions 👇 ✨ Like and repost to your network 🎯 Follow me to not miss the next update #BuildInPublic #ElixirLang #Erlang #GleamLang

000

👆 Individual profiles will have a different structure from company profiles. What info would be the most important for you to see in an individual and company profile❓ Bonus points if you can tell from which perspective, dev, team lead, CTO, hiring manager, recruiter, just to name a few. 👇

000

👆 To enable effective networking and easily find matches for who you want to connect with, profiles for both individuals and companies will be strictly structured. When creating a profile, the majority of its fields will need to be filled by selecting from a predefined list of one or more options,

000

👆 BEAM Devs goal is to enable developers and companies to network with others to find projects they can collaborate on, whether open-source or not, and to share ideas and knowledge in closed groups or publicly. 👇

000

📢 BEAM Devs dot com: Your Chance to Shape BEAM Devs Functionality At the core of #BEAMDevs will be the network of developers and companies using the BEAM ecosystem, whether with Elixir, Erlang, Gleam, or another language running on the BEAM VM. #BuildInPublic #ElixirLang #Erlang #GleamLang

631

I agree that the LSP experience is far from perfect and a huge adoption bottleneck for Elixir adoption, but I am curious about what other tools were difficult for you?

100

👆 What would you do differently? Do you have any questions or suggestions? 👉 Share your thoughts and suggestions below ✨ Like and repost to reach your network 🎯 Follow me to not miss the next post #BEAMDevs #ElixirLang #Erlang #Programming #SoftwareEngineering

100

👆 Also, In software development, you can choose the fast lane and build tech debt to ship faster, or you can choose the middle lane to balance speed with quality, my option. Otherwise, new features and bugs will become increasingly difficult to work on as the project grows via the fast lane. 👇

100

👆 I could start with a non-distributed traditional Phoenix app, but I want to use this project as an opportunity to use distribution for real, and to start with a good base for building a very resilient architecture. 👇

100

👆 So, my challenge is to be able to use the failover and request duplicator approach in conjunction with blue-green deployments and keep strong consistency guarantees for my CRUD application. 👇

100

👆 As with everything in software architecture, it's about trade-offs. Thus, this will have some, like added complexity to ensure no side effects occur in the non-production systems and to guarantee that both production and failover are in the same state (strong consistency). 👇

100

👆 I am thinking of using this approach for BEAM Devs, as per the diagram. However, I have a CRUD application from the user perspective, whereas in my previous roles, they were read-only for external users and CRUD internally based on background jobs or request metadata collection and analytics. 👇

100

👆 Bear in mind that I wasn't in the DevOps team, nor did I have input on the architecture. Thus, the diagram in the start of this thread is trying to reflect what I was aware of and can recall. 👇

100

👆 Key Consideration: Applications using this approach must ensure side effects (e.g., emails, billing) only occur in production. A flag-based system is required to enforce this. 👇

100

👆 The request duplicator only relied on production responses but on my case it could be coded to consider the first response from production or failover. For strong consistency guarantees, it could wait for both before returning a response, backed by a TTL and a request failure-handling strategy. 👇

100

👆 In my second role, we had a request duplicator. This tool allowed stress testing of new releases by amplifying live requests (e.g., x2, x4) to find breaking points. It also helped validate major architecture changes before going live by running them in parallel with production. 👇

100

👆 Failover isn't the same as Blue-Green Deployments. While a blue-green deployment gradually replaces an older version, failover runs continuously alongside production. Ideally, both strategies should be used together when possible. 👇

100

👆 When a cloud provider is having an outage/issues or we have a production incident that is not easy to solve or roll back effortlessly, we can switch the DNS to use the failover system, or having clients switch automatically to the failover when production doesn’t respond after a certain timeout. 👇

100

👆 This differs from redundancy within the same provider. In this approach, the switch from production to the failover happens by manually switching the IP for the server in the DNS, which has a very short TTL. 👇

100

📢 #BEAMDevs app: Asking for Feedback on my Software Architecture Draft In my first two UK roles, software architecture always included a failover system, an independent, exact copy of production running in another cloud or on-premises data-center #ElixirLang #Erlang #GleamLang #Devs #Programming 👇

The BEAM requires another mental model to take advantage of it's superpowers. It's easy to start with, but to take fully advantage of fault-tolerance via well structured supervision trees and use of message passing takes time and effort.

010

👇 Are you aware when to use an not use GenServers to avoid bottlenecks?

011

I use MailerLite to collect the emails, thus you need to thank them :) I recognized you immediately in the list and was surprised with your email format, and to be honest I never saw one similar.

100

👆 This isn’t an exhaustive list, and I welcome feedback on it with suggestions to improve it. 👉 Share your thoughts below ✨ Like and repost to reach your network 🎯 Follow me to not miss the next post #BEAMDevs #ElixirLang #MyElixirStatus #Erlang #GleamLang #WeBEAMTogether #Hiring

👆 15. Salary reviews frequency and if they are attached to performance reviews. 16. Probation period duration. 17. Termination notice in days for both the company and employee during probation and after it. 18. Benefits, both legally required and optional. 19. Perks. 👇

👆 11. Sync or async working methodology 12. Holidays: Flexible (20 to 90 days) or a fixed number of paid time off (PTO) days. Unlimited PTO is a lie 13. Clearly defined expectations for the candidate after 1 month, 3 months, and 6 months in the role 14. Performance reviews frequency 👇

👆 6. Links to relevant company pages: About, Careers, Values, Mission, Job Description, Handbook and Social Networks. 7. Salary range with a realistic lower and upper band. 8. Number of hours per week. 9. Work week length: Four or five days 10. Flexible or fixed working hours 👇

👆 3. Skills required and optional, including proficiency levels and how they will be used in the role. 4. Business scope of the role: e.g., Working on the backend of a B2B fintech app. 5. List up to five reasons why a candidate should apply to this role and company in short sentences 👇

👆 To me, job descriptions should focus on what matters and be presented as a list of bullet points to make it easier to find, but not limited to, the following: 1. Clear and specific job title: Elixir Backend Software Engineer instead of just Software Engineer or something vague. 👇

👆 Job seeking is a full-time job for unemployed devs, and I have been experiencing this first-hand. I quickly got tired of job descriptions full of fluff designed to sell the company and the role, making it hard to spot whether the role aligns with my experience and what I am looking for. 👇

👆 This approach will also enable both candidates and companies to specify filters to refine their search criteria, saving time for everyone involved by providing more relevant results for what they are looking for. 👇

Your Gateway to the BEAM Ecosystem - A network hub for developers, companies, and recruiters to showcase projects, share knowledge, and find the best talent in the BEAM world.

📢 BEAM Devs: Gateway for the best BEAM talent Tired of boring job descriptions full of fluff to sell the company and the role? For the future jobs board, the aim is to have job descriptions made up of bullet points that are easy to read, without the fluffy text. 👇 #ElixirLang #Erlang #GleamLang

beamdevs.com

BEAM Devs

250

👆 Scribe Engineering: The fusion between Software and Product Engineering 👉 Share your thoughts below ✨ Like and repost to reach your network 🎯 Follow me to not miss the next post #SoftwareEngineering #ProductEngineering #Programming #Developers #TechDebt

000

👆 Scribes were an elite in ancient societies, highly regarded and holding special social status. They were disciplined and known for their excellent craftsmanship in writing laws, copying documents, and other related tasks. 👇

100

👆 Whatever the next buzzword may be, or whether the current terms remain for a long time, you need to build SOLID foundations for both the product and the business. This means balancing speed in product delivery with engineering craftsmanship. I would name this as Scribe Engineering. 👇

100

👆 I have seen technical debt building up from day zero in both traditional Software Engineering and the newly trending concept of Product Engineering. Some time ago, it was also called 10x Engineers. What will be the next trending term for shipping faster in our industry? 👇

100

👆 Software Engineering isn’t just about caring for code and architecture; it’s about creating solid foundations for your product and business to grow while keeping users happy and focusing on delivering the most impactful features (Product Engineering). 👇

100

👆 This is often followed by coupling between domains, whether intentional or accidental, which is frequently the root cause of overwhelming technical debt. This debt will slow everything down, from fixing bugs to adding new features. 👇

100

👆 One of the primary reasons both types of engineers accumulate technical debt from day zero is that they rush to the keyboard to start coding without proper planning, failing to identify the Domains, Resources, and Actions of the product. 👇

100

👆 It’s like rushing to build a fancy new home that won’t stand the test of time. While they create clear and immediate value for the product and business, they often fail to sustain this as the product grows and time passes. 👇

100

👆 A common trait I have observed among engineers who ship features and projects very quickly is that they don’t build solid technical foundations for the product and the business, despite some think they are doing so. 👇

100