Came across a second Microsoft-sponsored competition aimed at showcasing PHP on Windows. This one is for Canadian residents, and is headlined ‘The Ultimate Coder Battle‘. The premise is quite interesting: one student and one professional developer will be the chosen finalists, and they will battle head to head at the “Make Web Not War” conference. The winner walks away with substantial cash prizes – $5000 with another $5000 in bonus awards available. Entries close 3rd June.
After many many years of pushing ASP and ASP.net, I’m finding it fascinating to watch Microsoft push Windows as a viable platform for publishing PHP applications. Although PHP apps on Windows have been viable for many years (provided you ditched the fundamentally-flawed ISAPI approach and stuck with the slower-but-stable CGI route), I think it’s great to see the improvements that are being made both to PHP and IIS. From personal experience, I know it can be very difficult to sell PHP-based apps into organisations that choose Windows; being able to point at Microsoft’s support for PHP is a good thing for the ISV community.
Be the first to leave a comment »
When it comes to IDEs for working on PHP projects, I’ve been a relatively happy user of phpEclipse for several years. (Tried Zend Studio, but never managed to convince Zeev about how much it sucks). But when the guys in the office started switching over to Netbeans, I thought it would be interesting to take a look for myself.
I’ve been using several of the nightly builds on both Linux and OS X for about a month now, after reading on Planet PHP about the UI improvements vs Netbeans 6.5. Apart from one bizarre problem, in general the nightly builds have performed well; I haven’t come across any major bugs in the builds. I don’t care about integrated source control, deployment or Apache management. What I care about is a solid IDE that saves me time, and helps me quickly work with larger PHP projects where I’m not yet intimately familiar with the code.
- Performs well enough … keeps up with my typing.
- Code completion works more often than not.
- Doesn’t have the annoying lockups that Eclipse-based editors suffer when they decide to rebuild the project.
- Code refactoring (BIG time saver) worked every time I tried it.
- A real memory hog – my copy is using half a gig of RAM with just 4 editor tabs open. Ignore the memory usage that displayed inside Netbeans itself (which currently claims 99MB being used); it’s either selective in what it monitors or is just plain fubar.
- Doesn’t use any native controls on OS X; looks fugly and doesn’t mimic standard OS X dialog boxes or behaviour.
- Too many dialog boxes; UI could be simplified with in-place editing or just skipping the dialog box completely (a la phpEclipse).
- No shortage of time-wasting UI design, such as not auto-populating the Find in Projects search field.
- No context-sensitive help on F1.
- No bundled documentation for PHP itself.
- xdebug support no use to me. I was unable to debug a CLI script, and I was unable to debug a website unless I went through the website’s homepage first.
- phpUnit support no use to me either. To use phpUnit from inside Netbeans, it requires all the tests to be in a separate folder tree. I choose to keep my tests in the same folder as the code under test.
I did find one bizarre problem with it. I was editing code stored on a networked drive whilst on the train, and I went through a blackspot which caused the networked drive to become disconnected. Netbeans did the sensible thing of marking all the open files as read-only, but once I had re-attached the networked drive, I couldn’t then save these files at all. Fair enough, I thought – I’ll just open the file again in another tab and copy and paste my changes across. Sadly, Netbeans wouldn’t actually copy the content of the read-only files into the clipboard at all.
Overall, I feel that Netbeans is a good editor, and I’m still using it every day on Linux (but not on OS X). The IDE features that relate directly to code all appear solid enough. The issues with phpUnit aren’t a big deal for me, but it would be nice to see the xdebug support overhauled and made useful one day.
Just a shame they can’t do anything about the fact it uses Java … 🙂
Be the first to leave a comment »
If you’re a regular reader of Planet PHP (and if you’re not, you should be), you’ll know by now that today (March 24th) is Ada Lovelace day. The idea is to throw a spotlight on female role models in tech, in order to encourage more women to get involved in technology work and roles in the future.
The need to do this was made very clear when I sat down to put this post together. I’m sad to say that I simply don’t work with any women in technology atm, and I’m struggling to think of any female programmers that I’ve worked with over the last 18 years. (I’ve sent Sara a patch or two for runkit, but I don’t think that counts as having worked with someone). I’ve worked with female product managers, project managers, and marketing consultants, but with only one notable exception I wouldn’t say they worked in technology, but around the male-dominated teams who did.
The research that has inspired Ada Lovelace day talks about women having a stronger need for suitable role models than men do. But the question that’s been praying on my mind today is this: what else do we need to do to make working in technology more appealing to women? Leaving aside the behavioural problems in male-dominated environments for a moment, are there changes to technical tools and practices we could make that would play more to the psychological strengths of women?
Be the first to leave a comment »
The motivation for this blog post came from reading an article today touting the meme that cloud computing is coming. That’s the message from Sarah Perez over on Read/Write Web. The “classic geek” (which presumably includes many of the folks reading this on Planet PHP) will no longer be the ones “working with the CEOs to execute the vision and direction via information technology,” according to Sarah.
Presumably because the companies will have gone bust from a lack of good leadership. Something we’ve seen before, and will see again.
The successful IT departments in the sort of larger organisations that can provide food and shelter for your true “classic geek” have been part of the business for the last decade, if not longer. Before we had the sexy CTO and CIO titles, there were IT Managers and Operations Managers who did all this stuff with little fan-fare and trumpet blowing. They did it on a budget, so they had to have financial management skills. They managed staff, so they had to have people skills. They delivered results, so they had to have project management skills. They made sure the business could do its job, so they had to have quality assurance skills. They implemented approaches such as ITIL and more lately CoBIT to ensure that the IT department was aligned to the business and relevant regulation. And they did this whilst still groking computers. In fact, they did this because they groked computers.
I’ve seen this sort of nonsense before when Java came on the scene, and the rise of the Web 2.0 blogger means I’m seeing it again. “Everything is new, everything is different; the old skills and the old lessons no longer apply, so don’t bother learning them” – that is the seductive siren call. Any student of management history can trace this echo back hundreds if not thousands of years. The core skills of good governance – direction, organisation and supervision – have not changed. You can read the works of Confucius from over two thousand years ago, and the principles behind the lessons for the leaders of the time are no different than the principles behind the lessons for the leaders of today. Practices have changed, but not principles.
There are no secrets, no short-cuts for those-in-the-know; not in business, engineering, or the arts. You have to know the basics, and you have to do the basics. Hard work and dedication is always the key, and you won’t find a single leading member of the PHP development team who doesn’t reflect that reality.
So what does this have to do with our favourite punch-bag here on Planet PHP, Ruby on Rails? For me, the rallying call of Rails is different from the Java and Web 2.0 hype/bullshit machines. I cringe every time Terry takes a swipe at it. Whilst I’m as sick of the term ‘agile’ as can be, Rails doesn’t try to claim that the old skills don’t matter. Quite the opposite. What they have done is to take the old skills and put them into one approach that can, and does, really work exceptionally well for a lot of firms and a lot of problems. They’ve worked out what the basics are, and they’ve designed a whole paradigm that ensures the basics are done well. They’ve executed in a way that the PHP community should be in awe of, not taking the piss out of.
They are years ahead of us in so many important areas, and yet PHP is thriving more than ever. They must have done something wrong, because they sure didn’t grow the market for web applications. What did they do wrong?
The fundamental mistake the Rails designers have made, and one that they still haven’t groked en-mass that I can see, is architectural, not philosophical. Rails is a classic application server, with all the deterministic, concurrency and big-iron-needed-here problems that stopped J2EE from squeezing out PHP at the turn of the century. For many of the problems of the web, the PHP execute-again architecture has repeatedly been proven to be superior to the application server architecture.
- PHP is easier for average-skilled folks to deploy. What’s the point of creating applications if you can’t figure out how to run them anywhere but your bedroom?
- It is easier to track down and eliminate bugs in PHP applications. No persistent processes mean that PHP applications are deterministic. PHP code is also much simpler to work through and debug.
- It is easier to scale applications written in PHP. Folks have done it, and other folks have repeated it. The Rails community as yet has not.
- It may be quicker to create applications in Rails, but the operational costs once the application goes into production quickly erode that advantage. If you’re not in the US, servers cost real money, and application servers need more iron than the equivalent PHP code.
The Agile community likes to talk about “smells”, so how come they don’t see something like mod_rails and gag on the stench of trying to mask architectural failings with such cleverness?
Before I make it onto Terry’s Christmas card list, I should state that I firmly believe that Ruby itself is a programming language that is vastly superior to PHP, especially when you get away from Apache and are creating the behind-the-scenes plumbing required. The OO in Rails continues to leave PHP for dead, and OO brings many advantages to a thriving development community. There are real advantages to being able to share code between both the must-be-real-time web front-end and the non-real time backends, and to be able to easily reuse whatever external open-source libraries save you time and effort. And I believe that solutions such as the Ruby gems are vastly superior to PEAR and PECL. PEAR/PECL should have been our CPAN, or our RubyForge. They deliberately chose not to be, wrongly believing that CPAN was a negative feature of Perl. They believed that one high-quality solution would prove the superior model over time. They failed to execute, and the paradigm was plain wrong in the first place.
My prediction is that a Rails-like framework, but built using a PHP-style mod_ruby and execute-again architecture, would have a real chance at displacing PHP. RoR the application server hasn’t a snowball’s chance in hell of achieving that. Their market firmly remains the same market that .NET and Java already fight over, and it’s a market they’re very welcome to.
Be the first to leave a comment »