Wednesday, September 30, 2009

Consumer Product Dispensers and Containers

I've been thinking a lot lately about how wasteful consumer product dispensers and contains are to the products that are contained within them. I will use soap pumps, toothpaste and gasoline pumps as examples.
  • Soap pumps - This can be either hand soap or dish soap. Think about what the bottle looks like when you can no long pump liquid out of the dispenser. There is all the residue on the sides of the bottle, and liquid in the very bottom of the contains that the pump is not sucking. There are a few ways to retrieve this waste, for example: tipping the bottle upside down into another container, or rinsing the dispenser with water to. Both have drawbacks. The upside down approach still leaves residue, and the rinsing dilutes the product.
  • Gasoline pumps - Whenever I pump gas, there is always a drip that comes out of the pump and hits the ground as I remove the pump from my car and place back on the holder. I jiggle, I shake, I wait, but still there is always a drip. Given the oil / energy crisis, it bothers me that I am dropping this gasoline on the ground.
  • Toothpaste - I am sure everyone has come up with many ways to squeeze that last bit of toothpaste out of the tube. There are attachments you can add to slide down the tube you use it, you can roll the tube, etc. Down the last bit, there is always toothpaste left to push out with force.
In each example there is waste, and each design has been around for ages. Why hasn't there been improvements? My suggestions are as follows:
  • Soap Bottoms - Design a pump with a pit in the bottom so the contents drains into the pit. The pipe on the pump can sit in this pit. This solves the waste that cannot be pumped at the bottom. For the residue, design a slicker plastic to contain the fluids in, or make the fluid more runny. Making the fluid run will not work in all cases. For example, cleaners need to stick on surfaces and dissolve grime and build up.
  • Gasoline pumps - Add a finalization step to the pump that either blows the left over gas into the tank, or add a sucking mechanism to pull the left over gas out of the pump. Or, ensure there is no drip on the pump, this simply means the fluid released into the hose was not properly drained out.
  • Toothpaste - I'm not sure about this one. Maybe a larger part of the container and be unscrewed for squeezing out. Or a tube that does not allow air in? I know they have machines now the auto squeeze for your from top to bottom.
Regardless, my point here is that I am aware of these shortcomings, and I shouldn't be. More so, if someone does not care to deal with the fuse of trying to consume all the product in a container, then this remaining product is being thrown away. While a small amount for that one person, but given a billion or so people, it's a lot. That amount of product could have been packaged and sold as additional units verses being thrown away.

Tuesday, September 29, 2009

Interview Question, Exception Handling Approach

I was reading an article the other day about exception handling, specifically checked exceptions. After thinking about this concept of wasting time dealing with handling of exceptions, I thought I would drop a similar question in an interview recently.

Basically, the question is open ended, "Can you describe a logging and exception handling approach you implemented in a reason project?". What I am interested in hearing is how the developer thinks about handling failure and reporting that failure. I don't care about specific logging frameworks, just a process of how to fail, or given the article reference, whether to consider failure at runtime at all.

Any interesting response will win me over, but the answer I got was, "Oh, well, I would use log4j". This was not an interesting response.

Sunday, September 20, 2009

I'm a Java J2EE Developer

I conduced a joint interview recently. We would ask questions, and the response was, "Yes, I am a Java J2EE developer, I know how to do that". This happened a few times throughout the interview. The issue was that after the statement was made, there was no follow through to prove it. I struggle to understand the need for "labels" on resumes and in interviews. These labels come from a field or certification process likely, and are only used in the context that the interview demands.

If you are specializing in that area, why would you push the label? You should stress around the label I would think, make points that bring me (the interviewer) to the conclusion that you are in fact a "Java J2EE developer" or that you must be "certified in X".

What I mean by "stress around" is to indirectly define yourself rather then force it. This is a more natural and conversational aspect of the interview. It shows personal interest and excitement in a field, rather then claiming expertise in the whole which is not really possible to discuss in a 30 to 60 minute interview.

Tuesday, September 1, 2009

Exposing Primary Keys To Users

I am not sure where I read or learned this concept, but it seems to be missing from a lot of what I do these days. One way or another, I was taught never to expose primary keys to users, or any internal database key for that matter. These keys are generated for database reasons such as indexing and constraints. For every unqiue row that will be exposed to the user, there should be some other natural way for the row to be identified in the database.

For example, lets use an address book. I may have many addresses I track in an account. Each row should have an address_id and some other textual uniquess identifier, for example nickname. When my address book entries are listed on a page, I should never see the address_id. I do not care how the database is numbering the entires. All I should see is the nickname for identification. This is including the form inputs to apply actions on my address entry, as well as in URLs.

Why does this matter? For one, nobody should likely know the internal numbering in the database. In a large system, these numbers maybe huge and don't present themselves well. It might pose security issues, giving the attacker insight into the numbering limits, the current numbering counter, etc. Lastly, numbers aren't really human friendly as compared to text or visual queues.

See Also

Pointless Printing

I see a lot of printing of documents that really aggravates me because it doesn't really make sense, and is therefore, pointless.

If a document is active, changing or dynamic and you print it, I think it is wasteful. Simply version the document, or save the document with a time stamp if you are worried about the snapshot of the progress of the document, or proof of its content at a given time. If its a webpage, then bookmark it for later viewing. If you are worried the web page will go away one day, then same the page, don't print it.

I understand the legal needs to have physical records, but given the nature of how digital information changes, I think its very rare that you should ever print something. If you are printing, its likely an area of process improvement or need for better long term backups and data storage.

It also bothers me to see the paper being used. After printing the document, you'll read it and then file it, and then what? It sits there. There are tons of people consolidating paper information to digital information, i.e. libraries are scanning books, banks are scanning checks, etc. Why do you need paper if they don't?

A recent reason I don't print much of anything these days is I don't want to pay for printer cartridges. It forces me to think of other ways of saving information because I can't immediately print (my personal printer has been out of ink for 6 months).

See Also:

Share on Twitter