NGINX index directive with PUT and DELETE requests

I just spent ages trying to figure this out, so I hope this post saves someone else some time.

I have a script named index.php that I want to send requests to by just referring to the directory it’s in, relying on the server to send the requests to the right place. I do that to keep the URLs simpler, and to make it easier to swap out the script for something else later without changing everything that refers to it.

That works great with regular GET and even POST requests, but for PUT and DELETE I was getting “405 Method Not Allowed” errors. After more digging around and false starts that I’d like to admit, I noticed that sending requests directly to index.php worked fine. It turns out that NGINX’s index directive does not allow PUT or DELETE.

That doesn’t seem to be officially documented anywhere, and the only workaround I’ve found is to either rewrite all URLs ending in “/”, which seems like overkill, or point the script sending those particular requests directly to the file instead of the directory.

How is it September already?

I swear the year only just started, and yet January also seems like it was ages ago. Life has been so full lately.

Last year I got laid off, spent a while dealing with burnout (including a month doing nothing but playing late-90s Japanese video games), spent some time doing contract work, and finally landed a job with UPMC, a local hospital and insurance company, where I have been helping kick-start the UX process for an internal insurance application. I know far more about insurance claims and payment authorization than I ever expected to know, and yet there is so much more to learn. Fitting UX processes into a long-standing development process without stepping on too many toes has been interesting, and is still an evolving process. We also just added a couple new people, and learning to organize and delegate has been an interesting process, too. I don’t quite know what I’m doing, but it’ll be ok.

I don’t know if UPMC is an anomaly in this, but I actually feel better about insurance having seen how much the people working the claims care about the members health and well-being. Most of them are former nurses who have been in the hospitals; they have seen patients with the same conditions they are now authorizing claims for, and they know how serious these things are. Not that that necessarily changes corporate policies, but it’s good to know there are people in the middle who care.

I’ve also been dealing with new dietary restrictions. At the end of last year I developed an inability to eat wheat or dairy, and learning how to eat again has been hard. It’s probably been good for me overall, in that I’m more mindful of what I eat and I don’t go out to restaurants as much, but it has been stressful at times. Sometimes I have to go out and there’s nothing I can eat. Sometimes I just want a cookie, and the easiest way to get one is to make it myself–and baking with no wheat and no butter or milk is extra hard. I’m getting there, though. Today I actually managed waffles.

Also this year, after 10 years together Zack and I finally got married and had a lovely honeymoon in England, Wales, and Scotland. It’s been 8 months, but after 10 years of having a “boyfriend” it’s weird to say “husband”. It’s weird to think that I have a husband. But not in a bad way. I feel like I ought to say more about this, but really, life together continues much as before (also not in a bad way ☺).

Using Design Artifacts with Stakeholders

Last week at Midwest UX, Uday Gajendar gave a talk called The Wicked Craft of Enterprise UX in which he noted several ways he has used UX design artifacts (diagrams, wireframes, etc.) with non-designers in order to facilitate communication.

This talk wasn’t really anything new to me, but it was validating, because I’ve been doing that for a long time and I thought I was just making something up, or misusing the tools. Talking to other people afterward, it seems like a lot of us do, and we all thought we were alone doing it.

There’s a perception among us that there’s a right way to use diagrams, models, flow charts, wireframes; that there’s a right time to use them in the project, and that they’re just for designers, or at most that you present them to clients as background justification for a final design that you’re unveiling–but this is fundamentally the wrong way to think about them.

Design artifacts are not just deliverables, they are communication and collaboration tools, and communication and collaboration is core to every designer’s job. You can use whatever tools you have in your toolbox however and whenever you need to in order to make that communication and collaboration happen. Mix and match, make up new tools, there is no pure process and every project is different.

So in the interest of spreading that mindset, here are a couple of examples of using the tools in perhaps unconventional ways. Both of these examples use wireframing tools, but really it could be anything.

