Modern development happens with JavaScript
Functional programming, with its roots in the 1950s, is more popular than ever. JavaScript—famously created in a hurry—has grown over the last couple decades into a serious, ubiquitous language. What once sounded laughable is now reality: the ecosystem is deep, and you can find libraries for almost anything.
JavaScript runs “web-scale” systems end-to-end: servers, build tooling, and the browser UI. It’s also simple enough that you can stand up a small web server in a handful of lines that read almost like English.
I’m not sure if you can tell yet, but I love JavaScript. And I’m excited about how well it pairs with Salesforce: you can use modern tooling to build responsive web apps faster, with a nicer developer experience than the old “click-and-pray” workflows.
JavaScript is a first-class Salesforce language (with the right tooling)
If you follow JavaScript, you know how rapid the pace of change is. There’s always a new library or tool—but that speed is also a strength: there are JavaScript tools to accomplish almost anything you’d want as a Salesforce developer.
- JsForce, nForce, ngForce, Heroku Force, etc...
- Control Salesforce from any environment: Command Line, Server, Browser
- Heroku + Heroku Connect for NodeJS / MEAN Salesforce apps
- Electron Engine underpinning Atom & Visual Studio Code
What is Visual Studio Code and how does it fit into this picture?
VS Code is a great Node.js development environment. It provides native Node debugging, runs on Electron, and uses Microsoft’s Monaco editor under the hood.
In my experience, VS Code hits the sweet spot: fast, simple, and extensible without forcing you into a heavyweight IDE.
So get to the workflow already
The Platform: It all starts with Node
- Node.js is the foundation modern JavaScript tooling depends on.
- NPM, Bower, and JSPM can all be used to retrieve packages. Most things can be found with NPM. (Historically, Bower/JSPM were popular too.)
Source Control and Project Management: Keep everyone up to date
-
SVN, Mercurial, or Git: use Git
-
When working in a team, branch management matters. Invest in a workflow that keeps branching and merging as painless as possible.
-
Use "GitFlow" as your branching and release management strategy: utilizing separate feature, develop, release, hotfix, and master branches, keeping broken code out of master as much as possible.
-
Bitbucket or GitHub: GitHub is popular for its interface and integrations (Slack, CI, etc.).
-
The differences are often mostly product ecosystem and pricing.
-
The combined offering from Atlassian of Bitbucket, Jira, and Jenkins is compelling works better for some enterprises
-
Jira, Sprintly, or ZenHub: mostly a preference call. ZenHub is compelling if you want tight GitHub integration.
Code Generators and CSS pre-processors: Don't Repeat Yourself
- Yeoman or Slush: we liked Slush for Gulp-era projects
- Stylus, Less, or Sass: Sass is a solid default
Generally, use the tool that has the content you want. Each has their benefits, but they're not really important when just starting out.
JavaScript pre-processors: ...and what they mean for the future of JavaScript development
ES6 (ES2015) was a major turning point for JavaScript. As developers, we should aim to make today’s code useful for as long as possible. You can use tools like Babel, but I’m going to make the case for TypeScript.
TypeScript lets you write modern code and compile it down for older runtimes, but the real differentiator is its type system. With TypeScript, you can optionally add types to JavaScript and get better tooling, refactors, and safer changes.
The Build system: The Magic
- Grunt is a task runner. It’s often used as a build system, but that can get messy as complexity grows.
- Gulp is a streaming build system that transforms source code through a pipeline. It works well, but it has limitations.
- Webpack was the next leap: module bundling that lets you assemble the client app more like a server app.
- It can import, assemble, bundle, uglify, and minify your code. And will give you a map!
- It can optimize, transform, preprocess, and assemble all your front end assets.
- It can run all your functional and integration tests
- It can even watch every one of your files and do all of that automatically, any time you save any file it cares about. It can even deploy all of that code up to Salesforce, automatically, about as fast as you can Alt+tab. Let me show you.
Demo of Webpack-Salesforce-Auto-Build-Deploy
Continuous Integration and Deployment
- Jenkins, CumulusCI, and CircleCI: CircleCI works great with Github
- They can run automated JavaScript and APEX tests
- They can deploy to whatever organization you want.
Finally... Other Tools
- Use Slack for integrated team communication. Integrates well with Git and CircleCI, and many other tools
- GoToMeeting for important internet meetings,
- Gmail and Hangouts for company wide and person to person communication.
The final word
Make the work you’re doing today matter tomorrow. Lean on JavaScript tooling for your Salesforce workflow, use TypeScript when it buys you safety, and use VS Code to keep the experience fast and pleasant.
It seems like there’s a new JavaScript tool or library every week. The key is to pick a small set that fits your team and stick to it long enough to compound the benefits.
Want to write a full-stack MEAN JavaScript app? Do it with Salesforce, Heroku, & Heroku Connect.
We're Agile at CodeScience
The process of development starts before the first bit of code is ever written. Software development is a complicated process that involves merging abstract concepts contained in the individual minds of team members into a structure that provides value to everyone. Because of this complexity, software development is a time consuming and expensive process. In order to minimize waste, we need to pay special attention to reducing effort and development time during our build process.
It's virtually impossible to build the right thing the first time. There will inevitably be incorrect assumptions and miscommunications. To build software properly, we need to have good tools that allow us the flexibility to change our code quickly and easily. We need to be able to properly debug an application.
What is Modern?
Modern is minimalist. Modern is clean. Modern is now. To be minimalist, we use fast text editors. To have clean code, we use MVC. To be now, we use JavaScript (Node, Angular)
Design Before development can start
We have to first understand what we're trying to build before we start building it. We do this through first establishing user personas. We have to know who we're going to be building the application for in order to know what those users will need the application to do.
Establish the personas that will be targeted with the MVP.
Proceed to build scenarios or use cases for each of the personas involved. We do this so we can establish what the basic requirements are so each persona involved can derive value from the application.
We then proceed to wire-framing where the UX designer creates an initial walk-through of the application. This allows the team to review a concrete idea to find where the issues are with the design. We do this so we can figure out how our assumptions are wrong sooner. It allows the team and product owner to review each aspect of the MVP and create a dialog about what features are missing or possible different ways to accomplish a certain task.
The modern workflow starts with development mockups in Lucid Charts or another wire-frame tool that can be easily shared amongst the team.
Telling Agile Stories
After we have a good idea about the structure of the application and the needs of the users, we start writing user stories. These short sentences—often captured on a sticky note—describe functionality that provides business value. We structure our user stories so the business value is always included.
A good practice is to write these user stories directly into GitHub as issues. Those issues become your backlog. Tools like ZenHub can organize the backlog into pipelines, sprints, etc.
Story Grooming
After we have a collection of user stories that cover the persona walk-throughs, we groom them by adding acceptance criteria: what a tester can do to prove the story is satisfied and the business value is delivered.
Story Sizing
We then size the stories so we can do sprint planning. Story points estimate time, complexity, effort, and risk—not just “how long will it take.”
Prioritizing
Then the product owner prioritizes the backlog based on what business functionality is most important. This helps the team decide what to pull into the sprint backlog first.
The Sprint backlog is built and the Sprint can begin
Once the team has established what features will be delivered during the first sprint, they can begin implementing the requested work.
All of the previous steps can be done using Lucid Charts, GitHub, and ZenHub. Communication among the team (and with build tools) can be consolidated in Slack.
TDD and BDD
Once we have the user stories and acceptance criteria, we can establish what tests we will need to run. These tests should be unit tests (or other well-scoped tests) that align with the story’s acceptance criteria.
Implement the functionality
Now that we know what we need to build—and can test that it’s not built yet—we can start implementing the code that drives business value. It may seem strange (or wasteful) that “nothing has been built” until now, but because development is the most expensive and unpredictable part of the process, this reduces the risk of wasted time by building the wrong thing.