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 05-03-2023

To assign a font family to part of your page, use some new CSS. As an example, this page has the heading set to Comic Sans MS. If this page is viewed on a Windows machine, it generally displays the font correctly because Comic Sans MS is installed with most versions of Windows. If you're on another type of machine, you may get something else. Look at the simple case. Here's the code: <!DOCTYPE html> <html lang = "en-US"> <head> <meta charset = "UTF-8"> <title>comicHead.html</title> <style type = "text/css"> h1 { font-family: "Comic Sans MS"; } </style> </head> <body> <h1>This is a heading</h1> <p> This is ordinary text. </p> </body> </html> The secret to this page is the CSS attribute. Like most CSS elements, this can be applied to any HTML tag on your page. In this particular case, it was applied it to the level one heading. h1 { font-family: "Comic Sans MS"; } You can then attach any font name you wish, and the browser attempts to use that font to display the element. Even though a font may work perfectly fine on your computer, it may not work if that font isn't installed on the user's machine. If you run exactly the same page on an iPad, you might see this result. The specific font Comic Sans MS is installed on Windows machines, but the MS stands for Microsoft. This font isn't always installed on Linux or Mac. (Sometimes it's there, and sometimes it isn't.) You can't count on users having any particular fonts installed. The Comic Sans font is fine for an example, but it has been heavily over-used in web development. Serious web developers avoid using it in real applications because it tends to make your page look amateurish.

Cheat Sheet / Updated 04-20-2023

Whether you are new to building websites or a web professional who is new to Squarespace, choosing Squarespace to build your site is a wise decision. An overview of the different editing modes in Squarespace can help you figure out where to go in your Squarespace site to perform a certain task. Even a basic task can sometimes turn into a huge hurdle, however, which is why it's important to know where you can go to find help. And if you already have your own domain name, find out how you can update your domain's DNS settings to point it to your site on Squarespace.

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 04-14-2023

Programming with JavaScript isn't fundamentally about memorizing syntax or knowing every function available in a library or framework. If you know and understand the basics, you can look up everything else easily enough. However, if you learn a wide variety of tools, you'll understand how libraries and frameworks are constantly improving on what's been done before, and you'll gain an appreciation for why change is so important in the JavaScript world.

Cheat Sheet / Updated 03-09-2023

All blogs start in the same way: A person picks a blogging application, creates a blog, and publishes a post online. What happens then depends on each individual blogger. This Cheat Sheet supplements the information provided in Blogging All-in-One For Dummies, 3rd Edition and helps you find resources and tools to make your blog a unique place that allows you to reach your goals.

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.

Cheat Sheet / Updated 01-11-2023

Writing Java statements (like for and if) and classes (like Math and NumberFormat) help you start and build strong programs. Variables hold different kinds of Java data types: numbers, characters, and true/false numbers. You designate Java operations that can be performed on operands, including arithmetic operators, relational operators (or binary) and logical operators (or Boolean).

Cheat Sheet / Updated 01-11-2023

R provides a wide array of functions to help you with your work — from simple statistics to complex analyses. This Cheat Sheet is a handy reference for Base R statistical functions, interactive applications, machine learning, databases, and images.

Cheat Sheet / Updated 11-14-2022

Coding, or computer programming, is your way of communicating with technology. It’s the new literacy you need to master to be successful in the coming decades. Like any form of communication, coding takes place through language. Just as there are many human languages (English, French, Mandarin, Spanish, and so on), there are many coding languages! Two examples of coding languages are Scratch and JavaScript. Scratch is perfect as a coding language for kids because it’s easy and fun to use, Scratch coding for kids allows you to build programs by snapping together commands in the same way you assemble a puzzle. JavaScript is a step up in difficulty because it’s an authentic programming language, used by real coders. JavaScript powers many technologies, and you can use it to make both apps for your phone and control code for operating electronics gadgets. You can ease into JavaScript by using blocks to build programs (just like Scratch) and then switching to text-based coding when you’re ready. Here, discover tips for creating programs in Scratch, coding JavaScript apps in App Lab, and writing JavaScript code in MakeCode to operate the micro:bit electronics board.