David J McClelland

Experiences at the Intersection of Programming & Design

Archive for the ‘Practice’ Category

Install Tomcat on Mac OS


Getting a local Tomcat server instance running on Windows was simple: install it and configure it as part of XAMPP.  Not so on Macintosh OS.

Looking for an alternative, Googling turned up a well-written step-by-step recipe. It includes all of the steps required, from getting Java SDK, getting the right Tomcat package, changing configuration settings, to pointing out a nice little control panel to manage startup and shutdown- similar to the XAMPP control panel for Mac. Well done Wolf Paulus!

Once I got Tomcat running I wanted to post a webapp to get a Hello World page up. This was not covered in the previous recipe, but I found a decent one that worked for me. It also covers installation for Mac, Windows and Ubuntu Linux.

  • Filed under: Practice
  • KnockoutJS, jQuery UI

    Quickly shifting gears to an alternative to KendoUI. Our biggest priority is to continue on with an MVVM architecture and as many controls we can customize as possible without having to build them from scratch.


    I am surveying resources to get up and running with KO as quickly as possible. The main site has some good interactive tutorials and videos, but the standout for me so far has to be Knock Me Out. As I was completing the first tutorial on learn.knockoutjs.com I was thinking “why aren’t they presenting this on jsFiddle so I can translate this into local code and run it on my server?” That must have been what Ryan at KnockMeOut.com was thinking because he created a fiddle for each exercise.

    It’s tempting to showcase your live in-browser tutorials in your own proprietary way that hides the boring html wrapping. But it violates a fundamental learning principal: you must situate the learner in an environment where they have their bearings before you can teach them. The very first knockout tutorial will not work run locally unless you know that the Javascript must be located in the body section below the body contents. Their tutorial completely hides this from the novice learner, and leads them down a lovely garden path as a consequence.

    So why did Ryan feel the need to recreate the tutorials on jsFiddle? Why was I excited to find he had done it? because jsFiddle is a common, known environment that people know how to translate into local file implementations. I can understand what I am looking at and view the source of the frame comfortably.

    Getting Started with KendoUI


    KendoUI is the pick to replace Flash at the office. We looked at several competing frameworks and Kendo seems the most polished and maintainable one out there. It is built over jQuery and seems to play nice with CSS and HTML5. It has almost all the UI controls Flex offers. Binding data to controls via MVVM declarative object instantiation. So far so good.

    Now I am starting to dig in and try to do actual things with Kendo that we are used to doing with Flex. This is turning out to not be as trivial as advertised. I tend to get lost easily when working with frameworks that are trying to make development simple. Because it isn’t.

    To start with we are moving away from using XML and replacing it with JSON. Our server application is supposed to support it. But it doesn’t really. It only supports JSON in certain ways on certain services. And then there is the complication that JSON will only work on pages hosted with the app server. I don’t run the app server on my dev box. My JSON is hosed. JSONP? Not supported.

    So I am forced to upload a package to someone else’s instance of the app server to see if anything works at all, scrape the JSON returned via Charles, make a data.json file that I can read in my local web server, and then figure out why I can’t populate a beautiful blueberry style datagrid in a single line of code.

    And within a week I am going to hear “Why isn’t this done yet? I thought this framework was a solid choice!”

  • Filed under: Practice, Tools
  • OMG, Your Fridge Has The Cutest Profile Pic Ever!

    Link to article

  • Filed under: Practice
  • Captive AIR: Flex is Finally a Legit App Solution

    Getting a Flash project to compile and run on Android devices is pretty well covered on gotoandlearn.com – I recommend starting there. Some of the instructions are out of date but I was able to make it work.

    I spent way too much time getting my Motorola Triumph to come up. If you have one, there is some good reference here. Amazon Fire was also a challenge to connect with, and is stuck on AIR 2.7. This required changing SDK to 4.0 and hacking the AIR Application Descriptor file which had already been generated to call for 3.1.  This aspect of mobile dev is counterproductive once you get over the thrill of testing an app a couple of times. It does underscore the incredible advantage Flex/Flash present for rapid development of mobile apps though, since you can develop a lot before testing on a device or emulator.

    My experience targeting the Fire made it clear to me why AIR captive runtime is really not a nice-to-have option:  it is the only way to guarantee your AIR-based app will run on a wide range of phone and tablet form factors. Compare the incremental download time/space savings of AIR to the installation user experience, developer effort and Flash-taint-avoidance. It finally establishes Flex mobile as a legitimate cross-platform approach. No-one knows/cares what tooling I used to develop a free-standing app, and they certainly don’t want to hear that their device won’t run my app because it isn’t certified to run the latest version of AIR. As a developer I can’t afford to guess how many devices I am abandoning when I move from 4.5 to 4.5.1 SDK.

  • Filed under: Practice, Tools
  • Navigating Cross-Platform The Adobe Way

    I am circling back to the Adobe multi-platform development approach now that I am using ActionScript 3 and MXML all day. I just don’t have the bandwidth now to be productive in Haxe, HTML5 or other language variants with my new full-time Flex responsibilities.

    Meanwhile I hear questions about what alternative to Flex should be pursued, so that keeps the alternative pressure on.

    So I am focusing on what is required to build to Desktop, browsers, iOS and Android from Adobe tooling, and incorporating any other required.

    So far that meant installing Android SDK and attempting to get a phone to show up for ADB. I have a Motorola Triumph, Droid 3 and Kindle fire to try. So far the Triumph does not show up, but I may have installed the USB storage drivers that came with the phone on dev machine. I have to admit, I have never once gotten a phone to work with ADB.

    I downloaded Motorola’s eclipse-based development environment – maybe it has some magic.

    iOS will be an interesting challenge as I have to justify buying a dev license and possible set up a Hackintosh to get something on the only iOS device in my house – an iPad2. I finished off the iPod we had trying to fix the cracked screen with a replacement kit.

    One note on the Moto Triumph – this is a prepay Android 2.2.2 smartphone through Virgin – I own the phone outright for $300 and can use it on Virgin or Sprint. Virgin is $25/month for “unlimited” data and text plus some voice (which I don’t use anyway) and it is almost as good as the Droid. When you look at total cost of ownership, it is about $1400 less than a less-well equipped iPhone or Droid on Verizon with a similar plan over 2 years – less than half.

    Going Enterprise @ Home

    Recently, my personal projects have consisted of building “rough drafts” of components slated in my build plan at work. This has enabled me to approach a problem with familiar methods and then translate them into the enterprise method. However, it is something I hope will diminish fairly quickly so I can move on to more productive activities.

    Having an active model implementation to compare to and learn from is an invaluable opportunity.  I can start layering on additional enterprise development tools and methods on my personal development environment. I will measure my success at this by how it influences my standing as an enterprise citizen.

    Right now I would index enterprise citizenship based on these developer roles:

    • naive thrall
    • educated consumer
    • enlightened contributor/questioner
    • process participant/collaborator
    • process owner/architect

    As I see it, there are three areas these roles vary in what they address: tooling, work practice and integration.

    Tooling should be the easiest: the enterprise where I am currently “enthralled” uses mostly FOSS software that I can attempt to replicate on a smaller scale and compare as I go. So far this is proving to be a lot more challenging than I expected.

    I am going to hold my scope to individual work practices for now. I will the tools I set up following agile practices as much as possible as an individual dev who is also the customer. This means building tests, programming to interfaces, code coverage etc. That should be a matter of personal discipline and mapping enterprise practice where I work.

    Integration is going to be difficult working standalone. I can set up a WSDL service and/or use Google API’s to initiate some automation in my builds. I am also targeting multiple platforms which may benefit from automation too.



  • Filed under: Practice
  • Confessions of a New Enterprise Flex Dev Part 3

    The number of parties participating in a highly integrated development environment increases the risk of a momentary critical failure. I have taken some steps to build resilience to this so that I can keep coding through them.

    The Clearcase Logo design hints at the concurrency node issue

    One step that has been very helpful was to create two local instances of the current project from version control. This serves two purposes: I am able to confirm that work I check in appears in the correct form on other peoples’ instances by doing it myself, and I am able to switch to my “backup” instance when an update breaks my project.


    Another practice is really a side-effect of an unintended consequence of continuous integration. I am very reluctant to check in code unless I am very confident that it won’t break something. This defeats one of the purposes of version control: to provide journalled increments of work.

    I have started using a personal version control system as I develop towards a working milestone that I can check in to the main development stream. Fortunately, I have a development sandbox I can work in that is independent of the main development stream so this work can build against a stable, simplified environment that is always “up”. Still feels dysfunctional though.

    Enterprise Flex Tools: IntelliJ IDEA

    I had never heard of this IDE until very recently. I assumed Enterprise meant you installed the Flash Builder plugin in your existing Eclipse instead of getting Flash Builder standalone.

    Everyone calls Idea IntelliJ because, let’s face it- they probably think they made a clever play on “IDE” but no-one knows what you’re talking about if you refer to it by the product name. “What version of Idea are you using?”

    So why use IntelliJ instead of Builder, FDT, FlashDevelop or Eclipse? The short answer is that it kicks Eclipse’s butt in performance, usability and actual capability. Builder’s too, If you aren’t concerned about editing MXML layouts visually and Adobe product integration. It is a very nice, well-thought-out tool that has all the hooks needed to fit into almost any enterprise setting that uses typical Java/OSS middleware and almost any version control system.

    If you want to try before you buy you can download a trial of the Ultimate Edition. The free Community Edition does not have the MXML/Actionscript plug-in. I might post more on this as I learn more about it.


    Here’s a cool feature I found recently: IntelliJ can make panels semi-opaque when they lose focus so you can still monitor them while coding:



  • Filed under: Practice, Tools
  • Confessions of a New Enterprise Flex Dev Part 2

    6 Challenges/Advantages working in an Enterprise Framework:

    1. I am trapped in someone else’s code and conventions forever.
    2. I don’t know if I broke it or someone else did – or maybe I just found a bug in the framework.
    3. Answering how long something will take to complete will always be wildly inaccurate based on factors outside my control (double-edged, that one).
    4. There is always more to know than I can discover in the duration of the project.
    5. There is always someone who knows more about something/everything than I do and can unintentionally make me look like a dullard to the other engineers.
    6. I have to ask lots of stupid questions or look like a dullard to management too.

    …here are some benefits:

    1. Learning a ton about highly-integrated development practices and tools which apply anywhere
    2. Learning some best practices and theory from OPC that is actually pretty good
    3. I don’t have ridiculous, unrealistic deadlines
    4. Practicing the art of filtering and sift what I need to know- a good management skill
    5. Being surrounded by very capable people who I am encouraged to learn from raises my game
    6. My self-confidence is rooted in something other than what I did lately, my ego is shrinking.

    Hopeful Signs

    Today I found out that a tweening routine I built on top of a panel resize was not the source of a locking bug when rapid-clicking it – it was  the framework. Another developer came by and asked if she could use my code for something because it worked better than what she had so far. Yesterday I found that the reason remote data wasn’t painting on my panel was my error-checking was working correctly and the remote data was garbage.

  • Filed under: Practice
  • Categories

    Finger Lakes, NY

    United States of America

    Subscribe via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.