General Programming & Web Design Articles

Article / Updated 06-06-2023

The term DevOps (a combination of software development and operations) refers to a set of practices, tools, and cultural philosophy that automate and integrate the work of software development and IT teams. Marrying the cloud with your DevOps practice can accelerate the work you’ve already accomplished. When used together, both DevOps and the cloud can drive your company’s digital transformation. You’ll see results as long as you emphasize the priorities of DevOps: people, process, and technology. The cloud — along with other tooling — falls squarely into the technical part of your DevOps implementation. Cloud computing enables automation for your developers and operations folks in a way that simply isn’t possible when you manage your own physical infrastructure. Provisioning infrastructure through code in the cloud — which is a system referred to as Infrastructure as Code (IaC) — enables you to create templates and repeatable processes. When you track changes to your infrastructure code through source control, you permit your team to operate seamlessly and track changes. IaC is much more repeatable and automated — not to mention faster — than having engineers click around a portal. Even instructions on the portal aren’t fool-proof. You risk making small, yet significant, changes to infrastructure setup if you consistently build the same setup through the portal rather than a YAML file. Taking your DevOps culture to the cloud People often speak about DevOps and cloud computing as if they are intertwined and, in many ways, they are. Be aware, however, that you can adopt DevOps — or begin to transform your engineering organization — without going all in on the cloud. It’s perfectly reasonable that you first establish the standards, practices, and processes for your team before you shift your infrastructure to a cloud provider. Although people speak as though everyone is already on the cloud, you are still on the cutting edge of the shift to the cloud. Cloud providers are becoming more robust by the day, and engineering companies are slowly transitioning their self-hosted services to the cloud. With that in mind, an organization seeking to adopt DevOps would be wise to strongly consider utilizing the services of a major cloud provider. Anyone with DevOps experience wouldn’t likely call the cloud a NoOps solution, but they might call it OpsLite. Cloud services often abstract complex operations architecture in a way that makes that architecture more friendly to developers and empowers them to take more ownership of their components. If you’ve ever grumbled that developers should be included in an on-call rotation, you’re right — they should be. Including developers in the on-call rotation is a great way to ramp up their knowledge of deploying code as well as managing and provisioning the infrastructure on which their services run. This reduces operational overhead and frees up the time of operations specialists to work on proactive solutions. Learning through DevOps adoption If your team is capable of adopting DevOps and shifting toward utilizing cloud computing at the same time, you can use these shifts as learning opportunities for both developers and operations folks. While your team shifts to the cloud, developers have the opportunity to familiarize operations specialists with code — perhaps even specific languages — and source control, and operations folks can teach developers about infrastructure. When both groups are both the experts and the newbies, neither group has to deal much of an ego-damaging transfer of knowledge. The trust, rapport, and healthy dynamic that emerge from these interactions will galvanize your team and last much longer than the immediate work took. In many ways, you’re reinforcing your DevOps culture through tooling your DevOps practice. Benefitting from cloud services in your DevOps initiative Modern operations is changing and evolving. Your competitors are already adopting new ways of innovating faster and accelerating their software delivery life cycles. Cloud computing represents a big shift from the traditional way businesses think about IT resources. By outsourcing much of your infrastructure and operations requirements to a cloud provider, you reduce overhead and free your team to focus on delivering better software to your users. Here are six common reasons organizations are turning to cloud computing services: Improving affordability. Cloud providers allow you to select only the services you need, when you need them. Imagine if you could access cable TV but pay for only the channels you watch. You’d love that, wouldn’t you? Most DevOps team members would! Cloud providers do just that while also providing you with the most up-to-date computing hardware housed in physically secure datacenters. Automating deployments. Changes to the system — deployments — are the most common contributors of outages or service disruptions. Cloud providers make releasing code an automated, repeatable process, significantly decreasing the probability of making mistakes in manual releases and introducing bugs. Automated deployments also enables developers to release their own code. Ultimately, automated deployments simplify the process while reducing site downtime and reactionary triaging in production. Accelerating delivery. The cloud reduces friction along nearly every phase of the software delivery life cycle. Although set up is required, it often takes no more than double the time required to do the process manually, and you have to set up a service or process only once. Accelerated delivery gives you a ton of flexibility. Increasing security. Cloud providers make security part of their offering. Microsoft Azure, Amazon web Services (AWS), and Google Cloud Platform (GCP) meet different compliance standards and provide policies, services, and controls that will help you reinforce your system’s security. In addition, if you utilize a deployment pipeline tool within the cloud, you can add security checks before new code is released to an environment, thereby reducing the possibility of security vulnerabilities. Decreasing failure. Through cloud build and release pipelines, your team is capable of creating automated tests to confirm functionality, code quality, security, and compliance of any code introduced into your systems. This capability decreases the possibility of bugs while also reducing the risk of problematic deployments. Building more resilient and scalable systems. The cloud allows organizations to scale up, scale out, and increase capacity within seconds. This elastic scaling enables spinning up compute and storage resources as needed, no matter where in the world your users interact with your product. This approach permits you to better serve your customers and more efficiently manage infrastructure costs. The DevOps approach is all about creating a cyclical method where you benefit and learn from the process each time you go through it.

Article / Updated 04-17-2023

Improving engineering performance as part of the DevOps process can have sweeping impacts on the entire business. Streamlining the development life cycle and removing bottlenecks will serve to accelerate the overall performance of the business — ultimately increasing the bottom line. And if you think, as a DevOps engineer, that you shouldn’t have to care about the business performance, you’re wrong. According to DevOps Research and Assessment (DORA), high-performing DevOps teams consistently outpace their competitors in four key areas: Deployment frequency: This term refers to how often your engineers can deploy code. Improving performance aligns with deploying multiple times per day as desired. Lead time: Lead time is how long you take to go from committing new code to running that code in a production environment. The highest performers, according to DORA, have a lead time of under an hour, whereas average performers need up to a month. MTTR (Mean Time to Recover): MTTR refers to how long you take to restore a service after an incident or outage occurs. Ideally, you want to aim for under an hour. An outage costs serious money, especially when it impacts profit centers of the application. Long outages destroy trust, decrease morale, and imply additional organizational challenges. Change failure: This term refers to the rate at which changes to your system negatively impact the performance. Although you will never reach a change failure rate of zero percent, you can absolutely approach zero by increasing your automated tests and relying on a deployment pipeline with continuous integration checks and gates — all of which ensure quality. Eliminating perfection as a measure of DevOps success DevOps relies on the mantra “Done is better than perfect.” It seems to be one of these impossible-to-attribute quotations, but the words nonetheless speak truth. Attempting to attain perfection is an enemy of effectiveness and productivity. Most engineers, including those of the DevOps variety, suffer from some version of analysis-paralysis — a mental affliction that limits your productivity in an attempt to overanalyze your work and sidestep any potential mishap. Training imperfection into your work requires you to embrace the possibility of failure and the inevitability of refactoring. Creating feedback loops around the customer and looping back to various stages of the pipeline are primary tenants of DevOps. In DevOps, you’re connecting the ends to bend the line into a circle. When you think iteratively and circularly, pushing out code that’s not perfect seems a lot less scary because the code isn’t carved into stone. Instead, it’s in a temporary state that DevOps engineers improve frequently as you gather more data and feedback. Designing small teams for DevOps You’ve likely heard of Amazon’s “two-pizza” teams. The concept broadly speaks to the importance of small-sized teams. Now, the exact number of people that comprise a two-pizza team varies according to your appetites. It’s a good idea to keep teams under 12 people. When a group approaches 9, 10, or 11 people, try splitting it into two. The sweet spot for group size is around 4–6 people. Your exact number may vary depending on the people involved, but the point is this: When groups get too large, communication becomes challenging, cliques form, and the teamwork suffers. Here’s one other bonus goal when forming DevOps teams: even numbers. It’s a good idea to give people a “buddy” at work — someone they can trust above all others. In even-numbered groups, everyone has a buddy and no one is left out. You can pair off evenly and it tends to work well. Forming even-numbered groups isn’t always achievable because of personnel numbers, but it’s something to keep in mind. A formula for measuring communication channels is n (n – 1) / 2, where n represents the number of people. You can estimate how complex your team’s communication will be by doing a simple calculation. For example, the formula for a two-pizza team of 10 would be 10 (10 – 1) / 2 = 45 communication channels. You can imagine how complex larger teams can become. Tracking your DevOps work If you can get over the small overhead of jotting down what you do every day, the outcomes will provide you with exceptional value. Having real data on how you use your time assists you in tracking you and your team’s efficacy. As Peter Drucker famously said, “If you can't measure it, you can't improve it.” How many days do you leave work feeling like you did nothing? You just had meeting after meeting or random interruptions all day. You’re not alone. Many workers have the same problem. It can be difficult to track your progress and therefor your productivity. The divergence between our feelings of efficacy and the reality of our efficacy is dangerous territory for any DevOps team. Try using pen and paper rather than some automated tool for this. Yes, you can use software to track how you use your time on your computer. It can tell you when you’re reading email, when you’re slacking, and when you’re coding, but it lacks nuance and often misses or incorrectly categorizes large chunks of time. After you have an idea of what you’re doing and when, you can start to identify which activities fall into which quadrants of the Eisenhower Decision Matrix. What busy work are you doing routinely that provides no value to you or the organization? Reducing friction in DevOps projects One of the best things a manager can do for a DevOps engineering team is to leave them alone. Hire curious engineers who are capable of solving problems independently and then let them do their job. The more you can reduce the friction that slows their engineering work, the more effective your team will be. Reducing friction includes the friction that exists between teams — especially operations and development. Don’t forget specialists like security, too. Aligning goals and incentives increases velocity. If everyone is focused on achieving the same things, they can join together as a team and move methodically toward those goals. Humanizing alerting for DevOps success Every engineering team has alerts on actions or events that don’t matter. Having all those alerts desensitizes engineers to the truly important alerts. Many engineers have becomes conditioned to ignore email alerts because of an overabundance of messages. Alert fatigue ails many engineering organizations and comes at a high cost. If you’re inundated daily, picking out the important from a sea of the unimportant is impossible. You could even say that these messages are urgent but not important . . . . Email is not an ideal vehicle for alerting because it’s not time sensitive (many people check email only a few times a day) and it’s easily buried in other minutiae. Applying what you’ve learned about rapid iteration, reevaluate your alerting thresholds regularly to ensure an appropriate amount of coverage without too many false positives. Identifying which alerts aren’t necessary takes time and work. And it’ll probably be a little scary, right? Deleting an alert or increasing a threshold always comes with a bit of risk. What if the alert is actually important? If it is, you’ll figure it out. Remember, you can’t fear failure in a DevOps organization. You must embrace it so that you can push forward and continuously improve. If you let fear guide your decisions, you stagnate — as an engineer and as an organization.

