Learn More About PHP And The Web Platform!

Struggling with your web server, or to scale your PHP application to meet growing demand?

Whether you're running one server or a whole server farm; whether you're hosting on Windows Server or on Linux.

Learn from Stuart's experience with system design, delivery, support and management to help you do a better job and have an easier time.

Beneath Whitby breakwater

Still Alive

Posted by Stuart Herbert on August 30th, 2009 in News.

It’s been a busy few months since I had to drop out of the Dutch PHP Conference’s PHP-on-Windows competition due to work pressures. At work, we’ve finished rebranding, launched a new corporate website, and are now starting on a review-and-polish cycle. We’ve also been kept busy finishing off the next version of our VoIP platform, migrating all of our customers onto it (just two more weeks to go!) and coping with a growth rate of 26% during the worst recession in living memory.

Outside work, my wife and I were involved in a car crash at the end of July. We’re both recovering well, although my wife won’t be back at work until at least mid-September. This has meant we’ve had to take things very easy for the summer, but I’m hoping to be back online and blogging regularly again shortly.

Be the first to leave a comment »

I’ve been running a series of polls as research for a new conference talk that I’m currently putting together. The first two polls have had over 1,200 votes between them so far, which is a fantastic response! Now I just need your help with one final poll 🙂

Please vote on twtpoll to let me know where will you get your PHP 5.3 from? Many thanks in advance!

Be the first to leave a comment »

A huge thank you to everyone who voted in my last poll about when you’ll adopt PHP 5.3, and everyone who has provided feedback on the problems caused by the way individual distros package PHP. I’ve had much more feedback than I could have hoped for! This is all useful research for a new conference talk that I’m preparing.

My next question for the PHP community is about where you’ll use PHP 5.3. I’m wondering: which server platforms you’ll choose to put PHP 5.3 on when the time comes? This new poll is multi-choice, allowing you to vote for all of the operating systems that you choose.

Many thanks in advance for your answers 🙂

Be the first to leave a comment »

As part of the research I’m doing for a new conference talk, I’m running a poll to find out when people are planning to switch to PHP 5.3. After the very slow uptake of PHP 5.0, I’m very curious to see how quickly PHP 5.3 will be adopted.

Many thanks!

Be the first to leave a comment »

I’m putting together a new conference talk, and I’d like your help and input.

Most Linux distributions ship with packages for PHP, but not everyone is happy with these packages. If you’re not happy with the PHP packages for a specific Linux distro (no matter how obscure), I’d love to hear what you think the problems are and (if possible) what the correct solution should be.

If you have something to say on this, please leave a comment below.

Be the first to leave a comment »

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 »

This is one of a series of blog posts about my experience competing in the European WinPHP Challenge 2009. Sponsored by iBuildings, Microsoft and Leaseweb, competitors are asked to build a PHP app for Windows Server 2008 and IIS 7 to showcase the FAST in FastCGI. The winner gets travel and tickets to Microsoft MIX 2010 in Las Vagas in March. My entry is Give It A REST , a SOAP <-> REST gateway.

My first problem to solve in R&D is simple: given a (possibly remote) WSDL, how do I create a piece of compiled .NET code to call the described web service? The last time I did any regular Windows development was back in the Win16 days; this is going to be quite a steep learning curve for me.

Finding The Relevant Microsoft Tools

MSDN – Microsoft’s Developer Network – is (AFAIK) the place to go to find Microsoft’s documentation for software development. Clearly, there is a lot of information on MSDN. But how do I quickly find what I need to know … when I don’t really know exactly what I’m looking for? This is a substantial weakness of the MSDN site.

In the end, I had best success using Google to search MSDN. It’s also worth looking at information provided by your SOAP service vendors; Netsuite (for example) publishes a very clear walkthrough of how to do exactly what I need to achieve too.

Introducing wsdl.exe

The .NET framework ships with a command-line tool called wsdl.exe. In my Windows Server 2008 install, it can be found in C:Program FilesMicrosoft SDKsWindowsV6.0ABin. It can do all sorts of useful things, but at the most basic level, it can create a C# source file from a (possibly) remote WSDL file:

Using wsdl.exe

If there are problems validating with the WSDL file, they appear in the output to the screen:

Example Errors Displayed By wsdl.exe

This is something I’ll need to make sure I support in the final app, where wsdl.exe will be called automatically from PHP.

As expected, it takes a few seconds for wsdl.exe to complete. The length of time depends on the time it takes to download the WSDL file and the complexity of the web service described. Rather than do this from front-end PHP code, I’ll need to trigger this from some sort of backend queue to ensure the best quality user experience. This is something I’ve anticipated, and it’s already on my R&D todo list 🙂

