General Programming & Web Design Articles

Article / Updated 04-28-2025

For enterprises whose growth depends on the innovation of their developers and data scientists, success moves at the speed of their development environments. Efficiency, effectiveness, and the ability to build without friction — that’s what sets the pace. The question is simple enough: Do your developers and data scientists work their magic in cloud development environments (CDEs), or is their work bogged down by a legacy development environment? Read on to find out why local development environments and other traditional solutions may be holding back your developers, and how cloud development environments can set them free. How traditional development environments are lacking What are some of the ways the wrong development environment may be making your company’s progress sluggish? Local development environments: This was yesterday’s standard, with all developers managing their own environments on their own machines. All that local control gets in the way of getting ahead. It’s complicated and time-consuming to configure tools and dependencies on each individual environment. You wind up with inconsistencies that slow things down. And don’t even think about scaling this approach. Virtual desktop infrastructures (VDIs): VDIs help to centralize environments, but they’re often not really workable for development. They’re expensive and complicated to maintain. They also tend to suffer from sluggish performance, and that’s no way to keep developers happy. Shadow virtual machines (VMs): Developers may get around these issues with ad hoc VMs, but they end up creating different problems. “Shadow” solutions may be lacking in governance and are often overprovisioned. That makes them potential security risks, not to mention wasteful of resources. How cloud development environments can help A fully managed environment is the answer to the challenges of these more disjointed solutions from yesteryear. The CDE may be hosted in the cloud or via on-premises infrastructure, and it brings together all the necessary tools, libraries, and infrastructure needed for efficient development. It’s a development workspace that can be accessed from anywhere, not tied to a specific location or machine. It’s great for remote work, and because of its centralized infrastructure, it’s a lot more secure than storing code and data on developers’ laptops. Developers and data scientists can easily tap into it for coding applications and training machine learning (ML) models, getting up and running in minutes. Provisioning is automatic, so everything developers need is right there and ready to go. It can all be controlled from a centralized interface by authorized team members, ensuring only the right people can access code and data. And the compute and storage resources are easily scalable. How CDEs make developers more productive Traditional local development environments tend to be frustratingly slow when it comes to onboarding new developers or moving developers to new projects (and developers tend to take on new projects multiple times a year, of course). Provisioning environments can take days or even weeks, thanks to all the complexities of dependencies and the need for approvals. Meanwhile, if developers are off working in their own local environments, that also leads to problems requiring time-consuming troubleshooting. Mismatched environments are the enemy of success. What’s more, resource constraints can be a hangup in local development environments. CDEs, on the other hand, can be preconfigured, so developers just log in and get to work. Platform engineers can make global updates and ensure consistencies across the CDE. Configuration drift is no longer a problem. As for resource constraints, the cloud can fix that with high-performance resources that scale as needed. Developers can set up resource-intensive tasks such as ML model training in the cloud, and use their local laptops to get other work done in the meantime. Why cloud development environments provide better security Local development environments and various noncentralized alternatives can pose security threats, due to a lack of adequate governance and a hard-to-manage attack surface. Working with intellectual property and other sensitive data on developer laptops or unapproved VMs is risky. If developers need to pull sensitive data to their laptops for such things as ML model training, you’re tempting fate, because security problems don’t just hold developers back — they can set back the entire organization. CDEs, on the other hand, can live in a cloud environment or be centralized in on-premises infrastructure. They can be air-gapped if need be. Source code and data can stay in secure cloud or on-premise locations, along with any compute resources needed for dealing with them, so sensitive data never needs to leave the safety of home. Compliance teams aren’t fond of local environments because they’re tricky to monitor. CDEs, on the other hand, offer better monitoring and auditing capabilities, without getting in the way of the developers’ work. How CDEs save both money and time Face it — local development environments can be costly. Local hardware isn’t cheap, especially the high-end hardware needed for resource-intensive processes. But if your enterprise tries to trim those costs, developers are likely to be displeased. The reality is, CDEs not only provide a better developer experience and greater security, they also save money and time. Developers can use most cost-effective machines that are less powerful and longer-lasting, because the heavy lifting is happening in the CDE, not on the local machine. What’s more, CDEs can tap into automation to optimize resource utilization. Auto-start and auto-stop features mean unused environments aren’t sitting there wasting money. Bin-packing multiple developer workspaces onto a single VM can reduce infrastructure costs, too. And once again, helping developers be more efficient — by easing onboarding and transitioning, while banishing sluggish equipment — saves money, too. Time is, after all, money. If you can save hours and days and weeks of wasted developer time, you’ll get a whole lot more out of the money you’re paying them. To learn more about the benefits of CDEs, download your free Cloud Development Environments For Dummies, CoderTechnologies, Inc. Special Edition e-book.

