As I See Tech

Once in a while, a developer can be challenged by a new problem that puts him/her in the zone. This one happened recently and it's exhilarating! I have never encountered this problem before. Honest! And this is how I (eventually) solved it...

The idea of creating APIs and templates to guide a team in developing an application can be nerve wracking to control freaks. The truth is, you can never stop a developer from bending the rules and doing something beyond the expected, and still get great results. There are developers who stick with the template provided to them, and there are those who brave themselves to explore. And this is where the fun begins.

Using Mendz.Data with Dapper and stored procedures is a great combination. It works well when the primary data source is just one database. Developers can centralize business rules in the database stored procedures. Mendz.Data-based repositories can then be used as the bridge between stored procedures and the domain's POCOs. Simple, right? Well... what happens then when you put transactions in the picture?

Mendz.Graph's Graph class implements IFormattable. The default DOTFormatProvider and DOTFormatter implementations included in Mendz.Graph are really just samples of what can be done. Developers are encouraged to create and use their own IFormatProvider and ICustomFormatter implementations for the Graph.

All Mendz projects and products are now .Net Standard 2.0 class libraries. Use them all in your .Net Core or .Net Framework or .Net Standard targeting projects.

For the longest time, web applications absorb processing loads on the server-side, leaving the client-side to mostly just rendering the response (i.e. HTML/CSS) from the web server. Now, with JavaScript frameworks like Angular, React, Vue, etc., the client-side is sharing the processing load.

When creating ASP.Net applications for business and enterprise requirements, you are more likely doing something nowhere near basic. While simple MVC examples are available everywhere, the truth is, they are more often, if not always, NOT applicable as-is.

If you like Mendz.Matrix and Mendz.Graph, you'll love Mendz.Graph.Representation.

G = (V,E). If that makes sense to you, then Mendz.Graph is for you! If it doesn't make sense to you, and you need to work on graphs (Graph Theory), then Mendz.Graph is definitely for you, too!

Matrix, square matrix, dense matrix, sparse matrix and compressed matrix galore! Create matrices, perform mathematical operations with them, and even compress them using CRS (compressed row storage), CCS (compressed column storage) or CVS (compressed value storage). Mendz.Matrix is a simple and lightweight library for working with matrices.

Mendz.Data is designed with the team in mind. Different developers have different styles. A good team respects each member developer's style. However, a team working on the same project should also mean that all developers agree on many things. At the very least, code completeness, consistency and quality should be predictably maintainable and measureable.

Mendz.Data.* helps teams delegate and separate concerns. Not everything needs to be done in a single project. You can use Mendz.Data to distribute tasks so that deliverables can be created concurrently, tested independently and later assembled/integrated together for functional testing.

The truth is, you can use the Mendz.Data.Repository and Mendz.Data.Repository.Async CRUDS interfaces in your own custom repository implementations. There is nothing in this namespace that requires you to use them only in purely Mendz.Data-based contexts and repositories.

The idea and motivation behind Mendz.Data is to remove the abstraction out of project planning, so that you can jump right ahead to coding and development. Mendz.Data is not just a library of APIs. As advertised, it is designed to provide tools and guidance.

More than a month has passed since I published Mendz.Data. Many developers and teams are using Mendz.Data to guide them in developing contexts and repositories for their projects. Simplicity, consistency, productivity, quality and scalability are key motivators.

Advanced ETL requirements can involve building data from various sources. Mendz.ETL-based joiners allow developers to define advanced query operations on data sources, generating data into a desired format that can be better consumed by the ETL flow.

ETL involves agreements between partners with regards to how they will "speak" with each other. Validating what a partner sends and what you send to your partner is an important ETL requirement. Mendz.ETL supports the creation of validators, which can be called at the start and at the end of an ETL flow.

Mendz.ETL suggests three basic ingredients to ETL solutions: source adapter, mapper and target adapter. Here are some ideas for your target adapters.

Mendz.ETL suggests three basic ingredients to ETL solutions: source adapter, mapper and target adapter. Here are some ideas for your mappers.

Mendz.ETL suggests three basic ingredients to ETL solutions: source adapter, mapper and target adapter. Here are some ideas for your source adapters.