m i n d c o d e

My trip to the fields resulted in some nice photos, and a new desktop background that I hereby release to the community.

I know, I must change the theme… I’ll try to capture some insects today in the village.

I recently started to read a book from Keith Devlin about the Millenium Problems of Mathematics. One particular problem which every Computer Scientist have heard about is the P = NP. I say heard, not understood. Most of the people I’ve met, including me, know that this problem is directly related to the complexity of a particular algorithm. Most also know that it states that any known solution of a particular problem performs in superpolynomial time. And that’s all they need to know…

What most don’t know is the exquisite meaning of NP. An NP class problem is one such that a non-deterministic computer can solve it in polynomial time. Got it? Let me express it in other words: A problem which is NP can be efficiently solved by just getting luck in every choice you have to make. For example, in the traveling salesman problem, one can in fact solve it in linear time by correctly guessing the next city. The problem is guessing it right!

Some people have also heard about NP-complete (NPC) problems. What is the difference between a NP and an NPC problem? To put it simple, an NPC problem is an NP problem that has been shown to exhibit the characteristic of being able to be “translated” into any other NPC problem. This means that a polynomial solution found to a particular NPC problem can be easily applied to every other one. It’s like a dictionary of problems; find the solution of a puzzle, and you’ve found the generic solution of that class of puzzles!

And this is where everyone stands… No one have been able to prove that there exists NP problems that can or cannot be solved in polynomial time, since no one ever found a P solution to an NP problem. Of course P = NP could be proved or disproved without actually founding a particular solution: this would mean that every NP problem have an efficient solution, though it hasn’t been found yet.

Keith describes this enigma in such an enthusiastic way that lead me to read the formal problem statement. I must say that even my recently acquired knowledge on formal language semantics is not enough to read it easily. But I couldn’t resist inciting my colleagues and readers to have a glance at it… Enjoy!

P.S.: My apologies to my purist friends from any inaccuracy I’ve made for the sake of simplicity. You are free to flame me in the comments section

Just got back from Tunise. Great place to test my new Canon 450D

I guess I sold my soul to Apple…

Hoje deparei-me com uma situação impar. Vou tentar contar a história da forma mais exacta possível, precavendo o anonimato de ambas as partes:

Muitos de nós sabemos sob que condições o trabalho em Arquitectura se desenrola em Portugal. Qualquer licenciado acumula estágios sobre estágios, grande parte das vezes não remunerados. E, quando finalmente consegue remuneração, é quase sempre à base de recibos verdes com vencimentos que raramente ultrapassam o ordenado mínimo líquido. Conheço muita gente nesta situação, mas tenho uma pessoa particularmente próxima de mim que acabou de passar por isto.

A situação é complicada especialmente porque uma parte significativa (e a julgar pela minha experiência, talvez representante da maior parte) dos ateliers de arquitectura tem perfeita noção disto. Mas vão mais longe: além de “oferecerem” estágios (porque isto de trabalhar é uma regalia que todos deviam-se sujeitar sem receber qualquer contrapartida financeira) consecutivos, renovando de 8 em 8 meses o seu staff, existem não registados como empresas, mas sim como entidades individuais. Já podemos adivinhar o resultado: dezenas de trabalhadores a recibos verdes, sem possibilidade de partilharem qualquer hipótese de carreira ou sucesso, sem o seu nome nos projectos que realizam, e no risco constante de não serem pagos.

E é exactamente esta última parte que me revolta ao ponto de vir aqui, na expectativa que alguns leitores tomem consciência desta realidade, partilhar a minha frustração. Essa pessoa, hoje, ao dia 21 do mês de Julho, depois de ter trabalhado 15 dos 22 dia úteis, quando confronta o seu empregador com a possibilidade de abandonar o seu trabalho (por motivos perfeitamente válidos), é-lhe recusado o pagamento das 8 horas diárias que efectuou até à presente data.

Mas obviamente que isto não fica por aqui. O parecer do Tribunal de Trabalho, também hoje consultado, resume-se ao “Temos imensa pena, mas como a actividade liberal não pressupõe a celebração de um contrato laboral, a entidade empregadora pode (na prática) recusar-se a qualquer pagamento visto não existirem provas escritas desse mesmo trabalho”.

E mais palavras para quê?… O que se faz a uma pessoa destas?…

