Tuesday, May 27, 2008

Customer Support 2.0

A few days ago I downloaded Firefox 3.0 RC1. I am very excited about this upcoming release. Firefox 3.0 performs *way* better than the previous versions and has some nice usability tweaks. That said I've also suffered a fair amount of instability since the move and Twittered my frustration to the public:


Unexpectedly after a while I got a response back from user "firefox_answers":


Now this is what I call Customer Support 2.0. I would have never actually logged a bug with Firefox nor would I have contacted them; Release Candidate or not. Most chances are that I would have just become a frustrated user. However, due to the fact that I was pro-actively engaged by folks watching Twitter not only would I most likely become a happy user but good chances that I would become a passionate user.

Note: I checked with the Firefox team and it seems that @firefox_answers does not originate from them so there must already be some passionate users out there who have taken this initiative. Just shows how passionate users will be the first to help your company succeed.

At Zend we do follow many of these types of media including Twitter and Blogs. While to my taste we still aren't pro-active enough in some areas there are several including Zend Framework where we've managed to more effectively engage the user base.

I believe no company today big or small can afford not to take a pro-active stance on customer care. Even Comcast has started figuring this out and has become pro-active on Twitter.

Here are some links to get you started:

- Technorati to watch the blogosphere

- Google Alerts to watch the more traditional Web (Web 1.0)

- Watch Twitter with Tweet Scan or Summize

In addition, make sure you encourage and empower your employees to engage in these types of conversations. I fully agree with James Governor that companies like IBM would be much better served if they participated more pro-actively in the conversation. Better to have glitches once in a while and lots of passionate users then to try and fully control (usually unsuccessfully) all corporate communications.

I am sure there are dozens of additional sites which help companies keep track of conversations related to them and their products. Please post additional pointers as comments to this post for the benefit of its readers.

Now go and create many passionate users by engaging them more pro-actively!

Wednesday, May 21, 2008

Dojo and Zend Framework Partnership Announcement

I am excited to announce a partnership between Dojo and Zend Framework. The goal is to deliver an out-of-the-box solution for building Ajax-based Web applications with Zend Framework. This is mainly targeted at users who rely on us to provide them with a best practice and an out-of-the-box experience for Ajax and don't want to have to deal with evaluating a solution (e.g. toolkits, licenses, etc.).

A big thanks to Matthew Weier O'Phinney, architect on the ZF team, who is leading this effort from our side (yes, he will still need to go through our new proposal process. No shortcuts!). Keep an eye on his blog for a more in-depth post on this effort. Thanks also to Alex Russell, Pete Higgins, and Dylan Schiemann from the Dojo team for their support.

Below is an FAQ which sheds some more light on this announcement:

Zend Framework and Dojo Partnership FAQ

1. What are the Zend Framework and Dojo Toolkit teams announcing?

Zend Framework and Dojo are announcing a strategic partnership to deliver an integrated solution for building modern PHP-based Web applications. In order to deliver an out-of-the-box experience Zend Framework will bundle the Dojo Toolkit and will feature Dojo-specific components.

2. Why did the Zend Framework and Dojo teams decide to work together?

There are many synergies and similarities between the two projects and their communities, including:

a) Licensing

Zend Framework and Dojo are both licensed under the new BSD license, allowing end users to integrate, alter, and distribute each project as they wish. In integrating with Dojo, Zend Framework continues to deliver business-friendly licensing along with its full Ajax support.

b) IP Purity

The Zend Framework and Dojo project both require all contributors to sign Apache-style Contributor License Agreements, which mitigates the risk of accepting contributions that infringe upon third parties' intellectual property rights.

c) Design Affinity

Both projects have similar design philosophies, including a strong emphasis on use-at-will architecture. Additionally, each has rigorous quality guidelines with strict unit testing and coding standards.

d) JSON Format

While Dojo can accept XHR responses in a variety of formats, JSON is the preferred response format. Zend Framework fully supports JSON for Ajax interactions, and already has a variety of helpers to facilitate data transmission via JSON. JSON is a lightweight format, can be evaluated directly in Javascript, and presents an elegant solution to the problem of data representation in XHR requests.

e) Comprehensive Ajax Solution

Dojo provides a comprehensive solution for rich web user interfaces. Many other toolkits either abstract common DOM-related actions to make remoting more efficient or focus solely on the UI layer; Dojo provides utilities for all of these.

f) Use of Standards

Dojo not only implements published standards, but also drives them. For example, members of the Dojo Foundation are working on draft versions of the JSON-RPC, JSON-Schema, and Bayeux Protocol specifications to promote interoperability among JavaScript libraries. In addition, Dojo is adopting and implementing standards driven by the OpenAjax Alliance including the OpenAjax Hub for interoperability.

