DEV Community: Chase Stevens

Weekend Hacking -- What Projects Are You Working on This Weekend?

Chase Stevens — Fri, 08 Feb 2019 16:03:39 +0000

Happy Friday, dev.to!

We all have interests and areas that we want to explore, and we also have obligations during the week. The weekend is a great time to carve out some time for yourself, learn something new, explore a new idea, or work on your side project.

This weekend, I'm working on a blog post explaining the Ruby on Rails Model-View-Controller architecture using a restaurant as an analogy. I've also signed up for a Python open hacking session on Saturday morning. My idea right now is to make something like a chat client, but instead of talking to a friend or coworker, you talk to a wise and mentoring rubber duck who will help you debug your code.

I wanted to reach out and see what everyone else is up to -- what are you going to be hacking on this weekend?

Overcoming the Tutorial Gap and Making Your Own Software

Chase Stevens — Tue, 05 Feb 2019 16:30:45 +0000

When learning to code, it's easy to fall into what some have named the "Tutorial Rut". There's so much to learn and so much content to follow along with that you churn out tutorial after tutorial, running through the motions and working out your fingers without getting to the root of software development and tapping into the flow of creation.

Following along with a tutorial takes out a lot of the hard parts of software creation -- you already know what you're going to build and when you're stuck, you have the answer right in front of you. When you're making something from scratch, you may have a vague idea of your project, but you don't know every feature that will be implemented.

I know I've been there. Here are some of the things that help me.

Take Part In The Community

Go to meetups! Talk to other developers. They've all been where you're at. You'll have a chance to meet like-minded people, eat free food, and hear speakers present on interesting and new ideas. Plus, the organization hosting the meetup is probably hiring.

Go to a Hackathon

Hackathons are awesome and exhausting. You're surrounded by a whirlwind of development and creation, you have a team of volunteers who are there to help you be successful, and you get free food and swag! I can think of no better way to get experience with coding than by taking place in a hackathon.

Even if you don't feel comfortable coding, you can still help with the presentation and with the documentation of the product. It's a perfect, low-stakes environment to be a part of a programming team and something you can bring up in interviews or put on your resume.

Make Jokey Arty Things

The apps and websites you use every day have entire teams dedicated to portions of their app that you've never even thought of. You're not going to become a DevOps expert overnight, so why not use the tools you have to make something fun? Go to a site like codepen.io or glitch.com and put up a fun little code snippet. Focus on making something visual instead of moving data around.

Here's an idea: recreate 10Print and show off how you can create your own universe. Or make Purple Rain Or just mess around! (note: don't follow these like a tutorial. that's against the rules of this article.)

Get Inspired (and Rip Something Off)

Instead of thinking about what would be cool to build (vague), or trying to imaging what could be a billion dollar app (yeah right), pick an existing product that you use and recreate it.

airbnb.com
twitter.com
tinyurl.com
dev.to (@ben)
news.ycombinator.com

Here's the secret -- there's absolutely no way your app will be better than theirs. They have had time and developers on their side, and they probably know more about the space they're in than you do. What you get is a guiding light that you can refer to, and a site that you can inspect and check out the code. If it's open source, even better! You can dig into the repo and see exactly how they made the thing that you're making now.

Write About Your Project

Measure twice and cut once. It does feel great to enter into the terminal "rails new my-blog" or "npx create-react-app my-blockchain" and start typing up some code willy-nilly, but in reality, most work that developers do is debugging, testing, documenting, or thinking about and designing the code they want to write rather than mindlessly hacking away in their IDE.

Think about your project -- what you really want to make -- and write down exactly what features you are going to include. Put this into a document called a "Product Spec." Product Specs turn in pseudo code turn into real code. Writing a product spec helps you design your project and come across potential pitfalls that are much better to make early on instead of after you've been programming for two weeks and realize you have to throw everything out and start over.

