Can you intuit that these slides are about promise-land of virtual filesystems inspired by #FunctionalProgramming ? pic.twitter.com/AGiupUies9

— Jeff Lee (@RebootJeff) May 23, 2015

On May 21st, I traveled to Boulder for LambdaConf 2015, a functional programming (FP) conference. Overall, it wasn’t as beginner-friendly as I had hoped, but it gave me plenty of food for thought as I explore FP. Today, I’m going to summarize some key points and takeaways from the talks that really stuck with me. I didn’t understand everything I heard, but still learned a thing or two …I think.

Recaps

Keynote: “Ipecac for the Ouroboros” by Paul Phillips

Apparently, the Ouroboros (serpent eating its own tail) in this talk represents all programmers (and perhaps even all computer users) who are eating their own tails by accepting the current model for filesystems (files, folders, directories, etc). Phillips suggests that he has the cure (the ipecac).

What if computers used virtual filesystems? Imagine if filesystems were more like databases, and retrieving files would be like using expressions that define queries and which files to retrieve. You would not need to rely on knowing filepaths and file names. You wouldn’t end up with multiple copies of the same files/folders in various directories. You would rely on useful metadata to get your latest photos. You could even ask for “all the photos with person X” (via facial recognition).

“Selfish Purity: How Functional Programming Makes Every-Day Jobs Easier” by Daniel Spiewak

Spiewak claims that FP gurus suck at articulating to non-FP programmers about why FP rocks. According to him, FP’s strengths boil down to reasonability, testability, and concurrency.

As a beginner in the world of FP, I partially agree. For me, it’s easy to grasp why FP rocks in theory, but sometimes it’s hard to understand in practice because it can be so difficult to start writing FP code.

Instead of going on about abstract algebra, Spiewak says FP evangelists should emphasize reasonability, testability, and concurrency. For intro classes, FP teachers should focus less on manipulating data and more on how to do data-centric programming instead of behavior-centric programming.

Reasonability

FP emphasizes data over behavior, and it’s easier to reason about data than behavior (especially if the behavior can be different due to side-effects, implicit inputs, etc –in other words, impurity makes it difficult to reason about behavior).

Testability

Side-effects leads to difficult testability leads to devs hating testing leads to devs writing fewer/poorer tests leads to lower software quality. This plagues the software industry.

Using FP algebra leads to simpler logic and better testability. By writing a “real” interpreter that performs side-effects and a “fake” interpreter that inspects, testing becomes easy. Free monads enable this pattern. Free monads make it easy to write these 2 “interpreters”.

Concurrency

• sequential ~ flatMap or for-comprehensions ~ monads
• Parallel ~ zip ~ applicatives

Note: In case it isn’t obvious already, I had trouble comprehending this part of the Spiewak’s talk. My understanding is that the purity of FP lends itself to easily distributing computation of expressions and composing the results.

“Why I Like FP” by Adelbert Chang

Imperative programming requires you to maintain state in your head. At the very least, you have to remember values stored in all sorts of variables, maybe different state for each iteration of a loop, etc. With imperative programming, your brain uses a lot of energy on maintaining state (and types in an untyped language) when it should be focused on just solving the problem. This is really annoying if you love the expressions from physics/math where you simply derive solutions to problems.

Math has referential transparency (algebra is just lots of substitution), which is straightforward. FP brings referential transparency (and therefore, more algrebraic concepts) into programming.

“How I Learned Haskell in 5 Years” by Chris Allen

Or: Thoughts on teaching Haskell (and just “teaching” in general).

Allen is a professional Haskeller, but he also does a lot of teaching. He spent a lot of time introducing co-workers to the language, and he eventually created a free guide on Haskell. It was great to hear his perspective on education in the realm of coding.

• It took Allen 5 years to learn Haskell because he went through unproductive cycles: complete a tutorial, try a practical project, get frustrated, stop …repeat.
• When he first started teaching, he sucked at it. He emphasizes that his first audiences were test subjects, and novice teachers should be grateful to their first audiences.
• His Haskell book, Haskell Programming from first principles is for self-learners and doesn’t assume recent Computer Science education. It doesn’t even assume programming experience because going from something like JavaScript to Haskell will feel like starting from scratch anyway (yikes!).
• Handwaving over explanations is problematic. Allen warns that teachers should avoid giving definitions before explanations. That tactic runs counter to how humans learn via intuition and informal observations that eventually coalesce into formal explanations.
• I found a few particularly interesting blog posts by Allen:
  • The problem of learning functional programming
  • Meditations on learning Haskell

