Tech News - Programming

Glitch, the web apps creating tool, has made a series of major announcements yesterday. Glitch is a tool that lets you code full-stack apps right in the browser, where they’re instantly deployed. Glitch, formerly known as Fog Creek Software, is an online community where people can upload projects and enable others to remix them. Creating web apps with Glitch is as easy as working on Google Docs. The Glitch community reached a milestone by hitting 2.5 million free and open apps, more than the number in Apple's app store. Many apps on Glitch are decidedly smaller, simpler, and quicker to make on average focused on single-use things. Since all apps are open source, others can then remix the projects into their own creations. Glitch raises $30M with a vision of being a healthy, responsible company Glitch has raised $30M in a Series A round funding from a single investor, Tiger Global. The round closed in November 2018, but Anil Dash, CEO of Glitch said he wanted to be able to show people that the company did what it said it would do, before disclosing the funding to the public; the company has grown twice in size since. Glitch is not your usual tech startup. The policies, culture, and creative freedom offered are unique. Their motto is to be a simple tool for creating web apps for people and teams of all skill levels, while fostering a friendly and creative community and a different kind of company aiming to set the standard for thoughtful and ethical practices in tech. The company is on track for building one of the friendliest, most inclusive, and welcoming social platforms on the internet. They’re built with sustainability in mind, are independent, privately held, and transparent and open in business model and processes. https://twitter.com/firefox/status/1148716282696601601 They are building a healthy, responsible company and have shared their inclusion statistics, and benefits like salary transparency, paid climate leave (consists upto 5 consecutive work days taken at employee’s discretion, for extreme weather), full parental leave and more in a public handbook. This handbook is open-sourced so anyone, anytime, anywhere can see how the company runs day to day. Because this handbook is made in Glitch, users can remix it to get their own copy that is customizable. https://twitter.com/Pinboard/status/1148645635173670913 As the community and the company have grown, they have also invested significantly in diversity, inclusion, and tech ethics. On the gender perspective, 47% of the company identifies as cisgender women, 40% identify as cisgender men, 9% identify as non-binary/gender non-conforming/questioning and 4% did not disclose. On the race and ethnicity front, the company is 65% white, 7% Asian, 11% black, 4% Latinx, 11% two or more races and 2% did not disclose. Meanwhile, 29% of the company identifies as queer and 11% of people reported having a disability. Their social platform, Anil notes has no wide-scale abuse, systematic misinformation, or surveillance-based advertising. The company wants to, “prove that a group of people can still create a healthy community, a successful business, and have a meaningful impact on society, all while being ethically sound.” A lot of credit for Glitch and it’s inclusion policies goes to Anil Dash, the CEO. As pointed by Kimberly Bryant, who is the founder of BlackGirlsCode, “'A big reason for Glitch's success and vision though is Anil. This "inclusion mindset" starts at the top and I think that is evidenced by the companies and founders who get it right.” Karla Monterroso, CEO Code2040 says, “It becomes about operationalizing strategy. About creating actual inclusion. About how you intentionally build a diverse team and an org that is just.” https://twitter.com/karlitaliliana/status/1148641017823764480 https://twitter.com/karlitaliliana/status/1148653580842196992   Dash notes, “It’s the entire team working together. Buy-in at every level of the organization, people being brave enough to be vulnerable, all doing the hard work of self-reflection & not being defensive. And knowing we’re only getting started.” Other community members and tech experts have also appreciated Dash’s resilience into building an open source, sustainable, inclusive platform. https://twitter.com/TheSamhita/status/1148706941432225792 https://twitter.com/LeeTomson/status/1148655031308210176   People have also used it for activist purposes and highly recommend it. https://twitter.com/schep_/status/1148654037518168065 Glitch now on VSCode offering real-time code collab Glitch is also available in Visual Studio Code allowing everyone from beginners to experts to code.  Features include real-time collaboration, code rewind, and live previews. This feature is available in preview; users can download the Glitch VS Code extension on the Visual Studio Marketplace. Features include: Rewind: look back through code history, rollback changes, and see files as they were in the past with a diff. Console: Open the console and run commands directly on Glitch container. Logs: See output in logs just like on Glitch. Debugger: make use of the built-in Node debugger to inspect full-stack code. Source: Medium https://twitter.com/horrorcheck/status/1148635444218933250 For now the company is dedicated solely to building out Glitch and release specialized and powerful features for businesses later this year. How do AWS developers manage Web apps? Introducing Voila that turns your Jupyter notebooks to standalone web applications PayPal replaces Flow with TypeScript as their type checker for every new web app

