Tag: Node.js

CLI showing the output of the program

Static Code Analysis of Apex

Would you wander down memory lane with me? It was on one of my first projects at Trifecta that I was introduced to Sonar (now SonarQube), a dashboard that aggregated results from a pile of code analysis tools and presented them in a visually appealing way. I loved the kind of insight it provided.When it listed a bunch of unused methods I went to work pruning them. When it found string concatenation in a big, heavily used loop, I replaced it with StringBuilder. When I moved over to Salesforce, I found a number of solutions but most were either costly or incomplete.

SonarQube dashboard
Different name, same usefulness.

I did manage to find a wonderful blog post, written by Andrew Fawcett, which covered using the tooling API to call out methods that are not referenced anywhere and display it on a Salesforce canvas. This was exactly what I was looking for, or at least it had the potential to be. You see, finding unused methods is a great help once a code-base becomes large and complex enough. Removing these relics could reduce your code-base and may reduce your unit test and deploy time. That is what makes unused method finding, my top feature to have. Even so, I wanted more, and given the choice to extend his project or make my own, I of course made my own.

GitHub new repository button
As if this was even a choice.

I started off with Node.js (bffs 4 lyfe) for no other reason than “I wanted to experiment with it.” Then I reimplemented¬†Andrew’s solution using the node-salesforce module to handle authentication and CRUD operations. Finally, I added a basic plugin system to allow for new checks to be added. How did that all turn out? Let’s find out.

CLI showing the output of the program
Well, it’s a start

I hate to say it, but Node may have been a mistake here. Don’t get me wrong, I had a lot of fun doing this, but there is a fundamental difference between Java and JavaScript that cranked the complexity right up. His logic was very sequential, going through steps one at a time with the next step depending on the completion of the last. Java did this very well, executing each call out to Salesforce and waiting for a response. Anybody familiar with AJAX should start to squirm right about now. I ended up with a tremendous chain of call backs, which fulfilled its purpose but got real messy in a hurry.

Reimplementing this solution went well enough minus the previously mentioned call back avalanche (call-backalanche?), but it was not without its drawbacks. These are no fault of Andrew and merely reflect the incomplete state of the Tooling API. For one thing, the method reference count does not count references in Visualforce. This was inconvenient, but to anyone coming from a java background where missing references in the view is par for course. I also ran into an issue trying this on an org with a scheduled job. You see, to build up the symbol table, it is compiled by basically performing a “check only” deploy. Salesforce did not like that one of the classes the scheduled job relies on was one of the classes we were checking. This resulted in total failure.

The plugins were perhaps the smoothest part of this project. Node’s ability to require a directory and a bit of trickery resulted in a plugin system as simple as dropping a properly constructed JavaScript file in the directory. These are not as efficient as if they were all part of the main file, as they end up looping over the same data a few times, but it is dead simple to add new checks, change thresholds, and disable old checks.

“So, is this project done?” I can hear you asking. The answer is an unequivocal no. On the roadmap is a web based interface, greater structure for plugins, ability to configure for multiple orgs, and heavy work trying out different flows and Node modules before I set in stone how everything will work. Until then, everything is in tremendous flux. Check it out at my GitHub repo.

Zero to Heroku

From Zero to Heroku in Three Posts, Part 3

Well, we have come a long way, from learning what Heroku was, to hosting a site on it. Now all that is left, are a few minor details. Let’s start by changing that wacky URL to something a bit more appealing.

Domain Name

For this section, unless you are hording domain names like some sort of virtual pack-rat, you will likely have to spend some money. If you have a great aversion to this, fear not, skip to the next section for more freebies. Now that that is out of the way, go buy a domain name. Go on, I can wait, no need to rush this. Once that is done log into the Heroku website, click the name of your app, then click settings. Scroll down to the section that says domains.

Heroku settings
You should be seeing this

On that line, enter the domain you own and click add. Now here is where my tutorial ends and Heroku’s documentation begins. Due to the sheer number of domain registrars, I must refer everyone to Heroku’s custom domain documentation and whatever documentation is published by your domain registrar.


Remember all of those add-ons from the first part? The post you surely read? Well now it is time to add one. This is not a necessity by any means, but it will be good to look through the add-ons and get a feel for how they work. We will start off easy with a simple log viewer. Log into the Heroku website, if you are not still there from the domain setup, click the name of your app, and this time click resources. On that page click Get Add-ons to be taken to the list of Heroku add-ons. You will likely have to click the login button in the top right if this is your first time here. Once that is taken care of, scroll down to the logging sections (section names are along the left hand side) and click Papertrail. I am going with Papertrail out of familiarity, not an endorsement. When I have tried out some of the others, maybe I will do a head-to-head comparison of them. As I was saying, click Papertrail and familiarize yourself with this layout. The add-on pages are set up with a general rundown of what the add-on does at the top and a breakdown of what level of service is offered at each pricing tier. Once you are ready, select the free tier and then select your app from the dropdown at the bottom, finally clicking the add button. Navigate back to your app and click the new Papertrail add-on at the bottom. Hurray, you now have a log viewer at your disposal. Not much use right now, but great if you start to see errors or start doing custom development.

Papertrail logs
All quiet on the website front.


We have come to the end of the opening week, three post blitz. I hope you will stop by every week (I am thinking a Wednesday update schedule would work) to see what I write for all of you.

Zero to Heroku

From Zero to Heroku in Three Posts, Part 2

So you have made it through¬†From Zero to Heroku in Three Posts, Part 1 and you are still here! If you haven’t, it was a 1000ft view of Heroku, the platform we will be working on in this post series. If you already know Heroku, you should be good anyway. Let’s get started with making a personal page. Please note, this tutorial assumes you know how to make a website with HTML, CSS, and Javascript; otherwise this series of posts would become way too broad.

So first thing is first:

  1. Sign up for Heroku! No cost and only a minimum amount of forms to wade through makes this is one low barrier of entry.

    Heroku Sign Up Page
    Single field forms? Yes please!
  2. Grab the Heroku Toolbelt for your operating system. This little command line tool provides a powerful utility for managing your instances.
  3. Download Git if you don’t already have it. This is used to push your changes to Heroku. Due to wide range of options and preferences, I can’t give a one-size-fits-all recommendation. I am going to assume that you can access your Git tool for the command line for the rest of the post.
  4. Download my server app from github. Simply open your command line and navigate to where ever you want to put the folder, then run git clone git@github.com:Bobnix/static-nodeku.git
  5. Navigate to the static-nodeku directory you just created.
  6. Run heroku login and login with your account credentials.
  7. Run heroku create. This will create an instance in heroku and set up the related Git information for you. It will spit out a phrase in the form of WORD-WORD-NUMBER. Take note of this phrase.
  8. Run git push heroku master. This pushes the code from your computer to heroku.

Thats it! You now have a live site, let’s take a look at it by going to https://THE-PHRASE-FROM-STEP-7.herokuapp.com/….

Hello world
Humble beginnings

Well, that is a bit bare. Lets fix that. Because there are so many ways to go about doing this, actually making the site will depend heavily on how you are comfortable working. I personally use Notepad++ or Sublime on windows. Some of the more seasoned may breakout VIM or Emacs. Others may turn to WISIWYG editors. The only rule (for now) is that your site stays contained within the site folder in the server app.

Once you are done with your edits:

  1. Commit your changes by running git add . then git commit -a -m "YOUR MESSAGE HERE"
  2. Run git push heroku master again.
  3. After a few seconds, verify your changes.
Personal page
Now that is more like it

If all goes well, your site should reflect your changes. Keep revising untill you are satisfied, there is no penalty for the indecisive. The third and final post will go into some more optional pieces. If you don’t feel like registering a domain name (that will cost money), feel free to spread the link to where ever you want it to appear.