I would like you to write an article that mimics the tone, style, grammar and voice of some example articles I will provide.

Here are the articles to analyze and emulate:

<articles_to_emulate>

<article_1>
# What is a computer?. The basics of Computer Science: part… | by Dan Quine | The basics of Computer Science | Medium
In the first part of this series, I asked the question “What is a computer?” It seems like a simple question with a simple answer. I am typing this on a computer; it has a screen and a keyboard, and inside are the CPU, the RAM, a hard drive and some other fancy electronics.

As H.L. Mencken would no doubt have said, this answer is neat, plausible, and also wrong. Understanding the more complex truth reveals the most fundamental theory in Computer Science.

What machines can do
--------------------

A Falcon 9 rocket, abjectly failing to sew a decorative doily. Credit: NASA

Machines do one thing. A sewing machine stitches together fabrics of various kinds, but can’t launch satellites into geo-synchronous orbit. On the other hand, a Falcon 9 would do a terrible job of Picot Edging.

Computers are different. They can perform a breathtaking range of tasks. The same machine that allows me to video conference with my friends on the other side of the world can also calculate my taxes, play a mean game of Angry Birds and compose music.

Universal machines
------------------

Computers are a special type of machine called a **universal machine**. They can run programs that do almost anything. The same computer can be programmed to control a sewing machine or fly a rocket. What a universal machine does is determined by the instructions the machine is given, not by the machine itself.

When a computer runs a program, it stops being a universal machine that can do any task and turns into a specific machine that performs the task defined by the program. The program itself is a machine in the traditional sense.

One of the specific types of machine that can be defined using a program is a universal machine. So I can create a program that itself runs programs. Most importantly, a universal machine that is defined purely by a program can ran _exactly_ the same programs as a hardware computer.

Alan Turing
-----------

All this was discovered by Alan Turing. He was the brilliant British code breaker and scientist who formulated the **Church-Turing Thesis**. While the mathematics behind the thesis is formidable, the basic idea is fairly easy to understand.

Turing demonstrated three important conclusions:

*   There is a small but important class of problems that can never be solved by a program — these are called the non-computable tasks, everything else is a computable task.
*   Any machine that can run certain basic operations can be programmed to perform any computable task. These basic operations are loops, logic and variables.
*   Running a universal machine _is_ a computable task.

One of the most remarkable aspects of Turing’s work is he published it in 1936, almost a decade before the first computer system was built.

What does this all mean?
------------------------

Computers are a special class of machine that can be programmed to do almost anything, in particular the can be programmed to run a universal machine. From a program’s perspective, running on a programmed universal machine is _exactly_ the same as running on a physical one.

All of modern computing is built on this idea.

For example, when you use your web browser, you are actually running dozens of different software computers, each layered on the one below. The browser is a computer, which is probably built in the C++ programming language, which uses an operating system, which runs in a virtual machine, which runs another operating system, which is built in another programming language, which translates code down to an assembly language, which runs on the instruction set of your hardware; and there are more layers in between these. Each of these layers is a universal machine: a computer.

In computing, it really is turtles all the way down. Credit: wikimedia

Each layer abstracts away the complexity of the layers below. This means that programmers can build immensely complex systems without having to specify every detail of how they work. I can write code that pulls information from a computer on the other side of the world, without needing to know how that other computer works or how the data is transferred across the network to my machine. All that complexity is hidden from me.

This is the heart of computer science. A computer is not a physical device. A computer is a universal machine and can exist purely as software. Almost all of the computers currently in existence are software not hardware machines. Because software machines are precisely as powerful as hardware ones, I can continually add new computer layers to the stack and make ever more powerful systems possible.

Next steps
----------

That’s it from me. This short series on the Basics of Computer Science has, I hope, introduced you to some of the core ideas that make computers and programming so powerful. There is, of course, much, much more to explore, this is just a taster.

If there is one thing you remember, it should be Turing’s idea of a universal machine. This is what make computers different from all other machines. We have only just set out on the journey towards controlling our world through software. The next decades will see the fastest transformation of human abilities in history, as access to knowledge and computation spreads into everyone’s hands. I hope you are excited by that prospect; I am.</article_1>

<article_2>
# The mindset of the software developer | by Dan Quine | Medium
Songkick developers. What is going on inside their heads?

