I've purchased CodeKit a while ago, it makes front end projects really easy to setup.
The problem is, I'm in what I call a 'Front-end tool hell'
I've checked out Grunt and Yeoman a while back, and I don't see the point of using these tools if I'm using CodeKit. Am I missing a point?
Short answer: No. You don't miss anything
Longer answer: All of those tools (maybe with the exception of Yeoman) tackle the same thing, but from completely different directions.
Codekit is great to start, because it's like a Swiss army knife of tools, where you actually don't have to do that much work to get it going. Easy to configure and totally easy to use, especially if you don't have any command line experience.
If you want to have things more flexible and you need maybe more than the provided tasks (running a server, creating proxy connections, FTP uploads, having tools included which CodeKit misses); or if you simply need to integrate your builds in continuous integration environments, you will most likely end up with a command line build tool, and also most likely with Grunt. Grunt's biggest strength is in having multiple configurations for different environments. So if you want to have the same code compiled in different ways for different destinations, that works wonderfully with Grunt.
If Grunt can't offer you more than CodeKit, fine, stick with CodeKit!
Grunt has also its limitations, especially in terms of execution time and intermediate file results. That's because in Grunt you take a defined process and configure it. Gulp on the other hand allows you to define the process itself, thus making it even more flexible.
Oh, and concerning Yeoman: If you have a basic setup and like it, write a Yeoman generator and easily scaffold new ones by the push of a button. Or, if you are new to things like, let's say Angular, take a community generator and see what the pros think it's best for such an application. I'm not sure if CodeKit can do "project templates" by now, but that's the idea behind it.
Hope this helped.
I'm curious if anyone else has a good recommendation for a Qt friendly toolchain.
We're currently evaluating using The following:
Bug/Issue Tracking - Atlassian JIRA (already in use)
IDE - Qt Creator (already in use)
Code Coverage - gcov (are there easy ways to integrate this into the dev/CI environment?)
Unit Testing - QTestLib and Boost Test
Code Review - Either Atlassian Crucible (expensive) or ReviewBoard (free)
Nightly build/check-in build - Hudson, CruisControl or Atlassian Bamboo. Any advice?
Code Analysis/Style Checker - Vera++? CppCheck? Any suggestions?
Source Code monitoring - Atlassian Fisheye (only if we go with Crucible), ViewVC. Any advice?
Are there any other tools I should take a look at?
Thanks!
Bugs: Bugzilla
IDE: QtCreator but many people will hate you if you enforce the use of one ide over the other, specially if you have opensource developers.
Code Coverage: In order to use gcov for code coverage, your ci environment needs to build the software with appropriate set of flags and execute the code. Also do note that gcov itself does not do any reporting, you need something like lcov to then actually generate the statistics from gcov generated files.
NightlyBuilds: TeamCity, but if you have time to invest and you do want flexbility: BuildBot.
CodeReview: Review board is quite good.
A .pro based build framework will allow your developers to use their own preferred IDE
AQtime is a decent profiler and leak checker
SourceMonitor provides some nice metrics
I've been leading rather large project that strives to "Mavenize" various testing apps produced by the engineering tools group over past 5+ years to test and optimize our home-built database. So far our group managed to successfully retrofit (beside obvious Java) few Coldfusion-based apps, PHP app, large .NET app with about 30 modules and currently working on roughly 40 C/C++ apps. Actually, once you abstract yourself from Java-centric nature of Maven and throw in few useful plugins such as antrun, exec, assembler and resource you can pretty much figure out way of "Mavenizing" just about anything.
So my question is - are there people who had this sort of experience - using Maven to manage non-Java projects? What was it? What language/technology? What did you end up using? How? Were you successful? And if not - what did you end up using as alternative?
Conceptually, Maven is not Java centric but Java is monopolizing most efforts as written on Wikipedia:
Theoretically, [Maven's plugin-based architecture] would allow anyone to write plugins to interface with build tools (compilers, unit test tools, etc.) for any other language. In reality, support and use for languages other than Java has been minimal.
Having that said, I don't have any personal experience of maven with something else than Java. But I can suggest to check out Maven for other languages? :)
We're using Maven to build a Flex application, and it's working quite nicely :).
I have used maven for generating documentation based on LaTeX source files. Using exec and some wrapper scripts, I can create PDF files and handle SCM releases.
One of the PDF files generated is included in a web app by letting maven package it into a jar file, which is referenced from the web app as a regular dependency. The web app can then access the PDF file on the class path.
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!
I recently discovered the org-mode in emacs and it works very well for me. I also like www.RememberTheMilk.com. I would like to be able to sync my org-mode file and RTM list. I know that RTM has its API exposed as web services. I am currently looking for a HTTP library that I could use to write my script. I found a couple of links but I am still not entirely satisfied.
http://www.koders.com/lisp/fidB46CCCA8D57FBD093BAF6E08289CFB4DA7624B2B.aspx?s=TV+Raman
http://www.emacswiki.org/cgi-bin/wiki/http-post-simple.el
Any pointers in doing web service interactions with emacs would be very useful. Also please keep in mind that I'm not a seasoned emacs expert. I have broken the initial barriers of emacs and can find my way around elisp. So, be gentle. :-)
Emacs ships with url.el and url-http.el. Although http-get.el, http-post.el and http-cookies.el are in vogue today. Here's the GitHub link where you can get it from.
http://github.com/wfarr/dotfiles/tree/master/.elisp
Any other suggestions are also welcome.
If I were to work on this, I'd use Pymacs to interface Emacs to Python and then use the existing Python API kit for Remember the Milk. Why re-implement all the HTTP crud yourself?