New post
Article
· Dec 26, 2024 2m read

Why Docker, IPM and ObjectScript Quality are Important?

#Development Environment #Docker #InterSystems Package Manager (IPM) #InterSystems IRIS

Hi fellow developers in InterSystems IRIS!

I'm often being asked, especially related to technical bonuses we encourage for every Open Exchange contest why do we constantly give bonuses for Docker, IPM and ObjectScript Quality pass.

In fact, this is very easy to answer.

7 Life Hacks Guaranteed To Make Your Life Easier - everymum

Why Docker?

Docker increases maintainability and collaboration opportunities for your project. Indeed, if it is dockerized, everyone (other than an initial developer) is able to set the development environment for the project and make sure it does what it promises; it is easy to make changes to fix an issue or add a new feature. See more in my article on using Docker with InterSystems IRIS. All the basic IRIS templates on Open Exchange go with Docker. 

Docker is a free tool and can be installed both on Mac and Windows platforms (the most common amongst developers).

Why IPM? 

If your IRIS solution is not a pure Python or ODBC/JDBC thing but contains interoperability and/or ObjectScript resources, you'll have a question about how your solution will end up on a target IRIS Server of your customer. Ideally, with minimal manual involvement but rather by the customer or a developer (if it is a developer tool). The solution is the set of instructions to be made by your customer, that could contain a number of manual steps happily done. The success of your product being installed properly depends a lot on the fewer steps you have in the installation instructions.

In this case, IPM is ideal as it minimizes the installation procedure to one command, "install package-name," executed by the customer in a target namespace. Also IPM is useful not only for a customer but for the developer him/herself e.g. in a CI/CD procedure or/and a unit-testing pipeline. Learn more about IPM: IPM, documentation, and the first article about IPM, videos.

IPM is free and is being actively supported by the InterSystems team led by @Timothy Leavitt .
 

Why ObjectScript Quality?

ObjectScirpt language, even being compiled, still allows obvious bugs and potentially causes problems if certain guidelines are not being followed. The Solution for this is a linter tool that analyzes ObjectScript code vs a set of rules, provided by ObjectScript Quality Tool by Lite Solutions. 

To have your public ObjectScript code automatically analyzed, you need to add only one file. After that, the analysis of your code will be reported here. Also, see more in this article.

ObjectScript Quality analysis is free for public ObjectScript code.

That's it! 

Happy coding and happy holidays!

Discussion (16)4
Log in or sign up to continue
Robert Cemper · Dec 27, 2024

Thank you @Evgeny Shvarov !
I'd like to underline especially the use of  Docker.
My hundreds reviews in OEX wouldn't be possible without it with my limited test environment.
It's not only the option to run various  versions in parallel to my personal setup,
but much more the possibility to clean out all traces and specific settings just with a click.

If you ever tried to remove COMPLETELY an IRIS installation with all traces
from Windows you may understand me.

And with the available templates it is a really easy exercise to compose
your personal customized package with almost no effort and
test it over and over from scratch.


​​​​​​

1 0
Enrico Parisi · Dec 28, 2024

Hi @Herman Slagman, I totally agree with you, we have already discussed the issues and errors of "ObjectScript Quality Tool" rules in this post where I commented some of the errors in the ruses and there are indeed many more errors and, as you mentioned, some rule is debatable (or silly, as you said) to say the least.

Since that post and the errors I reported there nothing has changed, the rules are still there, wrong and unchanged.

What's the sense of having a "ObjectScript Quality Tool" with....such a poor quality itself?

To @Evgeny Shvarov, you say:

It’s difficult to introduce rules that will satisfy everyone.

Do you think that contradictory rules and rules with errors (plain errors) can satisfy anyone?!

what prevents you from introducing your own rules?

Time and probably I think it wouldn't be fun.

Let’s discuss....

We have started a discussion in the post linked above, I have reported some of the errors in the rules, nothing has been done/fixed. This gives the impression that "ObjectScript Quality Tool" is a dead project.
 

0 0
Herman Slagman · Dec 28, 2024

