Tuesday, September 30, 2014

MakerSquare Day 24: Time--important for traveling salesmen and sleepers (6/1)

This is the beginning of our sixth week, the last week before we move from the junior side to the senior side. Which is both a philosophical shift--from learning programming languages to planning our projects--and a real physical shift, since MakerSquare has two offices, one of which is the HQ for the younger cohort (when they have overlapping cohorts). Which means we have to get in as much ping pong time as we can.

And "time" is on my mind (yes it is), both because we spent part of today thinking about how fast/slow a recursive Fibonacci program would be (answer: much slower than an iterative version--unless you use cache-ing); and because I was up until 1am on Sunday night working out a working draft of my traveling salesman algorithm--the algorithm that beat me on Thursday.

It took a fair amount of time; and then, after I finished (closer to 1:30am) and had a chat with my night-owl housemate, I was a little too energized to fall asleep. Which is why I only had four hours of sleep on Sunday night and spent Monday in that low-sleep-dep fugue.

Still, as much trouble as I have building a traveling salesman algorithm, I love me some abstract data structures--like queues, stacks, and singly/doubly linked lists, which is what rounded out the day.

No, wait: what really rounded out the day was a meeting with my mentor where we discussed writing clear code, which gives me lots of ideas for making comments and clarifying my traveling salesman... tomorrow.

Saturday, September 27, 2014

MakerSquare Day 23: Hackathon Day Two: Getting (the Small) Stuff Done (5/5)

And... scene.

Or if you're not into improv and would rather think of web development as a school/testing environment: Pencils down, everyone.

Because today was the day when our time was up and we had to present our products to the class.

