Data from https://data.cityofnewyork.us/City-Government/DSNY-Grafitti-Information/gpwd-npar

NYC OpenData

New York is one of the United States leading proponent for open data and government transparency. The city has stood by the Open Data movement from the beginning, initially gaining public acclaim during President Obama’s first term. The movement surrounds the practice of publicizing data collected by citizen funded departments. Data varies in content and form, from financial balance sheets to statistical records. In the past year, emphasis has been made to release information into machine-readable formats: sans-PDF, pro-JSON.

CivicHacking

Yesterday I received an email promoting the Code for America brigade supporting the “Code Across NYC” civic hackathon. The email, from Chris Whong, promoted the spirit to getting involved with local communities through any means. Following Chris, Noel Hidalgo shared a recently released NYC OpenData blog post on new real time datasets on New York city.

The data set topics ranged from medical history, farmer’s market records, and graffiti reports. All the sets were deemed “real time” and machine-readable. These data sets provide public access to rich repositories of information. Based on the availability, these will be the beginning of fresh new software applications based on consuming these datasets. Imagine the next farmer’s market notification mobile app or graffiti report location tool.

Individually, the data makes available the well-organized datasets. Even more exciting are the cross-reference opportunities. An interested party doesn’t need to know how to program. Simply grab the CSV export copy of a preferred data set and get to some analysis. Immediately a PivotTable reference between data and category can provide interesting high-level comparisons. Looking at graffiti creation by date across boroughs shows the uneven reporting of graffiti incidents.

Graffiti

To start, I love graffiti. I love the notion of people finding and accessing places that have been deemed ‘dead’. I love the raw-ness of spray-paint. I love the culture, the people, even the drudgery associated to the painters. Most of all, I love how it represents a community of people who desire to express themselves publicly.

I am not one to argue that graffiti is not vandalism.mi strongly disagree with the painting of private property. I instead believe graffiti is the effect of a greater social culture associated with stemming the voice of individuals. I believe that large amounts of graffiti in an area are public signs for improvements.

There is a person doing the painting and that person is trying to say something. Maybe they have poor handwriting and a poor value system, but they are people to understand. Why do they get pleasure out of scrawling their moniker in public places? Why do they write on things that don’t belong to them? These questions make me interested in drilling into the available graffiti dataset.

I have a hypothesis that areas that are not central urban sectors with high amounts of graffiti could be improved by providing public art programs. I think most of the periphery communities with large amounts of graffiti are the result of youth between the ages of 12-18. I also believe these students have poor grades in school, are high risk for dropping out, and are likely exposed to drug use.

These assumptions aside, the graffiti is an expression of a societal problem. It’s not a graffiti problem. It’s. Community issue. It’s an education issue. Graffiti is the signal, but the cause is larger.

Action

I have never been able to pinpoint or analyze graffiti from a statistical front. I have never seen a dataset like the one that NYC has made publicly available. I’m sure these sets have been stringently analyzed and reviewed by police and sanitation departments, I believe the information was most likely viewed from a cost-arrest standpoint. I believe the individuals who, like myself, love graffiti and see the value in its messaging will make great use of this information.

I will be looking at this information to seek out insight for potential public programs to stem these issues. Imagine, graffiti declines because citizens feel alternative ways to express themselves. Imagine, communities coming together to take responsibility for the visual composition of their neighborhood. Imagine, children and teenagers out on the street with a spray can, because they feel they are being heard.

Algebra for designing layouts

I have been reading about machine learning and linear algebraic analysis. In college, I failed two calculus courses. In high school, I repeatedly failed higher-level algebra courses. In an academic setting, pumping away at math worksheets was never a convincing use of my time. I much rather play video games at the time. I didn’t realize at the time, but I was using complex equations to calculate the optimal strategy to win.

Although I never caught on to academic mathematics, I find myself regularly using algebraic equations at work. I use complex algebraic equations everyday while design. While visual design is driven by aesthetic choices, the execution of interactive layouts requires thought out calculations. To get a navigation item to “stick” on a webpage when scrolling, or “unstick” after scrolling a certain distance, calculations are necessary.

