Author: javanator

TypeScript

For a long time now, I’ve tolerated JavaScript.

There is no denying that JavaScript is here to stay. The browser wars are over and HTML5, CSS, and JavaScript won. This is a fact of life, but I’ve not always been happy about it. Rather, I’ve felt that JavaScript is a great way to make something simple happen when you click something, but that it is not well equipped for large-scale development and trying to use it for complex projects is definitely putting a square peg in a round hole. Yes, yes, I know, jQuery, Underscore.js, Backbone.js, AngularJS, Node.js, blah, blah, blah, blah. The list of JavaScript frameworks goes on an on these days and, yes, some of them do some impressive things. Just because one can do a thing, however, does not necessarily make it a good idea. (Remember self-modifying code, anybody? Hopefully, not.)

My objection to traditional JavaScript is based on the fact that the world has been here before and that strongly typed languages were a response to the pain caused by weakly typed languages. Strongly typed languages permit tooling to be orders of magnitude more intelligent. In addition to the heaven-sent standard fare that is autocomplete, I can instantly view all the methods implemented by a class, search for references across an entire code base, and reliably perform a dozen standard refactorings. Code comprehension is boosted by a host of tools that instantly reveal the secrets of large inheritance hierarchies.

While JavaScript support in IDEs has improved over time, by and large none of the above is available with anything like the scale and reliability of tools built for strongly typed languages (e.g. Java).

Perhaps this is changing …

References

The Rise of TypeScript

Official TypeScript Home Page

Determine if a Windows Machine has Local Administrator rights

Use the command net localgroup Administrators to produce a list of all members of the Administrators group, then check if your user ID is in the list.

In this example, the user in question is OPR\K2M6.

C:\Users\k2m6>net localgroup Administrators
Alias name     Administrators
Comment        Administrators of this workstation

Members

-------------------------------------------------------------------------------
G056
OPR\CDE_LTSAltClient_DLG
OPR\Domain Admins
OPR\K2M6
OPR\OPR_WKSAdmins_DLG
OPR\SMS2_INST_WKS_G
OPR\SVC_SMS2_CLTCFG_DLG
The command completed successfully.

REST URL Conventions

GET /locations Show all locations.
GET /locations/new Present form for creating new location.
POST /locations Create new location.
GET /locations/1 Show location #1
GET /locations/1/edit Present form for updating location #1.
PUT /locations/1 Update location #1
DELETE /locations/1 Delete location #1

Use URL parameters _method=PUT or _method=DELETE to generate HTTP verbs not available in browsers.

Use Spring filter HiddenHttpMethodFilter on the server side to support _method parameter.

A Helpful Reference

Pretty Printing in SOAPUI

By default, SOAPUI will pretty-print responses it receives back from web services calls. This is all well and good; makes things simpler to interpret for humans. Unfortunately, it also uses the pretty-printed XML to evaluate any XPATH assertions on your test steps. This means that if the responses contain leading and/or trailing spaces, they are removed. Thus, 

 25

becomes 

25

. By itself, this is not a problem. In fact, it’s convenient. It’s easier to assert that 

//requestId='25'

than 

normalize-space(//requestId)='25'

. Regrettably, SOAPUI does not do this when evaluating the responses in load tests. Create a load test based on a test case with lots of SOAP test steps with assertions that work perfectly well run as a single test case and now you find most of the assertions are broken. Especially if the relevant DBAs are still living in the ancient world and never use varchar because they’re convinced char is dramatically more efficient.

The short story: Test SOAPUI test cases with pretty printing off at some point. Apply the XPath function normalize-space where needed to deal with leading/trailing spaces.

Thread Confinement

True to the mission of this site, my first post reflects something for which I forgot the name and had to look up, so in the Javanator hopper it goes. Thread Confinement is a technique for making the use of an object thread-safe by guaranteeing that only one thread ever uses it. This is in contrast to many of the other techniques for engineering thread safety that involve a lot of guarding and synchronizing and general-purpose sweat of the mind.

The simplest way to ensure thread confinement is to write a single-threaded application. Unfortunately, this is harder to do than it sounds. Think you’ve written a single-threaded app? Don’t be so sure. Does your app use Swing? Definitely not single-threaded, then. Just because you haven’t spawned any threads doesn’t mean one of your frameworks hasn’t and frameworks, it seems, are everywhere these days, even for the smallest of tasks.

I first saw the term thread confinement in the book Java Concurrency in Practice. That reference contains a fine description of the technique, and includes subsections on implementing thread confinement using stack confinement, ThreadLocal variables, and ad-hoc techniques.