Remodeling Four Kitchens: A look inside our new brand
With the additions of Advomatic and Manatí, we’ve had an exciting few years at Four Kitchens. While we’ve remained fundamentally the same organization, we’ve also been evolving into something new. It’s time for our brand to catch up.Learn more
A more modern, sustainable approach to higher ed websites with YaleSites
A higher ed website is a product, not a project. Learn about Yale’s sustainable approach to digital development and how your team can do the same.Learn more
News and insights from the Web Chefs
Filter by topic
- Being online
- Client stories
- Design and UX
- Digital strategy
- Immersive technology
- Industry report
- Office news
- Work life
Filter by type
Update from the Drupal 7 contributed modules sprint
chx and I gathered last week in Vancouver's West End for a two-person performance sprint during the final code slush days, allowing us to finish several key improvements to Drupal's database layer. Right afterward, many more people joined us for _another_ sprint to **port key modules to Drupal 7**. People worked in-person, voluntarily over IRC, and involuntarily over IRC (lost passport). I can say -- without reservation -- that our work was successful. We kicked off the weekend with Drupal 6 versions of Coder and Views. (Though there had been a touch of prior work on the Views port to Drupal 7's new database layer.)
No-brainer shared branch storage on your workstation
For me, my projects are code-based and, hence, mostly a collection of version-controlled branches. So, my "Projects" directory contains a smattering of branches organized into multi-level directory structures. In my last post, I noted that shared branch storage is the key to fast branching, good offline access, and efficient disk usage. I even covered a quick way to get it rolling for Drupal branches. But it's one thing to know how and another to know "best practices," so I'll share how I do things.
Enforcing branch commit atomicity (or, why the git staging area is bad)
With CVS, one of the only repository-wide atomic operations is tagging a local checkout. And not all that long ago, Subversion introduced mainstream users of free, open-source version control systems to full-scale atomicity. Or, at least the ability to be atomic.
Creating common branch ancestry is a hard problem
One of the key features of distributed version control systems (DVCS) is support for divergent development (branching) and then merging. Most DVCS tools, including Bazaar, include rather elegant support for such workflows by embedding metadata about common ancestry into branches. In this post, I'll be focusing on Bazaar.
Distributed version control provides a streamlined alternative to vendor branches
Anyone who's worked with a sufficiently large project eventually ends up establishing vendor branches to track and merge upstream releases. Maintaining these branches is time-consuming, redundant work because everyone who needs a vendor branch of a project needs approximately the same thing.
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!