DEV Community: Laura Lindeman

Engineer more than software

Laura Lindeman — Wed, 24 Mar 2021 16:16:27 +0000

Salesforce engineers are builders. Together, we’ve created a platform that helps companies around the world connect with their customers. Driven by our commitment to trust, equality, and innovation, we’re contributing to a more collaborative and inclusive world. Learn more at salesforce.com/tech.

2020 Year in Review

Laura Lindeman — Wed, 06 Jan 2021 15:11:47 +0000

2020 was (dare we say it?) an unprecedented year, but before it's fully in the rearview, we at Salesforce Engineering wanted to take a beat and look back at 10 good things that happened.

10. With our thousands of employees forced to leave their offices and work remotely, we took the opportunity to develop new practices and guidelines for distributed work. We'll be better able to effectively communicate, create, and collaborate together no matter what the next year(s) hold.

9. We published a lot of blog posts! Our top three most-read posts covered security (Easily Identify Malicious Servers on the Internet with JARM), automated testing (Automating Complex End-to-end Tests), and an open source tool for Kubernetes (A Generic Sidecar Injector for Kubernetes).

8. We sponsored the first-ever virtual Grace Hopper Celebration put on by Anita Borg and extended internship offers to a slew of folks we’re looking forward to welcoming to the team next summer.

7. In a truly strange year, almost 300 employees took to the virtual stage at conferences around the world (er, in their living rooms?) to talk about the great work they’re doing.

6. It’s no secret we love open source. We headed to the StackOverflow blog to share the complexities and rewards of open sourcing corporate software projects.

5. Speaking of open source, we dropped some cool projects this year: Best, which allows you to write JavaScript benchmarks in the same way you write unit tests and integrate it into your continuous integration workflow; the AI Economist, which is an open source framework for economic policy design; and Cloudsplaining, an AWS IAM Security Assessment tool that identifies violations of least privilege and generates a risk-prioritized HTML report, among many others.

4. We launched the FOSS Fund to donate money every quarter to a project selected by our employees; a sustainable open source ecosystem is essential for our technical future.

3. The world got to meet the Salesforce Kubernetes Platform, a substrate-agnostic Kubernetes install that handles concerns for the entire runtime stack.

2. The Buildpacks project was promoted to Incubation from the Cloud Native Computing Foundation Sandbox.

1. We announced Hyperforce, a complete re-architecture of Salesforce that uses the scale & agility of the public cloud, representing a massive, multi-year, cross-company engineering effort that we’re so proud of.

So that’s a wrap on 2020. It was a difficult year, making it all the more worth looking back on what we accomplished together! We're already back at it after taking a short breather around the holidays and hope to bring you more great stuff in 2021.

Salesforce Employees Make 178 Open Source Contributions During Hacktoberfest!

Laura Lindeman — Thu, 19 Nov 2020 14:42:44 +0000

by Alyssa Arvin, Sr. Open Source Program Manager

Salesforce engineers are builders.

Together, we’ve created a platform that helps companies around the world connect with their customers and establish lasting, trusted relationships. Whether we’re working with a small business, a nonprofit, or a Fortune 500 company, it’s our job to ensure all systems are always a go. And with thousands of customers and tens of millions of daily users on our platform, our aim is to keep pushing boundaries on just how massively we can scale.

We’re also building a team of problem solvers who believe technology creates meaningful progress when the people behind it progress together. Driven by our commitment to trust, equality, and innovation, we’re contributing to a more collaborative, inclusive, and connected world. We contribute to thousands of open source projects every year, from key technologies powering our innovation to community projects that make our world a better place.

We couldn’t let October pass without participating in Hacktoberfest. This year looked a little different and it actually came with better results!

This year we had 52 people participate in Hacktoberfest with a 178 total open source contributions! Almost half of the participants made 4 or more contributions. Our employees also gave 71 hours to volunteering through open source.

How did we run Hacktoberfest at Salesforce?

The biggest theme of our Hacktoberfest was.... THEMES! We came up with themes for each week to help inspire people to contribute. The themes were:

Week 1: Project you know & love
Week 2: Projects that were released by Salesforce employees
Week 3: Projects we depend on at Salesforce
Week 4: Volunteering through open source

Our employees didn’t have to stick to the themes. If they wanted to make contributions throughout the entire month to one project they loved, then they could do that! However, the themes were really helpful in getting new open source contributors to see what projects were out there.

“It's a great introduction to the open source world and has a lot of community support that beginner contributors are looking for.” - Swati Kothari

This year we skipped things like tech talks, office hours, and synchronous events and instead encouraged people to contribute when they wanted to. The great thing about this is that it allowed anyone to participate no matter what time zone they were working in. We had a huge turnout from our employees in India and Tel Aviv.

“This was really fantastic, exciting and energetic event. I was quite amazed to see many Salesforce employees all around the globe participating in various open source projects while working from home. And I am sure anyone who loves coding to the core would feel the same.” -Viraj Jasani

We also followed DigitalOcean’s lead to make Hacktoberfest easier on open source projects. We encouraged our employees to use Hacktoberfest’s list of projects and to only make meaningful contributions. For projects that were released by Salesforce employees, we made sure the maintainers wanted their project listed as an opportunity. The projects listed under the volunteering theme were previous projects that we had used, so we knew the maintainers were comfortable accepting contributions.

Reflections

It is always fun to try new ways to get people contributing to open source. What are some ways that you have encouraged employees? Let us know on Twitter @SalesforceEng.

How an SRE became an Application Security Engineer (and you can too)

Laura Lindeman — Wed, 28 Oct 2020 13:24:24 +0000

by Breanne Boland

I realized I found security really interesting early on in my career as an engineer, back in 2015. It was a useful complement to infrastructure and networking, the other interests I quickly picked up. However, while security roles are notoriously hard to fill, they’re also notoriously hard to get when you haven’t had one before. I assumed security work would be something I’d pursue once I felt more grounded in my skills as a site reliability engineer – meaning I might have waited forever, if left to my own self-education.

Instead, early last fall, a friend reached out to me about an opening on her team at Salesforce. They wanted someone with an SRE background and security aspirations. Was I interested in pursuing it as a job, she asked, or was it just a professionally adjacent hobby?

I had to sit and think about that.

For about five seconds.

