Installing apps at boot, Wi-Fi magic, and custom MDM URLs

Hey everyone,

We've just rolled out Fleet 4.59.0, and I thought I'd share some of the updates we've been working on. These are the little things that (hopefully) make your day a bit smoother.

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.)

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!

1. Daily communication with the customer (like a standup during the engagement)
2. Timebox the engagement (ok to scope features, but also set a timeframe.)
3. Make it explicit who is working on it and how many hours they'll be working per week.
4. 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.

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?

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:

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

(in fleetdm/fleet#3666)

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)

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