Examining the .cs File

I’m very pleased to say that wsdl.exe generates a single C# file containing all of the classes required for the SOAP client. That really makes my life a lot easier 🙂 It also illustrates why having auto-generated SOAP clients is so important: the C# file for the Netsuite 2009 SOAP service weighs in at a “mere” 186796 lines of code!

Autogenerated C# SOAP Client Source Code

Can you imagine having to create that by hand?

Compiling The SOAP Client

To compile the .cs file from the command-line, I need the .NET framework compiler, csc.exe. On this fresh install of Windows Server 2008, there are multiple copies of csc.exe to be found; one copy per installed .NET framework. The latest version (and hopefully the best version to use for this project) is in C:WindowsMicrosoft.NETFrameworkv3.5.

Creating a basic DLL (dynamic link library; roughly similar (but not quite) to a Linux .so dynamically-loaded library) from the auto-generated C# source code is very easy:

Compiling A SOAP Client By Hand

The result is one Windows DLL file. My next step is to figure out how to call this from PHP.

Be the first to leave a comment »

This is one of a series of blog posts about my experience competing in the European WinPHP Challenge 2009. Sponsored by iBuildings, Microsoft and Leaseweb, competitors are asked to build a PHP app for Windows Server 2008 and IIS 7 to showcase the FAST in FastCGI. The winner gets travel and tickets to Microsoft MIX 2010 in Las Vagas in March. My entry is “Give It A REST”, a SOAP <-> REST gateway.

In an earlier post, I described my experience in building a (hopefully) suitable PHP development environment on Windows Server 2008. Since then, a couple of folks have kindy sent some feedback to help improve my understanding a couple of the sticking points I mentioned.

In the Zend Forums, this post describes how to get xdebug up and running under Zend Server on Windows (via Bram). Sadly, Zend’s build of PHP still crashes after following these instructions. Commenting out the Zend Extension Manager seems to stop these crashes, but I’m not sure that’s a compromise I’m willing to make. As I mentioned before, whilst I’d normally choose to install xdebug into any environment I’m working on, it’s not a big deal for me on this project because I am interested in seeing what Zend’s environment has to offer on Windows.

Elizabeth N. Smith from the PHP Windows teams kindly pointed out that the downloads page on www.php.net does indeed offer a NTS (non-thread-safe) build of PHP for Windows further down the page. I’m planning on plundering the PDO driver for MS SQL from there and evaluating it as part of my R&D phase.

Sadly, though, I’ve not seen anything said about why there isn’t a binary standard for PHP on Windows 🙁 These binary incompatibilities just seem to re-enforce why proprietary products on proprietary platforms should be avoided.

Be the first to leave a comment »

I’m currently looking for two PHP developers to come and join my web development team at Gradwell. The team creates and maintains the web-based control panels for our award-winning VoIP service, plus our broadband, email, and web hosting services. From time to time we also get to do crazy things like Twittex and Facebook applications. Our partners often describe us as the geekiest company they ever have to deal with. And one nice bonus is that we use Linux for our desktops not Windows 🙂

The full details are on the Gradwell website, but the basics are that I’m looking for people with a computer science / software engineering degree, with PHP experience (via open-source projects is fine; it doesn’t have to be commercial experience), and experience with symfony is a major plus. It’s essential that you fit in with everyone else in the company, so you’ll need to be someone who’s proactive but supportive rather than competitive.

If you’re interested in applying, talk to me on Twitter or send through a CV and covering letter explaining why you’re the person for the role to stuart(dot)herbert at gradwell(dot)com.

Be the first to leave a comment »

This is one of a series of blog posts about my experience competing in the European WinPHP Challenge 2009. Sponsored by iBuildings, Microsoft and Leaseweb, competitors are asked to build a PHP app for Windows Server 2008 and IIS 7 to showcase the FAST in FastCGI. The winner gets travel and tickets to Microsoft MIX 2010 in Las Vagas in March. My entry is “Give It A REST”, a SOAP <-> REST gateway.

In my last post, I solved my problems with PHP not working out of the box, and finished choosing and installing apps to complete my development environment. With that done, it’s time to think about the design of Give It A REST.

Product Brief

I find it always helps to start with a short description of what I’m trying to achieve. In a larger enterprise environment, this would normally be found in the product brief written by the product manager.

Given a (possibly remote) WSDL file, Give It A REST will automatically generate a RESTful webservice bridge between remote PHP clients and the remote SOAP service described by the WSDL file. Give It A REST will run on Windows Server 2008, it will use .NET to connect to the remote SOAP service, and the RESTful webservice bridge will be written in PHP.

Throughout the project, I’ll keep coming back to this description to make sure that this is still what I am delivering.

