Can I use a styles.css file uploaded on GitHub as styles for multiple projects? I'm trying to define a default style for my projects here: https://raw.githubusercontent.com/GhitaB/default-design/master/styles.css
I prefer to link this file instead of copying it in multiple projects.
RawGit serves raw files directly from GitHub with proper Content-Type headers.
Or, consider using Github Pages
Here we need to distinguish between duplication of code and resources. What you don't want is copying code, because those files would diverge and you'd need to repeat every change for all of them. Having one file uploaded to multiple servers, however, shouldn't be a problem as long as you have one place to edit them all at once.
For this case there's Git submodules. The idea is basically having a repository with the shared part and then including that repository in a specified path in your other projects. You can read more about it here: https://git-scm.com/book/en/v2/Git-Tools-Submodules
This way all your IDE-based and external tools will still work and your website can be deployed as a whole. If, at some point in the future, you decide to have separate CSS files, you can simply replace the submodule with a file and you won't need to change the paths in HTML.
Of course, you can also use the same exact resource in multiple projects simply by pointing them to the same URI, but then the uncoupling might be harder afterwards and you can't see the file in your IDE.
Related
We are using trackjs.com code to help us detect javascript errors. We want the trackjs code to report all errors in any javascript code. This requires that the trackjs code be loaded first.
I know it goes against the general meteor loading order, however we don't want any javascript issues hidden, no matter where the errors are.
We tried including the trackjs.com code included in the compatibility folder and hardcoded in a <head> block. Both of these approaches resulted in the code being loaded last.
Suggestions?
Taken from official documentation:
Files in subdirectories are loaded before files in parent directories, so that files in the deepest subdirectory are loaded first, and files in the root directory are loaded last.
Within a directory, files are loaded in alphabetical order by filename.
After sorting as described above, all files under directories named lib are moved before everything else (preserving their order).
Finally, all files that match main.* are moved after everything else (preserving their order).
So you should be placing them in the lib directory. If you place it in server/lib it is going to be available to the server, or in client/lib the client only. But if you place it in a common lib folder, then it is going to be available to both the client and the server.
That being said, it is usually a better idea to place such code into its own package. Packages have better loading order management as described in the relevant section of the docs.
Finally, you might also want to look at http://observatoryjs.com/ which targets to achieve a similar solution as trackjs and it has native meteor packages you can search and add from http://atmosphere.meteor.com
UPDATE:
These solutions place trackjs after meteor's native code and before yours and any other 3rd party's.
To be able to truly inject trackjs before everything else, there may be a few ways:
https://github.com/arunoda/meteor-fast-render/blob/master/lib/server/inject.js#L52 is how fast-render package alters the contents of head to inject arbitrary scripts. You can inject trackjs at the very beginning using this technique.
You can directly hack https://github.com/meteor/meteor/blob/devel/packages/webapp/webapp_server.js how meteor serves the app. This would again be client side only and prone to meteor update conflicts.
I'm considering using LESS for CSS development with server (or development) side processing, but I can't decide if I should keep the generated CSS files in version control. There are plenty of solutions with hooks, but this adds software dependencies to the server. A hook could just be added locally so staging and production areas on the web would get the same files. So, the question is:
Should generated CSS files be included in version control or not? Please keep in mind that some frameworks require a CSS file to exist for a particular reason (i.e. WordPress themes require a style.css file in order to be recognized).
When I say 'considering using LESS', I mean it becomes a requirement. New developers would not have the option use vanilla CSS after the choice is in favor of LESS.
Checking in derived artifacts is almost always sub-optimal.
I vote no to checking in the .css. It's only a matter of time until one of your peers or successors checks in an edit to the .css and not the .less. Then when you change the .less the prior change is lost.
You've pretty much answered your own question. It depends on how you deploy your website.
If the server is just going to pull directly from the Git repository:
1) It needs to have software installed to generate CSS from LESS.
2) or you need to include the CSS files in the repository.
If you're not pulling straight from the repository on your web server, you could have a build script that pulls from git, generates CSS, and then transfers the content to the web server(s), possibly excluding unnecessary files from the transfer.
In my opinion, Git should be used to keep all of the source for a project, and none of the "derived artifacts" (as mentioned by #thekbb). Developers need to have all tools installed to generate those derived artifacts during development and test. For deployment to test and production servers, an automated build server should take the source and create just the files needed for distribution.
In the case of software development, you'd have a Makefile with .C and .H files (for example) in your Git repository. Developers and the build server have a compiler installed that will create an executable or compiled library. When the files are packaged for distribution, the source code is not a part of the archive.
For web development, you have source files like original graphics, HTML templates and LESS files. Developers and the build server can run scripts to generate the site assets (CSS from LESS files, static HTML pages from templates, flattened images in multiple sizes/formats, etc.) When the build server deploys new builds, it copies just the files needed by the server, excluding the source graphics, templates and LESS files.
If there are people that need to review the site content, they should do it on a staging server. If that's not possible, the automated build server can create a ZIP file on an internal server that they can download for review.
Should generated CSS files be included in version control or not?
In theory they should not, but for practicality, I do usually checks in the generated css file. The reason is that it simplifies deployment since I do deployment using git; I would not need to have a less compiler installed on the server and usually not even on the machine I'm deploying from (as opposed to the machine where I'm developing on). Doing this could be useful if you have separate developer and deployer, but can sometimes also be useful even if you're deploying yourself.
Now, there are drawbacks on doing this:
You can't use git add --patch (or you really need to be very careful when doing so)
You should not modify the .css directly; instead I usually use a secondary .css file to do minor modifications without modifying the primary .less or .css file. You can also compile .less file straight into a minified css, to make it less tempting to modify the generated css.
Developers have to set up their machine to use automatic recompile tool (like SimpLess or Less.app), so the .css file is updated as soon as they save to the .less file. Without automation, you'll run into risk of the css not matching the checked-in less file.
I would not do the same when compiling from .C and .H files though, because the generated binary for those are platform specific, and also .less/.css file is usually a very small part of a larger web project so the space overhead of the additional file is small.
Good question. If you can absolutely guarantee that the CSS file gets updated when the LESS gets updated then perhaps yes - as per #Scott Simpson's comment. I suspect that this would be difficult to guarantee and what happens when the new developer get's a copy of CSS the day when they are out of sync? Also, of course, and I hadn't originally thought of this, what happens if the new developer then makes updates to the CSS file rather than the LESS?? If the CSS has to be built and isn't part of archive I can see less problems.
I would say yes -- because what happens if you want to add a developer to your workflow and they don't want or need to build .Less? It would be helpful for them to have access to only the generated file.
On a new project I have started, XCode has decided that it will compile every file in the project every time I run it, rather than just compiling files that change (and files dependent on those). As there are getting to be more and more files in the project, this becomes a bigger and bigger burden in both time and battery life.
It is possible that I have changed a setting somewhere that affected this; or, maybe not. What are some project settings that I should be looking at?
If Xcode recompiles most or all of your source files whenever you do a build, that usually means that those files are all directly or indirectly dependent on some header file that has changed. Here are some things to look for:
Do your source files tend to #import some top-level header file that itself recursively imports a bunch of lower-level header files? If any file in that tree of dependent headers is modified, it will force recompilation of any .m file that imports the top-level header file. You may be able to reduce these dependencies by importing headers for lower level submodules, or better yet, for just the specific headers you need for each file. (Note: Some libraries that aren't designed to be used this way can make this approach challenging or impossible in some cases.)
Some third party development tools and static libraries run scripts that generate or modify code as part of their build process. If your source files are dependent on a header file that's generated by a script, they'll be recompiled every time the script regenerates that header file. Even if the code generated by the script doesn't change, dependent source files will be recompiled if the last-modified date of the header file changes. It may take some clever hacking to eliminate redundant compilation if this is your issue.
Don't forget to check your precompiled header (.pch) file to see what's being imported there. The contents of that file are effectively injected at the top of every .m file in your project at compile time.
Try to minimize dependencies by moving as many #import statements as possible out of your .h files and into your .m files. You can generally get away with just importing the headers for your class's superclass and any protocols your class implements in its .h file. You can use forward declarations instead of #import statements for any other classes, data types, or protocols you use in your class's #interface.
I realize this question is over a month old, but I had a similar problem in moving an old project to Xcode 4. After much hair-rending, I discovered that Xcode 4 (4.2 in my case) has a bug where, if there are any non-ASCII characters in the full path either of a source file, or in the full path of any headers the source file includes, it will be recompiled every time you build. This includes the prefix header, in which case a full compile will be triggered every time. In my case, the previous programmer had appended 'ƒ' to several folder names, and once I removed those, it worked perfectly.
Anyway, I stumbled upon this question during my (unsuccessful) attempts to Google an answer and thought I'd share my solution.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.
if you're familiar with Liferay you'll know that when you make an itsy-bitsy change to a css file you shall rebuild the theme and redeploy it.
As for redeploying I made a symlink (mind you I'm on Windows: for the curious creating a symlink on Vista is just a matter of issuing mklink /d dir1 dir2).
But what about rebuilding the stuff with maven? I'd rather skip that step. Basically what it does is combyining and packing all CSS in one everything_packed.css. Is there a sort of config variable to tell liferay just to include the raw files and skip redeployment alltogether?
Thanks
Guys I found the solution myself.
You should have a file called portal-ext.properties file in
$TOMCAT_DIR/webapps/ROOT/WEB-INFO/classes
Or more specifically for my win setup in
C:\liferay\webapps\ROOT\WEB-INF\classes
The file would hold the value
theme.css.fast.load=false
This will prevent liferay to be looking for the everything_packed.css and so you're free to modify your stuff without rebuilding and CTRL-R to refresh the page and see the changes.
Just for completeness, as this question is somewhat old and the problem already solved: There's a lot more along these lines, e.g. javascript, layouts etc. that can be used uncached. This is documented in either the Liferay Wiki (as Developler Mode) or the Development Guide, available from the documentation site (though currently it's not there for the last version - if it's still not there when you're reading it, look for it (PDF) in the older versions.
It's advisable to use these settings only in development, not in production, as putting all css and javascript in as few files as possible results in a huge performance impact.
to include all those settings, just can also just add the following line into your portal-ext.properties file:
include-and-override=portal-developer.properties
this will include all the developer specific settings, and when you want to remove them, you can just comment out this line.
you can edit the css files of your theme from Webapps{your theme}\css
And can see the changes directly.
You can edit almost every file which doesn't require compilation.like .jsp files but not .java files