It has been a year since I last setup a new project with Django and I remember automatizing it was pretty painful at the time. When searching the subject these days I can't find anything really helpful.
So, what is the latest in automatic setup of Django local development environment?
By that I mean maybe some orchestration with something like chef or juju to setup a vagrant box or similar to develop on a local system with a database like PostgreSQL and other system level tools (cache, queue...). Maybe with automatic connection to a github repository or equivalent. Anything that would help start developing right away and also deploy the environment on a server without pain.
Does something like that exist today and it has escaped me? Or is it something that still needs to be improved? Setting up a good development environment for Django has changed a lot since the early days of virtual environment and sqlite, and even since a few years ago.
Edit: I have accepted the only answer because... it's the only answer. And it's good enough. But feel free to add any new answer since this one, although interesting, does not satisfy my needs.
It looks what vagrant-django-template is pretty good solution for you.
Related
OK, I am desperate enough to finally post a github question.
SUMMARY:
Django deploy -> digital ocean droplet -> nginx and gunicord + git pull
It works, but manually writing all the commands is way to tedious + error prone. I have been trying to find a suitable tool ever since, and kinda need some advice.
SOO FAR:
I have tried Fabric, BUUUT complexity and simplicity baffles me. Some tutorial are way to trivial, some are way too complex and 95 % of them seems to be outdated(this seems relevant in this case , because syntax has changed drastically)
In addition, the most basic example in docs don't work no matter how many times I have tried to correct it(ssh connection vie password).
P.S. I am completely new to devops, so a lot of things is confusing for me
Beside that, I have tried to dive into some other tools like bash scripting and ansible and dropped them shortly after, mainly due to them not being as alluring as Fabric seems to be.
My question is!
Should I continue tring to solve Fabric, or is there some other commonly used way to make deployment a simple and enjoyable matter while preserving the functionality?
::btw I am windows 10 user put prefer to use git bash, could this be the problem for Fabric(it seemed not being able to recognize ls command and I used DIR instead)
I typically recommend using ansible over fabric unless you are working with *nix. If you have to work with AIX, Solaris, HPUX, fabric can offer you more flexibility since you don't need python on the server. It will take about two-days to get up to speed on ansible, but if you're already using django, jinja2 (the templating language used by anible) should be a snap.
This question already exists, but it is over one year old now and a lot has probably happened if the documentation is a good judge. There is no documented path to migrate from current redmine (2.1) to chiliproject for example.
Chiliproject is a fork of redmine, but I am unable to decide wherever I should migrate or not. There is no clear path as to how I should do the migrations and how much functionality I might loose.
Is there a way to compare the differences between the two projects? Is it worth to spend the time investigating the migration path?
If you have migrated what is your experience?
I searched StackOverflow for the "redmine vs. chiliproject" question because I am having a lot of trouble with installing plugins of any kind on the newest chiliproject version.
Usually, it looks like everything is working fine until you try to update the settings for the plugin (for example, install the Contact Form plugin and try to change something on http://SERVER:3000/settings?tab=contact_form), the debug log shows that the changes were made in the database, but they changes are never loaded back to the plugin page.
I have not been ale to find any documentation on potential changes to the plugin architecture in ChiliProject that would cause this. The plugin page does not list many plugins that are known to work with ChiliProject 3 either.
TL;DR: If you think that you will have any desire to use any existing plugins to extend the functionality of the program you choose, go with Redmine.
Let me first say I am aware of this faq for Mach-II, which discusses using application specific mappings as a third option when:
locating the framework in the server root is not possible and
creating a server wide mapping to the Mach-II framework directory is impossible
Using application specific mappings would also work for other ColdFusion frameworks with similar requirements (ColdSpring). Here is my issue however: my (I should say "their") production servers are all running ColdFusion MX7, and application specific mappings were introduced in ColdFusion 8. I most likely will be unable to do option 1 or 2 because they involve creating server wide changes that could conflict with other applications (I don't have a final word on this but I am preparing for that to be the case).
That said, is there anybody out there who was in similar bind and has done an option 4, in any ColdFusion version, or with any similar framework? The only option 4 I can think of is modifying the entire framework to change this hardcoded path, and even if that worked it would be time consuming and risky. I'm fairly sure that if there was a simple modification or other simple solution it would already be included in the framework (maybe it's included in version 1.8 of Mach-II and I don't know about it yet).
Any thoughts on solving this problem or even unorthodox setups with libraries that have specific path requirements would be appreciated. Any thoughts from Team Mach-II would especially appreciated...we're on the same team here Matt! ;-)
EDIT
Apparently, the ColdBox framework includes a refactor.xml ANT task which includes a target that refactors the ColdBox code to use a different absolute path as a base along with several other useful refactoring targets. So problem solved for ColdBox users.
Looking at the build.xml for Mach-II (1.6 and 1.8) I don't see any target in there that would allow me to refactor the code. I thought about creating a feature request ticket for such a task for Mach-II but frankly I don't think creating such an ANT task is a big priority for the MachII team since the need really only relates to either
a) users of ColdFusion versions below 8
b) someone who wants to use multiple Mach-II versions in the same application, a use I doubt they want to support
The ColdSpring code I have doesn't come with any ANT tasks at all, although I do have unit tests, and I bet if I poked around the SVN I'd find a few build scripts.
Using Ant tasks to refactor and retest the code, or the simpler (and sort of cop out) solution of creating a separate ColdFusion instance for the application are the best answers I've been able to come up with. I don't need this application to exist in the shared scope of other applications, so my first solution is going to be to try and get a dedicated CF instance for this application.
I'm also going to look at the ColdBox refactor.xml ANT task however and see if I can modify it to work generically to recognize and refactor CFC references with modified absolute paths. If I complete this task I'll be sure to post the code somewhere and edit create an answer to link to it. If anybody else wants to take a crack at that or help me out with it feel free.
Until then I'll leave this question open and see if someone comes up with a better solution.
Fusebox is not so strict, I think.
In XML mode (maybe I call this not 100% correcly, just mean using the Application.cfm) it's just proper include in index.cfm, something like:
<cfinclude template="fusebox5/fusebox5.cfm" />
In non-XML mode it will need proper extending in the root Application.cfc:
<cfcomponent extends="path.to.fusebox5.Application" output="false">
All you need is to know the path.
Perhaps you could create a symbolic link and let the operating system resolve the issue for you?
I've been playing with FW/1 lately, and while it may look like you need to add a mapping and extend org.corfield.framework, you can actually move the framework.cfc file into your web root and just extend="framework". It's dead simple, and gets you straight into a great framework with no mess and very little overhead.
It should be as simple as dropping the 'MachII' folder at the root of your domain (i.e. example.com/MachII). No mappings are required to use Mach-II if you just deploy at the root of the domain of your website.
Also:
Please file a ticket for the ANT task you mentioned in your question. Team Mach-II would love to have this issue logged:
Enter a new ticket on the Mach-II Trac
If you want to tackle an ANT task for us, we can get stuff like this incorporated into the builds faster than waiting to for a Team member to work on the ticket. Code submissions from the community are welcome and appreciated.
We don't keep an eye on Stack Overflow very often so we invite you to join our official community group at called "Mach-II for ColdFusion" at Google Groups. The Google Group is the best place to ask questions or comments like this if you want feedback from the Team.
Google does not really deliver much content (or my query sucks). Has anyone made the switch and can share the experience?
We found that when we upgraded to CF 8:
Carraige returns are stripped in plain text emails. We found we had to be explicit about line feed characters by creating a var like so <cfset CRLF = "#Chr(13)##Chr(10)#"> and inserting it in the plain text email where we needed the line feed. We eventually went to HTML emails.
Third party jar files caused problems due to the order in which jar files are loaded. Certain jar files must appear first in the java classpath as defined in cfroot/runtime/bin/jvm.config. This was a messy workaround and we have discontinued using that jar.
Also make sure to patch immediately to 8.0.1. We had a performance nightmare becuase of this issue.
Best of luck!
I haven't had any CFMX 6.1 apps to switch across, but Railo is definitely my CFML engine of choice.
Compatibility-wise, there is very unlikely to be any significant issues migrating from CFMX 6.1, and you can easily test this with the Express version - no installation required!
Railo can be stricter about certain aspects of CFML, so you might get a few errors if you exploit bugs/weaknesses with CF, but nothing really to worry about.
And, if you do get stuck on anything, the Railo mailing list is active with plenty of friendly helpful people who can help to get you going again.
We made the switch about a year ago and if you are talking about only on the code side, then the change from cf6 to cf8 shouldn't require any changes as long as your setup remains the same. One change is the way that CF handles verity collections, so if you make use of cfsearch then it might be something you look into. There are a number of improvements from cf6 that you should look to implement. The few that we have found especially helpful are cfdocument, cfimage, cfpdf, and cffeed. Here is a good link with other key points... http://www.adobe.com/products/coldfusion/upgrade/
If you are upgrading from CFMX 6.1 to Railo 3.1 almost no problems should occur. There are some things that we do not support (like CFREPORT or C++ CFX tags). Besides that it should be very easy to migrate existing CFMX 6.1 code over to Railo. By default Railo is configured to be as compatible as possible with CFMX.
There are some other things you might watch out for:
If you create a struct like this in CF: <cfset a["image.x"]> you will be able to call that variable by using the "." notation, although it's misleading. So in CF you could do <cfoutput>#a.image.x#</cfoutput> whereas in Railo you would have to write: <cfoutput>#a["image.x"]#</cfoutput>
Inside functions creating variables in the local scope that are named like scopes will work in CFMX but not in Railo. So this: <cfset var url = "whatever"> will work in CF but not in Railo.
In Railo you cannot use the application scope or the session scope before it was initialized with cfapplication. Well in CF you couldn't either but there CF will create a local variable in the variables scope called "application" or "session". This sometimes leads to confusion.
Besides these things, it should go flawlessly. If you have of course any problems, just contact our Railo Google group or us directly at www.getrailo.com
Gert Franz
Railo Professional Open Source
I'm not aware of any depreciated tags or functions from CF6.1 to CF8. CF8 has been optimized for performance so you will most likely see an improvement in your application depending on what was used.
I successfully upgraded a large application from CF4.5 to CF8 with no problems. If the application consists of pretty straight forward use of ColdFusion tags and functions, you shouldn't have much problem.
However, since the developer version is free to use, you should really setup a test environment and determine the answer to this question yourself by testing your application. All datasources, custom tags, etc will have to be migrated and tested. If any CF6.1 applications used any of the lower level java api available in some things, you may need to test that thoroughly to make sure the underlying implementation of the coldfusion hasn't changed and fix what's necessary.
As for Railo3.1, there may be some tags or functions not implemented yet. You will again need to setup a test environment and determine this yourself. Somewhere on the Railo site there should be a list of compatibilities between the difference versions of CF and Railo.
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 3 months ago.
Improve this question
I am about to start a new project and would like to document its development in a very simple blog.
My requirements are:
self-hosted on my Gentoo-based LAMP stack (that seems to rule out blogger)
Integration in a django based website (as in www.myproject.com/about, www.myproject.com/blog etc rather than www.myproject.com and a totally different site at blog.myproject.com)
very little or no learning curve that's specific to the blog engine (don't want to learn an API just to blog, but having to get deeper into Django to be able to roll my own would be OK) According to the answers so far, there is a chance that this excludes Wordpress
Should I
a) install blog engine X (please specify X)
b) use django to hand-roll a way to post new entries and a page on my website to display the posts in descending chronological order
Install Wordpress. It is the most common engine for a reason. It's PHP but will play just fine in your environment.
If you're the perfectionist kind, roll your own.
It isn't that hard
You learn something useful
You'll get exactly what you want and need
Be warned that you may run into a quagmire fighting comment spam, fixing security holes, etc. But it'll probably be a fun project.
If you are the practical type and ready to face some integration pain, use an existing engine like WadcomBlog (Python) or PyBlosxom, or something completely different like MovableType or WordPress.
Here's a simple Django blog example to get you started.
Some pros and cons of rolling your blog engine this article by Phil Haack.
Jeff Croft apparently rolled his own as well.
I've tried WordPress recently and am very disappointed. As long as you don't want to customize anything, all is well. But imagine you want to install a plugin to handle Markdown editing. There the trouble begins. The plugin architecture of WordPress is seriously screwd up. In the case of Markdown, this means that no good solution exists. The existing plugin is a series of (quite well-documented) hacks that fall apart at a hard stare.
I never intended to write the least bit of code for WordPress but the last few days, I've been knee-deep in PHP the whole time, hacking plugins as well as the WordPress core in order to make it work for my special scenario (which really isn't all that special, I'm just a perfectionist). Which is a pity, because the documentation of WordPress is more than just patchy. I don't use it anymore, I grep for functions and read the source. All in all, one of the less enjoyable OpenSource projects.
You can spend hours if not days customizing Wordpress with plugins, themes, etc...
I would go with a 0 installation solution, such as blogger (https://www.blogger.com/start)
You can even use our own domain name with it if you need do.
EDIT: Plus, if you ever get slashdotted, digged or redditted, google can handle the traffic, your server probably can't.
For me, Wordpress is still the quickest & simplest to setup and get going. It can be extended to do pretty much anything or you can keep it real simple. Runs on PHP, but unless you want to write plugins for it, you never need to write code
Have a look at Blosxom. It's file-based, so no crufty database. The basic idea has been ported to different languages, pyblosxom is in Python.
I use PyBlosxom for my personal blog, and I think it is pretty useful if you need something minimalistic. The deployment is simple, as you need only the python runtime and cgi. You might want to have some basic knowledge of python at least if you are going to use it, though.
Have a look at Blosxom. It's file-based, so no crufty database. The basic idea has been ported to different languages, pyblosxom is in Python.
I wrote the engine for my personal blog in maybe 6 hours during one weekend, with comments, labels, simplified markup, sitemap, feeds and so on. It was great fun and I learned a lot of Django.
If you decide to go this way, look at generic views, this Django feature will save you much of work (and learn few useful tricks).
I Haven't tried it myself yet (other than the demo), but I've bookmarked Chyrp so that if I ever need to set up a quick & simple blog (kind of like you're describing) I could try this. So check it out, might be a good option for you.