Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

Tech Guides - Programming

81 Articles
article-image-new-languages-brave-new-world
Akram Hussain
26 Sep 2014
6 min read
Save for later

New Languages: Brave New World

Akram Hussain
26 Sep 2014
6 min read
The tech world has seen a number of languages emerge, grow, and become super popular, but equally it has seen its fair share of failures and things that make you ask yourself “just why?” We initially had the dominant set of languages introduced to us many years ago (in the 80s), which are still popular and widely used; these include C++, C, Fortran, Erlang, Pearl, SQL, Objective C, and so on. There is nothing to suggest these languages will die out completely or even lose their market share, but the world of programming really came to life in the 90s in an era known as the “Internet age” where a new set of languages came to the party. During this period, a set of “special” languages emerged and I personally would go as far as to say they revolutionized the way we programme. These were languages like JavaScript, Python, Java, R, Haskell, Ruby, and PHP. What’s more interesting is that you see a huge demand for these languages currently on the market (even after 20 years!) and you certainly wouldn’t categorize them as new; so why are they still so popular? Has the tech market stalled? Have developers not moved on? Do we have everything we need from these languages? And what’s next for the future? The following image helps explain the introduction and growth of these languages, in terms of use and adoption; it’s based on Redmonks’ analysis which compares the popularity of Stackoverflow tags and Github repositories: This graph shows a number of languages with the movement from left to right as a positive one. It’s apparent that the languages that were introduced in the 90s are at the forefront of programming; there are even few from the 80s, which supports my earlier statement that older languages don’t die out but seem to improve and adapt over time. However with time and the ever changing tech market, new demands always arise and where there are problems, there are developers with solutions. Recently and over the past few years, we have seen the emergence of new programming languages. Interestingly they seem to be very similar to the older ones, but they have that extra oomph that makes them so popular. I would like to introduce you to a set of languages that may be around for many years to come and may even shape the tech world in the future. Could they be the next generation? Scala is a multi-paradigm programming language supports both object-oriented and functional programming. It is a scripting language used to build applications for the JVM. Scala has seen increased adoption from Java developers due to its flexibility, as it provides the ability to carry out functional programming capabilities. Could Scala replace Java? Go, introduced by Google, is a statically-typed programming language with syntax similar to C. It has been compared and seen as a viable alternative to major languages such as Java or C++. However, Go is different thanks to its inherent support for concurrent programming, where it independently executes tasks, and computations are designed to interact with each other that can be run on a single processor or multi-core processors. Swift is Apple’s new programming language, unveiled in June 2014. It is set to replace Objective-C as the lingua franca for developing apps for Apple operating systems. As a multi-paradigm language, it has expressive features familiar to those used to working with modern functional languages, while also keeping the object-oriented features of Objective-C. F# is a multi-paradigm programming language that encompasses object-oriented features but is predominantly focused on functional programming. F# was developed by Microsoft as an alternative to C#, touted as a language that can do everything C# can but better. The language was primarily designed with the intention of applying it to data-driven concepts. One of the greatest benefits of using F# is the interoperability with other .NET languages. This means code written in F# can work with different parts of an application written in C#.  Elixir  is a functional programming language that leverages features of the Erlang VM and has syntax similar to Ruby. Elixir offers concurrency, high scalability, and fault-tolerance, enabling higher levels of productivity and extensibility while maintaining compatibility with Erlang’s tools and ecosystem.  Clojure is a dynamic, general-purpose programming language that runs on the Java Virtual Machine that offers interactive development with the speed and reliable runtime of the JVM. It takes advantage of Java libraries, services, and all of the resources of the JVM ecosystem. Dart, introduced by Google, is a pure object-oriented language with C-style syntax. Developers look at Dart as a JavaScript competitor that offers simplicity, flexibility, better performance, and security. Dart was designed for web development and to scale complex web applications. Juliais an expressive and dynamic multi-paradigm language. It’s as fast as C and it can be used for general programming. It is supposed to be a high level programming language with syntax similar to Matlab and Fortran. The language is predominantly used in the field of data science, and is one to keep an eye out for as it’s tipped to rival R and Python in the future.   D is another multi-paradigm programming language that allows developers to write “elegant” code. There’s demand for D as it’s a genuine improvement over C++, while still offering all the benefits of C++. D can be seen as a solution for developers who build half their application in Ruby/Python and then use C++ to “deal with the bottle-necks”. D lets you have all the benefits of both of these languages. Rust is another multi-paradigm systems language developed by Mozilla. It has been touted as a valuable alternative to C++. Rust combines strong concurrent programming, low-level abstraction, with super-fast performance, making it ideal for high-level projects. Rust’s type system ensures memory errors are minimized, a problem that is common in C++ with memory leaks. However, for the moment Rust isn’t designed to replace C++ but improve on its flaws, yet with advancements in the future you never know… From this list of new languages, it’s clear that the majority of them were created to solve issues of previous languages. They are all subsets of a similar language, but better refined to meet the modern day developer’s needs. There has been an increase in support for functional languages and there’s also been a steep rise of multi-paradigm features, which suggests the need for flexible programming. Whether we’re looking at the new “class” of languages for the future remains to be seen, but one thing is for sure: they were designed to make a difference in an increasingly new and brave tech world. 
Read more
  • 0
  • 0
  • 17705

article-image-5-reasons-you-should-learn-to-code
Richard Gall
02 May 2018
4 min read
Save for later

5 reasons you should learn to code

Richard Gall
02 May 2018
4 min read
If you're on the Packt Hub, it's likely that you already know how to code. But perhaps you don't - and if you don't, it's our job to let you know why you should learn to code. And even if you do know how, evangelizing and explaining to others why they should learn is incredibly important. People often think of writing code as something very specialized and technically demanding. There’s sometimes even a perception of people that do write code as a certain kind of person. But this is, luckily, demonstrably untrue. Writing code is something that can be done by anyone. While there are some incredibly specialized roles that require incredibly detailed levels of programming knowledge, in actual fact a huge number of roles today use software in creative and analytical ways. That’s why learning how to code is so essential. Let’s take a look at 5 reasons why you should learn how to write code. Learn to code to better understand how software works Code is everywhere. Learning how to write it is a way of understanding how so much of the world works. Perhaps you’re a writer. Or maybe a designer. Maybe you work in marketing. Whatever you’re doing, it’s likely that you’re working in a digital environment. Understanding how these are built and how they work puts you at an advantage, in that you have an extra dimension of knowledge of how things work ‘under the hood’. Learning to code will help you better manipulate and use data The world runs on data. Code can help you better understand it and manage it. Excel is a sad part of business life. You don’t have to look had to finding someone complaining about spreadsheets. But if you’ve ever been impressed with someone’s dexterity with Excel, that’s really just a type of code. In the world of data today there are far more sophisticated systems for processing and managing data. But if you’re working with large datasets in any capacity, learning how to write SQL scripts, for example, is a great place to begin your coding adventure. Learn to code simply to have fun Coding is fun and creative! Before talk of spreadsheets and databases turns you off, it’s important to note that writing code and learning to program is fun. If you’re just starting out seeing the effect of your code as you build your first web page is a really neat experience. A lot of people think coding is purely technical - but the technical part is just a small aspect of it. Really, it’s about solving problems and being creative. Even if you’re not sure how learning to code might help you professionally right now, having a creative outlet might just inspire your future. Coding isn't as hard as you think It’s not actually that hard… Writing code isn’t really that hard. It might take some getting used to, but once you’re over those first steps you’ll feel like an expert. True, learning how to write code always involves some ups and downs, and if you’re getting deeper into more complex programming concepts and tasks, it will be challenging. But that doesn’t mean that it’s beyond you. It’s a valuable skill you can actually develop quickly. You can learn to code without spending lots of money It’s a valuable skill you can develop cheaply. Learning how to write code could increase your earning power. Even if it doesn’t transform your career, it could still give you a push to get to the next step. But while development often requires expensive training and certifications that your employer might pay for, learning the basics of coding is something you can do without spending very much money at all. There’s lots of free resources out there. And even the very best resources won’t put you out of pocket. Slow down to learn how to code faster
Read more
  • 0
  • 0
  • 17687

article-image-service-mesh-trick-or-treat
Melisha Dsouza
31 Oct 2018
2 min read
Save for later

Service mesh - Trick or Treat?

