Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Starting a new project. It's basically a blogging/commenting system.
We're considering node.js as the back end server. Is node.js ready for this sort of thing or is it too early and experimental?
We need HTTPS and gzip compression - perhaps a front end nginx server could provide this?
What's missing from node.js that would make developing a web app difficult?
From a production ready perspective, we're wondering if it is stable enough for building a commercial app on top of.
Thanks
UPDATE:
Almost a year has passed and now I'd definitely use node.js for live systems.
It's not ready. It sure is an awesome piece of software but it's not suitable for production use yet.
The developer of node.js himself stated in a talk, that it's probably full of bugs and security issues.
This is the talk: http://www.yuiblog.com/blog/2010/05/20/video-dahl/
He recommends that IF it is to be used in a production environment, you should place it behind a stable http proxy like nginx but he discourages doing that at all.
I'll wait for a production release and until then, play with it on my local machine.
Node.js is really great. But it's complicated for a production use now. Actually, the API change several times in each version and can be change again a lot of time. So you need fix to a particular version. The migration can be painful.
I'm using it for a production site. It's been live for a few months and I've had no issues with the node runtime. Stick with the latest stable release (currently 0.2.6).
The 3rd party modules written by the community are where you may run into issues. Some modules are more stable than others. The node community has standardized on github, so it's pretty easy to fork and fix things you run into. But be prepared to roll up your sleeves and hack -- it's probable that you'll need to fix a few bugs in the modules you use.
Overall I've been happy using node.js
It's just another tool, with different pros and cons. If your project is planned carefully you shouldn't run into major problems. Node.js is a very active project and it shouldn't be long before it reaches stable. If your team finally decides to use node.js please contribute any findings / solutions / code or any kind of valuable information back to the community while you're at it. That would really help. The more people active, the faster node.js will progress.
It's still got some rough edges, but I'd say it's ready to use (I'm about to launch a production site based on it). Here's an article describing how 3 companies are using it in production.
You may still find yourself finding/fixing the occasional bug, but that's where the community really shines.
(Updated answer) On June 2013 (version 0.10.12):
Node.js is ready for production, it's stable and really fast.
I am using it on live servers with Redis, using a SmartOS VM with dtrace and flamegraph for profiling (on a dev server). It also replaced quite well my Apache/PHP stack for creating websites.
The best ways to find up-to-date modules are Nipster and npmjs.
As some modules are not mature enough, finding the right one is sometimes an iterative process.
--
(Old answer) On May 2012 (version 0.6.18):
Node.js and its API seems stable enough for production use.
However, its ecosystem isn't: most modules are not stable yet and a lot of them aren't maintained anymore (last commits from 8 to 18 months - you can check on the github pages of modules)
Currently, using a module often require an active participation: subscribing to its mailing list and patch it when needed.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
We have a linux production server and a number of scripts we are writing that we want to run on it to collect data which then will be put into a Spark data lake.
My background is SQL Server / Fortran and there are very specific best practices that should be followed.
Production environments should be stable in terms of version control, both from the code point of view, but also the installed applications, operating system, etc.
Changes to code/applications/operating system should be done either in a separate environment or in a way that is controlled and can be backed out.
If a second environment exist, then the possibility of parallel execution to test system changes can be performed.
(Largely), developers are restricted from changing the production environment
In reviewing the R code, there are a number of things that I have questions on.
library(), install.packages() - I would like to exclude the possibility of installing newer versions of packages each time scripts are run?
how is it best to call R packages that are scheduled through a CRON job? There are a number of choices here.
When using RSelenium what is the most efficient way to use a gui/web browser or virtualised web browser?
In any case I would scratch any notion of updating the packages automatically. Expect the maintainers of the packages you rely on to introduce backward incompatible changes. Your code will stop working out of the blue if you auto update. Do not assume anything sacred.
Past that you need to ask yourself how much hands on is your deployment. If you're OK with manually setting up each deployment then you can probably get away using the packrat package to pull down and keep sources of the exact versions you are using. This way reproducing your deployment is painful, but at least possible. If you want fully automated reproducible deployments I suggest you start building docker images with your packages and tagging them with dates or versions.
If you make no provisions for reproducing your environment you are asking for trouble, while it may seem OK at first to simply fix any incompatibilities as they come up with updates, and does indeed seem to be the official workflow from the powers that be, however misguided that is; eventually as your codebase grows that will be all you will end up doing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Is WxWidgets relevant in 2015? Last release was on October 06, 2014, is this project dead? Is there any reason to pick it over Qt?
Yes, wxWidgets is relevant in 2015 for writing portable desktop applications with native look and feel, nothing much has changed there.Reasons for choosing wx over Qt remain the same as always too, see e.g. this answer. What did change is that in many cases you need to target mobile platforms (where wxWidgets is much less relevant as it only has some support for iOS and still not for anything else) or may choose the HTML+JS approach -- but this is a separate decision.
The project is certainly mature (who wouldn't, after 20+ years), but is not dead at all. You can look at the commit activity to check for yourself. If you think that 11 months since the last release is too long to wait for, you are absolutely free to use the latest Git master (which does have quite a number of improvements) or switch to one of JavaScript frameworks.
Gladly to informed about latest release wxWidgets, it's now being version 3.1. Seem the guys behind the stage were worked hard to invent and make this library become more mature and provide better feature. wxQt is now being supported, nice...
wxWidgets is worth as our primary GUI framework to work with. Congratulation for all wx developer community.....
Check it: http://wxwidgets.org/news/2016/02/wxwidgets-3.1.0-released/
I do agree with Dr.Vadim, 11 months (now 12 months) is not too long to wait for another recent release. Since it first release 20+ years ago, wxWidgets now is become really mature library and provide you very complete documentation. wxWidgets also makes GUI component look native in the desktop's OS where it appeared... be it windows, linux or mac...
I'm also heavy user of wxWidgets due to it's ability to yields portable application, maturity, complete documentation, updated and licensing scheme reasons. Binary application yields by this library is very small, even for statically linking compare to qt.
For those reasons, developing an application for ARM architecture with limited cpu speed and memory will be satisfied by wxWidgets library.
CMIIW, I believe, future of portable and embedded application will belong to wxWidgets...
This link is my experience to build wx library and application for Raspberry Pi: http://yasriady.blogspot.co.id/2015/10/how-to-build-wxwidgets-for-raspberry-pi.html, and as the result, my application running smooth and happy in Raspbian...
You might try to make a comparison for those reasons as well.... and see if wx will match your expectation....
UPDATED (12-Jan-2016):
Ready used and easy installation wxWidgets/Eclipse-IDE/Toolchain cross compiler, please do follow this link: http://yasriady.blogspot.co.id/2016/01/raspberry-pi-toolchain.html
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am trying to plan a way for 5 developers to use Visual Studio 2005/2008 to collaboratively develop an ASP.NET web app on a development web server against an Oracle 8i(soon to be 10g) Database.
The developers are either on the local network or coming in over a vpn (not a very fast connection),
I evaluated the latest Visual SourceSafe, but ran into the following gotchas:
1) We can't use decentralized development because we can't replicate a development oracle database to all developers computers. Also, the vpn is too slow to let their local app instances connect to the database server.
2) Since VSS source code not on the file system, the only way to debug it is to build the app and run debugger, which only one developer can do at a time on a centralized development server. This is unacceptable. We tried using shadow folders so that every time a file is checked in it gets published to the app instance on the development server, but this failed for remote developers on the vpn.
3) Since the developers do a lot of web code, it is important for productivity reasons that when they SAVE a file, they should be able to immediately see the change working on the development server.
4) No easy way to implement a controlled process for pushing files to the production server.
Any suggestions on a source control solution that would work under these contraints?
Update: I guess since development is forced to be on the server, we need to go with a "Lock and Check In" model. So which source control solution would work best for "Lock and Check In' scenarios?
Update: Does Visual SVN support developing centrally against a development server? As in, the dev can immediately see his update on the development server after saving in VS?
I have used Subversion and TortoiseSVN and was very pleased.
Is point 1 due to an issue with your database schema (or data) ?
We can't use decentralized development because we can't replicate a development oracle database to all developers computers.
If not, I strongly suggest that every developer has its own environment (Visual Studio, Oracle...) and use your development server for integration purposes. Maybe you could just give them a subset of the data, or maybe just the schema scripts.
Oracle Express Edition is perfectly fit for this scenario. Besides, sharing the same database violates rule #1 for database work, which in my experience should be enforced anywhere possible.
As Guy suggested, have an automated build allowing any developer to recreate its database schema at any time.
More very useful guidelines can be found here (include rule #1 above).
Define your development process so that parallel development is possible, and only use locks as a last resort.
I'm sorry if you already envisioned these solutions and found them unfit to your situation, but I really felt the urge to express them just in case...
Visual Source Safe is the spawn of Satan.
Look at Subversion, and Visual SVN (with Tortise SVN). Sure, Visual SVN costs a bit - $49 per seat - but it is a great tool. We have a development team of 6 programmers, and it has been a great boon to us.
If you can spend the money, then Team Foundation Server is the one that works best in a Visual Studio dev environment.
And based on personal experience, it works beautifully over VPN connections. And you can of course have automated builds going on it.
I would say SVN on price (free), Perforce on ease of integration.
You will undoubtedly hear about GIT and CVS as well and there are good reasons to look at them.
Interesting -- it sounds you are working on a web site project on the server, and everyone is working on the same physical files. I agree that SVN is far superior to VSS and really good to work with, but in my experience it's really geared toward developers working on a copy of the code locally.
VSS is a "lock and check in" type of source control, while SVN and TFS and most others are "edit and merge" -- devs all get copies of the source, edit the files as needed, and later merge their changes in to source control, and if someone else has edited the file in the meantime they merge the changes together.
From a database standpoint, I assume you are checking in your database scripts, then have some automated build packaging and running them (or maybe just a dev or DBA running them manually every so often). In this case, having the developers have a local copy of the scripts that they can edit and merge using SVN or TFS makes sense.
For a team working on a shared copy of the source code on a development server, though, you may get into problems using edit and merge -- a "lock and check in" model of source control may work better for you. Just not VSS, from a corruption and stability standpoint.
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!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
At my job we make & sell websites. Usually we install our .NET C# based site on a customer's server and maintain and support it remotely. However, every once in a while, for bigger development works and just to make things simpler (and faster!), we will copy the site to a local server.
This is great, but has one pain - moving the site back to the customer. Now, If nothing was change on the customer's copy - no problem. However, it is the sad truth that sometime (read more often than I would like) some fixes were needed to be applied on the production server. Either because the customer needed it NOW or simply because it was major bug.
I know that you can easily apply those bug fixes to the local copy as well, but this is an error prone process. So I'm setting my hopes on a distributed version control to help synchronize the two copies.
Here is what I need:
Easy to install - nothing else needed except the installer and admin rights.
Can integrated in an existing website as a virtual directory and works on port 80 - no hassle with new DNS required.
Excellent software
That's it. Any ideas?
Some comments on the answers
First, thanks! much appreciated.
I've looked at Mercurial and Bazaar and both look very good. The only caveat is the installation as a virtual directory on IIS. Mercurial, as far as I understand, use a special protocol (wire) and Bazaar needs and addition of python extensions. Is there another system which is easier to integrate with IIS? I'm willing to take a performance hit for that.
I'd look at either Mercurial or Bazaar. I'm told Git also works on windows, but I suspect the windows port is still a second class port at best.
You'll probably need to be able to run python scripts on your webserver to host either of them.
Maybe not exactly what you request but checkout DeltaCopy which is a windows version of rsync. You can also read about another rsync solution here
I can also vouch for Mercurial. Simple to use and powerful to boot!