Mentor with EE

A place to keep notes and examples!

see Useful Links:

Reading List:

The essentials, in order:

  • [ ] Newbie friendly: Make a Star Wars Game with Hour of Code (free website)
  • [ ] Newbie friendly: “JavaScript for Cats”, Max Ogden (free website)
  • [-] Newbie friendly: FreeCodeCamp’s 10-hour Basic JavaScript track You can come back to FCC for more practice while you explore the rest of these resources. I recommend that you dedicate time to study other resources and do some fresh FCC exercises every day. There are hundreds of hours of exercises, in total, covering a lot more than just JavaScript.
  • [ ] “Eloquent JavaScript: Second Edition”, Marijn Haverbeke (book with free online edition)
  • [√] “The Two Pillars of JavaScript Part 1” on Prototypal OO, Eric Elliott (article, free)
  • [√] “The Two Pillars of JavaScript Part 2” on Functional Programming (article, free)
  • [√] Introduction to Functional Programming Webcast Recording
  • [-] “Learn JavaScript with Eric Elliott”, disclaimer: I’m Eric Elliott (online courses, includes detailed screencasts on ES6, React, TDD, and more…)
  • [ ] “Programming JavaScript Applications”, Eric Elliott (book, free online, print & ebooks available)
  • [ ] “JavaScript: The Definitive Guide”, David Flanagan
  • [ ] “Essential JavaScript Links” Other reading:
  • [ ] “Design Patterns” book by the Gang of Four: “Program to an interface, not an implementation,” and “favor object composition over class inheritance.
  • [ ] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Back To Top

Mentoring with EE:

Back To Top

Blog:

https://medium.com/@_ericelliott/latest
jQuery('.streamItem-cardInner.streamItem-cardInner--postPreview').map((i,v)=>{
  console.log(v.innerText); return v
 })

Back To Top

Inside the Dev Team Death Spiral

Oct 10, 2015 Not long ago, I set out to write an article about how to interview JavaScript developers. As I dug…

Back To Top

A Simple Challenge to Classical Inheritance Fans by Eric Elliott

Oct 7, 2015 “When there is freedom from…

Back To Top

10 Interview Questions Every JavaScript Developer Should Know

Oct 2, 2015

AKA: The Keys to JavaScript Mastery

  1. Can you name two programming paradigms important for JavaScript app developers?

JavaScript is a multi-paradigm language, supporting imperative/procedural programming along with OOP (Object-Oriented Programming) and functional programming. JavaScript supports OOP with prototypal inheritance.

Good to hear:

  • Prototypal inheritance (also: prototypes, OLOO).
  • Functional programming (also: closures, first class functions, lambdas). Red flags:
  • No clue what a paradigm is, no mention of prototypal oo or functional programming. Learn More:
  • The Two Pillars of JavaScript Part 1 — Prototypal OO.
  • The Two Pillars of JavaScript Part 2 — Functional Programming.
  1. What is functional programming?

  2. Functional programming produces programs by composing mathematical functions and avoids shared state & mutable data. Lisp (specified in 1958) was among the first languages to support functional programming, and was heavily inspired by lambda calculus. Lisp and many Lisp family languages are still in common use today.

  3. Functional programming is an essential concept in JavaScript (one of the two pillars of JavaScript). Several common functional utilities were added to JavaScript in ES5.

Good to hear:

  • Pure functions / function purity.
  • Avoid side-effects.
  • Simple function composition.
  • Examples of functional languages: Lisp, ML, Haskell, Erlang, Clojure, Elm, F Sharp, OCaml, etc…
  • Mention of features that support FP: first-class functions, higher order functions, functions as arguments/values. Red flags:
  • No mention of pure functions / avoiding side-effects.
  • Unable to provide examples of functional programming languages.
  • Unable to identify the features of JavaScript that enable FP. Learn More:
  • The Two Pillars of JavaScript Part 2.
  • The Dao of Immutability.
  • Professor Frisby’s Mostly Adequate Guide to Functional Programming.
  • The Haskell School of Music.

  • What is the difference between classical inheritance and prototypal inheritance?

  • Class Inheritance: instances inherit from classes (like a blueprint — a description of the class), and create sub-class relationships: hierarchical class taxonomies. Instances are typically instantiated via constructor functions with the new keyword. Class inheritance may or may not use the class keyword from ES6.

  • Prototypal Inheritance: instances inherit directly from other objects. Instances are typically instantiated via factory functions or Object.create(). Instances may be composed from many different objects, allowing for easy selective inheritance. In JavaScript, prototypal inheritance is simpler & more flexible than class inheritance.

