Project ideas can easily get overwhelming and complicated when going from initial thought to reality. This is even more true when working in a group.

Here are a few tips to help get ahead of the curve and be on point when building a project from the ground up:

1. Set a strict deadline and figure out if you can get done a simple, base-case version of the idea within that time

When do you need to get this hack done by? A week? A month? Make sure you stick to whatever date you pick. Don’t give yourself wiggle room (at least at the beginning), as you might be tempted to take advantage of it.

Pair down your idea, stripping away layer after layer, until you get at the core of what you’re trying to accomplish. And then build from there. Weigh each feature of the project to estimate how feasible it would be.

2. Sketch a flow of how a user would interact with your app, and how the app would respond to the user. Design the infrastructure around this flow

When someone visits your app, what would be the first thing that they would see? Where would they go from there? How would they use your project in their life. What would they click on, and what do they expect it return?

All these questions need to be answered to figure out what the app will look like and what it will contain. Also, come to piece with the fact that you might not get this right the first time. Programming shows us how both intuitive and error-prone we all are. Constantly evaluating the app flow after every change in the project can get us closer and closer to the truth.

3. Collect resources and tutorials about the technologies you may use for the project

The programming community is very collaborative and there are tons of free resources available. Take advangtage of that fact. Everyone comes across errors and bugs that baffle them from time to time so get comfortable reading documentation and looking up answers to broken code on forums like Stackoverflow.com

4. Create each new feature on a separate git branch. Only merge to master after a thorough inspection

Not only will this help you prevent team members from working on the same issues at the same time and creating overwhelming code, but it allows you to make an easy-to-track progression of how your project was built.

5. Write out the code you want to have in the comments. Use it to form the code you will have

Writing out the comments first allows you to verbalize to yourself, and your teammates, what kind of logic you need to implement, as well as what variables you have access to.

6. Hack away at the problems in the code until you’re exhausted, then hack away some more

Jump right into the thick of the code and swim your way through it. Keep practicing figuring out things in the moment, adapting to each situation as it comes. If it’s not working, push yourself to think about it a different way, and question your assumptions.

7. Figure out what job each part of your app is supposed to have, and partition their functionality

Think of every piece of your app as an object that serves a specific purpose and a role to play. Defining that purpose can help make your code cleaner and narrow down where the error might be located when they pop up.

8. Always ask for feedback

A new fresh set of eyes can do wonders to your project’s progress. As well as challege your assumptions about the way things need to work.

9. Delay the desire to abstract until after it’s already working

Abstraction is important, and can help us hone in on programatic thinking and effecient design patterns, but the wrong abstraction will cost you dearly. Make sure your code is nearing its final form before you start making it look clean and pretty.

10. Work on the frontend last, and split up the workload

It’s important to have a good app styling and branding, but without a solid and robust backend holding it up, the project can become brittle and unpredictable easily.

Also, even when you approach styling last, proceed with caution. Frontend styling is usually applied across every page of an app, so any merge conflicts can get messy fast. Make sure anybody working on frontend is working on a specific goal on a feature branch and that their tasks don’t overlap with anyone else on the team.

Nothing gives you the edge more than creating your own toolbox to problem solve faster and more effienciently. As developers, we want to go in, keyboards blazing. But going through the motions of setting things up can easily get in your way.

Building up a treasure trove of smart tasks and shortcuts abstracts away a lot dirty work, so that you can focus on the bigger picture. You can set up tasks to automate all facets of your interaction with a program: the front end, back end, and even the keyboard. Here are some shortcuts I’ve been exploring:

Back End:

Rake Tasks

Rake tasks are part and parcel of the rails framework, but you can easily set up your own custom ones.

You can create tasks that load different environments, install themes, generate templates, seed data, organize folders, and clean up unwanted files.

All the tasks will be stored in a RakeFile, where you can handpick what gems and dependencies are required.

Rake uses an intuitive and abstracted language to explain your tasks clearly. For example, a task making a new postmay look like:

1
2
3
4
5

desc "Makes new blog post"
task :generate_post do
  # makes a new post by targeting a directory and adding a new file with predetermined markup. 
    .....
  end

Or to preview a simulation

1
2
3
4
5

desc "Starts simulation"
task :simulate do
  # loads environment, starts server and runs scripts 
    .....
  end

Gems

Extending your built in functionality is important in creating an awesome and robust program that feels intuitive.

Gems are stored in the Gemfile, which is created during the bundle install command in the Terminal. Their dependencies and versions are safeguarded by the Gemfile.lock file.

Some cool and useful gems I’ve come across:

Logstash
RubyCritic
Faker
And lots more gems on the Ruby Gems website.

Front End

Gruntfile.js

