Monthly Archives: February 2016

Server Basics

Servers……eek!  I often heard terms like ‘client’ and ‘server’ being thrown around when getting into coding.  Because I was mostly focused on learning front-end development, or basically the part of a web app that the user sees and interacts with (aka, the ‘client’), I never thought about the backend, or server-side until about two weeks ago.  I’m going to attempt to break down what I’ve learned.

Big Picture

Let’s say you’ve been working on a web application for weeks.  It has some basic functionality that you are able to use by opening it up in the browser.  You feel proud of yourself, and your friends who’ve seen it think it’s pretty great too.  But, how can you get it to a wider audience?

A server is basically a computer that is responsible for holding onto a website (or ‘hosting’ it).  As people visit that website and interact with it, that server is responsible for getting and sending out data that the people visiting the site want to use.  People using the site (sometimes referred to as clients) request data from the server.  The server responds to requests with a response.

Gray cat photo

Example cat loaf photo of Valcore – the friendliest cat on the East Coast.

Pretend your app is a site for browsing and sharing cat pictures.  When you visit the site, you can browse cats in a variety of categories (“Mischievous Cats,” “Cats Sleeping,” “Cat Loaves”, “Kittens at Play,” and “Cat Hunting Conquests”).  If you’re really into cats causing mischief, you might click on that album.  The server is hit with a request for those pictures, and will respond with showing you all the pictures of cats causing mischief it has.

Alternately, maybe you have a cat picture you want to share on the site, such as the example to the right.  In this case when you upload the photo on the website, the server is hit with a request to get your photo and store it somewhere (probably in a database).  Now, other people visiting the site can enjoy the cute cat photo you posted too.

This is a basic overview, but it is essentially what happens between a server and a client.  Clients can send GET requests to the server, when they are asking for data, or POST requests when they are asking the server to handle data for them.

Zoom In: Local Server

I jumped ahead to talking about external servers in the previous example.   Let’s turn back the clock in the development of our cat pictures site a few weeks.  Before finding an external server to host your site, most developers will want to test their site locally.  This allows them to fine tune the way their app handles different types of requests, and debug anything that might change functionality when refactoring code to have a server.

When developing the front-end, you might test functionality of the site by just opening up the index.html file in your browser.  But, once you develop a server, you will run it in the browser through your local host and port number.  It turns out that each computer has its own server!  This initially confused me because I had an image in my mind that a server was just one of those box-like machines in a datacenter somewhere.  Nope, you have a local server too.

My Foray into NodeJS

I have spent the past few weeks learning how to use NodeJS to make a server.  There are many resources on how to make a basic server with Node, but once it came time to actually use it I realized that I was missing some fundamentals about how they work!

Things to Remember

  1. Your machine’s server has a special address, http://localhost, which resolves to the IP address http://127.0.0.1.
  2. You must specify a port number when you make a server.  Ports help computers communicate across networks.  There are some port numbers that have certain rules and specifications surrounding them, but many others you can use for developing your apps at home and testing them out.
  3. To test out if your app is working once you’ve written it to include a server, you must START THE SERVER!!!!!  This usually involves going into your command line and starting it up from the directory where your project is located.  This depends on what you are using to create the server, but in Node you would type in node app.js, where the app.js is the file where your server code is located.

In this example, you can see that this application is connected to localhost at port 3000, and it happens to be routed to the login page:

localhost example

The server on your machine is great for testing out your project, but it can’t handle a bunch of visitors from the outside.  In order to get your app to a wider audience, you need to basically contract out the services of another company where your project can live on its servers.  I hope to discuss deploying to a server in an upcoming post.

 

TDD/Ed Link

Last week, we had the option of designing a review ‘sprint’ for ourselves, and I took the opportunity to redo a sprint on data structures from the first week of HR. Data structures were a new concept for me, and I knew I would benefit from the review. Even though I didn’t have a partner to bounce ideas off of, I did have a test suite full of tests to help point me in the right direction.

Importance of TDD

Test-driven Development, or TDD, is an extremely important part of the software development process. It involves three steps: 1. Writing a failing test that aligns to a desired part of your program, 2. Writing the minimal amount of code that passes that test, and 3. Refactoring (or rewriting) to make the code more robust or acceptable with common programming standards.

Below is an example of what this looks like.  As you can see, the code that this is based off of is passing the first two tests but failing the last one.

testExample

With HR assignments, we are often given prewritten tests like these to help guide us. Eventually, we will be writing more of them ourselves, but for now we have the benefit of someone else having thought through all of the requirements our code is supposed to pass. In order to write great tests, you have to think about what you want to accomplish with your code. This involves thinking with the end in mind, as well as thinking of possible edge cases that might impact your project.

Connection to Education

I had no idea that programmers had unit tests, or wrote tests with this TDD framework in mind before starting Hack Reactor. However, I am not new to this idea of testing and planning with the end in mind – teachers call this backwards planning. As a former educator, backwards planning was constantly stressed by my graduate school and the middle schools where I worked. Teachers plan units of instruction that take weeks of instruction and also break those weeks into sub-units and eventually daily lesson plans. Backwards planning involves thinking with the end in mind.  It is a common practice, whether planning a daily lesson or a unit plan, to develop the assessment students will use to show their learning FIRST before even starting to think about what the lesson is going to look like.  What key understandings to students need to have by the end of the unit?  What skills do they need to know?  What skills do they already know?  How does it differ according to student needs in the classroom?  What national or state standards or benchmarks are the lessons attached to?

In TDD, programmers have to think through the same types of questions.  It starts with being able to elucidate what exactly it is your code needs to do.  Thinking through this involves thinking of the big picture and breaking it into smaller more manageable ideas. Those smaller ideas can be the basis of the tests you write in your suite, which will help you reach your goal step by step.  Writing tests first results in higher quality code because it allows you to think of possible edge cases and consider all parts of your code.

Wonderings

Any teacher who has gone through a teacher preparation program has at some point had to write a very detailed unit plan. However, in the real world of teaching, sometimes the demands of the curriculum and the resources of the school might lead you to plan a unit as you go instead of in advance, or to use a poorly planned unit.  Unfortunately, teachers and students do not benefit when this happens.  Learning still happens, but not as optimally as it would with a well thought out unit.

I am wondering if this also happens in software engineering. Which companies and startups utilize TDD and what does it look like? Does it ever get overlooked? Why?  This is something I hope to start talking to professionals about as I move forward in this industry.  I know how important planning with the end in mind is, and I would like to work somewhere that believes the same.