DEV Community: Emilie Gervais

Server Error status codes

Emilie Gervais — Thu, 06 Feb 2020 21:44:51 +0000

Preface: A HTTP status code is issued from the server in response to a client's request made to the server. The five status code response classes are informational, successful, redirection, client error and server error.

Server Error status codes

Server error status codes indicate that the request was valid, but an error on the server is preventing its fulfillment.

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage (WebDAV)
508 Loop Detected (WebDAV)
510 Not Extended
511 Network Authentication Required
598 Network Read Timeout Error
599 Network Connect Timeout Error

`500 Internal Server Error`

Definition: The request can't be fulfilled due to an unexpected condition encountered by the server. This error response is a generic "catch-all" response, given when no more specific message is suitable.

500 Internal Server Error is defined in RFC 7231.

`501 Not Implemented`

Definition: The request can't be fulfilled because the server does not support the functionality required to fulfill it. A Retry-After header can also be sent to tell the requester when to check back to see if the functionality is supported by then. 501 Not Implemented is the appropriate response when the server does not recognize the request method and is incapable of supporting it for any resource. The only methods that servers are required to support (and therefore that must not return 501 Not Implemented) are GET and HEAD. If the server does recognize the method, but intentionally does not support it, the appropriate response is 405 Method Not Allowed.

501 Not Implemented is defined in RFC 7231.

`502 Bad Gateway`

Definition: The request cannot be fulfilled because the server was acting as a gateway or a proxy and received an invalid response from the upstream server.

502 Bad Gateway is defined in RFC 7231.

`503 Service Unavailable`

Definition: The request cannot be handled by the server because it is overloaded or down for maintenance. In other words, the server is not ready to handle the request. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service. Caching-related headers that are sent along with this response should be taken care of, as a 503 Service Unavailable status is often a temporary condition and responses shouldn't usually be cached.

503 Service Unavailable is defined in RFC 7231.

`504 Gateway Timeout`

Definition: The request cannot be fulfilled because the server was acting as a gateway or a proxy and it did not receive a response in time from the upstream server.

504 Gateway Timeout is defined in RFC 7231.

`505 HTTP Version Not Supported`

The request is using an HTTP version that is not supported by the server.

505 HTTP Version Not Supported is defined in RFC 7231.

`506 Variant Also Negotiates`

Definition: The request was made in the context of Transparent Content Negotiation, a protocol that enables a client to retrieve the best variant of a given resource, where the server supports multiple variants. The 506 Variant Also Negotiates status code indicates an internal server configuration error in which the chosen variant is itself configured to engage in content negotiation, so is not a proper negotiation endpoint.

506 Variant Also Negotiates is defined in RFC 2295.

`507 Insufficient Storage`

Definition: The request cannot be fulfilled because the server is unable to store the representation needed to complete it.

507 Insufficient Storage is defined in RFC 4918.

`508 Loop Detected`

The request cannot be fulfilled because the server detected an infinite loop while processing it. This status indicates that the entire operation failed.

508 Loop Detected is defined in RFC 5842.

`510 Not Extended`

Definition: The request was made in the context of the HTTP Extension Framework and cannot be fulfilled because one, many or all the described extensions are not supported by it.

510 Not Extended is defined in RFC 2774.

`511 Network Authentication Required`

Definition: The request was made without proper identification. The client needs to authenticate to gain network access. This status is not generated by origin servers, but by intercepting proxies that control access to the network. Network operators sometimes require some authentication, acceptance of terms, or other user interaction before granting access (for example in an internet café or at an airport). They often identify clients who have not done so using their Media Access Control (MAC) addresses.

511 Network Authentication Required is defined in RFC 6585.

`598 Network Read Timeout Error`

Definition: This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.

`599 Network Connect Timeout Error`

Definition: This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Unofficial and customized non-standard responses defined by server softwares are not included in the list above.

Resources:

Client Error status codes

Emilie Gervais — Thu, 06 Feb 2020 21:34:15 +0000

Client Error status codes

Client Error status codes indicate that there was a problem with the request. It cannot be fulfilled.

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 URI Too Long
415 Unsupported Media Type
416 Range Not Satisfiable
417 Expectation Failed
418 I'm a teapot
421 Misdirect Request
422 Unprocessable Entity (WebDAV)
423 Locked (WebDAV)
424 Failed Dependency (WebDAV)
425 Too Early
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
451 Unavailable For Legal Reasons

`400 Bad Request`

Definition: The request cannot be understood by the server due to invalid syntax.

400 Bad Request is defined in RFC 7231.

`401 Unauthorized`

Definition: The request cannot be processed because it lacks valid authentication credentials for the target resource. This status is sent with a WWW-Authenticate header that contains information on how to authorize correctly. This status is similar to 403 Forbidden, but in this case, authentication is possible.

401 Unauthorized is defined in RFC 7235.

`402 Payment Required`

