Chemicals

Digging through my photograph collection I came across these that I took last year in a science exhibition - I guess primarily aimed at children. Crap (I wanted to use a stronger word) like this has no place in either a science exhibition nor, for that matter, in any place being aimed at anything remotely human.

The photos are of a computer screen which was part of a quiz for children on food. They're in Finnish but I'll provide the translation. Here's the question:

Knowledge Quiz:


Compared to "normal food", "natural food" ...

1. Contains less fat and sweeteners
2. Contains no chemicals and genetic manipulations
3. Is produced in the countryside

And the answer is....

Natural food contains...no chemicals.

The next question should be then what is it made of?  Pure energy? Some exotic matter? Maybe that's where all the dark matter in the Universe is....natural food.

The UK's Royal Society of Chemistry is offering a £1000000 (UK pounds) prize for anyone who creates a "chemical free" material. I guess no-one at that particular science museum has claimed the prize, which basically means they're either lying or stupid.

Here's a quote from the RSC:

Dr Neville Reed, a director of the RSC, said today: "I'd be happy to give a million pounds to the first member of the public who could place in my hands any material I consider 100% chemical free. 

"Should anyone do this, we will see thousands of years' worth of knowledge evaporate before our eyes. We would have to tear up the textbooks, burn the degree certificates and retrain the teachers."

One of the major constituents of any food-stuff is water...you know that chemical H2O, sometimes known as dihydrogen monoxide...not to mention those other nasty chemicals such as sodium chloride, or L-ascorbic acid, or any of the myriad of carbon based chemicals...

Some might say that this only applies to "man-made" or "bad chemicals"...so what constitutes a "bad chemical" or even a "natural chemical"...well, plenty of interesting poisons exist in nature including cyanides and many, many radioactive materials too, so that can't be the definition.

Dihydrogen monoxide incidentally was the subject of many hoaxes based on a complete misunderstanding of what chemistry, chemicals and a basic knowledge of science.

I remember an advert on TV for some cosmetic product which contained only natural chemicals which must be "good"...natural chemicals such as I've already stated...such as cyanides naturally found in almonds and apple seeds.

So, anyone who states that something is "chemical free" is stupid, deranged and plain wrong. In fact, anyone who states such a thing in a science context should be...I'll let you decide on a suitable punishment...maybe something nasty such as not allowing them access to that most evil of bad chemicals: dihydrogen monoxide. This kind of crap has no place in a science exhibit, in childrens' education or in society in general  - only bad things will come of this if this kind of nonsense is let to continue.

ps: I did ask a member of staff at the science museum about this - she had no answer other than it must be true otherwise they wouldn't have had such an exhibit...oh dear...

More ballet and software engineering

Sometimes a quick search using some popular search engines reveals people with similar ideas, in this case about ballet and software engineering: on the IBM Developer Works site is an article dated from 2005 by someone called "gbooch"*:

Software architecture, software engineering, and Renaissance Jazz

which mentions the link between software architecture and dance:

"It seems to me that there's a curious relationship between dance and software architecture: in both disciplines, there are only a limited number of patterns available, each genre assembles those patterns in specific ways that define a particular genre, and furthermore, most knowledge is passed on through tribal memory, from one dancer or architect to another. In dance, by the way, some attempts have been made to define a graphical notation for describing dance movements, just as we have the UML for visualizing, specifying, constructing, and documenting software-intensive systems."

Exactly...!

*I guess if the mysterious "gbooch" thinks this then I'm in good company.

Then there's another post on Techtalk: If Software Were Like Ballet which lists a number of points, the first of which is:

• Little kids are encouraged to get used to the equipment and basic practices.  Even if they don't actually do these things they are told about build and release cycles, software qa, and algorithms.

Now I don't agree with some things said in that posting, but certainly the above at least in terms of encouraged to use the correct equipment, techniques and basic practices is apt.

The Ballet-Software Engineering "Isomorphism"

A grand title for some thoughts. After watching a dance show involving various styles of dance etc a thought struck me on some interesting parallels I see between dance and the practice of software engineering. I guess this comes from reading things such as Baez and Stay's "Physics, Topology, Logic and Computation: A Rosetta Stone" - a paper describing the links between various scientific disciplines, ostensibly through category theory.

As I and many others have stated before the key to good software engineering (and thus great software) is an understanding and use of the core, formal theories of computer science - I consider software engineering to be a sub-discipline of computer science (and in turn mathematics). Why should this be so? Simply because of understanding how each of the parts of a piece of software interact and an appreciation of the complexity and need for elegance and simplicity in this.

So what has this got to do with ballet? Comparing modern dance with ballet and the dancers performing their routines I noticed the approach to the task was in most cases different - there is an interesting exception which I'll get to later. The difference was in the execution, fluidity and attitude to the performance: how accurate the moves were being performed individually and collectively as a group. An interesting point I thought was that you could recognise the really talented dancers by how they looked at each other and the audience.