“Programming and Math” by Harold Carr

Boom: http://www4.di.uminho.pt/~jno/ps/pdbc_part.pdf

Further Impressions

FP in the real world

Functional programming used to be considered rather academic and unpractical, but nowadays, there are a lot of languages and corresponding communities that make FP friendlier and useful. Consequently, there are plenty of people using FP for “real” software.

FP languages

Judging from the conference, Scala, Clojure, and Haskell are the most popular functional programming languages. Haskell seems to have the fewest programmers, but the most momentum/interest. Not only is Haskell favored by the purists, but its static type system is lauded as being the near-panacea that programmers don’t realize they need until they learn it.

However, I saw enough Clojure code to walk away impressed by it. It seems far less intimidating than Haskell, but perhaps that’s largely due to my background in JavaScript (JS and Clojure are both dynamically typed). The funny thing is that there seemed to be a theme where Clojure developers end up finding enlightenment in Haskell thanks to its strict ways. Perhaps learning Clojure is the perfect stepping stone for learning Haskell? If you’re intrigued, check out:

• Clojure for the Brave and True, an online book
• ClojureBridge, organization providing workshops and a free online curriculum
• Nightmod, a Clojure-based game-making tool

In my first article on Communication For Engineers, I ranted about my disappointment surrounding engineering and communication skills. I ended that blog post with a list of communication-related topics that I promised to write about. Instead of addressing any of those topics (sorry!), this post will talk about how software engineers can improve their communication while coding collaboratively or while solving coding challenges for a job interview.

Warning: JavaScript is my specialty, so some of the advice below is JS-centric, and all code examples are written in JS.

I cooked up 7 steps for how to discuss code smoothly:

1. Draw the situation
2. Ask clarifying questions
3. Explain approach
4. Breadth-first coding
5. Refactor
6. Walkthrough
7. Testing

Notice that these steps don’t magically provide a complete guide to actually solving problems. For example, they don’t tell you which data structures to use. Instead, these steps show you how to communicate better as you solve a challenge. They help you talk with your interviewer or colleague about the problem space, your initial impressions, your ability to break down the problem into sub-problems, and your quality assurance process.

The 7 Steps Explained

1. Drawing the Problem

Admittedly, this step could be optional. Drawing is best for folks who work well with visuals. But even if you’re not an artist, you should still consider drawing a diagram or picture of the problem because visuals tend to be effective tools for communicating complex subjects and situations. For example, data structures are usually easier to talk about after you draw them out.

Furthermore, you might reveal certain questions through the act of drawing. At the very least, drawing stuff out can help an interviewer follow you. Going back to the data structures example: imagine you’re supposed to work with a binary tree. It’s easier to talk about it if you draw a tree and point to nodes rather than just saying, “First we will process the root node, then we will go to the left child and do blah blah blah. At that point, depending on the value, we might go down to the child’s child or we might…”

By the way, you don’t have to stick to drawing pictures. This step could be about writing down example data, example inputs, example outputs, example use cases; and then mapping them together by drawing arrows, circles, etc. Examples are great for communication, and they are also good for problem-solving in general. Try to think of examples that are really simple (to get a basic grasp of the problem), examples that are more realistic, and examples that are crazy (to reveal edge cases and potential validation concerns).

2. Asking Clarifying Questions

Do not follow any of your assumptions without asking a question first. It’s tempting to hear a challenge or puzzle and immediately get into solving it. But there are real-world concerns for real-world problems, and you should demonstrate your familiarity with such issues.

Also, you can save time by asking clarifying questions during an interview because interview challenges tend to be contrived. Do you have to account for crazy input values? Does the output need to be formatted in a certain way? If the puzzle involves numbers, do you have to account for negative values, decimals, etc? Are you expected to do input validation, error handling, or memory optimization?

3. Explaining Your Approach

At this point, you might have a solution in mind and you’re eager to get coding. Or you might just have a partial solution. Either way, take a moment to give a quick overview of the purpose of the code you’re about to write. Also, give a sense of what algorithms or concepts will be implemented as part of your approach to the problem at hand.

For example, “This looks like a problem we can solve with a recursive solution that traverses all nodes of the dataset.” In this example, “recursion” is the concept and traversal is the purpose.