Melisha Dsouza
31 Oct 2018
2 min read
‘Service mesh’ is a term that is relatively new and has gained visibility in the past year. It’s a configurable infrastructure layer for a microservices application that makes communication between service instances flexible, reliable, and fast. Why are people talking about ‘service meshes’? Modern applications contain a range of (micro)services that allow it to run effectively. Load balancing, traffic management, routing, security, user authentication - all of these things need to work together properly if the application is going to function as intended.. Managing these various services, across a whole deployment of containers, poses a challenge for those responsible for updating and maintaining them. How does a service mesh work? Enter the Service mesh. It works delivering these services from within the compute cluster through a set of APIs. These APIs, when brought together, form the ‘mesh’.. This makes it much easier to manage software infrastructures of particular complexity - hence why organizations like Netflix and Lyft have used them.. Trick or treat? With the service meshes addressing some of the key challenges when it comes to microservices, this is definitely a treat for 2018 and beyond. NGINX Hybrid Application Delivery Controller Platform improves API management, manages microservices and much more! Kong 1.0 launches: the only open source API platform specifically built for microservices, cloud, and serverless OpenFaaS releases full support for stateless microservices in OpenFaaS 0.9.0
Read more
  • 0
  • 0
  • 17635

article-image-techs-culture-war-entrepreneur-egos-v-engineer-solidarity
Richard Gall
12 Jul 2018
10 min read
Save for later

Tech’s culture war: entrepreneur egos v. engineer solidarity

Richard Gall
12 Jul 2018
10 min read
There is a rift in the tech landscape that has been shifting quietly for some time. But 2018 is the year it has finally properly opened. This is the rift between the tech’s entrepreneurial ‘superstars’ and a nascent solidarity movement, both of which demonstrate the two faces of the modern tech industry. But within this ‘culture war’ there’s a broader debate about what technology is for and who has the power to make decisions about it. And that can only be a good thing - this is a conversation we’ve needed for some time. With the Cambridge Analytica scandal, and the shock election results to which it was tied, much contemporary political conversation is centered on technology’s impact on the social sphere. But little attention has been paid to the way these social changes or crises are actually enforcing changes within the tech industry itself. If it feels like we’re all having to pick sides when it comes to politics, the same is true when it comes to tech. The rise of the tech ego If you go back to the early years of software, in the early part of the twentieth century, there was little place for ego. It’s no accident that during this time computing was feminized - it was widely viewed as administrative. It was only later that software became more male dominated, thanks to a sexist cultural drive to establish male power in the field. This was arguably the start of egos tech takeover- after all, men wanted their work to carry a certain status. Women had to be pushed out to give them it. It’s no accident that the biggest names in technology - Bill Gates, Steve Wozniak, Steve Jobs - are all men. Their rise was, in part, a consequence of a cultural shift in the sixties. But it’s recognise the fact that in the eighties, these were still largely faceless organizations. Yes, they were powerful men, but the organizations they led were really just the next step out from the military industrial complex that helped develop software as we know it today. It was only when ‘tech’ properly entered the consumer domain that ego took on a new value. As PCs became part of every day life, attaching these products to interesting and intelligent figures was a way of marketing these products. It’s worth remarking that it isn’t really important whether these men had huge egos at all. All that matters is that they were presented in that way, and granted an incredible amount of status and authority. This meant that complexity of software and the literal labor of engineering could be reduced to a relatable figure like Gates or Jobs. We can still feel the effects of that today: just think of the different ways Apple and Microsoft products are perceived. Tech leaders personify technology. They make it marketable. Perhaps tech ‘egos’ were weirdly necessary. Because technology was starting to enter into everyone’s lives, these figures - as much entrepreneurs as engineers - were able to make it accessible and relatable. If that sounds a little far fetched, consider what the tech ‘ninja’ or the ‘guru’ really means for modern businesses. It often isn’t so much about doing something specific, but instead about making the value and application of those technologies clear, simple, and understandable. When companies advertise for these roles using this sort of language they’re often trying to solve an organizational problem as much as a technical one. That’s not to say that being a DevOps guru at some middling eCommerce company is the same as being Bill Gates. But it is important to note how we started talking in this way. Similarly, not everyone who gets called a ‘guru’ is going to have a massive ego (some of my best friends are cloud gurus!), but this type of language does encourage a selfish and egotistical type of thinking. And as anyone who’s worked in a development team knows, that can be incredibly dangerous. From Zuckerberg to your sprint meeting - egos don’t care about you Today, we are in a position where the discourse of gurus and ninjas is getting dangerous. This is true on a number of levels. On the one hand we have a whole new wave of tech entrepreneurs. Zuckerberg, Musk, Kalanick, Chesky, these people are Gates and Jobs for a new generation. For all their innovative thinking, it’s not hard to discern a certain entitlement from all of these men. Just look at Zuckerberg and his role in the Cambridge Analytica Scandal. Look at Musk and his bizarre intervention in Thailand. Kalanick’s sexual harassment might be personal, but it reflects a selfish entitlement that has real professional consequences for his workforce. Okay, so that’s just one extreme - but these people become the images of how technology should work. They tell business leaders and politicians that tech is run by smart people who ostensibly should be trusted. This not only has an impact on our civic lives but also on our professional lives too. Ever wonder why your CEO decides to spend big money on a CTO? It’s because this is the model of modern tech. That then filters down to you and the projects you don’t have faith in. If you feel frustrated at work, think of how these ideas and ways of describing things cascade down to what you do every day. It might seem small, but it does exist. The emergence of tech worker solidarity While all that has been happening, we’ve also seen a positive political awakening across the tech industry. As the egos come to dictate the way we work, what we work on, and who feels the benefits, a large group of engineers are starting to realize that maybe this isn’t the way things should be. Disaffection in Silicon Valley This year in Silicon Valley, worker protests against Amazon, Microsoft and Google have all had an impact on the way their companies are run. We don’t necessarily hear about these people - but they’re there. They’re not willing to let their code be used in ways that don’t represent them. The Cambridge Analytica scandal was the first instance of a political crisis emerging in tech. It wasn’t widely reported, but some Facebook employees asked to move across to different departments like Instagram or WhatsApp. One product designer, Westin Lohne, posted on Twitter that he had left his position saying “morally, it was extremely difficult to continue working there as a product designer.” https://twitter.com/westinlohne/status/981731786337251328 But while the story at Facebook was largely disorganized disaffection, at Google there was real organization against Project Maven. 300 Google employees signed a petition against the company’s AI initiative with the Pentagon. In May, a number of employees resigned over the issue. One is reported as saying “over the last couple of months, I’ve been less and less impressed with Google’s response and the way our concerns are being listened to.” Read next: Google employees quit over company’s continued Artificial Intelligence ties with the Pentagon A similar protest happened at Amazon, with an internal letter to Jeff Bezos protesting the use of Rekognition - Amazon’s facial recognition technology - by law enforcement agencies, including ICE. “Along with much of the world we watched in horror recently as U.S. authorities tore children away from their parents,” the letter stated, according to Gizmodo. “In the face of this immoral U.S. policy, and the U.S.’s increasingly inhumane treatment of refugees and immigrants beyond this specific policy, we are deeply concerned that Amazon is implicated, providing infrastructure and services that enable ICE and DHS.” Microsoft saw a similar protest, sparked, in part, by the shocking images of families being separated at the U.S./Mexico border. Despite the company distancing itself over ICE’s activities, many employees were vocal in their opposition. “This is the sort of thing that would make me question staying,” said one employee, speaking to Gizmodo. A shift in attitudes as tensions emerge True, when taken individually, these instances of disaffection may not look like full-blown solidarity. But together, it amounts to a changing consciousness across Silicon Valley. Of course, it wouldn’t be wrong to say that a relationship between tech, the military, and government has always existed. But the reason things are different is precisely because these tensions have become more visible, attitudes more prominent in public discourse. It’s worth thinking about these attitudes and actions in the context of hyper-competitive Silicon Valley where ego is the norm, and talent and flair is everything. Signing petitions carries with it some risk - leaving a well-paid job you may have spent years working towards is no simple decision. It requires a decisive break with the somewhat egotistical strand that runs through tech to make these sorts of decisions. While it might seem strange, it also shouldn’t be that surprising. If working in software demands a high level of collaboration, then collaboration socially and politically is really just the logical development from our professional lives. All this talk about ‘ninjas’, ‘gurus’ and geniuses only creates more inequality within the tech job market - whether you’re in Silicon Valley, Stoke, or Barcelona, or Bangalore, this language actually hides the skills and knowledge that are actually most valuable in tech. Read next: Don’t call us ninjas or rockstars, say developers Where do we go next? The future doesn’t look good. But if the last six months or so are anything to go by there are a number of things we can do. On the one hand more organization could be the way forward. The publishing and media industries have been setting a great example of how unionization can work in a modern setting and help workers achieve protection and collaborative power at work. If the tech workforce is going to grow significantly over the next decade, we’re going to see more unionization. We’ve already seen technology lead to more unionization and worker organization in the context of the gig economy - Deliveroo and Uber drivers, for example. Gradually it’s going to return to tech itself. The tech industry is transforming the global economy. It’s not immune from the changes it’s causing. But we can also do more to challenge the ideology of the modern tech ego. Key to this is more confidence and technological literacy. If tech figureheads emerge to make technology marketable and accessible, the way to remove that power is to demystify it. It’s to make it clear that technology isn’t a gift, the genius invention of an unfathomable mind, but instead that it’s a collaborative and communal activity, and a skill that anyone can master given the right attitude and resources. At its best, tech culture has been teaching the world that for decades. Think about this the next time someone tells you that technology is magic. It’s not magic, it’s built by people like you. People who want to call it magic want you to think they’re a magician - and like any other magician, they’re probably trying to trick you.
Read more
  • 0
  • 0
  • 17170

article-image-exploring-language-improvements-c-72-and-73-0
Mark J.
28 Nov 2017
9 min read
Save for later

Exploring Language Improvements in C# 7.2 and 7.3

Mark J.
28 Nov 2017
9 min read
With the C# 7 generation, Microsoft has decided to increase the cadence of language releases, releasing minor version numbers, aka point releases, for the first time since C# 1.1. This allows new features to be used by programmers faster than ever before, but the policy poses a challenge to writers of books about C#. Introduction One of the hardest parts of writing for technology is deciding when to stop chasing the latest changes and adding new content. Back in March 2017, I was reviewing the final drafts of the second edition of my book, C# 7 and .NET Core – Modern Cross-Platform Development. In Chapter 2, Speaking C# I got to the topic of representing number literals. One of the improvements in C# 7 is the ability to use the underscore character as a digit separator. For example, when writing large numbers in decimal you can improve the readability of number literals using underscores, and you can express binary or hexadecimal number literals by prefixing the number literal with 0b or 0x, as shown in the following code: // C# 6 and earlier int decimalNotation = 2000000; // 2 million // C# 7 and 7.1 int decimalNotation = 2_000_000; // 2 million int binaryNotation = 0b0001_1110_1000_0100_1000_0000; // 2 million int hexadecimalNotation = 0x001E_8480; // 2 million But in the final draft I hadn't included code examples of using underscores in number literals. At the last minute, I decided to add the preceding examples to the book. Unfortunately, I assumed that the underscore could be used to separate the prefixes 0b and 0x from the digits, and did not check the code examples would compile until the following day, after the book had gone to print. I had to release an erratum on the book's web page before it even reached the shelves. I felt so embarrassed. In the third edition, C# 7.1 and .NET Core 2.0 – Modern Cross-Platform Development, I fixed the code examples by removing the unsupported underscores after the prefixes since they are not supported in C# 7 or C# 7.1. Ironically, just as the third edition was due to go to print, Microsoft released C# 7.2, which adds support for using an underscore after the prefixes, as shown in the following code: // C# 7.2 and later int binaryNotation = 0b_0001_1110_1000_0100_1000_0000; // 2 million int hexadecimalNotation = 0x_001E_8480; // 2 million Gah! Clearly, I wasn't the only programmer who thought it is natural to be able to use underscores after the 0b or 0x prefixes. For the third edition, I decided not to make any last-minute changes to the book. This was partly because I didn't want to risk making a mistake again, and also because the code examples do work, they just don't show the latest improvement. Maybe in the fourth edition I will finally get the whole book perfect! But, of course, in the programming world that's impossible. Since the third edition covers C# 7.1, I have written this article to cover the improvements in C# 7.2 that are available today, and to preview the improvements coming early in 2018 with C# 7.3. Enabling C# 7 point releases Developer tools like Visual Studio 2017, Visual Studio Code, and the dotnet command line interface assume that you want to use the C# 7.0 language compiler by default. To use the improvements in a C# point release like 7.1 or 7.2, you must add a configuration element to the project file, as shown in the following markup: <LangVersion>7.2</LangVersion> Potential values for the <LangVersion> markup are shown in the following table: LangVersion Description 7, 7.1, 7.2, 7.3, 8 Entering a specific version number will use that compiler if it has been installed. default Uses the highest major number without a minor number, for example, 7 in 2017 and 8 later in 2018. latest Uses the highest major and highest minor number, for example, 7.2 in 2017, 7.3 early in 2018, 8 later in 2018. To be able to use C# 7.2, either install Visual Studio 2017 version 15.5 on Windows, or install .NET Core SDK 2.1.2 on Windows, macOS, or Linux from the following link: https://www.microsoft.com/net/download/ Run the .NET Core SDK installer, as shown in the following screenshot: Setting up a project for exploring C# 7.2 improvements In Visual Studio 2017 version 15.5 or later, create a new Console App (.NET Core) project named ExploringCS72 in a solution named Bonus, as shown in the following screenshot: You can download the projects created in this article from the Packt website or from the following GitHub repository: https://github.com/PacktPublishing/CSharp-7.1-and-.NET-Core-2.0-Modern-Cross-Platform-Development-Third-Edition/tree/master/BonusSectionCode/Bonus In Visual Studio Code, create a new folder named Bonus with a subfolder named ExploringCS72. Open the ExploringCS72 folder. Navigate to View | Integrated Terminal, and enter the following command: dotnet new console In either Visual Studio 2017 or Visual Studio Code, edit the ExploringCS72.csproj file, and add the <LangVersion> element, as shown highlighted in the following markup: <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.0</TargetFramework> <LangVersion>7.2</LangVersion> </PropertyGroup> </Project> Edit the Program.cs file, as shown in the following code: using static System.Console; namespace ExploringCS72 { class Program { static void Main(string[] args) { int year = 0b_0000_0111_1011_0100; WriteLine($"I was born in {year}."); } } } In Visual Studio 2017, navigate to Debug | Start Without Debugging, or press Ctrl + F5. In Visual Studio Code, in Integrated Terminal, enter the following command: dotnet run You should see the following output, which confirms that you have successfully enabled C# 7.2 for this project: I was born in 1972. In Visual Studio Code, note that the C# extension version 1.13.1 (released on November 13, 2017) has not been updated to recognize the improvements in C# 7.2. You will see red squiggle compile errors in the editor even though the code will compile and run without problems, as shown in the following screenshot: Controlling access to type members with modifiers When you define a type like a class with members like fields, you control where those members can be accessed by applying modifiers like public and private. Until C# 7.2, there have been five combinations access modifier keywords. C# 7.2 adds a sixth combination, as shown in the last row of the following table: Access modifier Description private Member is accessible inside the type only. This is the default if no keyword is applied to a member. internal Member is accessible inside the type, or any type that is in the same assembly. protected Member is accessible inside the type, or any type that inherits from the type. public Member is accessible everywhere. internal protected Member is accessible inside the type, or any type that is in the same assembly, or any type that inherits from the type. Equivalent to internal_OR_protected. private protected Member is accessible inside the type, or any type that inherits from the type and is in the same assembly. Equivalent to internal_AND_protected. Setting up a .NET Standard class library to explore access modifiers In Visual Studio 2017 version 15.5 or later, add a new Class Library (.NET Standard) project named ExploringCS72Lib to the current solution, as shown in the following screenshot: In Visual Studio Code, create a new subfolder in the Bonus folder named ExploringCS72Lib. Open the ExploringCS72Lib folder. Navigate to View | Integrated Terminal, and enter the following command: dotnet new classlib Open the Bonus folder so that you can work with both projects. In either Visual Studio 2017 or Visual Studio Code, edit the ExploringCS72Lib.csproj file, and add the <LangVersion> element, as shown highlighted in the following markup: <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> <LangVersion>7.2</LangVersion> </PropertyGroup> </Project> In the class library, rename the class file from Class1 to AccessModifiers, and edit the class, as shown in the following code: using static System.Console; namespace ExploringCS72 { public class AccessModifiers { private int InTypeOnly; internal int InSameAssembly; protected int InDerivedType; internal protected int InSameAssemblyOrDerivedType; private protected int InSameAssemblyAndDerivedType; // C# 7.2 public int Everywhere; public void ReadFields() { WriteLine("Inside the same type:"); WriteLine(InTypeOnly); WriteLine(InSameAssembly); WriteLine(InDerivedType); WriteLine(InSameAssemblyOrDerivedType); WriteLine(InSameAssemblyAndDerivedType); WriteLine(Everywhere); } } public class DerivedInSameAssembly : AccessModifiers { public void ReadFieldsInDerivedType() { WriteLine("Inside a derived type in same assembly:"); //WriteLine(InTypeOnly); // is not visible WriteLine(InSameAssembly); WriteLine(InDerivedType); WriteLine(InSameAssemblyOrDerivedType); WriteLine(InSameAssemblyAndDerivedType); WriteLine(Everywhere); } } } Edit the ExploringCS72.csproj file, and add the <ItemGroup> element to reference the class library in the console app, as shown highlighted in the following markup: <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.0</TargetFramework> <LangVersion>7.2</LangVersion> </PropertyGroup> <ItemGroup> <ProjectReference Include="..ExploringCS72LibExploringCS72Lib.csproj" /> </ItemGroup> </Project> Edit the Program.cs file, as shown in the following code: using static System.Console; namespace ExploringCS72 { class Program { static void Main(string[] args) { int year = 0b_0000_0111_1011_0100; WriteLine($"I was born in {year}."); } public void ReadFieldsInType() { WriteLine("Inside a type in different assembly:"); var am = new AccessModifiers(); WriteLine(am.Everywhere); } } public class DerivedInDifferentAssembly : AccessModifiers { public void ReadFieldsInDerivedType() { WriteLine("Inside a derived type in different assembly:"); WriteLine(InDerivedType); WriteLine(InSameAssemblyOrDerivedType); WriteLine(Everywhere); } } } When entering code that accesses the am variable, note that IntelliSense only shows members that are visible due to access control. Passing parameters to methods In the original C# language, parameters had to be passed in the order that they were declared in the method. In C# 4, Microsoft introduced named parameters so that values could be passed in a custom order and even made optional. But if a developer chose to name parameters, all of them had to be named. In C# 7.2, you can mix named and unnamed parameters, as long as they are passed in the correct position. In Program.cs, add a static method, as shown in the following code: public static void PassingParameters(string name, int year) { WriteLine($"{name} was born in {year}."); } In the Main method, add the following statement: PassingParameters(name: "Bob", 1945); Visual Studio Code will show an error, as shown in the following screenshot, but the code will compile and execute. Optimizing performance with value types The fourth and final feature of C# 7.2 is working with value types while using reference semantics. This can improve performance in very specialized scenarios. You are unlikely to use them much in your own code, unless like Microsoft themselves, you create frameworks for other programmers to build upon that need to do a lot of memory management. You can learn more about these features at the following link: https://docs.microsoft.com/en-gb/dotnet/csharp/reference-semantics-with-value-types Conclusion I plan to refresh this bonus article when C# 7.3 is released to update it with the new features in that point release. Good luck with all your C# adventures!
Read more
  • 0
  • 0
  • 16288

