- Critical Making — essays from 70 contributors looking at the politics, choices, and ethics of a lot of the makery going on.
- Continuous Integration for Infrastructure — slides on the emerging tools for large-scale automated testing integrated into development and deployment workflow.
- Implementing Reproducible Research — book by Victoria Stodden and Johanna Cohoon on tools, practices, and platforms for making science that others can verify (another step in improving velocity and quality of scientific research).
Powering your app with open source and OpenShift
As a software developer, you are no doubt familiar with the process of abstracting away unnecessary detail in code — imagine if that same principle were applied to application hosting. Say hello to Platform as a Service (PaaS), which enables you to host your applications in the cloud without having to worry about the logistics, leaving you to focus on your code. This post will discuss five ways in which PaaS benefits software developers, using the open source OpenShift PaaS by Red Hat as an example.
No More Tedious Config Tasks
Most of us don’t become developers to do system administration, but when you are running your own infrastructure you end up doing exactly that. A PaaS can take that pain away by handling pesky config and important security updates for you. As a bonus, it makes your sys admin happy too by allowing you to provision your own environment for that killer new app idea you want to tinker with, rather than nagging them for root access on a new VM.
On OpenShift, it goes like this: let’s say you decide you want to test an idea for a Java app, using Tomcat and PostgreSQL (yes, we could argue about the merits of those choices, but work with me here). You can spin that up with a one-line terminal command:
rhc app create myawesomeapp tomcat-7 postgresql-9.2 -s
That -s on the end is telling the platform to make the app auto-scaling, which I will elaborate on later; yes, that’s all it takes. RHC (Red Hat Cloud) is just a Ruby Gem wrapping calls to the OpenShift REST API. You could also use the OpenShift web console or an IDE plugin to do this, or call the API directly if that’s how you roll. The key technologies in play here are just plain old Git and SSH — there’s nothing proprietary.
Tips and tricks to squeeze the most out of your mobile UI
Editor’s Note: Mobile HTML5 is a book by front-end engineer and frequent speaker Estelle Weyl. It is packed with hands-on examples to make you a stronger web developer–including best practices for SVG, Canvas, and CSS3 tailored to fit mobile devices. In the excerpt below, Estelle walks you through five easy things you can do to improve battery life in your mobile web apps. As throughout the book, the tips she provides come from her own real-life experience with these technologies.
Unlike desktop computers that are tethered to the wall at all times, and even laptop computers that are generally used by stationary users, mobile users do not recharge their devices throughout the day. Mobile users expect their devices to last, at a minimum, 24 hours between recharging.
Your users do realize that calls and GPS usage consume battery power. However, if they think they’re just using their browser to surf the Web, they don’t consider that different websites will drain their battery faster than other sites. It is our job, as developers, to manage the power consumption of our code. Read more…
Decorating content may no longer be enough
Thousands of people invented it independently. Millions use it without thinking about a broader context. It’s time to name it so we can talk about it.
Transformation is changing the way we look at the balance between clients and servers, our approach to formatting and layout, and our expectations of what’s possible on the Web. As applications shift from transformation on the server toward transformation on arrival on the client, transformation’s central role becomes more visible.
These practices have been emerging for a long time, in many different guises:
- In the Dynamic HTML days, scripts might tinker with the DOM tree as well as modify CSS presentation.
- Transformation was supposed to be a regular and constant thing in the early XSLT plans. Stylesheets on the client would generate presentation from clean blocks of XML content.
- New data format options evolved at about the same time that Ajax emerged. JSON offered a more concise set of programmer-friendly content tools. Many apps include a ‘bind JSON to HTML before showing it to the user’ step.
- Template systems now run on the client as well as the server. In many systems, templates on the server feed data to the client, which applies other templates to that data before presenting it to users.
- The HTTP powering Ajax still created a long slow cycle of interaction. WebSockets and WebRTC now offer additional approaches for collecting content with less overhead, making it easier to create many more small transformations.
- Some developers and designers have long thought of the document tree as a malleable collection of layout boxes rather than a deliberately coherent base layer. Separation of concerns? A dead horse, apparently. Recent debates over CSS Regions highlighted these issues again.