I thought yesterday was a bit frustrating and hard. That was nothing compared to today. Today was excruciatingly difficult! The amazing thing is that it went from shaking my confidence to my core to leaving with a feeling of exhilaration and renewed sense of understanding.

We started off with our first self-assessment. These are basically timed tests that feature a handful of problems you need to solve (in this case, you’re basically writing some helper functions) and test yourself. Once you’re happy and confident in your results, you push it to Github and submit a pull request on the main Hack Reactor repo. A helpful robot runs your code against its own internal test suite and gives you some basic results.

I did bad. Like real bad. There were 35 possible points and I got 18. One of the reasons is that I just didn’t pay attention to how many problems there were. So, I mostly finished 4 of them, thought I had extra time and went back to clean them up.

When the warning bell sounded to let us know we needed to turn in our tests, I loaded up the Readme file and copied all the grading criteria for each problem (which we submit as a comment on our pull request). That’s when I noticed there were 5 problems.

Oh, shit.

I quickly added some “pseudo code”, basically a bunch of comments in the code about what I would do if I actually had time.

Fortunately, it sounds like a lot of others were in the same boat. Man, oh man. Welcome to Hack Reactor.

Our mid morning lecture consisted of coding best practices and then a very basic intro to data structures. We were turned loose to attempt some problems before lunch.

Telling people about food trucks has turned me into a popular guy! There were about 11 people waiting to leave with me at lunch. It was pretty fun and I got to know some of my fellow classmates a bit better.

Afterward, we had more lectures, this time that focused on debugging tools. We were them split into pairs based on our knowledge of 10 questions related to data structures (I only knew 2 of the 10 answers). So my partner and I were relatively new to this whole coding thing.

From the moment we dived in, it was a disaster. Not between us, though! We were just in over our heads trying to solve some of these new problems! We talked ourselves in circles and couldn’t get any of our tests to pass. We kind of just spun out wheels for an hour and a half.

We went to dinner and were just totally demoralized. He went somewhere to focus on some of the solo modules that were assigned to us, while I started looking up resources that could better explain some of the things I was having difficulty with. After an hour or so, I felt like I was understanding things better. It also helped that a Hacker in Residence sat down with me to explain things.

When my partner came back, he seemed refreshed and was ready to dive back into things with both of our newfound knowledge. Things just clicked and it’s like we really started to understand things. It was awesome!

We even took the time to go back and rewrite one of the solutions that was giving us so much trouble. It’s kind of crazy to think about how low we were feeling earlier in the day and how high we ended up.

Today was a little more intense. We basically covered the rest of the pre-course review material. My coding partner, Daniel, and I were able to work through the rest of the problems but I felt like I struggled a bit. He exhibited a lot of patience and understanding while helping me to work through things.

Ultimately, we got through everything and I think I understood it! But it does shake the confidence ever so slightly. That said, we were able to quickly work through rewriting a number of functions that proved difficult during our pre-course. Stuff like _.memoize, .reject, .filter, .every and a few others.

The morning lectures were a town hall format where we asked questions based on certain topics we studied on our own. This featured things like scopes and closures. Overall, I think I am pretty comfortable with the concept though people were asking some crazy questions that made me wonder if I was missing anything. Basically, stuff like memory management and such.

Our instructor said that this was unnecessary complexity that we shouldn’t worry about right now, which is really reassuring. One of his awesome quotes was that pre-optimization is the enemy of progress. Really, we shouldn’t concern ourselves with that at all right now. Marcus said that we should optimize our web apps when there’s an actual problem that needs optimization. I’ll need to keep that in mind.

In the afternoon, we finished up rewriting our underbar functions and then had a lecture on how to succeed at Hack Reactor.

There was a lot of great stuff in the lecture that focused on the personality, technical backgrounds (and lack thereof) that go into the ideal HR student / graduate. Things like:

Fixed vs Growth Mindset

- Some think their value is based on some intrinsic quality. Others think is can change over time.
- Growth mindset: Experience joy at failing at a thing and treat it as a learning process.
- What kinds of people need a growth mindset? Effective learners and effective programmers.

Coding isn't fast
- This is why people deride the idea of improving VIM and emacs skills – so little keystrokes. You should be thinking about the program / problem, not the application you use.

How can I tell how I'm doing?
- Don't gauge yourself with regard to others! Only with the curriculum.

