DEV Community: Marco Ledesma

Daily Stand Ups for Devs

Marco Ledesma — Sat, 27 Jul 2024 17:24:06 +0000

During a recent vacation, I wanted to code...something. My background is primarily in .NET and Laravel, with Laravel being my most go-to stack since its quick to develop anything. Anywho, at my company we've been managing our daily stand ups in a Confluence doc, constantly updating it as the sprint goes on. It turned out to be a really good system to keep track of everything we're doing and have it documented for each sprint. For example:

Say your Sprint is called Abracadabra, you would create a corresponding Confluence document with the same name.
You would then start by adding a table per day. Members of your team would insert their "In Progress" tasks, their "Priorities", and any "Blockers".
You continue to insert new tables as the days of the sprint continue, until the sprint is over.
Then you create another Sprint doc and repeat.

Although this worked well, we found that there were a lot of conflicts that occurred as a result, since all of us were updating the same confluence doc. This is where the idea for this app came along.

Daily Stand Up App

The goal of this app is to replicate the same experience of writing stand up entries within a Document, with the exception that it would be impossible to have conflicts.

The way it works is like this:

You create a Stand Up group, which would be your Sprint name.
Once created, click "View". This will take you to a place to add entries.
You can submit your first entry. All you need is a Date and your stand up details.
And then at any moment you can edit that entry.

All your stand up entries are under the stand up "group", which is under the currently selected "team". You can freely create teams, invite others to your team, and have everyone see each others stand up information (though only the author of the stand up entry can edit or delete their entry).

Open Source

https://github.com/m4rcoperuano/daily-standup-2

I wanted to build an app that is more of a tool rather than a product (though it can certainly be one). I also understand that not everyone wants to use a hosted platform where you, and others in your company, put sensitive information into. So by open sourcing it, you can pull the repository down and host it in any environment you wish. For the time being, I've hosted mine on a subdomain of my website: https://standups.sunnyorlando.dev.

Is It Production Ready?

