标签：#devjournal

Winning is the part everyone posts about. The two months after — the part where a cash prize actually...

Hey everyone! I bring you my development journey on what I have discovered, accomplishments for this...

What are you working on? I hear these words in my day-to-day. And sometimes, when I hear them, there’s this little brain freeze that happens because my brain is probably trying to put into words the amount of things that have wandered through my head in the last 24 hours. 😂 So I thought, okay, let me try something. I want to take some of those wandering thoughts, explorations, things I'm trying out and things I'm learning, and put them into writing. This is going to be a series where I come and talk about what I'm working on — software engineering, product, work, people, faith, relationships, rest, and whatever else happens to be taking up space in my head at the moment. So, what am I working on? I recently started writing backend code, and there’s a bit of a backstory to that. I built this frontend commerce store years ago where people can come and shop for furniture. At the time, I used a backend-as-a-service to handle the backend side of the application. Now, I’m coming back to that same system and writing the backend myself with NestJS. I wanted to go beyond just consuming a backend and actually understand what is happening behind the scenes. The learning process is a bit stretching at the moment because I’m getting familiar with a lot of new concepts. Tiring and frustrating? Yes. But the feeling when I finally understand the reason behind something is always refreshing. That has been really rewarding lately. I'm also in the middle of launching a mobile application at my workplace, going through system design classes, figuring out how to get the best out of my engineers (AI sub-agents, by the way 😅), and occasionally imagining that dream job where you get to build products that serve millions of people and work with really brilliant minds. Also, I discovered the productivity rush that comes with using large monitors. 😂 Then there's learning how to rest while also trying to close out all the open loops in my head. Building reading habits. Figuring out what to pri

