Found a similar question about the difference between QAPlug-FindBugs and FindBugs-IDEA, but not about CheckStyle...
I think (from previous experience) with these plug-ins that one difference is that the QAPlug's CheckStyle version seems to be behind the CheckStyle-IDEA's CheckStyle version (I'm not referring to the versions of the plug-ins, but of the version of CheckStyle that's embedded in them).
Anyone knows of any other differences between those?
Advantages of CheckStyle-IDEA over QAPlug – Checkstyle:
Newer version of Checkstyle used
Community on GitHub
Fast scan before commit
Support for multiple configurations
Support for third-party checks
I haven't noticed any use case when QAPlug is better.
Related
Based on my understanding, all the components in RedHat BRMS can be achieved by integrating various drools components. So, is it a bad idea to use drools in Production?
Not at all. The difference is that if you pay RedHat you will have support from them if you need advice or you find any problem.
If you use the Open Source version, you will have all of the features present in the payed version (or even more), but you are basically on your own.
Hope it helps,
Along with support you will get patches on regular basis for reported issues. You wont get any patch for community release of Drools/jBPM.
I am sure after WebAssembly Post-MVP, asm.js will be deprecated. Even now, a few existing asm.js projects already start to use WebAssembly. JS engine (V8) also starts to comiple asm.js to WebAssembly, so even if old projects never migrate, end-users will still get partial advantages from WebAssembly.
My question is, what about native-client then? It is not implemented in JS engine so that can be a problem. Native-client seems to be deprecated even now. Will native-client be completely removed from Chrome in foreseeable future? I would love to see some reduction in binary size of Chrome.
Side questions:
After thread/gc/simd/exception are included in WebAssembly, is there still something native-client has but missing in WebAssembly (blocking migration)?
It took WebAssembly about 2 years just to reach MVP, what is the expected time for any one of the Post-MVP to get finalized?
It seems like WebAssembly group is tackling multiple Post-MVP features at once instead of one by one, won't that make it slower to finalize one of them?
Answering the side-questions only, because I no longer work on Native Client. Google's plans are its own to speak for, so I'll make this a wiki.
Update as of 2017/05/20 NaCl isn't in glibc. This was the original libc which was supported, and took quite a while to clean up and upstream. It was only ever supported by NaCl's GCC toolchain. There's still support for musl libc, which works with the more up-to-date LLVM-based NaCl and PNaCl toolchain.
Update as of 2017/05/30 the Chromium team announced the fate of PNaCl and tentative roadmap of WebAssembly features.
Here are some Native Client features which you haven't mentioned:
Out-of-process, which many consider a bug because it forces asynchronous communication. It allows guaranteed address space, which with 64-bit isn't much of an upside, and was critical to Native Client's double-sandbox design. WebAssembly doesn't have processes yet.
Has blocking to and from the JavaScript event loop, through postMessageAndAwaitResponse. Also seen as a bug by many.
Has many APIs through Pepper. Many mirror the web platform's APIs.
Can do memory protection through mprotect (though execute pages are limited).
POSIX signals can be handled.
Supports computed goto and other irreducible control flow.
Has some Just-in-Time code patching support.
Supports weaker than seq_cst atomics.
Has support for inline assembly, as long as it follows the NaCl validation rules.
Not all of these are in Portable Native Client, though. There's official documentation of differences.
There's no timeline for any of the post-MVP WebAssembly features. We don't want to rush anything, but we want to deliver one the most useful things first. It's a community group, so priorities are really driven by whoever gets involved. Implementations won't be able to tackle features all at once, but exploration parallelizes well.
I hoped to use sonarlint-cli (2.0) for pre-commit analysis of C++ with a remote SonarQube server (5.6.1), but when updating the binding and downloading analysis plugins, it tells me the cxx plugin (among others) is not compatible:
DEBUG: Plugin cxx is not compatible with SonarLint. Skip it.
This is the community C++ plugin (0.9.6).
I'm wondering about the compatibility rules for plugins with SonarLint, and about alternative pre-commit approaches.
According to SonarLint web site, the connected mode "will make SonarLint use the analyzers, quality profiles and settings defined on your SonarQube server." However, that is not entirely true.
SonarLint does not support the non-sonarqube analyzers. Thus, it does not support PMD, checkstyle, FindBugs, C++ community plugin, and others. So, even if these analyzers are defined on your SonarQube server and quality profiles, they will not be used.
You may ask why. In a google group discussion, it's said that SonarLint can only work perfectly and superfast if these other analyzers do not run.
I personally think that statement is detrimental to the developers of these other tools. The decision not to support third-party plugins is also problematic to organizations (like mine) that have invested a lot of time in polyglot static code analysis. Remember, for 5+ years many people have created custom checks and custom rules using checkstyle and PMD, for example. Back then, sonar (ergo sonarqube) did not offer an API for Java custom checks.
I'm worried that SonarQube might eventually drop support for all these external plugins altogether.
I'm working on upgrading our product's MySQL version. MySQL documentation states that Upgrades between milestone releases (or from a milestone release to a GA release) are not supported
I'm trying to determine if the version path we're traversing is not supported (5.5.30 to 5.6.26).
It isn't clear on their archived release page how to distinguish a GA from a milestone build. Is there a place with additional information about each release? If not how can I tell the difference?
Check the Release Notes.
Version 5.5.8 and all later versions are GA in MySQL Server 5.5.
Version 5.6.10 and later versions are GA in MySQL Server 5.6.
Non-GA releases are the versions prior to these, which shouldn't be used in production, because (among other reasons) there are sometimes breaking changes prior to GA. Once the series goes GA, these are not supposed to happen.
Note that there's a difference between "not supported" and "impossible." In MySQL compatibility parlance, "not supported" sometimes means "if you read and understand the release notes for each and every intermediate version, know exactly what you're doing, proceed deliberately, and take appropriate precautions, it might work just fine, but don't say we said it might work just fine, because we didn't say that." In other words, it's literally not supported in the sense that failures on such paths will not be considered to be something that merits a remedy or fix or workaround.
I'm having trouble finding older revisions of the HTML5 specification. I keep finding resources such as WHATWG's version, or HTML5 differences from HTML4 and my google-fu is failing me.
Is there a repo where I can browse different versions of the HTML5 spec, and (more importantly) compare different versions?
It depends on how far back you want to go, but for looking at earlier versions a couple of options spring to mind.
The latest version of the spec has a list of links to some previous drafts at the very start.
The other option is the Wayback Machine, but it seems it stopped indexing the pages mid-2011.
Don't know how you'd go about comparing them though. You might be better looking at the diff tracker although that's tracking changes on the WHATWG version.