article-image-technical-debt-is-damaging-businesses
Richard Gall
11 Jun 2018
5 min read
Save for later

Technical debt is damaging businesses

Richard Gall
11 Jun 2018
5 min read
A lot of things make working in tech difficult. Technical debt is one of them. Whether you're working in-house or for an external team, you've probably experienced some tough challenges when it comes to legacy software. Most people have encountered strange internal software systems, a CMS that has been customized in a way that no one has the energy to fathom. Working your way around and through these can be a headache to say the least. In this year's Skill Up survey, we found that Technical debt and legacy issues are seen by developers as the biggest barrier to business goals. According to 49% of respondents, old technology and software is stopping organizations from reaching their full potential. But it might also be stopping developers from moving forward in their careers. Read the report in full. Sign up to our newsletter and download the PDF for free. Technical debt and the rise of open source Arguably, issues around technical debt have become more pronounced in the last decade as the pace of technical change has seemingly increased. I say seemingly, because it's not so much that we're living in an entirely new technical landscape. It's more that the horizons of that landscape are expanding. There are more possibilities and options open to businesses today. Technology leadership is difficult in 2018. To do it well, you need to stay on top of new technologies. But you also need a solid understanding of your internal systems, your team, as well as wider strategic initiatives and business goals. There are a lot of threads you need to manage. Are technology leaders struggling with technical debt? Perhaps technology leaders are struggling. But perhaps they're also making the best of difficult situations. When you're juggling multiple threads in the way I've described, you need to remain focused on what's important. Ultimately, that's delivering software that delivers value. True, your new mobile app might not be ideal; the internal CMS you were building for a client might not offer an exemplary user experience. But it still does the job - and that, surely is the most important thing? We can do better - let's solve technical debt together It's important to be realistic. In the age of burn out and over work, let's not beat ourselves up when things aren't quite what we want. Much of software engineering is, after all, making the best of a bad situation. But the solutions to technical debt can probably be found in a cultural shift. The lack of understanding of technology on the part of management is surely a large cause of technical debt. When projects aren't properly scoped and when deadlines are set without a clear sense of what level of work is required, that's when legacy issues begin to become a problem. In fact, it's worth looking at all the other barriers. In many ways, they are each a piece of the puzzle if we are to use technology more effectively - more imaginatively - to solve business problems. Take these three: Lack of quality training or learning Team resources Lack of investment in projects All of these point to a wider cultural problem with the way software is viewed in businesses. There's no investment, teams are under-resourced, and support to learn and develop new skills is simply not being provided. With this lack of regard for software, it's unsurprising that developers are spending more time solving problems on, say, legacy code, than solving big, interesting problems. Ones that might actually have a big impact. One way of solving technical debt, then, is to make a concerted effort to change the cultural mindset. Yes, some of this will need to come from senior management, but all software engineers need to take responsibility. This means better communication and collaboration, a commitment to documentation - those things that are so easy to forget to do well when you could be shipping code. What happens if we don't start solving technical debt Technical debt is like global warming - it's happening already. We feel the effects every day. However, it's only going to get worse. Yes, it's going to damage businesses, but it's also going to hurt developers. It's restricting the scope of developers to do the work they want to do and make a significant impact on their businesses. It seems as though we're locked in a strange cycle where businesses talk about the importance of 'digital skills' and technical knowledge gaps but ironically can't offer the resources or scope for talented developers to actually do their job properly. Developers bring skills, ideas, and creativity to jobs only to find that they're isn't really time to indulge that creativity. "Maybe next year, when we have more time" goes the common refrain. There's never going to be more time - that's obvious to anyone who's ever had a job, engineer or otherwise. So why not take steps to start solving technical debt now? Read next 8 Reasons why architects love API driven architecture Python, Tensorflow, Excel and more – Data professionals reveal their top tools The best backend tools in web development
Read more
  • 0
  • 0
  • 15203
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at $19.99/month. Cancel anytime
article-image-python-oop-python-object-oriented-programming
Liz Tom
25 Apr 2016
5 min read
Save for later

Python - OOP! (Python: Object-Oriented Programming)

Liz Tom
25 Apr 2016
5 min read
Or Currency Conversion using Python I love to travel and one of my favorite programming languages is Python. Sometimes when I travel I like to make things a bit more difficult and instead of just asking Google to convert currency for me, I like to have a script on my computer that requires me to know the conversion rate and then calculate my needs. But seriously, let's use a currency converter to help explain some neat reasons why Object Oriented Programming is awesome. Money Money Money First let's build a currency class. class Currency(object): def __init__(self, country, value): self.country = country self.value = float(value) OK, neato. Here's a currency class. Let's break this down. In Python every class has an __init__ method. This is how we build an instance of a class. If I call Currency(), it's going to break because our class also happens to require two arguments. self is not required to be passed. In order to create an instance of currency we just use Currency('Canada', 1.41) and we've now got a Canadian instance of our currency class. Now let's add some helpful methods onto the Currency class. def from_usd(self, dollars): """If you provide USD it will convert to foreign currency """ return self.value * int(dollars)def to_usd(self, dollars): """If you provide foreign currency it will convert to USD """ return int(dollars) / self.value Again, self isn't needed by us to use the methods but needs to be passed to every method in our class. self is our instance. In some cases self will refer to our Canadian instance but if we were to create a new instance Currency('Mexico', 18.45) self can now also refer to our Mexican instance. Fun. We've got some awesome methods that help me do math without me having to think. How does this help us? Well, we don't have to write new methods for each country. This way, as currency rates change, we can update the changes rather quickly and also deal with many countries at once. Conversion between USD and foreign currency is all done the same way. We don't need to change the math based on the country we're planning on visiting, we only need to change the value of the currency relative to USD. I'm an American so I used USD because that's the currency I'd be converting to and from most often. But if I wanted, I could have named them from_home_country and to_home_country. Now how does this work? Well, if I wanted to run this script I'd just do this: again = True while again: country = raw_input('What country are you going to?n') value = float(raw_input('How many of their dollars equal 1 US dollarn')) foreign_country = Currency(country, value) convert = raw_input('What would you like to convert?n1. To USDn2. To %s dollarsn' % country) dollars = raw_input('How many dollars would you like to convert?n') if( convert == '1' ): print dollars + ' ' + country + ' dollars are worth ' + str(foreign_country.to_usd(dollars)) + ' US dollarsn' elif( convert == '2' ): print dollars + ' US dollars are worth ' + str(foreign_country.from_usd(dollars)) + dollars + ' ' + country again = raw_input('nnnWant to go again? (Y/N)n') if( again == 'y' or again == 'Y' ): again = True elif( again == 'n' or again == 'N' ): again = False **I'm still using Python 2 so if you're using Python 3 you'll want to change those raw_inputs to just input. This way we can convert as much currency as we want between USD and any country! I can now travel the world feeling comfortable that if I can't access the Internet and I happen to have my computer nearby and I am at a bank or the hotel lobby staring at the exchange rate board, I'll be able to convert currency with ease without having to remember which way converts my money to USD and which way converts USD to Canadian dollars. Object-oriented programming allows us to create objects that all behave in the same way but store different values, like a blue car, red car, or green car. The cars all behave the same way but they are all described differently. They might all have different MPG but the way we calculate their MPG is the same. They all have four wheels and an engine. While it can be harder to build your program with object oriented design in mind, it definitely helps with maintainability in the long run. About the Author Liz Tom is a Software Developer at Pop Art, Inc in Portland, OR.  Liz’s passion for full stack development and digital media makes her a natural fit at Pop Art.  When she’s not in the office, you can find Liz attempting parkour and going to check out interactive displays at museums.
Read more
  • 0
  • 0
  • 14872

