sunwukung

I dropped WAMP in favour of XAMPP a while ago and haven't had any issues since. I'd recommend trying XAMPP, see if that gives you any issues.

As someone with experiance of both, we've decided to go down the route of nothing but Wordpress for every site we do. This is what we were looking for:
 

A simple interface for clients to update there site.
A system that is easy and quick to expand.
A quick yet stable upgradeability (I may have made that word up!)

 
Wordpress provides all of these, where as Drupal fails on a couple of points. We have found, especially with more complex systems, that the way Drupal works is counter intuative for many of our clients. We have to have training days with each client and virtually re-write a set of instructions based on what the client wanted the website to do. We have had clients who are scared off updating there sites because it's built in Drupal. When we have shown them equivilant Wordpress systems, they have found it much easier and this really forced our hand to change. Coupled with this, the new custom content types that can be created allow us to easily create sections of a Wordpress website (which we usually do through plugins) that are tailored to the individual needs of the client. Bcause we use the plugin structure, we are then free to duplicate this work to other clients.
 
Yes, Drupal is a more flexable system in the grand scheme of things but with that flexability you also dramatically increase both development time and the learning curve of your perspective clients. Also, the upgrade path on Wordpress is a dream, so easy in fact, we are looking to automate the process as soon as we have time.
 
With Wordpress, I think more than Drupal, you also have a scaleable system. When you're new to it you can set up websites by learning how to create templates (a very easy thing to do) and using the thousands of available plugins for functionality. As you progress, you will start to modify the system via plugins and your reliance on those third party codes will decrease.
 
