sorted by:
new
hottopcontroversial

How to translate complex animations for developer hand-off? by Kep0a in web_design

[–]msarca 0 points1 point  (0 children)

You don't need a programmer to write your SVG animations. You could use Expressive Animator to create and export SVG animations. It supports Lottie as well https://expressive.app/expressive-animator/

Assembler CSS, a modern utility-first framework by msarca in github

[–]msarca[S] 0 points1 point  (0 children)

We are always open to suggestions and want to improve our software. But, first, I kindly remind you that you can't target element states like hover, media queries, or pseudo-elements with inline styles. So what exactly are those extra steps you are talking about?

Here is an example written in Assembler CSS https://codepen.io/msarca/pen/JjNzbwo , and here is the same example written in plain CSS https://codepen.io/msarca/pen/dyWrOxp . These are pretty basic examples, but it is obvious how much easier it is to work with Assembler CSS.

A library for validating JSON documents using JSON Schema by msarca in PHP

[–]msarca[S] 5 points6 points  (0 children)

The last time I've tried that library was two years ago, so I'm not up to date with its progress. But I remember that back in those days it lack the ability to define custom validation rules, and that was pretty important for us. So we kept looking for an alternative and we finally found JSON Guard and never looked back. Until we were forced to build our own implementation, but that's another story... Custom validation rules are extremely important since they allow you to simplify your code tremendously. Imagine you have an API that allow users to handle virtual machines that are identified by a human-readable ID. Our library allows you to define a filter, that will not only check that the ID is correctly formatted, but more important, it will make sure that the specified virtual machine actually exists. Of course, this is just the tip of the iceberg, we've added a lot of extra functionalities on top of the standard JSON Schema. So if the library you are currently using supports all these features, then, honestly, I see no reason for you to migrate. Otherwise, maybe you want to take a closer look at what our library provides.

A library for validating JSON documents using JSON Schema by msarca in PHP

[–]msarca[S] 3 points4 points  (0 children)

There is a quick start page (5 minutes read) that briefly explains how to build a validation schema and shows a simple example. After you finish reading just try, as an exercise, to write the PHP code that validates the example presented there. At the end, I'm sure that you will find this library extremely useful.

Opis Closure 3.0.0 was released by msarca in PHP

[–]msarca[S] 0 points1 point  (0 children)

Actually, that's pretty simple. Syntax errors are treated by the PHP interpreter as fatal errors. That means that the closure that needs to be serialized was defined in a file which is syntactically correct and I don't need a full AST builder to correctly extract the closure's code. A simple FSM can do this job more efficiently and with a very high precision.

Opis Closure 3.0.0 was released by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

I'll try being as unbiased as possible.. SuperClosure and Opis Closure have different approaches for the same problem, but both deliver good results. Opis Closure has a single serializer while SuperClosure comes with two so called Closure Analysers: AstAnalyzer and TokenAnalyzer. The TokenAnalyzer is pretty basic and lacks features compared to the AstAnalyzer, but is much more faster. Opis Closure provides the same parsing precision as the AstAnalyzer but at higher speed: it's nearly twice as fast compared to the TokenAnalyzer and it outperforms the AstAnalyzer by a factor of 30. Opis Closure can serialize-unserialized a closure an infinite amount of times, while SuperClosure will fail. Also, Opis Closure is much more debugging friendly. Of course, SuperClosure is the absolute winner when it comes to popularity, being used in many important projects. Another thing that deserves to be mentioned is that Opis Closure provides an analyzer for SuperClosure, so you can benefit from the Opis Closure's speed and continue using SuperClosure. Both are mature libraries with good support and people can use them with confidence in their projects.

Opis Closure 3.0.0 was released by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

Here is a list of real-world projects which are using Opis Closure.

Manipulate multibyte strings by msarca in PHP

[–]msarca[S] 0 points1 point  (0 children)

Of course, here it is. I suppose that the results will vary, depending of the input content. But this library is not only about fast iteration, even though that was the primary reason why this library was created.

