Digital Ocean: Simple, Cheap, Reliable Web Hosting
Name: DigitalOcean (Visit DigitalOcean)
Type: Web Host
Best Website For: Simple, Fast, and Competitively Priced Hosting
Reason it's on The Best Sites:
Digital Ocean takes the headache out of web hosting with their sleek interface. They gained popularity when they were one of the first to offer SSD hosting for as little as $5/month. This site is hosted with DigitalOcean. At their best, they're the fastest, simplest, and most competitively priced mainstream hosting provider.
RailsConf has left the desert and makes its way to Steel City April 17-19, 2018. We’ll have Sam Phippen presenting, and several DO-ers checking out talks and tending our booth. Here’s what you need to know about RailsConf 2018.
In Sam’s talk, “Quick and easy browser testing using RSpec and Rails 5.1,” you'll learn about the new system specs in RSpec, how to set them up, and what benefits they provide. It’s for anyone wanting to improve their RSpec suite with full-stack testing.
Make sure you don’t miss it, Thursday, April 19, from 10:50 AM-11:30 AM in the Spirit of Pittsburgh Ballroom. If you’re interested in RSpec, you might dig his talk from 2017, “Teaching RSpec to Play Nice with Rails.”
You can also catch us in the Exhibit Hall, at booth number 520. The Hall is on Level 2, in Hall A. We’ll be hanging at our booth Wednesday, April 18 from 9:30 AM-6:00 PM, and Thursday, April 19 from 9:30 AM-5:15 PM.
See you there, or, as they say in Pittsburgh, meechinsdahnair!
On the six-year voyage toward becoming the cloud platform for developers and their teams, we have received tremendous support from the larger developer community. We’ve seen hundreds of Meetups organized, pull requests submitted, tutorials written, and Q&As contributed, with even more ongoing activity. To show our appreciation, last month we introduced a new way to highlight some of our most active community contributors - our Community DO-ers!
Community DO-ers help make the community better through the content they create and the value they add. In addition to the Community homepage, we’ll regularly highlight Community DO-ers on the blog, Infrastructure as a Newsletter, social media, and to our growing internal community. In March, we were excited to bring you the trio of Marko, Mateusz, and Peter. This month, with a focus on our global Meetup community, we have three new individuals for you to get to know and celebrate with us. Without further ado, meet April’s featured Community DO-ers:
Aditya is an early adopter and advocate of DigitalOcean, so it’s no surprise that he became the first organizer of our second largest Meetup group, based in Bangalore. He has been producing Meetups since 2016 and has served as a speaker and panelist at consecutive DigitalOcean TIDE conferences. His talk on foolproofing business through infrastructure gap analysis was well received at TIDE New Delhi, and we later invited him to conduct an online webinar on setting up a multi-tier web application with Ansible. We’re extremely proud and excited to be working with him because of his passion for education and for helping the wider community.
For the second month running, we are proud to highlight the work of our active Taiwan community. Specifically, we are excited to recognize Samina Fu, a Network and Systems Engineering graduate of National Chiao Tung University in Taiwan. Samina is a co-organizer of our Hsinchu community, which she has been bringing together since early 2017. She helped to organize our first of 120 Hacktoberfest Meetups last year, and works closely with Peter Hsu (who we highlighted last month) as a core contributor to the CDNJS project.
When David Endersby filled out our Meetup Organizer Application Form in September 2016, we didn’t know he would go on to lead one of our largest and most active Meetup communities. Since early 2017, David has worked hard to develop a blueprint for successfully running a new Meetup community, covering everything from starting out, to finding speakers, to time management, choosing a location, feeding attendees, and more. His efforts have produced a wealth of content and he has an ambitious plan for 2018. If you’re interested in joining, he welcomes you with open arms!
Aditya’s, Samina’s, and David’s efforts exemplify the qualities we are proud to see in our community. They all have a knack for educating the community (off- and online), promoting both learning and community collaboration. But there are so many others we have yet to recognize! We look forward to highlighting more of our amazing community members in the months to come.
Are you interested in getting more involved in the DigitalOcean community? Here are a few places to start:
- Share a project that you’ve built with our API.
- Share your knowledge in our community Q&A section.
- Join our Write for DOnations program and contribute to our library of tutorials.
- Get involved in your local DigitalOcean Meetup or start your own.
Know someone who fits the profile? Nominate a member to be recognized in the comments!
For two years, I’ve managed the Infrastructure Engineering (“Infra”) team at DigitalOcean. We’re responsible for managing all servers and machines up to the application layer. This includes hardware spec, firmware, component validation, base OS, configuration management, and hardware management (hardware management database).
In addition to my core responsibilities managing the Infra team, I wanted to foster an environment where mentorship was possible and worked with colleagues to create the Infrastructure Engineering Fellowship Program. It’s an immersive program where DigitalOcean employees from other teams “join” the Infra team for two weeks. Employees with fundamental Linux knowledge and some configuration management experience are eligible to participate.
“Fellows”—as they are known—are invited to a private Slack channel with fellowship alum. They work through JIRA tickets assigned to the team (all while pairing with Infra team engineers), attend team stand-ups, and finally, pick a project to work on for the two week duration. Additionally, fellows meet with me at the start and end of each week to discuss what they worked on and to answer questions they have. To date, we’ve had nine people complete the fellowship and we continue to open the fellowship up to other engineers at DO.
How the Fellowship Started
This program started as a cross-team training experience between my team and the Tier-2 Cloud Operations team (the 24/7 team responsible for uptime on our servers and services), since both of our teams interacted with each other on a daily basis. After a few successful trials with the Cloud Operations team, we realized that there were several other teams that were interested in learning what we do and wanted to take advantage of the fellowship program. We have now had people from five different teams sign up and participate in the program.
My team gets so much more out of the fellowship than we put in. First, we build comradery between the wider organization and my team. Individuals we only worked with through JIRA and Slack now have a personal relationship with the team and are more eager to engage and work with us. My team gains a better perspective of what other teams go through and work on a daily basis which helps us build better tools and workflows to support them. Finally, it is a great way to recruit. Engineers that have been hired for my team came through the fellowship program.
Growing people internally is one of the greatest things I have done with my career. I have had three people join my team from inside the company and have been very successful in their new roles. In a perfect world, we would pair every senior engineer on the team with one engineer still early in their career. In my experience, when looking at the “Tuckman's stages of group development” you will have the best performing team when you have mentors and mentees going through the four stages together as a team:
Tuckman's stages of group development. Photo credit: Tutorials Point
Managing the Fellowship Program
One of the things that we keep top of mind is sustainability. Although two weeks isn’t very long, properly mentoring someone takes a lot of time, and we want to make sure no one feels overwhelmed by the experience. We currently take on just one fellow at a time, and we cater the program to each participant. For example, if a fellow is more interested in hardware than big data, they might pair with our integration team who is charged with managing hardware and firmware, rather than our DevOps-focused team.
There are a few benefits of managing the fellowship this way. One, we can iterate quickly since the program lasts just two weeks. And two, we can focus our energies on mentoring just one person at a time to limit straining the team’s bandwidth. Based on feedback from past fellows, we’ve changed how we handle our 1:1s with engineers and code pairing sessions. We now conduct 1:1s with specific goals in mind. Each fellow is asked to give feedback at the very end of the program to help us guide future fellows.
That said, the same benefits are in some ways ongoing challenges. Working with each fellow individually takes up my time, but it also affects the engineers on my team. They need to take time out of their busy schedules to pair with the fellow by breaking their usual workflow and compelling them to walk through projects step by step. This means something that may take them an hour ends up taking most of a day.
That said, we’re able to make this work because we work on a number of tasks and projects at any given time. If a team is working on one long-term project, the time it takes to explain the project to someone won’t actually yield any benefit in a two-week long program. The fellowship program (and programs like it) really need to be catered to the participant and the team that they are embedding with.
What Makes It Worthwhile
As I pointed out earlier, pairing engineers with more senior engineers leads to better performing teams. Furthermore, there is an even stronger connection when you pair engineers that have proprietary or historical knowledge from inside the company. I am a firm believer that if strong minded, eager-to-learn engineers exist within the company, you shouldn’t hire from outside the company. Creating infrastructure that supports mentorship leads to strong engineers, strong teams, and a strong company.
I love seeing people continue to have conversations and work on projects with my team after the fellowship is over. It is simply amazing to see, and I give all the credit to the engineers on my team. Every one of them is eager to pass on knowledge that they have, and they’ve embraced the fellowship and its goals. The fellowship wouldn’t have been successful if my team didn’t share the same beliefs around mentorship and its cross-team benefits that I have.
Future of the Fellowship
When I started my career in IT, I had an amazing mentor (shout out to Rob Lahnemann) who really took me under his wing and taught me everything he could about programming, Linux, and networking. My manager at the time (shout out to Eric Austin) set this up and put me in a place to succeed as a mentee. This experience really influenced what I believe it means to be a good manager. Pairing engineers eager to learn with senior engineers is huge key factor in any successful team. In the current engineering community, it is not uncommon to find engineers who are not influenced to share their knowledge or are not given the time to be a mentor. But in my opinion, growing as an engineer means being a mentor.
In the future, I would love to see the program more of a revolving door of people doing more work with the Infrastructure Engineering team and doing the fellowship program multiple times (hopefully sometimes for longer than two weeks). I also would love to influence programs like this more often inside DigitalOcean and outside DigitalOcean. One of my biggest goals and drivers in writing this is to influence similar programs in the industry as a whole. My career and pace of growth was directly influenced by a strong mentor, so my passion here for influencing more mentor/mentee relations in the industry is high.
Tom Spiegelman is an Infrastructure Engineering Manager at DigitalOcean. He has an awesome dog, a great team, and is married to the amazing Chantal Spiegelman. He is passionate about all things tech, specifically infrastructure. You can find him on LinkedIn or on Twitter.
A code review, at its core, is a conversation about a set of proposed changes. Early in my career, I viewed code reviews as a mostly technical exercise that should be devoid of non-technical concerns. I now see them as one of the few opportunities to concurrently learn and teach while also strengthening my relationship with my peers and colleagues.
My team, Delivery, has been working together for at least six months (some much longer), but only two members work in the New York City office while the rest are spread across North America. Because of our familiarity with each other, most of our daily interactions take place via text or video chat. Code reviews are often short, but we also go out of our way to communicate when we are stating an opinion or being nit-picky.
Most software developers are expected to participate in code reviews, and yet few are offered any training or guidance on conducting and participating in an effective code review. Participants attempt to find the most appropriate solution to a problem given the constraints of time, effort, and skills of all involved. But how do we have that conversation? What does an effective conversation look like? And what are the challenges of participating in a code review, and how can you overcome them?
Whether your tool of choice is GitHub, GitLab, Gerrit, or another tool, the goal of this article is to help you get as much out of the code review process as possible.
What Are Code Reviews For?
Code reviews happen in a wide range of contexts, and often the skills and depth of experience of participants vary widely. On open source projects, for example, participants may not have any sort of personal relationship with each other. Indeed, they may never communicate outside of the code review process. At the other end of the spectrum are code reviews where the participants have daily face-to-face interactions, such as when everyone works at the same company. A good participant will adjust how they participate in a code review according to their knowledge of the other participants.
While it is important to adjust one's communication style in accordance with the intended recipient, how to adjust is influenced by three primary factors: the purpose of the code review, the intended audience, and one's relationship to the audience.
Identifying the Purpose of a Code Review
Code reviews serve both technical and cultural purposes: finding bugs before they're integrated, identifying security concerns, ensuring style consistency with the existing codebase, maintaining code quality, training, fostering a greater sense of ownership, and giving other maintainers an opportunity to get familiar with the code before it's integrated are just some of the reasons you may be asked to participate in code reviews. Make sure you know why you're participating in a code review beforehand.
Regardless of why you’re conducting a code review, it is important to respect the purposes that code reviews serve for the codebase. If the only purpose of a code review is to check for security concerns, then drop whatever personal concerns you may have about coding style or naming patterns. Unfortunately, it is not uncommon for the purpose of code reviews to be poorly defined or non-existent. In that case, once you've determined that the proposed changes are necessary and add value, I'd suggest reviewing for correctness, bug identification, and security concerns. Secondary to those concerns may be overall quality and long term maintainability of the proposed changes.
Submissions: What to Include
Code reviews typically start with a contributor submitting a proposed set of changes to the project. The submission should include:
- A clear and useful description of the changes and give a general overview of why the change is necessary.
- The scope of the change.
- Areas where reviewers may want to give special attention.
- Subtleties that need clarification.
- Details that may help reviewers better understand the patch.
Depending on the complexity of the changes, reviewers may find an overview of the trade-offs the submitter made in the patch helpful in order to be better understand why the patch is the most appropriate of the possible alternatives.
Written communication about technical subjects can be difficult: people have limited time, and each of us is on a journey of confronting challenges and personal growth. In code reviews every participant has a role to play, each with its own set of objectives:
- As a writer, strive to be as clear as you can. When in doubt, be descriptive.
- As a reader, ask questions when something is unclear.
- As a reviewer, be gracious when someone uses their time to submit a patch to your project.
- As a submitter, be forgiving when your patch is not reviewed in the time frame you would prefer.
Regardless of your role in the review process, respect that others may be at a different place in their journey, and assume that all participants are engaging in the process in good faith and because of shared values and goals. The process is easiest when one assumes that all other participants are doing their utmost to help you succeed and get better.
Here's an example of a pull request from our team where I asked for clarification, discussed my concerns, and ultimately landed on a compromise that made the submission better and easier to maintain, all while gaining personal knowledge of the subject at hand:
Example of how my team communicates in our code reviews.
Knowing Your Audience
Start by reading all the code. As a reviewer, recognize that the submitter gave their time and energy and tried to improve the product in some way. As you read and strive to understand the patch, record your questions and concerns privately so that you understand the full context before providing any feedback. As mentioned previously, make an honest effort to restrict your feedback to the purposes for which the code review is being conducted.
Prepare and submit your feedback after reading and understanding the changes. Be gracious. Try to keep your comments focused on the code and the solution it offers; avoid digressing into unrelated matters. If you see something surprising, ask questions. If you don't have a strong history with a submitter, go the extra mile to communicate your good intentions. It's OK to use emojis to communicate tone. Strive to begin fostering a healthy, productive relationship with this new contributor.
Your feedback in code reviews is one of the primary ways to build a community of developers eager to contribute to your project. By nurturing a strong community, you will promote a quality product. Especially for open source maintainers, an authentic, explicit “thank you for the contribution” or other nice words can go a long way towards making people feel appreciated and fostering a supportive community.
Take the feedback, evaluate it, and decide what to do next. For submitters, it can be difficult to read criticism of the code you have written. When a reviewer asks for changes, they are doing so for the same reason a patch author submits a patch: a genuine desire to improve the product. Remind yourself that feedback about code is not personal. You may decide to accept the feedback and change something. Or you may decide that there was a misunderstanding, and that some requested changes are unwarranted or would simply be wrong or add no value. It’s OK to push back.
Developing a Partnership Through Code Reviews
When there is an asymmetric level of experience between the submitter and reviewer, use the opportunity to mentor. As a reviewer with more experience than the submitter, you may choose to accept that submitter's patch as-is and then improve upon it, contacting the submitter to let them know about your changes later. In a professional setting, such an approach isn't always feasible. Have the conversation in the open so that observers (i.e. other readers) can learn too, but reach out for a more personal touch if the extent of feedback is becoming overwhelming in written form. In my experience, patches submitted by someone significantly more experienced than the reviewer are usually accepted as-is or with only very minor changes requested.
When you're thinking out loud, make it clear to the reader so that they do not think you are asking for a change inasmuch as evaluating a possibility. If you're nitpicking, explain your reasons for doing so. On our team, we often preface nit-picky comments with
(nit), in order to help contributors recognize these types of comments. This usually serves as a signal that the contributor can ignore that feedback if they want. Without that distinction, the nitpicks are not distinguishable from the feedback that the reviewer feels more strongly about. For all participants: when you're unsure about something, ask, and err on the side of clarity and friendliness.
A successful code review will result in a higher quality change, strengthen the relationship between reviewer and submitter, and increase the understanding that everyone involved has of the project. Code reviews are not just a formality that require a rubber stamp before being merged; they are an essential aspect of modern software development that provide real value to projects and teams by promoting good software engineering practices.
Through code reviews, I've learned to be more gracious and more understanding about the personal challenges and technical struggles that everyone experiences. I have learned to more thoughtfully examine the trade-offs that we all make when writing software. I hope the ideas presented here can help you grow your community and increase your effectiveness.
Billie Cleek is a Senior Software Engineer on the Delivery team where he supports internal tools to provide a consistent deployment surface for DigitalOcean's microservices. In his spare time, Billie is a maintainer of vim-go, infrequent contributor to other open source projects, and can be found working on his 100-year-old house or in the forests of the Pacific Northwest regardless of the weather. You may also find Billie on GitHub and Twitter.
Currents is back with our third report on the developer experience. This February we asked 5,993 participants about their thoughts on hot topics like artificial intelligence and machine learning, new ways of working with codebases and services like continuous integration and delivery, and important issues like the European Union’s General Data Protection Regulation (GDPR) and the FCC’s decision on net neutrality.
Among our findings this quarter:
Developers in the US are strongly against the repeal of net neutrality with 83% saying they believe the Federal Communications Commission (FCC) made the wrong decision. This is in line with the 83% of US voters who said the same in a December poll, highlighting the overwhelming public opposition to the repeal.
Despite the wide reach and the intense media coverage of the Spectre/Meltdown vulnerabilities, a majority (71%) of developers’ day-to-day work was not impacted by the issue.
Though GDPR is slated to go into effect in just a few months, developers and companies are still confused about who the regulation will affect. A third (34%) of all respondents are unsure if their company is preparing for the legislation. This holds true regardless of company size, but developers in some countries appear to be more confused than others; up to 40-50% in markets like Mexico and Indonesia say they are not sure where their company stands on GDPR.
As companies grow in size, they’re more likely to be using continuous integration (CI), but there’s still room for growth. Today, roughly two-thirds (68%) of companies with 1,000+ employees use CI. Of all industries, financial services companies are most likely to be using CI at 72%, while nonprofits are least likely at only 39%.
If you work in a larger organization, chances are you are using CI/CD
While only 45% of developers in organizations with five employees or less are using continuous integration, and only 35% are using continuous delivery (CD), developers report the likelihood of using these technologies increases with the size of the organization. This is somewhat intuitive as many of the benefits of these methods provide ways for groups of developers to work together. In large organizations with over 1,000 employees, 68% of developers report using continuous integration and 52% are using continuous delivery.
Developers strongly disagree with the US FCC’s recent decision on net neutrality
Worldwide, the developers we surveyed voiced a strong opinion against the repeal of net neutrality in the US by the FCC. Among those in the United States this opinion was even more pronounced with 83% of developers against the decision and only 3.6% in favor of the change.
Adoption of the GDPR in Europe has many developers working to ensure compliance
Thirty-seven percent of the developers we surveyed reported that their teams were currently working to prepare for the GDPR. Unsurprisingly, developers in European countries are leading in this regard, with 58% of respondents in the Netherlands, 62% in Belgium, and 68% in Sweden stating their teams were actively working to ensure GDPR compliance. The United Kingdom saw the most engagement at 70%.
DigitalOcean Currents is published quarterly, highlighting the latest trends among developers.
If you would like to be among the first to receive Currents each quarter, sign up here. You’ll receive the latest report once it is released, share your ideas on what topics we should cover, and participate in our next survey.
Read more about these and other findings in the full report. Download the full Currents report here.
Simplifying the developer experience in the cloud has been a priority for DigitalOcean since we launched Droplets in 2013. As our product capabilities grow, we're taking great care to ensure that using DigitalOcean to run your applications remains as easy and intuitive as possible.
Today, we’re announcing the Control Panel Dashboard, the first of many Control Panel updates planned for 2018 as part of our mission to make it simple for development teams to operate and scale production applications in the cloud.
Introducing The Dashboard
Every day as we talk to developers, read feedback from the community, and witness the amazing applications being launched on our platform, the message that rings the clearest is that everyone values simplicity and ease of use. Visualizing, understanding, and controlling your cloud infrastructure in a single place is not inherently simple or easy, and it can get significantly more difficult as complexity increases.
The release of the new Dashboard is specifically meant to help you quickly access your existing resources and key account-related information, while highlighting additional products and features we think you’ll find useful when deploying scalable, production-ready infrastructure.
For existing users, the Dashboard replaces the Droplets page as the new default home page of the Control Panel. It provides “at-a-glance” visibility into active resources, like Droplets, Spaces, Load Balancers, Domains, Floating IPs, month-to-date current billing usage, shortcuts to team management, and other common tasks without having to navigate to different, often hard-to-find, sections of the Control Panel.
A look at the new Control Panel Dashboard.
Additionally, we’ve made changes to the top and bottom navigation to expose more helpful links to our status page, Community tutorials, API docs, and the support portal. All with the goal of surfacing more ways to help keep your applications running smoothly without overloading the UI.
The Dashboard is just the beginning. We have many more updates planned this year, and we can’t do it without your continued feedback. When you log in to take a look, please leave us some feedback using the little megaphone icon in the bottom right corner of the Control Panel. Or get early access to upcoming features by completing this survey.
The new Control Panel Dashboard is available starting today and will roll out to all DigitalOcean users over the course of the week. Stay tuned for more UI updates in the future!
Remote culture at DigitalOcean is one of my favorite things to talk about when discussing my job. When I first joined the company in June of 2015, there was already a substantial percentage of existing remote employees (better known as our “remotees”). Working with the remotees wasn’t initially a part of my function, but as a member of the Employee Experience Team, I gradually found myself getting to know many of them more personally. I learned about their experiences as distributed employees, some of their pain points, and how it influences their engagement.
Since I've never been remote, I educated myself on best practices for companies with remote employees and how we could expand our top-notch employee experience to those outside of our HQ.
Two and a half years later, our remotee population totals over 200 employees, making up over 50% of our employees, and our program has grown to support both the needs of our business and those who work remotely. To date, remotees score higher in engagement than any other subgroup at the company. This has been attributed to the attention and effort we have actively given to support the remotee experience.
Here’s what we learned and how we adjusted our efforts to better support the remotee experience:
“Watercooler talk” is an important aspect of working in-office, and it’s a practice that companies seeking to become more remote-friendly have trouble replicating. Being able to easily communicate with other colleagues helps improve team bonds and makes people feel part of the company fabric. At DO, we use several different mediums to avoid having remotees excluded from conversation and risking having information fall through the cracks:
Slack: The entire company uses Slack extensively for communication, whether you’re located across from each other or across time zones. We have a dedicated Slack channel specifically for our remotees, and we use that channel to make all remote-specific announcements (not to mention, for a lot of watercooler conversations). Additionally, we recently started a “Coffee Buds” program that pairs participants in our #coffeebuds Slack channel each week. Remotees have the chance to meet other colleagues—remote and in-office alike—and “hang out” over Hangouts!
Google Hangouts: It is common practice at DigitalOcean to have all our meetings hosted on Google Hangouts. All of our conference rooms include screens where remote employees join the meeting, making it possible for them to always be a contributor in team conversations.
Zoom: Hangouts can be limiting depending on the amount of people you have on a call. All of our company-wide, internal meetings are hosted on Zoom, and all remotees use it to join our biweekly All Hands Meeting. (It’s always fun seeing all of our remotees tune in at the same time.)
Google Drive: But what about time zone differences? Because we have an office in Bangalore, India and other remotees globally, all of our company-wide meetings are recorded and filed in a Google Drive for anyone to access at their convenience.
Who’s in HQ: Our weekly, internal newsletter goes out to the entire company on Monday mornings and a recurring section in it is called “Who’s in HQ”. This section has pictures of all the remotees who are visiting either our New York or our Cambridge office that week. This gives our in-office employees visibility into the visiting remotees so they can be sure to take the opportunity to meet them.
While most of our teams at DigitalOcean are comprised of both in-office and remote employees, there is definite value in giving teams the opportunity to get together in person at different times during the year. Here are the processes we have in place to ensure teams get face time:
DO Docking In: The "DO Docking In" program supports remote employees joining the rest of their team in the office all at once. We arrange leadership meetings, team dinners and activities, reserve workspace or conference room space, and host a Meet and Treat (a midday gathering between in-office employees and remotees) for them. In addition, teams also have the opportunity to participate in facilitation or meeting preparation by our internal Talent Development Team to serve the team’s goals for getting everyone together in person.
DO Out To Sea: Considering that we have employees dispersed domestically and internationally, some teams prefer to have their entire team get together in locations more local to where they work remotely from. This program is essentially the same as DO Docking In except that any team member who works from the office will fly out to meet with their remote team members. We help to arrange all of the offsite logistics and activities to support that team’s objectives for the visit.
DO Local: This program is the newest addition to our remote experience effort. This program parallels all major events or activities that are occurring in our office for our remotees. An example of this is our holiday party: we host our holiday party in New York and give the option for remotees who work in near proximity to other remotees to get together locally and enjoy a DigitalOcean sponsored dinner.
Shark Week: Shark Week is our annual family gathering. Essentially it’s structured like an internal conference providing team time, workshops, team activities, shared meals, and an entire week of quality time together. DigitalOcean covers the flights and the accommodations for all the remotees to join us for that week.
Perks for Remotees
While some companies see working from home as a perk in and of itself, we recreate many of the in-office perks and make them available to remotees. This is key to building a cohesive company culture and experience, and one where remotees feel engaged with the company at large.
Our remotes are able to participate in our workstation program, where they get access to different monitors, mouse/keyboards, and trackpads for their home offices, as well as credit up to $100 for headphones of their choice. The equivalent of our commuter benefit for in-house employees is providing remotes a credit toward the cost of either their monthly internet bill or their monthly coworking space membership. Additionally, remotes can opt into a monthly subscription snack box (because snacks are awesome!). Finally, DO covers travel and per diem costs, and provides accommodation at our corporate apartments for remotee visits to HQ.
"Love is What Makes Us Great"
DigitalOcean’s employee experience programs strives to be inclusive of all of our employees. We do this by keeping both the needs of in-office and remote employees in mind, and by adjusting our programs as needed to ensure they can change and scale with our growing organization. Removing obstacles to communication between people in our offices and remotes is essential for building cohesion across teams and to help everyone be the most productive employee they can be, no matter where they’re located.
Amanda Brazzell is DigitalOcean’s Office Experience Team Lead. She has helped build an effective Remote Experience program that drives dispersed employee engagement and job satisfaction. Amanda is a California native who moved to NYC without having ever visited the city before, and has been at DO since 2015.
Here at DigitalOcean one of our core values is "our community is bigger than just us". From our support of the broader open source community to making our tutorials as platform agnostic as possible, we believe that contributing knowledge and resources to the community benefits not just ourselves but all members – past, present, and future.
We never could have anticipated the amazing amount of support we've received in return. You’ve built open source tools using our API, hosted Meetups across the globe, shared your DigitalOcean stories, and so much more. We wouldn’t be where we are today without you.
We're now six years into this journey and want to start recognizing our members more regularly. So today we are excited to highlight some of our most active Community contributors—our DO-ers!
Marko Mudrinić (@xmudrii)
It’s hard to overstate just how lucky we are to have people like Marko in our Community; he’s an all around rockstar whose contributions span from ocean to ocean. Marko is one of the most prolific users on our Community Q&A platform, where he helps users learn about and build on DigitalOcean. He’s written tutorials on topics like Prometheus and Go, but also puts that knowledge into practice. He is the most active contributor to doctl, our open source command line interface, and has worked extensively on DigitalOcean support in Kubicorn to help users get up and running with Kubernetes.
Mateusz Papiernik (@maticomp)
Mateusz's passion for giving back to the Community inspires us. He has been sharing his technical expertise with us for many years, which you can enjoy in the dozens of tutorials he has published on topics from ProxySQL to Nginx optimization. With even more in the works, he has already helped hundreds of thousands of readers. His genuine enthusiasm and drive to aid others shines through in his writing and his collaboration with our editorial team.
Peter Hsu (@peterdavehello)
Peter is an open source enthusiast who is always going above and beyond. He has traveled across Taiwan to share DigitalOcean with his community—from COSCUP in Taipei to MOPCON in Kaohsiung. As the maintainer of the CDNJS (a free, public, and open-source CDN service), he helps to power millions of websites across the globe. Closer to home, he is an organizer of the DigitalOcean Meetup group in Hsinchu, Taiwan, which is quickly approaching 600 members. With nine events in 2017—including the first Hacktoberfest event of the year—it’s one of our most active Meetups!
Marko, Mateusz, and Peter exemplify some of the best qualities found in our community. All three share our enthusiasm for open source and passion for knowledge-sharing. But they’re not alone! We look forward to recognizing more of our amazing Community members in the coming months.
Are you interested in getting more involved in the DigitalOcean Community? Here are a few places to start:
- Share a project that you’ve built with our API.
- Share your knowledge in our Community Q&A section.
- Join our Write for DigitalOcean program and contribute to our library of tutorials.
- Get involved in your local DigitalOcean Meetup or start your own.
There’s such a thing as “too much information”, especially for companies scaling out their sales operations. That’s why Attentive was born in 2015: to help sales teams make their increasing pipelines simpler to manage. Indeed, the small, Portugal-based team is itself focused on scaling, having participated in accelerator programs like Techstars.
In this episode, Attentive founder and CTO Pedro Araújo talks about what it takes to build a tech product from the ground up. Discover their approach to running an engineering team, from adopting new open source technologies, to onboarding junior developers and learning about cloud infrastructure.
Hollie Haggans heads up Global Partnerships for DigitalOcean’s Hatch program. She is passionate about startups and cold brew coffee. Get in touch with questions at email@example.com.
As we turn the page on 2017, I’m proud to share that DigitalOcean had another tremendous year of rapid growth and strong profitability, a combination which few tech companies have achieved at our scale. We are rapidly approaching $200M in annual recurring revenue and are looking forward to celebrating our 6th anniversary next month. The key to our success is our disruptive offering — a cloud computing platform that is engineered with simplicity at the core — and our vibrant, growing developer community. We see a substantial and growing market need, and believe that DigitalOcean is perfectly positioned to lead this category in the years ahead.
While we have enjoyed great success since I co-founded the company in 2012, I believe we have barely scratched the surface. I’ve been reflecting on our next phase of growth and what it will take to reach our full potential, and it’s become clear to me that now is the right time to identify my successor as CEO of DigitalOcean.
I recognize where my strengths lie and where others will have more experience to give. With all of the exciting opportunities in front of us, including the possibility of an IPO — a long-term goal we have frequently discussed internally — I feel a new seasoned executive will be best to guide the company through the next chapter of our journey. We have engaged a leading search firm to help us find a great leader. One that will be inspirational, able to scale our operations beyond 1,000 people, evolve our go-to-market strategy, and help us reach our audacious vision. Someone who can build a global brand that could potentially help us become a publicly-traded company with the simplest cloud platform for developers to run applications of any size.
Once we’ve identified this person, I’ll be taking on a new role as Chairman of the Board, which will allow me to support our company vision and strategy while working closely with the new CEO.
When Moisey, Mitch, Alec, Jeff, and I started the company in 2012, we left our families and friends in New York to join the Techstars program in Colorado. We slept on bunk beds and worked relentlessly pretty much every day until midnight. Finding product-market fit didn’t happen overnight and it took months of iterating and refining our product offering. We had 400 users when we graduated from the Techstars program, and while we knew we had developed something special, trying to raise venture capital at that time was a real uphill battle. We heard many “no’s” from investors along the way, but believed in our long-term vision.
After returning to a small office in New York City, we launched the first SSD virtual machine service with unprecedented price-to-performance on January 15th, 2013. We instantly went from signing up a couple of new users per day to more than 100. I vividly remember sitting at our kitchen table with the co-founding team, having to manually install SSDs into our servers to keep up with the demand. It’s been a humbling journey to say the least, and I could not have imagined the growth, success, and scale we would achieve only five years later. DigitalOcean has accomplished so many incredible things over the years and I know that our product, people, and operations have never been stronger.
Aug 9, 2012 - Mitch, Alec, Moisey, me and Jeff walking on stage for Techstars demo day
We have raised $123M from some of the world’s leading VCs that share our belief that the developer will lead the continuing technology revolution. Today, we have a team of 400-plus employees around the world with growing offices in New York, Cambridge, Mass., and Bangalore. Our user base has grown with us and last year we crossed one million users from almost every country in the world. Over the last few years, our product went from a single offering, Droplet, to a complete cloud platform. We are extremely proud to be one of the largest and fastest-growing cloud providers in the world.
I’ve always said that putting the business first and doing what is right for DigitalOcean is my highest priority. I’m making this decision knowing that DigitalOcean’s best days are still to come. We have never been in a better position to begin this transition. We have a great leadership team in place, the business has very strong momentum, and we are a clear leader in our industry. I’m confident that our new CEO will be able to rapidly build on this strong foundation.
No matter who our next leader is, one thing that definitely won’t change is our unwavering commitment to delivering the industry’s simplest cloud computing platform, while building one of the world’s largest developer communities. All of the core elements that have contributed to our success — the powerful simplicity of the product, the dedication and talent of the team, and the passionate community of developers that we serve — will remain the same.
I am tremendously excited about DigitalOcean’s future and the milestones ahead. I want to thank everyone who has helped turn our dream and passion into reality. The skills I have learned and friendships I have made while helping to build this company will last me a lifetime, for which I will be forever grateful and I couldn’t be more excited for the journey ahead.
Onward and upward together,
As a company, we’ve always cared about contributing to developer culture in an authentic way, and one of the ways we do that is by adding moments of visual delight to everything we do, whether it's a Community tutorial, an interaction in the control panel, or a T-shirt at a conference. That is why, from the very beginning, DigitalOcean put an emphasis on building out a Brand Design team comprised of not just proficient graphic designers, but brilliant illustrators as well.
The Brand Designers at DigitalOcean are challenged every single day to transform extremely technical and esoteric content into approachable and friendly touch points. Lead Visual Designer Masami Kubo says, “We believe these technologies should be accessible to everyone, and a part of that is acknowledging and celebrating the diverse and quirky personality behind the humans that build these amazing things. Visuals and branding throughout the cloud computing industry are often disregarded or unconsidered, so it’s a unique opportunity for us as designers to bring that culture to life.”
We interviewed DO’s Brand (Visual) Designers Kasia Bojanowska, Masami Kubo, Pat Raubo, and Alex Mostov to learn more about their design process, how they illustrate technical concepts, and where they turn to for inspiration.
How do you approach technical topics as illustrators?
Masami: We’ve been illustrating technical topics for years, so the challenge now is how to keep it fresh and relevant. However, if we push the imagery too conceptual or meta, we run the risk of none of it making any sense to our audience. My approach now is to identify the primary action or message behind complex concepts, and focus on making that one thing really clear. I like to start minimal, then add elements sparingly to not distract from the primary message.
Alex: I came to the DigitalOcean team without much technical knowledge. In some ways I think this has actually been an advantage in creating conceptual illustrations. I create images that help me understand the concepts. I think and hope that inherently makes them more intuitive to others, too.
Where do you draw inspiration from for your designs?
Kasia: When starting a new project I definitely try to spend a good chunk of time looking for inspirations. Google image search, Pinterest, Dribbble, Behance are all wonderful resources for that. We have a few shared pinterest boards with stuff we like. I also get really inspired when I see great work being made by others on our team.
Pat: One of the benefits of working with a team of such enormously talented designers is that I draw inspiration from them and their work all the time. Masami and Kasia both do amazing work, and I’ve learned a great deal from both of them, as well as from Alex. I try to seek out inspiration from a number of things. Some have a pretty clear association with the kind of work we do at DO, like design and illustration done specifically for tech, but I also draw from editorial illustration, film, comics, and book covers, among other sources.
Illustrations by Kasia Bojanowska, Patricia Raubo, & Alex Mostov
How do you come up with new ideas for similar technical topics?
Masami: I think it actually helps for imagery with similar technical topics to have a common thread of imagery, so as to build a visual association. We have strict style guides for most of our platforms and campaigns, but some of these style guides allow for permutation in aesthetics to avoid looking too repetitive over time.
Pat: I like to first do some research to understand the basic concept of what I’m going to illustrate, and then add to my notes with simple schematics and/or sketches to see if there’s anything I can pull from those for the final visuals.
Alex: I will often try to think about representing a topic in a different kind of space or world. For examples if I create an image for a topic in a 2D space, the next time I will try to figure out how I could represent that same concept in a 3D space or from a different perspective.
What is one of your favorite projects you’ve worked on at DO thus far?
Pat: I worked on a series of illustrations for our Employee Handbook, which meant drawing a team of cute sea creatures in an office setting. I really enjoyed working on that project, and it was great to see people respond to the illustrations in such a positive way.
Masami: My favorite projects are often also the most challenging ones. And usually the more ambitious they are, the more compromises on vision I’ve had to make. But some of the most exciting stuff I’ve worked on here is the art direction and design of our office spaces, in collaboration with architects, fabricators, and our People team. I was expected to transform the space into a branded and navigable experience. It’s still a work in progress, but I love the challenge of designing for physical spaces.
Murals by Alex Mostov & Masami Kubo
What was one of the most challenging projects you’ve worked on at DO?
Kasia: Redesigning the DO logo was definitely the biggest challenge for me. The process was pretty high pressure but I was allowed enough time to really let myself explore and dig in deep. In this case having a supportive team to brainstorm and keep motivation high through all of the iterations was essential.
Masami: We did a design refresh of the marketing site a year ago, and it went through a lot of changes and push backs. The task was simple—refresh the designs and clean up the performance—but it involved approval from every department and stakeholder in the company. I was doing everything from art direction, web design layouts, and spot illustration. I learned a ton about project management and designing within web accessibility standards, thanks to Una Kravets. I felt creatively drained after the project was finished, and didn’t think it would be possible to revisit it with new ideas. Surprisingly, I am now leading a complete design overhaul for the marketing site, and I feel more equipped than ever to tackle all the challenges and make something more beautiful and smart than last year.
Sometimes you create visual assets that are targeted at a very specific audience, and you have to balance things like humor with cultural sensitivities. How does localization factor into your designs?
Masami: Part of our job is being aware and sensitive to any imagery that might have harmful or negative impacts to our community. We are fortunate to have a diverse employee base that cares about these things, so the more opinions we can gather, the better. We try to treat branding the same in any other countries as we do here. However, we do want to highlight our growing global coverage, so one way we approach this is to celebrate the unique design culture local to these countries. For example, the Frankfurt datacenter launch campaign featured designs inspired by Bauhaus Constructivist design. For the Bangalore datacenter launch, we created stylized renditions of local architecture. Being a developer from another country doesn’t necessarily mean you have vastly different tastes or interests, so it’s important for companies and designers to address these things authentically.
How do you create different kinds of content while maintaining brand consistency?
Kasia: For illustrations, we keep a consistent color palette. We have a list of prompts to help us throughout the process, but we do not have a very strict style guide when it comes to editorial illustration. We tend to have more fun and variation with all of our community and conference designs. However, we are definitely more strict about stylistic consistency when it comes to our website design.
Like much of DO, the Brand Design team is distributed across the world. What systems or processes do you have in place that allow for open communication and collaboration?
Pat: One of our team members, Kasia, is based in Poland, so we have a time difference of six hours between us. We started to make a habit of doing our daily stand ups and critiques early in the day to make sure we were all able to benefit from them. We have a private Slack channel which we use to stay in contact, to brainstorm, and to share ideas on projects.
Where do you see the DO brand going?
Masami: When I first joined DigitalOcean in 2014, the company was breaking into the cloud computing world by differentiating itself as friendly and accessible. At the time that meant being extra illustrative and bubbly with our designs. We wanted to let the developer community know that their content and culture deserves this kind of attention. That attitude and core value is still what drives every decision, but our aesthetics have matured and evolved just as our products and features have grown. The brand now has a diverse voice ranging from playful and young to mature and sophisticated, all under the same goal of enabling the developer community. I think this range directly reflects the diversity of users we want to speak to.
Alex: I really like DO’s brand evolution because I feel like the changes are made based on need and effectiveness rather than just trying to make a splash. I think the brand will continue to change in this deliberate way as the community and product develop. I also hope it will always maintain the sense of playfulness that I think makes DO special.
What is your best advice for designers just starting out?
Pat: I would encourage aspiring creative folks of any stripe to always stay curious (as cliched as it may sound, it’s advice I’ve followed that I feel has served me well) and seek out inspiration from a range of sources (museums, books, online communities, whatever floats your boat!), because you never know what’s going to be the seed that becomes the root of a fantastic idea. Feeding your mind will give you perspective and enrich your work.
That said, don’t wait around for inspiration to strike, either! It’s best not to be too precious about your work. Just sit down, make the thing, and make it to suit your standards. Then, when you think it’s done, work on it just a little bit more. Keep learning, and push yourself a bit more with each new project.
Do you enjoy our designers' creations? Download desktop wallpapers from some of their favorite illustrations.
“Our community is bigger than just us” — As DigitalOcean (DO) employees, we aim to keep this value at the front of our minds in all our work. Since the company was founded in 2012, we’ve worked hard to build a vibrant, engaging Community where everybody from beginners to professionals can learn from one another about working in the cloud.
It’s important to us that the Community emulates the best that tech has to offer by serving as a welcoming place where members can share their ideas and experiences. This is what led us to introduce the Write for DigitalOcean program. Write for DO gives Community members an opportunity to build their brand, develop their writing skills, and get paid for contributing to DigitalOcean’s collection of tutorials on open-source software deployment, configuration, and development.
We’re always looking for new ways to give back to the Community. To that end, we’re excited to announce some updates to the Write for DigitalOcean program and reintroduce it as “Write for DOnations” (currently in beta — the full program launch is coming later this year).
There are two main changes that we are excited to share:
DigitalOcean will match the payout to Community authors in the form of a donation to a tech-focused nonprofit, which they can choose from a predetermined list. We hope to add more organizations to this list over time, but as of the beta launch the available organizations fall into the following categories: Free and Open Source, Tech Education, Diversity and Inclusion in Tech, and organizations promoting a Free and Open Internet.
The typical payout for new tutorial content from Community authors will increase to $300, to be paid either via PayPal or as DO credit.
The Write for DOnations beta program will follow the same editorial structure as Write for DO:
- Anyone interested in becoming a DO Community author can apply by submitting a sample tutorial which showcases their ability to explain technical concepts to others.
- One of DigitalOcean’s editors will reach out to approved applicants and the two will work together to find a topic for an original, first-run article that would be exciting to the author and valuable to the broader DO Community.
- The author will write and submit their first draft, then collaborate one-on-one with their editor to revise their work to align with the DigitalOcean Style Guide.
At the end of this review process, the author’s tutorial will be published on the Community website and they will receive their payout. The author will then get to choose the nonprofit(s) that will receive their matching donation. Donations will be processed through Bright Funds, and authors’ donations can either go to a single tech-focused nonprofit or be evenly split between a group of nonprofits that share similar missions. Please note that the charitable contributions made by DigitalOcean through this program are not tax-deductible to the authors.
Since its launch, the Write for DigitalOcean program has allowed authors to share their diverse technical knowledge with the world while also improving their writing skills and growing their personal brand. Our team is always on the lookout for fresh content our community will love. To get a sense of which tutorial topics we’re particularly interested in, take a look at our suggested topics page.
Although Write for DOnations is still in development, we’re excited to help our Community authors make a real impact by donating to fantastic organizations that are working to shape the world of tech for the better.
We are actively seeking feedback to inform the full release of the the new Write for DOnations program. Check out the program’s FAQ page for more details, and please share any questions or comments about the Write for DOnations beta launch in the comments below or reach out to us directly at firstname.lastname@example.org.
A vision, a small prototype, and a PowerPoint presentation: that’s how Muzzley, a platform for interacting between Internet of Things (IoT) devices, was born three years ago. Today the Muzzley team works to solve a pain point for smart home consumers: managing their IoT devices from one interface, with minimum hassle. But they also place importance on transparency, privacy, and protecting their customers’ data.
In this episode, Muzzley co-founders, Domingo Bruges and Sasha Dewitt, discuss how Muzzley’s tech stack evolved to support a product that integrates with different vendors. They share insight into how they manage the data generated by consumer IoT devices, and how they approach consumer privacy and data production.
Subscribe to the The Deep End Podcast on iTunes, and listen to the latest episode on SoundCloud below:
Hollie Haggans heads up Global Partnerships for DigitalOcean’s Hatch program. She is passionate about startups and cold brew coffee. Get in touch with questions at email@example.com.
Benchmarks are a common way to measure and compare the performance of cloud compute servers. While standardized benchmarks are useful for establishing a consistent, broad set of comparison metrics, it can be useful and more practical to compare the performance of the actual tasks you run most often on your servers as well.
For example, how much time could you save when running your app's automated test scripts if you used a more powerful cloud server?
We compared the performance of Standard and Optimized Droplets when doing just this. Specifically, we used the basic React Boilerplate app, which includes a comprehensive set of testing scripts covering 99% of the project. Because the tests are CPU-intensive, we chose test execution time as our comparison metric for the two different Droplet configurations.
Server Setup and Testing Methodology
For the default environment, we used a Standard $40 Droplet, which is configured with 4 vCPUs (Intel Xeon CPU E5-2650L v3 @ 1.80GHz), 8GB of RAM, and 160GB of SSD storage.
For the comparison environment, we used an Optimized $40 Droplet, which is configured with 2 dedicated vCPUs (Intel Xeon CPU E5-2697A v4 @ 2.60GHz), 4GB of RAM, and 25GB of SSD storage.
Both Droplets were running Ubuntu 16.04, and we set both up using the following procedure.
After initial setup to create a non-root user and basic firewall, we verified the CPU architecture using lscpu. We installed Node.js using the PPA to get a recent version of Node.js that includes npm, the Node.js package manager, which we needed to execute the test scripts. Finally, we installed React Boilerplate by cloning the react-boilerplate repository and running
npm run setup to install its dependencies.
At this point, we had everything we needed to run the tests. To measure the time it takes to execute them, we used the utility program time, which summarizes the time and system resource usage for a given program command.
As a baseline, we first compared Droplet performance when running React Boilerplate's test suite with its default settings using
time npm test.
Because npm uses a test framework that can use all available processors, we also ran a single CPU comparison to better understand the impact of CPU on performance. For the single CPU comparison, we ran
time npm test -- --runInBand to force all of the automated tests to run sequentially. This test is relevant for applications that are not designed to use multiple CPUs, where a more powerful processor can improve performance.
Additionally, we found that setting the number of worker nodes to match the number of vCPUs on the server yielded the fastest overall test execution time, so we compared the best case setup on both servers as well. For the vCPU-specific comparison, we ran
time npm test -- --maxWorkers=4 for the Standard Droplet (which has 4 vCPUs) and
time npm test -- --maxWorkers=2 for the Optimized Droplet (which has 2 vCPUs).
We ran each of these tests five times on each server to look at the average execution time over a larger sample size.
So, how did the Standard and Optimized Droplets perform?
Here's an example (truncated for length) of the output from time npm test on the Optimized Droplet:
> firstname.lastname@example.org pretest /home/perfaccount/react-boilerplate > npm run test:clean && npm run lint [...] PASS app/containers/App/tests/index.test.js PASS app/containers/LocaleToggle/tests/index.test.js [...] PASS app/containers/HomePage/tests/actions.test.js Test Suites: 76 passed, 76 total Tests: 289 passed, 289 total Snapshots: 4 passed, 4 total Time: 14.725s, estimated 33s Ran all test suites. ---------------------------------|----------|----------|----------|----------|----------------| File | % Stmts | % Branch | % Funcs | % Lines |Uncovered Lines | ---------------------------------|----------|----------|----------|----------|----------------| All files | 100 | 100 | 100 | 100 | | app | 100 | 100 | 100 | 100 | | configureStore.js | 100 | 100 | 100 | 100 | | [...] sagaInjectors.js | 100 | 100 | 100 | 100 | | ---------------------------------|----------|----------|----------|----------|----------------| real 0m22.380s user 0m23.512s sys 0m0.884s
The output we’re interested in is
real time, which is the actual elapsed wall-clock time it took to execute the tests. In this example, the test script completed in 22.380 seconds.
These are our results showing the average execution time across multiple runs:
The Optimized Droplet outperformed the Standard Droplet in all tests, but as we explain in the next section, this isn't the only factor to consider when choosing the right configuration for your use case.
When comparing cloud servers with the goal of optimizing price-to-performance and resources, it's important to test the applications that you plan to run on the server in addition to comparing standard benchmarks.
In measuring the execution times of the react-boilerplate project's automated tests, our results showed a small improvement of 4.9% when using a $40 Optimized Droplet compared to a $40 Standard Droplet. For applications that perform similarly and do not take full advantage of all CPUs, choosing the $40 Standard Droplet may be a better choice because of its additional memory (8GB vs 4GB) and larger SSD (160GB vs 25GB).
However, the Optimized Droplet executed 37.3% faster when running the tests sequentially. For compute-intensive applications that use a single vCPU, this difference may be significant enough to choose the Optimized Droplet for the same price as the Standard Droplet.
If your application can run in a clustered mode with a specific number of CPU resources, you may be able to optimize price to resources by using a Standard Plan with more CPU, RAM and SSD versus a lower number of higher powered CPUs. We saw the best performance on both Droplets when we set the number of application instances to match the number of available vCPUs, where Optimized Droplets still outperformed Standard Droplets by a significant 21.7%, though the additional RAM and SSD in Standard Droplets may be preferable.
The tests performed in this article are not designed to be comprehensive, but are tailored to the types of applications that typically consume time and CPU resources. To maximize price-to-performance and resources for your applications, you can test various Droplet configurations and measure execution times of the typical jobs you place on your servers.
We have always been community-focused at DigitalOcean. On our Community site, we offer a few ways that developers can connect with each other, through sharing projects, learning about meetups, or answering questions. Additionally, we have over 1,800 technical tutorials, written by both external community members and internal technical writers, that have been designed to support the learning pathways of software engineers and system administrators as they develop their skills and scale their projects.
Since joining the DigitalOcean Community team, I have focused on curriculum development and technical writing related to Python software development. Today, I am happy to share that we are repackaging the “How To Code in Python 3” tutorial series as an eBook that can serve as both a teaching tool for beginners and a point of reference for more seasoned developers.
Our goal in making this tutorial series available in an eBook format is to facilitate access to this educational content. This is especially significant for people with limited internet access, long commutes without wifi, or who primarily access written material from mobile devices. Our hope is that the people who will benefit from this eBook will become more knowledgeable about how coding works, and thereby increase the number of technology stakeholders, decision makers, and knowledge producers who can work to build better software for everyone. By offering a new format of this content, we would like to drive engagement with and interest in software development across broader and more diverse communities.
Creating an eBook
This eBook project came about during a DigitalOcean company-wide Hackathon. Hackathons offer a great environment to test out projects that teams have been thinking about taking on, but have not been able to devote the time and resources to during a regular work week. Our team, which we nicknamed Bookworms, consisted of Brian Boucheron (Technical Writer), Kasia Bojanowska (Senior Visual Designer), and myself.
Brian was our eBook developer. He used pandoc, GNU Make, and Perl scripting to automate the eBook creation process from the original tutorial markdown. For some final stylistic choices, he has done some hand crafting along the way, but has worked to ensure that the eBook can be read as its user desires across devices. We intend to release relevant source code in a repository for others to extend and modify.
Kasia has done a lot of the design work that sets DigitalOcean’s tutorials and brand apart, and has conceived of a new vibrant cover for this eBook. Designs and imagery that invite readers in are an instrumental element of book conception, and Kasia’s dynamic image inspires curiosity and playfulness.
Since the Hackathon, I have worked to ensure that this eBook is made publicly available from major eBook distributors, is catalogued in libraries, and made available as an open educational resource in schools and universities.
What Is an Open Educational Resource?
Open educational resources (OERs) are texts or digital assets that can be used for teaching, learning, and research. What is significant about them is that they are openly accessible and openly licensed. At DigitalOcean, we use a Creative Commons License on all of our tutorials so that others can freely translate our technical content to other languages to encourage learning.
Each version of the eBook that is made publicly available will have a separate ISBN in order to facilitate access to the book. I have been working with the librarians at the City University of New York’s Brooklyn College and Graduate Center in order to catalogue the eBook and make it available for students as an open educational resource. If you would like to see this eBook in your library, share this WorldCat link with your local librarian.
By having this eBook available in libraries and within OER repositories, more students will be able to access computer programming learning material without having to pay textbook prices for that privilege.
We hope that readers who learn from or reference this eBook will be empowered to make their own contributions to open-source code via software and documentation pull requests or repository maintenance. Our community is bigger than just us, and building software together can make sure that everyone has an opportunity to participate in the technology we use every day.
You can now download the free eBook in one of the following formats:
Lisa Tagliaferri is the manager of Community Content at DigitalOcean. In addition to writing about Python, Lisa helps people find solutions through technology and infrastructure. Holding a PhD from CUNY, Lisa has a continued interest in interdisciplinary research, and is committed to community building through education. Find her on Twitter @lisaironcutter.