Code Tutorials Work

How to tar a directory and only include certain file types

find myProjectDirectory -type f \( -name \*\.php -o -name \*\.js -o -name \*\.css -o -name \*\.inc \) | xargs tar -rf myProjectTarName.tar
Code Tutorials Work

How to change file or folder permissions recursively with chmod

To set only files that end with .tpl to 600 (pattern escaped with slashes)

find . -name \*\.tpl -exec chmod 600 {} \;
Tutorials Work

Facebook Conversion Tracking Prestashop Module

The Facebook Conversion Tracking Prestashop Module.

Need to track your ROI from Facebook Ads? With this easy to use Prestashop module you can. This module automatically adds the tracking conversion code when a customer makes a purchase so you can measure if your Ads are working.

You can download the Facebook Conversion Tracking Prestashop Module using the link below:
Facebook Conversion Tracking Prestashop Module


Don’t Make Squirrel Burgers

Your manager comes to you and says “Hey, Joe.  Let’s talk.  I need to get a new system developed to keep track of our help desk calls.  It needs to have a slick user-interface that is easy to navigate, it needs to be fast, and also we need integration with SAP.”  You ponder what the system architecture might be like.  He continues.  “So how long do you think this will take?”

Of course, your first instinct is to tell your manager that you’ll get back to him later with a rough estimate, but he is in a hurry and persistent.  You cave in and tell him, “I think it would take 6 weeks.”

“Hrm, 6 weeks?  I really need it in 5 weeks, no later.”

Your manager is already negotiating your rough estimate.  Be afraid.  You start to figure out how you can accomplish all of this in 5 weeks and you are realizing that you really needed eight weeks, not six.  Let me put this story on pause while I tell you another story…

Bob is the new night manager at FatBurger.  One night a man walks in and requests a double Fat-burger with cheese, a large order of Fat Fries, and a chocolate shake.  He pulls out the change in his pocket and Bob finds out that he only has $1.20.  The entire meal costs $7.50.

What would you do in this situation?  Turn away your only customer in the 11:00pm hour?  Offer something that he can afford?  Give it to him for $1.20 this time only?

Bob, being a proud night manager, wants to satisfy his customer.  He cannot give away the food cheaply because then the guy will return again, expecting another discount.  So Bob decides to get creative.  He goes around back and finds a dead squirrel on the pavement.  He scrapes it up with a shovel and brings it inside, grills it up and gives it to the man.

In this story, Bob sacrified quality to give the gentleman what he wanted for only $1.20.

Stop me if this scenario sounds familiar.

Back at your desk, you are realizing that you are about to deliver to your manager a squirrel-burger.  He wants X features, but you can’t deliver them on time.  The first thing you are going to throw out are automated tests.  Then you’ll stop refactoring.  Pretty soon you are just heads-down coding like you did in high school and you are making a huge mess.

Two things are likely to happen.  The system will buckle under its own weight because the code reaks of dead squirrels.  The other thing that is likely to happen is that your system becomes useful, and now management has another request.

“Hey Joe.  The new system rocks!  I just got off the phone with marketing and they want to start selling this to our larger clients.”

Now you’re in a pickle.  You have a spaghetti-mess of a system and now you need to extend it and polish it for redistribution. 

This sad state of affairs is all too common.  Your manager might want a double Fat burger with cheese in 5–weeks, but what he’s getting is a squirrel burger.  Don’t deliver squirrel burgers.  Be careful with off-the-cuff estimates that end up turning into negotiations.  Joe should have negotiated features instead of quality to meet his 5–week deadline.  Estimates should include time for automated tests and refactoring because it is part of your daily coding activity and it helps maintain quality.

I first heard the term “squirrel burgers” and the above story from Mark Pushinsky.


Holding a Program in One’s Head

by Paul Graham

August 2007

A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he’s working on. Mathematicians don’t answer questions by working them out on paper the way schoolchildren are taught to. They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will.

That’s particularly valuable at the start of a project, because initially the most important thing is to be able to change what you’re doing. Not just to solve the problem in a different way, but to change the problem you’re solving.

Your code is your understanding of the problem you’re exploring. So it’s only when you have your code in your head that you really understand the problem.

It’s not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you’re actively working on a program it can take half an hour to load into your head when you start work each day. And that’s in the best case. Ordinary programmers working in typical office conditions never enter this mode. Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they’re solving.

