I'm wondering how to get complexity metrics for my JS functions.
I've tried to run the package against my application, but had only several code style warnings. I'm pretty confident I should be warned about complexity in several cases.
Is there a special flag for this feature?
https://www.npmjs.com/package/sonarjs only returns issues, no metrics (use SonarQube for metrics).
While there are as well rules for complexity, unfortunately they are not activated and there is no way to activate them yet (here is the list of activated rules).
Welcome to create an issue for the feature https://github.com/SonarSource/sonarjs-cli/issues/new
Related
Since Laravel 5.4, the default method to compile assets is using Laravel Mix, instead of elixir.
I know that "Mix" uses WebPack by default to compile the assets.
What benefits does this method bring?
The Mix also allows you to compile without WebPack, and this always
produces files that are smaller in size and work the same.
This is entirely incorrect. Have you attempted to configure any of the myriad options to optimize your bundle at all?
Start with the webpack-bundle-analyzer plugin. This will give you an idea where your bloat is, what is duplicated, and where to start trimming your application.
Between uglifying, chunking, deduplification, minification, etc. you'll have in the end compiled resources that are far from "large".
Now I'll grant you it has a steep learning curve comparative to other tools, regardless, WebPack is an incredibly powerful tool, you need to take the time to learn it's configuration capabilities.
Care to elaborate on what you mean by working the same? I run several production applications as well as a number of smaller personal projects. I never seem to get different results after each build.
But in the end it's just a tool. A tool like any other tool, you use what you feel comfortable with and what fits for the job. There's a reason it as selected as the default, though. And it isn't because the maintainers are ignorant by any means.
I'm trying to set up a working ruby project with guard-rspec.
I've mixed together the general method of a tutsplus tutorial with some new syntax as described in the RSpec videos and another post. The project can be found in the stack-overflow-question branch on github.
I'm also trying to practice namespacing as described in Programming Ruby 1.9. So eventually I'd like to have example.rb in my lib/example/ directory.
There's 4 questions I have about my project:
What do I need to put in my Guardfile to watch specific directories in my project for changes? I've several different ways which can be seen in my Guardfile as comments labelled like:
# Watch Specific Directory Attempt X
What is the difference between uncommenting lines 8 and 9 in my Guardfile (bellow Uncomment and set this to only include directories you want to watch) and adding "named group captures" like watch(%r{^lib/(?<path>.+)\.rb$}) { |m| "spec/lib/#{m[:path]}_spec.rb" } as described here
Where do I need to put the --clear option to make it persistent? I know I can run it with my binstub like bin/guard --clear and I've tried putting that in my Guardfile however it didn't work.
Are there any glaring convention, syntax, or clarity mistakes that you see in my project? I feel like I'm duck taping this whole thing together and I'd appreciate some guidance in piecing this thing together in a sensible way.
I'll answer the question in the title and cover the "sub-questions" as I go.
The best way to set up a project (as of now) is to use bundle exec guard --init rspec. This should give reasonable defaults to start work immediately. It's not perfect, but there is a lot of work planed to improve things, so do ask questions on GitHub instead (makes more sense).
Guard has to maintain backward compatibility, so there are some "non-intuitive" things for now and skimming through all the docs first (and wiki) is a good investment to quickly know what's available and where. Asking when confused or in doubt is also a good idea (one issue per question is best).
Guard uses a DSL to simplify setting up listeners. This is a bit non-intuitive and clunky at times, but it does help organize actions into groups, which can help maintain complex workflows. The DSL's command for e.g. clearing the terminal automatically is: (clearing: on). (This answers question 3).
There are all kinds of uses and scenarios, so Guard tries hard to make everyone happy and on every platform too. Guard uses Listen, which watches directories recursively (due to restrictions on OSX mostly). This usually isn't a problem, but for huge directions on OSX this can be very, very slow. That's why Guard lets you select which top directories to watch (like 'lib', 'app', etc.). Watching the whole project directory is very convenient, so that is still the default. More info on this is at the Listen project. So by default all directories (:directories statement) are "physically watched" (take up operating resources), though in Guard you only configure which changes you want to respond to (which is what watch statements do).
The words chosen are a bit misleading at times. E.g. watch in the DSL actually means: "out of all the changes happening, select changes matching ...". The block passed to watch is given the results of the match. That block should return a list of files for the current guard plugin to run. So "watch" probably is more misleading than helpful. "match" would probably be a better choice and it might replace "watch" in the future.
The guard-rspec project runs RSpec on changed files. You can see the exact RSpec commands if you run guard with the debugging option on, e.g. bundle exec guard -d. To simplify setup, Guard::RSpec uses a DSL that should work out-of-the-box if your project follows a given setup. E.g. dsl.watch_spec_files_for(ruby.lib_files) is defined here: so it pretty much already should do what you want if you put all your tested source files in lib. For other folders, you can add your own. E.g. Rails projects typically have sources also in an app directory, so in the default Guard::RSpec template there's an statement: dsl.watch_spec_files_for(rails.app_files) with the pattern defined as: rails.app_files = %r{^app/(.+)\.rb$} If you have a typical case that isn't covered, open an issue in that project. (covers question 2).
Everything looks fine in the example project and suggestions are mostly based on taste or preference. E.g.
Instead of let (:greeter) { Example::RSpecGreeter.new }, I'd use RSpec's implicit subject (but some may argue that it's less explicit and less readable)
if you're testing Example::RSpecGreeter, I'd recommend putting that class in a separate file and including it instead (require 'example/rspec_greeter')
you might add RubCop/Guard::RuboCop for detecting convention issues (covers 4th question)
you might want to check out Guard's own Guardfile used to test itself for a more "real-life" setup without the documentation clutter.
for best results I think it's best to copy a whole existing project and rename the parts you want to change. Usually there are many hours spent still fine-tuning things like alternate RSpec configs for Travis, special gem release tasks, certain workarounds and conveniences, etc.
I know that the 5.0 release note say "After the migration, source syntax-highlighting won't be available on a project until it has been successfully analyzed"
BUT, i can't imagine that there is no way to activate just by running another analysis. In fact, when you have thousands of components (it's our case), you can't plan 4500 analysis just to "restore" a basic but helpful functionality ! And it's more true when you know that the majority of theses components wasn't changed since a time ago... :(
So, please, say me that we can write a little batch or program that will do the job without need to pull all the sources ! I don't know how because i don't' understand this limitation of this upgrade (why sources aren't accessible)
You should trust the release notes. Information required for syntax highlighting is computed during analysis. Note that it also requires the language plugins to support this feature. I suggest to upgrade them to latest versions.
I've written a program that runs perfectly in Dart but fails to run in the transpiled Javascript version. I suspect it's an infinite loop (because CPU usage goes up). Has anybody experienced such a behavior before? Maybe even more important, how can I find out the problem?
Yes; this is a big part of my day job.
First, understand that you are most likely dealing with a dart2js bug, not a bug in your code. Your immediate goal is to work around the problem. The end goal, though, is to construct a small test case that you can file on dartbug.com.
Checked mode is your friend
If you are really lucky, enabling checked mode will throw an assertion that will point to the problem. If not, you'll need to dig into the JS.
Using pub serve or pub build --mode=debug will give you more readable code. I usually set my pubspec.yaml up like so:
transformers:
- $dart2js:
minify: false
checked: true
(or checked=false if I'm chasing a performance issue). Then running pub build (without any arguments) will produce to desired output.
Produce a smaller use-case
If you can get Angular out of the mix, the Dart Team will have a much easier time debugging. Failing that, generate a AngularDart application that shows the error on page load.
Print statements
Adding print statements in Dart help you understand the execution flow, but also make it easy to search the dart2js output for good places to add breakpoints.
I find that source maps only confuse things and always disable them.
git bisect
Once you have a small enough use-case that triggers on page load, using git bisect to search your history for the breaking change is quick and impresses your friends.
Dart can generate source maps since a while which makes it quite easy to debug generated JS.
With source maps the browsers show Dart code and stack traces when debugging built JS code.
Source maps need to be enabled in the browser (see https://www.dartlang.org/tools/dart2js/ for details) and in the $dart2js transformer (see https://www.dartlang.org/tools/pub/dart2js-transformer.html for details)
You can get readable JavaScript by running dart2js in debug mode. If you are using pub build you need to use pub build --mode=debug.
Are there any useful plugins for source code metrics for Hudson/Jenkins?
I'm looking for total lines of code, total number of tests, classes, etc. with graphing.
Does anything like this exist?
Are you using Java? If so, SONAR should certainly be your first port of call. It does a lot on it's own and also wraps up all the major Java analysis tools, such as:
Out of the box, you'll get metrics on:
Potential Architectural & Design issues
Unit test coverage (uses cobertura)
Lines of code\packages\classes etc
Potential bugs
Code duplication
Adherence to code formatting standards
(plus many more)
It allows you to traverse from the high level analysis through to the source code it relates to. It will be easier if you're using Maven for your build though...
There is a Hudson plugin. And it's free.
Try CCCC (http://sourceforge.net/projects/cccc/). It does code counting, module counting (classes), etc., and the plugin also graphs it for you. (for C, C++)
Incidently, what language are you looking at?
There's also CLOC (Count lines of Code) which will tell you how many lines of each language you have, although I can't seem to find a link for it.
You don't specify which language you are using, but Redsolo's awesome blog post Guide to building .NET projects using Hudson shows you how to use FxCop and NUnit on Hudson to give some of what you are looking for. The Violations plugin used also supports Simian, CPD, PMD and PyLint.