About Author: The Pleasure of Finding Things Out

My name is Popescu Lucian Gabriel and I was born in June 4, 1978 during Ceausescu regime in Turnu Severin, a city near Serbian border. Since I was little, I loved to look behind and analyze what was around, discover patterns then build theories onto their cause.

The pleasure of finding things out soon became my lifetime mission: it gave me endless intellectual and emotional satisfaction and art came along as lifelong companion. For me, the beauty of order would be sterile without art: a Bach's fugue is a necessary emotional complement that drives achivement of perfection in programming as well.

My Personal Journey as Programmer

I've started programming as late as age 25 and my first impressions were actually negative. I've discovered you're neither expected nor encouraged to think: as a student you must mindlessly memorize theories and as an employee you must concede at being a robot that munches through bloated illogical code to get a paycheck or face "authorities" you have nothing to learn from.

Meeting the Pit of Damnation

Looking at that code and people that authored it, I couldn't help noticing some obvious patterns: what makes code so bad is that it consolidates a pit of damnation, a place where ugliness and disorder reigns supreme. How fitting that authors, apart of being stupid and incompetent, had lowest moral qualities and no sense of beauty whatsoever!

Making a Garden of Earthly Delights

To transform programming into a garden of earthly delights a sense of beauty and order must naturally exude from it (be it in the way code is written or in the way architecture is designed). To produce this, however, is only possible if you've practiced that skill already for other venues that hightened your aesthetic standards: very few programmers who label their code "art" understand what art really is!

My Work Methodology

For me programming is art: taking a task, learning & thinking about it, elaborating into a structure then peeling off imperfections until what remains is completely harmonious, modular and deceptively simple. How arrogant is it for me, though, not to use what someone else did already?

Unfortunately very few developers (especially in web programming) take any consideration at writing elegant optimal code, so the end product is typically slow, chaotic, over-programmed and deeply coupled to target framework. This forced me to become a serial wheel reinventer whenever task is within reach (doable by a single man).

Developing Libraries

Whenever I'm requested to develop a library, I split my workflow into four steps:

  1. researching: look for official specifications for subject of task or (if not found) already made solutions to understand what developers expect (if any)
  2. learning: if specifications exist (eg: oauth2 client), simply learn them and ignore what others did; otherwise, if task already done by others (eg: database migrations) compile resolutions into a specification
  3. thinking: based on specifications I learnt/created, build a logical tree of components that will serve as foundation for classes to develop. If task is inovative (eg: file-based database) foundation will be built purely by thinking.
  4. developing: developing classes on that logical tree then covering their operations with one or more unit tests. When developing classes I take extreme care at loose coupling while at the same time being very economic in code.

Each library will be loosely coupled: completely covering its subject, knowing nothing else! Eg: OAuth2 Client API

Developing Applications

Whenever I'm requested to develop an application (itself using libraries), I split my workflow into three steps:

  1. learning: learning what is expected from application to deliver (what its constractor and its target users expect)
  2. thinking: think of breaking up each functionality into a library to reuse for other purposes as well
  3. developing: developing each library independently to cover one functional aspect (as described in "Developing Libraries" section)
  4. binding: classes inside must be solely geared at integrating (binding) libraries underneath, themselves built with reusability in mind

Eg: Framework Skeleton API, binding OAuth2 Client API to gain ability of communicating with OAuth2 providers

Building This Framework

This framework was first and foremost an intellectual exercise of massive scale. "Every block of stone has a statue inside it and it is the task of the sculptor to discover it", said Michelangelo. You will never know what lies behind that block of stone until you remove last pieces of rabble, so the process itself adds pure excitement on top of aesthetic satisfaction on masterpiece about to be produced.

The Goals

Creating a framework that is absolutely modular: each aspect of a web application logic dedicated to an independent API, perfectly usable from outside framework, able to be reassembled elsewhere. Framework's job remains that of integration and nothing more!

The Means

A set of principles (harmony, simplicity and efficiency) in development "powered by" Art of Fugue (mostly) then months of arduous work to make every part in the puzzle fit perfectly: from code itself to architecture and documentation.

The Results

Assessing results of my own work will always be relative, but judging by quantifiable criteria (performance, modularity, elegance) framework is up to highest standards, an exercise of art of computer programming inspired by Bach's pursuit of beauty and order through simplicity.