Vacation over!

In our hectic occidental life, we are not used to stop doing what we usually do, i.e. work (and shop by judging on the popularity of shopping mall)! My break lasted for more than 4 months, in which I did enjoyed playing with the kids, reading more books than the last 4 year, biking around 1000km (although it was late in the year) and did various other things we usually don't have time doing during our short 2 days weekend break (BTW, yes I must confess I also did work during this break!). I guess it looked fun, since my wife got jealous and decided to take a break with us as well!

But it seems we are well programmed to live our active life which is not difficult to understand considering that we are brought up to it at very early stages (when I see those 4-5months old at aycare, sigh!). So after a while I was quite motivated to go back to work, but first I needed to find one.

Although I have my own consulting company, contracts don’t come so easily when you are a foreigner in a foreign country. I’ve worked in Lausanne before, but mostly involved in job at the backend, i.e. the RDBMS. My experience acquired within my consulting firm helped me broaden my knowledge in the J2EE environment and improve my ability as a consultant. This is the sort of skills I want to exploit in my new job.

So that means starting all over again and look for jobs the normal way, i.e. sending resumes, meeting new people and company and go through interview. Not the most fun, however I decided to take it seriously. The thing is, in my previous two jobs, I did not bother much about sending resumes and going through interviews. Actually I targeted only a single company, went through the normal hiring process and got lucky enough to get the job I was interested in.

So before leaving Canada, I actually checked the job market, identified a few potential firms/jobs and send them a link with my online resume. I started with about 5 or 6 of them, from which there were middle man ("intermédiaire"). I though that this would be enough as a first step and I could find additional target once arrived here. I must say the job market for my skills is well active in Switzerland, because this initial sending lead to an impressive list of follow-up:

-6 interviews
-1 psychometry test
-1 technical test
-3 phone interviews, etc… and 4 job proposal!!

p.s. Don’t underestimate the effect of the middle-man which can have a multiplicative effect.

Comparing this with my first job interview at Lausanne, for which I felt I was being sold a job rather than the opposite, I must say that things are more professional and most firms take recruitment very seriously. I've been through very high-level technical interview, challenging test, and very precise questions requiring thought-out answers and leaving not much place to subjectivity.

This took me quite some time and energy but I’m happy to have dedicated this effort because at the end this pays off and offered me the luxury to choose a job that meets most of my criteria (in order of importance):
1- type of work involved
2- type of technology involved
3- advantages like salary, vacation (of course!)
4- location of work
5- type of work environment


I’m happy to announce that I have accepted a job as a consultant for SWORD. This job will give me the opportunity to see former colleagues (because the first contract is at Orange), work not too far from home (Geneva looked cool but the commuting would be a bit too long, at least until they finally open the new metro M2 line at Lausanne), and I'm given the opportunity to exploit two of my expertise BI and J2EE!


Martin

Arrivée en Suisse

Les deux dernières semaines ont été très occupées pour toute ma petite famille… nous avons organisé notre départ de Montréal pour aller s’établir à Epalinges juste au nord de Lausanne à quelques 830 mètres d’altitude (donnée importante dans cette région du monde puisqu’elle détermine la présence de neige en hiver).

En plus de toute l’organisation reliée au départ d’un pays, on a dû affronter les tâches reliées à l’arrivée dans un autre pays. Et l’arrivée fût un peu perturbante puisque le container avec tout notre mobilier est en fait arrivé en retard et ma femme n’a pas encore officiellement son permis de travail (une simple formalité … mais qui nous empêche pour l’instant d’être des citoyens avec les mêmes droits que les autres…. dans nos sociétés “modernes” ceci veut dire consommer). Donc nous avons campé dans notre nouvelle maison avec matelas d’appoint et le stricte minimum pour plus d’une semaine. Ceci veut dire pas de tv, pas de radio, pas de téléphone (on a finalement pu acheté un téléphone avec carte prépayée seulement), et ….le plus difficile pour moi, par d’Internet!

