so-called programmer

Technical Debt Is The Wrong Term - We Should Call it Code Rot

Mon, 12 Dec 2022 08:00:00 +0000

What is technical debt?

The term technical debt gets thrown around at any company that maintains any sort of code base, often used to explain to stakeholders the need to dedicate resources to refactoring. Generally I hear it summarized as expediting delivery by intentionally writing imperfect code, thus saving time. Eventually this debt has to be paid back eventually - either in development time to address it proactively or in the time to recover when things go wrong. However, financial debt has always felt like a poor comparison and at best miscommunicates the problem and at worst misleads the audience.

Financial debt is a bad analogy

Financial debt has little in common with what we call technical debt. Financial debt has to be paid back eventually, usually in a very defined schedule with specific consequences for not doing so. Code is not like that all; there is no “due date” for technical debt and it may never come. The internet is held together with scripts written in a weekend that have been running for years. You also usually don’t know the consequences of not refactoring. Sometimes the market for the product just ends and the code gets thrown away, never needing to be refactored.

There is also an element of intentionality when it comes to financial debt. You take out a loan with the goal of accomplishing something that has a higher rate of return than the interest on the loan (well, in theory, but that’s another blog post). With code, there are occasions where you intentionally make that decision. For example, I often work on an MVP and see an opportunity to use a design pattern to make a feature more scalable, but opt not to go that path because solving for scale isn’t needed at the time. If that need for scale comes suddenly, it will be harder to implement on that tighter timeline in the future, but we don’t handle it now because if we don’t deliver, scale won’t be a problem. This is what I think most of people consider to be technical debt. However, most technical debt is not intentional and as such we shouldn’t call it debt. We should call it “rot.”

Code Rot

The second code is delivered it has an expiration which could come due to known future scenarios and unknown external influences. For example:

A security vulnerability could be discovered, requiring a rewrite several pieces of functionality
Version upgrades could deprecate functionality that you depended on, requiring a work around
Your product could start to be used in unexpected ways, creating bottlenecks in unexpected places
Even lack of documentation causes code rot, expiring immediately the day the one person that understands everything decides to leave. (There’s no such thing as legacy code, just code that you didn’t write and now have to maintain!)
You could have just plain not anticipated something. It happens all the time and should be expected

And kind of like food, there’s no defined expiration date. Sure, you know that the milk will go bad after a few weeks, but how is the flour after a year? And honey doesn’t go bad, right? If you aren’t careful, one day you will open the fridge and it will reek and you’ll have no idea where it’s coming from.

Keep your code fresh

If you want to keep your code fresh, you need to look through the fridge regularly. A really good practice is to get rid of functionality you don’t need. Code that doesn’t exist doesn’t go bad! The idea of “what’s the harm in keeping it?” is a poor one because all code must be maintained.

Log everything. You should have technical notes for each of your features, either in comments or in separate documentation. Call out places that are potential technical debt so that future people (including yourself) have an idea why something is the way it is.

Speaking of technical documentation, make sure it exists! I am a huge fan of code comments on methods explaining what’s going on and the intent. Runbooks are great too, i.e. documentation of how a feature is expected to be used. Keep your solution docs archived and make sure you have a system where your commits can be linked to a change request. Historical context is key to making sure you are addressing rot correctly.

Code rot is everyone’s problem

I often see technical debt used as a way to deflect on a problem - with technical stakeholders saying they don’t get enough time and resources to address issues and non-technical stakeholders saying they don’t have enough metrics to measure success. Cleaning out the code fridge is everyone’s problem.

If you are technical contributer, it is on you to track where the rot is, what needs to be done, and take a swing at some predications on the consequences of not doing so. If you’re a non-technical contributer, you need to consider that this time is table stakes for successfully delivering a product and be ruthless when it comes to prioritizing new work. If you cannot tell the technical stakeholders what the consequences of not adding a feature is, then the feature doesn’t need to be added.

This is all easier said than done - this is both a technical problem and a cultural one. I’m hoping if that if we start using a term that better fits the reality, then maybe we’ll be more successful at communicating it’s importance to the code we work on.

Hosting your own Mastodon server

Tue, 08 Nov 2022 08:00:00 +0000

Why Host Your Own Server

With Mastodon becoming more popular, I wanted to see what was invovled in creating my own server. I figured if it didn’t work out I could join one of the bigger servers later, either by creating a new profile, or by migrating the profile from my own server. There are a few reasons that I think make hosting your own server a good fit for you.

You want to have more control over your own content on the internet. While you may be able to move Mastodon servers, only your profile and followers go with you, NOT your posts
You want to experiment with the technology itself
You already have a bunch of people you want to follow and that want to follow you. Without this, it may be hard for your content to reach other federated timelines if people aren’t able to find you easily.
You want to host a community and are committed to maintaining and moderating your server.

If you are going to open up registrations, that last piece is important. While people can migrate out of your server should you decide not to maintain the server anymore, I think it’s important to be upfront with your intentions so your users aren’t suddenly scrambling to find somewhere else to go.

Still Want to Host a Server?

There are several options for hosting. There are managed products such as masto.host that you can just sign up and they manage the infrastruture for you. Something like cloudron.io gives you a little more control in that you own the machine itself (even if just in the cloud), but they manage installing the product on your machine. I don’t know much else about these services, but they are available if you are not interested in diving in the command line.

I’m interested in the code itself, but was also intimidated by the idea of installing from source. Luckily Digital Ocean had something to meet my needs.

My setup experience.

I opted to host on Digital Ocean after I found their 1 click app. If you’d like, you can use my referal code to get some Digital Ocean credits for yourself and for me if you don’t have an account yet. Once you have an account, go to the 1 click app page and you can create a droplet. When you do, make sure to click a droplet size that has at least 2GB of RAM. I was running into a lot of issues in with a 1GB droplet and am currently running at 80% in the 2GB droplet.

During that setup, make sure to choose to upload an SSH key. Here’s instructions on how to generate an SSH key. I find it’s more secure than using a password.

While that is setting up, we’ll need a few other things.

First I needed a domain name. I used name.com to register mine, but feel free to use whatever provider you want. After getting my domain, I needed to configure the domain to in Digital Ocean. Here’s the link to the official documentation from Digital Ocean on how to setup your domain and DNS records.

I also needed an email provider. I tried to set up my your own email server on the droplet with the sendmail command, but my email were not being delivered to gmail. Whether it was an issue with my setup or gmail just blocking the emails, I’m not sure, but I eventually gave up. SendGrid has a free tier, which I think should be enough for a single user server. If you’re planning to open registrations you might want to shop around to find a provider that fits your budget. If you use SendGrid, follow the instructions in their documentation to set up an API Key.

With that all set up, let’s ssh into the droplet and install Mastodon. Here are instructions on connecting with SSH. Once you are connected, you’ll be greeted by the setup wizard and some prompts. Here’s what I put to configure my server. When things went wrong I was able to use disconnect from the droplet and reconnect to restart the wizard. The wizard appears to keep running until you succesfully complete it:

Welcome to the Mastodon first-time setup!
Domain name: forcedconversation.com
Do you want to store user-uploaded files on the cloud? No
SMTP server: smtp.sendgrid.net
SMTP port: 587
SMTP username: apikey
SMTP password: <my_send_grid_api_key>
SMTP authentication: plain
SMTP OpenSSL verify mode: none
E-mail address to send e-mails "from": Sean <no-reply@forcedconversation.com>
Send a test e-mail with this configuration right now? no

I didn’t want to configure S3 or some other cloud host, so all user uploaded files will live on the droplet. It’s just me so I figured it’d be ok. The only other thing of note is that the SMTP username is literally apikey.

After completing those prompts I was able to create my admin account:

Great! Saving this configuration...
Booting up Mastodon...
It is time to create an admin account that you'll be able to use from the browser!
Username: squizzleflip
E-mail: sean.cuevo@gmail.com

Next I was given my initial password, and prompted to setup Let’s Encrypt for SSL

You can login with the password: YOUR-PASSWORD-WILL-BE-HERE
The web interface should be momentarily accessible via https://forcedconversation.com/
Launching Let's Encrypt utility to obtain SSL certificate...
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): sean.cuevo@gmail.com

This failed a BUNCH of times - turns out when I set up the DNS recodrs I had a typo in my domain name. A frustrating error, but at least not a complicated one.

After that I had to update certificates:

sudo apt install ca-certificates

Lastly I needed to add 127.0.0.1 localhost forcedconversation.com to the file /etc/hosts. And that was it! I was up and running!

Immediate Upgrades

I started posting on my instance and one of the first messages I got was “How did you manage upgrades?” to which I thought “Upgrades? I just installed it, what would I need to upgrade?” Turns out the Digital Ocean 1-click-app is set to Mastodon version 3.1.3, while the latest release is 3.5.3. COOL.

I connected to my droplet again and in another monitor and opened up the upgrade documentation. Fortunately you can update directly from 3.1.3 to the latest version, but the documentation does warn about making sure to follow any intermediary upgrade steps. For example, if version 3.2.1 has a unique upgrade setup, you’ll probably need to do that as well. I opened up all the releases and found I needed to do the following:

Run apt install shared-mime-info as root
Update ruby to 3.0.3 with RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install 3.0.3
Run bundle install
Run yarn install
Run SKIP_POST_DEPLOYMENT_MIGRATIONS=true RAILS_ENV=production bundle exec rails db:migrate
Run RAILS_ENV=production bundle exec rails assets:clobber assets:precompile
- The docs don’t include the assets:clobber part, which caused me to run into this issue
Run systemctl restart mastodon-sidekiq
Run systemctl restart mastodon-web
Run RAILS_ENV=production bin/tootctl cache clear
Run RAILS_ENV=production bundle exec rails db:migrate
Run systemctl restart mastodon-sidekiq
Run systemctl restart mastodon-web

Once that was complete I was finally upgraded the latest version. Hopefully following those steps will make this a little more straightforward if you try this.

Lastly I set the server to single user mode by adding SINGLE_USER_MODE=true in the file /home/mastodon/live/.env.production. This disable registrations and points the domain directly to my profile.

What’s Next?

Things seem fairly stable right now, but I’m actually not sure what more work will be required. After a few months and some upgrades, I may decide to open up some limited registrations. If you want to try this yourself and have any questions, please feel free to tag in a post on @squizzleflip@forcedconversation.com! Good luck and happy tooting!

Across the Fediverse

Fri, 04 Nov 2022 08:00:00 +0000

The Fediverse

I’ll start with I kind of hate the term “fediverse”, but I do like the concept! If you’re not familiar with a federated network, Mastodon, or how this “bird site replacement” works, I’ll try to explain in as few words possible. A federated network is distributed amongst separate servers that communicate with each other using a common protocol or “language” (called ActivityPub if you want to dig into the details). So while your account lives in one server, because of the common language across servers, you are able to follow and reply to people on different servers.

Mastodon is one type of software that uses a shared language to create a Twitter-like replacement, and because of the federated network, all of these Mastodon servers are able to interact with each other. You could join any server and you’d be able to follow/reply to people on other servers fairly seemlessly. There are also other types of software like Pleroma or Pixelfed (which is like instagram), that also implement the same protocol, so you can even follow people using those platforms and vice versa!

