Hello I just cloned meanjs project and somehow there is no app folder under that project. Why they changed the structure? Am I doing something wrong? Sorry just try to learn Node and one of those tutorials I follow up is using that project
Meanjs project github link
it looks like the new version 0.4.0 has been already merged to the master branch and it has a new folder structure, if you want to work with the version 0.3.x that has the folder structure you mentioned you can clone the latest tagged 0.3.3 release:
git clone --branch v0.3.3 https://github.com/meanjs/mean.git
This will checkout to a 'detached HEAD' branch that has the 0.3.3(current latest 0.3.x) version and the folder structure you're looking for.
After cloning this version you can use the yeoman generator to create your template project from there.
The app folder is removed, which is the major concern for the noobs trying their hands on MEANjs following the older tutorials. Controllers,views, models are now moved into a separate folder called modules which was previously in the public folder. You can explore modules/core/server and modules/user/server of your project
for future people running into this same problem.
credits goes to pooja's answer at this thread
Related
I am writing draft blog posts using hexo. I am running the hexo server as follows:
hexo server --draft
This watches for changes in the draft folder and generates the draft posts which can be viewed at http://0.0.0.0:4000
The problem is I can't work out how to use live-reload while writing drafts.
With livereload I call
live-reload --port 9091 public/
And use use the javascript implementation with the browser
<script type="text/javascript" src="//localhost:9091"></script>
I can see why this doesn't work, live-reload is looking for changes to the public folder. With the server running in draft mode, I don't know what folder the html generated drafts are being stored in. I've searched my project structure and can't seem to see anything obvious. Any ideas?
Hexo can offer live-reload-like functionality via the'Browsersync-based' plugin, 'hexo-browsersync'.
There is actually also a hexo-livereload plugin, but the net, and hexo-browsersync's NPMJS rating, seem to favour the Browsersync Hexo plugin.
Christopher Martin's blog post 'Getting Started with the Hexo Blogging Framework', outlines the plugin's installation and usage, as well as many other helpful tips:
To install the hexo-browsersync plugin:
$ npm install hexo-browsersync --save
$ hexo server --draft --open #restart the server
This might possibly suit the OP's original question better than the accepted answer.
This is how I normally do this sort of thing:
hexo generate --draft --watch & live-server --port=4000 public
This generates the site in the public folder and watches for changes, whilst also serving said public folder with auto-updates.
Not exactly answering the specific question but maybe someone will find it useful.
Note: You will need to have live-server and hexo-cli installed globally, or locally if running via npm scripts.
hexo server serves the source version of the post not the public version. If you set livereload to watch the source folder livereload will work. I suggest setting livereload to use a 1 second or so delay before processing so the on the fly source generation to occur before reload is attempted.
Looking to the --draft option implementation at Github shows that it only extends the post processor to the _draft folder. So the place where it puts draft rendered files is the same it puts published posts.
However, hexo server does not save published posts in public directory as might be suggested by the question; public directory is populated by hexo generate command only. In fact hexo server does not save temporary files as it renders them on the fly.
I think live-reload will not work this way.
I have a couple of Mercurial installations running on IIS7 on a 2008 server. I'd like to use the monoblue theme style for both of them, but I want to change the colour of the second one.
To accomplish this, I copied the monoblue theme, and it’s related static files and renamed it to monored. I adjusted the header.tmpl file to point at the new style-monored.css file in the static folder and updated the site's hgweb.config to reference my new theme, monored. I’ve done this in both the files in the site itself (in the template folder) and also in the Mercurial installation folder, C:\Program Files (x86)\Mercurial.
However, when I update the hgweb.config file, all that happens is that the theme reverts to paper (the default). I’m obviously missing something, but I can’t find any information on the web that points to what I’m missing out. Effectively, bar the change to the header.tmpl to reference the style-monored.css file in the static directory, the only other change I’ve made is to change the monoblue colour in the css file to a red variation i.e. #006699 became #996600.
Anyone out there got any ideas on what I’m missing out on changing. I’ve also investigated my Python installation to see if there were any Mercurial references in it, but I couldn’t find any.
FYI: My Python installation is from the Windows (x86) specific Python-2.7.5.msi
My Mercurial installation is from the Windows (x86) specific Mercurial 2.6.2 MSI installer.
In my travels about the Googlesphere, I’ve discovered the following two websites that have "instructions" on how to adjust/edit Mercurial templates. I’ve followed these, but to no avail.
http://www.endswithsaurus.com/2010/05/setting-up-and-configuring-mercurial-in_3404.html
http://colas.nahaboo.net/Hacks/HgwebMercurialTemplateCustomization
Any help would be greatly appreciated.
Thanks.
UPDATE: I found the answer to my question. All the template files I was making changes to are ignored by Mercurial. The correct template files to copy and edit are to be found in the \Python27\Lib\site-packages\mercurial\templates directory. I chanced upon this when I was re-reading my installation documentation on an unrelated matter.
The answer to this question is that the template files that Mercurial references to modify the display are to be found in the \Python27\Lib\site-packages\mercurial\templates directory. I discovered this when I re-visited the documentation I'd created as I installed Mercurial onto my Windows 2008 R2 server.
I am using Jenkins for our build server. I have multiple projects using the same Mercurial (Hg) repository and want to avoid each project cloning it's own local repo to build from (since the repo is rather large). This is supposed to be possible via Jenkins and the Mercurial plugin.
In my Mercurial plugin configuration I have checked both "Use Repository Caches" and "Use Repository Sharing". In each project, the same repository location (a network location specified via IP address) is listed.
However, each project still seems to want to create a clone of the repository. Any ideas?
In our setup (using Jenkins 1.506), I've defined a custom workspace under the Advanced Project Options for each of my builds, typically at [project]\repo and then build from there into a \build\ folder.
If you define the custom workspace for each Jenkins project to point to the same shared custom workspace using the same source for the repo it will reuse what is already there.
I've not tested this, but I would assume that under this setup, it is important to prevent concurrent builds from occurring in the same working directory. Bad things would follow.
As a followup question: What is your rationale for not wanting each build to have its own source code?
I see a file in the root folder of my Tizen project called .rds_delta that contains what appears to be change commands for something. A Google search reveals nothing. Does anyone know what this file is for and if it should be kept in the Git repository, or should we add this to .gitignore?
.rds_delta file:
#delete
#add
#modify
res/wgt/author-signature.xml
res/wgt/config.xml
res/wgt/signature1.xml
It was a file that inform application installer what is changed in your app between one package build and second one. This is needed to quick application install from SDK.
Some official link: https://developer.tizen.org/development/training/native-application/application-development-process/running-applications
In my opinion it shouldn't be throw into Git repository.
Need some help adding a blog for this client in Silver stripe CMS.
The client is http://arborwinsys.co.uk/
and the SilverStripe version is - 2.3.7
Would it work installing this module?
https://github.com/silverstripe/silverstripe-blog
The git master branch that you are looking at contains changes for SilverStripe 3. To make the blog work with your SilveStripe version you'll have to go back to the blog module 0.4 or 0.3 by switching the branches.
Steps to adding the blog module to silverstripe 2.3
Download the .zip from https://github.com/silverstripe/silverstripe-blog/tree/0.3
(later versions of the module require later versions of silverstripe)
Extract the contents of the .zip file (it may be within one directory in the .zip file) to a new folder called "blog" in your silverstripe install (it should be at the root level - that is, it should be in the same folder as your "mysite", "cms" and "sapphire" folders
Run a /dev/build on your silverstripe install
Run a ?flush=all on your silverstripe site
if you have any issues:
Ensure you downloaded the correct file (later versions of the module will not work unless you update your silverstripe install)
ensure that you have extracted the files correctly:
e.g. if your website is www,mysite,com and you can access your admin from www,mysite,com/admin - you should have your files in www,mysite,com/blog
ensure you have done a rebuild on your site
try doing a flush
if all else fails, post the error you're receiving back on here.
Good luck!