Blog

Nov 3

FullStack Conference Recap

By on November 3, 2015 8:10 am

I had the opportunity to speak and attend FullStack 2015 organised by Skills Matter and hosted at their CodeNode location in central London. It was a great experience and it’s clear that JavaScript is everywhere and permeating every aspect of technology today! It was no surprise that ES6/ES2015 and TypeScript were popping up in every conversation. Even at a full-stack conference, the front-end seemed to get a lot of focus, most likely because everyone is challenged with improving the web experience.

Continue reading1 Comment
Jun 17

JavaScript in the Enterprise: Where do your developers turn for JavaScript Support?

By on June 17, 2015 8:45 am

The Situation

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!

With SitePen Support, each developer on your team has instant access to their very own dedicated help desk, staffed by SitePen’s expert JavaScript engineers. Inevitable problems like bugs, bad implementations, questions, and indecision are constantly wreaking havoc on project timelines and there are dozens of these issues popping up, around the clock, that kill team efficiency and threaten a project’s success. Choose OPTION 3 and eliminate problems quickly and efficiently by having SitePen’s team of senior JavaScript engineers on call to extend the knowledge, manpower and expertise of your development team.

Learn how SitePen Support can help your team!

No Comments
Mar 17

Memory Consumption: the Externality of Programming

By on March 17, 2015 11:35 am

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.

Continue reading2 Comments
Feb 12

Dojo FAQ: How do I set up continuous integration testing with my Dojo app?

By on February 12, 2014 9:18 am

DojoFAQ

Continuous integration, the practice of frequently integrating the output of multiple developers into a common repository, has become very popular in recent years. A major benefit of CI is automated testing, which also makes CI useful for single developer projects. Intern, the complete JavaScript test stack from SitePen Labs, makes CI easy with your JavaScript-based source code.

Intern has out-of-the-box support for running both unit and functional tests through Travis CI, a popular hosted CI service that is free for open source projects and offers paid subscriptions for private projects. Before you start with CI you’ll need to write tests for your application. The Intern Tutorial is a good place to start, and the Intern Examples project shows how to use Intern with several popular JavaScript frameworks and libraries such as Dojo, AngularJS, jQuery, and Backbone.

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 cobertura and lcovhtml reporters, which are helpful for Jenkins users.

If a simple reporter won’t get the job done, or you just need some help creating one, SitePen offers commercial JavaScript support and development services to assist you in your CI efforts.

No Comments
Oct 31

Debugging Dojo: Common Error Messages

By on October 31, 2012 3:37 pm

Debugging JavaScript can be a tedious and frustrating chore. To compound the already difficult task of debugging, browser vendors each have their own style of error messaging, some of which are confusing, cryptic, or downright misleading to the untrained eye. Through the delivery of our Dojo workshops, we’ve observed a number of common mistakes that are easy to fix once you decipher the error message. Take some time to familiarize yourself with the following common errors that appear when working with Dojo, their symptoms, and their solutions. With this knowledge, writing manageable code is not only possible, but a lot less cryptic.

Continue reading12 Comments
Aug 13

Hacking Safari’s Inspector

By on August 13, 2009 12:05 am

Recently the long-anticipated Safari 4.0 was released. The earlier WebKit was already fast, but this version performs just insanely well. Reloading a page on your local host takes milliseconds as I showed in my last post. Even more importantly, Safari 4.0 comes with a new inspector which includes all the functionality of Firebug, although it’s still not quite as good as Firebug. It doesn’t have the error handling ability, especially for the in-memory Dojo JavaScript files that are initiated with XHR eval. I still use Firefox primarily for development, but I find myself using Safari more and more often, as I just can’t resist the almost instantaneous refreshing of the page.

Continue reading1 Comment
Jan 27

Debugging Adobe AIR Applications Using The Dojo Toolkit

By on January 27, 2009 12:01 am

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.

Continue readingNo Comments
Oct 21

Quick Fixes and Dojo Support

By on October 21, 2008 7:55 am

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.

Continue reading10 Comments

Search the blog

Categories