article-image-open-source-software-are-maintainers-the-only-ones-responsible-for-software-sustainability
Savia Lobo
01 Dec 2018
6 min read
Save for later

Open Source Software: Are maintainers the only ones responsible for software sustainability?

Savia Lobo
01 Dec 2018
6 min read
Last week, a Californian Computer Scientist disclosed a malicious package ‘flatmap-stream’ in the popular npm package, ‘event-stream’. The reason for this breach is, the ownership of the event-stream package was transferred by Dominic Tarr (original author) to a malicious user, right9ctrl. Following this, many Twitter and GitHub users have supported him whereas the others think he should have been more careful while transferring package ownership. Andre Staltz, an open source hacker mentions in a support to Dominic, “The fact that he gave ownership meant that he *cared* at least to do a tiny action that seemed ok. Not caring would be doing absolutely nothing at all, and that's the case quite often, and OSS maintainers get criticized also for *that*” Who’s responsible for maintaining the open source software? At the NDC Sydney 2018 conference held in September, two open source maintainers Nick Randolph, Technical Lead at Built To Roam and Geoffrey Huntley, an open source software engineer talked on why should companies and people should contribute back to open source and how they can do it. However, if something goes wrong with the project, who is responsible for it? Most users blame the maintainers of the project, but the license does not say so. In fact users, contributors, and maintainers together are equally responsible. Open source is a fantastic avenue for personal development as it does not require the supply, material, planning, and approval like other software Some reasons to contribute to Open Source Software: Other people will help you for free You will save a lot on training and documentation You will not be criticized by open source advocates Ability to hire best engineers You will be able to influence the direction of the projects to which you contribute Companies have embraced open source software as it allows them to get solutions to the market faster for their customers. It has allowed companies to focus on delivering business value instead of low-level technical tasks. The problem with Open Source The majority of open-source software that the world depends on is built by volunteers. When a business chooses to use open-source software this volunteer labor is essentially an unpaid vendor with no contractual obligations. However the speakers say, “Historically, we have defined open-source software in terms of freedom for the consumer, in the future now that open-source has ‘won’ this dialogue needs to change. Did we get it right? Did we ever stop to think about how software is maintained, the rights of maintainers and the cost of maintenance?” The maintainers said, as per the Open Source Software license, once the software is released to the world their responsibility ends. They need not respond to GitHub issues, no need to create documentation, no need to answer questions on stack overflow, and so on. The popular example where a security damage was caused by the popular Heartbleed Bug where the security issue was found in the OpenSSL cryptographic software library, which caused a huge loss of revenue. However, when an OSS breaks or users need new features, they log an issue on GitHub and then sit back awaiting a response. If the comments are not addressed by the maintainer, users start complaining about how badly the project is run. The thing about OSS that's too often forgotten, it's AS-IS, no exceptions. How should Businesses secure their supply chain? Different projects may operate differently, with more or fewer people, with work being prioritized differently, on differing release schedules but in all cases the software delivered is as-is, meaning that there is absolutely no SLA. The speakers say that it businesses should analyze the level of contribution they need to make towards the open source community. They have highlighted that in order to secure their supply chain, users should contribute with money or time. The truth is that free software is not really free. How much is this going to cost in man hours? If not with money, they can contribute with time. For instance, there is an initiative called as opensourcefriday.com and as an engineering leader you or your employees can pull request and learn how the open source they depend upon works. This means you are having a positive influence in the community and also contributing back to open source. And if your company faces any critical issue, the maintainer is likely to help you as you have actively contributed to the community. Source: YouTube How do you know how much to contribute? In order to shift the goal of the software, you have to be the maintainer or a core contributor to influence the direction. If you just want to protect the supply chain, you can simply fix what’s broken. If you wish to contribute at a consistent velocity, contribute at a rate that you can maintain for as long as you want. Source: YouTube According to Nick and Geoffrey what users and businesses should do is: Protect their software chain and see that from a business perspective what are the components I am making use of and make sure that these components are going to exist, going forward. We also need to think about the sustainability of the project and let it not wither away soon. If the project is good for the community, how can we make it sustainable by making more and more people joining the project? Companies should also keep a track of what they are contributing back to these projects. People should share their experiences and their best practices. This contribution will help analyze the risk factors. Share so that the industry matures beyond simple security concerns. Watch the complete talk by Nick and Geoffrey on YouTube https://www.youtube.com/watch?v=Mm_RuObpeGo&app=desktop The Linux and RISC-V foundations team up to drive open source development and adoption of RISC-V instruction set architecture (ISA) OpenStack Foundation to tackle open source infrastructure problems, will conduct conferences under the name ‘Open Infrastructure Summit’ The Ceph Foundation has been launched by the Linux Foundation to support the open source storage project
Read more
  • 0
  • 0
  • 14752

article-image-5-things-that-matter-application-development-2018
Richard Gall
11 Dec 2017
4 min read
Save for later

5 things that will matter in application development in 2018

Richard Gall
11 Dec 2017
4 min read
Things change quickly in application development. Over the past few years we've seen it merge with other fields. With the web become more app-like, DevOps turning everyone into a part-time sysadmin (well, sort of), and the full-stack trend shifting expectations about the modern programmer skill set, the field has become incredibly fluid and open. That means 2018 will present a wealth of challenges of application developers - but of course there will also be plenty of opportunities for the curious and enterprising… But what's going to be most important in 2018? What's really going to matter? Take a look below at our list of 5 things that will matter in application development in 2018. 1. Versatile languages that can be used on both client and server Versatility is key to be a successful programmer today. That doesn't mean the age of specialists is over, but rather you need to be a specialist in everything. And when versatility is important to your skillset, it also becomes important for the languages we use. It's for that reason that we're starting to see the increasing popularity of languages like Kotlin and Go. It's why Python continues to be popular - it's just so versatile. This is important when you're thinking about how to invest your learning time. Of course everyone is different, but learning languages that can help you do multiple things and solve different problems can be hugely valuable. Investing your energy in the most versatile languages will be well worth your time in 2018. 2. The new six month Java release cycle This will be essential for Java programmers in 2018. Starting with the release of Java 9 early in 2018, the new cycle will kick in. This might mean there's a little more for developers to pay attention to, but it should make life easier, as Oracle will be able to update and add new features to the language with greater effectiveness than ever before. From a more symbolic point of view, this move hints a lot at the deepening of open source culture in 2018, with Oracle aiming to satisfy developers working on smaller systems, keen to constantly innovate, as much as its established enterprise clients. 3. Developing usable and useful conversational UI Conversational UI has been a 'thing' for some time now, but it hasn't quite captured the imagination of users. This is likely because it simply hasn't proved that useful yet - like 3D film it feels like too much of a gimmick, maybe even too much of a hassle. It's crucial - if only to satisfy the hype - that developers finally find a way to make conversational UI work. To really make it work we're ultimately going to need to join the dots between exceptionally good artificial intelligence and a brilliant user experience - making algorithms that 'understand' user needs, and can adapt to what people want. 4. Microservices Microservices certainly won't be new in 2018, but they are going to play a huge part in how software is built in 2018. Put simply, if they're not important to you yet, they will be. We're going to start to see more organizations moving away from monolithic architectures, looking to engineering teams to produce software in ways that is much more dynamic and much more agile. Yes, these conversations have been happening for a number of years; but like everything when it comes to tech, change happens at different speeds. It's only now as technologies mature, developer skillsets change, and management focus shifts that broader changes take place. 5. Taking advantage of virtual and augmented reality Augmented Reality (AR) and Virtual Reality (VR) have been huge innovations within fields like game development. But in 2018, we're going to see both expand beyond gaming and into other fields. It's already happening in many areas, such as healthcare, and for engineers and product developers/managers, it's going to be an interesting 12 months to see how the market changes.
Read more
  • 0
  • 0
  • 14321

article-image-what-makes-programming-languages-simple-or-complex
Antonio Cucciniello
12 Jun 2017
4 min read
Save for later

What makes programming languages simple or complex?