Even the best programmers don’t always have the whole program they’re working on loaded into their heads. But there are things you can do to help:

  1. Avoid distractions. Distractions are bad for many types of work, but especially bad for programming, because programmers tend to operate at the limit of the detail they can handle.The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

    Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don’t even start working on something hard.

  2. Work in long stretches. Since there’s a fixed cost each time you start working on a program, it’s more efficient to work in a few long sessions than many short ones. There will of course come a point where you get stupid because you’re tired. This varies from person to person. I’ve heard of people hacking for 36 hours straight, but the most I’ve ever been able to manage is about 18, and I work best in chunks of no more than 12.The optimum is not the limit you can physically endure. There’s an advantage as well as a cost of breaking up a project. Sometimes when you return to a problem after a rest, you find your unconscious mind has left an answer waiting for you.
  3. Use succinct languages. More powerful programming languages make programs shorter. And programmers seem to think of programs at least partially in the language they’re using to write them. The more succinct the language, the shorter the program, and the easier it is to load and keep in your head.You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head.
  4. Keep rewriting your program. Rewriting a program often yields a cleaner design. But it would have advantages even if it didn’t: you have to understand a program completely to rewrite it, so there is no better way to get one loaded into your head.
  5. Write rereadable code. All programmers know it’s good to write readable code. But you yourself are the most important reader. Especially in the beginning; a prototype is a conversation with yourself. And when writing for yourself you have different priorities. If you’re writing for other people, you may not want to make code too dense. Some parts of a program may be easiest to to read if you spread things out, like an introductory textbook. Whereas if you’re writing code to make it easy to reload into your head, it may be best to go for brevity.
  6. Work in small groups. When you manipulate a program in your head, your vision tends to stop at the edge of the code you own. Other parts you don’t understand as well, and more importantly, can’t take liberties with. So the smaller the number of programmers, the more completely a project can mutate. If there’s just one programmer, as there often is at first, you can do all-encompassing redesigns.
  7. Don’t have multiple people editing the same piece of code. You never understand other people’s code as well as your own. No matter how thoroughly you’ve read it, you’ve only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would.And of course you can’t safely redesign something other people are working on. It’s not just that you’d have to ask permission. You don’t even let yourself think of such things. Redesigning code with several authors is like changing laws; redesigning code you alone control is like seeing the other interpretation of an ambiguous image.

    If you want to put several people to work on a project, divide it into components and give each to one person.

  8. Start small. A program gets easier to hold in your head as you become familiar with it. You can start to treat parts as black boxes once you feel confident you’ve fully explored them. But when you first start working on a project, you’re forced to see everything. If you start with too big a problem, you may never quite be able to encompass it. So if you need to write a big, complex program, the best way to begin may not be to write a spec for it, but to write a prototype that solves a subset of the problem. Whatever the advantages of planning, they’re often outweighed by the advantages of being able to keep a program in your head.

It’s striking how often programmers manage to hit all eight points by accident. Someone has an idea for a new project, but because it’s not officially sanctioned, he has to do it in off hours—which turn out to be more productive because there are no distractions. Driven by his enthusiasm for the new project he works on it for many hours at a stretch. Because it’s initially just an experiment, instead of a “production” language he uses a mere “scripting” language—which is in fact far more powerful. He completely rewrites the program several times; that wouldn’t be justifiable for an official project, but this is a labor of love and he wants it to be perfect. And since no one is going to see it except him, he omits any comments except the note-to-self variety. He works in a small group perforce, because he either hasn’t told anyone else about the idea yet, or it seems so unpromising that no one else is allowed to work on it. Even if there is a group, they couldn’t have multiple people editing the same code, because it changes too fast for that to be possible. And the project starts small because the idea is small at first; he just has some cool hack he wants to try out.

Even more striking are the number of officially sanctioned projects that manage to do all eight things wrong. In fact, if you look at the way software gets written in most organizations, it’s almost as if they were deliberately trying to do things wrong. In a sense, they are. One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that’s what programs are: ideas.

It’s not merely true that organizations dislike the idea of depending on individual genius, it’s a tautology. It’s part of the definition of an organization not to. Of our current concept of an organization, at least.

Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable. Arguably a market is such a form of organization, though it may be more accurate to describe a market as a degenerate case—as what you get by default when organization isn’t possible.

Probably the best we’ll do is some kind of hack, like making the programming parts of an organization work differently from the rest. Perhaps the optimal solution is for big companies not even to try to develop ideas in house, but simply to buy them. But regardless of what the solution turns out to be, the first step is to realize there’s a problem. There is a contradiction in the very phrase “software company.” The two words are pulling in opposite directions. Any good programmer in a large organization is going to be at odds with it, because organizations are designed to prevent what programmers strive for.

Good programmers manage to get a lot done anyway. But often it requires practically an act of rebellion against the organizations that employ them. Perhaps it will help if more people understand that the way programmers behave is driven by the demands of the work they do. It’s not because they’re irresponsible that they work in long binges during which they blow off all other obligations, plunge straight into programming instead of writing specs first, and rewrite code that already works. It’s not because they’re unfriendly that they prefer to work alone, or growl at people who pop their head in the door to say hello. This apparently random collection of annoying habits has a single explanation: the power of holding a program in one’s head.

Whether or not understanding this can help large organizations, it can certainly help their competitors. The weakest point in big companies is that they don’t let individual programmers do great work. So if you’re a little startup, this is the place to attack them. Take on the kind of problems that have to be solved in one big brain.

Thanks to Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram for reading drafts of this.


Changing Gears

It’s been a crazy and busy week for me. It’s the holiday season, and it’s getting pretty busy at work. Just found out this week that we are going to be losing a developer. So that means the rest of us programmers are going to get slammed. Just to give you an example, this week I have had to switch programming mind sets to different languages. I think about 4 languages total. (Unix and Windows side)

I started off earlier in the week writing a Perl script to pull data from sandicor real estate listings and merge the results into an existing database application written in flash. During the mid week I was writing php for a few websites like readypac and California avocados. Another day during the week I was writing some classic VB asp and Javascript ASP for Sunkist and JohnLaingHomes. Towards the end of the week I was writing some c# web user controls for an up and coming new website launch. For most of you this sounds like jibberish and probably won’t mean much, but for me it’s a little amazing as I sat back and thought about what all I did this week at work. We’ll see what the next few weeks have in store.