Latest Posts

I waited for this day too long. Today, I've tried out GitPod, and made it work for a project based on Osm Admin.

Today, I reiterated on what's left in this iteration, and finished the side menu view, and created a trivial home page for the admin area.

After getting the main branch all-green (tests pass, CLI and UI works as expected), I decided that from now on, I'll keep it always green, and use feature branches for all major development.

Then, I started implementing the main menu of the admin area.

Yesterday, I created a template for new projects powered by Osm Admin.

This way, you can create and publish a project in minutes, just follow the README. Yay!

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

Last two weeks were about implementing initial version of an Osm Admin grid, integrating it seamlessly with the editing form, and enabling mass-editing of multiple objects.

After finishing it, I realized that Osm Admin had become bigger than Osm Framework! To keep up, I started writing docs for it.

And now, you have a step-by-step guide for creating a project, adding Osm Admin to it and a practical example of an admin area that you can copy to your project and try it out locally.

Recently, I implemented mass-editing in Osm Admin. It allows you to view and edit multiple objects in a single operation.

This article describes mass-editing of products in a typical e-commerce application.

The last 4 weeks were mostly a vacation. It's been a time for reflection, but still, I delivered some new features.

In Osm Admin, forms already allow creating new objects and saving them to the database, and editing one or several existing objects.

I've also implemented URL query filters that are applied to the underlying database query and that can be displayed in the user interface.

From now on, Osm Framework and all projects built with it - can be installed and developed under Apache and on Windows.

In the user interface, you can narrow displayed data using grid column filters, or filters displayed in the sidebar. To enable that, apply #[Filter\*] attributes to class properties.

Applied filters appear in the URL query parameters, for example, .../edit?id=5+16+19, and on the page.

You can apply filters not only to a grid page, but also to a form page - to mass edit all matching objects, or to an action URL (edit, delete, or custom) - to perform the action on all matching objects.

In the same way, you can apply filters to the API URLs in order to retrieve or modify matching objects in a script.

The project repository, osmphp/admin, follows a typical Osm Framework-based project structure. However, this repository is going to be a reusable Composer package, and has important structural differences presented in this article.

This article introduces the core project concepts: data object, data class, data query, and data schema.

I'm super-excited to announce that I'm starting a new project codenamed "The Big Red Button". It's about defining application data structures and logic in PHP code, pressing the big red button (hence the codename), and getting fully functioning Admin Panel and API.

This sprint was dedicated to writing Osm Framework documentation, and indeed, there are 8 new in-depth documentation articles, 4-5 minutes long each.

Despite documentation focus, I kept improving the website. From now on, you can assign a canonical URL to a blog post or a documentation page, and use GitHub friendly relative URLs in documentation.

But the most important thing - I started sharing progress and insights daily on Twitter.

Throw the NotImplemented exception in any code path that is not implemented yet, and configure the debugger to stop there whenever the code path is executed.

osm.software website. From now on, Osm Framework documentation resides in the docs/ directory of the osmphp/framework repository, and it is displayed in a separate section of osm.software website. New data source indexing engine allows running complex interdependent data synchronization with a single command, osm index. New Placeholder class simplifies dynamic Markdown content generation.

Osm Framework. Apply dynamic traits within the same file using #[UseIn] attribute. Implement fast dynamic routing using new DynamicRoute class. Generate URLs using new $osm_app->base_url property.

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.

Osm Framework introduced production mode and maintenance mode. osm.software website went live.

Osm Framework introduced JS controllers, and JS unit tests. osmcommerce.com website project was renamed to osm.software, it finalized the post rendering, and introduced a tool for checking broken links.