Skip to content

Instantly share code, notes, and snippets.

Lawrence Walters lawrencewalters

  • Chicago, IL
Block or report user

Report or block lawrencewalters

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@lawrencewalters
lawrencewalters / gist:4c5cd0e2913a120720d2cb506d94f2a2
Created Mar 4, 2019
use bash to generate password with diceware word list
View gist:4c5cd0e2913a120720d2cb506d94f2a2
for run in {1..6}; do shuf -i 1-6 -n 5 -r|perl -ne 'chomp;print' | xargs -I pattern grep pattern diceware.wordlist.asc; done
View windoze text editors.md

NeoVim 0.2.2

after exploring neovim for a couple days, here are the things on windows 7, 2018-04-20:

good

terminal inside it seems awesome

bad

View Pentaho - RabbitMQ integration.md

Pentaho - RabbitMQ on Windows Proof of Concept

RabbitMQ install

Went with the manual install (kept getting an error on erlang not being available;

Erlang could not be detected. You must install Erlang before installing RabbitMQ. Would you like the

View Basic Ruby on rails - The Rails Philosophy.md

Explain how "convention over configuration" allows us to be more productive as a group.

Convention over configuration gets all the basics out of the way. All the tiny decisions like "how should I organize my project file structure" that could involve a lot of thinking (how do I future proof this?) are already made - by convention. We learn the same, single convention, and then we all follow it. This means when we switch projects, or start new, we don't spend a lot of time figuring out basic context - we can get right to the heart of the functionality we are working with. Another higher level example is akin to the shopping cart platform. Assume we are building a transactional ecommerce website. If we start with an off the shelf product that has a home page, PDP, cart, checkout - the basic stuff is already done for us. There's no reason for us to rethink this very straightforward thing that thousands of people have already built. This lets us move right to the interesting parts - customizing it for our busine

View Strategies for Better Testing.md

Strategies for Better Testing

Understands how "writing the code you want to see" makes for better code

Explain the theory around 'writing the code you want to see'.

Writing the code you want to see is all about making your code focused on the application's functionality, not on how you want to build it. Many times as developers we want to get right to writing the code, because we have some idea of how the application can be built. If we instead start by documenting what the application should do - via tests - we will write code that is focused on the functionality. Our code design will more closely model the functionality, instead of how we thought it should be built before we started considering what it would actually do from a user's perspective.

Create a short gist illustrating a place where violating this rule would cause you to write worse code.

View Shopping Cart.feature
Feature: shopper shops
As a shopper
I want to a decent shopping experience
So I can buy a ton of stuff easily
Scenario: add to cart
Given I am on a PDP
When I click Add To Cart
Then I should see this product in the minicart
View It's Not All Automatic.md

It's Not All Automatic

Knows why manual testing doesn't scale

Name some cases where manual testing is preferable or necessary to verify code.

When visual design changes are made - it's exceedingly difficut to validate design changes automatically, especially when they don't impact the functionality.

Usability - if usability is important (it always is), an automated test won't tell you if you've made some changes that hurt it (like creating a div that hides buttons or links - the machine tests are not going to realize this)

@lawrencewalters
lawrencewalters / Your Toolbelt.md
Last active Aug 29, 2015
Basic Test Engineering - Your Toolbelt
View Your Toolbelt.md

Basic Test Engineering - Your Toolbelt

http://leveluprails.herokuapp.com/test.html

Uses and understands unit, functional and integration tests

You've now written two types of tests. Name them, and explain the differences.

@lawrencewalters
lawrencewalters / gist:2497526908599e2b4e32
Created Sep 16, 2014
level up rails Ruby Basics answers
View gist:2497526908599e2b4e32
Explain how the Five Second Rule for code review works.
The five second rule is the concept that if you can't understand the intent of a line of code or method in 5 seconds
then it is likely that item is too complex, and needs to be broken down into more easily understandable components.
Knows why comments lie, and how to write self-documenting code
The phrase "comments lie" refers to the fact that because comments are not a part of the working application,
they are never tested, reviewed, or used in production. Because of this, as bugs are found, or enhancements
are made, the functionality is verified, but the comments are never validated in any consistent way. Thus,
You can’t perform that action at this time.