Touchy Feely Events


Touch event types:

There are several types of event that can be fired to indicate that touch-related changes have occurred. You can determine which of these has happened by looking at the event’s TouchEvent.type property.

touchstart: Sent when the user places a touch point on the touch surface. The event’s target will be the element in which the touch occurred.

touchend: Sent when the user removes a touch point from the surface (that is, when they lift a finger or stylus from the surface). This is also sent if the touch point moves off the edge of the surface; for example, if the user’s finger slides off the edge of the screen. The event’s target is the same element that received the touchstart event corresponding to the touch point, even if the touch point has moved outside that element. The touch point (or points) that were removed from the surface can be found in the TouchListspecified by the changedTouches attribute.

touchmove: Sent when the user moves a touch point along the surface. The event’s target is the same element that received the touchstart event corresponding to the touch point, even if the touch point has moved outside that element.

This event is also sent if the values of the radius, rotation angle, or force attributes of a touch point change.

touchenter: Sent when a touch point enters an element. Note: These events don’t bubble.

touchleave: Sent when a touch point exits an element. Note: These events don’t bubble.

touchcancel: Sent when a touch point has been disrupted in some way. There are several possible reasons why this might happen (and the exact reasons will vary from device to device, as well as browser to browser):

  • An event of some kind occurred that canceled the touch; this might happen if a modal alert pops up during the interaction.
  • The touch point has left the document window and moved into the browser’s UI area, a plug-in, or other external content.
  • The user has placed more touch points on the screen than can be supported, in which case the earliest Touch in the TouchList gets canceled.

View Source:

Image Source: (really helpful tips on jQuery libraries to use to achieve the touch gestures in your native or mobile web app)

Explain the difference between “Responsive” and “Mobile First”

Photo source: Metamonks

Responsive design is something we’ve all learned to love. Being able to seamlessly scale down a page and have the site respond to the different sizes. Whether this is reducing fonts, scaling images down, or hiding parts of the app’s functionality that weren’t intended to work on mobile devices. Responsive design starts from the desktop browser and then scales down accordingly (as pictured above). However, “Mobile First” is a new way of approaching design, starting with mobile… first.

Instead of starting from the browser and hiding the javascript elements or flash banners that don’t work as well on mobile (but are still present and slowing down your app), Mobile First design focuses on the key content you want to display to your users. Then we scale up from there. This approach to design will improve the usability, organization, cleanliness, and speed of your app. 

Explain the diff b/t private and protected methods:

I have looked this up countless times in the last three months. And I am determined to get this straight. 

All methods are public in ruby by default.

Private means the method is private to this instance. Private methods can not be called with explicit receivers. 

Protected means the method is available to any instance of the class and is also available to the children of that class and subclass. Protected methods can be called with explicit receivers.

In the example below self.a and other_object.a are examples of explicit receivers. Therefore self.a and other_object.a would work if the method was protected. However, because “a” is a private method, these explicit receivers will not work. 

See example from Wikipedia: 

To truly understand the difference I had to do a bit of research on the difference between implicit and explicit receivers. Which I understood after reading Matt Hodan’s example:

"We’ve created a “Parent” class and a “Child” class that is a sub-class of Parent. Parent has a private method “name” that returns the value “Mommy”. When we call “” on line 18, we see the output produced by lines 12-14. Only when the Parent’s method “name” is called with an implicit receiver do we get a return value.

What does this mean? This means that private methods can only be called within the context of the current object (since any context outside of the current object would require an explicit receiver). I.e. one object cannot access another object’s private methods.”

If you were to change Private to Protected in the above two examples, then all three instances of explicit and implicit methods would work! 

View Matt’s full blog post here.

Is there an alternative to the box model? If so, how/why would you use it.


box-sizing: border-box;

If you did *{ box-sizing: border-box; } - this would effect the box model across the entire page.  

Why would you want to do this? Say you have two columns on a page with a margin of 10px on the right and left side of each column. You want to make the column text area 100%, but you don’t want this to cut into the 10px margin you have already set. Instead of having to reduce the 100% text area width to accomodate for the 10px margin, you can add the box-sizing: border-box style, this will overwrite the standard content-box default. 