Last week, Joe Groff of the Swift Core Team published a post on the Swift forums discussing refining the Swift Generics model which was established by the Generics Manifesto, almost three years ago. The post introduced new changes to improve the UI of how generics work in the Swift language. The first part of this group of changes is the SE-0244 proposal. This proposal introduces some features around function return values. SE-0244 proposal The SE-0244 proposal addresses the problem of type-level abstraction for returns.  At present Swift has three existing generics features in Swift 5. Type-level abstraction The syntax of a type level abstraction is quite similar to generics in other languages, like Java or C#. In this users type out the function definitions, use angle brackets, and conventionally use T for a generic type, all of it happening at the function (or type) level. Each of the functions for Type-level abstraction has a placeholder type T. Each call site then gets to pick what concrete type is bound to T, making these functions very flexible and powerful in a variety of situations. Value-level abstraction Value-level abstraction deals with individual variables. It is not concerned with making general statements about the types that can be passed into or out of a function; instead, developers need to worry only about the specific type of exactly one variable in one place. Existential type Many swift libraries consist of composable generic components which provide primitive types along with composable transformations to combine and modify primitive shapes into more complex ones. These transformations may be composed by using the existential type instead of generic arguments. Existential types are like wrappers or boxes for other types. However, they bring more dynamism and runtime overhead than desired. If a user wants to abstract the return type of a declaration from its signature, existentials or manual type erasure are the two choices. However, these come with their own tradeoffs. Tradeoffs of existing generics features The biggest problem of the original genetic manifesto is generalized existentials. Present existentials have a variety of use cases that could never be addressed. Although existentials would allow functions to hide their concrete return types behind protocols as implementation details, they would not always be the most desirable tool for this job. This is because they don’t allow functions to abstract their concrete return types while still maintaining the underlying type's identity in the client code. Also, Swift follows in the tradition of similar languages like C++, Java, and C# in its generics notation, using explicit type variable declarations in angle brackets. However, this notation can be verbose and awkward. So new improvements need to be made for existing notations for generics and existentials. Reverse generics Currently Swift has no way for an implementation to achieve type-level abstraction of its return values independent of the caller's control. If an API wants to abstract its concrete return type from callers, it must accept the tradeoffs of value-level abstraction. If those trade-offs are unacceptable, the only alternative in Swift today is to fully expose the concrete return type. These tradeoffs led to the introduction of a new type system feature to achieve type-level abstraction of a return type. Coined as reverse generics by Manolo van Ee, this system behaves similar to a generic parameter type, but whose underlying type is bound by the function's implementation rather than by the caller. This is analogous to the roles of argument and return values in functions; a function takes its arguments as inputs and uses them to compute the return values it gives back to the caller. This process has already begun with a formal review in progress on SE-244: Opaque Result Types. This proposal covers the “reverse generics” idea and some keyword in return types. “If adopted”, says Tim Ekl, a Seattle-area software developer, “it would give us the ability to return a concrete type hidden from the caller, indicating only that the returned value conforms to some protocol(s)”. He has also written an interesting blog post summarizing the discussion by Joe Groff on the swift forums page. Note: The content of this article is taken from Joe Groff’s discussion. For extensive details, you may read the full discussion on the Swift forums page. Swift 5 for Xcode 10.2 is here! Implementing Dependency Injection in Swift [Tutorial] Apple is patenting Swift features like optional chaining

Red has been around for a while now and has been extending its purpose from systems programming to various fields like Blockchain, Android development, among others. Recently, Red introduced some modern implementation support for Android programming. The way Red can be used in Android programming is using a specific bridge, that allows the Red code to call the whole Android API in Java. This allows you to write Android applications in Red language without having to write any Java code. Red, in its latest release, has introduced a new and improved Java bridge for Android. Java bridge was first introduced in Red's version 0.3. With this bridge, the Red programs are able to interface Java Virtual Machine through JNI (Java Native Interface). The new Java bridge now replaces the old implementation and is now optimized for efficient bindings of Red programs to the Android API in Java. This optimization greatly improves the performance of the Android application. To explain this, Red has published a short overview of Red/View backend on Android, the source code for which can be found on this GitHub repo. Red his also been working on implementing several features in its v0.7 release. The community has released a short list of features on its site, though all the work on these features is done in a private repository. The private repo will be opened to selected developers soon for testing and fine-tuning. Some of the features that are set to come in the new release are as follows: Full set of Red/View widgets support Draw & Shape dialects full support Compatibility with Android GUI themes Device-independent coordinate system Updated APK building toolchain for targeting API 23+ Android systems Improved ARM backend, support for ARMv7+ Android support Red has also released a roadmap for the upcoming releases which shows that v0.7 is going to be an important milestone for Android development with Red. Apart from the work in Android, Red has been concentrating on the Blockchain-related wave of tasks, Full I/O, among other high-priority milestones. As of now, Red v0.6.4 has been released on the GitHub repository. The community is still considering a 0.6.5 release, to insert a small extra milestone before going into the 0.7 release. Build your first Android app with Kotlin Why are Android developers switching from Java to Kotlin?

GitHub's importance to software developers can't be overstated. In the space of a decade it has become central to millions of people's professional lives. For it to be taken away, then, must be incredibly hard to take. Not only does it cut you off from your work, it also cuts your identity as a developer. But that's what appears to have happened today to Hamed Saeedi, an Iranian software developer. Writing on Medium, Saeedi revealed that he today received an email from GitHub explaining that his account has been restricted "due to U.S. trade controls law restrictions." As Saeedi notes, he is not a paying GitHub customer, only using their free services, which makes the fact he has been clocked by the platform surprising. Does GitHub really think a developer is developing dangerous software in a public repo? Digging down into the terms and conditions around U.S. trade laws, Saeedi found a paragraph that states the platform cannot: "...be used for services prohibited under applicable export control laws, including purposes related to the development, production, or use of nuclear, biological, or chemical weapons or long range missiles or unmanned aerial vehicles." The implication - in Saeedi's reading at least - is that he is using GitHub for precisely that. But the impact of this move is massive for Saeedi. The incident has echoes of when Slack terminated Iranian users' accounts at the end of 2018, but, as one Twitter user noted, this is even more critical because "GitHub is hosting all the efforts of a programmer/engineer." How has GitHub and the developer community responded? GitHub hasn't, as of writing, responded publicly to the incident. However, it would be reasonable to assume that the organization would lean heavily on existing trades sanctions against Iran as an explanation for the actions. The ethical and moral implications of that notwithstanding, it's a move that would ensure that would protect the company. Given increased scrutiny on the geopolitical impact of technology, and current Iran/U.S. tensions, perhaps it isn't that surprising. But it has received condemnation from a number of developers on Twitter. One commented on the need to break up GitHub's monopoly, while another suggested that the incident emphasised the importance of #deletegithub - a small movement that sees GitHub (and other ostensibly 'free' software) as compromised and failing to live up to the ideals of free and open source software. Mikhail Novikov, a developer part of the GatsbyJS team, had words of solidariy for Saeedi, reading the situation in the context of the U.S. President's rhetoric towards Iran: https://twitter.com/freiksenet/status/1154297497290006528?s=20 It appears that other Iranian users have been affected in the same way - however, it remains unclear to what extent GitHub has been restricting Iranian accounts.

The Red Hat Certified Engineer (RHCE) certification program has certified skilled IT professionals for around 20 years now. This program has also one of the leading certification programs for Linux skills. As new technologies are coming up and industries are equally evolving, the focus has now shifted to hybrid cloud implementations. With this new development, shift automation has become an important skill to learn for Linux system administrators. So, the team behind RHCE thought that there is a need for evolving the RHCE program for Red Hat Certified Professionals. What changes are expected? In the updated RHCE program, the team is shifting the focus to automation of Linux system administration tasks with the help of Red Hat Ansible Automation and will also be changing the requirements for achieving an RHCE credential. With the upcoming release of Red Hat Enterprise Linux 8, the team at RHCE will be offering a new course and a new certification exam. Red Hat System Administration III: Linux Automation (RH294) The team at RHCE has designed this course for Linux system administrators and developers who are into automating provisioning, configuration, application deployment, and orchestration. The ones’ taking up this course will learn how to install and configure Ansible on a management workstation and will get a clear idea about preparing managed hosts for automation. Red Hat Certified Engineer exam (EX294) The RHCE exam will focus on the automation of Linux system administration tasks that uses Red Hat Ansible Automation and shell scripting. The ones who pass this new exam will become RHCEs. What will remain the same? Ken Goetz, vice president of Training and Certification at Red Hat writes in a blog post, “One thing that we want to assure you is that this is not a complete redesign of the program.” The candidates can still get an RHCE by having first passed the Red Hat Certified System Administrator exam (EX200) and then later passing an RHCE exam while still being an RHCSA. The Red Hat Enterprise Linux 7 based RHCE exam (EX300) will remain available for a year post the new exam gets released. How does it impact candidates? Current RHCE The RHCE certification is valid for three years from the date the candidate has become an RHCE. The period of the RHCE can be extended by earning additional certifications that can be applied towards becoming Red Hat Certified Architect in infrastructure. Candidates can renew the RHCE before it becomes non-current by passing the new RHCE exam (EX294). Aspiring RHCE An RHCSA who is progressing towards becoming an RHCE can continue preparing for the Red Hat Enterprise Linux 7 version of the course and take the current RHCE exam (EX300) till June 2020. Or else they can prepare for the new exam (EX294), based on the upcoming release of Red Hat Enterprise Linux 8. Red Hat Certified Specialist in Ansible Automation The ones who are currently Red Hat Certified Specialist in Ansible Automation can continue to demonstrate their Ansible automation skills and knowledge by earning RHCE via the new process. Ken Goetz, vice president of Training and Certification at Red Hat writes in the post, “We are aligning the RHCE program, and the learning services associated with that program, to assist individuals and organizations in keeping up with these changes in the industry.”   To know more about this news, check out Red Hat’s blog post. Red Hat Satellite to drop MongoDB and will support only PostgreSQL backend Red Hat announces CodeReady Workspaces, the first Kubernetes-Native IDE for easy collaboration among developers Red Hat drops MongoDB over concerns related to its Server Side Public License (SSPL)  

