Next Tuesday night we’re excited to have WebSphere guru Roland Barcia introduce the latest PHP and Web 2.0 capabilities in IBM’s WebSphere sMash environment (built on Project Zero) to the New York PHP community:
It supports the Groovy language, familiar to Java programmers, and PHP for access to thousands of PHP applications and libraries,and the huge PHP developer community.
Partners and community have found that by combining PHP applications and libraries with new code written in PHP or Groovy for the IBM WebSphere sMash platform, they can achieve significant reduction in development time for Situational Applications and Mashups.
We cover an overview of the PHP support in IBM WebSphere sMash and the support for generating new PHP code before exploring more detailed scenarios demonstrating PHP applications being extended, integrated and mashed up.
Here’s a little background on how sMash relates to Project Zero (you can find more info on the about page):
- Project Zero experimental builds (latest are named LeMans and Sebring). Includes the latest/greatest functional enhancements, tools, and bug fixes that haven’t yet made it into the generally available product. No-charge for development and limited deployments. Support via the Project Zero community.
- WebSphere sMash Developer Edition – includes tooling as well as the stable, production-ready runtime. No-charge for development and limited deployments. Support via the Project Zero community.
- WebSphere sMash – same stable, production-ready runtime as WebSphere sMash Developer Edition, but warranted & licensed for full production deployments. Available for purchase from IBM. Support available via the Project Zero community and 24x7x365 voice & electronic IBM support included with each new license purchase.
On a personal level, I’m excited to learn more about the PHP capabilities at this meeting first hand. I had a chance to work with sMash recently on an internal situational application. It used Groovy however, not PHP.
There’s also a slew of articles on developerWorks to learn about writing apps for sMash. In particular, Introducing IBM WebSphere sMash, Part 1: Build RESTful services for your Web application is a good place to start.
Back to the NYPHP meeting, please make sure you RSVP at least 24 hours in advance, by 6pm ET on Monday, April 27th for the meeting Tuesday night.
Hope to see you there!
The network is the computer… finally? It seems that Sun’s motto comes full circle, and perhaps confirms their business plan all along.
I attended Sun’s CommunityOne East in Manhattan last Wednesday and cloud was the word of the day. It was also an apt term to describe IBM’s vague overture towards the hardware/software stalwart that morning.
I didn’t walk away from the conference with specifics about the new buzzword, but I do appreciate that it captures some of what IBM has been doing, and therefore reveals a rare bit of consensus among the major vendors:
- Software as a Service (SaaS). For example, Bluehouse.
- Middleware as a Service, for example DB2 on WebSphere available on the Amazon cloud.
Other notes from the sessions I attended:
- OpenESB: Connecting Enterprises: Sang Shin is an excellent instructor and firmly placed three technologies I’m evaluating for some current business needs… BPEL, WSDL, and SOAPui. Despite the compelling demo of NetBeans, I missed the actual server side / asynchronous implementation that is the promise of the ESB.
- GlassFish v3, OSGi, Java EE 6 Preview and Tools (Eclipse, NetBeans): JEE 6 was introduced in the context of GlassFish 3. There still seems to be some work to get the standards settled any time soon for implementation in WebSphere 8. I look forward to the annotation-based and modular approach of the new standard.
- Dynamic Languages: The Next Big Thing for the JVM or an Evolutionary Dead End? Chris Richardson reaffirmed some of my observations about Groovy… while cool, it may be the overly rebellious offspring of a middle-aged Java; Brilliant in flashes, but not quite predictable enough to bank on. Scala, however, seems to have lots of promise.
I ran into an issue today that I couldn’t find an existing answer to. Hopefully this solution helps anyone else who’s still using Struts 1.x and running into errors when uploading large files through a Web form. It’s a setting for the Apache Jakarta Commons FileUpload library that Struts uses rather than internal to Struts itself.
Occasionally during the submission of forms I’d see errors in the console which began with the following stack trace.
Code)) at org.apache.commons.fileupload.
You might think that it makes sense to increase the buffer size to fix a problem like that. You might even try increasing any of the other Struts RequestProcessor settings.
In retrospect it makes sense that you don’t tell something to allocate more of a resource that it can’t already get enough of, but it took me a cup of coffee or two to realize I had to reduce the buffer size, not increase it.
Anyway, lesson learned.
“bufferSize – The size (in bytes) of the input buffer used when processing file uploads.” Lowering this may affect performance, the documentation says, but that’s a better option than having it not perform at all.
“memFileSize – The maximum size (in bytes) of a file whose contents will be retained in memory after uploading. Files larger than this threshold will be written to some alternative storage medium, typically a hard disk. Can be expressed as a number followed by a “K”, “M”, or “G”, which are interpreted to mean kilobytes, megabytes, or gigabytes, respectively.”
Default <controller> element in struts-config.xml:
What I tweaked to eliminate the error.
Your mileage may vary.
I’ve explored a few PHP frameworks for some new application prototypes recently.
Normally when I build sites, I prefer to have full control over the codebase, but with short deadlines and the abundance of new frameworks available, I’ve found that pre-built infrastructure code for handling the plumbing common to all applications makes it easy to get new concepts up and running.
In short, it’s getting easier to leave most of the drudgery of building PHP applications to the framework, and spend more time developing the logic behind my applications.
Two of the more interesting frameworks are CakePHP and CodeIgniter. Both are modeled on Ruby on Rails and adhere to its “Convention over configuration” principle, meaning they are ready to go out-of-the-box with little initial setup and take a very pragmatic approach to Web development.
They also support MVC architectures, so they simplify maintenance and separation of concerns between modules of code. This is all in addition to simplifying security, data-mapping, and rich user interface development.
While I see CakePHP as the more fully featured framework, CodeIgniter seems to have it beat when it comes to the initial learning curve, so it’s what I’ve been using more often.
In any case, I look forward to using these frameworks more in the coming year (and to make good on my promise to enable CakePHP for DB2).
If you’re a PHP developer and still building applications from the ground up, you owe it to yourself to check out the many framework options now available. You can’t go wrong by starting with one or both of these two frameworks.
Peter Seebach returns with another crotchety installment of his “Cranky User” column at developerWorks. :)
A couple of my favorite points:
A shocking number of people still believe that Web pages should be designed to run only with the most common browser, because that way more people can use them. This is ridiculous; if a page works with every browser more people can use it!
Search engines go a long way toward bringing users to your site, but only if your pages are navigable by spiders. That means adding a few plain old links to the brilliant, enthralling, and genuinely challenging flash video game you use for site navigation.
Migration guides and abstraction layers abound, but you may still run into some interesting behavior when porting or trying to run your queries from PHP for both MySQL and DB2 databases. To address some of these quirks, I’ve put together some tips for writing database independent PHP applications.
I first heard about OpenLaszlo last summer, but the goofy name immediately kept me from looking at it. After reading a slew of developerWorks articles, however, I got some encouragement to give it a chance.
- OpenLaszlo: An XML Framework for Rich Internet Applications (PDF)
- Learn Laszlo in 10 Minutes
Like Jeffrey Zeldman, I was hesitant at first, but since I’m no longer primarily a front-end Web developer I’ve got no qualms.
Anyway, if something’s broken, please let me know. Though I suppose that would require a working contact form. Doh.