Even though there are others idea that have tried accomplishing the same goal as HipHop for PHP, I believe it is quite safe to assume that Facebook has a large enough user-base to produce code that is solid enough to run and can run well.

The announcement has been made on the Facebook blog earlier today, and tonight there is going to be the video tech talk that everybody can watch:

This evening we’re hosting a small group of developers to dive deeper into HipHop for PHP and will be streaming this tech talk live. Check back here around 7:30pm Pacific time if you’d like to watch.

A few questions come to mind even though we haven’t seen the code just yet. My main concern though is the one of buffer overflows and the security implications of turning PHP code into C++. As they say on the blog, it took nearly 18 months before having a relatively stable version and 3 developers. This is a very short lapse of time to develop a solution used by so many.

Another interest of mine related to this release is how does it compete with the likes of phc or roadsend php. If it does at all.

However I have noticed on their blog that Facebook has also developed HPHPi which seems to let you use HipHop but without having to actually compile your code before running it (The concept seems a bit like APC’s stat on and off switch from the few lines of description), which seems like a quite interesting idea for the development stages.

In an attempt to identify the reasons why the speakers presence is so repetitive, I nailed it down to the diffidence factor. Today we were discussing about the community on IRC and the issue of low amount of new speakers came up again. So I’m bringing the idea back up to the surface

Many new speakers are scared of coming forward either because they think their ideas are plain bad, they don’t have enough content, they are scared to speak in front of a large audience or simply don’t have time to organize a full length session. Lightning-talks were made to try and overcome those issues however the “speaking in front of an audience” problem remains and some people need to validate their ideas before throwing themselves on stage in front of a 100 people.

In a breeze of imagination I hereby present to you the idea of “speed-speaking” which is basically “speed-dating” for speakers.

The rules are simple:

• 10 tables of different size and shapes (between 6 and 12 seats)
• 1 new speaker per table (That’s 10 new speakers)
• 10 minutes super-lightning talk
• 2 minutes Q&A per table
• 1 minute to change table between the 10 minutes

This result is more or less a hundred and thirty minutes  (say 2 hours), 10 speakers which get the chance to express their ideas, very simple Q&A, contacts are made, speakers loose their speaking virginity and they get out there, more press coverage for the event (imagine if anyone would put up a simple post about each 10 talks), new speakers and out of those at least 1 has to be a good one that will either come back the next year or become a quality speaker due to the confidence boost and experience he just gained.

What I am looking for with this blog post is to gather your feedback on the idea. Is is something conference organizers would be willing to try? Maybe an uncon version? Give me your ideas, changes, thoughts. I’m sure we can find new quality speakers with this

FRAPI handles standard API things like authentication and data formatting, and speeds up the API development process — like the way ZF or Symfony for PHP, Django for Python, JQuery for JavaScript (or, I suppose even Ruby on Rails ;-p ), does for other technologies.

David Coallier put together a quick 5 minute screencast to show you how you can use FRAPI to start building your API.

FRAPI is about to go into closed beta and we already have a nice list of developers building up. If you’d like to be part of our closed beta release, you can sign up on getfrapi.com.

This article is a major Kudos to the CouchDB developers. In particular I would like to thank Jan Lehnardt, Paul J. Davis and Robert Newson from the CouchDB fame. Let me explain why…

For all the skeptics (As I was and still am with some concepts) I have to admit that jumping both feet into CouchDB is scary, especially coming from an RDBMS-core background. I think in joins, I see relations, I’m a normalized database person. Coming with the idea that de-normalization can actually be ok if it’s done correctly was hell for me.

So the first things we did when using Couch was creating databases, until then, in my head, using “many” databases was always a big no-no simply because it was making management of connections and everything hectic. However, with CouchDB it’s a bit different and that’s a concept that Jan helped me understand and it can indeed be correctly done if planned thoroughly.

After finding myself in many dead-ends after starting CouchDB, the previously mentioned helpers were always there even for the simplest, most ridiculous questions I could have answered myself by re-reading my questions.

Imagine the following scenario where you have a list of documents that have two fields. “time” and “type“. the “type” field can be either “love” or “hate” and and “time” field is a unix timestamp (php -r ‘echo time() . PHP_EOL;’).

We need to create views in order to retrieve the data. The first scenario involves counting the amount of types. So how many documents with type “love” and how many documents (entries) with the field type with value “hate“.

You will mostly likely have to do a reduce function as well as your view. So using futon you can create your simple view that’ll look like such:

View:

1
2
3
4
5

function(doc) {
    if(doc.type) {
        emit(doc.type, 1);
    }
}

and your reduce function to look somewhat like:

1
2
3

function(key, values) {
    return sum(values);
}

Now Save this as design document “example” and view name “countdocbytype“. (See image below)

This is all very nice but what does that give you the ability of doing? Remember that “WHERE type = ‘get’” in SQL? Well now that you saved that view you can effectively search on the key you are returning in your emit() function. In this case you are returning the doc.type thus “hate” or “love” which means that if you want to get a count of type “hate” you will invoke your view as such:

http://localhost:5984/databasename/_design/example/_view/countdocbytype?group=true&key=”hate”

Remember that this is all JSON lovin’ so the key you are passing has to be JSON encoded (So key=”hate“ instead of key=hate). This view (Query for SQL people) will return a count of entries/documents with the field “type” that has the value “hate”

For the second example let’s introduce a new field in our documents, let’s name the field “phone” and it’ll be “iphone” and “android“. Update your documents and put as many “iphone” and “androids” as you want. The next example is going to be finding how many people hate iphones (This implies searching for a count of field “phone” with value “iphone” and field “type” with value “hate“).

Documents updated? Good.

Now let’s make our view:

1
2
3
4
5
6

function(doc) {
    if (doc.phone && doc.type) {
        var keys = [doc.phone, doc.type];
        emit(keys, 1);
    }
}

and the reduce to return a sum of the values:

1
2
3

function(key, values) {
    return sum(values);
}

In Futon it would look somewhat like:

With the results looking like:

So now again save it as design “example” and view name “countdocbyphoneandtype” and now you can invoke the following URL.

http://localhost:5984/databasename/_design/example/_view/countdocbyphoneandtype?group=true&key=["iphone", "hate"]

As you can see, we are passing an array in the “key” field with the values “iphone” and “hate“. This retrieves all the “phone” fields with value “iphone” and then from that resultset all the field “type” with value “hate“. It gives us the following type of output:

1
2
3
4
5
6

{
    "rows":[{
        "key":["iphone","hate"],
        "value":2
    }]
}

You now have a query that searches for “two” fields in your document.

I strongly suggest to read the wiki and anything related to views if you are remotely interested in using CouchDB as they are going to be your main source of nightmares and happiness. The latter example, was nicely explained to me on the IRC channel even though it was plain black and white on the wiki… Apparently I just couldn’t see it clearly enough. There are loads of little things with the views that require user experience instead of wiki reading and the people on the IRC channel have used CouchDB, they’ll get you by

Moving on, on top of many exciting upcoming features (as such as continuous replication, bulk inserts, etc.) the project has online documentation, online books for people to read for free (Even though I strongly recommend buying the book), a vibrant IRC channel with the nicest helpers from extensive users to software developers/creators to book authors.

When in need of direction, if you really can’t find it online or don’t understand how it’s explained, you can hop on the IRC channel and get your well formulated questions answered at all times. With a thorough patch review process and code quality insurance,in my opinion, it makes CouchDB a very solid open source project that should be respected and should serve as example for any new software that wants to make it into the open source world.

Some of the features in current development include reporting and analysing of activity and spend, setting of alerts to suit a budget, and the service works with Amazon Web Services, with future support for Microsoft Azure.

CloudSplit was founded earlier this summer by echolibre and Joe Drumgoole, and since then we’ve been working hard on our alpha version, which we’ll be bringing to TechCrunch50 in a few short weeks.

This stage of development has been real fun as it’s allowed us to work in PHP, C, Python and we have been putting CouchDB, nginx and Gearman through their paces

If you’d like to know when the service is fully launched, let us know on CloudSplit.com .

A few weeks ago, Helgi and I attended PHP|Tek 2009 in Chicago, as both representatives of echolibre and The PEAR Group.

This post will briefly discuss the formation of a Recommended PHP Standards Group, as put forward by a meeting of PHP developers at the conference. As would be expected, a bit of controversy surrounds this proposal, but my hope would be that it would be accepted and grow within the global PHP community in the coming years.

As posted by Travis Swicegood, a group of community project representatives came together to discuss naming standards for PHP 5.3 and above. (I would like to take the opportunity to publicly thank the staff of the PHP|Tek conference for providing us with a large meeting room with little more than 2 hours notice).

So, what’s this all about?

With PHP 5.3 being closer to a stable release, the inclusion of namespaces and packaging within projects will take on a whole new meaning for large projects. People representing The PEAR Group (PEAR2), The Zend Framework, Cake PHP, Solar PHP, Agavi and unofficial representatives of Symfony and Phing met together and we discussed standards that could benefit each of the projects and the community in general.

Attending were

• Agavi - David Zülke;
• Cake - Nate Abele;
• PEAR - Brett Bieber, David Coallier, Helgi Þormar Þorbjörnsson, Travis Swicegood;
• PhING - Travis Swicegood;
• Solar - Paul Jones;
• Symfony - Stefan Koopmanschap;
• Zend Framework - Matthew Weier O’Phinney;
• and the always amiable (i.e., at-large community member), Cal Evans.