4. Breadth-First Coding

When it comes time to actually write out some code (or pseudocode), write out as much as possible at a high-level before going into the low-level details. For example, if your solution requires looping over objects received from an AJAX request in order to parse some data, don’t dive into that AJAX request. That’s a low-level detail. Start from the high-level approach of “fetching data” and then immediately move to the next high-level step of “parsing data”. With this strategy, you cover the whole breadth of the solution before diving into any detail of the solution.

In other words, write modular code by using a breadth-first mindset. Everyone knows it’s a good idea to write several small functions rather than one giant function, so apply that approach to your communication too. When you explain how a computer works, you start the explanation at a high level (e.g., “hard drives store data, CPUs crunch data, …”) rather than starting at a low level (e.g., “the flow of electrons is controlled by gates known as transistors”).

// Challenge (aka Prompt) - Write a function that determines the average number of
// retweets for a given user after a given cut off date.

// Phase 0 - Psuedocode (optional)
function getRetweetAverage(username, cutOffDate) {
  /**
   * 1. Fetch tweets via Twiter API
   * 2. Filter tweets based on date
   * 3. Calculate avg count of retweets from filtered data
   * 4. Return a promise that resolves to the answer
  **/
}

// Phase 1 - Coding with declarative helper functions
function getRetweetAverage(username, cutOffDate) {
  return fetchTweets(username).then(function(tweets) {
    var recentTweets = filterTweetsByDate(tweets, cutOffDate);
    return calculateAverageRetweets(recentTweets);
  });
}

// Phase 2 - Implement low-level helper functions
function fetchTweets(username) {
  // Let's pretend we're using AngularJS's HTTP request service, which uses promises.
  var params = {
    screen_name: username,
    count: 200 // FYI this is the max allowed by Twitter's API
  };
  return $http.get('https://api.twitter.com/1.1/statuses/user_timeline.json', params);
}

function filterTweetsByDate(tweets, cutOffDate) {
  return tweets.filter(function(tweet) {
    // Convert tweet's String date into a JS Date object before comparing.
    var createdAt = new Date(tweet.created_at);
    return createdAt > cutOffDate;
  });
}

function calculateAverageRetweets(tweets) {
  var totalRetweets = tweets.reduce(function(sum, tweet) {
    return sum + tweet.retweet_count;
  }, 0);
  return totalRetweets / tweets.length;
}

In the example above, you should write code one “phase” at a time. Starting with psuedocode is optional, but it might be a good idea to at least verbalize it if you don’t plan on writing it. Then write the code in a declarative style as seen in “Phase 1”. Lastly, flesh out the functionality of your solution by writing the code that actually makes things work.

By the way, I’ve never actually used the Twitter API, so the example code might not follow best practices or might not take into account how it actually behaves. For instance, maybe the API accepts a parameter to do the date filtering for you.

5. Refactoring Your First Draft

Once you’ve reached the point where the code seems to solve the challenge at hand, it’s time to refactor. If you’re writing under pressure in an interview situation, it’s likely that you haven’t written the cleanest code. If you’re writing without any pressure, it’s still good to refactor your first draft into a more readable/maintainable variant. Here’s a list of tips for deciding what to refactor:

• Improve readability by fixing indentation, whitespace, names, etc.
  • Rename variables into semantic names. It’s tempting to use very short variable names during interviews because you feel pressure to finish quickly. Consider renaming them into more recognizable names to show your audience that you know how to write maintainable code that potential co-workers could easily read.
  • Replace loops with a map, filter, reduce, etc where possible.
  • Consider naming anonymous functions if they have potential to be re-used as a helper.
• Extract code into helper functions. It’s very common for interview candidates to inadvertently write long functions. Even if you tried to follow Breadth-First Coding in Step 4, you may have slipped.
• Double-check promises and look for opportunities to reduce boilerplate and anonymous functions.
  • Check return statements to ensure that your promises will resolve to the correct values (and that the segments of your promise chain will pass correct values).
  • Use promise library helpers such as all, spread, etc where possible.
• Add error-handling/logging for professional bonus points.
• Rewrite in another style (e.g., Functional Programming vs Object-Oriented Programming) for massive bonus points.