Researchers from Northeastern University, University of Massachusetts, Amherst and Czech Technical University in Prague, published a paper on the Impact of Programming Languages on Code Quality which is a reproduction of work by Ray et al published in 2014 at the Foundations of Software Engineering (FSE) conference. This work claims to reveal an association between 11 programming languages and software defects in projects that are hosted on GitHub. The original paper by Ray et al was well-regarded in the software engineering community because it was nominated as the Communication of the ACM (CACM) research highlight. And the above mentioned researchers conducted a study to validate the claims from the original work. They used the experimental repetition method, which was partially successful and found out that association of 10 programming languages with defects is true. Then they conducted an independent reanalysis which revealed a number of flaws in the original study. And finally the results suggested that only four languages are significantly associated with the defects, and the effect size (correlation between two variables) for them is extremely small. Let us take a look at all the 3 researches in brief: 2014 FSE paper: Does programming language choice affect software quality? The question that arises from the study by Ray et al. published at the 2014 Foundations of Software Engineering (FSE) conference is, What is the effect of programming language on software quality? The results reported in the FSE paper and later repeated in the followup works are based on an observational study of a corpus of 729 GitHub projects that are written in 17 programming languages. For measuring the quality of code, the authors have identified, annotated, and tallied commits that are supposed to indicate bug fixes. Then the authors fitted a Negative Binomial regression against the labeled data for answering the following research questions: RQ1 Are some languages more defect prone than others? The original paper concluded that “Some languages have a greater association with defects than others, although the effect is small.” The conclusion was that Haskell, Clojure, TypeScript, Scala and Ruby were less error-prone whereas C, JavaScript, C++, Objective-C, PHP, and Python were more error-prone. RQ2 Which language properties relate to defects? The original study concluded that “There is a small but significant relationship between language class and defects. Functional languages have a smaller relationship to defects than either procedural or scripting languages.” It could be concluded that functional and strongly typed languages showed fewer errors, whereas the procedural, unmanaged languages and weakly typed induced more errors. RQ3 Does language defect proneness depend on domain? A mix of automatic and manual methods has been used for classifying projects into six application domains. The paper concluded that “There is no general relationship between domain and language defect proneness”. It can be noted that the variation in defect proneness comes from the languages themselves which makes the domain a less indicative factor. RQ4 What’s the relation between language & bug category? The study concluded that “Defect types are strongly associated with languages. Some defect type like memory error, concurrency errors also depend on language primitives. Language matters more for specific categories than it does for defects overall.” It can be concluded that for memory, languages with manual memory management have more errors. Also, Java stands out as the only garbage collecting language that is associated with more memory errors. Whereas for concurrency, Python, JavaScript, etc have fewer errors than languages with concurrency primitives. Experimental repetition method performed to obtain similar results from the original study The original study used methods of data acquisition, data cleaning, and statistical modeling. The researchers then planned for experimental repetition. Their first objective was to repeat the analyses of the FSE paper and obtain the same results. They used an artifact coming from the original authors that had 3.45 GB of processed data and 696 lines of R code for loading the data and performing statistical modeling. According to a repetition process, a script generates results and match the results in the published paper. The researchers wrote new R scripts for mimicking all of the steps from the original manuscript. They then found out that it is essential to automate the production of all tables, numbers, and graphs to iterate multiple times. Researchers concluded that the repetition was partly successful and according to them: RQ1 produced small differences but had qualitatively similar conclusions. The researchers were mostly able to replicate RQ1 based on the artifact provided by the authors. The researchers found 10 languages with a statistically significant association with errors, instead of the eleven reported RQ2 could have been repeated but they noted issues with language classification. They noted that RQ3 could not be repeated as the code was missing and also because their reverse engineering attempts failed. RQ4 could not be repeated because of irreconcilable differences in the data.  Another reason was that the artifact didn't contain the code which implemented the NBR for bug types. The Reanalysis method confirms flaws in the FSE study Their second objective was to carry out a reanalysis of RQ1 of the FSE paper. i.e., Whether some languages are more defect prone than others? The reanalysis differs from repetition as it proposes alternative data processing and statistical analyses for addressing methodological weaknesses of the original work. The researchers then used methods such as data processing, data cleaning, statistical modeling. According to the researchers, the p-values for Objective-C, JavaScript, C, TypeScript, PHP, and Python fall outside of the “significant” range of values. Thus, 6 of the original 11 claims have been discarded at this stage. Controlling the FDR increased the p-values slightly, but did not invalidate additional claims. The p-value for one additional language, Ruby, lost its significance and even Scala is out of the statistically significant set. And a smaller p-value (≤ 0.05) indicates stronger evidence against the null hypothesis, so the null hypothesis can be rejected in that case. In the table below, grey cells are indicating disagreement with the conclusion of the original work and which include, C, Objective-C, JavaScript, TypeScript, PHP, and Python. So, the reanalysis has failed to validate most of the claims and the multiple steps of data cleaning and improved statistical modeling have also invalidated the significance of 7 out of 11 languages. Image source: Impact of Programming Languages on Code Quality The researchers conclude that the work by the Ray et al. has aimed to provide evidence for one of the fundamental assumptions in programming language research, that is language design matters. But the researchers have identified numerous problems in the FSE study that has invalidated its key result. The paper reads, “Our intent is not to blame, performing statistical analysis of programming languages based on large-scale code repositories is hard. We spent over 6 months simply to recreate and validate each step of the original paper.” The researchers’ contribution provides thorough analysis and discussion of the downfalls associated with statistical analysis of large code bases. According to them, statistical analysis combined with large data corpora is a powerful tool that might even answer the hardest research questions but the possibility of errors—is enormous. The researchers further state that “It is only through careful re-validation of such studies that the broader community may gain trust in these results and get better insight into the problems and solutions associated with such studies.” Check out the paper On the Impact of Programming Languages on Code Quality for more in-depth analysis. Samsung AI lab researchers present a system that can animate heads with one-shot learning Researchers from China introduced two novel modules to address challenges in multi-person pose estimation AI can now help speak your mind: UC researchers introduce a neural decoder that translates brain signals to natural sounding speech

