Mike McNeil mikermcneil

name	about	title	labels	assignees
🎟 Story	Specify an iterative change to the Fleet product. (e.g. "As a user, I want to sign in with SSO.")		story,:product

A user story is estimated to fit within 1 sprint, is QA'd, and drives independent business value.

You know, if you simplify something, you don't have to work as hard, learn as much, or bother other people with as much complexity.

That's how I like to write code anyway. More conventions, fewer ways to do things, less cognitive load.

More creative energy to make good decisions. More brain space to move quickly.

Here's what I'd say if I was teaching a younger version of myself advanced JavaScript:

data types
made a commitment not to use classes, new, or constructors at all (plenty of other ways to look clever)

Client-side validation is always less work and easier to maintain because it requires one less integration point between backend and frontend, and no spinner, so no timing issues. Always use client-side validation any time you can. Occasionally it seems easier to check things on the server, but without exception, I have always found this impression to be wrong, when looked back at in retrospect. There are some times you need server-side validation, such as for uniqueness constraint checks in the database, or any kind of database-based check. (Because the browser doesn't have access to the entire database, nor should it.)

Principles for delivering professional services

mikermcneil, 2022-08-10

A few principles for delivering a great customer experience and successfully completing professional services engagements. The following are lessons that I had to learn the hard way. Hopefully, they save you some trouble!

Daily communication with the customer (like a standup during the engagement)
Timebox the engagement (ok to scope features, but also set a timeframe.)
Make it explicit who is working on it and how many hours they'll be working per week.
Do frequent demos during the project (weekly or biweekly). If the customer doesn't show, demo internally anyways. Fix bugs that come up in the demos before moving on. Fri morning or Thu afternoon demos work best, to leave time for bug fixes before the week (and sometimes project timeframe) ends.

Question

So I guess in Rails and Laravel world queues and background jobs are really all front and center but I don't hear that mentioned even moderately in Node. What will be the equivalent?

Answer

Mike McNeil sent the following messages at 8:21 PM

The equivalent is like what's in the sendTemplateEmail() helper in default new sails apps, at the bottom

I know of a couple of valid reasons to use queues in Node.js:

Values

The Fleet values have moved to https://fleetdm.com/handbook/company#values

(in fleetdm/fleet#3666)

Monitoring your Sails app for errors

Monitor your Sails app for missing awaits, 500 errors, failed script runs, and more!

Here's how to monitor a Sails app for errors using Papertrail, a logging tool that works with anything but is particularly easy to use as a Heroku add-on. This search string uses Papertrail's search syntax, but the log output it's searching for is not Heroku-specific; neither is it Papertrail-specific. (Search "sails.js platzi" for a tutorial with an example involving Heroku. See part 5.) Anyway, you can use the general principles here to monitor a Sails app using any logging tool.

(error: Sending 500 ("Server Error") response:) OR (error: Background instruction failed:) OR (WARNING: A function that was initially called over 15 seconds) OR (Error: Internal error occurred while running) OR (warn:) OR (Could not run script)

Finding the fault lines

May 8, 2021

In our agile world, we often divide up tasks longitudinally; that is, along goal-oriented lines. This results in mini-projects like “put documentation on the website” or “put a contact form on the website”.

This is an intuitive and low-effort management exercise, which can have great results. And I love how it lets you put trust in people to figure things out. The problem is, to assign a directly responsible individual (DRI), they have to be the right person to make decisions about every part of the project: from the marketing copy to the coding to the deployment of the changes. If they don't? Not only can it be very frustrating for them, but output and quality of work can suffer. Not to mention that getting things back on track can eat up valuable time for other members of the team.

Alternatively, you can divide tasks latitudinally - along their natural, functional lines. These lines have to be felt out, since they depend on the nature of the types of work in

Originally posted in sindresorhus/awesome-nodejs#998 (comment)

Just want to clear things up here: the Sails framework is actively maintained and widely used. For context, I am its creator and BDFL. @eashaw is lead maintainer and community manager. @DominusKelvin also maintains an active supplementary community called SailsCasts. https://sailsjs.com/support has a full list of resources you might want to check out. As far as what that means: there's a daily check for vulnerable code paths, a weekly roundup of community GitHub issues/PRs, and active development as needed to fix any priority bugs. This is all funded by Flagship customers and supplemented by my continued personal financial commitment to keep the Sails framework alive.

This will continue for many years to come.

![image](https://user-images.githubusercontent.com/618009/108785018-37378000-753

	\ Community / market /
	\ Audience / target account /
	\ Impression /
	\ Visitor /
	\ /
	\ Contact /
	\ /
	\ Activity (psychological stages / nurture) /
	\ /
	\ Lead(s) (actionable intent) /