I don't like the idea of hardcoding brand names in my projects. I get the feeling they might change later, and sometimes I don't even have a name yet. So, can I do rails new app for my every project and just rename the directory? What problems could arise from that?
this could result in some issues
the name of the application has some implications on the internals and using several apps named "app" might have undesired effects and bugs.
for instance, sessions and cookies are named after the app name, so they will all be the same
further more, this have effects on outside sources such as AWS buckets, github repos, and even folder names - it will be pretty hard to figure out what all those /app folders are.
so if the only app you have and are working on is called app - it shouldn't be a problem (besides the name app, which is really lame, and if you are working on it at least call it by greek letters or something..)
if you are going to work on more that one app.. do yourself, your coworkers, your file-system, github, and everything else - name your app.
Also an important side note - how can you have an app and not know what it is about?
and if the name is not suiting anymore.. change it https://github.com/morshedalam/rename
If you rename your project, you must rename it in some files too. (routes.rb, environment.rb, application.rb, ...)
Heroku, for example, let you rename your app any time with apps:rename.
Related
I'm using Umbraco 7.4.x. I've been trying to figure out the best way to do bi-directional deployments.
As in, we have more than one dev working locally, and we have a dev server and a live server. We have single click deploys from local to dev, but that's only code. We were copying up the databases to dev, but now we also have people who need to enter content on dev. This leads us to making changes on dev database as well and copying down the database. We do all this with Version control of course, but still, this is all very inconvenient.
Is there a better approach to this that I'm missing? I tried using usync a few months ago but we'd often run into crashes.
I have heard of Courier, it seems like it would be good for deploying from dev/stage to production, but would that also work for pushing content/doc type changes to our local machines? I wasn't sure as they're not web servers on the internet but just local IIS Express running through Visual Studios
Thanks in advance!
We use uSync (uSync + uSync.ContentEdition - https://our.umbraco.org/projects/developer-tools/usync/) for moving everything between instances. Give it another shot as it has changed from the point when you're exploring it in the past. It's worth to mention that it requires good configuration on different enviroments to avoid conflicts etc.
You can also use Courier and it's latest version is used by Umbraco Cloud (http://umbraco.io/) which may also interest you as it gives you full control over deployment processes between multiple Umbraco instances.
One option is to have all of your developers set up to work off of the same dev database. On occasion, your developers might have to "Republish the entire site" or reindex the examine indexes to make sure all their cache and TEMP file are up to date. Otherwise, this has worked well for us for many years. One frustrating part of this is that media files uploaded by dev A won't be immediately on the file system for dev B. You should be able to move your media to azure blob storage to work around this problem. There is a package that should help set this up here.
I wouldn't recommend uSync.ContentEdition. I haven't tried it personally, but I have yet to hear a good report about it. uSync on the other hand has been a life saver for us even if it isn't perfect. At this point, we install usync on every site even if we never configure it to read in changes. We like that we can record our changes to document types and datatypes in source control. Working with the shared database setup means that we don't need usync to be reading on our dev and local environments. However, you will need to make sure that your devs all understand usync. If dev A adds a doc type, the usync .def file for that doc type could show up on the file system for dev B. Dev B should not commit that usync file in that situation.
Courier has been working a lot better recently. I wouldn't recommend it unless you are running umbraco 7 and can get the latest version of Courier. Courier is very useful, but you should do a lot of testing with it before you hand it over to a client because Courier gives you the ability to shoot yourself in the foot in a big way. It has definitely improved. In Courier for umbraco 6 I used to have to try really hard to deploy without breaking my site. Now, in Courier for umbraco7, I have to try really hard to break it. This is now a viable option for deploying content changes to production. Just make sure you test it heavily before you use it in a production environment.
I just got a typo3 website and need to transfer to an other domain.
Is it enough to copy all the folders (except typo3temp?) to the new place?
First I just changed baseurl in ts but it didn't do anything..
Should I do anything with the database when it still on the same server?
In case your question is about "cloning" a complete TYPO3-system an rsync/copy of the whole folder (yes including typo3temp) is the best idea, as this works on all versions, everything else (like excluding typo3temp) depends a whole lot on your TYPO3 expertise to resolve. The database needs to be copied as well. If you need to change db-name or db-credentials on the new system you need to change them in
typo3conf/LocalConfiguration.php
As soon as you have done this Install Tool and Backend should work: At first try the Install Tool:
https://my.new.domain/typo3/install/
If that doesn't work your problem is with the webserver configuration or dns.
If that works (and the reports there show no errors), try the Backend:
https://my.new.domain/typo3/
In case your question is about which changes are necessary to your TYPO3-installation if domain changes and the web server itself is configured correctly, then there are probably two things you need to change, in order to make the frontend work (although both cases might be omitted, depending on your configuration):
sys_template record, if any of those use absRefPrefix or baseurl. If you have access to the MySQL-Database a
SELECT pid FROM sys_template WHERE config LIKE "%baseurl%" OR "%absRefPrefix";
might help finding the template, however these template configuration might also be stored in files (typically in fileadmin/templates/**)
sys_domain records, a MySQL
SELECT pid FROM sys_domain;
might uncover where those are stored
However these changes are only necessary to enable the frontend to work.
Add a domain record in the backend. And while you don't need the content of the typo3temp folder, make sure the folder actually exists.
When you go to the new domain name in your browser, what happens?
Do you get redirected to the old domain? If so, maybe there is an .htaccess redirect happening.
Do you get to the new domain, but if you click on a link end up on the old one?
Do you get an error? If so, what is the error?
Does something else happen?
We have two QA sites: they should be identical, but their generated links behave differently.
On one case, the generated links contain the app.name. In the other case, the links do not contain the app.name and are failing with a 404 error.
good link: devici1/appName/controller/action
bad link: devici2/controller/action <-- notice the missing appName
Now here is what is weird:
Both systems are running the same version of code, the links are
generated using g.createLink(controller: entry.controller, action:
entry.action)
We do not set app.context anywhere that I know of.
It is not in application.properties, config.groovy, or the
icw-config.groovy (local override file).
Both systems set app.name in application.properties
grails.serverUrl is not set (we stopped using it more than a year ago)
Further, this may have been going on for several months and no one noticed it on the bad system, so there is no recent change I can go looking for.
Does anyone know the logic used by g:createLink to determine when the app.name should be included or not? Any suggestions for variables I should make sure are set or not set would be most appreciated!
As sf_sandbox has set up the symfony environment, why not develop in the sandbox directly and then upload on to server? What are the disadvantages of sandbox compared with configuring manually?
I think there is no drawback in following this approach. sf_sandbox is a pre-configured symfony project. One of the pluses is that is saves you time in creating your project and initializing an empty application (by default this is called frontend).
It's more a matter of taste rather than a matter of right or wrong. It's up to you!
Note: If you follow this approach you have to make some initial configuration (steps 1,2,3 would be done anyway if you started your project from scratch):
Rename the project
Change the config/properties.ini file
Change the config/databases.yml file (by default sf_sandbox uses sqlite database)
Remove the data/sandbox.db database file
I needed some templates to render some code for users to paste. I put these into
/project-dir/grails-app/resources/templates/quickInstallCode.html
Then I tried accessing them using their relative path (grails-app/resources/templates/quickInstallCode.html), and it worked great.
When we then deployed the application to a Tomcat Server, using a .war file, the paths began pointing to a wrong location.
ERROR call, Template file /var/lib/tomcat6/grails-app/resources/templates/quickInstallCode.html not found.
I assumed, that Grails, giving good defaults for everything would handle this mess for me, but it seems like it does not.
I also tried this call, and it seemed to work great, but when deployed, the BuildSettingsHolder did not contain build Settings, which resulted in a fatal error.
BuildSettingsHolder.settings.baseDir.toString()
http://grails.org/doc/latest/api/grails/util/BuildSettingsHolder.html
http://grails.org/doc/latest/api/grails/util/BuildSettings.html
I am pretty frustrated that I cannot get this easy task to work, but the reason that this is so complicated seems to be that all Files are encapsuled in a WAR and not unpacked on the Server.
So the Questions are:
Where in your Project would you put
Files like this?
How to get a
reliable and stable way to access
this files? I just need a stable path to a base directory, without having to hardcode something in the configuration ... This cannot be so hard.
I have 2 solution to propose for this situation:
Save the template in the database, in a setting table. This way guarantees that nothing can go wrong.
You can consider using the resource folder like Sachin & Nirmal has proposed. About security, I think you can configure SpringSecurity Plugin to protect the specific resources, so that it can only be accessed by the site user.
Take a look at this link and try to use the getResource that spring provides. Its way more flexible and configurable.
def filePath = "resources/file.txt"
def appHolder=ApplicationHolder.application.parentContext.getResource("classpath:$filePath")
By the way Conf is on the root of the classpath, you can stick the files in src/java or src/groovy.
I keep my static resources in web-app folder and access them like this
ApplicationHolder.application.parentContext.servletContext.getRealPath("quickInstallCode.html")
// quickInstallCode.html should be in web-app folder.