GitLab Web IDE, aimed to simplify the workflow of accepting merge requests, is now available in GitLab 10.7, along with other features focused on improving C++ and Go code security and improving Kubernetes integration. The GitLab Web IDE was initially released as a beta in GitLab 10.4 Ultimate. The primary goal of this IDE was to streamline the workflow to contribute small fixes and to resolve merge requests. This allowed developers to contribute without storing their changes and switching to a new branch locally, then back.This could be of particular interest to developers who have a significant number of PRs to review, as well as to developers starting their journey with Git. GitLab Web IDE has the familiar layout of many graphical IDEs, with a left panel showing the files belonging to the project and a middle panel allowing to view and edit their contents. The right panel in GitLab Web IDE is the commit panel, which allows developers to keep track of which files make up the commit, to review changes, edit the commit message, and control whether the commit goes to the master branch or to a new branch, and whether to merge the changes or not. GitLab Web IDE GitLab has made its Web IDE open source with the goal of letting the developer community contribute to its development and improvement. Setting up a local development environment, or needing to stash changes and switch branches locally, can add friction to the development process. Using the Web IDE you can change multiple files, preview Markdown, review the changes and commit directly all from a browser. You can even open the diff from a merge request and get a side by side view of the changes. The latest release of Web IDE comes with performance improvements and the ability to contribute small fixes and resolve merge request feedback. GitLab 10.7 also released SAST for Go and C/C++ Additionally, GitLab 10.7 also extends GitLab Static Application Security Testing (SAST) by adding support for C/C++ and Go. GitLab SAST is a set of security tools aimed to analyze source code to detect known vulnerabilities. In addition to C/C++ and Go, SAST supports Python, Java, and Ruby on Rails. GitLab SAST is somewhat reminiscent of GitHub Security Alerts, which support Ruby and JavaScript, while Python support is in the workings. Another interesting change brought by GitLab 10.7 is Deploy Tokens, which provides support for long-lived read-only authenticated sessions for specific needs, such as when using Kubernetes to orchestrate a bunch of containers in a CI pipeline. Indeed, to flawlessly handle pod restarts and auto scaling, Kubernetes requires ongoing access to the container registry. This was previously available through CI job token, which had the downside of expiring once Kubernetes completed its task. As a workaround, personal access tokens could be used, but this could be undesirable when the access token had to be shared among multiple users. Deploy token provides a solution to both limitations. GitLab 10.7 includes many more new features, such as parametrized CI/CD control flow, project badges, subgroup issues boards, and others. Do not miss the official announcement for full details. The Microsoft-GitHub deal has set into motion an exodus of GitHub projects to GitLab GitLab’s new DevOps solution Microsoft is going to acquire GitHub

Soft skills have been high on the tech agenda for a while now. This was largely down to the stereotypical (and unfair) image of the IT team as quiet, uncommunicative and awkward. But it is also related to broader changes in tech. Today, more people have a stake in software related projects. Product and project managers, even financial managers, will have their work impacted by software. That means everyone's communication around it is so important. This year's Skill Up report clearly highlights that developers are aware of how valuable soft skills really are. A huge 96% of respondents said they believe that developing soft skills is important: The Skill Up 2018 report will be available to download on Monday 4 June. Perhaps this isn't that surprising. We all know how much of a difference effective communication can make on a project. Without good communication, the technical bits of work become even harder. Why soft skills are important to developers working today If we go back to the stereotype of the ring-fenced IT team, it's not hard to see why soft skills are so valued by business leaders and management figures. It's almost as if trainers and consultants and management have conspired, saying 'we need these engineers to be more like us'. But whatever the management industry want from tech pros, it's clear that the real advantage of developing soft skills are for developers themselves. Here are just a few reasons why soft skills are so important for developers: It makes collaboration easier. You can't of course, collaborate if you don't communicate. And in today's Agile-centric software world, clear communication is crucial. When you're working to tight deadlines, being clear about your challenges and problems is vital. Soft skills can change how you focus on problems. Communication changes the way you understand problems. It changes the way they are framed. For example, is the database issue simply a technical issue, or is there a wider point about what the knock on effect for the user will be? There's usually a number of technical solutions, but to select the best one, you often need a frank and clear discussion about the impact different decisions might make. Soft skills open up your career path. When you develop your soft skills you find that you occupy a subtly different role within your team or even within your organization. You become more visible to other people - maybe even more trusted. That can only be a good thing. At a superficial level it's about status; but more importantly it allows you to push forward your own interests. How often have you found your opinions and ideas discounted or ignored? Yes, maybe your ideas were just really bad, but maybe you just didn't quite communicate them properly. Similarly, soft skills are also essential for anyone networking. True, networking is rarely anyone's favorite pastime, but doing it well could do wonders for your future. Also, meeting people is sometimes fun! Good people do exist! It makes work more enjoyable. Work isn't going to be great every day. But anyone who's worked in a job they hate will probably know that communication challenges are often at the root of their dissatisfaction. Of course, sometimes other people are the problem. But if you can keep up your end of the bargain, you've done all you can. And if you can start to help other people develop soft skills then you're well on your way to becoming an important and valuable leader. You learn more when you communicate. This really comes back to collaboration, but it's a little more specific than that. When technology changes so quickly and there are so many options out there - from what you learn to how you learn it - engaging with others can be so important. This might just be about the conversations you have with colleagues. But it's also the wider conversations you take part in within a given community. Perhaps you contribute to a forum, or maybe just like tweeting - either way you're not only playing an important role in the community, you're also pushing your knowledge and understanding forward. The reasons why soft skills are important could be huge. And given 96% of developers believe it to be important, it would seem that no one really needs convincing. However, it is important to see how soft skills impact different parts of your job, and even your life. Yes it's about writing great emails, but it isn't just that. Yes it's about learning how to network at conferences but it's also much more than that. You can't have great technical skill without soft skills The bottom line is that it's hard to be a great technician without soft skills. It's possible, but very rare. Nothing technical happens in a vacuum - technical things are always about people. Forget management speak and training courses: that, really, is the one thing you need to remember. Read next Soft skills every data scientist should teach their child ‘Soft’ Skills Every Data Pro Needs