Good to hear:

  • Classes: create tight coupling or hierarchies/taxonomies.
  • Prototypes: mentions of concatenative inheritance, prototype delegation, functional inheritance, object composition. Red Flags:
  • No preference for prototypal inheritance & composition over class inheritance. Learn More:
  • The Two Pillars of JavaScript Part 1 — Prototypal OO.
  • Common Misconceptions About Inheritance in JavaScript.
  1. What are the pros and cons of functional programming vs object-oriented programming?

  2. OOP Pros: It’s easy to understand the basic concept of objects and easy to interpret the meaning of method calls. OOP tends to use an imperative style rather than a declarative style, which reads like a straight-forward set of instructions for the computer to follow.

  3. OOP Cons: OOP Typically depends on shared state. Objects and behaviors are typically tacked together on the same entity, which may be accessed at random by any number of functions with non-deterministic order, which may lead to undesirable behavior such as race conditions.

  4. FP Pros: Using the functional paradigm, programmers avoid any shared state or side-effects, which eliminates bugs caused by multiple functions competing for the same resources. With features such as the availability of point-free style (aka tacit programming), functions tend to be radically simplified and easily recomposed for more generally reusable code compared to OOP.

  5. FP also tends to favor declarative and denotational styles, which do not spell out step-by-step instructions for operations, but instead concentrate on what to do, letting the underlying functions take care of the how. This leaves tremendous latitude for refactoring and performance optimization, even allowing you to replace entire algorithms with more efficient ones with very little code change. (e.g., memoize, or use lazy evaluation in place of eager evaluation.)

  6. Computation that makes use of pure functions is also easy to scale across multiple processors, or across distributed computing clusters without fear of threading resource conflicts, race conditions, etc…

  7. FP Cons: Over exploitation of FP features such as point-free style and large compositions can potentially reduce readability because the resulting code is often more abstractly specified, more terse, and less concrete.

  8. More people are familiar with OO and imperative programming than functional programming, so even common idioms in functional programming can be confusing to new team members.

  9. FP has a much steeper learning curve than OOP because the broad popularity of OOP has allowed the language and learning materials of OOP to become more conversational, whereas the language of FP tends to be much more academic and formal. FP concepts are frequently written about using idioms and notations from lambda calculus, algebras, and category theory, all of which requires a prior knowledge foundation in those domains to be understood.

Good to hear:

  • Mentions of trouble with shared state, different things competing for the same resources, etc…
  • Awareness of FP’s capability to radically simplify many applications.
  • Awareness of the differences in learning curves.
  • Articulation of side-effects and how they impact program maintainability.
  • Awareness that a highly functional codebase can have a steep learning curve.
  • Awareness that a highly OOP codebase can be extremely resistant to change and very brittle compared to an equivalent FP codebase.
  • Awareness that immutability gives rise to an extremely accessible and malleable program state history, allowing for the easy addition of features like infinite undo/redo, rewind/replay, time-travel debugging, and so on. Immutability can be achieved in either paradigm, but a proliferation of shared stateful objects complicates the implementation in OOP.

Red flags:

  • Unable to list disadvantages of one style or another — Anybody experienced with either style should have bumped up against some of the limitations. Learn More:
  • The Two Pillars of JavaScript Part 1 — Prototypal OO.
  • The Two Pillars of JavaScript Part 2 — Functional Programming.
  1. When is classical inheritance an appropriate choice?

  2. This is a trick question. The answer is never. I’ve been issuing this challenge for years, and the only answers I’ve ever heard fall into one of several common misconceptions. More frequently, the challenge is met with silence.