Admittedly, this Step 5 isn’t as directly related to communication as other steps. It’s mostly focused on improving your code. However, there is still a communiation-related opportunity here. As you are refactoring, verbalize your intentions. Discuss what you want to improve before you improve it. Explain the rationale behind the improvements. Mentions the pros and cons of your code without the improvements and with the improvements (i.e., before vs after).

6. Walking Through Your Answer

At this point, your code should be presentable. By following the previous steps, your audience should already have a solid, high-level understanding of your code. So now it’s time to give a detailed walkthrough.

Explain any nuances, use precise terminology, and expound on any interesting control flow or references (e.g., closures in JavaScript). You can also mention any implications regarding speed, memory, I/O, security, etc. But overall, your goal is to describe your code in detail.

7. Testing Your Answer

You might actually want to perform this step before step 6, but it depends on how you roll. After you’ve gotten to the point where you have a solution that seems to be good, take a minute to describe how you’d make sure it’s robust. When you normally write code on your own, you of course test it out by running it with various inputs or circumstances. Describe them; verbalize them.

For example, if you’re writing a function with some parameters, you’ll probably run the function with a bunch of different arguments with different values and maybe different datatypes.

• Numbers: negative values, 0, 1, odd vs even, really big numbers, decimals
• Strings: upper vs lower case, single character, numeric characters, punctuation and non-alphanumeric characters.
• Object Literals: check for weird keys (much like Strings)
• Collections & Data Structures: empty collections, only 1 item, several items, check for mutation side-effects, ascending order, descending order, random order, nested objects/arrays/other data structures.

Where Did These Steps Come From?

I came up with these 7 steps based on…

• advice from Gayle Laakmann McDowell
• advice from Hack Reactor instructors
• my experience interviewing for jobs
• my experience conducting a handful of mock interviews for Hack Reactor grads
• my experience conducting interviews where I work (10+ so far)

When I teach JavaScript workshops, I usually have teaching assistants who can help students complete classwork exercises. The TAs mostly focus on helping beginners debug their code rather than just giving solutions and walking through them.

Here’s the advice that I give TAs:

Dear Teaching Assistant

Remember that you should avoid giving away direct solutions. When students ask for your help, they will often not know exactly what puzzles them. They will often just ask, “Can you help me?” rather than asking something more precise such as, “Why doesn’t this function return the value I expect?”

Your role is to understand the particular problem that the student is facing. Try to find out what precise questions should be asked and relay them to the student. This might require vocalizing your step-by-step thought process for solving the problem, and finding the first step that confuses the student.

When debugging, try to debug the student’s code one step at a time. Explain those steps so the student can learn how to debug (e.g., where to put console.logs, which variables need to be checked, etc).

Never give the hungry student a cooked fish. Teach the student how to use a fishing pole, a gutting knife, a cooking fire, and Chrome DevTools.

Do everything you can to show a student how to get the solution. Showing a student the actual solution is the last resort. At that point, you should not only show the student the solution, but walk through it and ask the student questions to test their understanding. Oftentimes, asking a student “do you understand?” is not effective. You will get nods thanks to a superficial level of a understanding. That understanding must be tested by asking the student to walk through the code verbally, asking the student values of specific variables, and so on.

A few months ago, the JavaScript community had a rather negative reaction to an announcement about Angular v2.0. Quick aside: my boss lost faith in Google and jumped on the ReactJS bandwagon. On a recent episode of the Adventures in Angular podcast, the Angular core dev team tried to clear the air regarding the general approach for Angular 2.0 and the differences between Angular 1.3 and 2.0. The podcast is surprisingly well-done. There are 9 people included (1 of them is THE John Papa; 4 of them are Angular team members) and yet they never accidentally interrupt one another or talk over one another.

I’ve listed some interesting bits I gleaned:

Some Misunderstandings

• It sounds like there might actually be a migration path for 1.3 to 2.0. There is no path yet because 2.0 isn’t close enough to completion to judge. The idea of “no migration path” was a misunderstanding.
• It is not necessary to use AtScript for Angular 2.0 (and it is not necessary to use Angular 2.0 for AtScript).

Some Rationale