Yesterday, reports from 9to5 Google says that as per the updated Google Mobile Services (GMS) agreement. Per the new terms, OEMs who utilize their own gesture navigation systems cannot have those available in the device's initial setup if it ships with Android 10. Google has struggled to devise a new navigation system for Android over the last few releases. The two-button design from Pie is not liked much in the market, and the new full-gesture setup in Android 10 also has its critics. However, with the new agreement, you will see a lot of Google's gestures in the upcoming new Android 10 devices. At this year’s Google I/O 2019, the company announced that it would support the new gestures and the three-button navbar going forward. It didn't rule out OEMs having their own custom gesture navigation and will indeed let them keep those, but there will be some restrictions. Notably, devices shipping with Android 10 will need to have either classic three-button nav or Google's gesture navigation enabled out of the box. This makes it sound like the two-button "pill" setup will be effectively dead. Android 10 devices will not offer custom navigation in the initial setup Phones often let users choose their navigation options during setup, but Android 10 will not offer custom gesture navigation as an option in the setup wizard at all. So, you'll probably be able to turn on Google's gestures, but something like Samsung's swipe-up targets (see below image) will only be available if you dig into the settings. Source: 9to5 Google Hence, the updated Google Mobile Services agreement puts into perspective what Google really wants for Android users. Manufacturers can still include their own navigation solutions, but those solutions aren’t to be immediately available to the users during the setup wizard. Users must go into the device settings to toggle alternative navigation systems after the initial setup. Not only are OEM-specific navigation systems not allowed during setup, but manufacturers can’t even prompt users to use them in any way. No notifications. No pop-ups or any other way. Also, Google also requires OEMs to hide their custom navigation systems deeper into the settings. Manufacturers can put these settings under new sections like “advanced” or something similar, not easily accessible to the user. This isn’t necessarily a bad call by Google. More uniformity throughout the Android ecosystem can only be a good thing. The gestures will mature quicker, apps will be forced to adhere to the new navigation systems, and users will get used to it more easily. Google Mobile Services requires new Android devices compatible with Type-C ports The new Google Mobile Services agreement also outlines the technical requirements that smartphone device makers must meet in order to preload Google Mobile Services. Nearly every Android smartphone or tablet sold internationally have met these requirements because having access to Google apps is critical for sales outside of China. A subsection 13.6 of this document is titled “USB Type-C Compatibility” which states: “New DEVICES launching from 2019 onwards, with a USB Type-C port MUST ensure full interoperability with chargers that are compliant with the USB specifications and have the USB Type-C plug.” On Reddit, this news has got significant traction and Android users are discussing that this move by Google is good only if the gesture usage works well. Here are some of the comments, “Im sure people will hate this, but im for easier usage for the general public.” Another user responds, “Sure. As long as the gesture usage works really, really well. If it doesn't, this is a bad move.” Google Project Zero discloses a zero-day Android exploit in Pixel, Huawei, Xiaomi and Samsung devices Google’s DNS over HTTPS encryption plan faces scrutiny from ISPs and the Congress Google Chrome Keystone update can render your Mac system unbootable Google’s V8 JavaScript engine adds support for top-level await Google announces two new attribute links, Sponsored and UGC and updates “nofollow”

OpenSSH 7.9 has been released with some new features and bug fixes. There are new features like support for signalling sessions and client and server configs. In bug fixes, invalid format errors and bugs in closing connections are solved. New features in OpenSSH 7.9 Most port numbers are now allowed to be specified using service names from getservbyname(3). This is typically /etc/services. The IdentityAgent configuration directive is allowed to accept environment variable names. This adds the support to use multiple agent sockets without having to use fixed paths. Support is added for signalling sessions via the SSH protocol. However, only a limited subset of signals is supported. The support is only for login or command sessions and not subsystems that were exempt from a forced command via authorized_keys or sshd_config. Support for "ssh -Q sig" to list supported signature options is added. There is also "ssh -Q help" that will show the full set of supported queries. A CASignatureAlgorithms option is added for the client and server configs. It allows control over which signature formats are allowed for CAs to sign certificates. As an example, this allows to ban CAs that sign certificates using the RSA-SHA1 signature algorithm. Key revocation lists (KRLs) are allowed to revoke keys specified by SHA256 hash. Allowing creation of key revocation lists straight from base64-encoded SHA256 fingerprints. This supports removing keys using only the information contained in sshd(8) authentication log messages. Bug fixes in OpenSSH 7.9 ssh(1), ssh-keygen(1): Avoiding Spurious "invalid format" errors while attempting to load PEM private keys when using an incorrect passphrase. sshd(8): On receiving a channel closed message from a client, the stderr file descriptor and stdout are closed at the same time. Processes don’t stop anymore if they were waiting for stderr to close and were indifferent to the closing of stdin/out. ssh(1): You can now set ForwardX11Timeout=0 to disable the untrusted X11 forwarding timeout and support X11 forwarding endlessly. In previous versions, ForwardX11Timeout=0 was undefined. sshd(8): On compiling with GSSAPI support, cache supported method OIDs regardless of whether GSSAPI authentication is enabled in the main section of sshd_config. This behaviour avoids sandbox violations when GSSAPI authentication was enabled later in a Match block. sshd(8): Closing a connection does not failed when configuration is done with a text key revocation list that contains a very short key. ssh(1): Connections with specified ProxyJump are treated the same as ones with a ProxyCommand set with regards to hostname canonicalisation. This means that unless CanonicalizeHostname is set to 'always' the hostname should not be canonicalised. ssh(1): Fixed a regression in OpenSSH 7.8 that could prevent public- key authentication using certificates hosted in an ssh-agent(1) or against sshd(8) from OpenSSH 7.8 or newer. For more details, visit the OpenSSH website. How the Titan M chip will improve Android security IBM launches Industry’s first ‘Cybersecurity Operations Center on Wheels’ for on-demand cybersecurity support low.js, a Node.js port for embedded systems