“If a feature is sometimes useful and sometimes dangerous and if there is a better option then always use the better option.” ~ Douglas Crockford

Good to hear:

  • Rarely, almost never, or never.
  • “Favor object composition over class inheritance.” Red flags:
  • Any other response.
  • “React Components” — no, the pitfalls of class inheritance don’t change just because a new framework comes along and embraces the class keyword. Contrary to popular awareness, you don’t need to use class to use React. This answer reveals a misunderstanding of both class and React.

Learn More:

  • The Two Pillars of JavaScript Part 1 — Prototypal OO.
  • JS Objects — Inherited a Mess.
  1. When is prototypal inheritance an appropriate choice?

  2. There is more than one type of prototypal inheritance:

  3. Delegation (i.e., the prototype chain).
  4. Concatenative (i.e. mixins, Object.assign()).
  5. Functional (Not to be confused with functional programming. A function used to create a closure for private state/encapsulation).
  6. Each type of prototypal inheritance has its own set of use-cases, but all of them are equally useful in their ability to enable composition, which creates has-a or uses-a or can-do relationships as opposed to the is-a relationship created with class inheritance.

Good to hear:

  • In situations where modules or functional programming don’t provide an obvious solution.
  • When you need to compose objects from multiple sources.
  • Any time you need inheritance. Red flags:
  • No knowledge of when to use prototypes.
  • No awareness of mixins or Object.assign(). Learn More:
  • “Programming JavaScript Applications”: Prototypes section.
  1. What does “favor object composition over class inheritance” mean?

  2. This is a quote from “Design Patterns: Elements of Reusable Object-Oriented Software”. It means that code reuse should be achieved by assembling smaller units of functionality into new objects instead of inheriting from classes and creating object taxonomies.

  3. In other words, use can-do, has-a, or uses-a relationships instead of is-a relationships.

Good to hear:

  • Avoid class hierarchies.
  • Avoid brittle base class problem.
  • Avoid tight coupling.
  • Avoid rigid taxonomy (forced is-a relationships that are eventually wrong for new use cases).
  • Avoid the gorilla banana problem (“what you wanted was a banana, what you got was a gorilla holding the banana, and the entire jungle”).
  • Make code more flexible. Red Flags:
  • Fail to mention any of the problems above.
  • Fail to articulate the difference between composition and class inheritance, or the advantages of composition. Learn More:
  1. What are two-way data binding and one-way data flow, and how are they different?

  2. Two way data binding means that UI fields are bound to model data dynamically such that when a UI field changes, the model data changes with it and vice-versa.

  3. One way data flow means that the model is the single source of truth. Changes in the UI trigger messages that signal user intent to the model (or “store” in React). Only the model has the access to change the app’s state. The effect is that data always flows in a single direction, which makes it easier to understand.
  4. One way data flows are deterministic, whereas two-way binding can cause side-effects which are harder to follow and understand.

Good to hear:

  • React is the new canonical example of one-way data flow, so mentions of React are a good signal. Cycle.js is another popular implementation of uni-directional data flow.
  • Angular is a popular framework which uses two-way binding.

Red flags:

  • No understanding of what either one means. Unable to articulate the difference.

