Tales of an IT Nobody

devbox:~$ iptables -A OUTPUT -j DROP

OOP August 20, 2009

Since I can remember, I always thought there was an irrational gravitation towards OOP from people. “If you don’t do OO, you’re not a programmer” is an underlying sentiment in all circles of programmers.

Now, I firmly believe that OO design is definitely a great way to organize, process and a conceptualization tool for programmers to use for managing their code.

However, I’ll add that too many people jump into OOP because they want admission into an ‘elitist’ realm. (Admittedly, programmers like to covet their engineering)

Here’s an interesting sentiment from the almighty MIT that you might find interesting:
http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism

Especially a quotation from Paul Graham:

  • Paul Graham, a successful web entrepreneur and programming author, has suggested that the purpose of OOP is to act as a herding mechanism which keeps mediocre programmers in mediocre organizations from “doing too much damage”. This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques. [1]

I think all to often the confines of an OO design slow down programmers attempting to encapsulate everything around an abundantly engineered solution for simple processes.

But the biggest issue with OO, is how easy it is to paint yourself into a corner and slow everything down.

No Comments on OOP
Categories: programming rant

Visualizing changeset activity August 13, 2009

Came across a nifty extension for mercurial that uses google charts to generate graphs revolving around your Hg repository activity. The extension is called ChartExtension – it’s not as configurable as I had hoped but the results are pretty easy to obtain:

(click for larger)

No Comments on Visualizing changeset activity
Categories: hg purdy

End-user responsible for security? August 7, 2009

Imagine this situation:

A massively distributed worm that connects to random P2P services and downloads and shares various music files gets installed on your machine.

The RIAA finds out and sues you right?

This brings up a good question:
Do we expect every citizen of the internet to be responsible for their own security – what happens if Microsoft hasn’t released a ‘hotfix’ to alleviate the hole for a month or more? (often the case).

Does the RIAA and it’s likes have to back off because people are too dumb not all security experts?

Interesting thought to entertain…

No Comments on End-user responsible for security?
Categories: security

Remote hooks with mercurial August 6, 2009

If you use mercurial in a centralized model – it can be a little fiesty to create and troubleshoot your hooks.

You’ll want to make sure you scan over the /hgrc hooks section and the redbook section on hooks

First, a few rule of thumbs:

  1. It’s possible to write them in bash/sh, and python
  2. If bash-style, your script is executed with your user’s shell. No need to put #!/bin/bash on top really (helps in vim though)
  3. Your script must be +x for the user that’s executing it. (Remote push over http/s, your www/apache user must have +x to it)

How to troubleshoot is easy, I start like this, from /home/rovangju:

This will set the stage. Then we’ll create our hook:

Your hook is now good to go!
Now, in order to fire this off we need to emulate a centralized model, so when we push to the main, we’ll fire off our hook.

/home/rovangju/repojunk/main/.hg/hgrc:

If your file looks like that with the correct path try:

If all goes well you’ll see something like:

And that’s your starting point for your hook.
I just wanted to throw this out there for myself and others someday if they’re trying to find a better way to troubleshoot why their hook isn’t firing or working.
Also, logger is your friend!

No Comments on Remote hooks with mercurial
Categories: hg linux

Overengineeringalisminity August 5, 2009

More often than not, developers thrive for the opportunity for self-developmental moments by designing something super abstract – and in the end become disappointed and unhappy with it because designing things that are too abstract can be just as limiting, if not more limiting and difficult to work with than something simple.

“KISS – Keep It Simple Stupid.” ~ Micheal Scott

Simplicity can be as profound as complicated abstract programming. Not everything has to have a special class or super abstract format – get over it cause it’s moreso an elitist coffee club for programmers to try and put a notch between them and others.

Do you want to be a real uber programmer, a savant, a pro, the ‘go-to’ guy that everyone trusts?

KNOW THE BALANCE
.

Don’t put everything on a high horse, know the balance between what should be a quick development and what should be programmed at a framework/abstract level.

Your superiors will love you because they can trust your judgement – it’s a true level of experience and knowledge, NOT your uber xyz class you wrote. Anyone can spend a year writing a ClassOfAwesome, but not everyone knows and understands the balance involved with being a truly productive programmer with a reputation and understanding of what can and should be done right.