Innovation is a word that seems to have emanated from the tech world and entered mainstream discourse. It's a term that has stuck to contemporary notions of progress and improvement. But is innovation and change really that great? Are we in danger of valorizing novelty at the expense of reliability, security and functionality? The "Boring Software" Manifesto, published on tqdev.com yesterday (18 June 2018) says yes. Written by software architect Maurits van der Schee, the "Boring Software" manifesto argues "as software developers we are tired of the false claims made by evangelists of the latest and greatest technology." Just days after we revealed data on developer attitudes to 'ninjas' and 'rockstars' the manifesto is further evidence of tension within the tech world. The tension is perhaps not so much one between 'innovators' and those concerned with ideals of security and reliability, but more about those actively selling innovation, speed, and efficiency and those with a more pragmatic approach to software engineering. Boring software vs. hyped and volatile technologies Schee's manifesto takes aim at what he calls 'hyped and volatile technologies'. He also appears to suggest that the demands of industry actually conflict with these 'hyped' technologies. Implicit in the piece is the idea is that there is a counter-industry of hype and evangelism that undermines how software can best serve industry today. 'In pursuit of "agility and craftsmanship", Schee writes, 'we have found "boring software" to be indispensable.' The most intriguing part of the manifesto features a number of examples that demonstrate the tension in the software world really clearly. For example: 3-tier applications are tried, tested and reliable; microservices, meanwhile, are hyped and volatile. Relational databases are 'simple and proven', while NoSQL is not, in Schee's view. Page reloads - also proven, whereas SPAs remain hyped. Unsurprisingly, reaction to the Boring Software manifesto is split. Many people have welcomed the intervention: https://twitter.com/overstood/status/1008956402050560000 Others, however, were more cautious. Innovation and invention only opens up new options, they argued: https://twitter.com/priyaprincess20/status/1008960699677081600 One Twitter user summed up the situation by suggesting the truth is probably somewhere between the two: https://twitter.com/ardave2002/status/1008984843403833344 This is likely to be a debate without a conclusion. However, the manifesto is a useful intervention in a discussion about how we should build software and what we should value most. What do you think about "boring software"? Is Maurits van der Schee correct? Or do we need to be open to new and emerging technologies and trends, even if they pose new challenges? Read next How Gremlin is making chaos engineering accessible [Interview] Are containers the end of virtual machines? Technical debt is damaging businesses

The GitHub team released a new Go library, Vulcanizer, that interacts with an Elasticsearch cluster, yesterday. Vulcanizer is not a full-fledged Elasticsearch client. However, it is aimed at providing a high-level API to help with common tasks associated with operating an Elasticsearch cluster. These tasks include querying health status of the cluster, migrating data from nodes, updating cluster settings, and more. GitHub makes use of Elasticsearch as the core technology behind its search services. GitHub has already released the Elastomer library for Ruby and they use Elastic library for Go by user olivere. However, the GitHub team wanted a high-level API that corresponded with the common operations on cluster such as disabling allocation or draining the shards from a node. They wanted a library that focused more on the administrative operations and that could be easily used by their existing tooling. Since Go’s structure encourages the construction of composable software, they decided it was a good fit for Elasticsearch. This is because, Elasticsearch is very effective and helps carry out almost all the operations that can be done using its HTTP interface, and where you don’t want to write JSON manually. Vulcanizer is great at getting nodes of a cluster, updating the max recovery cluster settings, and safely adding or removing the nodes from the exclude settings, making sure that shards don’t unexpectedly allocate onto a node. Also, Vulcanizer helps build ChatOps tooling around Elasticsearch quickly for common tasks. GitHub team states that having all the Elasticsearch functionality in their own library, Vulcanizer, helps its internal apps to be slim and isolated. For more information, check out the official GitHub Vulcanizer post. GitHub increases its reward payout model for its bug bounty program   GitHub launches draft pull requests GitHub Octoverse: top machine learning packages, languages, and projects of 2018