Antonio Cucciniello
12 Jun 2017
4 min read
Have you been itching to learn a new programming language? Maybe you want to learn your first programming language and don't know what to choose. When learning a new language (especially your first language) you want to minimize the amount of unknowns that you will have. So you may want to choose a programming language that is simpler. Or maybe you are up for a challenge and want to learn something difficult! Today we are going to answer the question: What makes programming languages simple or complex? Previous experience The amount of experience you have programming or learning different programming concepts can greatly impact how well you learn a new language. If this is your tenth programming language you will have most likely seen plenty of the content before in the new language so that can greatly reduce the complexity. On the other hand, if this is your first language, you will be learning many new concepts and ideas that are natural to programming and that may make the language seem more complex than it probably is. Takeaway: The more programming experience you have, the lower the chances a programming language will be complex to you. Syntax The way you need to write code for that language can really affect the complexity. Some languages have many syntax rules that can be a nuisance when learning and will leave you confused. Other languages have fewer rules that will make it easier to understand for someone not familiar to the language. Additionally, for those with previous experience, if the new language has similar syntax to the old language it will help in the learning process. Another factor similar to syntax is how the code looks to the user. In my experience, the more the code has variable/function names that resemble the English language, the easier it is to understand it. Takeaway: The more syntax rules the more difficult a language can be to learn. Built-in functionality The next factor is how much built-in functionality a language has. If the language has been around for years and is being continuously updated, chances are it has plenty of helper functions and plenty of functionality. In the case of some newer languages, they might not have as much built-in functionality that allows you to develop easier. Takeaway: Generally, languages with more functionalitybuilt-in will make it easier to implement what you need in code. Concepts The fourth topic we are going to discuss here is concepts. That is, what programming concepts does this language use? There are plenty out there like object oriented programming, memory management, inheritance and more. Depending on what concepts are used in the language as well as your previous understanding of a concept, you could either really struggle with learning the language, or you could potentially find it easier than most. Takeaway: Your previous experience with specific concepts and the complexity of the concepts in the language could affect the complexity of the language as a whole. Frameworks & libraries Frameworks and libraries are very similar to built-in functionality. Frameworks and libraries are developed to make something in the language easier or to simplify a task that you would normally have to do yourself in code. So, with more frameworks you could make development easier than normal. Takeaway: If a language has plenty of support from libraries and frameworks, the language will decrease in complexity. Resources Our last topic here is arguably the most important. Ultimately, without high-quality documentation it can be very hard to learn a language. When looking for resources on a language, check out books, blog posts, tutorials, videos, documentation and forums for making sure there are plenty of resources on the topic. Takeaway: The more high-quality resources out there on the programming language, the easier it will be to learn.  When deciding on what programming languages are complex or simple, it truly depends on a few factors: your previous experience, the syntax of the language, built-in functionality, the concepts used, frameworks for support, and high-quality resources available. About the Author  Antonio Cucciniello is a Software Engineer with a background in C, C++ and JavaScript (Node.Js) from New Jersey.   His most recent project called Edit Docs is an Amazon Echo skill that allows users to edit Google Drive files using your voice.  He loves building cool things with software, reading books on self-help and improvement, finance, and entrepreneurship. Follow him on twitter @antocucciniello, and follow him on GitHub here: https://github.com/acucciniello
Read more
  • 0
  • 0
  • 13937
article-image-year-python
Sam Wood
04 Jan 2016
4 min read
Save for later

The Year of the Python