This lecture took about 1 and a half hours and ended at 8pm. Marcus (who is a co-founder of Hack Reactor and a CTO) dismissed the class but held an optional fireside chat that around a dozen of us took part it. It was kind of awesome to have this personal one on one time with him.

Everyone asked him tons of questions on best companies to work for, taking equity vs salary, interview questions, how to find out if the culture is right, etc. It was interesting but I was personally more interested in what he had to say about how we could succeed RIGHT NOW and in the next 12 weeks.

So, I asked him what those of us from less technical backgrounds could do to cope with or reduce “imposter syndrome,” that tinge of self doubt the seems to crop up every now and then. At this point about a quarter of the remaining students left. Sorry, dudes!

Anyway, he had some great answers in how we should trust Hack Reactor and trust our peers who are helping us and supporting us. He said that if it’s really an issue, we should ultimately talk to HR staff and make sure everything is staying on track. I kind of felt like some of the other students think that I’m considering quitting. No way! I just want to make sure I’m doing everything I can to be in the right place, mentally and emotionally.

Another student followed up a bit later with a question on how students with lesser tech background could avoid being bogged down in complexity and only focus on what we need to worry about. He brought up the point about students asking about memory management techniques and how that sort of thing is unnecessary, especially when we’re just trying to grasp the basics.

Anyway, that was it. Only 2 questions out of 2 dozen that wanted to know how we should deal with things going on now. Overall though, it was really awesome to have more personal communication with him and have him get to know me as well.

Like last night, we wrapped things up just after 9 PM. Another 13 hour day. Crazy! Tomorrow, we start learning new stuff for the first time! It’s all about data structures for the next 4 days.

What a day! I arrived at Hack Reactor at about 8:20AM to find the 7th floor landing overflowing with new students. There was a lot of excited chatting as we waited for the doors to open so we could take our class photos and get out information packets.

We had brief introductions as everyone went around and shared a fun fact about themselves. Then we dived right into it!

We had lectures that talked about life at Hack Reactor and what to expect over the next 13 weeks and it was full of a lot of stuff like how HR can benefit us over competing career acceleration programs.

They mentioned that some of the goals of Hack Reactor are:

Autonomy: Confidence that you can find a solution

“Some problems are going to suck and are broken on purpose. That’s good for you!”

Make us strong software engineers:
- CS (and software engineering) fundamentals
- Native to web
- JS expertise

How hard is this going to be?

They had a slide that said “Very, very hard.” Then another slide that said “Then think about how hard that is and keep going.” It’s a boot camp!

After the welcome lecture, we started to review the recursion exercise we worked on during our coursework as well as the underbar exercise.

Their strategy is to basically give you a small taste of a topic or idea and then throw you in the deep end of the pool. It’s crazy! This was a lot of folks first experience with pair programming. I feel pretty fortunate to have done this before (thanks to a one-day class at Hack Reactor back in March).

My partner and I clicked really well and we were able to quickly work through rewriting both the recursion and underbar exercises. We were even starting to tackle the extra credit. I’m not saying that to brag, it was just such a great feeling to suddenly understand something and work with someone else who bounced ideas back and forth.

I think that’s going to be one of the biggest things during the program. It’s going to make is more effective communicators and able to know how to solve technical problems. I’m really excited about it!

One thing I noticed is that time REALLY flies. We start working on an assignment, and before I know it, time is up. It’s kind of amazing. I think that’s going to be indicative of how the whole program is going to.

In the evening, we had a mixer with the senior class – these are the people who are starting the second half of the HR program (they are now in week 7). We played a bingo game where we had to match names up with some random and crazy facts that people had previously written about themselves. It was a great way to break the ice.

It seems like there’s a ton of ridiculously friendly, smart, enthusiastic, and positive people in my particular cohort (and enrolled in the program as a whole).

I wrapped up things at around 9:10PM and just hopped on BART to head home. That’s about 13 hours today. Wow. Oh wow!

Current Version: 0.1.4

Say hello to NodeEBot (pronounced as “nodey bot” or even “naughty bot”, if you prefer). It stands for Node E-books Bot.

It’s a Nodejs package for creating Twitter bots which can write their own tweets and interact with other users (by favoriting, replying, and following). This project draws heavy inspiration from the twitter_ebooks gem for Ruby.

You can see two examples of this bot in action at @daveleeeeee and @roboderp.

Installation and Usage

This project requires Nodejs v0.10.35+. If you’re looking for a place to host Nodejs projects, I’ve had success setting up a free Ubuntu virtual server through Amazon’s Web Services dashboard and installing nodejs on it.