Learn more:

  1. What are the pros and cons of monolithic vs microservice architectures?

  2. A monolithic architecture means that your app is written as one cohesive unit of code whose components are designed to work together, sharing the same memory space and resources.

  3. A microservice architecture means that your app is made up of lots of smaller, independent applications capable of running in their own memory space and scaling independently from each other across potentially many separate machines.

  4. Monolithic Pros: The major advantage of the monolithic architecture is that most apps typically have a large number of cross-cutting concerns, such as logging, rate limiting, and security features such audit trails and DOS protection.

  5. When everything is running through the same app, it’s easy to hook up components to those cross-cutting concerns.

  6. There can also be performance advantages, since shared-memory access is faster than inter-process communication (IPC).

  7. Monolithic cons: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.

  8. Monolithic architectures are also much harder to understand, because there may be dependencies, side-effects, and magic which are not obvious when you’re looking at a particular service or controller.

  9. Microservice pros: Microservice architectures are typically better organized, since each microservice has a very specific job, and is not concerned with the jobs of other components. Decoupled services are also easier to recompose and reconfigure to serve the purposes of different apps (for example, serving both the web clients and public API).

  10. They can also have performance advantages depending on how they’re organized because it’s possible to isolate hot services and scale them independent of the rest of the app.

  11. Microservice cons: As you’re building a new microservice architecture, you’re likely to discover lots of cross-cutting concerns that you did not anticipate at design time. A monolithic app could establish shared magic helpers or middleware to handle such cross-cutting concerns without much effort.

  12. In a microservice architecture, you’ll either need to incur the overhead of separate modules for each cross-cutting concern, or encapsulate cross-cutting concerns in another service layer that all traffic gets routed through.

  13. Eventually, even monolthic architectures tend to route traffic through an outer service layer for cross-cutting concerns, but with a monolithic architecture, it’s possible to delay the cost of that work until the project is much more mature.

  14. Microservices are frequently deployed on their own virtual machines or containers, causing a proliferation of VM wrangling work. These tasks are frequently automated with container fleet management tools.

Good to hear:

  • Positive attitudes toward microservices, despite the higher initial cost vs monolthic apps. Aware that microservices tend to perform and scale better in the long run.
  • Practical about microservices vs monolithic apps. Structure the app so that services are independent from each other at the code level, but easy to bundle together as a monolithic app in the beginning. Microservice overhead costs can be delayed until it becomes more practical to pay the price.

Red flags:

  • Unaware of the differences between monolithic and microservice architectures.
  • Unaware or impractical about the additional overhead of microservices.
  • Unaware of the additional performance overhead caused by IPC and network communication for microservices.
  • Too negative about the drawbacks of microservices. Unable to articulate ways in which to decouple monolithic apps such that they’re easy to split into microservices when the time comes.
  • Underestimates the advantage of independently scalable microservices.
  1. What is asynchronous programming, and why is it important in JavaScript?

  2. Synchronous programming means that, barring conditionals and function calls, code is executed sequentially from top-to-bottom, blocking on long-running tasks such as network requests and disk I/O.

  3. Asynchronous programming means that the engine runs in an event loop. When a blocking operation is needed, the request is started, and the code keeps running without blocking for the result. When the response is ready, an interrupt is fired, which causes an event handler to be run, where the control flow continues. In this way, a single program thread can handle many concurrent operations.

  4. User interfaces are asynchronous by nature, and spend most of their time waiting for user input to interrupt the event loop and trigger event handlers.

  5. Node is asynchronous by default, meaning that the server works in much the same way, waiting in a loop for a network request, and accepting more incoming requests while the first one is being handled.

  6. This is important in JavaScript, because it is a very natural fit for user interface code, and very beneficial to performance on the server.

Good to hear:

  • An understanding of what blocking means, and the performance implications.
  • An understanding of event handling, and why its important for UI code.

Red flags:

  • Unfamiliar with the terms asynchronous or synchronous.
  • Unable to articulate performance implications or the relationship between asynchronous code and UI code.

Learn more:

Back To Top

Every Developer Needs a Code Portfolio

Sep 24, 2015

If you want to stand out, you need some publicly visible code.

Back To Top

Introducing the Stamp Specification

Sep 22, 2015

Move Over, class: Composable Factory Functions Are Here

Back To Top

How to Make Your App 10 Times Better

Sep 11, 2015 How to Make Your App 10 Times Better

Back To Top

5 Questions Every Unit Test Must Answer

Aug 29, 2015 How to Write Better Tests

Video: Watch the webcast recording, TDD in ES6 & React

Back To Top

How to Build a High Velocity Development Team

Jul 27, 2015

Be the Quantum Leap

Everything is awesome!!!!

READ THIS!

Language Matters