If you've never been in a hackathon situation, here's a key bit of advice I got from everyone: start small. As our friend/housemate/TA told us, when he was taking the class (because, oh yeah, he's also an alum of MakerSquare), at least half the students presented unfinished and unworking prototypes.

Which makes my class look like goddamn rockstars. Not only did everyone have a finished prototype (which seems like an oxymoron but is more an Irish bull), but every group obviously learned something through the process; and, more interesting, every group had some clear ideas about how to make things better.

And my group has some definite ideas about how to improve our web app, Eff Errands, our efficient errand organizing system. (It could also be used for efficient pub crawls, which is another statement that seems oxymoronic, but isn't really.)

Overall, it was a good 36 hours of working, thinking, experimenting, failing, trying new routes, and ultimately succeeding. (For a different POV--and some pictures of the finished(ish) prototype--see Kelsey's blog here.)

It also always interests me that a little bit of work can go a long way. Seriously: it takes about three lines of jQuery to make a list that will slide up or down if you click on it--and it makes people so happy to see that little list sliding around.

The lesson here, of course, is to use slideToggle all the time.

Friday, September 26, 2014

MakerSquare Day 22: Hackathon Day One: A Well-Laid Plan and the Joy of Blowing Things Up (5/4)

I'm right now 16+ hours into my first hackathon and stopping right now to tell you all about it would be a bit like stopping a movie halfway through and saying, "Well, how do you like it?"

The answer usually is "I don't know, but I think I like it. Let's see how it ends."

For those who don't know (hi, mom!), a hackathon is something like a mock production: in 36 hours (more-or-less), we're supposed to go from

  • idea to 
  • design to 
  • implementation to 
  • screaming into pillows to 
  • presenting the product
Usually, hackathons are done in teams, which gives people a nice taste of both taking an idea to a finished(ish) product and working together.

And I'm very thankful for my team. I've got permission to talk about our project before our unveiling Friday afternoon, so: we had four people helping to build our way-finder web app and each person had a pretty clear role, from our front-end UI/web designer, to our Google Maps API expert, to our floating troubleshooter, to our, well, me, who spent today working on the back-end algorithm for finding the best route from place to place.

Which brings me to the somewhat embarrassing part of the hackathon: my algorithm doesn't work. Now, this is both annoying (I like to finish things, I don't like being told I can't do something)*; and not all that big a deal, since Google Maps provides an algorithm for doing what we want it to do.

On the bright side (which I can find--thanks to some useful API), I did get my hands pretty dirty with some deep algorithm reading and a nice tour of some of Ruby that I hadn't played with before. Oh, hello (1.0/0.0) = Infinity!

*You now know the secret to getting me to do something: tell me I can't. Use that secret wisely.

Thursday, September 25, 2014

MakerSquare Day 21: Hackathon (almost)! (5/3)

Instructors, like everyone else, have catch-phrases. Now, it's possible that I was raised on old sitcoms, so I think everyone has catch-phrases, when in reality, only instructors do, but it comes to the same thing.

Instructors have catch-phrases.

And one catch-phrase that we heard several times in one day from our great Javascript instructor is that "The other students are our biggest resource."

And, as much as I like Google for looking for an answer, he's not wrong when he says that. Which is why I'm so excited about the Hackathon starting tomorrow. (Or, rather, starting today, by the time this is posted.)

A large part of today was dedicated to preparing for the Hackathon: coming up with ideas, dividing into teams, asking some questions of ourselves and our instructors (who, I'll admit, are also a pretty good resource).

And here's something else that happened today which may help demonstrate why I'm so excited for tomorrow. (Oh, and also: there will be breakfast tacos.) We started today with a coding challenge: given a list of words, find which words in the list are anagrams of each other; and return an array for each group of anagrams. Following the dictum "make it work," I wrote out several lines of code that were basically readable English. It wasn't an elegant or the fastest solution--it was merely the quickest to write out.

Then a peer/colleague presented her solution and it was this beautiful one line of code that worked because she found the Ruby method that was a perfect match for the task: group_by.

Now maybe in my younger days I would've been jealous to be outdone like that; but with the perspective of my thousands of years (or maybe it just feels that way), I can see that single line of code and just enjoy the elegance.

And also, now I know group_by.

So yeah, the other students are a pretty good resource.

Bring on the Hackathon!

Wednesday, September 24, 2014

MakerSquare Day 20: Time is on my side (5/2)

At the beginning of our second week, I went to meetup for AustinRB to hear a talk on testing. Now, at the beginning of my fifth week, I went to a meetup for Austin on Rails to hear... well, the same talk. Not the same topic of conversation--the same talk, given by the same speaker. And, surprise surprise, I'm able to follow this talk a fair bit more after three weeks of learning.

(Also, after hearing this talk for the second time. But let's just focus on me learning.)

But besides that repeated talk, today was full of churn: new Javascript tricks, new implementation of our Checkers game, new paddles for ping pong, and a new great example of instructor trolling, when our current Javascript instructor launched today's lesson by saying

"I'm sure you all finished the console and the jQuery version of Checkers, so today we're going to bring in Backbone [a Javascript library that we haven't used yet], so you'll probably have to Google that..."

And he went on for a little while before we stopped him to say, no, we were still working on Checkers.

I guess you had to be there to understand how funny it was. But I'm honestly not sure what my favorite part of the day was: the super-cool trick I learned for connecting to my game logic to my mock web-page or our instructor trolling us just to see if we'd stop him.

No, I know: my favorite part was when our instructor started a list of things we learned yesterday and things we found challenging. I'm a sucker for lists. And also feeling like I learned something. But mostly lists.

Tuesday, September 23, 2014

MakerSquare Day 19: There's always a better way (5/1)

I have just finished inventing a new game I call "Checkers," so I may keep this short.*

Today's theme is the title: "There's always a better way," whether you're creating a database or writing a bunch of if/else statements for Checkers.

In today's lesson, the better ways include 
  • a) using ActiveRecord as a programming interface between you and the database, so that you don't have SQL language in the middle of your Ruby program; 
  • b) why you don't need to check if either array is empty in your MergeSort (because if you just attach the two original arrays to your solution array, whichever array is empty will just disappear); and 
  • c) how you can always make your life easier by not trying to make it complex too soon (i.e., if you're programming Checkers, start with moving a piece, then work your way up to jumping).
Also, I'd like to note that I went out after school to meet with my mentor and we had a very pleasant conversation. He also laid out the number of ways he can assist me in preparing for the job market--everything from code reviews to mock interviews (oh, how we will mock those interviews! That's what that means, right?). So now I'm really excited for our next meeting.

Perhaps he would like to play this brand new game I invented.

*Claims of inventing Checkers not fact-checked. I did, however, write a bunch of functions that allows Checkers to be played; and now I have to just slap some interface together and it'll be playable in the console or in a webpage (according to the assignment instructions).**

**Note: Slapping together an interface isn't as fun as it sounds.

Saturday, September 20, 2014

MakerSquare Day 18: I am beginning to love this. (4/5)

To be sure, when I say "this," I am referring to something very particular: Javascript's "this", which is a reserved keyword that refers (roughly speaking) to the context in which it's called.

So, for example, if I write a function--let's call it contextA--and I give that function a this.name property with a return value of "Ben," then any time I'm in contextA and I call this.name, I'm going to get back "Ben."

But if, let's say, contextA calls another function--and, off the top of my head, let's call this one contextB--and contextB calls this.name, it will no longer give back "Ben."

Now, I'm sure, given 10 minutes, I could come up with some non-computer-y analogy that might make this clearer to the average joe and jane, something like:

"this" is the undead hand of a convicted murderer, always pointing back to its traumatic origin story--except for when it doesn't. Which is all the time. Scrap that. "this" is like a compass in a world where everything is magnetic north and also ghosts are out to get you. No, that's not it.

(Also, can you tell Halloween talk is beginning to get to me?)

To sum up, "this" is a strange little word that can be very helpful once you understand what it can do--and what it can't do.

And today, with a great hour of Q&A with our Javascript instructor, I felt something click into place, as if I found a spot for "this"--that undead hand trying to crawl home, that swinging compass needle trying to orient itself.

Now if only Javascript had a "that" as well.

(Actually, it's pretty great that Javascript doesn't have a "that" because this way, if you ever need to save your context at one moment so you can call it later, you can do so by saying
that = this
which makes me so happy.)

Friday, September 19, 2014

MakerSquare Day 17: Javascript: weird or just different? (4/4)

In college (Bard '01, varsity fencer), I took an advanced computer science class that involved a few weeks of working with assembly code.

Assembly is not the computer's native language--we'd call that machine code--but it's pretty close. So after weeks (and semesters) of dealing with higher-level languages, we were thrust into this desert of strange commands and odd syntax. Imagine moving from learning French and suddenly being told that you were going to learn a new language that was all basic phonemes. So now, if you wanted to talk to the computer, you might come up with a sentence in English--and then remember that there's a different syntax (French!)--and then remember that you've got to go even deeper.

That's not exactly what we're going through now, but it gets close: after weeks of dealing with Ruby, we suddenly have been switched to Javascript almost exclusively. And Javascript does not move like Ruby. Javascript has behaviors like closure and first-class functions and hoisting and curly brackets all over. My god, the curly brackets!

But slowly, we are learning.

(Or at the very least, I was able to create a Javascript module to turn a sentence into a mess on purpose.)

Thursday, September 18, 2014

MakerSquare Day 16: The problem with synchronicity (4/3)

I know, that sounds like the title of a heart-warming indie drama--or maybe one of those really low budget science fiction films like Primer--but it really was the focus of this morning's class.

So here's the scenario: you try to get info from a server and get that info to display on your computer. But the internet being what it is, you get some of that information before others; so if you're asking for a poem, you might get the end before the beginning.

If you've read Stephen Hawking's A Brief History of Time, then you're familiar with this black hole/faster-than-light sort of scenario. But in programming, there's a solution that's a bit easier than reading Hawking: AJAX (asynchronous Javascript and XML).

The basic idea of that is that you can hold off on displaying that info until it's all delivered. That was our morning challenge.

If you've been reading along and thinking, "god, how do they fit so many topics in?" then you are not alone. Apparently, our cohort is pretty advanced.

Which was a nice shot of confidence and pride leading into our evening activity, a meet-and-greet with some potential mentors. That was a good time; it's always nice to meet people who are farther along the road than we are and to see how they've progressed; to see how they put these skills we're learning into practice in their day-to-day lives. (Or how they don't--or don't consciously.)

So, it'll be a few days before I pick a mentor/the mentors pick us, but I met some interesting people and it was very interesting.

Note: In grad school, a critic once pointed out that "interesting" was the go-to empty word for talking to people about their work, especially about their presentation. If you didn't like a lecture, you said "it was interesting," the way poets who have nothing to say about another's poetry will say, "I get the sense that you're really playing with language." But here, in programming world, "interesting" isn't exactly so empty. It is also about all I can commit to this late at night, after I have run into the N-Queens problem.

Wednesday, September 17, 2014

MakerSquare Day 15: "Computers are always right and people are always wrong..." (4/2)

"...until we get it right."

That's what one of my instructors said today when we had a brief interlude of philosophical introspection about coding and humanity.

Speaking of humanity, how great, how very altruistic and communal and just plain nice is it, that many programmers put their work up online and share it. In part, it's just interesting to see people's codes and to hear their thoughts about it. But in (probably larger) part, there's the tremendous use value of these tools that people built. For instance, today, we learned about how to use Underscore for templating in Javascript, which, as far as I know, is just something some people made and made available for the rest of us. (Also, is one of the many sentences that I swear makes sense even though it looks like a bad translation.)

Also, today's project was to make a bell ringing program, which meant that our normally quiet classroom was awash in cowbells. And SNL references. Which is not a bad recipe for a day.

P.S. I just remembered, a peer and I passed some pretty terrible ping pong/computer puns around last night, like:

Lili: why does everyone request permission from the database to play ping pong? it has all the tables.

Ben: Why wasn't the Ping pong table able to play online? The net was down.

So, I'm keeping that part of my brain sharp(ish).

Tuesday, September 16, 2014

MakerSquare Day 14: Mondays! (4/1)

Theme: Many roads lead to the palace of wisdom. Or, in this case, the palace of correct implementation.

It's not a great theme, but that's Monday for you. My girlfriend has noted that I have certain cat-like qualities: fast reflexes, purr when chin is scratched, nuzzle when hungry, etc. Has MakerSquare finally completed the transformation and turned me into... Garfield?

Which would explain my sudden urge to mail Nermal to Abu Dhabi.

(It should also be noted that many of my cohort are too young to have marinated in the brilliance that was Garfield and Friends.)

And that long intro should indicate to you that I've had a very long day here, at Chez Code. I don't mean long in hours so much as long in content, if that makes any sense. (If it doesn't, see above comment about "long day.") 

Today started off with seeing the instructor's code for Songify 3 (subtitled: This Time It's Personal and also a Database with a Web portal on top), which was interesting. There are lots of useful ideas I got, but I also noticed that we had a lot of overlaps, which could not always be said of previous code. (::Pats self on back for learning.::)

No, wait, today started off with some Ruby challenges, then Songify (::pats self on back again::), then segued roughly into Javascript (::no pats on the back::). 

Don't get me wrong: I like Javascript and last week I had some really fun and slightly advanced implementations of a pseudo-minesweeper web game. 

(That came about when I finished some work early and the teaching fellow said, "I bet you could make this into pseudo-minesweeper." To which I responded, "Never! That's impossible! Oh, wait, I guess if I..." Which is how a lot of my projects start: "I guess I could do this... which means I could do this... which means...".) 

But today's practice was strangely difficult, and not just for me (thank god). I blame the weekend, which means that, yes, I'm back to blaming Monday, which means that, yes, I am Garfield again.

With one crucial difference: Garfield never stayed up late to run through the practices again and see how he could do better. (Or maybe he did: the cartoon was always a little vague about his evenings.)

Saturday, September 13, 2014

MakerSquare Day 13: Rising tide of teamwork lifts all boats, tables (3/5)

I mentioned the lesson in ping pong I got a couple days ago (both: I got it and I mentioned it a few days ago). But I never told you the revelatory bit of info from that lesson: don't slap the ball, don't even hit the ball--push it.

Which I only mention because it might be useful to you.

You're probably asking, "Why would you want to help me?" I'm glad you asked me that, mysterious stranger, because it gives me a chance to go on and on and on about how I believe humans are naturally both competitive and altruistic, both individualistic and community-minded.

Actually, let's just pretend I went on and on about that topic. If you went through an Ayn Randian phase as a teen (when it's most appropriate), then you might know her idea about the virtue of selfishness: you help everyone by helping yourself. I mostly believe in the reverse: you help yourself by helping other people.

So, for instance, I'll tell you how to play ping pong better and maybe you'll beat me. Or maybe you'll be such tough competition that I'll become a better player by playing against you.

Or, to take an example from this morning, maybe you'll help me extend the legs on this adjustable table--and now we have a standing table in the classroom. Which means that all of us have a chance to get off our keisters sometime during the day. (The keister is where programmers are most vulnerable to work-related injuries.)

Result: everyone's happier and physically more comfortable. Result: All our code is better. Result: Everything is awesome.

Also, in a few weeks we'll be split into teams to complete some bigger project, which is very exciting and interesting to me since we're a huge resource for each other.

As was proved both when we made a standing desk this morning and when we worked on Javascript this afternoon.

Friday, September 12, 2014

MakerSquare Day 12: "Think in trees" (3/4)

At least, that's what our afternoon instructor said. I think he mostly meant that we should "think in trees" as it relates to the DOM--the document object model--which is representation of HTML, where everything is a node and all the nodes are connected in a family-tree-like structure. It's helpful to think in trees so you remember what's a parent node and what's a child node, which is helpful when you style things in CSS* or get things with jQuery**.

But I prefer to take him in the more philosophical sense of "think in trees"; as in, think in improving incrementally, like a tree growing. Or think in a tree's branches, so that all your ideas can spin off into other ideas. (Or, if you're using git, think in branches so that you always have some earlier version to go back to.) Or think in trees because sometimes--always and inevitably--you'll have to prune back your code to improve it.

Which is what I spent a fair amount of the morning doing. Today we started the third part of our Songify project, involving multiple tables in a database. It wasn't easy, particularly because the first change that I made involved me going back and changing a bunch of my old code. Which makes it a weird morning: not very productive in terms of code, but very educational in terms of re-viewing my code.

Today wasn't all sitting through: I did play two games of ping pong and did a lunch-time yoga. I'd be in really OK shape by the end of this program if I wasn't constantly eating.

* Cascading Style Sheets: a way to apply lots of formatting and structure to HTML.
** jQuery: a Javascript library specifically for working with online materials.

Thursday, September 11, 2014

MakerSquare Day 11: If you don't ask, you don't get (3/3)

Today's theme is basically the title.

And it all started with cereal.

See, in classic tech-company style, MakerSquare has a little kitchen with some snacks stocked by the company, including my favorite, Honey Nut Cheerios. (Consider this a plug, and, if you work for General Mills, feel free to send me cereal.) There's milk too, but, gasp!, it's regular cow's milk, which I am allergic to or intolerant to or scared of. (Whichever you prefer.)

So today, after looking at the cereal for two days, I sent an email to someone in the organization asking if we could get soy milk. And instead of telling me I'm a prima donna (which is true), she said, "sure!"

Which goes to show the truth of that old saw: If you don't ask, you don't get.

And that brings me to the structure of MakerSquare, which is very student-centered and student-led in a way. For instance, today, we spent some part of the morning talking about mentorship and about being clear about what you want from your mentor. Then, in the afternoon, we talked about CSS by all coding up a little web page together, with the students offering suggestions on what they'd want to see and then everyone--including the instructor as the final arbiter--figuring out how to write the HTML and CSS to get that.

The rest of my notes for today are all super specific CSS comments, so I'll leave you with the note that I am still terrible at ping pong, but that our master ping pong player just gave me a little lesson.

(Yes, this is tagged "Sinatra" and "Songify" because we spent time doing that, though I didn't have much to say.)

Wednesday, September 10, 2014

MakerSquare Day 10: "Hacky" means something different here (3/2)

From listening to lots of Marc Maron's podcast over the last few years, I've gotten into the habit of referring to jokes as "hacky" when they are too easy, too lazy, too unoriginal. Making a joke about how dumb blondes are--how strict Germans are--how anything any group of people are--all of that could qualify as hacky. (In case you're wondering, from my very limited experience, cruise-ship comedy is often hacky.)

But here, in programming world (which you could image as "Programming World," with a big fun banner over the gate and rides like "It's a Small Loop After All" and the "Hall of Control Flows"), "hacky" means something different. It means something like "ugly" and "ad hoc." In comedy, something is hacky because it's old. In programming, something might be hacky because it's a new, ugly fix to a problem.

And today's problems to fix all revolved around HTML and CSS. Because today we got a big heap of info on website design. All about classes and IDs and how to use the Google Chrome Developer Tools to break websites.

(So, if I send you a picture of the New York Times website with your name in a headline title, well, then either I've been playing around--or they've finally caught up with you for what you did. You know. Don't make me say it.)

Today was also the day when we asked, if you had 100 cats in a row, and either gave a cat a hat or took away the hat you gave every time you stopped at that cat, and if you stopped at every cat the first time through--and then every other cat the second time through--and then every third cat the third time through...

Surprise: the answer is squares of numbers. I did it by hand from 1 to 9 and then my old high school math class kicked in. Of course (my math theory teacher Mr. T. would say), any cat you visit an even number of times won't have a hat; and the only cats you'll visit an odd number of times are those squares. (Like that cat at 36 gets visited at 1 and 36; 2 and 18; 3 and 12; 4 and 9; and... 6. Give that kitty a hat.)

Another big take away from today: the Space Jam website is still up.

Tuesday, September 9, 2014

MakerSquare Day 9: He did it his way (3/1)

Huh, I just realized that I stopped giving each day a theme. Which seems fine now because, really, how do you boil a day down to a theme?

Take today for instance: we started a new project we're calling Songify, a music/playlist manager. So we started by creating a song instance; then we created a database for those songs, along with all the methods that you would need.

(And here I'll talk about one of my strength/weaknesses: I like to do things the best way. I know, it probably sounds like I'm preparing for a job interview, but it's a true problem, and here's the example for the day: I wanted to write a method that could search by album or by artist and return all the songs that matched that category. Off the top of my head, there's a simple way to do that with some basic control flow: ask the user if they want option A or B and give two fully-written methods for each of those options. BUT! Since those options are almost identical, wouldn't it be great if you could somehow provide the switch INSIDE the meat of the method? And that's how I ended up looking around online for a while--even going so far as to post my question to Reddit.)

This program will eventually become a web application of some sort, which I know because we spent the afternoon looking at how Ruby and HTML can interact. The answer is Sinatra, which is a ... well, it's not a "framework" in the technical sense, but that's what most people call it. Curiously, whereas most work in class is hands-on coding, individually or in small groups, this was an all-class discussion and example. Which might sound relaxing, but since it was pretty new, it was pretty intense.

Luckily, I'd spent part of my lunch hour doing a little yoga with some other students, as well as playing ping pong, so I was up for the challenge.

Special bonus note: After class, I went to playtest a video game, which was very interesting--both the game and the process.

And apologies for the title of this blog post, today was full of Frank Sinatra puns and references.

Saturday, September 6, 2014

MakerSquare Day 8: The day we had an actual puppy in class (2/4)

I no longer could stand calling my puppy-breeder classes by that name and today I decided to rename them "PAWS," after the shelter in Chicago where I got my puppy.

Due to a change in schedule, today was entirely dedicated to that one challenge: getting our puppy-breeder (ahem: PAWS) classes to work with our PostgreSQL database.

It was interesting to sit and code on one project for so long. It was especially helpful to have the other students and the instructor just focused on this one issue (getting the Ruby to talk to the database). And I'm glad to say that it all worked out.

I'm also glad to say that we had an actual puppy in class today. One of my fellow students has a service animal, a big German Shepherd (I think) named Mischa, who was very well behaved for the whole day. Which was a cute change of pace for the class. Now we have to start thinking: what other animals can we bring to class? I'd love a trained bear who could walk on my back when it starts to get cramped. Or: how about a trained chiropractor?

Though I'll end this by noting that there's rumors of a student-led yoga session on Monday. What do you wear to a casual class that might also be a yoga session?

Friday, September 5, 2014

MakerSquare Day 7: Puppies and databases--two great flavors! (2/3)

I have added a "puppy" label, since much of this week has been dedicated to that puppy project, which has steadily grown: first we did it; then we added some new functions; and now we're really going deep into databases.

However, the morning was given over to working on and improving our Project Gutenberg algorithm. Which I never explained my version of, so: 

For my first version, I did what I considered the obvious: I trained the program by taking the training books, making a hash for each category, and counting all the meaningful words. (We were given a list of "stopwords" that we could discount, like "and," "the," and "Gutenberg." Part of me rebelled against that since, as we know from Franco Moretti, you can sometimes learn a lot by looking at "the" vs. "a." Lit-nerd out.) I then took the top few words for each category and looked for them in the books-to-be-tested.

But since I was already done with that version on Thursday, I decided to spend my time looking at the TF-IDF version, where you

1) go through a text and count each time a word appears for that text (the TF or term frequency); and

2) go through a set of texts and count how many texts have that word--and then take the log of the ratio (the IDF or inverse document frequency.

Weird, right? Anyway, that gives you a number that tells you how important a word is to a set of documents. So you can use that word score to help judge what genre a book is in.

Which was a long and interesting trip that resulted in a score that wasn't too much higher. Ah well.

After that, we did more database stuff for our puppy program.

Also, ping pong. Am I getting better? Well, I'm not getting worse.

Thursday, September 4, 2014

MakerSquare Day 6: Johannes Gutenberg, master of algorithms (2/2)

We did a little more work today on our puppy-breeder classes, but it was nothing compared to our new and fabulous (for me) algorithm assignment: we had to write a program that would take in a set of books from Project Gutenberg and would tell us the genre! Now, if you've ever talked to me before, you know I'm a huge nerd for genre, trying to find the weird edge-cases between science fiction and fantasy and other genres of novels.

This was not that kind of genre test.

We were given a batch of books that we knew were either astronomy, philosophy, physics, or religion. We had to write a program that would take those books and those categories; and then apply what it had "learned" to some other books which did fit into one of those programs.

Which is kind of a perfect intersection of my grad school career studying English and my new career.

So, ahem, bragging alert. Awoo. Awoo.

By lunch time, I had reached 100% with a time hovering around the 6-8 second mark.

[Edited to add: Since then I have had a friend run it on her newer computer and it runs around 3-4 seconds.]

Bragging alert off.

[Edited to add: Especially because the next day, people had come up with versions that were faster than mine. Still, it was nice to have the earliest complete version.]

The rest of the day was dedicated to our puppy breeder classes; and more specifically, to learning how to use a database to store information. Which was super abstract and not at all like the fun I was having with the Gutenberg project. Though maybe I was the only one who found Gutenberg fun.

Wednesday, September 3, 2014

MakerSquare Day 5: Swimming with a new pod (2/1)

Our second week started with a bunch of pod-switching, which makes me realize I never described our office beyond "has a ping pong table." Really, the ping pong table is most important. But if you must know, we have three big desks that the students sit at; along with a tall desk for the instructors; and a wireless-enabled projector that has only once or twice accidentally picked up on someone's music or Skype call.

First week, I was in pod one; second week, pod two. Which seems like a great idea. I could imagine someone saying "why do we need to do this?" But already I've had more conversations with my new pod-mates than I had with them when they were not my podmates. Of course, given my sentimental nature, I'll probably start thinking of pod two as a close family and then get wrenched away from them next week.

Speaking of wrenching away, today's big project was to work on something for a puppy breeder. (If I can get political for a second: people, check with your local animal shelter or rescue before purchasing a puppy from a store or breeder.) There was a lot of individual coding time working on setting up the tests and turning them green. 

Bonus challenge: we were given a list of things the client wanted... which was not all the information we needed. The lesson being that sometimes you got to form questions to ask the client so that you can do your work. Or that our client was irredeemably sloppy in their thinking and should not be allowed to have any puppies.

Extra bonus: after class, a few of us went to a meetup for the Austin Ruby community, which was interesting since the topic was testing and rspec and how sometimes you shouldn't let your tests drive your programming. All in all, it was very interesting to meet some experienced web dev and programming people.

Though my real takeaway was this line of argument, which I'm paraphrasing from something that night's speaker said:

"When something is painful, it is broken; make it better—nobody else can."

I don't know about you--like, literally, I have no idea who you are reading this--but that line moved me some. With all this talk about Ruby and rspec, we shouldn't forget to make our code beautiful in its own way. Or put another way: don't forget to have fun.