We continue to look into some of the AR/VR trends in the ecosystem, focusing on the main differences between developers and non-developers active in this space. You can view our first part of this article here.
22% of AR/VR non-developers are learning to code
15% of people involved in AR & VR as non-developers have zero knowledge of how to code, whereas 17% are actively coding to get things done. There is a large range of skills, but the biggest group here are those that are actively trying to build on their coding skills, with 22% of AR/ VR non-developers doing so. This indicates that no-code tools, whilst useful for getting things done, don’t cover the needs of more than 1 in 5 AR & VR practitioners who are subsequently learning to code to overcome these limitations. Despite the large amount of effort – and marketing – that has gone into positioning no-code tools as a solution for non-coders to get into AR & VR without worrying about writing code, a sizeable proportion of those who do get involved subsequently decide they need coding skills to realise their vision after all. This represents an opportunity for platforms aspiring to appeal to non-coders to create more functionality in these tools in order to capitalise on this under-served audience.
Amongst non-developers trying to improve their coding skills the most popular languages are Java (28%), C++ (26%), C# (25%) and JavaScript (22%). 17% don’t write code for their AR/VR projects, and 15% use a visual development tool. This indicates that non-developer AR & VR practitioners see the value in knowing how to code, but that they still want to create things while they’re learning.
Games is the most popular app category for developers and non-developers alike
AR & VR practitioners are primarily focused on creating entertainment and services products, but the primary focus is different for developers and non-developers. 77% of AR/VR developers are building products in the services category (such as business logistics products) whereas only 67% of non-developers are doing so.
The most popular category for AR and VR practitioners is games & toys, with 52% of developers and 44% of non-developers working on products in this category. The picture is somewhat different for other entertainment products (such as moves and animation), with 65% of non-developers working on apps in this category and only 47% of developers operating here. This indicates that developers are using their coding experience to experiment and create games in AR and VR, whilst non-developers are inspired by other use cases.
Industrial applications (such as manufacturing and construction) for AR/VR are much less popular for both groups, but a larger proportion of developers are creating products in this category than non-developers. As AR and VR mature and stabilise, commercial applications will become more viable and we will see further innovations in industrial areas from developers and non-developers alike, but the pull of building entertainment apps will still be strong.
Which AR/VR skills will you need to sharpen in 2021? Which tools do you think will be irrelevant as early next year? Our State of AR/VR survey is live. Spend 10 minutes sharing your experiences, we’ll donate $0.10 to Techfugees to for every completed response.
Clean code is vital in every aspect of software development as well as mobile app development. A code that’s clean means it’s easy to understand and to change. Writing clean code is paramount in creating a successful and maintainable product. What is clean is, of course, subject to every developer’s take. Here is the definitive guide to clean code.
There are many considerations when it comes to what constitutes a clean code as well as the best coding practices. Nonetheless, there’s no particular distinction. Again, it is subjective to what a developer considers clean, based on the product being built.
Why Clean Code?
Clean code is important to care since code almost is never written only once and forgotten. Most of the time, you and others have to work on the code. Understanding of the code leads to work efficiency. The code is not only intended for computers but humans as well. Writing clean code means minimizing maintenance expenses.
Furthermore, it means making it much easier when fixing bugs as well as working on code for many years a lot more enjoyable. In essence, clean code means making life easier for those involved in the project. However, it doesn’t mean being obsessed with clean code. It has to provide value, thus do not spend countless to make it perfect.
Anyway, clean code doesn’t occur on the first try. The key is adopting a mindset that always strives to enhance the code that you work on. Clean code is paramount since it makes or breaks a project.
Guide to Clean Code Characteristics
1. It should be elegant. It has to be pleasing to read, making a reader smile in such a way that a well-crafted music box would or even a well-designed car.
2. It is focused. Every module, class, and function exposes a one-minded attitude that’s free from distraction and pollution by surrounding details.
3. It’s taken care of. Someone took the time to keep it orderly and simple. Moreover, they have paid close attention to details, meaning that they cared.
4. It doesn’t have duplication.
5. Runs all tests.
6. Minimize entities like methods, classes, functions, and others.
Writing Clean Code
Clean code follows and embraces specific practices. The practices are what make code readable, more comprehensible, cleaner, and simple. Implementing some of the following could bring positive results.
Make readable code. Never neglect its comprehensibility and readability.
Utilize meaningful names for variables, methods, and functions
Review the code regularly.
Allow one method or function to perform just one task.
Use comments for clarification.
Be consistent.
1. Make readable code. It’s always a possibility that another would get your code or else if you’re working in the same software development company then you can re-use the code. It is of the best interest of all to write code in such a way that makes it easy to read as well as understand. Using whitespace is the easiest way. It isn’t a must to write code that looks minified. Rather, use line breaks, empty lines, and indentation to make the code structure more readable.
2. Utilize meaningful names for variables, methods, and functions. Meaningful means names that are descriptive enough that others would be able to comprehend the purpose of the function, method, or variable. In simple terms, the name itself should suggest the method, function, or variable is used or what it carries. Nevertheless, descriptive names do not mean you’re free to use as many characters as you wish. Rule of thumb would be limiting names to three or four words.
3. Review the code regularly. Simply writing code is not enough. The next step would be to maintain its cleanliness. Review it regularly, clean it, and try improving it. Otherwise, it would become outdated. The same as with the device, to keep them in the best shape requires regular updates.
4. Allow one method or function to perform just one task. Let every method or function do just one task. This may be simple but could change everything and help you write clean code, or at least something cleaner than before. Moreover, functionalities and methods also become predictable.
5. Use comments for clarification. Regardless of how you struggle to come up with meaningful methods, variables, or functions, on its own, the code still would not be clean and understandable as it should be. There would be lines that require elaboration. Using comments via the code helps to fix this. Comments explain to other people why you are writing them and the reason why it’s written in that manner. This way, people would not have to make a guess. Comments should be used only when necessary and not for explaining bad code. Writing endless comments won’t help transform a code that’s poorly written into clean code. A bad code should be fixed by improving it, not adding instructions on how to use it.
6. Be consistent. Stick to specific coding styles or practices and use it everywhere. It’s not a good idea to use different styles or practices in another project. It’s not as smooth and natural as it could be getting back to old code. Select coding practices set and stick to them in all projects. It would be much easier to return to an older code and proceed where you left off or to improve code. It’s a good idea to experiment on new coding practices. Furthermore, it could help look for better ways to do work. Nonetheless, it would be preferable to experiment with different practices on a separate project or exercise instead of on the main project.
Why Strive for Clean Code
Clean code is easy to understand and readable by everyone. Writing clean code is a critical mindset and it takes practice. Nobody is perfect, including you. There is always an opportunity to refactor or improve code when you review it after a few days or a few weeks. Therefore, begin writing a clean code as you can from the first line to work more on improving performance and logic.
Pros
1. Better use of time. The first recipient of clean code is, of course, the programmer. Working on a project for months sometimes makes it easy to forget what you’ve done with the code. This is particularly true when a client comes back with changes. Making changes is easier with clean code lines.
2. Easy debugging. Bugs are inevitable whether you write clean or dirty code. Clean code, however, makes for faster debugging, whatever your expertise or experience may be. Managers or colleagues could help and jump in to help you.
3. Easier for new members of the team to get on board. Principles of clean code help to get onboard a new programmer. It helps to get a new programmer on board with clean code. No documentation is required to understand the code and a newbie could jump directly into it. This saves time on training and for a new member to adjust to the project.
4. Much efficient maintenance. Maintenance doesn’t mean fixing bugs. Any project would need changes, new features to existing ones. In any software project, maintenance is the major cost. New features or additional ones always are an afterthought. Clean code makes fast and easy maintenance.
5. Feel good. Clean code makes you feel good and confident to share it with others or with a client. You need not fear of breakdown and you would also be able to fix defects faster and this means you get to enjoy programming more.
6. Easier to solve problems. The approach to problem-solving changes when writing clean code. Furthermore, software design and algorithm design become more intentional and elegant.
7. Communicated ideas. A clean code minimizes the change of misunderstandings when working with other developers and programmers. Furthermore, this also means lesser bugs to deal with in the future.
Going Further with Clean Code
Majority of the basics in making clean code are common sense. Nonetheless, even with the most basic software, success requires paying attention and focusing on details. Products increasingly have more at stake than pride and money. In today’s age where we have autonomous vehicles on the road, the rules on code structuring and writing have gained relevance. Furthermore, more diligence should be applied to security-critical and safety systems.
Industries like defense, automotive, aerospace, banking and finance, and medical device manufacture have stringent coding compliance standards. The code should meet industry standards. Source code could be scanned using static code analysis tools. Furthermore, the tools could also detect vulnerabilities in security, hidden defects, and ensure adherence to the best coding standards.
Undoubtedly, custom software development companies create products for their clients. Clients could do whatever they want with the software or product. They could use it internally or even sell it to somebody else. Most importantly however is that they could modify or extend it themselves.
To be able to do this, they need a clean code. Thus, when building software, it is of utmost importance to deliver clean code at all times. Again, clean code truly matters. A clean and readable code enables continuity of the product. Furthermore, it makes it possible for another person to continue the work and enjoy doing so. The result is a lesser bug and easier to maintain software.
Did you enjoy this guide to clean code? Is there anything else that a developer should consider?
About
Working as a manager in a software development company Tatvasoft.com. Vikash always has a passion to explore more about software development and likes to share his bylines among relevant audiences. He is a full time blogger and you will find his informative bylines around many corners of blogs related to development. You can always find him on Twitter.
What will be the biggest dev trends in 2021? Help us find out! Take the new Developer Economics survey, answer a few questions about dev tools, platforms, technologies for a chance to win cool prizes!
Check out our latest research reports and graphs, based on data from developers who took our global surveys.
Evers since the Covid-19 outbreak took on global pandemic proportions, a lot has changed about how developers work, communicate, and stay sane, above all. There are certain stereotypes about developers (i.e developers are “loners”, most working remotely, they get most of their entertainment online anyway etc) that make it all too easy to assume that quarantines were easy on developers. Did they feel the impact of lockdowns and social distancing as sharply as other people? We wanted to debunk these stereotypes and ask developers what really affected their lives during these uncertain times.
To understand what’s happening, we ran a small poll in May 2020 asking the members of our community to describe their day-to-day during quarantine. How did the new social distancing rules affect their work, education, entertainment, and lifestyle choices? This mini-survey was intended to be fun and entertaining first and foremost. 138 developers from our community took part. We thank them once again for being good sports and helping us create these light-hearted insights on an otherwise very heavy subject.
The results are summed up in this Covid-19 infographic, which we hope you’ll find amusing.
You may be nodding your head as you scroll down and think “yes, me too!” or you may have a very different experience that you’d like to share. Whatever the case, we invite all developers to take part in our new Developer Economics survey, where we investigate new trends in software development and what the future holds.
Do you like this infographic? Feel free to share it on social media and don’t forget to tag us as the source!
If you’re interested in dabbing your toes in the front-end development, this post if for you. Our community is rich with developers covering all major areas of development, so we reached out to one of our loyal members to share a few front-line tips with you via this mini professional front-end developer guide!
Dominic Myers is a professional front-end developer with a wealth of experience. He spends most of his day being fascinated by, developing and implementing the newest trends in web development, primarily HTML, CSS and JavaScript, or whatever will get the job done. Here he shares his professional front-end developer guide to the front-end development triangle.
A Professional Front-end Developer Guide
I’ve spent the past couple of years writing, editing (and editing some more) a book about front-end development (which you can purchase here or here), which is finally making it’s slow and ponderous way into the light. That use of words suggests that it’s a vast and weighty tome of a book – and it certainly was when I first submitted it – but after all that editing, it’s finally down to a fighting weight, and I think it’s a better book for that. One thing I was keen to point out is the triangle of technologies we, as front-end developers, need to be conversant. In much the same way that fire isn’t possible without fuel, heat and oxygen, front-end development is impossible without a more than cursory knowledge of HTML, CSS and JavaScript (JS).
HTML
In the dim and distant past, when attending the introductory lecture for a conversion Computer Science MSc, I didn’t understand why the rest of the students sniggered when someone answered HTML when asked if we had any experience of programming. Once the chuckling had subsided sufficiently, the lecturer was keen to point out that while HTML was not a programming language, with its lack of all those things recognisable as being associated with programming languages such as variables and functions it couldn’t be; it was still a language – be it a markup language. As such, it involves a certain level of abstraction.
The writer of HTML needs to have an appreciation of the milieu in which it will reside: the browser. Browsers themselves are unusual beasts with all sorts of wild and weird characteristics. The same browser might act differently on different architectures, or in identical hardware but with varying levels of user privileges, or with plugins installed. The unfortunate HTML author might even have to deal with superseded versions of browsers (Yes, IE11, I’m looking at you! I spend a significant amount of time massaging ES6 into ES6 for IE11, most often by hand but sometimes with Babel – but even Babel has its limits).
Along with the vagaries of the browser, an appreciation of what the browser will do with HTML is necessary. It isn’t merely rendered line by line to the user interface; instead, it is converted to Document Object Model (DOM). I like to think of the DOM as something like a tree with a trunk quickly splitting into two – one being something of a stub and the other adorned with a whole plethora of branches, sub-branches and twigs. This second branch is when the HTML writer gets to play, and the palette of elements they get to play with grows larger all the time! I guess my analogy might get strained though, my knowledge of Dendrology is limited, but suffice it to say that there are many HTML elements, some of which have fallen from favour, while still others have found favour and been embraced.
Without this tree as a foundation, front-end development is nigh on impossible. I can’t tell you how many times I’ve seen CSS or JS courses suggesting that a rudimentary knowledge of HTML is a requirement. Rudimentary knowledge? HTML is our bread and butter and, while we can use CSS to get a `div` to behave like a `span`, why not use a `span` in the first place? But this brings us neatly to our next side of the triangle: CSS.
CSS
It is arguable that if my fellow student had said CSS instead of HTML, then the laughter might’ve been even louder – this was a few years ago before you say anything. CSS acts as adornment for our DOM tree; it gives its elements’ colour if you will. That’s not to say that altering the colouring is its limit – but it’s still essential. Also, please take note of when they were laughing; CSS was then not Turing Complete (footnote: Turing Completeness denotes a language where a question is asked and answered – there is no guarantee how long that answer might take though). CSS3 was demonstrably Turing Complete in 2011, though follow through on the links please, its a fascinating read.
CSS3 is profoundly compelling and allows the canny front-end developer to avoid all sorts of weird and wonderful JS trickery. Trees in autumn can be bare and stark but can still hold a beauty all their own, but trees in the flush of Spring, Summer and Autumn are nigh on always a delight to behold. CSS serves as the foliage and, while I appreciate aesthetics plain HTML I love decorated trees, all the while knowing that without the foundation of HTML – the trunk and branches if you will – all that gorgeous adornment would be on the ground, blowing in the wind.
CSS has taken over from JS in some areas, though there is still a tendency for front-end developers to reach for JS rather than utilise CSS.
I can understand this: if all you’ve got is a hammer, everything looks like a nail. If I can do something quick and dirty using JS rather than research the CSS technique, then I used to do that. I did before I clocked just how performant it was to use the native capabilities inherent in CSS, it’s lightning-fast so learn and use it, please!
That brings us nicely to the next side of our triangle: JS.
JS
I dread to imagine what the reaction would’ve been to my fellow student saying JavaScript. I dare say snorts of derision rather than any form of laughter. JS has a history of being seen as something of a joke language, which is a shame as it is rather elegant – especially now.
If HTML is the bare tree and CSS is the foliage, then JS allows us to act like tree surgeons with superpowers! With JS we can make all sorts of alterations to the DOM (the DOM is, after all, merely an API for HTML). We can add, subtract and alter the constituents of the HTML with JS, we have superpowers with JS. But take heed of my caution above regarding CSS, just because you can do something with JS, first please check you can’t do the same thing with CSS! After all, with great power comes great responsibility!
There is an excess of books and courses on JS and the frameworks and libraries that have sprung up about it. Strangely, such an overabundance can present something of a barrier to those seeking to enter front-end development. With a whole feast presented to you, it’s easy to find an old and obsolete resource and end up eating something well past its sell-by date, getting food poisoning and resolving to give it up as a bad job.
But, should you find something bright, shiny and new and that works off the bat, or drink the kool-aid by some other route, the sheer power of JS can mean that you leave good old HTML and CSS by the roadside. You might even get tempted to start implementing some CSS-in-JS and never have to touch a CSS file throughout your career, only looking at the MDN Web Docs to find out what the JS name for a CSS property is.
Thoughts
I think it is this disconnect between JS and the other two sides of the triangle that prompted Chris Coyier to write about “The title ‘Front-End Developer’ is obsolete.”. Something of a provocative title and one that he doesn’t endorse but uses as a launchpad to explore the confusion regarding the term “front-end developer”. Most, if not all, job postings for front-end developers will ask for one of three things: Angular, React or Vue. That list is likely to change though, and it’ll change at a rate of knots, in much the same way as the things themselves and their associated toolchains will also change. Sometimes the postings won’t even mention HTML or CSS or will suggest candidates should know SCSS, further alienating those whose bread and butter is HTML and CSS.
Does this mean that we’re looking at a further sub-division within development? The need for developers dedicated to working with the front-end led to a separation of developers into front- and back-ends. Are we now seeing a further split between HTML and CSS developers and JS developers, with HTML and CSS developers getting short shift? I’m not so sure TBH, those dedicated JS developers do generate HTML and CSS, but do so via JS, leading to a further question of how well they appreciate the nuances of both HTML and CSS? Perhaps more of a focus during preparation for the career on these would suffice. HTML is rock solid, and CSS standardised nowadays so the necessity of knowing how anything other than evergreen browsers interprets identical HTML and CSS.
I’m not sure about what to do to address the situation of this further fracturing, or even if it’s worth discussing – I’m just conscious of it, and I’m wary of losing something. JS gives you superpowers and enables the canny developer to spin a whole DOM out of nothing, made up of HTML and CSS. The superpowered JS has some mean powers but still, in the end, relies upon a thorough knowledge of both HTML and CSS, it isn’t a one-man-band. All three together and employed skillfully are an orchestra with a profound impact and rich timbre. We owe it to ourselves as developers to embrace the full triangle. a cursory knowledge of HTML, CSS and JavaScript (JS).
About
Dominic Myers is a front-end developer with a wealth of professional experience. He spends most of his day being fascinated by, developing and implementing the newest trends in web development, primarily HTML, CSS and JavaScript, or whatever will get the job done. He shares his knowledge online via his blog and forums such as Stack Overflow.
If you are involved in front-end and want to share your views, visit our latest survey and help shape the trends.
Did you enjoy this professional front-end developer guide? Do you have a topic that you are passionate about and would like to share with our developer audience in our blog? Get in touch!
Augmented Reality (AR) and Virtual Reality (VR) have captured the public imagination for decades; from the Holodeck in Star Trek to Ironman’s Heads Up Display, this technology is synonymous with visions of the future. Recently however, AR & VR processing has become commonplace on smartphones and companies like Oculus & Sony have released consumer-quality headsets. In this post we take a look at some of the AR/VR trends in the ecosystem, focusing on the main differences between developers and non-developers active in this space. Let’s look at those AR/VR trends.
AR & VR are the smallest individual software sectors
Considered individually, Augmented Reality and Virtual Reality remain the smallest software sectors out of the ones we research (the others being mobile, desktop, web, games, backend, industrial IoT, consumer electronics, data science & machine learning). Even when combined, AR and VR (AR/VR) are only marginally bigger than Consumer Electronics, the next smallest sector. Only 0.4% of people are involved solely in AR or VR, the rest are involved with at least one other development area.
AR/VR trends – Only 0.4% of developers are involved solely in AR and/or VR
Of the 9% of people involved with AR or VR almost half (46%) are involved with both AR and VR. This shows that there is a significant overlap in the skills needed to work in these sectors. There are more people involved solely with VR (31%) than with AR (24%). AR is slightly less mature than VR and there are some technical challenges in AR (occlusion, optics & object registration, for example) which are still being resolved, this also means that there is a smaller market for AR products, as the technology is less established. This results in a slightly higher barrier to entry and subsequently a smaller number of people involved in AR than for VR only.
AR & VR trends – practitioners are mostly hobbyists
One of the defining features of AR & VR practitioners is their diverse involvement in different development areas. As previously discussed, the number of people involved solely in AR & VR is very small, but in fact, many of them are also involved in multiple development areas. Over 60% of practitioners involved in AR and VR are involved in 5 or more sectors in total. This is a large contrast with respondents who don’t work in AR or VR, where only 9% only are involved in 5 or more sectors.
Most people who are involved in AR or VR are hobbyists, and not just in AR & VR. These people are more likely to be hobbyists in every other sector than people not involved in AR or VR. They are technology enthusiasts who like to experiment outside of their professional duties, and are currently experimenting with AR & VR, potentially with a view to incorporating AR & VR into their existing development projects.
Looking at this from the other side, 28% of VR professionals also consider themselves to be hobbyists in the same sector. Out of AR professionals, 24% take on AR projects in their spare time as a hobby. This is higher than most other sectors, with machine learning being the next highest at 26%, then games at 25%. This shows that AR & VR practitioners are enthusiastic about the sector, often having passion projects on the side.
57% of AR & VR hobbyists work professionally in at least one other development area
We also see more diversity in the type of roles that AR & VR practitioners do. Because AR & VR sit at the intersection of arts and technology, practitioners often fulfill hybrid (both technical and non-technical) roles. In fact 35% of AR practitioners fulfill a hybrid role. Subsequently, people involved in AR/VR are less likely to be ‘Pure Developers’ (people solely fulfilling developer-type roles) than those involved in other sectors. This difference is especially pronounced for respondents working in VR or in AR and VR, with only 34% and 38% respectively working solely in developer roles, compared with 50% of respondents working in AR only.
Practitioners who are involved in VR only, or VR and AR are more than twice as likely as their counterparts who are only involved in AR to be in non-developer roles. This shows that non-developers tend to favour working in VR in some capacity.
Drilling down into the roles, we see that 49% of AR practitioners work as programmers or software engineers, compared with only 37% and 32% respectively for VR practitioners and those who work in both AR and VR. Many AR practitioners are also involved in web & mobile development and machine learning. This suggests that these coders are interested in AR from a technical point of view, looking to challenge themselves by using the latest technology or to implement AR in their projects.
On the other hand, VR practitioners and those involved in both AR and VR are more than twice as likely as AR practitioners to be game designers or work as product managers. The popularity of these roles reflects the quick uptake of VR by the game market – moving from being an emerging technology to generating revenue.
Not only do AR & VR practitioners hold different roles compared to people involved in other sectors, but they also wear a lot of different hats. More than 20% of people involved in AR or VR take on 4 or more roles, compared with only 12% of people involved in other sectors. We already know that AR & VR developers are often passionate hobbyists, but it’s also clear that they have diverse interests and skills. This diversity comes from the fact that as AR and VR development technology matures, tools are appearing which require fewer technical skills to create an AR or VR product. This attracts non-developers who can more easily realise their vision.
AR & VR practitioners take on more roles than people working in other sectors
What other AR/VR trends are there?
Almost as many AR & VR developers use 3D animation software as use IDEs
While there is some overlap in the technologies used by developers and non-developers involved in VR, none of them have a strong appeal for both audiences. The Oculus technology suite comes closest to being the go-to platform for both developers and non-developers, with over 35% of each audience using the platform. Playstation VR, Windows 10 Mixed Reality & Google Daydream all attract a good proportion of non-developers (36%, 28% and 26% respectively), but fail to appeal to VR developers. This landscape creates an opportunity for a technology vendor willing to invest in widening support and access for one (or both!) audiences, as a unified tech stack would provide large efficiency benefits to integrated teams by integrating with other tools and platforms, streamlining training needs and reducing the variety of tools being used.
Unity Mobile AR, AR Core and AR Kit lead the pack of software tools for people creating AR products, but all of these tools are favoured more by developers than by non-developers. This suggests that there is space in the AR software market for a tool which allows non-developers to more easily realise their creative vision.
Over half of developers use game engines and 48% use 3D modelling and rendering software. The high uptake of these technologies amongst AR/VR developers is testament to the powerful efficiency gains available from the abstraction they offer, as well as that AR, and especially VR, lend themselves to game development.
Over 50% of AR & VR developers use game engines
We’ve already seen that practitioners that undertake developer and non-developer roles (hybrid developers) make up a sizeable proportion of those involved with AR & VR, and this is validated by the popularity of 3D animation software (39%) and designer tools (30%) amongst the technologies used by AR & VR developers. In fact, almost as many AR & VR developers here use 3D animation software as use IDEs!
Backend-as-a-service, ML APIs and app store analytics are all used by less than 15% of AR & VR developers. The usage rate of app store analytics for AR & VR developers is 3 percentage points lower than for game developers, and 10 percentage points lower than for mobile developers. This suggests that AR/VR developers are focusing on getting the basics right, rather than trying to extract maximum value from their apps’ marketing funnel.
We see some overlap in the tools used by non-developers; 49% use 3D modelling and rendering software, 43% use game engines and 42% use 3D animation software. The high usage rates of the more artistic technologies is to be expected, given that these people are, by definition, not developers.
The Adobe toolset is the most popular software tool amongst non-developers, but the next three most popular software tools are all SDKs used by 24% of AR non-developers (ARCore, ARkit and Unity Mobile AR). This begs the question, do non-developers involved in AR & VR know how to code?
What are your biggest pain points in getting into AR/VR development? You can share your experiences in our AR/VR survey.
Who are thetop companies contributing to open source? This blog post looks at how CodersRank used publicly shared data to answer this question, and how they created a series of data visualization videos.
The boom of open source software brought a change in technology that shaped the world as we know it today.
Open source exists thanks to the hard work of dedicated programmers and developers. It has become the foundation of cloud computing, software-as-service, next generation databases, mobile devices, the consumer internet, and more.
We, at CodersRank, are great admirers of open source. Almost every one of us contributes to open source regularly, and we sometimes work on a project or two together.
In this blog post, we’ll introduce you to a video that we created. This video gives you a visual representation of companies that contributed the most to open source since 2012. If you find this data interesting, then you’d probably love to know the methodology behind it. We’ll show you exactly how we gathered the data and then how we gave it a visual spin.
Video: Top Companies Contributing to Open Source
The video, “Top Companies Contributing to Open Source | 2012-2019”, is part of a series of data visualization videos that we came up with at the end of 2019. We made these out of curiosity, after realizing that you could see certain trends forming if you put together some of the publicly shared data.
Haven’t seen the video? Here it is:
Behind-the-scenes of our method
This will be a quick overview of our method – please see the actual code used further down this page.
Measuring contributions
In measuring the contributions we only considered the commits. We know that there are many other ways to contribute to a project not just commits but in this particular case we wanted to focus on the commits.
Defining contributing authors
We relied on the email addresses of the authors. The second part of the email is usually the company’s domain.
Assigning commits to a company
There are around 2.4B public commits in GitHub (since 2011) and we had to analyze each and every one of them to answer this question. Thankfully, not manually!
Using the GitHub API to extract that amount of data would have been impossible. Thanks to the GitHub Archive Project, all the public GitHub events are stored in a publicly available BigQuery database. Using SQL to extract data made the process easy and painless.
Cleaning up the data
After we counted the commits for each company, the data needed to be cleaned. First, we excluded email providers like gmail, hotmail, yandex etc. Then, we excluded a few more, as there were some cases where the commits were made by bots.
Converting the results to the expected format
We used Flourish to create the videos. The data had to be converted into a format that is acceptable for Flourish (i.e.: handling months with no data from a given company).
Implementation
Step 1: get the commits/domains
The payload column is what we needed here, since it contained the email address. In our example it is a454492e42fd9810e577ebee548c7e59bd883bca@live.com.au. GitHub hashed the first part of the email, but we didn’t need that anyway, because we were only curious about the domain-level information.
The query to count the commits/domain name looked like this:
## pre-2015 API
CREATE TEMP FUNCTION
json2array(json STRING)
RETURNS ARRAY<STRING>
LANGUAGE js AS """
return JSON.parse(json).map(x=>JSON.stringify(x));
""";
WITH
export_domains AS(
SELECT
DATE_TRUNC(DATE(created_at), month) AS month,
emails,
ARRAY(
SELECT
REGEXP_EXTRACT(x, "@(.*)")
FROM
UNNEST(emails) x
WHERE
REGEXP_EXTRACT(x, "@(.*)") IS NOT NULL) AS domains
FROM (
SELECT
* EXCEPT(array_commits),
ARRAY(
SELECT
JSON_EXTRACT_SCALAR(x,
'$[1]')
FROM
UNNEST(array_commits) x) emails
FROM (
SELECT
created_at,
json2array(JSON_EXTRACT(payload,
'$.shas')) array_commits
FROM
`githubarchive.day.20130101`
WHERE
type='PushEvent' )))
SELECT
month,
flattened_domains AS email_domain,
COUNT(flattened_domains) AS domain_count
FROM (
SELECT
month,
flattened_domains
FROM
export_domains
CROSS JOIN
UNNEST(export_domains.domains) AS flattened_domains )
GROUP BY
month,
email_domain
ORDER BY
month,
domain_count DESC
After 2015, the format of the payload changed a bit and required a slightly different query:
## post-2015 API
CREATE TEMP FUNCTION
json2array(json STRING)
RETURNS ARRAY<STRING>
LANGUAGE js AS """
return JSON.parse(json).map(x=>JSON.stringify(x));
""";
WITH
export_domains AS(
SELECT
DATE_TRUNC(DATE(created_at), month) AS month,
emails,
ARRAY(
SELECT
REGEXP_EXTRACT(x, "@(.*)")
FROM
UNNEST(emails) x
WHERE
REGEXP_EXTRACT(x, "@(.*)") IS NOT NULL) AS domains
FROM (
SELECT
* EXCEPT(array_commits),
ARRAY(
SELECT
JSON_EXTRACT_SCALAR(x,
'$.author.email')
FROM
UNNEST(array_commits) x) emails
FROM (
SELECT
created_at,
json2array(JSON_EXTRACT(payload,
'$.commits')) array_commits
FROM
`githubarchive.day.20150102`
WHERE
type='PushEvent' )))
SELECT
month,
flattened_domains AS email_domain,
COUNT(flattened_domains) AS domain_count
FROM (
SELECT
month,
flattened_domains
FROM
export_domains
CROSS JOIN
UNNEST(export_domains.domains) AS flattened_domains )
GROUP BY
month,
email_domain
ORDER BY
month,
domain_count DESC
The result looked like this:
Row
month
email_domain
domain_count
1
2015-01-01
gmail.com
131357
2
2015-01-01
users.noreply.github.com
8802
3
2015-01-01
python.org
5786
4
2015-01-01
hotmail.com
4942
5
2015-01-01
fhda.edu
3888
6
2015-01-01
yahoo.com
3216
7
2015-01-01
etudes.org
2736
8
2015-01-01
qq.com
1955
9
2015-01-01
sly.mn
1908
10
2015-01-01
foothill.edu
1848
Step 2: exclude email providers
The heavy lifting was done by BigQuery. We exported the results into a .csv file and used the good old Jupyter Notebooks to clean up the data.
As you can see in the example result, not surprisingly, the first one was gmail.com. Our next task was to remove the email providers from the list.
And we also added some other blacklisted domains (excluded_domains.txt):
.(none)
91177308-0d34-0410-b5e6-96231b3b80d8
samo-laptop.(none)
dd0e9695-b195-4be7-bd10-2dea1a65a6b6
ubuntu.(none)
b8fc166d-592f-0410-95f2-cb63ce0dd405
b9a71923-0436-4b27-9f14-aed3839534dd
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
0b4bb1d4-4e5a-0410-9cc4-b2b747904278
709f56b5-9817-0410-a4d7-c38de5d9e867
iki.fi
Gmail.com
none
example.com
1a063a9b-81f0-0310-95a4-ce76da25c4cd
localhost.localdomain
localhost
localhost.(none)
home
b8457f37-d9ea-0310-8a92-e5e31aec5664
li7-202.members.linode.com
g
users.noreply.github.com
us.door43.org
mailinator.com
smullindesign.com
review.openstack.org
nyarlabo.com
boston.com
li.gugod.org
niob.xnis.de
sly.mn
kazer.org
recoil.org
tsaousis.gr
rituwall.com
cbrese.com
renovateapp.com
scrapers.everypolitician.org
Step-by-step code walkthrough
Load BigQuery results
from tqdm.notebook import tqdm
import pandas as pd
import numpy as np
tqdm.pandas()
df = pd.read_csv("./email_domains_large.csv")
Merge the list of domains we want to exclude:
free_providers = list()
with open("./free_email_provider_domains.txt", "r") as f:
for line in f.readlines():
free_providers.append(line.strip())
excluded_emails = list()
with open("./excluded_domains.txt", "r") as fe:
for line in fe.readlines():
excluded_emails.append(line.strip())
free_providers = free_providers + excluded_emails
Add a new column to the dataset, whether the domain is a free email providers’ domain
df["free"] = df["email_domain"].progress_apply(lambda x: x in free_providers)
Create a list without the email providers
df_filtered = df[(~df["free"])].copy()
Add a row counter and limit the data to those domains that appear at least once among the top 30. This will make the final dataframe smaller and easier to handle.
rn = list()
for _, df_tmp in df_filtered.groupby("month"):
t = list(range(df_tmp.shape[0]))
rn += t
df_filtered["rn"] = rn
domains = np.unique(df_filtered[df_filtered["rn"] <= 30]["email_domain"])
Step #3: format data
As it was mentioned before, we used Flourish to create the video. In some cases there were empty months (the company didn’t have any commits) and Flourish expected the columns to be months not companies. So we had to make this transformation too.
More and more companies are recognizing the importance of open source software development and are committed to support it.
We hope that visualizing just a slice of the data that these amazing men and women generate round the clock is a way to acknowledge their hard work. Thanks to them and the millions of hours they invested to build open source products, we get to use our everyday apps and software seamlessly.
Thank a developer today!
About
Adrienn Tordai Growth Marketer / Pizza Enthusiast @CodersRank. I love the Blue Jays, books, and The Office. Tell Elon I said hi. Always waiting for a Steam sale. | CodersRank: Our goal is supporting DEVELOPERS’ growth by their always up to date, professional CodersRank profile