Definition: The request can not be processed until the client makes a payment. Originally it was created to enable digital cash or (micro) payment systems and would indicate that the requested content is not available until the client makes a payment. However, no standard use convention exists and different entities use it in different contexts. It is a nonstandard client error status response code that is reserved for future use.

402 Payment Required is defined in RFC 7231.

`403 Forbidden`

Definition: The request was understood by the server but the server refuses to authorize it. This status is similar to 401 Unauthorized except that in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.

403 Forbidden is defined in RFC 7231.

`404 Not Found`

Definition: The request is looking for a resource that can't be found by the server but may be available again in the future. Subsequent requests by the client are permissible. Links which lead to a 404 page are often called broken or dead links, and can be subject to link rot. A 404 Not Found status code does not indicate whether the resource is temporarily or permanently missing. But if a resource is permanently removed, a 410 Gone should be used instead of a 404 Not Found status.

404 Not Found is defined in RFC 7231.

`405 Method Not Allowed`

Definition: The request method is known by the server but is not supported by the target resource. The server MUST generate an Allow header field in a 405 Method Not Allowed response containing a list of the target resource's currently supported methods. For example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.

405 Method Not Allowed is defined in RFC 7231.

`406 Not Acceptable`

Definition: The request cannot be fulfilled by the server. The server cannot produce a response matching the list of acceptable values defined in the request's content negotiation headers and is unwilling to supply a default representation. Content negotiation headers include: Accept, Accept-Charset, Accept-Encoding and Accept-Language. 406 Not Acceptable is rarely used: Servers usually ignore the relevant header and serve and actual page to the user. If a server returns such an error status, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them.

406 Not Acceptable is defined in RFC 7231.

`407 Proxy Authentication`

Definition: The request has not been applied because it lacks valid authentication credentials for a proxy server that is between the browser and the server that can access the requested resource. The client must first authenticate itself with the proxy. This status is sent with a Proxy-Authenticate header that contains information on how to authorize correctly.

407 Proxy Authentication is defined in RFC 7235.

`408 Request Timeout`

Definition: The request is taking too long. The server timed out waiting for it or decided to close the connection rather than continue waiting. The client MAY repeat the request without modifications at any later time. In the response, the server should send the close Connection header field. This response is used much more since some browsers, like Chrome, Firefox 27+, and IE9, use HTTP pre-connection mechanisms to speed up surfing.

408 Request Timeout is defined in RFC 7231.

`409 Conflict`

Definition: The request could not be processed because it is in conflict with the current state of the server. Conflicts are most likely to occur in response to a PUT request. For example, you may get a 409 Conflict response when uploading a file which is older than the one already on the server resulting in a version control conflict.

409 Conflict is defined in RFC 7231.

`410 Gone`

Definition: The request is looking for a resource that is no longer available and will not be available again. Upon receiving a 410 Gone status code, the client should not request the resource again in the future. If you don't know whether this condition is temporary or permanent, a 404 Not Found status code should be used instead.

410 Gone is defined in RFC 7231.

`411 Length Required`

Definition: The request did not define Content-Length header, which is required by the requested resource so it cannot be accepted by the server. By specification, when sending data in a series of chunks, the Content-Length header is omitted and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format.

411 Length Required is defined in RFC 7231.

`412 Precondition Failed`

Definition: The request has been denied access to the target resource. Per example, with conditional requests on methods other than GET and HEAD when the condition defined by the If-Unmodified-Since or If-None-Match headers is not fulfilled. In that case, the request, usually an upload or a modification of a resource, cannot be made and this error response is sent back.

412 Precondition Failed is defined in RFC 7232.

`413 Payload Too Large`

Definition: The request is larger than the limits defined by the server. The server might close the connection or return a Retry-After header field if the condition is temporary.

413 Payload Too Large is defined in RFC 7231.

`414 URI Too Long`

Definition: The request is looking for an URI that is longer than what the server is willing to interpret. This is a rare condition that might occur when: A client has improperly converted a POST request to a GET request with more than ≈2 kB of submitted data; a client has descended into a loop of redirection or the server is under attack by a client attempting to exploit potential security holes.

414 URI Too Long is defined in RFC 7231.

`415 Unsupported Media Type`

Definition: The request is refued by the server because the payload format is unsurpported. The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

415 Unsupported Media Type is defined in RFC 7231.

`416 Range Not Satisfiable`

Definition: The request was made for a specific portion of the resource, but the server cannot supply it. The most likely reason is that the document doesn't contain such ranges, or that the Range header value, though syntactically correct, doesn't make sense. The 416 Range Not Satisfiable response message contains a Content-Range indicating an unsatisfied range (that is a '*') followed by a '/' and the current length of the resource. For example: Content-Range: bytes */12777

416 Range Not Satisfiable is defined in RFC 7233.

`417 Expectation Failed`

Definition: The request has requirements in its Expect header that the server can't meet.

417 Expectation Failed is defined in RFC 7231.

`418 I'm a Teapot`

Definition: The request wants the server the brew coffee, but the server refuses because it is a teapot. This error is a reference to Hyper Text Coffee Pot Control Protocol which was an April Fools' joke in 1998.

418 I'm a Teapot is defined in RFC 2324.

`421 Misdirect Request`

Definition: The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

421 Misdirect Request is defined in RFC 7540.

`422 Unprocessable Entity`

Definition: The request is understood by the server but the server is unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed, but semantically erroneous, XML instructions. The client should not repeat this request without modification.

422 Unprocessable Entity is defined in RFC 7918.

`423 Locked`

Definition: The request is trying to access a locked resource. This response SHOULD contain an appropriate precondition or postcondition code, such as lock-token-submitted or no-conflicting-lock.

423 Locked is defined in RFC 4918.

`424 Failed Dependency`

Definition: The request failed due to failure of a previous request.

424 Failed Dependency is defined in RFC 4918.

`425 Too Early`

Definition: The request is considered one that might be replayed and the server is unwilling to risk processing it for security reasons. Replayed requests create the potential for a replay attack.

425 Too Early is defined in RFC 8470.

`426 Upgrade Required`

Definition: The request cannot be processed using the current protocol, but the server is willing to process it after the client upgrades to a different protocol. The server sends an Upgrade header with this response to indicate the required protocols.

426 Upgrade Required is defined in RFC 7231.

`428 Precondition Required`

Definition: The request is not conditional and the server requires that it be conditional: A required precondition header, such as If-Match, is missing. When a precondition header is not matching the server side state, the response should be 412 Precondition Failed.

428 Precondition Required is defined in RFC 6585.

`429 Too Many Requests`

The request is one of too many sent by the user in a given amount of time (\"rate limiting\") Intended for use with rate limiting schemes. A Retry-After header might be included to this response indicating how long to wait before making a new request.

429 Too Many Requests is defined in RFC 6585.

`431 Request Header Fields Too Large`

Definition: The request's HTTP headers are too long, so the server refuses to process it. 431 can be used when the total size of request headers is too large, or when a single header field is too large. To help those running into this error, indicate which of the two is the problem in the response body — ideally, also include which headers are too large. This lets users attempt to fix the problem, such as by clearing their cookies. Servers will often produce this status if: The Referer URL is too long or if there are too many Cookies sent in the request.

431 Request Header Fields Too Large is defined in RFC 6585.

`451 Unavailable For Legal Reasons`

Definition: The request is looking for a resource that is not available due to legal reasons. Per example, a web page for which legal action has been issued.

451 Unavailable For Legal Reasons is defined in RFC 7725.

Unofficial and customized non-standard responses defined by server softwares are not included in the list above.

Resources:

Redirection status codes

Emilie Gervais — Thu, 06 Feb 2020 21:13:02 +0000

Redirection status codes

Redirection status codes are returned when a new resource has been substituted for the requested resource. To complete the request, further action must be taken.

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 (Unused)
307 Temporary Redirect
308 Permanent Redirect

`300 Multiple Choices`

Definition: The request has more than one possible response. The user-agent or client should choose one of them. There is no standardized way of choosing one of the responses, but HTML links to the possibilities are recommended so the user can pick. For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.

300 Multiple Choices is defined in RFC 7231.

`301 Moved Permanently`

Definition: The request is looking for a resource that has moved permanently. Its new URL is given in the response.

301 Moved Permanently is defined in RFC 7231.

`302 Found`

Definition: The request is looking for a resource with a URI that has been changed temporarily. Further changes in the URI might be made in the future. The current URI should be used by the client in future requests.

302 Found is defined in RFC 7231.

`303 See Other`

Definition: The request is looking for a resource that can be found at another URI using a GET method. When received in response to a POST, PUT or DELETE, it should assumed that the server has received the data and the redirect should be issued with a separate GET message.

303 See Other is defined in RFC 7231.

`304 Not Modified`

Definition: The request is looking for resource that hasn't been modified since the last time the client accessed it, so the client can continue to use the same cached version of the response.

304 Not Modified is defined in RFC 7232.

`305 Use Proxy`

*
Definition:* The request is looking for a resource that must be accessed by a proxy. It has been deprecated due to security concerns regarding in-band configuration of a proxy.

305 Use Proxy is defined in RFC 7231.

`306 (Unused)`

Definition: This response code is no longer used; it is just reserved. It was used in a previous version of the HTTP/1.1 specification.

306 (Unused) is defined in RFC 7231.

`307 Temporary Redirect`

Definition: The request is looking for a resource that is currently redirected. The server sends this response to direct the client to get the requested resource at another URI with same method that was used in the prior request. Future requests can still use the original URI. 307 Temporary Redirect has the same semantics has the 302 Found response code, with the exception that the user agent must not change the HTTP method used: If a POST was used in the first request, a POST must be used in the second request.

307 Temporary Redirect is defined in RFC 7231.

`308 Permanent Redirect`

Definition: This means that the resource is now permanently located at another URI, specified by the Location: HTTP Response header. This has the same semantics as the 301 Moved Permanently HTTP response code, with the exception that the user agent must not change the HTTP method used: If a POST was used in the first request, a POST must be used in the second request.

308 Permanent Redirect is defined in RFC 7538.

Unofficial and customized non-standard responses defined by server softwares are not included in the list above.

Resources:

Successful status codes

Emilie Gervais — Thu, 06 Feb 2020 21:01:28 +0000

Successful status codes

Successful status codes are returned when the browser request was successfully received, understood and processed by the server.

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV)
208 Already Reported (WebDAV)
226 IM Used

