We now have continuous integration with Jenkins in Angular.

At a high level, the steps are:

1. add a line like ng test --code-coverage --browsers=ChromeHeadless to your build script

2. have Jenkins publish the code coverage HTML report with it's HTML Reports plugin

3. install karma-junit-reporter and have it output the test report to a location on the build machine where it can be globbed together with other junit test reports you want to publish

I'd be happy to talk about these steps more if anyone is doing the same thing.

That makes a lot of sense that you naturally avoid the abbreviations where the English word carries some significant meaning.  Also, it seems like you naturally avoid abbreviations where the abbreviation carries a sort of misleading semantic meaning. With $case vs $c, $c at first glance looks like some sort of character function, whereas $s and $H don't immediately appear to be something that they're not.

And I forgot about horizontal space; on lines that get long it's not trivial.  That said, things like $select, $HOROLOG, and $piece carry a lot of meaning through the full word, and I think there's value in that.

Side note: for some reason I always want to use $g instead of $get (I don't, but it feels natural).  I think that's because, as a single syllable word which is a very simple operation, after seeing the definition for $get once, $g seems to fit it just as well as the full "get".

This is a really good point I hadn't considered.

When I was working with legacy code bases, it was difficult.  However, perhaps I'm blaming the wrong culprit.  Looking back, the main issue is that all the variable names were two random letters (at least to me; by the end I could usually figure out what the two letters were supposed to mean).  I'd be down 15 lines and then have to go back up to a variable's initialization to remember what the heck "cb", "sh", or "ac" actually were, semantically.

That was probably also done to save characters, and, as you said, is far more damaging than set -> s or if -> i.

I also agree that the lack of appropriate spacing makes a huge difference, as appropriate spacing can help show the control flow of the code.  Thanks for commenting this; after reading it, I now think that of all the questionable (in today's world) space saving techniques used in the past, the single letter variable names might be the least offensive.

That said though, with respect to the seeing more at once, s -> set doesn't increase the vertical space at all, so in theory you can see the same number of lines.  Also, I think it's very useful for coding languages to be written in English.  Coding is complex enough as it is, so we might as well take advantage of the fact that we're already completely comfortable with English, and thus we don't need to waste any mental resources during the processing of English string -> semantic meaning.  By using English, we're hijacking our preconceived notions of words like "while" such that the jump to the more complex control flow operator is less severe.  I'd contend it would take far longer than a few hours to be able to really read "w" the way you can read "while".

It's just like learning a new (non-coding) language.  Once I know what the vocabulary words mean, I can competently translate a passage in that language.  But I can't read it yet, with a direct link from the text to the meaning.

From what I understand, the single character command names are an anachronism from a time when the actual space the code took up was more of a limiting factor.  Nowadays, that's not relevant at all, so the added readability of the full words is optimal.

I remember my first time looking at code bases using the single letters.  One of the worst offenders, 'i' instead of 'if' was very annoying; it makes reading the code more like translating and less like reading.

That article about pack and link was very helpful and informative.  Thanks for that.

It didn't address what I'm asking, though (unless it did, and I'm wrong).  I don't really need a css build tool, at least I don't think I do.  I literally just want to know how I can get a scss file from one project into the node_modules directory of another via npm.

When I used npm pack on project1 to create a tarball, then installed that tarball into project2, the css file from the project1 wasn't in tarball2's node_modules, and I'd like it to be (so I can import it somewhere in project2).

Interesting.  We already have all of our Cache code building, running unit tests, and running code coverage on Jenkins.  My current plan is to see how easy/difficult it is to fit Angular build/test/coverage into that architecture, so that we can have everything in once place.

If there are features we can't have with Jenkins, or if it turns out to be so difficult that it may be worth splitting up our continuous integration across multiple platforms, I'll definitely give this stuff a look.  Thanks for the advice.

Would something like that ever make sense if the queries were repeated a lot, across a lot of different applications?  (minus the deleting the query part)

I'd never actually thought of this before.  Have you ever implemented anything like that?  Actually now that I think about it more, it would make more sense to just post the query and have it run (and store if it's not there), rather than getting trying to GET the query first, getting back a 404 or something, and then POSTing it before getting it.

Like others have said, a /search endpoint is inherently non-RESTful.  Are you certain that /search endpoint shouldn't be something else? 

For example, if the search is searching people, then perhaps redesign it as a /person endpoint instead?  If that's the case, then a GET request to /person with URL parameters is definitely the most "RESTful" thing you can do; you're asking for ("GETing") information for a bunch of person resources.

If /search is really what you want, then it's not really following the RESTful architecture anyway, because you aren't asking for information about resources, you're really just asking the server to take an action for you and send you the result.  In this case, you might as well forget about RESTful conventions and just do whatever is most convenient and maintainable. 

I suspect that the user is filling out some sort of a form in the UI with these search parameters.  If that's the case, you might be able to simply POST the object that the form generates to the server, and then pull the parameters out of the request body in your server-side handler method.  In general, whether you're pulling the parameters out of %request.Data or out of  %request.Content, there isn't much code that needs to be written on the server.  So pick the option that makes the client code the most straightforward.

As a follow up to this, if you're using the ##class(class name).myMethod(args) syntax and it's not working, it may be that you're trying to call an instance method, a method called on an object instance of your class, rather than a class method, a method called on the class itself.

In that case, you'd want to try something like:

set myObj = ##class(class name).%New()

do myObj.myMethod(args)

Hope this helps!

Can confirm that the %JSON.Adaptor tool is extremely useful!  This was such a great addition to the product.

In Application Services, we've used it to build a framework which allows us to not only expose our persistent classes via REST but also authorize different levels of access for different representations of each class (for example, all the properties, vs just the Name and the Id).  The "Mappings and Parameters" feature is especially useful:

https://irisdocs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page...

Also, @Stefan are you writing backwards while you talk?  That's impressive.

A few more details about your exact use case would help me give a better answer here.  As for the exact questions you asked, here's an example of the syntax you can use to write a query as part of a class:

Query Orgs() As %SQLQuery(CONTAINID = 1)
{
SELECT ID As OrgID,Name,DisplayName FROM Org ORDER BY Name
}

As for getting the query result as JSON, I asked a similar question a little while ago, and this discussion was very useful:

https://community.intersystems.com/post/how-do-i-return-json-database-sq...

Now, if your real question is something along the lines of "I want to write a REST endpoint that gives me back the result of a class query in Person as JSON", then unfortunately that's a non-trivial problem.  The fastest way would be to write some endpoint, like /basicpersoninfo, and have the REST handler route requests for that endpoint to a method that uses JSON_ARRAYAGG and JSON_OBJECT and dynamic SQL  (discussed in that other thread) to write out the results of that query in JSON.

Oh, okay!  I think the fastest way to get to what you want would be front end form validation.

Whatever you're using to build the UI that leads to this JSON post, have that code mark certain fields as required, and then alert if those aren't filled.  In general, I think in the division of labor that task typically falls to the front end.

In theory, you can write a server method that scans the input before JSON import and then throws a custom exception with all the missing fields, but that's likely more work than doing it on the front end (because the front end will still have to catch that, then assemble the alert message from it anyway).

Also, if you're going to be changing which fields are required a lot, you can (in theory) write a server method which exposes which fields are required, instead of hard-coding that in the front end, but, again, that's likely not worth the effort.

Any of that helpful, or am I misunderstanding the problem?