devopsy.kinsta.cloud

Tag: coding languages

  • Watch Your Language(s)

    Watch Your Language(s)

    Just about every organization I am familiar with today is using more languages, frameworks, libraries, etc. than they were a decade ago. Back then, most organizations were doing a lot of Java, and maybe a little bit of PHP or .NET (almost always VB.NET). Now we have Java, Python, Ruby, Go, Swift, etc. And etc., etc.

    The problem is that employees don’t come pre-instructed with your selection of languages. Most developers can bring Java or Python and most know at least one other language well. All of them can learn (more on that in a moment), but when hiring, an organization needs to focus on the one or two languages the hiring team is using, not all the languages an organization might ask a developer to learn over the course of their employment. After all, when hiring 20 years ago, the tools of the mainframe team weren’t generally listed as requirements for a desktop developer. While there is a difference (desktop developers were only asked to work on mainframes when the shortage of experienced big iron devs got really bad), it is a similar situation today.

    You can hire with an eye to training, and most developers will be more than willing to pick up a new language and learn its ins and outs. But ask any manager that pays close attention, and they’ll let you know that there is a huge difference between time-to-productive and time-to-proficient. One manager told me that any programmer with experience could start contributing relatively quickly in Ruby, but to do the important stuff—things like knowing which array access methods were faster and the most efficient communication between Ruby and other languages—took far longer. His numbers seemed too high, in my opinion and based on my experience, so I asked around. All the managers I know that worked with Ruby (because to a great extent, this is language-dependent, so I didn’t want to make hasty generalizations though, in hindsight, the same data point in Python would have given me more responses) agreed there is a curve, and the range was somewhere between six months to two years. This is strictly anecdotal, but it seems the more technical the team in question, the longer the manager thought proficiency would take.

    But even if the lower number is accurate and applies more generally, it is an argument for keeping your language count down. Yes, some languages are better at X or Y or Z than others, but most modern languages can do just about everything an average enterprise team will ask of them. So, keeping languages within a smaller pre-defined set still allows teams to choose the best tool for the job while keeping the number of skills developers at the organization might need down to a manageable level.

    And keep wowing them. No matter what languages you are using, your user base is logging in and using the results daily—or perhaps your devices are reporting the results daily or processing them. No matter how you are delivering, you are, as our digital world shows. Keep rocking it, and do what you can to keep the number of languages under your roof down.

  • Is TypeScript the New JavaScript?

    Is TypeScript the New JavaScript?

    While JavaScript is frequently the language of choice for all sizes of frontend and backend applications, it’s not the only option; nor is it necessarily the most efficient or cost-effective. Increasingly, TypeScript is becoming the go-to language for app development—particularly for larger apps. The time- and cost-saving benefits are significant enough that some organizations are even taking projects initially started in JavaScript and migrating them to TypeScript. 

    What is TypeScript?

    While the number of programs written in JavaScript has grown exponentially, the programming language’s ability to express the relationships between different units of code and mitigate coding errors early on hasn’t kept pace. Along with JavaScript’s inconsistent semantics, this makes JavaScript-driven app development difficult to manage at scale.

    Released in 2012, TypeScript was created to address JavaScript’s deficiencies in developing large-scale apps. It’s an open source, strongly typed programming language that builds on JavaScript by adding optional static typing. Types enable structuring and validating code before it’s executed, which is beneficial when developing large apps. They also provide additional information about code, which serves as better documentation for other developers and facilitates collaboration.

    TypeScript is a superset of JavaScript, which means any JS code is also valid TS code—provided the TS configuration is set to be compatible with it. It outputs code in pure JavaScript and allows developers to liberally use JS libraries, tools and frameworks. It runs on Node.js or any browser that supports ECMAScript 3 or higher. It also supports object-oriented programming features. 

    JavaScript Drawbacks

    JavaScript is one of the world’s most popular programming languages and works extremely well for small projects. However, its disadvantages—many of which affect project costs and code delivery time—make a strong case for considering alternatives such as TypeScript, particularly for larger projects.

    Most of these drawbacks have to do with the lack of types and compile-time error checks, making JavaScript less than desirable for server-side code in enterprises and large codebases. The following are just a few of its disadvantages:

    • JavaScript employs dynamic typing, which means scripts can compile even if they contain errors that can prevent them from properly running.
    • Because JavaScript is dynamically typed, it allows one variable to have multiple properties assigned to it. It doesn’t instantly let developers know what a variable can contain. That makes it easy to assign the wrong properties.
    • Since JavaScript is an interpreted language, errors can only be found during runtime. Code needs to run before being tested and validated, so it can take considerable time to find bugs and errors in JavaScript code.
    • To eliminate inaccuracies, it’s necessary to manually verify types and the syntactic correctness of the code. This lengthens development time and extends the delivery cycle to production, increasing development costs.
    • JavaScript code is executed on the client side so it’s viewable to the user. As a result, bugs and oversights have the potential to be exploited for malicious purposes. 
    • Lengthy onboarding of new developers can result because developers must figure out the properties of the structures they’re working with, as well as the data types. While JSDoc can be used for documenting code and annotating types, there’s still the need to synchronize the actual code and documentation. The lack of synchronization, in turn, can mislead developers and complicate the introduction of new, business-requested features.
    • JavaScript is prototype-based, not class-based. It’s not considered a pure object-oriented programming language, although it can follow some object-oriented programming principles.

    The TypeScript Advantage

    TypeScript is a superset of JavaScript. If a developer knows JavaScript, there’s not much of a learning curve to take advantage of the features TypeScript offers that make up for many of JavaScript’s deficiencies—and it can offer additional benefits.

    For example, with JavaScript, variables can start as one property, and then change into an object or a string. These inconsistencies can generate problems that are difficult to resolve in large apps. TypeScript, on the other hand, analyzes the code and tries to determine proper variable types prior to runtime. Once a variable type is assigned, it stays unchanged. TypeScript’s compiler also helps shorten the QA and testing process in later stages of development.

    TypeScript also helps developers quickly figure out the purpose of a variable within the code. It can also suggest available properties in functions, classes or components. Being able to quickly look up a variable is important because it reduces the likelihood of calling the wrong function or accidentally skipping a variable declaration. Any reduction in bugs and errors reduces the time required for fixing those issues and, therefore, reduces overall development time. That gives developers more time to work on app logic and fix errors that can be detrimental to in-app performance and usability. According to a postmortem analysis by Airbnb, 38% of bugs they encountered were preventable with TypeScript after the company adopted it throughout the organization. 

    As a static language, TypeScript performs type checks upon compilation, flagging type errors and helping developers spot mistakes early on in development. Reducing errors when working with large codebases can save hours of development time.

    Clear and readable code is easy to maintain, even for newly onboarded developers. Because TypeScript calls for assigning types, the code instantly becomes easier to work with and understand. In essence, TypeScript code is self-documenting, allowing distributed teams to work much more efficiently. Teams (and individual developers) don’t have to spend inordinate amounts of time familiarizing themselves with a project.

    TypeScript’s integration with editors also makes it much easier to validate the code thanks to context-aware suggestions. TypeScript can determine what methods and properties can be assigned to specific objects, and these suggestions tend to increase developer productivity.

    TypeScript is widely used to automate the deployment of infrastructure and CI/CD pipelines for backend and web applications. Moreover, the client part (for example, when using Angular) and the backend can be written in the same language—TypeScript. This flexibility allows an engineer who knows one programming language to cover all parts of the system.

    Because TypeScript essentially transpiles to JavaScript, migrating existing code to TypeScript is easy and fast. It can typically be accomplished simply by running the compiler and adding typing where it’s not recognized by the language. There’s no need to make changes to the code.

    The benefits of TypeScript have been noticed by developers. TypeScript was used by 78% of the 2020 State of JS respondents, with 93% saying they would use it again. TypeScript continues to grow in popularity. It was voted the second most-loved programming language in the Stack Overflow 2020 Developer survey. 

    TypeScript & AWS: Better Together 

    There’s another compelling reason to consider TypeScript for large-scale app development projects. It’s fully supported by AWS, the leading cloud platform for modern app design and development as noted in Gartner’s Magic Quadrant for Cloud Infrastructure and Platform Services.

    The following services and tools have seamless integration out-of-the-box with TypeScript, enabling you to use this language for a vast number of tasks:

    • AWS CDK provides infrastructure-as-code (IaC) to automatically deploy the entire infrastructure in one click. You can also automate the creation of CI/CD pipelines for the future launch of specific jobs on demand.
    • AWS Lambda allows you to run computation tasks in serverless mode using automatic scaling and an efficient pricing scheme.
    • Amazon EC2, ECS and EKS can cover any of your tasks and provide a wide range of solutions for running apps written in TypeScript—from bare metal servers to complex clusters of hundreds of Docker containers.

    Optimize Your Application Development Projects

    All decisions made during an application development project can impact overall costs and time to market. That includes going with the right programming language and using the most appropriate cloud platform and resources. 

    When approaching an app dev project, a one-size-fits-all approach rarely works. Take the time to define your needs and priorities and select the best resources to deliver the best results.

  • Languages and DevOps: Embedded

    Languages and DevOps: Embedded

    Every once in a while, it is a good idea to take stock of the environment and the market around us to determine if what we are doing is what we should be doing. I’m a developer, not a prognosticator, so these observations are simply based on my experience in the development world, along with a frank assessment of what’s changing, to try and offer some advice to my fellow developers. This week I’ll talk about embedded, but we’ll hit a bunch of application targets over the coming weeks.

    Embedded development is, generally speaking, more low-level than most other modern programming practices. Considering the goal of embedded is to interface with the hardware, this is no surprise.

    C/C++

    And that brings us to the king(s) of the embedded hill. C, and to a lesser extent, C++ rule this roost. You will see a lot of talk about Python, and we’ll get to that in a minute, but for historical and performance reasons, C is still your best bet. If your DevOps tools support your Make variant – Ant, Maven, or whatever – it can be plugged directly into the DevOps process. Testing will still take extra steps. Since deployment is most often handled directly, that does not generally need extra steps, but, in some cases, it might. A lot of general guides claim C/C++ is “easy” to learn. I disagree with this assessment; newer languages tend to be more intuitive while retaining some of C’s better features, but it is, at this time, necessary to embedded development.

    There’s a Reason (or Many) for That …

    There are a lot of conflicting factors going into where embedded is headed in the future, so we’ll try to address them here.

    Historically speaking, C/C++ have had better performance and smaller footprints than interpreted (even bytecode) languages. They are easier to code in than Assembly and supported by a ton of libraries to get work done; they struck the right balance for embedded. The weight of these developers and the legacy source code they created are part of the reason C/C++ are still on top.

    But three things have caused a shift that will open up room for other languages to make headway into this space. Embedded devices are getting faster, and storage is getting both smaller and cheaper. That means that a less-efficient means is more viable. Arduino and other hobbyist embedded platforms have also come of age. It is now viable to pick up an embedded board and start prototyping over the weekend. These embedded environments are well-supported by newer languages, and, historically speaking, today’s hobby builders are tomorrow’s startups. This is pulling other languages into the mix far more frequently, particularly our next entry.

    Python

    Python is popular in almost every category of programming. It has been around long enough to lose the mantle of “language du jour,” and should be considered based on its strengths and weaknesses. Given that the newer wave of prototype systems is well-supported by Python, it is easy to maintain, and has a broad selection of libraries (often, ironically, written in C), it has gained clout in the embedded space. It doesn’t perform as well as C/C++, but modern embedded devices are of a class that this may not be as important (early embedded devices were high-performance tools, while IoT often has devices that don’t require anything like near-real-time), and hardware improvements make this less of a concern. Python’s popularity makes it relatively easy to work in to your DevOps toolchain, with targeting of embedded devices making deploy and test require extra steps … but that’s true for all of these languages, as it is a targeting feature, not a language issue.

    Assembler/Assembly

    In the end, we need machine code. Even bytecode (or p-code, if you prefer) interpreted languages execute their instructions in hardware, eventually. Because performance and space have long been issues in embedded development, assembly language has been a preferred tool for pieces of the development pie. While few developers use assembly language for everything, most embedded developers use it, at some point, to modify libraries or create targeted subroutines. Certainly not a “popular” language among developers, most of us buckle down and just do what we need to. Like C, assembly is normally built using a Make variant. These are easily integrated into DevOps toolchains to get reporting and results up to those dashboards that run a company’s agile efforts.

    Others

    There are a wealth of other languages in use on embedded platforms, most notably C#, but also newer languages like Rust. The environment is changing, and as the ramifications of terabyte SD cards and multi-core embedded boards start to sink in, they are worth watching. We are not that far off from having a desktop-quality computer in a board only a little larger than a credit card. That changes a lot of things. More room for data storage and processing, and the need for tools that are easier to use in these contexts.

    Libraries

    All languages use libraries to make development easier. We are past the days when coders wrote all of the functionality of their project. The tools that bring libraries into a project need to be incorporated into the DevOps toolchain. For C/C++, the mechanism is largely manual, and can be automated with scripts or with the build tool. For newer languages, tools like NPM will need to be hooked into the toolchain. The ease of library dependency management is one of the appealing aspects of newer languages, and making it easier for a developer to hook in libraries also makes it easier for DevOps tools to make use of library management functionality.

    You. Rock.

    Whatever your language of choice, in the end it will likely be your build tool that links it to DevOps. Maybe we should do a series on those, too; comparing when to use Gradle versus Ant, for example. Until then, keep rocking it. All development depends upon embedded in the end, so you’re holding up the foundation.

  • Python’s Popularity Continues: Examining the Top Use Cases

    Python’s Popularity Continues: Examining the Top Use Cases

    Python continues to be one of the most popular coding languages in use. In fact, the TIOBE index of programming language popularity named it the 2018 Language of the Year. Its usage and adoption continue to grow and proliferate into additional use cases.

    Python’s popularity and growth are in part because it’s flexible and easy to use. Python has grown from a scripting solution for sysadmins to web development for programmers to the driving force behind machine learning. We’ve observed this growth since 1999, when we began to build engineering Python distributions. As we’ve seen the use cases grow, we’ve examined the top use cases by customers ActiveState has observed.

    Let’s look at the three most popular Python use cases within the traditional tech space: infotech, software and hardware.

    Infotech: IT modernization

    The IT team of a state legislature is challenged to be able to remotely manage thousands of user desktops. Its 147 representatives, as well as its hundreds of supporting personnel, work on-premises and/or remotely. One of the key tools that empowered the team was Windows Powershell. Unfortunately, Powershell is unsupported and no longer works under newer Microsoft operating systems.

    Rewriting any application that’s a cost center is always difficult to justify. As a result, rewrites are rarely budgeted, planned and resourced appropriately. But the alternative was much costlier in terms of capital and resources: dispatch IT personnel to physically install, update and manage each user’s desktop, on an on-call basis.

    It’s famously easy to get started and develop with Python. While there was no way around a rewrite of the desktop management scripts, the IT team could at least minimize the time and resources required. Python allowed Powershell script rewrites to be done incrementally in IT’s spare time. This translated into a significant lowering of costs, and reduction in the risk of a “big bang” rip and replace project.

    Software: Adding Extensibility to Legacy Applications

    A U.S.-based public company has a 30-plus-year history of providing a suite of electronic design automation (EDA) tools to their more than 5,000 customers worldwide. Its suite of tools historically was built in C++ and is packaged for deployment on-premises.

    Because each customer has their own instance, it’s natural for the customer to want to customize the suite of tools to their needs. The U.S. public company used Python to wrap some of its C++ APIs to expose key functionality, making their software solutions more extensible by customers. Ensuring Python was deployed properly at customer sites required including Python within their existing installer, rather than relying on their customers to install Python correctly.

    The company used an OEM distribution Python that added a standard version of Python within their application and deployed it, so all teams can customize and leverage the EDA tools as required. Plus, by deploying a standardized Python version across all customer sites and developer desktops, the company can decrease support costs and speed time to market by eliminating the need for legal department reviews. Further, using a third-party-standardized Python version eliminates the opportunity cost of managing one’s own Python build and can facilitate the discovery of issues, bugs and performance issues.

    Hardware: Automating Network Administration

    A Silicon Valley-based American technology leader develops, manufactures and sells networking hardware. A key enterprise demographic for the company is network administrators, who often are confronted with managing the vendor’s multiple devices across extended corporate networks.

    The challenge: Network admins aren’t typically developers. Yet, they want to improve their efficiency by being able to programmatically make configuration changes to multiple network devices at once. While sample scripts are easy for any network admin to use and modify, the vendor did not want to be held responsible for creating all the scripts its user base might require.

    Python was the solution because it is simple enough for any technical person to learn and start using effectively. The company chose a version of Python that allows their customers to quickly create sample Python scripts to cover the majority of typical network admin use cases.

    This choice also allows network admins to create Python libraries they can leverage to create their own custom scripts to manipulate the configuration, operational state or event data from network devices. Most importantly, the cost of administering enterprise networks is significantly lowered and network admins are dramatically more efficient with programmatic access to physical networking devices and virtual network resources.

    Looking Outside the Tech Space

    Other examples that round out the top 10 use cases for Python include:

    • Consulting services: Bespoke web development.
    • Insurance: Creating business insights with machine learning.
    • Finance: Data mining to identify cross-sell opportunities.
    • Retail banking: Flexible data transformation and manipulation.
    • Aerospace: Meeting software system deadlines.
    • Business services: API access to financial information.
    • Health Care: Predicting disease prognosis.

    Ongoing Innovation

    Python’s usage continues to grow due to its simplicity and flexibility. Developers clearly want to use it for a variety of reasons that surpass its creator’s original intent. To support this usage, organizations need to ensure their developers can do so securely, by overcoming open source vulnerabilities while still iterating quickly. It seems that use cases for Python are limited only to the imaginations of its growing, enthusiastic user base.

    — Bart Copeland