I’m a musician turned full-stack developer living in NYC. Before studying code at The Flatiron School I attended NYU and worked at music startups like Next Big Sound and Songtrust. I care about creating innovative products with great user experiences.
Transactions allow us to execute batches of SQL operations either in their entirety or not at all. While this may seem simple, it is an incredibly powerful tool that solves incredibly important real world problems.
What are SQL transactions?
A transaction is a group of related SQL statements that will either be committed or rolled back, depending on whether the statements within perform as expected. Generally, SQL statements are implicitly committed to the database. Transactions commit statements to the database explicitly, allowing several related statements to be committed all at once or not at all. What’s the benefit? If two statements must occur concurrently, for example a transaction between individuals, non-transactional SQL runs the risk of implicitly committing the first before the second fails. If the statements are wrapped in one transaction, this can’t happen.
Let’s look at an example. My friend Lucas and I go to a bar. He pays for the drinks and requests $6 (because NYC bars are exorbitantly pricey).
Recursion is one of those classic computer science topics. It’s an interview favorite and often intimidating to beginner programmers. Recursion can provide elegant solutions to extremely complex problems that follow a pattern (e.g. Towers of Hanoi, Fibonacci Numbers, Collatz Conjecture).
How not to use recursion
If used incorrectly, recursion can be dangerous. Not all problems are meant to be solved recursively. Common pitfalls include infinite loops (if you fail to provide termination conditions), memory errors and stack overflows (if the function is deep and memory intensive). All of these issues are avoidable if you follow one rule: don’t use recursion for the sake of using recursion. In addition to the pitfalls above, irresponsible use of recursion can be much slower and more cryptic than iterative solutions.
Mongo’s relations are the NoSQL equivalent of associations found in relational databases. While serving a similar purpose and appearing similar in implementation, they do behave differently.
NoSQL relations vs RDBMS associations
Relations associate data from one model with data from another model. On a high level, this is precisely what RDBMS associations are for. However, the way in which data is associated in NoSQL is quite different.
In traditional relational databases, associations are used to relate data from one table to another. MongoDB and similar NoSQL databases are document-oriented (there are no tables), so relationships are drawn between document-objects instead.
What is a closure?
At first glance, a closure is simply a function defined within another function. However, the power of closures is derived from the fact that the inner function remembers the environment in which it was created. In other words, the inner function has access to the outer function’s variables and parameters.
One of my current projects — GitShoes was pretty straightforward. However, we quickly realized that users didn’t usually provide enough feedback for a developer to easily solve the problem. A few words (especially from a non-technical user) might not lead the developer to the root of the problem, so we decided to take things one step further.
“A picture is worth a thousand words.”
Our average issue was about 20-30 words long. So, if a picture is worth 1000 words, that means taking some quick screenshots at issue submission would make our app about 40x more useful. Seems like a no-brainer feature to me. But how do we make it happen?
A couple weeks ago, I was scraping Wikipedia and hit a wall while I was parsing the data. I eventually traced my errors back to my parser, which was failing to split a string on a space I knew should be present in each iteration. I dug further, and eventually isolated the iteration causing the failure. I copy and pasted the string into IRB to test the split myself and, as expected, the string couldn’t be split on the space. But the space did exist. It was there. I could see it. I tried writing the same string out by hand and splitting it. That worked.
The ActionView module is an awesome part of the Rails framework. It exists to handle template lookup and rendering and provides several helpers allowing you to minimize the back-and-forth between Ruby and HTML in your ERB templates.
If you’re developing a Rails application, you’ll most likely be making use of ActionView helpers within your templates. Rails will also be utilizing these helpers to create associations between different parts of your application based solely on naming conventions. ActionView is largely responsible for the power of the Rails framework that is provided by prioritizing convention over customization.
Git is an amazing tool for collaboration and version control, but its merits are largely unknown to the general public. Over the past few years, amazing collaborative tools (e.g. Google Drive) have become popular for word processing, spreadsheets and other common needs for the average person. However, these tools don’t offer sophisticated version control — they are limited to moving linearly backwards and forwards a certain number of steps.
One of the most compelling aspects of the Ruby language is the sweetness of its syntactic sugar. This made the almost ubiquitous use of the && and || operators over their semantically pleasing counterparts and and or all the more surprising to me. It turns out the two sets of operators are actually different in a meaningful way.
So what’s the difference?
Precedence. Huh? Precedence is the same as Order of Operations. Remember PEMDAS from grade school? It’s that acronym for Parentheses, Exponents, Multiplication, Division, Addition, Subtraction. The operators at the beginning of PEMDAS (parentheses) are considered first, then the next (exponents), and so on. Operator precedence in Ruby and other programming languages works the same way — there are just more operators. Got it? Got it. Moving on…