Medical data will proliferate exponentially in the coming years. There are many drivers and patterns. Of special interest to the US data industry is the proliferation generated by mobile sensory devices.

The devices themselves are proliferating. While away from medical facilities, one may wear or be attached to devices that sense pulse, blood pressure, body temperature, blood flow rates, and many of the other vital indictors. These data can be generated and stored at high rates. In the US, increasingly the data are stored in private medical practice networks. Imagine a small, 4,000-patient group fitted with a device or two, each generating data 24 hours per day.

In its “The World in 2012” edition the Economist points out the high value obtained from such data by Britain’s National Institute for Health and Clinical Excellence. They are able to closely monitor the benefits of new drugs and expensive treatments. There are studies showing the US value of such systems could be in the hundreds-of-billions range.

The data are accumulating, the value is becoming obvious, and the contracts to aggregate data from scattered systems will be many and huge. Nearly as demanding, will be the contracts to order the data so it may accessed by business intelligence systems.

Wanting to be as unbiased as possible, I have researched online several times and offer these two third-party views:
http://www.bivingsreport.com/2007/wordpress-vs-drupal/
http://www.quis.com/2009/06/01/drupal-vs-wordpress

Both articles try to be unbiased, and I think they succeed. Neither writes that WordPress and Drupal are on the same plane. They both assign WordPress to the simplest of websites and Drupal to the next echelon. This matches our considerable experience. WordPress provides an elegantly ease-to-use CMS. It is the appropriate choice for lightly featured blogs and very simple websites.

Here’s the experience of someone who “loves” WordPress (the language needs editing):
http://kevinjohngallagher.com/2012/01/wordpress-has-left-the-building/

The Drupal community is on a different track. Drupal is a machine for making interactive websites – newspapers, magazines, large corporate websites, online stores. In the spectrum of technology, Drupal picks up where WordPress leaves off, and takes us toward standard web applications. When the project no longer fits “standard things you do on a website,” it is a web application that requires a web application framework. GORGES will in that case recommend the appropriate framework, maybe Ruby on Rails, Yii, or .NET.

It should also be noted, that when a client is engaging GORGES to perform setup, to propose designs, to guide the process and provide training, the distinctions having to do with ease of setup, theme decisions, and ease of use become inconsequential. GORGES shoulders those.

The differences between WordPress and Drupal are finally differences in capability. What interactive features does your website need now and how likely are you to want significant visitor interaction in the future? Is the site to be a one-time undertaking, or is it likely to grow thought time? If these are not issues, WordPress might be just right.

There are legitimate reasons to leave them in test/staging code, if you’re still working out some details.

So I wrote this little library as a replacement.

It doesn’t blow up when the console is not available, adds chainable log() and warn() methods to jQuery selectors, and improves a bit on the display in FF and IE9.

Tested and working nicely in FF, IE9 and Chrome.

I realize this isn’t a groundbreaking idea – but I looked at a couple of existing libraries that do something similar, and nothing really seemed to work well in IE.

Also, this kind of thing should be small – this script compresses to less than 0.5 KB.

On Friday afternoon the event started with brainstorming sessions, and presentations of possible startup ideas were made that evening.  Votes were cast and teams formed around the half-dozen or so leading ideas.  Each team had students with different roles for the concept development, business modeling, and actual programming.

Fueled by caffeine and sugar, the teams worked all weekend in preparation for Sunday evening’s final pitch.  For GORGES’ role, Don Ellis and I were involved at the three mentoring sessions.  To the best we could, we asked questions and offered advice based on our own startup experiences.

On Friday evening the teams presented their ideas and working prototypes to a panel.  The presentations were well-attended, and I would not be surprised if a few of these teams evolved into real startup companies.

As for the actual ideas, most involved using mobile smartphones.  That is a clear indication of where future opportunities lie, and I’m glad we have cultivated and matured our mobile development talent at GORGES.