I typed back a quick ~~I VOLUNTEER AS TRIBUTE~~ extremely casual and professional confirmation that I was indeed interested in security as a career, and then the process began in earnest.

Starting the conversation, completing the interview

My interview and hiring process, from first conversation to gauge interest to phone screen to final interview, took about two months. (This was longer than is typical for this role, as I was out of town for three weeks when I first applied.) I have an eclectic resume, as you’ll learn later, and, during my interview process with Salesforce, I got to highlight things that I have learned in different ways: through casual conversations, the formal interview, and even some impromptu network diagramming on a whiteboard when I realized my hand gestures were not up to conveying the complexity of what we were discussing. (Spoiler alert for preparing for a security interview, which I’ll talk much more about later in this post: if in doubt, it’s always the OWASP Top Ten. Also worth checking out: Salesforce’s interviewing trail.) I was also able to meet a DevOps architect who, like me, thinks it’s extremely important to encourage junior engineers, which gave me a good feeling about Salesforce being a place I could be supported to successfully make the move into AppSec. We benefit enormously from diverse experience, so I was glad to know I was being assessed on my skills, not my years on the job or other sometimes-superficial markers of seniority. When I left after the interview, I wasn’t certain if I’d done well or not, but I felt like I’d done as well as I could have and demonstrated the things I actually know, which is a good interview in my book.

An ops CV for security

I began my career as a writer and editor. I attended code school in 2015, and my first engineering job was at a consultancy that focused on infrastructure and process. After three years of consulting, I moved to a role as a site reliability engineer (SRE). Throughout all this, I cultivated my interest in security by going to DEF CON, Women in Security and Privacy (WISP), Day of Shecurity, and the many other security events that take place in the Bay Area. It became clear pretty quickly that ops and security have a lot of things in common – that is, beyond a reputation for being risk-averse and more than a little curmudgeonly.

There are skills that are essential for both, including:

Networking, infrastructure, AWS, and port hygiene
Coding, especially scripting; Bash and Python are great choices but aren’t the only valid ones
Command line skills
Looking up running processes and changing their state
Reading and manipulating logs

The skills that are less explicitly required but that I’ve found to be really useful include:

Communication, both written and verbal
Documentation creation and maintenance
Teaching
A UX-centered approach

Here’s what I mean by that last one: I have some education in UX principles and practices, and I’ve done official UX exercises as part of previous jobs. I’m still able to, if needed. The part of it I use most often, though, is what I’ve come to think of as a UX approach to the everyday. (Beginner’s mind is a similar idea.) What I mean by that is the ability to come into a situation with someone and assume that you don’t understand their motivations, previous actions, or context, and then to work deliberately to build those by asking questions—while resisting the very normal human inclination to think that you totally understand this other person’s situation well before you actually understand it. The key part is remembering that, even if someone is doing something you don’t think makes sense, they most likely have reasons for it, and you can only discover those by asking them.

This was useful in ops, when I was often dealing with app engineers who weren’t familiar with my part of our systems, and it’s useful in security, when an incomplete understanding of why people do what they do can result in processes that no one will use and vulnerabilities left unchecked. It makes you nicer to deal with, yes, but also much more effective in your work.

My accidental security education

Here’s something I only realized after getting this job: I’ve done a LOT of security learning since becoming an engineer. I just didn’t fully realize what I’d been doing because I thought of it as just having fun. Meaning: I did none of these things with interview preparation in mind. The closest I came was thinking, “Oh, I see how this might be useful for the kinds of jobs I might want later, but I’m definitely not pursuing them right now.” It’s a great way to get an education in something, with no pressure and all of the enthusiasm of the hobbyist, but I realize it’s not going to be accessible for everyone.

These are the things I did over the last four years that ended up being really helpful as I went through this process:

Going to DEF CON four times
Going to Day of Shecurity three times
Being a beta student for an eight-part course all about writing secure code from a friend’s security education startup
Attempting Capture the Flags (CTFs)
Talking security with my ops coworkers, who all have opinions and stories
Volunteering for AWS IAM work whenever it came up as a task
Classes at the Bradfield School of Computer Science in computer architecture and networking (I suggest getting a company to pay for this)

Every one of these things gave me something that either helped me feel more adept while interviewing or that I was able to mention when answering questions and discussing the job. Four years is a lot of time to pursue something casually, especially since I went to an event at least every month or two.

I’ve also benefited from industry newsletters, especially these:

The Cloud Security Reading List
Julia Evans’s weekly emailed engineering comics
Devops Weekly
SRE Weekly
Crypto-Gram from Bruce Schneier

Many of these are ops-centric, but all of them have provided something to this most recent professional transition. Very few issues and problems exist in only a single discipline, and these digests have been really useful for seeing the regular intersections between things I knew and things I wanted to know more about.

Interview preparation, done deliberately

Once the interview was scheduled, I dove into interview studying. I made a wishlist of everything I wanted to be able to talk confidently about, prioritized it, and began working through everything I could. I touched on about half of it, as it was an ambitious list. I studied for about a week and a half, a couple hours at a time. I focused on three main things:

Exercism, primarily in Python
The OWASP top ten from 2013 and 2017
Blog posts that crossed my current discipline and the one I aspired to

The Exercism work was because I never feel like I code as much as I’d like in my jobs, and I feel more confident in technical settings when I feel more fluent in code. The OWASP reading was a mix of official resources, their cheat sheets, and other people’s writing about them; reading different perspectives is part of how I wrap my head around things like this. And the blog posts were for broader context and also to get more conversant about the intersection between my existing skills and the role I was aspiring to. Studying a high-profile breach that happened due to misconfigured AWS IAM permissions, something I was already well versed in, was really useful for this.

(Read about our open source project Policy Sentry automates least privilege in AWS IAM.)

Here’s a grab bag of some of the other things I read, watched, and used that helped me feel better prepared for the interview.

The great and terrible thing about infosec education is that there are so many resources out there for you to learn from. Pick a couple of things you want to get really good at (ideally that you already know something about, that’s already important to your current job or field of study) and keep digging into them. The other thing I’d recommend, which I hear suggested less often, is making sure you can explain what it is you’re trying to understand to another person. I have a couple non-engineer people in my life who let me explain things to/at them, and it’s the single best thing I do to make sure I actually understand something, instead of that inaccurate feeling of “understanding” that actually means “I read that, and the individual sentences made sense,” which is a bit different - and not something you want to realize in the middle of an onsite.

