Back in Time with PHP

I recently had the opportunity to work on a PHP application that was written by a student in 2004. Before the time of PHP frameworks and separation of MVC, when applications had SQL and HTML in the same files. Each page was a form that submitted to itself. Everything contained in one file per page. Pretty crazy, right?

Crazy like awesome. I had so much fun working on features for this old application. It wasn’t just nostalgic, it was like comfort food. Easy and delicious. I’m not really sure how comfort food is “easy”, but just go with it. I was practically begging to do more work on it.

I can’t imagine myself creating a new application like this from scratch, but I’ve been thinking about the benefits. Anyone with just a tiny bit of PHP experience could pick it up and maintain it, there’s no technology ramp-up time. A project like this could be orphaned and passed around between anyone. It could be used to teach people basic PHP within the organization. Say, people who are so Java-centric they refuse to learn anything new or different.

It was a good opportunity to take a look at the past and see what we’ve lost by going forward with technology.

Deciding on a Style Guide

Recently a couple of groups here at work were brought together to try and standardize on a few things. The Software Development Community of Practice! Style guides came up. Everyone said they had no style guide and everyone agreed having a style guide would be worthwhile.

I had spent some time writing a style guide (customizing) so I was interested by this. I got to reflect on my style guide, how I’ve referred back to it in the year since I put it out there, and how I think it has helped or could help in this forum.

See the reason I created this style guide is not all that different from the reason these communities of practice are looking to create style guides. I was/am writing open source, and on the hope that someone will want to contribute to the project, I want a rule set defined so people won’t submit something unreadable.

For the community of practice, it’s a little different, but the spirit is the same. What they want is to have the option to point at something when a fellow developer is writing horrible code. The premise is you have a new developer and they don’t know how to write clean code.

The problem I have with this is everyone knows how to write clean code. And by everyone, I mean every professional software developer. If they’re not writing clean code, they’re not professional. Now that of course means if we are using student employees or taking in work from unknown outsiders (Open Source), that we are risking poorly written code being introduced and should therefore have a style guide. But if the premise is to have something for professional developers, I think it’s a waste of time.

Most style guides are 95% the same and we’re not talking about trying to enforce the 5% that is going to be different between individual developers. If ever a problem comes up with software developers where one is trying to say another’s code style is wrong, they should be able to say “google a style guide to see what best practices are” and be done with it.

Sadly, I’ve wasted more time arguing this than it would have taken to just agree, pick a guide that no one will ever use and move on.

Avoiding Page Reloads

My applications are part of a framework (LMS) that load a billion extra items on each page load.

To get around it I wanted to do that silly “twitter thing”. They’re the ones who get credited with it because for years normals were baffled by their url changing.
 http://www.adequatelygood.com/2011/2/Tho…

Additionally, if you’re interested in why the bang(!) is necessary, it’s not. It’s just to tell google to index the page. Otherwise they assume it’s just an anchor link.
 https://developers.google.com/webmasters…

So I spent the last few hours changing all links in one of my current applications to do a “hashbang” sort of call instead of loading new pages. This significantly increased speed when using our clunky LMS.

This was especially annoying because our LMS forces changes with <a> tags.

What made this especially easy to implement was that I had already made all links go through a smarty plugin so altering all links in the application was just in one file and I could make those links specific to whatever authentication scheme / LMS the application is living in. So I just had to alter that plugin and the LMS specific layout and bam. The only thing that’s not covering is form submissions. But there are only a couple of those, so I’m not going to stress about that.

In continuing research obviously I had to investigate why twitter moved away from hashbangs.
 http://engineering.twitter.com/2012/05/i…

The highlight of that being that with hashbangs, you have to go to the client and then back out, which reduces speed on the initial pageload. So twitter went a little fancier 6 months ago and used the history api’s PushState.

Implementing the hashbang urls was a very small amount of code, so I’m going to move forward with that for now, maybe next time I get a chance to do some research I’ll focus on converting that to PushStates.

Workspaces

Yesterday the New York Times posted an interesting article about research in the field of inactivity studies and the trend of workplaces transitioning to upright workspaces (standing desks), particularly at top tech companies. There has been a steady stream of articles and blog entries about the topic over the last few years. Is it just a fad? What are the implications for productivity and learning (if any)?

Posted in Uncategorized. 1 Comment »

Harmony Lab

One of the nice things about my job is being able to take credit for interesting student projects. We’ve got an awesome pool of kids that are always doing stuff. They have cool ideas, write up a sloppy implementation and don’t want to maintain it. So it comes to us and we have the opportunity to polish it and expand it for use to a broader audience.

The most recent of these projects to come along is the newly named “Harmony Lab”. (Formerly GoFigure / Piano Lab) This is a nice application that allows you to hook up a midi keyboard to your computer and get information about music theory stuffs (and by “music theory stuffs” I mean I haven’t yet wrapped my head around everything the application does).

