Because I work for Sencha, I was lucky enough to spend all of last week at SenchaCon 2013 in Orlando (although I was working the whole time). I tweeted a number of things about the conference recently, but now that I have some time to reflect I wanted to post some of the things I enjoyed most about the event.
In the coming weeks, I’ll be speaking at SenchaCon and ThatConference about building Windows 8 apps using Ext JS. Although these presentations cover the same concepts, their content is slightly different (based upon the target audience of each conference).
Because I don’t expect everyone to have a strong background in either, I thought I would list all of the relevant resources here rather than having 30 links at the end of each slide deck.
If you’re using Sencha Cmd for your Ext JS or Sencha Touch application, then you may be somewhat familiar with the build.xml file.
This file is auto-generated by Sencha Cmd when you create a new project and allows you to add all kinds of hooks into the Sencha build process (which runs on top of Ant).
Over the past several months I’ve seen a number of ways in which developers are using their build.xml file to customize their production builds – and I thought I would share one with you today.
A few days ago, I released LintRoller v2.3.0 – and to celebrate it’s new features, I thought it would be cool to post a screencast. New Features in v2.3.0: Now enforcing strict mode on LintRoller src files Now supporting multiple output formats: text and JSON (XML is coming… eventually) W3C Validation support for HTML files!…
Today I pushed my new website theme live! There’s a lot of exciting things to mention about my new theme, so let’s take a dive into what has changed.
Building Unit Tests for Sencha Apps from Sencha on Vimeo. Slides Give Feedback! If you’re interested in building unit tests for web applications, check out my recent webinar for Sencha. The presentation is specifically targeted at Sencha applications, but the concepts are identical for testing any generic web application. If you take the time to…
This year marks 5 years (minus one I forgot) that I’ve posted my New Year’s resolutions online. Overall I think this strategy helps to keep me accountable… and generally speaking, I think I’m getting better at hitting these goals.
Recently I was asked by a client to if using console.log() would be appropriate in enterprise web applications.
Not everyone agrees with me, but my opinion is simple: Production applications should rarely, if ever, use the console API. I don’t think these statements should ever be checked into version control – they clutter your code, and ultimately make debugging more difficult (because you have to ignore console messages unrelated to a given problem).
Additionally, I have seen errors reported in Internet Explorer by the console object – runtime errors that are in effect bugs in your code.
We went on to discuss the console API and how it offers more than just the standard console.log() method. That got me thinking… even though the major browsers seem to support a consistent console API, are there any actual differences in the implementations?