Modern dance seems to be (or is) very free in terms of movement, style and composition - akin to agile methods in software engineering. In some ways, modern dance is easy ... anyone can just move, similarly to agile methods, anyone can hack a project together. But to get a consistent, fluid, elegant whole is extremely difficult in that the choreography of the individual dancers becomes very difficult to make consistent, unless the dancers are very experienced and instinctively understand how each is moving relative to oneself. I suspect the very good dancers here have or understand the fundamentals of movement to a very precise degree.

Ballet on the other hand is very strict with a limited set of movements which themselves are precisely defined. Wikipedia's (sorry, I know you shouldn't cite wikipedia!) article on ballet contains the statement:

"It is a poised style of dance that incorporates the foundational techniques for many other dance forms."

I need say no more regarding the basis of ballet for other forms of dance.

An in that respect we have our link with mathematics, computer science and software engineering. Formal methods are computer science's version of ballet: strict rules and technique and hard to master but forming the basis for the rest of the subject, especially software engineering.

When auditing, watching or even performing the "art" of software engineering - or at least - developing software (and systems); those who have an understanding (either explicitly or implicitly) a deep understanding of how the science works build the best software. The "moves" of the software engineer are deliberate, planned and executed with precision. This remains the same whether this is agile or formal development, though most agile development tends to be very ad hoc, messy, immature and poorly executed - like the modern dancer without discipline.

And indeed this is the core of what makes a good engineer - not whether they have the formal grounding, but they have an understanding of what makes the engineering work and the discipline to actually use those techniques properly.

Relative complexity

I'm told that software engineers don't understand taxonomies and ontologies, which confuses me a little - or actually a hell of a lot because I'm not sure what this statement actually means?

Are we saying that our software engineers are on one hand stupid but on the other hand build complex class hierarchies and relationships then navigate through the various mechanisms for building instances of those?

I currently have to construct an ontology/taxonomy for data/information with some real bizarre simplicity requirements which will ultimately reduce something inherently simple down to something unusable and without any real worth. Primarily because I am told that software engineers won't understand anything complex.

This troubles me.

Must go, off to another debate about syntax, or specifically the naming of things; or probably the colour of the picture in Powerpoint - wrong shade of pastel blue again....Wadler strikes again...

A (Lego) Shuttle to Space

This must have been fun...



Thanks to El Reg for reporting on this.

CFP: IEEE International Conference on Semantic Computing 2012

Industry Session Call for Papers

IEEE ICSC 2012: The Sixth IEEE International Conference on Semantic Computing 

September 19th- 21st, 2012 

Palermo, Italy

Website: http://icsc2012.pa.icar.cnr.it/industry-session.html

Program Goals and Format: 

The goals of the ICSC 2012 Industry Session are to foster exchanges between practitioners and the academics, to promote novel solutions to today's challenges in the area of Semantic Computing and applications, to provide practitioners in the field an early opportunity to evaluate leading-edge research, and to identify new issues and directions for future research and development efforts. Similar to regular papers, the papers in the industry session will undergo a review process and will appear in the conference proceedings. However, the selection criteria for industry papers are slightly different. In particular, papers should describe technologies, methodologies, applications, prototypes or experiences of clear industry relevance. A main goal of this session is to present research work that exposes the academic and research communities to challenges and issues important for the industry. Therefore, the papers in this session will be evaluated primarily by the novelty and applicability of the insights from its industrial solutions, instead of the originality of its algorithmic content. 

Topics of Interest: 

Topics of particular interest include but are not limited to those identified in the main conference call for papers, as well as those listed below:

1. Development of new semantic systems, architecture, and standards 

2. Employment of semantic computing tools and interfaces 

3. Employment of large scale semantic systems 

4. Benchmarking and performance evaluation of semantic systems 

5. Innovative solutions for performance optimization

6. Mobile semantic systems and services 

7. Multimedia semantic content analysis and retrieval systems

8. Modeling issues and case studies of semantic computing 

9. Game and entertainment applications 

10. e-Business and other applications 

11. Analysis of industry-specific trends and challenges 

Important Dates

Demo Submission: May 04th, 2012

Notification: June 28th, 2012

Conference: September 19th-21st, 2012

Industrial Paper Submission: 

Industrial papers should be submitted via the ICSC 2012 online paper submission system. Industry Session papers should be no longer than 8 pages with the same submission guidelines available on the ICSC 2012 web page. Only electronic submission will be accepted. All industrial papers will be peer-reviewed and published in the conference proceedings, which will be published by the IEEE Computer Society Press. Submissions must not be published or submitted for another conference. 

Industry Session Co-Chairs: 

Alexander Loui, Kodak Research Labs, USA

Vito Morreale, Engineering SpA, Italy

Ian Oliver, Nokia, Finland

Evelyne Viegas, Microsoft Research, USA

Note:

1. Every  paper accepted for publication in the Proceedings of ICSC 2012 MUST be presented during the conference.

2. Every  paper accepted for ICSC 2012 MUST have attached to it at least one registration at the full member/nonmember rate. Thus, for a paper for which all authors are students, one student author will be required to register at the full registration rate.

Progams are models

