I own one of the great miracles of the modern age -- a filter pitcher. While this has made my life much more enjoyable, there's a flaw inherent in the design of the pitcher I have.
The problem is the filter insert seals the top of the pitcher, except for the spout. This is fine, until you try to pour at full tilt. When water leaves the pitcher through the spout, a vacuum is formed inside and air is sucked back in. Pouring is slow and uneven when this happens.
We can fix this by adding a vent. A small hole drilled into the back of the pitcher allows air to enter and the pitcher to empty faster.
Brita Slim Filter Pitcher
Fix what's broken.
Update: I've received many comments about the orientation of the insert. When in the "proper" orientation, the insert wants to come off with the cover when opened and then blocks part of the spout. I use the tab now to hold the insert in.
This style of buzzer has remote video and a handset for sound, so the "buzz-in button" isn't directly connected to the door lock. The only external attachment is a header cable to board which connects the video, audio and door buzzer signals in series to other apartments.
Finding the door lock wires was a bit challenging. The model numbers listed on the parts led to some very vague schematics which suggested the door lock circuit would be a 12V supply which switched to ground to open the lock. This means the button was an NO or Normally Open style, so we'll see next we connect the ground and the 12V door open signal to the NO terminals on the wireless relay board. If you have trouble finding schematics, use a multimeter to find likely candidates and carefully play the guessing game by jumpering the terminals until the door opens. Make sure any circuit you close is between 5V and 24V DC to prevent a nasty surprise.
I used the multimeter to find a 12V signal and determined the yellow wire was the bingo, and obviously enough, the black wire was ground.
Wireless Relay Board
The relay board goes into the closet behind the door buzzer housing and is connected to the buzzer by fishing the wires through a small hole drilled in the back of the wall.
The first thing to know is you can't assume a client browser will accept gzipped content. We need to check the request headers for something like this:
Each of the options below does this in some way or another.
One option is to use mod_deflate. This causes CPU overhead, and is not supported by many shared webhosts because of it. So we can't distribute an application assuming we can use mod_deflate. Deflate compresses files as they are requested.
To use mod_deflate, you'd add something like this to your config or htaccess:
A second option is to use MutliViews in mod_negotiation. MultiViews allows Apache to choose a file based on the browser's request headers and is designed to specifically support different encoding and languages which a client browser claims to support. This method allows to you pre-compress your files and avoid the overhead associated with on-the-fly compression.
To use mod_negotiation to handle gzip, you'd add something like this to config or htaccess:
AddEncoding x-gzip .gz
You'd create two versions of each file:
Then, in your application, you'd link to non-existent file:
But, as you can tell, if MultiViews isn't enabled for some reason, the application will request the file "myscript.js" and since the file doesn't exist (and cannot exist, or else MultiViews won't try and find the correct file), we get a 404 and the application breaks. If you're distributing your application across multiple server types and configurations, your application will just plain break. This also won't work if a browser doesn't support the English language (should be very rare).
The third and most appealing option is to use mod_rewrite and combine the best of the first two methods, pre-compression and conditional file responses.
To use mod_rewrite to handle gzip, you'd add something like this to config or htaccess:
The mod_rewrite configuration checks the client headers for gzip support then checks to see that the .gz version of the file exists before rewriting the request for the .gz version. AddEncoding ensures the gzip content encoding header is sent to the browser. The ForceType directives make sure the proper content type is sent to the browser for the .gz extensions.
Then you'd create two versions of each file (you don't have to do this for all files, just the most compressible):