When ActiveRecord just isn’t enough
In Just Enough Arel, we explored a bit into how the Arel library transforms our Ruby code into SQL to be executed by the database. To do so, we discovered that Arel abstracts database tables and the fields therein as objects, which in turn receive messages not normally available in ActiveRecord queries. Wrapping up the article, we also looked at arguments for using Arel over falling back to SQL.
As alluded at the end of the previous article, Arel can do much more than merely provide a handful of comparison operators. In this post, we’ll look at how we can call native database functions, construct unions and intersects, and we’ll wrap things up by explicitly building joins with Arel.
Adding consistency to Kivy's Python UI tools
Kivy has a wonderful set of built-in widgets that can be extended in numerous ways. They have very useful behaviors, but their look and feel may not integrate well with your App or the platforms you are targeting. Kivy doesn’t support theming out of the box right now, but if you poke around enough, there are a range of options you can use to customize the default look of widgets without having to define your own inherited versions of them.
I’ll first introduce you to Kivy’s image atlases, which are less mysterious than they sound, and are important groundwork for understanding theming in Kivy. Then you’ll learn two different ways to do manual theming in Kivy, with an eye to future automation.
To understand theming, you must first understand atlases. An atlas is essentially a collection of distinct images combined into a single image file for loading efficiency. A JSON file describes the location of the separate images inside that master image file so that Kivy can access them directly. If you’ve ever worked with CSS sprites, you know exactly what I’m talking about. If you haven’t, the following example should explain everything.
Never forget to clean up again!
Close the door!
Here we have a Ruby class representing a refrigerator. Prior to accessing a refrigerator object’s contents via its
contents method, you have to call its
open method to open the door. (Sensible enough.) Read more…
Not just for code anymore
Do you really want a technical book for your project? Does your community need to provide more helpful docs to support even more users? Does your community have a lot of knowledge they need to get out of heads and into bits and bytes? Do you have a good mix of technical experts and technical writers and users who would enjoy each other’s company for a week of hard work?
If the answer is yes, then consider a book sprint. If you’re in the open source world, you may have heard of a code sprint. A book sprint is a similar event, with an intense collaborative authoring session time boxed by a few days or a week. People get together typically in person to author and complete a book in a week.
Generally speaking it’s best if you have an idea of the scope and audience for the book prior to holding the sprint. These discussions can take place on line, such as on a mailing list or in a wiki page or Etherpad. You can also meet with future collaborators regularly, but understand, the first day of your sprint your book will certainly take shape. As book sprinter Adam Hyde says, “While you may not know the exact book you want when you go into the sprint, by the end you will have the book you need.”
For the OpenStack Operations Guide, we held a five-day book sprint in February 2013. OpenStack releases every April and October, and this timing was nearly halfway between two release dates. With Adam as our facilitator, seven authors agreed to work together and we nervously awaited our fate. We asked, “Could we complete a book in a week?”
Common behavior to watch out for when transitioning to a PaaS
Today I am going to cover 5 ways developers may be on a Platform as a Service (PaaS) but have not really embraced the new platform effectively. If you have done any of these things below while building your application hosted on a PaaS, like OpenShift, Heroku, or Google App Engine, don’t feel bad:
- PaaS is a relatively new concept in the development world and I think some of these patterns are only recently coming to light
- I have seen veteran developers making these mistakes as they move to the new paradigm
One piece of terminology I will use throughout the article is container. When I am using this word I am referring to the piece of the PaaS that hosts the application and does the work. An application can be composed of multiple containers and the PaaS will probably have a method to add your favorite server-side tech to the container. On OpenShift this is called a gear while on Heroku it is called a dyno.
So without further ado, let’s dig in on some of the code smells in the cloud.
Making forking the norm
Forking another spec: generally less than ideal. Spooning w another spec: weird. Knifing another spec: generally indicative of larger issues
— вкαя∂εℓℓ (@briankardell) April 28, 2014
— Kip Hampton (@kiphampton) April 28, 2014
Free and Open Source software licenses make forking legal. Git makes forking easy. GitHub makes it easy to fork sociably. Can we just make this normal?
Meanwhile, in a reminder that specifications can fork too, Ian Hickson put his objections to the W3C forking a WHATWG spec on www-archive to make sure his complaints of plagiarism would be part of the permanent record. WHATWG specs are licensed CC0, so once again, it’s legal.
It seems to be a common pattern to want to grant rights, but only want other people to use those rights if they acknowledge our control. (I sometimes have similar tendencies, granted.) We hope that people will contribute to our works while recognizing our power and our ownership over those works. Even the fact that we have to choose licenses at the start of a project gives us a sense of ownership and control, often hiding the (excellent) lack of control that comes once those licenses are applied.