Normally I tell managers to hire great developers and give them broad freedom to implement things in the best way they know how. I have two exceptions to that rule. Language choice is one of them.

  • JavaScript is the standard language of the web platform, and your app should be written in JavaScript on both the client and the server side. Why? JavaScript is the most popular programming language on the planet*, and the easiest to hire for.
  • There are more working open-source solutions in JavaScript than there are in any other language. Your team will have to write less code from scratch.
  • JavaScript is the only language that can run universal code natively across the entire web platform stack, including clients, servers, and mobile.

Back To Top

Get Ready for the Future

Jul 24, 2015

A high-tech video time capsule from my future self

AWESOME VIDEOS!!!

Back To Top

Curry or Partial Application

Jul 20, 2015

The Difference Between Partial Application and Curry

see video: Practical Functional Programming

Back To Top

Why I use Tape Instead of Mocha and So Should You

Jul 12, 2015

"If you get your kicks burning money, use Mocha, Jasmine, Jest, etc… But if you value your time, keep reading."

Back To Top

Why We Need WebAssembly An Interview with Brendan Eich

Jun 27, 2015

Brendan Eich & Eric Elliott Discuss…

Back To Top

JavaScript Scene Tech Survey Results

Jun 21, 2015

ES6, Node, React, Angular…

Back To Top

What is WebAssembly The Dawn of a New Era

Jun 18, 2015

Pedalboardjs

Why the future of the web platform looks brighter than ever.

Back To Top

Babys First Reaction

May 27, 2015 A “Hello, World” Example for React Getting Started With React

Back To Top

JSX Looks Like An Abomination

May 20, 2015 But it’s Good for You

Back To Top

Why Hiring is So Hard in Tech

May 13, 2015

Talent Shortage

Back To Top

Assessing Employee Performance

May 8, 2015

You’re Doing it Rong

Assessing Employee Performance

Back To Top

How to Use ES6 for Universal JavaScript Apps

May 8, 2015

ES6 is final. It’s time to start using it for production… How to Use ES6 for Universal JavaScript Apps

boilerplate

Back To Top

Common Misconceptions About Inheritance in JavaScript

Apr 17, 2015

WAT? [wat] — interjection: A sound a programmer makes when…

TL;DR:

  • A class is a blueprint.
  • A prototype is an object instance.

Common Misconceptions About Inheritance in JavaScript

Back To Top

The Compassion Challenge

Apr 10, 2015

Why Your Worst Pain is Your Biggest Opportunity

Back To Top

The Dao of Immutability

Apr 9, 2015

The Way of the Functional Programmer

see: Introduction to Functional Programming Webcast Recording

Back To Top

How to Fix the ES6 class keyword

Mar 3, 2015 Make class inheritance compositional similar to the way stamps are…

"TL;DR Because of associated dangers with them (which have caused a lot of real damage to a lot of real projects) we need the ability to disallow new, extends, super, & instanceof in our lint rules. ES6 class won’t let us disallow new without throwing errors."

Back To Top

The Cure for Homelessness

Feb 8, 2015 How Tech can Bridge the Income Gap

Back To Top

Programming Literacy

Jan 23, 2015 Why Every Kid Should Learn to Code

Back To Top

JavaScript Training Sucks

Dec 29, 2014

"99 out of 100 JS developers lack the skills they need to fill hundreds of…"

"npm is the largest programming language package repository in the world."

"You’re paying people to slow the rest of the team down. "

Back To Top

The Two Pillars of JavaScript Pt 2

(Functional Programming) Dec 12, 2014

How to Stop Micromanaging Everything

"JavaScript is one of the most important programming languages of all time, not simply because of its popularity, but because it popularized two features which are extremely important for the evolution of programming: Prototypal Inheritance (objects without classes, and prototype delegation, aka OLOO — Objects Linking to Other Objects), and Functional Programming (enabled by lambdas with closure)"

"The only way we’ll be able to keep up with the exponentially increasing complexity will be to decrease the complexity of understanding programs. To maintain the goliath apps of tomorrow, we must learn to build more expressive code. We must learn to write programs that are easier to reason about, debug, create, analyze, and understand.