`200 OK`

Definition: The request has succeeded. Its response is cacheable. The meaning of this response depends on the HTTP request method the server received: For GET requests, the resource has been fetched and is transmitted in the message body; for HEAD requests, the entity headers are in the message body; for POST requests, the resource describing the result of the action is transmitted in the message body; for TRACE requests, the message body contains the request message as received by the server. For PUT and DELETE requests, a successful request is often not a 200, but a 204 No Content.

200 OK is defined in RFC 7231.

`201 Created`

Definition: The request has been fulfilled and resulted in a new resource being created. Successful creation occurred (via either POST or PUT). The new resource is returned in the body of the message, its location being either the URL of the request, or the content of the Location header.

201 Created is defined in RFC 7231.

`202 Accepted`

Definition: The request has been accepted for processing, but the processing has not been completed. It is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing.

202 Accepted is defined in RFC 7231.

`2013 Non-Authoritative Information`

Definition: The request was successful but is returning a modified version of the origin's response resulting in an enclosed payload that has been modified by a transforming proxy from that of the origin server's 200 OK response. The 203 Non-Authoritative Information response is similar to the value 214 Transformation Applied of the Warning header code, which has the additional advantage of being applicable to responses with any status code.

2013 Non-Authoritative Information is defined in RFC 7231.

`204 No Content`

Definition: The request has succeeded, but the client doesn't need to go away from its current page. This response is cacheable by default and includes an ETag header. The common use case is to return 204 No Content as a result of a PUT request, updating a resource, without changing the current content of the page displayed to the user. If the resource is created, 201 Created is returned instead. If the page should be changed to the newly updated page, the 200 OK should be used instead.

204 No Content is defined in RFC 7231.

`205 Reset Content`

Definition: The request was successfully processed by the server, but is not returning any content. Similar to 204 No Content, but lets the client know that it should reset the document view.

205 Reset Content is defined in RFC 7231.

`206 Partial Content`

Definition: The request has succeeded, but the server is delivering only part of the resource due to a Range header sent by the client. If there is only one range, the Content-Type of the whole response is set to the type of the document, and a Content-Range is provided. If several ranges are sent back, the Content-Type is set to multipart/byteranges and each fragment covers one range, with Content-Range and Content-Type describing it.

206 Partial Content is defined in RFC 7233.

`207 Multi-Status (WebDAV)`

Definition: The request has succeeded and the body of the server's response is by default an XML message which can contain a number of separate responses codes, depending on how many sub-requests were made. Useful for situations where multiple status codes might be appropriate.

207 Multi-Status (WebDAV) is defined in RFC 4918.

`208 Already Reported (WebDAV)`

Definition: The request has succeeded and contains a collection: Only one element will be reported with a 200 OK status. The others will be reported with a 208 status inside the response element <dav:propstat> to avoid repeatedly enumerating the internal members of multiple bindings to the same collection.

208 Already Reported (WebDAV) is defined in RFC 5842.

`226 IM Used`

The request has succeeded and the response sent by the server is a representaiton of the result of one or more instance-manipulations applied to the current instance.

226 IM Used is defined in RFC 3229.

Unofficial and customized non-standard responses defined by server softwares are not included in the list above.

Resources:

Informational status codes

Emilie Gervais — Thu, 06 Feb 2020 19:43:20 +0000

Informational status codes

Informational status codes indicate that the request initiated by the browser was received and is continuing.

100 Continue
101 Switching Protocols
102 Processing
103 Early Hints

`100 Continue`

Definition: The request has been received and has not yet been rejected by the server. The server intends on sending a final response once the request has been completed meaning that the server has received the request headers and client can now proceed to send the request body. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body.

100 Continue is defined in RFC 7231.

`101 Switching Protocols`

Definition: The request has asked the server to switch protocols. The server response indicates that it is switching protocol as requested. In this response, the server includes an Upgrade response header to indicate the protocol it switched to.

101 Switching Protocols is defined in RFC 7231.

`102 Processing`

Definition: The request has been received and is being processed by the server, but no response is available yet. In the meantime, this response prevents the client from timing out and assuming the request was lost.

102 Processing is defined in RFC 2518.

`103 Early Hints`

Definition: The server is likely to send a final response with the header fields included in the informational response. Mainly intended to be used with the Link header to allow the user agent to start preloading resources while the server is still preparing a response.

103 Early Hints is defined in RFC 8297.

Unofficial and customized non-standard responses defined by server softwares are not included in the list above.