g) Support

There are dedicated organizations behind both that allow customers to benefit from a fully supported stack. Zend offers support for PHP, Zend Framework and its application server offering while SitePen has support offerings for Dojo. Depending on customer demand the companies may also create joint support offerings in the future.

h) Communities

Both projects foster very strong and active communities that can support each other. Visit http://dojotoolkit.org/community and http://framework.zend.com/community for more information on how to participate.

3. What if my favorite Ajax toolkit is not Dojo? How does this fit in with your use-at-will philosophy?

Zend Framework will continue to be largely Ajax toolkit agnostic. While we will ship Dojo with Zend Framework as our preferred Ajax toolkit, only those who seek out-of-the-box Ajax functionality in the standard library will require Dojo. Additionally, we expect that the various Dojo-related components and helpers added to Zend Framework will serve as a blueprint for similar components serving alternate Ajax toolkits developed by the Zend Framework community. While we don’t have immediate plans to support them directly, we may ship such community contributions in the future.

While the Zend Framework team feels that Dojo is the right choice of JavaScript toolkit to build our Ajax experience on, it is not necessarily the case that Dojo is the right toolkit for you or your project. In addition, it may not be worthwhile to refactor existing code to standardize on Dojo. You may find that features found in other JavaScript toolkits far outweigh any benefits of our collaboration.

The Dojo Toolkit project will, for its part, also continue being server-side framework agnostic. In essence, this collaboration should not be taken as a move towards exclusivity in either project; rather, it adds features in each project to facilitate interoperability between Zend Framework and the Dojo Toolkit.

4. What components in the Zend Framework will be affected by this integration? Will any of this work benefit integration projects for other Ajax libraries?

Currently, we intend to add the following components:

o A dojo() placeholder view helper to facilitate Dojo integration in your views, including setting up the required script and style tags, dojo.require statements, and more. In essence, this work will support and enhance Dojo's modularity at the application level.

o Zend_Form elements that utilize Dijit, Dojo’s widget collection and platform. This will simplify creation of Zend_Form elements that can be rendered as Dijits. For instance, highly interactive widgets such as calendar choosers, color pickers, time selectors, and combo-boxes will be provided in the initial integration project.

o A component for creating dojo.data-compatible response payloads. dojo.data defines a standard storage interface; services providing data in this format can then be consumed by a variety of Dojo facilities to provide highly flexible and dynamic content for your user interfaces.

o A JSON-RPC server component. JSON-RPC is a lightweight remote procedure call protocol, utilizing JSON for its serialization format; it is useful for sites that require a high volume of interaction between the user interface and server-side data stores, as it allows exposing your server-side APIs in a format directly accessible via your client. Dojo has native JSON-RPC capabilities, and Zend Framework will provide a JSON-RPC implementation that is compatible with Dojo.

These features will be added to Zend Framework; no components will be re-written to make use of Dojo.

With Dojo support in Zend Framework, we hope to see ZF community contributions that follow this blueprint to add similar functionality for other Ajax toolkits.

5. I have feedback regarding the proposed method for integrating Dojo and Zend Framework. How can I deliver this feedback?

The Dojo integration will undergo the standard Zend Framework proposal review process. Please watch the main developer’s mailing list in the coming days for a proposal. You will be able to give feedback as with any proposal.

6. Could I contribute support for my favorite Ajax toolkit to Zend Framework?

Absolutely. However, we will only officially support Dojo components for the foreseeable future.

7. Will Zend Framework ship Dojo?


8. Is Zend joining the Dojo foundation?

Zend has signed a corporate CLA with the Dojo Foundation in order to enable Zend staff to contribute to Dojo as needed and has begun the process of becoming a new Dojo Foundation member.

9. Is the Dojo team joining Zend Framework as contributors?

Yes; the Zend Framework project already has CLAs on file for Dojo contributors.

10. If I have signed a Zend Framework CLA will I be able to contribute to the bundled Dojo library?

We will not allow contributions to the bundled Dojo library through the Zend Framework project. We will bundle the latest, unmodified version of the Dojo library in Zend Framework; all contributions to that library should be done through the Dojo Foundation according to their policies. However, we may create custom modules to extend Dojo that contain contributions from Zend and the Zend Framework community. The Zend Framework team does not expect to ship custom extensions as part of our initial Dojo integration project.

11. What license governs Dojo?

It is dual licensed under the modified BSD License and the Academic Free License version 2.1. For details see http://dojotoolkit.org/license

12. Will Zend Studio add support for Dojo? Will Zend Studio also support other Ajax toolkits?

