Made of Everything You're Not

Working in IT requires balls; you have to make some really tough choices with very real consequences. It’s not really a problem for programmers; very few of us work on projects that has the potential to destroy lives or break companies apart. On the other hand, in IT, you’re dealing with the backbone of an organization. Make a mistake here and: You. Are. In. Trouble.

Don’t Be A Pussy

Not to worry though; try as hard as you want to not fuck up and it’s just going to happen that much sooner.

I can say with absolute certainty that there’s going to come a time in your career when you fuck up. Big. Like really BIG. The type of mistake that has the potential to sink the company or client you’re working for/with. When it happens it’s going to be bad. So bad that you’ll have the fear of Dad in you. You remember that right? When Dad was coming home and you knew he knew what you did and you knew your life was over. If you didn’t have a Dad; think shear panic mixed with absolute paranoia and terror. Yeah, that’s the stuff.

What you did/will do isn’t important. What is important is how you deal with it. You’re going to have options when it  comes to dealing with the issue(s) and how you act is going to determine how your colleagues and peers look at you for the next few months. Make the wrong call and you’re in for some real uncomfortable silences and some really awkward sidelong glances.

If this has already happened to you; congratulations. Just know it probably won’t be the last. On the other hand if it hasn’t happened yet get ready; it will. You’re going to make some stupid mistakes in your career; mistakes so idiotic and so demoralizing your confidence will shatter and you’ll have a hard time getting back on the horse.

Like I said above, I have absolutely no idea what you do or what you can do to fuck it up so, as anecdotal examples only, I’m going to rely on my personal experience. I can honestly say, with absolute pride, that I have done the following:

• Deleted a database and couldn’t restore the data
• Deleted all the rows in a table and didn’t have a backup
• Deleted a user account and all the email and files associated with it.
• Changed every users password to “password” in a database
• Sent an internal cost analysis report for a client project to the client

And that’s only what was off the top of my head; I’m sure I’ve blocked out some of the worse things. The one constant between the above list (aside from the stupidity involved) was that I owned the mistake. You have to immediately handle the situation whatever that means (it’ll depend on the situation).

After that though a funny thing will happen; it’s very likely your confidence will be shot. This is important because you need confidence (read: balls) to work in IT. There are too many things, that you just don’t know how to do, that you’re going to have to do, and that requires the confidence to know you can do these things. It’s why we make the big bucks.

In my experience the only thing you can do in these situations is get back on the horse ASAP. The sooner you do something, anything, that has consequences the better. You can’t wallow in the past and getting hung up isn’t the answer.

BTW: After reviewing the above I have to say:

Thank fucking God I don’t work in IT anymore.

The first thing you need when working with any new web language or framework is figure out how to work with forms. Forms are one of the constants when working online and it’s the rare occasion when you can bypass dealing with them. They are also one of the more rote and boring portions of a web app to build; they’re, pretty much, always the same requiring the same fields on the same pages with the same validation rules and the same database schema.

Make Zend_Form Bend To Your Will

If you’re smart dealing with forms effectively becomes a priority. My previously held favorite method was using HTML_QuickForm for handling forms. If you’ve never used; IT IS AWESOME.

Here’s an example login form script:

<?php
/**
 * Include HTML_QuickForm library
 */
require 'HTML/QuickForm.php';
 
/**
 * Include HTML_QuickForm Smarty Renderer
 */
require('HTML/QuickForm/Renderer/ArraySmarty.php');
 
$renderer =& new HTML_QuickForm_Renderer_ArraySmarty($smarty);
$form = new HTML_QuickForm('login');
 
$form->addElement('text','Email','Email:' ,'class="textfield" size="30" maxlength="128"');
$form->addRule('Email','Please Enter Your Email','required', null, 'client');
$form->addRule('Email','Please enter a valid email address','email', true, 'client');
 
$form->addElement('password','Password','Password:','class="textfield" size="30" maxlength="128"');
$form->addRule('Password','Please Enter Your Password','required', null, 'client');
$form->addElement('checkbox','remember',null,'Remember Me?');
$form->addElement('submit','save','Submit','class="csubmit"');
 
if ($form->validate()) {
    //do the processing stuff here...
 
}
 
$form->accept($renderer);
$smarty->assign('LoginForm', $renderer->toArray());
?>

Very straightforward I think; instantiate the object, declare the elements, attach the rules and send to smarty (view) object.