It was great to see such enthusiasm during the weekend, as well as impressive programming and business talent.  Kudos to Sohan and his team for putting together a great event.

Most people simply do something along the lines of this:

$('body').append('<h1>Hello, World</h1>');

jQuery injects the HTML string into the DOM, and all is well.

But sometimes you need to inject more structured content, or even entire forms – what I typically do is something along the lines of this:

jQuery('body').append(
  $('<div/>').append(
    $('<div/>').text('Hi there'),
    $('<p/>').text('How do you do?')
  )
);

With all the parentheses, angle brackets and repetitive calls to append(), this doesn’t exactly look nice.

Recognizing the repetitive construction of elements, followed by calls to append, what if we had a set of tiny functions that would do both in one simple operation? I decided to give it a shot, and here’s what it looks like:

jQuery('body').append(
  $div(
    $h2('Do you love it?'),
    $form(
      $div('Sign here:', $text()),
      $div($label($checkbox('yes'), 'I love it!')),
      $ul(
        $li($radio('1'), 'Option One'),
        $li($radio('2'), 'Option Two'),
        $li($radio('3'), 'Option Three')
      ),
      $submit('I submit!')
    )
  )
);

The functions prefixed with the $-sign create the elements, and pass down any arguments to the append() method.

The input element methods, such as $radio and $submit are a bit different – they create input elements, set the type-attribute, and if you pass them an argument, they apply that as the value-attribute on the element. (input elements can’t have child-elements, so this doesn’t get in the way of anything.)

You can see a working example and source code here.

Because JavaScript is a highly dynamic language, I didn’t need to write each of these $-functions by hand – with just 13 lines of JavaScript, applying a simple meta-programming technique, all of the functions are automatically generated.

Finally, it’s worth noting that something like $('<div/>') actually results in a string of HTML being parsed and then inserted into the browser. My handy little DOM-helpers avoid the parser – they access the DOM and create HTML elements directly, which means they execute around 10 times faster compared to the first example.

Update

One of my GORGES colleagues pointed out the fact that I had no convenient way to apply attributes to the created elements – if you don’t like the repetitive calls to attr(), try this updated version, which provides a simplified way to apply attributes quickly. This takes a bit more code, but I suspect he’s now porting this to CoffeeScript

Web developers typically write unit tests on server side code and rarely on client side code, which is where JavaScript resides. This approach is reasonable given that the majority of the application logic of web applications run on the server side. However, as the web become increasingly more dynamic, so does the number of lines of JavaScript code needed to support a rich user experience. The need for unit testing in JavaScript should be apparent, yet JavaScript unit testing have been largely ignore.

One reason why developers don’t write JavaScript unit tests is that JavaScript testing is front end testing. Front end tests are hard to write and we are better off leaving it to manual testers. Keep in mind, however, that application logic tend grow exponentially in complexity. So unless the project has the resources to hire manual testers at an exponential rate, it is far more cost effective to devote the time to write tests.

Another reason for not writing JavaScript unit tests is the belief that client side programming logic should be minimized and pushed into the server side wherever possible. The rationale is that JavaScript unit testing is not needed if the code base is small. In other words, not writing JavaScript means not having to write unit tests. However, as mentioned, JavaScript is needed to support a rich web experience. Not writing JavaScript is not an option if a modern web experience is desired.

There are many free and open source testing frameworks available for JavaScript. Three such frameworks are: Selenium, JS Test Driver, and QUnit.

SELENIUM, http://seleniumhq.com

Selenium is not a JavaScript testing framework. Rather, it is an end-to-end testing framework for web applications. So Selenium implicitly tests the JavaScript portions of a web application. Selenium works as follows:

1. Write your Selenium scripts. The scripts can be written in many languages including PHP, Ruby, C#, and Java. If you don’t know how to program, you can use Selenium IDE which is a Firefox plugin that records your mouse clicks and typing web browsing behavior to create test scripts
2. Your unit test runner (e.g., JUnit) sends the scripts to the Selenium server
3. The Selenium server launches browsers and runs the tests. The Selenium server can be configured to launch different browsers on different computer platforms (e.g., PC, Mac, Linux).

Note that Selenium runs your tests using real browsers so you get comprehensive tests of your web application against various browsers. The downside is that the comprehensiveness also leads to complexity of setting up the Selenium server and stand-by machines waiting for Selenium tests. Selenium is best suitable for large web projects with the resources needed to configure various servers.

JS TEST DRIVER, http://code.google.com/p/js-test-driver/

JS Test Driver can be thought of as Selenium-lite but specifically designed for unit testing your JavaScript code (as opposed to end-to-end integration testing as is the case with Selenium). The test runner for JS Test Driver runs your unit tests in the same manner as Selenium. JS Test Driver launches your browsers and executes your tests inside the browser. JS Test Driver can also be integrated into the Eclipse or IntelliJ IDE as a plugin which provides a one click interface to running your JavaScript tests.

QUnit, http://docs.jquery.com/Qunit

QUnit is the simplest of the three framework. You write your tests in JavaScript and embed it in an HTML page with qunit.js and qunit.css include. To run your tests, you simply refresh the page in your browser. There is almost no learning curve for developers familiar with any of the xUnit framework. Because of its simplicity, there is no out-of-the-box support for running your tests on multiples browsers simultaneously, unlike Selenium and JS Test Driver.

Which framework?

These three frameworks all serve different testing needs and are by no means mutually exclusive. If you are only interested in end-to-end integration test, then Selenium is a good choice if you have the resources to set up your testing environment. If you see the value of unit testing JavaScript in your web application, then QUnit is the easiest way to start but look into JS Test Driver as your testing need evolves.

The answer to my first inquiry did not clear it up. The presenter answered something about management policies and approvals for virtualization. Thinking it was just one of those security paranoia things, I let it rest.

But coming back to it I still wondered, why would something so quick, simple, and useful be expensive and management intensive? Then the little light came on, it’s because they were speaking in the world of Microsoft servers and each virtualized server needs a license.

In our shop the virtualization decision has been pushed down to project management level and on down to the developer level. A new application is often virtualized after completion, adjusted to be a production version, and then pushed to the cloud.

Developers treat virtualization as a handy “envelope”, a quick and useful place to put an untrustworthy current version of a new client’s application, or anything else that needs compartmentalization. Developers virtualize as needed. They do not need permission. They use Linux or Centos so there are no cost issues.

Once again. Open Source brings the productivity tool we all need at a price our clients can afford.

GORGES CEO Chris Grant meets with Congressman Hinchey

When the Congressman asked me about GORGES, I let him know about our rapid business growth over the last 5 years, primarily due to our innovation in Internet technologies, and our ability to help our customers businesses grow.

I also mentioned that we are actively keeping software development work from heading to offshore development companies, as our expert developers, low cost of living, and proven processes compete very well on the global market.  While our hourly rates may be higher than India, for example, our total cost to complete a project is often lower.

There are many reasons for this, foremost among them dedicated project management, a willingness to understand our clients’ business needs to create the right-fitting solution, as well as in-house experienced web developers and designers.

After hearing this, the Congressman remarked ‘Now this is the kind of company that America needs to create jobs and move this economy along’.

Just what we were thinking….

This set of guidelines may be used for evaluating websites as they develop or for examining sites by others. It addresses Usability, User Interface, and Communication. There is more to UX, please see other posting by me and watch for new posting on the subject in the next few months.

While this article is not explicitly about SEO, applying the standards here will only be good for SEO.

Usability

Do the graphics communication or supplement the message and purpose of the page? What is the desired balance between the graphical message and the text message?

People scan web pages. They do not read them. So, layout should be rhythmic and language should be concise. Break up traditional paragraphs by using subheadings, bullet lists, and short paragraphs.

