Nerdy Creativity

I gave presentation about why fellow students should attend the weekly Hack Reactor minihackathons. Despite my natural aversion/hatred for public speaking, I actually got positive feedback from quite a few people. Someone even told me it was one of the better student presentations they’ve seen at HR.

Reason being? I made the audience laugh. Like a lot.

Here’s the slideshow for the presentation. It probably won’t be funny to those who don’t attend Hack Reactor because there’s a lot of inside jokes.

And hey, it was my first chance to use reveal.js, an html friendly slideshow.

So I made people laugh, learned a new tech..all in all, not a bad day.

On August 21st we had our fourth Thursday night minihackathon. The goal for this minihackathon was to create a Tower Defense game with as few lines of code as possible. External libraries and CSS were not included in the line count.

I had used jQuery and D3.js for animation in previous projects, and for a while now I wanted to learn more about CSS animations, so I decided to do the game with only CSS. I knew I wasn’t going to be able to implement a real game with only CSS, but I wanted to see just how far I could go with only CSS. Plus, the irony of doing a project in only CSS without a lick of Javascript at a coding bootcamp that teaches only Javascript and not a lick of CSS kinda amused me. Here’s a demo of CSS Defense.

Challenges/Things I’ve learned

• Hardest part of this project was figuring out how to make the towers appear and fire bullets after you click on the screen.

  Early on I decided to use a grid of links to make the towers “magically” appear when you click on the board. The boards starts with white links on a white background so the towers aren’t visible. When users click the board, a link changes to the visited state, turns black, and a tower appears. That was the semi-easy part.

  The hard part was making the moving bullets appear after the towers appear. Since the only css rules you can apply to visited links are color and animation, I had to create a second grid of clickable links for the bullets, and position the two grids on top each other.

  Each cell on one board has a unique url. The corresponding cells on the two boards share the same url so when you click a cell on the towers board, the corresponding cell on the bullet board will also appear.

• Using formulas in the :nth-child() selector is pretty nifty way to get finer control over which elements to apply styles to.

  This code applies different rotation rules to every fourth tower. Tower 1 rotates to the right in 1 second, tower 2 rotates to the left in 2 seconds, etc.

  #board_towers a:nth-child(4n+1) {
  animation: 1s towers_right infinite ;
  }
  #board_towers a:nth-child(4n+2) {
  animation: 2s towers_left infinite ;
  }
  #board_towers a:nth-child(4n+3) {
  animation: 3s towers_right infinite ;
  }
  #board_towers a:nth-child(4n+4) {
  animation: 4s towers_left infinite ;
  }
• Using a multiple keyframes in a animation can allow for some complicated movements. Here’s the code to move the three shapes along the path.
  @keyframes slide in {
  0% {
  transform:translate(0px,0px);
  }
  20% {
  transform:translate(0px,200px);
  }
  60% {
  transform:translate(400px,200px);
  }
  80% {
  transform:translate(400px,400px);
  }
  100% {
  transform:translate(650px,400px);
  }
• Before the hackathon, I didn’t get much of a chance to use absolute/relative positioning, so I always got those rules confused. I had to use positioning a few times in this project which greatly helped my understanding of positioning. A little bit of practice can go a long a way.
• Before the hackathon, I was not aware that the only css rules you can apply to visited links were color and animation. I originally hoped to use a:visited:after {content} to make the towers and bullets appear after the click. Because of the limitations of visited links, I had to do some major hacky creativity to find a workable solution for the towers/bullets.
• After the hackathon, I found examples of fully functional games that only use CSS. Pong, Space ship, Minesweeper, CSS Panic, and car game.
• “Programming” in a language that isn’t meant for programming was more challenging and more fun than I had anticipated. Who would’ve thunk that doing things the hard way to produce a non-functional app could be so entertaining?

On August 14th, we had our third Thursday night minihackathon. The goal for this minihackathon was to use Firebase to create an collaborative app that should not be collaborative. (FYI, Firebase is a service that allows users to store data for their web app in an cloud database.)

Keep in mind, we had already spent 11 hours at Hackreactor doing a bunch of coding, and here was Drew (organizer of the minihackathon) asking us to voluntarily spend another 2 hours at Hackreactor doing a bunch of coding for an app that he himself said no one would ever use. Huh?

And yet, I stayed. Partly because I’ve never worked with Firebase before, and partly because the project sounded fun. I like being sarcastic, and this was the first coding project at Hackreactor that I was able to use my humorous side.

It took, like, half an hour before I could come up with a project idea that was absurd enough to keep my sarcastic side amused, and practical enough to keep my techy side challenged. After brainstorming various ideas, I decided to create a collaborative mashup where users could submit YouTube links and the page would play all the videos at the same time. Here’s the demo of Y’all Tube.

Challenges/Things I’ve learned
• This was the first time I used Firebase and I was surprised at how easy it was to set up. All you have to do is sign in, give your app a name, and add three lines to your code.
  // include the Firebase script on your page.
  <script src=”https://cdn.firebase.com/js/client/1.0.19/firebase.js”> </script >
  // connect to the Firebase link for your app.
  myData = new Firebase(“https://xxxx.firebaseio.com”);
  // push the data the Firebase server.
  myData.push({key:value });

  And BAM! The data from the app is now being stored in the cloud. Yay, internet magic.

• While storing the data in Firebase is easy, getting the data out of Firebase is a bit trickier. I’m used to working with mysql where you can do queries across multiple tables. From my quick perusal of the Firebase docs, complicated queries would be difficult, so I had to limit the features of the app.

  This project drove home a point that Hackreactor instructors have said numerous times: pick a databased based on the needs and functionality of your app. In this case, the database was chosen ahead of time, so I adjust my app design based on what I could make the database do in two hours.

• FYI, after the hackathon, I found out that it is possible to some complicated queries in Firebase. Firebase advanced queries part 1 and part 2.
• Simultaneously playing multiple YouTube video can slow down your computer a lot. I had to set a max limit of six simultaneous videos to a get a reasonable load time.
• If you give people the chance to post a YouTube video, someone will inevitably post a Rick Rolled video and a cat video.

On August 7th, we had our second Thursday night minihackathon. The goal for this minihackathon was to use D3.js and data from Data.gov to create a data visualization.

Here’s the demo for a data visualization for the 1,800+ known exoplanets.

Challenges/Things I’ve learned
• Data.gov is not the best source of data to use for a two hour hackathon. Data.gov has so many datasets in so many formats and in so many sizes that it was difficult to find a suitably small dataset for the hackathon. In the end, I decided to ditch Data.gov and use the list of exoplanets from Exoplanets.eu.

• Sometimes, Chrome does not like loading local files. When I tried loading a csv that was on my computer into D3.js, Chrome showed a cross origin request error.

  XMLHttpRequest cannot load file://User/xxx/exoplanet.eu_catalog.csv. Cross origin requests are only supported for HTTP.

  This was a very weird error since I wasn’t connected to the network. The index.html, csv, and javascript files were all in the same directory. I tested the index.html file in Safari. Safari could load the csv, but Chrome could not. I was all kinds of confused.

• By the end of the 2 hour hackathon, I did not have a finished product to show. Looking for a dataset, reading about how to use a csv file with D3.js, and Chrome not loading the file took up the entire two hours. Getting ready to create a simple data visualization was a lot more challenging that I expected.
• After the hackathon, I found out that Chrome not loading local files is a thing that Chrome does. You either have to start a server and use the server to load the index.html file or use terminal to start Chrome.
• Due to other Hackreactor projects, it took like a week for me to find the time to return to this project. Once I got everything set up correctly, I could actually start coding using D3. After the two hours of things not working, things not working, things not working, it was so cool the first time I saw circles appear on the page. Yay!
• Astronomy is awesome. That is all.