Being a PEAR representative with Travis, Helgi and Brett we brought to the table the feedback and problems that we have been facing over the past year and a half with namespacing standards discussions, Matthew Weier O’Phinney from the Zend Framework brought their issues, same for Agavi, Solar, Cake and Symfony (Stefan is an unofficial representative). We brewed and stormed our issues, brought solutions and came up with a standard for namespacing and package structure.

Sneak Preview

Here are a few hints about the standards (outlined on this page) which cover things like namespace packaging structure, exceptions, abstract class naming, interface naming, and concrete class naming.

Namespaces

All packages should be named:
<vendor>\<package_or_component>\<ClassName>

Example:

1
2
3
4
5

<?php
    namespace pear2\text_diff\Diff;
    namespace zend\controller\FrontController;
    namespace cake\models\DatabaseModel;
?>

Exception Naming

• All packages must declare at package level Exception (i.e., pear2\text_diff\Exception)
• All packages should use SPL Exceptions where applicable

All of the above mentioned projects consented to this standard as of PHP 5.3. What this means to users and developers is that the barrier for entry from one framework to another becomes greatly reduced and the interoperability of packages between projects is tremendously improved.

I have been studying and working with web standards (XHTML, RDF, ATOM, RSS) for well over 4 years now, something I am glad of,  because recently something struck me. Conventions are arising, for example DOAP, SKOS and others, that are built on top of the Resource Description Framework otherwise known as RDF, if they aren’t, they are usually built on something very similar or related.

In this blog post I am going to be using the FOAF standard as an example and base for my proposal. First of all, the Friend Of A Friend standard (FOAF) is a project aimed at creating machine readable pages that describe people. It covers all basis of human interactions and behaviours. From basic profile information - name, mailbox, title, homepage, img, depiction, surname, given name, family name, firstname - to more detailed information as such as web blog, based near, geekcode, publications, etc.  As you can see on their standard description page, it also covers the following personal aspects: Online Account / IM, Projects / Groups and Documents and Images.

For instance, if a web application was to describe me using FOAF it could look something like this:

1
2
3
4
5

<foaf:Person rdf:about="#davidc" xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <foaf:name>David Coallier</foaf:name>
  <foaf:homepage rdf:resource="http://echolibre.com" />
  <foaf:img rdf:resource="/images/david.jpg" />
</foaf:Person>

The Problem

Whilst such a standard is clearly easy for a computer to read and does seem a logical fit, it’s not the easiest for a developer to read. These days, web users are looking for performance, simplicity, ease of use, and so are the developers creating web applications. Considering that XML is heavy to parse using current technologies (Javascript mostly), it makes very little sense for developers to make web applications that are going to be slower due to parsing complex XML nodes. However, JSON (JavaScript Object Notation) is a lightweight data-interchange format made to carry data over networks with a very small footprint. It has seen massive adoption across the web and is used in widget apps, web apps and various other systems.

As I was talking at OSS Bar Camp, something struck me. Developers need a standard. Fact. We need standards for the same reason the industrial revolution had need of machine part standards: to reduce the amount of different solutions to learn in order to achieve the same goal by having everyone do what they do in a standard way. Some may see standards as a way to prevent innovation, I see them as a way to innovate. See “why are web standards important” by the W3C, a good read.

So, developers need standards. Great, now what currently exists? Development standards (IDE, Documentation, tools, design patterns, unit testing, etc.), Output standards (XHTML, CSS, etc), XML based standards (Namespaces, Schemas, XPath, XQuery, XSLT, DOM, XML Base, RDF(s), etc.), usual web architectural principles, and many more. One thing that is missing though is the standards that allow developers to easily and rapidly work with each other’s web application.

If “Web 2.0″ was characterised by the democratisation of content, we feel strongly that the next stage of web evolution, “Web 3.0″ for want of a better word, will be characterised by the democratisation of data and applications.

The Solution

A standard would make that democratisation a little easier. I’ve decided that I am going to be working on this over the next few months with the help of a few others as such as Ed Finkler from the CERIAS (Also the creator of Spaz and all round awesome guy).

So, today I’m putting forward the need for PJFS - The Practical JSON Format Standard. It will strive to make heavy XML based standards more developer friendly and lighter by creating new, fresh and adapted Practical JSON Formatted Standardized outputs.

For instance, the FOAF example I drew above, is a great example of the need for PJFS. Consider the following from a developers perspective:

1
2
3
4
5
6
7

{
    "Person": {
        "name":"David Coallier",
        "homepage":"http:\/\/echolibre.com",
        "img":"http:\/\/echolibre.com\/images\/david.jpg"
    }
}

It’s easy to read but also easy to parse. It’s fast and reliable. I am well aware of the implications of this post and I do not underestimate the complexity of existing standards. I think each one of them, as complex as they can be, are needed and are something we should all aim to use. However, computers are not completely independent ( just yet!) and the middlemen (developers and users) should not be forgotten.

