A Grumpy Young Man

Technosplode - A New Technology News Site

2011-08-12T17:43:00.000-07:00

Check out my new site for trending technology news headlines.

Singleton Abuse

2011-07-25T18:59:00.000-07:00

I know this is a tired topic, but when explaining how not to abuse the singleton pattern, I explain it this way:

Many developers ask themselves this question: "Is there any reason anyone would want to have two instantiations of this class?" This is the wrong question and leads to an over-abundance of singletons. Really, they should be asking, "If I instantiate more than one object of this class, will everything break?"

An additional benefit of approaching the pattern this way is that an answer of "yes" leads to the questions, "Why would my code break? Can I refactor and generalize so that the singleton pattern won't be necessary?"

Programming: What Exactly Is It

2011-03-05T07:37:00.000-08:00

Computer Science is a misnomer. A science is the study of a particular subject with the aim of building a body of knowledge through observation, experimentation and prediction. Physics is a science; we've worked to understand the natural laws that govern material objects, their movement and their interaction with each other.

In contrast, a programmer does not study and try to understand a set of laws inherent to an existing, mysterious system. A programmer creates. The computer does not cease to function if you put everything into the global namespace or create a God object. It's just a bad judgement call. Science doesn't have judgement calls. It's either true and testable, or it isn't.

So programming is a craft. A craft is something that requires skilled labor. Unlike art, it generally produces something practical and usable. Unlike unskilled labor, one of the worker's responsibilities is to make judgement calls that greatly affect the quality of the result.

A programmer named Dan North wrote a winding and controversial article defending his opinion that programming is not a craft but a trade. I don't feel like picking apart his entire article, but here are a couple points:

He doesn't argue in terms of concepts. Depending on your take on the words "craft" and "trade" (which, according to some dictionaries, are synonyms), you may agree or disagree with him. That's a shaky basis for an argument.
He focuses on the attitude of some programmers who claim to be craftsmen. He has more of an issue with conceited posers than good programmers who consider their work a craft.
He says that clients don't care how well-crafted the code is; they simply want it to do what they want it to do. That's true, but they also want to save time and money in the long-run.

Unskilled labor can be unskilled because they've been given a design formulated by someone else; there are few or no judgement calls left to be made. E.g., an assembly line worker who bolts pre-stamped parts to a car or a worker in an electronics factory who solders components to a board according to a schematic. Unless you have a software architect who spells out every class, every package, every method and every interaction, you make hundreds of judgement calls every day as you code, and those decisions affect the long-term viability of the software.

No matter what features our bosses or clients want from us, we're the programmers. We're responsible for knowing how to implement those features in a way that will benefit the company or client, not just right now, but in the long-run. If your only focus is to get the code to do what the the client wants, I pity the developer who has to maintain it and the client who has to foot the bill to extend it. That's where craftsmanship comes in. We're paid by clients to craft a quality product that they will continue to be pleased with.

Architectural Notes

2011-03-04T08:57:00.001-08:00

These are just a few things related to programming I've been thinking about.

There's rarely a right answer; if you're fortunate, there will be an obvious choice with fewer trade-offs.

Design is very subjective. If you give a problem to five programmers, you will get five different implementations, and it's quite possible that all of them are good. Every carpenter knows that a dovetail is the strongest joint, but the curve of the chair's back, the spread of its legs and the finish of its grain are all judgement calls that go into making something elegant but practical.

Programming is a craft, not a science.

Expect to do one major refactor of any project or feature. It's OK---you had no way of knowing that what you thought you needed at first wasn't what you actually needed, and your first attempt will finally give you a standard for comparison to create what you actually needed to begin with.

Code something with the simplest solution possible without ignoring extensibility or flexibility. Worst case, you have to do a major refactor, which is quite nearly inevitable, anyway (see above point). Best case, the solution works and you're done. Either way, you didn't spend more time than was necessary.

All things considered, this means we're the blue-collar workers of the future. I hope you're OK with that.

List File Plugin for Vim

2010-12-13T18:46:00.001-08:00

A while back, I had a post about managing lists in vim. Since then, I've found greater and greater use for the script and have invested more time into it. I've decided to put it on vim.org.

I'm going to reproduce the documentation in the plugin itself with the addition of some in-depth explanation.

Check this post often, as I will keep the documentation up-to-date with the latest features and tweaks.

The plugin helps me manage a plain-text file of nested lists. I use it to manage to-do lists, shopping lists, URLs---all in the same file. It manages priority, status, date, custom folding, among other things. It supports tagging, timestamping and searching with vim's quickfix list. Aside from the shortcuts and commands below, indentation and folding are managed by the standard vim mappings.


First Step

:Lcreate <name> - create new list file in current buffer with <name> (".list" is added automagically)


Creating Items

,n - create new item
<enter> - (insert or normal) create new item
,s - create sub item
<tab> - (insert or normal) create sub-item
,u - create super item


Marking Items

:Lmark <mark> - (normal or visual line) mark item(s) with <mark>
,p - mark item with '=' (in progress)
,x - mark item with 'x' (completed)
,o - mark item with 'o'
,? - mark item with '?'
,- - mark item with '-' (default, incomplete)
,N - set priority as N, where N is 1-5


Tagging Items

:Ltag <tag> [tag ...] - (normal or visual line) add tag(s) to line(s) (has auto complete)
:Ltagr <tag> [tag ...] - (normal or visual line) remove tag(s) from line(s) (has auto complete)


Searching For Items

:Lsearch mark <mark> - find all items with <mark> (e.g.: =, 1, -, etc.) using location list
         tag <tag> - find all items with <tag> using location list
         due [date] - find all items due on [date]. Today is the default.


Setting Due Dates

:Ldue [date] - (normal or visual line) set due date. Today is the default.
:Lduer - (normal or visual line) remove due date
Due dates are in the format YY-MM-DD or any of: yesterday, today, tomorrow,
                                                N day[s], N week[s] (where N is a number)
                                                N:M day[s], N:M week[s] (where N and M are numbers and N <= M)
E.g.: To see all items due this week or next week: :Lsearch due 0:1 week
      To see all items due next week: :Lsearch due 1:1 week
      To see all items due last, this, or next weeks: :Lsearch due -1:1 week
      To see all items due tomorrow or the next day: :Lsearch due 1:2 day
      To make an item due end of next week: :Ldue 1:1 week
      To make an item due one week from today: :Ldue 1 week
      To see all items due in exactly four days: :Lsearch due 4 days


Sorting Items

,r - (visual line) sort highlighted items 
,r - (normal) sort entire file


