I haven’t had the time to read through this yet, but wanted to keep a bookmark of it for reading later.
Historagraphy.io is a website that creates a timeline of historical events spanning 14 Billion years, sourcing it’s data from Wikipedia.
It’s an amazing website. You must check it out.
Great breakdown by Rarst. I was thinking about my own progression just the other day and thought I should write a post about it. Of course, I haven’t written anything, but for now I’ll share his post, and hopefully get around to writing my own reflection of how I’ve grown and progressed.
November 1-7 has been claimed as “Hug a Dev” week by WPEngine. Share some love, and possibly when a trip to WordCamp for a developer!
I’ve had to help maintain a few blogs that were built on Headway and it’s unbelievably frustrating to work with. I’m sure there’s some great things about it if you spend the time to get to know the ins and outs of it, but it’s pretty annoying to work with.
Today I spent some time migrating a blog away from Headway, and realized it’s even more annoying that I thought. I was trying to move some SEO data (meta descriptions and titles) and hunting down where Headway stores data was frustrating.
Instead of storing the data for posts in ‘wp_post_meta’ or ‘wp_posts’ like one would expect, Headway creates a new option for each post in ‘wp_options’ and stores everything as a searialized array under that option. I’m sure there’s some explanation on why it’s done this way, but it’s frustrating to work with if you’re used to traditional WordPress standards.
Again, I’m sure there are great things about Headway. I know they’re successful and have a strong customer base, but I find it frustrating to work with, and can’t personally recommend using it.
Came across this CSS “mindset” and just wanted to keep a link for future reference. Looks cool. (found out about it from The Meteor Chef)
I came across The Meteor Chef several months ago when I first started digging into Meteor, but at the time there wasn’t a whole lot of content on the site and I wasn’t deep enough into Meteor to find it extremely helpful at the time.
During the Meteor hackathon a few weekends ago, someone mentioned The Meteor Chef, so I checked it out and boy has it changed since I last checked it out.
It looks like it’s becoming an incredibly useful resource for Meteor beginners as well as advanced Meteor developers.
I can’t wait to dig in more and see what I can learn and put into practice.
I heard about a project called VersionPress quite some time ago. The idea of being able to manage WordPress data via .git in the same way files are easily managed sounded sweet. I’m constantly working locally, pushing to staging, waiting for client approvals, then deploying to production. But, in the time I work locally, sometimes people on the my team or the clients team have made changes to the staging site, and definitely to the production site. . .then typically the changes will sit on a staging server for who knows how long until the client gets around to approving things, and by that time it’s impossible to keep track of what’s changed on the production site in the mean time.
That’s a problem that a lot of WordPress developers face. I’ve seen some developers lock clients out of the production site until changes are approved on staging, but that doesn’t sound like a good solution. I’ve also been involved in meticulously comparing staging to production to make sure everything gets migrated appropriately and nothing gets unintentionally overridden. I use a plugin called Stream to keep track of all activity on production sites, so that way I can see what’s changed in the time I was working locally and on staging, but again it’s a difficult job to make sure nothing accidentally gets replaced, or set incorrectly, etc.
For a while, the only tool I knew of that attempted to solve this data versioning problem was RAMP by CrowdFavorite. While RAMP seems to have some good ideas, it seems to lack a lot of features that would make it useful enough for work I regularly do. It might be a great product and is probably very useful, but it doesn’t quite meet my needs.
VersionPress hasn’t quite met my needs either (I’ve never used it, just read about it), but today I saw that VersionPress 2.0 has been released, and it seems like they’re getting to a point that it will be an extremely useful tool that will solve a lot of issues I deal with on a regular basis.
I went and signed up for the Early Access Program and I’m anxious to check it out and see how it works.
At the moment it looks like a lot of the data versioning is limited to WP-CLI (which is fine with me), but it sounds like a GUI is in the works, which should make it easier for developers of any level to have more control over versioning WordPress.
I’m excited to see how it works and if it indeed can help ease the pains of working in multiple environments and ensuring things get deployed appropriately.
This past weekend I participated in a global distributed Meteor hackathon. I’m pretty new to developing with Meteor, so I didn’t expect to build anything crazy myself, but it was cool to see the submissions from across the world come in.
This app allows you to enter a REST Endpoint URL and it converts it into a live DDP stream for use in a Meteor app. Pretty cool if you’re familiar with DDP, and extremely useful. I’ve seen a lot of folks in the Meteor community looking for similar solutions, so it’s exciting to see something like this come out of the hackathon.
I’ve been tinkering with connecting Meteor to WordPress via the new WP-API, and this tool might make that a bit easier.
Details of REST2DDP can be found here, and it’s also on GitHub.
It turns out that I wasn’t the only person who thought the app was cool, as it won the hackathon! Congrats to the folks at OK Grow who put it together.