I have installed git with gitosis on ubuntu and on mac osX several times in the past months, but I have to admin that although I’ve done it all in command line on the servers, the internals were still a bit obscure to me.
My vserver runs Gentoo, and initially I installed git and gitosis via emerge.

However, unlike my previous installs where I blindly (but successfully) followed the instructions and how-tos, I could not find anything else than how to host a public repository on Gentoo. Remember: these instructions are for a public repo!

That means that you’ll be able to pull from the server, but not push.

The explanation is simple: the way it’s presented will only ever user git-daemon, provided by git, that is designed to only server pull requests.

These instructions work well and in 10 minutes I had a public repo working flawlessly, but I wanted a private one where I could push my code and use it for automated deployments.

Killing git-daemon – Back to square one.
Like many out there, I guess, I followed the excellent scie.nti.st guide.

For Gentoo, this has to be changed slightly though.

Assuming you’ve setup git and it’s working fine
emerge -av dev-util/git
you haved cloned gitosis
git clone git://eagain.net/gitosis.git
and you are trying to install it
cd gitosis
python setup.py install

python setup tools might not be installed on your system.
On gentoo, to install them, use the following
emerge -av dev-python/setuptools

Adding the git user takes slightly different options too

adduser \
--system \
--shell /bin/sh \
--comment 'git version control' \
--home-dir /home/git \
git

Now, the part that confused me, the gitosis init. As there is no sudo on my system (and I believe on many others), i could not execute the indicated command. Ok, no big deal in the end, just do by hand what the sudo options do for you:

By becoming the git user and switching to its home directory, you cover the -H and -u options of the sudo command that you’d otherwise use on other systems.
su git
cd /home/git

then run the init script with the public key of your remote account uploaded in the /tmp folder f your server
gitosis-init < /tmp/id_rsa.pub

Now follow the rest of the tutorial and you're good to go.

Just one last thing, unlike the automatic emerge of the gitosis ebuild, your repositories will be in /home/git/repositories by default.

If you ALSO want public repositories, you can always use git-daemon when you want too. It works independently and can be in parallel of gitosis.

Launched in August 2009, Social Life has consistently attracted customers and offers a wide range of social networks integration.

Having worked on it since it’s very very early stages, it feels great to look at it and feel proud that we all made it!
I remember the day when my boss came around and asked my availabilities for ‘the months to come’ =)
These months started by creating an HTML and JavaScript mobile prototype to be demonstrated around the business units. It already has live update of a twitter feed and notifications.

The interface was going to be really different from anything that had been done so far, promoting social activity through some cleverly expanding friends icons on the home screen depending on their amount of activity, easy access to communication functions directly from there, and deep integration of the social networks in the usual device capabilities.

Things have slightly changed since then, but the concept is the same, and it works!
The whole service sits on top of a pretty big architecture to allow integration through a single access point into all the required social networks. We’ve worked together countless hours into the specifications of this API, the integration with Orange’s partners, developers, manufacturers and vendors, done quite a few business trips around Europe to finally bring it all together!

Now, it’s been rewarded for it’s simplicity over some bigger players in the market and from the point where I stand in R&D, for most of my work to be hidden from the outside world, I am exstatic to see that what we do in R&D (along with Snapshot) is real stuff that makes it out.

Happy about my second award in the month =)

Sometimes you are requested to do a quick job at work, that “should not last longer than 2/3 days”.
We’ve all been there, all done it and in my case in R&D with Orange, seen too many times the “project” end up in a drawer somewhere.

However, this time, I have been assigned on that “little project” called snapshot, for which the goal was simple: our team racing designer was creating the graphical design and I was translating that into XHTML/CSS as well as XHTML-MP templates for mobiles as quickly as I could

As you’d expect from super quick things like these (mind you I was already assigned 100% on two other high profile projects before that came on), we had to cut corners. For example, there is no support for older browsers like IE6 for the moment. No time to work on that unfortunately, but it should not be too difficult to adapt the templates and CSS and found yet again a hacky way around double margins, wrong positioning and lack of png support.