Zend Studio will continue to enhance its Ajax support in upcoming versions. As part of these enhancements it will likely also support individual toolkits including Dojo. We are evaluating enhanced support for Dojo widgets used in Zend Framework components.

13. I have questions which you haven’t answered in this FAQ. How can I ask them?

On Tuesday May 27th Zend Framework and Dojo team members will hold a joint Q&A webinar. In the webinar the Zend Framework team will deliver a short overview of the proposed integration. Following this short presentation we will open up the Webinar to questions from the audience. In addition, Zend Framework and Dojo community members can email the main development lists of either project.



Monday, May 19, 2008

Twitter, please fix your app!

Tried to follow the php|tek twitter but as has been quite typical lately the Twitter service continues to be sporadic.


I partially agree with Blaine Cook's blog post that languages per-se don't scale on their own. However, there are two things that immediately jump to mind:

a) It is much easier to find people who have actually scaled PHP applications, especially in the bay area.

b) Over the past years PHP and its extensions have undergone a lot of tuning to enable them to scale more effectively. This includes optimizing file system access, memory management and various other sub systems which will ultimately affect throughput.

Twitter team: If you have interest in considering PHP (and Zend Framework) drop me a note.

Friday, May 16, 2008

Zend Framework May Update...

Yesterday, May 15th, we released a maintenance release of Zend Framework. 49 issues were resolved in this 1.5.2 release. Thanks to all contributors and the ZF team who made this happen. This reinforces our commitment to high quality and we will continue to release periodic mini releases on an as needed basis.

Not only is the Zend Framework user base growing rapidly but we are also seeing a sharp rise in adoption of ZF in business-critical commercial applications. Recently we posted two new interesting case studies including one on Indianapolis Motor Speedway who standardized on Zend Framework and Zend products. Another interesting story is IGN Entertainment, a division of Fox Interactive Media, for who the ZF's use-at-will architecture was a key factor in making the choice of Zend Framework.

I am looking forward to php|tek where I will be giving the opening keynote this coming Wednesday. I will be talking about a variety of topics related to PHP, the eco-system and the broader market changes we are experiencing. I will also be talking about a new RIA related project we have been working on in the Zend Framework team. So stay tuned... For those who can't make it we will be putting out further information right after the keynote. And no, we are not building yet another JavaScript Toolkit :)

Last but not least we have just recently worked on improving our contribution process. We believe the new process will make it easier to contribute to Zend Framework while not having to compromise on quality. As a result we have also moved many proposals forward in the review process and I believe we will see a lot more code contributions in the coming weeks.

Until next time... Happy ZF'ing.

Monday, May 05, 2008

CommunityOne Talk - Technical Problems

My talk at CommunityOne was disappointing. I was planning to show a demo which demonstrates both some of the initial Zend Framework Ajax support and also a prototype of server-side push which we've been working on. Unfortunately Vista was unable to project. I have no idea why but it was constantly giving me errors. After about 15 minutes of the technical staff and myself not being able to resolve the issue I did the presentation sans-demo on a Sun machine which was running XP. Also as a result of not using my machine I didn't have ZoomIt available which made it hard for the audience to see the code I was showing.

The audience was very courteous though and waited for me to get started. It was also nice that about 50% where PHP users and about 50% had Web-based MVC experience. A balanced setup for a talk which covered PHP, Zend Framework and Ajax/PHP interoperability including scalability and server-side push.

Besides the technical difficulties the talk went fine but I am sure there was some disappointment in the audience.

I apologize for the inconvenience and am planning to put up the slides and a recorded version of the demo within the next couple of days on this blog so stay tuned. I'll also try and make sure I add a comment on the CommunityOne site once they are up if I manage to figure out how :)

In any case, for those who read my Upgrading to Windows XP blog post, my new Lenovo with pre-installed XP has already been ordered but it'll take 2-3 weeks to actually make it here.

Sunday, May 04, 2008

Launched andigutmans.com

For years I've wanted to run a personal Web site but never found the time to do it. A couple of weeks ago a few Zenders and I started leasing a dedicated server which gave us each a bit more hosting flexibility. Once we got the machine up and running I decided it was finally time to actually launch my own personal Web site.
I browsed the Web for a nice design and once I found one I used the little free time I have, after the kids go to sleep, to start building the site.
I got started with Zend Framework and a combination of Zend Studio for Eclipse and vim. For now it's a very simple site but I do plan on extending it over time as time permits.