The implications of JSON formatting standards mean that it’s adoption will make things easier for developers by reducing the amount of work they have to do, and remove the learning curve on new object structures for every web service the want to use.

The first task I will start working on is a PJFS for micro-blogging web services. The likes of identi.ca have already started in the general direction by “copying” the behaviours of the Twitter API, however many other micro-blogging platforms are still very independent and a unified standard could help the tools developers creating more flexible tools that would cover more networks.

So, remember where you heard about PJFS first It’s there to create standard object names, properties, variables, class members names to JSON elements so that developers can expect something identically formed when requesting JSON information from a webservice.

If you’d like to be involved leave a comment or catch me on twitter - @davidcoallier.

This past weekend we went along to Dublin’s OSS BarCamp. There were some really great talks, Stuart Langridge’s Javascript presentation was a highlight. Jaime Hemmett’s talk on using Git for version control was useful and informative. Paul Biggar’s talk on PHC, the Open Source PHP Compiler, was thought provoking and certainly caused a few grumbles from PHP guys like myself in the audience ;). JD and myself managed to catch up with him after and talk through some of his ideas over a drink.

I also got to give a talk on how APIs will be the cornerstone of the next stage in the evolution of the web - web 3.0 if you will.

This was my first time talking about a subject that didn’t directly involve PHP.  I’m planning on doing a similar talk at BarCamp Belfast at the end of the month, so if you were present and have suggestions on how my presentation could be improved feel free to leave a comment below.

Andrea Trasatti (@andreatrasatti) made the valid point that a small company and startup are not the same thing. Also I’ll have to add a list of successful startups towards the end of the presentation to support my central argument that APIs can extend a customer base and service subscriber network.

So, my slides from the presentation are below, please do let me know what you think. As a company, we were delighted to be able to sponsor the event, and it was great to be able to connect to speakers and attendees alike over a few drinks after the event.

I would seriously recommend people (managers, developers, etc) to look at it and register for the BETA version because having been granted access to test and give feedback, we, as private beta testers, found it really nice, insightful and simple to use.

This web app has a huge potential (internationally) and is developed following a solid architecture. Being strong PEAR contributors we are of course happy to take a look at what helped the footprintapp.com team achieve such a great product. So I went ahead and asked a few questions to Iarfhlaith Kelly from webstrong.

Q: How long have you been using PEAR?
A: I dabbled with a few of the PEAR packages back in college (2001-2005). Mostly I used the database abstraction packages like DB and MDB2. It was great to use on object oriented approach to interact with a database. After college though, from 2005 onwards, I ventured much deeper into the PEAR packages because as a freelance developer I was getting a lot more requests from clients.

Q: How does PEAR help you in your daily development life?
A: Using PEAR has greatly reduced the amount of code I’ve needed to write on the ‘heavy lifting’ areas of web development. This lets me focus on the flow of the system and spend more time building features that make my app unique, rather then re-inventing the wheel on some of the more common features often needed in most modern web apps.

Also, because of PEAR’s command line interface for installing and updating packages (both locally and remotely) it has made maintaining the code packages a lot easier then if I had to download and upgrade each one manually. This saves a lot of time during system upgrades.

Q: What do you use it for (packages you use)
A: Well, like I mentioned before I started off by using DB and MDB2 in college, but once I started using PEAR on client projects I quickly learned about the XML parsing libraries, HTTP requests, MS Excel generation, encryption, authentication, and email. I used a number of key PEAR libraries without which I would still be building it today. These were:

* Auth_HTTP for HTTP based authentication
* MDB2 for database abstraction

The system also communicates with a number of other web services, such as Amazon’s S3 service and authentication services via the OpenID format. To communicate with these, I use:

* XML_Parser for processing the returned information
* HTTP_Request for sending commands and data to the web services

Because of the standard approach to documentation across all PEAR for these packages allowed me to hit the ground running on new packages.

This is yet another great experience by PEAR users and we are glad to be helping and best of luck to webstrong and footprintapp for the future!

A few days ago we were granted commit access to the kick ass,  award winning Adobe AIR Twitter client Spaz.

We are delighted to be part of another open source project, and one that takes a new and innovative approach to web and desktop development.

The Spaz client is a cross-platform (available on AIR platforms) client that allows people to interact with Twitter in a whole new way. It’s great for both regular computer users in it’s ease of use, and heavy twitter users. For example you have different themes with Spaz but you can also override the CSS design to customise the app’s appearance.

The application supports markdown, it minimizes to system tray on windows, it has a URL shortening helper, retweet functionality, the ability to add favourites, the ability to delete messages, twitpic support, and much more.

You can of course go directly on Spaz’s website and read more about it and try it out