Doing React in 14 Hours: Hacking For Humanity 2017

“Damn, those kids are smarter than me!” I whispered to Jessica, who laughed and playfully slapped me in the arm. We watched in awe as the kids – middle schooler going to high school – talked about wanting to build their app in Java and the algorithm involved (“I didn’t know computer existed when I was in middle school!” “…We sound so old!”). The joy of hackathon – you see all sort of ideas and participants.

The Event

I was at DocuSign HQ for Hacking for Humanity, hosted by Girls in Tech and Hackbright and sponsored by DocuSign, Cisco, Kintone, Handshake, Memebox, and JINS. Topics we can select may include Homelessness, Sexual Assault, Domestic Violence, Human Trafficking, or Women’s Health.

The host decided to assign us into teams in advance. Like all events though, we have a bunch of MIA attendee – Missing In Action. So, those us missing members waited in line for reassignment. While there, I started chatting – which led me to me be invited into another team before the re-assignment.

We started as 4 person team – UI/UX designer Jessica and Tawny, software engineer Anoja, and myself as web developer. The host wanted a 5 person, so they assigned us Ryu, engineer and Kintone evangelist visiting from Japan.

Opening talk took the whole morning – Hackbright even did a Coding 101! For me, the most interesting part was listening to SF Safe House and Women Inc’s work and mission.

DocuSign CEO Opening
SF Safe House
W.O.M.A.N., Inc
Special gifts from sponsor Memebox

Since this hackathon didn’t have idea pitching, our team are formed without a project idea or even a common topic interest. My team eventually decided to go with Women’s Health: HerCare, a web app that extracts SFGov Opendata and list nearby free health care clinic, then help user to easily find transportation route.

UI working… on the DocuSign window, with the Bay Bridge as background pic.

Onto Hacking

Both Anojo and Ryu mentioned they know a bit of JavaScript, so I decided to go with React. As with all projects, I quickly encounter issues.

Styling in React

Being in a time-constrained event like hackathon, I decided to use Bootstrap. But altering DOM other than React is considered bad practice: Bootstrap contain its own JavaScript, which conflicts with React. The common suggestion online was to use react-bootstrap.

fetch() and Component Lifecycle

For some reason, console.log revealed that the state is not setting with the data I retrieved in fetch() when I use the OpenData API. Looking into React’s fetch(), I learned that it returns a promise that must be waited. Meanwhile, render() is also setting state and mounting. To ensure the state are set in the mounted component befire re-rendering is trigger, API calls with setState() should be done in componentDidMount().

Latitude & Longitude via Google Map API

While trying to get Google Map working, I spent too much time on the wrong npm packages. I had picked one of the recently updated one with a simple example, thinking it would be a snap.


Fortunately, when I finally switch to a different one someone recommended in Reddit (react-gmaps), it worked almost right away. After that, I needed to get the latitude and longitude by address – regular user obviously wouldn’t be entering their latitude and longitude.

Having been working with bunch of npm packages lately, I jumped onto the npm-package-solution again. Silly, since it turns out Google have an API for that.

*Sigh* The precious hours… Almost submission time!

Controlling State Updates via componentWillReceiveProps() & componentDidUpdate()

When users clicked on the parent component, LocationList(), which holds the address, it should updates the child component, GoogleMap(). The update involves calling the Google API that detects latitude and longitude.

So, another API call. I would use componentDidMount(), right? I mean, the React doc say so itself:

If you need to load data from a remote endpoint, this is a good place to instantiate the network request.

…yea, didn’t worked. The question is why?

Well, the thing is that the map component (GoogleMap in this case) was first mounted, then its states changes when the parent component (LocationList) holding it passed down a new prop that activates an update – not a new mounting. What I need was componentDidUpdate().

But when I did the API call in GoogleMap and use setState to update the states with latitude and longitude data, the component itself will update, again.

This is an infinite loop.

That’s where componentWillReceiveProps() came into use. I set up a flag variable, “updated”. In the constructor, it is initialize as false.  Inside componentDidUpdate(), an if statement checks the flag. If false, we do the API call, setState, and set “updated” to true. After that, the subconsquent update from state change will not activate another API call because the flag variable is now true. Only if the component receive new props from the parent component LocationList(), – in another word, someone click one of the address listing – would the variable “updated” be set to false and thus activate the API call.

Deployment on Heroku