Grunt runs tasks with javascript using Node.js. It can run asynchronous tasks, check for typos in syntax, uglify files, and generate JSON. There are also tons of plugins available for Grunt. Here are some good tutorials on how to start installing a using it:

Grunt: Getting Started
Grnt.js: The Basics

Text Editors

Both Sublime Text and Atom have awesome autocompletion and snippets, however Sublime gets annoying quickly with popups to purchase their product, while atom is free.

To the more hardcore programmers, the solution is either Vim or Emacs. Vim has a lot of shortcuts and starts with them as default, and emacs allows you to customize commands across many platforms. You can learn about both in the links below:

Interactive Vim Tutorial
Absolute Beginner’s Guide to Emacs

In the last post, we gathered up some useful methods for our journey. Now let’s take next step: entering the dream space.

Remember that this is our target dream:

    dreams = { 
     :dream_one =>{
        :location => "grandma's house",
        :people => ["Grandma", "Grandpa", "Sis", "Brother", "Auntie Charlotte"],
        :discussions => ["ancient aliens", "superheroes turned Senators", "ninjas"],
        :items => {
          "bratwurst" => {
             :color => 'Firetruck red',
             :shape => 'Cylindrical',
             :satisfying => true,
           },
          "sofa" => {
             :color => 'burnt sienna',
             :shape => 'L-shaped',
             :satisfying => true,
           }
        }
      }
     :dream_two =>{
        :location => 'enchanted forest',
        :people => ['woodsman', 'wizard', 'Sleepy Tom', 'Butters', 'Tinkerbell'],  
        :discussions => ['politics', 'magic','good', 'evil'],
        :items => {
           "tree of life" => {
               :power => 'vivaciousness',
               :state => 'glowing',
               :color => 'golden',
               :shape => 'branchy',
               :blissful => true   
               },
            "magic potion" => {
              :power => 'strength',
               :state => 'bubbly',
               :color => 'purple',
               :shape => 'liquid',
               :blissful => false   
              } 
         }
     }     
    }

Still scary, right? Not to worry - as we venture through the levels of the dream, we’ll keep track of where we are at in two ways: drawing out our current level in a comment above a method a handy library (referred to as ‘gems’ in Ruby) called ‘pry’

Adding comments (descriptive lines that don’t affect your program) above your code can help you map out the dream as you work your way through it and be used as a reference points if you get stuck.

Pry, on the other hand, freezes a program as it’s running and lets you peer inside of it.

It even lets you play around with all the inner variables and test them all out. All you need is two lines of code inserted into the area that you want to check out:

  require ‘pry’
  binding.pry

‘Require’ imports the gem into your file, so it can be on hand, and the second line triggers pry to stop whatever program that crosses paths with it and reveal its binding. Binding is the ‘universe according to that line of the program’ - all of its variables, methods, and values.

Entering the Dream

As you enter the dream, you have two goals in mind:

• Collect data on the dream
• Add bottles of Tap to the dream

Let’s start with the top level:

  # Level 1: Tale of Two Dreams
  # dreams = {:dream_one => {...}, :dream_two => {...}}
  dreams.each do |dream, dream_content|


  end

We’re just scoping out our path interating through the dream, so we haven’t added anything logic inside the block yet. Also, make sure that you name your parameters (here ‘dream’ for the keys and ‘dream content’ for the values) in a way that is clear and makes sense to you.

This level doesn’t seem that useful. We’re ping-ponging between two dreams, each pointing to nested hashes which contain the dream content. So…

Let’s enter the next level:

  # Level 1: Tale of Two Dreams
  # dreams = {:dream_one => {...}, :dream_two => {...}}
  dreams.each do |dream, dream_content|
    # Level 2: Content is King
    # {:location => "...", :people => [...], :discussions= [...], :items => {...}}
    dream_content.each do |type, attributes|


    end
  end

Here we have much more to work with. We have a list of different types of data in the dream (location, people, and items), a map of where different things may be located, and an overall sense of the string’s structure.

The marketing company wants to know each type of content, and the structure that each one points to. They also want to compare this level between different dreams.

Easy enough. Lets iterate through everything and print it to the screen, focusing on the type name and the attribute Object class:

  # Level 1: Tale of Two Dreams
  # dreams = {:dream_one => {...}, :dream_two => {...}}
  dreams.each do |dream, dream_content|
    # Level 2: Content is King
    # {:location => "...", :people => [...], :discussions= [...], :items => {...}}
    dream_content.each do |type, attributes|
     puts "#{type} points to a(n) #{attribute.class}."
    end
  end

  => location points to a(n) String.
     people point(s) to a(n) Array.
     discussions point(s) to a(n) Array.
     items point(s) to a(n) Hash.

Now that you have printed out this information, you have everything you need to incept bottles of Tap into the dream. You know where you want to insert them and the data structures you’ll be dealing with. Therefore, you can prepare the path to inception and methods needed beforehand.

Let’s get two new bottles of Tap for dream insertion:

    tap_one = Tap.new
    tap_two = Tap.new

We’re going to target the discussion and item types. Discussion points to an array, meaning that we can just push tap_one into the end of the array. Let’s also use .collect to iterate over dream_content, so that the inception will be sure to solidify:

1
2
3
4
5
6
7

  # Level 1: Tale of Two Dreams
  # dreams = {:dream_one => {...}, :dream_two => {...}}
  dreams.collect do |dream, dream_content|
    # Level 2: Content is King
    # {:location => "...", :people => [...], :discussions => [...], :items => {...}}
    dream_content[:discussions].push(tap_one)
  end

Next, we want to pass tap_two into items. We don’t know what items themselves point to inside the hash, but we don’t need to. Brands love distinguishing themselves from the flock, so we just have to make whatever tap_two points to compelling. Here we go:

1
2
3
4
5
6
7

  # Level 1: Tale of Two Dreams
  # dreams = {:dream_one => {...}, :dream_two => {...}}
  dreams.collect do |dream, dream_content|
    # Level 2: Content is King
    # {:location => "...", :people => [...], :discussions => [...], :items => {...}}
    dream_content[:items][tap_two] = "Amazing thirst-quenching childhood nostalgia popularity comfort love belonging individuality"
  end

You successfully incepted this dream! The marketeers are overjoyed. The campaign was a success and you’re getting job offers left and right for inception contracts, even from the US government- regarding a secret mission to incept the dreams of foreign revolutionaries and make them more America-friendly.

A lot of programming is working through layers of data to retrieve or manipulate the necessary values. Wading into giant, deep containers of virtual lists an associatons can be daunting, but once you get more familiar with them, they come easier to navigate.

We’ve invited the characters of the movie Inception to help us out.

Let’s say you’re a contractor hired by the Tap Soft Drink company to infiltrate potential customers’ dreams and place bottles of Tap in “meaningful” parts of their dreams. They also want you to collect data on the content of people’s dreams, so that they can market to the public better. You’re a bit rusty on your dream infiltration technique, so you ask the team from Inception to bring you up to speed.

The dream layout looks something like this:

    dreams = { 
     :dream_one =>{
        :location => "grandma's house",
        :people => ["Grandma", "Grandpa", "Sis", "Brother", "Auntie Charlotte"],
        :discussions => ["ancient aliens", "superheroes turned Senators", "ninjas"],
        :items => {
          "bratwurst" => {
             :color => 'Firetruck red',
             :shape => 'Cylindrical',
             :satisfying => true,
           },
          "sofa" => {
             :color => 'burnt sienna',
             :shape => 'L-shaped',
             :satisfying => true,
           }
        }
      }
     :dream_two =>{
        :location => 'enchanted forest',
        :people => ['woodsman', 'wizard', 'Sleepy Tom', 'Butters', 'Tinkerbell'],  
        :discussions => ['politics', 'magic','good', 'evil'],
        :items => {
           "tree of life" => {
               :power => 'vivaciousness',
               :state => 'glowing',
               :color => 'golden',
               :shape => 'branchy',
               :blissful => true   
               },
            "magic potion" => {
              :power => 'strength',
               :state => 'bubbly',
               :color => 'purple',
               :shape => 'liquid',
               :blissful => false   
              } 
         }
     }     
    }

The first thing is that you want is to get in and out of the dream as quickly as possible while completing your objective. Without the right constrainsts, you can end up stuck in a dream, forever!

Don’t do this:

    while dream do
       print “#{dream[:items]} ,”
    end

Or this:

    loop do
       print “#{dream[:items]} ,”
    end

You will end up with this:

You’ve entered a never-ending loop that crashes your program!

You need to supply the variables to make sure you have a safe time. An incrementor like i is handy. The flow i =0, i < (a number) and i+=1 inside the loop can help keep everything in check.

Even better are methods that run through each element of data structures like an Array (similar to a list of elements) or a Hash (a list of keys that each point to, or associate with, a value). These types of methods, like each, collect, select and inject use an object called a block while operating. You can think of the block as an ambiguous dreamlike space that methods can yield their consciousness to. Just like dreams, things outside the block can appear inside the block, but anything defined in the block don’t exist on the outside.

Let’s go through a few main methods that you might use:

Each

The .each method goes through each element, hands it over to the block, and returns exactly what you gave it. It’s like having a dream, forgetting about it, and going about your day the next morning. One of the ways programmers use .each is by printing out each element from the block to the screen.

Array:

      [1, 2, 3, 4].each do |num|             
           num * 2                                      
        end
  =>     [1, 2, 3, 4]

Hash:

    names = {:name_one => “Julian”, :name_two => “Jeremy”}
    names.each do |key, value|
      value + “is awesome”             
    end
    =>   {:name_one => “Julian”, :name_two => “Jeremy”}

Collect

The .collect method is the “inception” method. Whatever happens inside the block changes the data structure .collect is affecting. You can plant easter eggs in the array or hash, and manipulate things to your liking. Dom Cobb would be proud.

Array:

      [1, 2, 3, 4].collect do |num|             
           num * 2                                      
        end
  =>     [2, 4, 6, 8]

Hash:

    names = {:name_one => “Julian”, :name_two => “Jeremy”}
    names.collect do |key, value|
      value + “is awesome”             
    end
    =>   {:name_one => “Julian is awesome”, :name_two => “Jeremy is awesome”}

Select

The .select method returns a data structure filled only with values that are inherently true. How you define what is true inside the block is up to you. This method is great for filtering out unnecessary parts of an array or dream, and obtain only the element you wanted all along.

Array:

      fruits = ['apple', 'banana', 'apple', 'banana']
      fruits.select do |num|             
           'apple'                                      
        end
  =>     ['apple', 'apple']

Inject

The .inject method takes an element and makes it interact with the upcoming elment. It keeps carrying over these values until they accumulate until it accumulates into a giant final snowball. It’s like bringing on what you come across in one dream on to the next dream.

Array:

      [1, 2, 3, 4].inject do |sum, num|             
           sum + num                                      
        end
  =>     10  

Now that we have the tools to do basic iteration, next post we’ll tackle the dream.

One crucial topic I constantly come across as I am studying at Flatiron is that I always need to be aware and keep track of what values my variables hold throughout my code and how they change over time.

I cannot drill this into my head enough. Or tell you how many times being sloppy has ruined an afternoon.

Let’s start at the very beginning…

The Ruby language has very few set keywords, so most of the work will come from you, the programmer, defining your own variables, meaning storing information by associating a name with a value (or technically, an object that has a value):

  x = 14
  food = “pasta”
  cities = [New York, Berlin, Dallas, Shanghai]

You use the variables as placeholders for data, so you can manipulate it for whatever program you’re working on. The problem arises when you call methods on the data, functions that operate on data in specific ways. Some are fairly straight forward. For example, most people can infer that:

  x = 14
  x = x + 6

reassigns x to equal 20. However, other methods are less obvious. It’s always important to understand how each one “returns” a value. A method like puts prints to your screen, but returns a nil value. Other methods will change a copy of the data, leaving the variable’s original data intact.

  puts “Return me, please!” # => nil

  name = “Julian”
  name.upcase  # => “JULIAN”
  name         # => “Julian” 

Some guidelines to keep in mind while tracking your variable:

• Ruby always returns the last value of a program. Think of how to use that to your advantadge.
• Ruby has built-in implicit returns, meaning just writing the variable is enough to get the value.
• Just because something is printed on the screen, doesn’t mean that the same value was returned in the program.
• Keep track of incrementing values, and methods that take multiple arguments
• Always read documentation for the nitty-gritty details. Ruby-doc.org is the place to be.
• Get dirty in the sandbox: Test out code snippets in the terminal using irb, or hacking into programs as they are running, using the pry gem.

In Brazilian culture, the word “malandro” can be a very controversial term. It’s usually has the connotation of a rogue, a gutter-punk, or a trickster. Someone who is very devious and dosen’t play by the rules. They follow a way of life called “malandragem,” or getting the advantage by any means possible.

It evokes a bit of a bad-boy persona, one that’s memorialized in songs and folklore.

But in martial arts like capoeira, malandro and malandragem has a much more positive meaning.

There it describes someone who is extremely versatile and can problem solve on cue. Fluid situational awareness and unconventional problem solving then take on an almost positive quality.

The word “hacker” can be just as controversial. In the programming community, hackers are inventive makers and testers, participating in a vibrant collaborative community. To the outside world, hackers are malcontents and thieves, bent on destroying people’s online lives and corrupt their data for laughs.

Sometimes the steretype gets taken to the extreme…

Hackers are a lot like malandros - they make things work, adapting to problems and systems at the tip of a fedora with everything they have on hand in any way they can. There’s no straight and narrow thinking - just bubbly, shapeshifting inventness.

And on the topic of hacking the planet, here are some awesome worldwide and national hackathons:
NASA Space Apps Challenge
BattleHack
International Open Data Hackathon
Code for America

Oi malandro e malandro! - A malandro is a malandro!