The corresponding Smarty template is just as straightforward:

{$LoginForm.javascript}
<form {$LoginForm.attributes}>
{$LoginForm.hidden}
 
{if $LoginForm.Email.error}<span class="errorMessage">{$LoginForm.Email.error}</span><br />{/if}
<div id="email">
	Email: {$LoginForm.Email.html}
</div>
 
<div id="password">
	Password: {$LoginForm.Password.html}
</div>
 
<div id="remember">
	{$LoginForm.remember.html}
</div>
 
 
<div id="submit">
	{$LoginForm.submit.html}
</div>
</form>

That’s my preferred method when layout of the form is important and/or outside the box; it’s totally possible to use HTML_QuickForm without the Smarty integration but I like the control. It allows me to build forms as complicated in layout as the I Am Legend community was (my baseline for form complexity):

Register for I Am Legend Community

Since I’m now using the Zend Framework, and it’s form component is Zend_Form, I can honestly say after the flexibility of HTML_QuickForm and Smarty Zend_Form is, at first, not so awesome. A lot of the resources and tutorials/articles for Zend_Form tout it’s use of the decorator design pattern and all the examples I found looked the same. Not. Good.

Almost none of the references I looked at mentioned anything about removing decorators and rendering just the raw form elements like I needed. It is possible though; you just have to attache a couple extra methods to remove the decorators as laid out below. Make note of the calls to “removeDecorator” and “setAttrib”. Those are the key pieces.

As a counter point here’s the above script using Zend_Form:

<?php
//APPLICATION_PATH/forms/Login.php
<?php
 
class Form_Login extends Zend_Form
{
	public function __construct($options = null)
	{
		parent::__construct($options);
 
		$email = new Zend_Form_Element_Text('email');
		$email->setLabel('Email')
				->setRequired(true)
				->addFilter('StripTags')
				->addFilter('StringTrim')
				->addValidator('NotEmpty', TRUE)
				->addValidator(new Zend_Validate_Db_RecordExists('users', 'email'))
				->removeDecorator('label')
				->removeDecorator('htmlTag')
				->removeDecorator('description')
				->setAttrib('class', 'transperentInput');
 
		$password = new Zend_Form_Element_Password('password');
		$password->setLabel('Password')
				->setRequired(true)
				->addFilter('StripTags')
				->addFilter('StringTrim')
				->addValidator('NotEmpty')
				->removeDecorator('label')
				->removeDecorator('htmlTag')
				->removeDecorator('description')
				->setAttrib('class', 'transperentInput');
 
		$submit = new Zend_Form_Element_Submit('submit');		
		$this->addElements(array($email, $password, $submit));
    }
}
?>

Since Zend_Form is a part of the Zend Framework MVC the above is just the form class and the below is the actual processing portion:

<?php
//APPLICATION_PATH/controllers/Login.php
class LoginController extends Zend_Controller_Action
{
	public function indexAction()
	{
		$form = new Form_Login;
		if ($this->getRequest()->isPost()) {
 
			$formData = $this->getRequest()->getPost();
			if ($form->isValid($formData)) {
                            //do the processing stuff here...
 
			}
 
		}
 
		$this->view->form = $form;
	}
}
?>

Sigh…
And then in the view script:

<form action="<?php echo $this->escape($this->form->getAction()); ?>" 
method="<?php echo $this->escape($this->form->getMethod()) ?>" 
id="sumbitForm">
<div id="email">
	Email: <?=$this->form->email; ?>
</div>
 
<div id="password">
	Password: <?=$this->form->password; ?>
</div>
 
<div id="remember">
	<?=$this->form->remember; ?>
</div>
 
 
<div id="submit">
	<?=$this->form->submit; ?>
</div>
</form>

There you go: Zend_Form is your bitch.

Now that I’m finally starting to “get” the Zend Framework I’m starting to have some serious doubts on whether I made the right choice; not in choosing Zend over another framework but in choosing any framework at all. The memory usage is just abysmal across the board and after working with the Zend Framework for about a month or so it’s not entirely clear if it’s going to scale as I need it to.

When Did Performance Stop Mattering?

Which lead to the question of why.  At the moment it seems like a question of speed of development versus performance (which is ironic because Zend Framework is not easy or speedy to develop with).

<disclaimer>
To be fair, it’s not just frameworks that have an uncomfortable overhead. Just take a look at Joomla and Drupal; 2 popular content management systems with an absurd overhead. It’s just easier to focus on my current interest rather than the CMS’es.
</disclaimer>

One thing I’m having a hard time getting comfortable with is how much memory is required when using a php web framework. Out of the box both Zend and Symfony (for example) use around 5MB per request. Understand, this is without any custom code. Just setting up the MVC and Autoloader for the default views and models. Nothing impressive or useful and 5 fucking MB to run that?

After having been on the wrong end of this issue on my own code I’m pretty sensitive to how my code performs; I’ve written some nasty algorithms and watching them crumble in real time has a tendency to turn you around

Researching the issue doesn’t really help. There’s a lot of advice on how to improve the performance but it seems to always center around common sense improvements you should be using anyway.

The most touted improvement I’ve heard is that you have to use a PHP accelerator and opcode cache. I just find that response flawed but not because it’s bad advice but because it’s common sense. Yes, it’s true, but not using a framework in combination with a PHP accelerator and opcode cache is still better in my experience. All relying on those tools does is move the baseline for performance, which you’re supposed to do already, and a framework still consumes a good amount of resources on it’s own.

In my experience you get about a 50% reduction in memory usage when using something like x-cache but using the Zend Framework  still leaves a total of 2.5MB of memory usage to accomplish the bare minimum setup.

One saving grace is that hardware is cheap. Scaling with hardware is usually the go-to escape when the bottleneck is the code but it’s not without it’s own set of issues. For one thing while it’s true that hardware is cheap the labor to maintain that hardware is not. Especially if you want to maintain the server in a proper and responsible manner.

Another option, that’s really only available when using the Zend Framework, is decoupling the project from a direct dependence and not use the MVC components. In anticipation of doing this I’ve been writing a lot my recent code and projects in a style that’ll allow easy(ish) separation when the time comes.

At this point I haven’t used a framework in a production environment so all of this consternation might be for nothing. I just have a hard time accepting the performance hit of half a MB for using something trivial like a content management system (drupal) or, for example, a component like Zend_Navigation compared to the benefit. What are they actually doing to make the cost worth while?

Still another option is to just walk away from this whole OOP thing and head back to the familiar touch of procedural php and using functions and classes as more of decorators to apply than core components.  From my personal experience, and only my experience, using OOP is way more expensive than procedural. At the end of the day I need my programs to work fast, be easy to operate for my users and have a low impact on the server. How does using OOP help that?

At the moment I’m not sure how this is going to work out. I am confident it’ll be an adventure though. Hopefully, I find out how Zend will scale before a project of mine goes viral or gets popular. Hopefully.

As I’ve mentioned I’m trying to move all my programming to a web framework. It was tough going though because of the sheer complexity and my naivete about the  undertaking.

The Framework is the Language

After about a month of working with the Zend Framework I’m a little… bored with it. If this is what working with a framework is like I don’t want it (thank you very much). I, naively, thought using a framework would increase my productivity and highlight some of the joy I feel when developing and learning but, so far, all I have is frustration and a pretty heavy headache.

Since then, I’ve spent some time looking at Symfony (a fine, but overly complicated, framework), looking at Code Igniter and digging deeper into the Zend Framework. It was while doing all of that, and struggling with the enormity of learning an entire freaking framework, that a thought occurred to me; I need to look at this as learning a new language instead of learning a component.

You can’t approach learning a framework as anything less than you would when learning a new language. Anything less and you’re in for pain. After this realization the framework came together pretty quickly though it still hurt like hell.

So, what does that mean? IMO you should have total absorption; learning a framework can not be done very effectively a couple hours at a time. Frameworks are just too damn big. They have too many parts and all the frameworks I’ve looked at seem to have very different philosophies in the architectural design and structure.

The strategy I took was, and the one I use when learning a new language BTW, is to make the project my world. Everything else is gone and all that’s left is the problem. There is no break, no rest and sleep is used to further solve problems more than it is to recharge. It’s really the only way I can accomplish something as complex and challenging as learning a new programming language.

The good news is that I now feel very comfortable using the Zend Framework though I still have my doubts as to how good of a decision it is to use a framework at all (that’s another discussion though).

In my never ending quest to find a replacement for JpGraph  I’ve covered charts built using JavaScript with the Google Visualization API and charts done with SWFs using Open Flash Charts (OFS). If you’re building web apps it’s easy to just stop there and consider yourself covered. I certainly thought so; until my conscience spoke up that is.