You can join any server you want, and if you’re unsure I’d say just start with one of the bigs ones like mastodon.social. The server you join doesn’t matter in the sense that you can communicate with people on other servers if you want, but it does matter in that it is where your posts will live and more importantly how the server is moderated.

Whoever is hosting a Mastodon server has complete control over that server. The admins can read any post on the server, including DMs. This is the case with something like Twitter, but the perception of trust can be different when it’s just a few hobbyists running a server as opposed to a giant corporation. Those admins also have control over which servers can interact with their server. For example, an admin on a Star Wars Mastodon server could block that servers interactions with a Star Trek server. So even though the Star Trek users are following the Star Wars users (and vice versa), the admin can decide that no Star Trek server posts will appear on their timeline.

Dunbar’s Number and a Better Online Experience

Having a distributed network means smaller user bases for each server. Instead of having to moderate the interactions and posts of millions of users on a single server, moderators only have to monitor the thousands or even just hundreds on their own server, while also having the ability to block communities in mass that don’t align with the values of theirs. Additionally, if an asshole suddenly becomes the owner of the instance you’re on, the fediverse’s portability allows you to leave a server and bring your followers with you to a server that you more align with.

The concept of many, small servers really appeals to me because I think it’s the best way to scale social networking that prioritizes safety because of the theory behind Dunbar’s Number. For those not familiar, Dunbar’s Number is the concept that an individual has a cognitive limit on the number of people they can maintain a stable social relationship, that number suggested to be around 150. To me, that means that I could potentially host a server of about 100 or so users and successfully priotize the safety of their interactions in my server. And because of the federated network, those users are not isolated to my server, they can freely interact with others in other servers. Again, if some asshat decides to buy his way into owning another server and it becomes a toxic hellscape, I can easily block that server’s posts from showing up in my server’s timeline.

If you’re familiar with Discord, which while not federated, you’ll see that it has a very similar feel. My online interactions on Discord are by far the least toxic and most meaningful in large part because of the small and separated nature of the servers.

Hosting My Own Instance

Currently I host a single user instance on forcedconversation.com. I’m not sure if I will open registrations; I’m not sure what is going to be required of me to keep this thing running, what the costs will end up looking like, what moderating posts will be like, or even if there is interest to join. However, I am intrigued by the idea, especially if there were others that would be interested in helping admin and moderate the server. For now feel free to come follow me @squizzleflip@forcedconversation.com and if you would be interested please send me a message! I’m really excited about this technology and I hope more people start to jump on board. This feels like what the future of social networking should be!

A Decade of Code

Wed, 19 Oct 2022 08:00:00 +0000

Wax Nostalgic

Ten years ago, I walked into the Bluewolf office in NYC that overlooked Madison Square Park. I passed someone working in what looked like a phone booth, and I remember thinking, “wow that person must be super important, they have their own office!” After the tour and some brief intros, I was shuttled into that phone booth where my laptop awaited me. Turns out that person started the week before me and there just was no more desk space.

My first project was to help maintain a custom built CMS built using Ruby on Rails for some non-profit in the city. I don’t remember much of about it but I do remember breaking the staging environment, blocking the client from making any changes. Luckily they didn’t notice while my mentor and I panicked to figure out what we broke. Eventually that client contract ended and didn’t renew (for unrelated reasons, I assume), which meant I needed to start learning Salesforce development. 10 years and 6 jobs later, here I am. And if you’d indulge me for a bit, I’d like to share some lessons from along the way.

In No Particular Order, Lessons from a Decade of Code

Learning vim would probably make me very productive, or at least feel that way. I’ve given up every time I’ve tried
Everything is a form. It’s just inputs that you’re capturing for some other system to consume. This gives me existential dread sometimes
Rebuilding is almost never worth it, until it is
Being very responsive to every slack message will get you lots of praise. It will also quickly burn you out
I used to think being able to solve problems quickly during live meetings was a skill. It’s actually a a detriment that prevents other people from contributing that leads to poorly thought out solutions and should be discouraged
The value of meeting plummets after adding more than 3 people. I promise you it should just be an email
No new feature cycle, from ideation to delivery, should be less than a day. I don’t care how small that change is, it needs to be prioritized like everything else or else you’ll constantly be drowning in “quick changes”
Processes not only protect the product, but they also protect you. However they should also work for you, not the other way around
A sustainable pace is critical for any role that you want to last for more than 2 years
Burnout takes months to recover from. It’s not something you can just take a long weekend to fix, especially if you don’t address the cause when you get back
Don’t derive your value or your passion from work. It will only hurt you
Working from home is the best and I would NEVER work in an office again if I had the choice
Version control is the single most important piece of technology if you’re writing code. It’s the bare minimum and I refuse to work in any environment that doesn’t have it
Design patterns should serve as inspiration, not as rules to be followed dogmatically
The agile manifesto itself is really good - it’s a focus on building a process that works for those involved, favoring a frequent feedback loop. If you ever say “that’s not Agile”, you’re missing the point
Documentation doesn’t get enough love. Code can’t document itself - the code can only do what’s written, it’s bad at showing intent
You will NEVER beat Excel. You should embrace it and integrate with a spreadsheet instead
You’ll generally make more money switching jobs than a promotion
Always ask for more than what you’re making. If a recruiter asks what you’re looking, add 20% over what your currently making. If they ask how much you’re making, lie
Transactional data should be separate from analytics data. Specifically, putting analytics data on your sObjects like Account is an anti-pattern
Capture events that happened, not timestamps that imply something. FIGHT ME.
I hate pair programming and I think it should be ok if you never want to do it
Favor async over synchronous collaboration
Giving people the chance to hit that flow state is the cheapest way to make your employees happy
Invest in good tools (chairs, monitors, desk, etc). You’re using them for at least a third of your day
You don’t need a side project. If you have one, don’t hesitate to work on it during the work week. You’re getting your work done right? So no one should care and it counts as professional development
Take the time to experiment with technology. On company time.
Keep your personal projects off company assets. I don’t know how enforceable those technology tranfers are and I don’t want to find out
Recognize the signs of burnout - no one is going to do it for you, you have to advocate for yourself
Getting really good at one thing can be very lucrative as opposed to chasing the latest technologies
Max out company matching on your retirement account - it’s free money
You don’t have to be passionate about your job to be good at it
Your job is not your family. You can (and probably will) develop friendships on a personal level with your coworkers naturally, but the idea that your company can be family is a lie
You will have trash managers. Leave if you can
You will have incredible managers who actually do feel family. Thank them often and let them know
Just because you’re good at your job doesn’t mean you’d be good at managing others doing that job, or that you’d even like management
Think often what you like about a job. Lean into that. You don’t have to love your job, but maximizing the parts that bring you joy helps
If software development didn’t pay like it does, I absolutely would do something else, and that’s ok if you feel that way
Forgive those that came before you. You don’t know what time pressures, uncontrollable circumstances, etc. that led to the state of the codebase. Don’t get angry, just take this into account when you pad your estimates
Estimates can be pretty arbitrary, but they become less so the more you do them, and they are very important when it comes to planning
Don’t be the only person that can do your job, there should always be at least two so that you can go on vacation
Be kind to each other. Avoid toxic interactions and embrace those that bring you joy. This is really hard
Know which battles to fight. When you stand your ground it’ll be really apparent how much it matters
You are worth it. You are worth that promotion, that raise, that time off. You deserve to be in that job, you know what you are doing