Do not over do the breaking up of the page text. If it is a bullet item, then it does not need to be indented. Use one method or the other.

Font styles, sizes, and alignment should be consistent, and generally controlled by the style sheet. Avoid in-line styles. Using more than three different fonts in one page requires very high design skill. Keep it simple.

Link text should contain clear, action words that indicate what the link points to. Avoid using “Click Here” and other test that refers to the document. Remember, the user should be aware of the message, not the website.

Links to non-web formats, such as PDFs, should be identified by noting the format in the link text.

Users associate underlined text with links. So, do not underline text that is not links, this includes headings, page and section identification, and titles in general.

Color for emphasis and differentiation is under used in web pages. The twentieth century used italics and bold to differentiate. The twenty-first century uses color.

Communication

The purpose of every page should be clear to the user. Good questions to ask when creating and reviewing pages include:
• Is it clear what this page is for?
• How is it different from other pages?
• Is this message necessary?
• What is the first thing I notice on this page and does that match what should be the first thing a user notices?
• Is there anything distracting me from the main purpose of this page?

The language of the site and any system messages should be written in clear terms familiar to most users. Avoid jargon and overly technical terms.

Do not invent syntax. Do you mean “or” or do you mean “and”? Do not write “and/or”. It is one or the other. More distracting yet is “inside/outside”.

Do not over use punctuation. Users are not generally computer programmers. The comma is understandable. “Jim ate rice, the brown kind.” Parenthesis have a purpose, but can be just distracting. “Jim ate rice (the brown kind).”

Strunk and Whites. The Elements of Style belongs on every proofreader’s desk.

All text should be proofread for spelling and grammar mistakes.

User Interface

Link text should contain clear, action words that indicate what the link points to. Avoid using “Click Here” and other test that refers to the document. Remember, the user should be aware of the message, not the website.

Links to non-web formats, such as PDFs, should be identified by noting the format in the link text.

Users associate underlined text with links. So, do not underline text that is not links, this includes headings, page and section identification, and titles in general.

Help user to avoid errors. For example, if data need to be entered in a specific format, provide clear instructions for doing so. Do this consistently. Examples:

Home Phone _________________ +1 (607) 555-1212
URL ________________________ http://www.mydomain.com

Does the text wrap around images correctly? Is it spaced away from borders and other graphical edges?

Did you use H1’s for page titles, H2’s for sub-headings, etc.?

Does each page have a unique <title> ? Does the title match the page content and purpose. Remember, these are the words displayed by search engine returns and the default words stored in bookmarks.

Strong passwords are essential to data security. Passwords are easy enough to produce, but they are not as effective as they should be because human foibles lead to compromises. Humans find strong passwords hard to remember so they write them down. They find them hard to say so they send them in email to coworkers.

These problems can be overcome and it can even be fun.

Make the strong password by making it along with a mnemonic. Like this:

Which bear ate up my donut holes
Wb8^mdOs

Now we can refer to this as the “donut” password without giving much away and it is memorable.

We can also make a family of passwords:

Bears do not care for those expensive holes
B!c4t$Os

Is it useful to have two related passwords that may be called “the bear question” and “the bear answer”? Say, for the admin password and the staff password?

Assigning words to the shift characters on the number keys is the trick here, but not too tricky. “^” is top or up or above. “@” is at or each. “$” is money or cash or dollars ……
You get it.

Now we have pass words that can be remembered without using word combinations, i.e., thefudge, or word bastardizations, i.e., es$enti@l, either of which is easily cracked.

Now we also have passwords that can be named even in the presence of strangers without giving them away, you could just say, “Try the bear answer.”

You may also use these ideas to make your own private passwords.

While you are thinking about this, it is also a great way to generate “family passwords.”

Jane never cared for asparagus
jnc4asparagus or jnc4agus

Have fun!