Resources:

Notes on algorithms

Emilie Gervais — Fri, 10 Jan 2020 13:47:45 +0000

I'm doing CS50: Introduction to Computer Science on edx.org. I find it's a great way to review what I learn by completing, rewriting and sharing some of my notes.

Note: Big O notation can be though of “on the order of” and it represents the running time of an algorithm. In the C examples, n is equivalent to sizeof(arr)/sizeof(arr[0]) which translates in JavaScript to arr.length.

Week 3 is about algorithms. 😺

Linear Search
Binary Search
Bubble Sort
Selection Sort
Insertion Sort
Recursion
Merge Sort

Linear Search

To iterate across the array from left to right searching for a target element.

Pseudocode example #1:

Repeat, starting at the first element:
    If the element is the target element, stop
    Else, move to the next element

Pseudocode example #2:

For i from 0 to n–1
    If i'th element is target_element
        Return true
Return false

C example:

bool linearSearch(int arr[], int n, int target) 
{ 
    for (int i = 0; i < n; i++) 
        if (arr[i] == target) return true;
    return false; 
}

JavaScript example:

linearSearch = (arr, target) => {
    for (let i = 0; i < arr.length; i++)
        if (arr[i] === target) return true;
    return false;
}

Linear Search algorithm's

Worst case scenario:
Having to look through the entire array of n elements in the case where the target element is the last one or it is not in the array.
In Big O notation, it translates to O(n).
Best case scenario:
The target element is the 1st element.
In Big O notation, it translates to Ω(1).

Binary Search

To find the target element by reducing the search area by half each time. Make sure the array on which the binary search algorithm is used on is sorted, else it's impossible to make assumptions about its content.

Pseudocode example #1:

Repeat until the (sub)array is of size 0:
    Calculate the middle point of the current (sub)array
    If the target element is the middle element, stop
    Else if it's less than the middle: 
        End point is now just to the left of the current middle, repeat
    Else if it's greater than the middle: 
        Start point is now just to the right of the current middle, repeat

Pseudocode example #2:

If no items
    Return false
If middle item is target_element
    Return true
Else if target_element < middle item
    Update end point
    Search left half
Else if target_element > middle item
    Update start point
    Search right half

C example (recursive):

int binarySearch(int arr[], int target, int start, int end) 
{ 
    if (end >= start) { 
        // instead of (start+end)/2 to avoid overflow
        int mid = start+(end-start)/2; 
        if (arr[mid] == target) return mid; 
        else if (arr[mid] > target) return binarySearch(arr, target, start, mid-1); 
        else return binarySearch(arr, target, mid+1, end); 
    } 
    return -1; 
}

JavaScript example (recursive):

binarySearch = (arr, target, start, end) => {   
    if (end >= start) {
        let mid = Math.floor((start+end)/2);
        if (arr[mid] === target) return mid;
        else if(arr[mid] > target) return binarySearch(arr, target, start, mid-1); 
        else return binarySearch(arr, target, mid+1, end); 
    }
    return false;
}

Binary Search algorithm's

Worst case scenario:
Having to divide a list of n elements in half repeatedly to find the target element because the target is found at the end of the last division or it is not in the array.
In Big O notation, it translates to O(log n).
Best case scenario:
The target element is at midpoint of the array, so we can stop searching immediately after we start.
In Big O notation, it translates to Ω(1).

Bubble Sort

To sort in a bubbling way: move higher values towards the right of the array and lower values, towards the left.

Pseudocode example #1:

Set swap counter to a non-zero value
Repeat until the swap counter is equal to 0:
    Reset swap counter to 0
    Look at each adjacent pair:
        If two adjacent elements are not in order:
            Swap them
            Add one to the swap counter

Pseudocode example #2:

Repeat until no swaps
    For i from 0 to n–2
        If i'th and i+1'th elements out of order
            Swap them

C example:

void bubbleSort(int arr[], int n) 
{ 
    for (int i = 0; i < n-1; i++)
        for (int j = 0; j < n-i-1; j++)
            if (arr[j] > arr[j+1])
            {
                int temp = arr[j]; 
                arr[j] = arr[j+1]; 
                arr[j+1] = temp;
            }
}

JavaScript example:

bubbleSort = arr => {
    for (let i = 0; i < arr.length-1; i++)
        for (let j = 0; j < arr.length-i-1; j++)
            if (arr[j] > arr[j+1]) {
                let temp = arr[j];
                arr[j] = arr[j+1];
                arr[j+1] = temp;
            }
    return arr;
}

Because comparing the ith and i+1th element, the sorting only needs to go up to n-2 for i before swapping the two elements if they're out of order. Knowing the largest n-1 elements will have bubbled to the right, the sorting can stop after n-1 passes.
When re-going through the array, only consider the unsorted elements.
When the swap counter remains at 0, there is nothing else to swap.

Bubble sort algorithm's

