Adding A Logo in the WordPress “TwentyFifteen” Theme

If you have a mobile ready logo, (that is one that’s approximately less than 300px wide) you can just edit the header.php file and replace:


The TCP Handshake Process

Internet traffic starts with a basic tuple: protocol, host and port. The browser provides three functions, render, computation and IO (a messaging layer that allows these origins to communicate.) Through IO layer, the browser then tries to resolve the requested resources.

Render API includes: HTML, CSS, MathML, ARIA, WebGL, <video>, <canvas>, and images (jpg, png, gif.)

IO API: XHR, DOM Storage, IndexedDB, Cookies, FileReader, Browser Cache, App Cache

Once a connection is made, the TCP Slow-Start process begins, wherein the server sends bytes in a very small amount to make sure it is getting a response.

  1. DNS lookup, finds server – approx. 200ms
  2. Ask server for file. Server acknowledges – approx. 200ms
  3. TCP Slow-Start begins, you ask server for 4 packets it responds accordingly
  4. Next you request 8 packets, if all is well, it sends them.
  5. This ramping up process repeats increasing the size of the data chunks sent – the increments of data size are as follows: 5.7kb, 11.4kb, 22.8kb, 45.6kb, 85kb
  6. A fast connection will take about 800ms to complete up to this point, plus the DNS lookup and initial handshake, we’re looking at 1200ms.

Most of the HTTP data flows consist of small bursty data transfers whereas TCP is optimized for long lived connections and bulk data transfers. Network roundtrip time is limiting factor in TCP throughput and performance in most cases. Consequently, latency is is the performance bottleneck for HTTP and most of the web.
High Performance Browser Networking: What Every Web Developer Should Know

Test your website

Traditionally, why has it been better to serve site assets from multiple domains?

Keeping images and assets on a geographically dispersed CDN allows for faster resource requests by reducing round trip time. It also leverages “domain sharding” benefits – which means rather than loading from a single domain, browsers actually load faster when requesting resources from several domains by allowing each domain connection to download up to the maximum allowed – 6 concurrent downloads.

More info: Quora and MaxCDN.

HTTP Actions

(Rewritten and taken from

  2. GET
  3. HEAD
  4. POST
  5. PUT
  7. TRACE


The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

Responses to this method are not cacheable.

If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.

If the Request-URI is an asterisk (“*”), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server’s communication options typically depend on the resource, the “*” request is only useful as a “ping” or “no-op” type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.

A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a

body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of “0”.

The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero (“0”), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.

2) GET

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

The semantics of the GET method change to a “conditional GET” if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

The semantics of the GET method change to a “partial GET” if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.

The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.


The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.


The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

  • Annotation of existing resources
  • Posting a message to a bulletin board, newsgroup, mailing list,
    or similar group of articles
  • Providing a block of data, such as the result of submitting a
    form, to a data-handling process
  • Extending a database through an append operation.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

POST requests MUST obey the message transmission requirements set out in section 8.2.

5) PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,

it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying “the current version” which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

PUT requests MUST obey the message transmission requirements set out in section 8.2.

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.


The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.


The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the

origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.

TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.

If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of “message/http”. Responses to this method MUST NOT be cached.


This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).

“use strict”;

Tells the browser, please add some extra rules when you parse and try to execute my code.

The result is:
Object {}

With "use strict"; the result is:
Uncaught ReferenceError: perple is not defined

“use strict” says, you must declare a variable in order to use it. Which can be really helpful when you have mistyped errors, similarly spelled functions or objects and get squirrelly responses.

It can be used at the top of your file OR at the top of a function and must be on the first line.

What it does: (from Stack Overflow) –

  1. It catches some common coding bloopers, throwing exceptions.
  2. It prevents, or throws errors, when relatively “unsafe” actions are taken (such as gaining access to the global object).
  3. It disables features that are confusing or poorly thought out.

Angular Ionic Button State Override

Didn’t seem there was a real easy way to just add an “active” class and call it a day when trying to add a class with ng-class in my Ionic app. So in the provided css file from Ionic, (your-app/www/css) which btw, they have a gulp watch on – I added one single line with the !important rule, and gave it a background color a little darker than the regular button state and was done for now. I will be looking into this closer.

My next post will be exploring how to set a watch onto the my-app/sass/ file. I want to be able to override directly on the scss file and not create a ton of !important rules in the .css file they provide.

Editing Arrays

Array manipulation: shift, unshift, pop, concat, length, join, push

.length is not from 0 index but 1

.join – the ‘joiner’ adds words between items

There is no joiner after the last item.

.push adds an index to the end of the array

.unshift adds named thing to 0 index

.shift removed first element of array (accepts no params)

.pop removes last item of array (accepts no params)