How developers think
--------------------
!Dan Quine
Dan Quine

**Disclaimer**: every software developer is of course completely unique; each one thinks in a very different way about the world. I have included this disclaimer because every developer believes this to be true.

That said, many developers think about the world in similar ways. Here are some of them.

Take it apart to see how it works
---------------------------------

Developers have an endless fascination with how things work. Every time they look at a system, they wonder — how is that done? How could I make one? How can I make it better? They want to take it apart to see what makes it tick.

This applies to software, but also to vehicles, radios, lamps, the lifts in your building and, if you are really lucky, a dead cat.

What happens when you give a developer a new digital camera (photo: Steve Jurvetson)

Solve problems
--------------

Developing software is all about problem solving. Writing code is only a tiny part of what developers do — most of the work involves solving some really complex abstract problems.

Developers are fascinated with problems of all sorts, so you’ll often find them solving crossword puzzles, playing Tetris or out geocaching.

Decompose
---------

Driven by the need to understand how things work, a key feature of the developer‘s toolset is reducing a thing into its smallest components. Small things are easier to understand and build. Once you have a set of components, the can be assembled back into the original thing, or into something completely new.

The formal term for this is **decomposition** — breaking something down into its components, which in turn can be broken down into smaller components and so on, until you are down to the simplest possible units.

You’ll often find developers arguing about the best way to decompose an object. In the real world, the ways to break down an object are constrained. In the virtual world where you are not subject to the laws of nature, there will be many different ways to break an object down into logical components.

Automate
--------

Developers are lazy, but in a very special and specific way. If you ask them to do something twice, they’ll immediately want to build a program to do the repetitive task for them. They have a very short attention span for things they have done before, and are quite happy to spend days writing code to avoid redoing a 5 minute task.

This is not always a good idea:

Randall Munroe’s take on the obsession with automation

Compose
-------

Developers love to pull things apart and to automate tasks, both of which result in small units of code that do useful things. The next step is to arrange these into larger blocks that do new, interesting things. This is **composition** and a lot of the craft of software engineering is how best to compose components into a working, reliable system.

You’ll hear a lot of talk about **architectures**: how the pieces fit together into a sensible whole. These high-level structures can help developers build large, complex systems in a manageable way.

Generalize
----------

Developers love to **generalize** — take some code that does one specific thing and turn it into a Swiss Army Knife that can do many different variants of that thing. This can be a useful instinct — you don’t want a hundred slightly different bits of code that do almost, but not quite, the same thing.

But, over-generalization is dangerous. You can end up with code that tries to do so many different things that it fails to do any of them well. This sort of code tends to be extremely complex as it tries to handle a vast number of edge cases. The skill is knowing when generalizing saves you time and complexity, and when it goes too far. Developers are always trying to find that dividing line.

Twain, as always, has a pertinent quote

Abstract
--------

**Abstraction** is a key idea in computer science. It is a way of hiding the details of _how_ something works, so other developers only needs to know _what_ it does. This idea is crucial to building large systems.

Developers are intrigued by abstraction and like to use it outside the world of programming. This is one of the reasons they love to categorise everything — music, art, railways, philosophy, types of short-haired dogs. Once you have a coherent category, you have an abstraction that allows you to talk about the world in short-hand.

Craft
-----

Software development is a craft, and developers take huge pride in their work. The feeling of shipping a great product is similar to the feeling that a painter might get from exhibiting their work, or a carpenter might feel at completing a new table.

Great developers get very frustrated if they are forced to produce shabby work.

The artisan’s workbench. It can be a little messy, but the end results are spectacular (Photo: Alan Cleaver)

Stack mind
----------

The **stack**) is a technical concept that pervades computing. It is a type of data storage that has just two operations: add an item to the top of the stack or remove the item at the top. This is useful in a wide variety of situations: many programming languages and operating systems make extensive use of stacks internally.

Most programming languages use a _call stack_ to control how data is stored when a piece of code calls another piece of code. The memory used by the first piece of code is pushed onto the stack before the second piece of code is run. When the second piece of code has finished, you can just pull the state of the first code block from the top of the stack and it can pick up where it left off.