Cheat Sheet / Updated 02-10-2023

When you first log in to GitHub.com, it can feel overwhelming. What is GitHub? GitHub is more than a place to store your code; it’s a community and a philosophy about how code should be written. When you’re first learning and navigating the website, you should always remember that the goal of GitHub is to provide a secure, collaborative environment where newcomers and experts alike can design, develop, and deploy any software, from programs that say “Hello World” to code that sequences human proteins to help cure major infectious diseases around the world. To be a part of this community, you just have to be an effective communicator, find and create collaborative projects, and know how to find the help you need, when you need it.

Article / Updated 07-29-2022

When done correctly, DevOps offers significant advantages for your organization. This article presents the key points to know about how DevOps benefits your organization. Use it as a reference to help you persuade your colleagues or to reinforce your understanding of why you chose to go the DevOps route when the road gets bumpy. DevOps helps you accept constant change The tech landscape is an ever-changing environment. Some languages evolve and new ones are created. Frameworks come and go. Infrastructure tooling changes to meet the ever-growing demands for hosting applications more efficiently and delivering services more quickly. Tools continue to abstract low-level computing to reduce engineering overhead. The only constant is change. Your ability to adapt to that change will determine your success as an individual contributor, manager, or executive. Regardless of the role you currently fill at your company or hope to eventually play, it is vital to adapt quickly and remove as much friction from growth as possible. DevOps enables you to adapt and grow by improving communication and collaboration. DevOps embraces the cloud The cloud isn’t the future; it’s now. Although you may still be transitioning or not yet ready to move, realize that the cloud is the way forward for all but a few companies. It gives you more flexibility than traditional infrastructure, lowers the stress of operations, and (usually) costs significantly less because of a pay-as-you-go pricing structure. Public, private, and hybrid clouds give you endless possibilities to run your business better. The ability to spin up (launch) resources within minutes is something most companies have never experienced prior to the cloud. This agility provided by the cloud goes hand in hand with DevOps. Omri Gazitt from Puppet, a company focused on automation and configuration management, put it best: “As organizations move to the cloud, they are revisiting their core assumptions about how they deliver software.” With the cloud, APIs connect every service, platform, and infrastructure tool so that you can manage your resources and application seamlessly. As you migrate to the cloud, you can reevaluate past architecture decisions and slowly transition your application and system to be cloud-native, or designed with the cloud in mind. DevOps helps you hire the best Because of increased demand, great engineers are scarce. There simply aren’t enough engineers to fill all the jobs currently open or to meet market demand over the next decade and beyond. Although finding engineers can be difficult, it’s not impossible, especially if you focus on discovering engineers who embrace curiosity and aren’t afraid to fail. If you implement DevOps in your overall engineering culture, you can level up engineers and train them in the methodology and technology that supports continuous improvement. It’s difficult to measure potential in an interview. Usually, talent whispers. The most talented engineers typically aren’t gregarious or braggarts; they let their work speak for them. DevOps enables you to listen more closely to the personal and professional interests of the engineers you interview. Try choosing candidates based on their level of curiosity, communication skills, and enthusiasm. Those qualities can see your team through the troughs of fear, uncertainty, and doubt. They can carry the team through hard decisions, made within constraints, in their attempt to solve difficult problems. You can teach someone a skill, but teaching someone how to learn is an entirely different matter. The learning culture you create in your DevOps organization enables you to prioritize a growth mindset over technical prowess. In DevOps, hiring for the team is critical. Every individual is a piece of a whole, and the team must have balance holistically. Achieving this balance means that sometimes you don’t hire the “best” engineer, you hire the best engineer for the team. When you hire for the DevOps team you can, like draft horses yoked together, pull more weight than you could individually. With DevOps, you can multiply the individual components of your team and, as a whole, create a powerhouse of a team. DevOps keeps you competitive The yearly State of DevOps Report released by DevOps Research and Assessment (DORA) makes it clear: Companies across the world are using DevOps to adjust their engineering practices and are reaping the benefits. They see increases in engineering production and reductions in cost. With DevOps, these companies are shifting from clunky processes and systems to a streamlined way of developing software focused on the end user. DevOps enables companies to create reliable infrastructure and utilize that infrastructure to release software more quickly and more reliably. The bottom line is this: High-performing organizations use DevOps, and they’re crushing their competition by increasing their deployment frequency and significantly decreasing their failures that occur because of changes in the system. If you want to compete, you must adopt the solid DevOps methodologies. Maybe not all of them, and definitely not all at one time — but the time to wait and see whether DevOps is worthwhile has passed. DevOps helps solve human problems Humans have reached a point in our evolution at which technology is evolving faster than our brains. Thus the greatest challenges humans face are due to human limitations — not the limitations of software or infrastructure. Unlike other software development methodologies, DevOps focuses holistically on your sociotechnical system. Embracing DevOps requires a shift in culture and mindset. But if you achieve a DevOps culture and mindset, you and your organization reap almost limitless benefits. When engineers are empowered to explore, free of the pressure and fear of failure, amazing things happen. Engineers discover new ways to solve problems. They approach projects and problems with a healthy mindset and work together more fluidly, without needless and negative competition. DevOps challenges employees DevOps accelerates the growth of individual engineers as well as that of the engineering team as a whole. Engineers are smart people. They’re also naturally curious. A great engineer who embraces a growth mindset needs new challenges after mastering a particular technology, tool, or methodology or they often feel stagnant. They need to feel as if their brain and skill sets are being stretched — not to the point of being overwhelmed or stressed, but enough to feel that they’re growing. That is the tension described by Dan Pink in Drive. If you can strike that balance, your engineers will thrive — as individuals and as a team. The methodology of DevOps promotes T-shaped skills, which means that engineers specialize in one area with deep knowledge and have a broad understanding of many other areas. This approach allows engineers to explore other areas of interest. Perhaps a Python engineer has an interest in cloud infrastructure, for example. No other engineering methodology permits and encourages engineers to explore as much as DevOps does, and it’s a huge contributor to hiring and retaining talent. DevOps bridges gaps One of challenges of modern technology companies is this gap between the needs of the business and the needs of engineering. In a traditional company, with traditional management strategies, a natural friction exists between engineering and departments like marketing, sales, and business development. This friction stems from a lack of alignment. Each department is measured by different indicators of success. DevOps seeks to unify each department of a business and create a shared understanding and respect. That respect for each other’s jobs and contributions is what allows every person in the company to thrive. It removes the friction and improves acceleration. Think about a team of sled dogs. If each dog is moving in separate directions, the sled goes nowhere. Now imagine the dogs working together, focused on moving forward — together. When you lack friction internally, the only challenges you face are external, and external challenges are almost always more manageable than internal strife. DevOps lets you fail well Failure is inevitable. It’s simply unavoidable. Predicting every way in which your system can fail is impossible because of all the unknowns. (And it can fail spectacularly, can’t it?) Instead of avoiding failure at all costs and feeling crushed when failure does occur, you can prepare for it. DevOps prepares organizations to respond to failure, but not in a panicky, stress-induced way. Incidents will always involve some level of stress. At some point along your command structure, an executive is likely to scream at the money being lost during a service outage. But you can reduce the stress your team experiences by using failure as a way of learning and adapting your system to become more resilient. Each incident is an opportunity to improve and grow, as individuals and as a team. DevOps embraces kaizen, the art of continuous improvement. When your team experiences flow in their work, they can make tiny choices every day that contribute to long-term growth and, ultimately, a better product. DevOps lets you continuously improve Continuous improvement is a key ingredient in DevOps. Use the visualization of a never-ending cycle when applying DevOps to your organization. The cycle shouldn’t invoke fears through thoughts of Sisyphus, pushing a boulder up a hill for all eternity. Instead, think of this cycle as movement, like a snowball rolling downhill, gathering momentum and mass. As you adopt DevOps and integrate more and more of its core tenets into your everyday workflow, you’ll witness this acceleration first-hand. The cycle of continuous improvement should always center around the customer. You must continuously think about the end user and integrate feedback into your software delivery life cycle. Fundamental to this cycle is CI/CD. Adopting CI/CD isn’t an all-or-nothing requirement of DevOps; instead, it’s a slow process of implementation. You should focus on mastering continuous integration first. Encourage engineers to share code freely and merge code frequently. This approach prevents isolation and silos from becoming blockers in your engineering organization. After your organization masters continuous integration, move on to continuous delivery, the practice of automating software delivery. This step requires automation because code will move through multiple checks to ensure quality. After all your code is secure and accessible in a source code repository, you can begin to implement small changes continuously. Your goal is to remove manual barriers and improve your team’s ability to discover and fix bugs without customer impact. DevOps automates toil Acceleration and increased efficacy are at the core of the DevOps methodology. By automating labor-intensive manual processes, DevOps frees engineers to work on projects that make the software and systems more reliable and easily maintained — without the chaos of unexpected service interruptions. Site reliability engineering (SRE) deals with toil, which is the work required to keep services up and running but is manual and repetitive. Toil can be automated and lacks long-term value. Perhaps most important of all, toil scales linearly, which limits growth. Note that toil doesn’t refer to the overhead of administrative necessities such as meetings and planning. This type of work, if implemented with a DevOps mentality, is beneficial to the long-term acceleration of your team. One of the core tenets of tooling your DevOps practice is automation. You can automate your deployment pipeline to include a verbose test suite as well as other gates through which code must pass to be released. In many ways, SRE is the next logical step in the evolution of DevOps and should be your next step after you and your organization master the core concepts of DevOps and implement the practice in your team. DevOps accelerates delivery The software delivery life cycle has evolved from the slow and linear Waterfall process to an agile and continuous loop of DevOps. You no longer think up a product, develop it fully, and then release it to customers, hoping for its success. Instead, you create a feedback loop around the customer and continuously deliver iterative changes to your products. This connected circuit enables you to continuously improve your features and ensure that the customer is satisfied with what you’re delivering. When you connect all the dots and fully adopt DevOps in your organization, you watch as your team can deliver better software faster. The changes will be small at first, just like the changes you release. But over time, those seemingly insignificant changes add up and create a team that accelerates its delivery of quality software.

