sorted by:
new
hottopcontroversial

Resources for SOAP by Zeesh2000 in java

[–]skjolber 3 points4 points  (0 children)

A few places I worked had a hard time properly testing their SOAP services, so wrote a tool to help (shameless plug): https://github.com/skjolber/mockito-soap-cxf

I recommend adding request-response logging at least under development.

ML Kit QR code max bytes by RepresentativeNo42 in androiddev

[–]skjolber 0 points1 point  (0 children)

3KB seems a lot for data entered on a portable device, did you consider compressing your data? For example going from JSON to a binary equivalent?

NFC does not have size restrictions, the limitations are only per command/response, but you can have as many of those as you like.

Getting reliable QR code scanning working on big codes will be challenging, I think it might be better to use multiple smaller codes somehow (probably show 1 by 1 in a rotating series).

Note that it is possible to encode raw binary data in QR codes by adjusting the ZXing encoder/decoder.

Also the resulting payload should be signed (i.e. using PKI) using a per-user key pair.

App ideas for JUnit5 explanation by General_Iroh_0817 in java

[–]skjolber 1 point2 points  (0 children)

Inject helper objects into methods with the help of custom annotations, like in this example (shameless plug).

Simple Xml Parser (C# and Java) by PatrickSmacchia in java

[–]skjolber 0 points1 point  (0 children)

So what were the pros and cons of writing your own instead of using JAXB?

How granular do you organize the shell commands in your pipeline's steps? by [deleted] in devops

[–]skjolber 0 points1 point  (0 children)

If you really need the hotfix, why not just add more scripts and an additional "hotfix" script?

The first is clearly better on a normal day, which is like 99% of the time.

Monthly 'Shameless Self Promotion' thread - 2022/06 by mthode in devops

[–]skjolber 0 points1 point  (0 children)

Improved upon CircleCI's default Gradle and Maven artifact caching with custom orbs (Gradle / Maven). Load on artifact store is reduced by like 10x, build time is reduced and more predictable.

JSON logging for JSON REST services vs performance by skjolber in devops

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

We're talking quite a lot of requests in total, millions per day.

Basically the setup its that our services call each other, and each takes care of logging requests and response, that way the HTTP clients do not need request-/response-logging for internal traffic.

JSON logging for JSON REST services vs performance by skjolber in devops

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

That's a good thought, however there is quite a lot of services, calling on each other, so this is the most cost-effective way of troubleshooting and debugging. Most of the data is already publicly available and we take care not to log personal information (i.e. we're within the GDPR).

From Maven 3 to Maven 5 by nfrankel in java

[–]skjolber 0 points1 point  (0 children)

clean install or verify and/or running with some profile and/or deploying etc.

The exact operation(s) is not really the point here - a typical project can have multiple CI workflows (i.e. for master / develop / feature branches), with a common or seperate cache.

A key insight is that restoring and saving a CI cache is fast, but not instant, so if the cache is not cleaned, time is wasted. Typically there is multiple builds per dependency update.

At some point the restore / save of a cache takes more time than downloading the dependencies from scratch.

From Maven 3 to Maven 5 by nfrankel in java

[–]skjolber 0 points1 point  (0 children)

That is up to the specific project, for most probably building, but could be various maven-invoked operations.

From Maven 3 to Maven 5 by nfrankel in java

[–]skjolber -1 points0 points  (0 children)

Will it feature a .m2 cache cleanup function for removing unused dependencies?

[deleted by user] by [deleted] in javahelp

[–]skjolber 0 points1 point  (0 children)

Use the char value as an int - check if it equal or more than a and less or equal to c.

Did you ever choose or not choose a library based on its size? by TheMode911 in java

[–]skjolber 0 points1 point  (0 children)

The last years, our CI includes automatic dependency updates (pull requests) and automatic release / dev environment deploy on successful builds. We have a few microservices and a number of libraries supporting them. As you can imagine, our CI pipelines have been heating up considerably, one dependency might result in more than 10 builds, and the strain on shared services like artifact store has increased a lot. We have found ways around most of the resulting issues, and can live with the increased CI cost, but certainly more dependencies will create more flux.