Integration was quick with the dev team, although not super smooth, but for once it was going to make it as a product! It’s now all on http://snapshot.orange.co.uk and it’s official

Some features might be added sooner or later to the site, but hopefully it will be kept simple!

From initial feedback, it seems the most wanted feature is the ability to rotate the pictures, and it will be done soon!

So for one of the very few R&D projects I worked on that actually made it to the market and I can showcase, it’s celebration day!

Rather than keeping the single access token generated at user registration untouched, like a standard API key, I enforced it’s regeneration at both login and logout. Returned in the login response, that token then has to be provided by the client for every request that needs authentication, effectively playing the same role as a cookie.

With this solution, the client looses the ability to stay logged in by storing the credentials in the client’s machine, but as the project it’s been created for only required an API, there was no problem with that.
Implementing this solution simply puts a little big more work on the client to store and provide the token in the requests parameters, but I still found it an elegant solution to get around my problem.

The following code implements this solution in the Application and the User_Session controllers, showing the regeneration of the token in both login and logout actions with authlogic’s reset_single_access_token method.

app > controllers > user_sessions_controller

 class UserSessionsController < ApplicationController

  def create
    @user_session = UserSession.new(params[:user_session])
    respond_to do |format|
      if @user_session.save
        current_user.reset_single_access_token!
        format.xml
      else
       format.xml {render :xml=>@user_session.errors, :status=>:unauthorized}
      end
    end
  end

  def destroy
    if(@user_session = UserSession.find)
      current_user.reset_single_access_token!
      @user_session.destroy
      respond_to do |format|
        format.xml {render :xml=>{:status=>'200 ok'},:status=> :ok}
      end
    else
      respond_to do |format|
         format.xml  {render :xml=>@user_session.errors, :status=> :not_found}
      end
    end
  end
end

app > models > user

class User < ActiveRecord::Base
  acts_as_authentic
end

app > views > users_sessions > create.xml.builder

xml.instruct! :xml, :version=>"1.0" 

xml.user{
    xml.user_id(current_user.id)
    xml.user_credentials(current_user.single_access_token)
}

app > controllers > users_controller

class UsersController < ApplicationController
  before_filter :check

  def create
  end

  def index
  end

  def update
  end

  def show
  end

end

db > migrate > create_users

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string  :username
      t.string  :crypted_password
      t.string  :password_salt
      t.string  :persistence_token
      t.string  :single_access_token, :null => false

      t.timestamps
    end
  end

  def self.down
    drop_table :users
  end
end

Key note by Nick Alliot (OMTP), Rick Fant (vodafone), and Caroline Lewko(WIP)

The global trend was said to see the desktop applications to be more and more ported onto mobile devices, requiring the same level of standardization and development tools that the desktop web has benefiting for the past years.
It became clear that the ratio of web developers to native apps developers (100 to 1) was very much in favor of pushing forward web activities for mobile devices.

The BONDI APIs are part of the possible answers to the problematic, through fast standard activities driven by reference implementation, offering local APIs to browsers such as device status and geolocation, all thinking about the security of devices, apps and users and letting the market and the developers decide the level of protection they require. The next delivery of the BONDI APIs is expected to be V1.5 for Q1 2010.

Rick Fant from Vodafone then presented the new “360″ new web connected services and Vodafone apps division to go with them, following as much as possible open standards to allow any developer to produce any application as long as they are not of objectionable content. It seems Vodafone 360 services will have connected widgets supporting the latest web standards, and should be delivered for Xmas 2009. Supporting ideas like connected contacts, the 360 services should be available on S60 devices, and will also incorporate JIL widgets, W3C standards and handset APIs to enable developers to quickly produce applications.