For more help and wisdom, check out [Joel Spolsky's blogposts] on writing product specs(https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/). He's one of my favorite tech writers, and he was a Program Manager at Microsoft working on Excel as well as founded Trello and StackOverflow.

Make Something 50 Times

Not a joke. Take something simple that you do know and write it 50 different ways. Vi Hart wrote about her experience writing Fizz Buzz fifty times demonstrating how setting constraints can be liberating, and how

Have Fun

Play around with your language of choice's REPL. Open up Vim and try to exit it. Change this article's title in your browser to "poop." Get cowsay to say something to you whenever you start up the terminal. Have fun! Coding is a creative and fulfilling endeavor, and you should take the time to enjoy the fruit of your labor.

Now go out there and make something!

Getting Started with Test Driven Development

Chase Stevens — Fri, 18 Jan 2019 19:52:26 +0000

Test Driven Development is considered to be a best practice in the software industry, yet many teams ship code without tests.

What it is

Test Driven Development, or TDD, is a method of creating software by writing tests before writing code.

Uncle Bob describes TDD with three rules:

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

It may seem unintuitive to write tests for code that doesn't exist yet; however, by writing tests first, we ensure we have a clear expectation of what our code will do, and we also guarantee that we don’t procrastinate and table writing tests until it’s too late.

While it may seem easier to jot down whatever code comes to mind and hack your code together until the compiler runs, you’ll end up spending more time me debugging your hastily written code than you would writing tests, which leads to substandard code and, even worse, you don't have any tests written for the future.

Tests may not be necessary for small projects or coding exercises, but for maintaining the health and stability of your programs and projects for the foreseeable future, test driven development is the way to go.

Why it matters

Some people take test writing so seriously that they adopt the mantra “If it’s not tested, it’s broken.”

Test Driven Development helps immensely with debugging and cuts down on time that would be spent hunting down bugs.

One benefit of writing tests first is that they don’t get lost in the shuffle. Say you’re on a tight deadline and as a time saving measure, you skip writing tests. You ship the new feature and then you’re back to the grindstone, with the same deadline, having to cut testing from your development. Soon, you’ve shipped an entire codebase with buggy code and no tests!

By using test driven development and writing the tests first,

How to implement it

Many programming languages have libraries and frameworks for testing. JavaScript has Jest and Mocha. Ruby has rspec. Python has built in test modules as well as Pytest (https://docs.pytest.org/en/latest/). Java has JUnit (https://junit.org/junit5/) -- if it’s a programming language, it probably has a test framework.

No matter what type of framework you choose, you’ll write a test that has an expected outcome. If your expected outcome or assertion evaluates to true, then the test is passing. If it is false, then the test is considered failing.

Let’s take a look at two tests for creating a url object in a url shortening web application built in Ruby on Rails.

require 'test_helper'

class UrlsControllerTest < ActionDispatch::IntegrationTest
  test "should create a new url" do
    url = Url.new
    assert url.save
  end

  test "should only save a unique url" do
    url = Url.new
    url.text = "https://www.amazon.com/Ruby-Under-Microscope-Illustrated-Internals/dp/1593275277"
    assert_not url.save, "Saved a duplicated URL"
  end
end

Here we have two tests, test "should create a new url" and test "should retrieve an existing url."

The first test creates a new url object and then asserts that we can save the url to the database. Ruby evaluates a successful completion of the save method on the url object and returns true, this the assertion is a success.

The second test makes sure that we only save urls that are unique -- if the url already exists in our database, we would rather refer the user to the existing url object. However, instead of checking against data in our actual database, we create dummy data in what's called a test fixture.

The purpose of a test fixture is to make sure we have a standard environment in which tests are run so that results are repeatable.

Here we have an object in our urls.yml file with which we can test our code against.

ruby_book_page:
  text: https://www.amazon.com/Ruby-Under-Microscope-Illustrated-Internals/dp/1593275277
  short: f0r

Since this object is in the urls.yml file, our code treats it as an existing url object in our database. Our code creates a new url, assigns the Amazon link to the text property, and when the save is unsuccessful and returns false, our assert_not test is a success.

Without any validation, the url would be saved and our test would fail. We then add our code to our url model that will validate each url and only accept unique urls.

class Url < ApplicationRecord
  validates :text, uniqueness: true
end

We then run our tests again and see that it's passing, thus completing the process of test driven development (for that line of code, anyway).

There are a ton of different methods and ways to test your code -- hopefully, this helps you take a step in the right direction.

11 Popular Technologies and the Wackadoo Origins of Their Names

Chase Stevens — Tue, 20 Nov 2018 15:39:08 +0000

Or: Why Computer Geeks Typically Leave the Words to the English Majors

Software engineers hold a revered status in society, creating games for our smart phones and professional tools for our dumb jobs, all the while making a pretty penny for their programs. They position themselves as visionaries, geniuses, and rock stars and they act as if their products are handed down from on high. Silicon Valley thinks it has the knowledge and the know-how to make the world a better place.

But you wouldn't know it looking at the names they choose for their products - some of them suck (Zune, Chumby, iMuffs).

A rose by any other name would smell as sweet (except crap weed). Or would it? Is Silicon Valley filled with omniscient techno-gods who will solve all our problems, or are they pompous nerds who need to read a book? Let's take a look into the names of well known technologies and tech companies and see where they got their origins.

- - -

Google Originally called BackRub (after the backlink technology used to determine search results), founders Sergey Brin and Larry Page recognized they needed a new name for their nascent search engine. They held a meeting, Someone pitched "googol" as a name, they liked it, someone misspelled "googol," and they arrived at (Google)[https://graphics.stanford.edu/~dk/google_name_origin.html].

"Google" is now a verb in the Oxford English Dictionary - could you imagine saying "Siri, backrub foot doctors near me?"

Bug The concept of "my program doesn't work in the way I intend it to" is named after a literal moth flew the Mark II computer at Harvard in 1947.

The first bug, or the reason why errors in your code aren't called "typefarts (courtesy of the Smithsonian National Museum of American History)

Apple Steve Jobs liked apples.

Macintosh Steve Jobs' employee Jef Raskin liked Macintosh apples.

Java First called "Oak" after an oak tree outside of the founder's office, it was later named "Green" and then "Java" after some Java coffee in the office kitchen. Other name ideas included "stapler," "Mike," and "that She-Ra action figure dealie on Mike's desk."

Javascript From its humble beginnings as a programming language for browsers called Livescript, Netscape wanted to capture some of the hot marketing buzz of Java (which itself was named after the third object the founder saw).

Python Creator Guido van Rossum named after Monty Python's Flying Circus, a sketch show from the 70's. His next door neighbor made a programming language named "Brian" and caused some mix-up.

Linux Creator Linus Torvalds named the popular open source operating system after himself.

Git British slang for "unpleasant person", creator Linus Torvalds also named it after himself.

It's true. Go backrub it.