This was a very large amount of work, and we learned a number of interesting things along the way that should be useful to you in writing your own tests.
We think it’s a real shame that there are developers that have to go it alone because they are in remote locations or can’t travel to one of our many in-person workshops. So we spent countless hours and many sleepless nights creating a way to ensure that no developer misses out on the opportunity to learn best practices building web apps with the Dojo Toolkit!
We’re very excited to announced that we are now offering…
Online, public workshops!
We will be using our very cool, Dojo-based workshop tool to deliver four hours of workshops each day, where you can expect to learn the essentials of using Dojo core, Dijit, and dgrid while watching expert developers live code all the while having the chance to try it yourself and ask questions, real time!
Are you In?
Register now! Demand for this workshop will dictate how soon we’ll hold the next one!
If you have any questions, ask in the comments or contact us.
In October, 2014, I was
A topic that’s been on my mind lately is how to choose a robust architecture that’s right for your application. The point of the talk was to encourage people to challenge assumptions and not just choose whatever is popular or whatever they know best. I’m sure some attendees in the audience just wanted to be told which framework to use, but the point was to make people really challenge themselves, and find solutions that work now, but are flexible enough to change later.
The talk is now available online:
At many conferences, the hallway track is more interesting than the track during presentations. It’s the serendipity of a small group of people interested in solving a similar problem that run into each other and just start talking through it that makes the hallway track the most interactive experience at most conferences.
EdgeConf capitalizes on these discussions by turning the hallway track into what the conference is all about! There are a selected set of topics covering emerging trends in web technologies and a panel of 5-6 people take the stage with one stepping forward to bring the audience quickly up to speed. The discussion begins!
The panelists work through a set of curated questions and there’s a system for the audience to participate and join the debate. Everyone is encouraged to spend less than a minute at a time talking, ideally 30 seconds or less. If the speaker goes over 2 minutes, there’s a nice warning across the screen on stage that tells the speaker that their time’s up. Oh, and the whole thing was streamed live! You can watch all 10 hours of coverage or read the gist below!
Last month, we conducted a live webcast to provide an Introduction to Intern, SitePen’s open source testing framework.
Our webcast covered:
- An overview of Intern’s numerous functional and unit testing features and capabilities
- Mocking objects and data
- Injecting dependencies
- Future direction of Intern
While it’s too late to attend this webcast and heckle us with live questions, we recorded the session and have made it available for you online:
The evolution of the Dojo Toolkit from namespaces to AMD packages has resulted in many changes over the years. In Dojo 1.x, we strive to maintain forwards-compatibility, while introducing new features and best practices in parallel. Mixing modern best practices and legacy code can lead to unexpected behavior.
One issue we see fairly often is setting
async: true in the
data-dojo-config property of Dojo’s script tag. This configuration setting tells Dojo to load resources as AMD modules using its asynchronous module loader. Many users choose this, but then rely on legacy package names such as dojo and dijit when migrating their old code. Unfortunately, this leads to failures when you try to use
dojo.* statements within your application. This is a simple issue to identify and correct.
AMD offers many benefits over the legacy Dojo module syntax. While Dojo is forwards-compatible, to take advantage of the benefits of AMD, developers are often faced with the challenge of migrating and refactoring large quantities of boilerplate code from the legacy
dojo.provide/dojo.require syntax to AMD’s
require. As we make the upgrade to AMD in our projects, we also usually want to leverage the latest version of our evolving APIs. With early work beginning on Dojo 2.0, we definitely need to work together as a community to automate as much of the upgrade process as possible.
Introducing the dojo-amd-converter
We have created an alpha quality release of dojo-amd-converter, a tool for helping you make a one-time migration of your existing source code to a newer version of Dojo.
Be warned, the tool handles only 70-80% of the manual conversion process, and generally does better with more standard usage of Dojo. Normally we wait a bit longer before announcing our projects, but this should be useful in its early alpha state. We know this tool has quite a few open issues that need to be fixed and we invite you to help us improve it.
Our hope is that this conversion tool, which is today useful for converting pre-AMD code to AMD code, could also form the basis for a community effort to make it possible to migrate code bases more efficiently from Dojo 1.x (pre-AMD or AMD) to Dojo 2.x. That work has not yet started, since Dojo 2.0 is not yet an actual thing.
As part of our great updates to the Dojo Tutorials for Dojo 1.8, we’ve been busy creating several new tutorials.
Feature Detection and Device Optimized Builds
Dojo 1.7+ now uses the popular
Check out the Feature Detection and Device Optimized Builds tutorial for Dojo 1.8 and 1.7!
Want to see a specific Tutorial? Want to Learn More?
Is there something you’d like to learn how to do with Dojo? Always wanted to know how something in Dojo works? Leave us a message in the blog comments and we’ll see about getting a tutorial created for you. Or sign-up for an upcoming SitePen Dojo Workshop to get a fully immersive hands-on experience with Dojo.