devopsy.kinsta.cloud

Tag: app developers

  • Developers Continue to Prefer Remote Work

    Developers Continue to Prefer Remote Work

    A survey found 83% of developers are working remotely more than half of the time, with more than three-quarters (76%) reporting they have maintained or increased the frequency of remote work in the last year. In fact, three in five respondents (62%) work remotely at least 90% of the time.

    The survey, published by Netlify, a provider of a platform for building the front end of Web applications using the Jamstack framework, polled 6,544 developers in the Jamstack community and found more than half (55%) would quit their jobs if forced to return to an office.

    It’s not clear how much remote work has become a de facto requirement for organizations to attract and retain developer talent, but it’s clear that, in the wake of the COVID-19 pandemic, the dynamic between developers and the organizations that employ them has completely changed.

    Netlify CEO Mathias Biilmann said regardless of industry, it’s apparent that DevOps teams are going to continue to need to make adjustments to foster collaboration across distributed teams. Senior managers will find it increasingly challenging to manage workflows across a workforce that is also witnessing a lot of turnover, he noted. A third of survey respondents (33%) reported having changed jobs in the last year. It’s not clear how much a lack of interaction in the office might be impacting innovation, but at a time when demand for developer talent far exceeds the available supply, organizations will need to adjust to what appears to have become a permanent new reality.

    At the same time, the Netlify survey noted the pace at which emerging technologies are being embraced continues to rapidly evolve—perhaps because of rather than in spite of remote work. For example, the survey found 70% of developers reported using a serverless computing framework in the last year. Nearly half (47%) are also experimenting with edge dynamic sites, the survey found. It’s clear that company culture, at least in terms of technology adoption, plays a large role in attracting developer talent.

    Overall, 96% of survey respondents noted that JavaScript is their primary choice of programming language, with 21% of developers now specifically using TypeScript to build applications. The React framework for building applications, meanwhile, is being used by 71% of developers, with 47% reporting they employed the Next.js version of that framework. Other React frameworks gaining traction include Vite (32%), Sveltekit (15%), Astro (11%), Remix (10%) and SolidJS (6%).

    However, emerging Web3 technologies have yet to gain traction. While 7% to 10% of developers have tried out technologies such as cryptocurrencies and NFTs, only 3% reported using these technologies regularly. A total of 42% of developers either didn’t know what Web3 was or didn’t care about it, while 31% felt negatively about it, the survey found.

    Ultimately, the primary reason organizations invest in DevOps is to increase developer productivity. The challenge is that, as developers embrace more tools and platforms for building applications, the process of deploying those applications becomes more challenging to manage effectively. One way to achieve that goal is to separate frontend and backend software development processes to enable developers to focus more on writing code rather than managing the arcane processes required to deploy it.

  • 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.

  • No Matter How Things Change, Have a Plan

    No Matter How Things Change, Have a Plan

    Had enough change yet? It is almost amusing that I and some other tech people had that conversation a decade ago, and since then, nothing has slowed down. Our conclusion was that, for the near future, change would be constant. That conclusion was right; I’d have to ping everyone else to see what they think, but “near future” turned out to be longer than I expected.

    Inevitably, though, change requires taking a breather at times. It appeared that high-tech was finally ready to admit that burning out your staff was not a viable long-term business model, and was slowing down … and then, COVID-19 hit. Now I’m hearing rumblings about going back to non-stop change as if the last couple of years were a vacation and staff is all rested up and ready to replace massive chunks of the infrastructure.

    The reason that change requires intermissions, though, is not 100% about staff and burnout. That only shows up when you’re making a ton of change non-stop. Before staff burnout becomes an issue, recovery and business continuity plans become outdated. At the rate we’ve been running, I’d go so far as to say they are likely useless.

    Yes, all this change has brought us some cool stuff. While we are busier, some of the busywork is far easier, or even non-existent now—but that doesn’t change the fact that you need to breathe. This is a perfect time to go over plans to keep the business on its feet in case of IT catastrophe—or at least some major systems catastrophe. Saying “We’ll just deploy a new version” is cool, but it only works in some scenarios. I touched on this and discussed one case where it doesn’t work in October 2021. But there are a ton more. Every environment is different, but hardware failures have not disappeared and destructive writes still occur, as just two more examples. Your infosec team can give you a few more examples.

    Knowing what you’re going to do when the worst-case scenario happens is huge. And for those who’ve never been through it, knowing before people are stressed and asking you for a timeline will save you a lot of headaches.

    For those who’ve never had a DR or business continuity plan, consider it. At least have a basic DR plan that lists critical systems, things most likely to go wrong and what the steps are to recover it and get things moving again. The process of making such a list will often uncover things that should be done but aren’t—like backups or backup verifications.

    For those with a DR or business continuity plan, I’ll take a wild shot and say, “It’s out of date.” Organizations tend to create them and then forget about them. These plans should involve a bit of each project, so it’s taken care of in bite-sized chunks, but—probably because the first implementation of DR or BC is normally a massive project—it tends to be set aside and revisited every few years. Don’t do that.

    As I’ve said before, you and yours have built the heart of the modern enterprise. Don’t forget to protect it. It doesn’t take much to use some of these sweet new technology advances to put in DR procedures. Tack DR review/updates onto each major initiative, be it a new product or a big change to existing software. And keep rocking it. If you have a say in your organization, consider slowing the pace down for a bit and even updating DR. If you don’t have a say, may your employer be wise enough to do so.

  • APM and Application Stability: Where Two Monitoring Roads Merge and Diverge

    APM and Application Stability: Where Two Monitoring Roads Merge and Diverge

    In software development, application performance management (APM) is one of the grown-ups in the room. Not only has APM been around for a long time, but its solutions have evolved over several generations, making it one of the more mature product categories. 

    APM’s longevity makes perfect sense when you consider its fundamental purpose, which is to provide organizations with a way to understand the performance characteristics of their software. Value is delivered by alerting infrastructure teams when applications are performing slowly or poorly, and APM has the vast experience to do this job well. 

    If APM is one of the old-timers in software development, then application stability is the new kid in town. With the rise of mobile apps and iterative development releases, application stability has answered the widespread need to monitor applications in a new way, shifting the focus from servers and networks to the customer experience. 

    The emergence of application stability has caused some consternation for die-hard APM fans. However, these two solutions embody very distinct monitoring focuses, which leads me to believe there’s room for both tools, as well as different teams for both.

    APM: The Engine for Infrastructure and DevOps Teams

    Before the cloud, organizations supplied their own physical hardware and monitored components such as RAM, disk space, CPU and memory. If you ran out of any of these resources, you were screwed. 

    And that was the beauty of APM: It enabled the people running the applications to anticipate when they’d need more resources. 

    Of course, rather than monitor physical machines, today’s infrastructure, SRE and DevOps teams monitor cloud instances. Gone are the days of running out to Best Buy and lugging back new hardware. Instead, a simple request for a new instance is submitted to a cloud provider, and instant access is received. 

    Rather than make APM obsolete, as some feared, the cloud presents two good reasons for continued reliance on this tool.

    1. Apps Can Be Resource Hogs: A cloud instance is simply a slice of someone else’s computer, which means you still need to know when you’re close to running out of resources on this virtual machine. In fact, extra care is needed these days because you’re likely to run out of space more quickly.
    2. Money Still Doesn’t Grow on Trees: The ease of access to infinite cloud resources means that software companies may fall into the habit of throwing money at problems rather than figuring out how to streamline usage and costs through better efficiency. Companies can end up paying a ton of money to run apps if they continuously spin up more cloud instances without thorough consideration of the cost and need.

    And that’s where APM steps in. Its main purpose is to help infrastructure teams figure out capacity planning. With the cloud, questions shift to include:

    • How can I better manage my cloud instances and optimize usage? 
    • How can I make sure I don’t give ludicrous amounts of money to cloud providers? 
    • How can we tweak and optimize the cloud to reduce costs?

    These are the types of things that APM does extremely well. Anytime you need to figure out how to optimize your current resources or when to buy a new server or cloud instance, APM tells you. This information is invaluable to the people running the applications, namely the infrastructure or DevOps team.

    Application Stability: Where the Tires Meet the Road for Engineering Teams

    Now, let’s be honest, APM doesn’t have its strongest showing when the person who runs the app is also the person who builds the app. And that’s exactly the scenario presented by mobile development and iterative coding. 

    Rather than going through long development cycles, software now gets pushed to the web on a daily basis, and mobile apps tend to have weekly or biweekly release cycles. This release speed is not only encouraged but expected in agile software development.

    That means the chasm between building and running apps has shrunk, especially for mobile apps. More often than not, the people building the apps are the people releasing them. There is no gap. And, with mobile, companies no longer need to worry about expensive physical hardware but rather about the end user experience. The customer becomes the focus.

    Unfortunately, APM is perhaps a little too set in its ways to help you do that. But it’s not APM’s fault. These requirements are not what APM is inherently built to do. It’s great at detecting problems and alerting infrastructure teams so they can toss the issue over the fence to the development team. However, its core strength isn’t providing information on how to fix the problems because it wasn’t built with the developer audience in mind. 

    Trying to refactor APM to help with stability and error issues is like tuning your engine when you have flat tires. They are completely separate components of the car, built for different purposes. You can tune the engine all you want, but it isn’t going to move the car unless you focus on why there isn’t air in the tires.

    In today’s iterative world, development teams care a lot more about how apps are running. There’s a demand for fixing actionable items. Developers want to know exactly what’s broken, what to fix right now and what can wait. In short, developers want aggregation and automation of errors. They want to know, “Do we build or fix?” 

    This trade-off between building new features versus fixing bugs is one of the key factors behind the adoption of application stability management tools. Developers need answers to several questions:

    • Where are the errors in the code?
    • How can we get to those bugs and fix them as soon as possible?
    • How can we tie bug fixing into our planning for the week? 

    Whether running sprints or building in an agile manner, development work is planned in advance. Developers want to figure out how much new feature work will be included in a sprint versus how much bug fixing is required. And they need a tool that helps them automate the answer to that question.

    Benefits of Application Stability

    The beauty of application stability is that it brings together the errors captured by APM and enables developers to see at a glance which ones are worth fixing. As a result, five major benefits arise.

    1. Increased Efficiency: Companies eliminate the problem of infrastructure teams tossing issues over the fence to development teams. Valuable time is saved because application stability tools remove the game of telephone between the two teams and deliver bugs directly to the team that will fix them.
    2. Stronger CSAT: The time to fix bugs goes down dramatically when the person who wrote the code fixes the code. With diagnostic information in hand from the application stability tool, software engineers innately understand what the code does, what the bug means and how to fix it. Faster resolution of bugs that impact the end user experience means that customer satisfaction levels (CSAT) are less likely to drop.
    3. Error Prioritization: Application stability tools group bugs by root cause, making it easy for developers to get a sense of severity at a glance. It’s much easier to determine what to fix first when developers can see which errors are most costly, which affect the most customers, and which bug is impacting a key customer.
    4. Tool Synchronization: Taking it one step further, application stability tools are tied into project management suites. Bugs map directly to tickets created in Jira (or whatever tool is used), and tickets update automatically as priority changes.
    5. Stability Scores by Release: Application stability enables product and development teams to see stability scores by release. Since it’s common to have multiple app versions live at the same time, especially with mobile apps (where DevOps isn’t really involved), companies can’t rely on a single stability score. Teams need to see stability by release so that it’s clear exactly where the errors are and what impact they’re having on users.

    What Percentage of Your Development Team Has a Login to Your APM?

    I’m often asked whether I think application stability will replace APM, and my answer is simple: no, I don’t. APM remains an essential part of developing software, and organizations still need to understand when they’re about to run out of resources and when there’s poor performance. 

    Instead, I see these two solutions co-existing as adjacent categories but helping different teams. Application stability delivers prioritized errors to developers for fixing, while APM works well for enabling ops teams to raise red flags on high error rates and reduce cloud spend.

    Some of you may be thinking to yourself, “Well, my APM product does what you’re describing for application stability, so I’m sure my developers are fine using it.” To which I poise the following challenge: What percentage of your dev team has a login to your APM? What percentage logs in on a daily basis? And, if they do use it, do your developers like it?

    The answers to these questions may surprise you. After all, APM wasn’t really built for developers or for keeping end users happy. In contrast, application stability was born at the customer layer and is designed specifically to monitor the front end and ensure strong customer experiences with web and mobile apps. 

    Once you’ve had a chance to hear from your dev team, it wouldn’t surprise me if you discover that they’re pretty excited about the new kid in town.

    — James Smith

  • Developing Apps for IOS 13: Things to Consider

    Developing Apps for IOS 13: Things to Consider

    Authors of numerous articles and videos have covered all the bells and whistles built into iOS 13, the latest major iteration of Apple’s mobile operating system. Rather than diving into all of these perks, though, I will focus on the changes for app developers.

    As it often happens, Apple introduced many proprietary applications that successfully supersede a number of third-party ones. It’s clear that QuickPath will now replace GBoard to enter text and provide swipe features. Also, the native secondary display feature for iPad called Sidecar will substitute Astropad and Dual Display solutions. Furthermore, custom stickers and animated emoji called Memoji can be used instead of the counterpart from Mirror AI.

    The to-do list application now comes with features that used to be a prerogative of the Things app users: you can set a date, create reminders with subtasks and configure various types of alerts based on location. The overhauled Files app allows users to share folders, connect to cloud services, leverage an archiving tool and do many other awesome things. The syncing of lyrics with Apple Music used to be a matter of installing Musixmatch solution, but iOS 13 has introduced a feature of its own for that purpose.

    There are two main conclusions you can draw from these ongoing tweaks. On the one hand, Apple is trying to hold sway over the ecosystem of the most popular applications. On the other hand, the company is developing a transparent and clear-cut array of services for integration and interoperability. 

    In other words, as long as your application hasn’t been replaced with Apple’s native counterpart, make sure its development occupies a unique niche aligned with the platform’s evolution strategy. Take into account the novelties that change the user experience and require that your coders take extra adaptation efforts.

    Dark Mode

    The 2018 macOS release came with the Dark Mode onboard. Users were expecting a similar feature for iOS back then, but it took Apple’s software engineers more time to implement it for iPhone and iPad. And here we go–Dark Mode is finally available in iOS 13. It functions as part of the Night Shift mode, and therefore the switching takes place automatically.

    It’s beyond all doubt that most users will keep the default iOS settings so that the mode is enabled depending on the time of the day. In the meantime, app developers have to do quite a bit of cumbersome work to support the new feature. They need to create UIs with variable colors while adhering to uniform graphics so people can enjoy using the app at any time with an equal degree of convenience.

    iOS 13 comes with turnkey instruments called Color Assets that minimize the amount of work required for app color theme development. iOS 11 and iOS 12 support this toolkit as well, but app makers relying on design for iOS 10 and earlier will have to stay on the sidelines of this progress.

    Standalone iPadOS

    Apple chose to depart from the general unification trend by segregating two platforms for their mobile devices. This approach gave rise to a separate branch called iPadOS. This is most likely a response to the low demand for the latest powerful iPad Pro models. Many users got the impression that the company actually created a professional, multi-functional gadget but failed to equip it with enough solutions to show its full potential. Neither applications nor compelling use cases were available to bridge the gap. The emergence of iPadOS is intended to change this as the independent, fully-fledged platform should match the hardware power.

    Overall, iPadOS bears a strong resemblance to the desktop operating system. It supports desktop-type scrolling features and the option to work with peripherals such as a mouse and trackpad. The revamped SpringBoard seems to bring some long-forgotten widgets back to the home screen. 

    Now that all of these modifications are in place, every developer should think of the iPad home screen widgets that their users might find handy. Perhaps it makes sense to add a widget rendering certain live information or providing helpful shortcuts.

    When it comes to multitasking, the all-new iPadOS appears to outperform macOS in many ways. For instance, iPad users can open multiple windows of the same app and quickly access favorite apps using the Slide Over feature.

    It means there are new scenarios the developers should consider. Among other things, they have to figure out which apps can be combined with theirs on the same screen; how to implement this without sacrificing the user experience; and what role–main or secondary–their app plays in such a tandem.

    To keep up with the new OS architecture, developers also need to ensure a resilient app layout. Enhanced multitasking means that your app will have to run seamlessly in multiple window sizes and proportions ranging from the traditional Full Screen to a swipeable tab in Slide Over mode. As a matter of fact, a similar interface design was available before; however, whereas it used to be optional, you definitely can’t disregard it anymore.

    Safari has also become a part of the maturity trend. Now it displays desktop site versions rather than mobile ones. The fundamental change, though, is that the browser has been fine-tuned at the engine level so the iPad can work with fully-functional web applications such as WordPress and G Suite. 

    Coders can benefit from this tweak as it poses a great alternative to masterminding an iPad-only application. They can save a good deal of time and money, additionally offering their users a readily available tried-and-tested web app if they have one, of course.

    Last but not least, the new Sidecar mode allows users to cast their Mac’s screen content to the iPad. This feature supports macOS Catalina. Aside from the secondary display perk, Sidecar allows you to use Apple Pencil in Mac apps. That’s one more way of leveraging iPad features without having to create a separate app version, which might make some developers question the need for such extra work.

    Data Rendering

    Dashboards are being definitely implemented in full swing in iOS 13. Lots of Apple’s native apps are using data illustrations on their main screens that reflect the event log, explain how to take advantage of new features and give comprehensive clues about various usage scenarios. This complex approach really differs from the purely functional one that used to be the case.

    The refreshed home page of Apple Maps is a good example of the current trend. It includes new tools to work with geolocation and arrange or add places to favorites. The Health app displays daily infographics, too. These features encourage users to open the application over and over.

    The ubiquity of real-time data and infographics has actually turned into a big trend for all Apple products, including smartphones, tablets, desktop computers and smartwatches. Therefore, if your app generates some potentially interesting or useful information, be sure to demonstrate it to the user. That’s what will fill the app’s dashboard. But first, you should understand what types of data your users prioritize: nifty content or strictly functional stuff.

    Photos

    The updated Photos app is one of the most conspicuous changes brought by iOS 13. You can’t go wrong if you say that creating and editing photos is currently among the main iPhone use cases. Apple developers have rethought the whole process to deliver the best graphics experience.

    The app’s home screen covers all the photo gallery browsing scenarios imaginable. It seems to have been designed specifically for hours of gazing at a time. In addition to the use of machine learning technology for choosing the most captivating images, the photo and video editor boasts amazing visualization of the settings and allows you to view the results immediately in the context of the other content. You can barely notice the process of switching between modes–from browsing to editing and taking photos. All in all, the iOS 13 Photos app exemplifies a mobile solution that surpasses its desktop counterpart in many ways.

    This is a serious challenge for developers because it calls forth a whole new level of coherent user experience in mobile app design. The users will be expecting equally elaborate and smooth apps flawlessly aligned with the rest of the iOS 13 ecosystem.

    Security

    Apple has marketed their operating systems as ultimately safe and privacy-friendly for years, consistently highlighting the leak-proof gist of both iOS and macOS as their competitive advantage. As many of you may know, it is not always the case considering how many new malware pieces target Apple users these days. 

    Trying to be on top of privacy defense, Apple updated the Location Alert feature lets the user know about background applications requesting geolocation data. Although, some programs need these details to operate properly, quite a few app authors keep such data harvesting enabled in the background just in case.

    In iOS 13, this characteristic can become a way to ruin your app’s reputation. As soon as the user gets an alert showing a bunch of points on the map that the application has been recently keeping track of, they are likely to follow the system’s recommendation and block this activity without a second thought.

    This security feature is meant to restrain developers from collecting redundant data that isn’t required for their apps to work properly. It also encourages app makers to notify users when and why they need to know their whereabouts.

    Sign in with Apple

    This feature has been anticipated for quite some time and it finally went live with the release of iOS 13. You can now use your Apple ID to sign into various websites and applications. This functionality secures the authentication routine by means of Face ID or Touch ID. Many developers will find it convenient because it introduces a simple and intuitive authentication workflow eliminating the need to store and manage passwords. The security of this process is now entirely up to Apple.

    Programming with Swift

    Apple has been endorsing the Swift programming language for a while. iOS 13 gave these initiatives a boost by introducing SwiftUI that overhauls the entire paradigm of creating applications for Apple devices. Effectively, it is a critical link between programmers and designers that was missing before. SwiftUI also propels a shift toward a reactive programming style. Apple Developer libraries now support a bevy of UI models. Furthermore, the Combine framework will be henceforth heavily used for coding. These instruments are currently in beta testing and things may change dramatically over time, though.

    Nonetheless, Apple has already provided developer tutorials aimed at facilitating the process of switching to reactive programming. The beta testing will definitely unearth a lot of roadblocks and there will be tons of bug fixes and tool replacements further on. However, Apple engineers will certainly address these issues in the long run.

    It appears that the age of Objective-C with its numerous drawbacks is doomed to fade away, succumbing to more competitive development instruments. 

    SwiftUI already allows programmers to compile applications without high coding proficiency. You can easily add modules that will complement your new app. That being said, designers and managers with entry-level skills will be able to compile prototypes of new software products.

    Overlapping Apps for iOS and macOS

    In the aftermath of the growingly close ties between iOS, macOS and the newly released iPadOS, mobile applications can now run on macOS. You actually couldn’t compile a mobile code using Apple’s desktop operating system till the summer of 2019, but now it’s possible. At the 2019 Apple Worldwide Developers Conference (WWDC 2019), experts claimed this could be done without having to use a simulator.

    However, since the layout structure of iPad applications has more in common with macOS style than the iPhone app layout does, we’re mainly talking about executing iPad apps on desktop machines. Given that some Apple apps look very much alike on different devices (Reminders and Stocks), the proprietor of the platform is expecting the developers of third-party apps to stick with the same uniformity across environments.

    It comes as no surprise that some mobile devices are starting to support desktop mouse and trackpad, and the user interfaces are being unified at the level of the smallest details. For instance, the design of the user icon has been concurrently updated in all the services and applications on iOS, iPadOS, watchOS, and macOS. To maintain the rebuilt environment, Apple is busy expanding the app development sections on their website. The company has provided UI kits even for products in beta testing and created a library of interface icons, lagging slightly behind Android in this regard.

    Summary

    To recap, it’s clear that Apple is trying to establish and push forward a convenient ecosystem for app developers. At the end of the day, this is one of the fundamental elements of a long-term competitive strategy and we may expect more changes with the advent of iOS 14.

    — David Balaban