This is our big GeekAustin bash of the year, and because I honestly love you, there is no cover. The event is free.
To help amp up the celebration, we have invited our friends at Refresh Austin and the Austin Electronic Music Grid to co-host. RefreshAustin represents some of the sharpest web and design pros in town, and the Grid represents some of the most interesting electronic music artists in town. I am pretty excited about getting them together in the same room. The Geeks meet the Grid.
The event begins at 6PM with drinks and conversation downstairs. At 7PM, Dubnautica performs in the Boom Boom Room Refresh Lounge. Beginning at 8PM, there will be performances by Austin Electronic Music Grid artists including: Gobi, Carbon Theory, Happy Panjoma, and Rage Ranger.
Union Park is a big club. We’ll have some rooms set up for performance, and some rooms set up for conversation. Union Park also has an excellent menu, so there is no need to head home before the party.
GeekAustin 8th Anniversary Party
Tuesday, September 30, 6PM - 11PM
Union Park, 612 W Sixth St (Next to Katz’s)
Please RSVP at Facebook
(this helps us determine how many bartenders have on hand)
Hope to see you there! - Lynn
 |
Intro: Every company in the tech space that I’ve worked for has had a QA dept. However, it wasn’t until I worked with Troy Waldrep at Pervasive that I heard about code review. The next time I heard about it was from Jason Cohen (blog), founder of Smart Bear Software, whose company offers a tool called Code Collaborator. Recently, I’ve been increasingly interested in software quality and process. So, I decided to ask Jason to talk to me about code review, and its role in the software lifecycle. |
Lynn Bender: I recently asked a head developer at a software company if his team had a formal code review process. He immediately got defensive and replied: “yes”. When I asked him to elaborate, he began to explain their QA process. So to begin, what is code review?
Jason Cohen: Everyone’s had to write a page of prose for school or work. Have you ever done it without making any mistakes? I’m not just talking typos — what about points that could have been clearer, paragraphs that didn’t make sense, missing segues, etc..
Bender: As a matter of fact, I pretty much always pass my important business communications by a colleague to read before sending out. It’s amazing what I miss.
Cohen: Of course you can’t do it, which is why most everything in the publishing industry is reviewed by editors. It’s not because writers are careless or incompetent. It’s because with any sort of creative knowledge work we’re “too close” to our work to see the problems. It’s normal and unavoidable.
So if no one — not even top-notch professional writers — can write a page without needing an editor, why do we expect software developers to write code alone?
That’s all a code review is: reviewing someone’s work.
Note that, as in writing, often the errors are things the author would have seen had the author been reviewing someone else’s code. It’s the “you’re too close” problem most of the time, not the “you’re incompetent” problem.
Bender: This would seem to have a larger scope than that of QA — encompassing programming style and method.
Cohen: People often think of code review as a process to “find bugs.” Although this is an important result — the one management is perhaps most interested in — there’s many other purposes. Finding maintainability issues (e.g. documentation, organization, architecture) saves time for the next developer and prevents bugs in the future. Sharing knowledge about programming in general and about gotchas in the code base helps everyone write better code. Overseeing new hires means noobs can get their hands in the code as fast as possible while ensuring they don’t break anything.
Bender: Can you tell me a bit about what the code review process looks like, and how does it fit into the overall dev process?
Cohen: There are many types of code review, all of which are useful and have trade offs. At one extreme you have the over-the-shoulder walk-through, performed whenever the author is uncomfortable about their work. On the other extreme is the Formal Inspection where participants must be trained, a seven-phase process requires four separate meetings, and reviews take two man-days to complete.
Typically the less formal processes have a better chance of succeeding, unless you’re a CMMI-Level-5 DoD contractor or some such and your employees don’t mind (or are used to) paper-pushing.
Code review comes after the code is written but before QA. Some like doing code reviews before code is even checked into version control, so “checked-in” also means “reviewed.” Others say that causes too much developer down-time waiting for the review and therefore prefer reviewing just after check-in. There’s no right answer to that one.
Bender: Is there much difference in how one would implement code review for an agile team?
Cohen: No. I don’t think e.g. Scrum means you don’t need to design, architect, review code, or do QA, it just means you need to do it in a compressed time-frame.
The exception might be pair-programming, which you could argue is an in-depth, continuous code review situation. In fact, I sometime argue that other code review techniques get you some (not all!) of the benefit of pair-programming at a small fraction of the time, and is therefore a better time/result trade-off for people who don’t want to go all the way.
Bender: Where is the optimal place for code review in the life cycle of a project?
Cohen: Clearly at the end of the lifecycle, during “feature freeze,” code review makes a lot of sense. By definition you’re trying to be extra careful about every check-in. In fact, in past companies we used to self-impose code review during those times.
However it’s just as useful earlier in the cycle. If you only review at the end, mistakes made long ago might be too embedded for change. Sort of the same problem as waterfall development!
If you’re religious with unit tests and constant refactoring, then it may not make sense to code review early on because it’s so safe to change later. In practice, few development groups are zealous enough for later major restructuring to truly be safe and fast.
Bender: With so many startups in Austin, we’ve had the opportunity to watch many software shops go from one or two people to a group of ten or twenty developers. At some point, most of these groups implement a bug tracking process, and half will have a formal QA process. However, I am surprised how few actually implement code review as part of the dev process. Has this been your experience as well? When is the right stage to begin a code review process? And for companies that already have a few hundred thousand lines of code, where do they begin?
Cohen: You’re right that code reviews are often the last quality process to be introduced, perhaps because it’s so social.
If a team is not already doing code reviews, I would strongly suggest reviewing only a little bit of the code. For example, have optional reviews, done just when the author is unsure, or just on a stable code branch, or just on the 10 files voted “scariest to change.” Stuff that everyone would agree is worth some extra effort. Going from zero review to reviewing everything is too much of a change to do at once.
If you have a large code-base, you could pick out files you know are trouble and review them first. Or, just do incremental reviews — reviewing each check-in — and find the problems as you go. If you do this you’ll naturally notice problems around the code being changed — even in code that wasn’t relevant to that check-in — and you can fix it then.
Bender: Your company, Smart Bear, is widely known for it’s code review tool called Code Collaborator. Can you tell me a bit how it facilitates the code review process?
Cohen: The most important part of the review — human beings thinking critically about code — is something no tool can help with! However there’s also lots of mundane aspects of code review where a tool can help, and that’s what Code Collaborator tries to do.
First, Code Collaborator integrates with version control so with a single click you can do things like “create a review with all the files I’ve modified but not yet checked in.” It can grab the files along with the content as it appears in version control and make diffs.
Second, Code Collaborator displays diffs together with chat in a web browser. The chat is live (or works like a newsgroup if you’re separated by lots of timezones), and is threaded by the line of code. This saves you from tedious notes like “on line 723 of //depot/project/foo/bar…” and emails with quote-carets all over the place as you try to make sense of everyone talking.
Third, Code Collaborator automatically collects metrics like time spent in review, number of lines of code, and number of defects found, so managers get the reports, audit trails, and numbers they need while developers don’t have to lift a finger. No forms, no stopwatches, no meetings, no rubrics.
Bender: I sometimes get this comment from developer friends: Because the dev environment in most startups tends to be fast paced, implementing processes like code review are often viewed as a “frill”. How would a developer best make a case for implementing code review?
Cohen: If you’re in an early stage of development, you might not be able to make the case! Early on, just getting something out the door is more important than bugs.
At some point though, your company turns the corner and keeping customers happy and having a solid platform becomes more important than the number of features you can spit out per quarter. It’s at this time — when you start talking about static code analysis, QA departments, integration tests, etc — when code review should be part of the discussion.
I think the best argument is a combination of common sense and measurement. The common sense part is the author/editor argument I gave earlier. It just doesn’t make sense that anyone could write perfect code in a vacuum, and it’s just as obvious that another pair of eyes could help. Just as spell-checkers are useful but not a substitute for a personal review, static code analysis is useful but not sufficient.
The other side is measurement. Code review is something you can prove has value! Just measure the number and type of defect you’re finding and the amount of time you’re spending in review. Then just divide and see if it’s worth it! The usual number is that you find AND FIX a defect every 10-15 minutes. So ask yourself, can you do that with QA? Shouldn’t you at least try to do it with review?
Bender: That’s a strong case. Jason, thanks for taking the time.
You can read more of Jason Cohen’s writing on software at his blog: A Smart Bear.
 |