Unfortunately, I didn’t solve the infinite issue until after the submission. Fortunately, I have continuously deploy my site onto Heroku. Deploying React onto Heroku is acutally a snap. The Heroku team have a instruction page just for that: Deploying React with Zero Configuration. I do have do a npm run build to get it running, but after that, it’s smooth sailing.

Team Communication

Due to language barrier and differences in programming specialty, we ended up doing the same task by accident at first, so stop coding and checking in became essential. Though the programmers in my team knows JavaScript, latest JavaScript and web development best practices isn’t exactly their specialty. In the end, Ryu ended up finding jQuery to be easier to do. In hindsight, I should have realize that language barrier may prevent my teammate from using React, which had an all-English doc. Fortunately, Ryu was good with at AWS, which he easily use to deploy his jQuery.


Prototype: HerCare Location Listing
Prototype: HerCare Appointment Request
The demo! HerCare main page
Demo: HerCare Location List

The challenge of this competition was definitely communication and task distribution. It was a bumpy ride, but we eventually find our rhythm. Both Anojo and Jessica was inspired to do more hackathon, so I recommended July’s AngelHack in Silicon Valley to them – we will probably bump into each again as a result!

HerCare Team!

HackGen: My Experience at 2017 AngelHack

I managed to snatch a free ticket for the 2017 AngelHack, so I was off to another hackathon!

My team and I created HackGen, which grabs DevPost data and displays winning hackathon idea randomly, often resulting in quite hilarious results. Seriously, my team spent a good portion of time after code freeze in laughter. Some people’s hackathon idea makes no logical sense. I can only deduce that they wrote it after a long all-nighter and did not presented their project that way on stage.

For this hackathon, I participated predominately in the front-end features, making sure the data that my teammate, Ting-Wai To and Michael Snowden, are displayed in an aesthetic, user-friendly manner. Consistent with my coding habits, the site uses responsive design. The languages I used included HTML, CSS, JS, Ajax, and jQuery. The framework we used was Django. We started trying to host the site on AWS, but ended up using Heroku. The VCS was Git on both Github and Heroku. Our project works with Amazon Echo and also allows visitors to subscribe by using the SparkPost API.

The site started with the name HackPredict and was supposed to predict the chance of success for an hackathon idea:

Initial version, HackPredict

However, the collected data wasn’t enough for an accurate prediction. No matter what was input, the result remained between 40%-50%. Eventually, it developed into an idea generator:

HackGenerator, draft version. I have no idea who wrote that idea… (Fruit Ninja?)

And this is its final outlook:

HackGen, Final iteration!

Now, for the struggles and lessons:

In this case, I was reminded that Anaconda and Virtual Environment don’t play well together. My team had a lot of trouble. I was able to solved it by doing a simple conda install python=2.7.8. I think it helped that I have previously set up everything to work once already last month while working on a Slackbot with Django as backend. All I needed was to switch from Python3 to Python2.7. The other guys sounded like they had bit more trouble.

I also ran into trouble with static file management in Django, which according to Michael, is a common problem. When Ting-Wai wanted to use Bootstrap with static url, Michael and I were all going “No! Just CDN it!” Yea, we didn’t get along with it.

Ting-Wai apparently hates the Bootstrap progress bar, but Michael really wanted a progress bar. So, I went with a customized dot progress bar. Fortunately, while I know Bootstrap, I often practice coding in raw CSS to build my foundation, so it was easy to whip one up:

My teammates were surprise that I didn’t use Bootstrap at all for the site. I actually did started with Bootstrap, but I wanted more customization on the input and buttons. Besides, almost everyone use Bootstrap with very few customization in a hackathon, so why not take a different approach? For a small site, raw CSS is pretty easy.

I also had trouble once my teammate set up mysql with Django. I first got “Did you install mysqlclient or MySQL-python?” error, which persisted even after installing those packages. Following online suggestion, I homebrewed mysql-connector-c, which turned out to be a Python3 suggestion. I got a “Segmentation fault 11” error and wasn’t able to do a runserver at all. I uninstalled mysql-connector-c and looked up for new solutions. The golden solution:

export DYLD_LIBRARY_PATH=/usr/local/mysql/lib:$DYLD_LIBRARY_PATH.

