Recently on GitHub, someone accused Dojo 2 of being vapourware. This opinion came from a position of misinformation. I was glad the individual then engaged with the Dojo 2 project to understand where we are today. We are making swift progress and a beta is on the horizon. It has taken Dojo 2 a long time to get here and to really solidify our vision. We first started brainstorming about plans for 2.0 almost 5 years ago! Around a year ago we solidified our plans and have been unwavering in moving down that path.
We were recently asked about options for mixing Dojo widgets and Angular 2 components into the same application:
- Is it possible to render an Angular 2 component and Dojo widgets on the same page?
- Are there any special configuration settings needed?
- What’s the best way for Angular 2 and Dojo to communicate and/or send messages?
- What kind of complex challenges and communication issues should we be aware of?
- For an application that assembles many different components, if some of these are are Dojo widgets and some are Angular 2 components, how can we get them to play nicely together?
Today, we’re very happy to announce the release of Intern 3.3! This is the result of several months of work to improve Intern and its Dig Dug and Leadfoot dependencies, as well as the introduction of a new intern-cli package to make command-line testing configuration even easier. sitecues by Ai Squared generously sponsored some of these efforts!
One of Intern’s goals has always been to make writing high-quality tests easier, but running those tests hasn’t always been straightforward. Now there‘s a new way to run Intern tests — intern-cli. This package provides an
intern command that has a POSIX-like interface, using familiar flags and options like
--help. It follows some conventions that make running Intern simpler, and provides plenty of inline help. It even makes getting started with Intern easier with a new
A quintessential British tradition is the pub quiz, a test of a group’s knowledge of obscure facts and trivia, typically shared over dinner and drinks at a pub. In the era of the smart phone, pub quizzes have needed to implement strict no phone policies to make sure people are answering from their knowledge rather than their computer.
Day 2 of the Lead Developer Conference continued with a series of excellent talks. Be sure to check out the Day 1 recap if you missed it.
Michael Lopp, Slack
Michael is the VP of Engineering at Slack and known for Rands in Repose. He gave the talk Leadership. By the Numbers which included a fun series of tips and suggestions to improve as a development lead.
Michael explained that you need to say the difficult things, in order to make sure someone fits in. Meaning that if you avoid addressing issues, the engineer will not succeed within your organization. A recurring theme of the conference was to give feedback early and often, rather than waiting for annual or semi-annual review.
Last week I had the opportunity to attend the Lead Developer Conference, a two-day, single-track conference with over 400 development leads from the UK, Europe, the US, Australia, and New Zealand. The event included an excellent array of speakers representing development leads at companies including Slack, Atlassian, ThoughtWorks, Amazon Web Services, GitHub, Shopify, Couchbase, and many other organizations.
Why didn’t anyone think of creating this conference sooner?
I was lucky enough to attend the Progressive Web App Summit hosted by Google at the Theatre Amsterdam with two of my SitePen Colleagues. I was blown away by the quality of the talks, the speakers, the content and of course the venue and hospitality.
Progressive Web Applications take advantage of new technologies to bring the best of mobile sites and native applications to users. They are instant loading, offline capable, installable, secure, responsive and addable to the home screen. More information is available on the Progressive Web Apps website.
In this installment of our series on building web applications, we look at the SitePen approach to solving challenges in web application development. We employ all of the solutions described in part 2 of the blog series. Additionally, we have some overarching principles we apply to our work.
The right architecture and an emphasis on quality
Solid applications and robust architecture begins with finding the right approach based on the goals and requirements for a particular application. There is no one right architecture for every application, but having the right approach to understanding requirements, translating those to architecture needs, and having a strong emphasis on quality lead to approaches that work for any application. We do this by making sure we ask the right questions and challenge our assumptions for every application we create.