Article / Updated 05-30-2024

For each web coding issue identified by a validator, you need to determine what course of action to take. Although some culprits that repeatedly crop up are easy to fix, such as missing alt text and <noscript> tags, you’re bound to find coding issues that completely baffle and stump you. For instance, if you get an error message that reads XML Parsing Error: Opening and ending tag mismatch: br line 52 and body, it might be difficult to figure out what that means, let alone why it was caused and how you should fix it. As a strategy then, try to fix the issues within the code from the top down, as they’re listed in the validation results, because sometimes fixing one issue resolves another. With the XML parsing error, that issue might disappear when you correct for an omitted closing element on a <br /> tag listed earlier in the error results. The best way to find out how to code better and make fewer mistakes before validation testing is to make lots of honest mistakes and figure out how to correct them on your own. Most often, you can fix noncompliant code by hand or with the help of a good HTML editor. To help you identify some of the more common coding mistakes, here several code issues along with suggestions about how to fix them. Problem Solution alt text attribute missing from <img> tag Add the alternative text attribute, either with or without a description, as in <img src="images/logo.gif" width="150" height="150" alt="Pete’s Pizza"> <img src="images/flourish.gif" width="200" height="150" alt=""> . <noscript> tags missing from code Add <noscript> tags below each instance when JavaScript is present in in-line JavaScript or at the end of the content before the closing body tag. Between the <noscript> tags, insert HTML content (text, graphics, media files, and so on) that describes the function of the JavaScript and, when appropriate, how visitors can access the information revealed by it, as shown here: <script language="JavaScript" src="bookmark.js" type="text/javascript"></script><noscript>The JavaScript used on this page provides a quick link that allows visitors to automatically bookmark this page. As an alternative, please use your browser’s Bookmark This Page feature.</noscript> Flashing or flickering element(s) detected, such as animated GIFs, Java applets, and other multimedia plug-ins Adjust the speed of any animations to avoid causing the screen to flicker with a frequency between 2 Hz and 55 Hz. Animations that exceed these two measures may cause seizures in visitors with photosensitive epilepsy. No DOCTYPE specified Add a valid DOCTYPE above the opening <head> tag. No HTTP charset parameter specified This special meta tag specifies the character set used in the HTML code. Some HTML editors include it automatically when generating new blank web pages. If validation finds that this tag is missing from your HTML or XHTML code, insert the following code by hand: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> . For HTML5, insert <meta charset="utf-8"> . No <title> tag specified Add a unique title between <title> tags in the head area on each page. No <meta> tags specified Add meta keywords and meta description tags to the head of each page. These can be identical on every page on the site. If desired, you may also add additional meta tags as needed. No Robots tags specified Add the Robots <meta> tag in the head of the page to instruct web spiders and robots whether to index the page and follow any hyperlinks, such as <meta name="Robots" content="All"> . Deprecated <font> tags detected Move all the presentation markup of the HTML (page, fonts, tables, links, and so on) to an external CSS file and remove all <font> tags and HTML and inline formatting attributes. Deprecated table height attribute detected Control table cell heights, when necessary, with CSS styles. Style attributes detected in the opening <body> tag Move body attributes, like margin attributes and background page color, to a BODY tag redefine style in an external CSS file. type attribute not specified for JavaScript or CSS Add the type="text/css" attribute for <style> tags and the type="text/javascript" attribute for <script> tags: <style type="text/css" ><script type="text/javascript"> . Entity name used instead of entity number Change the entity name to an entity number, such as using $#169; instead of © to create the copyright symbol (c). No background color attribute was specified for a CSS style that specifies text color Provide each style that contains a text color attribute with an attending background color attribute. The background color should match, or closely match, the background color upon which the text will display on. When you’re finished identifying and adjusting all the noncompliant code identified by the validation tools, and have fixed everything that needed fixing, move on to the retesting and acceptable failure phase of the testing process.

Article / Updated 05-30-2024

The success of your DevOps initiative relies heavily on following the process, but it’s also important to use the right tools. Selecting a cloud service provider isn’t an easy choice, especially when DevOps is your driving motivation. GCP (Google Cloud Platform), AWS (Amazon Web Services), and Azure have more in common than they do apart. Often, your decision depends more on your DevOps team’s comfort level with a particular cloud provider or your current stack more than the cloud provider itself. After you’ve decided to move to the cloud, the next decision is to decide on a cloud provider that fits your DevOps needs. Here are some things to consider when evaluating cloud providers with DevOps principles in mind: Solid track record. The cloud you choose should have a history of responsible financial decisions and enough capital to operate and expand large datacenters over decades. Compliance and risk management. Formal structure and established compliance policies are vital to ensure that your data is safe and secure. Ideally, review audits before you sign contracts. Positive reputation. Customer trust is absolutely key. Do you trust that you can rely on this cloud provider to continue to grow and support your evolving DevOps needs? Service Level Agreements (SLAs). What level of service do you require? Typically cloud providers offer various levels of uptime reliability based on cost. For example, 99.9 percent uptime will be significantly cheaper than 99.999 percent uptime. Metrics and monitoring. What types of application insights, monitoring, and telemetry does the vendor supply? Be sure that you can gain an appropriate level of insight into your systems in as close to real-time as possible. Finally, ensure the cloud provider you choose has excellent technical capabilities that provide services that meet your specific DevOps needs. Generally, look for Compute capabilities Storage solutions Deployment features Logging and monitoring Friendly user interfaces You should also confirm the capability to implement a hybrid cloud solution in case you need to at some point, as well as to make HTTP calls to other APIs and services. The three major cloud providers are Google Cloud Platform (GCP), Microsoft Azure, and Amazon web Services (AWS). You can also find smaller cloud providers and certainly a number of private cloud providers, but the bulk of what you need to know comes from comparing the public cloud providers. Amazon Web Services (AWS) As do the other major public cloud providers, AWS provides on-demand computing through a pay-as-you-go subscription. Users of AWS can subscribe to any number of services and computing resources. Amazon is the current market leader among cloud providers, holding the majority of cloud subscribers. It offers a robust set of features and services in regions throughout the world. Two of the most well-known services are Amazon Elastic Compute Cloud (EC2) and Amazon Simple Storage Service (Amazon S3). As with other cloud providers, services are accessed and infrastructure is provisioned through APIs. Microsoft Azure Before Microsoft launched this cloud provider as Microsoft Azure, it was called Windows Azure. Microsoft designed it to do just what the name implies — serve as a cloud provider for traditionally Windows IT organizations. But as the market became more competitive and Microsoft started to better understand the engineering landscape, Azure adapted, grew, and evolved. Although still arguably less robust than AWS, Azure is a well-rounded cloud provider focused on user experience. Through various product launches and acquisitions — notably GitHub — Microsoft has invested heavily in Linux infrastructure, which has enabled it to provide more robust services to a wider audience. Google Cloud Platform (GCP) The Google Cloud Platform (GCP) has the least market share of the three major public cloud providers but offers a substantial set of cloud services throughout nearly two dozen geographic regions. Perhaps the most appealing aspect of GCP is that it offers users the same infrastructure Google uses internally. This infrastructure includes extremely powerful computing, storage, analytics, and machine learning services. Depending on your specific product, GCP may have specialized tools that are lacking (or less mature) in AWS and Azure. Finding DevOps tools and services in the cloud Literally hundreds of tools and services are at your disposal through the major cloud providers. Those tools and services are generally separated into the following categories: Compute Storage Networking Resource management Cloud Artificial Intelligence (AI) Identity Security Serverless IoT Following is a list of the most commonly used services across all three of the major cloud providers. These services include app deployment, virtual machine (VM) management, container orchestration, serverless functions, storage, and databases. Additional services are included, such as identity management, block storage, private cloud, secrets storage, and more. It’s far from an exhaustive list but can serve as a solid foundation for you as you begin to research your options and get a feel for what differentiates the cloud providers. App deployment: Platform as a Service (PaaS) solution for deploying applications in a variety of languages including Java, .NET, Python, Node.js, C#, Ruby, and Go Azure: Azure Cloud Services AWS: AWS Elastic Beanstalk GCP: Google App Engine Virtual machine (VM) management: Infrastructure as a Service (IaaS) option for running virtual machines (VMs) with Linux or Windows Azure: Azure Virtual Machines AWS: Amazon EC2 GCP: Google Compute Engine Managed Kubernetes: Enables better container management via the popular orchestrator Kubernetes Azure: Azure Kubernetes Service (AKS) AWS: Amazon Elastic Container Service (ECS) for Kubernetes GCP: Google Kubernetes Engine Serverless: Enables users to create logical workflows of serverless functions Azure: Azure Functions AWS: AWS Lambda GCP: Google Cloud Functions Cloud storage: Unstructured object storage with caching Azure: Azure Blob Storage AWS: Amazon S3 GCP: Google Cloud Storage Databases: SQL and NoSQL databases, on demand Azure: Azure Cosmos DB AWS: Amazon Relational Database Service (RDS) and Amazon DynamoDB (NoSQL) GCP: Google Cloud SQL and Google Cloud BigTable (NoSQL) As you explore the three major cloud providers, you notice a long list of services. You may feel overwhelmed by the hundreds of options at your disposal. If, by chance, you can’t find what you need, the marketplace will likely provide something similar. The marketplace is where independent developers offer services that plug into the cloud — hosted by Azure, AWS or GCP. The table below lists additional services provided by most, if not all, cloud providers. Common Cloud Services Service Category Functionality Block storage Data storage used in storage-area network (SAN) environments. Block storage is similar to storing data on a hard drive. Virtual Private Cloud (VPC) Logically isolated, shared computing resources. Firewall Network security that controls traffic. Content Delivery Network (CDN) Content delivery based on the location of the user. Typically utilizes caching, load balancing and analytics. Domain Name System (DNS) Translator of domain names to IP addresses for browsers. Single Sign-On (SSO) Access control to multiple systems or applications using the same credentials. If you’ve logged into an independent application with your Google, Twitter or GitHub credentials, you’ve used SSO. Identity and Access Management (IAM) Role-based user access management. Pre-determined roles have access to a set group of features; users are assigned roles. Telemetry, monitoring and logging Tools to provide application insights on performance, server load, memory consumption and more. Deployments Configuration, infrastructure and release pipeline management tools. Cloud shell Shell access from a command-line interface (CLI) within the browser. Secrets storage Secure storage of keys, tokens, passwords, certificates and other secrets. Message Queues Dynamically scaled message brokers. Machine Learning (ML) Deep learning frameworks and tools for data scientists. IoT Device connection and management.

Cheat Sheet / Updated 03-26-2024

If you want to build your own website from start to finish, this book serves as a great resource. It includes many secrets and best practices that web developers know and implement when building any quality website. This cheat sheet includes bits and pieces of what you'll find in the book.

Cheat Sheet / Updated 01-05-2024

One of the handiest features of web coding and development is that once you’ve learned a few basics, you can apply those basics to any project. A good example is the underlying structure of a page, which uses the same set of standard HTML tags, no matter how large or small the project. It’s also worth your time to learn how selectors work, because you use them to save you time both when you’re writing CSS rules and when you’re writing JavaScript code. Errors, too, are a fact of web coding life, so understanding the most common errors can help you debug your code faster and get back to more creative pursuits.

Cheat Sheet / Updated 11-13-2023

Note: The following cheat sheet is from Building Websites All-in-One For Dummies which published in 2012; therefore, this content may be outdated. For more current information on website building, please see HTML, CSS, & JavaScript All-in-One For Dummies. Whether complex or simple, websites require that you make decisions — such as color, theme, and tone — and that you juggle many pieces of the project — like code, style sheets, and graphics. Knowing which resources to turn to for help implementing HTML5, and a few key points about incorporating graphics and video, can help you.

Cheat Sheet / Updated 09-25-2023

