DEV Community: Sebastian Sastre

Developing a SQLite backend for Mapless

Sebastian Sastre — Tue, 10 Oct 2023 14:20:35 +0000

Earlier this month I was asking in the community for interest on moving forward the development of a SQLite backend for Mapless and it was generally well received. People understands that is good to have another persistence option in Smalltalk specially if it's based on a backend that is both mature and well accepted, not just among smalltalkers but in the whole industry.

SQLite alone will be a good fit specially with new small projects, MVPs or micro-SaaS and used behind Mapless, the SQLite features will be reachable with its comfortable API and its schemaless experience in the smalltalk side.

Two attractive reasons for adoption.

And with Mapless, there is a plus: state portability. A secondary benefit of having a MaplessSQLiteRepository is that your data can easily be migrated from one backend to another and since running SQLite is cheap, this has important economic consequences. It could make feasible something that previously wasn't.

Think of the margins for a project that can start with a persistence solution that doesn't require the costs of setup, DevOps and operations of an additional database server. Instead, it will be the same server you're using for the application as SQLite only needs a library in the system and lean usage of CPU and RAM.

Once your product, either a MVP, micro-SaaS or full SaaS has the network traffic that requires an upgrade, with Mapless you'll be enabled to easily develop migrations to MaplessPostgreSQLRepository or MaplessMongoDBRepository with almost no impact on your application. All that while the economics of that migration and setup are covered by the growth of your business.

So, for using SQLite with Mapless, the good news is that I'm almost having all its unit tests green.

Currently two unit tests that are failing. These were designed when developing the PostgreSQL support and using its feature of querying inside the JSON column type.

Speaking of which, I'm still thinking what's the best approach for that since SQLite has 2 ways to use JSON:

JSON1 extension and
using the BLOB type

If you have an educated opinion on what's the best path for this, reach me by email, the Pharo Discord server or LinkedIn I'd love to hear it.

Bonus benchmarks

Here are some benchmarks it on my 2,5 GHz Quad-Core Intel Core i7:

Benchmarking Mapless on SQLite...

Saved 1000 instances of MaplessDummyPerson in: 166 ms (~6008 saves per second)
Read 1000 instances of MaplessDummyPerson in: 159 ms (~6279 reads per second)
Saved 10000 instances of MaplessDummyPerson in: 1755 ms (~5699 saves per second)
Read 10000 instances of MaplessDummyPerson in: 1590 ms (~6290 reads per second)
Saved 1000 instances of MaplessDummyPerson and MaplessDummyUser in: 367 ms (~2722 saves per second)
Read 1000 instances of MaplessDummyPerson and MaplessDummyUser in: 188 ms (~5311 reads per second)
Saved 10000 instances of MaplessDummyPerson and MaplessDummyUser in: 3721 ms (~2687 saves per second)
Read 10000 instances of MaplessDummyPerson and MaplessDummyUser in: 1818 ms (~5500 reads per second)

The DRY Principle: Reducing Redundancy for Clean Code

Sebastian Sastre — Thu, 07 Sep 2023 22:05:53 +0000

Have you heard about DRY? or "Don't Repeat Yourself"? This a principle that leads to clean coding, aims to reduce redundancy and promotes elegant, concise, and maintainable code.

At its core, DRY encapsulates a simple idea: avoid duplication. It's the art of writing code in such a way that every piece of knowledge or logic is expressed in just one place. By adhering to DRY, you ensure that your codebase remains efficient, consistent. Also we can say less error-prone because each non-repeated functional unit can, precisely, be unit-tested.

Here are key scenarios where DRY shines and can make your code better:

Repetitive Logic: Whenever you find yourself writing the same logic, obviously for a second time or a slight variation of it that can be refactored into one. That's a DRY opportunity. Create an intermediary reusable function or method to encapsulate that logic, promoting code consistency and making maintenance a breeze.

Configuration Management: Managing configuration settings like API endpoints or database credentials in one central location not only adheres to DRY but also simplifies updates and reduces the chance of inconsistencies.

Constants and Magic Numbers: Replace hardcoded values scattered throughout your code with named constants. This not only enhances readability but also facilitates changes by modifying one central constant. Better, these central constants can be taken from environment variables making your code safer while keeping it flexible.

Cross-Function Duplication: If you have multiple functions or methods that perform similar tasks, consider consolidating the common logic into a single function and calling it from wherever needed.

Testing: In your test suites, the DRY principle shine. If you avoided duplicating functions you will fill the benefits when coding its unit tests. You'll notice it reduces test maintenance efforts, ensures consistent test conditions and provides regression detection.

Note that the DRY principle isn't limited to a specific programming language or paradigm; it's a universal concept for evading to have multiple source of the same function. And multiple source of truth leads to ambiguity and deambiguation costs. Hence, whether you're writing Ruby, JavaScript, Python, Smalltalk, or any other language, DRY remains a guiding rule.

Said that, we can also talk about when not to use DRY in software engineering.

But as usual, before breaking the rule, you need to first master the rule so let's keep that for an incoming article.

In principle let's think about DRY and the reasons why is a great rule to have as default system design and programmer's behavior.

My solution to Phone Number on Exercism in the Ruby journey

Sebastian Sastre — Wed, 23 Aug 2023 13:54:32 +0000

https://exercism.org/tracks/ruby/exercises/phone-number/solutions/sebastianconcept

Answer: Compiling Pharo to C?

Sebastian Sastre — Wed, 23 Aug 2023 13:45:02 +0000

Aug 23 '23

I wan't to develop, test and profile code using Pharo, but then compile it to C.

How can I do it?

Smalltalk code in Pharo will be compiled to bytecodes that the VM runs, so there is no way really to transpile straight Smalltalk code from Pharo to the raw…

Open Full Answer