• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.

Building the next-gen Chevereto (old topic)

Status
Not open for further replies.
Update 2019-11-06


Honestly I don't know if there's any crowd for getting the API first so please let me know if you care about that.

Hope to post more updates soon.

API in terms of being able to publish to chevereto (with the usual options of uploads) and pull some sort of list or gallery from chevereto would be useful for me. I wouldn't be desperate for it as soon as v4 is released but by the sounds of the way v4 will become, I think API should be available within the first six months of the v4. Having said that, earlier reading about a possible desktop client (to be able to publish direct to chevereto), would be an awesome useful productive solution if you were to develop it first. Just my thoughts :)
 
Hey there,

Long time since last report, first things first:

Are you considering adding the ability to upload videos in addition to images?
Yes, I'm considering to add support for video formats. It is something that brings a lot of content and I will like to see how it goes with that.

I think API should be available within the first six months
Sure thing!

2020-01-20

Development is ongoing, is just that it is a ton of work so I try to focus on that rather than show and tell. There will be time for that.

2019 was a very busy year:

Screenshot_20200119-213200__01.jpg
From rodolfoberrios

Release 3.14 dragged me a little bit, but it was of the highest priority to patch the security vulnerabilities affecting 3.X. You can learn about it here.

The development is ongoing and I'm peeking at delivery options (refers to how the software gets provisioned). I like the idea of ship something to where you don't worry about the software infrastructure.

The code looks nice (totally impartial opinion, at least to my eyes) and I'm adding more tests to complete the code coverage. I've added support for php 7.4 and typed properties, which suit me very well as I'm doing it strong typed.

I also got the domain chevere.org, it will be the home of the framework and it will be basically its documentation. That will include a function reference and instructions on the system components.

Hope to keep the same rate, wish to have it ready now.
 
Thanks for the update and I can see you have made good progress. I am looking forward to the video upload feature.

Would you also consider adding a video to GIF converter? Some of the top image hosting sites like giphy, gycat and imgur has added this due to increased demand for GIF.
 
Would you also consider adding a video to GIF converter? Some of the top image hosting sites like giphy, gycat and imgur has added this due to increased demand for GIF.
Thanks for the suggestion! It will be a nice addition to have the ability to convert video segments to animated images (gif, webp). Also, it will be nice to get an editor, a meme generator, etc. Basically, the goal is to get everything.

To be honest, I don't care that much about the specific application features at this time but its supporting architecture. This is because the needs around media sharing varies a lot so my focus is the system extensibility, not X given feature.
 
2020-02-02

Code coverage is being improved, this is a measure of the code actually tested, therefore is a measurement for quality. I think that I must explain what are these tests and code coverage terms that I will use in this entry.
  • Test / Testeable code
    It refers to code that can be tested in any given different environment (isolated or not) and it allows to detect inconsistencies in the code. Testeable code means higher quality code, which is also easier to maintain.
  • Code Coverage
    This is a measure that accounts the code execution, if a line is executed then is covered. Coverage indicates how meticulous tested is the alleged code.
The following image illustrates the code coverage, which is expressed in percent (%). You can also see other relevant information, like the size of the code which is 4K total lines to date (not including tests).
1580667309105.png

Code coverage is harder than I expected, mostly because it is just a slow process sometimes. There are days where I progress 5% vs others where I merely get .5%. The slow progress days are because this accounts lines, not complexity. Sadly, I don't have graphs on this yet (more data required). Code coverage is being reported at https://codecov.io/gh/Chevereto/chevere and the automated builds are on travis https://travis-ci.org/Chevereto/chevere

I will keep reporting on this, thanks for reading and for caring about the process.

Rodolfo.
 
Thanks for the suggestion! It will be a nice addition to have the ability to convert video segments to animated images (gif, webp). Also, it will be nice to get an editor, a meme generator, etc. Basically, the goal is to get everything.

To be honest, I don't care that much about the specific application features at this time but its supporting architecture. This is because the needs around media sharing varies a lot so my focus is the system extensibility, not X given feature.
i think it's must have feature in 2020, if new chevereto will have such feature it will be the best image sharing script ever
 
2020-02-10

Coverage keeps getting better, above 70% now. The image bellow shows a report for all the current work in progress.
1581357247320.png

Elements like Hooks or Middleware need to be tried at application context, I'm delaying the checks for now. Controller/s require a re-made, simple as that. For the API, I want a JSON API implementation for handling file related tasks, eventually with a GraphQL endpoint to provide a flexible data retrieval. Providing this kind of API will allow to create very flexible and unique server applications, with more ease. I'm still looking at libraries for this purpose.

There are other elements like Console (which is not shown in the report) which need to be written from scratch. In this regard, the system will provide a complete console application, with commands to turn on/off runtime settings, build, rebuild, analyze, list, logs, etc. The idea is to make this component extensible to the application settings, like enable/disable guest uploads or toggle a plugin setting.