What I'm using:
- Zend Framework MVC - Matthew did a great job on this. I assure anyone who starts using it will become addicted. Especially useful are the view helpers which make it dead easy to share presentation logic across pages. In my case that included the logic for the navigation menu and the Google analytics setup.
- Zend_Gdata - Google's official PHP SDK for the Google Data APIs. This component is actively developed and maintained by the Google team and works great. I use blogger.com for my blog and didn't want to migrate it to my Web site. So thanks to the Zend_Gdata component and little effort I am exposing the most recent entries on my personal Web site.
- Zend_Cache (Zend Framework's caching API) - Caching can't get any easier than this. I use it to cache the blog posts fetched via the Google Data Web service and set a TTL.
- Twitter Badge - Gives you the ability to embed a Twitter feed on your Web site.

That's about it. Most of the Web site is pretty static. It's still a bit boring right now but I am looking forward to building on top of this. If you have any feedback and/or suggestions please let me know.

Update: Click here to get to the site...

Thursday, May 01, 2008

Follow-up to recent Java post...

Note to myself - Don't publish a blog post which is likely to get broad feedback before going on holiday :)

My recent post "Java is losing the battle for the modern Web. Can the JVM  save the vendors?" has made its way through the blogosphere and I have received an overwhelming amount of both positive feedback and criticism. It also spawned some interesting threads on several forums including on one of the most popular Java community sites, TheServerSide.com, on entwickler.com, one of Germany's most popular developers sites (lucky I speak German) and on a large amount of blogs.

As I can't answer all the feedback I received I do want to at least clarify a few points.

Foremost, it is important to understand that this was not a general attack against Java as a language. There are many benefits to Java and many tasks which I would use Java for. Also despite me being primarily a C/C++ developer at heart a lot of PHP 5's object model was inspired by Java as it is significantly cleaner and more elegant than what you find in C++ (*duck*). However, I do also have experience in writing J2EE applications including managing teams of Java developers on large scale projects with the good and the bad. Am I the best Java developer on the block? No. But I do think I have spent enough time with J2EE (oops, sorry, Java EE) and with customers who are significantly invested in Java to have a good idea of its advantages and disadvantages.

Without reiterating what I said in my previous post the blog post by Coach Wei, CTO of Nexaweb really sums it up. Like it or not, agree or not, dynamic languages on the LAMP stack in all of its permutations have captured the modern Web for many reasons which I already mentioned in my previous post.

In addition, we are seeing a large number of our prospects choose PHP due to huge cost savings and availability of resources (both in house and application development firms), with the understanding that LAMP-based architectures are proven and deployed both on some of the most scalable Web sites (e.g. Facebook & Yahoo!) and in mission-critical Enterprise environments (Fiat pushes 5 billion Euro through a PHP application every year).

So if this is a proven paradigm, with a huge community, why are the large Java vendors so focused at the JVM as opposed to embracing hybrid applications with LAMP and Java side-by-side, e.g. LAMP for the Web application and Java for the back-end transaction management, service bus, etc...? As I mentioned I don't believe the answer is as much the good of the customer as it's a matter of control. The investments some of the vendors have made in deploying and managing to the JVM are significant.  Their sales reps would be frustrated if dozens of their products which significantly increased the Java EE deal size would now not be relevant to the LAMP-side of the house. So at the end of the day I believe it ends up being a financial decision for the vendors and not what would most benefit the customer.In my previous post I pointed out why I think ports of the popular dynamic languages to the JVM will not deliver the same result as supporting the native versions and joining those communities.

P.S. answers to some of the feedback which repeated itself:

- Some readers understood that I was saying that multi-cores only benefit PHP and not Java. My comment was misunderstood.In the past, the Java vendors believed that the lack of multi-threading support in dynamic languages would not enable them to take advantage of technologies such as hyper-threading. My point was that now that the industry is primarily investing in multi-core technologies (because unfortunately they can't figure out how to make CPUs any faster) this disadvantage goes away. I realize that Java can also take full advantage of multi-core technologies.

- I got feedback that the stability advantages of the LAMP stack are only relevant if you have bad developers. Not only do I believe that appealing to less experienced developers is a huge advantage (which Microsoft has also traditionally enjoyed) but I don't subscribe to the notion that experienced developers don't screw up. There are many experienced Java EE developers who open threads in the app server when they aren't supposed to because it's the most sane way of achieving a task, have a synchronization blunder, or have forgotten to release a reference to some data. Developers are not perfect beasts and never will be so my point was that the LAMP architecture does protect you from many of these issues as a result of its shared nothing architecture.

- I was asked when Eclipse would be written in PHP. Again I am not opposed to Java on all fronts but mainly feel it's got a low ROI when it comes to modern Web applications. At Zend we use Java for our Zend Studio product line, and in general, the reason why PHP has been so successful is because we only focus on doing one thing - powering Web applications.

On Monday I'll be giving a talk regarding PHP and Rich Internet Applications at CommunityOne. Feel free to catch me after my session...