Baseline Decisions - Githubissues

GeekOnCoffee commented 12 years ago

Maybe each of these should be a separate discussion topic, but for lack of clutter, I'm combining them for now. All of these are things which should be decided on before any code is written...

Supported Ruby Versions Supported Rails Versions Supported Databases HTML Templating Engine (HAML, ERB, Slim ?) CSS Templating (Compass, SASS, Less, ?) Javascript Transcomplier (Coffeescript, Pure Javascript, ?) Testing Framework(s)

GeekOnCoffee commented 12 years ago

My votes: Ruby 1.9+ Rails 4 (so tracking master for the time being) Relational (The Big 3) Haml Sass Coffeescript Minitest (I haven't used it, but hear it's awesome)

knewter commented 12 years ago

My votes:

1.9+
Rails 4
Postgres (but via a separate persistence layer, with persistence distinct from BL ala objects-on-rails groupthink / my recent experiments in this area)
Slim > Haml >>>>>>>> erb
Compass + sass without question
coffeescript
minitest/spinach (I have all kinds of data points suggesting it's the best damn thing evar) - also, a focus on expectation-based unit tests / adherence to SRP, and a nice and lengthy 'happy path' integration test suite with spinach/capybara :)

PS - yay something to disagree over!

johanb commented 11 years ago

My votes:

1.9+
Rails 4
Postgres (baseline) but obviously should support also Mysql
Erb or Haml (don't know HAML but willing to learn)
sass (scss syntax) unless we're going with HAML, then sass makes more sense.
Coffeescript

All flexible though.

gogogarrett commented 11 years ago

Pretty much agreeing with everyone else:

Supported Ruby Versions 1.9+ ( I prefer new ruby hash syntax over hash rockets)

Supported Rails Versions Rails 4 all the way

Supported Databases I'd vote for postgres

HTML Templating Engine (HAML, ERB, Slim ?) I know ERB like a champion, but I'm fine learning another. We need to remember that this could be another entry barrier for people to help contribute once we release. (most people at my company hate haml and might not use this cms simply for that fact)

CSS Templating (Compass, SASS, Less, ?) SASS ( with SCSS syntax )

Javascript Transcomplier (Coffeescript, Pure Javascript, ?) Coffee script all the way

Testing Framework(s) Anything but cucumber goes in my book.

parndt commented 11 years ago

1.9+ ( I prefer new ruby hash syntax over hash rockets)

Unfortunately I prefer hashrocket ;) FIGHT, FIGHT, FIGHT! But Ruby 1.9.3+ should be minimum.

Coffee script all the way

Agree

SASS ( with SCSS syntax )

SCSS because SASS is too far divorced from real CSS.

Supported Databases I'd vote for postgres

All of them...?

HTML Templating Engine (HAML, ERB, Slim ?) I know ERB like a champion, but I'm fine learning another. We need to remember that this could be another entry barrier for people to help contribute once we release. (most people at my company hate haml and might not use this cms simply for that fact)

I used to prefer ERB but now when I see things like this it makes me want to use HAML (or maybe just use view helpers/presenters):

<% if something %>
  <% if something_else %>
    <%= "foo" %>
  <% else %>
    <%= "bar" %>
  <% end %>
<% else %>
  <%= "Nothing found in your search" %>
<% end %>

It probably looks just as ugly in HAML, though. @robyurkowski posted a classic example once where he refactored the application layout in HAML and it was half as long.

johanb commented 11 years ago

Supported Databases I'd vote for postgres

All of them...?

As long as they are supported by AR I guess ? we're not doing the Mongo dance right ?

parndt commented 11 years ago

Supported Databases I'd vote for postgres

All of them...?

As long as they are supported by AR I guess ? we're not doing the Mongo dance right ?

This raises an interesting point.. we should abstract that stuff... right? By the way I don't believe in using AR by default.. I'd rather use DataMapper2 which has a mongo adapter which may be a little out of date.

johanb commented 11 years ago

I'm ok with Datamapper, my point was just that we should try to please all people by trying to support all databases, it's just going to lead to more headaches.

parndt commented 11 years ago

it's just going to lead to more headaches.

It's pretty easy currently to support Postgres, MySQL, SQLite.. I don't think we should go out of our way to support Oracle for example.. but it'd help to not use any hardcoded strings.

johanb commented 11 years ago

Sure, but Mongo/Couch etc are different beasts entirely.

GeekOnCoffee commented 11 years ago

I've had to hook things up to both Oracle and MsSQL... ActiveRecord worked fine, as long as you don't have hardcoded SQL Strings.

parndt commented 11 years ago

Right so I think the real takeaway right now is no hardcoded strings anywhere in afterburner or any afterburnercms.

knewter commented 11 years ago

I think something using DataMapper pattern makes a lot of sense here. Also, anyone in favor of pursuing a Clean Architecture / Hexagonal strategy here? I.e. separate the Domain Objects into their own project, defined using virtus (part of DM2), then define the mappings to actual persistence layers in the project that actually wraps the domain objects up into a full-on app (i.e. in the rails app, in an initializer, define the persistence layer mappings / repository patterns).

I am constantly in danger of making people scared to work on this project, but at the same time I think the Rails/Ruby community could use some examples of the upsides of these patterns. Otherwise I fear we will just run into the standard "welp, my rails app is six months old and now I can't run the tests without crying because it's so slow" dance. And/or run into the Rails Monolith problem.

Thoughts? Am I a crazy person?

knewter commented 11 years ago

I forgot to mention - one benefit of something like virtus is that you don't always find yourself talking from system to system in terms of standard types - i.e. you test against strings and bools a lot less in your app. Without having a shared domain model that's ubiquitous, it's hard to do good oop because eventually you end up doing string comparison instead of passing objects around.

parndt commented 11 years ago

I think we should continue this discussion about CMS concerns over at parndt/afterburnercms#2 as it's not related to the framework which won't interact with a DB at all, probably.

robyurkowski commented 11 years ago

Thoughts? Am I a crazy person?

You're Joe frickin' Biden, pushing the President to be a bit more librul. I love it.

And yes, closing this in lieu of parndt/afterburnercms#2.

grounded / afterburner

Baseline Decisions #7