Look at you, all full of pep, spunk, and other synonyms. You are a week away from going to TrailheaDX, the Salesforce conference dedicated to developers. Are you all ready? Do you know what ready is? I sure didn’t, so I decided to do some research and share the fruits of my labor. Let’s run through what to do to make the most out of your trip.
If you want to get involved in the Salesforce community, the default answer is usually the forums. It isn’t a bad answer, but it isn’t a complete one either. I can tell by the way that you are reading a third sentence into this blog post that you are a person who wants more. Reading this fourth sentence tells me you’re ready for more. You see, there is a wealth of opportunities to interact and get involved in ways that help yourself and others around you. Ways that can cater to your skills or help you develop new ones.
Let’s see, clear some cobwebs, dust off some settings, check that it was indeed over a year since my last post. Yep, every thing seems in order. To kick off this post-a-versary, how about a quick exploration of Salesforce’s built in geolocation features, now that this data has been automatically added to the standard address fields!
If I had ever thought I would be doing a post on documentation, I would have made sure to have more topic starters in the back log. Let me put this out in the open, I hate writing documentation. Now that that is out of the way I feel empowered and what better way to express that than by judging all of you. I am going to guess that a great many of you hate documentation as well. Now don’t get put off by that statement or think I am belittling anyone in particular. I have seen it everywhere, on projects big and small, proprietary and open source, useful and utter garbage. Even my own git hub projects languish with bad documentation. Actually writing documentation, it seems, is farther down on my todo list than writing a blog post about writing documentation. Part of the problem is that once you start getting serious about documenting it appears that everyone has different ideas of the style, scope, and purpose. With every single sample different, finding a consistent thread of what a specific type of documentation is for, becomes an infuriating mess. If you are like me, this turns into mental gridlock as you agonize over how far you go with the details.
Are you looking for a no holds bared, pulse pounding, head-to-head match up between two established titans!? Then I am sorry, this is just a comparison between two code editors. I am sorry to have wasted your time. If, however, you came here looking for the type of fuel that can keep a flame war burning for way longer than it should have, then have I got a post for you. First let me frame this for anyone who isn’t in the know.
Oh look, a git hub repo. That’s right, my mocking framework for apex has a name and a repo. Yay? Right now it is a 0.0.1 release. That means there is lots of chance for the api to change (I am still trying to decide whether to split out the object mocking and method stubbing). For now let’s see what it has to offer.
Like the title says, I am keeping good on my word to get some stuff done. I have been working on my mocking framework to post it to github. There have been a number of changes. Probably the biggest noticeable change is the switch to a mockito-like when+doReturn style. Along with this, I no longer use a static mock manager which means that there are less chances of method name conflict. The down side to this is that the mock now needs to be injected via constructor or property as the mocked calls are specific to the instance created in the test. The mocks have also been softened and now allow for out of order method invocation. There are still matchers but they have changed a bit. It is very much a work around for the lack of reflection and I expect them to change in the second release. In fact, there is a laundry list of features I want to add, but I need to get something out there first before I start planning where I will put the kitchen sink. Now, some may be wondering why I have not put anything in github and the reason is, is that this was a major overhaul from top to bottom. I didn’t want some broken piece of code attached to my name. Right now it is 90ish percent done. The code is working, but I want more tests and some clean up. You see, I do most of this at night… or the morning as it just so happens (12:11am as of this sentence) and while I produce working code, I also produce code with a high WTF/m at this time. So once I have it cleaned up, tested and commented, I will push it to github and make a big ol’ post about it here.
I feel happy. I feel happy…
Well color me surprised, my last article on mocking in apex was, well, a little more popular than I thought it would be. I was happy that so may people enjoyed it, but it got me thinking, “Bob, you handsome and brilliant, yet refreshingly humble man, you can do more for your fans!” After an obligatory back patting, I set off to add more features. This will build entirely off of the last article. In fact, you are doing yourself a disservice if you don’t read it post haste.
I love mocking frameworks. I love the ability to isolate a unit of code so I can make smaller, more coherent tests. I have grown accustom to them during my time with java and I would love to use them with apex. The problem is that mocking frameworks rely heavily on robust reflection, a feature apex sorrily lacks.
Well, this is an interesting situation. When I started this blog, my intent was to do reviews, news, and the occasional small project. My post series on using Heroku to host a personal site was just that. My last post which laid the ground work for an Apex static code analyzer took a good deal of time but would have been fine if it ended there. It didn’t end there though. In fact, I poured a pile more work into it this week to hook together the express framework as well as an sqlite database. If you have been watching the git repo, you have likely noticed…. nothing at all. The changes are so drastic, I cannot commit until I have at least the functionality I had before. No real post this week but I wanted to keep people in the loop.
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.
Sorry for the lack of post this week. House hunting and the depth of the next post are taking a bit more of my time than I expected. If everything goes as planned, I should have a dozy of a post for next week. While I have your attention, don’t be too surprised if the look and feel of the site changes as well, I am experimenting with new styles. I want to keep things simple but pleasing. See you all then!
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.
With Twitter, Facebook, Tumbler, LinkedIn, Instagram, GitHub, StackExchange, MySpace (is MySpace still a thing?) there is a lot of places to put your personal brand. You, dear reader, probably have a few of these yourself. Have you ever wanted a central location you could direct people to, one that linked to all your various identities? Luckily there are solutions, free ones in fact. The one I will be talking about in this series is Heroku, a web host with a unique way to do things.
subscribe via RSS