Your data is telling you what you need to know about turnover and age
To really grasp a free/open source software project, you need to know how the community that develops and supports it is evolving. Attracting lots of new members will be a reason for celebrating success in a young project — but you should also check whether they stick around for a long time. In mature projects, however, you can afford not attracting many new members, as long as you are retaining old ones. The ratio of experienced, long-term members to recent ones also tells you about the quality of the code and need to support members.
Think labels, not boxes
Python tuples have a surprising trait: they are immutable, but their values may change. This may happen when a tuple holds a reference to any mutable object, such as a list. If you need to explain this to a colleague who is new to Python, a good first step is to debunk the common notion that variables are like boxes where you store data.
In 1997 I took a summer course about Java at MIT. The professor, Lynn Andrea Stein — an award-winning computer science educator — made the point that the usual “variables as boxes” metaphor actually hinders the understanding of reference variables in OO languages. Python variables are like reference variables in Java, so it’s better to think of them as labels attached to objects.
Here is an example inspired by Lewis Carroll’s Through the Looking-Glass, and What Alice Found There.
Tweedledum and Tweedledee are twins. From the book: “Alice knew which was which in a moment, because one of them had ‘DUM’ embroidered on his collar, and the other ‘DEE’.”
The O'Reilly community shares stories of inspiring women in tech. Who inspired you?
October 14 is Ada Lovelace Day (ALD), an annual global event that recognizes not only the 19th century mathematician and aristocratic super nerd who wrote the first computer program, but other women in our community, too. ALD founder Suw Charman-Anderson’s goal is “to raise the profile of women in science, technology, engineering, and maths by encouraging people around the world to talk about the women whose work they admire.“
Supporting diversity is important to us, so we’re participating in ALD this year. We’ve compiled some stories of women in tech from O’Reilly staff and members of our extended family — you can read about them below.
Before you ask HR to find a developer skilled in a particular tool or language, think about who you really want in that seat.
I had a conversation recently with Martin Thompson (@mjpt777), a London-based developer who specializes in performance and low-latency systems. I learned about Martin through Kevlin Henney’s Tweets about his recent talk at Goto Aarhus.
We talked about a disturbing trend in software development: Resume Driven Development, or RDD. Resume Driven Development happens when your group needs to hire a developer. It’s very hard to tell a non-technical HR person that you need someone who can make good decisions about software architecture, someone who knows the difference between clean code and messy code, and someone who’s able to look at a code base and see what’s unnecessary and what can be simplified. We frequently can’t do that ourselves. So management says, “oh, we just added Redis to the application, so we’ll need a Redis developer.” That’s great — it’s easy to throw out resumes that don’t say Redis; it’s easy to look for certifications; and sooner or later, you have a Redis developer at a desk. Maybe even a good one.
And what does your Redis developer do? He does Redis, of course. So, you’re bound to have an application with a lot of Redis in it. Whenever he sees a problem that can be solved with Redis, that’s what he’ll do. It’s what you hired him for. You’re happy; he’s happy. Except your application is now being optimized to fit the resumes of the people you hired, not the requirements of your users. Read more…
Prepare for the future of computing with Python.
I was reminded of this when reading some recent articles worrying about the slow transition from Python 2 to Python 3, such as Python 3 is Killing Python. The authors of such articles, and Python developers in general, really like Python, and for the most part like Python 3. Their main concern is that the protracted 2-3 straddle will hurt Python’s popularity.
About five years ago, I started writing an introductory Python book for O’Reilly. It featured Python 2, which was dominant then. Unfortunately, the tides of business went out and took the book with them. Two years ago, the tides returned and the book was revived. Introducing Python: Modern Computing in Simple Packages is finally in production and early release.
When we rebooted the book, there was now a serious question of whether to feature Python 2 or 3. The other version might merit some sidebars or an appendix, but we really needed to pick just a single base for the code examples. And by now it seemed that Python 3 had become the right choice. If you’re wondering why the editors and I thought Python 3 was best for this book, let me give some of the reasons, more or less in order of importance.
Discover, connect, and transmit data between devices.
Multipeer Connectivity is a means of identifying and connecting services together, and allows for very easy passing back and forth of data with minimal setup. If you are thinking that this seems similar to Bonjour, you are correct; however, Bonjour is for service discovery, not connection or transmission. Multipeer Connectivity handles everything in one neat package.
Multipeer Connectivity is comprised of a few different components, but it works by having applications advertise their services asking if anyone is available to connect. The service browser listens for these advertisements and can request to create a connection between the devices. If the connection is accepted, a session is created with every one inside the session being represented by a peer object.
To demonstrate how this works, we’ll make a simple chat application using Swift, Apple’s new language.