In conclusion, I think Wordpress is a much better entry level CMS (remembering that it's core is blogging software) which can be expanded as your compitences increase. Unfortunately for Drupal, your clients are not likely to increase there technical abilities just to fit in with your choice of CMS and so Wordpress remains the best choice for those developing for end user updatability.

Keep em separate during development - push them into one file (and minimise it) for production. A good IDE like Netbeans can reformat minimised JS back into it's original format - but failing that, keep hold of your full fat scripts for later use.

I don't really read many blogs, usually just browse through dzone and zend developer zone and take a look at anything that takes my fancy. Sometimes read dailywtf and coding horror if in need of a laugh.
 
Anyway the only blogs I make a point of subscribing to are...
 
Invisible to the eye
Phly Boy Phly
Ralph Schindler
 
+ a couple of other ZF developers
 
I guess the reason I read them is because they are by highly respected industry professionals who are in the same field as me. Most of the topics they blog about are relevant to my work.

I agree with Jock (an increasingly frequent event...) although I'd remove the need for certain topics - bitwise operations for example.
Personally, I'd be looking for someone with some good understanding of design patterns and associated implications (i.e. Dependency Injection, MVC), a competent degree of knowledge in *nix, good understanding of RDBMS - and a better understanding of how ORM features work in relation to Relational Theory (i.e. the implications of Active Record when using libs like Doctrine/Propel).
More importantly than all of this - I'd want someone that ENJOYED coding! Plenty of devs out there that just do it for the cash...

1 - Consider becoming Zend Certified - http://shop.zend.com/en/php-certification.html (it probably holds more weight than a degree)
 
2 - If I was hiring a PHP developer I'd expect them to know pretty much everything about the language, not just how to do a few things with it. I would also probably be looking for extra things like TDD, debugging/profiling knowledge, use of version control, experience with agile development methods.
 
Edit: If it was a junior position, I wouldn't expect any of the above, probably just a good base understanding of computer science and some practical examples of things they've done with PHP.

sorry but the design isnt nice. the font is hard to read, the colour is awful and the dodgy filters on every element are killing it. looks like something from a dodgy 1980's website. start again and forget about colours and filters for now. work on the structure in 1 colour, black.

Ok well the people have spoken about the visual design so I’ll go with a different tack. The idea of a logo is a calling card or a signature something that says who you are or what you do, unless you are a big brand and just plaster everywhere with the logo so they know it’s you. The logo tells me it belongs to a designer but leaves the type of design open to interpretation; if I saw it on a van i might think kitchen design. Try and pinpoint two ideas and bring them together into something that makes people go “ah cleaver”. Or tone it down and make it more professional. Hope that’s helpful.

Why is Smarty always brought up when the topic is on MVC/frameworks? Smarty has nothing to do with MVC architecture, its just a template engine.

Singletons are a bit of a marmite pattern...people who advocate Unit testing are generally against them, because they promote tight coupling to global resources which makes it hard to test classes in isolation. The need for static methods points to the real problem - resolving dependencies.
 
Singletons DO have a constructor phase where variables can get initialised. Zend_Registry (and many other application level components) use Singleton - and they get a reference via ::getInstance. You could tie the loading of a config file to that method to get the parameters you need. You could just hard code the connection parameters into the class itself. Personally, I think the solution lies elsewhere - using a Singleton causes more problems than it solves.
 
 
If you look at this problem another way, the solution may not be to make the class static, rather to have a mechanism in place to load an instance when you need it...
 
My experience is that Singletons are best used for a specific problem - providing resources globally (and is not always the best method to achieve this*). Rather than creating a Singleton to provide database connections - use a Singleton to pass an instance round your system
 

class Registry{ private static $instance; private function __clone(){} private function __construct(){ } public static function getInstance() { if( !isset( self::$instance ) ) { self::$instance = new self(); } return self::$instance; } public static function get($key){ $instance = self::getInstance(); if(isset($instance->$key)){ return($instance->$key); } } public function set($key,$value){ $instance = self::getInstance(); $instance->$key = value; } }
 
now you can set and get a database connection from the registry instead i.e.
 
 

Registry::set('dbConn',new DB_Connection($config_file)) Registry::get('dbConn');
 
Memory issues are another concern you expressed. To be honest - loading a database connection class is pretty negligible.
 
http://phparch.com/2010/03/03/static-methods-vs-singletons-choose-neither/
 
You can, however, deal with this using a pattern called Lazy Load.
http://www.devshed.com/c/a/PHP/Lazy-and-Eager-Loading-in-PHP-5/
 
*I recommend taking a look at dependency injection, but this is a whole other kettle of fish...
http://fabien.potencier.org/article/11/what-is-dependency-injection
 
I also recommend taking a look at this great site:
http://sourcemaking.com/design_patterns

Singletons are a bit of a marmite pattern...people who advocate Unit testing are generally against them, because they promote tight coupling to global resources which makes it hard to test classes in isolation. The need for static methods points to the real problem - resolving dependencies.
 
Singletons DO have a constructor phase where variables can get initialised. Zend_Registry (and many other application level components) use Singleton - and they get a reference via ::getInstance. You could tie the loading of a config file to that method to get the parameters you need. You could just hard code the connection parameters into the class itself. Personally, I think the solution lies elsewhere - using a Singleton causes more problems than it solves.
 
 
If you look at this problem another way, the solution may not be to make the class static, rather to have a mechanism in place to load an instance when you need it...
 
My experience is that Singletons are best used for a specific problem - providing resources globally (and is not always the best method to achieve this*). Rather than creating a Singleton to provide database connections - use a Singleton to pass an instance round your system
 

class Registry{ private static $instance; private function __clone(){} private function __construct(){ } public static function getInstance() { if( !isset( self::$instance ) ) { self::$instance = new self(); } return self::$instance; } public static function get($key){ $instance = self::getInstance(); if(isset($instance->$key)){ return($instance->$key); } } public function set($key,$value){ $instance = self::getInstance(); $instance->$key = value; } }
 
now you can set and get a database connection from the registry instead i.e.
 
 

Registry::set('dbConn',new DB_Connection($config_file)) Registry::get('dbConn');
 
Memory issues are another concern you expressed. To be honest - loading a database connection class is pretty negligible.
 
http://phparch.com/2010/03/03/static-methods-vs-singletons-choose-neither/
 
You can, however, deal with this using a pattern called Lazy Load.
http://www.devshed.com/c/a/PHP/Lazy-and-Eager-Loading-in-PHP-5/
 
*I recommend taking a look at dependency injection, but this is a whole other kettle of fish...
http://fabien.potencier.org/article/11/what-is-dependency-injection
 
I also recommend taking a look at this great site:
http://sourcemaking.com/design_patterns

http://en.wikipedia.org/wiki/PHPDoc

Well that gives an unfair advantage to SWK in our future Mac/PC debates. Damn Edit button.
Congratulations to you both

On first glance it looks like line 176 of your css is the problem:
 

.captionfull .boxcaption { left:0; top:186px; /* should be 514px */ }
 
should be set to the same position as this
 

$(".cover", this).stop().animate({top:'514px'},{queue:false,duration:200});

I edited that line int the browser using Firebug - and it seemed to fix the problem.

On first glance it looks like line 176 of your css is the problem:
 

.captionfull .boxcaption { left:0; top:186px; /* should be 514px */ }
 
should be set to the same position as this
 

$(".cover", this).stop().animate({top:'514px'},{queue:false,duration:200});

unless your client plans on maintaining the code themselves, there is no value difference whatever to your client in respects to what technology is provided (I mean if it was written in ADA and for-filled their requirements it would not matter).
 
What you need to look at is what these contractors will provide.
 
Fully object oriented, documented code full of unit tests, or some horrible spaghetti code that's had no unit testing and ambiguous to its actual functionality. One might be packed with useful AJAX functionality and a more robust database design, one might perform far better than the other.
 
IMH0 having some cleanly written, well documented and tested code is worth twice as much easily. It will be more maintainable, more piece of mind that it will work as specified more likely to be cheaper/quicker to fix or upgrade in the future.
 
Oh and also of course how well their designs are skin-able/template-able, how easily your html/css designs can be implemented.
 
And non of this has anything to do with the language, but how well designed and written the code is.
 
Cheers, Nick.

Nice words and sentiment but only one post that really speaks of the experience being faced by many career jumpers. Yes yes, if you have the passion, time and energy, do it. You're never too old and all that, but!
 
Like so many people who make career jumps, if you don't have the same level of skill and experience that your job competitors have then you will find it very hard indeed (speaking from years of providing career counselling and stress management support(often a big push for people to jump careers)).
 
You need to set your expectations accordingly; talk to some recruitment agencies who specialise in the field and ask them to give you an idea of where you could fit into the job market and what salary you could expect to earn. They should also be able to tell you what level of skills and experience are generally required for the level you want to be at. All of this helps give you a realistic insight into where you are now, what you can expect and the size of the hill you need to climb to get where you want to be.
 
Then you need to consider how you fund your transition. Do you need a part-time job? Do you need a full-time job and do web work in the evenings? Can you afford to take the plunge and go independent and drum up enough business? Can you offer to work for a design agency at a reduced fee whilst you are learning? This last point can be a win-win for both you and the design agency; they get a cheap pair of hands and you get much needed experience and practical learning.
 
 
I'm not trying to put you off of course, I'm just a pragmatist and I really wish you all the best and hope you get to make the career change you want.

I'm writing my own at the moment, based on a model view controller architecture. It's pretty lightweight and does only what we need it to do as a business. At my last employment we used the Zend framework, which I must admit I found to be needlessly lofty.

Wait for symfony 2.0

When you pull that code out of the database, its treated as a string. You need to evaluate that string as PHP code using the eval() function. However this practice is very 'wrong'. Its possible to serialize code and store that but again its not really recommended practice - http://uk.php.net/manual/en/language.oop5.serialization.php

Choosing a Mac has become an ideology. The creative elite, what should I have to be the best not what should I know.
 
It doesn’t change who you are, get you fantastically looking partners or print money. I use both Mac and PC and couldn’t care less which one, as it is all the same to me.

ANYTHING is better than a netbook and one with XP. Just don't believe all the Mac hype though

You need to include the jQuery timers plugin to get this working.

//use this to identify and preload your images function preloadImages(){ var images = [ 'slideshow_01.jpg', 'slideshow_02.jpg', 'slideshow_03.jpg' ]; var image_n = images.length; var frag = document.createDocumentFragment(); for (var i = 0; i < image_n; i++) { var cacheImage = document.createElement('img'); cacheImage.src = 'PATH/TO/YOUR/IMAGES' + images[i]; frag.appendChild(cacheImage); } return frag; } function timer() { $("#slideshow_wrapper").everyTime(6000, function() { nextImage(); }); } function slideshow(frag){ $('#slideshow img').replaceWith(frag); //get the new images var slideshow_images = $('#slideshow img'); var img_n = slideshow_images.length; //hide all but the first slideshow_images.first().nextAll().css('display','none'); var i = 0; $('#slideshow_wrapper').everyTime(5000,function(){ if(i <= img_n -1){ i++ } if(i > img_n -1){ //reset i = 0; } slideshow_images.fadeOut('fast'); $(slideshow_images[i]).fadeIn('fast'); }); } $(document).ready(function(){ var frag = preloadImages(); slideshow(frag); })
 
Put this markup where you want the slideshow - put in a fallback image for no JS.
 

<div id="slideshow"> <div id="slideshow_wrapper"> <img src="PATH/TO/YOUR/IMAGES/slideshow_01.jpg"> </div> </div>
 
You can see a sample here on my art portfolio site:
http://www.simianrex.co.uk

I was going to reply to your original topic about this form class but I think i got distracted with something...
 
Anyway this doesn't help your question but personally I would rather the sending logic was not in the send mail function. I would prefer my contact form page controller to be something like...
 

if($_SERVER['REQUEST_METHOD'] == 'POST') { if($contactForm->isValid($_POST)) { $contactForm->send($config); } else { $contactForm->showErrors(); } }
 
I also wouldn't want my class interfacing with $_POST directly, so I'd be using isValid as a setter method for the post vars array. Note use of dependancy injection on the send method (I would be sending it a mail configuration class $config). In this case I would actually make the mail config an extended simpleXML object, so the mail settings would be read from an XML file. You know what designers are like when they have to change PHP variables...
 
I would also take out bad words filter and write it as a plugin, so you could do something like...
 

$badwords = new Rizo_Contact_Filter_Badwords(); $contactForm->addFilter($badwords);
 
where addFilter would accept a Rizo_Contact_Filter interface. Then users could implement that interface and write their own plugins.