Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CMS Trap

hakunin.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: CMS Trap

#31

Post by hakunin »

Breefield wrote: post #30
icedog wrote: post #29

Earlier quoted context omitted.

The article is stating that developers should lean towards going static versus using any content management system. Would you like to provide a meaningful comment about how Prismic voids this author's argument?

[edit] Apparently we may both be on the wrong page: https://twitter.com/hakunin/status/405874291100901376 Prismic allows you to "go static" for very little dev cost. Your content creators get a nice editor and can publish their content as needed, effectively making it static for you (the dev), as though it went through a build script (Jekyll or something "static"). The CMS gets out of your way, and you get to concent…

I should've made it clearer, sorry. When referring to CMS in the article, I refer to the wider meaning of a content management system, the code that you write as a developer of your own site, which happens to manage your content. Not a CMS that one could download and install.

Re: CMS Trap

#32

Post by platz »

AsymetricCom wrote: post #21
kenster07 wrote: post #2

Love of complexity is a programming disease.

Complexity can signify a complex problem on a simple domain, or a simple problem in a complex domain. You simplify one place, you're just pushing the complexity somewhere else.

That's why there's a distinction between 'accidental' complexity (poor architecture) and 'intrinsic' complexity (unavoidable)

Re: CMS Trap

#34

Post by ahoge »

ams6110 wrote: post #20
ahoge wrote: post #18

Earlier quoted context omitted.

> A pretty web interface isn't a must-have requirement. According to most definitions of "CMS", it is. With static website generators, editing, versioning, publishing, etc is done externally. They aren't systems which encompass all of this. They just punch some content into your templates and write the result to disk. That's all they do.

Are there any CMS that have a "pretty web interface" ? From what I've seen of Drupal, the interface exposed to content creators is awful. It works (mostly), but it ain't pretty.

Oh, you.

Re: CMS Trap

#35

Post by jacques_chester »

AsymetricCom wrote: post #21
kenster07 wrote: post #2

Love of complexity is a programming disease.

Complexity can signify a complex problem on a simple domain, or a simple problem in a complex domain. You simplify one place, you're just pushing the complexity somewhere else.

I optimistically called this Chester's First Law of Complexity:

   Essential complexity in the problem domain is a conserved quantity.
The idea being that someone, somewhere, always has to pay the piper for any given architecture. It might be paid at write time, or at read time. By the server or by the client. By the programmer or the sysadmin. By the compiler guy or the programmer. By the code that defines the data structure or the code that relies on the data structure. But somebody always pays the toll.

Then I found out that Larry Wall had beaten me to it with the pithier much pithier "Waterbed Theory". Kolmogorov partly so with the somewhat less pithy Kolmogorov Complexity.

Re: CMS Trap

#36

Post by na85 »

>A CMS Trap is a state of a web-application in which the development of content management systems is obstructing the development of the content.

I think this pretty neatly summarizes my experience working with Drupal.

Re: CMS Trap

#37

Post by rbanffy »

ams6110 wrote: post #20
ahoge wrote: post #18

Earlier quoted context omitted.

> A pretty web interface isn't a must-have requirement. According to most definitions of "CMS", it is. With static website generators, editing, versioning, publishing, etc is done externally. They aren't systems which encompass all of this. They just punch some content into your templates and write the result to disk. That's all they do.

Are there any CMS that have a "pretty web interface" ? From what I've seen of Drupal, the interface exposed to content creators is awful. It works (mostly), but it ain't pretty.

I like Plone a lot - it mixes the admin with the site itself.

Re: CMS Trap

#38

Post by foz »

From an architecture point of view, I'm convinced that the CMS is better treated as a service, and not as part of your web application. This is especially true in a larger organization where content needs to be collected and managed in different ways (via import, or where people edit or curate content).

At the start of this year, the company I work at had about six different CMS platforms. Many of the applications that used them were built on top of CMSs, and were tightly coupled to them. As for static content generators, we tried that. It really didn't scale, especially for dynamic content. Too many hacks, deploys, and hard to train people.

As of today, our team has switched nearly all public content for our company to LocomotiveCMS (http://www.locomotivecms.com/), and deployed a centralized multi-tenant system. In many cases, we use our Locomotive instances as an API, pushing content via the API or the command-line tool, wagon. The CMS then renders HTML templates (or even JSON), which are consumed by our applications via HTTP. Sometimes it's just a tiny part of a page, or sometimes entire mini-sites. As a result, most of our apps don't need to know about a database.

Whenever there's a change that requires a new model, or the addition of a field, it can be done quickly through the LCMS back-office UI (or the wagon CLI tool). We update the application(s) affected, and re-deploy. Non-techies can edit the content using the admin web UI in a familiar way.

In any case, it's been working really well for us. The CMS has become an API, a service, and a separate app, shared by many applications. We've become more flexible and efficient as a result, our web applications are no longer burdened by CMS frameworks or admin interfaces of their own. And we dont have to struggle with Sharepoint or Wordpress or any other nonsense.

It's been a fundamental shift in how we think about the CMS, and has scaled well across multiple projects.

Re: CMS Trap

#39

Post by vinceguidry »

I wrote an app for my company to extract data from the database and form xml feeds for various e-commerce services. I took the opportunity to learn OO principles and read through Object Oriented Design in Ruby.

What I eventually came up with was pretty much exactly what this post is advocating for. YAGNI was the rule, I was new and wanted to demonstrate results quickly. Instead of classes, I put constants in modules, realizing that all that a class I'd written was holding was basically a hash, and since that data wasn't changing anytime soon, they might as well go in a constant.

I caught the refactoring bug sometime around when I was tasked with adding a third service. I found turning the logic I'd created into proper classes incredibly easy, make changes, run rspec, rinse, repeat. The interfaces between the various pieces were surprisingly loose. So I could play around with different implementations of a piece of logic and at every point have something that could be made to work if I suddenly had to shift gears.

I had two services and they were each slightly different. Waiting to build the abstractions until I had multiple implementations of them wound up being a big win. Now that I have a third, I can already tell that it's going to be an easy add. I spend much more time figuring out service-specific stuff than wrangling with my code.

Hard-coding really does get a bad rap. You're not building a castle, you're fixing a pressing business need. If you do it well, then one day you'll be able to open-source your work, because your company will want to add more and more to it because of how badass it is. Not because your delusions of grandeur led you to over-abstract everything to the point of uselessness.

Re: CMS Trap

#40

Post by patio11 »

Pitarou wrote: post #22
patio11 wrote: post #7

Earlier quoted context omitted.

If you're making PPC pages, host them statically somewhere. I'd counter recommend this. In my limited experience with it, dynamic PPC landing pages are so effective as to be almost cheating. BCC's AdWords campaigns are not doing well in 2013 for what I believe are unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make URL #1 and URL #2 roughly the same today but will automatically switch URL #…

Can I check I've understood you right, Patrick? You have some code that infers from usage that, for instance, civil rights cards are popular in late January (Martin Luther King Day is on January 20th)? Neat! :-)

Right idea, but I'm not sure it would work for your example. MLK Day for the longest time didn't work correctly. I had a string tied around my finger about that bug for 3 years, can't remember if I squashed it in January or not.
Post reply on HN