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.)
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.
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)
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
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 file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters