Latest Posts

Use config:nginx, config:host and install:nginx commands to automate Nginx configuration of your project. Now, it's fully automated!

Yesterday, I tested the instructions for installing Osm Admin locally as a contributor.

Yesterday:

• Osm Admin in-browser functionality was fully restored after creating search index in the indexer.
• All test suites started passing again, and being run automatically on git push.

Yesterday started as usual, planning new iteration, and then BAM! - one folk - Saif - joined the project. It made me correct the course a bit, and take care of potential contributors:

• README explains what the project is about, and how to get started as a contributor;
• I'm fixing things to make the project actually runnable just after installing it.

Yay! After implementing invalid data conversion, I finished the iteration #18 dedicated to diff-based migrations!

I must say, it's a bit disturbing to implement the same thing for the third time. Still, the goal is to get it finished, and have it sustainable.

After the effort, the code has become su much easier to read!

I continued working on property diff algorithm that plans all the migration details.

Yesterday, I finished implementing data conversion for int and string property types.

Then, I started refactoring it.

Last time, I pushed through string property migrations and created a migration log.

Today, I continued solving data conversion issues.

• I finished implementing string property migrations.
• Migrations have got a meaningful log explaining what migrations take place, and why.
• Along the way, I fixed numerous issues.

Yesterday, I finished writing int property migrations. True, testing it is still a todo.

The major part of the code (type change, nullability and other attribute handling) will be reused in other property types.

I refactored Property::migrate() using additional Migration classes. It's so much more convenient to compare property definition versions and generate migration SQLs!

New code structure already handles property explicitness changes.

After enumerating what kind of changes can happen to a property, I started implementing the most hard one - changing property type.

Estimating projects is hard. Here is my approach for getting better at it.

It's based on a concept of a "primitive problem" - something non-trivial that you can solve in one go.

You can use primitive problems as story points in agile project management.

The Query::bulkUpdate() method is implemented in the TDD way.

Implemented in Osm Admin:

• new ALTER TABLE algorithm
• NULL to non-NULL data conversion
• new query test suite

This time, I tackled adding an explicit property to an existing table, and then making it non-nullable.

It raised the need for data conversions - additional handling of the existing data - or otherwise, the database engine fails, or the data becomes invalid.

And it made me split migrations in two parts - the one that runs before the data conversion, and the other one that runs afterwards.

While working on diff algorithm I noticed a certain pattern that I use over an over again.

Using this pattern, I implemented notification table diff.

Finally, I rearranged diff/migration code for better code readability.

Yesterday, I moved the table creation code into new schema diff migration engine.

Now, working on notification table migrations.

This time:

• I found out that the whole search index creation should be done during indexing, not migrations.
• I refactored diff algorithm and made it much easier to read.

Before digging into property diff algorithm, let's dig into how exactly it's used, and what other property-related logic is there.

Yesterday, I continued working on schema migrations:

• implemented table diff algorithm;
• took into consideration table renames.

After a system update, I've got some problem with my laptop, and one thing to check was system log files.

This got me thinking: what makes a good log for my own application? And I think that application logs are as useful as they are able to answer potential questions I may have when an application is in production.

Let's think what kind of questions I might have, and what information might be useful to answer them.

Recently, I fixed numerous issues to make the first migration tests work.

Then, I started implementing the schema diff algorithm - the basis for schema migrations.

More dots got connected in the schema migration design, see this post for details.

Then, I tried to return to TDDing it, but strange errors met me there, so I left them to be resolved in the next piece.

Schema migrations are going to be generated and executed automatically under gulp watch. It will result in lots of tiny migrations: add a column, change its type, make it not nullable, and so on.

It's convenient during development, but it might be not optimal to reapply in production. Indeed, it's better to convert a large table to new structure all at once rather than running a conversion for each of the tiny migration.

This observation contradicts the previously stated migration workflow, so let's update it.

In spirit of TDD, I started with a meaningful, but failing test that is reasonably fast. Then, I worked to make it green:

• implemented the loading of schema fixtures from the codebase;
• worked on generating migration files.

After drafting some ideas of how the schema migrations should actually work, let's start implementing it in TDD way.

The goal of the current iteration is to adjust the database schema and preserve/convert existing data according to any changes in schema classes, grids, forms or indexers.

This post presents some thoughts how it might work with class definitions.

After finishing the iteration "#17 Minimum UI", I revisited the goals and the scope of the minimum viable product, and picked the most pressing task for the next iteration - "#18 Database Schema Changes".

I implemented the last user action that is typical to a CRUD application - object deletion.

Done:

• routes responsible for creating new products, and modifying existing products
• incremental indexing
• cloning query objects
• INSERT INTO ... SELECT ... statements

In Osm Admin, I've finished indexing. It means that whenever you modify an object in the database, the changes are automatically propagated to all dependent indexed properties in the database.

I've also introduced a grid/form pair as the main user interface concept that is optimized for performing operations on multiple objects. There is also a programming interface (API) that will internally work in the same way, but without visuals. I implemented a part of this interface - an object creation form.

Osm Framework and all projects built with it - including this website and Osm Admin - are upgraded to TailwindCSS 3.0.

Today, I finished implementing an object creation form.

It works according to the specs on Interfaces and Forms. Currently, it only supports string and integer input fields; later, there will be a lot more.

Let's review how it works.

In Osm Admin, a form is an integral part of the class user interface. It's a very specific kind of HTML form.

In this article, I'll review what's in a class form, and how it's reflected from the application code.

Yesterday, I described a user interface pattern for managing data of a certain data class using a grid/form pair. Let's call this grid/form pair class interface in the admin area.

In this article, I'll examine what moving parts are inside a class interface.

So far, I've been concerned about how application data is modeled, stored and handled internally.

Yet, the final objective a user interface for viewing and editing it visually.

Let's dream a bit about how it might look like.

Yay, indexing works!

It's changed quite a bit, so let's review how it works from the very beginning.

For the last two weeks, I figured out two core features that will allow Osm Admin to stand out from other CRUD applications:

1. It will allow mass editing of data objects.
2. It will automatically propagate data changes throughout the database.

The foundation for the mass editing feature is data queries. Data propagation will be ensured via indexing.

I've been working on the Osm Admin indexing engine, and it's still in progress. While working on it, I reworked the inner working of data queries. Finally, I've achieved a very clear separation of various Osm Admin concerns, and documented it.

In Osm Core, I added reflection over class methods.

I'm still working on indexing, and it seems to get one more refactoring. But more on that later.

Meanwhile, let's review Osm Admin modules, their responsibilities and dependencies.

After you got a project up and running, let's have a look what's inside. Every directory has its purpose. Learn where to put your creative efforts!

Note. This post is moved to Osm Framework documentation.

This website got a completely new look. There are new blog posts diving into core Osm Framework features. Osm Framework itself offers more convenient page layout, website-wide header, footer and <head>, customizable error pages. The themes support theme-specific CSS styles and JS scripts not bound to any module. New projects come with a handy bin/install.sh script that simplifies installation on Linux. From now on, run osmh without any parameters.

In Osm Framework, an application is a set of modules that you run as a whole. There are several applications defined in the project, each having its own PHP class. Mostly, deal with the main one, Osm\App\App. Beside the class name, every application also has a name, the main one is named Osm_App.

Access the current application object, and the main parts of Osm Framework, via the global $osm_app object and its properties. Add your own long-living objects there. Run an application using its HTTP or console entry point, or using Apps::run().

Note. This post is moved to Osm Framework documentation.

Modular software development is a well-known practice of dividing your application into several modules, each doing one thing, and doing it well. It increases readability and simplifies maintenance, as application concerns are fully separated from one another, easier to reason about, and to debug.

Modular development also encourages reuse. It's like a puzzle. Using one set of modules, you'll get an e-commerce application, using another set of modules - you'll get a blog application.

Note. This post is moved to Osm Framework documentation.

Using dynamic traits, customize anything. Inject your code in the beginning, in the end, or instead of any standard method. Even more, add new properties and methods to the existing standard classes.

Note. This post is moved to Osm Framework documentation.

Computed properties are one of Osm Framework pillars. They help to execute code only once, and only if it's actually needed. Computed properties control object serialization and caching. They provide meaningful insights into class interdependencies. Finally, computed properties are easy to test.

Note. This post is moved to Osm Framework documentation.

From now on, this website is deployed on push, and by the way, you can easily play with the website copy locally. In the Osm framework, new Osm_Project application allows reflecting over modules and classes regardless to which application they belong. New experimental project is aimed at quick creation of the Admin UI.

Osm Framework uses Monolog library for logging. Use standard loggers defined in the $osm_app->logs object, or add your own. Control logging in the settings.{app_name}.php and .env.{app_name} files.

Note. This post is moved to Osm Framework documentation.

After pushing changes to GitHub, osm.software website is updated without any additional manual action. On push, GitHub executes the deployment script on the production server. Most changes are done to content only, and in this case, the deployment script only updates the search index. Otherwise, with the website being on maintenance, it additionally updates Composer and Node dependencies, builds JS and CSS assets, and runs the database migrations.

This article describes our package release process before v1.0.0. In short, every change is released as soon as it's ready, and all dependent packages are updated at the same time.

This article provides a practical example of contributing changes to Osm Framework and other osmphp/* GitHub repositories. It's based on the Osm_Project application pull request.

Install PHP 8, MySql, Node, Gulp and ElasticSearch. Clone the project. Edit project settings. Finally, run few commands in the command line.

New Osm Framework version comes with improved, configurable and easily customizable Gulp script, modular NPM dependencies, standard page layout Blade component and brand new README. osm.software website contains an easy-to-follow new project installation instruction.

This article describes how we use GitHub issues and projects, both for new development and for support.

Install and use osm, osmc, osmt and osmh command line aliases for faster command typing.

Note. This post is moved to Osm Framework documentation.

Once PHP 8, Node and Gulp are installed, create new projects quickly using the command line.

Note. This post is moved to Osm Framework documentation.

The first osm.software blog articles have been written, edited and revised. Content changes are deployed in semi-automated way. The website got some SEO improvements, and now it scores 100% in Google Lighthouse.