pChart

The thought them comes creaping into my head, “Um… What about the JavaScript? How do you think those pretty charts and graphs will degrade?”.

Shit.

Not to take anything away from either of those programs; they’re very fun to work with and, relatively, easy to use. It’s just that they’re both rendered using JavaScript which is well and good provided your user has JavaScript enabled (and Flash too for OFS). It’d be a nice addition to provide an alternative when using either one of the previous programs.

This is where pChart comes in:

pChart is a PHP class oriented framework designed to create aliased charts. Most of todays chart libraries have a cost, our project is intended to be free. Data can be retrieved from SQL queries, CSV files, or manually provided. This project is still under development and new features or fix are made every week.

Focus has been put on rendering quality introducing an aliasing algorithm to draw eye candy graphics. Rendering speed has been dramatically enhanced since the first version, we’ll still continue optimising the code!

Implementation is pretty easy too:

// Standard inclusions
include("pChart/pData.class");
include("pChart/pChart.class");
 
// Dataset definition
$DataSet = new pData;
$DataSet->AddPoint(array(1,4,3,2,3,3,2,1,0,7,4,3,2,3,3,5,1,0,7));
$DataSet->AddSerie();
$DataSet->SetSerieName("Sample data","Serie1");
 
// Initialise the graph
$Test = new pChart(700,230);
$Test->setFontProperties("Fonts/tahoma.ttf",10);
$Test->setGraphArea(40,30,680,200);
$Test->drawGraphArea(252,252,252);
$Test->drawScale($DataSet->GetData(),$DataSet->GetDataDescription(),SCALE_NORMAL,150,150,150,TRUE,0,2);
$Test->drawGrid(4,TRUE,230,230,230,255);
 
// Draw the line graph
$Test->drawLineGraph($DataSet->GetData(),$DataSet->GetDataDescription());
$Test->drawPlotGraph($DataSet->GetData(),$DataSet->GetDataDescription(),3,2,255,255,255);
 
// Finish the graph
$Test->setFontProperties("Fonts/tahoma.ttf",8);
$Test->drawLegend(45,35,$DataSet->GetDataDescription(),255,255,255);
$Test->setFontProperties("Fonts/tahoma.ttf",10);
$Test->drawTitle(60,22,"My pretty graph",50,50,50,585);
$Test->Render("Naked.png");
?>

The above code produces something similar to:

pChart Linechart Example

One really cool addition the developers added was a little cmd script, buildAll.cmd, to automate the build of all the Example scripts on Windows machines. Just double click that and you’ll have all the graph images generated automatically.

It is recommended by the developers that caching is implemented but I haven’t really found the need for it yet.

A good idea, and one I’m going to be implementing, is to use charts and graphs created with OFC and create static image graphs for the noscript tags using pChart. Definitely a lot of work but it’ll add a bit of shiny to my programs. Yours too I think.

Truth: I’m a whore when it comes to books. I Just love ‘em. I love the way the feel in my hands, I love the way they smell and I love how I can just lie down with a good one and, somehow, miraculously, that makes a good day. We’ve been hearing for a while how books were going to die and be replaced by the Internet but I don’t see that happening anytime soon. You can’t hold it (no a Kindle isn’t the same), there’s no smell (except warm plastic I guess) and there’s no satisfaction reading a computer all day (in fact, it’s bad for your eyes).

Reading is Good.

I have a special leaning towards hard c0ver books though. Paperback books are good for a trip, I guess (for example a long flight or train ride). But if you want to keep that book, which I always do, then a hard cover book is the way to go. The great thing about hard cover books is that they can be purchased online through Amazon for a fraction of the cover price. There’s a reason Amazon is on top of the online book selling market and it’s not because they rape their customers (are you listening RIAA?)

It used to be that all I had to worry about when buying a book was ensuring it was the hard cover edition. I never cared about edition versions (first, second, yada-yada-yada) or anything but now I have to worry about Large Print Editions (LPE). LPE books are irritating.

Obviously, the print is HUGE. I’m sure they’re made specifically for sight challenged (blind) people but to us who can see it’s a little disconcerting reading text so big. Each page can only contain around 2.5 paragraphs of text. This makes the books big. Like really BIG. It’s irritating holding a normal novel and having so many pages to thumb through.

