I’ve integrated rsync with in my gruntfile via grunt-rsync-2 https://github.com/MaxDaten/grunt-rsync and been wanting to ask you if the order of the arguments passed to rsync matters.

This grunt tool adds the checksum parameter as the last one. From what I read on the man page it doesn’t matter. Only the order of filter arguments is important, like for includes/excludes. Just wanted to double check with you.

-r,-p,–delete,–delete-after,-z,-c,

When I was at the man page I discovered this:

−−delete

This tells rsync to delete extraneous files from the receiving side (ones that aren’t on the sending side), but only for the directories that are being synchronized. You must have asked rsync to send the whole directory (e.g. “dir” or “dir/”) without using a wildcard for the directory’s contents (e.g. “dir/*”) since the wildcard is expanded by the shell and rsync thus gets a request to transfer indi- vidual files, not the files’ parent directory.

So now I’m wondering if wouldn’t be better if you remove that asterisks. It reads as if you render the delete argument useless by using it.

rsync -crz –delete _site/* user@host:~/site

Cheers,
Patrick

I respect the tech.
But I decided to use Weebly. Like a boss.

@ Agn0sis:

I think they say that “mastering” anything takes roughly two years of daily practice. Granted, with programming you always tend to be chasing moving targets and shifting paradigms, which is one of the many reasons programming sucks. :P

But I find it helpful to think about things that way: mastery is just a matter of practice. No matter what you do, you are going to suck at it at first and you are going to spend a lot of time googling things, and being baffled. But the more you do it, the smoother it gets.

@ IceBrain:

I could have made it much simpler on myself, but for some reason I like to build these things from scratch. Jekyll does have pretty sane defaults. The new default template in 2.0 is actually really nice. You can just do:

jekyll new mywebproject

What you get is pretty much good to go as far as a simple blogs go. I added complexity to the project myself mainly because:

– I wanted bootstrap and responsive grid and jQuery
– I wanted to host the above dependencies locally and not from a CDN
– I wanted to manage my dependencies with bower
– I wanted to use Grunt to minify and concatenate my css/js assets
– I chose not to use Yeoman for all of the above
– I wanted to write the HTML from scratch rather than use a pre-made template

If I didn’t want to do any of the above, I could just generated a new basic site and tweaked the standard Jekyll template until I was happy with it.

Thanks for mentioning Hugo. I have not heard of it before. :)

Ouch, that sounds involved; I’ve used another generator in the past; being a Python guy and since I often like to mess with my tools, I went with Pelican instead, and I don’t remember needing all that configuration. Then again, I barely touched the default templates.

Regarding the long compile times, I hear Hugo is blazing fast; they talk about generating whole sites in just miliseconds.

Well, that was a long response, thank you for your time. Yeah, I thought that your approach would be to take a little from here and there. It is just that there is so much information that I didn’t wanted to end in a shitty site giving terrible advice and bad practices. Anyway, sometimes I ask myself if I actually master any languages at all, or if everything I do is learn enough from each tool to get something functional … in fact I don’t even know if that is a good or a bad thing. Man, this world is huge and we have so little time!

@ Agn0sis:

Hmm… Good question. I don’t really know what would be a good starting point since I tend to just pick up things by reading random articles on the web, and just by doing things. That said, CodeCademy tutorials are extremely accessible for just learning basics of HTML5/CSS3 or Javascript.

Some of the stuff I was talking about above are just best practices and stuff. For example, Twitter Bootstrap is basically a bundle of CSS and Javascript files that define things like fancy buttons, responsive grid and etc.. So instead of lining up headers and sidebars by hand, I just put each in a div, give that div the right class name, and it snaps into place. So I build on a solid skeleton.

Since Bootstrap is a bundle of files, it stands to reason to use a package manager to handle installing it. That’s where Bower comes in. It’s basically apt-get for web stuff. All you need to do is bower install bootstrap and it will download all the bootstrap files and dependencies (such as jQuery) and put them into a folder in your project directory.

Then there is Grunt which is a build tool for web designers which lets you lint (or syntax check) your Javascript and CSS and then minify and concatenate it for fast loading.

Then there are tools like Yeoman which wrap around all of the above, and provide generators that will scaffold websites for you. So you can just be like yo webapp and 30 seconds later you get a basic website with HTML5, Bootstrap (or another framewrk) scaffolded out for you right there in the folder.

Honestly, just reading the Yeoman page you can learn quite a bit about modern web development workflow. Just read what they provide, and any time you see something unfamiliar, google/research that. At fist it might feel like tumbling down a rabbit hole but eventually you’ll come out with better understanding of how people build websites. Because this was a tool build to abstract all the boring stuff away and get you from 0 to passably looking website skeleton in less than a minute, so that you can spend time drafting out ideas rather than futzing with config files for hours.

Which is something I still like to do from time to time, because it helps me to understand how these tools interact, and it makes me feel like I have more control over the underlying structure of my page.

@ Chris Wellons:

Yeah, hardlinks would work great, though it seems like they are pretty invested in running well on Windows and don’t want to diverge the codebase to much. :(

I was thinking that if my multimedia folders become too huge I will just rename my img/ directory to _img and then eschew jekyll serve -w and instead use a build script like:

jekyll build
ln _img _site/img
grunt serve

Or something like that.

@ Luke Maciak:

I offload my large files, such as videos, onto S3. This speeds up my build slightly, but I mainly do it to avoid using too much space on my GitHub account. That’s probably not very managable for lots of small files, like I suspect you need. (Just how do people organize their CDN content?) Unfortunately I don’t know what else you could do to speed up Jekyll in this situation.

Looks like there was a discussion about using hardlinks. This would certainly speed things up, but apparently nothing came of it because, checking now, I’m not seeing any hardlinks in my output.

Hey Luke,

I haven’t done any web development in like 10 years. Could you suggest me where to start? HTML5? Javascript? Any good book/site recommendation. I don’t know if the official documentation would be the way to go.

Thanks

@ Chris Wellons:

Yeah, there are a lot of little quirks here and there. Also, if you are not careful with the encoding of your markdown documents Jekyll may get confused with respect to excerpts. The few posts I created on Windows, defaulted to DOS line endings and the Windows version of Jekyll compiled them as they should. Then I compiled same documents on Ubuntu and Jekyll displayed full posts on the front page because it was looking for \n\n to indicate the end of the excerpt. :P

Any suggestions on how to deal with large image folders? I’ve been adding image galleries to the site, and each of them is between 10-30MB which is not a lot, but they have started adding up lately. The performance is not terrible yet (about a minute or two to compile the site) but I suspect it will get much, much worse as I add content. How do people deal with multimedia assets?

I’ve been using Jekyll for almost three years now. I’ve reported in the past that page builds had gotten painfully slow: several minutes for just a couple hundred blog posts. Fortunately it’s gotten a whole lot better over the past year. With 265 posts it only takes a few seconds. Running a giant blog like Terminally Incoherent on Jekyll is probably now practical.


$ time jekyll build
Configuration file: ./_config.yml
Source: ./
Destination: ./_site
Generating... done.
real 0m7.688s
user 0m4.968s
sys 0m0.308s


A third of the time is spent on I/O (with full-disk encryption) with output currently at 117MB.

The real gotcha now is that Jekyll will quietly break backwards compatibility. You’ll probably have to revisit your configuration after some of the updates to update it along with Jekyll. Suddenly the same exact site that built fine yesterday won’t build today. The Liquid and Markdown syntax changes subtly in undocumented ways as the parsers are tweaked. Sometimes it impacts dozens of posts (for me), requiring manual fixing. Most of the time this isn’t actually Jekyll’s fault directly, but rather Maruku or Liquid or some other dependency.