I just found out from Darren Peterson about the first meetup of Joomla users in Austin. I’ve been hearing about Joomla quite a bit recently — mostly as an alternative to Drupal. I decided to contact Darren and get the details on the meeting as well as a status on Joomla. |
Lynn Bender: Have you been using Joomla long?
Darren Peterson: Not long at all. I stumbled on Joomla about three years ago when a client asked me to customize his Mambo site. I wasn’t familiar with what Mambo was, so I started researching it and found that Joomla had essentially taken its place in the open source CMS world.
Bender: For a local person building a Drupal-based site, there seem to be a lot of local developers with experience in Drupal. What about Joomla?
Peterson: Austin has a great base of talented Joomla developers. There are more Joomla users than there are developers and I’ve found that most Joomla developers are also Drupal savvy. Over the past few years, I’ve attended several Joomla conferences in different cities around the US and have met hundreds of developers and I’d have to say that Austin and Central Texas have some of the best.
Bender:What are some of the local austin websites that are currently using Joomla? What about nationally-known high profile sites?
Peterson: There are so many, its hard to distringuish a Joomla site from other types of sites. You can’t tell just by looking because it is possible to customize every aspect of the framework. Three years ago I developed Twin Liquors (www.twinliquors.com) on Joomla, as well as many other local business sites. On a national level Joomla.org has listed that the United Nations (http://www.unric.org) , MTV Networks Quizilla (www.quizilla.com) , L.A. Weekly (www.laweekly.com) , Harvard University (gsas.harvard.edu) sites have all been developed on Joomla.
Bender:Can you tell me a bit about the licensing model? How does it stack up against other CMS software — like Plone or Drupal?
Peterson: Joomla, Drupal, and Plone are free, open, and available to anyone under the GPL license. I am not has familiar with Plone’s licensing, but Joomla and Drupal both permit users to customize, and contribute code as well as resell the software as long as you allow the purchaser to to modify and redistribute it as well.
Bender:I’ve heard that, unlike with Drupal, most of the modules are are not free. What’s the scoop on this?
Peterson: Some of the modules have commercial licenses attached to them. Some users don’t like this, but I think it’s a great thing. You get a better product, and better support when you pay for an extension. There are many developers who will never charge for their work, and I applaud them, but there are many extensions Joomla would never have if it weren’t for the development teams working hard day and night.
Bender:SEO functionality seems to be lagging behind Drupal. Are there any solutions in the works?
Peterson: The latest version of Joomla has many great SEO features. From SEF urls, individual article meta tags and titles, to turbo charged SEO extensions, the Joomla team has delivered a CMS that drives traffic.
Bender:For someone implementing a new CMS system or collaborative website, what do you consider the main advantages to Joomla?
Peterson: Ease of use, the Joomla community, the customization options, and oh yeah, the local Joomla Austin user’s group (www.joomlaaustin.org) who has their first meeting this Wednesday (http://webdesign.meetup.com/528/) .
 |
Managing social networks is a total pain. Fortunately for wannabe 2.0 rockstars everywhere, CEO Dewey Gaedcke and his team started Minggl, a tool for managing multiple social networks. I caught up with him downtown to ask him a few questions about it. |
Michelle Greer: Social networks are never static. We’ve all come to love or hate the new Facebook, and people adopt new Twitter clients seemingly monthly to keep up. Every week, some naive VC funds a social network of some stripe hoping it will actually get adopted. How does Minggl plan to keep up with the constantly evolving trends in the social networking sphere?
Dewey Gaedcke: Great question and this is Minggl’s sweet spot—-we believe that people want to participate in many communities and will frequently move between them. We’re not a site, or a tool, or a community—we’ve built a “relationship layer” that is embeded in the browser so we can facilitate all the social things you do, transparently between communities. You get to “do social” based on how you know someone and how much you care, instead of ‘where’ they hang-out, or which tools they use. If you think about it, “social” is relationship centric, not tool or venue centric, so the only sensible thing to do is to carry the relationship model with you, in the same way your brain does it. The only point of personal connection between Facebook, LinkedIn, and MySpace (for you, from a technology perspective) is your browser, so we modify the browser to bring relational/productive benefits to you, everywhere you go on the web. From a technical perspective (if that’s what you are asking), Minggl is an API abstraction layer—this means we have ZERO site-specific code in the product…..Minggl support for Facebook (for example) is defined by a little XML file that Minggl knows how to interpret and run. If we want to add support for Plaxo, we just have to create this little text file and ww don’t change the core program at all. It’s very elegant ;-)
Greer: Minggl allows users to filter statuses from the people you follow based on keywords. What are some applications for this sort of functionality?
Gaedcke: Out of the 400 “friends” you have online, very solid research shows that you can only be truly “friends” with about 150 of them. Of that 150, only about 40 are meaningful (you really care) in your life. And of those 40, it’s likely that only a few publish information that aligns with your goals and interests. Do you have time to read the daily menu consumed by 250 distant strangers??? If you do, then use minggl without filters (in this mode, our mStream feature works just like the news aggregators) and read everything. If you don’t, then Minggl will show you information from the people you care about first and not waste your time with the rest….or at least save it for when you aren’t so busy.
Greer: Twitter seems to be the social network of choice for many prominent people in the social networking sphere. Any plans to expand the Twitter section of Minggl to include the “replies” and “archives” sections?
Gaedcke: We already support replies and retweets. Archive will be coming in the next few months. But micro-blogging is only a fractional part of the social dimension—-we believe that people care most about the person and about the message, not whether it goes over phone, email, sms or pony express. So you will see Minggl shifting the focus from “where you hang” and “what you use” (to communicate) and making it about who, what and why—-the real essence of social
Greer: What is your platform built in? Should we expect to see Minggl FailWhales?
Gaedcke: Minggl is built on a massively scalable architecture. The app server alone is written in three (Java) tiers, including a clustered cacheing layer. The DB layer is partitioned, load balanced, multi-master and replication aware. You may see Minggl hickup because someone pulled the wrong plug, or a bug slipped through QA, but it won’t be for scalability reasons….that I can guarantee.
Greer: What is it like working with the Twitter API?
Gaedcke: Twitter API is great….it’s clean, simple and works (when their infrastructure is up)
Greer: I hate managing social networks and like that Minggl integrates them into one sidebar. Do you need more developers so as to appease my need for easier and easier tools to manage social networks? If so, how should they get in touch with you?
Gaedcke: We will be hiring experienced Java and Javascript developers aggressively beginning in the middle of November. They can begin experimenting with our API to build social apps that deal with the ENTIRE friend list (instead of just a slice). Experienced techs can send their resume to jobs@minggl.com (best wait till mid-November). They should also play with the product, and get involved recommending features and reporting bugs at: http://getsatisfaction.com/minggl
Greer: Minggl allows you to tag people with certain keywords. Did I get a “cool” tag and if so, when the hell are we going wakeboarding?
Gaedcke: you received a “genius” tag and this means that minggl will randomly inject pictures of Einstein and Tila Tequila onto your various online identities.
To see how Minggl can save you some social networking headaches, download Minggl here. If you have some ideas for the product, get satisfaction by letting their team know here.
While selecting musical artists for the upcoming anniversary party, we noticed that many of the artists we were considering had something in common — they are members of the Austin Electronic Music Grid. So, rather than contact all the artists individually, I sent a note to Mary Abshier at the Grid, and asked if she would like to host a Grid showcase as part of the GeekAustin Anniversary Party. She said: Yes!
Tentatively, starting at 7PM, we’ll have laptop musicians performing in the BoomBoom Room Refresh Lounge. Then beginning at 8PM we’ll have Grid artists performing in the main room and on the roof — most likely until midnight. We are currently making arrangements with the artists, and hope to publish the acts and schedule within the next week.
I encourage you to check out the artists on the Grid. Some of my current favorites are Canartic, Carbon Theory, Dubnautica, My Dark Side, Death is not a Joyride. That’s only the beginning though. Check out the full list of Austin Electronic Music Grid Artists.
Remember, the GeekAustin Anniversary Party is free. Hope to see you there!
I’m happy to announce that Refresh Austin will be co-hosting the GeekAustin 8th Anniversary Party on September 30th. If you’re on Facebook, you can RSVP here.
When asked to give an example of Austin tech groups have done the most to empower both their members and the greater tech community, a few come to mind. Refresh Austin is one. (Agile Austin and Austin on Rails are the others). Although Refresh Austin is grows by leaps and bounds in membership, it continues to succeed as “an organization of Web professionals working together to foster new ideas and refresh the creative, technical and professional aspects of their trade”.
For those of you unfamiliar with the group, the Refresh Austin monthly meeting is tonight. These are a great group of folks, and if you are in any way involved with design, I encourage you to meet them — either at one of their monthly meetings, or at the GeekAustin Anniversary Party.
I’ve noticed quite a bit of small layoffs in Austin tech over the last month. In most cases, it appears to be members of web teams that are getting laid off. Are local companies cutting back on web initiatives? I haven’t heard similar news among system/network admins.
The first of the free SQL classes that GeekAustin is hosting is full. We will most likely be doing a second class. If you haven’t received a reply yet, look for one later this week. Daniel and I will be putting the curriculum and reading list online.
There are 450+ recruiters on the GA mailing list. How many of them also sell real estate for Keller Williams? Should I be inviting these folks to the GA party? Do you know Java?
-Linear
