"Code" entries
Software engineers must continuously learn and integrate
Four ways programmers can thrive in their careers.
As O’Reilly continues to build and assess our programming content ecosystem — now more than 30 years in the making — we have gone from covering a few key languages, operating systems, and concepts to a diversification of topics that would have made an editor’s head spin in the 1980s. Our goal, however, remains the same: to continue to provide practical content from experts who help you do your job. An important piece of that goal is to keep you informed as we interpret the trends on the horizon. What follows are a few of the core themes we are focusing on at the moment. Expect these to evolve and change with the speed of innovation.
You can also stay in the loop on the latest analysis and developments through our weekly Programming newsletter.
Actually be a software engineer
The term “full-stack” first emerged in a 2008 blog post (the original post is no longer available, but an archive is published here). The term perhaps reached its canonical definition in a post by Facebook engineer Carlos Bueno. He wrote:
“A ‘full-stack programmer’ is a generalist, someone who can create a non-trivial application by themselves. People who develop broad skills also tend to develop a good mental model of how different layers of a system behave.“
Whether you are striving to be a full-stack programmer, a T-shaped engineer, or you choose to rebuff those terms entirely as mere marketing, what now floats around as a “full-stack developer” definition is incomplete. Read more…
Yes, CSS is code
Learning from "The Humble Border-Radius"
One of the best things I overheard at the Fluent Conference was (more or less):
“CSS live coding? I was like, that isn’t code. But then it was.”
Lea Verou had changed the mind of a skeptic.
CSS is not Turing complete (Update: Lea points out that I’m wrong about that), and I’ve long been grateful that it wasn’t designed as an imperative programming language. It can be too much code for designers, too little code for programmers, and yet it’s code.
I think about the graphics work I tried to do with shapes and sprites and assorted kinds of vectors over the years, and then watch this keynote. Even with the glitches and coming improvements she notes, it’s clear that whatever tools I was using at the time, they weren’t declarative enough. (I’d also just seen this JSFest talk on CSS box-shadow by Vince Allen, so I was looking forward to more CSS graphics magic.)
7 ways to be a better programmer in 2014
Great tips to help you sharpen your skills
Coders make resolutions, no? If your to-do-better list is still empty, consider these ideas from other programmers to put to use in the New Year. Even the smartest folks have room to grow. The following excerpts are contained in the book 97 Things Every Programmer Should Know edited by Kevlin Henney.
The Programming Industry: Not a Woman’s World – Yet
A Frank Talk about Women in Programming with the Founder of CodeChix
Rupa Dachere (@rdachere), Founder and President of CodeChix, and I had a chance to talk programming and open source community culture at OSCON 2013. She brings up some great points about the specific problems that arise for women, talks about why she brought CodeChix to life, and what we can all do to make the programming community more diverse.
Key highlights include:
- Women face unique challenges: Time, Resources, and Support [Discussed at 0:18]
- And, there is support, for instance, CodeChix has refresher courses and tech talks [Discussed at 0:50]
- The CodeChix origin story [Discussed at 2:36]
- Cultivating positivity [Discussed at 4:02]
- Eighteen month outlook – some companies are talking but others need to join the conversation [Discussed at 4:57]
You can view the full interview here:
Will Developers Move to Sputnik?
The past, present, and future of Dell's project
Barton George (@barton808) is the Director of Development Programs at Dell, and the lead on Project Sputnik—Dell’s Ubuntu-based developer laptop (and its accompanying software). He sat down with me at OSCON to talk about what’s happened in the past year since OSCON 2012, and why he thinks Sputnik has a real chance at attracting developers.
Key highlights include:
- The developers that make up Sputnik’s ideal audience [Discussed at 1:00]
- The top three reasons you should try Sputnik [Discussed at 2:46]
- What Barton hopes to be talking about in 2014 [Discussed at 4:36]
- The key to building a community is documentation [Discussed at 5:20]
You can view the full interview here:
Six Ways to Make Your Peer Code Reviews More Effective
OSCON 2013 Speaker Series
NOTE: If you are interested in attending OSCON to check out Emma Jane’s talk or the many other cool sessions, click over to the OSCON website where you can use the discount code OS13PROG to get 20% off your registration fee.
The critique is a design school staple. You can find more than a few blog posts from design students about how “the crit” either made them as a designer, or broke their will to live. Substitute “critique” with “code review” and you’re likely to find just as many angst-filled blog posts in the open source community. Or, more likely, you’ll notice a lack of contributors following a particularly harsh text-based transaction.
Somewhere along the way we dropped one of the original meanings of the word “critique”. According to Wikipedia, a critique is “a method of disciplined, systematic analysis of a written or oral discourse”.
A good critique is more than just a positive feedback sandwich that wraps “negative” feedback between two slices of “positive” feedback. An effective critique needs to have three components in place to be successful:
- An agreed-upon framework for the evaluation.
- Reviewer objectivity.
- A creator uncoupled from his or her work.
The Quantitative Review
Quantitative reviews are the easiest to conduct. And, generally, coding standards for a project are quantitative. A quantitative review answers questions such as: Is this code formatted according to coding standards? Does the code cause any performance regressions? Quantitative evaluations can be easily measured. The code being reviewed is either right, or non-compliant. The findings of quantitative reviews are generally hard to argue with. (Ever tried to pick a fight with Jenkins?) Having a quantitative framework in place often means that your project will also be able to free up reviewer time by putting automated tests in place. Which leaves time for a more difficult type of review: the qualitative review.
The Qualitative Review
A framework for a qualitative review is incredibly difficult to create because there is space for subjective thought as it addresses the values of a project. There is room for opinion. Two people could be right at the same time, even though they are not at all in agreement. Qualitative frameworks are so difficult to create that most projects don’t even try; however, an effective qualitative framework helps both the coder and the reviewer to improve their skills. A qualitative framework teaches non-experts what attributes they should be looking for in the code they are reviewing. Questions posed during a qualitative review may include: Does this code implement a pattern we’ve already seen somewhere in the project? Has the code been sufficiently abstracted to make it reusable in other situations?
Building Windows 8 Apps, Hadoop Developer Track Course, Write/Speak/Code, and More
Tech events you don't want to miss.
Each Monday, we round up upcoming event highlights from the programming and technology spaces. Have an event to share? Send us a note.
Zero to App in Two Weeks webcast: Kraig Brockschmidt shares lessons learned to help you improve your productivity and app-building efforts when programming Windows 8 apps in HTML, CSS, and JavaScript. Register for this free webcast.
Date: 10 a.m. PT, May 21 Location: Online webcast
Apache Hadoop Developer’s Track – 1 Day Course: This Big Data Cloud University class reviews Hadoop’s essential server components and details its relation to MapReduce, Hive and Pig programming. Course instruction includes hands-on labs. For more information or to register, visit the class website.
Date: 8:30 a.m. to 5:30 p.m. PT, May 25 Location: Los Angeles, CA
Make It Simple: Architecting Your JavaScript Applications for Testability
Mark Ethan Trostler tests a lot of small pieces rather than giant hunks.
Mark Ethan Trostler (@zzoass) writes and tests code for a living, currently at Google. The veteran coder and author of Testable JavaScript recently delivered a comprehensive lesson on writing and maintaining testable code to some 400 folks from around the globe. In one hour Trostler detailed methods for swapping implementations, writing tests once, and working/testing in parallel.
You’ll probably want to watch his free webcast from beginning to end, when Trostler answers a handful of audience questions. (Registration required). Here are some of the key points from the recording:
- What is testability?
- It all boils down to writing and syncing interfaces, not implementation
Drupal for Designers
Dani Nordin on what you need to know
Dani Nordin (@danigrrl) is an O’Reilly author (Drupal for Designers) and UX designer.
We sat down recently to catch up on her current projects and her predictions for the future of Drupal design. She shared some best practices for designing, her experiences with a large-scale academic project, and what criteria goes into the Design 4 Drupal Boston event.
Highlights from the conversation include:
- Learn the common pitfalls Drupal designers fall into, along with some tips and tricks to avoid them (hint: Drupal is like a cake recipe) [Discussed at the 0:17 mark].
- How the Berklee College of Music is using Drupal [Discussed at the 5:49 mark].
- The focus for 2013’s Design 4 Drupal Boston [Discussed at the 7:50 mark].
- The ways Drupal 8 could change how designers work [Discussed at the 9:40 mark].
You can view the entire interview in the following video.
Why we need Go
Rob Pike on how Go fits into today's computing environment
The Go programming language was created by Rob Pike, Ken Thompson, and Robert Griesemer. Pike (@rob_pike) recently told me that Go was born while they were waiting a long while for some code to compile — too long.
C++ and Java have long been the go-to languages for big server or system programs, but they were created almost 30 and 20 years ago, respectively. They don’t address very well the issues programmers see today like use of concurrency and incorporating big data and they’re not optimal for the current programming environment.
One main reason that Go will succeed is how it deals with concurrency. It outpaces Java and C++ as well as Python, Ruby, and all the other scripting languages. It simply provides a better model, with Java a close second, that is able to work within the computing environment into which it was born.
During a recent interview, Pike elaborated on the need for Go and where it fits in today’s programming landscape. Highlights from our discussion include: Read more…