Category / Company

Grant Skinner

The "g" in gskinner. Also the "skinner".

@gskinner

by Grant Skinner

Check. Check. Is this thing on?

It’s been nearly a full year since I last blogged. (Do people still blog? Maybe I should snapchat this instead?) I used to blog a lot, but life became busier, posts became more infrequent, and eventually it stopped being a habit and became a chore.

That doesn’t mean I don’t have a lot to say. It’s just that the last few years have been a crazy and exciting ride, and I haven’t had a lot of time to dedicate to writing posts.

Five years ago, Flash as a platform died. For a lot of shops, the migration was gradual. Not for us. Our clients come to us for cutting-edge tech, and almost overnight, Flash didn’t meet their criteria. We went from almost 100% Flash work, to nearly 0% in less than a year.
Continue reading →

by Sebastian De Rossi

New versions of CreateJS released!

Wow. What a difference of couple of years makes. Most of you have noticed a shift in the industry over the last two years towards HTML5 — instead of running away from this change, we’ve embraced it. Our response was CreateJS: a collection of Javascript libraries that allow us to create the same high quality experience and quick turnaround that we are known for.

Not only has the framework been a major part of our development, but some great tools have been created to improve user workflow, such as ToolKit for CreateJS and Zoë.

We are happy to announce new versions of the CreateJS Libraries, available now on the CreateJS CDN and GitHub.

This update includes a new common event model, vastly improved documentation, and a ton of new features and fixes for each library. For specific information on the changes, please review the VERSIONS.txt file in the relative GitHub repositories.

We have also introduced a minified CreateJS library to the CDN, containing all the latest libraries in one handy file.

With this release, we are happy to announce the launch of the CreateJS blog, which will provide a centralized location for announcements and articles about the libraries. Read more about the update to the CreateJS libraries here.

Thank you all for testing, feedback, contributions, and bug reports…keep them coming!

by Grant Skinner

Open Source Licenses, JS, and Minification

I’m definitely not a lawyer and I detest reading legalese, but I have a strong interest in the legal considerations of the technology I work with. One area I’ve done a lot of research into in the past is the implications of different open source licenses, which led to this older blog post comparing common licenses.

Recently, one of my devs asked how this applied to JS and minification. Here’s the quick response I tossed together:

—

Let’s assume we are looking at the MIT license or an equivalent. Remember that ANY third party code requires client approval, and any license other than MIT should be run past me as well.

The MIT license specifically requires that the license is included somewhere in the software, but it does not need to be public facing. Typically, the license is included as a comment at the top of the source files. However, minification strips out the comments and combines source code into a single file. This raises three possible scenarios:


  1. All of the code in the file is under MIT license. In this case, you can inject the copyright statements for each of the libraries followed by the main body of the MIT license above the minified code. We do this automatically for the CreateJS libraries as part of our build process.

  2. Client code & MIT licensed code. I would recommend that all open source code is treated as in #1, and client code is minified into its own file (potentially with a copyright header specified by the client). This is much cleaner than trying to mix them.

  3. Code with different licenses. This gets much more complex, and should be dealt with on a case by case basis.
—

I’d be interested to hear about how other companies are dealing with this topic, or related ones.

by O'Jay Robinson

The Great Pumpkin Showdown 2012

Welcome to our most hotly contested pumpkin showdown ever! This year, exciting new teams formed to reshape ordinary pumpkins into masterpieces. Please vote to help decide which pumpkin wins, and which get burned.

For something new this year, the app was crafted for HTML5 using CreateJS. We also continued something old, with the app being built by the newest member of the team, O’Jay.

Continue reading →

by Lanny McNie

Great Pumpkin Showdown 2011 Results

I am proud to announce the winner of this year’s pumpkin contest!

“Kill All Pumpkins”, Ryan and Lanny’s homage to Futurama brings home the gold, narrowly edging out Grant and Wes’ “2001, a Squash Odyssey”, and “The Angry Pumpkin” by Sebastian and Chris, which kept up until the last few days of the race. There were some great entries this year, and I think it was one of the best contests yet.

Thanks to everyone that voted!

by Grant Skinner

Creating Great Developers: Shadowing

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, “Planning“, and “Production“.

Once the new hire has successfully delivered their internal project, they are ready to move to the next phase of training: project shadowing.

We pair the new hire up with one of our senior developers, and have them work on the same project and tasks in parallel. At the start of each week, the senior developer will sit down with the new hire to outline the goals for the week, help prepare micro-deadlines (ie. production targets for each day), and provide some guidance on architecture and approach.

Throughout the week, the new hire works towards the assigned goals, and is free to ask their mentor for help or advice in an appropriate, organized manner. We schedule time for the senior developer to account for this, so that it does not create a burden on them.

At the end of the week, the trainee is provided with the mentor’s source code and given some time to compare it to their own efforts. They then sit down with their mentor to review their code quality, communication, and productivity. This also gives the trainee an opportunity to ask additional questions that arose during development or (more critically) while they were comparing their efforts to the senior developer’s work.

Besides being another great learning opportunity, it also provides the trainee and the senior staff with applied benchmarks as to how they are performing on a real project, without the risk associated with actually placing them on a client project. An important factor is that shadowing is treated as a serious project by both the trainee and the team, with a project manager, deadlines, and testing / quality control.

We repeat this process for 3-5 weeks, depending on the trainee’s performance. Most weeks we will switch mentors, so that the trainee is exposed to a variety of working / coding styles.

At the conclusion of shadowing, the trainee has been with us for between eight to twelve weeks, and is ready for their three month review, which will is the subject of the next article, available here.

by Grant Skinner

Creating Great Developers: Production

After an extended hiatus, for which I apologize, I’m finally going to wrap up this series with the last 3 entries: Production, Shadowing, and Conclusion.

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, and “Planning“.

With their plan in hand, the trainee now has 3-4 weeks to develop their internal project. They are assigned a project manager, and expected to treat this project as though it were real client work. This includes checking in regularly to version control, tracking their time, adhering to deadlines, and effective communication of issues to their manager.

They are provided full access to the team in order to ask questions or seek feedback, but are briefed on strategies to leverage this resource effectively without distracting others.

Every week (on beer Fridays) the new hire presents an update of their progress to the entire team. They walk everyone through their code, and ask for input on things they are having difficulties with. This provides the entire team with an opportunity to interact with them, get a sense for their strengths, and provide input on their code quality or approaches. It also gives the trainee experience with managing client feedback and change requests mid-production.

This weekly review is supplemented by ongoing reviews from a senior mentor who will check in every day or two to ensure the project is progressing well, validate their approaches, and do a quick review of their code.

By the end of production, they will ideally have completed coding their project, documented it with ASDocs, fully tested it, and debugged it. The final project is staged, and the trainee presents a full project debriefing which includes an analysis of what went well, what went poorly, and what they would change if they started again.

The senior staff then reviews their progress according to a variety of criteria, including:


  • Adherence to timeline and micro-deadlines or ability to notify management appropriately of non-adherence. Estimating time is hard when you’re new to it, so we expect a lot of inaccuracy. The important thing is that they communicate that back to their project manager in a timely manner.
  • Communication. Did they effectively communicate changes and issues to their manager. Did they utilize the support of the team in an appropriate and non-invasive manner? Did they accept, understand, and implement feedback well? How well written were their docs?
  • Introspection. How well did they judge their own abilities. Were they able to identify weaknesses and work to address them? Do they show an improved understanding of time estimation based on their own productivity? In brief, do they demonstrate an ability to analyze their own performance and work to improve it?
  • Tool use. How well did they use tools like SVN, time tracking, Basecamp, and their developer tools?
  • Code. Adherence to company standards, architecture, appropriate commenting, documentation, use of appropriate frameworks / libraries / patterns.
  • User experience: Did they attempt to create a usable, aesthetically appropriate interface? Do they demonstrate an understanding of UX core concepts and underpinnings.
  • Productivity. How productive were they in the time they had, accounting for things like necessary rewrites, and accommodating feedback?

Based on this review, we may ask them to spend another week or two cleaning things up or extending the project, or we may proceed into the next phase, project shadowing.

This internal project development gives the new hire a great opportunity to learn and apply new technical concepts while gaining an understanding of our processes and all the elements that go into delivering a successful project. It also gives our senior team to evaluate the new hire in a near real-world situation, without any real-world risk.

The next article, on project shadowing, is available here.