It’s the name of the game – you don’t have all the time in the universe, PR/Marketing wants the goods delivered by xyz, every programmer is grumpy and unhappy because they can’t write ‘the perfect code’ – GET OVER IT and start understanding, this is the way it’s been, and will be FOREVER.

If the consumers/PR/Marketing/”The bosses” had their way, you’d have the best, most perfect product done yesterday, right? So, either you’ve already failed, or there’s an unachievable construct of constraints keeping you from doing what DOES need to be done in time.

What you need to do, is get as close as possible to your goals by making a trade off of “perfect” for “got it done”.

Do you -honestly- think the folks at Microsoft are too dumb to write perfect software?
It’s a game of balance – deliver xyz featrues if possible – keep it as secure as possible, your deadline is xyz – Corners have to be cut and it’s up to -you-, the programmer to pick the right ones that don’t end in catastrophe.

No Comments on Overengineeringalisminity
Categories: programming rant

Good programmers

Truths about good programmers:

0. They know the difference between writing it ‘quickly’ and writing it ‘right’
1. They know that the ability to do both is necessary.
2. They know that when writing it quickly, if you have to stop and think about something, think about the data storage schema, not the code.
3. They know that other programmers go through the same stuff, so stop complaining.
4. “Proof of concept” code tends to turn into production code, so don’t show it to marketing unless you’re ready.

No Comments on Good programmers
Categories: programming rant

Programming through inductive reasoning

I’ll never forget my Geometry class in high school, not just because it was fun, but the teacher was kind of an oddball (in a good kind of way). I learned so much from this class it was unbelievable, it was a life changing experience because it taught the true powers of using inductive reasoning (in geometry, things like the sums of the angles of a triangle are always 180 degrees, etc)

Kevin Mitnick demonstrated this power in the 90’s – Organization and inductive reasoning work hand in hand. If you know that something is completely organized around a concept you can safely assume a lot about it without truly knowing.

With that said, my previous post about table organization should already (hopefully) make more sense.

You can safely assume that because a table starts with ‘category’, it contains a p_id, id and title, etc. All of this is nice and consistent, other programmers will know what’s going on as well.

Admittedly I have plenty of stuff that doesn’t revolve around this concept – maybe someday I’ll re-organize.

No Comments on Programming through inductive reasoning
Categories: databases programming

Canonically speaking

A co-worker and I recently got into a discussion regarding table naming – specifically prefixes and how to group them.

A common approach you see, is to group the tables around a system using a prefix for it’s name:

_newsevents_news
_newsevents_categories
_newsevents_acl

The hardest thing about keeping everything ‘integrated’ is to get other developer’s off of the concept that they need to build their own access control system, or specialized category organization – a category system is a category system, it’s more so a metadata heirarchy to organize data.

I’ve always adopted a canonical approach, similar to how dns server operate, start with what would be your end:

com.mydomain
com.mydomain2
org.anotherdomain

in table terms:

_acl_news
_acl_content_management
_categories_files
_categories_news

The reason I do this is to keep myself in check with how consistent my designing is –
the schema for ‘newsevents_categories’ and ‘file_categories’ in a conventionally grouped table set may vary widely – the idea is to wean off of these drastic changes and group them by their TRUE function, not just the ‘sub-system’ they compliment – and have their schemas as similar as possible. This ensures better object design and abstraction possibilities as well as truly faster development. You can trust yourself with this naming convention just as much as you can trust yourself with the conventional naming, it just takes a different perspective to have it make sense.

The real issue here is how we name our datastore tables for our various formats – if you have news posts, or faq items you’re likely to see tables like:

news_items
faq_questions

Ideally, these generic datastore tables would follow a naming convention revolving around what they truely are, the ‘data’ that drives the system (not to be confused with various metadata tables like category), e.g.:

_data_news
_data_faq

The idea here is to keep the schemas the same – everything has metadata and other supplemental information that makes it ‘different’, that’s what code is for, bringing those tables together to make them into specific objects.

There’s always the unknown – a good example of a wrench thrown into the mix is if you have file information stored in a table – possibly containing image dimensions, file mime types or category relationships – The thing that makes table designs so inconsistent is typically the metadata that revolves around the specifics of what it’s relevant to. This inconsistent, or ‘unique’ information should be stored boldly in a metadata table.

This post is a little long so I’m going to post the “bring it together” stuff in another post

No Comments on Canonically speaking
Categories: databases programming