There are tools like Fortify available which can be integrated with IDE to scan the source codes for security vulnerabilities. But what I expect is a plugin for IDE like eclipse, which should check for vulnerabilities while typing the code. (Probably, in case of a Java program, for every semi-colon(;) it should check for the vulnerability). It would be great if the tool recommends a fix on the go. So that the developer can fix the vulnerabilities as such fixing the compilation issues in eclipse. This would really reduce the developers' time a lot, when compared to running a full scan of the code, checking vulnerabilities, fixing those and scanning the entire code base again.
Is there any such product available in the market already? If not, is it a feasible one to develop such thing?
FindBugs can be made to work in a similar manner perhaps, I have set it to run every time I compile a new file and it warns about some interesting potential bugs. The only plugin I know of that runs as you type is Checkstyle so maybe there's a similar plugin that checks for security vulnerabilities?
Cigital.com They have a plugin that works in a 'spell checker' mode. As you type it will high light the vulnerability code. For example SQL injections, XSS and so in. It works very well and does not hog your machines resources like other plugins.
You can also check out Ounce Labs and Coverity...
Related
For past 4 years, I have been programming with Eclipse (for Java), and Visual Studio Express (for C#). The IDEs mentioned always seemed to provide every facility a programmer might ask for (related to programming, of course).
Lately I have been hearing about something called "build tools". I heard they're used almost in all kind of real world development. What are they exactly? What problems are they designed to solve? How come I never needed them in past four years? Are they kind of command-line stripped down IDEs?
What are build tools?
Build tools are programs that automate the creation of executable
applications from source code (e.g., .apk for an Android app). Building
incorporates compiling,linking and packaging the code into a usable or
executable form.
Basically build automation is the act of scripting or automating a
wide variety of tasks that software developers do in their day-to-day
activities like:
Downloading dependencies.
Compiling source code into binary code.
Packaging that binary code.
Running tests.
Deployment to production systems.
Why do we use build tools or build automation?
In small projects, developers will often manually invoke the build
process. This is not practical for larger projects, where it is very
hard to keep track of what needs to be built, in what sequence and
what dependencies there are in the building process. Using an
automation tool allows the build process to be more consistent.
Various build tools available(Naming only few):
For java - Ant,Maven,Gradle.
For .NET framework - NAnt
c# - MsBuild.
For further reading you can refer following links:
1.Build automation
2.List of build automation software
Thanks.
Build tools are tools to manage and organize your builds, and are very important in environments where there are many projects, especially if they are inter-connected. They serve to make sure that where various people are working on various projects, they don't break anything. And to make sure that when you make your changes, they don't break anything either.
The reason you have not heard of them before is that you have not been working in a commercial environment before. There is a whole lot of stuff that you have probably not encountered that you will within a commercial environments, especially if you work in software houses.
As others have said, you have been using them, however, you have not had to consider them, because you have probably been working in a different way to the usual commercial way of working.
Build tools are usually run on the command line, either inside an IDE or completely separate from it.
The idea is to separate the work of compiling and packaging your code from creation, debugging, etc.
A build tool can be run on the command or inside an IDE, both triggered by you. They can also be used by continuous integration tools after checking your code out of a repository and onto a clean build machine.
make was an early command tool used in *nix environments for building C/C++.
As a Java developer, the most popular build tools are Ant and Maven. Both can be run in IDEs like IntelliJ or Eclipse or NetBeans. They can also be used by continuous integration tools like Cruise Control or Hudson.
Build tools are generally to transform source code into binaries - it organize source code, set compile flags, manage dependencies... some of them also integrate with running unit test, doing static analysis, a generating documentation.
Eclipse or Visual Studio are also build systems (but more of an IDE), and for visual studio it is the underlying msbuild to parse visual studio project files under the hood.
The origin of all build systems seems like the famous 'make'.
There are build systems for different languages:
C++: make, cmake, premake
Java: ant+ivy, maven, gradle
C#: msbuild
Usually, build systems either using a propriety domain specific language (make, cmake), or xml (ant, maven, msbuild) to specify a build. The current trend is using a real scripting language to write build script, like lua for premake, and groovy for gradle, the advantage of using a scripting is it is much more flexible, and also allows you the to come up with a set of standard APIs(as build DSL).
These are different types of processes by which you can get your builds done.
1. Continuous Integration build: In this mainly developers check-in their code and right after their check-in a build initiates for building of the recent changes so we should know whether the changes done by the developer has worked or not right after the check-in is done. This is preferred for smaller projects or components of the projects. In case where multiple teams are associated with the project or there are a large no. of developers working on the same project this scenario becomes difficult to handle as if there are 'n' no. of check-in’s and the build fails at certain points it becomes highly difficult to trace whether all the breakage has occurred because of one issue or with multiple issues so if the older issues are not addressed properly than it becomes very difficult to trace down the later defects that occurred after that change. The main benefit of these builds is that we get to know whether a particular check-in is successful or not.
2. Gated check-in builds: In this type of check in a build is initiated right after the check in is done keeping the changes in a shelve sets. In this case if the build succeeds than the shelve-set check-in gets committed otherwise it will not be committed to the Team Foundation Server. This gives a slightly better picture from the continuous integration build as only the successful check-in's are allowed to get committed.
3. Nightly builds: This is also referred as Scheduled builds. In this case we schedule the builds to run for a specific time in order to build the changes. All the previous uncommitted changes from the last build are built during this build process. This is practiced when we want to check in multiple times but do not want a build every time we check in our code so we can have a fixed time or period in which we can initiate the build for building of the checked-in code.
The more details about these builds can be found at the below location.
Gated-check in Builds
Continuous Integration Builds
Nightly Builds
Build Process is a Process of compiling your source code for any errors using some build tools and creating builds(which are executable versions of the project). We(mainly developers) do some modifications in the source code and check-in that code for the build process to happen. After the build process it gives two results :
1. Either build PASSES and you get an executable version of your project(Build is ready).
2. It fails and you get certain errors and build is not created.
There are different types of build process like :
1. Nightly Build
2. gated Build
3. Continuous integration build etc.
Build tools help and automates the process of creating builds.
*So in Short Build is a Version of Software in pre-release format used by the Developer or Development team to gain confidence for the final result of their Product by continuously monitoring their Product and solving any issues early during the development process.*
You have been using them - IDE is a build tool. For the command line you can use things like make.
People use command line tools for things like a nightly build - so in the morning with a hangover the programmer has realised that the code that he has been fiddling with with the latest builds of the libraries does not work!
"...it is very hard to keep track of what needs to be built" - Build tools does not help with that all. You need to know what you want to build. (Quoted from Ritesh Gun's answer)
"I heard they're used almost in all kind of real-world development" - For some reason, software developers like to work in large companies. They seem to have more unclear work directives for every individual working there.
"How come I never needed them in past four years". Probably because you are a skilled programmer.
Pseudo, meta. I think build tools do not provide any really real benefit at all. It is just there to add a sense of security arising from bad company practices, lack of direction - bad software architectural leadership leading to bad actual knowledge of the project. You should never have to use build tools(for testing) in your project. To do random testing with a lack of knowledge of the software project does not give any sort of help at all.
You should never ever add something to a project without knowing it's purpose, and how it will work with the other components. Components can be functional separate, but not work together. (This is the responsibility of the software architect I assume).
What if 4-5 components are added into the project. You add a 6th component. Together with the first added component, it might screw up everything. No automatic would help to detect that.
There is no shortcut other than to think think think.
Then there is the auto download from repositories. Why would you ever want to do that? You need to know what you download, what you add to the project. How do you detect changes in versions of the repositories? You need to know. You can't "auto" anything.
What if we were to test bicycles and baby transports blindfolded with a stick and just randomly hit around with it. That seems to be the idea of build tool testing.
I'm sorry there are no shortcut
https://en.wikipedia.org/wiki/Scientific_method
and
https://en.wikipedia.org/wiki/Analysis
I am fairly new to Eclipse and have recently setup the IDE using the base installation. I am mostly working on java projects that use a Spring, Maven and of course all the files that come with a website. I installed several plugins to handle color coding for JS, CSS, JSP and tag files. My IDE now slows down quite a bit after about 2 hours of using it. It's really frustrating having to restart it or suffer slow load times when opening or switching files. I want to know what a good base installation of Eclipse that would include things like color coding for basic files used on the web like javascript, css, xml etc...
If these requirements can't be achieved with a default installation, what should I start with as my base and what plugins are some great stable ones to get for what I require?
Less of an answer, more of a comment.
Eclipse has some performance issues, especially with a lot of plugins running. The web tools project in particular has issues where it appears to re-parse XML files on a ridiculous frequency which causes some serious slowdown.
However, it is still my IDE of choice for Java Web/EE applications. Some quick fixes are:
Upgrade to Eclipse 4--there's no reason not to if you're starting out, it is much faster.
Turn off "Automatic building"
Install it on a RAM drive/SSD so your file-hits move more quickly (the RAM drive, as a bonus, starts clean)
Run it with -clean every once in a while and ditch your local file history
Keep a minimum set of files open.
My general problems are when editing JSF/XML files due to the validation running constantly. Turning off automatic building minimized this.
As to Netbeans...
Netbeans I find to be very sluggish when dealing with EE projects and less intuitive. This might just be personal preference, but in my experience Eclipse makes building and dealing with web projects less of a headache. Additionally the UI feels far more sluggish than Eclipse when dealing with anything substantial. It is faster in some areas and slower in others--basically a wash in productivity in my books (the last time I seriously used it was late 2011 so there might be some improvements I'm unaware of).
Also, make sure you're setting up your servers so that you're not rebuilding from scratch and you're taking advantage of native "hot-code replacement" while debugging or JRebel if you want to spend a bit of cash. It really makes a difference. Additionally "JBoss tools" off the marketplace might be of interest. Some of those plugins are rather helpful.
Lastly
I reboot at my coffee breaks--it really isn't that big a deal in my workflow. It might be a bigger deal in yours.
Few suggestions:
disable "automatically build" in "project"'s menu.
use the latest Eclipse
use the latest JDK for launching eclipse (edit eclispe.ini)
configuring the eclipse.ini (see this question for a complete eclipse.ini). Increase the heap values over there.
I am new to Eclipse plugin development.
I have been modifying a plugin that was used in our team, and i don't want to add new bottle-necks.
Also the eclipse to which i am integrating to is taking too much time to install the plugin. any suggestion on how to identify the reason for that?
So i would like to know some tips on
How to check performance of a plugin - any tools that are available. (like jprofiler in java or any other performance analyser tool)
How to check for bottleneck in my plugin code using some tools.
And is there a doc that tell the do's and don't of the plugin development.
Examining performance of a plugin isnt that much different from any ordinary java program. It works in similar ways. Look at this question for example.
It takes long to install; It seem like that would be an issue of the underlaying program, P2, rather than your plugin. At installation of a plugin your manifest is read, some information about your extensions are saved in Eclipse. The actual plugin is copied. Dependencies checked. It seems like these things shouldn't take that long, unless you have a very large plugin?
Perhaps you are installing the plugin into an environment that already have alot of plugin? Try downloading a clean Eclipse, do you have the same issue there?
Make sure you don't set your plugin to start automatically when the user starts Eclipse. That is bad behaviour that causes clutter and general slowdown for the users. The plugin should be started when the user actually wants to use it, not a second before.
Also my answer to this question might help with the general design of the plugin.
First of all, measure everything, as you should never try to optimize just by guessing performance bottlenecks. I recommend Yourkit for all Java code (Eclipse plugins as well as plain Java code).
The second important thing: If you have functionality that takes more time than the twinkling of an eye, make it a job in Eclipse, so it can run in the background. It is fine for something to run some seconds, if it does not stop the user from working.
Can anybody point me to Netbeans plugins that help do better code?
I hope to find some plugins that do Java code review and search for:
bug patters
duplicate code
and other types of vulnerabilities.
Thanks!
Install EasyPMD from the plugin portal. http://plugins.netbeans.org/plugin/33246/easypmd-2-1
How about Findbugs.
Never used it with Netbeans (only with HudsonBuilder), but some Google results state that there is a plugin for NB.
Several of the PMD and Findbugs rules (suggested by others) are already part of the regular "Hints" of Netbeans. By enabling more than the standard set of hints, you can already get some good "programming advices" without having to install anything.
(But they are by no means a complete replacement for PMD or Findbugs)
There is an article about integrating plugins you could try to follow that (I haven't yet), but from my experience sadly in IDE tools never work as well as the commandline versions.
I would recommend you instead use Maven as your build tool and add the Cobertura, FindBugs, PMD, and CheckStyle plugins that will produce reports whenever you compile your code. Not as handy, but you will still get good feedback.
Also, this means that they will be equally available for people working on your code base with other IDEs. If you use a continuous integration server like Jenkins and it will create a report using any tool you'd like whenever you check-in code.
And this is speaking as someone who prefers NetBeans over Eclipse.
Over the past year, I've heard an increasing amount of hype regarding the Scala language. I know that there are several existing projects that have plans to integrate Scala support with IDEs; however, it isn't always clear how good the integration really is.
Do they currently support Intellisense as well as Eclipse and Netbeans do for the Java language? Do they support instant verification as well?
I can't personally speak to the stability of the IntelliJ or NetBeans plugins (though I have heard good things), but the Scala IDE for Eclipse just recently made a new release with Scala 2.7.4. Architecturally, this release is quite different from the previous ones in that it uses Equinox Aspects, the officially supported mechanism for extending JDT (and other cross-plugin extensions). Whereas before the Scala plugin had to literally hack into the JDT internals using private APIs and reflection to trick the system into behaving properly, now it is able to simply declare its extension points and let the system do the rest. It's hard to even describe how much more stable this makes things. I'm not saying that it's all sunshine and roses yet, but if you've tried and rejected the plugin in the past (as I had), it's time to give it another look.
As for how it stacks up feature-wise, SDT doesn't have any refactoring support (IntelliJ has some basic stuff like "Rename"), nor does the editor do some things like "Mark Occurrences". However, it has a significantly better Outline than NetBeans, better compiler support than IDEA, and very good semantic highlighting. All three plugins support content assist (or "intellisense", as Microsoft calls it), but none of them are particularly reliable in this area just yet. The Scala IDE for Eclipse is the only one to support incremental compilation (alla Eclipse's Java tooling).
My advice: shop around. Try all three and see which one works the best for you. From what I've been hearing, the Scala IDE for Eclipse has leap-frogged the competition with its latest release, but the others have shown such consistent stability and steady advancement that you can't count them out just yet.
Here's a similar question:
Which is the best IDE for Scala development?
In my very short experience with the Scala IDE for Eclipse and the Scala Plugin for Netbeans, it seemed like the Netbeans plug-in was a little more solid than the Eclipse one.
With the Scala IDE for Eclipse I was having problems with running a Hello World-type Scala object, and sometimes the syntax highlighting would start acting up. Then, I tried out the Netbeans plug-in, and it seemed to be more functional than the Eclipse one.
I haven't used either Scala IDE plug-in much in-depth, so I can't speak out of a lot of experience, but just from my initial impression, the Netbeans plug-in seemed a little bit more stable than the Eclipse one.
Currently, all three main IDEs are at roughly the same level of support.
IntelliJ - the plugin has fits of not working at all, but is otherwise quite good. The underlying platform is sluggish (at least in linux) since v8.
Eclipse - the plugin is receiving a lot of support and is under very active development.
NetBeans - IMHO, the plugin works a little better than the Eclipse one, but not being able to run arbitrary files is a major downer.
All of the above suffer from being unable to parse the AST in all contexts. It is quite easy to confuse them by mixing in traits with implicit defs, for example. No IDE can be trusted when it advises of a syntax error. Fall back to the compiler to be certain.
I'm quite happy using IntelliJ IDEA 8.1 and its Scala plugin and can recommend it. It even has a roadmap that you can influence by voting your favorite missing features :) I don't have experience with the Scala support of the other IDE's, unfortunately.
I'm using the Eclipse Scala plugin. Its pretty good but not at the same level as the Java tooling.
AS for intelliJ, no idea.
But between Eclipse and Netbeans, I must say Netbeans especially if you are not willing trade maven for sbt and you want an IDE that does not get in the way of maven.
Netbeans maven support is just way too good.
The Netbeans scala editor seems to work quite nicely as well.
I care not for the integrated scala development kit in netbeans or the compiler plugin, or any such helpers. From netbeans I expect only tthree things:
(a) Do not get in the way of maven and let maven run my build
(b) Give me a decent editor
(c) Let me drill down from my .scala files into the source code of the libraries referred by my maven dependencies.
And Netebeans is able to deliver all three quite well, I belive, even if at times it feels a bit too slow.
What I can say is that
(1) You do not run into any compilation issues since the task is up to maven.
The maven compiler plugin is a bit too slow. But compiling scala vs java is always like that, painful. Still if you've tried GWT compiling java to javascript is more painful even.
(2) Netbeans figures out the source code to you maven dependencies flawlessly and you can drill in into the most obscure sacala operators, such as the CSS mappers of lift.
As for eclipse, eclipse maven integration has always been nasty.
Netbeans maven integration can turn very sour if you have a big project with too many dependencies and modules. Then the check for external changes done by netbeans is just horribly slow. That is the downside of netbeans.
However, if you are and SBT fan ... well, maybe then answer might be something else.
But for me, since maven has become the thing it is today, I never want to go back again to those "web application project", "library project" etc... wizard like options that you have when you create a new project in the IDE.
I simply want "maven project", and please figure out what my output artefact is by reading the pom.