Et Cetera

,t - add/update last-modified timestamp on item


Configuration

listFile_timestamp = 0
Should timestamps be added to each item by default? Set to 1 to show a timestamp by default.

listFile_indent = 4
Standard indent for nesting.

listFile_ranks = ['=','1','2','3','4','5','o','-','?','x']
Rank of marks for sorting. Note that your own, custom marks can be added to this list and used with the :Lmark command above.

listFile_mark = '-'
Default mark for new items.

listFile_dateFormat = '%y-%m-%d'
Default format for due dates.

Advanced Configuration

Here's an example of something you may put in your .vimrc file:


" add new "!" mark to ranking
let g:listFile_ranks = ['=','1','2','3','4','5','!','o','-','?','x']

" open local projects list file
nmap <Leader>l :60vsplit ~/projects.list

" add my mappings when a list file is loaded
autocmd BufNewFile,BufRead *.list call MyListFileStuff()
fun! MyListFileStuff()
  " add "!" mark for normal and visual modes
  nmap <buffer> ,! :Lmark !<CR>
  vmap <buffer> ,! :Lmark !<CR>

  " tag lines with "quick" tag
  nmap <buffer> ,tq :Ltag quick<CR>
  vmap <buffer> ,tq :Ltag quick<CR>

  " find all lines tagged as "quick"
  nmap <buffer> ,sq :Lsearch tag quick<CR>

  " set an item as due today
  nmap <buffer> ,dt :Ldue today

  " find all items due this week
  nmap <buffer> ,sw :Lsearch due 0:0 weeks
endfunction

In this example, I've added a new mark for me to use: "!". I've also added it to the mark ranks so that sorting will put "!" items in their proper order. I created a shortcut ("\l") to open my projects.list file in a narrow sidebar in vim. I added some things to help me manage items that are quick tasks---a mapping to easily tag items as "quick" and another to search for them. I also added a way to set a due date of today and to find all items due this week.

If you'd like this simple tool in your belt, go get it.

Vim, PHP, TagList, and Ctags

2010-09-02T16:47:00.000-07:00

I spent a good bit of time figuring out how to get vim to play nice with the spectacular TagList plugin, Ctags and PHP, so I've decided to sum up everything I did to get it working perfectly for the next person who comes along.

Installing TagList itself is simple---just follow the instructions, standard to installing any vim plugin. However, getting Exuberant Ctags, which is TagList's workhorse, to work properly with PHP is another matter. Ctags doesn't understand PHP very well. It picks up on variables (which is sorta useless in PHP, anyway) but not functions whose definitions specify access ("public", "protected", etc.), interfaces or abstract classes. How useless!

Creating a useful Ctags file for PHP is not difficult, thanks to the info at these two resources. Just use these flags:


ctags -R --exclude=.svn --tag-relative=yes --PHP-kinds=+cf-v --regex-PHP='/abstract\s+class\s+([^ ]+)/\1/c/' --regex-PHP='/interface\s+([^ ]+)/\1/c/' --regex-PHP='/(public\s+|static\s+|abstract\s+|protected\s+|private\s+)function\s+\&?\s*([^ (]+)/\2/f/' lib/

Notice that I exclude variables via the --PHP-kinds option. This isn't C, tyvm.

What I didn't understand, at first, is that TagList calls Ctags every single time it's opened so that it generates an up-to-date temporary tags file. This makes perfect sense, but when Ctags is called by TagList, it doesn't have all of our required command-line options. Enter the Ctags config file. Put the following in your ~/.ctags file:


-R
--exclude=.svn
--tag-relative=yes
--PHP-kinds=+cf-v
--regex-PHP=/abstract\s+class\s+([^ ]+)/\1/c/
--regex-PHP=/interface\s+([^ ]+)/\1/c/
--regex-PHP=/(public\s+|static\s+|abstract\s+|protected\s+|private\s+)function\s+\&?\s*([^ (]+)/\2/f/

And, amazingly, TagList becomes useful for PHP development. The last step is to tweak TagList to work in a way that's most convenient for you. Personally, I like these options:


" set the names of flags
let tlist_php_settings = 'php;c:class;f:function;d:constant'
" close all folds except for current file
let Tlist_File_Fold_Auto_Close = 1
" make tlist pane active when opened
let Tlist_GainFocus_On_ToggleOpen = 1
" width of window
let Tlist_WinWidth = 40
" close tlist when a selection is made
let Tlist_Close_On_Select = 1

TagList has a ton of options, so check them out. You may also be interested in my most up-to-date .ctags and .vimrc.

My Health As a Programmer

2010-07-30T12:52:00.000-07:00

People often separate general health into categories--physical, emotional, mental, congenital, hexagonal, Portugal. Although some degree of health in one area or another is possible while ignoring the others, I firmly believe each category is dependent on the others.

Good programmers are proud of their capacity for resolving issues and breaking down problems into their salient parts. Quips about co-workers aside, mental and intellectual health are crucial, and I'll bring that up again later. But that's a very small part of a very large picture.

Physical

I had an undiagnosed medical condition for a couple years that affected my energy, motivation and self-image. I didn't have enough energy to keep a routine of physical exercise. On some days, I struggled to stay awake. Focus was hard to come by.

After a successful diagnosis, proper medication helped tremendously. I still felt, though, that my work performance was suffering. I began exercising.

A note about exercise: I hear people say "Oh, I'm not the exercising type." These are always people who have never had an exercise routine before. Anyone I've ever met who has had a routine and fell out of it (for whatever reason) has spoken fondly of the days when they had a routine and of how good they felt--not just physically, but about themselves. So don't give me that "not the exercising type" crap. Unless you have a doctor's note, get out there, even if you have to start small, like, walking-two-blocks small. You will not regret it.

Anyway, so I started exercising. And it was awful. I was exhausted. Panting, tired, and the next day, painfully sore. But after a couple weeks, I started to really look forward to my exercise. Then I started setting goals. Then I started running barefoot. Now I'm six seconds away from beating my best-ever mile time (I ran my best mile in eighth grade).

More importantly, I feel I'm more productive than ever at work. I've started exercising in the morning before I go into the office, which means I'm alert and ready long before I get there. My body is fully awake, my blood is pumping and my brain is active. I walk into the office with a plan, confident and proud of myself for sticking to my routine.

Family

I also try to resolve issues at home. As a married man, I have to occasionally resolve conflicts, of course, with my wife. And bills have to be paid, the car has to be detailed and the trash has to be taken out. I like to keep up with these things, not letting them pile up, go unresolved, or otherwise weigh on my mind. This prevents me from being distracted during the day by stress.

A note about motivations: Of course, I don't do all of these things to be a better programmer. I do them to have a better life in general. I have noted, however, that they have a huge effect on my performance at work and as a programmer.

Intellectual

I've also started caring for my intellectual health. I've had an addiction to certain web sites that waste my time. Considering the GIGO principle, I shouldn't be reading them, anyway.

I've noted how I used to have far more original ideas years ago. In fact, I used to deliberately avoid reading certain things because I thought they'd spoil my creativity by filling my head with other people's ideas. At some point, I started questioning that theory and started reading obsessively. Now I'm finding that a balance between these is best. Say no to Hacker News. Say yes to Schneier on Security and The Old New Thing.

Attitude

One of the most effective things I've done to be a healthy programmer is made an effort to be more humble:

Programming is hard.

Neither I nor anyone else is perfect.

There exists someone who is smarter than I am.

There exists a programmer who could do my project better.

I will never be done improving my craft.

I find that, when I remember these things, I am more open to advice, willing to accept constructive criticism, and curious to learn more, and I feel like I get along with my coworkers better. If I'm willing to listen to what others around me have to say, their knowledge is added to my knowledge. Imagine taking the knowledge from five, ten, fifty good programmers and sticking it in your own head. How can that be a bad thing?

I think a lot of this could be applied to any craft or profession. I, however, am only a programmer. I can say, from first-hand experience, that living and thinking this way has made me a better programmer.

What Facebook Needs: Respect, Not Settings

2010-05-26T22:06:00.000-07:00

Unless you're like the Unibomber and live in a remote cabin, you're probably already bored of the security and privacy news surrounding Facebook.

Since Facebook has realized that they're precariously close to losing millions of users over the bad press, they've made some changes to the privacy settings in an attempt to simplify them and rebuild the trust that has been lost.

What It's Really About

But it's not about settings. I appreciated their efforts to make the settings more granular some time ago. As I see it, there are actually two major hurdles for Facebook, neither related to the current set of privacy settings but to their lack of respect for users and their data:

1) Obviously, settings should not be changed automatically for any reason, as Facebook has done with previous updates. Facebook should also show respect for its users' data by erring on the side of privacy. If an advertiser does not absolutely need a piece of data, it should not be shared, even if Facebook's privacy policy allows it.