One of the bonuses you get when you tackle HTML, CSS, and JavaScript is that after you learn a few basics, you can apply those basics to any project. A good example is the underlying structure of a page, which uses the same set of standard HTML tags, no matter how large or small the project. It’s also worth your time to learn the most powerful CSS selectors, because you use those selectors all the time to speed up your work when you’re writing rules. Programming errors, too, are a fact of web coding life, so understanding the most useful JavaScript debugging strategies can help you fix your code faster and get back to more creative pursuits.

Article / Updated 08-16-2023

What is DevOps? It’s difficult to provide you with an exact DevOps prescription — because none exists. DevOps is a philosophy that guides software development, one that that prioritizes people over process and process over tooling. DevOps builds a culture of trust, collaboration, and continuous improvement. As a culture, the DevOps philosophy views the development process in a holistic way, taking into account everyone involved: developers, testers, operations folks, security, and infrastructure engineers. DevOps doesn’t put any one of these groups above the others, nor does it rank the importance of their work. Instead, a DevOps company treats the entire team of engineers as critical to ensuring that the customer has the best experience possible. DevOps evolved from Agile In 2001, 17 software engineers met and published the “Manifesto for Agile Software Development,” which spelled out the 12 principles of Agile project management. This new workflow was a response to the frustration and inflexibility of teams working in a waterfall (linear) process. Working within Agile principles, engineers aren’t required to adhere to original requirements or follow a linear development workflow in which each team hands off work to the next. Instead, they’re capable of adapting to the ever-changing needs of the business or the market, and sometimes even the changing technology and tools. Although Agile revolutionized software development in many ways, it failed to address the conflict between developers and operations specialists. Silos still developed around technical skill sets and specialties, and developers still handed off code to operations folks to deploy and support. In 2008, Andrew Clay Shafer talked to Patrick Debois about his frustrations with the constant conflict between developers and operations folks. Together, they launched the first DevOpsDays event in Belgium to create a better — and more agile — way of approaching software development. This evolution of Agile took hold, and DevOps has since enabled companies around the globe to produce better software faster (and usually cheaper). DevOps is not a fad. It’s a widely accepted engineering philosophy. DevOps focuses on people Anyone who says that DevOps is all about tooling wants to sell you something. Above all else, DevOps is a philosophy that focuses on engineers and how they can better work together to produce great software. You could spend millions on every DevOps tool in the world and still be no closer to DevOps nirvana. Instead, focus on your most important engineering asset: engineers. Happy engineers make great software. How do you make happy engineers? Well, you create a collaborative work environment in which mutual respect, shared knowledge, and acknowledgement of hard work can thrive. Company culture is the foundation of DevOps Your company has a culture, even if it has been left to develop through inertia. That culture has more influence on your job satisfaction, productivity, and team velocity than you probably realize. Company culture is best described as the unspoken expectations, behavior, and values of an organization. Culture is what tells your employees whether company leadership is open to new ideas. It’s what informs an employee’s decision as to whether to come forward with a problem or to sweep it under the rug. Culture is something to be designed and refined, not something to leave to chance. Though the actual definition varies from company to company and person to person, DevOps is a cultural approach to engineering at its core. A toxic company culture will kill your DevOps journey before it even starts. Even if your engineering team adopts a DevOps mindset, the attitudes and challenges of the larger company will bleed into your environment. With DevOps, you avoid blame, grow trust, and focus on the customer. You give your engineers autonomy and empower them to do what they do best: engineer solutions. As you begin to implement DevOps, you give your engineers the time and space to adjust to it, allowing them the opportunities to get to know each other better and build rapport with engineers with different specialties. Also, you measure progress and reward achievements. Never blame individuals for failures. Instead, the team should continuously improve together, and achievements should be celebrated and rewarded. You learn by observing your process and collecting data Observing your workflow without expectation is a powerful technique to use to see the successes and challenges of your workflow realistically. This observation is the only way to find the correct solution to the areas and issues that create bottlenecks in your processes. Just as with software, slapping some Kubernetes (or other new tool) on a problem doesn’t necessarily fix it. You have to know where the problems are before you go about fixing them. As you continue, you collect data — not to measure success or failure but to track the team’s performance. You determine what works, what doesn’t work, and what to try next time. Persuasion is key to DevOps adoption Selling the idea of DevOps to your leaders, peers, and employees isn’t easy. The process isn’t always intuitive to engineers, either. Shouldn’t a great idea simply sell itself? If only it were that easy. However, a key concept to always keep in mind as you implement DevOps is that it emphasizes people. he so-called “soft skills” of communication and collaboration are central to your DevOps transformation. Persuading other folks on your team and within your company to adopt DevOps requires practicing good communication skills. Early conversations that you have with colleagues about DevOps can set you up for success down the road — especially when you hit an unexpected speed bump. Small, incremental changes are priceless in DevOps The aspect of DevOps that emphasizes making changes in small, incremental ways has its roots in lean manufacturing, which embraces accelerated feedback, continuous improvement, and swifter time to market. Water is a good metaphor for DevOps transformations. Water is one of the world’s most powerful elements. Unless people are watching the flood waters rise in front of them, they think of it as relatively harmless. The Colorado River carved the Grand Canyon. Slowly, over millions of years, water cut through stone to expose nearly two billion years of soil and rock. You can be like water. Be the slow, relentless change in your organization. Here’s that famous quote from a Bruce Lee interview to inspire you: Be formless, shapeless, like water. Now you put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend. Making incremental changes means, for example, that you find a problem and you fix that problem. Then you fix the next one. You don’t take on too much too fast and you don’t pick every battle to fight. You understand that some fights aren’t worth the energy or social capital that they can cost you. Ultimately, DevOps isn’t a list of steps you can take, but is rather an approach that should guide the decisions you make as you develop.

Article / Updated 08-16-2023

DevOps has no ideal organizational structure. Like everything in tech, the “right” answer concerning your company’s structure depends on your unique situation: your current team, your plans for growth, your team’s size, your team’s available skill sets, your product, and on and on. Aligning your DevOps team’s vision should be your first mission. Only after you’ve removed the low-hanging fruit of obvious friction between people should you begin rearranging teams. Even then, allow some flexibility. If you approach a reorganization with openness and flexibility, you send the message that you’re willing to listen and give your team autonomy — a basic tenet of DevOps. You may already have a Python or Go developer who’s passionate and curious about infrastructure and configuration management. Maybe that person can switch into a more ops-focused role in your new organization. Put yourself in that person’s shoes. Wouldn’t you be loyal to an organization that took a risk on you? Wouldn’t you be excited to work hard? And that excitement is contagious. Here, you learn how to align the teams you already have in place, dedicate a team to DevOps practices, and create cross-functional teams — all approaches from which you can choose to orient your teams toward DevOps. You can choose one approach and allow it to evolve from there. Don’t feel that this decision is permanent and unmovable. DevOps focuses on rapid iteration and continual improvement and that’s the prime benefit of this methodology. That philosophy applies to teams as well. Aligning functional teams for DevOps In this approach, you create strong collaboration between your traditional development and operations teams. The teams remain functional in nature — one focused on ops, one focused on code. But their incentives are aligned. They will grow to trust each other and work as two teams yoked together. For smaller engineering organizations, aligning functional teams is a solid choice. Even as a first step, this alignment can reinforce the positive changes you’ve made so far. You typically start the alignment by taking the time to build rapport. Ensure that each person on both teams not only intellectually understands the other team’s role and constraints but also empathizes with the pain points. For this approach, it’s a good idea to promote a policy of “You build it, you support it.” This policy means that everyone — developer and operations person alike —participates in your on-call rotation. This participation allows developers to start understanding the frustrations of being called in the middle of the night and struggling while foggy-eyed and caffeine-deprived to fix a bug that’s impacting customers. Operations folks also begin to trust your developers’ commitment to their work. Even this small change builds an extraordinary amount of trust. A word of caution: If developers fight hard against being on call, a larger problem is at play in your organization. The pushback is not uncommon because being on call is wildly different from their normal day-to-day responsibilities. The pushback often comes from a place of discomfort and fear. You can help mitigate this reaction by addressing the fact that your developers may not know what to do the first few times they’re on call. They may not be familiar with the infrastructure, and that’s okay. Encourage them to escalate the incident and page someone with more experience. Finally, create a runbook with common alerts and what actions to take. Providing this resource will help to assuage some fear until they begin to get the hang of things. Another tactic to help spur collaboration to form a more cohesive DevOps team is to introduce a day of shadowing, with each team “trading” a colleague. The traded person simply shadows someone else on the team, sits at their desk (or in their area), and assists in their day-to-day responsibilities. They may help with work, discuss problems as a team (pair programming), and learn more about the system from a different point of view. This style of teaching isn’t prescriptive. Instead, it lends itself to curiosity and building trust. Colleagues should feel free to ask questions — even the “stupid” variety — and learn freely. No performance expectations exist. The time should be spent simply getting to know each other and appreciating each other’s work. Any productive output is a bonus! In this alignment approach, both teams absolutely must be involved in the planning, architecture, and development processes. They must share responsibilities and accountability throughout the entire development life cycle. Dedicating a DevOps team A dedicated DevOps team is more an evolution of the Sys Admin than a true DevOps team. It is an operations team with a mix of skill sets. Perhaps some engineers are familiar with configuration management, others IaC (infrastructure as code) and perhaps others are experts in containers or cloud native infrastructure or CI/CD (continuous integration and continuous delivery/development). If you think that putting a group of humans into an official team is enough to break down silos, you’re mistaken. Humans are more complex than spreadsheets. Hierarchy doesn’t mean anything if your silos have entered a phase in which they are unhealthy and tribal. In toxic cultures, a strongman style of leadership can emerge that is almost always followed by people taking sides. If you see this on your own team, you have work to do. Although any approach may work for your team, this dedicated team approach is the one you should think through the most. The greatest disadvantage of a dedicated DevOps team is that it easily becomes a continuation of traditional engineering teams without acknowledging the need to align teams, reduce silos, and remove friction. The risks of continuing friction (or creating more) are high in this approach. Tread carefully to ensure you’re choosing this team organization for a specific reason. The benefits of this DevOps approach is having a dedicated team to address major infrastructure changes or adjustments. If you’re struggling with operations-centered issues that are slowing down your deployments or causing site reliability concerns, this might be a good approach — even temporarily. A dedicated team if you’re planning on moving a legacy application to the cloud. But rather than calling this team a DevOps team, you might try labeling it an automation team. This dedicated group of engineers can focus completely on ensuring that you’ve set up the correct infrastructure and automation tools. You can then proceed with confidence that your application will land in the cloud without major disruption. Still, this approach is temporary. If you keep the team isolated for too long, you risk going down a slippery slope from rapid growth to embedded silo. Creating cross-functional product teams for DevOps A cross-functional team is a team formed around a single product focus. Rather than have separate teams for development, user interface and user experience (UI/UX), quality assurance (QA), and operations, you combine people from each of these teams. A cross-functional team works best in medium to large organizations. You need enough developers and operations folks to fill in the positions of each product team. Each cross-functional team looks a bit different. It’s a good idea to have, at a minimum, one operations person per team. Do not ask an operations person to split their responsibilities between two teams. This scenario is unfair to them and will quickly create friction between the two product teams. Give your engineers the privilege of being able to focus and dig deep into their work. If you’re organization is still small or in the startup phase, you can think of your entire engineering organization as a cross-functional team. Keep it small and focused. When you begin to approach having 10–12 people, start thinking about how you can reorganize engineers. The image below shows what your cross-functional teams could look like. But keep in mind that their composition varies from team to team and from organization to organization. Some products have a strong design focus, which means that you may have multiple designers in each team. Other products are technical ones designed for engineers who don’t care much for aesthetics. Teams for that kind of product may have one designer — or none at all. If your organization is large enough, you can certainly create multiple teams using different DevOps ideas and approaches. Remember that your organization is unique. Feel empowered to make decisions based on your current circumstances and adjust from there. Here are some possible combinations of various types of product teams. Legacy Product Team: Project Manager (PM), Front-end Developer, Back-end Developer, Back-end Developer, Site Reliability Engineer (SRE), Automation Engineer, QA Tester Cloud Transformation Team: SRE, SRE, Operations Engineer, Automation Engineer, Back-end Developer MVP Team: PM, Designer, UX Engineer, Front-end Developer, Backend Developer, Operations Engineer The downside of a cross-functional product team is that engineers lose the camaraderie of engineers with their same skill sets and passions. Having a group of like-minded individuals with whom you can socialize and from whom you can learn is an important aspect of job satisfaction. Check out a solution to this issue below. As shown below, you can give your engineers dedicated work time to spend with their tribes. You can do something as generous as paying for lunch once every week so that they can get together and talk. Or you might provide 10–20 percent of work time for them to work on projects as a tribe. Either way, you need your engineers to stay sharp. Tribes share industry knowledge, provide sound feedback, and support career growth. Provide time for your engineers to learn from people with whom they share education, experience, and goals. This time provides a safe place where they can relax and feel at home. No amount of perfect finagling will overcome the shortfalls of a bad organizational culture. But if you’ve paid attention so far and made the appropriate strides, the next step is to form teams that reinforce the cultural ideals you’ve already put in place.

Article / Updated 08-02-2023

The XMLHttpRequest object contains several class properties that you’ll need to know about to handle the HTTP response from the web server. The XMLHttpRequest Class Properties Property Description onreadystatechange Defines a callback function that the browser triggers when the HTTP connection changes state readyState Contains the connection status of the HTTP connection responseText Contains the response sent by the web server in text format responseXML Contains the response sent by the web server in XML format status Contains the numeric HTTP response code from the web server statusText Contains the text HTTP response string from the web server After you use the send() method to send a connection request to a web server, the HTTP connection process works through five connection states, as tracked by the readyState property: State 0: The connection has not been initialized. State 1: The connection to the server has been established. State 2: The server received the HTTP request message. State 3: The server is processing the HTTP request. State 4: The server sent the response. As the HTTP connection works through these five connection states, the value contained in the readyState property changes. This causes the function you define in the onreadystatechange property to trigger for each state change. When the readyState property contains a value of 4, the final result from the request is available for processing. When the readyState property value is 4, you know the communication is complete, but you don’t know how it turned out. To determine that, you check the HTTP response returned by the web server using the status property. If the status property contains the 200 numeric HTTP result code, that indicates the connection was successful, and any data returned by the web server is available in the responseText and responseXML properties. If the status property contains some other HTTP result code (such as 403 or 404), that indicates there was an error communicating with the web server. Because these values are standard, it has become somewhat common practice to start out the onreadystatechange callback function code checking for them: con.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { var result = this.responseText; } }; The function only retrieves the data when the connection is complete and has returned valid data. This method of defining the callback function inline is referred to as creating an anonymous callback function, because you don’t define a name for the function. It only exists inside the onreadystatechange property, so you can’t reference it anywhere else in your JavaScript code. Although using an anonymous function is a popular way of defining the callback function, you can define the function as a standard named JavaScript function and then reference that function name in the onreadystatechange property.