Currently it is an application that uses an applet to get the midi data from the keyboard and a ton of javascript for visualizing the key/chord. And a ton of javascript is never a pretty thing.

We are giving it a backend for some authentication, cleaning up the javascript where we can, and adding some extra functionality — hopefully not too much extra. This is a cool project, but it’s usefulness is limited to one or two classes.

What’s cool about this is it’s a (potentially) simple application so it lets us play with (learn) something new (to us). So we went for python Django.

It’s available on github from the start.

The Code Monkey – Devaluing Software Developers

Code Monkey

Note: Opinion. This is something I’ve noticed/perceived in all positions I’ve held.

Of course no one is paid enough money. Boo hoo, we all want more money. Although that is a nicely objective way to value employees, that’s not what this is about.

This is about how software developers are perceived by (most) management. If a manager has a software developer and a project manager under them and they get conflicting reports/opinions from the two people, they will always go with the project manager. Management typically looks at a developer as an overly technical person, unable to understand client and business needs. So when a developer goes for a management position, they are shot down because they are “too technical”. (When someone gets turned down for a position in an IT organization because they are too technical, something is clearly wrong.) The perception of management is clear. PMs get the attention and typically the praise. PM ideas are seen as coming from a position that’s higher level because a developer works in the nitty gritty and doesn’t think in terms of high level.

A software developer ideally understands the client and business needs just as well as the PM. Given that’s an ideal, but that’s what makes a good developer good. Often the reason a project turns out bad is the developer wasn’t made aware of why they’re doing what they’re doing. (Sometimes that’s because it hasn’t been thought about on a high level — no one really knows why.)

The truth of it is software developers come in good and bad the same as project managers. Some are really good and some are totally not. The problem is most management don’t bother to get to know their employees, so they don’t know who is good and who is bad so they make generalizations based on role. That’s bad.

Of course you can now say I’m making a generalization about management in the same way. And you’re right.

Posted in Development. No Comments »

More MOOCs in the News

Massive Open Online Classrooms (MOOCs) made headlines in the New York Times again. Harvard University’s own venture into MOOC-space, edX, is mentioned, along with the usual suspects, Coursesara and Udacity.

A couple highlights from the article:

  • The challenges inherit in widening a traditional classroom to a global audience are breathing new life into the art of teaching and learning. Professors are finding that they need to reshape and rethink their instructional approach when teaching tens of thousands of virtual students.
  • These challenges will be overcome with the help of the students themselves. For example, the crowd-sourcing of moderating discussion forums and of grading via peer-to-peer evaluation is becoming critical to running a MOOC.
  • Peer-to-peer evaluation of assignments, such as essays, is permitting the MOOC to go beyond computer science and engineering, which were suited to automated, computer grading. Humanities courses are starting to jump aboard.
  • There is, of course, still much to learn, especially about how well students learn in a MOOC. MOOC-space is young, wild, and untamed.
Posted in MOOCs. Tags: , , , . No Comments »

Gamification in Software Development


Gamification has been on my mind a lot lately.

I was just doing some of my sprint planning and found myself filling out borderline excessive github issues for my project. I put all of the issues for the current sprint into aptly named milestones. So as I finish the issues in the milestone, the milestone progress bar gets filled up. I recently realized I enjoy doing this because it’s very game-like.

I’ve turned work into a game and I think it has increased productivity and general happiness with employment. Maybe that sounds lame, but it seems true in my case, I would recommend it for most people who are finding their current work stale and are looking for some self motivation.

Badgered about badges: Will higher ed be shook up by alternative credentials?

Harvard badgesOne of the big buzzwords circulating through the halls of academia has been “gamification,” the concept of introducing game-like elements into the higher ed environment. The NMC Horizon Report of both 2011 and 2012 indicated that game-based learning is a growing trend in the classroom, and just within the past month, articles in the New York Times and The Chronicle of Higher Education highlight an element of gamification that may very well disrupt the entire paradigm of attending a school to earn a degree. This new element is the digital “badge,” a possible foundation for what might be called the “alternative credentialing” movement.

This movement is serious business.  The Mozilla Foundation has established the Open Badges project, which, with support from the MacArthur Foundation, is defining the Open Badge Infrastructure, a technology suite that can be used to build an ecosystem of badges.  The Digital Media and Learning Competition, sponsored by the MacArthur Foundation and the Bill and Melinda Gates Foundation, awarded several grants to institutions such as Disney-Pixar and NASA to explore the concept of badges in life-long learning. Prominent Universities, including Duke, Purdue, and Carnegie-Mellon, are also experimenting with badges. And badges will probably play a significant role in the credentialing process of the now ubiquitous MOOCs.

The question remains, of course, as to whether badges will ever be considered as valuable as a regular degree. The jury is out on that one, and probably will continue to deliberate on this issue for years, if not decades, to come. But should the time come when a collection of badges on your resume is equivalent to a degree from a major University, prepare to witness a revolution in higher education.

Agile Documentation and Research Stories

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.