2) In addition, there is currently no easy way to close an account. You can only "deactivate" it--meaning that all of your data is still in Facebook's servers, linked to other users' accounts and ready for your inevitable (ahem) return to their social network, at which time your account can be conveniently reactivated.

These are the ways that Facebook has betrayed the trust of its users. It's not about what settings can be configured. Facebook just needs to show some respect for the users and data that have made the social network successful.

Why Your Data Isn't Safe

Recently, Mark Zuckerburg had a phone call for the press where he explained Facebook's mistakes, its goals, and the changes that are being made. The way I see it, there are only two possibilities here:

1) Mark Zuckerberg is a liar. He doesn't want to really change the way Facebook does things because this will result in a loss of revenue. The revamped user settings are just a red herring.

2) Mark Zuckerberg is a bothersome, idealist figurehead to those who actually run Facebook and must appease him. He may not have made these business decisions for the sake of revenue, but those responsible for increasing revenue convinced him that these offending choices were best for other reasons, e.g., that openness is the way of the future and a way for Facebook to continue changing the world. This would also suggest that Zuckerburg's lofty goals and hubris will be his downfall, like so many ancient Greek protagonists.

Regardless of Zuckerburg's motives, your data is not safe with Facebook.

How to Demonstrate Respect

To turn this situation around, they need to demonstrate an unflagging respect for their users' personal data, even at the loss of revenue. This means not unnecessarily sharing data and not changing the way data is shared, even when settings are added or removed. This will take time. They will not be able to gain their users' trust as quickly as they lost it.

They also need to provide a way to completely close an account without any caveats or persistent data. This would be a huge overhaul; it would require removing photos, updates, comments on other users' walls and posts. It would also require removing other users' actions relating to the cancelling user's account. This is a huge loss of data, but it is the only way to thoroughly remove an account from the system.

Even if someone never cancels his account, he can take comfort in the fact that if, at any time, he is uncomfortable with Facebook's use of his data, it can be quickly and thoroughly wiped. This would not only decrease users' reluctance to share personal data on the site, it would also give the users an effective way to hold Facebook accountable for its decisions, as any bad decision could result in a permanent loss of valuable data.

Orlando Perl Workshop (OPW) / Perl Oasis

2010-01-19T07:28:00.001-08:00

I had a really great time this weekend with all the guys at OPW! Although I'm obviously not a Perl guy, it was neat to see some of Perl's capabilities and some of the cool things this community is doing to improve web development. Some of these ideas could even be applied to PHP development. I'll have to give that more thought.