• They’re trying to re-make their routing module in a way that will be easier to use.
• Some things are disappearing for logical reasons:
  • $scope is disappearing because they realized “controller as” syntax is best, so they want to revamp that system completely to avoid common $scope confusion.
  • Code for directives will be totally different because Directive Definition Objects as they currently stand are ugly and kind of convoluted (e.g., most directives don’t need a linking function, they just need a controller function –kind of like how most views/templates should use controllerAs instead of $scope).
  • Angular’s module system will disappear because ECMAScript6 will have a native module system. By embracing the new ES6 system, it will make Angular 2.0 more compatible with future non-Angular modules (much like how all back-end JS embraces Node’s system).
• There are a few key motivations behind Angular 2.0’s design:
  • Mobile friendliness.
  • Fixing mistakes they’ve made when creating Angular 1.x (e.g., getting rid of $scope).
  • Simplicity and performance.
  • Embracing future tech like ES6 and web components.

Some Points of Emphasis

• The new syntax looks crazy, but the Angular team claims that it will be much harder to convert a non-Angular 1.3 app to 2.0 than to convert Angular 1.3 to 2.0 –which sounds like a no-brainer, but as you can imagine, they’re really trying to emphasize that you should not abandon 1.3 just because 2.0 looks so different now.
• They emphasized how Angular 2.0 is still in a state of flux, so it’s too early to make business decisions based on it.
• The Angular team claims they are making changes for practical reasons, not purely academic reasons. In other words, they have examined how current Angular apps are made, deployed, etc. They don’t just think about what would be cool, they do think about what would be truly helpful/useful.

My Takeaways

I know I sound like I’m defending the Angular team. To a certain extent, that’s true (I need to try some React.js one day to hopefully reduce my bias for Angular), but it really comes down to:

• They’re converting to ES6, which means it will probably be necessary to use a transpiler to convert core Angular 2.0 code to ES5 for older browsers.
  • Ideally, this won’t be a huge problem for evergreen (self-updating) browsers. Maybe they will support key ES6 features by the time Angular 2.0 becomes “mainstream” (in the same sense that Angular 1.3 is currently “mainstream”). Or maybe I’m dreaming :p.
• There were some huge misunderstandings when Angular 2.0 was announced (re: lack of migration path, role of AtScript, etc).
• It’s too early to really tell what Angular 2.0 will look like when it’s released.
• When Angular 2.0 does arrive, it may look syntactically different, but it will do many of the same, Angulary things (i.e., the Angular “flavor” of MVC, augmenting HTML markup, enabling powerful custom components, etc).

Newsflash! Angular 1.x is NOT Dead!

Angular 1.4 is coming in Spring 2015.

News of 1.4 landed after the podcast aired. It will bring the new router I mentioned earlier, a “first class” I18N system, slick-looking documentation (using Angular-Material), and other goodies –including some breaking changes. :D

Me teaching a JavaScript workshop for beginners

Last update on Nov 30, 2014 to add a great link to the “Compilations” section.

1. A couple of weeks ago, a friend asked me for advice on giving advice to beginners.
2. One week ago, I taught a class on JavaScript for beginners (or advanced beginners –as I like to say).
3. A few days ago, I recently found a Quora question about getting better at JS.

These three moments have had my brain wondering about how to point coding newbies in the right direction. After some Googling and recalling my own past, I’ve gathered some links that will hopefully help beginners and maybe even intermediate folks. However, I should warn you that I haven’t tried out all the various services for myself.

The Basics

This Imgur post lists 6 sites that provide tutorials for getting started in coding. I’ve personally used Code School and Codecademy. They’re great, but after awhile, you’ll want to explore other options. They are not sufficient by themselves.

Compilations

These sites gather tutorials and various resources into one place. Most of these also give some guidance or roadmap to help beginners prioritize what to learn:

• Programming, Motherf…: Categorized links for various languages.
• Bento: Links organized into manageable sections.
• What’s Next: Links grouped by topic and difficulty.
• The Odin Project: Open-source web dev curriculum.
• JavaScript The Right Way: Links covering the entire JS ecosystem (basics, patterns, testing, frameworks, news/podcasts/feeds).

The Fundamentals of JS

If you’re specifically trying to learn the quirks of JavaScript, then classes like the one I teach are perfect for you. If you’re not near San Francisco, you can try online classes taught by the one who helped me become a teacher (@BiancaGando).

But these aren’t free. Ya know what is free? This great gathering of words describing vital JS concepts: 16 JavaScript Concepts JavaScript Professionals Must Know Well

The Community

San Francisco is my neck of the woods. If you’re lucky enough to be around here, then you should take advantage of the stellar community. There are lots of free meetups/events that can help you learn. If you’re not in the area, check Meetup.com for groups that provide similar events.

• Tinderbox: They often host “hack nights”, which might sound intimidating, but they’re very open-ended so you could show up and just ask for help learning a particular subject.
• SF Rails: Much like Tinderbox, the SF Rails group hosts open-ended “protonight” events. The group might focus on Ruby on Rails, but you’re likely to find people who can help with any beginner or intermediate level coding topic.

If you’re female, you might want to search for organizations that provide free support for women. Some examples:

• Women Who Code
• Girl Develop It
• Railsbridge
• Aysegul Office Hours

Back in the day, I used a free, online curriculum created by Railsbridge to learn some web dev skills.

A Hack Reactor alum recently launched a free service called Hackvard. It helps people quickly find nearby programmers who want to meet up. After a few weeks (or days?), it was renamed to Codaround. One of the co-founders contacted me and mentioned that Codaround might be changed to focus on helping match mentors/teachers with students/beginners. I don’t know any details, but it’s worth keeping an eye on this.

Games

Want to play while you program? Here are some sites that turn learning to code into a game:

• CheckIO: When I tried them out, I wasn’t impressed by their attempt to cover coding challenges in a layer of gamification. A CheckIO employee reached out to me and told me things have changed a lot. I haven’t verified his claims, but their user base was pretty large last time I checked, and their blog is very active, so they’re alive and kicking.
• Code Combat: I played with this a couple months ago. It was fun, but a tad buggy. I like the idea of writing code to control your character.
• Screeps: This looks quite promising. You write code to control small armies.

What else?

Let me know in the comments (or via Twitter) if you know of any other solid resources that help people learn JavaScript and other programming skills.

Last updated: Sep 22nd, 2014 at 12:21PM PDT. I added some info about using CSP with AngularJS.

Last Thursday, I published a blog post in which I summarized the main attack techniques (XSS, CSRF, and MITM) used by baddies to screw with the web. That post also covered two header-based solutions available to help you defend your site: CSP and HSTS. To supplement all that info, I am providing a bunch of articles, references, videos, and tools to help you learn more and take advantage of CSP and HSTS.

Content Security Policy (CSP)

Browser Support

Cross-browser support for CSP is pretty good. The latest versions of IE require the CSP header to use a special prefix (much like vendor prefixes for certain CSS features). Older crap like IE9 and below have no CSP support.

AngularJS + CSP

Sadly, CSP reduces Angular’s performance because the framework does some optimizations that run afowl of CSP. I imagine that the performance loss shouldn’t be a problem unless you have a ton of Angular expressions on the page at once (e.g., you use ng-repeat to generate hundreds of expressions).

Despite these concerns, CSP is highly recommended by the AngularJS FAQ page. For more info on how to use CSP with AngularJS, check out the docs for the ngCSP directive.

Further Reading/References

• HTML5 Rocks - Intro to CSP
• MDN - CSP Topics
• CSP Cheatsheet
• Yelp Engineering Blog - CSP at Scale

Awesome Presentation on CSP

HTTP Strict Transport Security (HSTS)

Browser Support

Most browsers get a passing grade when it comes to HSTS support –except for…

Internet Explorer doesn’t support HSTS—which means that there’s basically no such thing as a secure website in IE

Further Reading/References

• MDN - HSTS Overview
• EFF - HSTS is a must
• Leviathan - Caveat for using HSTS with wildcard SSL certificates

Quick Video Summary of MITM and HSTS

Note: The video above provides outdated browser support info. Updated info can be found here: CanIUse.com.

Bonus: Security Toolkit for Express Apps

Lusca

Do you use Node.js? Does your Node.js app use Express? Want some middleware to help secure that app? Perhaps you should consider using Lusca, a free module created by Paypal to quickly add and configure various security features such as CSP and HSTS. I haven’t personally tried it yet, but I plan to do so soon. Their README file makes Lusca look very easy for devs to use.

You can pick and choose which security features you want to enable. For example, if you’re already using JSON Web Tokens, then you may not want to use Lusca’s CSRF method while you take advantage of Lusca’s legacy browser XSS protection.

By the way, don’t get confused: Paypal uses their own open-source, Express-based framework called KrakenJS, but Lusca works with Kraken apps and Express apps.

Presentation on Securing SPAs and Node.js Apps (by PayPal Engineer)