Fresh from Afton Field Farm: four dozen eggs, pork shoulder, pork chops, a chicken, and pork breakfast sausage. We almost need another freezer.
Idea: WordPress plugin for wp-cli so I could use the latter in the WordPress admin. Like Hopscotch, but installed on the site instead of as a browser extension. A sort of power user mode for the WordPress admin.
P2 By Email v1.0 released. New plugin lets you get instant email notifications of all new posts and comments, reply by email to those notifications, or create new posts by email.
One of my favorite recipes from Leah’s mom: nograinola. It’s delicious, wholesome, filling, and, hence the name, a grain-free granola. Some day, Leah and I will finally get around to picking another name for it and starting a wildly successful food company. Until then, and because Siobhan is asking for Paleo recipes, you can make it for yourself.
Preheat oven to 275 degrees Fahrenheit.
In a large bowl, combine nuts, seeds and coconut flakes. Stir until well combined. In a small bowl or 2-cup Pyrex measuring cup, mix coconut oil, honey, vanilla extract, cinnamon and nutmeg, until well blended. Pour oil and honey mixture over nuts and seeds and stir with a large spoon or your hands until everything is well coated.
Spread mixture out evenly on a jellyroll pan (cookie sheet with sides) and bake at 275 for 1 hour, stirring every 15 minutes. Remove from oven and stir in dried fruit. Let cool completely and store in an airtight jar.
- 1 cup raw cashews, chopped
- 1 cup raw walnuts, chopped
- 2 cups sliced almonds
- 1 cup raw pumpkin seeds
- ½ cup raw sunflower seeds
- 2 cups unsweetened coconut flakes
- ½ cup melted coconut oil
- ½ cup honey (or ¼ cup honey and ¼ teaspoon liquid stevia)
- 2 teaspoons vanilla extract
- ½ teaspoon ground cinnamon
- ¼ teaspoon ground nutmeg
- 1 ½ cups dried fruit (raisins, cranberries, cherries, chopped apricots, chopped dates, etc.)
An idea: Use creation of WP_Error objects as a way of tracking application exceptions. If WP_Error had an action in the
__construct() method, you could easily
error_log() WP_Error codes and messages.
Can someone tell me why this is a bad idea (other than exploding your error log), or whether there’s a better approach?
Automattic has claimed ownership of the plugins I worked on during my employment. As such, the VIP team and others will be taking responsibility for their continued development, maintenance, WordPress.org support, etc. Hopefully they remain independent and aren’t rolled into Jetpack. I’ll contribute as relevant to Human Made projects, but will no longer take an active role with the plugins.
These plugins include:
- Edit Flow
- Co-Authors Plus
- Ad Code Manager
- P2 Resolved Posts
- Document Feedback
- Rewrite Rules Inspector
Sometimes what appears to be a curse is actually a blessing in disguise. Human Made has pretty neat products in the works that I’m enjoying applying my creative energy towards. Stay tuned for that. And, on the open source side of things, I’ll have more time to contribute to wp-cli.
To everyone who’s used one of the above: it’s been a pleasure working with you. I’m looking forward to the opportunity to do so again in the future.
Advantages of pre-deploy code review, over post-deploy audit:
- Authors have a strong incentive to craft small, well-formed changes that will be readily understood, to explain them adequately, and to provide appropriate test plans, test coverage and context.
- Reviewers have a real opportunity to make significant suggestions about architecture or approach in review. These suggestions are less attractive to adopt from audit, and may be much more difficult to adopt if significant time has passed between push and audit.
- Authors have a strong incentive to fix problems and respond to feedback received during review, because it blocks them. Authors have a much weaker incentive to address problems raised during audit.
- Authors can ask reviewers to apply and verify fixes before they are pushed.
- Authors can easily pursue feedback early, and get course corrections on approach or direction.
- Reviewers are better prepared to support a given change once it is in production, having already had a chance to become familiar with and reason through the code.
- Reviewers are able to catch problems which automated tests may have difficulty detecting. For example, human reviewers are able to reason about performance problems that tests can easily miss because they run on small datasets and stub out service calls.
- Communicating about changes before they happen generally leads to better preparation for their effects.
WordCamp Portland 2013 Call for Speakers. Git yer video applications in.