Following Rick, Caroline Lewko, from WIP, presented here company’s products and the API wiki they host, including an interesting summary of current application stores that are flourishing on the market. It is indeed more than 15 mobile app stores that have been recently, or will be soon available on the web, amongst which it can be forth noting the presence of the following

• china mobile
• vodafone
• orange app store
• Nokia OVI
• blackberry (that chose a ‘no free app’ approach)
• get jar (independent, mostly free apps)

More information on http://wipwiki.com/index.php/appstores, http://www.wipconnector.com/ and http://wipjam.com/.
This key note, although slightly too commercial I think to be very honest (sponsors oblige I guess) gave the tone of the trend: app stores, app stores, app stores and a bit of the design process. It is important to note that many factors are still ignored from developers and even development companies in their process to develop mobile apps:

• Keeping an eye on the target not to miss it is important. Too many mobile application started with a good idea but did not succeed as the market evolved quickly during the development.
• Don’t forget UX or the application will get dropped
• Platform choice might be a difficult one to do, but will be critical to reach the target market
• How do you apply charging and generate revenue through the apps you sell?
• The submission process might be long and painful for some app stores, faster for others. It is yet to be understood fully why the android app store releases the apps straight away after submission when the Vodafone process is said to take up to 10 days, and the apple one up to…. 4 weeks!

UX mobile design

The first session I attended concerned application design through an iterative process of paper prototyping and user reviews. All details about this session here http://blog.ekynoxe.com. Presenter was Tom Hume from Future Platforms.

cross platform programming

The second session of the day concerned the creation of cross platform mobile applications. Wolfram Kriesing pointed out that there are many ways applications can be built and distributed on mobile devices: as part of the pre-installed software, as a native application such as a Symbian bundle, as a web application which access is limited to mobile phones browsers, and as W3C widgets.
The emphasis of this session was to make developers realize that developing a native application will only reduce the number of users it reaches, but this is only one aspect of the problem.
Widgets should not only be thought as only a mobile application, but should have a wider range such as the ability to be published on iGoogle or other desktop web platforms. But as there is no killer app that can do everything and do it well at the same time, a better approach is to concentrate on simple use cases only, and execute them well across many devices and OS.

Recommended specifications to follow include:

• JIL spec
• BONDI spec
• W3C spec
• open source “phoneGAP”
• nokia WRT (only nokia)
• G Chrome OS?

Ericsson Labs APIs

Ericsson labs presented their APIs. Unlike common belief, they are not Sony Ericsson, but do work on mobile application APIs, providing also coding resources, hosting for some applicationss, a showroom for publication and hosting of IMS solutions. Their model highlights a centralized provision of telco enablers and internet enablers. At the moment, Ericsson provides mobile Java communication APIs, Mobile Java push to allow push notifications to be sent to mobile devices, Mobile Maps as a set of J2ME and web developer tools for developers, SMS send and receive and Web location to enhance web applications with location based services. Their coming APIs will include mobile location, streaming media, media fabric (Ericsson does aggregation from providers and streams to devices)
At the moment, these APIs are available on JAVA and Android phones, but Ericsson Labs is pushing to extend their coverage of technologies in the future.
All web APIs are available from any platform as they are exposed as a REST architecture.

W3C recommendations

Later on, at one of the W3C sessions on mobile web best practices, it’s been obvious that the recommendations on mobile devices include the same set than for desktop devices for their basis, but also incorporate mobile devices specifics such as follows:

• No popups as everything happens in a single window, it would not make sense.
• No link using the “target=blank” property to minimize the number of windows opened on the mobile device’s screen, if the device allows it anyways.
• Work in one column only, because of the limited width most mobile screens only accommodate
• Get the markup right so as to limit the possibility of errors at display, which can be more critical on a mobile device than on a larger screen.
• Use DL list instead of tables for tabular data for mobiles. It appears that many mobile browsers are unable to render tables relatively to the small size of the screen, forcing the view to scroll horizontally which is both inconvenient and can be impossible to do.

