Created
July 14, 2014 20:28
-
-
Save richardking/c9b8bded0e5236ef31e2 to your computer and use it in GitHub Desktop.
iSheet
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Terms | |
### General Programming/CS | |
**Threads** vs **Processes** | |
A process is an instance of a program in execution. A process is an independent entity to which resources are individually allocated. | |
One process cannot access another process's variables and data structures. | |
One process can have many threads. | |
Threads within a process share resources, including heap space. | |
Each thread has its own registers and stack, but other threads can read and write the same heap memory. | |
**Interpreted** the code you write is executed on the fly | |
+easier to implement | |
+no need to spend time compiling | |
**Compiled** the code you enter is reduced down to a set of machine-specific instructions before being executed | |
+faster performance | |
#### Paradigms | |
Imperative | |
Declarative | |
**Object Oriented** Rather than structure programs as code and data, an object-oriented system integrates the two into a concept of an 'object'. An object is an abstract data type that has state (data) and behavior (functions). | |
**Functional** paradigm that centers around evaluating functions and avoids state and mutable data. Emphasizes functions that produce results that only depend on their inputs | |
**Pass by reference** like passing a url around. If the webpage changes, everyone with that url sees that change. | |
**Pass by value** like passing a copy of the webpage around. If the original web page changes, that person won't see the changes | |
--- | |
#### SOLID Principles | |
Single responsibility | |
Open/Closed | |
Liskov's Substitution | |
Interface segregation | |
Dependency inversion | |
**stack** It's a special region of your computer's memory that stores temporary variables created by each function | |
- the stack grows and shrinks as functions push and pop local variables | |
- there is no need to manage the memory yourself, variables are allocated and freed automatically | |
- the stack has size limits | |
- stack variables only exist while the function that created them, is running | |
**heap** a region of your computer's memory that is not managed automatically for you, and is not as tightly managed by the CPU. It is a more free-floating region of memory, and is larger. | |
**stack** LIFO data structure | |
**queue** FIFO data structure | |
**Function overloading** the ability of a method with one name to perform different tasks based on how many arguments are passed in. In Ruby, you can use default values. | |
**tail recursion** if a function calls itself as its last action, the function's stack frame can be reused. Thus, tail recursive functions are an iterative process. | |
-if input data is not susceptible to deep recursive chains, write your function as clear as possible, which probably won't be tail recursive | |
-with a compiler or interpreter that treats tail-recursive calls as jumps rather than function calls (called *tail-merging*), a tail-recursive function will execute using constant space (essentially iterative) | |
-the caller's return position need not be saved on the call stack; when the recursive call returns, it will branch directly on the previously saved return position. | |
-resues the calling function's stack frame rather than creating a new stack frame. | |
--- | |
### Data Structures | |
#### Hash tables | |
Hash code- | |
**collisions** always an issue | |
**systematic biases** | |
should be **evenly distributed** | |
Re-sizing hash tables | |
once we discover we will be storing more items than we had anticipated | |
#### Graphs | |
vertex | |
edge (connecting two vertices) | |
undirected/directed graphs | |
weighted graphs | |
#### Binary Trees | |
unbalanced vs balanced | |
**Depth-first** | |
Pre-order: | |
1) Visit the root | |
2) Traverse left subtree | |
3) Traverse right subtree | |
In-order (symmetric): | |
1) Traverse left subtree | |
2) Visit the root | |
3) Traverse the right subtree | |
Post-order: | |
1) Traverse left subtree | |
2) Traverse right subtree | |
3) Visit the root | |
**Breadth-first** traverse all elements in one level of the tree before going to a lower level | |
--- | |
#### Algorithms | |
**Greedy algorithm** an algorithm that follows the problem solving heuristic that by choosing the locally optimal choice at any stage, you'll end up with the global optimum. | |
**Amortized time** average time taken per operation, if you do many operations | |
-doesn't have to be constant amortized time, can be linear amortized time, logrithmic amortized time | |
##### Sorting | |
Insertion sort- sorted list|unsorted list. compare one item in unsorted list to sorted list. move item in sorted list as we encounter them. | |
Bubble sort- compare a[i], a[i+1], if a[i+1] is < a[i], then switch them. | |
Merge sort- recursively splits down to 1-unit arrays and merges together. | |
Disadvantage is a lot of memory use (copies original array into temporary array). | |
Time and space complexity: | |
constant space complexity means that the amount of space needed is independent of input parameters. | |
--- | |
OOP | |
Has-a relationship | |
**Composition** Obj A owns Obj B. B has no purpose or meaning in the system without A | |
**Aggregation** Obj A uses Obj B. B exists independently of A | |
### Ruby | |
##### Characteristics of OOP | |
**Encapsulation** technique of making data in a class private and providing access to them using public methods | |
**Abstraction** the process of moving from a specific idea to a more general one | |
**Inheritance** the way a class can get its features from a parent class | |
vs **Composition** a class made up of several smaller classes, delegates to them for functionality | |
**Polymorphism** ability for many forms (types) to present the same interface | |
-**duck-typing** doesn't matter what the type is as long as it responds to a certain method | |
--- | |
**Class** a collection of related methods that operate on the state of an object. It can be instantiated, to create an instance of that class | |
**Module** similar to a class, except it cannot be instantiated. Usually used to namespaced methods, and use as mixins to classes. | |
**Constructor** using #initialize | |
**Singleton class** a unique class inserted in between an instantiated object and its real class. | |
**Closure** a first-class function, it remembers the values of the variables that were in scope when the function was created. It is then able to access those variables when it is called even though when they may not be in scope. | |
**Method** is on an object | |
**Function** is independent of an object | |
**Break** exits from the innermost loop | |
**Return** exits from the entire function | |
**Rails engine** allows you to wrap a Rails app or a subset of its functionality in a way to make it easily shareable with another Rails app. You can then mount it into routes for another Rails app. | |
**Rack** A webserver interface convention, allows middleware to communicate with each other | |
**Rake** a Ruby gem that makes the running of jobs easier; allows you to configure dependencies between jobs. | |
#### Other Ruby concepts | |
>&object is evaluated in the following way: | |
> | |
>if object is a block, it converts the block into a simple proc. | |
>if object is a Proc, it converts the object into a block while preserving the lambda? status of the object. | |
>if object is not a Proc, it first calls #to_proc on the object and then converts it into a block. | |
Observer pattern: a software design pattern where an object (the subject) maintains a list of its dependents (the observers), and notifies them automatically of any state changes. | |
Value objects- represents a value, and its job is not to do things, but to answer questions about that value | |
How Ruby passes variables around: | |
http://stackoverflow.com/questions/1872110/is-ruby-pass-by-reference-or-by-value | |
#### Rails | |
**ActiveRecord Concern** provides a mechanism for composing modules, so one module can easily be mixed into a class and provide both class and instance methods. | |
**Controllers** Once a request hits the Rails stack, it uses the routes file to determine which controller and action to hit. | |
**Views** Presentation layer- HTML/JS that the user sees in the browser, rendered based on what the controller calls | |
-**Layouts** reusable snippets of HTML for views. | |
**Models** Interaction with the database to store, validate and retrieve data. Business logic. | |
#### Other Rails concepts | |
Caching: | |
Fragment caching (Rails) | |
Page caching (Rails, though removed from Rails 4) | |
- won't hit controller action, just will serve up pre-generated html | |
- cannot be used with pages that need authentication, or dynamic pages in general | |
Action caching (Rails, though removed from Rails 4) | |
- will actually hit the controller action, so before_filters and authentications can be run | |
Database record caching (through json, memcached/redis) | |
fastly/varnish caching | |
Table associations: | |
has_one/belongs_to -- foreign key goes on the table for the class declaring the ```belongs_to``` association | |
#### RSpec | |
Shared fixtures makes tests hard to understand in the future, and hard to update. Add an attribute and other tests break. | |
### Git | |
**Merge** will take two branches and merge the commits, and they will be in chronological order and there will be a new commit stating the merge is done | |
**Rebase** rewinds head to common point between two branches, replays 2nd branch commits, then main branch commits | |
### Databases | |
**Normalization** is the process of efficiently organizing data in a database. There are two goals of the normalization process: eliminating redundant data, and ensuring data dependencies make sense. | |
-Denormalizing data could make sense when you are doing a lot of database reading; e.g. data analysis. | |
**Single Table Inheritance** idea of using a single table to reflect multiple models that inherit from a base model. Uses a column 'type' | |
**Eager loading** (N+1 problem) database query optimization strategy to reduce the number of calls made to DB. e.g. User.includes(:email).limit(10) | |
**ACID** Compliance | |
A-- atomicity | |
C-- consistency | |
I-- isolation | |
D-- durability | |
**Cardinality** refers to the uniqueness of data values contained in a paricular column (attribute) of a database table. The lower the cardinality, the more duplicated elements in a column (probably don't need to index low cardinality columns) | |
**Full table scans** scan where each row of the db is read in sequential order and the columns are checked individually to see if it matches the condition. Usually means an index needs to be created. | |
**Optimizing using EXPLAIN** | |
-shows how tables are joined and in what order | |
-can tell if you need to add more indexes | |
**Concatenated (multi-column, composite, combined) index** | |
-column order is important | |
-can search on combination of all columns, or first column listed | |
### General Internet | |
**SOAP** | |
**REST** architecture, usually over HTTP, that is stateless to create/read/update/delete data. | |
**HTTPS** Uses same HTTP protocol, layers SSL/TLS encryption layer on top of it. | |
SSL layer has 2 purposes: | |
1) Verifying that you are talking directly to the server that you think you are talking to | |
2) Ensuring that only the server can read what you send it and only you can read what it sends back | |
Steps: | |
1) Handshake between client and server | |
2) Certificate exchange between client and server- server sends over SSL certificate (which includes public encryption key), client either implicitly trusts it or verifies it with CAs | |
3) Key Exchange- both parties agree on same key for encryption/decryption (client generated, encrypted with public key in SSL cert, sent over to server) | |
**HTTP** transmission (request-response) protocol for sending/receiving data in the client/server computing model | |
**HTTP Request** consists of: | |
-a request line (such as ```GET /images/logo.png HTTP/1.1``` | |
-request headers (such as ```Accept: text/plain```) | |
-an empty line | |
-an optional message body (usually for POST requests) | |
**HTTP Response** consists of: | |
-a status line (such as ```HTTP/1.1 200 OK```) | |
-response headers (similar to request headers, such as ```Content-Type: text/html``` | |
-an empty line | |
-an optional message body (with html etc) | |
### Systems Architecture | |
**Nginx** web server, can serve static files better. Also some app (Rails) servers can only handle 1 request concurrently. | |
### Misc | |
**Bit** a binary '0' or '1' | |
**Byte** 8 bits | |
**Bitwise NOT** unary operation, takes each bit and performs logical negation | |
**Bitwise AND** takes two binary representations of equal length and performs logical AND operation on each pair of corresponding bits | |
**Bitwise OR** takes two binary representations of equal length and performs logical OR operation on each pair of corresponding bits | |
**Bitwise XOR** 0 if both are 0 or both are 1; 1 otherwise | |
**ASCII** 128 characters | |
**Unicode** | |
### Interview problem solving tips | |
- use pseudo-code | |
- draw out problem | |
- see if it matches up with algorithm (tree, hash, etc) | |
common mistakes | |
-ignoring requirements | |
-missing edge cases/ off-by-one errors | |
-check to confirm initial case works | |
-check all possible inputs | |
### Other links | |
http://superuser.com/questions/31468/what-exactly-happens-when-you-browse-a-website-in-your-browser | |
http://www.sorting-algorithms.com/ | |
Heaps explained: | |
https://www.youtube.com/watch?v=v1YUApMYXO4 | |
TEMP | |
Most challenging -insta | |
What you learned -insta | |
Most interesting –insta, docker | |
Hardest bug – user tag | |
Enjoyed most –insta docker | |
Conflict with teammates – wanting a bigger role | |
Stories: | |
Docker | |
Started learning it on my own based on HN mentions and my experiences deploying an app to production. Learned enough to write a blog post and present to the engineering team and driving the adoption of it at BR. | |
-interest came from HN mentions, and the fact that it always took a long time to get a side project onto production | |
-started researching myself | |
-asked to go to Docker conference to learn more | |
-brought up a side project on EB/Docker on my own | |
-first in company | |
-wrote blog post on docker | |
-presented to our team about docker | |
-drove the adoption, helping other out to get on it | |
UserTag deletion bug | |
Wasn’t technically difficult, but one of those sporadic, can’t reproduce bugs. Took the lead and found good places to put logs in prod. | |
-worked with mobile team and front end manager to track it down. | |
-happening sporadically | |
-no one could track down for months | |
-hard to tell what was going on except a few reports from users here and there. Could’ve been user error | |
-a few people in the company got their teams deleted | |
-signed up for papertrail | |
-https://github.com/br/breport/pull/4297 | |
-found the model code that updated topics | |
-added logging around that | |
-then found all the controller code that called that updating code | |
-added logging around that | |
-one api endpoint for mobile, one api endpoint for desktop | |
-compiled all information related to mobile and sent it over to the mobile guys | |
-found all the javascript files that called the controller code, sat with front end manager and walked through it all a few times | |
-found a snippet that fired on a pretty generic close class, which ended up firing a call to the api a few calls deep. That call depended on the users tag being populated in the DOM, and on an errant call, the DOM wasn’t populated, so it sent an empty array which deleted the user’s teams. | |
-my project from end-to-end | |
-creative engineering to make it work seamlessly to our admins | |
-used oop principles (metaprogramming, ducktyping) for clean code reuse. | |
- Instagram did not have real time firehose. Their consumption api was actually kind of poor. Needed to come up with a creative engineering solution, couldn’t just give a list of instagram accounts to consume. Created a instagram account, created hooks in our admin to follow/unfollow other accounts, then we could use our normal api to pull all images from that account’s feed. This was polled regularly and then logic applied here | |
-Used metaprogramming and ducktyping to DRY out code because between twitter/instagrams, used some similar parent/child and keyword filtering logic. | |
Frustrations with role | |
-very open about it. | |
-a lot of one-off bug fixes, database updates | |
-Met with manager and prod manager to express my frustration with recent workload. They mentioned that it naturally became that way because a ticket assigned to me would get done quickly and correctly. | |
-met with them over the course of a week to talk about future projects, give me ‘meatier’ tickets | |
-was a small shift but wasn’t super excited with the pipeline | |
-build more than maintain | |
Json caching bug | |
I feel like I’m completely in my comfort zone at BR. I did some work-related projects on my own to try and step out of it and continue to learn, but I’d rather go to a company where that’s part of the work and culture. | |
Project | |
- data is pretty simplistic, only one model | |
- but has async processing, Capistrano deploy, automated mailer, attempted api | |
o api: post to /api/checks | |
- runit to keep scheduler process up |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment