You may have noticed that this blog has a new URL. I’ve been meaning to get my own domain for a while and I finally decided to just do it. I ended up migrating off of wordpress.com and hosting with DreamHost. The move was rather painless. If you see something that doesn’t look quite right, let me know. It looks like all the code snippets didn’t make the migration very well. I’m working through those to update them.
Usually it is so easy to work on the Salesforce platform that I just jump right in and start coding or adding page layouts. Sometimes, if I don’t have a clear idea of what I need to do, a mockup can help. I recently found Balsamiq, and it is a fantastic tool for quickly creating wireframes. One thing I found myself doing was repetitively putting together the same components over and over again. I figured there must be a better way and found out about Balsamiq symbols. With symbols, I could create reusable components that can be quickly added to my mockup.
I tweeted to find out if anybody else had done something similar and got an overwhelming response that no, but people would love it. I ended up sharing my symbols on GitHub so others could benefit and contribute. Hopefully they will help you too!
Here’s what you’ll see in Balsamiq after adding the symbols to your project assets:
And here’s what they look like when added to a mockup:
What would you like to see added to this project?
Sometimes you create an awesome workflow rule and you just can’t figure out why it isn’t firing. Did you know you can use debug logs to check values and see if your workflow rule is firing? Here are the steps:
1. Open Developer Console: Click on Your Name->Developer Console
2. Make sure the Logs tab is selected.
3. Perfom the record save that you think should trigger the workflow.
4. Look in the Developer Console and you should see some logs. Depending on how you edited the record, it may show up in the log differently. You probably just want the last log. It will probably look like one of the ones with an arrow:
7. You’ll end up with something like this (you may need to scroll down a little):
With the arrival of Spring ’13, you may have noticed that finding code coverage is a little more challenging. Before Spring ’13, I would just open up my class which contained my tests, click the Run Test and then look at the code coverage results on the resulting page. That has changed in Spring ’13 because the tests now run asynchronously. There are a few ways to view your code coverage.
The first way is under Setup->Develop->Apex Classes. Look for the column called “Code Coverage”. When you click on the percentage, you’ll get a familiar looking screen.
The other option is to use the Developer Console. This gives you additional details about what each test method is actually doing. Open the Developer Console, click on the Repository Tab and then open the class for which you want to see the coverage. You can select to see no coverage, the coverage from all tests or coverage from a specific test method.
You can also run specific test methods from the Developer console if you open the test class.