*Sighs* I swear, setting things up probably took more time from my team than coding. I am not the one in charge of set up, but I can tell by the way my teammates acted. If this is an anime or cartoon, they would probably had smoke coming out of their ear. One of them rushed to a couch for a nap right after demo. There were a lot of demos too. The hosts had to divide us and the judges into 2 rooms, and I think we were the last few teams to demo.

I got to brush up on my front-end skill during that weekend and hang out with a lot of cool people. Got a bunch of nice goodies:

Amazon have notebook, t-shirt, and ninja sticker – who don’t like ninjas!? IBM have cool hexagon sticker and external usb port, the later of which I totally need for my Chromebook (only 1 usb port there). SparkPost is my favorite since I am a sticker collector: they have grid notepad and awesome stickers. Apparently, they have all the languages they supported sticker-ify, plus one more design for our beautiful Golden Gate Bridge!

All in all, it was a good hackathon, with awesome people, good amount of API challenge choices, cool goodies, healthy food and plenty of coffee, and a lot of fun demos and ideas.

Lego, Fistfight, GraphQL, & Observable – React in Silicon Valley

Real World React had its first Silicon Valley meetup. As a React newbie who enjoys the Silicon Valley cities, naturally I attended!

Held at Atlassian, this is the Meetup “GraphQL with REST APIs | RxJS & Redux-Observable“.

Real World React at Atlassian

We started off with the Lightning Talks, and the first one up is Joshua Nelson from Atlassian. His original topic line is “Component libraries and React as a platform”. The final version of his topic? “Why Lego is Great”!

I concur! Lego is Great!!!
More Legos!

Lego have a rich history and culture, which Joshua started his talk with and eventually turned it around to Atlassan’s component library, discussing its 3 key advantages: Clean API, Reusable, and Platform.

Then Michael Leung and David Katz talked about their Reactathon project. Utilizing the OpenTable API, their project BrokenTable determines which bar is most likely to have bar fight.

Yep, bar fights.

All while the developers are students too young to even step into a bar.

Those orange dots are fist!
That black thing is actually a broken table. A non-broken table means no fights

Needless to say, the idea was hilarious, and the duo succeeded in giving a presentation that was both funny and educational. I particularly enjoyed their presentation of how their code works and how they implemented React Native and Redux in the fast-paced environment of a hackathon.

After a brief break, Feature Talks started, with the first one being on of my main goal for attending this Meetup: “Going GraphQL First on Web and Mobile” by Jon Wong from Coursera. I am considering GraphQL for the next on my to-learn list, so this is perfect timing!

Jon discussed about the task to implement GraphQL in an existing project – a task he found similar to what Justin Bachorik mentioned in the Reactathon talk regarding NPR’s transition from legacy code to React. Both are accomplished through the process known as incremental adoption.

Speaking of, I have been studying Redux, and I don’t envy the future me that will eventually adopt Redux for my React project. Incremental adoption indeed.

Jon touched on how Joshua talked  API contract earlier in the Lightening Talk and stated that GraphQL inverts API contract back to client, who is the the one to actually build product. Such schema-first approach helps create better contract.

For someone planning to learn GraphQl, his description is helpful in giving me an idea of what and why I should learn it. His diagrams also did a great job in graphically representing how GraphQL works with React’s Component-focused system.

GraphQL & Server.
GraphQL and React working together in Coursera. The visuals and the way he presents really showed why they interact well with each other!

The last but not least (oh, definitely not least) is Berkeley Martinez, CTO at freeCodeCamp. Perhapes a reflection of his work, he is quite excellent in teaching – seriously, I have zero clue of what Observables when I started. Yet, I wasn’t lost with the amount of codes he displayed, and I came out with a pretty good understanding. He was very good at being precise yet informative and to the point.

I love the definition here.
Once again, concise but to the point.

I must say, this Meetup was one of my most satisfying I had. Meetup that shows lots of codes and teaching materials can be dull if it is not a tutorial everyone can follow. Not a lot can be fun, inspirational, and technically informative. This definitely hits all the spots. I can’t wait to attend another one!

D3, Data Visualization, & Bubble Wrap: Winning at the 2017 PDA Hackathon

Another hackathon? Do I really want to do two hackathon in a month? On the other hand, my last hackathon was as fun as it was intense. I really enjoyed it. Plus, this hackathon is hosted by Stanford library with digital archiving as the theme.

Archiving. Library. My inner bookworm is dancing. (Or wiggling?)

The temptation is just too great.