Hello I'm Marlene and I invite you to follow my journey developing ProForma.net. But since this is my first post about ProForma, I will give you an overview of what I'm trying to achieve. What ProForma.net is planned to be The main Goal is to develop an application shell for schema based Applications. You will have mainly to different types of UI schemes, first for the Window Layout, there you will tell which elements are contained in the different application sections, like what Buttons or Menus you will have in the window title bar, or what sidebar tabs you will provide for the Ribbons, what the content area is filled with (spoiler I'm going to use flexlayout-react https://github.com/caplin/FlexLayout ). As host application I will write a C# application using the WebView2 abstraction library Photino ( https://www.tryphotino.io/ ). What you can expect In this dev diary series I'll show what I was working on, I'll show you some code and will explain why did to choose the way I did it, or will share some thoughts about the project or the architecture. I also will show you how to write plugins for ProForma, because I plan to handle everything as a plugin so you can change the most aspects of the app. The journey begins: overcome the guard Ok, most of you will know it... parameter checking on top of a method... nearly endless 'if throw' constructs... they are ugly... if (! Directory . Exists ( physicalPath )) throw new DirectoryNotFoundException ( $"Could not find the given path ' { physicalPath } '." ); if ( _directories . ContainsKey ( urlPrefix )) throw new Exception ( $"Key ' { urlPrefix } ' already exists." ); if ( _directories . ContainsValue ( physicalPath )) throw new Exception ( $"Physical Path ' { physicalPath } ' already exists." ); I mean who wants to read that? I don't. So I wanted guards, and I've could used some 3rd Party library, but instead I came up with my own solution for the Guards, since I don't always want to throw the exception on a failed asser

When I first started contributing to open source, GitHub Actions felt like a black box. Seeing a failed workflow on my pull requests was intimidating because I didn't really understand what was happening behind the scenes. Well, this month, I decided to change that. What I Worked On I implemented GitHub Actions across three of my project repos. My main focus was: Adding Markdownlint for Markdown quality Adding Pylint for Python linting. Updating documentation while integrating CI. What I Learned The biggest lesson wasn't technical — it was changing my mindset. A failed workflow isn't something to fear. It's simple feedback. Whether it's markdownlint warning or a pylint error, each failure helps improve the project. Looking Ahead Most of this month was spent improving my own projects, so I didn't contribute much to external repositories. Next month, I want to build on this foundation by contributing to more open source projects and applying what I've learned. Sometimes, learning the tools behind open source is just as valuable as making another pull request. I'm curious What part of GitHub Actions or CI/CD was the most challenging when you first started? Or If you are just getting started, what's the biggest thing that's still a mystery to you? I'd love to hear your experience and tips in the comments. Transparency Note: I used AI as an editor—not as the author. For this article, it helped refine the structure and improve the English grammar. The technical content, experiments, opinions, and conclusions are my own and were reviewed by me before publishing.

Hey everyone! I bring you my development journey on what I have discovered, accomplishments for this...

Part 1 documented the recurring snapback in practice. This note asks a narrower question: what does the observed pattern support, what remains a working hypothesis, and what changes should follow in the project? Status: Bounded project conclusion. This note separates observed behaviour, working hypothesis, and practical consequence. It is based on current project documents and interactions; it is not external validation or a universal claim about AI systems. What the evidence supports 1. The project already contains a stable relational model The working model is not generic “AI assistance.” It separates reasoning surfaces, uses bounded comparisons, permits two-way cognitive pressure, and keeps final acceptance authority with the human. Reciprocal cognitive contribution, asymmetrical governing authority. 2. Concrete project work preserves the structure better than public abstraction At the concrete level, instructions such as: Review this proposal against that architecture. preserve the distinction between the object being reviewed, the surface applying pressure, the evidence, and the authority that may accept a change. When the same structure was compressed into general prose, generated explanations repeatedly returned to a simpler one-way model of either human control or transferred AI authority. That is an observed pattern in this development process. 3. Public explanation is a separate reasoning surface A README, article, summary, or portfolio page is a projection of the model, not the model itself. It cannot be assumed to reproduce the internal structure faithfully merely because that structure is present in context. The explanation must be reviewed against the model it represents: Does this explanation preserve the actual authority, review, evidence, and state-transition structure? 4. Annoyance was useful boundary data The irritation indicated that the generic rendering was no longer merely an imperfect exploration. It was colliding with an internal frame that

Shipped this week Workflows are now a first-class Bizbox primitive — PR #86 · v2026.603.0 The biggest drop this week. @DennisDenuto landed Workflows as a company-scoped concept that sits alongside issues and routines — not shoehorned into either. What that means in practice: Google ADK-backed execution — workflow pipelines run as ADK agents, with phase state persisted as run records. Human handoffs baked in — pipelines can pause and wait for a human before resuming. Deliverables that survive — artefacts from each run are persisted and surfaced in the UI. A pipeline graph in the UI — topologically ordered, showing live phase state and console output. This is the foundation. More on what we can build on top of it below. Workflow human-handoffs now route through ClickUp — PR #91 · v2026.605.0 The day after Workflows landed, @angelofallars wired up the last kilometre: when ADK Python code calls input() inside a pipeline, Bizbox now intercepts that call and sends a ClickUp message to collect the human reply — instead of blocking the process forever. A few things that were fixed along the way: input() monkey-patching now works consistently across Python environments (was silently failing in some setups). Failed workflow runs no longer submit deliverables. You only see artefacts from runs that actually completed. ClickUp awaiting-human bridge adapter ships as a pure plugin — PR #78 · v2026.601.0 This one technically crossed the line on the last day of May (23:56 UTC, 31 May), so it's in scope. @ralphbibera ported the ClickUp transport and adapter as a genuine plugin — implementing the AwaitingHumanBridgeAdapter registry interface — without touching bridge core at all. What that gives you: ClickUp works through the same provider-agnostic layer as any future provider (Slack, Discord, whatever comes next). The core doesn't know ClickUp exists. Included: send/poll/reaction transport, message templates for request_confirmation and ask_user_questions interactions, brain_is_think

We’ve all been there: you are busy coding, and suddenly you get a scary error saying your code conflicts with a teammate's work. Git won't let you pull their changes because it's afraid of overwriting your unsaved files. Instead of panicking, I used git stash. This command acts like a temporary clipboard—it safely hides your current work away so your workspace becomes completely clean. With a clean screen, I was able to safely update the project, fix the conflicting lines of code by hand, and make sure everything compiled perfectly. Once the team's updates were safely pushed, I ran git stash pop to bring my hidden work right back. Git wasn't trying to break my project; it was just protecting my code. Next time you get stuck, remember the golden rule: Stash your work, fix the conflict, and pop it back!

I’ve been out of context with my computer science degree for years, and honestly, it feels overwhelming. I want to change that, so I'm starting this log to document my comeback story, my failures, and my progress. What I did today: Acknowledged the starting line. Took 10 minutes to think about where I left off and what I need to tackle first. Decided to write daily logs. This is not my first attempt to finish the degree, but hopefully with some public eyes on it, it will be the last. 10 subject left. Starting with Mathematical analysis. The biggest challenge right now: Feeling completely out of context and fighting the urge to get distracted by everything else. Many things have changed since i was actively going to classes. My generation graduated many years ago and i feel like getting all the information I need will be extremely difficult since i don't know anyone. Getting information from the university websites and emailing professors will be slow. Next steps: Tomorrow, I'm going to try to overcome my overdramatic anxiety and post in the student groups I was in, in hope that somebody might have new information about the subjects. I will go start lesson #1. Goal is to ease into the material and start a habit, rather than pressuring myself to do everything at once. Come back tomorrow.

**🙄 فى كتاب chapter الصدمة دي هي بالظبط اللي حسيت بيها وأنا بقرأ أول “operating system: three easy Pieces “ ‘OSTEP’. 🖤اهلا بيكم ! يارب تكونوا بخير 💯 حابه اشارك معاكم رحلتى مع قراءة الكتاب ونستفيد منه سوا قبل ما نعرف هو !!!! ولا لا OS is virtual machine 🤔 !!!!دا يعنى ايه ووظيفته ايه OS تعالوا الاول نعرف ال موجودة فى الكمبيوتر ولا لا ؟؟؟؟ RAM وال CPUزى ال HARDWARE وهل هو قطعة ::هنبدأ من الاخر موجود على الكمبيوتر SW هو عبارة عن HW يسيدى مش قطعة OSال .على الجهازINSTALL ولازم يبقى ووظيفته ايه؟؟؟ OS طب يعنى ايه ‘OS’ اختصار “OPERATING SYSTEM”. .“يعنى نظام تشغيل “ .👁‍🗨👁‍🗨 تعالوا نعرف معنى ” نظام تشغيل” ونفسرها نظام تشغيل يعنى مسئول عن 1_ “HWالنظام “من غيره مش هيبقى فيه نظام خصوصا لقطع ال . يعنى بناخد منه الاذن للعمليات HW ببعضه وكمان بيدير ال HWيعنى هو بيربط ال 👏 . (Order)من الاخر بيخلق “النظام” 2_.”التشغيل “هو المسئول عن تشغيل البرامج Learn about Medium’s values هو اللي بيتحكم في دورة حياة البرنامج بالكامل؛هو اللي بيبدأ تشغيله في الذاكرة،OSيعني الـ وبيحدد هو محتاج إيه من إمكانيات الجهاز عشان يشتغل بكفاءة وبيفضل مراقبه ويحميه طول ما هوشغال ، ولحد ما تقفليه بنفسك 🌹 .ويقوم هو بتنظيف الذاكرة وتوفير المساحة لغيره 🧐::وظيفته بقا بيخلي البرنامج يشتغل بسهولة:1️⃣ لأنه بيخلق للبرنامج بيئة وهمية مريحة، وبيخفي عنه كل التعقيدات والأسلاك بتاعة الهاردوير عشان يشتغل بسلاسة 2️⃣: بيسمح للبرامج إنها تشارك الذاكرة بين كل البرامج بالعدل RAM بيشتغل كعسكري مرور بيوزع مساحة الـ . وبيحمي كل برنامج في مساحته الخاصة 3️⃣: بيمكن البرامج إنها تتعامل مع الأجهزة بيعمل كـ “وسيط” أو مترجم بيوصل كود البرنامج بالقطع الحقيقية (زي الشاشة أو الهارد) .عشان ينفذ أوامره فوراً بيعمل التلات حاجات دول إزاي في نفس الوقت وبمنتهى السلاسة؟ ؟؟؟OS طب الـ بيعملهم يسيدى عن طريق أكبر خدعة سحرية في عالم الكمبيوتروهي الـ Virtualization👌 كنت حابة جداً أكلمكم المرة دي عن خدعة الـ “Virtualization” 💎 😌👁👁اللي اتكلمنا عليها في العنوان، بس لقيت البوست هيبقى طويل أوي عليكم ✔🔥!!وعشان متعبكمش معايا.. هنخليها للبوست الجاي إن شاء الله 💯✅!!بيعمل الخدعة دي إزاي OSاستنوا البوست الجاى عشان نعرف الـ 💋.دمتم بخير **

Every team doc tool promises "search everything." Ours did too — and it still didn't answer the question new hires actually ask: not "where is this doc," but "why does this decision look the way it does, and what else does it touch?" We spent the last few months trying to solve that by treating team docs less like a filing cabinet and more like a graph. Here's what we tried, what broke, and what we'd do differently.

Big Howdy, I'm so tired of hearing all the hype about AI. Don't get me wrong, I think AI is pretty cool and I use it all the time for various tasks throughout the day, but I hate AI marketing. What do I mean by that? Whenever there is any hype, advertising, or corporate shilling about AI, it's always vague. Talks about agents, multi-agent systems, RAG pipelines, etc. are everywhere, and yet the specifics are always just out of reach. Even when I try to dig into deeper technical articles, the handwaving usually begins almost immediately. Several architecture diagrams and acronyms later, I still do not have a much better idea of what is actually happening (although I'm not really looking hard enough). I’m going to fix that. For myself, at least. First Stop: RAG My first target is RAG. It's been out for quite a while now and I've been hearing about it for forever. It also sounds like enough progress has been made that the problem has effectively been solved. Best practices have been established and it's pretty commonplace now, so it's a great place to start. But what is RAG? RAG stands for Retrieval-Augmented Generation , which is... not a helpful name if you are just learning about this for the first time like I am. However, if you use AI at all, you've already been using a form of it without even knowing it. RAG is simply a pattern: Retrieve relevant external information. Add that information to the AI model’s working context. Generate an answer grounded in it. That's it. When you use an AI assistant and it goes and searches the internet for relevant information to give you an answer, that's a form of RAG. That doesn't mean your AI assistant is a RAG system, but it can perform RAG functions. But this STILL sounds a bit hand-wavy to me. How does this work in real life? The Part I Kept Missing Context windows are massive these days, but I have seen technical documents that are literally more than 3,000 pages long and full of dense technical information. Even if one tec

