Full-stack web development is what Learners Guild in Oakland, California, prepares its Learners to do. Essentially, that means developing a whole website or web application. Most of the exercises that Learners engage in are limited to front-end development (writing programs that your web browser executes) or back-end development (writing programs that a server executes before sending content to your browser). That’s because the exercises are designed, in most cases, to take a week, and that isn’t enough time to create both the front end and the back end when the Learner is, in each case, becoming familiar with new technologies.
Multi-week projects have been growing in popularity, though, and they have become the norm in the final (“Apprenticeship”) phase. I have been working for a few weeks on a full-stack application that will let you (if you have a server) store a collection of documents on it and selectively grant permission to users to search for and retrieve documents of interest to them. During my 31st week at the Guild, which ended on 8 December, I got this application, tentatively named DocSearch, to a state of partial completion sufficient for testing by others. My server has a demonstration of it that you are welcome to try. If you do, please comment below, or in an “issue” about how you think it should be improved.
Many document repositories are partly restricted. Specifically, document owners or laws have dictated that not everybody is entitled to see every document, delete every document, and add any new document to the repository. Typically, people belong to various categories, and those with a given category may take particular actions and not others.
So, to be useful for repositories like those, the application must allow users to register and be classified as to the categories they belong to, by somebody with authority over the repository. That person in authority must also be able to define the privileges of those in each category. If a user is in multiple categories, the user’s privileges include those that at least one category grants to the user. My application handles this requirement by letting you grant particular powers over particular document directories to users in particular categories. Users register and state which categories they claim to belong to, but you get the final say. When a user registers or deregisters, or you (in your role as a “curator”) amend any user’s registration, the application sends email messages to those who need to know.
Getting the existing features to work right has been tricky, as most things are the first time. For example, if a curator changes the categories of a user and that user is currently logged in, then the next thing the user asks to do should be based on the new categories, not the old ones. That doesn’t just happen; the programmer has to make it happen and test the application to be sure. Because passwords are involved, the application insists on all communications with users being encrypted. So, if a user requests a plain-text connection (with “http” instead of “https”), the server tells the browser to use an encrypted connection instead. Another detail I needed to attend to was redundancy in the browsing interface: If a user is in categories A and B, category A gives permission to see the documents in the
/docs/finance directory, and category B gives permission to see the documents in
/docs/finance/budgets, the application should show only
/docs/finance to the user, not both, because the more general permission automatically implies the more specific one.
With the partially functional application working, I’m pausing for a few days to get comments, and working on a front-end application in the meantime. With luck, you’ll be able to give me your thoughts about that one, too, in about a week. My last purely front-end application was a calculator that I worked on 4 months ago and discussed in an earlier blog entry. You know what happens to skills you leave to atrophy for 4 months. Use it or lose it.