Previous Posts in this Series How to Host a CodeFest/Hackathon, Part 1: Why Have a Hackathon? Answering Questions in Advance So last time I hopefully convinced you that you should at least consider having an internal company hackathon, or as we call it here at Aviture, a Codefest. But before we really get started, you have to flesh out enough of the details that you can get yourself excited, and so you can actually communicate the idea to everyone else! And believe me, they’re going to have a lot of questions. Here’s a couple big questions to ask yourself that should help you get the structure of the event settled:
From left: Kathy Andersen, Taylor Byrd, Asia Tyler, Jeremy Glasser
Subscribe to our blog by filling out the form below:
How do already great developers become even better developers? They spend time learning with other talented developers, of course! And there’s no better place to soak up the latest industry tools, trends, and techniques than at the Kansas City Developer Conference (KCDC).
What was your favorite subject in school? If you answered “recess,” we’re right there with you. It’s true that playing games with friends is the highlight of most kids’ days, but the fun doesn’t have to be contained to recess. There’s a lot to learn as technology continues to change the business world and we want the next generation to be prepared. All of this is why educators and national leaders are focused on keeping subjects engaging, relevant, and fun with STEM curriculum. So, what is STEM?
Agitating for Innovation A little over a year ago, I sat down with Mark Griffis and Jerry Koske (Aviture’s President and CTO, respectively) to make my case that Aviture should have an internal hackathon. I had a Powerpoint presentation all ready to go, a head full of ideas about how awesome it was going to be, and some pretty high hopes for the end results. I came out of the meeting feeling luckier than ever. Mark and Jerry are just as nuts about innovation and exploration of ideas as I am, and I got the go-ahead to put the event together.
From the trenches, Our experiences with Style Guide Driven Development Style Guide Driven Development (SGDD) is a technique of developing your UI components in a living “Style Guide.” There is no one set definition but the basic idea is that you develop a separate page or pages outside your application that use the same CSS and HTML that your application uses. There is an excellent introduction to SGDD and its benefits at Smashing Magazine and we encourage you to check it out! This post will be about our experiences working with this technique, which suggest that on a green-field project, it is extremely difficult to know enough about your application to fully embrace SGDD out of the gate. We found that waiting for the UI patterns to emerge from your application and then creating a style guide was a better approach. Key to this recommendation is to develop and build all your UI components (style guide or not) with discipline, using known best practices.
Introduction This post is about my project’s experience implementing Acceptance Test Driven Development of our web applications, the process around automating our Given, When, Then (GWT) specifications, the path we took, problems that surfaced, and how we dealt with those problems. The motivation for automated testing was a corporate mandate. Most of the company’s previous applications were services APIs and I expect the main goal was to gain a higher level of confidence with those APIs.