So, on a sunny Friday afternoon, I drove from San Francisco to Stanford, and my adventure at the 2017 Personal Digital Archiving (PDA) Hackathon commenced!

The hackathon was part of the PDA Conference. While I didn’t got to attend ($120 for late non-student registering), listening to the participants, the conference seemed to be very well done and highly-praised. They sounded so enthusiastic, particularly about the keynotes and agenda selections, that even I felt excited!

For me, the excitement was also twofold compared to a normal hackathon. I obviously enjoyed the chance to code a project with practical usage in a team environment. But I had also been a library assistant, a teen library council member, and an art history minor student. My love for the history of fine art and literature started when I was just a kid. To be with so many that shared the same interest was rejuvenating after so fully engaged into the tech industry in the last 2 years of my career change.

Naturally, when one of the attendee, Katie, talked about her intention to do a project that address email archiving issues related to her work as an art archivist, I was hyped up!

Art + Archiving = I Am In!!!

Our team decided to build a web platform that organizes and analyzes email in a shareable way. Having an art archivist that is passionate about her work really helped directed the project. While I had looked into Stanford’s email archiving software ePADD, without hearing Katie’s perspective as a professional, it was difficult to fully comprehend the importance of analyzing email and maintaining content privacy in the field of digital archiving.

Thus, with the project decided, our team “Girl With A PERL Earring” began our platform, Bubble Wrap!

Bubble Wrap Logo
Our Platform, Bubble Wrap

Katie and Natasha, whom were both interested in art digital archiving, created the wire frame using Lakshmi, whom was interested in analyzing email, tackled extraction method for a set of sample emails. She applied the NLTK toolkit with Python to extract the data into the required JSON file for our project.

Inspired by the MIT Immersion project Katie showed me, I researched into the project’s background. I knew I saw a similar graph built using a D-something library and 4j-someting while attending a DevWeek presentation. I was right. Immersion was a force-directed graph built using the data visualization D3 library and graph database Neo4j.

D3 LogoNeo4J LogoInital research indicates that D3 have a high learning curve. It required understand of jQuery chain methods, objects in JavaScript, CSS to style SVG, reading coordination… wait, I know those.

And the sample codes. It looks understandable.

I think I can do it.

Gosh, it would kill a lot of my brain cell. I mean, an entirely new library in less than 12 hours?


But yes, I can do it. Let’s do it!!!

Thus began an intense all-nighter that I haven’t attempted since I left architecture school. I did got 3 hours of sleep, but the impression that I didn’t sleep apparently got stuck in the event host’s mind. My teammates were also impressed with my energy. I have a feeling the most memorable part the library host and my teammates will remember about me is that I don’t need to sleep.

But hey, the result was worth it. The data visualization I created looked beautiful, and I learned so much!

D3 required a good grasp of SVG and not just basic CSS styling. I struggled with labeling the circle (it seemed to be a known issues. Text couldn’t just be drawn on the circle) and DOM query (SVG have their own set of query method).

I didn’t have time to go through tutorials, so I quickly analyzed sample codes that seemed applicable. From there, I selected specific methods to research. Force, a D3 module, have its own rules and requirements. In particular, it takes the array key, “source” and “target”, from the imported JSON file. I had changed the JSON keys to make it more applicable to our case, so I was confused when nothing was printing.

As morning came, the essential features of my graph seemed completed.

Working on Bubble Wrap's Graph
Working on Bubble Wrap’s Graph. Photo by Josh Schneider.

Then another issues occurred – our presentation is on and Google Slide, so how do we present a dynamic demo? At one point, the discussion involved taking snapshot, but it would defeat the purpose of a moving demo. So, I quickly whipped up a Heroku page, looked into the right webpack (static), and pushed my code up. There, a dynamic demo site!

Bubble Wrap Force-Directed Graph
The Force-Directed Graph
Bubble Wrap Selected Network
Bubble Wrap Selected Network with Annotation Generated

By the way, it is now also hosted permanently at my own website, and it has a Github repo for the curious. was beautiful – elegant but clean. Sadly, while Lakshmi got the JSON set up, it was too late to link it to my D3 script. I ended up using a modified dummy code from the D3 tutorial. Fortunately, Lakshmi set a flowchart in advance, so she was able to go over how the Python script work.

Bubble Wrap Login Page
Front/Login Page. Our demo was created by Katherine Martinez and Natasha Culbreth.

To our excitement, we won a prize! The prize was for – and since it is long, I dared everyone to say this in one go really really fast – “Most innovative project relating to email management or archiving”.

Bubble Wrap Team Photo
Bubble Wrap Team Photo: Natasha Culbreth, Lakshmi Rao, Amy Chan, and Katherine Martinez

In total, I learned a whole new library in less than 12 hours, met new friends, got to hang out with archivists, listened to some really cool conversations, and won a prize. All in 12 hours!

Safety on the Street: The 2017 All-Women Hackathon

Have you ever been harassed on the street?

That was the question of the day for my team and I last Saturday, when  I attended the 2017 All-Women Hackathon hosted by Expat Woman at Pivotal Lab. The Hackathon have 7 challenges, as listed in their Eventbrite:

  • Engage more Girls in STEM
  • End the Gender Gap in Tech
  • Women’s Empowerment
  • Women’s Safety
  • End Gender Violence
  • Teach Boys/Men to Respect/Empower Women
  • Help Immigrant/Refugee women Navigate the US

My team’s chosen challenge is Women’s Safety, and the project idea stemmed from the experience of our team members, when some random guy just started yelling at them outside the street Pivotal Lab. The incident motivated Grace to go up stage and pitch her ideas, which brought our team together, which consisted of Grace, Magda, Daminika, Anju, Steph, and I.

safe-route team
The Safe Route team, hard at work

Our project is a web app would let user to search their destination using the Google Map API, but instead of just seeing the route, they will also see safety ratings. The rating would be generated from a combination of crime data and user feedback, showing keywords that indicates incidents that occurred. Users would be able to filter and customized feedback result base on time of travel and gender. Upon research, I saw that SFPD have Socrata OpenData set up. With the combination of the OpenData and Google Map API, the path to map a safe route in real-time is not far!

To coordinate our pace, Grace took the advice from one of the hackathon mentor to set up a hourly timer, and I started to write a to-do list that will let our teammates assign themselves to different tasks. Even though I introduced myself as a front-to-full developer, interestingly I ended up working with Grace to establish the data parameters that the app will query.

Using a mix of skills in JSON, REST, SQL (for OpenData’s SoQL), and ES6 JavaScript, I programmed a script that will extract the needed data from OpenData. Grace got an Express server running to connect my script result to Dominika and Magda’s part of the program that deals with Google Map API.

Doing our initial brainstorming, deciding on the project’s direction and presentation content took a lot of discussion. Thankfully, we had a good group of mentors who would periodically come by to talk with us.

In the end, we were able to get a Google Slides set up, a demo video recorded, and time to rehearse our presentation, all in 11 hours! Somehow, I ended up being the presenter, which was a bit nervous-inducing. Thankfully, it went smoothly.

safe-route snapshot
Final Product of our web app, Safe Route

Overall, it was fun to work on the project with my teammates, and my experience at this hackathon was very satisfying. We didn’t win the physical prizes, but the experience was a prize of its own.

On Helping Others – Volunteering at Techtonica’s Workshop

Last Saturday, I volunteered to help students with coding tutorials in the first application workshop of Techtonica, a new San Francisco non-profit that offers free tech training for low-income women and non-binary adults. Interestingly, I myself was studying coding tutorials for React the night before.

My React studies has been going for a while. ES6, ES7, vanillaJS, functional programming… my work and studies last year rarely involved JavaScript, and the landscape has changed dramatically since the days when I was learning JQuery and Ajax. I found myself spending the days learning JavaScript instead of starting on a React web app as I had planned.

On the morning of the application workshop, I put a pause on my React studies and did a quick review of the Django Girl tutorial, since I remember reading that Techtonica hosted Django workshop before. It was pretty familiar materials, and really, how in depth can a first-day workshop be? Yet, as I walked to the workshop site, I found myself feeling unsure, both about whether I should start my web app already and whether I can teach coding well.

In the end, my worry about the workshop was unwarranted. The students went through a tutorial that introduces basic HTML and CSS. Not only did I not have any issues helping them, I truly enjoyed the experience of sharing what I know.

I signed up for the last of 5 workshops. It was a small workshop where there were about 6 to 8 applicants. Volunteers and students shared the table, so interactions were easy and the environment was pretty relax and open.