The flip cards given out at the session summarize these points, but require the reader to also comply with desktop standards.

Mobile push notifications

Mobile push notifications (by dale lane, http://dalelane.co.uk/blog/?p=938)
Alongside the standard polling and long polling techniques to retrieve new data from a mobile application, some platforms use SMS push in order to trigger the device to fetch data such as Betavine.
Another solution developed by IBM is called MQTT for MQ Telemetry Transport. It has been created for applications with time critical issues such as fire alarm for deaf people for example.
The technology, which resembles SIP in some ways in its subscribe/notify mechanism, is available online with client libraries available in many languages, but some aspects of the protocol have been deliberately kept in the commercial versions, such as security with encryption of payload data.

On the subject of designing the application not require too much data exchanges, it has also been suggested to incorporate caching, which can be done using google gears to cache on the background

The Hackathon!!

Some of the best projects in the Hackathon of Friday night included:

• Drinker, an app that helps you count the pints you’ve had by displaying a disk that grows bigger with the amount of drinks (supposedly easier to press)
• Project Blue bell which use bluetooth signals from mobile phones in the conference hall to generate both a musical and a visual representation.
• An offline wiki editor for android.
• A Bondi password generator/storage. This was generating a random password and keeping it on a mobile for the user to find easily afterwards.
• A hangman game for which the words are based on the twitter usernames of a given hash tag. This has been hugely successful and continues to live and expand outside OTA09.
• The non coding but truly amazing hair blowing holodeck project from ewan spence

The highlights and what to remember from my point of view

• TWITTER TWITTER TWITTER!!! We can’t highlight enough how much the tweets have played an importance in this conference. Unless you have experienced it for real in such a reunion of geeks, you can’t really understand how much twitter can deliver! It’s quite impressive the amount of updates and exchanges that have been taking place over the two days of the conference and even after it.
• Good ideas in the contests, and good small apps that can go forward quickly! I can cite directly the creepy friendhangman from Makoto Inoue or Something around you by Alfredo Morresi, Stefano Zingarini, & Robert (Jamie) Munro
• Teens Dragons Den gave some critical insight into the future of oure apps and the market segements we are targetting right now. One of the most striking remarks that must be remembered, not only for teenagers apps, but I think for any app that will hit the market was “can you get it on ‘regular phones’? None of my friends use Android.” Just remember who the target market is and build on purpose is the message here!
• BONDI APIs have been very much in the line of fire from all developers during the contest, and later on twitter, as many tweet suggested. Several developers dropped the idea of using them altogether saying there “The BONDI SDK isn’t an SDK, there is a runtime … but no actual developer tools!”. That can summarize quite well the general feeling about it as only one contestant in the competition, Kai Hendry for his BONDI password generator, managed to have an app working with the BONDI APIs.

Altogether an amazing two days of interactive conferences and great fun.
Thanks to you all for that, and thanks for the bean bags that did raise a few looks in the tube back home!

In teams of 4-5 people, we were all given the same requirements in terms of target market (or character), but almost all different devices.

The target character: Jeremy, keen mountaineer, 42, 2 kids and dyslexic, is not an uber-user of the web and prefers voice chats, but will not mind using emails.

The application was to be designed to help him enjoy his mountaineering experience, while enabling him to share it with friends and family.

Now, that’s where it becomes interesting: each team is given one device on the first iteration of the design, and that will change on the second one. This might seem to be a detail, but as we will see, it had a great impact on some teams later on!

For the first iteration, my team was given a nice wooden representation of a Nokia 6210 which did not have all the fancy gadgets you can find on a top of the range device, and with this in mind, the team went only for a limited, but still relevant set of features that would be do-able on the little handset. But in the process, Matyjas rightly pointed at the fact that for iteration two, we might have a way more rubbish device. And this was the real key of the session for many teams!
At the end of this first iteration, we integrated a member from another team to simulate a quick 5-min user testing and got feedback on our “product to-be”. Interestingly, we had Tara, graphic and UX designer from ribot and she commented on the importance of making textual input easy and intuitive. Indeed we had neglected that in what we have been talking about, and this was going to go in the pool of improvements for iteration #2.

After I presented our team’s first app ideas and the “user testing” feedback, we have been handed our second device, which was like an old Sony Ericsson p900. Interestingly, this device was in almost all points identical to the newer nokia, including the screen resolution that was really close, so we decided not to change much of our application, except a slight re-factoring of the proposed UI, as we had a touchscreen with this new device.

My team did not have to apply many changes because the two devices were quite similar, but as already suggested, for others, it’s been a different story altogether. The most impressive change being for teams that initially went berserk on apps features, but were then handed a clam-shell phone without almost all media capabilities. What do you do in that case? Yeah, you’re stuck! One team even considered getting rid their first design altogether!

It was clear at that point, at least to me, that pure developers, like most of the people in the room and some in the team, do not think far enough in the life cycle of their future application. yes, we do have some fantastic high end devices available like the iPhone or the Gphones, but one must not forget that the majority of the users out there:

• don’t own one of these super high end devices
• are not interested into gadget features
• don’t even know what twitter, facebook and other hype social activities are

Hence, if your application is targeted at the average user, there is probably no real need to cram as much of these functions trendy amongst technology savvy users as you can. The UX will only be clearer to everyone, simpler to build and leave you with more time to refine it properly instead of integrating lots of APIs.

Conclusions drawn from this workshop were interesting from a developer point of view, but I think also from a general UX design point of view:

Lessons learned

• Don’t ignore the importance of the key features (The text in our case!)
• Constraints boost creativity and passion (that has to be remembered and repeated everywhere!!)
• More voices help (probably only up to a certain point)
• Basic ideas translate well across devices
• The second iteration helped in refining, or re-defining the application
• User testing helps a lot! (And must probably be always integrated in any project, which is sadly not the case!)

Difficulties encountered

• Starting out is tough, specially in defining the scope of work
• You’re on mobile, so think of the size of these buttons (whether hardware or touchscreen elements). That has been dubbed the gloved man problematic ;)