Sam Wood
04 Jan 2016
4 min read
When we asked developers for our $5 Skill Up report what the most valuable skill was in 2015, do you know what they said? Considering the title of this blog and the big snake image, you can probably guess. Python. Python was the most valuable skill they learned in 2015. But 2015 is over - so what did developers say they're hoping to learn from scratch, or increase their skills in in 2016? Correct guess again! It's Python. Despite turning 26 this Christmas (it's the same age as Taylor Swift, you know), the language is thriving. Set to be the most widely adopted new language for two years running is impressive. So why are people flocking to it? Why are we living in the years of the Python? There are three main reasons. 1. It's being learned by non-developers In the Skill Up survey, the people who were most likely to mention Python as a valuable skill that they learned also did not tend to describe themselves as traditional software developers. The job role most likely to be learning Python were 'Academics', followed by analysts, engineers, and people in a non-IT related role. These aren't the people who live to code - but they are the people who are likely finding the ability to program an increasingly useful professional skill. Rather than working with software every day, they are using Python to perform specific and sophisticated tasks. Much like knowledge of working in Microsoft became the essential office skill of the Nineties/Noughties, it looks like Python is becoming the language of choice for those who know they need to be able to code but don't necessarily define themselves as solely working in dev or IT. 2. It's easy to pick up I don't code. When I talked to my friends who did code, mumbling about maybe learning and looking for suggestions, they told me to learn Python. One of their principal reasons was because it was so bloody easy! This also ties in heavily to why we see Python being adopted by non-developers. Often being learned as a first programming language, the speed and ease with which you can pick up Python is a boon - even with minimal prior exposure to programming concepts. With much less of an emphasis on syntax, there's less chance of tripping up with missing parentheses or semicolons than with more complex languages. Originally designed (and still widely used) as a scripting language, Python has become extremely effective for writing standalone programs. The shorter learning curve means that new users will find themselves creating functioning and meaningful programs in a much shorter period of time than with, say, C or Java. 3. It's a good all-rounder Python can do a ton. From app development, to building games, to its dominance of data analysis, to its continued colonization of JavaScript's sovereign territory of web development through frameworks like Django and Flask, it's a great language for anyone who wants to learn something non-specialized. This isn't to say it's a Jack of All Trades, Master of None, however. Python is one of the key languages of scientific computing, aided by fast (and C-based) libraries like NumPy. Indeed, the strength of Python's versatility is the power of its many libraries to allow it to specialize so effectively. Welcoming Our New Python Overlords Python is the double threat - used across the programming world by experienced and dedicated developers, and extensively and heartily recommended as the first language for people to pick up when they start working with software and coding. By combining ease-of-entry with effectiveness, it's come to stand as the most valuable tech skill to learn for the middle of the decade. How many years of the Python do you think lie ahead?
Read more
  • 0
  • 0
  • 13896

article-image-we-need-to-encourage-the-meta-conversation-around-open-source-says-nadia-eghbal
Richard Gall
24 Jul 2018
4 min read
Save for later

We need to encourage the meta-conversation around open source, says Nadia Eghbal [Interview]

Richard Gall
24 Jul 2018
4 min read
Two years ago, Nadia Eghbal put together a report with the Ford Foundation. Titled Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure, the report is one of the most important discussions on the role of open source software in business and society today. It needs to be read. In it, Eghbal writes: "Everybody relies on shared code to write software, including Fortune 500 companies, government, major software companies and startups. In a world driven by technology, we are putting increased demand on those who maintain our digital infrastructure. Yet because these communities are not highly visible, the rest of the world has been slow to notice." Nadia's argument is important for both engineers and the organizations that depend on them. It throws light on the literal labor that goes into building and maintaining software. At a time when issues of trust and blowout cast a shadow over the tech industry, Nadia's report couldn't be more important. It's time for the world to stop pretending software is magic - it requires hard work. Today, Nadia works for Protocol Labs. There, she continues her personal mission to explore and improve the relationship between who builds software and who needs it. I was lucky enough to speak to Nadia via email, where she told me her thoughts on the current state of open source in 2018. Open source software in 2018 Do you think there's a knowledge gap or some confusion around open source? If so, what might be causing it? Open source has been around for ~20 years now (and free software is much older than that), but I don't think we've fully acknowledged how much things have changed. Earlier concerns, like around licensing, are less salient today, because of all the great work that was done in the late 1990s and early 2000s. But there isn't really a coherent conversation happening around the needs or cultural shifts in modern open source today, like managing communities or finding the time and resources to work on projects. I think that's partly because "open source" is such an obvious term now that people affiliate with specific communities, like JavaScript or Ruby - so that means the meta-conversation around open source is happening less frequently. "Money is complicated in open source, especially given its decentralized nature" Your report was published in July 2016. Has anything changed since it was published? [caption id="attachment_20989" align="alignright" width="300"] Nadia Eghbal at Strange Loop 2017 (via commons.wikimedia.org)[/caption] Lots! When the report was first published, it wasn't commonly accepted that sustainability was an important topic in open source. Today, it's much more frequently discussed, with people starting research initiatives, conversations, and even companies around it. My views have evolved on the topic, too. Money is complicated in open source, especially given its decentralized nature, and it's closely tied to behavior and incentives. Understanding all of that as a complete picture takes time. "I'd like to see more developers advocate for company policies that encourage employees to contribute back to the open source they use." Getting developers to actively contribute to open source projects Following the arguments put forward in your report, do you think there any implications for working software engineers - either professionally or politically? I'd like to see more developers advocate for company policies that encourage employees to contribute back to the open source they use. Open source projects have become sort of productized as they've scaled, but it would be great to see more developers go from being passive users to active contributors. It's also great for working developers who want to show off their work in public. Similarly, are there any implications for businesses? Any software-enabled business is mostly running on public infrastructure, not proprietary code, anymore. It's in their best interest to get to know the people behind the code. Follow Nadia on Twitter: @nayafia Visit Nadia's website: nadiaeghbal.com
Read more
  • 0
  • 0
  • 13405

article-image-how-are-container-technologies-changing-programming-languages
Xavier Bruhiere
11 Apr 2017
7 min read
Save for later

How are container technologies changing programming languages?

Xavier Bruhiere
11 Apr 2017
7 min read
In March 2013, Solomon Hykes presented Docker, which democratized access to Linux containers. The underlying technology, control groups, was already incubating for a few years at Google. However, Docker abstracts away the complexity of containers' lifecycle and adoption skyrocketed among developers. In June 2016, Datadog published some compelling statistics about Docker adoption: the industry as a whole increasingly adopted containers for production. Since everybody is talking about how to containarize everything, I would like to take a step back and study how it is influencing the development of our most fundamental medium: programming languages. The rise of Golang, the Java8 release, Python 3.6 improvements--how do language development and containerization marketsplay together in 2017? Scope of Container Technologies Let's define the scope of what we call container technologies. Way back in 2006, two Google engineers started to work on a new technology for the partition hierarchical group of tasks. They called it cgroups and submitted the code to the Linux Kernel. This lightweight approach of virtualization (sorry Mike) was an opportunity for infrastructure-heavy companies and Heroku and Google, among others, took advantage of it to orchestrate so-called containers. Put simply, they were now able to think of application deployment as the dynamic manipulation of theses determinist runtimes. Whatever the code or the business logic, it was encapsulated into a uniform execution format. Cgroups are very low level though, and tooling around the original primitives quickly emerged, like LXC backed by Canonical. Then, Solomon Hykes came in and made the technology widely accessible with Docker. The possibilities were endless and, indeed, developers and startups alike rushed in all directions. Lately, however, the hype seems to have cooled down. Docker market share is being questioned while the company sorts its business strategy. At the end of the day, developers forgetabout vendors/technology and just want simple tooling for more efficient coding. Docker-compose, Red Hat Container Development Kit, GC Container Builder, or local Kubernetes are very sophisticated pieces of technologies that hide the details of the underlying container mechanics. What they give to engineers are powerful primitives for advanced development practices: development/production environment parity, transparent services replication, and predictable runtime configuration. However,this is not just about development correctness or convenience, considering how containers are eating the IaaS landscape. It is also about deployment optimizations and resilience. Tech giants who operate crazy large infrastructures developed incredible frameworks, often in the open, to push how fast they could deploy auto-scalable, self-healing, zero-downtime fleets. Apache Mesos backed by Microsoft, or Kubernetes by Google, make at least two promises: Safe and agile deployments at the (micro-)service level Reliable orchestration with elegant service discovery, load-balancing, and failure management (because you have to accept that production always goes wrong at some point) Containers enabled us to manage complexity with infrastructure design patterns like micro-services or serverless. Behind the hype of these buzzwords, engineers try to improve team collaboration, safe and agile deployments, large project maintenance, and monitoring. However,we quickly came to realize it was sold with a DevOps tax. Fortunately, the software industry has a hard-won experience of such balance, and we start to see it converging toward the most robust approaches. This container landscape overview hopefully provides the requirements to now study how it has impacted the development of programming languages. We will take a look first at their ecosystems, and then we will dive into language designs themselves. Language Ecosystems and Usages Most developers are now aware of how invasive container technologies can be. It makes its way into your development toolbox or how your company manages its servers. Some will argue that the fundamentals of coding did not evolve much, but the trend is hard to ignore anyway. While we are free, of course, to stay away from Silicon Valley’s latest fashions, I think containers tackle a problem most languages struggle with: dependencies and packaging. Go, for example, got packaging right, but it’s still trying to figure out how to handle dependencies versioning and vendoring. JavaScript, on the other hand, has npm to manage fine-grained third-party code, but build tools are scattered all over Github. Containers won't spare you the pain of setting things up (they target runtimes, not build steps), but it can lower the bar of language adoption. Official images can run most standard language projects and one can both give a try and deploy a basic hello world in no time. When you realize that Go1.5+ needs Go1.4 to be compiled, it can be a relief to just docker run your five-lines-long main.go. Growing a language community is a sure way to develop its tooling and libraries, but containers also influence how we design those components. They are the cloud counterparts of the current functional trend. We tend to embrace a world where both functions and servers are immutable and single-purpose. We want predictable, pure primitives (in the mathematical sense). All of that to match increasingly distributed and intensive workloads. I hope those approaches come from a product’s need but, obviously, having the right technology at hand drives the innovation. As software engineers in 2017, we also design libraries and tools with containers in mind: high performance networking, distributed process management, Data pipelines, and so on. Language Design What about languages? To get things straight, I don't think containers influence how Guido Van Rossum designs Python. And that is the point of containers. They abstract the runtime to let you focus on your code™  (it is literally on every Docker-based PaaS landing page). You should be able to design whatever logic implementation you need, and containers will come in handy to help you run it when needed. I do believe, however, that both languages last evolutions and the rise of containers serve the same maturation of ideas in the tech community. Correctness at compile time: Both Python 3.6, ELM, and JavaScript ES7 are bringing back typing to their language (see type hints or Typescripts). An application running locally will launch just the same in production. You can even run tests against multiple runtimes without complex scripts or heavy setup. Simplicity: Go won a lot of its market share thanks to its initial simplicity, taking a lot of decisions for you. Containers try their best to offer one unified way to run code, whatever the stack. Functional: Scala, JavaScript, and Elixir, all enforce immutable states, function compositions with support for lambda expressions, and function purity. It echoes the serverless trend that promotes function as a service. Most of the providers leverage some kind of container technology to bring the required agility to their platforms. There is something elegant about having language features, programmatical design patterns, and infrastructure operations going hand in hand. While I don't think one of them influences the other, I certainly believe that their development smoothen other’s innovations. Conclusion Container technologies and the fame around them are finally starting to converge toward fewer and more robust usages. At the same time, infrastructure designs, new languages, and evolutions of existing ones seem to promote the same underlying patterns: simple, functional, decoupled components. I think this coincidence comes from industry maturity and openness, more than, as I said, one technology influencing the other. Containers, however, are shaking how we collaborate and design tools for the languages we love. It changes the way we on-board developers learning a new language. It changes how we setup local development environments with micro-replicates of production topology. It changes the way we package and deploy code. And, most importantly, it enables architectures like micro-services or lambdas that influence how we design our programs. In my opinion, programming language design should continue to evolve decoupled from containers. They serve different purposes, and given the pace of the tech industry, major languages should never depend on new shining tools. That being said, the evolution of languages now comes with the activity of its community—what they build, how they use it, and how they spread it in companies. Coping with containers is an opportunity to bring new developers, improve production robustness, and accelerate both technical and human growth. About the author Xavier Bruhiere is a lead developer at AppTurbo in Paris, where he develops innovative prototypes to support company growth. He is addicted to learning, hacking on intriguing hot techs (both soft and hard), and practicing high-intensity sports.
Read more
  • 0
  • 0
  • 12997
article-image-7-tips-python-performance
Gabriel Marcondes
24 Jun 2016
7 min read
Save for later

7 Tips For Python Performance

Gabriel Marcondes
24 Jun 2016
7 min read
When you begin using Python after using other languages, it's easy to bring a lot of idioms with you. Though they may work, they are not the best, most beautiful, or fastest ways to get things done with Python—they're not pythonic. I've put together some tips on basic things that can provide big performance improvements, and I hope they'll serve as a starting point for you as you develop with Python. Use comprehensions Comprehensions are great. Python knows how to make lists, tuples, sets, and dicts from single statements, so you don't need to declare, initialize, and append things to your sequences as you do in Java. It helps not only in readability but also on performance; if you delegate something to the interpreter, it will make it faster. def do_something_with(value): return value * 2 # this is an anti-pattern my_list = [] for value in range(10): my_list.append(do_something_with(value)) # this is beautiful and faster my_list = [do_something_with(value) for value in range(10)] # and you can even plug some validation def some_validation(value): return value % 2 my_list = [do_something_with(value) for value in range(10) if some_validation(value)] my_list [2, 6, 10, 14, 18] And it looks the same for other types. You just need to change the appropriate surrounding symbols to get what you want. my_tuple = tuple(do_something_with(value) for value in range(10)) my_tuple (0, 2, 4, 6, 8, 10, 12, 14, 16, 18) my_set = {do_something_with(value) for value in range(10)} my_set {0, 2, 4, 6, 8, 10, 12, 14, 16, 18} my_dict = {value: do_something_with(value) for value in range(10)} my_dict {0: 0, 1: 2, 2: 4, 3: 6, 4: 8, 5: 10, 6: 12, 7: 14, 8: 16, 9: 18} Use Generators Generators are objects that generate sequences one item at a time. This provides a great gain in performance when working with large data, because it won't generate the whole sequence unless needed, and it’s also a memory saver. A simple way to use generators is very similar to the comprehensions we saw above, but you encase the sentence with () instead of [] for example: my_generator = (do_something_with(value) for value in range(10)) my_generator <generator object <genexpr> at 0x7f0d31c207e0> The range function itself returns a generator (unless you're using legacy Python 2, in which case you need to use xrange). Once you have a generator, call next to iterate over its items, or use it as a parameter to a sequence constructor if you really need all the values: next(my_generator) 0 next(my_generator) 2 To create your own generators, use the yield keyword inside a loop instead of a regular return at the end of a function or method. Each time you call next on it, your code will run until it reaches a yield statement, and it saves the state for the next time you ask for a value. # this is a generator that infinitely returns a sequence of numbers, adding 1 to the previous def my_generator_creator(start_value): while True: yield start_value start_value += 1 my_integer_generator = my_generator_creator(0) my_integer_generator <generator object my_generator_creator at 0x7f0d31c20708> next(my_integer_generator) 0 next(my_integer_generator) 1 The benefits of generators in this case are obvious—you would never end up generating numbers if you were to create the whole sequence before using it. A great use of this, for example, is for reading a file stream. Use sets for membership checks It's wonderful how we can use the in keyword to check for membership on any type of sequence. But sets are special. They're of a mapping kind, an unordered set of values where an item's positions are calculated rather than searched. When you search for a value inside a list, the interpreter searches the entire list to see whether the value is there. If you are lucky, the value is the first of the sequence; on the other hand, it could even be the last in a long list. When working with sets, the membership check always takes the same time because the positions are calculated and the interpreter knows where to search for the value. If you're using long sets or loops, the performance gain is sensible. You can create a set from any iterable object as long as the values are hashable. my_list_of_fruits = ['apple', 'banana', 'coconut', 'damascus'] my_set_of_fruits = set(my_list_of_fruits) my_set_of_fruits {'apple', 'banana', 'coconut', 'damascus'} 'apple' in my_set_of_fruits True 'watermelon' in my_set_of_fruits False Deal with strings the right way You've probably done or read something like this before: # this is an anti-pattern "some string, " + "some other string, " + "and yet another one" 'some string, some other string, and yet another one' It might look easy and fast to write, but it's terrible for your performance. str objects are immutable, so each time you add strings, trying to append them, you're actually creating new strings. There are a handful of methods to deal with strings in a faster and optimal way. To join strings, use the join method on a separator with a sequence of strings. The separator can be an empty string if you just want to concatenate. # join a sequence of strings, based on the separator you want ", ".join(["some string", "some other string", "and yet another one"]) 'some string, some other string, and yet another one' ''.join(["just", "concatenate"]) 'justconcatenate' To merge strings, for example, to insert information in templates, we have a classical way; it resembles the C language: # the classical way "hello %s, my name is %s" % ("everyone", "Gabriel") 'hello everyone, my name is Gabriel' And then there is the modern way, with the format method. It is quite flexible: # formatting with sequencial strings "hello {}, my name is {}".format("everyone", "Gabriel") 'hello everyone, my name is Gabriel' # formatting with indexed strings "hello {1}, my name is {2} and we all love {0}".format("Python", "everyone", "Gabriel") 'hello everyone, my name is Gabriel and we all love Python' Avoid intermediate outputs Every programmer in this world has used print statements for debugging or progress checking purposes at least once. If you don't know pdb for debugging yet, you should check it out immediately. But I'll agree that it's really easy to write print statements inside your loops to keep track of where your program is. I'll just tell you to avoid them because they're synchronous and will significantly raise the execution time. You can think of alternative ways to check progress, such as watching via the filesystem the files that you have to generate anyway. Asynchronous programming is a huge topic that you should take a look at if you're dealing with a lot of I/O operations. Cache the most requested results Caching is one of the greatest performance tunning tweaks you'll ever find. Python gives us a handy way of caching function calls with a simple decorator, functools.lru_cache. Each time you call a function that is decorated with lru_cache, the interpreter checks whether that call was made recently, on a cache that is a dictionary of parameters-result pairs. dict checks are as fast as those of set, and if we have repetitive calls, it's worth looking at this cache before running the code again. from functools import lru_cache @lru_cache(maxsize=16) def my_repetitive_function(value): # pretend this is an extensive calculation return value * 2 for value in range(100): my_repetitive_function(value % 8) The decorator gives the method cache_info, where we can find the statistics about the cache. We can see the eight misses (for the eight times the function was really called), and 92 hits. As we only have eight different inputs (because of the % 8 thing), the cache size was never fully filled. my_repetitive_function.cache_info() CacheInfo(hits=92, misses=8, maxsize=16, currsize=8) Read In addition to these six tips, read a lot, every day. Read books and other people's code. Make code and talk about code. Time, practice, and exchanging experiences will make you a great programmer, and you'll naturally write better Python code. About the author Gabriel Marcondes is a computer engineer working on Django and Python in São Paulo, Brazil. When he is not coding, you can find him at @ggzes, talking about rock n' roll, football, and his attempts to send manned missions to fictional moons.
Read more
  • 0
  • 0
  • 12588

article-image-how-has-python-remained-so-popular
Antonio Cucciniello
21 Sep 2017
4 min read
Save for later

How has Python remained so popular?

Antonio Cucciniello
21 Sep 2017
4 min read
In 1991, the Python programming language was created. It is a dynamically typed object oriented language that is often used for scripting and web applications today. It is usually paired with frameworks such as Django or Flask on the backend. Since its creation, it's still extremely relevant and one of the most widely used programming languages in the world. But why is this the case? Today we will look at the reason why the Python programming language has still been extremely popular over the last couple of years. Used by bigger companies Python is widely used by bigger technology companies. When bigger tech companies (think companies such as Google) use Python, the engineers that work there also use it. If the developers use Python at their jobs, they will take it to their next job and pass the knowledge on. In addition, Python continues to be used organically when these developers use their knowledge of this language in any of their personal projects they have as well, futher spreading its usage. Plenty of styles are not used In Python, whitespace is important, but in other languages such as JavaScript and C++ it is not. The whitespace is used to dictate the scope of the statements in that indent. By making whitespace important it reduces the need for things like braces and semicolons in your code. That reduction alone can make your code look simpler and cleaner. People are always more willing to try a language that looks and feels cleaner, because it seems easier to learn psychologically. Variety of libraries and third-party support Being around as long as it has, Python has plenty of built-in functionality. It has an extremely large standard library with plenty of things that you can use in your code. On top of that, it has plenty of third-party support libraries that make things even easier. All of this gained functionality allows programmers to focus on the more important logic that is vital to their application's core functionality. This makes programmers more efficient, and who doesn't like efficiency? Object oriented As mentioned earlier, Python is an object oriented programming language. Due to it being object oriented, more people are likely to adopt it because object orient programming allows developers to model their code very similar to real world behavior. Built-in testing Python allows you to import a package called unittest. This package is a full unit testing suite with setup and teardown functions. Having this built in, it is something that is stable for developers to use to test their applications. Readability and learnability As we mentioned earlier, the whitespace is important, therefore we do not need brackets and semicolons. Also Python is dynamically typed so it is easier to create and use variables while not really having to worry about the type. All of these topics could be difficult for new programmers to learn. Python makes it easier by removing some of the difficult parts and having nicer looking code. The reduction of difficulty allows people to choose Python as their first programming language more often than others. (This was my first programming language.) Well documented Building upon the standard libraries and the vast amount of third-party packages, the code in those applications is usually well documented. They tend to have plenty of helpful comments and tons of additional documentation to explain what is happening. From a developer stand point this is crucial. Having great documentation can make or break a language's usage for me. Multiple applications To top it off, Python has many applications it can be used in. It can be used to develop games for fun, web applications to aid businesses, and data science applications. The wide variety of usage attracts more and more people to Python, because when you learn the language you now have the power of versatility. The scope of applications is vast. With all of these benefits, who wouldn't consider Python as their next language of choice? There are many options out there, but Python tends to be superior when it comes to readability, support, documentation, and its wide application usage. About the author Antonio Cucciniello is a Software Engineer with a background in C, C++ and JavaScript (Node.Js) from New Jersey. His most recent project called Edit Docs is an Amazon Echo skill that allows users to edit Google Drive files using your voice. He loves building cool things with software, reading books on self-help and improvement, finance, and entrepreneurship. Follow him on twitter @antocucciniello, and follow him on GitHub here: https://github.com/acucciniello.
Read more
  • 0
  • 0
  • 12331
Modal Close icon
Modal Close icon