Worst case scenario:
Having to bubble each of the elements all the way across the array because the array is in reverse order. Since it's only possible to fully bubble one element into its sorted position per pass, the sorting must happen n times.
In Big O notation, it translates to O(n²).
Best case scenario:
The array is already perfectly sorted, resulting in no swapping on the first pass.
In Big O notation, it translates to Ω(n).

Selection Sort

To find the smallest unsorted element and add it to the end of the sorted list.

Pseudocode example #1:

Repeat until there is no unsorted elements remaining:
    Search unsorted part of data to find the smallest value
    Swap the found value with the first element of the unsorted part

Pseudocode example #2:

For i from 0 to n–1
    Find smallest item between i'th item and last item
    Swap smallest item with i'th item

C example:

void selectionSort(int arr[], int n) 
{ 
    for (int i = 0; i < n-1; i++)
    {
        int min = i; 
        for (int j = i+1; j < n; j++) 
            if (arr[j] < arr[min]) min = j;
        int temp = arr[min];
        arr[min] = arr[i];
        arr[i] = temp;
    }
}

JavaScript example:

selectionSort = arr => { 
    for (let i = 0; i < arr.length-1; i++) {
        let min = i; 
        for (let j = i+1; j < arr.length; j++)
            if (arr[j] < arr[min]) min = j;
        let temp = arr[min];
        arr[min] = arr[i];
        arr[i] = temp;
    }
    return arr;
}

Selection sort algorithm's

Worst case scenario:
Having to repeat the sorting process n times to iterate each of the n elements of the array to find the smallest unsorted element and sort it. Only one element gets sorted on each pass.
In Big O notation, it translates to O(n²).
Best case scenario:
The same as the worst case scenario as there is no way to guarantee the array is sorted until the sorting process iterates over all of the elements of the array.
In Big O notation, it translates to Ω(n²).

Insertion Sort

To build a sorted array in place; shifting elements out of the way to make room if necessary as the array is being built.

Pseudocode example #1:

Call the first element of the array sorted
Repeat until all elements are sorted:
    Insert next unsorted item into sorted part shifting the required number of items

Pseudocode example #2:

For i from 1 to n–1
    Insert next unsorted item into sorted part shifting i items

C example:

void insertionSort(int arr[], int n) 
{ 
    for (int i = 1; i < n; i++) { 
        int key = arr[i]; 
        int j = i-1; 
        while (j >= 0 && arr[j] > key) { 
            arr[j+1] = arr[j]; 
            j = j-1; 
        } 
        arr[j+1] = key; 
    } 
}

JavaScript example:

insertionSort = arr => { 
    for (let i = 1; i < arr.length; i++) { 
        let key = arr[i]; 
        let j = i-1; 
        while (j >= 0 && arr[j] > key) { 
            arr[j+1] = arr[j]; 
            j = j-1; 
        } 
        arr[j+1] = key; 
    } 
    return arr;
}

Insertion sort algorithm's

Worst case scenario:
Having to shift each of the n elements from n positions each time to make an insertion because the array is in reverse order.
In Big O notation, it translates to O(n²).
Best case scenario:
The array is already sorted. Only gotta keep moving between unsorted and sorted elements as we iterate over each of them.
In Big O notation, it translates to Ω(n).

Recursion

To code elegantly. 🌹

Recursion is related to how an algorithm or a function is implemented, it isn't an algorithm itself.

A recursive function invokes itself as part of its execution.

Detailed example using the factorial function:

n! is defined over all positive integers
n! equals all of the positive integers less than or equal to n, multiplied together
n! as fact(n):

Pseudocode example #1:

fact(1) = 1
fact(2) = 2 * 1
fact(3) = 3 * 2 * 1
…

Pseudocode example #2:

fact(1) = 1
fact(2) = 2 * fact(1)
fact(3) = 3 * fact(2)
…

The basis for a recursive definition of the factorial function:

fact(n) = n * fact(n-1)

Recursive function has two cases that can apply given any input:

Base case: terminates the recursive process when triggered
Recursive case: where the recursion happens

int fact(int n) 
{
    // base case
    if (n == 1)
        return 1;
    // recursive case
    else
        return n * fact(n-1);
}

There can be multiple base cases.
Example the fibonacci number sequence where:

1st element is 0
2nd element is 1
nth element is the sum of (n-1)+(n-2)

There can be multiple recursive cases.
Example the collatz conjecture.

The next C and JavaScript examples define a collatz function that calculates how many steps it takes to get "back to 1":

C example:

int collatz(int steps) 
{
    // base case
    if (steps == 1) return 0;
    // recursive case: even numbers
    else if ((steps % 2) == 0) return 1+collatz(steps/2);
    // recursive case: odd numbers
    else return 1+collatz(3*steps+1);
}

JavaScript example:

collatz = steps => {
    // base case
    if (steps == 1) return 0;
    // recursive case: even numbers
    else if ((steps % 2) == 0) return 1+collatz(steps/2);
    // recursive case: odd numbers
    else return 1+collatz(3*steps+1);
}

Merge Sort