View demo

Demo Source:

Explain the diff. between a module and a class

Classes are about objects. Classes create your database, but do not always have to be included in your database.

Modules are about functions. Bite size libraries - like in user authentication that you can use to do small parts of your app.

The difference was most clearly explained here:

"Modules are collections of methods and constants. They cannot generate instances. Classes may generate instances (objects), and have per-instance state (instance variables).

Modules may be mixed in to classes and other modules. The mixed-in module’s constants and methods blend into that class’s own, augmenting the class’s functionality. Classes, however, cannot be mixed in to anything.

A class may inherit from another class, but not from a module.

A module may not inherit from anything.”

The difference between hashing and encryption.

Two of my three most recent apps have had user authentication from scratch. It was a huge pain in the ass to learn. But it got easier the second time around. At General Assembly, we were instructed to use Bcrypt. I was never really sure why we choose Bcrypt over other encryption methods… until today.

Bcrypt uses hashing, not encryption. This is an important distinction. Hashing has a one-way mapping function, whereas encryption has a two way mapping function. 

One way meaning, the password is encrypted once and can not be decrypted or reverse engineered. (I’m sure it can in some way, but it is really really difficult). When a password is hashed even the developer will not be able to retrieve the user’s password.

Encryption on the other hand, is a two way mapping function. The password is encrypted once stored, but can be decrypted, just in case the user or the developer need to be able to retrieve that password at some point in time.

Hashing passwords is a more secure way to store user sign in data than encrypting passwords.

Read more about the distinction on Stack Overflow: (answer below)

Hashing is a one way function (well, a mapping). It’s irreversible, you apply the secure hash algorithm and you cannot get the original string back. The most you can do is to generate what’s called “a collision”, that is, finding a different string that provides the same hash. Cryptographically secure hash algorithms are designed to prevent the occurrence of collisions. You can attack a secure hash by the use of a rainbow table, which you can contrarrest by applying a salt to the hash before storing it.

Encrypting is a proper (two way) function. It’s reversible, you can decrypt the mangled string to get original string if you have the key.

The unsafe functionality it’s referring to is that if you encrypt the passwords, your application has the key stored somewhere and an attacker who gets access to your database (and/or code) can get the original passwords by getting both the key and the encrypted text, whereas with a hash it’s impossible.

People usually say that if a cracker owns your database or your code he doesn’t need a password, thus the difference is moot. This is naïve, because you still have the duty to protect your users’ passwords, mainly because most of them do use the same password over and over again, exposing them to a greater risk by leaking their passwords.

Reflecting on my first technical interview.

Learning to be comfortable with how much you know, you don’t know.

Standing desk music!

Tic Tac Toe!

Today is a great day! I got tic tac toe up and running using angular-jsfirebaseapps:

Yea, our class is pretty awesome @GA #WDI

Yea, our class is pretty awesome @GA #WDI

Spaceman crashing the fat boy slim party! (at Sahara Tent)

Spaceman crashing the fat boy slim party! (at Sahara Tent)

Bonobo (at Coachella Polo Fields)

Bonobo (at Coachella Polo Fields)

4/9/14: Day 3 | CSS Specificity

Something that I never quite figured out on my own was CSS specificity. What trumps what? Are there exceptions? Isn’t it just a cascading style sheet, so doesn’t it just show whatever appears last? 

Well, yes and no. It depends on the specificity! The general rule of thumb is ID > Class > Element/tag… but there are two exceptions (see below!):

1. Id (#): Most specific! Id’s will trump classes and element/tags. 

html: <div id=”main”></div>

css: #main {background: #1C3148;}

2. Class (.): Second most specific! Classes will trump element/tags but will not trump Id’s.  

html: <p class=”caption”>This is a caption for a photo!</p>

css: .caption {color: white;}

3. Element/Tag: Element tags are the least specific. 

html: <li>This is a bullet point</li>

css: li {color: yellow;}


  • inline styles overwrite most cases.
  • !important overwrites pretty much everything, but many people advise against using this in your CSS.