After recognizing how something pleasantly interactive requires mathematically complex planning, I decided to explore other pursuits. I love math when its applied to something practical. I thrive in solving animation related math problems. Through reading about machine learning, I found a new topic that seemed interesting.

I attended the Soka Education Student Research Project conference this weekend. In preparation, I compiled the past 10 years of published articles. The compilation was made for WhoWroteForSESRP.¹ The process resulted in a simple JavaScript table for users to search published authors, titles, and issues.

Presenting data

The context in which you view Data (with a capital D) determines what you can understand. Edward Tufte emphasizes this point. I tried to understand the past 10 years of SESRP published papers. First, I organized the information in a flat context with simple attributes. Second, I viewed the relations between the attributes in aggregate. Lastly, I created charts and tables to make the results clear. This process shows that there are still many interesting relationships among SESRP papers that have not been clearly identified.

The first step required me to review the past 10 years of published journals. I selected the individual published paper titles, associated authors, and published issue year. The attributes chosen could have been expanded to full article texts, human-defined tags or categories, and article bibliography. Initially, I wanted to create a basic repository for easily browsing the past-published articles. ²

Second, I isolated the individual attributes to view them in relative increasing or decreasing order. Through collecting the data, I saw a distinct increase in published papers during the year 2011. Similarly, viewing the authors in aggregate clearly displayed the writers who published the large number of articles over the past 10 years. ³

Lastly, I charted the data to further understand the relationships between the authors, years published, and quantity of articles. In the future, I will add attributes to compare against. Mainly, I am interested in charting network relationships between cited articles, cited authors, and unrecognized topic driven clusters. ⁴

Insights from analysis

Filtering the quantity of articles published by year showed a unusual spike of submissions and a potentially changing overall trend. In 2011, the number of articles submitted more than doubled from previous year. In 2010 nine (9) articles were submitted, followed by 22 articles submitted in 2011. In the years following 2011, the average number of articles submitted increased by over 20%.

The quantity of articles published by author shows a familiar trend in participatory communities. Out of 85 total authors published in the yearly booklets, 64 authors had one paper published, 13 authors had two papers published, 3 authors had three papers published, 3 authors had four papers published, and 2 authors had five papers published. These numbers show that in the past 10 years from 2005 to 2014, approximately 75% of writers only publish one article.

The two authors who published the most are Gonzalo Obelleiro and Ryan Hayashi. Obelleiro’s first article appeared in 2006 and Hayashi’s first article appeared in 2011. While Hayashi and Obelleiro have the same number of articles published, Obelleiro has presented articles that have not been published, therefore technically he has written more than any other author. Regardless, Hayashi has been writing for less than half the number of years, so his rate of appearance is impressive.

Suggestions

The past 10 years of conference organization has been completely led by students. The proposal request process for SESRP papers is distributed through current student body, the alumni network, and individual requests. In the interest of revitalizing previously interested attendees, past SESRP paper submitters should be personally requested to submit new papers. Future student tasked with organizing the SESRP conference should seek to mobilize the 75% of one-time publishing authors to propose a new paper topic. Most past authors are alumni of Soka University of America, so the alumni network may be useful in gathering contact information.

As the 10-year anniversary booklet is being prepared, organizers should seriously consider the 25% of authors who published more than one paper. The eight authors who published more than 3 articles each should be consulted for advice. While quantity of published papers does not reflect a priori for understanding Soka Education, their insight should be considered. These authors have shown personal interest through their multi-year commitment. These authors, from most published to least, are:

• Gonzalo Obelleiro (5)
• Ryan Hayashi (5)
• Maria Sanchez (4)
• Jean Marcus Silva (4)
• Michael Strand (4)
• Masahiro Kaleo Louis (3)
• Menelik Tafari (3)
• Nozomi Inukai (3)

Future expectations

The three attributes listing of the SESRP papers from 2005 to 2014 have raised positive results. This method of organizing information and finding relationships will be further applied to understand the relationships between sources cited in submitted papers. The goal will be to find the unseen relationships between the submitted papers. The cited resource’s author and publications will help create rich network maps displaying relationships between SESRP authors. Similarly, this relational mapping may display under recognized clusters or categories. This will prove to be useful in the 10-year anniversary booklet’s drafting.

On meeting strangers

You should be meeting more strangers. Strangers are scary, smelly, often have lopsided feet, and more than anything, have a lot to offer you. Whether you are sitting on a bus, picking up your mail, getting a cup of coffee, or sitting in your house watching TV while secretly watching what you neighbors do, the strangers in your life have a lot to offer you.])

Talk to everyone and anyone.

I mean everyone. You would be very surprised how much the people you casually talk to can offer you exactly what you need. Once you talk to your first stranger, you will be on your way to learning more about the world. Through talking to strangers, you can learn about different careers, life struggles, current events, and occasionally a new cookie recipe. When your standing in line for groceries, getting a cup of your favorite drink, or sitting alone quietly. You can simply start a conversation with “hello, my name is _____” (please don’t actually say ‘underscore-underscore-underscore-underscore". Fill in your name instead). Another effective method is joining conversations that have nothing to do with you. While you feel like this is totally unacceptable and disrespectful (it mostly is), occasionally its a great way to get past all the awkward conversation and get straight to the point (“I love chocolate chip bacon covered whiskey dipped cookies too!”) From there you can take the conversation anywhere.

Break all the ice.

Global warm that shit. Start by being as intrusive as possible, so as to learn about the persons personal life. The sooner you can break the ice, the sooner you can have a new friend. Don’t worry that you don’t know anything about this person. Did you hear a word that sounds vaguely interesting? Does the person have really well hemmed pants? Maybe you want to know whats in the bag they are carrying (“So whats in the bag?”). Take them off guard with a question they wouldn’t expect from a stranger. Find a commonality and make some personal association to its relationship to you. (“Nice novel on ax murdering. I love ax murdering…”).

Make it easy to get in touch.

Get a business card. Have a portfolio website to show off. Make your twitter handle easy to pronounce. Stop using that email address you made in 2001 and make something that doesn’t have the . By talking to strangers and asking them what they do, you will naturally start up a conversation. (Unless you just creep the person out and need to run away out of fear. If you run away, don’t worry. They can’t judge you because they are still trying to figure out what just happened.)

But seriously. Go talk to a stranger. Go make friends with someone on the street. Jump in a taxi with someone, even if you’re not trying to go anywhere. And start making friends.

Why learn?

I have spent the past three years developing websites. I have been hired by clients ranging from startups to fortune 500 corporations. Yet, I don’t have any formal training as a computer scientist or digital designer. I went to school to study in a Liberal Arts program in the humanities. I read books on cultural theory, history, and adopted an obscure love for classical literature (Goethe I’m looking at you).

So why does this all matter? Well, like most people, I wanted to get on the band wagon of utilizing the immense power available today in the form of technology. I saw computers as the beginning, but instantly knew before smart phones that mobile technologies were offering amazing opportunities through widely distributed data networks. I wanted to use this, but I didn’t have any training. I think a lot of people around my age (and those who are not) have this feeling.

I started learning web development, and more recently Javascript. Javascript was my “in” to the growing digital frontier. Making a website was foreign to me, but I found people would pay me to do it, so I invested my time to get good at it. I identified the front-end (User Experience, User facing elements, Design) web development as most interesting to me.

Deciding the front-end

Deciding I would become prolific at front-end technologies (HTML/CSS/Javascript), I found myself struggling with the abstract concepts of Javascript. I also noticed that Javascript could potentially offer the most learning value. As the founder of Javascript says, “Always bet on Javascript”.

I traverse the infinitum of blog posts being written on software engineering to find the rare nuggets of informative learning resources. I find myself attracted by titles to blog posts, but unable to comprehend the complex code blocks. Instead, I browse the (often Jekyll or Octopress) blog posts, only to read the commentary and skip of the code segments.

My greatest obstacle when reading code is that I’m feeling like I understand the code, but fail to absorb the lessons. Overcoming the mammoth that is learning to code by adopting good practices has significantly helped. I can confidently say, I am not good at learning over the internet or even teaching myself how to do “stuff”. Instead, I am good at identifying my faults in remembering and make up for it by creating processes that make me “fail forward”.

I know that I fail at absorbing coding concepts. I also know that I am good at learning from mistakes. I combine the two understandings about myself by forming a practice to force myself to fail at absorbing coding concepts by making guided mistakes. I do this without another teacher guiding me or a tutor.

Note: The term “Failing into the pit of success” was a term developed by a software developer at Microsoft.

I have developed a four step process to help me learn from coding blogs. There seems to be an endless number of programmers who enjoy sharing their software development discoveries in blog posts and articles. I often find these very informative, although not always well written. Sometimes there is (what seems like) a missing part or gap. I find that the core concepts are discussed, but the directions seem to miss explaining how to get “there”.

Although instructions are not present, I find that code examples are numerous. Specifically, code examples without explanation behind their inner-workings or core-concepts. As a result, I started pragmatically reviewing the code myself. I use the code examples that are completely foreign to me, to begin a process of exploration and discovery. I have documented this process with examples for readers.

Step -1: Always be coding

I find the best way to solve a problem is by having a contextual and relevant application. Without the relevance, you won’t be able to remember the problem. You might forget the idea, but you won’t be able to apply what you learned when the same problem appears out of context. I find the problems I understand best are the ones I learn to solve when encountered during actual development. This is one of the reasons side-projects are crucial. Always be coding and you will always be learning.

Step 0: Identify well written articles and dependable educational resources

There are literally hundreds of email newsletters that compile the “best” articles of development in your field. I get no less than 10 a week. Some of languages I feel overly confident about and others that I am only just starting to learn. Regular exposure to newsletters, as well as online coding communities (such as Reddit/r/webdev or HackerNews) will keep you exposed to the well written articles and best educational resources available.

My personal favorite for front-end questions is the Mozilla Development Network (MDN). The MDN has the best documentation on all web related APIs. This means anything you want to learn about HTML5, CSS3, Javascript and web APIs are well documented here. To discover these resources, you can use Google. Simply add the string “MDN” to a search query and you will find the relevant resources

Using Twitter and Github to follow well known developers has been priceless. Whenever I find an article I enjoy, I follow the authors twitter account (This is a great time for me to say “Follow me on Twitter @Lkbcc”). By following developers, you can see what links are being shared and most importantly who they follow. The twitter feeds of developers, open source projects and companies are often the best place for discovery.

Step 1: Place your browser beside a note taking application

Open up a code editor or note taking application and open it side-by-side your browser window. You are going to write down every idea/snippet/word that you don’t understand. This is crucial. Being aware of what you don’t know will allow you to advance. It may be painful to realize you read a paragraph, only to write down nearly every word in your notes, but this is where you can start moving forward.

You picked an article with an interesting but difficult topic and lines-on-lines of coding examples. You are about to learn some thing new. Be confident that you can learn this idea, even if it seems completely out of reach. Most of programming is not about being smart, but pushing through the foreign ideas until it “clicks”. Just as Woody Alan says, “Showing up is half the battle”. Seriously, just read through the stuff you don’t understand, and the exposure to the foreign ideas will be hugely beneficial.

For note taking, I use a program called Notational Velocity. Its a very simple application that makes all my notes easily searchable. I’ve seen people effectively use Evernote, TextEdit, and even Word Processors. I find the most important thing is reducing the friction to start the note taking process. I like Notational Velocity because it natively binds a keyboard shortcut to pull up/hide the editor. This process can actually be assigned to any application through a computer’s System Preferences.

Step 2: Copy down code examples. Write them out again from memory

When you read articles, if you just read the articles, they won’t do sit nicely in your head. Like a poorly written Backbone application, you’ll have a memory leak, until all the time you took to learn will be forgotten. The best way to remember is to physically go through the code and write it down. If I learned anything from Zed Shaw in his Learning Python the Hard Way, it was the value of copying code.

Often, you will get into the flow of copying/writing out code, without being conscious. Other times, you will be conscious of how impossibly terse a code block is and will not understand it. This is okay. At times, I physically write out code blocks with pen and paper, because it forces me to slow down. Regardless of how you do it, the next part is very important.

Write out the previously copied code purely from memory. You can do it write underneath the copied code or in a new page or document. The exercise will force you to be present. No copying aloud. You should go back as needed and look at the original code to jump your memory, but the purpose of this important step is honestly reflecting on what you don’t know.

The hardest part of learning to code for me is stubbornness. I either like to default to assuming something is too hard to understand or make believe that I don’t need to know an idea. I almost always find myself encountering the same problem or code concepts without fully committing time to understanding them. Don’t do this. But sometimes you can write something from memory and still not understand it.

Step 3: Write out directions to write the previous code

Next, write out english sentences that tell you exactly what each line of code does. You need to be clear enough that reading these sentences will allow you to understand how to recreate the original lines of code. Do this without giving yourself specific coding syntax. If possible, use the vocabulary to properly describe the code. If you don’t know the vocabulary, then its good to check out places like the MDN to review.

This may be weird because you just effectively “memorized” the previous snippet. A proven effective method of learning is to teach what you know. In the context of coding, you can teach yourself. By treating yourself as both the teacher and student, you can deepen your ability to communicate the coding concepts. Your success in this step will be seen when able to use the instructions to recreate the exact same code as the original code block.

Step 4: Recreate the original code using your instructions

Using your instructions, attempt to write out the original block of code. Be strict with yourself and follow your instructions. Don’t pull from your memory (Assume an irreversible memory leak). Go through your instructions, and line-by-line try to write what you communicated to yourself.

// Example for completed description
// define function called getHTTPObject
// check if XMLHttpRequest exists
// if it does return it as a constructor
// otherwise try to return the constructor for ActiveXObject with Msxml2.XMLHTTP attribute
// check for errors
// and if they come up try to return a constructor for ActiveXObject with Microsoft.XMLHTTP attribute
// check for errors again and kill the process
// After the original conditional, return false

function getHTTPObject(){
  if (typeof XMLHttpRequest != "undefined"){
    return new XMLHttpRequest;
  } 
  try {
    return new ActiveXObject("Msxml2.XMLHTTP")
  } catch (e) {
    try {
      return new ActiveXObject("Microsoft.XMLHTTP")
    } catch (e) {}
  }
  return false;
}

If you do anything like me, then your initial instructions are going to suck. Through this forced consciousness process, you will notice parts that you either missed or didn’t understand enough to explain. Review the actual code and try to revisit your instructions again.

It’s important that during this process, you are not looking at the code while writing the instructions. As much as possible, try to understand the idea, move away from the original, then document your understanding. This is maximize your opportunity to discover where you don’t understand.

Step 5: There is no step 5

You have iterated this process enough to accomplish your end goal of writing instructions that clearly explain the code, you will have accomplished one of two things: mindlessly memorized completely useless code, or remembered the syntax/framework/structure of some code which you don’t completely understand.

If you are in the latter, then you’re on the right path. You realize that no code is perfect and often your understanding of concepts too is imperfect. More importantly, you realize how to communicate what you know and also provide yourself a mechanism for understand what other people are trying to communicate. You provide yourself a strong tool for learning from the plethora of undocumented, but very useful code.

Hopefully this idea was not new to you and you have now learned an effective way to push yourself to learn new coding concepts. Take notes, copy down code examples, give yourself instructions to rewrite the examples, and most importantly look up all the questions you have!