As a developer your mind has to work like a call stack. You’re working on one bit of code, then find you need to change one of the components it uses. So you switch your focus over to thinking about how the component works. All the stuff you were holding in your head has to be remembered, so you can return to that “mental context” when you have finished working on the component and need to pick up work on the original code.

This switching between mental contexts uses your own mind as a _stack_. If you’ve ever seen the film Inception, you’ll have an idea of the mental gymnastics required to do this well as you go down through multiple levels of code. Developers get very good at pushing one mental context aside, working on another and then returning to their previous context. It is a skill that takes time to learn to do well.

Holding everything in your mind
-------------------------------

Writing software requires _intense_ concentration, because you need to hold details of the entire system in your head. You have to understand the ramifications of each change you make on all the other inter-connected bits of the code.

Developers hate interruptions and context switching, especially big ones. The act of “loading” your brain with the information needed to be effective on a project is significant. Moving from one project to another requires you to drop all that carefully assembled information and load up a new context. This can take days or weeks to do.

Developers get into a “zone” where they are completely focused on a task and have a lot of short-term information organized in their minds. If they get interrupted, they will drop out of their zone. Getting back in is painful and time consuming. That is why scheduling meetings every half an hour is incredibly disruptive to a developer because it forces them to constant drop and reacquire the mental context they need to work.

_Yes, this sort of contradicts the stack mind. But context switching to different part of the same codebase is less painful than switching out of coding entirely. Developers have to learn how to have a stack mind to be effective; its hard enough, so don’t make it worse by imposing yet more context switching._

Continually improve
-------------------

Great developers love to **learn** and improve. They are constantly honing their tools and skills. They are _polyglot programmers_, which means they know a number of different programming languages and are always interested in learning new ones. They know — and have strong opinions about — a large number of frameworks and libraries. They have an insatiable appetite for new and interesting ways to think about the world.

The mind of a developer
-----------------------

These are a few of the ways that developers think about the world. Glib disclaimers aside every one is indeed different, but I suspect devs will recognize at least some of themselves in this post. I used to be a developer myself, and I know at lot of my way of thinking is here.</article_2>

<article_3>
# Why Continuous Deployment matters to business | by Dan Quine | Continuous Delivery | Medium
Songkick’s Kanban board for tracking the continuous flow of work — we’ve since switched to using Trello
!Dan Quine
Dan Quine


!Continuous Delivery
Continuous Delivery

“Continuous Deployment” (**CD**) has become a hot topic amongst development teams recently. At Songkick, we moved to CD three years ago. It’s been a revelation for the development team, but what does it mean to the broader business?

What is Continuous Deployment?
------------------------------

Traditional software development — especially before the web — was organised around **releases**. You would work on a set of features, writing code and testing it until everything worked. Then you’d release all of these changes to your product in one go. Back when software was delivered on floppy disks or CD-ROMs, you might do 1 or 2 releases every year. Really fast companies released new versions every quarter.

It was a painful process for users to upgrade to the latest version. They had to get the software sent to them, in the post, then install it slow physical media. No-one wanted to do that every week. So releases were infrequent and were the result of months of work.

With the advent of the web, it became possible to update more frequently and usually automatically. Web software like Google Docs updates every now and again without you having to do anything. Nice.

When web software updates, users mind less if it updates more often. If you start releasing updates every month or every couple of weeks, each release becomes smaller. After all, you have less time to develop features if you only have two weeks rather than six months.

Doing lots of smaller, more frequent releases has a number of rather pleasant effects:

*   **Quality goes up** — because you are making smaller changes, each release is smaller and easier to test.
*   **It is easier for users to learn** — turns out people are quite good at dealing with small, frequent changes. They don’t like having to learn hundreds of new features all in one go; a steady feed of small changes is much easier to deal with.
*   **Faster development** — developers are more efficient working on smaller changes because they have less context that they need to hold in their heads while working. They can focus on one or two features, and not worry about how hundreds of different features interact.

Continuous Deployment takes this trend to its logical conclusion. Instead of trying to release sets of changes every couple of weeks, you aim to release multiple times per day. You break features down into the smallest possible chunks, and as soon as a chunk of code is finished, you deploy it onto your production systems and it is live before users.

At Songkick, we went from releases every 2–3 weeks to doing 10–15 releases every day.

Why is CD good for developers?
------------------------------

Continuous Deployment makes a huge difference for developers. Here are some of its effects:

*   **You develop even faster** — with CD there is much less overhead. As soon as your code is developed, your users are using it. If there is a bug, its in the code you just wrote, so you never have to stop what you are doing and go back to code that went live a week ago.
*   **Quality rises even further** — the emphasis on tiny changes means that if a bug occurs its very easy to find and fix — it has to be in that tiny change you just made.
*   **Tiny changes are good for users** — the changes are so small and frequent that they are often invisible to users. Their product just gets gradually better and better and they rarely have to stop and learn something new.

There’s a lot more to doing CD well, some of which I’ve talked about before, if you’re interested in the details.

Why is CD good for business?
----------------------------

With CD, productive developers deliver higher quality products to happy users. That sounds like a recipe for business success. It is. It really is.

But there are other business benefits of using CD:

*   **Flexibility**— because your development team is making constant small changes, its relatively easy to re-priortize what they are working on. You don’t have to wait for two weeks (or 6 months!) for the next release cycle, people can usually wrap their current tasks within a day and work on something else.
*   Of course, there are still switching costs. If I’m currently deep in writing highly-distributed Go microservices and you want me to work on a JavaScript client application feature, it will take me time to make the switch. But, if I’m currently working on a web app feature and you want me to focus on a different feature of the same app, I can do so quickly.
*   **Experimentation** — CD promotes a highly experimental approach. It is relatively easy to implement a proper A/B testing regime on top of CD. This allows you to quickly develop and deploy alternative versions of a feature and see which performs better with real users.
*   Your product strategy can now be data-driven. For many product questions, you no longer need to guess, you can just build a different version of a feature and see whether it improves your business metrics.
*   **Innovation** —A team that is used to quickly shipping experiments and getting back user-validated results fast, will soon find itself naturally innovating. The team will be constantly generating new ideas and testing them out.
*   These innovations start at the micro level, with the team experimenting with relatively small changes. But innovation is addictive and they will soon be coming up with bigger ideas that could make huge changes to your business.
*   **Costs become clear** — traditional software development suffers from many problems, but perhaps the biggest is that it’s impossible to accurately estimate how long a large release will take (which is why software is almost always late) and therefore it is almost impossible to understand the costs involved.
*   By breaking down large releases into a continuous flow of small changes, it becomes much easier to measure progress. The costs are exposed, rather than hidden. Also, smaller changes are easier to prioritize, so you are always working on the next most important task, which makes it easier to stop when you’ve reached the value you wanted.
*   You still can’t estimate how long a large project will take, but you can measures its costs and impact as you go, rather than waiting months or years for it to complete.

Continuous deployment is fundamentally changing how software is being built. It makes software development faster, leads to higher quality products and happier teams and customers. It gives you more visibility into progress and costs. It helps you be more innovative. Why wouldn’t you want all that?

Further reading
---------------

Interested in learning more about CD? Here are some good starting points:

*   Timothy Fitz’s “Continuous Deployment at IMVU”, one of the first descriptions of CD in practice
*   Chad Dickerson’s “How does Etsy manage development and operations?” — how Etsy does CD at scale. Another early and influential post.
*   Video of my presentation on “How Songkick Experiments” at LeanConf 2013</article_3>

</articles_to_emulate>

Please carefully read through these articles and make note of the key aspects of the writing such as:

- Overall tone and voice (e.g. casual, formal, humorous, scientific, etc.)
- Stylistic elements like sentence length, vocabulary level, use of idioms/slang/jargon
- Grammatical patterns and quirks
- How arguments and points are structured and presented
- Any other notable features of how the posts are written

The article I would like you to write should be on this topic:
<topic>what is computer network</topic>

Before writing the article, please brainstorm in a <scratchpad>:

- The key points you want to make in the article
- A rough outline of the article's sections
- Reminders of the main tone, style and voice elements to emulate
  </scratchpad>

Then, please write out the full article in the analyzed writing style. Aim to make it sound as much like it was written by the same author as the example articles as possible. Match the tone, grammar, vocabulary, idioms, and all other stylistic elements. The content and arguments should be your own, but the writing style should be emulated.

Please output the article inside <article> tags.