I was also graciously invited to speak about roles in PHP (since they were inspired by Perl's Moose::Roles module). I'll throw up another post with more details about the talk later.

There were some great speakers; I really enjoyed the talks and getting to meet fellow programmers. Stevan Little gave a great talk on everything, particularly wiring up a new app with URL routing and Bread::Board. The colorful Matt Trout told an epic poem about database management, and Marty Pauley give an interesting talk on functional programming in Perl, which actually refreshed a lot of the basics I'd forgotten from school. Shawn Moore revealed even more geek than I thought possible in his talk about conquering NetHack with an artificially intelligent bot.

Of course, there were more good things that happened there, but these are the highlights that came to mind. Many thanks to Chris Prather and his very organized and hard-working wife Jamie for their putting this shindig together. Well done! I look forward to next year. Also, I wanted to mention a particular Perl web server named Plack.

Nested Lists in Vim

2009-10-08T18:08:00.000-07:00

A while back, I worked on a project called Simplist. It was a little web app for creating, managing and sharing infinitely nestable lists.

It was really handy, and I was very proud of myself, until I realized that this is something you can do in Notepad with little effort and in vim with even less.

So I created a short script to duplicate Simplist's basic features in vim:

Notice that some items are marked as completed ("x") and some have priorities (numbers). The last item is actually a list itself with sub-items and is folded.

With a few simple commands, it's pretty handy:


,n - create a [n]ew list item
,x - mark item as done ("x")
,p - mark item as in [p]rogress ("=")
,- - mark item as undone ("-")
,N - mark item with priority N where N is 1-5
,t - update item's [t]imestamp

If you combine these with a few vim keys:


>> - indent line (make it a sub-item of item above)
<< - outdent line (make it a super-item)
zo - open a folded list
zc - fold an open list

you get a pretty decent way to manage lists. I use this all the time--every day at work and for personal lists.

Here's the vim script. Just paste it into your .vimrc:


if version >= 700
 autocmd BufNewFile,BufRead *.list call ListFile()
 autocmd TabEnter *.list call ListFile()

 " 'install' list features
 function ListFile()
  setlocal foldmethod=expr
  setlocal foldexpr=ListFoldLevel(v:lnum)
  setlocal shiftwidth=4
  setlocal tabstop=4
  setlocal foldtext=ListFoldLine(v:foldstart)
  setlocal noshowmatch
  setlocal cindent
  " add [n]ew item below current
  map  ,n o- =ListTimestamp()^la
  " mark item as [x]
  map  ,x mz^rxf[hdf]$a=ListTimestamp()`z
  " mark item as [-]
  map  ,- mz^r-f[hdf]$a=ListTimestamp()`z
  " mark item as = (in [p]rogress)
  map  ,p mz^r=f[hdf]$a=ListTimestamp()`z
  " mark item with a rank
  map  ,1 mz^r1f[hdf]$a=ListTimestamp()`z
  map  ,2 mz^r2f[hdf]$a=ListTimestamp()`z
  map  ,3 mz^r3f[hdf]$a=ListTimestamp()`z
  map  ,4 mz^r4f[hdf]$a=ListTimestamp()`z
  map  ,5 mz^r5f[hdf]$a=ListTimestamp()`z
  " add/update [t]imestamp
  map  ,t mz$a [^f[hd$a=ListTimestamp()`z
 endfunction

 " return properly formatted timestamp
 function ListTimestamp()
  return ' ['.strftime('%Y-%m-%d %T').']'
 endfunction

 " return fold line format
 function ListFoldLine(linenum)
  let s:count = 1
  let s:spaces = ''
  while s:count <= &shiftwidth
   let s:spaces = s:spaces.' '
   let s:count = s:count + 1
  endwhile
  return substitute(getline(a:linenum),"\t",s:spaces,'g')
 endfunction

 " foldexpr function
 function ListFoldLevel(linenum)
  let s:prefix = ''
  let s:myline = getline(a:linenum)
  let s:nextline = getline(a:linenum+1)
  let s:mynumtabs = match(s:myline,"[^\t]",0)
  let s:nextnumtabs = match(s:nextline,"[^\t]",0)
  if s:nextnumtabs > s:mynumtabs " if this item has sub-items
   let s:level = s:nextnumtabs
  else " next item is either same or higher level
   let s:level = s:mynumtabs
   if s:nextnumtabs < s:mynumtabs " if next item has higher level, close this fold
    let s:prefix = '<'
    let s:level = s:nextnumtabs+1
   end
  endif
  if a:linenum > 1
   s:pline = getline(a:linenum-1)
   s:pnumtabs = match(s:pline,"[^\t]",0)
   if s:level < s:pnumtabs
   " if this is higher level than prev, start a new fold
    let s:prefix = '>'
   endif
  endif
  return s:prefix.s:level
 endfunction
endif

A Different Way: Traits in PHP

2009-09-24T06:54:00.000-07:00

For a while now I've had some friends who are Perl fanatics. Perl's OOP support is minimal, which makes it extremely flexible and powerful. One module that takes advantage of that is Moose, which provides an easy-to-use framework for OO design. Basically, Moose gives Perl the OO capabilities that most languages take for granted, if that's what you're looking for. In addtion to such capabilities are a few that most languages don't have, such as Roles.

Moose Roles are:

like multiple-inheritance, except that a Role handles method and attribute collisions

like interfaces, except that a Role is more than a contract--it's fully-working code

like mixins, except that Roles can have requirements for being applied to an object

like duck typing, except that a Role is a named collection of methods and attributes, so the state of being something is more concrete

These ideas really inspired me, but I'm stuck with PHP. Fortunately, PHP 5.3 comes with a crippled implementation of lambdas and closures, which gives just enough functionality to implement something similar to Moose::Role. I also read these two papers, which gave me some solid ideas, although I didn't read them as gospel.

You can get the code from GitHub.

How It Works

First, you have to define some traits:


TObj::Trait('Sortable',
    'sort',function($obj) {
      ...
    },
    'sortAttribute','',
    'setSortAttribute',function($obj,$attrName) {
      $obj->sortAttribute = $attrName;
    }
  );

TObj::Trait('Categorizable',
    'category','',
    'getCategory',function($obj) {
      return $obj->category;
    }
  );

Now we create some other class:


class Something extends TObj {
  private $foo;

  public function __construct($baz) {
    $this->foo = $baz;
  }
}

And now we apply our traits to Something object:


$something = new Something('lolwut');
$something->apply(Sortable);
$something->apply(Categorizable);

You can now call those traits' methods as if they belonged to the Something class! Note that an object's methods and attributes will override any methods or attributes in the traits, even within the context of the calling trait (see part about aliasing below). This makes traits as flexible as extended super classes.

It's a fairly simple concept, though there are some hang-ups when you get down to the nitty-gritty. For instance, what if two traits have methods or attributes with the same name? Well, you can simply exclude it from one of the traits:


$something->apply(Categorizable,array(
      except=>array('getCategory')
      )
    );

or alias it:


$something->apply(Categorizable,array(
      alias=>array('getCategory'=>'getCategoryName')
      )
    );

But what if getCategory() is used all over in other Categorizable methods? Now they'll actually be calling the getCategory() from the other trait, right?

Wrong! Since TObj has to handle all trait method dispatch, it does a little magic. To resolve method and attribute names, it checks for the original name ("getCategory") within the trait whose method made the call, then moves outside and checks aliased and unaliased names. It works the same way for trait attributes, too. This prevents aliases from breaking trait code.

To know if some random object you've received has a certain trait:


if ($something->applied(Categorizable)) {
  echo 'It is categorizable!';
} else {
  echo 'This object marches to the beat of a different drummer.';
}

To require that the object have a certain trait method:


TObj::Trait('TraitThatRequires',
    required,array('aRequiredMethod'),
    ...
    );

$something->apply(TraitThatRequires);

The last line would throw an exception because aRequiredMethod() is not yet implemented by a trait applied to $something.

TObj traits do other things, and you're welcome to check out its unit tests to see its full functionality.

This project is very new, and it has little or no documentation and I'm sure it has bugs (though all tests pass, of course). If you're interested in the project, feel free to pull it and contact me if you have any interesting ideas.

Vim Tip: Debug Path

2009-09-02T08:21:00.000-07:00

I work for a company whose code is in thousands of files in hundreds of directories. We have multiple VCS repositories. Function libraries, class files, HTML, XSL--a convoluted maze to navigate, especially when trying to debug something.

Whenever I'm debugging, I may follow the rabbit hole from function to function, through various libraries and classes, only to find that I'd taken a wrong turn somewhere and come to a dead end. I then either have to sift through the multiple tabs I've opened to find where I should pick up the search again, or, if I've been closing files along the way, I have to start the search from the beginning. This is annoying and time-consuming.

I decided to write a simple vim script to save my cursor's current line, along with the file name and line number, to a file in my home directory. I can then continually save lines as I follow a path through the code. If, at any time, I hit a dead end, I simply go through this "trace" file and find where to pick up the search again. Combined with vim's "gf" command, this file is very useful!

Here's the code you can add to your own .vimrc file:


nmap <F8> <ESC>:call WriteTrace()<CR>

function WriteTrace()
  let lineNum = line('.')
  let lineFile = bufname('%')
  let lineVal = getline(lineNum)
                        
  let allLines = readfile("$HOME/trace.txt")
  let allLines = add(allLines,lineFile.":".lineNum)
  let allLines = add(allLines,lineVal)
  let allLines = add(allLines,"")
                        
  call writefile(allLines,"$HOME/trace.txt")
endfunction

In the code above, F8 will save the line under the cursor, but the nmap can be changed to map to any key, of course.

PHP Is a Husk

2009-08-26T08:13:00.000-07:00

I thought there was hope. I really did. Maybe it was naivete, or simply denial because it's the language I use day-in and day-out. But there is no hope for PHP.

No, I don't think the project will die; I'm sure it will continue to grow. It's no new revelation that the language has a lot of problems. Even when we finally got prepared statements with the MySQLi interface, there were a lot of problems with the way it worked such that writing a thorough DBAL for it was nearly impossible. But lately I've been pretty positive about the direction PHP has been going--with 5.3 came namespaces, lambdas and closures, among other things.

And then I started playing around with these new features. The namespace delimiter is odd, but big deal. Lambdas and closures, though, are broken and useless for anything but the most basic applications.

For instance, I've been messing around a little with Perl and an awesome OO extension for it called Moose. Moose has a ton of features, but one particular feature is Roles. Roles, as defined by the Moose devs, are somewhere between abstract classes and mixins, with multiple inheritance--but more flexible and easier to develop with. You know, pure awesome.

So I set out to try my hand at making something similar to Roles with PHP's new lambdas and closures. That should give me all the power I need to hack something together, right? This is the best I could come up with:


// class used to enable roles for other classes
class Role {
 // used by the class the role is applied to
 // must be in that class's __call() method
 static public function call($obj,$funcName,$args) {
  $func = $obj->$funcName;
  array_unshift($args,$obj);
  call_user_func_array($func,$args);
 }

 // applies a role to the object.
 // for best results, use in the constructor.
 static public function apply($obj,$name) {
  $mixin = new $name();
  foreach ($mixin as $funcName=>$func) {
   $obj->$funcName = $func;
  }
 }
}

// my example role that I want to apply to other classes
class MyRole {
 public $yar = 'role\'s test string';

 public function __construct() {

  // prints a string, including a var from the object
  // that is using this role.
  $this->roleFunction = function($obj) {
   print('This is a role function! '.$obj->blah."\n");
  };

  // prints the object that is using this role.
  // this will also show the methods it has received
  // from the role.
  $this->printr = function($obj) {
   print_r($obj);
  };

  // a function that gets overridden by Test class's
  // native method by the same name.
  $this->overriddenFunction = function($obj) {
   print("You'll never see this.\n");
  };
 }
}

// my class that I want to apply a role to. Note the
// call to Role::apply() in the constructor.
class Test {
 public $blah = 'test string';

 public function __construct() {
  Role::apply($this,'MyRole');
 }

 // overrides MyRole's version, as it should
 public function overriddenFunction() {
  print("I beat the role's method!\n");
 }

 // necessary mess to get $object->roleMethod() to work
 public function __call($funcName,$args) {
  Role::call($this,$funcName,$args);
 }
}

$test = new Test();
$test->printr();

The above will print_r the Test object, as it should, including the public attributes that hold the lambdas from the Role. Neat, right?

Well, not really. This is so messy, so impractical. The limitations are ridiculous. For example, the following works:


$someFunc = function() { print('Hello, blog!'); }
$someFunc();

But this doesn't:


$obj = new StdClass();
$obj->someFunc = function() { print('Hello, blog!'); }
$obj->someFunc();

Whoops! That object method doesn't exist! And what about this:


class MyNeatoClass {
 public $someVar = 'Hello, blog!';

 public function __construct() {
  $this->someMethod = function() { print($this->someVar); }
  $this->otherMethod = function() use ($this) { print($this->someVar); }
 }
}

Neither the lambda nor the closure works. $this cannot be used in lamdas or closures. So, when it comes to using these new features with objects, they're quite nearly completely useless. These are just a couple examples of what makes my above attempt at creating Roles broken and useless.

And as I mentioned before, this isn't the first time the PHP devs have botched up new features. They seem to be committed to adding "big boy" features, which should be a good thing, but not to building them correctly. This leaves developers--who actually know what these features are and how to use them in other languages--frustrated and disgusted. For what audience are they coding? Do they think Grandpa Jo's 14-year-old nephew, who "builds websites", is going to use closures? No, real developers are going to try to use them, and then give up, because they're useless.

This trend is obviously going to continue. PHP had the opportunity to recover from past mistakes with recent new features. They have not learned a thing from past mistakes. PHP, you are dead to me.

Chaos vs. Best Practice: Let Them Eat Cake

2009-08-23T17:20:00.000-07:00

Even if you didn't know who _why was a couple weeks ago, most likely you've gathered enough since then to know that he was a very bright and artistic programmer (or a very bright and logical artist?) who inexplicably erased his digital presence.

But enough about _why, as that dead horse has been and is currently being beaten to horse pudding. However, in looking through some of _why's archives (things are rarely truly erased), I found this insightful and interesting blog post.

To sum up, _why feels like so called "best practices" are dead, boring, and stifling. Good, artistic and revolutionary code comes from chaos. Diagrams and TDD are simply scripted banality. I see his point, but I responded to his post thus:

Refusing to be stifled by best practices is one thing, and it’s not a new thing; to touch on the gagging cliches, everyone who’s ever caused a shift in perception or the field of possibilities--Beethoven, Lennon, Newton, DaVinci--questioned the “best practices” of their field in their day. But you mentioned yourself that we can’t possibly understand every avenue, every corner, of the systems we work with. Isn’t that why we have best practices? To invent the wheel without understanding friction coefficients is foolish. Even though you disagree with their choice, maybe your predecessors decided a sleigh made more sense because you didn’t realize that you live in North Dakota.

Chaos is for after-hours. Chaos is a bunch of possibilities and fewer probabilities, with only one or two sure things. Once you’ve polished all that and have one sure thing in your hands, use it at your day job. At that point, it’s a best practice. Best practices have an origin. Chaos has a conclusion; to claim to subscribe to one and reject the other is short-sighted. To accept both as part of the process shows your passion and dedication to your field.

To expand on this response, there are three types of programmers with respect to chaos and best practice:

Great programmers who can dabble in chaos, confident that a best practice will rise from the ashes of many smart--but failed--attempts. They then share and use these practices. These are the French elite of programmers.

Decent programmers who dabble in chaos but do not develop best practices. Such dabbling helps them to see the wisdom in best practices and use them wisely to make solid software. These are the French bourgeoisie.

Programmers who shouldn't be programmers--the peasant farmers.

I appreciate _why's contributions to programming-as-art. And I really believe that he is brilliant enough to develop best practices from chaos. But his advice to abandon best practice for chaos is saying to the rest of us, "Let them eat cake!" I'm sure his elitism is unintentional, and I certainly don't mean to villianize him by any means. But cake is a luxury and an artistic tribute to the beauty of food. Buildings are built by men eating meat and potatoes. Solid, robust and maintainable software is developed by programmers who use best practices.

Vim Tip: Session Management

2009-08-20T08:14:00.000-07:00

Instead of having another gigantic essay "Vim Tips, part 2," I decided to just address interesting tid-bits of my .vimrc file one at a time. First up: sessions!

Vim sessions are rudimentary but can easily be enhanced to make working on a project or multiple projects more convenient. I'm a big fan of tabs, so I'll often have several tabs open at a time. When I return to work the next day, I'd like to pick up where I left off as seamlessly as possible. Also, if I get pulled away on something else temporarily, I'd like to be able to save my current state, jump to the task at hand, and save its session, as well, in case I have to go back to it again after it's complete.

To this end, I've put the following in my .vimrc file:


nmap <F3> <ESC>:call LoadSession()<CR>
" don't store any options in sessions
if version >= 700
  set sessionoptions=blank,buffers,curdir,tabpages,winpos,folds
endif

" automatically update session, if loaded
let s:sessionloaded = 0
function LoadSession()
  source Session.vim
  let s:sessionloaded = 1
endfunction
function SaveSession()
  if s:sessionloaded == 1
    mksession!
  end
endfunction
autocmd VimLeave * call SaveSession()

To start a session in vim, use the following:


:mksession

This will create a Session.vim file in your CWD. Now, next time you open vim, you can simply hit F3 and your session will be restored. Of course, this little snippet does more than just ":source Session.vim".

When you hit F3, my script sets a flag that means we're currently using a saved session. When you quit vim, it will automatically re-save your session, so when you restore it next time (by hitting F3 again), vim will be returned to the exact state it was in when you quit. It's a very simple hack, but it saves a lot of time.

One improvement I'd like to make is to be able, somehow, to select which session file to use. Suppose I have Project1.vim and Project2.vim ("Session.vim" is the default name, but isn't required). I'd like to be able to select which project I'm working on, and the appropriate session file would be loaded.

Vim Tips, part 1

2008-07-18T15:41:00.000-07:00

Because I'm such a fan of Vim, and because I have people asking me about it quite often (for tips, general questions, etc.), I figured I'd write a two-part article on the greatest text editor in the world.

There are innumerable key combinations in Vim (well, they are in fact finite, but numerous), so I thought I'd describe the ones that I use most often and find the most useful:

Navigation

h, j, k and l - Move left, down, up, or right.

gg and G - Move to the top or the bottom of the file.

ctrl-u and ctrl-d - Move up or down one half-screen.

w and b - Move forward or backward, one word at a time.

fX, FX - Move the cursor over the next or previous occurrence of X in the current line, where X is any character.

tX, TX - Move the cursor to (not over!) the next or previous occurrence of X in the current line.

0 and $ - Move the cursor to the beginning or end of the line.

^ - Move the cursor to the first non-whitespace character of the line.

/[string] and ?[string] - Searches forward or backward for [string].

Tabs

I love tabs. They're a new feature in Vim 7, and I instantly became dependent on them. Here are the commands for using them:

:tabe [file] - Open a new tab editing [file]. Don't specify [file] to open a blank tab.

gt and gT - Move to the next or the previous tab. If already at the last or first tab, wraps

Ngt - Move to the Nth tab.

:q - Closes current tab.

:qa - Closes all tabs and exits Vim.

Editing

d - Deletes in the direction of your movement. E.g.: d$ deletes to the end of the line, dw deletes to the end of the current word, dF[ deletes backward to and including the next '[' character.

dd - Deletes current line.

rX - Replaces current character with character X.

~ - Toggles capitalization of current character. If in visual mode, toggles capitalization of highlighted block.

s - Deletes current character and enters insert mode.

i - Enters insert mode.

a - Moves one character forward and enters insert mode.

Folding

Folding is incredibly useful. It's great for getting large blocks of code out of your way in annoyingly long class files.

zf[movement] - Folds lines in direction of [movement]. E.g.: zfG folds all lines from the current line to the end of the file. For [movement], you can also use text objects.

zf - In Visual mode, will fold the currently selected lines.

zo - Open the fold under the cursor.

zc - Close the fold the cursor is in.

Other Tips

:% - Replaced by current file. You'll see how this is useful below.

:![command] - Execute [command] in the shell. E.g.: !php % - runs current PHP script, !ls - lists files in current directory, !php -l % - checks syntax of current PHP script, !cp % %.bak - creates a backup of current file.

:nohl - Turns off highlighting, if it's on. Depending on your Vim's configuration, doing searches (with / and ?) highlight all matches. This will un-highlight all search matches.

This may seem overwhelming if you're new to Vim, but it becomes second-nature as you get used to it. I did not have to check the Vim documentation at all to write this blog post. It is in fact possible to become accustomed to using so many (useful!) Vim commands. Of course, these aren't all I use, but just the most common.

Next post, I'll discuss my .vimrc file, which contains tons of configuration that makes using Vim a lot easier for me. Perhaps you'll be able to use some of my settings to help you, too.

Simplist Launches

2008-05-09T12:00:00.000-07:00

So I've been working on a new project lately. I threw it out there for a few friends and on a social news site I frequent for suggestions. I got some great feedback and tweaked many things that made it easier to use and more powerful. The site is live and there are already many active accounts, though I'm still making feature additions and changes as I figure out what works and what doesn't. I'd love to get some more feedback. Check it out:

http://mysimplist.com

Profiling by Command History

2008-04-17T11:09:00.000-07:00

I read a blog post about seeing what commands you use most in your shell. So I went ahead and executed the convoluted awk command to give me a pretty list:


[lucas@sarpedon ~]$ history|awk '{a[$2]++} END{for(i in a){ \
> printf "%5d\t%s \n",a[i],i}}'|sort -rn|head
  193   vim
  143   ssh
  129   ls
  108   clear
   91   cd
   69   screen
   65   ruby
   34   time
   22   scp
   19   top

And I got to thinking about how this can say a lot about how I use my computer and how I do my programming. First of all, it's obvious what text editor I use to code--Vim. Second, I obviously do a lot of my coding on other servers, since ssh is the second-ranked command. I use clear a lot because sometimes my CPU gets hot (Thunderbird has an annoying bug that causes it to top off my CPU for minutes at a time), which prints warning messages in my terminal window.

Anyway, sort of a silly diversion, but interesting nonetheless. What commands do you use most often? What does it indicate about your habits?

Why Use OO design?

2008-01-29T10:11:00.000-08:00

There are several paradigms for organizing and writing code for a web application. I hate to use the word "paradigm", though, since it's a two-bit word, and some common paradigms I've seen aren't worth twenty-five cents.

Hopefully, if you're reading this article, you've already read the others, especially the one on The Basics. In that article, I give a list of important things to keep in mind when developing a web application. I give some superficial advice on how to adjust your design to meet these goals, but now I'm going to give you the best solution that exists at this moment, and it will probably remain so for a long time--the object-oriented (OO) paradigm.

For many of you, especially those who have no formal training in software development, the subject of object-oriented programming (OOP) may automatically turn you off. I can promise that it's not as difficult as the old Java dinosaurs would like you to think (they're looking for job security, you know), and any effort you put into learning OO principles will be repaid ten-fold when you write your next app. Let's see why.

Parallel to my Basics article, I'll cover each point and explain how OO design applies.

OO design makes it easier to code additional functionality in the future.

Everything in a well-designed OO application will be modular and separated from code that does a different task. It also makes following the "black box" principle a breeze. Once you code something that works and has a well defined interface--like public functions (methods) and what those functions get and give back in return--you don't have to look at the internals again. In fact, the rest of your code that may use this "black box" doesn't care what the internals are, either.

This also has the implication that you could code support for a certain feature into your application before you even code the feature itself. This is a great way to force yourself to stick to the "black box" principle and sketch out well-defined interfaces before starting to code a module.

- OO design follows the DRY principle by default. The easiest and most obvious way to follow the DRY principle is to factor your code into functions. OOP forces you to do this, to an extent. At any rate, learning OO principles will also help you think in this direction, even if you're not forced by the paradigm to factor your code.

- OO design requires that you correctly identify relationships in your data. Yes, it's true--sometimes OO programmers get it wrong. It's easy to do. But if you're thinking about everything in terms of objects, sometimes real-world ones, then you'll have a better perspective for accurately seeing these relationships.

OO design makes it easier to maintain your code.

As I mentioned above, using OO design turns your application into a bunch of "black boxes". If you change something in a module, as long as you leave the interface the same, no other code will be affected by your changes. This is a huge time saver. You don't have to lay awake in bed wondering if you've broken some completely unrelated part of your application.

- OO design helps you separate data from code. If your models are the only objects that are tightly related to your data, then most of your code will satisfy this requirement automatically.

- OO design helps you keep things organized. I've gotten confused trying to figure out a 10-page site coded using the "page-by-page" method (which is dreadfully popular). If an OO app is well-designed, even if it has a hundred features, you will be able to navigate the code and find what you're looking for quickly.

OO code is often usable in other projects.

This is an area where OO design really shines. How complicated is the idea of a category? Really, you could code something like this once, and use this code in every project that uses categories. Modular code is reusable, and everything in an OO application is modular.

To conclude...

I hope that I've convinced you that OOP is worth a careful look. Even if you never use it, after learning it, you will be a better programmer. Of course, I can't teach OOP in a single article. There are many, many helpful resources out there for learning about OO design, and I won't dare to try to trump them on my blog. Google is your personal research assistant, and he's just itching for something to do.

Web Application Security

2007-12-19T10:10:00.000-08:00

Before expounding the topics in my last post, I thought I'd take a detour to explain something that is very important and often overlooked: web application security.

This is a broad topic, one that is the subject of innumerable mailing lists and that has spawned innumerable consulting firms. I will hardly be able to treat the topic thoroughly in this article. I can, however, give some advice that can knock out the most common and devastating vulnerabilities in web applications. This short list covers some of the biggest non-SQL related vulnerabilities. SQL vulnerabilities and attack prevention are very important, as well, and are a topic for a future article.

Cross-Site Scripting (XSS) - This vulnerability can affect any application that accepts and displays user input. If this input is not properly validated, an attacker can input HTML or Javascript code that is then displayed to every user who comes to the site. This code can do a range of damage, from changing the display/style of the webpage to reaping user login information with an AJAX control using the Javascript DOM.
Solution: Validate your data! Strip all HTML tags from your user input. If you must, allow a well-defined subset of harmless HTML tags (text formatting only, like bold, italics, etc.), and strip the rest.

Cross-Site Request Forgeries (CSRF) or "session riding" - Attackers can fool your unwitting users who have logged in to your application to execute arbitrary site functionality. For instance, say someone has logged into your web forum. Later, he receives a malicious email containing a link like this:


<a href="http://yourwebforum.tld/post.php?body=I'm%20a%20loser!">Check out this funny picture!</a>

Or worse:


<img src="http://yourwebforum.tld/post.php?body=I'm%20a%20loser!"/>

The user wouldn't have to click on the above example--only open the email--for the request to be made. In this example, a post could be made using a user's credentials without his knowledge.
Solution: There are several easy things you can do to mitigate the chance that an attack like this would be successful, like using POST instead of GET or making user credentials expire quickly. However, to thoroughly prevent this type of attack, the solution requires even more. It helps to associate a unique key with each form submission, a key that the attacker could never know. The key could be generated randomly for the form when it is displayed to the user and saved to match to the future POST when the form is submitted back to the server.

"Session hijacking" - An attacker can discover the ID of a user's session and send the session ID in the URL or in the HTTP headers as his own, thereby "hijacking" the user's credentials. This gives any access your user had to the attacker.
Solution: You can try associating the user's IP address with the session, which you would check against the client's IP every time a request were made. This, though, can knock out valid users whose ISPs use load-balancing proxies for internet traffic; their IP addresses may change with every request. It could also allow an attacker behind the same router as the user to hijack a session undetected. Instead, you can set a cookie on the client's machine that contains nothing important or private, say, a unique key generated when the session is created. This key is also saved in the session, and is checked against the cookie at every request.

Lack of URL access restriction - Sometimes a web application will only authenticate a user when trying to access an entry point to a restricted portion of the site. For instance, if a user tries to view his personal dashboard, his credentials are checked and he is redirected to a login page before he can continue. However, if this user were to type in a direct URL to a page other than the dashboard, he would bypass the login procedure altogether. This is a glaring oversight in many web applications. All an attacker has to discover is the the URLs to non-entry pages, to which he would have full access.
Solution: Validate credentials on every page that should have restricted access.

A good rule of thumb when it comes to web application security: Don't ever assume that an attacker won't try or won't figure out how. Ideally, you should be comfortable allowing an attacker to see your source code. It should be apparent that your security is so air-tight that he is forced to play by the rules.

Of course, there are many other types of attacks, and, as I mentioned, I will do another article on SQL vulnerabilities and exploits, which are also very important. For more information on the topics in this article, here are some great resources:

The Open Web Application Security Project
- OWASP's top ten web app exploits

Web Application Security Consortium
- Join their mailing list

MIT paper on secure sessions

The Basics

2007-12-10T12:55:00.000-08:00

From the perspective of most people, web software development is much simpler than compiled software development. Coding a desktop application should require far more planning than coding a web application, right? On the other hand, compiled software developers see most web applications as silly toys and most web application developers as silly people who don't know good software from a hole in Vista.

So how can these two perspectives be reconciled? The fact is, web software development and compiled software development are exactly the same. Both have attracted different types of developers and, in some cases, different types of users, but the same principles apply. By opening the eyes of web software developers to the beauty of good software design, their opinion that web software doesn't require much planning will change. At the same time, with the increase in quality in the design of web software, compiled software developers may actually begin to show a little respect for "silly" web software developers. Well, maybe.

There are some very basic questions you should ask yourself when designing ANY software:

Can I make it easier to code additional functionality in the future?
Some develop with the sole purpose of checking items off the list of requirements. True, this may help you meet your deadline faster (though even that is not likely). But what happens when, six months from now, your client asks for another feature to be added? Did you anticipate that feature request? More realistically, did you code a framework to support quick addition of any request? Here are some ways you can do so:
- Follow the DRY (Don't Repeat Yourself) principle. For example, do you find that your code is similar or even identical in different parts of your software? It would make far more sense to generalize the code and put it in a single function. Later, when you add a feature that requires similar code, you simply call this function. This works especially well for pulling and massaging data from your database.
- Anticipate changes in data. Sure, your client may say that "red" and "blue" are the only options, so you figure an enum in the database will work just fine. Don't be so trusting. There's an N% chance that your client will remove or add colors in the future, where N is large. Create a separate table for these options, and don't feel silly when there are only two rows in the table at your initial launch.
- Correctly identify relationships in your data. Does a shopping cart have an item, or is it the other way around? Can a cart have more than one item? Unless the alternative is absurd, don't ever assume that a cart won't have multiple items, or a user won't have multiple profiles, or a post won't have multiple comments, even if your client swears that they want to "keep it simple" and only have a one-to-one relationship.
- Separate anything that looks remotely like an option from your logic (i.e., don't "hard-code" anything). The number of pictures per row in a photo gallery, the number of file upload fields in a form, the maximum dimensions of a profile photo--all of these should be variables or constants in your code. Initially, before the client asks for the ability to modify these options, they can be set in a separate config file for the application. As the client realizes that these options need to be configurable through the web interface, it will be easy-cheesy to accommodate that.

Can I make it easier to maintain this code?
Even if the client never asks for additional features, he may want "tweaks" to the software. Are tweaks going to be just that, or are they going to require an overhaul?
- Separate design from content. I can't stress how important this is. For instance, in a web application, have just a few source files (like a header, a footer, and a stylesheet) that define all design elements. If your client wants a re-design, you won't have to modify every single page of the website. This seems like common sense, but it's amazing how many people will forgo this huge time saver because "it's just a small site."
- Separate data from code. What if your database schema changes? Don't spend hours modifying eighty-two source files because you add or change one column, or worse, avoid making changes to the software that would improve functionality or efficiency because it's too much of a pain to make them. Your database queries should be quarantined in functions. All your application should know about is functions like getUsers, addUser, getCart, removeAccount etc. To demonstrate how flexible this can be, imagine converting a web application from MySQL to CSV flat files (don't actually do this, or I'll shoot you). None of your page-to-page code would have to change; you'd only have to re-work a few functions responsible for accessing data.
- Keep things organized. This is a broad point, and touches on things like consistent tabbing of your code blocks, sane file naming conventions, sane directory structure, and grouping library functions in files. There's a place for everything, and everything should be in its place. All files should be included at the top of a file, and, ideally, included in only one file. Don't include a source file in the middle of your code just because you need to call a function defined in that file on the line below. How in the world are you going to follow that logic later?

How can I make this code usable in other projects?
It's really nice to have a battle-hardened library of code that you can plug into a client's site for oft-requested functionality. Really, by taking the advice above, this takes care of itself. But just to stress a couple important points:
- Separate data from code. You wrote an awesome photo gallery module for a client, but your new client uses a different type of database. It shouldn't matter. Just rewrite your data access functions.
- Options, options, options. One client may want four photos per row, but the other may only want three. Even if you don't have a web interface for them, separate all options from your code and keep them in a config file. By changing only a few config variables or constants, you can completely customize an application for a client.
- Separate design from code. How's your client going to feel when he sees an identical gallery on a competitor's site? Allowing your clients to skin their application to fit their branding gives them warm fuzzies inside.

This is a huge topic, and I've only scratched the surface. I will expound on some of these points in later articles. Please leave additional points in the comments.