C’est inquiétant comment je suis rendu dépendant à l’Internet, en fait j’ai pas eu de souci pour la tv, le téléphone et la radio mais impossible de vivre sans ce monstre. Je m’aperçois que j’ai comme plusieurs pratiquement tout réorienté mes sphères d’activités vers le TCP/IP… scary !!! Ex: communication avec la famille sur Skype, email, et blog, transfert et opération bancaire via site bancaire, projets de développement storés sur site en-ligne, mis au courant des nouvelles, guide d’achat et localisation des commerces, etc... (Parenthèse professionnelle: pour quelqu’un qui fait de l’architecture de système, je devrais modifier cette dépendance des plus fragile afin que mes moyens de communication re-deviennent plus résiliente et robuste aux échecs « tolerance to failure »).

En ce qui concerne notre villa, tout est vraiment bien et nous avons en bonus une belle vue sur les alpes à partir des fenêtres des combles (Bernoises/Valaisannes et de la Haute-Savoie française)-- voir photo en debut de texte.

Martin

p.s. étant éloigné des miens restés au Québec, ce blog va prendre une tangente plus orientée personnelle, avec par contre toujours des sujets techniques qui devraient êtres nourris par mes expériences dans le domaine de la consultation.

Quick solution for Spring & GWT integration

As promised in my last post, I'll describe here how I proceeded to integrate my service bean layer managed by the Spring container with the RPC mechanism offered by GWT.

GWT toolkit offers a custom servlet (RemoteServiceServlet) from which we can inherit in order to let client code calls server-side code asynchronously. The solution I implemented was to create a base Controller which simply extends the Google RemoteServiceServlet. See code below.
(I no longer has access to these files, so I just removed them for now)




By subclassing this new base Controller, all my service-bean classes become now GWT-RPC compatible. This simple solution has some drawback such as adding a compile-time dependency between my service-bean and the Spring framework/GWT, however that is just fine for my specific use-case. More clever solution could also make use of reflection in order to leave your service leaving the service-layer classes free of such dependency, however this will come at a price of more intense processing needs. For those interested see the GWT Server Library initiative.

However for me, this simple solution offered a very convenient caching mechanism to improve performance all client accessing these service-beans. Since I have some RPC service objects on the server layer for which result are cached to avoid the expensive database access hit. Because these result objects contain long object graphs (a few number of association at various depth level..), I also wished to avoid the GWT serialization process involved at every hit of these cached object graph. To achieve this, I wanted to store the GWT-serialized version
of my result objects instead of the normal de-serialized graph. The cache is planned to refresh itself at regular interval...

All my service-bean achieve this by optionally intercepting the RPC request (i.e. override the method 'processCall') and use the GWT-serialized value when available in cache (see example below).
(I no longer has access to these files, so I just removed them for now)




Martin

Web development

Up until my current project which uses GWT to develop a rich web client, I always followed the best practices in terms of Web development. I used to develop thin and dumb client view (e.g. jsp) which were fed and render based on data model objects and eventually sent back to the web client.

All web requests are taken care by some dedicated controller (or action in Struts parlance) that are responsible in analyzing the user request, delegating the request to the service layer (the core of the application where business rules usually sits), obtaining the return domain object from the service and preparing the response by selecting the proper view to be rendered and sent to client. Ok, that is a very brief and incomplete description of the MVC pattern adapted to the Web server and HTTP protocol. Although this design pattern may be overkill for smaller applications, the advantages (e.g. makes web applications that are easier to maintain and are logicially divided into layers that are inherently decoupled and whose focus are on very different software concern) usually outweight the additional learning curve and relative complexity.

A great deal of coding must be done on the controller aspect of the MVC. And a lot of this includes details originating from handling the request/response of the stateless HTTP protocol...which has very little to do with the main application business logic. If I'd have the choice, I'd rather spend this time developing and improving the business objects domain, the related business rules logic and the database model, i.e. my preferred subjects and expertise!


With the advent of AJAX Web 2.0 fat client, a great deal of the weight that used to sit on the web server shoulder implementing this MVC pattern has now moved toward the client sitting on the other side of the communication channel. Web clients now make asynchronous RPC (remote procedure call) to the server without having to deal with the of HTTP concern details (for example the RPC mechanism of the GWT API isolates client code these). They can also now handle their own session state by keeping and handling the data model locally.

The server can focus less on the "C" of the MVC, and more on the service core layer designed to enforce and apply all business rules logic. The client code can choose to implement the traditional MVC pattern, when its complexity justifies it.

In my current project, all web controller codes disappeared and my web application does not move anymore from one page to another (following subsequent user request), but rather change its unique page appearance (by replacing/changing section of page through DOM manipulation) followed by user action and RPC response from the server.

My next post will present the way I've implemented my RPC client code to talk directly to my service layer using the Spring Framework. Now, I need to get back to work!

Martin

my Web2.0 experience with GWT

My last month as a freelancer allowed me to have made quite important progress on my current project. I find it quite motivating since I'm the main analyst/designer/developer/tester and even business analyst (actually, I'm all alone on that one, so no one to blame or complain about;-). Technology wise, it's a perfect situation since I can freely chose all components based on design merit and no decision is based on political constraint of some sort.

Currently the technologies involved are:

On the server:

- Spring framework, iBatis, ehcache, Quartz, Velocity, and eventually the servlet container (not yet decided.. but the development is obviously done using Tomcat).

On the client:

- GWT and a few velocity pages.


The novelty for me is the use of GWT (Google Web Toolkit). I've already mentioned my frustration in developing client side code especially using http-based web client. The time spent on the page design messing around with jsp tag, html and css styling seems to me as a big wasted time and effort. That's why in my professional life I'm usually involved muck closer to the back end where my expertise is more profitable for the client.

Now with the advent of GWT, client side component is no longer restricted to thin and dumb page presenting the view/model already prepared on the server. A lot can happen on the client with the capability to hold on great deal of state information and business logic. And this magic is done without adopting Javascript and sacrificing the strongly-typed property of Java.... the toolkit does the Java-->Javascript conversion for you!!!

So far I'm quite pleased with the toolkit as it practically eliminate the need to write any html markup... however all styling still depends on css. I'm probably half-way there for the client part and only have a single html page with just a few lines of markup html code.

The server integration is done through RPC call (done asynchronously à la AJAX style) with servlet on the server end. A great deal of design effort is done by keeping the server scalability as a top priority. Because the application will target the web public at large, most design decisions are affected by this, e.g.

• Keeping minimal state on the server. As a matter of fact, with the help of GWT most state is kept locally while the server only keeping a session token (cache in memory) to identify valid client connection. This will avoid issues involved when relying on HttpSession object (to hold client state information within servlet container) such as server affinity and more importantly larger memory footprint per connecting session.




• Data is cached both on the client side and on the server side. Because some data is not mission critical, the client keeps some data content (limited size) and the server keeps all data content in cache eliminating the need to hitting the database back-end during most client request.
  




• The cache server data content is refreshed at fixed interval of time which is configurable depending on the data volume and the database query extraction time
  




• The cache server data content is kept in a de-serialized GWT form, avoiding the need to serialize the payload of server response at each client request.
  

I'm confident to be able to put a beta version of the application before the end of year... stay tuned!

Martin

La gang de Chicout!

Bon ce qui semblait anodin à l'époque relève maintenant de l'exploit: avec un petit groupe d'amis datant de l'époque du Séminaire de Chicoutimi, nous avons réussi à rester chums et garder contact à travers tout ce temps passé (ouch, près de 30 ans ou plus pour certains!!! ).

Les bases de cette amitié sont assez simples: on ne se doit rien et aucun reproche pour les manques de nouvelles ou absences plus ou moins prolongées... et le tout reposant sur un passé commun durant une période de vie assez agitée. Cette période demeure encore la source principale de nos discussions et anecdotes interminables.


Ca sera mon post le plus court car malheureusement on ne peut en dire beaucoup sans risquer d'entâcher et compromettre des vies d'adultes responsables ... quoique le risque d'en voir un tombé sur ce site reste faible!

Donc pour conclure voici deux clichés pris avec pas mal d'années, de kilos et d'enfants en plus:


Party d'une date quelconque mais assez lointaine :

Dernier party en date :

From photos_amis

Martin

Laurie and Mathias

I never spent too much time writing about my family here... naturally I tend to value more the time that I can spend with them instead of the time that I could write about them!

I just wanted to post a few pictures looking at my kids growing up. The thing that come into my mind looking at these pictures is: "Warning: Kids are less calm than they appear in photograph!"

But nevertheless we've got really two great kids, Laurie my daughter is now 5 and Mathias 3 years old and I'm confident that they'll continue making me a very proud dad!








Martin

That's it I'm changing career path!

I've eluded in my previous blog all my frustration concerning closed source software... and today I'm very happy that I finally decided to move on to a different career path: I'm quitting my job at IMS Health where for the last 4 years I've held various positions as BI developer, team leader, etc.

My goal will be to focus on doing more consultating type of work that will rely primarily on open source libraries/framework to deliver high-quality application. During the last few years, I've been lucky enough to get some external contract which made use of these libraries. And I really appreciated the possibilities that OSS can offer:

• in terms of quality of source code which helps to increase the quality of the application to build as well as your productivity
  
• but also in terms of the education opportunities it gives to increase your expertise and knowledge as a software developer

This career move almost coincides with our plan to return back to Europe... my wife and I have finally decided to go back in Switzerland by the end of this year or early next year. More on this on a future post...

What will I do for the these 4 months left to 2007? Well, I'm very anxious to continue a personal project that I started a few months ago like a fun 'passe-temps', but now is starting to occupy too much time in my mind and I need to get rid of it ... meaning putting it online asap.

Enough said for now, I need to get back to work.

Martin

OSS, the future of software development?

Came across this interview the other day from Lars Trieloff... "I believe that in ten years OS will be the predominant business model in the software industry". I usually tend to be quite wary and skeptical about these sort of long-term prognostics, especially in such a dynamic and rapid growth industry as the IT industry. However, Open Source to me is really the most effective way to produce complex piece of software. Without re-iterating the most cited advantages of this de-centralized approach, I'd just like to comment on a more personal experience.

At the office we are stuck with proprietary closed source software (no for long though.. more on this in a future post). As expected with software we hit a few limitations (read bugs) that were quite difficult to find a workaround or a graceful solution... all we were left with was a potential resolution in some future release of the framework (Reporting Services from Microsoft for this specific example)!

I can't help but compare this situation with a recent limitation I came across with Spring Framework a few weeks ago.

When trying to use EhCache for a project, I actually want to use the caching not only for what it is ... well i.e. caching, but also as a way to gather usage stats on the access of some of my service object methods. So I've defined a EhCacheFactoryBean while configuring it with the standard ehcache property file and decorated with a SelfPopulatedCache by injecting an implementation of the CacheEntryFactory. However, reviewing the code I realized that there was an issue, so in less than 5 minutes I raised a jira log and about 2 hours later my issue was assigned to one of the author of Spring, and corrected 2 days later!!

Well the fact that it took such as small amount of time to resovle the issue is very impressive and honor the commiters at Spring, although this could have very well happened in any other companies... but do you know a lot software vendors with such a quick reactive turnaround on bugs correction? However to me, the real advantage lies in the possibilities of having all source code at your disposal, it becomes trivial to simply write a corrected version and move on without having to wait for some future release. I can't help but compare this with similar situations we're faced with when issues are found at work with some Microsoft components.... well just too bad!

Martin

Consultation informatique

Dans ma vie professionnelle j'ai la chance de combiner deux types de travail assez distinct. Le premier est relativement commun car il implique un emploi comme "Lead technique" d'une équipe de développeur d'application de type BI.

Par contre, ma deuxième vie professionnelle est plus stimulante et comporte son lot de défis. Dans cette seconde vie, je fais de la consultation informatique (freelance) dans mon domaine d'expertise: i.e. tout ce qui gravite autour des tâches d'analyse, de design et développement d'application développée avec Java et exigeant des interactions avec des systèmes de base de données.

Mon cheminement professionnel m'a permis de maîtriser ces deux spécialités comportants certaines incompatibilités, soit l'implantation de systèmes de base de donnée basés sur un design de type relationnelles des données, et l'implantation d'applications basées sur un design de type Orienté Objet (dans mon cas c'est Java). Il faut noter que certaines incompatibilités sont quelques fois une conséquence de la mauvaise fois des gens de chacun des deux clans, mais ceci est une autre histoire....

La connaissance de ces deux spécialités s'avère d'autant plus utile avec l'explosion d'application sur l'internet dont les caractéristiques justifient l'utilisation de ces deux spécialités.

Tout cela pour dire, que je suis bientôt mûr pour un changement de carrière ... mon emploi chez IMS étant moins stimulant car nous servons une industrie beaucoup plus conservatrice avec de long cycle de vie des applications logiciels (je travail en ce momnent sur une application vieille de plus de 30a ns fonctionnant sur le Mainframe). Il faut dire que j'arrivais du monde un peu fou de la télécommunication qui est assez intense et garnie en terme d'innovation.


Martin

JDBC convenient programming with Spring

There is no need to re-iterate what has already been said and spread about the usefulness of the Spring framework... but it seems that every time I make use of a feature I come to the same conclusion: it simply makes you more satisfactory of your code, that is how I see it anyway !

Most of my database-related code usually made use of Hibernate because the sizing and the extend of the domain model simply justified leveraging the complexity of this framework.

However, in my current project I decided to give a shot at Spring jdbc support packages mostly because my domain model is simple enough (less than 10 entities with basic relationship) and because... well exploring more of the Spring library!


Although the library only really offers some thin wrapper around jdbc api (as opposed to a complete ORM solution), it does it in a way that you can create your data access code in a more object oriented fashion while keeping a close access to the underlying jdbc low-level api.

To illustrate this, I've created some helper classes (one per each business object entity) wrapping Spring jdbc data access object (e.g. SQLUpdate, JdbcTemplate, MappingSqlQuery) and offering a convenient way to centralize all sql-related string (sql command, table name and field, etc..).

On top of these classes, you can actually implement all generic sql access code (e.g. delete by id) and generic sql commands. Here's how look like the superclass, refer here as BaseSqlHelper:


And Here's one example of how one could implement a particular subclass (in this specific example the subclass handles sql for the User business entity object):



What does this offer you:
1- get all your sql strings contralized in one convenient place
2- benefit from code re-use by moving-up all your common fields (e.g. id, createDate,..) and common sql operations (e.g. delete from ... where id=, select ... from ... where id=) for all business entities into the superclass
3- exploit the MapRow capability to treat query response as real business entities and not merely as data field.
4- Ease for accomodating new fields and remove existing ones


Martin

Utilisation d'Hibernate

Pour faire suite au post précédent, j'ai observé que certaines applications sont construites sans tenir compte des limites et contraintes d'Hibernate... ils utilisent cette librairie comme le "silver bullet" qui va se charger de tout ce qui touche la question de la persistance et ce sans effort ou configuration spéciale!


Par exemple concernant l'utilisation du Paramètre Lazy dans le mapping, plusieurs applications sont configurées avec lazy=false. Ceci facilite évidemment la question du fetching des graphes d'objet, mais ceci à un prix et ce prix s'appelle performance!


Recommandation:

Pratiquement toutes les entités et les associations de compositions devraient être configurées de façon Lazy (i.e. lazy=”true”). Il ne faut pas confondre le paramètre lazy et le paramètre fetch, le premier indique seulement à Hibernate s’il pourra créer un proxy (qui exigera une initialisation en session ouverte) pour la classe en question ou la collection, tandis que dernier indique comment les relations doivent être fetchées (eager ou non).

En utilisant lazy=”false” ceci a comme « side-effect » de pre-fetché toutes les dépendances de l’entité et ultimement la base de donnée complète sera chargée en objet ! Cela peut être pratique puisqu’on n'a pas à se poser la question de devoir initialiser ou pas les dépendances, mais ça devient vite catastrophique lorsque le volume de donnée est important.

La décision de fetcher ou ne pas fetcher (eager fetch) est une stratégie qui doit être défini en runtime puisque différente utilisation exige différent accès aux données. La couche DAO peut être utilisée en ce sens en fournissant des options de loader ou ne pas loader les dépendances (avec Hibernate.initialize()) avant de fermer la session Hibernate. Configurer avec lazy=”false” élimine tout simplement cette flexibilité.

Si pour une raison quelconque, une dépendance d’une entité doit toujours être pre-fetché, alors utiliser l’option fetch=join dans le mapping mais en gardant le lazy à false pour cette entité dépendante.

L’auteur d’Hibernate a lui-même reconnu ce fait et recommande depuis Hibernate 3.0 que toutes les mapping des class et des collections soient lazy= ‘true’ (ceci est maintenant le défaut utilisé).

Martin

Performance des applications aves des outils ORM

Evidemment certains aspects sont plus importants que d'autres lorsqu'il est temps de considérer les performances des application se connectant avec les bases de données de type relationnel. Si on utilise de surcroît des outils de mapping ORM, alors la mauvaise utilisation de l'outil peut venir brouiller encore plus les cartes.

De façon général, voici par ordre d’importance les éléments qui doivent être considérés lors d’optimisation des applications interagissant avec une base de donné avec un outil ORM:

1. Le model ER (Entité Relationel) da la base de données Peu importe comment l’application et les modules ORM sont optimisés si le modèle ER de la base de donnée est pourri il sera difficile de produire des applications performantes. Normalement en utilisant des outils ORM, ce problème ne se pose pas puisque la création du modèle suit plus ou moins le modèle UML. Ce problème se pose normalement lorsqu’on dépend du base de données « legacy » qui ne peut pas être modifié.
2. La configuration du ORM (« fetching strategies », « caching », « report queries »). Cet aspect est critique car une mauvaise configuration résultera forcément en de très mauvaises performances peu importe les autres aspects et avec une dégradation linéaire en fonction du volume de données.
3. Le model physique de la base de donnée (tables, contraintes, indexes) Présumant que l’aspect précédent est respecté, ceci va garantir de bonnes performances avec l’accroissement du volume de données.
4. Le tuning général de la base de données (vendor-specific) Cet aspect est intimement lié au type de base de donnée, chaque vendeur fournit différent mécanisme afin d’améliorer la performance des applications de type OLTP ou bien OLAP. Cet aspect est difficilement généralisable et est la responsabilité du DBA.

Il reste toujours des cas d'exceptions mais en général ces principes s'appliquent assez bien pour les application de type OLTP avec base de donnée.

Martin

Muret de pierre sèche

Ouf!

Cet été j'ai finalement complété mon petit aménagement "style naturel" autour de notre piscine. Le plus dur fût sans contredit le mur de pierre sèche qui a nécessité plusieurs centaines de grosses pierres traînant ici et là. Après la construction de notre maison il restait à faire tout l'aménagement paysager. Nous avons donné quelques contrats mais les coûts exhaustifs de ce type de main d’œuvre saisonnier m'a convaincu d'en faire une partie moi-même.

Le sol sur lequel notre maison est construite est littéralement envahi par les pierres, donc j'ai décidé de faire 1 pierre 2 coups (mauvais jeux de mots): ne pas seulement les transporter pour m'en débarasser (à grosses sueurs), mais de les réutiliser du même coup (à plus grosses sueurs) pour en faire un muret, une terrase et des marches pédestres. Le seul principe important pour le muret est qu'étant donné qu'il n'y a aucun ciment pour assurer la cohésion (il tient que par gravité), il faut s'assurer qu'une pierre repose sur au moins trois autres pierres.

Et après un grand merci à ma copine et à ma mère pour l'esthétique jardin de fleurs (ok, ok aussi à mes enfants qui se sont enfargés plus d'une fois), voilà le résulat de cet aménagement...!

Martin

Statistical General Concept

Update: Most of these notes are work in progress and likely to remain as such for ... well no end date planned!  These notes, originally included as google-doc iFrame,  are thus removed from this blog... may decide to make them public directly as google-doc later on. 



This post is part of the notes I'm gathering from various references providing theoretical background and explanation related to data mining, analytics and computer learning (see this post for the book reference). I'm gathering these notes in hope to be a little smarter in applying and interpreting data mining algorithms taken out-of-the-box from mining tools (I must admit I'm also doing this to serve my endless quest for understanding).

This is actually linked (through an "iframe" tag) to a Google Doc that I keep updating as I face projects making use of new mining algorithms... so this is work-in-progress. I realize that blog is probably not the best way to publish live text, but is the easiest one for me.

This first part gathers basic topics from statistics difficult to classify into a very precise subject... should pretty much serve as a refresher for most people in this domain.

Definition:

• instances = data objects observed and analysed (sometimes referred to as objects, data points...)
• variables= characteristics measured (for continuous) or observed (for categorical) for each instance

Notation:

• n data objects (sample size)
• X generic input variables. When it is a vector, its component variable j is expressed with subscript: X_j
• x denotes some observed instance, and when we have p-variables, we denote x₁ .. x_p as the the real-valued for the 1.. p variables measured on the particular object or instance.
• x_k(i) correspond to the measure for variable X_k of the i-th data objects, where i has 1 .. N.
• x (in bold) correspond to the vector of n observation of a single variable x.
• X (capital in bold) correspond to the matrix N x p, containing N input p-vector x_p(1..N).

iFrame notes now removed.