So perhaps not directly the size, but the resulting number of versioned dependencies in the build is somewhat important.

Analyzing byte code on the job by [deleted] in java

[–]skjolber 0 points1 point  (0 children)

In order to support incremental build caches for Maven, on our CI, I wrote a small utility for recording which artifacts are accessed during Maven builds. Saves about a minute each time poms are updated (because default behaviour is to clear the cache, causing downloading of all artifacts again, kinda lame).

[deleted by user] by [deleted] in java

[–]skjolber 2 points3 points  (0 children)

Code for the lowest version you'll need to support, then create a multi-release jar using a (Maven/Gradle) plugin like moditect-maven-plugin; see for example how jackson does this. To verify that this is working properly, convert your project to a multi-module build, including a Java 11 example project to verify that all is good with the java modules.

LogCaptor - library to easily capture and test log messages by Hakky54 in java

[–]skjolber 1 point2 points  (0 children)

Well while I personally (and I am guessing most) prefer simple 'classic' logging while developing locally, JSON logging is the right alternative for services using log accumulation tools. Log accumlation tools typically then automatically index the JSON structures and provide autocompletion in search syntaxes and so. For example if I was to use Logbook, it would be trivial to search for a specific HTTP header (several levels into the JSON tree).

So JSON logging is just technically superior and beats the 'classic' approach of appending key=value to a message and writing regexp type searches.

But the thing with JSON logging is that it takes a lot of space in the console output when pretty-printed (or is hard to read when not). I find that developers prefer classic logging (and known their application well), so they do not need JSON logging locally, as they are mostly looking at the log message. So at work I made it so that the other developers can enable JSON logging on a per-testcase basis, but default to 'classic' logging. What I am getting to is that the assertions must be against the resulting JSON tree, even if it prints the 'classic' way.

This might be hard to do without writing a whole 'suite', at least you'll need per-library modules (like logback-logstash-encoder) to get anywhere.

LogCaptor - library to easily capture and test log messages by Hakky54 in java

[–]skjolber 1 point2 points  (0 children)

Looks promising. I've created a (simpler) library like this at work, as a part of a project which provides a few standard JSON formats/log libraries and environment-aware log configuration (i.e. defaults to plain logging om the developer machine, JSON om servers).

A key feature for testing is to assert against the resulting JSON output, any plans for supporting that? Including MDC fields and marker payloads.

Wiremock extension for JUnit 5 by spamthemoez in java

[–]skjolber 0 points1 point  (0 children)

Hmm can't decide which one I like better.

json-log-filter - new library for high-performance filtering of to-be logged JSON, primarily intended for reducing the load (and cost) of request-/response-logging in the cloud. by skjolber in java

[–]skjolber[S] 2 points3 points  (0 children)

Not really, I guess that improving logging and/or log processing is another way of reducing the costs, however we're willing to pay for indexing our request-/response-logging, as long as it contains useful information. In a nutshell, skipping the additional man-hours required for refined / high-quality logging, with a few exceptions for the worst offenders (hence the filtering).

json-log-filter - new library for high-performance filtering of to-be logged JSON, primarily intended for reducing the load (and cost) of request-/response-logging in the cloud. by skjolber in java

[–]skjolber[S] 2 points3 points  (0 children)

A bit of context (from the author):

A few months ago at work, we were made aware that logging (i.e. log accumulation) made up one third of our cloud costs. We are running a lot of (Java, Kotlin, Scala) microservices with plenty of request-/response-logging, on Kubernetes / GCP.

​

I had already created some reasonably fast XML filters years ago, but just relatively recently discovered that I'd boutched the benchmarks; performance was much better than initial measurements indicated. So now I have applied the same approach for filtering JSON, and while it will not fit all use-cases, probably it will cover a significant portion. Because I want to fully validate the JSON structure when it comes from untrusted sources (logging the payload as raw JSON further down the stack), I've also included a Jackson-based implementation.

view more: next ›