So today after a session of the Goldsmiths Deep Learning with Tensorflow group, I decided to go back to the basics and start ML101. I found a good resource for that:

The first chapter in this book gives a primer in how basic artificial neurons, such as the perceptron and the sigmoid neuron work.

The perceptron is a basically a mathematical approach to define a decision making model. The perceptron defines a set of binary variables (the inputs xs and output y) and a set of parameters (the respective weights for each input, ws, and a threshold value). Each configuration of weights and threshold provide us with a different decision-making model.

Now, you can scale up the power of a perceptron to a network of perceptrons, composed by several interconnected layers of perceptrons. Each input is connect to the first layer of perceptrons and each perceptron output is multiply connected to all the perceptrons of the subsequent layer. Thus, each layer subsequent layer will be making more complex and abstract decisions, providing a very sophisticated mechanism for decision making.

Here I’m using the dot product and the negative of the threshold to express the bias

Output = 0 => w≤ 0

Output = 1 => wb > 0

To be updated…

Also began the basic Tensorflow starter tutorial with the MNIST dataset, for recognition of handwritten digits.


Middleware is a class of software designed to support the development and operation of other software (e.g. end-user applications, other middleware). Middleware that is considered infrastructural software, as its features are mostly invisible and often expressed through client code features. It can take the form of toolkits, libraries or services which are incorporated.

In this paper by W. Keith Edwards, Victoria Bellotti, Anind K. Dey, and Mark W. Newman addresses the problem of designing and evaluating user-centred middleware, a difficult task since the the technical features of the underlying infrastructure are directly invisible and typically expressed in the features of the client applications. Apart from the general criteria for evaluating software (performance, scalability, security, robustness, …) the authors found  no user-centred criteria, based on usability and usefulness, for designing and evaluating the features of the middleware itself.

This prompted the authors to formulate the following questions about the middleware design gap:

  • Is it possible to more directly couple the design of infrastructure features to the design of application features?
  • How can this more direct coupling exist when the applications that will be built atop the middleware don’t yet exist…and may be impossible to build without the middleware itself?
  • Could the context of either the users or the use of these unknown applications have an important impact on the features we decide upon?
  • How can we avoid building a bloated, overly complex system incorporating every conceivable useful feature, at the same time as developing a system that will not need to be constantly updated (and thus repeatedly broken) throughout its life span?
  • Are there better models for deciding on the features of “experimental” middleware, designed to support completely

And also for the middleware evaluation gap:

  • How do we choose which applications to build to evaluate the middleware?
  • What kinds of users and contexts (types of uses) for these applications should we consider as appropriate for testing purposes?
  • What does the manifestation of the technology in a particular application say about the capabilities (or even desirability) of the middleware itself? How useful is this “indirect” evaluation?
  • Are the techniques we normally use to evaluate applications acceptable when our goal is to evaluate the middleware upon which those applications are based?
  • Is it possible to evaluate the middleware outside of the context of a particular application?

Thus, authors present the major challanges and lessons learned over the design and evaluation of three case studies: (1) Placeless documents, (2) Context toolkit and (3) SpeakEasy. The lessons learned set encompass the following list:

  • Lesson 1 – Prioritise Core-middleware Features.
  • Lesson 2 – First, build prototypes with high fidelity for expressing the main objectives of the middleware.
  • Lesson 3 – Any test-application built to demonstrate the middleware must also satisfy the usual criteria of usability and usefulness.
  • Lesson 4 – Initial proof-of-concept applications should be lightweight.
  • Lesson 5 – Be clear about that your test-application prototypes will tell you about your middleware.
  • Lesson 6 – Do not confuse the design and testing of experimental middleware with the provision of an infrastructure for other experimental application developers.
  • Lesson 7 – Be sure to define a limited scope for test- applications and permissible uses of the middleware.
  • Lesson 8 – There is no point in faking components and data if you intend to test for user experience benefits.
  • Lesson 9 – Understand that the scenarios you use for evaluation may not reflect how the technology will ultimately be used.
  • Lesson 10 – Anticipate the consequences of the tradeoff between building useful/usable applications versus applications that test the core features of the middleware.

At the current point of my PhD research, I believe I now have a broad view of the field, a plan outline for my research, have tackled with practical work, exchanged ideas with other researchers and now looking to define my specific research questions or problems. Further than that, I am preparing to start writing my upgrade I keep thinking about the whole process as whole that needs a successful conclusion.

One article that I was lucky to see passing before my eyes when I was beginning my PhD at UCP was “How to Choose a Good Scientific Problem” by Uri Alon. The title seems rather prescriptive but the analysis that it presents is highly enlightening.

The starting point of the article is that choosing a problem is, just as the culture of a specific lab, related to nurturing. When choosing a problem, both for a lab or for an individual researcher or student, the goal is maximising their potential by fostering growth and self-motivated research.