Apparently, I’ve been living under a  rock all my life because I hadn’t been exposed to LPE books before .

Recently, I bought a book on Amazon which I thought was going to be a nice little addition to my library. Just a guilty pleasure book but one I wanted. I was a good little consumer, making sure it was hard cover, it was being sent from a reputable seller, and that it was in English (don’t ask).

Then it arrives and I’m just bummed. Not because of the book, per se, but because now I have to worry about the format of the text when I’m buying a book.

So as I said, buying a book just got harder. A little, sure, but it’s now one more thing.

Fuck.

Oh, var_dump()… Poor, pathetic, little vardump()… There was a time when you were my favorite little go-to for debugging. Once upon a time, you were the end all be all of problem solving tools; this would be during my idiot phase of life. Not anymore though; thanks to some god (or whatever) someone smarter than me (and apparently with more time on their hands) went and invented the Debug Toolbar.

Keeping an Eye on Your Development

In case you didn’t know, a Debug Toolbar (I don’t know if that’s the universal name for it but it makes sense to me) is a nifty little widget that allows for easy access to all sorts of info on your web program. Since I work primarily in php that’s what I’m going focus on; I’m sure they’re available in other languages. Like most things; Google is your friend on this.

Usually, a Debug Toolbar contains information on included files, any sessions and cookies available, the database calls with timers and a breakdown of memory usage and performance.

Debug Toolbars usually work by encapsulating different code blocks or functions around “timer” functions to record the time it took for a block to run. All the Debug Toolbars I’ve used also included a memory component; really helps to see where the spikes are. There’s also the database integration; it’s just good sense to know where the bottlenecks are in a project.

As I said in the intro var_dump() is a handy little tool for debugging issues in php scripts. It works pretty well for small scripts but, the thing is, on larger projects it just becomes unpractical. Not only is it limited to arrays and objects but you have to manually place the call in the code and depending on the issue, you can get a HUGE amount of data back in a horrible tangle of strings. Makes XML look good.

Instead, using a Debug Toolbar, you get a nicely formatted unobtrusive way to keep an eye on how your code is performing while creating it. Needless to say, these are handy little tools.

PHP_Debug

A little disclosure: My first experience with a debug toolbar was with a really early, think pre alpha, version of PHP_Debug. PHP_Debug, at that time, worked by displaying the debug information at the bottom of a page in a table. This was definitely a step up from using var_dump(), to be sure, but it was still a little painful to decipher. Clients would complain.

Then PHP_Debug pretty much innovated the Microsoft way and copied a feature from another application; Symfony. (I kid, I kid.)

Seriously though, PHP_Debug does claim inspiration from the Symfony which I think is pretty classy of them; it seems too many times credit goes unsaid.

Keep in mind, this was the first time I saw anything like a debug toolbar. I don’t want to break down to hyperbole but to say the sky parted and angels sang would be a fucking understatement.

PHP_Debug Toolbar

PHP_Debug is perfect for those stand alone projects that are started from scratch. It’s not impossible to integrate PHP_Debug into an existing program, I’ve done it a few times, but unless you’ve abstracted out a good deal of the logic it’s going to be a little painful. Put aside a few hours if you’re going to attempt it.

The script displays the output in 2 different ways; through a floating div at the top of a page or as an HTML table displayed at the bottom of the page. Installation is pretty easy and straightforward, either as a PEAR module or as a stand alone script.

ZFDebug

ZFDebug is a plugin for the Zend Framework that acts pretty much like PHP_Debug except with a simple and easy integration into the Zend Framework and it’s quite a bit slicker. Smooth animations, version details, sticky states and full of detail. If you use the Zend Framework I can’t recommend it highly enough.

ZFDebug

There are some installation instructions which at the time of this writing are just broken though. Follow the linked instructions but use the below code in place of the code provided in the instructions:

protected function _initZFDebug()
{
    $autoloader = Zend_Loader_Autoloader::getInstance();
    $autoloader->registerNamespace('ZFDebug');
 
    $options = array(
        'plugins' => array('Variables', 
                           'File' => array('base_path' => '/path/to/project/'),
                           'Memory', 
                           'Time', 
                           'Registry', 
                           'Exception')
    );
 
    # Instantiate the database adapter and setup the plugin.
    # Alternatively just add the plugin like above and rely on the autodiscovery feature.
    if ($this->hasPluginResource('db')) {
        $this->bootstrap('db');
        $db = $this->getPluginResource('db')->getDbAdapter();
        $options['plugins']['Database']['adapter'] = $db;
    }
 
    # Setup the cache plugin
    if ($this->hasPluginResource('cache')) {
        $this->bootstrap('cache');
        $cache = $this->getPluginResource('cache')->getDbAdapter();
        $options['plugins']['Cache']['backend'] = $cache->getBackend();
    }
 
    $debug = new ZFDebug_Controller_Plugin_Debug($options);
 
    $this->bootstrap('frontController');
    $frontController = $this->getResource('frontController');
    $frontController->registerPlugin($debug);
}

Using ZFDebug is as simple as that. Once installed you’ll have a div laying at the bottom of the page with all the details you could want. Plus, it comes preinstalled with the hooks for database and cache profiling. It’s still possible to manually insert timing blocks but the hard part is already done for you.

Symfony

If you’re using Symfony you’re in luck (and none of this is probably news to you); Symfony comes with a Debug Toolbar (the original maybe?) preinstalled and read to use. All you have to do is either hit up frontend_dev.php in a browser or change:

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);

to

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', false);

in your bootstrap file.

Symfony Debug Toolbar

It’s not as robust as PHP_Debug or ZFDebug out of the box (oddly, there’s no included file reference) but it does allow for customization so it has the potential to be very informative and useful.

One last thing about Web Debug Toolbars; they aren’t a replacement for good practices. You can’t rely on them too much and sometimes your instinct will contradict the output of the toolbar. In my experience you should trust that instinct. A Web Debug Toolbar should only be used to provide insight not replace common sense.

One thing to keep in mind is to not focus too much on the

As I previously mentioned I’m using Eclipse IDE for a good deal of my php development at the moment. At first, I was a little skeptical of how much Eclipse would improve my productivity. Initially, it was kind of painful but after changing my work flow to work better with Eclipse I do admit it’s an improvement.

Eclipse IDE

My initial “look” at Eclipse was Eclipse for PHP Developers; this was on my old laptop but sine I no longer had it I had to reinstall Eclipse again. This time I’m using Eclipse standard with the PHP Developer Tools (PDT) extensions added on instead. No real reason, “just ’cause”.

First the good.

Right off, the most important and very coolest of the very cool features, is the built in function reference. I LOVE the ctrl+click feature! You can click on any function, class or method call and it will open the file containing that call. It’s really, REALLY, helpful. This feature is incredible, and one I’m sure isn’t unique to Eclipse. Still, after doing the alternative (see function, search for file with function, search for function in file and read) a feature like this is simply magical.

Hell, just hovering over an element will display the comment info if you used docblock style comments (you do write docblock comments right?).

Eclipse Code Inspector

Combining the above two features pretty much kills off a pretty signifigant portion of development; digging through code looking for something.

But wait! There’s more:

There’s also the integration with Subversion; it requires an add-on plugin to work but work it does. It’s a little confusing to use at first, but after reading How to use Subversion with Eclipse article by IBM it started to make sense. I started working with Eclipse before I dug into the Subversion integration so the change to workflow was a little disruptive at first. If you’re planning on using Subversion you should definately check out the Subversion integration before using Eclipse full time.

One last thing about the Subversion plugin; it’s written by the same guys (CollabNet) who make TortoiseSVN and Subversion itself so you can still use Tortoise if you want to. I appreciate that.

One of my first “misconceptions” was that there wasn’t any FTP or SFTP functionality. This is technically true but there is a plugin that handles this in a basic manner. There isn’t any way to work directly on the server (by this I mean, upload on save type functionality) but you can download and upload files to a server using either FTP or SFTP.

Now the petty, petty, stuff

One gripe I have is that Eclipse doesn’t syntax highlight Smarty tags; not even the HTML is syntax highlighted.

I was also hoping for some sort of customization on the syntax highlighting colors. Personally, I like the colors to be a little more vibrant than most IDEs default to. Small gripe to be sure but it would have been nice to have.

At this stage I haven’t really dug into the build process but from what I’ve read it should be able to improve the deployment work. Since I do php work I’m hoping “deployment work” means automated replication and setup. I know there’s ANT integration but having never used ANT before this is a whole other discussion.

Still, all and all Eclipse isn’t bad. Not even close. I still use EditPlus for some development, especially since there isn’t remote access, but more and more I’m finding myself open Eclipse for the real work.