No, really: you can too

I want to leave you with some more general ideas of how to shape your career to more effectively get to the security role you might be seeking.

Find a couple security-essential skills you already know something about and dive deeply into them. For instance: I have a lot to say about IAM stuff, in AWS, Jenkins, and general principle of least privilege contexts, so that’s been something I’ve really focused on when trying to convey my skills to other people. Find what you’re doing that already applies to the role you want, and get conversational in it. Keep up on news stories relevant to those skills. This part shouldn’t be that hard, because these skills should be interesting to you. If they aren’t, choose different skills to focus on, and keep that in mind as you continue figuring out the right place for you in security.

While you’re doing this learning, make sure the people in your professional life know what you’re doing. This can be your manager, but it can also be online communities, coworkers you keep in touch with as you all move companies, and anyone else you can speak computer or security with. Don’t labor in obscurity; share links, mention things you’ve learned, and search for other people interested in the same things.

Build that community further by going to meetups and workshops. When I think about living outside the Bay Area, one of the things that would be hardest to give up is all the free education that’s available. Day of Shecurity, OWASP in SF and the south bay and so many more—and with everything being online now, there are so many more resources available from wherever you live. Follow some infosec folks on Twitter, search on meetup.com, and find your people.

Finally, remember that security needs you. Like all of tech, security is better when there are a lot of different kinds of people working out how to make things and fix things. Please hang in there and keep trying. And good luck. <3

How to Build a VS Code extension for Markdown preview using Remark processor

Laura Lindeman — Tue, 13 Oct 2020 13:31:22 +0000

Add missing remark preview support by writing your own extension.

Author:

Subrat Thakur (subrat.thakur@salesforce.com)
LinkedIn: https://www.linkedin.com/in/subrat-thakur/

Introduction

Visual Studio Code (VS Code) is a cross-platform, light-weight code editor created by Microsoft for Linux, Windows, and macOS. VS Code has support for extensions to add extra capabilities. If a feature you want is missing, you can create an extension to add it.

In my case, I wanted to be able to use a Markdown processor other than the one natively supported by VS Code. VS Code supports Markdown files out of the box and targets the CommonMark Markdown specification using the markdown-it library. But there is no way to use another markdown processor like remark, common marker, or showdown instead of markdown-it in default preview. You can definitely change the style by adding CSS to update the look and feel but the internal processor will stay as markdown-it. So, I decided to create my first VS Code extension! In addition to sharing this specific extension in the Marketplace, I wanted to outline the steps I took to build it, so that you can build an extension for a feature you want to see.

The very first step of building a VS Code Extension

To get started, install the following if you haven’t already:

VS Code
Node.js
Yeoman: An open-source client-side scaffolding tool that helps you kickstart new projects.
vscode-generator-code: A Yeoman generator to generate a new Visual Studio Code extension project from a template.

To install Yeoman and vscode-generator-code: npm install -g yo generator-code

VS Code extensions support two main languages: JavaScript and TypeScript. So having basic knowledge of either of these is pretty mandatory.

Generate a VS Code Extension Template

Go To ‘Terminal’ (‘Command Prompt’ in case of Windows), navigate to the folder where you want to generate the extension, type the following command, and hit Enter:

yo code

At the prompt, you must answer some questions about your extension:

What type of extension do you want to create? New Extension (TypeScript).
- To know about other type of extension you can go through : What can extensions do ?
What’s the name of your extension? (in my case it was Remark Preview)
What’s the identifier of your extension? (consider it Visible Name in small-case separated by -) e.g remark-preview
What’s the description of your extension? Write something about your extension (you can fill this in or edit it later too).
Initialize a Git repository? This initializes a Git repository, and you can add set-remotelater. To create an extension Git repo is not a mandatory thing. You can publish it directly from your local as well.
Which package manager to use? You can choose yarn or npm; I will use npm.

Hit the Enter key, and it will start installing the required dependencies. And finally you will get:

Your extension remark-preview has been created!

To start editing with Visual Studio Code, use the following commands:

 cd remark-preview
 code .

The project's structure

Once you are done with generating the extension template and open it in VS Code, your editor will look like this:

The generator-code project creates the most basic wiring and plumbing needed for a functioning extension. If you look in the extension directory, you’ll see several files:

vsc-extension-quickstart.md provides some instructions for creating and using the extension.
extension.js is the actual code for the extension. The entire extension doesn’t need to fit into this one file, but this is the default entry point for the extension.
jsconfig.json controls how the project’s JavaScript code is handled by the Node.js runtime. You generally don’t need to change anything here.
package.json contains the packaging information for your extension. If you are a Node.js developer, some of this might look familiar since name, description, version, and scriptsare common parts of a Node.js project.

I will talk about the files more, but, for now, let’s try running our basic extension.

// This will install all the dependencies
npm install

// This will compile your code 
npm run compile

// Run the code by hitting f5
f5

The above code instructions will open a new VS Code window with your basic extension installed in it.

What’s different inside Package.json ?

There are a few sections that are very important.
- engines: States which version of VSCodium the extension will support
- categories: Sets the extension type; you can choose from Languages, Snippets, Linters, Themes, Debuggers, Formatters, Keymaps, and Other
- contributes: A list of commands that can be used to run with your extension
- main: The entry point of your extension
- activationEvents: Specifies when the activation event happens. Specifically, this dictates when the extension will be loaded into your editor. Extensions are lazy-loaded, so they aren't activated until an activation event occurs

Let’s focus on few concepts that are crucial for VS Code extension development:

Activation Events: events upon which your extension becomes active. This will be part of package.json e.g

//the extension becomes activated when user runs the `Hello World` command
"activationEvents": [
  "onCommand:opendocs.helloWorld"
],

This is currently there inside your newly generated projects package.json

A few more example would be:
EX 1:

//This activation event is emitted and interested extensions will be activated 
// whenever a file that resolves to a certain language gets opened.

"activationEvents": [
  "onLanguage:markdown"
]

As we are planning to develop an extension for markdown, the above could be suitable for our extension ⬆️

EX 2:

// This activation event is emitted and interested extensions will be activated 
// whenever a folder is opened and the folder contains at least one file 
// that matches a glob pattern. 
"activationEvents": [
  "workspacecontains: package.json"
]

EX 3:

//The `*` activation event is emitted and interested extensions will be activated 
// whenever VS Code starts up.
"activationEvents": [
  "*"
]

You can also provide multiple multiple event as "activationEvents" is an array.

Contribution Points

Static declarations that you make in the package.json Extension Manifest to extend VS Code. This could be used to add commands available in command pallets, menu bar, editor title, editor context as well as configurations related to the extension.

Commands: Contribute the UI for a command consisting of a title and (optionally) an icon, category, and enabled state.

Configuration: Contribute configuration keys that will be exposed to the user. The user will be able to set these configuration options as User Settings or as Workspace Settings, either by using the Settings UI or by editing the JSON settings file directly.

menus: Contribute a menu item for a command to the editor or Explorer. The menu item definition contains the command that should be invoked when selected and the condition under which the item should show.

keybindings: Defining key binding for window (linux) and mac for each command.

Command Palette: When registering commands in package.json, they will automatically be shown in the Command Palette (⇧⌘P). To allow more control over command visibility, there is the command palette menu item. It allows you to define a when condition to control if a command should be visible in the Command Palette or not.
Sorting of groups: Menu items can be sorted into groups. The order inside a group depends on the title or an order-attribute. The group-local order of a menu item is specified by appending @<number> to the group identifier

Registering a command

vscode.commands.registerCommand binds a command id to a handler function in your extension. This will be part of extension.js by default (or whatever entry point you mentioned in package.json).

Once you are done adding these few points your extension will be in good shape in terms of configuration. Let’s talk about our goal to generate a preview.

Generating Preview

We already decided that we would use remark processor to process our markdown, but the most important question is: how are we going to show it inside VS Code?

So the one word answer for it is Webview.

What is Webview ?

As per VS Code documentation, the webview API allows extensions to create fully customizable views within Visual Studio Code. For example, the built-in Markdown extension uses webviews to render Markdown previews. Think of a webview as an iframe within VS Code that your extension controls. A webview can render almost any HTML content in this frame, and it communicates with extensions using message passing.

So the flow is going to be very simple :

Create HTML of our Markdown content using remark.
Add it to Webview as content.
Show that Webview in VS Code!

Simple, right?! I promise it is simpler than it sounds!

SO, let’s begin.

Create HTML content from Markdown content

This code sample will turn markdown into HTML. In our case, instead of creating another Markdown compiler instance, we will use @sfdocs-internal/compiler package .

import admonitions from 'remark-admonitions';
import * as html from 'remark-html';
import * as remark from 'remark';

function markdownCompiler(): any {
    const admonitionsOptions = {};

    return remark()
        .use(html)
        .use(admonitions, admonitionsOptions);
}

let currentHTMLContent = await markdownCompiler().process(markdownContent);

You need to add the below entries to package.json and run npm install to install new dependencies:

        "remark": "12.0.1",
        "remark-admonitions": "1.2.1",
        "remark-html": "12.0.0",

Create a Webview Panel

// Create and show a new webview
this.panel = vscode.window.createWebviewPanel(
        // Webview id
        'liveHTMLPreviewer',
        // Webview title
        '[Preview] ' + fileName,
        // This will open the second column for preview inside editor
        2,
        {
            // Enable scripts in the webview
            enableScripts: true,
            retainContextWhenHidden: true,
            // And restrict the webview to only loading content from our extension's `assets` directory.
            localResourceRoots: [vscode.Uri.file(path.join(this.context.extensionPath, 'assets'))]
        }
 );

Add HTML to Webview Content

this.panel.webview.html = await markdownCompiler().process(markdownContent);

Finally, this is what your extension.ts should look like:

import * as vscode from 'vscode';
import { admonitions } from 'remark-admonitions';
import * as html from 'remark-html';
import * as remark from 'remark';
import * as path from 'path';


export function activate(context: vscode.ExtensionContext) {

    // commandId
    const SIDE_PREVIEW_COMMAND = 'remark.sidePreview';

    const disposableSidePreview = vscode.commands.registerCommand(SIDE_PREVIEW_COMMAND, async () => {
        initMarkdownPreview(context);
    });

    context.subscriptions.push(disposableSidePreview);
}

async function initMarkdownPreview(context: vscode.ExtensionContext) {
    const panel = vscode.window.createWebviewPanel(
        // Webview id
        'liveHTMLPreviewer',
        // Webview title
        '[Preview]',
        // This will open the second column for preview inside editor
        2,
        {
            // Enable scripts in the webview
            enableScripts: true,
            retainContextWhenHidden: true,
            // And restrict the webview to only loading content from our extension's `assets` directory.
            localResourceRoots: [vscode.Uri.file(path.join(context.extensionPath, 'assets'))]
        }
    );
    panel.webview.html = await markdownCompiler().process(vscode.window.activeTextEditor?.document.getText());
}

function markdownCompiler(): any {
    const admonitionsOptions = {};
    return remark()
        .use(html)
        .use(admonitions, admonitionsOptions);
}



// this method is called when your extension is deactivated
export function deactivate() { }

You can make it more modular and efficient.

Now let’s talk about few more things that might be useful for your new preview extension.

Developer Tools for Webview

As I already told you, Webview is very similar to a Web Browser; you can actually inspect the Webview Panel, check the console logs, and debug any script added to it when the Webview is open. To do all this, open Command Palette (⇧⌘P) and Search for “Developer: Open Webview Developer Tools.” This will open a developer console very similar to Chrome browser.

Content security policy for Webview

Content security policies further restrict the content that can be loaded and executed in webviews.

To add a content security policy, put a <meta http-equiv="Content-Security-Policy"> directive at the top of the webview's <head>.

Here's a content security policy that allows loading local scripts and stylesheets (inline as well), and loading images over https:

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; img-src ${panel.webview.cspSource} 'self' 'unsafe-inline'; script-src 'nonce-${nonce}'; style-src ${panel.webview.cspSource} 'self' 'unsafe-inline'; font-src ${panel.webview.cspSource}">

The ${webview.cspSource} value is a placeholder for a value that comes from the webview object itself.

We can also load the scripts and css in old fashion way if we use vscode uri path instead of relative path.

function **getDynamicContentPath**(context, panel, filepath) {
    const onDiskPath = vscode.Uri.file(path.join(context.extensionPath, filepath))
    const styleSrc = panel.webview.asWebviewUri(onDiskPath);
    return styleSrc
}

VS Code creates a secure URI for webview panel and makes it accessible for Iframe.

<link rel="stylesheet" type="text/css" href="${getDynamicContentPath(context, panel, 'assets/css/admonitions.css')}">

How to interact with Webview through Messages?

As we all know by now, Webview is content inside an iframe, so we need special messaging to send events to Webview.
So whenever we want to send a message we can use something similar to:

private postMessage(msg: any) {
        // here this flag is to check if webview panel is still alive or not
        if (!this._disposed) {

        // this.panel is the instance of Webview Panel
            this.panel.webview.postMessage({
                        type: 'messageFromExtension',
                        line: visibleRanges});
        }
    }

Now let’s see how to catch this message inside Webview. The most important thing is that this script should be part of the HTML that we add to Webview panel.

window.addEventListener('message', event => {
    const message = event.data;
    if (message.type === 'messageFromExtension') {
        console.log('Line : ' + message.line[0][0].line);
        onUpdateView(per);
    }
});

In a very similar fashion, we can catch any window event of Webview as well like scroll, click, double click, etc.

For example:

window.addEventListener('scroll', throttle(() => {
    console.log("Scroll Event in Webview window");
}, 100));

To send any message back to VS Code, we need to use acquireVsCodeApi.

// acquireVsCodeApi is the api to talk to extension from webview
const vscode = acquireVsCodeApi();

// createPosterForVsCode is a class provided by VSCode
const messaging = createPosterForVsCode(vscode);
messaging.postMessage('revealLine', { line });

And in the same way, we need a subscribe method for any events coming from Webview:

//this should be part of extension and no need to load inside webview
this.panel.webview.onDidReceiveMessage(e => {
     console.log(e.body.line);
});

Publishing Extensions

To publish an extension, you need to set up a few things.

Install VSCE : vsce, short for "Visual Studio Code Extensions," is a command-line tool for packaging, publishing and managing VS Code extensions. You can use vsce to easily package and publish your extensions. It can also search, retrieve metadata, and unpublish extensions.

To install VSCE: npm install -g vsce

Get a Personal Access Token: You need to create an account on Azure Dev. You can log in using Github as well. Once you log in, you have to create a project; you can probably name it VSCode Extensions. Once you are done, let’s move ahead to create Personal Access Token.
- Open the User settings dropdown menu next to your profile image (top right corner) and select Personal access tokens:
- On the Personal Access Tokens page, click New Token to create a new Personal Access Token
- Give the Personal Access Token a name; optionally, you can extend its expiration date to one year, make it accessible to every organization, or select a custom defined scope ruleset:
- Finally, scroll down the list of possible scopes until you find Marketplace and select Manage:
- Select Create and you'll be presented with your newly created Personal Access Token. Copy it; you'll need it to create a publisher.
Create a publisher : A publisher is an identity that can publish extensions to the Visual Studio Code Marketplace. Every extension needs to include a publisher name in its package.json file.

Use this command to create publisher : vsce create-publisher

Use this command to login : vsce login

Publish your extension: As the final step, publish your extension to marketplace.

Use this command to publish : vsce publish

Keep in mind you always need to change version in package.json before re-publishing the extension, or else it will throw an error. You can use a command like vsce publish minor or vsce publish 2.0.1 .

Wrapping up

One message I want you to take to heart is that creating a VSCode extension is not as hard as it looks. It is pretty simple, actually. Sometimes you just need to push yourself a bit and try things out.

VS Code is awesome 😎 and it’s really amazing how we can extend functionality inside it by developing extensions.
There are many helpful APIs that will help you create the extensions you want to build. The VS Code extension API has many other powerful methods you can use.

If you want to take a look at the whole project the code is available here, which might help for code references (watch out for some messy code though!) and you can also find it in the marketplace.

Reference

VS Code Extension Sample
VS Code Extension DOC
Workbench Extension

Salesforce Standup with Jae Taylor

Laura Lindeman — Mon, 28 Sep 2020 18:43:47 +0000

Welcome to the Salesforce Standup, where we check in with employees in our Technology, Marketing, and Product organization from locations all over the world! At every Standup we ask our guest some questions to help us get to know them better. As any good standup should be, it's a quick chat where we’ll find out answers the questions that matter most—or maybe are just the most fun. You’ll have to watch to find out.

Today's guest, Jae Taylor, is a director of Product Management for Service Delivery at Salesforce. That means he drives the efforts to make sure our platform, which so many people depend on, is highly available and highly performant.

Outside of work, Jae is passionate about the importance of mentorship, which he's seen at play throughout his varied career. He's not a morning person but has started running first thing and finds it makes him more alert and productive throughout the day. And, he loves spending time with his kids building video games.

Catch the whole interview to find out more about Jae!

We caught up with @JaeInTech in the latest edition of the #SalesforceStandup. He loves Korean food, building games with his kids in @unity3d, and starting his day on his @onepeloton treadmill! Watch the video to learn what new gadget has changed the way he uses his phone pic.twitter.com/AGhR65IsYG
— @SalesforceEng (@SalesforceEng) September 25, 2020

Principles of Learning

Laura Lindeman — Thu, 18 Jun 2020 17:09:04 +0000

by Rafay Syed

When I was in middle school, I used to think that I was not capable of learning new concepts very quickly because my peers would tell me that they never studied. Some of them would receive high grades in the range of 95–100, while I would sit there thinking how hard I studied and I would have a 90 or a high B. I would feel discouraged thinking that maybe I was not smart enough, because I would spend all this time studying while others would tell me that they would not study and would receive such high grades. However, I realized that studying is essential to learning and that there is no substitute for drive and persistence, and even IF people got by without studying, they would not be successful in the long run. Here I will highlight eight principles of learning from Andreia Neagoie’s Udemy course Learning How to Learn that helped me reach this mindset.

Learning vs. Winning the System

When you go to school, do you think about what you are going to learn on that day, or do you think about how you can make an A in the class? Many of us are guilty of the latter. When you are studying for an exam, do you actually study for the sake of learning the material, or do you think about what will and will not be on the exam? We have to learn how to un-learn this tendency in order to embark on a lifetime of learning. Cramming for a test the night before is never a good idea because you will not be able to retain all that information and your brain will not be able to make the synaptic connections you can make through compound learning, studying a little bit at a time, every day, for a sustained period of time.