Use Cases

The product brief is just an idea; it needs further iterative development before it’s mature enough to turn into code. Sketching out some basic use cases to identify who will use Give It A REST, and how they will use it, is a good next step. Use cases can be very lightweight (especially the ones I typically create), but they’re easy to share with non-technical folks, and they make it fairly easy to play “what-if” and “walkthrough” type games with your customers. And because they are quick to create, they save you time overall.

When I’m creating use cases, they inevitably go through several iterations. I generally start with some rough ideas for actors, explore the high-level systems that the actors interact with, and then revamp my list of actors to suit the systems and use cases that I’ve discovered. Then, with my new list of actors, I do the whole exercise again, and I keep repeating it until I feel happy with the results. It’s that emotional connection that I’m always searching for whenever I’m designing something; I’m a great believer that this is where the creativity ultimately lies.

In this case, I have decided on four high-level systems that together will make up Give It A REST:

  • I need some sort of user manager to handle user registration, login / logout, and administration of registered users.
  • A bridge manager will handle the tricky work of creating, managing and destroying individual SOAP <-> REST bridges. It will also handle administration of who is allowed to use which bridge.
  • The bridge itself will handle SOAP <-> REST requests and responses, and also provide tools for investigating problems, usage stats, and also (if possible) documentation auto-generated from the WSDL file.
  • Finally, users need a way to find the available bridges, so I need a bridge browser for that. It will also provide the mechanism for users to request permission to use a bridge.

The generic ‘users’ need to be clarified into specific actors who participate in specific use cases. Working out the specific roles that a user can have makes it a lot easier to get the permissions system right first time. The downside is that mistakes made at this stage are the most expensive of all to fix.

  • Admin users are the administrators of Give It A REST. They can do everything the app allows, without restriction.
  • Bridge owners are users who own one or more bridges. They have control over who can and can’t use their bridges. Any user can create a bridge, and so become a bridge owner, but bridges have to be approved by an admin user.
  • Bridge users are registered users who are not admin users or bridge owners. They have successfully applied for permission to use one or more bridges.
  • Registered users are users who have registered to use the app, but who do not yet have permission to use any of the bridges.
  • Finally(!) we have guest users, who need to register to use the site. Their registration must be approved by an admin user before they become registered users.

The actors describe roles, not people. People’s roles can and do change as they successfully complete some of the use cases.

Here are the use case diagrams. You should be able to click on each thumbnail to open the full diagram.

Use Cases: Admin Users

Use Cases: Admin Users

Use Cases: Bridge Owners

Use Cases: Bridge Owners

Use Cases: Bridge Users

Use Cases: Bridge Users

Use Cases: Registered Users

Use Cases: Registered Users

Use Cases: Guest Users

Use Cases: Guest Users

Strictly speaking, the remote PHP RESTful client is also an actor with use cases that could be identified and captured, but I’ve chosen to treat the PHP client as just another way that my existing actors can interact with Give It A REST.

Problems To Solve In R&D

Thankfully, the majority of the use cases are run-of-the-mill web-app functionality that are straightforward to code up. But together, the product brief and use cases have generated a number of problems that I need to solve by a little bit of R&D.

  • Given a WSDL file, how can I create a SOAP client in .NET?
  • How do I call that SOAP client from PHP code?
  • How do I capture the raw XML sent from the .NET client to the SOAP service, and how do I capture the raw XML sent back in response?
  • From PHP, can I make multiple simultaneous calls through the SOAP client to the SOAP service?
  • Because we’re using FastCGI, can I call multiple .NET SOAP clients from a single PHP process w/out memory leaks?
  • How do I automatically define a RESTful client for a SOAP service?
  • How will the security for calling a bridge from a RESTful client work?
  • How do I automatically generate documentation from the WSDL file?
  • What do I use for queueing up offline tasks on Windows?
  • How do you do test-driven coding with .NET?

It may feel like I’ve taken the long way round to reach this list, but thanks to having use cases, I’m confident that I have the right list of questions to solve during R&D. If (and right now it is an if) I can solve them all, Give It A REST should be doable.

Whether I have enough time to do it, now that is another question 🙂

Next Steps

In this post, I’ve clearly stated my initial idea by writing a very basic product brief, and then I’ve started on the long road to clarifying my thinking by creating the main use cases for Give It A REST. I don’t know whether it’s possible to achieve all of these use cases, as I’m not a .NET developer, so I’ve identified the main questions that need to be answered by a little bit of R&D.

The next step is to try and answer all of these questions 🙂

Be the first to leave a comment »
Page 13 of 18« First...1112131415...Last »

This Month

July 2018
« Jul