On Wed, Jul 22, 2015 at 3:09 AM, <cedric_at_jcplaboratory.org> wrote:
> Hello Vy-Shane,
>
> >2) Deploy the site as a read-only Docker container
>
> >We basically move the smarts from the page serving step to a publishing
> step that is performed off server. The server serves static pages from a
> read only-environment. It's a simple solution with very few moving parts,
> and a reduced attack surface.
>
> I agree this could be a good alternative but I would like to point out
> that some if not most of the companies did not build they own website. For
> examples: Harel Mallac Health Care[1] or even the website of the Open
> University of Mauritius are built by third-party firms.
> Are the developers there ready to implement these alternatives? Even on
> the request of their clients? Do they always build using the easiest blog
> engine available?
>
> Once I called DMS (the firm that build the website of [1]) he said that
> they build using popular CMS available: Joomla, Wordpress, Drupal etc.
>
> So my last question is do they build website using only the platforms they
> are used to in order to provide effective customer service after the
> website's construction?
>
> I haven't experiment with Jekyll. Is it as easy to maintain and managed
> as the popular CMS? Or does it require the know-how a web developer?
>
> All this aspects has to be taken care of before implementing new solutions.
>
> [1] http://www.hmhealthcare.mu
> [2] http://www.open.ac.mu
>
Jekyll and Docker are developer/devops tools. GitHub Pages [1] uses Jekyll.
The main userbase consists of developers.
In the context of a web agency building sites for their clients, you'd only
consider Jekyll if you'll be managing the content on behalf of the client.
Web developers currently often opt for a CMS in this case because it gives
them a nice templating engine. However, a traditional CMS also has some
drawbacks. Content is stored in a database. Which means that you need to
copy data across from development to staging to production when you need
clients to approve changes. When you do that, you typically don't want the
development or staging settings to be copied across to production; only the
content. In practice this means that content is sometimes copied and pasted
across. This is a bad workflow. Jekyll treats content as files on the
filesystem. Files can be checked into a source code repository, and
versioned. This fits very nicely into a development workflow.
As with any tool, you need to know when to wield it. Again, I'm not
advocating using Jekyll and Docker everywhere. I'm simply pointing out an
alternative solution that has some nice properties.
[1]:
https://pages.github.com
Received on Wed Jul 22 2015 - 01:45:50 PST