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.

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.

In part I, I explained how I’m attempting to write a webapp that can solve simple Sudoku puzzles. Since then, I’ve made some progress. This series will track what I’ve been working on, learning, and any difficulties I’m encountering.

With a goal in mind, it was time to just dive in and go.

Step 1: Oh God, what is this even…

At first, it was kind of overwhelming. Where do I even start? How the heck am I going to even tackle any of this?

After learning the basics of Javascript loops, functions, arrays, and objects, thanks to Codecademy, I was mostly ready to go. What was my real first step? How the heck do I even manipulate data on a webpage, let alone collect and analyze it?

After a few tries, I had a simple project featuring a table (with cells individually labeled) up and running!

After some more tinkering, I was able to get the “Generate Numbers!” button to actually randomly generate the numbers 1 through 9 and fill in the cells without repeating any numbers. Sweet!

Hey, that’s kind of cool. Now we’re getting somewhere! I think I was ready to take it to the next level.

Step 2: Okay… I guess we need to make a fake Sudoku grid.

There’s probably simpler ways to go about doing this, but I ended up spending a lot of time figuring out how to build a Sudoku grid in the first place. Hey, I wanted this project to look somewhat presentable when I showed it off and (hopefully) finished it.

HTML tables were driving me crazy, so I just straight up stole this helpful thing after Googling for an answer. It looks pretty good. Pretty, pretty, pretty good.

“Wow, sir. That looks so good that I’d like to take two!”

Alright, one mission accomplished. Now onto another mission. How do I completely fill out the entire grid? I started with this, because I wanted to understand how to try to isolate certain sections of the Sudoku grid and see if I could create a series of non-duplicated random numbers.

Why did I start with randomly generating numbers? I initially thought I would just try to brute force solve some simple beginner’s level puzzles, but I later realized how ridiculous this would be. There’s a ridiculous number of possible permutations to try.

For now though, I decided to start filling out random numbers by row. This is what my initial code looked like.

[javascript]
function fillTable(row) {
for (var i = 1; i <= maxColumns; i++) {
var selectCell = row + i;
//console.log(selectCell);
document.getElementById(selectCell).innerHTML = fillCell(selectCell);
if (i == maxColumns && row != maxRow) {
i = 0;
row = nextChar(row);
} else if (i == maxColumns && row == maxRow) {
break;
}
}
}
[/javascript]

Did it work? Yes! I ended up with grid of random numbers filled out! Sure, there’s really no rhyme or reason for where numbers ended up, but it certainly looks like a completed Sudoku puzzle, right?

Step 3: Let’s put some real numbers in there

Alright, entering a bunch of random numbers into a grid is pretty fun for all of 5 minutes. (To be honest, it was pretty fun) But to take this to the next level, I really needed to have the beginning of a Sudoku puzzle in there.

A few quick Google searches later, and I found a suitable candidate! One thing I decided early on was to store all this data in an object — mostly so I could easily update it with different puzzles later on. It ended up looking like this.

[javascript]
var allCells = {
a1: "", a2: 1, a3: "", a4: 6, a5: "", a6: 4, a7: 3, a8: "", a9: 7,
b1: 3, b2: 5, b3: 6, b4: "", b5: "", b6: "", b7: "", b8: "", b9: "",
c1: "", c2: "", c3: "", c4: "", c5: 5, c6: 3, c7: 6, c8: 9, c9: "",
d1: "", d2: 8, d3: 3, d4: 2, d5: 6, d6: "", d7: 4, d8: "", d9: 9,
e1: "", e2: "", e3: "", e4: "", e5: "", e6: "", e7: "", e8: "", e9: "",
f1: 4, f2: "", f3: 5, f4: "", f5: 7, f6: 8, f7: 2, f8: 6, f9: "",
g1: "", g2: "", g3: "", g4: "", g5: "", g6: "", g7: "", g8: "", g9: "",
h1: "", h2: "", h3: "", h4: "", h5: "", h6: "", h7: 7, h8: 2, h9: 4,
i1: 7, i2: "", i3: 9, i4: 4, i5: "", i6: 2, i7: "", i8: 8, i9: ""
};
[/javascript]

On top of this, I wanted to easily differentiate the initial numbers that were created on a brand new board (so I could easily see what my script was generating, versus what was already in place on the board). I wrote a function to modify the DOM and change the font weight and background color of the starting cells.

[javascript]
function setupBoard(row) {
var row = row;
var cellValue = 0;
for (i = 0; i < maxColumns; i++) {
//console.log("ROW: " + row + (i+1));
cellValue = allCells[row+(i+1)];
document.getElementById(row + (i+1)).innerHTML = allCells[row+(i+1)];

// Just highlighting what cells we initially started with.
if (Number(cellValue) > 0) {
document.getElementById(row + (i+1)).style.fontWeight = "bold";
document.getElementById(row + (i+1)).style.backgroundColor = "#F2F2F2";
} else {
// Use this to count up total number of empty cells that we need to solve for
// The idea is that we can use this to detect if we’re stuck
emptyCells++;
}
}
}
[/javascript]

You’ll notice I have a lot of console.log() calls commented out. I liberally used these all over the place so I could make sure things were working correctly. Anyway, once all that was said and done, it ended up generating a board that looked like this.

Wow, we’re starting to chug along pretty nicely! Next time, I’ll talk about the million different functions I created in trying to solve this.

This series of posts will track what I’ve been working on, new things I’ve been learning, and any difficulties I’m encountering along the way. Buckle up!

One of the things I resolved to do this year was spend a bit more time learning to code. Sure, sure, I’ve dabbled in things like PHP and have used MySQL to build some pretty basic websites and tools.

Even with the little I’ve done, I’ve always enjoyed it and have found myself losing track of time while trying to solve some problem or just get this certain thing to work. It reminds me of a similar thing I’ve encountered with the addictive nature of Sid Meier’s Civilization games.

“Just one more turn…”

Late last year, I mentioned to a coworker my desire to spend a bit more time learning various techniques and theory. He suggested that if I’m serious, I should really just start trying to tackle some problems and we could go over it together.

The first thing he suggested? I should build a application to solve a Sudoku puzzle.

What??!

As tends to happen, the end of the year got a bit hectic and I put this project on the backburner. When I originally considered it, I was going to try and write it in PHP. However, I recently saw this goofy map of popular programming languages by state and thought, “I’ve never really done anything with Javascript. Maybe I should try that.”

So, that’s what I’ve been doing the last few weeks. Between taking some awesome online courses through Codecademy and Udemy, as well as reading up on various books, I’ve been trying to really get into it.

How am I doing? I’ll try to share my progress in future updates.

I’m talking robots to a bunch of middle schoolers who visited Engadget HQ for Hour of Code.