Article / Updated 05-31-2022

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 </span> tags, you’re bound to find coding issues that completely baffle and stump you. For instance, if you get an error message that reads <span class="code">XML Parsing Error: Opening and ending tag mismatch: br line 52 and body</span>, 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 <span class="code"><br /></span> 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. <table> <tbody> <tr> <th>Problem</th> <th>Solution</th> </tr> <tr> <td> <pre class="code">alt</pre> text attribute missing from <pre class="code">&lt;img&gt;</pre> tag</td> <td>Add the alternative text attribute, either with or without a description, as in <pre class="code">&lt;img src="images/logo.gif" width="150" height="150" alt="Pete’s Pizza"&gt; &lt;img src="images/flourish.gif" width="200" height="150" alt=""&gt;</pre> .</td> </tr> <tr> <td> <pre class="code">&lt;noscript&gt;</pre> tags missing from code</td> <td>Add <pre class="code">&lt;noscript&gt;</pre> 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 <pre class="code">&lt;noscript&gt;</pre> 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: <pre class="code">&lt;script language="JavaScript" src="bookmark.js" type="text/javascript"&gt;&lt;/script&gt;&lt;noscript&gt;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.&lt;/noscript&gt;</pre> </td> </tr> <tr> <td>Flashing or flickering element(s) detected, such as animated GIFs, Java applets, and other multimedia plug-ins</td> <td>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.</td> </tr> <tr> <td>No <pre class="code">DOCTYPE</pre> specified</td> <td>Add a valid <pre class="code">DOCTYPE</pre> above the opening <pre class="code">&lt;head&gt;</pre> tag.</td> </tr> <tr> <td>No HTTP charset parameter specified</td> <td>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: <pre class="code">&lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"&gt;</pre> . For HTML5, insert <pre class="code">&lt;meta charset="utf-8"&gt;</pre> .</td> </tr> <tr> <td>No <pre class="code">&lt;title&gt;</pre> tag specified</td> <td>Add a unique title between <pre class="code">&lt;title&gt;</pre> tags in the head area on each page.</td> </tr> <tr> <td>No <pre class="code">&lt;meta&gt;</pre> tags specified</td> <td>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.</td> </tr> <tr> <td>No Robots tags specified</td> <td>Add the <pre class="code">Robots</pre> <pre class="code">&lt;meta&gt;</pre> tag in the head of the page to instruct web spiders and robots whether to index the page and follow any hyperlinks, such as <pre class="code">&lt;meta name="Robots" content="All"&gt;</pre> .</td> </tr> <tr> <td>Deprecated <pre class="code">&lt;font&gt;</pre> tags detected</td> <td>Move all the presentation markup of the HTML (page, fonts, tables, links, and so on) to an external CSS file and remove all <pre class="code">&lt;font&gt;</pre> tags and HTML and inline formatting attributes.</td> </tr> <tr> <td>Deprecated table height attribute detected</td> <td>Control table cell heights, when necessary, with CSS styles.</td> </tr> <tr> <td>Style attributes detected in the opening <pre class="code">&lt;body&gt;</pre> tag</td> <td>Move <span class="code">body</span> attributes, like margin attributes and background page color, to a BODY tag redefine style in an external CSS file.</td> </tr> <tr> <td> <pre class="code">type</pre> attribute not specified for JavaScript or CSS</td> <td>Add the <pre class="code">type="text/css"</pre> attribute for <pre class="code">&lt;style&gt;</pre> tags and the <pre class="code">type="text/javascript"</pre> attribute for <pre class="code">&lt;script&gt;</pre> tags: <pre class="code">&lt;style type="text/css" &gt;&lt;script type="text/javascript"&gt;</pre> .</td> </tr> <tr> <td>Entity name used instead of entity number</td> <td>Change the entity name to an entity number, such as using <pre class="code">$#169;</pre> instead of <pre class="code">&copy;</pre> to create the copyright symbol (c).</td> </tr> <tr> <td>No background color attribute was specified for a CSS style that specifies text color</td> <td>Provide each style that contains a text <pre class="code">color</pre> attribute with an attending background <pre class="code">color</pre> attribute. The background color should match, or closely match, the background color upon which the text will display on.</td> </tr> </tbody> </table> 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.

Cheat Sheet / Updated 05-03-2022

If you're just getting started writing computer programs, you need to learn programming branching and looping statements to perform the specific jobs you need for an effective program. Keeping a list of computer programming resources for useful information handy can help, too.

Cheat Sheet / Updated 04-20-2022

The terms virtual reality and augmented reality (and others, like mixed reality and extended reality) are thrown about everywhere today, but do you really know what they mean? Virtual and augmented reality are rapidly changing fields, so it helps to know where they are today and where they may be headed in the future. Finally, seeing how virtual and augmented reality are being used in a variety of industries and how exactly you can experience these technologies is key to your enjoyment.

Cheat Sheet / Updated 04-20-2022

Working with PHP, MySQL, and JavaScript to create dynamic web applications can be difficult, but if you know a few programming tricks, you can make that job a lot easier. This Cheat Sheet shows you how to extract data from different databases in your PHP programs, filter out unwanted or potentially dangerous data from web forms, quickly find data stored in your MySQL database, and trigger timed events in your JavaScript programs.

Cheat Sheet / Updated 03-02-2022

A surprising facet of the DevOps engineering practice for software development is that it focuses more on the people and process of an organization than the specific tools or technologies that the engineers choose to utilize. DevOps offers no silver bullet, but it can have a massive impact on your organization and your products as an engineering culture of collaboration, ownership, and learning with the purpose of accelerating the software development lifecycle from ideation to production.

Cheat Sheet / Updated 02-15-2022

Create web documents and websites by knowing basic HTML elements, PHP statements and functions, and more. Become familiar with these special programming languages, which you can use to build dynamic websites that work with the MySQL database.