Not quite. First, there is no landing page that advertises what this app does effectively (the landing page of the site is still Laravel's default one). Also, if you register for an account, you will be greeted with an empty "Dashboard" page (part of the starter kit I used). Otherwise, everything else should work as intended with security in mind. There's more work to do still when it comes to Unit tests too, and maybe some better coding practices.

Overall, I'd say I've put about 10-12 or so hours into the project, and at best can be called a Beta.

Tech Stack Details

The app uses Laravel 11.x, PHP 8.3, and MySQL 8.0.
I used Laravel Jetstream to kickstart a few things for me, such as Authentication, Teams, and API support.
The text editor for formatting your stand up entry is CKEditor (which has come a long way!).
The app is hosted on a decent-size Linode instance, with the provisioning of the server handled by Laravel Forge.
It uses Redis as well for caching and user sessions.

What's next?

As time permits, I plan to continue adding features to the project, such as:

Mood tracking: Allows the team to see how everyone is feeling which, if you have a great company culture, may be helpful to see how your teammates are feeling sprint to sprint.
Sprint Retro Automation: Creating sprint retro docs and trying to remember what exactly were issues during the sprint is hard, our memories are not reliable. Therefore, why not have users enter any sprint-retro information whenever they submit their daily stand up? Almost like building a list of notes throughout the sprint that get dumped into a Sprint-Retro bucket, of sorts. Furthermore, leveraging OpenAI, summarization of key points within the sprint should be fairly easy.
Integrations with Slack, Github, and JIRA?
Make Stand Ups fun! Honestly, its such a drag sometimes to just talk through everyone's todolists. There's an NPM package called beanheads (https://beanheads.robertbroersma.com/) that allows each person to customize their avatar. Then, my plan is to show these characters on the screen around a circle of sorts, maybe with a spinning arrow to navigate to the next person to begin giving their update, rather than being called upon by the SCRUM master (though I'm still thinking through all this). I really want the remote-nature of development work to feel more connected. Reading documents, meeting once a day, etc. it all feels so...isolating at times with remote work. Why not have a place where you can have fun with these mandatory meetings, perhaps with web-based games integrated in it? But i digress.

Questions

In my time as a dev, I've been exposed to a variety of ways to do stand ups:

Via Slack
Via Meetings where nothing is written down
Via Emails

I haven't found any that quite work as well as having an ongoing doc per Sprint, but perhaps we've been doing it wrong? I would love to know how your company handles daily stand ups and any pains associated with it :).

Building Apps That Don't Make Any Money

Marco Ledesma — Thu, 11 Jul 2024 00:07:37 +0000

I've forgotten when it was released, but at some point in the past, I released an app called Bill Panda, which you can read about following the link. It was my first complete app that I built to solve a personal problem. I went through the full experience of building it, tearing it down, rebuilding it, tearing it down again, and building it again. I created an LLC that the app is published under, a business banking account, and a light website to market the app. This is a post reflecting on some things I learned during this experience.

Why I built it in the first place

For a long time I was using a spreadsheet to manage my recurring bills. There were apps out there, like Mint, that automate some of this stuff for you. But I always disliked that I couldn't mark my bills as paid ahead of time. I also couldn't use the data to create any cash projections. So i thought, why not build my own? It needed to do a few simple things:

Track my recurring bills.
Notify me of upcoming bills.
Allow me to mark them as paid/unpaid.
Let me add notes
And eventually, reporting, so I can make cash projections.

I originally built it using Laravel - a web application framework. The frontend was all in Vue and the backend was PHP. You can see a demo of it here (I demoed it for a Hackathon, which I won second place :D): Bill Panda Web. The second time I used React Native. The third and final time, it was all Swift UI. It's been a fun journey building the app. I'm finally at a point where I can begin thinking about new features for it. But before I get to those, I thought I'd share a few mistakes I made along the way. You may find this helpful if:

You are about to build a payment system with recurrence.
You work with recurring events in general.
You plan on building your own app.

Mistakes

1. Regarding Recurring Events - Don't store every occurrence in your database!

When I built the web-based version, i made a critical mistake. For my use-case, you should never populate your database with all occurrences of a recurring event. Not only are you creating a TON of data, you also corner yourself by having to answer questions like "this event repeats daily until the end of time, do i create every single event until the end of time in my database? Do i cap it to the first 1,000 events?” Whats the right number of recurring events to create? There is no right number.

During my research developing recurring events, I ran into this amazing post on Github by user bmoeskau: https://github.com/bmoeskau/Extensible/blob/master/recurrence-overview.md. This post sent me in the right direction. You do not create every occurrence, you compute them. You follow a recurrence rule standard that's been around since 1998. I highly suggest reading the github post I linked above if you are going to create a recurring event system!

2. Your friends and family may not like to use your app if they know that you have access to their finances

If you've built the application, you have access to the database. You can promise you'll never look at the database, but cmon, you probably will. Trust is a big thing when it comes to finances - your friends and family probably won't want to use your app if it means handing over all their data. You have to guarantee that their data will not be accessible to you. During the time that I developed the web app, I did not have a way around this. But by pivoting the technology I used, I did find a way.

At some point in the last couple of years, Apple announced SwiftUI.
This looked so interesting that I ended up diving back into iOS development (I've jumped back and forth between iOS/Android app development and Web Development in my history). As I started working in SwiftUI, I thought, why not try CoreData one more time? Maybe work with CoreData and CloudKit. If i was to incorporate CloudKit, the user never has to sign into the app. All their data can live inside a private CloudKit container that I, as the developer, have ZERO access to. It also has an incredible generous free tier that makes it so that I don't have to pay anything. Furthermore, CloudKit data syncs across your iOS devices seamlessly. It had everything I needed (it was also a huge, painful, learning curve). Happy to say that I made the right decision :). The app is running fully on CloudKit.

3. Not working with technology you love

If you have a hobby project and your goal isn't really to get rich, then don't work with technology you loath. This is not to say that I hate Laravel or Vue (they powered the first iteration) - I truly love those technologies. No, the one i tend to loath sometimes is React Native -- which I used for the second iteration of the app.

If you look at a prior post of mine (https://dev.to/m4rcoperuano/react-native-best-practices-when-using-flatlist-or-sectionlist-4j41), I wrote:

...React Native has been the only [language]that has been able to change my mind and has me questioning why I would ever want to code in Swift or Java again.

Looking back, this is still true.....sometimes. Sometimes I hate it. The debugging (not knowing if the bug is in your javascript code, your native module, the react native run time, or once its packaged) is maddening. This doesn't mean I would never code with React Native. For example, if you want to make a cross-platform app, or if it's a requirement from your client/job, then its no problem. But if you're doing it for fun, and you don't care about cross-platform, then save yourself the headache. Work with the native code and framework.

But I digress. If you are working on a hobby project, work with tech that you love. It will motivate you to keep going back to it. Personally, I love using SwiftUI and sometimes wish it was all I did.

Sidequest: Why Is SwiftUI Awesome?

SwiftUI is pretty darn cool once you get the hang of it. This is a framework that Apple has developed so that its easier to make native iOS apps. Here's a quick example:

struct MonthHeader: View {
   var monthName: String;
   var totalDue: Int;
   var amountPaid: Int;

   var body: some View {
      VStack(alignment:.leading, spacing: 2) {
         Text(monthName)
            .font(.headline)
            .foregroundColor(Color.textGeneral)

         HStack {
            Text("\(amountPaid.toCurrency) paid ")
               .foregroundColor(Color.brand)
               .font(.subheadline.bold())
            +
            Text("out of \(totalDue.toCurrency)")
            Spacer()
         }
      }
      .padding()
      .background(.thinMaterial)
      .listRowInsets(EdgeInsets(
         top: 0,
         leading: 0,
         bottom: 0,
         trailing: 0))
   }
}

This is a pretty simple view that displays this:

I find this code super readable. You have:

3 required parameters defined at the very top. These are your "props", essentially (if you are familiar with Vue or React)

struct MonthHeader: View {
   var monthName: String;
   var totalDue: Int;
   var amountPaid: Int;
....

You then have you "body" field, which is essentially a template tag, or what you return from a React component (again, if you are familiar with web). You can learn what the code does by reading my comments below:

   var body: some View {
      //VStack stands for Vertical Stack
      VStack(alignment:.leading, spacing: 2) {
         //Inside it we have a Text field that displays your prop,
         // monthName. It's then modified to look like a headline 
         // with a specific foregroundColor.
         Text(monthName)
            .font(.headline)
            .foregroundColor(Color.textGeneral)

         //Then you have an HStack, or Horizontal Stack, that takes
         // your prop amountPaid and uses an extension (a function) 
         // that converts it to currency. It also sets the color to a
         // specific "brand" color that I selected, and makes the 
         // font a subheadline that is bolded. 

         //Finally, another text element is right next to it 
         // (concatenated) that represents the amount due. The reason 
         // is separated from the first Text element is because I 
         // don't want it to be colored at all.
         HStack {
            Text("\(amountPaid.toCurrency) paid ")
               .foregroundColor(Color.brand)
               .font(.subheadline.bold())
            +
            Text("out of \(totalDue.toCurrency)")
            Spacer()
         }
      }
      //Then i apply some padding, change its background color to a 
      // .thinMaterial, which apple has provided -- it changes the 
      // background color to be blurred and translucent
      .padding()
      .background(.thinMaterial) 
      //finally, i remove any default padding provided by default 
      // from Apple's SwiftUI framework
      .listRowInsets(EdgeInsets(
         top: 0,
         leading: 0,
         bottom: 0,
         trailing: 0))
   }

Compared to the past, where you would have to create Swift ViewControllers, or worse, Objective-C ViewControllers, this is much welcome change. If my job was to create Swift apps full time, man, that would be exciting.

Summary

It took about 3 years to get the app to a state where I was happy with it. The app was built during nights and weekends, sometimes on vacations. It, thankfully, wasn't too stressful to build. If you love to code and you have a goal in mind, then you'll find the time to make the app that you always wanted to make. Its okay if it takes a long time--we have day jobs. Will I ever make money on this app? I don't really know and I don't really think about it. It serves its purpose to me and a few others (I have about 40+ daily users!). That's all I need to be content with it :).

Coding in a Monolith

Marco Ledesma — Mon, 30 May 2022 20:24:58 +0000

In my experience, I found that web application monoliths are very common in a lot of successful businesses. There are probably many reasons for this, but I found that most companies start out, and continue to build upon, their minimum-viable product. This type of product is usually prototyped quickly, using full-stack web-frameworks like Django, Laravel, of even ASP.NET's MVC framework. Developers then continue to build on top of that MVP as new feature requests are asked from them -- this is largely due to finding product-market fit, leading to an app that is sometimes built on a wobbly foundation... so, what do you do if you are working with a product like this?

To Rebuild or Continue the Majestic Monolith?

It almost feels like a video game. Now that you've progressed in the game, do you restart your character and add points to the areas you know you need to be successful (now that you know what the game is like), or do you continue from where you left off, and try to adapt your acquired skills as the game continues to take you to uncharted places?

To Rebuild:

Pros

No more legacy code 😸
You can now use the latest technologies 📡
You understand the business better, so your architecture will be significantly better thanks to the advantage of hindsight. 👀
Overall, better development experience 🎉
Higher flexibility to adapt to future business changes. With better architecture comes better flexibility. ⚡️

Cons

Your customers are not going to wait until a new build is complete, they will continue to ask for more features. Now you have a problem - adding features to the old app while building the new. 😤
Introduction of a new system of bugs 🐛. Despite the old system having a lot of legacy garbage, its had years of bug fixes & testing. This rebuild will not have that out the gate, leading to some instability in the new system.
Questions from stakeholders asking you - when is it going to be done? 💀 This is the most challenging thing to predict. It took years to get you to the legacy system - how does one estimate a rebuild of an entire system?

To Continue? 🚌

Continuing an app doesn't really require Pros/Cons. If you're considering a rebuild, you already know the cons of continuing the current monolith. The Pros are usually straight forward - features continue to be built, albeit at a slower pace.

Third Option? 🏗

This last option is a combination of the other two -- you build parts of a brand new system, while also continuing your existing monolith. For example, say you have a subsystem to handle notifications. I can imagine your monolithic folder structure would look something like this:

app/
   Events/
      NotificationDelivered.php
   Mail/
      OrderSuccessfulEmail.php
      ItemShippedEmail.php
   Jobs/
      ProcessOrder.php
      ShipItems.php
   Actions/
      SubmitOrder.php
      ShipOrders.php

In this example, SubmitOrder.php will dispatch the ProcessOrder.php job. This job then delivers an Email to the user (OrderSuccessfulEmail.php), which then fires a generic event called NotificationDelivered.php. You can consider these 3 files as part of a larger "domain", such as "Orders". Some of the other files can be considered as part of another domain called "Shipping". Let's refactor these classes around domains.

app/
   Events/
      NotificationDelivered.php

domain/
   Orders/
      Mail/
         OrderSuccessfulEmail.php
      Jobs/
         ProcessOrder.php
      Actions/
         SubmitOrder.php
   Shipping/
      Mail/
         ItemShippedEmail.php
      Jobs/
         ShipItems.php
      Actions/
         ShipOrders.php

So what do we gain from this?

Your domains are clearly defined within these domain folders.
All these features are just groups of related domain functions.

Having these domains split into their own feature folders allows us to detach these domains in the future. For example, the entire Shipping feature could be copied into its own Laravel instance, run separately as a micro-service someday 😵‍💫. Of course, it doesn't need to happen right away, but moving your monolith to a pattern like this will put you in the right direction for slowly breaking it apart in the future 😸.

At my current company, this has been our approach. It allows us to bite chunks out of this elephant a little bit at a time. It’s a huge challenge considering we’re also growing as an organization and introducing new processes all at the same time. Growth pains of a startup 😬.

Just wanted to share some of my experience. If you’ve worked with monoliths in the past, I’d love to hear how your company was able to adapt! The more knowledge we can share, the better ❤️.

React Native: Best Practices When Using FlatList or SectionList

Marco Ledesma — Wed, 25 Sep 2019 17:10:30 +0000

Have you had any performance issues when using React Native SectionList or FlatList? I know I did. It took me many hours and one time almost an entire week to figure out why performance was so poor in my list views (seriously, I thought I was going to lose it and never use React Native again). So let me save you some headaches (or maybe help you resolve existing headaches 😊) by providing you with a couple of tips on how to use SectionLists and FlatLists in a performant way!

(This article assumes you have some experience with React Native already).

Section List Example

Above is a simple app example where users manage their tasks. The headers represent “categories” for each task, the rows represent a “task” that the user has to do by what date, and the Check is a button that marks tasks as “done” – simple!

From a frontend perspective, these would be the components I would design:

CategoryHeader
- Contains the Title and an arrow icon on the left of it.
TaskRow
- Contains the task’s Title, details, and the Check button that the user can interact with.
TaskWidget
- Contains the logic that formats my task data.

This also uses React Native’s SectionList component to render those tasks.
And here’s how my SectionList would be written in my TaskWidget:

<SectionList
    backgroundColor={ThemeDefaults.contentBackgroundColor}
    contentContainerStyle={styles.container}
    renderSectionHeader={( event ) => {
        return this.renderHeader( event ); //This function returns my `CategoryHeader` component
    }} 
    sections={[
       {title: 'General Project Management', data: [ {...taskObject}, ...etc ]},
       ...additional items omitted for simplicity
     ]}
    keyExtractor={( item ) => item.key}
/>

Pretty straight forward right? The next thing to focus on is what each component is responsible for (and this is what caused my headaches).

Performance Issues

If we look at TaskRow, we see that we have several pieces of information that we have to display and calculate:

Title
Description
Due date formatted
Due date from now calculated
“Check” button action

Previously, I would’ve passed a javascript object as a “prop” to my TaskRow component. Maybe an object that looks like this:

{
   "title": "Contact Joe Bob",
   "description:": "Need to talk about project assesment",
   "due_date": "2019-07-20"
}

I then would have my TaskRow display the first two properties without any modification and calculate the due dates on the fly (all this would happen during the component’s “render” function). In a simple task list like above, that would probably be okay. But when your component starts doing more than just displaying data, following this pattern can significantly impact your list’s performance and lead to antipatterns. I would love to spend time describing how SectionLists and FlatLists work, but for the sake of brevity, let me just tell you the better way of doing this.

Performance Improvements

Here are some rules to follow that will help you avoid performance issues in your lists:

I. Stop doing calculations in your SectionList/FlatList header or row components.

Section List Items will render whenever the user scrolls up or down in your list. As the list recycles your rows, new ones that come into view will execute their render function. With this in mind, you probably don’t want any expensive calculations during your Section List Item's render function.

Quick Story

I made the mistake on instantiating moment() during my task component's render function (moment is a date utility library for javascript). I used this library so I could calculate how many days from "now" my task was due. In another project, I was doing money calculations and date formatting in each of my SectionList row components (also using moment for date formatting). During these two instances, I saw performance drop significantly on Android devices. Older iPhone models were also affected. I was literally pulling my hair out trying to find out why. I even implemented Pure Components, but (like I’ll describe later) I wasn’t doing this right.

So when should you do these expensive calculations? Do it before you render any rows, like in your parent component’s componentDidMount() method (do it asynchronously). Create a function that “prepares” your data for your section list components. Rather than “preparing” your data inside that component.

II. Make your SectionList’s header and row components REALLY simple.

Now that you removed the computational work from the components, what should the components have as props? Well, these components should just display text on the screen and do very little computational work. Any actions (like API calls or internal state changes that affect your stored data) that happen inside the component should be pushed “up” to the parent component. So, instead of building a component like this (that accepts a javascript object):

<TaskRow task={taskObject} />

Write a component that takes in all the values it needs to display:

<TaskRow 
   title={taskObject.title}
   description={taskObject.description}
   dueDateFormatted={taskObject.dueDateFormatted}
   dueDateFormattedFromNow={taskObject.dueDateFormattedFromNow}
   onCheckButtonPress={ () => this.markTaskAsDone(taskObject) }
/>

Notice how the onCheckButtonPress is just a callback function. This allows the component that is using TaskRow to handle any of the TaskRow functions. Making your SectionList components simpler like this will increase your Section List’s performance, as well as making your component’s functionality easy to understand.

III. Make use of Pure Components

This took a while to understand. Most of our React components extend from React.Component. But using lists, I kept seeing articles about using React.PureComponent, and they all said the same thing:

When props or state changes, PureComponent will do a shallow comparison on both props and state

https://codeburst.io/when-to-use-component-or-purecomponent-a60cfad01a81 and many other React Native Posts

I honestly couldn’t follow what this meant for the longest time. But now that I do understand it, I’d like to explain what this means in my own words.

Let’s first take a look at our TaskRow component:

class TaskRow extends React.PureComponent {
   ...prop definitions...
   ...methods...
   etc.
}

<TaskRow 
   title={taskObject.title}
   description={taskObject.description}
   dueDateFormatted={taskObject.dueDateFormatted}
   dueDateFormattedFromNow={taskObject.dueDateFormattedFromNow}
   onCheckButtonPress={ () => this.markTaskAsDone(taskObject) }
/>

TaskRow has been given props that are all primitives (with the exception of onCheckButtonPress). What PureComponent does is that it’s going to look at all the props it’s been given, it’s then going to figure out if any of those props have changed (in the above example: has the description changed from the previous description it had? Has the title changed?). If so, it will re-render that row. If not, it won’t! And it won’t care about the onCheckButtonPress function. It only cares about comparing primitives (strings, numbers, etc.).

My mistake was not understanding what they meant by "shallow comparisons". So even after I extended PureComponent, I still sent my TaskRow an object as a prop, and since an object is not a primitive, it didn’t re-render like I was expecting. At times, it caused my other list row components to rerender even though nothing changed! So don’t make my mistake. Use Pure Components, and make sure you use primitives for your props so that it can re-render efficiently.

Summary, TLDR

Removing expensive computations from your list components, simplifying your list components, and using Pure Components went a long way on improving performance in my React Native apps. It seriously felt like night and day differences in terms of performance and renewed my love for React Native.

I’ve always been a native-first type of mobile dev (coding in Objective C, Swift, or Java). I love creating fluid experiences with cool animations, and because of this, I’ve always been extra critical/cautious of cross-platform mobile solutions. But React Native has been the only one that has been able to change my mind and has me questioning why I would ever want to code in Swift or Java again.