Introduction I've spent way too much time trying to come up with some generic introduction for this story, but then I realized none of you probably want to read that anyway. So instead, I'll just jump straight into the story—which is why you're here in the first place. The day I received the requirements The story begins when I received the requirements for a new feature that allows Teachers to share their presentation to review slides before the Lecture begins, so we would have teachers aids using the web version and seeing a screenshare from the main pc powerpoint, at first I thought maybe we can use HLS or RTMP for this and be okay with the 3 seconds delay that it has, but then I continued reading the ticket, we also needed the user to move to the next and previous slides via the web application, which immediately threw my initial idea out of the window. This is because if the user needs to interact with the application there is no way it will be usable without almost immediate feedback. Since we needed to show this to the client quickly we had 2 weeks to implement this feature, so before I did anything, I stopped and started drafting a simple design doc, which besides the fancy name was really just a document with my raw notes taken from research and comparisons between different solutions. After spending some time doing research and looking into different architectures and engineering blogs from companies like Twitch, Slack and Discord, I narrowed the possibilities down to four common architectures used for this type of use case. Architecture Options P2P Mesh This approach revolved around a user establishing WebRTC connections with every other user in the room. Besides being difficult to manage in terms of connections and sessions, it had one fatal flaw: network and CPU overhead. If we had twenty users in the room, every participant would maintain nineteen separate peer connections while sending nineteen streams, quickly consuming both CPU and bandwidth. MCU (M