Most applicants seemed to do fine in the tutorial sets and finished it in the requested time frame. The tutorial leaded up to a personal web page. After the tutorials were completed, the applicants got called in individually to be interviewed by the staff while the rest could continue to improve and practice on their own page. They also got to present the resulted web page that their tutorial codes created. In between, there were questions and chats, mostly related to basic HTML/CSS and additional tutorial recommendations.

I found myself reminiscing on how I started coding and how far I have came. Back then, there were no interactive tutorials like Code Academy or FreeCodeCamp – the most popular recommendation during the workshop. Coding wasn’t even a word in my dictionary, until I saw a deceptively thin book on WordPress website while I was shelving books in the college library I worked at.

Now, I can build a website off the top of my head. I can explain to the applicant in the workshop what html tag to use, what css to change, and troubleshoot their codes.

True to the old saying, when you help someone, you end up helping yourself as well. By the end of the day, I felt energized and inspired by what I was able to do and how much I can help others. I went back home where I finished the tutorial set I am on, closed the browser window, and made a new directory.

I am ready to build my React web app.

Installing the Linux Distro GalliumOS in My Acer Chrombook

I love customization. Which is also why ever since I won a Chromebook during a HTML5 Meetup (Hooray!!!), I have been thinking about installing Linux on it. Finally, I got around to it!

Firstly, I debated on which Linux OS to get. The most popular one seems to be Crouton. However, I eventually decided on GalliumOS, because it was specially designed for Chromebook and seem less likely to break on updates – at least according to what people are saying online. Plus, built on top of Xubuntu, GalliumOS is a fully functional desktop. I would sacrifice some GPU performance, but I think it’s worth it. I will be working predominately in Linux instead of ChromeOS, so it is a good exchange. The simple-to-follow wiki guide from GalliumOS also is another plus – hurray to good documentation!

Secondly, following the wiki, I identified my hardware and its associated flash firmware requirements. My Chromebook is an Acer Chromebook 11, CB3-131. According to the Hardware Compatibility page, it is a Bay Trail model, and thus require custom firmware. Using Firmware page, I chose to use the firmware update of RW_LEGACY from MrChromebox – RW_LEGACY would allow me to duo-boot and I don’t have to open up the Chromebook and remove the write-protect.

Thirdly, with the choices made, I followed the Baytrail installation guide. Time for me to set my Chromebook into Developer mode!

The process was pretty smooth. The powerwash did took a while as the guide stated. The white developer mode boot screen appeared and stayed there for a while before the screen emits 2 loud, alarm-like beeps that had me a bit worry. Fortunately, it was a false alarm and a setup panel for ChromeOS appears:

Chromeos Setup

I logged into my wifi and log into the crosh shell as instructed:

Looking good. Now is time to update my Legacy Boot capability, which in my case, is the RW_LEGACY from MrChromebox as mentioned earlier. After that, to get back to the ChromeOS login screen, I restarted the laptop. The 2 loud beeps happened again and I got back to the ChromeOS setup panel, which shows that I am still logged into my wifi.

Finally, it was time to install GalliumOS. I had 2 choices, the standalone setup that uses a bootable USB and dual-bootup that uses chrx install script. I decided to go with the dual-bootup. The process for that was also pretty smooth. I followed the steps and went with the recommended 9 GB space allocation:

First Run of Chrx Script

After chrx rebooted and “repair” the laptop, I have to run the chrx installation script a second time:

Chrx Installation Script
The anticipation……

There were some confusion as the second run of the chrx install script didn’t seemed to work, which turned out to just be a disconnected wifi. After that, it was a smooth sailing!

Installing GalliumOS Core Image
It’s loading… it’s loading!

I set up my chronos account password, and the rest is just customization all I want! I found a reddit for GalliumOS, and got some good recommendation from the post What To Do after installing Gallium OS: A noobie’s Guide for other chromebook noobies. Some softwares I added were Firefox (with all my favorite addons: ABP Adblock, NoScript, Blur, Firebug, and Pocket), PIA VPN, Cisco AnyConnect, VIM, Sublime Text, GIMP, LibreOffice Writer, and Gnome Software Center.

What I Have Been Doing 2016-2017

