Here's part #3 in the series explaining our "full stack" at a high level. If you missed part 1, or part 2 make sure to give those a read first. If you prefer, you can read the long-form post with all the content in one. Again, feel free to call me on any technicalities or suggest changes/additions in the comments!
Welcome back to the pond! Last week we touched on the importance of mentoring juniors and Github best practices. In this week's episode, we'll be following up on the junior workflow from last week by discussing two tools you should definitely have and how to install them, exploring new ground by touching on some entry level SCSS techniques, sharing my AHA! and FAIL moments of the week, and lastly, our weekly query for you good people out there to ponder. So lets jump right into it shall we?
You may know about some of the problems that CSS has as a language. There is a lot of repetition. There is a lot of repetition. You may have worked on projects with 5000 lines of CSS. Not only is that a lot of code to write, but it's also a lot of code to maintain. But what about its smarts?
When we added the Compass CSS authoring framework to our projects, new wrinkles appeared in the deployment process. Committing the artifacts to Git was used for our first prototypes, but is unsuitable for team projects because it's a sure-fire way to introduce merge conflicts. Running compass on the server (either with Cap or the Drupal module) is appealing, but a minority of our projects deploy to hosts without the ability to install Compass. Rather than support multiple strategies, we decided on executing Compass locally on the workstation running Capistrano. Changes are needed to several files: