Merging conflitcts

Week07/Caching.md

@@ -27,7 +27,9 @@ On the other hand if we wanted to issue a PUT/PATCH request we would have to inc
 
 ###CacheCow
 
-CacheCow library implements server and client by means of [message handlers](http://www.asp.net/web-api/overview/advanced/http-message-handlers).
+The CacheCow library implements HTTP caching on both client and server in ASP.NET Web API. It uses [message handlers](http://www.asp.net/web-api/overview/advanced/http-message-handlers) on both client and server to intercept request and response and apply caching logic and rules.
+
+CacheCow comes with an in-memory database what will be used on the server if nothing else is specified. If the API is to be use for anything else than debugging, testing or a website that you don't want be get popular, something like sql, redis or memcached is recommended.
 
 First you need to install [this library](https://www.nuget.org/packages/CacheCow.Server/)
 
@@ -101,7 +103,7 @@ But the second request:
 
 Here we notice that that the first request returned a status code 200 with an Etag, then when we issued a second request with the "If-None-Match" header with the Etag value and we got a status code 304, thus cached contents where issued.
 
-As mentioned on there [CacheCow wiki](https://github.com/aliostad/CacheCow/wiki), some features include:
+As mentioned on their [wiki](https://github.com/aliostad/CacheCow/wiki), some features include:
 
 **CacheCow.Server features**
 

Week09/NodeJS.md

@@ -7,7 +7,7 @@ Also I assume that you are familiar with javascript. If you are not I recommend
 
 ## How to install Node.js
 
-To install node.js on OSX, open a terminal window and type
+To install Node.js on OSX, open a terminal window and type
 
 	brew install node
 
@@ -123,9 +123,9 @@ The reason is because **node.js** is asynchronous. What really happens is this:
 ```javascript
 1. The program starts to execute the setTimeout function
 	* In it we tell it to wait for 3 sec. 
-	* What happens now is that Node.js has a task that will be ran in 3 sec.
-	** it places this task somewere and continues with the code.  That is it runs the console.log('hello world!'); line
-	** after 3 sec. Node.js will receive a interrupt and when it recives this interrupt it will run the console.log('Nirvana BEST'); line.
+	* What happens now is that Node.js has a task that will be run after 3 sec.
+	** it places this task somewhere and continues with the code.  That is it runs the console.log('hello world!'); line
+	** after 3 sec. Node.js will receive a interrupt and when it receives this interrupt it will run the console.log('Nirvana BEST'); line.
 ```
 
 This is because node.js is asynchronous. This is really the pattern in node.js code, it will never stop. It will allways continue to run. You define tasks and callback but node.js will allways continue to run. This means that there is really no way to stop in node.js code. Of course you can do something like we did above with setTimeout() or a callback. But node.js will not stop even if you do it, it will keep on going and when it receives the interrupt it will run the task or callback.
@@ -209,7 +209,7 @@ var server = net.createServer(function(socket){
 });
 ``` 
 
-We can bind this socket server by calling a function named `listen()`. like this.
+We can bind this socket server by calling a function named `listen()`. Like this.
 
 ```javascript
 server.listen(6000)
@@ -265,7 +265,8 @@ var server = net.createServer(function(socket){
 });
 
 server.listen(6000)
-``` 
+```
+
 Now lets start our node.js server again in terminal window and start nc localhost 6000 from two separte Terminal windows. Now if we write some text in our terminal windows we can see the server terminal window echoing our data.
 
 So we have written a socket server in node.js. It can handle multible socket connections on a single threaded server, by using callback events to handle them.
@@ -328,7 +329,7 @@ It is really easy to write a HTTP web service in node.js. Below is a code that s
 var http = require('http');
 
 var server = http.createServer(function(request, response){
-	response.writeHead(200, {'conent-type': 'test/plain'});
+	response.writeHead(200, {'content-type': 'text/plain'});
 	response.end('Hello World!');
 });
 
@@ -432,13 +433,14 @@ The response we get back is like this:
 
 ```
 HTTP/1.1 200 OK
-conent-type: test/plain
+conent-type: text/plain
 Date: Sat, 08 Nov 2014 11:04:52 GMT
 Connection: keep-alive
 Transfer-Encoding: chunked
 
 Hallo
 ```
+
 And then after 2 secs get added:
 
 ```
@@ -449,6 +451,7 @@ There are two things in the header response that we should take a close look at:
 
 1. The first one is that the connection is keep alive [`Connection: keep-alive`](http://en.wikipedia.org/wiki/HTTP_persistent_connection)
 2. Is that the transfer encoding method is chunked [`Transfer-Encoding: chunked`](http://en.wikipedia.org/wiki/Chunked_transfer_encoding)
+
 Remember that node.js is single threaded. By having the connection keep alive and the transfer encoding chunked makes it possible for node.js to handle multible requests.
 
 Now that we have changed our HTTP server (added our fake fetch to database). Lets do multible requests again with ab. See command and response that we got in terminal window:
@@ -499,13 +502,16 @@ Percentage of the requests served within a certain time (ms)
   99%   2019
  100%   2019 (longest request)
 ```
+
 Look at the time it took to do this test `Time taken for tests:   2.027 seconds`. This is only 2 sec. more it took before we added the 2 sec. delay. Note that we are making 100 requests all at the same time.
 How much time will it take if we make 200 requests in two chunks. 100 requests at the same time and when finished there there will be another 100 requests sent immediately. Can you assume how much time it will take?
+
 Lets try it.
 
 ```terminal
 ab -n 200 -c 100 http://127.0.0.1:7000/
 ```
+
 We get in the Terminal window:
 
 ```terminal

Week11/RabbitMQ.md

@@ -93,7 +93,17 @@ RabbitMQ is an application server that you must setup and execute on a server
     brew install rabbitmq
     rabbitmq-plugins enable rabbitmq_management
 
-And on Ubuntu, or other Linux distributions that use apt.
+The RabbitMQ server scripts are installed into /usr/local/sbin through Homebrew.
+This is not automatically added to your path, so you may want to add it, to be able
+to use the RabbitMQ commands. This can be accomplished by either adding 
+PATH=$PATH:/usr/local/sbin to your .bash_profile or .profile. Or opening your
+/etc/path by writing this in terminal:
+
+    sudo vim /etc/paths
+
+(or any other text editor of you choosing) and add /usr/local/sbin to the file.
+
+On Ubuntu, or other Linux distributions that use apt.
 
     sudo apt-get install rabbitmq-server
     sudo rabbitmq-plugins enable rabbitmq_management
@@ -115,9 +125,12 @@ If it didn't start automatically, you can start RabbitMQ in foreground with
 
 When you install the management plugin you can manage RabbitMQ through a
 web console. If you are running RabbitMQ on your local machine, the url should
-be [http://localhost:55672](http://localhost:15672/)
-
-# Example 1
+be [http://localhost:55672](http://localhost:15672/). The management plugin does
+also include a browser-based UI where you can observe your queues, see how many
+are connected etc. To gain access to the UI you type the same path into your 
+browser and use 'guest' for both username and password.
+
+# Example 1 
 
 Now let's write a simple producer, which creates messages and adds them to
 RabbitMQ. On a random interval, between 0 and 10 seconds, it adds a JSON 
@@ -282,6 +295,8 @@ Acknowledgement works well at RabbitMQ side, if an ack packet isn't recieved fro
 
 this simple code makes sure that a message is not lost on worker being killed, unacknowledged messages are redelivered
 
+For further information check:
+
 # Message durability
 
 If RabbitMQ server goes down it will lose all of its queues and therefore all of our messages.   To prevent this from happening even though the server crashes we need to mark both the queue and the message as durable.  
@@ -302,5 +317,12 @@ Now we need to mark our messages as persistent.
 
 When messages and queue is durable RabbitMQ will save all messages to a disk.  Even though all messages are saved it does not guarantee that no messages will be lost.  There is still a short window when RabbitMQ has received the message and has not yet saved it to a disk, and sometimes RabbitMQ stores the message in a cache.  To get a stronger guarantee it is possible to use: publisher confirms.  
 
+                          routing_key='durable_orders',
+                          body=json.dumps(message),
+                          properties=pika.BasicProperties(
+                            delivery_mode = 2,
+                          ))
+                          
+More on this at:
 https://www.rabbitmq.com/tutorials/tutorial-two-python.html