2025-11-16 - Daily Note - About CV Editor

First of all, I want to point out that I discovered another handy Obsidian feature: the "Open today's daily note" button, located in the left side button palette, just creates a note with the current date as the title.

Notes about the CV editor

While I am completing the CMS tutorial in the official CakePHP documentation (titled "CakePHP 5.x Chiffon Book"), I am thinking to the data structure of the CV editor I am planning to code, a feature I always wanted to add to one of my corpse(?) projects.

The intent to implement it in CakePHP, Laravel and NestJS

In another [[NestJS VS Laravel|note]] of few days ago, I was disserting about the similarities of the two frameworks, in order to support my point of view in an old debate against HR recruiters (and tech interviewers) misbelief that a developer, who knows both JavaScript/TypeScript and PHP, isn't able to switch (easily) to NestJS if he knows Laravel (and/or CakePHP) and vice versa. Which has proven to be a false belief, since the three framework API interfaces are almost identical (and now I am sure of that).

Given this "new discovery", I posed myself the goal to implement the CV editor in all the aforementioned frameworks (which is trivial, given time).

About the front-end, instead, the divergences between the major front-end API interfaces (React, Angular, Vue, ...) are much more evident and it's nearly impossible to realize a 1:1 porting.

Sticking to basic HTML/CSS code, Laravel and CakePHP, for example, adopt entirely different approaches. While CakePHP uses standard PHP templates (i.e. PHP source files with PHP and HTML code), Laravel provides a templating engine named Blade.

Optionally, Laravel offers the possibility to use other front-end interfaces with it's installable starter kits: React, Vue and Livewire. React and Vue kits are powered by Inertia which is a sort of "adapter" layer, between back-end (server-side) and front-end (client-side), removing entirely the need to manage routes and HTTP calls in the front-end (plus other amenities) and driving the entire app flow from back-end (Laravel) routes. Despite it is quite interesting to explore, it is not my priority, to date. Livewire is a sort of an advancement of Blade. It uses Tailwind and FluxUI as its component library.

Some Time Tracking and Project Management

In the meantime, it's worth to note that this document took 1 hour of work, so far, from 4:54 PM to 5:55 PM, and I didn't get to the point yet.

After a coffee pause and some setup work on Asana and Clockify, I am back to this note at 6:58 PM. I launched a Clockify activity tracker to keep track more consistently of the time spent on this work.

Back to the Point: The CV Editor

Once discussed about the technologies involved in the project, I think I need to draft some ideas for the data structure. The question we should ask ourself is: what is already out there?

The eventual answer, responds to a couple of other decisions we have to make:

• Do we want to be compatible with existing standards?
• Do these standards (if any) suit our needs?

To create a simple work experience data model is simple. This is a possible JSON data structure of what a work experience entity could look like.

[
  {
    "id": "any alphanumeric (or just numeric) code",
    "title": "Front-end Developer",
    "company_name": "Full Pipe Umbrella",
    "begin_date": "Nov 16, 2025",
    "end_date": "Dec 16, 2025",
    "body": "A long description (eventually in some formatted text, like Markdown)"
  }
  // ...
]

Though, apart from id, title and body, we are not considering the fact that the company data could be an entity itself, and begin and end dates could be part of a more complex structure, which could be named period, for example, and include information about the timezone.

Before we start to get crazy, trying to build up this data structure, we should look for any standard that already implements such concepts, if any.

Microdata - LD-JSON schemas

In the past days, while working on another tool, to handle job postings, I came upon an HTML 5 standard: Microdata.

Microdata is a mechanism to provide a meaningful description of the data displayed in a Web page.

The Microdata mechanism allows to use so called "vocabularies" which are schema specifications, to define commonly used properties and describe data structures (types), like, for example the properties used to describe a book or a film.

The major Search Engines joined to provide a central resource for these vocabularies: Schema.org. Schema.org is also the reference organisation for the maintenance and development of the existing or future vocabularies, additions and modifications.

They are essentially metadata, and, as a consequence could remind of EXIF data block in media file formats.

Google provides a thorough document about Microdata, in which they explain how to implement them in Web pages. This is, for example, the chapter dedicated to job postings: Learn About Job Posting Schema Markup, which add information to the Schema.org job posting type page: JobPosting - Schema.org Type.

Europass Format

The unfortunate Europass CV format has been a big misunderstanding.

Everyone hated it because the project marketing focused mostly on the (terrible) presentation layout generated by the old Web App. The "captivating" layout was intended for exporting in PDF and Word formats. And there was also the option to export it as an XML. Which is interesting, because XML is not a presentation format; it is a data format.

Though, let's go back to the format, ... The data format.

XML was actually the native format of Europass and it was designed to hold all the information about a person professional and educational experience. The Web App was able to export in XML or a PDF file with the XML data block embedded in it. In fact, I coded a PHP program to extract that XML data.

What is interesting is that, inside the Europass XML format, we can find data structures with a scope similar to data structures found in the Schema.org JobPosting type.

Though, after a first comparison pass, I would say that Europass is much more complex from a point of view of the tree-hierarchy, but is missing a lot of information that Schema.org provides.