Deadlines are looming and it looks like it’s is going to come down to the wire. A developer has hit a roadblock while trying to integrate code from another team and connect it to a third-party API. He can’t figure out where things are going wrong. Is it his code? Is it the other team’s code? Is it the API? A few hours in and he’s going in circles — with no answer in sight.
‘Who can I even ask to help me with this?’
The rest of the developers on the team are heads down trying to complete their own tasks, and googling for an answer has proven fruitless due to the number of moving parts involved.
After pinging a couple of the developers on the other team and getting the runaround, the developer is completely stuck. Due to confidentiality and the rapidly approaching deadline, going to a public forum is out of the question and, even if he could, he’s unlikely to get an answer – let alone the right answer – in time.
This leaves him with with only a couple of viable ways to solve his problem.
Option 1: Keep hacking on it and hope the answer comes.
Option 2: Escalate to a development manager who will need to stop what they’re doing, review the issue, and work to solve it.
At this point, one thing is certain, the project is delayed and multiple tasks are stopped while this bug remains at large. The developer did the best he could with what he had to work with. But what if there was an…
Option 3: SitePen Support
The developer logs into his SitePen Support account, provides the details of his issue and asks for an answer. A SitePen engineer who is familiar with the developer’s source code, reviews the issue and works with the developer to get him unstuck. Meanwhile, the rest of his team continues on their tasks, uninterrupted. The project is saved!
Learn how SitePen Support can help your team!
Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience. Reasonable load times, smooth animations, and responsive interaction gives user a sense of interaction and immersion, whereas slow load times frustrate users, and choppy animation and interaction quickly makes an experience awkward and disconcerting. As developers, we wisely work for better performance by understanding performance characteristics, and verifying performance with tests. However, one aspect of performance can be particularly difficult to assess, and its effect can easily be underestimated. Memory consumption can have a large impact on performance, but in ways that can easily be missed and ignored.
Once you have created your tests, you’ll need to create a
.travis.yml file in your repository. This file contains configuration information that tells Travis CI how to construct your testing environment and run your tests. For example, to run tests using Sauce Labs, a hosted web app testing service, your
.travis.yml file should look like the following:
language: node_js node_js: - "0.10" env: global: - SAUCE_USERNAME: username - SAUCE_ACCESS_KEY: access-key install: - npm install - cd node_modules/intern - npm install --production - cd ../.. script: node node_modules/intern/runner.js config=tests/intern
You will need to link your GitHub project to your Travis CI account for Travis CI to detect commits to your repository. The process for doing this is described in the Intern wiki. Once linked to your project, Travis CI will be notified of commits and will automatically run the tests specified in the
.travis.yml file in the source code branch that was committed.
Intern is easy to use with Travis CI, but can also be extended to work with other CI tools like Jenkins and TeamCity. In many cases this just means writing compatible reporters to allow Intern to produce output, like unit test and coverage reports, that the CI system can understand. Reporters can be very simple, and the Intern wiki has more information on writing and using them. Intern 1.4 includes an official TeamCity reporter, as well as
lcovhtml reporters, which are helpful for Jenkins users.
Dijit has a tremendous wealth of high quality and feature-rich form elements providing key functionality including validation, time calculation, spinner controls, calendars, and much more. Furthermore, Dijit gives you a set of themes to choose from: Tundra, Soria, Noir, and Nihilo.
In a previous post I provided the steps to get you up and running with Adobe AIR. I’ll continue with the debugging features available in AIR and the Dojo Extensions for Adobe AIR (dAIR). The Adobe AIR Introspector is a Firebug-like console that logs messages and has code inspectors. Its logging capability is good, but it’s made even better with code in the dair namespace.
As an Ajax developer, I’m always looking for easy ways of helping my development process—things to make development faster, easier ways of checking things, etc. Today I’ll share two quick and easy tricks I use all the time when developing web applications using the Dojo Toolkit.
A lot of the stock Dijit components are single-serve, meaning they only solve one style of problem. But Dojo is very flexible, and can work most any way you imagine or intend — you just have to put on your coder hat, and bend away. That’s where I come in. One of the things I do most often in my role as lead support for SitePen’s Dojo Support offering is to find simple solutions and workarounds for problems encountered when the widget code doesn’t behave exactly as you want, or otherwise needs some level of professional bending.