What is Success?

A lot of people think that in order to be successful, you have to be very smart, but that is not enough nor will it ever be enough. There are two things that help you get to the success that you want to achieve: drive and persistence. You can be very smart, but if you are lazy and you are not willing to put in the hard work, you will never be successful.

Obstacles

When you go on your learning journey, you will always encounter obstacles. Obstacles will help us grow, and if you do not encounter any obstacles, you are doing something wrong. If there were no obstacles in life, everyone would be successful. When we see an obstacle, we should say, “I know this is something that I’m struggling with, but I will overcome it and this just means that I am growing”.

The “Dip”

The dip is when you realize that something is not meant for you, and I can give you an example. Let’s say that I wanted to work hard to get into the NBA and play basketball for a living. Is that possible for me? I am 26 years old now, and most players get drafted from college at 19 or 20 years, and they have been playing since they were kids. And some people are naturally gifted, meaning that genetics can come into play. However, we must take advantage of what WE have, and think about how we can maximize our potential.

Choice vs. Chore

When we think of doing something that we enjoy, it becomes our choice to do that thing. But when something is a chore, you think about getting done with that task as soon as possible and it is something that is not enjoyable. When we think about learning, we have to think about it as a choice and not as a chore. We should make learning a choice just as we choose to go to the beach or go to Walt Disney World. We want learning to be an enjoyable experience and not something that should be treated as a chore. If it is treated as a chore, then you will not be able to reach your goals in the long run.

Failures Don’t Count

Think about a time when you failed a test. Now look at yourself today. Does anyone remember the time you got a 40 on a test, or do people see you at where you are today? I can guarantee you that no one will remember what you got on a test that you did years ago, or what obstacles you had to face. They see you at where you are at today. That F you got on a test is not the end of the world for you. Learning is a journey, and it will involve all kinds of failures in order to reach that success. Failures help us grow.

Productivity Time

Are you an early bird, or a night owl? Only you will know what your most productive hours are in your day. For me personally, I work better in the mornings than I do at night, so I am an early morning riser. The motivation comes from doing everything during the day so that I can have the rest of the night to spend time with family, friends or even game. When you know the hours that you are most productive, use that time to get the most work done.

Skill Stacking

Skill stacking is a phenomenon where if you learn different skills and combine them together, you can be one-of-a-kind. For example, if you have really good programming skills, a strong business acumen and design skills, you can combine those skills together and build an amazing company. You have different skills that you use together in order to accomplish something.

These principles, and the others covered in Learning How to Learn, changed how I think about and approach learning, and I hope they will do the same for you!

What is Programming?

Laura Lindeman — Tue, 19 May 2020 14:27:00 +0000

by Rafay Syed

Programming is a way for us to give instructions to a computer. The code behind the computer runs everything that you do, from moving the cursor to watching videos to playing video games. It’s a neat way of telling the computer exactly what you want to do since computers will run the instructions you give them without questioning it (unless SkyNet takes over the world). But here’s the thing: computers don’t understand English, or any other human language. Computers speak in binary, meaning in 1’s and 0’s. Does that mean we have to speak to computers in 1’s and 0’s? Just imagine having to learn how to communicate in binary. It would be so hard for schools to teach and it would be tough for students to grasp.

This is why we have programming languages. There are two types of programming languages: high-level languages and low-level languages. High-level languages are languages such as Java, Python, JavaScript, and C#. These languages are closer to the English language and easy for humans to learn and understand. An example of a low-level language is Assembly, which is closer to machine code. If you’re a computer science major, you may have learned about the Assembly language in a Sparc Architecture class. It’s not a language that many employers ever ask for, nor will you ever have to use it, but it’s good to know about it.

Now you may be thinking, if computers speak in binary and we use a language closer to the English language such as Python, how will computers understand what we are trying to tell them? Let me ask you a question. When you try communicating with someone who speaks a different language, how do you overcome that communication gap? Do you use a dictionary, Google Translate, or a human translator? The concept of having a translator is the same with these high-level programming languages! You have a translator that communicates between what the human has typed in the code file and then have that file translated in a way for the computer to understand. The code file gets converted into a binary file known as the bytecode. There are two types of translators: interpreters and compilers. Interpreters go line-by-line, executing each line to the computer. Compilers differ from interpreters since they read the entire file and then translate it. They don’t go line by line and then translate. It’s like saying that a translator wants to know everything you’re going to say to someone, and another translator may prefer that you say one line, have the translator translate that line, and then you continue to say the next line and have the translator translate the next line.

Let’s use Python as an example for illustrating what happens underneath the hood when you run your Python program. When you run the file, it’s given to the interpreter called CPython which goes line-by-line and creates a bytecode file. The bytecode file is then run on the CPython virtual machine, and then you obtain the output from the program on your computer! I know this is a lot of information knowing what happens underneath the hood, and you will probably never be asked this type of question in an interview, but it is good to understand what’s happening when we run our programs.

You may be wondering what the CPython virtual machine is. It’s part of the translator package we install on our computers when we want to run Python programs. It comes with an interpreter written in C (CPython) and it comes with the CPython VM. Now Java runs its programs using a compiler and not an interpreter, which translates the whole file and then creates a bytecode file. The translator you get depends on the programming language.

If you’re new to programming you may be wondering why there are so many programming languages. Why don’t we have one language that can do everything rather than having so many different languages? That is not possible, since each language is used for different purposes. For example, when making video games, C++ is used with the Unreal Engine. With automation, machine learning, AI and data science, Python is used. We also have so many different devices that do so many different things, so it would not be possible to have one language that can encompass every device there is on this planet. Apple uses Swift, while Android uses Kotlin. When you are thinking about what language you want to use or learn, think about what you want to work on. Are you wanting to build an AI chat bot? Use Python. Are you wanting to build a game such as Flappy Bird on the iPhone? Use Swift. It all depends on what you want to work on. When you learn one language, it will become easier to learn the others since the principles are just about the same. Even when you do a coding interview, 9 times out of 10 you’ll be asked to solve a problem in any language that you would like to use, making it a more comfortable experience. Interviewers like to see if you are able to communicate your thought process effectively and explain the steps you are taking in solving a problem. You can always catch up on learning the language that the hiring team uses. But as long as you know your fundamentals, you will be a quick learner in other languages.

And that’s the world of programming! I know this is a lot of information, but it will definitely make sense as you think about it. Just know that programming is the basis of how everything works on your phone, your computer and even your video game consoles.

Digitally Engaged or Digitally Confused?

Laura Lindeman — Wed, 13 May 2020 16:51:34 +0000

by Gavin Austin
original post

A lot of trends and buzzwords circle around the tech-sphere. Agile, big data, and most recently, digital engagement is in vogue. If you’re not sure what digital engagement means, you’re not alone. Ask a few of your coworkers what it means, and you’ll probably get different definitions or conflicting descriptions. You might even hear an answer that includes something called digital transformation, too.

What does this all mean? Why should you care? Because if you’re confused about digital engagement — or your organization attempts digital engagement haphazardly — your business could suffer enormous losses and missed opportunities.

First, let’s define digital transformation — It’s the precursor to digital engagement. Digital transformation is simply the conversion of ink-on-paper records to digital formats. Most businesses began this conversion years ago when teams moved data and documents off of paper and onto computers, databases, disk drives, and eventually the cloud for safe storage. Since information was no longer lost on someone’s desk, and it was easily accessible across teams, changes started happening in the workplace.

Tasks once reserved for marketing, such as communicating new products or seasonal deals, quickly made their way into the realm of customer support: “While I help you reset your password, would you like to learn about a new promotion?” Silos between teams began to blur. Traditional functions of who delivers which experiences to customers came into question.
As the era of digital transformation progressed, consumers — you and me — began to have access to new mobile devices and communication platforms. Instead of complaining verbally to friends and family about bad customer experiences, we started to post our grievances to global audiences on Facebook, Twitter, and an infinite number of online forums or review websites. Businesses that didn’t know or acknowledge these posts lost customers. Businesses who continue to ignore these posts may go out of business.

Enter digital engagement. It’s a term that describes how companies engage with customers across all digital touchpoints while providing a consistent customer experience. Typically, a customer’s journey includes marketing, selling, and servicing in a way that lets them switch between multiple channels — email, Twitter, Facebook, and more — without interrupting a positive experience.

A digital customer journey for — let’s say shoes — might look something like this:

A new campaign to promote shoes on the web or on multiple social media channels.
Leads and opportunities from the campaign are captured and every stage of each deal is tracked and analyzed until the sale of the shoes is complete.
After the shoes are purchased, customers receive service reminders as texts on their mobile devices, review service agreements from an online community, and reach out for support through chatbots, web chat, social media channels, and more.

Ideally, each part on the journey — no matter where the customer is at — is optimized with automation and artificial intelligence (AI) to make sure that a positive experience is delivered consistently.

You may say, “But my business isn’t related to the digital realm. None of this stuff applies to me.” Fair point, but how many of your customers visit the digital realm? Probably most. With mobile phones, web browsers, and SMS text available to nearly everyone, everywhere, customers expect to reach businesses as easily as they reach their friends and families.

Salesforce research states that 78% of customers expect an effortless and consistent experience across multiple communication channels. Additionally, “more than two-thirds (69%) of customers expect a connected experience when they engage with a company.” This means that customers expect to reach your business on the channels of their choice, whether that’s on a mobile device using their favorite messaging app, on a website using web chat, or social media channels like Twitter or Facebook.

If you’re not engaging with customers in the digital realm, you’re not only providing poor experiences that could lead people towards your competitors, but you’re also missing opportunities. For example, as a writer on Salesforce’s Content and Communications Experience team (we’re the team that creates user interface text, feature callouts, videos, graphics, online help, release notes, Trailhead, and more), our social media presence has provided us with incredible feedback from customers. Tweets have pointed out where we need to update content. Posts on the Trailblazer Community have shown us where we can provide more useful in-app communications. This engagement is leading us to partner with Salesforce MVPs to write content together that benefits all of our customers. What a win!

Digital engagement isn’t as hard as it sounds. If you’re getting started on figuring out how to bring your organization into the digital realm, Salesforce has plenty of resources and features you can use.

To learn more, and begin the journey, check out the Digital Engagement module on Trailhead.

Salesforce Standup with Sarah Aerni

Laura Lindeman — Tue, 12 May 2020 19:19:23 +0000

Today's guest, Sarah Aerni, is a Senior Director of Data Science, leading a team of folks who build the automated machine learning behind Salesforce's Einstein product.

Sarah says that, most days, she feels like the "yay!" emoji in Slack. She is not much of a chef but has been enjoying takeout from a slew of Bay Area restaurants. And, she thinks she's reached the end of the Internet when it comes to TV shows; what would you recommend she watch next?!

Salesforce Standup with Sarah Aerni https://t.co/8oz5AZJXCd
— @SalesforceEng (@SalesforceEng) May 12, 2020

Clear and Effective Communication with Agile Software Development

Laura Lindeman — Mon, 23 Mar 2020 18:05:26 +0000

by Rafay Syed

I was first exposed to agile software development in my first job as Software Engineer. Agile, for those of you who may be unaware, is a methodology that many software engineers practice when they are building software. The people involved in building software aren’t just software engineers. Product managers and engineering managers are also involved in the software development process.

One thing that really stands out with agile is that it is adaptive to the changing requirements that the customers may have. One day, the customer may want a product to contain certain features, but then that customer’s requirements may change as engineers are developing the product, so engineers can go back and modify their codebase in order to be adaptive to the customer’s changing requirements.

My third day on the job, I was involved in something known as a standup, which I had never heard of. Everyone stood up, went to a corner of the office, and made a circle. This standup involved software engineers, a UX designer, a product manager and an engineering manager. Each person would spend about 30–60 seconds talking about what they worked on the day before, what they would work on during the day, and if they had any blockers. I was amazed at the level of communication that each team member was providing. And these stand-ups were known as ‘daily stand-ups’, meaning that they would happen every day and we would have them at 9:15 AM.

Stand-ups allow for effective communication amongst all team members and allow for transparency so that there are no holes or gaps in understanding across the team. They also allow others to jump in and help an engineer who may be struggling with completing a task. This is one key aspect I love about agile: it involves clear and effective communication.

Another concept I got exposed to was the idea of user stories, where each story is a task assigned to someone. To write a user story, you can follow these four steps:

Define your end user.
Specify what they want.
Describe the benefit.
Add acceptance criteria.

I learned that a user story explains exactly what the end user wants to see in a product. User stories are mainly written by the product manager, who gathers requirements and steers the product in the right direction. The product manager is also known to represent the “true voice of the customer.” This customer-centricity was another aspect of agile that amazed me.

I learned another term: sprint. In agile, a sprint is the amount of time that is allocated for completing certain user stories that are grouped together. Both of my jobs so far have had teams that worked in two-week sprints. This means we are given two weeks to complete any features that are assigned for that sprint. If an engineer does not complete a story assigned for that sprint, then that story gets placed in the next sprint.

A sprint involves multiple phases, including sprint planning, backlog grooming, and retrospectives. I will go over each of these.

In sprint planning, the product manager, engineering manager, UX designers, and software engineers come together to discuss the tasks for the new sprint. What I like about sprint planning is that everyone gets perspectives on each team member’s viewpoint about the stories that would be assigned for that particular sprint. It also gives everyone an idea on what tasks are prioritized by the Product Manager and what the goal of the sprint is.

In backlog grooming, the team reviews the progress of stories that are currently being worked on as well as prioritizing stories. This occurs a few days before a sprint ends, allowing for transparency and letting everyone on the team see the progress of each user story in that sprint and prioritizing tasks accordingly. The stories that are prioritized at the top are the stories that are ready to be delivered.

In a retrospective, or a retro, the team discusses what went well in the sprint and what could have been improved, adds action items to make those improvements, and gives kudos to people. This happens after the end of a sprint, and it is one of the most refreshing parts about agile. We each get an opportunity to celebrate our successes as well as seeing how we can improve in the next sprint.

My experience with agile has been amazing, and it can be a very beneficial, productive, and efficient approach to building great software.

WFH FTW: Staying Connected When You're Working Remotely

Laura Lindeman — Mon, 16 Mar 2020 14:44:19 +0000

by Kate Vazansky

Salesforce supports a lot of remote employees, and with our recent announcements around reducing the spread of coronavirus, there are a lot more people working from home full time. I’ve been a remote employee since 2012, both at Salesforce and elsewhere, so I worked with a few of my peers in engineering and product to put together some tips for success for anyone who finds themselves quarantined or unexpectedly away from their home office for awhile. Hope they help, and please comment here with any suggestions (or questions) of your own!

You’ll need to set up more meetings to have conversations with people.

It’s a fact: the level of effort is higher to talk to people, unless its on a real-time chat app. Do not stop having conversations. In fact, we’d encourage you to have more conversations!
For those “face to face” conversations: video calls count as face to face, because you get to see one another and the non-verbal cues. Telephones do not count as face to face but can be a lot more reliable, connection-wise.
Slack and other chat apps are your friends: create a room or channel for water-cooler/hallway talk and use it.
Virtual “happy hour” is a great thing. Make the time to talk with your coworkers just like you would in the kitchen - about weekends, etc. These can be ad-hoc or planned on a regular cadence, and you’re probably going to be across multiple time zones, so in our experiences, these are rarely booze-centric. You can have tea, coffee, cake, ice cream, salads (why salads, probably not salads, we were just trying to think of something healthy)... you get the idea.

Seeing faces matters! A lot!

Keep that video on whenever possible. Your voice is one of 100 ways you are communicating with your co-workers, and keeping your camera on increases your communication bandwidth. Frowns, head-tilt, squints, laughing, crying! It all counts, and it’s all important.
Put about 30-60 minutes of attention to the lighting for your work area and make sure your face can be seen on camera. Move lamps if needed.
If you do turn off your camera, tell people why — imagine coming into a meeting room full of people, but everyone had on masks that were their profile pictures. (Actually this would be a funny team Halloween theme...)
This is also an accessibility matter — you may have coworkers who need captions or read lips!

Say hello in the mornings, and “brb” when you’re out for a bit

Say good morning in your team’s (or watercooler) chat channel when you start in the morning.
Since people don’t know if you have have left your desk to go make lunch or are running a longer errand: let them know (via chat) when you will not be reachable.

Get some really comfortable headphones or earbuds.

You’re going to be using them a lot and the plastic earbuds tend to hurt after awhile.
Try to avoid, if possible, relying on your laptop’s mic and speaker. The echo tends to be higher and you are frequently harder to hear on the other side. The mic on your computer usually offers less filtering, so you’ll hear a lot more "life noise."

If your team is still in the office, send them this post, because once one person is remote, everyone has to adjust.

If half the team is co-located in the physical office, but the other half is working from their individual homes, the entire team should act as if there is no co-location when communicating; use chat apps for everything, even if the initial target of your message is sitting just to your left.
This prevents accidentally leaving folks out and maximizes awareness around seemingly innocuous but sometimes important pieces of information
When a majority of people are remote, allow for a couple of minutes of non-work-chatting when you are all in the same meeting. Social banter is important.
Ask your manager to help with promoting remote inclusion.

It can be really easy to get caught churning in your own head. Be aware of this, and actively check yourself.

This goes back to the “have more conversations” point. Without the office vibe and the shared space with interruptions, there’s nothing to check yourself against and it can be harder to break up a mood. So take care of yourself: it is easy to go many hours without a break. Set a timer to remind yourself to get up and walk around.
Related to that: figure out what works for you, your life, and your team. It might take a few iterations to nail it. For example:
- You might need a designated space where you can shut the door and walk away at 5 PM until you come back online at 9 AM next day.
- Or: You might need longer breaks throughout the day, and choose to pick your work back up in the evenings.
- Or: You might flip back and forth between both, because life is like that.
- Point being: despite what “experts” say, there’s no formula or “right” way to work remote. Give yourself the space to find what works for you.
Streams of big events, or a long series of meetings where you are just observing, can be especially draining and disconnecting since you’re removed from the activity. If your mood starts to tank, take a break and go do something you enjoy — you’ll be happier and more effective that way.
Remember that a significant routine change like this affects those you live with too, so be extra kind to yourself and others.
If you’re worried about being “forgotten” while working remotely, it doesn’t have to be that way! Apply these tips to continue building your personal brand and remember that, at least right now, we are all in this together as we work to flatten the curve of virus spread.

Any tips you’d like to share? Please comment here! And if you want to learn even more, check out the Virtual Collaboration module on Trailhead.