Hi @Enrico Parisi,
I was going to say "I wasn't aware of that previous discussion", but I saw that I actually contributed to it :-(
Indeed, since February nothing has changed.
We are all busy and apparently didn't have had the time to make our own attributions.
For me, I wouldn't know how to define a CQ rule, SonarCube is Java based AFAIK and I'm not a Java tiger.
It would be great if ISC would set up a GitHub repository with rules to which we can contribute.
I am not involved in the code base that was obliged to use CQ so it doesn't bother me directly anymore.
But SonarCube has some status and if a customer demands that the code base adheres to the rules of such a tool, you're in trouble. Perfectly working code (for years) suddenly has many major and critical 'errors' and you have to explain why that is.
I think no tool is better than a bad tool.
 

1 0
Herman Slagman · Dec 30, 2024

Hi @Evgeny Shvarov,

I, and I think Enrico too, was talking not only of the 16 rules you've selected, but the 100+ rules that are in the product if you buy it.

As far as I can see, the 16 rules are mostly about bugs which should easily be found by simple testing.

One of the biggest problems I have with OQ is that it doesn't expand macros, which gives a lot of false positives.
For instance $$$ReturnError("Illegal argument") isn't regarded as a Return, which is in the macro definition.
The same for $$$Yes, $$$True, etc aren't recognized as legal boolean values.

Silly rules that state that you should use certain syntax formats, such as parenthesis around conditions, because otherwise it is hard to comprehend for people coming from other programming languages.

I don't have the time to go though all rules but I will illustrate with one.

Rule ID:objectscriptquality:OS0078

Incompatible argument type in a method

The title is wrong, it should be "in a method call"

The argument passed must be of the type expected by the method. When no type is defined for a parameter, a %String argument is expected.

The first part of the sentence makes sense, the second is not true for Objectscript. If no type is specified the argument can be of any type.
If this is something you want is another issue.

Sometimes you want an argument to be able to be of different types.
For instance if an argument is of type %Stream, you might want to allow a simple string as a value too.

In general I would say this is not a rule that would enhance the quality of the code.

Then the rule explanation is simply wrong.

In following code, method DoWork2 expects to receive %Numeric as argument and DoWork3 expects to receive %DateTime as argument, but in both cases receive Sample.Person and will raise a "PARAMETER error" message on runtime.

A "PARAMETER error" only occurs when supplying too many arguments in the call and has got nothing to do with the datatypes of those arguments. Besides; running the example code gives no error at all.

Then the example code has several issues, which I won't discuss right now.

 

1 0
Evgeny Shvarov · Dec 31, 2024

Why discuss 100+ rules? 

I don't care honestly which rules ObjectScript Quality's clients would like to enforce in their organisation.

By providing a free-of-charge scanning with this tool (which is not InterSystems one), we use only 11 rules that we think are useful for the developer community. And we are more than happy to expand these 11 to more or improve current.

For 100 + other rules we don't care.

0 0
Enrico Parisi · Dec 30, 2024

Hi @Evgeny Shvarov,

I fully agree with the answer above from @Herman Slagman so I won't repeat what he wrote.

You asked me:

Which of them is not useful/silly?

As already reported in my previous post in February in other tread, many rules contains errors, I don't think I should repost the same comments, so please have a look to my previous post for details of some of the errors in the rules. Please note that the errors I comment/report is not a complete list of all errors in the rules, just some random I had time and will to report, there are more than that.

As for the not useful/silly rules I gave you two additional examples on top of what @Herman Slagman already wrote. Again, there are more than this few reported.

Class has too many properties
A long property list can indicate that a new structure should be created to wrap the numerous properties or that the class is doing too many things.
Maximum allowed number of properties (inclusive)
Default Value: 10

A class with more than 10 properties is considered a Quality issue? Really?
Most of complex real life projects have classes with more, sometime much more, than 10 properties, simply because real life "things" are complex and often have many possible attributes.
Just as an example, there are so many classes among IRIS "system" classes (part of the various frameworks) that have much more than 10 properties and this for very good and valid reasons.

Class has too many methods
This rule checks that a given class has a number of methods which is less than, or equal to, a configurable threshold. A class with too many methods is often an indication that this class needs to be refactored into several, smaller classes.
Maximum number of methods allowed for a class
Default Value: 10

Same as in number of properties. Useless to repeat.

So, ObjectScript Quality tool has many rules with errors and some rule is....well....debatable.


I fully agree on your statement "It’s difficult to introduce rules that will satisfy everyone" and that's the very reason why in my previous post in other thread I avoided mentioning "debatable" rules and only reported errors in the rules. Now you asked, so I had to comment on that too.

The issues (plain errors) reported in February has never been fixed/considered, that's why me and @Herman Slagman said that nothing has changed since February.
This gives the impression that nobody cares of the quality and maintenance of ObjectScript Quality Tool.

As for the invite to develop our rules I'm sorry but I don't have time, knowledge and will to do so, my contribution was to report errors and, if anybody cares (so far it doesn't seem so) to fix them, I can report more errors and "debatable" rules.

My concern in your endorsement of ObjectScript Quality tool is that some new IRIS user may think this rules are valid good practice and guidelines for coding in ObjectScript when, in fact, many rules are not at all.

I'm not sure if "no tool is better than a bad tool" as Herman wrote, but the risk of misleading people is very high, I think that at least a disclaimer and warning to people looking at it is advisable.

0 0
Evgeny Shvarov · Dec 31, 2024

Why are we discussing too many properties and too many methods rules?

For InterSystems Developer Community we use only 11 rules.

Is "variable not found" a bad rule?

I faced this issue many times, even in my code, and found it very helpful. What is bad that public ObjectScript repositories will be scanned for free for such an error?

Could we discuss these 11 rules that are being used? 

Which else rules could be useful and potentially could be added?

0 0