Sebastian De Rossi

Sebastian De Rossi is a senior software developer working at gskinner. During this time, most of his efforts have been in developing web- and mobile-based applications. Serving as the Community Evangelist for CreateJS, he finds himself answering a ton of great questions from community members.

@derossi_s

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!

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.

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 →

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!

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.

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.

New site and blog design.

After nearly six years of letting it stagnate, we finally got around to redesigning our site and blog. It’s something I’ve wanted to do for a while (read: 5 years), but it always winds up at the end of the list after client work and all the other things we build internally.

I love redesigning our site, because it’s one of the few times I get to return to my (rusty) designer roots. I’ve probably done it 4-5 times over the past few years, but I never get around to actually cutting the design up and implementing it. After sitting on the most recent design for nearly a year, I caved in, and hired a friend of mine to cut it up, move everything to WordPress, and get it ready for deployment. He did a great job, and to be honest, I’d much rather be coding than cutting up comps.

The new home page is super simple. I wanted something that was going to provide the essential info, be easy to keep up to date, and remain extensible so we can improve it in the future. The blog has moved from MoveableType to WordPress, and we’ve dropped all of the Flash based navigation – it was kind of cool back in the days before AJAX, but it was time to dump it. In fact, the only Flash left on the page is the clouds at the top, and the grass at the bottom. This isn’t reflective of any move away from Flash, it just makes sense on a content driven site like this one.

As simple as the clouds and grass are, they were a bit of challenge to build. I really wanted some subtle motion on the screen, but I wasn’t willing to sacrifice more than about 10% of the user’s CPU (assuming a MBP 2.5ghz) for it.

This was easy for the clouds, I just render some long strips of stiched perlin noise with a gradient pre-composited when the SWF inits, and move them at different speeds over top of each other with a screen blend, looping them when they reach the end. Total CPU cost is about 2-3%.

The grass was a much bigger issue, since my previous experiments drawing about half as much vector grass used 60% of my CPU. Reducing the render quality, and using a low framerate helped, but it was still hitting nearly 40% CPU. I ultimately settled on rendering a small, sparse patch of vector grass to a BitmapData object. This image is then displayed in multiple Bitmap objects spread across the full area at different y positions. This massively reduced the cost to render the dynamically drawn vectors, and dropped CPU use to just over 6-7%.

Sometimes, even that 10% is too much. On pages with intense experimental pieces, I wanted to be able to completely shut off the header and footer. To accomplish this, I wrote a little AS3 library that registers a SWF with a companion JS library. I can then make a JS call in my page that instructs these SWFs to pause or unpause. You can toggle this setting by clicking this link.

Unlike the old site, which remained static after it was deployed, we’re planning to evolve and tweak this site as we have free time.

I’m sure we’ll be working out kinks for the next little while, so my apologies for any inconvenience. If you encounter any problems, please let us know in the comments below.