Managing client requests

This was a bad project for a number of reasons, but one of them was that we had somehow gotten to the point where development was basically at the mercy of the client’s every whim. Every couple of weeks the client would have a new genius idea, and that would be the most important thing until the next idea came along. The project manager did his best, but the client would not commit to any long-term priorities.

In one meeting where the client had just brought up something new, I brought up a wireframing tool (the meetings were remote, no whiteboard sketching here) and started sketching out what the client was describing and asking questions. Actually showing the client what it would be like to try to use what they were asking for and how it would interact with the existing system showed that maybe this wasn’t such a good idea, or at least that it would be far more complex than expected, and having the finished wireframe at the end of the meeting that the client agreed reflected the idea accurately was enough progress on that idea that we were able to get other things done instead of being jerked around by new things all the time.

Wireframing became a go-to technique in many future meetings with that client.

Getting requirements out of people’s heads

On another project, I basically needed to design a CMS that included a huge amount of metadata for each item. I was working directly with several of the people who would be entering the data, and they had a general idea what would be needed but I was having trouble getting them to express it concretely or consistently.

I broke out a wireframing tool in this case also, which helped them move from “what might it possibly be” to “what will it be like to enter this information”, which helped draw out concrete statements about what each thing could or could not be. The tool helped them think about the information more directly, and we were able to try out the sketches we created together against some of the real data to validate them.

Notes from Midwest UX 2015 Day 2

These are my notes from day 2 of Midwest UX, held October 2-3, 2015 in Pittsburgh, PA.

Table of Contents:

Read More

Notes from Midwest UX 2015 Day 1

These are my notes from day 1 of Midwest UX, held October 2-3, 2015 in Pittsburgh, PA.

Table of Contents:

Read More

Experimenting with Pattern Libraries

I’ve been experimenting with pattern libraries lately. They’re useful to have so developers can put things together quickly without reinventing the wheel (I once provided a pattern library for a team that had reimplemented some of their basic design patterns at least 6 different ways before I helped them unify everything) and they help the design team think about things consistently and meaningfully (having to add another pattern to the library makes you start questioning why this particular region needs a different style). But they can be awkward to put together and difficult to make sure all of the design changes continue to be added over time–and once they’re out of date, they’re worse than useless.

I’ve recently discovered Pattern Lab, which produces a pretty nice basic pattern library off of a bunch of templates, and that solves the first problem, but the problem of maintaining it over time remains. In fact, the problem could even be worse–with something entirely custom, you might be able to build it off of the same template system that’s used in the real site, so there only needs to be a change in one place, but with the generator you’re almost certainly using a separate code base, so all changes need to be made twice.

So I’ve been playing with making a conversion script that takes the patterns from Pattern Lab and converts it for a couple of different content management systems I use. So far I have it working for Django, Jekyll, and Statamic; I have tried but failed to get it working in Perch and Drupal because some of the things that need to be done in those environments is difficult to automate based on the Mustache templates that Pattern Lab uses.

The code for the script is on Github, and I’d be delighted if you used it on your own projects, forked it, modified it, added more output CMSs, etc. if it is a thing you would find useful. I hope it’s well enough documented to get started, but if you have questions, please ask :)

Notes from Web Design Day 2015

These are my notes from Web Design Day, held on June 12 2015 in Pittsburgh, PA.

Table of Contents:

Read More

Notes from IA Summit 2015 Day 3

These are my notes from day 3 of the Information Architecture Summit, held from April 22-26 2015 in Minneapolis.

Table of Contents:

Read More

Notes from IA Summit 2015 Day 2

These are my notes from day 2 of the Information Architecture Summit, held from April 22-26 2015 in Minneapolis.

Table of Contents:

Read More

Notes from IA Summit 2015 Day 1

These are my notes from day 1 of the Information Architecture Summit, held from April 22-26 2015 in Minneapolis.

Table of Contents:

Read More