Finally, there are elements that will get deprecated like ArrayFile. This was a wrapper on top of FilePhp. It will be replaced by object data structures.

On a different subject, building has been adopted at Travis and GitHub Workflows. This refers to build jobs carried by virtual machines, in which the machine gets configured like this:

[CODE lang="yaml" title=".travis.yml"]dist: bionic
language: php

php:
- 7.4
- nightly

matrix:
allow_failures:
- php: nightly

cache:
directories:
- $HOME/.composer/cache

before_install:
- phpenv config-add chevere.ini
- composer validate

install:
- composer install --prefer-dist --classmap-authoritative

script:
- vendor/bin/phpunit --coverage-clover=build/coverage/clover.xml

after_script:
- wget https://scrutinizer-ci.com/ocular.phar
- php ocular.phar code-coverage:upload --format=php-clover build/coverage/clover.xml
- bash <(curl -s https://codecov.io/bash)
[/CODE]

The above is a simple example, you can also add more PHP versions or other OS. This automatizes the testing process and many other stuff that I have not tried yet.

Hope to keep the steady work!

Cheers,
Rodolfo.
 
I've done a lot of translation work for the Dutch language. Does everything have to be done again for version 4? I hope not, I'm sure there will be additions and that's not a problem of course.
 
I've done a lot of translation work for the Dutch language. Does everything have to be done again for version 4?
Currently there are more than 20 translations and it will be a shame to lost these. I think that most of the translation contents will be preserved.
 
2020-02-20

Code coverage is about 90%, several bugs have been addressed aswel. At this time I'm working on the hook system that will allow us to customize the built-in functionality in a very high degree. This will grant a plugin ecosystem for third-party developers.

The framework still lacks about 4 crucial components (console, api, app, controller) so it is still not production ready. Hope to make progress in the following weeks.

The mainteability rate of the framework is 1 week! estimated by CodeClimate https://codeclimate.com/github/chevere/chevere which is very low if you consider that 1 month is already low. I now notice that the new code quality is way higher than the current accepted industry standard, which means that the framework will stand up due its strong base, developer friendly and feature set.

Hope you like the update, back to work now.
 
2020-02-29

I'm having second thoughts on the Routing implementation so I'm issuing several changes. Basically, I'm adding more separation of concerns for the whole thing at a very strict level while I'm working in the API router mapper. The idea is to be able to craft the API routing relying in the filesystem, so it is basically a bunch of objects doing the whole thing.

Something that seems to be clear is that it won't adopt the JSON:API standard as it will provide our own descriptive REST API, with its own toolset. This is because we need a self-descriptive, self-documented, self-validated standard with the ability to change on the fly (plugins) and I've found that the alleged standard is cumbersome for our need.

Most likely the API will be ready for my next post here.

Cheers,
Rodolfo.
 
2020-03-09

Last week I worked in the Routing component, which is a file system iterator that allows to describe the application routing based on route objects organized in the file system. Routing works by defining route file object properties in the file system:
[CODE lang="php" title="/api/articles/{id}/RouteDecorator.php"]return new class() extends RouteDecorator
{
public function name(): RouteNameInterface
{
return new RouteName('article-entity');
}

// You can omit this method to use the default regex.
public function wildcards(): RouteWildcardsInterface
{
return new RouteWildcards(
(new RouteWildcard('id'))
->withMatch(new RouteWildcardMatch('\d+'))
);
}
};[/CODE]
In the example above, the path is for /api/articles/{id} and it defines the route name (identifier) and the regex matching for digits (meaning that it will resolve /api/articles/123 but not /api/articles/alpha). This piece of code works as a nice example on how granular the framework is.

Route endpoints (method + path) are also defined in a file return object:
[CODE lang="php" title="/api/articles/{id}/Get.php"]return new class() extends RouteEndpoint
{
public function getController(): ControllerInterface
{
return new GetArticleController;
}
};[/CODE]
In the example above, a little magic is used to determine the HTTP method based on the filename and the controller is the only thing you have to declare.

Most likely the API will be ready for my next post here.
WRONG, because reasons. The main problem was that I wanted to use the HTTP OPTIONS method to describe the route endpoint communication with human readable data, like arguments type, purpose of the endpoint, etc. This was crucial to provide the self-described API I've been talking since forever.

Problem is that OPTIONS can't be cached (I know, I forgot to read the last line of the spec) so I can't use the same API to self-describe itself unless I add extra GET paths under the API routes for this purpose which I will hate myself if I do it, and everybody using the framework will also hate. Since that option is out of the table, I'm now building a /spec/ route which will work as the API that self-describe the whole public application endpoints.

Most likely the API will be ready for my next post here... Deja vu.

Cheers,
Rodolfo.
 
2020-03-19

Progress has been made in the application self-exposing, which is a system that describes how the application works in machine readable format. I've came up with a system that automatically generates a matryoshka of json files, in a document like this:

[CODE lang="json" title="/spec/index.json"]{
"groups": {
"group-name": {
"name": "group-name",
"spec": "\/spec\/group-name\/routes.json",
"routes": {
"route-name": {
"name": "route-name",
"spec": "\/spec\/group-name\/route-name\/route.json",
"path": "\/route-path",
"wildcards": [],
"endpoints": {
"PUT": {
"method": "PUT",
"spec": "\/spec\/group-name\/route-name\/PUT.json",
"description": "Replace all current representations of the target resource with the request payload",
"parameters": []
},
"GET": {
"method": "GET",
"spec": "\/spec\/group-name\/route-name\/GET.json",
"description": "Transfer a current representation of the target resource",
"parameters": []
}
}
}
}
}
}
}[/CODE]
The document represents the public description of all the application endpoints, it is like a manual in how to use the alleged application which is distributed in separated components. Top key is groups which in real-life will contain stuff like "web" and "api". So it is used not only to describe the API but the entire application.

Everything is distributed as components, for example this GET endpoint:
[CODE lang="json" title="/spec/group-name/route-name/GET.json"]{
"method": "GET",
"spec": "\/spec\/group-name\/route-name\/GET.json",
"description": "Transfer a current representation of the target resource",
"parameters": []
}[/CODE]
Clients implementing the api can easily detect and be aware of changes in a programmatic way, isolated for each endpoint. To make an actual endpoint self-expose its spec, like GET /route-path, the system injects a describedby link header pointing to the spec file at /spec/group-name/route-name/GET.json.

Progress status is very advanced, I will keep you updated.

P.S. Please stay at home.
 
I just installed Chevereto. I've been considering the premium upgrade and the positivity in this thread sealed the deal! God speed!
 
2020-03-24

A recap shows that since 2020-02-02 (last 51 days) coverage increased from 53.6% to 92.15%. Not only I added more tests, I did a ton of refactoring, started using data structures, etc. Overall, I have a bigger control on the system and you can tell by the rate of new code that I'm shipping constantly.

The last week I made some amends to the router-spec system, making it more clean and maintenable. Most of my daily work is to amend oddities and remove unnecessary stuff and everyday I get closer to the point where I will start with the actual V3 to V4 transition. It is for sure that V4 development will be also Open Source (same as Chevere) and it will be from scratch. This means that I will open a new RFC in the following weeks/months to determine the shape of the thing and it will be carried all over during development.

As some may know, during all this time I'm paying development with my savings and with the licenses that are still being sold. I'm an indie dev, this is my only real job and I will like to thank those that still support the ongoing development of this software. Most important, thank you for letting me create this state-of-the-art framework.

By the way, Coronavirus has slowed down some activity as for everybody in this world. So far I'm healthy so the development is still ongoing. Thankfully, my family is also still healthy. I know that we have visitors and readers from literally every corner of the world, I hope that wherever you are you can stay safe.

Cheers,
Rodolfo.
 
2020-04-12

Work in progress has slowed as I was working on V3, which is now getting neat improvements like the automatic importer and improved parallel upload performance (it is really fast now!).

I actually don't have any more stuff to tell, just wanted to mention the current situation.

Una mierda de post, pero vamos avanzando.
 
2020-04-21

Last weeks I've been working in V3.15, that kept me busy for a while and at this time I'm preparing a revision. In the meanwhile I'm retaking my work on this.

I want to show you how controllers works.

A controller is a element in charge of an actions in the application. It contains a stored procedure to "do something". Controllers in Chevere are dead simple. You define its parameters and the run method:

1587497896462.png

The parameters define strings arguments, with regular expression matching for validation.

Controllers can be wired to a route endpoint, in which case the declared controller parameters will merge to any path-based context argument (like /user/123). Controllers can be also called directly in the terminal:

Code:
php app.php run App/Controllers/Users/PutUser --id 123 --name rodo

Being able to call actions on the application from the terminal provides a very handy way to interact with the application in dev ops. For example, a shell script could perform a list of actions based on a bunch of controller calls. This heavily extends the usefulness of the application, because it is another way to interact with it. Just think about it, being able to tell the application what to do via chained commands rather than having to write application code.

Finally, controllers can be extended using the hook system. That way the parameters can be modified alongside the run instructions to be able to provide more functionality.

Sounds good isn't?
 
2020-04-28

Today I've reached a point where the code structure is getting more stable and documenting is already happening.


For me this is the beginning of the publishing process of the Chevere framework, and it will drive towards its first public release which should be ready very soon.


Está sucediendo!
 
Hello upgrade now payment plan for albums and join disk space.

Hello upgrade now payment gateway or plan for albums and join disk space sub categories.
 
Status
Not open for further replies.
Back
Top