To divide an array into smaller arrays to sort and then, combine those sorted arrays back together in sorted order.

Pseudocode example #1:

If only one element
  Return
Else
    Sort left half of elements
    Sort right half of elements
    Merge sorted halves

Pseudocode example #2:

Sort the left half of the array (assuming n > 1)
Sort right half of the array (assuming n > 1)
Merge the two halves together

C example (recursive):

// merges two subarrays of arr[]
void merge(int arr[], int leftIndex, int mid, int rightIndex) 
{ 
    int n1 = mid-leftIndex+1; 
    int n2 =  rightIndex-mid; 

    // temp arrays
    int Left[n1], Right[n2]; 

    // copy data to temp arrays
    for (int i = 0; i < n1; i++) 
        Left[i] = arr[leftIndex+i]; 
    for (int j = 0; j < n2; j++) 
        Right[j] = arr[mid+1+j]; 

    // merge the temp arrays back into arr[]
    int i = 0; // init index of 1st subarray 
    int j = 0; // init index of 2nd subarray 
    int k = leftIndex; // init index of merged subarray 
    while (i < n1 && j < n2) 
    { 
        if (Left[i] <= Right[j]) 
        { 
            arr[k] = Left[i]; 
            i++; 
        } 
        else
        { 
            arr[k] = Right[j]; 
            j++; 
        } 
        k++; 
    } 

    // copy the remaining elements of Left[], if any
    while (i < n1) 
    { 
        arr[k] = Left[i]; 
        i++; 
        k++; 
    } 

    // copy the remaining elements of Right[], if any
    while (j < n2) 
    { 
        arr[k] = Right[j]; 
        j++; 
        k++; 
    } 
} 

void mergeSort(int arr[], int leftIndex, int rightIndex) 
{   
    if (leftIndex < rightIndex) 
    { 
        // instead of (l+r)/2 to avoid overflow
        int mid = leftIndex+(rightIndex-leftIndex)/2; 
        // sort first and second halves 
        mergeSort(arr, leftIndex, mid); 
        mergeSort(arr, mid+1, rightIndex); 
        // merge them back together
        merge(arr, leftIndex, mid, rightIndex); 
    } 
}

JavaScript example (recursive):

// to merge left subarray and right subarray
merge = (left, right) => {
    let resultArray = [], leftIndex = 0, rightIndex = 0;

    // concat values into the resultArray in order
    while (leftIndex < left.length && rightIndex < right.length) {
        if (left[leftIndex] < right[rightIndex]) {
            resultArray.push(left[leftIndex]);
            leftIndex++;
        } else {
            resultArray.push(right[rightIndex]);
            rightIndex++;
        }
    }

    // concat remaining element from either left OR right
    return resultArray
        .concat(left.slice(leftIndex))
        .concat(right.slice(rightIndex));
}

mergeSort = arr => {
    // if array has one element or is empty, no need to sort
    if (arr.length <= 1) return arr;

    const mid = Math.floor(arr.length/2);
    // divide the array into left and right
    const left = arr.slice(0, mid);
    const right = arr.slice(mid);

    // merge back together using recursion
    return merge(mergeSort(left), mergeSort(right));
}

Merge sort algorithm's

Worst case scenario:
Having to split n elements up before recombining them effectively, doubling the sorted sub-arrays as they are built.
In Big O notation, it translates to O(n log n).
Best case scenario:
The array is already sorted, but still gotta be split and recombined back together to know it is sorted.
In Big O notation, it translates to Ω(n log n).

Resources:

JavaScript FizzBuzz solution in details

Emilie Gervais — Sat, 12 Oct 2019 11:23:27 +0000

The first time I solved FizzBuzz, my code result was:

for (let i = 1; i <= 100; i++) {
    if (i % 3 == 0 && i % 5 == 0) {
        console.log("FizzBuzz");
    } else if (i % 3 == 0) {
        console.log("Fizz");
    } else if (i % 5 == 0) {
        console.log("Buzz");
    } else {
        console.log(i);
    }
}

While looking for pull requests to make for Hacktoberfest, I stumbled upon

s-bridges / Hacktoberfest_Fizzbuzz

Hacktoberfest FizzBuzz Challenge

Hacktoberfest_Fizzbuzz

Hacktoberfest FizzBuzz Challenge

This challenge is meant to help developers solve the FizzBuzz challenge in their respective programming language, as well as teach new GitHub users how to make their first Pull Request in honor of Hacktoberfest's 2019 campaign.

Problem

Write a short program that prints each number from 1 to 100 on a new line For each multiple of 3, print "Rat" instead of the number. For each multiple of 5, print "Ghost" instead of the number. For numbers which are multiples of both 3 and 5, print "Spider" instead of the number.

Write a solution (or reduce an existing one) so it has as few characters as possible.

How to Create a Pull Request in GitHub

Click on the fork in the top right corner of this repo.
Clone fork to your machine. git clone https://github.com/${username}/Hacktoberfest_Fizzbuzz
Create a branch titled your programming language. git checkout -b python…