To run, copy the project into your preferred directory and then install the required dependencies using:

npm install

You can edit various configuration settings in the bot.js file. Before you can begin you’ll need to have Twitter API credentials which can be setup right here. Once you have your consumer API key and secret as well as your access token and secret, add them to the top of the bot.js file:

// Twitter API configuration
var client = new Twitter({
  consumer_key: ‘xxxx’,
  consumer_secret: ‘xxxx’,
  access_token_key: ‘xxxx’,
  access_token_secret: ‘xxxx’
});

You’ll also need to add the Twitter username of your bot (without the @ symbol) to the config file. (This is for tracking mentions as well as making sure the bot ignores actions from itself so it doesn’t get caught in a loop).

// Your robot’s Twitter username (without the @ symbol)
// We use this to search for mentions of the robot and to prevent it from replying to itself
robotName = “xxxx”;

Once that’s done, the bot is almost ready to go. You can modify a few other settings that influence how chatty the bot is, how often it will interact with other users or use random hashtags and emojis.

In order to run the bot, I use the forever npm package. This allows us to automatically restart the server in case of a crash, as well as force restart the server in order to reload the Twitter stream (added in v 0.1.2).

Source material

The one last thing that you’ll need to do is give it some source material to generate text from. I use source material my own Twitter archive.

Right now, I haven’t implemented a way to parse the Twitter’s csv data that’s generated when you request your history. In the meantime, I’ve simply opened up the tweets.csv in a spreadsheet app, copied the contents of the ‘text’ column into a new file and used that as the source material. This script will treat each line as a separate and unique sentence.

I’ve added some basic ability to strip our Twitter usernames and URLs from the archive. That means it will treat something like:

@davely That’s great. I’ve seen something like that before. 
http://flickr.com/…

as

That’s great. I’ve seen something like that before.

Running multiple bots

If you want to run multiple bots for different Twitter accounts, copy this project into separate folders (e.g., ~/MyBot1, ~/MyBot2, ~/MyBot3, etc) and make sure you input the proper Twitter API credentials at the top of each bot.js file. Then spool up separate node instances and load up the relevant bot files.

Future things to do.