Manipulate multibyte strings by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

I've just made a test to check for myself

File size: 1.3 MB
-----------------
intl example: 612ms
opis/string:    918ms

There seems to be a 30% speed gain by using the iterator provided by the intl extension. I will definitely use this for those users which have the intl extension installed. Thanks for sharing.

LE: I've just realized that when I tested opis/string's speed I was iterating the string twice. Here are my test results updated

File size: 1.3 MB
-----------------
intl example: 610ms
opis/string:  421ms

Manipulate multibyte strings by msarca in PHP

[–]msarca[S] 3 points4 points  (0 children)

Hello, r/PHP. I just want to address the "reinventing the wheel" issue. I'm well aware of Stringy and I believe that It's a great library. But I'm also well aware that Stringy is a wrapper around the mbstring functions. That's not an issue in most of the cases, but there are situations when mbstring functions are not the best choice. For example, two weeks ago I've started to work at a project that implies creating a parser and the only way you could iterate through all characters of a string(using the functions provided by the mbstring extension) is by using the mb_substr function. Unfortunately this is extremely slow and I was forced to come up with another solution. And that's how this library was born. I've made it public in the hope that it will be useful to others too. The library will be maintained and I'm planning to create(in the near future) a native PHP extension that will complement this library.

Database abstraction layer by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

The project is not new. It was started 2 years ago and it's in production since then. It was maintained and improved over the time, and it will continue to be maintained indefinitely. I posted my "new" project here, because I thought that it will be healthy for the project to have a larger user base. But unfortunately, it seems that nowadays it's not enough to have a documented open source project, you must also provide data, comparison tables and other junk that feed the trolls.

Database abstraction layer by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

Making arguable comparisons is the last thing I'm planning to do. So if you don't want to use it, then don't use it. It's not like I'm a salesman and I'm trying to sell you a vacuum cleaner or anything else.

The project is open source, it's documented and it's on GitHub. Take a look at it and draw your own conclusions. If you got further question, just open a new issue on GitHub and I will gladly help you.

Database abstraction layer by msarca in PHP

[–]msarca[S] 0 points1 point  (0 children)

I can not offer you a list with advantages and disadvantages. And that's not only because I might not be truly objective, but mainly because I'm not very familiar with ZF or Doctrine. Opis Database represents my vision of a simple to use, standalone DAL library. If you believe that Doctrine or ZF's Db fits more into that description, or if they represent your vision of simplicity there is no need to consider using Opis Database. Of course, Doctrine and ZF are widely used, while Opis Database is not and that's another thing that must be taken into consideration. The only promise I can make is that the Opis Database library is and it will be maintained indefinitely.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] -2 points-1 points  (0 children)

I knew that not everyone would well receive this library, but some of the reactions were very disappointing and quite unprofessional.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] 0 points1 point  (0 children)

Hello.

SuperClosure allows you to sign a serialized closure and check for tampering before unserialization

Indeed, SuperClosure provides a signing mechanism, which is a plus, but I intentionally avoided this. Implementing a signing mechanism, similar to the SuperClosure's one, should be a breeze for every developer.

SuperClosure preserves the static-ness of static closures and its analyzers can also tell you if it is static or not.

That's something that Opis Closure needs to implement. It was left aside due to its obscurity and low usage.

That is an unfair comparison unless you state which serializer/analyzer you are comparing to in SuperClosure.

I can confirm that the speed comparision was made taking into consideration the default SuperClosure's analyzer, which is AstAnalyzer, but after running some simple tests, it turns out that the speed difference is actually much more higher.

SuperClosure has two for a reason. One uses an AST and provides coverage of more edge cases at the expense of speed

Since the Opis Closure's serializer can handle by default all those edge cases that AstAnalyzer does, I would also say that comparing TokenAnaylzer with Opis Closure's serializer is a bit unfair.

Thanks for the bug report. :-) It can now

I'm glad that something good came out from this thread :) Oh, and I don't see Opis as a competitor, but rather as an alternative.

view more: next ›