View on GitHub

~ the Hacktoberfest_Fizzbuzz repo (😢 it has now been marked as 'invalid' for hacktoberfest). On the moment though, I got excited and aimed to refactor my previous solution to the smallest possible one I could find using JavaScript.

Note: The repo author asked to print 'Spider' instead of 'FizzBuzz', 'Ghost' instead of 'Buzz' and 'Rat' instead of 'Fizz'.

My result:

console.log([...Array(100)].map((_,i)=>{i++;return(i%15?'':'Spider')||(i%5?'':'Ghost')||(i%3?'':'Rat')||i;}).join('\n'));

SET UP
--> console.log(): to directly log the result.
--> [...Array(100)]: to create a temporary array of 100 to produce the much wanted indexes.
--> .map((n,i)=>{}: to return an array filled with new content after the current values have iterated through the method's callback function.

CALLBACK
--> i++: to initiate i to be 1 (in this case, we don't want to start from 0).
--> return: to stop the function from running once its done iterating and return the new array.
--> (i%15?'':'Spider'): check if i is divisible by 15 (if divisible by 15, it is also divisible by both 3 and 5); if there's a remainder, print nothing; if there isn't, print 'Spider'.
--> ||: OR
--> (i%5?'':'Ghost'): check if i is divisible by 5; if there's a remainder, print nothing; if there isn't, print 'Ghost'.
--> ||: OR
--> (i%3?'':'Rat'): check if i is divisible by 3; if there's a remainder, print nothing; if there isn't, print 'Rat'.
--> ||: OR
--> i: if it isn't divisible by any of the previous options, print the fucking number.

FINISHING
--> .join('\n'): to return a string of all the concatenated elements of the new array using a new line as separator; thus, jumping a line between each elements to console.log a nice SpiderGhostRatNumber list! =)

PS. In JavaScript, an integer converts to a boolean such that 0 is false and all non-zero values (even negative ones) are true.

DEV Community: Emilie Gervais

Server Error status codes

Server Error status codes

Table Of Contents

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates

507 Insufficient Storage

508 Loop Detected

510 Not Extended

511 Network Authentication Required

598 Network Read Timeout Error

599 Network Connect Timeout Error

Client Error status codes

Client Error status codes

Table Of Contents

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Payload Too Large

414 URI Too Long

415 Unsupported Media Type

416 Range Not Satisfiable

417 Expectation Failed

418 I'm a Teapot

421 Misdirect Request

422 Unprocessable Entity

423 Locked

424 Failed Dependency

425 Too Early

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

451 Unavailable For Legal Reasons

Redirection status codes

Redirection status codes

Table Of Contents

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

305 Use Proxy

306 (Unused)

307 Temporary Redirect

308 Permanent Redirect

Successful status codes

Successful status codes

Table Of Contents

200 OK

201 Created

202 Accepted

2013 Non-Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi-Status (WebDAV)

208 Already Reported (WebDAV)

226 IM Used

Informational status codes

Informational status codes

Table Of Contents

100 Continue

101 Switching Protocols

102 Processing

`500 Internal Server Error`

`501 Not Implemented`

`502 Bad Gateway`

`503 Service Unavailable`

`504 Gateway Timeout`

`505 HTTP Version Not Supported`

`506 Variant Also Negotiates`

`507 Insufficient Storage`

`508 Loop Detected`

`510 Not Extended`

`511 Network Authentication Required`

`598 Network Read Timeout Error`

`599 Network Connect Timeout Error`

`400 Bad Request`

`401 Unauthorized`

`402 Payment Required`

`403 Forbidden`

`404 Not Found`

`405 Method Not Allowed`

`406 Not Acceptable`

`407 Proxy Authentication`

`408 Request Timeout`

`409 Conflict`

`410 Gone`

`411 Length Required`

`412 Precondition Failed`

`413 Payload Too Large`

`414 URI Too Long`

`415 Unsupported Media Type`

`416 Range Not Satisfiable`

`417 Expectation Failed`

`418 I'm a Teapot`

`421 Misdirect Request`

`422 Unprocessable Entity`

`423 Locked`

`424 Failed Dependency`

`425 Too Early`

`426 Upgrade Required`

`428 Precondition Required`

`429 Too Many Requests`

`431 Request Header Fields Too Large`

`451 Unavailable For Legal Reasons`

`300 Multiple Choices`

`301 Moved Permanently`

`302 Found`

`303 See Other`

`304 Not Modified`

`305 Use Proxy`

`306 (Unused)`

`307 Temporary Redirect`

`308 Permanent Redirect`

`200 OK`

`201 Created`

`202 Accepted`

`2013 Non-Authoritative Information`

`204 No Content`

`205 Reset Content`

`206 Partial Content`

`207 Multi-Status (WebDAV)`

`208 Already Reported (WebDAV)`

`226 IM Used`

`100 Continue`

`101 Switching Protocols`

`102 Processing`

`103 Early Hints`