• Better modularization of our script. Right now it’s in one ginormous .js file.
• Turn it into a proper npm module.
• Better regex handling to clean up source material (e.g., links, usernames, etc
• Send direct messages back to users who DM our robot.
• Keyword ranking of our source material. (Sort of implemented but disabled right now since performance is SLOW.)
• Allow robot to reply with some content (e.g., if someone asks what it thinks about ‘baseball,’ it tries to compose a reply that mentions ‘baseball.’
• Retweet various tweets that it finds interesting based on keywords and interests.
• Let it potentially upload images or GIFs.

Changelog

v 0.1.4 (2015/05/07)

• Simple change to load and require underscore. This is going to help simplify some of my functions in future development.

v 0.1.3 (2015/04/28)

• Fixed bug that would cause bot to think that all users replying to it were found in our otherBots array and kept applying a temporary time out on replies, even if not needed.

v 0.1.2 (2015/04/27)

• Implemented a hacky fix for an issue I’m having with the Twitter Streaming API randomly dying without an error. If we’re running this with the npm package forever, let’s kill the server and restart if ever few hours.

v 0.1.1 (2015/04/19)

• Initial public release!

Other stuff

If you end up using this script in your own Twitter bots, let me know! I’d love to know how it works out for you and please let me know about any improvements or suggestions you might have.

Thanks for checking it out!

You can download the source code for nodeEbot on Github.

One of my favorite computer games, Out of the Park Baseball, released its latest version just in time for the 2015 baseball season (one of the biggest features this year is the official MLB license — that means real team names and logos!). I’ll have to write up a more in-depth review later, but first I wanted to share this screenshot from a recent game.

The situation: I took over management of the Los Angeles Dodgers in 2015 (sorry, Andrew Friedman, I know you just got this job and all, but it’s time for a new sheriff) and I eventually navigated them to the 2017 World Series!

In game 2, Zack Greinke is pitching for the Dodgers, and LA ends up scoring 7 runs in the first inning! Greinke hits TWO homeruns during the game and on top of all that, Texas still came back and nearly won. Crazy!

(Click screenshot for larger view.)

Anyway, the Dodgers would go on to win the 2017 World Series by sweeping Texas in 4 games. 😉

I’ve been playing around with Node.js recently and taking some of the neat online lessons available through Nodeschool. One of the lessons involved streaming realtime data between the client and server using Socket.io.

This sounded insanely powerful and fun, so I took a break from the rest of the lessons and started playing around with Socket.io. They have a tutorial that explains how to build a simple, realtime chat application using its library in about 20 minutes.

I’ve uploaded the results of this little project to Github and you can view it right here. This little web app is more or less a result of tutorial and I’ve added some additional stuff as I played around with it:

• Usernames!
• Number of active users!
• Display a list of all connected users!
• Check for identical usernames and prompt for different name
• Timestamps on messages!
• Sanitizing user input!
• Properly autolink URLs!
• Detect if a link to an image is pasted in and expand!
• Display welcome message on connect

All in all, it’s been a really fun learning process and has given me some ideas on how to use Node.js for future realtime applications.

Note: You can see this in action on Heroku. You’ll probably be the only one only, but hey! https://davechat.herokuapp.com/

This past weekend, I played around with jQuery, JavaScript, and Twitter’s API to create a web app that displays realtime search results for various baseball teams. I figure this is particularly important since pitchers and catchers report in about 10 days! 🙂

Anyway, the goal of this project was to rapidly build out a web app that could search and parse publicly available data (e.g., tweets!) for mentions of particular baseball teams while using various jQuery and JavaScript libraries. I could see this app having potentially wider uses beyond baseball such as returning the latest tweets from an event or hashtag. It also gave me a chance to use various libraries and frameworks as well. I’m pretty happy with how it turned out.

You can see it in action right here and the source code is available on Github.

Earlier this year, I joined a group on Meetup dedicated to creating, analyzing, and talking about digital maps. It’s organized by the fine folks at #Maptime, who have an amazing enthusiasm for all things map related. It sounded like something that’s right up my alley, considering all the time I spend thinking about maps.

Last night was project night. All sorts of folks were there, working on complicated issues such as transit, land use, green space, climate effects. It’s kind of inspiring!

I went to focus on some less lofty goals — I just wanted to get some experience playing with a JavaScript mapping library created by a company called Mapbox. My goal was to get the library up and running and then use it to display some geo-encoded data from a service I happen to use a lot: Foursquare.

It’s no secret that I really like Foursquare — mainly for keeping track of our adventures far and wide. I found a helpful PHP library for converting Foursquare (and other social networking) data into GeoJSON, which is needed by the JavaScript mapping libraries. After a couple of hours of hacking around, I got something up and running!

Pretty neat stuff! I have some ideas on how to improve this and some additional data that I want to show in the future.

This past weekend, I completed my first official half marathon after participating in the 32nd annual Kaiser Permanente San Francisco Half Marathon! The course was fairly flat and wound its way through Golden Gate Park and along Ocean Beach. You couldn’t have asked for better better weather or scenery! Overall, it was the perfect event for a new runner like myself.

My official result? 2:17:32. That’s kind of the nice thing about your first half marathon — any time is a new personal record. I’ve been training off and on for the last few months (and indeed, I could have trained more) and was hoping to hit 2 hours.

As it turns out, I was on pace to do it until one of my calves started to cramp up exactly half way through the race, forcing me to take a stretching break and limp through the remainder of the course.

That’s me at mile 8! via @kerryme.

That said, it was still a really positive and fun experience and it’s something I’d like to do more of! Which is good, because I signed up for the Oakland Running Festival in March. Oh, boy!

A couple things I learned:

• I brought my own water bottle (mainly so I could eat some of the gross energy gels that I brought with me). Overall, I wasn’t too distracted by it — I had brought a disposable bottle just in case it was annoying and I needed to chuck it. However, I skipped a bunch of water stations at the beginning of the race since I figured I had water. Big mistake! I should have taken advantage of the free water and gatorade (and used it to time when I should have consumed the gels). As it is, I ran out of water at around mile 10.
• The gels really helped! I had the Cliff Bar variety. While they were really thick and gross to consume, I really felt that they gave me energy and I didn’t really hit a wall until the last mile and a half or so of the race. More than anything, I was distracted about my tight calf!
• Someone else had mentioned this to me in the past, but I basically found someone who was running at a pace I was mostly comfortable with and I ended up sticking close to them for the first 6 miles. Trying to keep up with him was kind of a fun game.
• I also discovered the “awful truth about jogging that no one ever talks about.” Oh, man is it true!