Changes required for #2

• Device constraints almost pushed some teams to completely throw away their #1

Surprising facts

• Basic devices can be better in some cases (especially when you try to design an app for the average user)
• It’s tempting to over-crowd the app with unnecessary features for the target market
• Paper prototyping helps concentrate more on the actual functionality rather than the polish
• Did I say constraints bring passion?

If this type of exercise might be common practice for designers, being still more of a developer, it was a great session to understand the basic principles of UX and common mistakes made in teams where designers are either neglected, not understood, or even worse, non existent!

If the two first ones have been of little trouble to install, I can’t say the same for Xdebug.

At first I have followed all the common tutorials that you can find around the web:

• downloading the pre-compiled xdebug.so for my PHP install
• simply copying to the proper folder
• modifying my php.ini configuration by adding the correct zend_extension parameter for [xdebug].

Until here, nothing fancy, it seems to work for most. BUT, when every install how-to on the web says “that’s it you’re done”, nothing happened for me. Xdebug was not loaded, there was no error message and everything was still running fine.

That’s when things started to get complicated, given the amount of combination possible of wrong configuration parameters and pre-compiled available shared objects, all of which would fail silently if anything would go wrong.

I tried to change zend_extension to zend_extension_ts because I was running PHP 5.2.8, but this did not change anything, I tried to compile xdebug.so manually and use the compiled object with the several parameters combination I have already tested with the pre-compiled version… Nothing. not single error or idicatio that could put me on the right way!

Then, I came across an old article on devzone.zend.com that I have discarded at first for its age (December 2007…) but that I ended up reading thoroughly and the following lines flashed before me:

Please note that phpize and php-config must match the PHP version you are using, so do not just copy them to your system from some other PHP installation. When your development tools are in place, you can download and compile xdebug