Before I post my 2017 Resolution, let’s list out and organize out what I am doing now. Cause honestly, I think I am doing too much at once. I need to trim down and focus. Ok, so here goes!

  • MIT’s 6.00.1x Introduction to Computer Science and Programming Using Python course
    • Just started this week. I am regretting it a bit now, cause it is asking my to install Anaconda right away, and the last time I did that it messed up my localhost Django practice page – conda does not get along with pip and virtualenv. This is definitely going to be more focus on data science than just Python. I like Python a lot, so a lot of time I forget most people use it for data science, not web development.
  • Functional Programming, cause I want to learn React.
    • This is growing into a monster. I only know basic vanilla JS and jQuery from like 2 years ago when I first got into web dev. One month of study, and I am now on 3 different tutorial cause everyone talks about a different aspect of modern JS. This is what happened:
      1. At first, someone recommended me to watch funfunfunction’s Youtube channel Functional programming in JavaScript. Oh, he’s funny indeed… Oh my god how much had JavaScript changed in the last 2 years!?!?!? Promises? Currying? Map? Filter? What Da H?
      2. Google. Google. How come the functions are all written differently (<— was not fully aware of the whole ES5-ES6-ES7 tangle of mess)
      3. Maybe my foundation just isn’t good. I had never read the holy grail JS book, Eloquent JavaScript. They were just talking about how good it is in the Women Who Code JS Meetup. Let’s do it. Oh, Wes Bos have a really cool video called JavaScript 30? Even better. I will make myself program once a day in JS! Let’s do both.
      4. Combining Eloquent’s Chapter 5 content with Wes Bos’ Array Cardio part 1 and part 2 was really good in helping me to finally understand higher order functions like map() and reduce().
      5. Decided to do Eloquent exercise – which is in ES5 – with ES6/7 instead to learn the differences between the versions.
      6. Wait, wait, wait. Why is object and prototype completely different between ES5 and ES6!? And the constructor! The class! What is even count as object in JS? (<— comes from a C++/PHP7 background)
      7. Found Secrets of the JavaScript Ninja in Barnes & Nobles. Great, another book. But I need it, cause it will explains what on earth is going on with this function-object JavaScript mess.
    • Correction, I am on 1 Youtube channel, 1 video tutorial, and 2 books all at once.
    • Told ya it’s a monster.
  • Doing a side project website of Drupal cause I wanted to brush up on for my internship. Which resulted in learning Bootstrap on Treehouse, cause the theme I selected is based on bootstrap. At least this one’s almost done.
  • The Drupal site is worked on while reading Beginning Drupal 8 by Todd Tomlinson.
  • Revamp of my website, which is PHP.
  • Yea, I am taking on way too much. I think I am going to put a pause on my Drupal project and reading (currently chapter 10)… Should work on my web page first.

Estimating, Mobile, and Websocket on Django

Recently, I went to my first Django Meetup and it was totally worth the trip, even the part where I accidentally took a wrong turn and ended up in Treasure Island instead.


What? The highway entrance to the bridge is literally next to the building! It actually wraps around it, which I thought was pretty cool, but anyway – tip to those going to Four Point: Don’t go up the ramp!

I like the inside too. The Meetup area where the group ate pizza is beneath an interior overlook. Some of the employees had paper decoration hanged up, and they range from pizza to Powerpuff Girls (They really like their pizza, don’t they?). There were rows of wooden benches to the right for the presentation, but for the first half hour, everyone is just enjoying the food.

Having finally started to learn Django and on my first web developer job hunt, it was pretty fun to hear from working Python developer at the table talk about how a Python project typically progress. For example, I got to hear about the typical requests from ecommerce clients and how there are features that most ecommerce clients eventually decides to get even if the clients didn’t thought of it at first. There were discussion of language version craziness (one had a client that use all version of Django starting from… 1.4 I think? Django is 1.10 right now, by the way). Of course, framework differences were also brought up, though being a Django meetup, everyone had found Django to be fairly likeable.

I wouldn’t go into detail about the presentations, since all notes and videos are available to the Meetup event site, Django + Ionic & REST Websockets API with Django Channels , but here are some thoughts:

The first talk was about a Python Estimator. With the name, at first I thought it have to do with finance or concurrency. Turned out it was more about improving the way data scientist shares data with back-end engineers.

The second talk have more to do with the presenter’s journey through building a well-functioning web app via Python and Ionic that tracks food truck – on his spare time. Talk about discipline!

Sam’s talk was about RESTful Socket. I had not read too much about the event profile until the day of the Meetup, so I was surprised to realize that Sam was an engineer at HouseCanary, the company that hosted the hackathon I participated. He was also one of the guys at the table I was sitting in. Realizing that makes me look even more forward to the presentation, since he sounded very knowledgeable at the table.