Most people think building an AI voice agent means writing a clever prompt. I build these for a living, and I can tell you the prompt is maybe an hour of the work. The other week disappears into two places: wiring up everything the agent touches, and testing it against the twenty ways a real caller will break it. So I built a pipeline that points one AI coding tool at each of those problems. Claude Code generates and wires the agent from a spec. Comet, an AI browser automation tool, runs it through dozens of messy call scenarios before a human ever picks up the phone. This post is how that loop actually works, and where it still needs me. Why the build loop is slow (and it is not the prompt) When you picture building a voice agent, you picture the prompt. That is the easy part. The slow part is everything around it. A production agent for, say, a car garage is not one artifact. It is a conversation flow, a set of custom functions that hit your automation layer, calendar and CRM wiring, a telephony number with A2P registration, and a pile of edge-case handling that only shows up when someone calls in angry with a dog barking in the background. The reason it is slow is not typing. It is the round trips. You build a version, you call it, it fumbles when the caller interrupts or asks something off-script, you fix one thing, you call it again. Each loop is a few minutes of manual dialing and listening. Multiply that by the fifty scenarios a real agent needs to survive and you have burned a week. The pipeline exists to kill those round trips. Half one: Claude Code builds the agent from a spec The first insight is that most of what goes into a voice agent is structured and repetitive, which is exactly what an AI coding tool is good at. I do not hand-write every custom function and every n8n node from scratch for each new client. I write a spec, and I let Claude Code turn that spec into concrete artifacts. The spec is a plain description of the vertical and the business: wh

