To increase developer support and diversity in the Node.js open source community, the Node.js Foundation earlier this year brought in Tracy Hinds to be its Education Community Manager. She is charged with creating a certification program for Node.js, increasing diversity, and improving project documentation, among other things.
“We are recognizing the very wide range of users the Node.js space has and trying to make sure they are all taken care of when it comes to learning Node.js,” Tracy says.
“This is a really exciting time to get to support and grow all of the communities that have been contributing to Node.js all these years,” she says.
Here, Tracy tells us more about how she got started as a developer and with Node.js, her goals for the year as the new Node.js education community manager, and the best ways for new contributors to get involved in the project.
Linux.com: Tell us a little bit about your background, how did you get introduced to development, then Node.js and then education?
Tracy Hinds: My prior work was in healthcare administration. It was a purpose-filled field, but that didn’t reduce how colleagues and I were constantly frustrated by all the technology challenges that came with the vertical. I was in the field when the industry was adopting electronic medical records. I found myself spending far too much of my day trying to teach my really savvy coworkers how to use really poorly designed software.
I decided that I wanted to start solving these problems instead of banging my head up against them, so I learned how to code. I was mainly self-taught and was first introduced to Python. At the time, I was living in Portland, OR and through connections that I made in the community learning Python, I got my first job programming professionally at Urban Airship.
I was hired as a junior engineer under the condition that I would learn JavaScript. Of course, like in many cases, JavaScript introduced me to Node.js. There was a small, but very enthusiastic Node.js community in Portland, OR, and I went to several of their meetups, spoke at a my first conference (NodePDX), and got involved with organizing various events and helping to build the community through seeing all these opportunities to help.
Linux.com: As a developer that really learned on your own, what advice would you give others to get started with this?
Tracy: Be patient. You’ll be exposed to so much information early on and you’ll be excited to be good at it. It’s so much information to take in and apply. Much of it takes time and experience to learn, not just theoretical readings.
There will be times where you’re feeling like you’re up against a brick wall. That’s okay! As a programmer, you’ll be paid to solve problems you very likely don’t know the answer to yet. You’ve been hired because you know how to approach the journey of finding a solution.
Find a community of people who encourage and support you, and you’ll be setting yourself up for success. No programmer is an island. OSS relies on a lot of wonderful people collaborating to make things work!
Linux.com: How about landing that first job, what are some things that people should be aware of in trying to get a job as a developer that you wish you would have known or that you found really helpful?
Tracy: I’d had friends who were programmers and had insisted I’d make a great one time after time. With the help of so many communities, friends, and mentors, I learned how to program in Python and some basic web engineering. I was unbelievably fortunate through my networking to find a job that was willing to hire me as a junior and asked that I deep-dive into JavaScript as a primary language.
It’s really important to introduce yourself to people, go to these meetups to try to learn more, but also show that you are open and persistent enough to never stop learning. Developers are problem solvers, so if you show that early on and have the added skill of being able to communicate well (and therefore collaborate), the better. Making those connections, showing that I could keep an open mind while also being a bit stubborn, and being willing to really immerse myself in the world of programming helped keep me on track from a big career switch.
Linux.com: Let’s get back to Node.js, tell us a little bit about what you are doing for the Node.js Foundation?
Tracy: I was hired to be the education community manager at the Node.js Foundation. Essentially what I’m trying to do is create materials that will help introduce developers to Node.js (new developers and those that have been in the field for a long time), help ensure that education is embedded in the process of learning Node.js through documentation, and promote diversity in the community through education.
Linux.com: What are your other goals in creating education opportunities for the Node.js community at large?
Tracy: I have three major goals this year, the first is how to create and provide a certification program for Node.js.
The second is to help build out the diversity of the Node.js community and I believe that education is the best way to do that. I’ve been trying to take a look at what workshops and in-person events exist that help create a supportive, inclusive learning environment so that I can assess how the Node Foundation can support future work. People getting to learn together form bonds and lets down barriers a little, enough so that they are open to making friends through the challenges they are facing. It’s easier to build camaraderie when you’re struggling with the same problem in a NodeSchool workshop or fixing a broken route in a NodeTogether class with a little help. These events draw much more diverse groups — underrepresented communities, career transitioners, other language users because they create spaces that are hellbent on being forgiving, friendly places to learn.
My third is to improve the documentation in Node.js to help facilitate learning. Currently, that means lots of discussions with different types of Node.js users on what it means to improve documentation. I wanted to encourage API docs improvements because they felt sparse. However, the more conversations I’ve had about docs in Node.js, the more I’m finding that our lack of other spoken languages being supported is a huge barrier for folks to level up or even step into Node.js. I can’t begin to imagine how difficult it must be having to translate the essential documentation I would need into the language I speak in order to write code. It’s an incredible barrier. There’s good work being done in our working groups for this, but there aren’t enough folks to support such a big challenge. We need to be smart about how we’d approach this.
Linux.com: What are some interesting things you are finding in creating this certification program, why is it important?
Tracy: Certifications are extremely important to developers that have previous coding experience and are employed by companies who require it for hiring or promotions. When you look at some older technology languages, like Java, they have fairly deep certifications process and plans. Those that have experience with these languages have expectations to have something similar when they convert to newer platforms/languages like Node.js.
Certifications can also be useful for what we see often in the Node.js ecosystem — smaller companies and consultancies. It could be an interesting space when a group of engineers can show that they have their certifications and establishes them as competent and potentially more competitive than another group that isn’t quite there yet.
We are having our first meetings with the newly formed Education Advisory Group, which will allow a good representation of perspectives from Node Core, Foundation members, NodeSchool, and the ecosystem to help form the scope of the certification. We’ll move forward with what we establish as tasks a competent Node.js engineer could complete. It’s definitely a work in progress and will take about 9 months to accomplish. We’re partnering with the Linux Foundation to build this out as an in-browser, 3rd-party proctored remote test.
Linux.com: Any sources currently that you would recommend to those that are interested in getting started with Node.js or that might need to brush up their skills?
Tracy: First, Ashley Williams has created a really great opportunity to introduce folks to Node.js and development in general that do not have experience in this space at all. The series is called NodeTogether and for the most part they are held wherever we are having our Node.js Live events. She is looking for those that want to participate and mentors, so definitely worth checking out.
Jon Kuperman released nodecasts.io, which is awesome for folks who like video learning. There’s about 6 courses that add up to a pretty great, free intro to Node.js.
Finally, NodeSchool is filled to the brim with free workshoppers that cover such an incredible variety of essential skills in Node.js. I recommend checking out one of the local events in your area where mentors will help you run through many of these modules, and the website has support for 20 different spoken languages! The NodeSchool community events are so warm and friendly, and the online repo with active organizers is very encouraging and helpful.
Linux.com: You joined the Foundation a few months ago, what are some of the major roadblocks you’ve been able to overcome or key initiatives that you’ve been able to launch or are going to launch (fairly soon)?
Tracy: We are making strides towards unearthing a lot of the really incredible activity that’s been happening in different corners of the world in Node.js and making plans on how the Node.js Foundation can elevate those communities. My strength is in seeing good people doing awesome work and removing their roadblocks by helping with processes that might be standing in their way.
The certification planning is moving forward. The Education Advisory Group is meeting and will have big ideas for years to come. We are recognizing the very wide range of users the Node.js space has and trying to make sure they are all taken care of when it comes to learning Node.js, be it through turning over rocks to find out which problems we can rally to in Documentation or elevating programs that help build out inclusivity and diversity of perspectives in our language. This is a really exciting time to get to support and grow all of the communities that have been contributing to Node.js all these years.
Two years ago, the Raspberry Pi seemed as if it might be eclipsed by a growing number of open-spec single board computer projects with faster processors, Android support, and more extensive features. But then the Raspberry Pi reestablished its lead in two major great leaps forward.
In early 2015, the Raspberry Pi Foundation released a quad-core, Cortex-A7 based Raspberry Pi 2, and then followed up a year later with a 64-bit, quad-core Cortex-A53 Raspberry Pi 3 with onboard wireless. The project wisely made these great leaps forward without messing much with the basic form-factor, port layouts, expansion connector, or software, all while keeping the same $35 price.
That dominance was reflected in the newly published results from a survey of community-backed board preferences taken earlier this month by HackerBoards.com. The survey asked readers to choose their favorite three Linux- or Android-based open-spec SBCs from a list of 81. Just as the Raspberry Pi 2 won last year’s 53-board survey, the Raspberry Pi 3 similarly blew away the competition in 2016.
Once again, an Odroid board and the BeagleBone Black filled the next two slots, although this time it was the Odroid-C2 in second and the BeagleBone third. Otherwise, the top 10 list looked considerably different from last year’s results. For example, only three of the top 10 most popular SBCs were around a year ago: the BeagleBone, RPi 2, and DragonBoard 410c, and only the BeagleBone was on our 2014 top 10 list. Four of this year’s top-10 contenders were new, 64-bit ARMv8 boards.
The following list shows the top 10 out of 81 boards, which were all ranked using Borda Count scoring in which second and third favorite choices were also factored in. To make the list, the SBCs had to run Linux or Android, cost less than $200, and ship no later than June 2016. They also needed to meet some basic requirements for open source compliance and community support.
Low priced boards with Raspberry Pi interfaces dominate the top half of the 81-board list. The 40-pin expansion interface has significantly broadened the Raspberry Pi community, even while reducing the necessity of owning a Raspberry Pi in order to gain access to that ecosystem. Among Linux/Android hacker boards, it has become more popular than an Arduino shield compatible interface, although those are in abundance as well. SeeedStudio Grove and MikroElektronika MikroBus Click interfaces are also found on many of these boards.
One of the Pi-compatible SBCs is Hardkernel’s $40 second-place Odroid-C2, which arrived around the same time as the $35 Raspberry Pi 3, and with similar features such as quad-core, 64-bit processors. The Odroid-C2 has the faster chip, but the cheaper RPi 3 also throws in WiFi and Bluetooth. Here, the Raspberry Pi is staying ahead of a general trend toward onboard, rather than, optional wireless.
Although low pricing was clearly popular here, with the $15 Pine A64, $9-and-up Chip, and $5-and-up Raspberry Pi Zero all making the top 10 list, some relatively pricey boards such as the Creator Ci40, Odroid-XU4, and DragonBoard 410c made the list too. When survey takers were asked to rank buying criteria, low price dropped in rank compared to last year. Other responses to questions about buying criteria remained largely consistent from last year, with home automation, for example, continuing to lead the list of intended applications.
It would appear that many potential buyers don’t see much difference between, say $20 and $35, especially when shipping is taken into account. The real impact for products such as the dirt-cheap Raspberry Pi Zero is likely going to be felt in more commercial products sold in small runs, or in hobbyist/maker projects in which CPU clusters and numerous IoT sensor boards are required. If you’re a weekend hobbyist looking to automate your sprinkler system with a single SBC, other issues are likely more important.
There seems to be growing resistance to irresistibly priced SBCs from certain Shenzhen-based projects. The $10 Orange Pi One and $12 Orange Pi Lite, both sporting the quad-core Allwinner H3, were ranked 28th and 31st, respectively. Of the five FriendlyARM NanoPi boards, several of which had similar cut-rate pricing, the highest ranked model was the $35, 64-bit NanoPi-M3, which came in 41st.
Buyers seem to be looking more closely at open source software support, which once again was the leading buying criteria in the survey. With so many cheap, capable SBCs to choose from, people can afford to be picky and choose the projects that offer timely firmware updates and solid community resources. How else to explain the surprising popularity of the 19th ranked Wandboard, an aging, fairly high-priced SBC with strong software support.
Another example where community and software support makes up for fairly low price/performance is the venerable, third-place BeagleBone Black. If you combined its score with the currently available clones — the BeagleBone Green, BeagleBone Green Wireless, and MarsBoard AM335x — this $48, Cortex-A8 based SBC would be neck and neck with the Odroid-C2. And more BeagleBone clones are on their way.
Of course, if you combined the Raspberry Pi 3 with the very similar RPi 2, now in 6th place, and the less similar, $5-and-up RPi Zero, now in 8th, you’d get an even more impressive total. It’s hard to imagine that a Raspberry Pi model won’t be the people’s choice in 2017, as well. Then again, judging from the amazing price/performance improvements that have occurred in the SBC market in 2016, a lot can happen in a year.
Back in 2012, when I was an operations engineer at Slideshare, I was part of a team that launched a DevOps model to speed processes and stay ahead of our competition.
We were a small startup, with fewer than 20 employees, building what became one of the most successful professional content sharing tools on the web. We didn’t know it at the time, but DevOps was one of the keys to our success in quickly reaching 29 million unique visitors per month and leading to the $119 million acquisition by LinkedIn in 2012.
Our goals in adopting DevOps practices were to create a more cohesive team and achieve maximum efficiency. The development team was split between San Francisco and New Delhi, and the infrastructure was quite complicated. A DevOps environment pushes every contributor to work on and contribute to different parts of the product, so it helped overcome geographic barriers by making people interact and help each other.
It also helped us spread technical knowledge to the most possible people, so that if someone was going on vacation or leaving the company, there was limited impact.
However, our DevOps success didn’t come without some failures, which have since become valuable lessons I share with my engineering students at Holberton School.
One of the main ideas behind DevOps is a greater sense of ownership over work responsibilities, and for that you need to give access to part of the infrastructure that developers do not generally have access to. At SlideShare, engineers had access to production servers and production databases.
A software engineer was working on a database-related project and trying out a tool that offered the ability to explore a MySQL database graphically. He decided to reorganize the order of the database columns in that tool so that the data would make more sense to him. What he did not know was that it was also changing the columns’ order in production on the actual database, locking it, which brought down Slideshare.net and shut out the more than 60,000 users trying to access it. When it happened, the person responsible did not realize that the tool was actually performing actions, and it took 15 minutes of collective effort to figure out the source of the problem.
There were two takeaways from this failure:
While DevOps is pushing for everyone to have an impact on any step of the product/service cycle, it’s good practice to take a step back every time you give access to something and make sure it is actually valuable. In this specific situation of the database outage, we realized that giving access to production data was actually not useful at all and was very dangerous. The developer could have extracted the same exact value by using a staging database, but with a much more minor impact on the company.
It’s important to better educate developers on the workings of infrastructure. Many of them have never been exposed to production infrastructure. DevOps is based on a way of working, which obviously is more about human interaction. You can’t expect everyone to naturally know the hidden rules. That’s why onboarding should be mandatory and critical.