.concat concatenates arrays

.slice returns a shallow copy of a portion of an array into a new array object

.splice changes the content of an array by removing existing elements and/or adding new elements.

.every() method tests whether all elements in the array pass the test implemented by the provided function

.some() method tests whether some element in the array passes the test implemented by the provided function

Using The Ionic Framework

I am learning to use Ionic to build JavaScript and AngularJS powered multi-platform applications. I will be revisiting this with more tips, issues and shortcut snippets as I come upon them. At this point, I am still early in my career as a JS developer, in the meanwhile this is what I offer:

Why Hybrid:

To run web pages (web applications) through a native component called the ‘WebView’. This allows you to to run a js application (which needs a browser) through this component.

There are frameworks that make it easy to run a webapp in a webview. The most popular, known as Cordova (an open source project) and PhoneGap (owned by Adobe and based on Cordova) that offers features and services on top of it.

Ionic let’s you write a webapp the same way you would for a website and (html, css, js) and package it as a mobile app with Cordova. If you just wrote a webapp from scratch yourself and showed in a webview, users would notice a weirdness in the responsiveness and look… Ionic gives you many components that have the same look and feel as native components, using appropriate styles and behavior for each platform.

Ionic is a front-end SDK for mobile applications containing components that mimic the native platform. Many components are written in css, so adding classes gives you immediate native interface look. More complex interactive components such as navigation and swiping are written in AngularJS and JS. It also includes a collection of icons as a css @font-face declaration.

Using the Ionic CLI:

View – To share your application with other for testing without needing to compiling to native code first
Creator – lets you design the UI and export a working Ionic project
Push – for push notifications




$ cd /Users/username/Development/android-sdk-macosx/platform-tools
./adb logcat
./adb devices

Revoke USB Debugging on phone
Restart ADB Server:
adb kill-server
adb start-server

$ cd /Users/username/Development/android-sdk-macosx
tools/android sdk
tools/android avd


ruby -e “$(curl -fsSL”
brew install homebrew/versions/node4-lts

Create a new project:

-> new name -> template
$ ionic start new-app-name maps
$ ionic start new-app-name tabs
$ ionic start new-app-name blank

Run Project In Browser:

$ ionic serve


(Navigate to project then…)
$ ionic platform add android
$ cordova platform add android
$ ionic build android
$ ionic emulate android ———————————–


1) Attach phone via USB
2) Open settings -> Developer Options -> Check (or re-check) USB Debugging
3) Navigate to application in terminal and run:
4) ionic run android -l (the -l is for livereload)

Run as IOS (new proj comes with it by default):

$ ionic platform add ios
$ ionic build ios
$ ionic emulate ios
$ ionic run ios

Preparing config.xml, splash screen and icon images

Open config.xml in the ww folder.
Change widget id to reverse domain to ensure uniqueness.
name field will probably need to be chnaged as well.
Further edit description, email and so on.
View Cordova docs for more details.
Generate icon and splash screen images (Ionic to the rescue!)
Use ionic help resources for a list of helpers
Overwrite /resources/icon.png with your new image.
Next command: ionic resources --icon to auto generate from that file.
Repeat process for “splash” screen images ionic resources --splash.

Packaging For Release In App Stores

View publishing details here.
Use $ keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
…to generate your key – change the path and alias to fit your needs
Keep your keystore certificate in safe place, you will need it for all app releases
CLI: ionic build --release android
It will create and UNSIGNED version, copy that version path and change the name to read “signed”
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore HelloWorld-release-signed.apk alias_name

    The above needs editing:

  • point to your local keystore
  • change path name to “signed”
  • edit to use your new alias

Updating your App

As you develop your app, you’ll want to update it periodically.
In order for the Google Play Store to accept updated APKs, you’ll need to edit the config.xml file to increment the version value, then rebuild the app for release.
zipalign your App
Go through the upload process, which asks for many photos, information and more so be prepared.

Publishing To Apple

You will need to ask apple to generate a certificate for you.
As a part of the apple developer program, you will have access to the “Member Center” which has a list of certificates, identifiers, devices and provisioning profiles.
For this case, use ‘App Store and Add Hoc”

readyState of a document

The readyState of a document can be one of following:
Ripped from

The document is still loading. TCP handshake is in progress.

The document has finished loading and the document has been parsed but sub-resources such as images, stylesheets and frames are still loading. The state indicates that the DOMContentLoaded event has been fired.

The document and all sub-resources have finished loading. The state indicates that the load event has been fired. When the value of this property changes a readystatechange event fires on the document object.

Stack overflow on the readystate numbers


Splice takes three arguments.
1) where to start removing items
2) how many to remove (zero removes nothing)
3) what to insert
It changes the original array.