Hi everyone! this is my first post here on dev. About 4 days ago I realized I'm stuck as a mid-level backend engineer, and honestly, not even a good one. Some background: I have a CS degree and started working as a software engineer in 2022. I spent a year and a half at a financial company, then moved to one in the tourism industry, and now I work at a client-based company doing multiple projects. For a while I've felt like my growth here is blocked, so I started looking for another job. That search made me realize something uncomfortable: I've been relying on AI way too much. So now I'm trying to cut down on AI for my tasks, and I've decided to build a couple of projects that'll actually challenge me and help me learn. I've got two projects in mind: a stock exchange engine and a collaborative music production system. I'll share how it goes, including the parts I get wrong! (English isn't my first language, so I used AI to help polish the wording. The story and the projects are all mine.)

Week 5 of my Google Summer of Code journey with CircuitVerse ( June 22nd to June 28th ) is officially in the books. After dealing with a rough sickness last week, I’m happy to say this week was incredibly positive . 🔄 Reconnecting with the Community Since I had to miss last week's sync because I was under the weather, I had to attend the CircuitVerse GSoC Contributors' Meeting this week. It felt so good to reconnect with everyone ! I shared the progress I'd managed to scrape together over the last couple of weeks, and the mentors were incredibly understanding and kind about my slower pace due to being sick. The CircuitVerse community is genuinely unmatched! Everyone is so encouraging, and having that layer of support makes a world of difference. It was also super motivating to hear what the other contributors have been up to. Seeing how much progress everyone has made gave me a massive burst of inspiration to jump right back into development! 🛠️ importCanonical.ts is Completed! Once the meeting was over, I officially finished implementing the entire import pipeline in importCanonical.ts! 🥳 This file does the heavy lifting of taking our clean, deterministic canonical JSON and reconstructing the circuit right back onto the user's canvas. Here is what's packed inside: 🔀 Full Multi-Circuit Support: The import pipeline seamlessly handles projects containing multiple individual circuits. 📐 Smart Subcircuit Dependency Resolution: Just like the export pipeline, the import engine now uses Kahn's Algorithm to figure out the exact sequence the circuits need to be loaded in so that nested dependencies never break. 🛑 What's Missing? (For Now): The import pipeline doesn't validate the incoming JSON file . I am waiting until the canonical format is finalised. Once that's locked in, I will add JSON schema validation in the file. 🚀 The PR Status On the GitHub side of things, the three foundational Pull Requests I opened earlier are still actively under review . One of my mentors gav

Hey everyone! 👋 I'm a complete beginner and today I'm officially kicking off my #100DaysOfCode challenge with Python. I've dabbled with the idea of learning to code for a while, but this time I want to actually commit - so I'm posting daily updates here to keep myself accountable and track my progress over the next 100 days. My plan: Post a short update here every day - what I learned, what I struggled with, and what's next Eventually move into some small real-world projects once I've got the basics down Why I'm doing this: I want to build real skills, not just "watch tutorials and forget everything." Writing it down publicly (even anonymously) keeps me honest and hopefully connects me with others on the same path. If you're also learning Python or doing a 100 days challenge, I'd love any tips, resources, or just to follow along with each other's progress! Day 1 status: Just setting up my environment and going through the basics — nothing exciting yet, but everyone starts somewhere! 100DaysOfCode #Python #Beginner #LearnToCode

A year ago today, I started at Approov. A hundred days in, I wrote about the transition: leaving management, the refreshing day-to-day feedback loop, the strange experience of relearning a craft I thought I'd lost. I stand by most of it. But a hundred days is enough to notice a change; it takes a year to understand it. So here is what a year taught me that a hundred days couldn't. The rust that mattered At a hundred days I called myself rusty. I was. I reached for patterns that no longer fit and looked up syntax I once knew by heart. I expected that to be the hard part. It wasn't. The rust came off faster than I feared, and somewhere along the way I realised I'd been worried about the wrong thing entirely. The agentic era arrived in earnest this year, and it quietly rewrote the job description. The premium skill is no longer how fast you can produce code from memory. It's whether you can write a precise specification and make a strong architectural decision, then judge honestly whether what comes back is any good. Those are not new skills for me. They are the exact skills that years of reviewing architecture and mentoring engineers had been sharpening the whole time. The craft I sat down to relearn was not the craft that turned out to matter. I spent years assuming management had pulled me away from engineering. It hadn't. It had been quietly preparing me for the version of engineering that was coming. Charity Majors has a name for the shape of this: the engineer/manager pendulum. The idea that a healthy career swings between the two, rather than treating management as a one-way door you walk through once and never come back. I didn't choose when mine swung back. But it swung the right way, and the years spent on the other side weren't lost. They were compounding. A secure transaction is a secure transaction The work itself has been a homecoming of a different kind. I spent years in payments. Now I work in mobile and API security. On paper those are different worlds

June was not about making the most contributions -- it was about becoming a better collaborator. This month I had: ✅ 1 PR merged 🔄 1 PR still open 👀 3 PR reviews completed 🐞 1 issue opened I am making this graph all green... Biggest Learning The biggest milestone wasn't writing code. It was reviewing pull requests. One review led the author to update their PR based on my feedback. That experience taught me that open source isn't just about contributing code; it's also about helping improve someone else's work through discussion and constructive feedback. Working Alongside AI Reviewers I also had an interesting experience interacting with automated reviewers like Vercel Bot and Copilot. Rather than accepting every suggestion, I tested them, evaluated the trade-offs, and explained why I chose a different approach. It was a good reminder that AI can assist reviews, but engineering judgement still matters. Looking Ahead My biggest challenge is still finding a larger project that I can consistently contribute to over the long term. That's my main goal for July, alongside publishing my OSS Contribution Toolkit repo and making my CaaS project usable for others. Small, consistent steps continue to move the journey forward. What was your biggest open source learning in June? Transparency Note: I used AI as an editor—not as the author. For this article, it helped refine the structure and improve the English grammar. The technical content, experiments, opinions, and conclusions are my own and were reviewed by me before publishing.