NSS – JarvisScript

Nashville Software School Hackathon. (Skill++)

First annual Nashville Software School Hackathon

Over the weekend Nashville Software School held it first annual school Hackathon. The purpose of the hackathon was for current students and alumni to meet, mix, and build projects. It was helpful to for new students to see how a hackathon works and for the former students to give back to the school.

The teams were built to include a mix of skill levels and created so no one from the same cohort would work together. My team included a couple of students that were just a month into their programs, one that was finishing the front end portion, one that graduated a couple of months ago, another that is about 2 months into backend course, Me that graduated early last year and our team lead that graduated in 2015.

The Challenge

To kick off the event, everyone gathered in the Hackery, the large open space on campus. We we were given a brief introduction and then challenged to build.
Our team went to our assigned location and began brainstorming on what to build. Greg, our team lead asked “What would have helped you early on, what did you have trouble with?” We came up with list of problems areas and decided to focus on JavaScript functions, because if you don’t understand functions it will be hard to code.

We brainstormed possible solutions we could build in the time limit. We decided to use the similarities between music and code and to help explain JavaScript functions. We chose “Total Eclipse of the Heart” to show repeated lyrics as reusable code and explain parameters.

We whiteboarded a basic layout of the app. Greg wrote some user stories, that we could break down in to tickets. About then was the call that the building was closing, we could continue to code but everyone had to leave for the night. So we planned to write more tickets over night, Angela worked on a Mock up.

We met back in the morning with new ideas and more tickets. We divided the project and started building, We did some paired programming. We talked to each other and shared ideas. We even had a visit from NSS Coach Steve. I was part of his first cohort. Slowly throughout the day our app came into focus. The application worked and it looked good.

Demo Time

Time was called, then all teams headed to the hackery. There were monitors set up on desks arranged in the center of the room. The teams presented their projects in science fair style. For alumni it was a reminder of demo day for current students a glimpse of what was waiting down the line.

man at desk. his monitor is facing out to demo a website.

This was different from demo day instead of sharing project with potential employers we were sharing with fellow developers, friends and family. I walked around and saw all the projects. The projects included git hub quizzes, flash cards, a resume builder, a read the room mixer app, and a Pokemon based CSS quiz. The apps were amazing.

Some of the instructors and staff were judges. I was very nervous when my old TAs came around. They saw my code back when I didn’t how to use the command line. Did Joe just say impressive?

Michael demos our project to Zoe, Joe, and Lauren. Super nervous Joe and Zoe were my first TAs.

Then students, alumni, friends and family got to vote for their favorite the judges would consider that in the scoring.

Design and ease of use: Judges look at the apps as a whole – does it look good? Does it have a consistent feel from one page to another? Is it easy to use? Is using it intuitive?

Functionality: Judges look at the apps as a whole – does it work? Are there some cool features? Do the features make sense? Is the app useful?

Public Opinion: friends and family got to vote for their favorite application.

Then we waited..

Finally the judges, organizers and staff came out. They thanked everyone for attending and talked about some new stuff for the school data science, front end & UI class.

and then they announced they winners. …..

And the Ducks go to

Third place went to Git Good for an application that let the user practice Git commands.
Second Place went to Total Eclipse, our app! Holy variables, batman! Man did that feel good.

The Team, Front row: Michael, Heather, Javon, back row: Chris, Greg, Kelly, not pictured Angela.

We even got trophy, a gold duck for rubber ducking!
You can see the app here.

First Place went to TIL. An app for sharing “Today I learned” items. It had Slack integration and voting.

What Did I Learn

It was a great weekend. We took an idea and 25.5 hours later we had an app. It felt good to build something that could help aspiring new developers. The school hackathon was the Brainchild of Coach, but it was organized by the Alumni. I was a member of the planning committee it was great to see this from start to finish.

I learn new shortcuts, a way to write tickets using user stories and some new git tricks. But more importantly I got to give back to the community.

Interested in reading more on the event, checkout the NSS Blog and see the winning three applications.

/* Your Comments? */

-$JarvisScript git push

UX Class & Case Study

I enrolled in the UI & UX for digital products course at Nashville Software School. It was a great experience for me. I got a taste of Agile, user interviews and digital design process.

I learned how to build a case study and how to frame a problem. I used interviews to see if what I thought was a problem really was something that needed to be fixed. Once I solidified my problem, I interviewed a few people and took that information to build my prototype and user persona.

This is a condensed version of my process. I have a full walkthrough of my UX Case Study on my portfolio.

My project

I proposed that people ran out of prescription pills and could use something to remind them to call the pharmacy before the bottle was empty. My resulting project was Medicine Minder an app that would send the user an alert to call the pharmacy when their prescription was low.

Wireframe

I sketched a basic paper prototype in a note book. It took several iterations to get everything I wanted on the design. Then I showed to some people got some feedback then I moved on to a wire frame.

Prototype

I built a wire frame using the prototyping tool, UXpin. The interactive prototype allowed users to experience the proposed functions of the app. I was able to get feedback in person and online. The feedback helped to refine my concept.

User receives an alert when the pill supply is calculated to be down to a few days supply.

Conclusion

Studying UX has helped me focus my process. The idea that “You are Not the User” was repeated throughout the class. As a Designer I should focus on what the user’s needs are. They will be the one using a product daily, it’s their experience that matters.

Introduction To Open Source Event

Over the weekend I attended a introduction to Open Source class. The class was presented by Max Shenfield of Evenbrite and Nick Lorenson of Code for Nashville. Nick talked about what open source is and how best to contribute.

How to find, learn about, and meaningfully contribute to an open source project without being one of those people.

Hosted by Max Shenfield and Nick Lorenson.

No help is better than bad help

Nick opened the class by saying you need to build trust we a project’s maintainer before you just start pushing code. Get to know the maintainers of the project, the project’s history and culture. Learn how the community likes stuff, why they do things the way they do. Use UX skills to determine what their standards are. Also get to know and be known in the project’s community by introducing yourself on their Slack or social media locations.

By knowing the the community as people you can build trust. That way when you submit a pull request it is easier for them to know that you are reliable.

Nick’s example if you are going to rearrange a house get to know the person’s likes before you move stuff. Don’t just jump in and totally rearrange everything or in his example set the house on fire. You’ll get bad results.

And now we Code,

Nick and Max had set up a faux Open Source project on GitHub. They assigned a few people to be project maintainers. The maintainers helped Max as the pull request started coming in. The rest of us split off into pairs. We forked the project and examined the code.

The project was a partially built Calculator with a list of know issues, or bugs, that need to be fixed. There were also unknown issues. My partner corrected a typo in the Readme file.

The teams claimed issues by commenting on the issues list. This prevented groups working on the same thing. We also used Slack for communication. My partner and I claimed an issue. We wanted to fix the subtraction function. We looked at the available code and figured out a solution. We built a test to confirm then submitted a pull request. Nick reminded the group to also add to the documentation. So we submitted an update to the readme file. Our pull requested was approved and our code added to the project.

We claimed another issue and went through similar steps to solve it. The issues were set up to be solvable in the allowed time. The idea of the project was to get introduced to Open source. The issues were resolved and we got a taste of the Open source world.

It easier to contribute than you think.

“Even the smallest person can change the course of the future.”
– Galadriel

I learned I don’t have to reinvent the wheel to contribute to an OSS project. A project maintainer doesn’t necessarily want a massive change in code. They may just need some minor changes or documentation added. There may be some bug that they don’t have time to fix. You can help them by clearing some technical debt.

-$JarvisScript git push