Cubic

Today I discovered OData.  Then I discovered GData.  Then I discovered that I don't like either one. The idea of a data standardization protocol is appealing on the surface, but the two "official" implementations of a common web protocol for data consumption are not my cup of tea.  I do like tea, however.  But I'm picky about my tea and I'm picky about how I communicate with web servers. First off, I don't like complicated protocols.  I find them annoying as do most other programmers.  This is one of the reasons why SOAP slipped on itself and fell on its derriere at the starting gate.  /hahagreatjoke I've been working with JSON a lot lately.  It benefits greatly from having native support in every popular scripting language and easy-to-integrate libraries in the few languages that don't.  So, if we want to develop a standard protocol, JSON is the starting and ending point for modern development. For some strange, bizarre reason, when a company

I thought about titling this post "How to make a DBA's head explode" or "The blog post from hell:  A DBA's worst nightmare come true" or something like that.  Of the database administrators (DBAs) I've met, which haven't been that many, none of them liked my radical database design ideas. Traditional database design says to create a field (column) for every little fragment of data you want to store.  I've found that this approach causes all sorts of immediate complications both at the database design layer and the application layer, and you have to nail the table design right off the bat or there will be big problems later on.  A lot of people get lost in the details of creating the database table and then lost in the details of linking the application to the database.  Good database design is perceived to be hard and therefore a good portion of the DBA's job is secure. Over the past 1 1/2 years, I've been playing with an alternate ap

It seems to be a rite of passage to author a login system - or several login systems - over the course of one's life as a web developer.  Some systems are more elegant than others but I have to ask:  Is it really necessary? Let me provide some background.  I was mulling one day and realized that every website I've ever come across has one of two problems: Multiple login systems all over the place with multiple registration mechanisms (the result of using open source products or just bad programming habits). Some homegrown, half-baked solution riddled with security issues and poor UI design choices that breaks in half the browsers out there and irritating every user who uses the system. Or some mix of both problems.  And don't think it is just limited to cheesy little one-off implementations.  Major big-name websites that people actually use every day are all in the same boat with the little dinky one-off sites. Then I got to thinking about how many man-hours are w