P.S.: Se alguém conhecer um atelier de arquitectura no Porto, que esteja interessado em empregar alguém com experiêncial profissional de 3 anos e licenciada na FAUP, que avise.

I’ve presented my PhD pre-thesis on the past 2 of July, and I’m glad it has been accepted by the Jury: “Adaptive Object-Modeling: Patterns, Tools and Applications”. I was also honored to have Joseph Yoder, from Refactory Inc., as my external supervisor. His contribution and ideas will be, undoubtedly, extremely useful during my doctoral research. I’m now officially a PhD. ABD (All But Dissertation).

For those who are wondering, the Adaptive Object-Model (AOM) is a software architectural style which allows for runtime adaptivity of the domain model. It succinctly consists on using an object-based metamodel as a first-class artifact from where all concerns are inferred, or derived from; classes, attributes, relations and behavior are represented and stored as data. At runtime this information is interpreted, instructing the system which behavior to take. Changing the model data immediately results on the system following a different business domain model.

The fact is, while an AOM defines a software architecture and design, any particular implementation of an AOM results in a Domain Specific Language (DSL). There are no standard DSLs for AOMs, and probably there will never be; the strength of AOMs rely in the fact that they are built bottom-up, instead of the top-down approaches other MDSE (Model Driven Software Engineering) methodologies and tools are based upon.

Actually, my thesis will be exactly about that: the study and documentation of a set of patterns, recipes and tools, together forming the basis which any developer can pick and use in its system. The validation of the thesis will, in part, be evaluated by the construction of a prototype framework that lies upon the theoretical models inferred (which, incidentally, is progressing fast enough to already have some production-level commercial applications built on top of it!)

For those who are not following along, let me put things this way: imagine you pick up any semi-formal notation, like UML + OCL, and you feed it to a program. This program will adapt itself, from structure to interface, resulting in a new application ready to use, without any further programming from the developer. You feed it the model that represents an Archeological Heritage Information System, and done! But there’s more: while the system is running, you change the model: you create new objects, new business rules… All applications will react according to the new model, and will evolve automatically, while maintaining their integrity, without any kind of code-generation or shut-down.

Do this seem like a dream? Well, it isn’t. It’s reality, right here, right now. But, somehow these theories never became mainstream. I intend to change that… or at least, give a small contribution And this is my thesis on a nutshell (details are always boring).

While writing this post, I also received an email from a friend suggesting that I should read Martin Fowler’s latest blog posts. It’s interesting that DSLs and MDSE is gaining so much attention these days. Martin, we are all anxious to lay our hands in that new book of yours

There has been a paper that was kept out of my radar for a surprisingly amount of time: “Big Ball of Mud”, by Brian Foote and Joseph Yoder. Just reading the introduction makes any software architect fight the urge to get out screaming to their bosses and colleagues: “See?? This is exactly what I’ve been saying!!”

The paper is an excellent summary of the dynamics of software development and evolution. I can’t resist to quote some passages from the introductory chapters to see if I can persuade someone to read it:

A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. 

Now… Who doesn’t recognize these symptoms? The authors go on:

Why does a system become a BIG BALL OF MUD? Sometimes, big, ugly systems emerge from THROWAWAY CODE. THROWAWAY CODE is quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it? When a related problem arises, the quickest way to address it might be to expediently modify this working code, rather than design a proper, general program from the ground up. Over time, a simple throwaway program begets a BIG BALL OF MUD. 

The time and money to chase perfection are seldom available, nor should they be. To survive, we must do what it takes to get our software working and out the door on time. Indeed, if a team completes a project with time to spare, today’s managers are likely to take that as a sign to provide less time and money or fewer people the next time around. 

As I finish my paper for submission tomorrow (PLoP’08), the following strips start to give me that sense of deja-vu:

I guess one day I will laugh out loud about this… but not today

Since the very first usage, I’ve found safari very slow when starting a page display, but I blamed the rendering engine for that. However, slightly after installing Little Snitch, I’ve incidentally realized that something wrong was happening with the DNS: it was taking too long to answer. By digging some pages on the internet, one can conclude that by adding the OpenDNS server addresses to the DNS section on Network preferences, the problem is fixed.For more information, check this forum.

I’m becoming addicted to making these…

Yes, insomnia sucks…

Just playing with stripgenerator…

AOMs.Equals(42)