Can we create more vibrant intersections?
For the past two decades, the web has been a vibrant intersection of design and programming, a place where practices from art and engineering both apply. Though I’ve spent my career on the programming side – you don’t really want to see the things I design – I’ve loved the time I’ve spent working with designers.
Much of that time was frustrating, because I was frequently stuck telling designers that no, 1990s HTML couldn’t produce page layouts like QuarkXPress. The medium was different, with its own complications. However, as designers became familiar with the web, and found new ways to apply it, the conversations became richer and richer. Front-end web development became an amazing place where designers and technicians could work (and sometimes curse) together. Read more…
A closer look at the forces causing demand
Buzzwords in the software industry arise and then die off with startling frequency. Ambiguous terms such as “growth hacker”, “sales engineer” and “rockstar developer” trip a developer’s spidey sense that the person saying them is just handwaving. However, occasionally a new term is created to articulate a programming skill set based on demand due to changes in the software development industry.
In 2013 the search term “full stack developer” took off on Google Trends and began appearing in numerous tech startup job postings. In this term’s case there are several real trends driving developers to invest in learning and identifying as full stack developers.
The usage of the full stack developer term is driven by several larger trends in software development. Read more…
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?”