The phpize command on my system was not pointing to the proper one, as I compiled my own AMP install on the Mac. Running the proper phpize (in /usr/local/php/bin/ for me), it gave kind of a weird result:

PHP Api Version: 20041225
Zend Module Api No:
Zend Extension Api No:

Yep! No Zend API version numbers at all. As phpise is a simple shell script that extracts the API numbers from the PHP and Zend configurations, I thought there was a problem simply with my PHP install, and not with xdebug at all.

As I was running 5.2.8, I upgraded to PHP 5.3, cleaned all xdebug.so files, cleaned my php.ini file and tried it all again!

The pre-compiled version DID NOT WORK either, but compiling it myself from source, this time phpize giving the right API numbers:

PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626

And finally xdebug worked!
So, a few things to remember:

• sort your PHP install properly first, with the commands pointing to the right places. That’s also valid for php-config that is required for the compilation of xdebug
• trying the pre-compiled version might not work on your system, so compile your own, it’s simple enough and the article on zend.com(http://devzone.zend.com/article/2803), albeit old, is still valid

1. you are served the expected website, the url stays the same
2. you are redirected to http://www.domain.com or some other url
3. you get a 502, Bad gateway timeout

I don’t know if it’s laziness, lack of knowledge or simply host providers being plain rubbish, but it’s an annoying problem that can be solved extremely simply!

Most of websites that are not configured properly often get away with it as many internet users believe that ‘www’ is a compulsory part of any web URL.
In fact it’s only because of an old practice of naming hosts according to the services they provide, in our case a web site, with www. FTP using ftp.domain.come etc.
But it has nothing to do with any technical issue or any standard.
Not many (if any) ‘Mr average’ know this!

One of the problems is that with the advent of new web browsers that suggest you URLs from your history, or even perform straight away an interactive search of web resources that match your typing, it is very easy to fall into the usual consumer laziness and let the browser find everything for you. That way, you get into the habit of accessing a website just by typing the domain name, without www or any other prefix, and sometimes even without the top level domain (The ‘.com’ or other ‘.something’).

I’m the first to do it and that’s why I probably end up on these poorly configured web servers from time to time.
But I am still quite astonished to it see happen, as it can seriously lead to some misunderstanding from the average user. If I don’t know anything of internet, don’t care about ‘www’s, just type a domain name in my browser and get an error page, I’m not going to try very long to search for how to access that site!

That problem has a simple solution though.

First, if you have access to them, check your DNS records.
This step might not be compulsory, but it won’t harm to check them anyways.
Your domain will have an A record to point your domain name to the IP of the host of your web site:

domain.com        A         0.0.0.0

You can also add either an A or a CNAME record for the www sub-domain. The syntax differs:

domain.com A 0.0.0.0
www.domain.com        A 0.0.0.0
www.domain.com CNAME domain.com.

Second, check your web server configuration that it actually is accepting requests from sub-domains and serving the proper files.
In Apache, for example, you can set it up by adding a virtual host:

Listen 80
NameVirtualHost *


<VirtualHost *>
ServerName www.domain.com
DocumentRoot /home/httpd/htdocs/
</VirtualHost>


<VirtualHost *>
ServerName domain.com
DocumentRoot /home/httpd/htdocs/
</VirtualHost>

or using a server alias:

Listen 80
NameVirtualHost *


<VirtualHost *>
ServerName domain.com
ServerAlias www.domain.com
DocumentRoot /home/httpd/htdocs/
</VirtualHost>

So yes, I admit, you have to have access to the DNS entries and the configuration files of the server. But even if you don’t and it’s down to the host provider to configure the DNS and the web server files, it is very easy to set these up properly.

Ok, again, you might argue that you could serve a different version of the site with http://domain.com and http://www.domain.com, but if you don’t and there is no redirection in place, just make sure you don’t serve a 502.