It is definitely the most technical talk of the day, leaving me much more educated and slightly awestruck about how much more there is to REST and websocket. I had used a bit of REST APIs before, but while I have read some definitely of both of REST and websocket, the definition in relation to their application plus their differences have never really sunk in until this talk. Though I have yet to learn channel, signal, and websocket, the talks today left me eager to learn more.

Deploying my Python Slackbot onto Heroku

I just build a Slack chatbot in Python within a night.

With all the hypes about building a chatbot, that was way easier than I imagine.

I pretty much just followed the tutorial at Full Stack Python: How to Build Your First Slack Bot with Python, which was pretty quick and easy. I hilariously tried to test out my slackbot for 10 minute before realizing I was in localhost. Duh.

So here is the long story version of my troubleshooting:
Most of the time I took to build the slackbot was actually the deployment to Heroku, since I have only ever used it once. When the warning “No default language could be detected for this app. HINT: This occurs when Heroku cannot detect the buildpack to use for this application automatically.” popped up, I was pretty clueless (“What’s a Buildpack?”).

So, I went to the Heroku site and added the Python Buildpack. Since it was giving out error message about not detecting Python, it reminded me that I was working with a virtual environment. Thus, I should do a pip freeze > requirement.txt so the deployment environment knows what to load. So I did that. Let’s git push again…

Python app detected Warning: Your application is missing a Procfile. This file tells Heroku how to run your application… Installing python-2.7.12

Python app is detected, but missing a Procfile? Isn’t that just for Django (my only encounter with Procfile so far is the Django Girls tutorial)? Also, why is it installing Python 2.7.12?

A quick Google revealed that I can create a runtime.txt file to state which Python version I want. I also did some reading on Procfile in term of Heroku and Python deployment. For apps, the example provided was web: gunicorn gettingstarted.wsgi and web: gunicorn hello:app. The later seemed to be more for frameworks like Django, so I went with the later and added web: gunicorn starterbot.wsgi –log-file –. I then pip install gunicorn and redo pip freeze > requirement.txt.

Along the way, I also saw another Heroku deployment tutorial that reminded me that I should use .gitignore. That’s right, I shouldn’t deploy my virtual environment files for security reason. That’s why the “SLACK_BOT_TOKEN” and “BOT_ID” are exported in the first place! So I went and delete my Heroku app, deleted my .git, create the .gitignore and Procfile file, and deploy my app again.

The slackbot, however, didn’t seemed to be running. In the slackchat, the dot that indicate activity status remained grey instead of green. Doing heroku logs revealed that “ImportError: No module named ‘starterbot.wsgi’; ‘starterbot’ is not a package“. So its the Procfile. After some more reading and I narrowed down to the Heroku statement that Procfile “…explicitly declares what command should be executed to start your app.“. So, I tried web: python, because that’s what get the program running, right?

That does get it running! At first, it seems to work well, but the slackbot keeps shutting itself down after a while, and it never respond to my command. Another heroku logs reveals that “Stopping all processes with SIGTERM… Process exited with status 143 …Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch… Stopping process with SIGKILL… Process exited with status 137… State changed from starting to crashed“.

It seemed something was wrong with the PORT variable. So, I went to the Heroku site and manually added the PORT config variable, testing the deployment with different port. None seemed to work.

I did a search of “heroku chatbot port”. Surprising, I found the answer in a Node.js tutorial – the author, Luciano Mammino, used “worker: node bin/bot.js” for his Procfile. What would happen if I use “worker: python“?

That got it running, permanently, without any error message about port binding!

My bot is still not outputting anything when I was typing commands though. I added in error checking statement in the if-else statement and eventually realized I have missed a simple colon sign in my command (“@starterbot:”). But once I started adding that, my slackbot worked!

The short, listed version:

  1. heroku create
  2. Find the corresponding app in the Heroku account. Go to Settings and add “SLACK_BOT_TOKEN” and “BOT_ID” to the Config Vars.
  3. pip freeze > requirements.txt
  4. echo “python-3.5.2” > runtime.txt (or whatever Python version you are working with)
  5. echo “worker: python” > Procfile
  6. Add the virtual environment directory name and *.pyc into .gitignore.
  7. Do git add, commit, and push.The bot should be up and running!