The Mozilla team announced Rust 2018 Edition Preview 2 today, the final release cycle before Rust 2018 goes into beta. The new release explores features such as the cargo fix command, NLL, along with other changes and improvements. Rust is a systems programming language by Mozilla. It is a "safe, concurrent, practical language", which supports functional and imperative-procedural paradigms. Rust provides better memory safety while still maintaining the performance. Let’s have a look at major features in Rust’s 2018 edition preview 2. The cargo fix command now comes as a built-in feature in Rust. This command is used during migration and addition of this new feature in Rust now further streamlines the migration process. Speaking of migration, extensive efforts have gone into improving and polishing the lints which help you migrate smoothly. Apart from that, the module system changes are now broken into several smaller features that help with independent tracking issues. There is no need of mod.rs anymore for parent modules Also, the extern crate is not needed anymore for including dependencies. Support has been provided for crate as a visibility modifier.   Another new addition in the Rust 2018 edition preview 2 is that NLL or Non-lexical lifetimes has been enabled by default, in migration mode. NLL improves the Rust compiler's ability to reason about lifetimes. It removes most of the remaining cases where people commonly experience the borrow checker rejecting valid programs. As per the Rust team, “If your code is accepted by NLL, then we accept it -- if your code is rejected by both NLL and the old borrow checker, then we reject it-- If your code is rejected by NLL but accepted by the old borrow checker, then we emit the new NLL errors as warnings”. In-band lifetimes have been split up in the latest release. Both rustfmt and the RLS have reached 1.0 “release candidate” status. For more information, check out the official release notes. Multithreading in Rust using Crates [Tutorial] Rust and Web Assembly announce ‘wasm-bindgen 0.2.16’ and the first release of ‘wasm-bindgen-futures’ Warp: Rust’s new web framework for implementing WAI (Web Application Interface)  

Last week, as per the schedule, the ISO C++ Committee met in Kona, Hawaii to finalize the feature set for the next International Standard (IS), C++ 20. The committee has announced that C++20 is now feature complete and they are planning to finish the C++20 specification at the upcoming meeting, which is scheduled to happen in July 2019. Once the specification is complete they are planning to send the Committee Draft for review. Some of the features this draft include Modules With the introduction of modules, developers will not require to separate their files into header and source parts. The committee has now fixed internal linkage escaping modules. Coroutines The committee has gone through the coroutines proposals and has decided to go ahead with the specification. According to the specification of this feature, three keywords will be added: co_await, co_yield, and co_return. Contracts Contracts are made up of preconditions, postconditions, and assertions. These act as a basic mitigation measure when a program goes wrong because of some mismatch of expectations between parts of the programs. The committee is focused on refining the feature and renamed expects/ensures to pre/post. Concepts The concepts library include the definitions of fundamental library concepts, which are used for compile-time validation of template arguments and perform function dispatch on properties of types. Ranges The ranges library comes with components for dealing with ranges of elements including a variety of view adapters. To read the entire announcement, check out this Reddit thread. Code completion suggestions via IntelliCode comes to C++ in Visual Studio 2019 How to build Template Metaprogramming (TMP) using C++[Tutorial] Mio, a header-only C++11 memory mapping library, released!

After the GitHub Octoverse report last month, GitHub released an analysis of the top programming languages of 2018 on its platforms. There are various ways to rank the popularity of a programming language. In the report published on the GitHub Blog, the number of unique contributors to both public and private repositories tagged with the primary language was used. In addition, the number of repositories tagged with the appropriate primary programming language was also used. JavaScript is the top programming language by repositories The most number of repositories are created in JavaScript. The number of repositories created has a steady rise from 2012. Around this time, GitHub was housing nearly 1 million repositories in total. New JavaScript frameworks like Node.js were launched in 2009. This made it possible for developers to create client and server sides with the same code. Source: GitHub Blog JavaScript also has the most number of contributors JavaScript tops the list for the language having the most number contributors in public and private repositories. This is the case for organizations of every size in all regions of the world. New languages have also been on the rise on GitHub. In 2017, TypeScript entered the top 10 programming languages for all kinds of repositories across all regions. Projects like DefinitelyTyped help in using common JavaScript libraries with TypeScript which encourages its adoption. Some languages have also seen a decline in popularity. Ruby has sunk in the charts over the last couple of years. Even though the number of contributors in Ruby is on the rise, other languages like JavaScript and Python have grown faster. Newer projects not likely to be written in Ruby. This is especially true for projects owned by individual users or small organizations. Such projects are likely written in popular languages like JavaScript, Java, or Python. Source: GitHub Blog Languages by contributors in different regions Across regions, there haven’t been many variations in languages used. Ruby is at the bottom for all regions. TypeScript ranks higher in South America and Africa compared to North America and Europe. The reason could be the developer communities being relatively new in Africa and South America. The repositories in Africa and South America were younger than the repositories in North America and Europe. Fastest growing language by contributors PowerShell is climbing the list. Go also continues to grow across repository type with rank 7. It’s rank is 9 for open source repositories. Statically-typed languages which focus on type safety and interoperability like Kotlin, TypeScript, and Rust are growing quickly. So what makes a programming language popular on GitHub? There are three factors for top programming languages to climb ranks—type safety, interoperability, and being open source. Type safety: There’s a rise in static typing except for Python. This is because of the security and efficiency static typing offers individual developers and teams. The optional static typing in TypeScript adds safety. Kotlin, offers greater interactivity while creating trustworthy, type-safe programs. Interoperability: One of the reasons TypeScript climbed the rankings was due to its ability to coexist and integrate with JavaScript. Rust and Kotlin which are also on the rise, find built-in audiences in C and Java, respectively. Python developers can directly call Python APIs from Swift which displays its versatility and interoperability. Open source: These languages are also open source projects with active commits and changes. Strong communities that contribute, evolve, and create resources for languages can positively impact its life. For more details and charts, visit the GitHub Blog. What we learnt from the GitHub Octoverse 2018 Report Why does the C programming language refuse to die? Julia for machine learning. Will the new language pick up pace?