I've finally written my first real Android app. I dabbled a bit with Android development in the very early days, writing an app that interacted with the web services of the company I was working for at the time. This app was ugly, written for Froyo, and frankly barely worked at all. It was a 20% time project at my then-employer, but I never went back and worked on it after the initial effort, and never even bothered getting it packaged into the Android Market, largely out of embarrassment.
I've been wanting to get into Android development more seriously since that effort, because I overall liked the idea, and as a big Android user myself, I felt that it was essential I be able to develop applications for my own device, as being unable to do so was a lot like using Linux without the ability to write shell scripts.
I've taken two all-day training sessions on Android before as part of larger development conferences, and while I was able to suss out some basics about the lifecycle and other Android fundamentals from them, neither left me with any sense of real understanding of how I could develop something for Android that people might actually use. But at OSCON 2013, I took an excellent half-day Android class taught by Marko Garenta. Among other things, he showed me, for the first time, how to write a modern-looking Holo app, how to use asynchronous background tasks, how to transition between multiple activities, and how to handle fragmentation issues. These were never touched on in my all-day sessions, and they're all large barriers to writing real applications.
Once I left the class I had a sense that I actually now knew enough that, with some help from web searches, I could actually write an Android app. I just needed a good idea, so I tried to take notice of various itches in my life to see if I could scratch any with a phone app.
This year, I went to O'Reilly's Open Source Convention, OSCON. Every year for the last four years, I've gone to a big tech conference. For the last three, I went to NoFluffJustStuff, which was later renamed UberConf. UberConf is held in my home state, I can drive to it from my house every day so there's no plane or hotel involved, which makes it inexpensive enough that I've been able to get my employers to pay for it. However, due to having attended UberConf consecutively for three years, last year I'd seen about half the sessions already either in previous years on at local Java User Group meetings, so I decided that this year I'd try something different.
OSCON was a radical departure for me. UberConf is a "Java/Agility" conference, and since I work almost exclusively with the JVM in an Agile environment, it's more or less custom-tailored to my interests. OSCON, however, had a huge variety of different tracks and a similarly varied group of attendees. There were Python folks, Ruby folks, hardware hackers, system admins, operations gurus, cloud nerds, data geeks, perl wonks, and more. I picked OSCON because, while the variety was less tailored to my interests, the sheer number of tracks (18 concurrent sessions per time slot!) made up for it.
Here is my review of the OSCON experience. OSCON was the first conference I've been to outside of my home state, and really the first one not run by the Rocky Mountain Software Symposium. As such, it will be unavoidable that I will be comparing it largely to my UberConf experience, since it's my only real frame of reference. I will try to address each element of the conference separately.
First thing's first, how were the sessions? I don't go to tech conferences to network or hand out business cards, though I hear that's half the point. I treat conferences like an intense week of school, I take notes and try to learn as much as I can in the sessions. A tech conference's quality is going to be 95% the quality of the sessions for me, so they're the most important thing by far.
I don't post book reviews here very often. Typically I write up a few paragraphs about a book when I finish it and post it to my Goodreads account, which I consider enough of a review for nearly every book I read.
But "Presentation Patterns: Techniques for Crafting Better Presentations" by Neal Ford, Matthew McCullough, Nathaniel Schutta is a bit more than a book. I'm not joking when I say this book has actually changed my life. As such, I felt it was necessary to devote an entire post to it to draw extra attention to it.
In the interest of full disclosure, I should admit that I know the authors personally, sort of. I've had a conversation or two with Neal and Nathaniel at various developer conferences, though I seriously doubt either of them would remember or even think my face looks familiar. McCullough I've interacted with quite a bit more, but I once managed to get him to tell me he wanted to punch me in the face. If you've ever met Matthew, you'd know this is pretty much like getting Gandhi to call you a stupid asshole. The point is, I'm not affiliated with the authors or getting anything out of promoting the book. I just found it extremely valuable and wanted to share it.
In any case, Presentation Patterns is excellent. The book is full of tons of real-world, usable tips, ranging from how to speak clearly to how to organize your thoughts to the actual mechanics of doing specific things in Keynote and Powerpoint. It's very detailed in this way, rarely leaving the reader wondering how to do a thing the book describes. Reading this book after seeing many presentations by speakers like Ford, McCullough, and Schutta was an eye-opening experience, something akin to seeing how the sausage is made.
Another semester is over, and it was quite the doozy like the last one. This time, however, it wasn't because I hated the workload (like last semester) but because I hated the material. Or more specifically, half of it, but more on that later.
This semester, I finally took the cross-department course from the Business School that I was dreading. My school's program is a joint-degree, Computer Science and Information Systems, with the CS stuff coming from the Engineering school and the IS stuff coming from the Business school. The degree has a number of requirements but one of them is that you must take at least one PhD-level class in each school. This means that I am able to take nothing but pure-CS courses, except I have to take one PhD-level course in the Business school. I've been dreading this since I started, somehow hoping this requirement would be removed before I had to take it, but this was not the case, and I had to take it this semester. With the credits I am able to transfer from my Master's degree, this actually completes all of my course requirements, but because I was interested I also took a course on Graph Theory, which was a class crosslisted as both an undergrad and master's level class. And once again, I somehow managed to get stuck grading.
I started the semester taking three courses on Coursera as well, but quickly decided that doing so contributed to my sense of being overwhelmed last semester, so I quickly dropped them and decided to download all of the lectures when the classes ended, and hence won't be mentioning them further.
Applied Graph Theory
To catch people up on some blogosphere drama:
Last month, Heather Arthur posted on her blog about an unfortunate incident in which some people on Twitter had found some code she wrote in GitHub, and people started trashing her on Twitter for it. Some of those people are considered leaders in the Software Craftsmanship movement, in particular Corey Haines. Corey immediately apologized for acting like an asshole, and I think his apology was sincere because I've met Corey and frankly the guy is almost annoyingly nice (he went around RubyConf 2012 taking a picture with every damn person there). But Ted Neward saw this turn of events and concluded that Corey's actions were not orthogonal to his involvement in Software Craftsmanship, but actually influenced by them, and he posted as such on his blog.
Neward's basic point is that this is the exact kind of behavior we should expect as a side effect of the Software Craftsmanship movement. By it's nature, it attempts to create a segregation between those who are "in the know" and those who are not, and he felt the behavior of Corey and others was a byproduct of this segregation. They saw Heather as an "other" and were overly harsh in their criticisms, emboldened in so doing by their sense of Craftsmanship. Neward took a lot of shit for this view on Twitter, with most people arguing that this was done by Software Craftsmen, but it wasn't done because they were Software Craftsmen, and it makes no sense to criticize the entire movement based on the action of a few members, regardless of how high their profile is. Neward responded to all of this feedback in a second blog post, where he reinforces his original point.
Uncle Bob Martin, one of the first five signers of the Software Craftsmanship Manifesto and author of Clean Code and The Clean Coder, then responded to all of this drama with his own post. Bob takes particular issue with Neward's promotion of what he sees as the opposite of a Software Craftsman, a Software Laborer. In Neward's words, a Laborer is someone "who cranked out one crappy app after another in (what else?) Visual Basic [...] their apps were sloppy, bloated, and ugly...cut-and-paste cobbled-together duct-tape wonders." At the end of the post, Neward bows "with respect to the "software laborers" of the world, who churn out quality code without concern for "craftsmanship", because their lives are more than just their code."
My third semester in the PhD program is over, and it has unquestionably been my hardest yet. I bit off way more than I could chew, this semester was extremely unpleasant and, for the first time since going back to school, I was glad for the semester to end.
I took two 7000-level PhD courses at once (previously I had only done one in a semester) which was part of the problem. Originally I was planning on doing three, but quickly decided that was insane and dropped one of the classes, which I'll now be taking in the Spring. One of these two remaining classes was material I had never been exposed to at all, and it also happened to be structured in a way that would have made it exceptionally difficult even if I had, while the other was material to which I had minimal exposure. I also took two courses on Coursera during this period of time, both of which I took quite seriously, as though they were credit courses. And if all of that wasn't crazy enough, I managed to once again get roped into grading.
Textbook: Artificial Intelligence, 2nd ed.
I had never taken an A.I. class as an undergrad, and I always regretted it. I felt like I should at least be see what it's about, and I was always really interested in things like evolutionary algorithms, genetic algorithms, and other metaheuristics. This class was taught by a professor I hadn't yet had, so this was a real gamble for me.
This Fall, I took a course on Computational Complexity. I've been exposed to complexity in Computer Science before, but as an undergrad it rarely went beyond discussing P, NP, and NP-Complete. While I enjoyed the class a great deal, I was slightly disappointed that we mostly studied some of the space complexity classes like PSPACE as well as went much, much deeper in depth on P, NP, and NP-Complete, without covering many of the other complexity classes, of which there are lots.
For a final paper, we had to pick a topic of our own choosing in Complexity Theory and research it on our own. For my topic, I choose to explore a bunch of the other important classes in complexity theory. I had never had any exposure to any of these classes before, so I really enjoyed this project, though I was unable to cover as many classes as I'd have liked, and none of them in as much depth as I was hoping.
Nonetheless, I'm pretty happy with my paper, which provides an undergraduate-level explanation of 26 other complexity classes, based off The Complexity Zoo, kept by MIT professor Scott Aaronson. I tried to boil these classes down to the bare essentials and explain them with examples in plain english as much as I could. The goal of the paper is to expose those new to Complexity Theory or early in their Computer Science careers to a handful of interesting classes and explain how they relate to each other, the more common classes, and of course the $$P =? NP$$ question.
You can download the paper here.
In December, I posted about my early thoughts on Scala after using it for a short time. Initially, I thought that using Scala didn't buy very much - the functional style could be adopted in in Java, and the syntax and libraries could be ugly.
Since that time, I've been using Scala almost exclusively, and I wish to revise my view: Scala is awesome.
While some of my initial thoughts still stand, particularly that Scala APIs often overuse operator overloading, much of my perception has shifted otherwise. Scala not only allows, but encourages solid functional programming principles that are difficult or impossible in Java.
Comfort and Training
A great deal of my perception shift has been due to familiarity and training. I realize that a lot of my earlier issues with Scala were due to my own lack of comfort with the language, and over the last year I've done a great deal to level up my Scala skills significantly, like:
I recently read a book called The Career Programmer by Christopher Duncan. I typically don't post book reviews unless I really love a book and want to spread the word, but in this case I felt compelled to post in order to spread the warning. I can't remember a book I've hated more.
"The Career Programmer" is meant to be a dispensation of wisdom from a sage, a book that gives younger programmers keen insights from someone who has been in the industry for a long, long time. I tend to really enjoy books like this, so I picked up a copy. Unfortunately, it comes across as an anachronism, like the book time-traveled out of the mid-90's. While reading it, I felt compelled to double-check the publication year, and was absolutely astonished that it was printed in 2006. The "wisdom" of the book is so hopelessly out of date with the current state of software development that I cannot recommend it to absolutely anyone.
Duncan's view of software development is straight out of Dilbert. Managers are idiots that hold all the power, programmers are just lackeys that do what they are told. In his world, "shit rolls downhill" and programmers are at the bottom of the hill. Duncan has over a decade of experience in the industry, which is the basis for his advice. Well, I also have a decade of experience and I have never, ever worked in a place as dysfunctional as what he describes as typical. Perhaps I am extremely lucky or just extremely talented, but I doubt either of those are true. If I found myself at a company like those Duncan describes, I'd leave immediately and get a new job, I certainly wouldn't build a 10-year career stringing those experiences together.
As an example of what I'm talking about, Duncan describes that programmers are expected to "do whatever it takes" to get the job done, which means:
There are a lot of things that annoy me in my industry: lack of commitment to writing quality code, no discipline regarding tests, and many, many more. These things irritate me, and I see them all the time, but there is one irritation I encounter that is so common that it dwarfs all others, at least in frequency.
How common is it? It's so common that this post has been in my Drafts for about five years. What I mean is, I wrote it in reaction to someone irritating me at work, but decided not to post it because I was worried they would see it and know I was talking about them. And it's been in Drafts since that day because I encounter it so often that any day I post it, it will be seen as a response to something that actually happened at work. There hasn't been a break in the last five years where I could post it without at least one person thinking it was a reference to them. That's how common it is.
In fact, I know posting even now, it's going to look like it's related to an occurrence this week. STFU co-workers, I wrote this shit ages ago. Except this paragraph, which I wrote just now.
Anyway, what I'm talking about is developers refusing to do things or complaining about doing things because they distract them from what they call "Real Work."