For that, Alon frames scientific problems in two dimensions: feasibility and interest. Feasibility reports to how hard/easy it is to complete a project, in what concerns time. Interest reports to “the amount in which they increase verifiable knowledge”. So considered options for positioning your research problems are: “low hanging fruit” – easy but not to interesting; “difficult is good” – difficult and low interest, and finally the best of options, feasible and with high interest. So choosing the right problem follows the Pareto principles according to an increasing level of difficulty and career development.

Some heuristics are provided that attempt to give students a more wise, defensive stance; “Do not commit to a problem before 3 months have elapsed” (whilst reading, discussing an planning) or “Resist the urge to “we must produce – let’s not waste time and start working”, with the given consideration to practical issues that usually arise such as funding, deadlines, etc.

The author departs to analyse how the ranking of problems occurs. Here, the value assigned by the community competes with the value, with the inner voice from the student or researcher. And a special mention is made to the importance of the supportive environment that the supervisors can provide and how much this helps to strengthen this inner voice. And how recurrent questions that go around inside for years can make the basis of good projects, how the self-motivation that emerges out of this can lead to a bigger commitment, a more rewarding routine and a greater appeal to the audience.

So how can one converge towards his problems? This way the author puts it reminded me of the old adage “Know thyself”. What are the personal interests, what is our perspective on a specific problem, what resonates with one’s values to explore? Achieving self-expression is one of the most important goals in research that may make work self-driven and revitalising.

On the concluding part of the paper, Alon focus on the schema of research, a path that is taken from beginning of research (A) to a particular end (B), and that is erroneously believed to be linear and predefined by most. In fact, in most of the cases the destination of research has been a newly found problem (C) in the way to solve the initial destination problem (B). In the course of a fuzzy stage called meandering of research, C became more interesting, feasible and worthwhile than that. As Alon puts it, the mentors’ task “is to support students through the cloud that seems to guard the entry to the unknown”.

After having a go with the MYOs in our lab and compiling some C++ code for Atau and Miguel for the Metagesture project, and, having been involved on the 24h hackthon in Sonar 2015, which had “Wearables” for its main topic, all this brought all the motivation that I had around 2007 to do some serious hacking in this field. At the time I had just beginning to write my master thesis in mobile and ubiquitous computing, and one of the ideas that I had was to develop a bracelet that connected through Bluetooth, was localisable and had big array of sensors that I could measure and do some data mining on. So, more that seven years passed, here we stand now with the Smart Watch from Apple and the Band from Microsoft, amidst others. So I decided to give myself a treat for my birthday and buy one Microsoft Band to hack.

The initial setup wasn’t as trivial as I expected… I was doing it late in the night, was tired, my Windows 8.1 phone was almost out of battery, and only charged the Band for about half-an-hour. I got it to pair with my phone but connection didn’t last. And the Health app seemed to do nothing about that. Spend almost 30m trying to work it out without success. Being both a Microsoft and Apple consumer and developer, I must confess that the recurrent thought that builds on frustration came to my mind “Why doesn’t this work? If it was an Apple product this would have been a flawless process…”. Some reflections on this later on. But now in the morning, after devices were recharged during the night, restarting my smartphone, removing the previous Bluetooth pairing entry, everything seemed to work well. I would say it was all about the order of the steps in the pairing process, Health app initialization and connection. I am still not sure about what failed in the initial process, but I suspect you mustn’t pair the bracelet before launching the app.

Now everything is setup and about to do some more testing. Leaving for a bike ride and testing the tracking features ;)

On project RAPID-MIX, Goldsmiths EAVI team had a task assigned which has been recently completed. The main outcome is a report on the methodological framework to be adopted, based on User-Centred Design, which involved choosing and adopting a code of research ethics. This involved going through some of the most relevant codes of research, such as:

We decided to adopt the last one since it seemed the most encompassing and adequate to international collaborative research, and provided an extensive coverage and guidelines for good practice. These claim for values such as integrity, uniformity, fairness and confidentiality applied to guidelines such as:

  • Data practices for availability and access
  • Research procedures
  • Publication-related, review and editorial conduct

Overall, it provides a great ethical framework to work on and one of the fundamental aspects of any serious research work.

Just found this picture online. Me playing with :papercutz on my last gig with them, at the beautiful concert room in Nogueira da Silva museum, Braga, Portugal. At the time I was the multi-instrumentalist at service, playing classical guitar, melodica, xylo, synth and electronics, and backing vocals.


Bittersweet memories… :P

Last week, went to IRCAM, Paris, for a three-day intensive work meetings. Had the pleasure to see some of the great work that is being conducted there in HCI research for music technologies. Here’s three projects that show some of the amazing work:

Stonic App by IRCAM

Playing sound textures Project

Project COSIMA