Salesforce DX? Continuous Integration? Source Controlled Development? Where to start??
Salesforce has recently introduced it’s new Developer Experience (DX) as of October 2017. The purpose of DX is summed up very nicely on the DX homepage
“Welcome to the modern developer experience that will change the way you build Salesforce applications. Whether you’re an individual developer or working in a large team, Salesforce DX provides you with an integrated, end-to-end lifecycle designed for high-performance agile development. And best of all, we’ve built it to be open and flexible so you can build together with tools you love.”
Let’s break this down.
Many teams at REA have adopted Scala, and we were keen to give it a go for our new backend web application. I wanted to talk about our experiences, and ultimately our decision to stick with Ruby (!).
Splunk’ing Netsuite is the act of aggregating logs from Netsuite into Splunk
So what is this blog post about? Allow me to introduce the problem – we have Netsuite. We use it extensively in REA. We also have Splunk which is used, even more extensively, I reckon, throughout the company. We would like to have our Netsuite execution logs in Splunk. Sounds simple? well, as it turns out – that’s not that simple.
Over the years we have created a lot of software at REA ranging from internal tools used by our customer experience team, to mobile apps used by millions of users each month, to data processing engines that crunch hundreds of gigabytes of data. While each piece of software has different functional and non-functional requirements we still have consistent expectations of that software as well as alignment on architectural principles. By taking this general consensus floating in the ether and capturing it using succinct language within high-level categories we have formed a foundation for discussion to ensure we can keep producing good software regardless of team, technology, and timeframe. Additionally, we routinely use this framework to assess all new and existing software to ensure our software continues to meet expectations and, where concerns are detected, to drive change.
The categories – overview
When considering the qualities of good software we use the following lenses:
There’s a pattern that I keep recommending to teams over and over again, because it helps separate concerns around I/O; sending and receiving things over a network, interacting with AWS, saving and loading things from data stores. It’s an old idea; you’ll find it filed under “Decorator” in your Gang of Four book.
For our purposes here, this is a compositional pattern that allows us to stack onion-rings of concern around an I/O boundary; strings on the wire, transfer protocols (eg HTTP) , formats (eg JSON), business concepts. There is no code in existence that should be concerned about more than one of these at once; they can be structured as stackable layers, and other modules can pick which level of detail they wish to talk to.
In REA, we have a list of highly sought after internal courses available on various topics including AWS, Docker and Elasticsearch. On 7th and 8th May 2018, we added Scala to the list, with over 20 people attending!
How did this all start?
Scala and functional programming have always had some mystique surrounding it. There is this idea that it is too hard or not pragmatic enough. Existing courses are very technical and many people including myself have struggled to complete them.