Symfony is an open-source PHP web framework, from their own blurb:

“Based on the best practices of web development, thoroughly tried on several active websites, symfony aims to speed up the creation and maintenance of web applications, and to replace the repetitive coding tasks by power, control and pleasure.

Symfony provides a lot of features seamlessly integrated together, such as:

• simple templating and helpers
• cache management
• smart URLs
• scaffolding
• multilingualism and I18N support
• object model and MVC separation
• Ajax support
• enterprise ready.”

Cool stuff.

Unfortunately the instructions lack those vital “For Dummies…” steps absolute beginners need (at least this one does).

So, more as a note to myself, this is how to install the symfony sandbox on WinXP.

1. Unpack the .tgz file to your www folder in WAMP (I assume XAMPP is similar). Using 7zip, this was a two-stage process so a bit of jiggery-pokery to get the sf_symfony folder directly under the www folder was required.
2. Writing http://localhost/sf_sandbox/web/index.php into your browser successfully displayed the congratulations page.
3. Open (or create) the file sf_sandbox/config/schema.yml and add the data model as provided.
4. Now it’s time to break out the command line skills and fail, especially if you’re an absolute beginner to all this.

Edit your Path Variable first

The command line instructions given are for *nix, so before ploughing ahead we need to give Windows a clue first, namely tell it where it can find php.exe.

1. Right-click My Computer and select Properties.
2. Go to the advanced tab and click the Environment Variables button.
3. In the system variables list of the resulting popup window, select the Path variable and click the Edit button.
4. Scroll to the end and type ;c:\wamp\php\ or equivalent path to the folder with php.exe in it.
5. Click OK all the way out to set the variable.

We’re good to go!

Get a command line

1. Go to Start > Run…
2. Type in cmd and press return.
3. You need to be in the sf_sandbox folder. Two commands are needed - cd and cd.. where cd means “change directory” and cd.. is “up a directory”. Eventually you’ll get to something like c:\wamp\www\sf_sandbox.

Building the first project

Back to the instructions except you drop the exclamation mark:

php symfony propel-build-model

Before executing the next two lines you need to enable read/write permissions on the sf_sandbox/data/ folder first. In Windows Explorer:

1. Find the folder, right-click and select Properties.
2. Untick the Read-Only flag and allow the changes to propagate.

We’re ready to execute more commands now:

php symfony propel-build-sql
php symfony propel-insert-sql
php symfony propel-generate-crud frontend post Post
php symfony propel-generate-crud frontend comment Comment
php symfony clear-cache

Success! It should be possible to see each of the two modules we just created without errors and hopefully carry on with actually learning symfony.

Technorati Tags: symfony, php, php-framework, how-to

Joel Spolsksy presented to the Yale Computer Science department on 28 November 2007 with a talk about software development and his experiences. Rather than do a standard save to this month’s del.icio.us bookmarks, I wanted to dedicate a full post to it as it resonates so well with my current situation.

“you might find yourself working on in-house software, by accident, and let me tell you, it can drain the life out of you.”

So why does it suck?

“Number one. You never get to do things the right way. You always have to do things the expedient way. You’re not going to [be] allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be. You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough. Get out of there and onto the next thing.”

First I should point out that I don’t actually do .NET programming. Our programmers were made redundant last year and me and my one remaining colleague have yet to receive any kind of support to plug the skill shortage. We have another guy who can write PHP in the support team but we can’t realign to deliver solutions using open source technology based on PHP / mySQL. We can’t even deliver a blog because we don’t have a LAMP infrastructure and we certainly don’t have the skill to implement a .NET solution either. We’re not empowered to do anything about it. I’ve snuck some jQuery into our Intranet and that’s as good as it gets. Ajax? Ruby on Rails? Yes, very cool. Would be nice.

“That’s the second reason these jobs suck: as soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship… You’re going to churn out embarrassing junk, and then, you’re going to rush off to patch up last year’s embarrassing junk which is starting to break down because it wasn’t done right in the first place. So, the number two reason product work is better than in-house work is that you get to make beautiful things.”

We have some ugly, poorly-designed web apps. Apps that handle things like surveys and feedback are a nightmare to configure because the initial scope and deadline was so tight they couldn’t be thought out properly so as to be flexible or extendable. “It can’t carbon copy the form submission to the sender?” We get bitten on the arse and made to look like fools too often. It wasn’t our former colleagues’ fault. It’s the circumstances, the management environment they found themselves working in. Ugly? Isn’t that my job? Yes, but you have to be given project time first. I deliver professional, minimal and clean design with consistent CSS treatment of typography and vertical rhythm and semantic, accessible markup but a website takes more than two days to put together because design is not all about the code either.

“Number three: when you’re a programmer at a software company, the work you’re doing is directly related to the way the company makes money. That means, for one thing, that management cares about you. What I was used to from the west coast was an attitude that management is just an annoying, mundane chore someone has to do so that the smart people can get their work done. Think of an academic department at a university, where being the chairperson of the department is actually something of a burden that nobody really wants to do; they’d much rather be doing research. That’s the Silicon Valley style of management. Managers exist to get furniture out of the way so the real talent can do brilliant work.”

Well, I have experienced this in-house before—and how lucky I was I see now—in my previous job as an intranet developer using PL/SQL and Oracle Portal (awful product though). We actually had deadlines that allowed for quality, testing and documentation. We solved internal customers problems and innovated by further streamlining established workflows. The department boss was a geek like the rest of us—with a sympathetic ear, wise words and a sense of direction.

I want that back before I lose my soul.

Technorati Tags: Joel Spolsksy, software development, work environment, job satisfaction