But now Composer, and its repository counterpart Packagist, promise to change all that. And obviously new conventions like PHP's namespacing support and the PSR-0 standard autoloader help.

Composer is heavily inspired by NPM which has built a strong culture of code-sharing and easy deployment in the Node.js community.

Easy for users

With Composer, managing dependencies in your project is very easy. Simply create a composer.json file where you state your dependencies, and let the package management system worry about the rest.

Packages that are registered with packagist.org are obviously easiest to depend on, but you can also state packages coming from custom repositories (like your company's internal version control system), or PHP extensions that you need.

Here is for example the composer.json from the Midgard PHPCR provider:

{
    "name": "midgard/phpcr",
    "type": "library",
    "require": {
        "php": ">=5.3.0",
        "ext-midgard2": ">=10.05.5",
        "phpcr/phpcr": ">=2.1.0-beta1"
    }
}

With this file, Composer knows that our PHPCR provider runs only on PHP 5.3 or newer (as it uses namespaces), and that it needs the Midgard PHP extension and the PHPCR interface classes to be available.

Now installing the project is easy:

$ wget http://getcomposer.org/composer.phar 
$ php composer.phar install

How about autoloading? Traditionally PHP required you to manually include or require all files you wanted to use in your code, with the possibility to write an autoloader to handle it automatically when you call an undefined class. But managing these autoloaders is also a chore.

Composer helps here too, by automatically generating an autoloader that will be able to load your own code, and the code from all your dependencies. So you can get rid of your own autoloaders and include statements, and just include the Composer-generated autoloader in your code:

require 'vendor/.composer/autoload.php';

After this all the classes you've stated your application needing will be available.

Easy for developers

While ease-of-installation is important, it isn't enough to build an ecosystem. The other thing that has to be easy is publishing code. Basically: if you've written a piece of functionality in PHP that you could see yourself using in another project, it should be effortless to publish it as a library.

This is where approaches like PEAR mostly failed, by making it too cumbersome to define your packages, to build them, and to upload them to the repository.

With Composer this is very easy. You again define a composer.json for your package, and push that to your project's Git repository. Then just register the Git repository URL with packagist.org.

After this Packagist will spider your repository and make it available as a package.

Publishing new versions is very easy: simply keep your composer.json up-to-date, and tag your releases in Git.

Where are we now?

It is still early days for Composer, and the project is being worked on at a hectic pace. However, it is already good enough for managing dependencies to modern, PSR-0 compatible libraries.

What I would like to see happen next is support for custom package roles and autoloaders. This would allow us to handle more specific cases, like for example installation of Midgard MVC components and their non-namespaced autoloading needs. After that we should be able to get rid of our custom installer code and just join the Composer crowd.

But if your code is already fully namespaced, this is a great time to get started with Composer.

Both environments have their strong points. Node.js is very fast and flexible, but PHP has a lot more mature tools and libraries available. So in a lot of projects it is hard to choose between the two. But now you might not have to.

Enter DNode

DNode is a remote method invocation protocol originally written for Node.js, as the name probably tells. But as the protocol itself is quite simple, just sending newline-terminated JSON packets over TCP connections, implementations have started popping up in other languages. You can talk DNode in Ruby, Perl, Python, Java, and now PHP.

I started working on the PHP DNode implementation in the Symfony CMF hackday in Cologne a week ago, and got it into a running stage on a train ride from there to Paris. The implementation isn't yet complete, but works already quite well.

With DNode you can expose Node.js functions to be available on PHP, and PHP class methods to be available on Node.

Like most Node.js functionality, DNode works asynchronously. So instead of waiting for return values you supply a callback function that will be called when the method completes.

PHP as client

Here is a simple DNode service for Node.js:

var dnode = require('dnode');
var server = dnode({
    zing: function (n, cb) { cb(n * 100) }
});
server.listen(7070);

This creates a DNode service running in TCP port 7070 that provides one method: zing that multiplies the value given to it by 100 and sends the result to the callback provided.

Calling this with PHP is easy:

// Connect to DNode server running in port 7070 and call 
// Zing with argument 33
$dnode = new DNode\DNode();
$dnode->connect(7070, function($remote, $connection) {
    // Remote is a proxy object that provides us all methods
    // from the server
    $remote->zing(33, function($n) use ($connection) {
        echo "n = {$n}\n";
        // Once we have the result we can close the connection
        $connection->end();
    });
});

Now just start the server:

$ node simple/server.js

And run the client. As you can see from the PHP code above, once we get the result the client will end the connection automatically:

$ php examples/simple/client.php 
n = 3300

Because only simple TCP connections and JSON packets are used, this is quite fast. Here are time results for the client on my MacBook Air:

real    0m0.064s
user    0m0.050s
sys     0m0.010s

PHP as a server

PHP can also act as a DNode server. You instantiate the DNode class and pass it the object you want to expose via DNode. All public methods of the object will be made available to the DNode clients:

// This is the class we're exposing to DNode
class Zinger
{
    // Public methods are made available to the network
    public function zing($n, $cb)
    {
        // Dnode is async, so we return via callback
        $cb($n * 100);
    }
}

// Create a DNode server
$server = new DNode\DNode(new Zinger());
$server->listen(7070);

This DNode service will obviously be visible for both Node.js and PHP clients.

Bidirectional communications

A DNode client can also expose methods to the server. In this example the server provides functionality for converting temperatures from Celsius to Fahrenheit, but actually gets the current Celsius temperature by asking it from a client.

Server:

// This is the class we're exposing to DNode
class Converter
{
    // Poll the client's own temperature() in celsius
    // and convert that value to fahrenheit in the supplied 
    // callback
    public function clientTempF($cb)
    {
        // The other side of DNode connection is exposed via
        // $this->remote proxy object
        $this->remote->temperature(function($degC) use ($cb) {
            $degF = round($degC * 9 / 5 + 32);
            $cb($degF);
        });
    }
}

// Create a DNode server that listens to port 6060
$server = new DNode\DNode(new Converter());
$server->listen(6060);

Client:

// This is the class we're exposing to DNode
class Temp
{
    // Compute the client's temperature and stuff that value
    // into the callback
    public function temperature($cb)
    {
        $degC = rand(-20, 50);
        echo "{$degC}° C\n";
        $cb($degC);
    }
}

$dnode = new DNode\DNode(new Temp());
$dnode->connect(6060, function($remote, $connection) {
    // Ask server for temperature in Fahrenheit
    $remote->clientTempF(function($degF) use ($connection) {
        echo "{$degF}° F\n";
        // Close the connection
        $connection->end();
    });
});

Then just start the server:

$ php examples/bidirectional/server.php

And run the client:

$ php examples/bidirectional/client.php 
28° C
82° F

The same will obviously work with a Node.js client:

$ node bidirectional/client.js 
23° C
73° F

Installing DNode

dnode-php can be installed using the Composer tool. You can either add dnode/dnode to your package dependencies, or if you want to install dnode-php as standalone, go to the main directory of its repository and run:

$ wget http://getcomposer.org/composer.phar 
$ php composer.phar install

You can then use the composer-generated autoloader to access the DNode classes:

require 'vendor/.composer/autoload.php';

Some DNode examples can be found from the examples folder. They are compatible with the similarly-named examples from Node.js DNode.

Contributing

php-dnode is developed under the MIT license in GitHub. If you're interested in it, please watch the repository and send issues or pull requests.

One option is to follow the lead of the big companies, hoping that Tizen works, or that Google again sees the benefit of working with others in the open.

The other is to take the matters in our own hands. There is precedent for this. Much of early Linux activity came from the efforts of the community, not on the initiative of corporate interests. And there have been OpenMoko and Mer, the latter an attempt to make a fully open version of Nokia's Maemo environment, suspended when MeeGo promised to bring the same benefits.

Well, now Mer is back.

The goals for Mer align pretty well with what the community would need:

• To be openly developed and openly governed as a meritocracy
• That primary customers of the platform are device vendors - not end-users.
• To provide a device manufacturer oriented structure, processes and tools: make life easy for them
• To have a device oriented architecture
• To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
• To innovate in the mobile OS space

There have also been some other invitations to new potential homes for the community, ranging from openSUSE to Debian.

It will be interesting to see how this works out. But whatever we as a community do, we should ensure we look at more than just licensing.

For the last month we've been working in Salzburg to build such a system, the Intelligent Project Controlling Tool needed for running large collaborative research projects like IKS. Since the design we went with can be reused for other business analytics needs, I wanted to write a bit about it.

But first, here is how our system looks like:

Where does the data come from?

There are many ways to gather business data. Often the information systems already contain the data needed. But it may also be hidden in a jungle of spreadsheets. Or maybe some data is simply not available, and has to be filled in manually.

Handling all these cases in one system is a tricky question. To solve it, we went with a two-layered strategy:

• All data used for analytics is stored as Linked Data in a CouchDB system
• NoFlo workflows are used for gathering data from the diverse sources and convert it to the format needed

In IKS's case, much of the data was available in a series of spreadsheets. With these, we built the necessary workflows for first converting the spreadsheets into XML with Apache Tika, and then extracting the information from them in a sensible subset of JSON-LD.

Because IKS is a collaborative project, information needs to be gathered from a diverse group of partner organizations. Some of them have systems that provide the needed APIs (like Basecamp, which we use), and we can just periodically import the data. But with many we decided on a simple data interchange approach: spreadsheets handled over email.

In this approach, user files a data request into the system. This gets picked up by NoFlo, which sends an email with the appropriate spreadsheet template to the partner. Then it starts waiting for a reply. When a reply arrives, it extracts the data from the attached spreadsheet and imports it to the system.

Our NoFlo processes are mostly initiated by the CouchDB change notification API. We keep them running persistently using forever Node, so whenever some operation needs to be run it happens nearly immediately.

Ensuring data consistency

With any automation, and especially with the email-based data interchange, things can go wrong. Because of this we tag all data that we receive with its origin, whether it was some automated operation or an imported spreadsheet. These origins are called execution documents. Users can browse all completed workflow executions and see what data came in from them. These can then be either accepted or rejected.

This way if some partner accidentally sends faulty data, or something else breaks, the incorrect information received can be easily removed. CouchDB's versioning capabilities help here.

Analyzing the data

CouchDB is built on top of the concept of map/reduce. Here you can modify and combine the data in lots of different ways using simple JavaScript functions. In our case we elected to write all our CouchDB code in CoffeeScript for simplicity. For example, here is the reduce function in CoffeeScript that counts totals of time planned, time used, and time left per task or partner in a project:

(keys, values, rereduce) ->
    roundNumber = (rnum, rlength) ->
        Math.round(parseFloat(rnum) * Math.pow(10, rlength)) / Math.pow(10, rlength)
    data =
        planned: 0.0
        spent: 0.0
        left: 0.0

    if rereduce
        for reducedData in values
            data.planned += reducedData.planned
            data.spent += reducedData.spent
        data.left = data.planned - data.spent
        return data

    for doc in values
        if doc['@type'] is 'effortallocation'
            data.planned += roundNumber doc.value, 1
        if doc['@type'] is 'effort'
            data.spent += roundNumber doc.value, 1
    data.left = roundNumber data.planned - data.spent, 1
    return data

If you figure out a new way to look at the data you have, simply write the needed map and reduce functions and save them into the database. CouchDB will then run them against existing data and produce numbers.

Data visualizations

Numbers are good, but to really see the information buried in them you need some visualizations. For this we decided to follow the CouchApp idea where the user interface code is stored in the database together with the data itself. This way no application servers are needed, and you can take the whole system with you just by replicating the database. Think of the possibility of doing some analysis on your company while flying to a meeting!

The visuals are in our case provided by JavaScript InfoVis Toolkit, a nice, MIT-licensed interactive graph library.

CouchDB views handle the number crunching, then CouchDB list functions process the numbers into the format needed for visualization. This leaves only a minimal amount of work for the client side.

For consistency our application has been built with CoffeeApp, so all the database and user interface code is in CoffeeScript.

In a nutshell

Any business analytics system dealing with moderate amounts of data can be built following this approach.

• Apache CouchDB is the central data store
• All data is stored as JSON-LD entities
• NoFlo handles all data imports
• Analytics based on the data are done with CouchDB map/reduce
• Visualization happens with a CouchApp using JavaScript InfoVis Toolkit

This way you have a business analytics environment that is easy to extend with more data when it becomes available. New analysis can be done by writing reasonably simple map/reduce functions, and CouchDB's replication capabilities allow you to take the system and data with you.

Using JSON-LD for the data storage makes a lot of sense, as this way the relations between different pieces of information are easy to handle. And using URIs for data identifiers means you can easily mash up information coming from different sources together.

The two-layered approach of using NoFlo for data imports, and CouchDB for analysis also allows for clean separation of concerns. In our case, I did the workflow part of things, and Szaby built the visualizations.

Yesterday I merged the Zart codebase into the VIE repository. This blog post describes some of the improvements it brings.

VIE now has an instance

For VIE 1.x users the first visible change (and probably the only necessary API change) is that now VIE needs to be instantiated before being used. Singletons are evil, and so we are not a singleton any longer.

So, for existing VIE code, you need to:

var vie = new VIE();
// and then any traditional VIE calls, like:
var entities = vie.RDFaEntities.getInstances('div.article');
console.log("There are " + entities.length + " RDFa entities in your articles");

The VIE 1.0 API can be disabled by passing a setting when instantiating VIE:

var vie = new VIE({classic: false});

Services and VIE

The other big change in VIE is that now the API has been built in a service-oriented manner. This means that for example reading and writing RDFa is just a service you can enable and disable at will.

The benefit here is that we can easily add support for other formats and capabilities without having to touch VIE internals. Thanks to the schema.org situation, Microdata is getting more use, and so at some point we'll probably add a service for it.

Registering and accessing services is easy:

// Instantiate VIE
var vie = new VIE();

// Pass the service instance and a name you want to use for it
vie.use(new vie.RdfaService, 'rdfa');

// Call a method from the service using the name
// this one would give us the RDF subject of the
// element matched by the jQuery selector
vie.service('rdfa').getElementSubject('div.article');

An immediate benefit here is that we can have two RDFa parsing implementations. If you have problems with our own custom jQuery-based RDFa parser, then you can use the more strict rdfQuery powered implementation instead:

vie.use(new RdfaRdfQueryService, 'rdfa');

Using deferreds

For the new main VIE API we created a sort of a Domain-Specific Language for handling semantic entities. A core part of it is that now all operations utilize jQuery's Deferred objects. With them you can attach different callbacks to the results of your operation, and they will fire either when the operation completes, or immediately if the operation has already been run.

This gives a lot of flexibility in using the API, and allows us to provide same API for services that deal with the DOM, and services that talk to external APIs like Stanbol.

For example, parsing RDFa from a given DOM element (provided with a jQuery selector) happens like this:

vie.load({
        element: 'div.article'
    }).
    from('rdfa').
    execute().
    done(function(entities) {
        console.log(entities);
    });

The chain here is: operation (in this case, load), from service (rdfa), execute operation, then when done, do callback.

With the RDFa service we register Backbone Views for the elements our entities came from, so just like with VIE 1.x, they will update automatically when you change the contents of your entities. But manual writing is also available in case you need it. Here is how it works:

vie.save({
        element: 'div.article',
        entity: someBackboneModel
    }).
    to('rdfa').
    execute().
    done(function() {
        console.log("Saved!");
    });

In addition to done, which fires if the operation succeeds, you have fail for failed operations, and then which fires regardless of success or failure.

Accessing external services

The new VIE is not just about RDFa. In addition to working with the entities you have on a page, you can also access external repositories of semantic information, like DBpedia.

For example, to find out everything that Wikipedia knows about Salzburg, you could run:

vie.use(new vie.DBPediaService, 'dbpedia');
vie.load({
        entity: '<http://dbpedia.org/resource/Salzburg>'
    }).
    using('dbpedia').
    execute().
    done(function(entity) {
        console.log("This is what we know of Salzburg");
        console.log(entity);
    });

In browser usage these calls to external services are subject to cross-domain AJAX limitations. A way to work around those is to set up a proxy, and tell the DBpedia service to use that. To do this, pass the proxy URL to the service when instantiating:

vie.use(new vie.DBPediaService({proxyUrl: 'http://localhost:8080'});

With this, all the factual information from Wikipedia will be at your disposal. The size of every city, the height of every mountain. Birthdates and places of birth for famous people. Your web app can do quite a bit with this information.

Finding entities from text

Apache Stanbol is a semantic engine that can extract all kinds of entities from text documents. It can be used for auto-tagging and other things.

Here is how you can use it with VIE:

vie.use(new vie.StanbolService, 'stanbol');
vie.analyze({
        element: 'div.article'
    }).
    using('stanbol').
    execute().
    done(function(entities) {
        console.log("We got the following enhancements for article content");
        console.log(entities);
    });

Stanbol can tell you what a piece of content talks about. People mentioned, places, concepts. It will also give you the language of the text.

Moving forward

The new version of VIE is still under heavy development. Most of the thngs work, but some details may still change. It is a good idea to start taking a look at it now, but before a beta release at least, VIE 1.0 is the recommended tool to use.

If you already use VIE 1.0 for making your content editable, VIE 2.x will give you a lot of additional power. Enhancements, data queries, namespace handling, and much more.

Thanks to Szaby and Sebastian for helping to make this happen!

node-gir has been written by Tim Caswell, with help from Sebastian Wick and Piotr Pokora.

I've been following the progress for a while, and today, during a flight from Helsinki to Salzburg, I was finally able to open a Midgard repository connection with it. The API still is a bit weird, and lacks support for the asynchronous nature of Node, but those will hopefully change soon. Quick example:

var Midgard, gir, config, mgd;
gir = require("../gir");
gir.init();
Midgard = gir.load("Midgard");
Midgard.init();

// Use a local SQLite database file
config = new Midgard.Config();
config.__set_property__("dbdir", __dirname);
config.__set_property__("dbtype", "SQLite");
config.__set_property__("database", "midgard");

// Open connection to the database
mgd = new Midgard.Connection();
if (!mgd.__call__("open_config", config)) {
    console.error("Failed to open connection");
    process.exit();
}

node-gir is being developed on GitHub if you want to lend a hand or try it out. To build it, run npm install and you should be able to run the code examples.

Having GIR support for Node would make it a full-fledged GNOME environment, and mean that there would be proper GObject Introspection in all three major JavaScript runtimes - SpiderMonkey, JavaScriptCore and V8. And this way GNOME JavaScript developers could also utilize the wealth of existing Node.js modules.

Many of their plans to make web competitive against native development environments are good, there is indeed much to improve in the stack. But what I'm uneasy with is the unilateral way they go about it, preferring "big reveals" and post-facto standardization instead of the open conversation that built most of the Internet we have today. This is not the way to collaborate.

Consider some of their recent efforts:

• SPDY, a protocol to replace HTTP which Web is built on. Currently only supported by Chrome, which uses it to talk to several Google services
• Dart, their JavaScript-killer which recently surfaced through a leaked email
• Microdata and Schema.org that seek to replace last ten years of semantic web development with a spec cooked up by couple of big vendors in secret

These - together with WebSQL, NaCl, WebM and WebP - mean that Google has active efforts to replace practically every layer of the web (except HTML itself) with something of their own design.

The way all of these were introduced bears strong reminders of how Microsoft tried to embrace, extend, and extinguish the web in late 90s. That period brought horrors like ActiveX and the awful, unkillable IE6. Though, for the sake of fairness, it also brought us XmlHttpRequest which was the enabler of the AJAX revolution.

Google's new technologies may end up being beneficial for web developers, but they also threaten to fragment the platform. After all, as the competition in the "post-PC" space heats up, the competitors are unlikely to embrace Google's extensions of the web stack. That would be a loss to all.

Brendan Eich, the original author of JavaScript comments on Hacker News:

So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste.

Ok, counter-arguments. What's wrong with playing hardball to advance the web, you say? As my blog tries to explain, the standards process requires good social relations and philosophical balance among the participating competitors.

Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status. Dart is GBScript to NaCl/Pepper's ActiveG.

Disclaimer: I've been a long-time fan of many of Google's services, and have visited some of their offices a few times. I like the company. Which is exactly why I'm so concerned about this unilateral approach at standards. I am also involved in some standards processes through the IKS Project.

I have been quite lazy from time to time on social networks. Just being there was enough for me.

But is it really?

No one connects  with you just like that. You have to be commited to make something fo a tool. As an example. Just beacuse you install Word on your computer you wont get tons of documents. You still have to write them ...      

So i decided some time ago to make somthing out of my profile. Make it more interesting to people. People should want to connect with me when reading it.

Here are some small ways on how to get more out of your LinkedIn profile:

1. Connections
If you connect with more people on LinkedIn you spread your message better. Even if its a person that wont buy your product or sell you something at the moment. The person will se your updates a
nd posts. This can lead to business in the future.

2. Groups
You can get alot of connection in participating in groups. Groups that targets your business area. It can generate leads, give you new information and it also says some on what kind of person yo
u are and what you work with. (My own profile for example is mostly about systems administration and offshoring industry)

3. Search engines
LinkedIn scores quite high on search engines. By keeping a good and updated profile with information on what you are doing will do good in promoting you and your company as a product.    

4. Cross post content
All your articles and updates you write should be cross posted across several networks. Facebook, LinkedIn, Twitter and more. That way your content is exposed to a broader audience and will make some points on all the search engines.

5. Building a good profile and what it can do for you.
Your profile on LinkedIn is almost like your CV. It tells your visitors who you are and what you have accomplished workwise. It show your publications, your work history and recomendations from
others.

In this way a good profile demonstrates knowledge and professionalism in a whole new way. It could generate more business for you by exposing you to wider audience. In the end it will make people more eager to connect with you and contact you for your services.

Final words.
I know forums because it comes with my work some. But i have never really USED them i just have an account and log in from time to time.

But now when i update them on a regular basis and really tend to them. It gives me new customers and a wider network. Securing a vital business for my company. It pays of in the end.

MG Siegler from TechCrunch has a great post on the subject:

...I’ve been trained over time to think that the traditional PC is the way to do these things whether it’s for work or play. That’s simply not true. The tablet form factor is so. much. better. when you don’t have to do an excessive amount of typing. And during downtime, when I use a computer like a more regular human being, I’ve found that’s often...

Computing is changing. That’s just about the most obvious statement ever. We’ve been seeing this for years with the rise of the smartphones. But traditional computing is changing as well. As in, people are abandoning PCs for these newer devices. And this will keep happening.

My experience conforms with this. I rarely use my laptop outside of the work context of writing code, instead preferring to use the tablet with its great ergonomics, portability and long battery life. On some of my previous trips I noticed that already more than half of people sitting in airport lounges use a tablet instead of a laptop. Not bad for a product category that has existed in a mainstream manner for less than two years. Nokia's internet tablets blazed the trail years earlier, but were never marketed outside the geekdom.

Now, much of the attention in the tablet world has been focused on the couple of platforms that are winning in popularity, and therefore have most of the apps. But regardless of how well Apple and Google play their cards, the post-PC world will be a multiplatform one.

About a week after I got my webOS-powered TouchPad, HP went and killed the product. Yet this hasn't made the device useless. As Paul Rouget recently found out, as long as you have a good browser, your device will be relevant.

Some people can't or don't want to use Native Apps. Because their phones don't have Apps, or because there is just no good Apps for what they want to do, or because, well, because they don't need to...

While in the Western world we were looking at Apple bringing pretty Apps in an expensive device, in the Eastern world, Opera was bringing a working web browser to all the existing devices.

This is the big opportunity for free software to remain relevant in an environment of highly-locked devices. Much of the web already runs on free components, and by using the web as a universal runtime we can bypass almost any platform restrictions. As Paul Graham wrote back in 2001, no one can break web applications without breaking browsing.

The world of publishing is starting to understand this. Their revenue models can't take the heavy control that vendors like Apple imposes, and so Amazon's Kindle is a web app, and so is Financial Times. That "Next year HTML5 will replace native apps" is the new "Next year will be the year of Linux on the desktop" is already a Twitter joke, but there is certainly some movement in this direction. And interestingly, the Linux desktop is actually becoming more web-savvy and touch-friendly.

There are clearly sweet spots for something to be a web app, or for it to be a native application. Similarly, there are different situations where tablets will be the appropriate tool, and where PCs are. The tablet context will be more like this:

Than this:

The heavy lifting is a better fit for a system designed for that. As Steve Jobs said, the PC will be the truck.

Even in the ten years of history of our company this is quite a significant move - it allows us to combine Nemein's traditional expertise on content management with Infigo's mobile offerings. As smartphones and tablets are becoming popular, more and more services we build will have a mobile element, which is now easier with lots of in-house expertise.

This also means more focus on the interplay between the Midgard content repository, NoFlo workflows, Node.js and Symfony web services, and mobile applications built in Qt.

Petri Rajahalme (with me in the photo) will be the CEO of the merged company, and I will focus on leading the R&D efforts.

Yesterday Igor Wiedler published Evenement, a PHP port of the EventEmitter class from Node.js. As NoFlo builds quite heavily on EventEmitter, I decided to see how far the PHP port could be taken.

As result, there is now PhpFlo, a flow-based programming environment for PHP.

Example of how to define and run a flow (you can also use a JSON format for this):

// Add nodes to the graph
$graph = new PhpFlo\Graph("linecount");
$graph->addNode("Read File", "ReadFile");
$graph->addNode("Split by Lines", "SplitStr");
$graph->addNode("Count Lines", "Counter");
$graph->addNode("Display", "Output");

// Add connections between nodes
$graph->addEdge("Read File", "out", "Split by Lines", "in");
$graph->addEdge("Read File", "error", "Display", "in");
$graph->addEdge("Split by Lines", "out", "Count Lines", "in");
$graph->addEdge("Count Lines", "count", "Display", "in");

// Kick-start the process by sending filename to Read File
$graph->addInitial($fileName, "Read File", "source");

// Make the graph "live"
$network = PhpFlo\Network::create($graph);

The flow consists of processes, or instances simple "black box" components that have their own defined input and output ports. Program logic is defined by making connections between them. Here is a simple component that reads the contents of a file:

namespace PhpFlo\Component;
use PhpFlo\Component;
use PhpFlo\Port;
class ReadFile extends Component
{
    public function __construct()
    {
        $this->inPorts['source'] = new Port();
        $this->outPorts['out'] = new Port();
        $this->outPorts['error'] = new Port();

        $this->inPorts['source']->on('data', array($this, 'readFile'));
    }

    public function readFile($data)
    {
        if (!file_exists($data)) {
            $this->outPorts['error']->send("File {$data} doesn't exist");
            return;
        }

        $this->outPorts['out']->send(file_get_contents($data));
        $this->outPorts['out']->disconnect();
    }
}

I hope people find this system useful. If you're interested in FBP, then J. Paul Morrison's book is a good place to start.

And if you're in FrOSCon, feel free to come and chat with me :-)

Subjects discussed included:

• Symfony2 as a central PHP ecosystem
• Basic ideas behind Symfony2
• Introduction to PHP namespaces
• Installation with Symfony Standard Edition
• Running Symfony2 with AppServer-in-PHP
• Creating a new Bundle
• Templating in Symfony2
• Routing in Symfony2
• Using the Midgard content repository with Symfony2
• Running MidCOM components inside Symfony2

You can also find the Pinpoint sources for the tutorial from GitHub. I'll try to keep them updated for future use.

While much of the corporate involvement around the desktops has evaporated through some recent events, this seems to have given the developers lots more creative freedom. I've seen many very promising concepts from both communities.

Here are some things that happened during the week:

• The roadmap for Midgard to become closer to the JCR specification solidified, including a reasonably good plan on backwards compatibility
• We published the first version of GICR, generic Content Repository interfaces for GObject. Midgard will probably be the first project to implement them, but we hope others will follow. It'd be a great fit for GNOME Documents, among other things
• The project to replace our own PHP frameworks with Symfony2 continued by implementing the MidCOM compatibility layer that will allow Midgard1 web applications to be run in the new environment
• My work on the NoFlo flow-based programming tool got some positive attention and interest. Still lot of stuff to do
• We at Nemein co-sponsored the GObject Introspection hackfest. GIR is important for bringing GNOME libraries to new environments like scripting languages and the web
• Lots of ice cream got eaten. I think it will be fair if I stay out of next year's deathmatch and focus on coaching ;-)

Tomorrow back to Helsinki for a week, then onwards to FrOSCon and Salzburg...

Now, one of the things I've talked about with people is NoFlo, my new tool that brings Flow-Based Programming to Node.js. What is that? Wikipedia explains:

Flow-based programming (FBP) is a programming paradigm that defines applications as networks of "black box" processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

Basically the idea here is to simplify managing the control flow of software: what data goes where, what happens then, etc. with the goal of making software more understandable. With NoFlo you can go and peek under the hood of a running piece of software, see where data is going to, and even rewire some connections if you want to.

The project is still in reasonably early stages, but it is already used in at least one real-life deployment. Here are some sneak peeks:

:

If you're interested, follow the progress on my GitHub repo, or subscribe to the Flow-Based Programming mailing list.

In the spirit of Desktop Summit, it would be interesting to talk how these workflows would fit into the concept of a free software desktop.

The test results was quite interesting. My clients Varnish+nginx+php-fpm cluster was actually faster than googles service in 3 out of four tests.

The grid with the results below says it all.

This is just one of the installations I have done. Results vary depending on what type of content you store. My clients content is a mix of static and frequently updated content.

A perfect example on a properly optimized website.

Frameworks are generally problematic concerning cross-project collaboration, as most of the code written against a particular framework tends to run only on that framework. If things are properly decoupled, and most of the logic is in generic libraries, this doesn't matter so much. But still, having a common framework most of the code is written for helps, as can be seen in the Ruby community.

So, to advance this goal, we in the Midgard Community have made a decision to start aligning our PHP code to Symfony2. The ideas behind SF2 are quite compatible with our views:

Symfony2 embraces standards: First, Symfony2 is willingly centered around the HTTP specification (just have a look at the built-in HTTP reverse proxy). Then, we are embracing the PHP standards: PHPUnit, namespaces, PSR-0 autoloader, ... That makes Symfony2 easily interoperable with many other great PHP libraries.

Symfony2 is decoupled: Beside being a full-stack framework, Symfony2 is also a set of decoupled and cohesive components; Symfony2 is made of 21 components that can be used as standalone libraries: they have their own Git repositories, and they are all available as PEAR packages.

For us this alignment means making sure code written for MidCOM and Midgard MVC, our two PHP frameworks runs properly under Symfony2, and filling various functionality gaps that exist between our frameworks and SF2.

I believe this to be a great opportunity for both communities. Especially for Midgard users this brings a great promise of future functionality coupled with full backwards compatibility.

Here are some very early results of this collaboration:

• Symfony2 can now be run on AppServer-in-PHP with our AppServerBundle. Great performance and deployment benefits can be had by adopting AiP, so having a simple way to run SF2 with it is useful
• There is a ConnectionBundle which is responsible for initializing and connecting to a Midgard2 content repository
• Midgard MVC components can now be run as part of a Symfony2 application with the MvcCompatBundle. Lots of work there still remains, but it is a good start

Here you can see a screen from a simple AiP-powered SF2 application, running the org_midgardproject_news component displaying content from the Midgard2 repository rendered via TAL:

After the Midgard MVC compatibility work is done we will also focus on ensuring full MidCOM applications run on Symfony2. There is already some precedent for this sort of compatibility work, as you can also run Zend Framework applications under Symfony2.

Congratulations to the Symfony2 community for a great release! I look forward to a lot more collaboration in the future.

Now I would like to bring GObject Introspection to PHP. Why?

For many years we in the Midgard community have been using GNOME infrastructure on the web server side, by building our persistence layer on top of GObjects, and providing D-Bus notifications when content changes. So far this has been done with our own custom PHP extension.

I believe a common PHP extension providing GObject Introspection support would make more sense, as it wouldn't just benefit our own community, but also support efforts like php-gtk.

Alexey Zakhlestin already started a project for this a while back, but unfortunately has been unable to finish it. Because of this, we would be willing to sponsor anybody interested in making the gobject-for-php extension work.

Benefits for the GNOME community:

• New supported development language and a large community of potential contributors
• The possibility of making the GNOME stack relevant in web space. Just think of Telepathy or GStreamer in a web app

Benefits for the PHP community:

• Access to the rich collection of GNOME libraries, many which may be useful when building web applications
• Being able to use your PHP skills to build GNOME applications and bring them to interesting environments like Ubuntu and Cordia

Benefits for the Midgard community:

• No need to maintain our own custom PHP extension
• A more generic GObject Introspection extension has better chances of being included into Linux distributions and being available on hosting providers

Let me know if you are interested. We're coming to the Desktop Summit with Piotras, so for example that is a great opportunity to talk more about this.

But there are also bright points. I've recently seen lots of exchange of ideas, and even potential code sharing between some communities including Symfony2, Midgard, TYPO3 and eZ Publish. Much of the vision in these systems is similar, as are many of the engineering principles. When everybody uses reasonable object-oriented design, namespaces, and test-driven development, it is much easier to share.

If I had to list three areas where there is most potential for collaboration, these would be:

Content model on the browser: VIE and RDFa

The age of communicating with your web audience via forms is almost over, and it is time to evolve. HTML5 includes support for the contentEditable attribute which allows rich editing interaction straight on the pages, and there are cool editors supporting that, including Aloha Editor and Mercury.

To do proper front-end editing, your CMS and the JavaScript environment have to agree on the content model. Fortunately there is a great solution for this: just annotate your content with some RDFa.

Having RDFa on a page allows the browser to understand the content. What is a collection of blog posts for instance, and what is the title of a blog post. With this, my VIE library will provide you with a nice in-browser content management API based on Backbone.js. Getting there is easy:

1. Annotate your pages with RDFa
2. Include vie.js to the pages
3. Implement Backbone.sync

This allows a great deal of decoupling in the CMS stack. Suddenly the server side just has to worry about content management and page generation, and newer in-browser technologies can be used for actual content authoring.

Using RDFa annotations in your content comes also with another benefit: suddenly your pages themselves are an API into your content model. And search engines can understand and present your content better.

If you want to learn more about this, watch my talk from the Aloha Editor Dev Con.

Content persistence and retrieval: PHPCR

Historically, all CMSs have implemented persistence in their own way. There have been systems using relational databases like MySQL, systems providing their own content repository APIs like Midgard, and also some systems just using XML and the file system. This has reduced integration and code re-use possibilities between systems. In the Java world, a solution exists for this: the Java Content Repository standard (JCR).

Now JCR has been ported to PHP. PHPCR provides a standard interface for all content management needs, and has multiple back-ends available. Depending on your deployment needs, you could store your content into a relational database, into Apache Jackrabbit, or into for example MongoDB.

PHPCR is great in that you can start small: just model your content with a simple, filesystem-like tree of nodes and properties. Then when you need it, a wealth of functionality is available. Versioning? Query builders? Access control? It is all there for you to use. And, depending on the PHPCR back-end, you'll have the ability to scale up to insane amounts of content.

While I've advocated using content repositories for years now, this is the first time PHP has a true standardized, vendor-neutral API for it. And PHPCR is even being integrated into the JCR specification, eventually making it an official standard.

Adoption is also picking up. Yesterday I was in a meeting where we had developers from TYPO3, Symfony2, Doctrine and Midgard discussing issues and solutions in the content repository space. I just hope the other projects also pick this specification up.

Improving performance: AppServer-in-PHP

Of the three, this is probably the most controversial idea. Traditionally PHP is run as a scripting environment on a regular web server, like Apache or Nginx. In such setup, when the server receives a request, it passes it on to the PHP environment. The PHP environment loads all the code needed to fulfill the request, runs it, sends the response back, and unloads everything loaded.

This is fine when PHP is being used in the way Rasmus originally intended, as a simple display layer. But nowadays most of PHP runs on a big framework, whether it is MVC or something custom like Drupal. And loading and then discarding a whole framework for each request is simply insane.

With AppServer-in-PHP (AiP), you have an environment where even a big framework can perform. AiP provides you with a full server environment for PHP, written in PHP. In this setup, your framework is loaded when the server boots up, and then each request just runs the request processing part of it.

During the San Francisco Aloha Dev Con we ported TYPO3 to run on AiP, and the performance results where staggering. A simpler request with not much I/O would run 3-4 times faster than the same code on regular PHP setup, and an I/O -intensive request would still be twice as fast. AiP can't do much about I/O performance, but at least the cost of having a framework is greatly reduced.

In short, AppServer-in-PHP is something any developer running web services with a PHP framework should consider. It is also a great way for framework developers to see if they have request isolation problems in their design.

This post has been written in the TYPO3 Developer Days 2011 event where I was invited to discuss these ideas, and also help run the RDFa part of the TYPO3 Goes Semantic workshop.

• Google already knows everything I do, so sharing stuff there feels less risky
• The UI is pretty and a lot less bloated than Facebook's
• Messages and comments can be edited, saving from unnecessary typos and having to post quick clarifications separately
• Circles are a great way to organize your contacts, and I like the fact that they avoid the loaded friend term
• You can export all your data, so you have a way out if you need one
• Group videochats are also a promising concept

• Facebook already has a crazy critical mass. We'll see whether the non-geeks convert to Plus or not
• There is no integration to third-party services like Flickr, and there is no API
• Content is not language tagged and filtered, like on Qaiku. Google could probably do even better here, doing automatic language recognition and translation

Scaling up some and running Varnish on the main site for the midgard project website show just how much better you can make a website perform.

The data ...

siege -b on http://www.midgard-project.org/documentation/

Without Varnish:

Transactions:                     817 hits
Availability:                 100.00 %
Elapsed time:                   9.69 secs
Data transferred:               3.75 MB
Response time:                  0.18 secs
Transaction rate:              84.31 trans/sec
Throughput:                     0.39 MB/sec
Concurrency:                   14.81
Successful transactions:         817
Failed transactions:               0
Longest transaction:            1.36
Shortest transaction:           0.01

With Varnish:

Transactions:                    2951 hits
Availability:                 100.00 %
Elapsed time:                  10.69 secs
Data transferred:              58.38 MB
Response time:                  0.05 secs
Transaction rate:             276.05 trans/sec
Throughput:                     5.46 MB/sec
Concurrency:                   13.50
Successful transactions:        2951
Failed transactions:               0
Longest transaction:            0.43
Shortest transaction:           0.00

I guess that says it all. I will try to add some more logic to Varnish so that it doesnt cache logged in users.  After that we can launch it  :)

Aloha Editor has an impressive rate of adoption: Drupal, TYPO3, WordPress, Midgard and others are now in the process of integrating the editor. If all of these work out, Aloha Editor can reach an approximately 66% of the CMS market.

And since most of them will do this with my VIE library, this is also great news for Decoupled Content Management, RDFa and the goals of the IKS project.

I also gave a talk on how we use Aloha Editor and VIE in Midgard Create. Both slides and video are available.

Later this week there will be also an interesting BoF in SemTech about Structured Data in HTML that I will try to attend. After that it is time to fly home...

Photo by Nils Dehl.

After the recent San Francisco MeeGo Conference there has been surprisingly much negative reporting about MeeGo, mostly centered at Nokia's MeeGo story. While Nokia's strategy changes are unfortunate, much of the reporting around it appears to come from misunderstanding what MeeGo is about.

Many see MeeGo just as Android without Java, but it is much more, as I'll explain here.

Industrial Linux

MeeGo is much more than just handsets or tablets. It is an attempt at creating a standardized industrial Linux distribution that can be used anywhere from in-vehicle infotainment devices to TVs to, indeed, handsets.

It is a true open and collaborative environment, managed by Linux Foundation. The governance model is there to ensure that MeeGo stays a vendor-neutral platform that anybody can build their products on top.

Many device segments have very long development, and especially usage times. For this MeeGo has a predictable release schedule of a major release every six months, and a roadmap kept by the Technical Steering Group.

If MeeGo succeeds in this, you will be using it in your TV, in your car stereo, and at the back of an airline seat. But in most of these situations you won't be able to know that it is MeeGo. It is simply there to make building products faster and cheaper for the manufacturer.

Openness

As I argued in my earlier piece Open Source? Free Software? What we need is Open Projects, being an open platform is much more than just the licensing terms of the code. There needs to be transparency into the development process, a clear procedure on how to participate and much more. And of course licensing has to be such that the participants can actually use the results in whatever they're doing.

For this, most of MeeGo is licensed under permissive terms, like the GNU LGPL and BSD-style licenses.

But indeed, the other aspects of openness are more important. With MeeGo you can see every commit happening on Gitorious, and you can see the bugs and features being worked out in a public Bugzilla.

MeeGo as a project is still quite young, and many participants are still learning how to work in the open. This has lead to some issues in project transparency. But hopefully those are now getting resolved.

User Experience

MeeGo allows anyone to build their own user experience on top of the platform. Actually, this is expected of any serious manufacturer. Sure, there are some reference UXs available, including Tablet, Handset and Netbook, but none of these are quite product-ready, and are not necessarily even intended to be.

Because of this it is quite funny to see reviews of the reference UXs. They're not the ones most devices will run, though obviously some manufacturers or community members are going to use them anyway. A full MeeGo product will look and feel like something completely different.

This is not like Android manufacturers adding their own skins. With MeeGo anybody has the full freedom to build a complete user experience that suits their device, branding and other goals. The whole platform has been built to allow this sort of differentiation, without a risk of fragmenting the ecosystem. I'll explain the fragmentation question soon.

Actually, the freedom of defining your own user interface is big enough that both Android and WebOS could theoretically be rebased on top of MeeGo to be just different MeeGo UXs. Obviously they would need to allow running MeeGo-compliant Qt applications in addition to ones written for them directly, but that is minor detail. WebOS already ships Qt, so it isn't even that far from this. Similarly, KDE or GNOME could run as MeeGo UXs.

Compliance

At the core of MeeGo there is a set of compliance rules. Being Open Source, anybody can take MeeGo, modify it, and run it on their devices. But only if their implementation passes MeeGo compliance it can be called MeeGo.

Device Compliance is a set of rules that ensures any MeeGo-compliant software can run on a particular device. Application Compliance similarly ensures an app can be installed and run on any MeeGo-compliant device.

Both of these sets of compliance rules have automated tests that anybody can run. So, between non-compliant MeeGo-related software there may be fragmentation, but anything branded MeeGo (and therefore compliant) must be fully compatible.

App Stores and business models

MeeGo is an open source project, not a company. This means it comes without strings attached, compliance rules aside. There are no limitations on the business model of a MeeGo device manufacturer, no mandatory online services or app stores to enable, and no royalty payments.

With this, each vendor can decide what they want to enable their users to do with the device. An embedded device might have no concept of installable applications, a tablet might come with the vendor's own app store.

For those who do not want to go through trouble of building their own developer ecosystems and app stores, there are some generic solutions available in the MeeGo sphere:

Intel's AppUp is a "white label" app store. This means that a device manufacturer, or even retailer or operator can get an instance of AppUp with their own branding and a revenue sharing deal with Intel. Developers submit software only once and it will be available on all the different branded AppUps.

On the more open side, there is also the upcoming MeeGo Community Apps, a fully community driven "store" of free software written for MeeGo. It comes with its own, OCS-compatible client application, a web frontend, and clear set of crowdsourced app quality assurance processes. The similarly handled Maemo Downloads has served over 80 million downloads for the Nokia N900, so the user and developer interest is clearly there.

The future of MeeGo

At this early stage of the project it is hard to make predictions, but there are many things MeeGo gets right. I think it has a bright future ahead of it, especially in more specialized devices. There the shared infrastructure and clear development schedule give manufacturers substantial advantages in both development time and cost.

Product development times in the embedded sector are quite long, and it may well take years before we'll see MeeGo in a airline multimedia system. But if the project shows the necessary durability and longevity, this will eventually happen. Now many of those systems run on customized Linux distributions that their manufacturers have to spend quite a bit of money to maintain. MeeGo removes that problem, and allows easier collaboration through the compliance rules.

As for consumer devices like tablets and handsets, that area mostly requires there to be a vendor that wants to properly differentiate itself from the grey masses of the Android ecosystem. MeeGo provides all the necessary tools on both systems side and user interface development to make that happen.

Currently there are many different ideas floating around on how to build user experiences on connected devices. There is the "wall of apps" approach of iPhone, there are the fully cloud-connected WebOS and Android approaches, and now Microsoft is also starting to enter the game with their own ideas.

I don't think the "post-PC" world is yet complete. What MeeGo gives is a fast way to build products differentiating from that crowd. It just needs companies who are willing to go for it.

The next couple of years will be quite interesting.

I have done this on websites running Tomcat, Wordpress, Drupal on both large installations and smaller ones. And decided to put a sample on how it affects Midcom/Midgard.

I did some preliminary tests on how it would work on this blog using one of my testservers for Varnish. Some small and simple rules made the website almost 3 times as fast. And this Varnish installation is not that optimized.

One of the things todo is to cache images .. we do that in vcl_fetch in the vcl code.

 if (req.url ~ "\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|flv|swf|html|htm)$") {
    if (beresp.status == 200) {
      remove beresp.http.Cache-Control;
      remove beresp.http.Set-Cookie;
      remove beresp.http.expires;
      set beresp.http.magicmarker = "1";
      set beresp.http.Cache-Control = "max-age=604800";
      set beresp.ttl = 1d;
      set beresp.cacheable = true;
    }
  }

Im using an unconfigured Siege on /blog for about 20 seconds.

Before Varnish:

Lifting the server siege...      done.
Transactions:		          53 hits
Availability:		      100.00 %
Elapsed time:		       20.28 secs
Data transferred:	        1.53 MB
Response time:		        4.43 secs
Transaction rate:	        2.61 trans/sec
Throughput:		        0.08 MB/sec
Concurrency:		       11.58
Successful transactions:          53
Failed transactions:	           0
Longest transaction:	       12.66
Shortest transaction:	        0.72

After Varnish:

Lifting the server siege...      done.
Transactions:		         170 hits
Availability:		      100.00 %
Elapsed time:		       20.11 secs
Data transferred:	        4.88 MB
Response time:		        1.21 secs
Transaction rate:	        8.45 trans/sec
Throughput:		        0.24 MB/sec
Concurrency:		       10.19
Successful transactions:         170
Failed transactions:	           0
Longest transaction:	        5.58
Shortest transaction:	        0.52

If you want something similar but without the Google tie-in, then a good option is my social impact calculator which is fully free software written in PHP. It was originally written in 2007, but the newer version has been cleaned of Midgard dependencies and updated to reflect the current popular social networking services. Usage example from my earlier post:

require('calculate.php');

$url = 'http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/';

// Get the raw count for only one source
echo com_meego_planet_calculate::hackernews($url); // 145
echo com_meego_planet_calculate::facebook($url); // 1

// Get weighted total score for all sources
echo com_meego_planet_calculate::all($url); // 130.8

PyGI is a project, which implements dynamic bindings to GObject based libraries for Python using GObject Introspection. Initially, it was a separate project, these days it is merged into main PyGObect. If you read my previous posts, this is kinda what we want to implement for PHP in GObject for PHP project, but for Python.

For the project, I used Python 3. This choice led to the requirement of installing latest versions of software, but the good news is, that coming Ubuntu Natty has a good initial set of software. So, I had to install:

• Python 3.1 (3.2 should work too)
• GObject Introspection 0.10.x
• PyGObject 2.28.0 (2.27.x-dev series are ok too)
• If you plan to work with ØMQ, as I did, be sure to grab PyZMQ 2.1 series (easy_install will probably work)

The main library, I worked with — libmidgard2 — supports GObject introspection, so I didn’t need to install anything python-related to make it work.

Ok. Here are some hints on coding using PyGI.

    # to use introspection-friendly library use import statement similar to this
    from gi.repository import Midgard

    # global functions are available directly in imported package
    Midgard.init()

    # constructors are ALWAYS called with "named" parameters
    config = Midgard.Config(dbtype = "SQLite", database = "testdb")

    # library errors are thrown as exceptions
    import gobject
    try:
        do_something()
    except gobject.GError as e:
        print(e.message)

    # want to know name of objects GType?
    print(obj.__class__.__gtype__.name)

    # want to get list of non-object properties of some GObject?
    property_names = [pspec.name for pspec in obj.props if not pspec.value_type.is_classed()]

    # need to get names of all classes, which inherit from your GObject's class?
    # (note: Midgard.Object is the class to be replaced by your class)
    child_names = [gtype.name for gtype in Midgard.Object.__gtype__.children]

But, novice Git users don’t know how to do this optimally, and “naive” approach leads to complexities. Git is a distributed version control system, which means that everyone can “commit” to their copies of repositories. Syncing these commits with upstream is a bit more difficult and leads to commit-conflicts sometimes. So, here’s aforementioned “naive” approach:

1. Fork upstream github repository
2. Clone forked repository to local machine
3. Make changes
4. Commit
5. Push
6. Send Pull Request

It will work, but, there’s one non-obvious thing: pull request, probably, won’t be merged immediately and there are high chances, that there will be some commits commits pushed to official repository before our commit is merged. As the result, we have a conflict between upstream repository and our forked repository. So, at this point, if we plan to use our forked repository again, we have to “merge” upstream changes. It’s not end of the world, and git, if we’re lucky enough, will do this merge automatically as part of “git pull upstream“, but it won’t be “fast-forward” merge and github’s “Network” diagram (or branches diagram in your favourite git GUI) won’t be nice and clean anymore.

There’s better approach, and it’s name is “Feature Branches“. It’s quite simple. Once you have cloned forked repository (i.e. after steps 1-2), use “git checkout -b new_branch_name” command (it’s nice, if “new_branch_name” summarises changes you’re going to implement). This command creates new branch, starting from current “master” and makes it active. Make changes and commit them: “master” branch is left intact and all the things you changed sit nicely in this new branch. Now, push these changes with “git push origin new_branch_name” command. This will send your new branch to github. Now, open this branch on github and send Pull Request from your “new_branch_name” to upstream’s “master”, as usually.

Use “git checkout master” to return to the “master” branch, and, whenever upstream merges your changes, and you pull those, they will appear here automatically, without a single “merge” effort from you. As a bonus, you get beautiful tree of branches without complex knots.