Useful CSS Trick to Keep Elements in Place on Hover

By giving elements a transparent border as a default, and changing the color of the border on hover, you can avoid moving other elements around the page when a user hovers over elements.


Do this:

button {
  border: 2px solid transparent;

button: hover {
  border-color: black;

Not this:

button:hover {
  3px solid black;

Now your other elements won’t move when a user hovers over the button.

TokBox – Building things on the Product Team

tl;dr I’m happily part of the product and growth teams at TokBox, working with the marketing team and others on efforts to help the company. I talk about what we do and some projects I’ve worked on. I enjoy being on the product team and dealing with the challenges that product teams face, balancing the future and the present.

What is a TokBox?

Time has flown by since last summer! I started working at TokBox over a year ago. It’s the premier  WebRTC platform company. We make it easy for developers to integrate video into their sites and apps. This means its easier for developer to build something like Skype, or Google Hangouts, or Facebook Live. Our customers range from side projects to massive companies across industries (in education – Duolingo, Chegg, Minerva; in finance and professional services – The Royal Bank of Scotland, Esurance; in entertainment – Fox Sports, Major League Baseball; and hardware and software companies like Double Robotics and Mozilla).

Who is a TokBox-er?

My coworkers are smart and experienced. They’ve worked for the innovative and the stodgy, from the tiny to the giant, including Mozilla, Google, Cisco, Twilio, Facebook, Telefonica, Adobe,  MobiTV, Scribd, Logitech, BlueJeans, Vodafone and more. Because of their experiences, I’m the real winner – TokBox is better, and I get to learn from all of them!

The culture is a good fit for me – yoga every Tuesday, occasional tea with the support engineers on the building deck, delicious catered lunch, weekly 1-on-1s with my boss. People try to have some fun, and have a sense of humor. I am thankful to be working here!

What, exactly, do yah do here?

What unifies my work is helping solve the problem of our users, who are mostly developers. The product team focuses a lot on trying to improve developer experience. I want them to have an easier time understanding what problems we can solve for them, and I want to solve their problems by using the OpenTok platform and our tools.  To accomplish this, I do full stack web development and solve product and growth problems. I use technology and tools I knew before (good old fashioned vanilla JavaScript, React, Node, jQuery, HTML, CSS, Jade, Stylus, Git/GitHub, WordPress). I’m adding new ones to my arsenal (DocPad, Jenkins, ReviewNinja, Docker, Elasticsearch, Kibana and more). I use tools like Google Analytics, HubSpot, AdSense, Tag Manager, and more. I lead user research sessions, and more.

I work closely with our awesome designers, PMs, marketing team, and more. I build web pages for new products and make improvements to the website and docs. I reduced the download time of our homepage by 40% by optimizing our assets and working with our DevOps team to tweak our CDN configurations.

We spend a lot of time improving our developer resources, and I get to play a big role here. We’re making our docs more usable for our developers by doing things like rearranging what resources live where, changing the information hierarchy of the site, redoing our homepage, creating an easier to use “Hello, world!”, and more. I lead some session on user research to help gather user feedback, which I used to identify issues and make recommendations on solving them – changes ongoing 🙂

I also work on special projects, e.g. building features on the React app where users manage their account, and help support growth initiatives for the product and marketing teams.

Product Is Where It’s At

Its great being on the product team. I like understanding and influencing what problem we’re trying to solve, what we’re building to solve it, and who we’re building it for as much as how we’re building it. On the product team, I get to learn about how to make a roadmap, prioritize features, develop and tweak process, see how teams work together across the organization, how designers think, how to gather feedback from user, how to incorporate feedback into the product and the product roadmap, how to strategize in relation to competitors, and how tradeoffs are evaluated and decisions are made. I’m very passionate about product and will become a product manager.

I’m wearing a ton of hats and it’s a good fit for me! I look forward to writing more about it soon.

We’re hiring for all sorts of positions! Check our openings out here 🙂

New Developments in JavaScript- Approval of ECMAScript2015, Announcement of WebAssembly

Times are exciting in internet land! ECMAScript2015 (aka ES6) has been approved, so the final specs are available for anyone to peruse. Read more about new features in a Treehouse blog post here or start fiddling around in your browser with some examples here or here.

Brendan Eich announced WebAssembly, and Axel Rauschmayer has a very readable blog post explaining it as well. In summary, the major browser players are all on board to help make a subset of JavaScript that compiles more quickly. This will be useful when performance is critical. Another bonus is JavaScript will load more quickly. Further, WebAssembly will make it easier to compile other languages for use in the web.

SQL vs NoSQL Databases – Part 2: Practice

This is part two of a two part series about databases. The first post focuses on theory, and this post focuses on the practical decision of which database to choose.

MongoDB, Redis, Cassandra, and CouchDB are some examples of popular NoSQL databases. There are a variety of types of NoSQL databases, based on either key-value pairs, documents, graphs, or columns (find out more here). MongoDB, a key-value store, has been extremely popular given how easy it is to set up and use. It comes with great flexibility, as schemas are dynamic (can be changed on the fly). If your data isn’t heavily interrelated, it’s a great choice.

Choosing MongoDB optimizes for developer time in part because of its flexibility. Setting up a MongoDB database is quick and easy. Further, your schema can be changed on the fly. As you store arbitrary objects in them, these objects can have completely different kinds of content in the fields; you don’t need to honor any schema. For this reason, it’s a great choice for projects where the schema is not well defined or could change. If you change your code, your data will go into your database with its new schema.

Further, this means you can change what your database is doing and keep your service running. Avoiding downtime is a big plus. The database won’t reject data of an unexpected type (a relational database most likely would). With smaller data sets, non-relational data is usually not a problem. Further, NoSQL is much easier to scale across many servers, and is cheaper. If all you need is simple persistent data, a NoSQL database will work well.

My group chose to use MongoDB for Glint, a forum for finding and getting feedback on project ideas. We wanted to optimize for developer time. Our needs were to track who contributed the idea, and the number of votes, so key-value pairs worked well. Upon scaling, we would consider transferring to a well indexed MySQL database to quickly see, for example, overall number of votes for a given user.

SQL has been around for years. It is battle tested at enormous scale. For a simple relational solution, SQLite exists as well. SQL databases offer powerfully interconnected data, meaning you can access and use the complex relationships within data. SQL is ACID compliant, which is a big deal. Further, well indexed data on well designed MySQL databases are performant.

Downsides to using a MySQL database include the database must be offline to easily restructure the tables. This means your service is unavailable during that time. More data generally means a bigger server. It requires some time thinking about data before using it- including the types of data you’re storing, and the important relationships between your data. It takes more time to set up for these reasons. SQL databases are less flexible – all columns have the same type of data and are the same size, defined ahead of time. The columns can’t be changed with ease to hold more characters. A new column can’t just be added to your table. Lastly, it is more expensive to maintain (you might need a dedicated Database Administrator for large datasets).

Appendix – A few useful database concepts:

CAP Theorem:
Normalized vs Unnormalized Data:

SQL vs NoSQL Databases – Part 1: Theory

This is part one of a two part series about databases. The first post focuses on theory, and the second part focuses on the practical decision of evaluating which database to choose for a project.

There are two kinds of databases: relational databases and non-relational databases. What is the difference, and what considerations are relevant when choosing which to use?

Developers refer to the contrast of relational and non-relational databases as SQL vs NoSQL. SQL represents relational databases. It is actually a query language for relational databases, most prominently MySQL. NoSQL, meaning Not Only SQL, is a more diverse collection of databases. It refers to any type of non-relational database. The use of NoSQL databases has grown in popularity over the last decade for a few reasons discussed in this post and the follow-up post.

Databases store data. Sometimes the data being stored is fairly straightforward. For a simple contact list, all you may need is a simple key-value pair, as in a person’s name and their phone number. You may just want a person’s phone number, accessing it using their name. For a task like this, a non-relational database works well. You can use a key to access its associated value (even if the value has more information than just a number- it could also have an address, a city, or more). The data can be stored essentially in simple key-value pairs.

A relational database should be used when the connections between data is important. If it makes sense to store the data in tables and rows, use a relational database. Tables and rows represent the underlying structure of relational databases.

This allows, for example, ease in finding all the entries with the same area code quickly. You can query multiple tables easily by joining them together. In a non-relational database, you would have to check each key-value pair, check if the value matches, and store that which of the numbers have the same area code.

Sometimes it is essential or helpful to keep track of many aspects of the data. I might want to easily access all my friends who have the same area code, or live on the same street or in the same city. This would take a long time in a non-relational database with many entries (unless you have a lot of redundancy, which takes up more memory- see the appendix here). However, it would be easy to perform this query in a well designed relational database. Once any two or mote tables are joined together, the new table can be easily queried. Joining tables allows for a variety of useful queries.

One of the main tradeoffs you get in the variety of available queries you lose in the convenience of set up. For example, in a MySQL database you have to define how many characters and what type of thing goes in a given column or row. This cannot be changed on the fly- most commonly, your database has to be disconnected when redesigning your database tables.

I’ll discuss in the next post how to choose a SQL or NoSQL database for your project.

JavaScript Framework Explosion

“Studies show that a todo list is the most complex JavaScript app you can build before a newer, better framework is invented.” -Allen Pike

Allen Pike published a great piece about the state of JavaScript frameworks.

It’s an exciting time to be in the JavaScript world. The language is getting more attention and tools daily. Companies and projects pick up and use new technologies in key roles before they hit fully stable, 1.0 releases. There has been an explosion in the number of frameworks for doing anything JavaScript, both on the client and the server.

JavaScript’s popularity has grown dramatically because it is the language of the browser. Only through JS can you make things happen in the browser. Developers use the language due to that privileged role and the widespread use of the internet (the fastest, widest distribution platform ever made). JS is THE choice if you’re developing client-side. Companies require many developers to use JS. Browsers are constantly changing, and leading developers to experiment more and more.

“…large, feature-rich JavaScript frameworks [make] slow, lumbering prey. A horde of young, nimble microframeworks swarm them, take them down, and fight over the meal. Modularity and componentization reigns.” -Allen Pike

The countless tiny frameworks make it hard for newcomers to the language to know what to use. It can have many negative consequences. Am I choosing the right framework to solve my problems, or are these 10 others a better choice? Will learning this framework provide lasting value, or will it be abandoned for others in a few months?

Developer attention on a framework contributes to its value. That’s what makes certain tools so great- developers using them and creating tools for them or directly improving them.

The tradeoffs of which framework to learn or use can be hard to navigate. It’s essential to identify which problems you’re solving, and which tradeoffs make sense for the project. Like most software engineering problems, it’s critical to know your needs.

It’s not clear if or when the JavaScript community will produce a clearly dominant frameworks. Angular is the current most likely contender. Perhaps a framework we haven’t heard of yet will surpass it, or one we know- React and React Native have been on people’s minds lately. Time will tell, and many more cleint-side JavaScript frameworks are certainly on the way. Hopefully each one solves a real problem, and learns about what works and doesn’t from the many recent frameworks that have been created.

‘This’, AKA The Context in JavaScript

What is ‘This’?

The creators of JavaScript incorporated the identifier ‘this’ to allow object oriented features. It can be confusing or unclear what the keyword refers to at any given time, so this post will give some helpful guidelines. I’ll explain what ‘this’ is, and then how to figure out what it refers to in your code.

In JavaScript, ‘this’, the context, is bound AT CALL TIME. 90% of the time ‘this’ refers to the object on the left of the dot at call time.

The keyword ‘this’ relates to the context, which means what variables are accessible and what their values are. It’s helpful to think of ‘this’ as a hidden variable automatically passed into any function when it is run. ‘This’ can be accessed anywhere within a function, much like the arguments object (which allows access to all the arguments passed into a function).

It’s worth noting that ‘this’ inside a function doesn’t necessarily refer to the function it appears within. ‘This’ is bound at call time, and some techniques such as bind, call or apply allow for explicitly setting the context by passing it in as an argument. These tools are useful when using JavaScript, for instance when using setTimeout.

To figure out what the keyword refers to, always look for the function body the code is enclosed within. In your debugger, find where that function was invoked by looking one level down in the call stack.

The 5 Rules of This

There are 5 rules for understanding what ‘this’ refers to, each related to a specific rule. If you figure out which pattern is in effect, you can identify what the keyword refers to.

1. Global Reference:’This’ Isn’t In A Function

When floating around in the wild, such as the simple program below, the binding target is the global object. In a browser, this is usually the ‘window’ object.

console.log(this); //this refers to the the global object

You might be asking why this is useful. This allows ‘this’ to be accessible from every part of your program, but otherwise doesn’t help much.

2. Free Function Invocation

When a function is invoked, and isn’t a method of an object, we call it free function invocation. Like before, ‘this’ refers to the global object, and isn’t particularly useful.

var func = function(){console.log(“Such wow”)};
func(); // ‘this’ inside func refers to the global object

3. Using .call or .apply

Here and below is where ‘this’ is really useful. The first argument passed into .call or .apply at call time will be what ‘this’ refers to inside the function. This allows us to do the following:; // inside func, ‘this’ refers to obj

Now within func, ‘this’ refers to obj. Now the following is possible, and powerful- you can pass in any object to a method, executing it as if it were a method of the passed in object! You can also pass in ‘this’ (eg to preserve the context.

setTimeout(secondFunc.bind(this), 1000); // the context of setTimeout is bound to secondFunc with bind

Bind allows you to create a function with a context you explicitly pass into it. The callbackfunction that consists of the function you pass in with the context you pass in, in this case secondFunc with ‘this’ at setTimeout’s call time. Without using bind to pass in a context, secondFunc’s context would have been the global object (often the window object). 1000 milliseconds later, we might get unwanted results (for instance, we would get an error if secondFunc depends on values inaccessible in global scope). When the callback returned from bind is executed in 1000 milliseconds, ‘this’ inside secondFunc refers to the context we passed into bind, so everything runs as planned.

4. Invoking A Method

‘This’ refers to the object on the left of the dot AT CALL TIME. The method doesn’t have a different context than its parent object: it just inherits its parent context.


When invoking a method, ‘this’ refers to the object housing that method. Methods run in the context of the object to which they’re bound. They can easily access the values of the objects they are housed on, making methods more useful. You will see this pattern all the time when using JavaScript.

5. Construction Mode

The last pattern to know about ‘this’ is when an object is created using a constructor aka making an instance of a class. These are usually designated with an uppercase ClassName and have the word ‘new’ before it (like below). A new context is created for each invocation, and the value of ‘this’ is the new object.

var instanceOfClass = new ClassConstructor(parameters);

Now, anytime within instanceOfClass, ‘this’ will refer to itself. This is useful for assigning properties, which is done by passing in arguments (values) to the ClassConstructor. Constructors now operate on the instance they are creating, and it’s easy to create instances and assign them properties.

When ‘this’ appears in working JavaScript code, one of the above patterns will be present. Figure out which is happening, and you’ll know what you can expect ‘this’ to refer to. 90% of the time ‘this’ refers to the object to the left of the dot at call time.

Happy coding!