'Procedural programming and OOP are not going to get us where we need to go by themselves.'"

"The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing — is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil — objects are merely a poor man’s closures.”

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened. ~ Anton van Straaten"

Back To Top

The Two Pillars of JavaScript

Oct 21, 2014

Part 1: How to Escape the 7th Circle of Hell

  • Prototypal Inheritance (objects without classes, and prototype delegation, aka OLOO — Objects Linking to Other Objects), and
  • Functional Programming (enabled by lambdas with closure) "... because JavaScript is pretty good at letting you code poorly if you don’t bother to learn it properly. This is actually a feature, because it makes it really easy to pick up JavaScript and start doing useful things with it, but that phase of your development as a JavaScript programmer should last no more than a year. If you haven’t yet, it’s time to level up."

"...Classical deep inheritance trees always bothered me, especially in the context of web development where business needs are often a moving target."

"Other good alternatives include making better use of JavaScript modules as an alternative to inheritance (I recommend npm and ES6 modules with Browserify or WebPack), or simply cloning objects by copying properties from a source object to a new object (e.g. Object.assign(), $.extend(), _.extend(), etc…)."

"You never need classes in JavaScript, and I have never seen a situation where class is a better approach than the alternatives."

"Another common argument that programmers use is that it should be up to them how they express themselves, as if code style rises to the level of art or fashion. This argument is a purely emotional and irrational: Your code isn’t the product of your self expression any more than a painter’s paintbrush is the product of their self expression. Code is the tool. The program is the product."

Back To Top

Fighting Poverty in Schools

Sep 28, 2014

How we act today will make or break our future

"Even if you can’t imagine right now that your kid might need to know how to program, I have some information you might want to pay attention to:

Researchers believe that in just 2 decades about 45% of today’s jobs will be replaced by code or robots.* Being deeply entrenched in Silicon Valley startup culture and knowing the technology that’s right around the corner, I believe they’re underestimating.

~ this is not science fiction ~"

"At several of my recent jobs, I’ve been tasked to hire developers who are ready to start contributing productively to applications that serve millions of monthly users. In case you’ve never tried to do this before, it’s very hard. "

Back To Top

Learn JavaScript

Aug 3, 2014

"The fact is, most JavaScript training sucks."

Back To Top

Why JavaScript?

9 Essential Resources:

The essentials, in order:

Back To Top

Garbage In Garbage Out

Jul 21, 2014

Elliott’s Rule of Social Media Curate the things you consume as carefully as you craft what you produce. ~ee

Back To Top

If Your Head Isnt In the Clouds Chances Are Youre Not Soaring

Eric Elliott in The Backer Army

Jul 16, 2014

"Don’t make my mistake. Think of the seven people you love most in the world. For the next seven days, start each morning with a short letter. Reach out to one of your most cherished loved ones. Share this article and add a tale or two about the trouble you got up to when you were a little less wise and a little less aware of what you couldn’t (or shouldn’t) do. Tell them how much you love them. Believe me, it would mean the world to them."

Back To Top

Fighting Poverty with Code

Jul 8, 2014

"Did you know it costs more money to let somebody sleep on the street than it costs to give them homes for free?"

"Because JavaScript is the only programming language supported by every modern browser, the entire web is dependent on it, making it the most widely used programming language in the world — and it’s still growing faster than any other programming language. There’s just one problem: There aren’t enough JavaScript developers to keep up with demand."

"Demand for software developers is so high that most of the top companies have an always hiring policy for developers; they hire as quickly as they can find qualified candidates, and when that’s not fast enough, they actively recruit candidates from other countries or outsource work to India."

"If you want to help, you can purchase a course bundle (you can give them as gifts or use them yourself. If you’re not sure who to give it to, we can refer you to a school or training program). Another great way to help is to share this article with your friends."

Back To Top

Book:

Back To Top

Videos:

Learn JavaScript with Eric Elliott

Classes vs Prototypes

Introduction to Functional Programming Webcast

Introduction to Functional Programming Webcast Recording

Practical Functional Programming

Back To Top

results matching ""

    No results matching ""