I could probably do this all day, but this is enough for now. Here’s to 10 more years of code! Thank you everyone that helped get me here because I certaintly did not do it alone. And if you’re starting your journey, I hope I can help you as well.

Can we trick salesforce into doing reportable dynamic rollups?

Mon, 23 May 2022 08:00:00 +0000

Rollups. Why is it always rollups.

I hate rollups. I hate building them. I hate how they slow down things in Salesforce. I hate how they can accidentally block users from editing records. And I especially hate debugging them. “Why is this roll up field wrong?” I don’t know, there are so many points of failure when it comes to a roll up. Maybe the job hasn’t run yet and someone just added another record. Maybe an error was thrown and a record wasn’t accounted for. But sure, I’ll throw away a few hours to answer your question and by the time I have an answer the rollup corrected itself. I digress.

And I say all this as a contributor to the Declarative Rollup Summary open source project. I get why we need rollups. Not every org has access to an analytics tool and is limited to Salesforce reporting. And sometimes an orgs needs to answer the question “How many Account records have donated more than $1000?” and the person asking the question needs to do this with a report. So you build a rollup summary because the alternative is building a custom reporting tool and that’s it’s own set of problems. That’s why DLRS is such wonderful tool. I just hate it that it has to be like this. Or does it?

SOQL to the rescue

What infuriated me for years was that SOQL can actually do this for you with aggregate queries. For example, if you captured your donations for an Account in a child object called Donations, you could do the following with SOQL:

SELECT Account__c, SUM(Amount__c) FROM Donation__c GROUP BY Account__c HAVING SUM(Amount__c) > 1000

But the goal here is to make this reportable. Sure, you might get away with having devs and admins run these SOQL queries for the business, but part of scalability is providing a mechanism for self-service. So you make the rollup field.

Enter the Apex Connector Framework

I was playing with the Apex Connector Framework to pull some data into Salesforce from an API so that they could be reportable. The flow of this framework is as follows

Define fields on an external object (i.e. how will this object be represented in Salesforce?)
Extend the framework classes, which mainly allow you to interpret a SOQL query, sent the search criteria to an API with a callout
Parse the results and map to rows for the external object.

After you do this, the external object becomes reportable! So I thought, what if instead of doing a callout we just did the aggregate query from above and mapped those results to the external object. In other words, I have an external object called AccountRollup__x with a field TotalDonations__c, and every time it is queried, it does an aggregate of Account records?

Turns out, it kind of works and it’s reportable! You can run a report using filters on the TotalDonations field as if you were reporting on a regular rollup field.

See this repo for code samples of a prototype that does just this you can try in a scratch org: https://github.com/seanpat09/live-rollups

Caveats

I ran into a few issues while building this prototype.

For some reason, I could not display fields related Account fields on the report as I was getting a system error with a gack. That’s why I suggest linking to the summary field in the report with the Name column, which can give you access to the Account via the AccountRecord lookup field
When I tried to make the rollup summary record a parent to the Account, the report would just break, not allowing me to do the filtering at all
You’re limited to whatever SOQL limits you are normally limited to, so if you have a really high volume org, this might not work at all.
I’m not sure of the licensing on the Apex Connector Framework, but I was able to use it in an Enterprise org that does NOT have the license for Salesforce Connect.

So what does this mean? I’m not really sure yet to be honest. But if this works and scales scales, it might be another option to rollup summaries without having to run background jobs to maintain the data! Instead of debugging a job, you’re debugging SOQL queries instead, which might be much easier to maintain for your team.

Design Patterns in Salesforce: Abstract Factory

Thu, 12 May 2022 08:00:00 +0000

Design patterns are powerful tool to build reusuable code, but they are hard to implement in without examples and use cases. This is a series that follows the book Design Patterns: Elements of Resuable Object-Oriented Software a provides examples that relate to Salesforce

Abstract Factory

The Abstract Factory design pattern is useful for creating related objects that follow an interface. I find this pattern particularly useful for building resuable Lightning Web Components. Let’s use this pattern to build a resuable custom related list.

Use Case: Viewing grandchild records on a detail page.

Out of the box related lists in Salesforce are great for displaying child records on a detail page, but what if you wanted to display all the grand child records? Imagine a national charity that oversees local branches. Each branch is represented as an Account record, and the volunteers for that branch are represented as Contact records. When a volunteer is onboarded, there are several onboarding tasks required before they can start any work, such as a background check, filling out emergency contact info, and creating a user in their Salesforce Community.

Region managers oversee local branches in their assigned region, so in addition to other information on the Account, the Region Managers want to see all the outstanding tasks for all the Contacts on the Account detail page in a table (for the sake of this post let’s pretend this is the best solution).

A non-resuauble approach

If you didn’t care about resuability (which is ok if you don’t have that bandwidth!), you could build an LWC like this (I can’t guarantee this compiles)

//contactTasks.html -->

<template>
  <lightning-datatable
    key-field="id"
    data={data}
    columns={columns}>
  </lightning-datatable>
</template>

//contactTasks.js

import { LightningElement } from 'lwc';
import getTasks from '@salesforce/apex/ContactTasksController.getTasks';

const columns = [
  { label: 'Subject', fieldName: 'Subject' },
  { label: 'Assigned To', fieldName: 'WhoId'}
];

export default class ContactTasks extends LightningElement {
  data = [];
  columns = columns;
  recordId;

  async connectedCallback() {
      const data = await getTasks({ accountId: this.recordId });
      this.data = data;
  }
}

//ContactTasksController

public class ContactTasksController {
  @AuraEnabled
  public static List<Task> getTasks(Id accountId) {
    List<Task> allTasks = new List<Task>();
    for(Contact aContact : [SELECT (SELECT Subject, WhoId FROM Tasks) FROM Contact WHERE AccountId = :accountId]) {
      allTasks.addAll(aContact.Tasks);
    }

    return allTasks;
  }
}

A solution like this is fine, but in the future you might get a similar request where you want to display all tasks for all the Contacts related to an Opportunity. Or maybe just some other data. You could create a separate LWC with a separate Apex controller, but you might notice that the LWC isn’t doing all that much, just displaying data. Most of the differences is in building the columns and getting the data. Wouldn’t it be nice to abstract out the logic that builds the table data? Like some kind of abstract factory?

The Abstract Factory Pattern

The abstract factory pattern can be broken down into 3 parts:

A interface that specifies what an implementation must be able to build.
A consumer that can request a specific implementation, but can handle any implementation of the interface
Concrete implementations that fulfill the interface

So in this case we need an interface that can build the columns and rows for a table, a component that can specify which columns and tables to display and actually display them, and then 1 or more concrete implementations with the business logic. How would this look?

First let’s create some objects to define what we’re building:

public class CustomListColumn {
  public String label;
  public String fieldName;

  public CustomListColumn(String label, Object fieldName) {
    this.label = label;
    this.fieldName = fieldName;
  }
}

public class CustomListRow {
  public Object value;

  public CustomListRow(Object value) {
    this.value = value;
  }
}

Next our interface for our factory.

public interface ICustomListFactory {
  List<CustomListColumn> buildColumns();
  List<CustomListRow> buildRows(Id parentId);
}

And then our concrete implementation of that factory

public class AccountContactsTaskListFactory implements ICustomListFactory{
  public List<CustomListColumn> buildColumns() {
    List<CustomListColumn> columns = new List<CustomListColumn>();
    columns.add(
      new CustomListColumn('Subject', 'Subject'),
      new CustomListColumn('Assigned To', 'WhoId')
    );
  }
  public List<CustomListRow> buildRows(Id parentId) {
    List<CustomListRow> allTasks = new List<CustomListRow>();
    for(Contact aContact : [SELECT (SELECT Subject, WhoId FROM Tasks) FROM Contact WHERE AccountId = :parentId]) {
      for(Task aTask: aContact.Tasks) {
        allTasks.add(new CustomListRow(aTask));
      }
    }
    return allTasks;
  }
}

Next let’s make our component more generalized. It now gets the columns in addition to the rows from the Apex controller. It also passes a listType parameter to specify which implementation should be used

//customRelatedList.html -->

<template>
  <lightning-datatable
    key-field="id"
    data={data}
    columns={columns}>
  </lightning-datatable>
</template>

//contactTasks.js

import { LightningElement } from 'lwc';
import getTableData from '@salesforce/apex/CustomRelatedListController.getTableData';

export default class CustomRelatedList extends LightningElement {
  data = [];
  columns = columns;
  recordId;

  @api
  listType

  async connectedCallback() {
      const tableData = await getTableData({ recordId: this.recordId, listType: this.listType });
      this.data = tableData.rows;
      this.columns = tableData.columns;
  }
}

Finally we create a controller that will handle getting the correct implementation based on the listType passed from the LWC

public class CustomRelatedListController {
  @AuraEnabled
  public TableData getTableData(Id recordId, String listType) {
    ICustomListFactory factory = getCustomListFactory(listType);
    
    TableData data = new TableData();
    data.rows = factory.getRows(recordId);
    data.columns = factory.getColumns();

    return data;
  }

  private ICustomListFactory getCustomListFactory(String listType) {
    if(listType === 'AccountContactsTasks') {
      return new AccountContactsTaskListFactory();
    } else {
      throw CustomRelatedListControllerException('List Type: ' + listType + ' not supported');
    }
  }


  public TableData {
    @AuraEnabled
    List<CustomListColumn> columns;
    List<CustomListRow> rows;
  }

  public CustomRelatedListControllerException extends Exception {}
}

Benefits

This seems like a lot of extra code and for just a single use case it probably is. The value comes with its reuse. Let’s add another table, this time displaying Contact information related to an Opportunity. Specifically, the Contact’s full name, parent account, grandparent Account (i.e. up an additional Account level in the hierarchy), and the Account website.

Here’s the concrete implementation:

public class OpportunityContactListFactory implements ICustomListFactory{
  public List<CustomListColumn> buildColumns() {
    List<CustomListColumn> columns = new List<CustomListColumn>();
    columns.add(
      new CustomListColumn('Full Name', 'fullName'),
      new CustomListColumn('Parent Account', 'parentAccount'),
      new CustomListColumn('Grandparent Account', 'grandParentAccount'),
      new CustomListColumn('Website', 'website')
    );
  }
  public List<CustomListRow> buildRows(Id parentId) {
    List<CustomListRow> contacts = new List<CustomListRow>();
    for(OpportunityContactRole ocr :
      [ SELECT Contact.Fullname,
               Contact.Account.Name,
               Contact.Account.Account.Name,
               Contact.Account.Website
        FROM OpportunityContactRole WHERE OpportunitId = :parentId]
    ) {
        Map<String, String> contactRow = new Map<String, String>{
          'fullName' => ocr.Contact.FullName,
          'parentAccount' => ocr.Contact.Account.Name,
          'grandParentAccount' => ocr.Contact.Account.Account.Name,
          'website' => ocr.Contact.Account.Website,
        }
        contacts.add(contactRow);
    }
    return contacts;
  }
}

And then we update the controller to handle this new list type:

  private ICustomListFactory getCustomListFactory(String listType) {
    if(listType === 'AccountContactsTasks') {
      return new AccountContactsTaskListFactory();
    } else if(listType === 'OpportunityContacts') {
      return new OpportunityContactListFactory();
    } else {
      throw CustomRelatedListControllerException('List Type: ' + listType + ' not supported');
    }
  }

And now our LWC can handle a different use case given a different listType API value, without having to change any of its code! Arguably the getCustomListFactory method should be pulled into its own class so that the controller also does not have to be updated either.

I find myself using this pattern often with LWCs to take advantage of the reusability of components. It can take a little extra upfront work, but can save you a lot of time in the long run in terms of code you don’t have to write and also for creating small testable components.

Pull Requests are an Essential Part of Security

Wed, 16 Feb 2022 08:00:00 +0000

Separation of Duties

Before I became a software engineer, I studied accounting and even worked as an auditor for a brief period. Not much accounting knowledge remains, but a few nuggets stayed with me, particularly the internal control known as “Separation of Duties” (not to be confused with the design principle “Separation of Concerns”). To summarize, no one person should have complete control over an entire transaction. For example, the person collecting cash from a customer for a bill should not be the one to also record the transaction and deposit the cash. Otherwise, that person could collect funds, credit the customer’s account, and take a little off the top before making the bank deposit. Having another person in this process does not eliminate the risk, but colluding with someone else is harder to hide. You know what they say about the only way for two people keep a secret.

What does this have to with code and pull requests? Pull requests serve a similar security purpose. Not only do pull requests provide the nice to haves of allowing for asynchronous collaboration, a second set of eyes, etc, they are also a very important auditing artifact and should be considered an essential component of your delivery process.

Code controls business logic, often at a pace magnitudes faster than what any human can keep up with. And because of the complex nature of writing code, it poses a huge security vulnerability where malicious behavior can easily be obfuscated. For example a fork bomb looks like an inconspicuous line of code, but can actually crash your entire system. Because of which, every line of code that makes its way into any system of importance should be reviewed by someone else. Pull requests not only provide the mechanism to do this review, but also create the audit trail for every change.

Components of a Pull Request

Let’s examine the components of a pull requests and how they contribute to security.

First and foremost a pull request aggregates proposed changes via its commits. By using git blame you are able to find the latest commit attributed to every line in the codebase. With this you are able to follow the history of any line change. If you ever wondered why a change was made, following the commit history is a great start. With GitHub, you can even see which pull request was the one that brought that commit into the current branch.

Not only can you see the history of changes, but the commits attribute the changes to the person that introduced it. Commit history great, but also being able to talk to the person that made the change can help provide more context that’s not in the code.

So far these are just things you get from a commit history alone. Pull requests show their value in the additional layer of tracking they provide. With a pull request, we can see the reviewer that approved the merge. Now you have at least two people involved in the process of getting code into production (provided that you have configured your version control to not allow self-approvals).

The pull request itself also provides an area to have a discussion - on the features, the code decisions, tech debt introduction. By doing this in the pull request, this discussion is linked very closely to the code itself. You could have the discussion happen in some other document, but several months down the line that document may get lost to some obscure folder in your company’s google drive.

For extra credit, you could also tag pull requests with the work item associated to the pull request, so you know why a change was made.

Security Benefits and Beyond

With all of these ingredients together, you can trace from a single line change who made the change, approved the change, approved the item to be worked on at all, and any context capture in any comments for the PR! And with all theses duties separated by person, you’ve mitigated a lot of the risk of any one person trying to act maliciously within an organization.

As an auditor, this kind of paper trail is gold. In fact, I’ve been involved in security audits that went super smoothly because this process was in place. In addition to security benefits, it was so useful to be able to see the context of something far into the future. Have you ever looked at code that YOU wrote and wondered why you took some odd approach? With this trail you can find the context of the original change, hopefully with an explanation of why.

Constructive Review vs. Fodder for Punishment

I want to emphasize that this internal control is not about placing blame. Accountability is important, but if this process is wielded as a threat, your team will be reluctant to to adhere to it. Should something happen, a bug, security breach, or even just a missed feature, this process should be used to trace the source of the problem. Afterwards a constructive, blameless discussion can happen where processes can improved. What happened in the past happened - the only thing to do is move on and learn from it. If leadership uses this process to punish contributors for their mistakes, the engineers will find ways to not be associated to the changes. Like any tool, its value to the organization highly depends on the culture those using it.

There are not many things that I consider essential for an engineering org, but pull requests are something that is a must have for me, and possibly a deal breaker for me if an organization refused to use them without a much better alternative. Even when I was the only working on a project professionally, I STILL used pull requests so that I could have the benefits of the audit trail, both for my future self or anyone else who would have to inherit my work after I left.

Good morning, and in case I don't see ya: Good afternoon, good evening, and good night!

Tue, 03 Aug 2021 07:00:00 +0000

Throughout my career I have joined and left several organizations, all for different reasons, and I have always felt confident in my choice to move on. For the first time, however, I am as equally excited in my next role as I am saddened to leave my previous one. Later this month, I will be joining the team at Twitch, leaving my current role at Salesforce.

I cannot express enough how lucky I was to be able to work with the people that I did at Salesforce. These were some of the most capable individuals I have ever worked with, and I found myself continually impressed by everyone. The way I was able to thrive, grow, and learn was phenomenal. Not just in the technical skills that I have gained, but also the numerous lessons I have learned in what we typically call “soft” skills. Lessons on how to lead and be a part of phenomenal teams, how to work productively and, more importantly, sustainably. What it means to work together with compassion and empathy. And what it truly means to work in a way that benefits not just the company, but myself.

There are too many people to thank in the organization. I am a different person, changed for the better, and for good, because of everyone I had the pleasure to interact with, and I hope our friendships will continue.

In particular I wanted to thank a few individuals in leadership that were instrumental in my growth. To Joysorlyn Dixon, Nina Patel, and Alex Peralta, the leaders that I was fortunate enough to work with closely on a daily basis, thank you for your mentorship, your guidance, and your friendship. I have never felt so valued and supported - even when I decided to move on to a new role you still put my wellbeing and my growth first. Whether I cried ugly tears on camera, vented my frustration at a tricky code base or situation, or just needed some advice on how to lead, your support was key to my success and ability to keep moving forward.

The attitude of servant leadership is something that is rare and a treasure - to not only help guide the success of the product, but also prioritize the growth of the individual is so admirable. I hope I can take those lessons with me and pass them on.

I am so lucky to have had this opportunity for the last few years to work with such great people. To my leadership, to my teammates on my scrum teams, and to those I was not fortunate enough to collaborate with more extensively - the words “thank you” are not enough to express my gratitude for all of your patience, encouragement, and support.

And so onwards to new adventures! I am so excited and grateful for this next opportunity and only hope to be even a fraction as impactful to those I work with in the future as everyone I worked with here at Salesforce has been for me.

Toxic Positivity - It's OK to Not Be OK

Tue, 27 Jul 2021 07:00:00 +0000

A friend recently introduced me to the idea of “toxic positivity”, which can be summarized as the “everything is awesome!” approach to life. I can’t speak to other industries, but I see this attitude all too often in tech. While I believe we should encourage some level of positive thinking, when we don’t allow ourselves the space for our pain, for our grief, we tip the balance into toxicity.

It’s not me, it’s you

If you work in tech, you have probably run into one of the following mantras at some point:

Celebrate your failures
Don’t come to me with problems, come to me solutions
Happiness is a choice

When something bad happens, it’s actually good! When you have a problem, it’s not worth talking to me about it unless you know how to fix it. You can be happy too - just be happy.

There are plenty more, but it all boils down to the idea that if you are not satisfied with a situation, you have the power to fix it. In the book “America the Anxious” by Ruth Whippman, she summarizes the problem with this mentality beautifully:

But it doesn’t take long to realize that the flip side of this logic is that, if I am not happy, then it is All My Own Fault

Let’s be honest here - failure sucks and I do not want to dwell on it, much less celebrate it. Sometimes I have a problem, I have no idea what to do, and I cannot face it alone. Sometimes I am sad, angry, disgusted, scared, and happiness won’t help me right now, because I need to process this feeling.

In my career, especially in the last year, I cannot stress enough how lucky I am to have worked in environments (some more equipped than others) where I have been given the space to have these feelings, to step away, to reset. While this is a practice I want to encourage, it still implies that the underlying problem is within the individual. People may be given the time to get away, but what happens when the problem is rooted in the way we work?

Everything is awesome!

I think retros are the most important thing you can do as team. Taking the time to reflect on the work you just completed, to celebrate the successes, to re-examine the challenges, is necessary for the continual improvement of the team. Too often, however, I’ve seen retro devolve into just being a “good vibes sesh”, a full hour of teammates just giving each other kudos. Recognizing and celebrating each other is important part of bonding the team, but it can’t be the only point of the discussion.

If retro doesn’t allow people to recognize the things that are not working, when will the team ever get the chance to fix it? Even worse, people may be actively discouraged from bringing up anything that’s going wrong because no one wants to be the person that “kills the vibes.” I have attended retros for sprints that completely burned me out, just seething in silence as the team celebrated all the “success.” I don’t care if the release went out on time, should we really be patting ourselves on the back for the all nighter we just pulled to make it so? Shouldn’t we instead be examining the circumstances that led to this situation in the first place? But I hesitated to speak up because I didn’t want to rain on the parade.

Spinning things as a positive does not magically make things positive. Instead, it isolates each individual who is struggling with the status quo, who actually may not be alone in their thinking! It gaslights them into thinking that maybe the process is fine and that they are problem. After all, no one has said anything, so it must be fine, right? And so what happens? They leave.

Bringing an attitude of balance

I am by no means encouraging complain-a-thons. The key here is balance. Here are a few ways you could help bring that balance to your team:

During retros, time-box each part so that there is space to discuss both the successes and the challenges
Be the person that brings up challenges. Try to do so calmly, without attacking, and using neutral words to keep things constructive. You are probably not the only person that is feeling that way.
If you’re a leader, recognize when things are going great and when things are not going well. And provide the space for the team to try things to remedy the problem. Yes, it might slow things down, but I can promise you that things will come to a screeching halt when your team decides to leave instead.

We have to recognize that in order to improve, we have to come to terms that the things we feel can’t just be ignored, that the things that aren’t going well need to be addressed. Recognizing that things can be improved doesn’t mean that everything is currently broken. But how will things get better if we don’t see them for how they truly are?

Merging DOCX files natively in Apex.

Tue, 22 Jun 2021 07:00:00 +0000

When it comes to document generation in native Salesforce, I always assumed that your only options were something really simple like using Blob.toPDF or rendering a Visualforce page as a PDF and saving it as a file. Neither of there were very pragmatic - the Blob method left much to be desired in terms of formatting and the Visualforce approach was too hard to maintain. As such, when someone would ask for document generation I would just point them to an ISV like Conga or Drawloop. Surely working with a Word document wouldn’t be possible in Apex, right?

The DOCX file format.

I always assumed that a Word document was a complex file format, inscrutable to the likes of me. For a long time that was true - the original .doc file extension was a more proprietary format binary-based format. In the early 2000s, in response to open source solutions like Open Office, Microsoft created the DOCX file format that used XML.

In fact, a DOCX file is actually just a zipped file of various xml documents. You can try it right now - go to Google docs, type some stuff in it, click File >Download > Microsoft Doc (.docx). Unzip that file and in the resulting folder you can see the xml files yourself. The file we’ll focus on is is named document.xml.

Working with document.xml

I created a Word document that looked something like this, but formatted:

%%title%%

%%header1%%

%%header2%%

%%content%%

I unzipped that file and took a look at the document.xml file, searched from my merge fields, and they were relatively to find. For example, the “content” merge field was displayed like this:

<w:t xml:space="preserve">%%contentText%%</w:t>

Seeing that, I realized I could just do a find and replace on these merge fields, re-zip these files as a new archive and tada, basic document generation. And tada indeed it does work like that. Could I do this programmatically?

Document generation with Apex,

Reading an XML file in Apex is simple enough - just get the blob from a ContentVersion or an Attachment record and turn it into a string. But how do I get that document.xml file out of the docx file?

Unfortunately, there does not appear to be a native way to extract files from a zip file in Apex. Luckily someone has solved this problem for us. Enter Zippex, a native Apex Zip utility for the salesforce.com platform. I installed this into a scratch org, uploaded my .docx file, and started to break down the problem:

Unzip the docx file
Get the document.xml file
Do a find and replace on the merge fields
Rezip the file and save the changes.

I first started by just hard coding IDs to make this a little easier so I didn’t have to worry about querying for ContentDocuments:

ContentVersion cv = [
    SELECT VersionData
    FROM ContentVersion
    WHERE ContentDocumentId = 'SOME_CONTENT_DOCUMENT_ID'
    AND IsLatest = true
];

Zippex sampleZip = new Zippex(cv.VersionData);
Blob fileData = sampleZip.getFile('word/document.xml');
String docxml = fileData.toString();

docxml = docxml.replace(
  '%%title%%', 'Merged Title!',
  '%%header1%%', 'Merged Header 1!',
  '%%header2%%', 'Merged Header 2!',
  '%%content%%', 'Merged Content!',
);

Blob mergedData = Blob.valueof(docxml);
sampleZip.addFile('word/document.xml', mergedData, null);

String newTitle = 'merged' + Datetime.now().getTime();
ContentVersion mergedFile = new ContentVersion();
mergedFile.VersionData = sampleZip.getZipArchive();
mergedFile.Title = newTitle;
mergedFile.ContentLocation= 's';
mergedFile.PathOnClient= newTitle+'.docx';
insert mergedFile;

Id conDoc = [SELECT ContentDocumentId FROM ContentVersion WHERE Id =:mergedFile.Id].ContentDocumentId;
ContentDocumentLink cdl = new ContentDocumentLink();
cdl.ContentDocumentId = conDoc;
cdl.LinkedEntityId = 'SOME_PARENT_RECORD_ID';
cdl.ShareType = 'I';
cdl.Visibility = 'AllUsers';
insert cdl;

After I ran that, on my parent account record that I had put my docx attachment, I had a new docx file that had the merge fields populated!

With a proof of concept I reworked the code a little bit so that it’s a little more reusable. Click here for the github repo.

With that code you can do something like this to generate documents with merge fields:

//This File must be a docx file
Id contentDocumentId = '<REPLACE_WITH_DOC_ID>';
Id parentId = '<REPLACE_WITH_PARENT_ID>';
Map<String,String> mergeFields = new Map<String,String>{
        '%%mergefield%%' =>  'I HAVE BEEN MERGED',
        '%%header1%%' =>  'NEW HEADER 1',
        '%%header2%%' =>  'NEW HEADER 2'
    };
new DocxMerger()
    .mergeDoc(contentDocumentId, parentId, mergeFields);

Too good to be true?

The document that I merged was tiny, but when I ran the code it took a while. The resulting debug log was 18 megabytes, so this seems to be an expensive operation. So I have no idea what would happen if I tried to merge a larger, more complex document. My hope is that the bottleneck is in the unzipping part itself and if that’s the case I can potentially try to do this client side using LWC. Of course, however, that would mean that you can’t bulkify this process via something like a batch job.

I’m actually quite surprised I got this far - usually I give up on these experiments but this wasn’t actually too hard. I’ll need to figure out where this project goes from here. Do I add more features, or does this end up in the pile of forgotten repos in GitHub? Either way, it was a cool experiment!