Funny how some themes tend to recur through computer science and a post on "Enso Blog" turned up this gem: Why I don’t consider Programs to be Models:

My main point here, however, is that I prefer to not think of programming languages as modeling languages. The reason is that, for me, a modeling language must be about what behavior is desired, not how to implement that behavior.

I spent a huge amount of time working on this, especially in the context of the MDA and actually trying to convince people that a description in some language such as UML was just as valid and concrete as a description in some executable programming language - though it was ironic often that something in SDL was considered a program but something in UML was considered a model.

At the time there was parallel work on something called 'executable modelling' - though interestingly that particular group never wanted to discuss what they meant by either term 'executable' or 'model'...in the end turned out because of this failing to even attempt to address these terms that particular approach (if it was even a valid approach given its lack of semantics) failed.

The posting mentioned earlier refers to another blog entry on the subject by Zef Hemel in his post Models are Programs. I tend to agree wholly with the point made there and thus indirectly with his PhD thesis: Methods and Techniques for the Design and Implementation of Domain-Specific Languages though a little surprised that mention wasn't made to some of the work in this area on specifications, especially the classic Fuchs' Specifications Are (Preferably) Executable.

However I can see the discussion on specifications versus programs lurking there but whichever way you look at things, a little abstraction reveals these things are all the same anyway.

So, after setting this up, while I don't agree with the first point and agree with the second, I do think there is an interesting taxonomic or ontological question on what makes a model different from a specification from a program - not to mention what makes something "executable" or not.

But to specifically address the point that modelling languages are about desired behaviour and not implementation is flawed in the sense that all programming languages are an abstraction - just depends on how deep you want to go.

Anyway, its late and I'll need to dig out from the recesses of my brain some of the work I made in this area but always nice to see these things haven't been resolved and still stir controversy :-)

References.
 
Johan Lilius , Ian Oliver (2007). Towards a Formal Definition of Model Driven Development (2007). Technical Report. Åbo Akademi.

Are you logged in?

Tom Anthony's blog has an article on how to detect whether someone is logged in to a given social network, eg: Facebook, Google etc..

You can run it here:  Social Network Login Status Detector Demo

 

A few things stuck me:

• I logged into Facebook earlier today and then closed the browser window - I was still logged in to Facebook
• Similarly for Twitter
• Going to www.google.com or www.google.co.uk showed the Sign In button, however it did appear according to the status detector demo above that I was still logged in. In order to log out I needed to login and then logout.

Given that some sites, particularly Facebook, have been caught tracking user behaviour when that user is not logged in (google search results here), this is quite worrying from the stand point that such tracking could occur even when you think you are not using a service or not logged in.

Before panic sets in, I'm not at this moment overly concerned about privacy (I am but...) but rather basic security and the fact that user could be accidentally revealing their behaviour.

 

I actually think that most of these kinds of accidental incidents and problems are more attributable to stupidity or less controversially, lack of knowledge, ie: Hanlon's Razor:

Never attribute to malice that which is adequately explained by stupidity.

 

or better still a quote by the journalist and UK civil servant Sir Bernard Inggam:

Many journalists have fallen for the conspiracy theory of government. I do assure you that they would produce more accurate work if they adhered to the cock-up theory.

 

I think this better explains what is going on with the current trend for secondary data collection from Apps such as those found on most mobile devices, ie: from the CNet article "Report says be aware of what your Android app does". Part of the problem is the education and knowledge of the programmers and developers in developing security and privacy aware systems and secondly the available features for security and privacy protection both on the devices and as presented to the users of those devices.

 

Now I lay part of the blame on the developers of the user experience and part on the users - mainly due to the fact that people seem not to care about setting their security and privacy settings, though it must be admitted that the user interfaces aren't really intuitive and many of these concepts rely upon the users being rather  knowledgeable about these features. I certainly don't think Privacy by Design principles help either - they are targeted at the wrong people. I'm not saying these principles are wrong or bad or unwanted but rather their targeting is off. On the other hand, this is certainly is not a trivial problem for the user experience developers, so maybe I'm being too harsh here.

One problem regarding privacy is that there still is no good formal underlying theory and practice for the developers, unlike security which is relatively mature and well defined. In fact I perceive the state we're in now is very, very similar to the level of immaturity the we saw when the masses of developers first started to develop networked systems and used network programming techniques (cf: leaky abstractions); and even the very first web based applications in the early '90s.

 

Maybe part of the problem is that in many cases privacy is still being framed in terms of security, that is confidentiality - which is partially correct but to my opinion, security is about protection of the information exchange and privacy is about protection of the content and meaning of that exchange.

It takes, I believe, about 10 years to understand these problems in the wider development community and probably another 10 to develop the theory and techniques such that they become common knowledge to the developers. Sadly at this time, I see too many incidents where despite the emphasis on guidelines, processes etc, the technical guys: the architects, the developers etc are all too forgotten.

Ultimately privacy and security are in the hands of the developers and if we don't address the problems they face through better tools, programming languages, development techniques, analysis techniques etc, then we're going to see issues such as those presented in the beginning occur in the future, malicious or more commonly not.