My team and I are developing a Dash application and I'm currently thinking about how to run functional tests. So far, we have some pytest code in place that uses selenium to basically click a download button and check that the result is as expected. Now I'm facing the issue that our apps has an abundance of Plotly graphs and I'd like to test their contents. To summarize, what are the tools we can employ to follow best practices and/or industry standards? The dash[testing] documentation seems to indicate that automated visual testing would be the right thing to do, 1) we can't employ services like Percy because we have to develop on-premises and 2) I'm struggling a bit with the idea of visual testing itself, in particular having to drag around binary image files as part of my testing environment.
So, I'm working on a big data project which requires importing data into Visual Studio and using Microsoft's R packages, in particular, the RevoScaleR packages. So, this is all well and good. I've written my scripts. What I would like to do is set it up so an end-user (who doesn't know anything about programming or R) can enter a set of parameters/values into my predict() function and see the output on his/her screen through a web interface or GUI/similar.
Any suggestions?
Thanks.
You can achieve this by leveraging Microsoft R Server's Operationalization Features, as this is a general question, please see the guides here:
https://msdn.microsoft.com/en-us/microsoft-r/operationalize/quickstart-publish-web-service
Gendarme and FxCop look very similar and seem to tackle the same problem. Which would you suggest for a small team of developers (3-5) mainly working on web application with lots of business logic? Why?
Gendarme is indeed the Mono equivalent of FxCop. Given that Microsoft is planning to ship a considerable set of Code Analysis rules with most versions of the next Visual Studio, you might want to use FxCop and stick with that. The integrated version of FxCop (called Code Analysis) is the simplest to use if your Visual Studio version supports it (Visual Studio 2010 Premium and Ultimate).
There is a Visual Studio add-in which allows you to run FxCop from inside Visual Studio Professional as well. You need to download FxCop 10 separately (it's part of the Windows Platform SDK). Do note that the Visual Studio integrated version comes with a few additional rules, so the output may differ.
As Gendarme doesn't integrate directly into Visual Studio (though you can make it part of the build process) and you won't see many people using Visual Studio use Gendarme. Mostly because it isn't too well known.
In the end I'd use FxCop from a convenience perspective. It's integrated into the version of Visual Studio I use by default and it's well known in the developer community.
But if you're not using Visual Studio Premium or Ultimate, then you can pick either or even both. Just keep in mind that if you choose both, you'll probably be receiving a number of duplicate messages or even conflicting messages as the creators of these different tools don't always agree.
If you don't mind investing some money, then, as niaher suggests, Resharper or Coderush are very useful additions (I wouldn't call them replacements, as they don't run outside of the IDE (in the continuous integration build for example)) as they provide direct feedback as you're writing the code. Often even without having to compile it. And they often provide the ability to "apply the fix" without you having to figure out exactly what to do.
An alternative or a good complement to FxCop/Gendarme would be to use the commercial tool NDepend. With this tool one can write Code Rule over LINQ Queries (namely CQLinq). Disclaimer: I am one of the developers of the tool
More than 200 code rules are proposed by default, these include design, architecture, code quality, code evolution, naming conventions, dead code, .NET Fx usage...
CQLinq is dedicated to write code rules that can be verified live in Visual Studio, or that can be verified during build process and reported in an HTML/javascript report.
The strength of CQLinq over FxCop or Gendarme, is that it is straightforward to write a code rule, and get immediately results. Facilities are proposed to browse matched code elements. Concretely this looks like that:
we are making an application to run on both Mono and .Net. The application is web based, so it uses ASP.Net.
We are now trying to find some kind of reporting software. We would prefer if there was a designer that end users(non-programmers) would be able to use like Crystal Reports.
Currently, we are not finding anything that looks even barely capable. We will have shell access on the server that Mono is running from, so it doesn't matter if there is no true web-preview or something as long as it's capable of creating a PDF on the server in an automated way.
Has anyone seen any competent report writing software that runs on Mono? (Also, licensing doesn't matter as long as it's not GPL)
edit:
Really, even running something that isn't Mono such as PHP or something else light on dependencies would be ok as long as it would run on *nix systems. I just am having trouble finding anything for non-windows systems for the server and Windows systems for the designer(this is the justification for the linux tag)
We've finally found a reporting solution. It's not quite as pretty as Crystal or something like that, but it works, and that's what counts.
It is called FlexCel.Net http://www.tmssoftware.com/site/flexcelnet.asp
You basically design reports in Excel using special markup(actually, you can even design reports in OpenOffice cause thats what I had to do cause there is something wrong with Excel licensing for me)
It's pretty powerful and cheap, about $200 USD. I have already gotten a demo to run on Mono after about 5 hours of tinking and trying to understand how the demos worked. It's pretty neat though and well put together from what I've seen.. I'll come back and edit this answer if we later decide that this software is not good and we don't recommend it.
They commercially support running their software on Mono(except for the Winforms portions) and you also get full source code, so it really is a good deal. The range name = reporting band is a bit strange in the template, but it's still seeming better the more we use it.
Have a look at itextsharp
Your users can create PDF documents with fields, and then you can use the itextsharp library to populate it.
One thing I have been looking at recently is Jasper reports. Its just like Crystal Reports, and with JasperServer users can connect to it using the iReport editor. The hurdle I have is getting it to play nice with Mono See Running report on JasperServer from C#
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As recently as several years ago, the developers actually made the builds that went to clients. This was obviously a disaster for reasons too numerous to list.
Then when we started to learn the errors of our ways, we looked for a way to auto-build the entire application on a dedicated build machine. The culture at that time was very averse to bringing in outside tools, so we built our own autobuild system by writing a VB app.
This worked fine for a while, until the project's structure started to change, new projects were added, and we needed to build the application in different ways. Then then weaknesses of our hand-rolled autobuilder became apparent and, over time, increasingly onerous. This disease has progressed now to the point where QA (who owns our build process) can't even maintain the autobuilder because it requires more and more programming skill. Every time we add a project or change something in an existing project, it consumes more developer time just to make it work. There have been days when we were unable to produce a build because the system was broken.
I'm now in a position where I can change this process, and I'm looking to scrap the entire system and put something else in it's place. My goals are:
Have an autobuild system that can run with zero human interaction at a specific time every day. It should be able to gather all the source code, compile all the apps, create the setups, put the finished products on a network share, and possibly trigger the automated testing system to kick in (we use QTP).
The autobuild system should be flexible enough to easily adapt to changes in the project without rrequiring a major overhaul.
It should be simple enough so that QA can own the system and not require developer resources to make changes to how builds are made.
What are your experiences? Can you recommend an autobuild system? Should I have different goals?
I'm currently using CruiseControl integrated with Ant to control project builds. This allows flexibility of build schedules and means you can automate the entire build process fairly easily using Ant scripts. Also, during defect fixing periods you can have CruiseControl set up to watch for source control submissions instead of time periods and build when these occur. This allows developers very quick feedback on defect fixes.
I use FinalBuilder and FinalBuilder Server for nightly builds. It's a bit buggy at times, but if you think it through it's quite easy to create extensible projects that can build X project type, build it's database from change scripts and deploy it to a testing server.
It can also handle all kinds of wierd and wonderful things like ZIPing a nightly build and uploading it to an FTP or creating ISO images automatically.
Definitely look into MSBuild if you're on the Microsoft stack.
Joel is always going on and on about how great FinalBuilder is, so that might be worth a look as well.
We just migrated from a hand-rolled set of Perl scripts to a Buildbot setup. I found it because that's what Google's using for Chrome.
You can do nightlies, or it can integrate with source control to do an isolated test build whenever anybody does a checkin, or a variety of other things. It's also parallel; you can have more than one machine in the build farm, either for specialized duties or just to handle more load.
The entire system is written in Python, so it's platform-agnostic, which is important if you need to do builds on more than one platform. It can do anything you can do from the command line; we have it calling MSBuild for user-mode components, a DDK build for kernel-mode pieces, and running products for unit test builds.
Out of the box it supports most OSS source control tools, but if you're using TFS or something else you may need to modify the package that you install on the slave machines.
I think you are on the right track here.
Whoever looks after your automated build process needs to have a fundamental understanding of how your solution fits together. This doesn't necessarily mean knowing how to write code or architect solutions, but they will require a solid understanding of how the solution compiles, packages itself etc.
You might need to share responsibility for builds between people or teams to accomplish this. I'd say that a daily build is a "team responsibility".
I'd look at establishing a baseline build configuration which can be extended for "special use" builds (besides just building a release version), e.g. internationalized releases, fxCop/Quality Tools config, build + run Unit Tests, continuous integration builds, a build config to run on developer workstations, etc.
Instead, I'd aim to achieve the following:
Automatic versioning, signing etc
Ability to produce verbose output (logging) to help debug build breaks
On that point - it should handle errors properly, capture as much information and log it properly
Consistency - It should work the same way each time to produce repeatable outcomes
Run in a clean, limited access environment
Well commented/documented so that it can be understood by new staff, etc.
Option to generate release notes, compile metrics, produce reports (if this option is available)
Ability to deploy to multiple environments
Support different ways to obtain source code from source control, e.g. by changeset, label, date, etc
As for tool recommendations, I've used FinalBuilder, Visual Build Pro, MSBuild/Team Build, nAnt, CruiseControl and CIFactory plus and good old fashioned batch files.
Each has its pros and cons, I'm not going to make a recommendation except to say that the products with decent UI support were a little bit easier to work with, but at times were far less powerful. If you're working with VIsual Studio, MSBuild is very powerful, but has a somewhat steep learning curve.
As of tools delivered with MS Visual Studio you might want to use MSBuild. Additional Community toolsets for MSBuild will even give you the possibility to checkout code from Subversion and zip output.
We're using it successfully in our company. Projects consists of several solutions with 100+ subprojects. Works like a charm.
Visual Build Pro is nice, if your build machines are Windows. I think this would fill the requirement you have about QA owning the system. But don't get me wrong, it's pretty powerful.
We use CruiseControl.NET and UppercuT (which uses NAnt) to do this. UppercuT uses conventions for building so it makes it really easy for someone to get started by answering three questions (What is the solution named? What is the path to source control? What is your company's name?) and you are building.
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
We use the Hudson buildbot for for big Java web app building from ant build scripts. Hudson is pretty sweet for our purposes. It has a master/slave setup so builds can be done concurrently (on a timer or on-demand). Slave nodes can be any OS/hardware combo provided it has the needed build tools already on it and is on the network (and won't crash every 10 min).
Full web-based interface including live console output, change logs, artifacts from the build are available across the network including previous builds (if successful). Awesomesauce!