The notion that Test Coverage alone can provide an adequate metric for determining how well a particular piece of code or, an entire codebase, is being tested has always troubled me. In my experience this can be a very misleading assumption.
Like many of my previous themes, with Test Coverage context trully is key. The issue I find is that relying on a predetermined percentage threshold to provide a “true” measure of successful testing simply fails to take into account the numerous factors involved. For example, the preceived thoroughness of a systems tests can easily be increased – beit mistakenly or intentionally – by testing parts of the system which could be considered irrelevant, or provide very little tangible value; such as getters, setters and the like.
Personally, I advocate focusing first on testing the most critical behaviors and state of a particular piece of code. The tests should not be limited to just testing the expected cases but also, and of equal importance, the testing of exceptional and negative tests.
I could go on about this in great detail; however, I recently came across a really good post from googletesting (which I found via Mike Labriola) which I think pretty much sums it up.
The other day a friend asked me what is the difference between a Value Object and a Domain Model, and when I would suggest using one over the other?
Since I have been asked this very same question quite a few times, I thought it might prove useful to provide a brief definition in the context of a language agnostic idiom which could serve as a point of reference for others as well. Thus, below is general definition of each.
Domain Models
A Domain Model is anything of significance which represents a specific business concept within a problem domain. Domain Models are simply classes which represent such concepts by defining all of the state, behavior, constraints and relationships to other Domain Models needed to do so. Essentially, a Domain Model “models” a domain concept, such as a Product, a User, or anything which could be defined within a problem domain itself, outside of the context of code.
Domain Models promote reuse and eliminate redundancy by defining specific classes which encapsulate business logic, state, behaviors and relationships. As business domain concepts change, so to do the implementations of the Domain Models.
Value Objects
As the name implies, a Value Object, more commonly referred to as a VO, is an object which simply provides values, nothing more.
Value Objects are entirely immutable; that is, all properties are read-only and assignments to those properties are specified only during object creation; after which, properties can not be modified and, by design, should not require changes.
Value Objects are typically used to provide an aggregation of conceptually related properties whose values describe the initial state of the object when instantiated and do not require any real concept of identity or uniqueness. While there are some edge cases (such as validation), more commonly than not, Value Objects do not implement any specific behavior. Conceptually, think of a Value Objects as being nothing more than an object which holds a value, or series of related values, which describe something about the object when created.
It is important to make the distinction between Value Objects and Domain Models, as a Value Objects is not a Model, but rather, it is nothing more than an object which holds values and could be used to describe any particular context. Perhaps a good example of a Value Object could be a JSON object returned from the server. That is a Value Object. A Domain Model could then wrap the Value Object in order to provide state changes, validation and behaviors.
And that’s it
Hopefully the above descriptions of both Domain Models and Value Objects will clear up any confusion surrounding the two concepts; ideally, making it easier to understand when to use each.
The point to keep in mind is that Domain Models simply model a business concept, including it’s rules, constraints and behaviors, while Value Objects simply describe a contextual state.
The Web Timing Specification (draft) aims at providing a standard set of APIs which allow for true end-to-end instrumentation of page load times across browsers.
To quote the w3 spec: “This specification (Web Timing Specification) defines an interface for web applications to access timing information related to navigation and elements.” The API is based on the Navigation Timing and Resource Timing interfaces, respectively.
While I haven’t seen this specification mentioned as part of the HTML5 Family before, in many ways I would consider it to be a worthy candidate for membership as it provides a standards based API through which web applications can be tested for load efficiency. This is obviously something quite useful for any web application as, the ability to precisely measure page load times – and implement optimizations as needed – affords developers the opportunity to provide an improved user experience.
Historically, the ability to accurately measure page load times of web applications has been quite challenging for a number reasons. Just knowing when and where to begin is debatable and, determining the best means of doing so can be a challenge in of itself. Regardless of any current strategies being used, the result is never entirely accurate. With Web Timing developers need not be concerned with these specifics as the API provides the ability to truly measure page load times by encompassing the full scope of loading and parsing a page. This includes the time involved to request, receive and render an HTML document.
For more information, try out the examples in the current supported browsers; IE9, Chrome 6.
“If everyone is moving forward together, then success takes care of itself.” – Henry Ford
The HTML5 Family of Technologies has been receiving considerable coverage lately; and, rightfully so, as, many next generation browsers – specifically those in the Mobile space based on WebKit: Android, iPhone, iPad, Blackberry etc. are now beginning to implement it’s specification, or parts thereof. On the Desktop more HTML5 support is also being seen in the latest versions of Chrome, Firefox, Safari, IE9 and Opera.
The HTML5 Family of technologies will without question play a vital role in the future of the web; and currently, in the mobile Web space, that future is now.
A Brief Overview of the HTML5 Family
For anyone who is unfamiliar with what has been termed “The HTML5 Family“, allow me to provide succinct overview of the technologies which I feel encompass what has already become a rather overloaded term. In general, on a very high level, I would summarize the HTML5 Family simply as follows:
HTML5
CSS3
JavaScript
While the above could be considered the umbrella Technologies upon which The HTML5 Family is based, there are certainly more associated technologies which themselves further augment what could be considered the HTML5 Family, some of which are (based on current specification status at the time of this writing ):
Microdata
Geolocation API
Device APIs
Web Storage (localStorage, sessionStorage) APIs
Web SQL Database API
Web Workers API
Web Sockets API
HTML5
First, HTML5. HTML5 is the next major revision of HTML which aims to advance the open Web through web standards and semantically rich content. HTML5 defines an emphasis on semantic structure and meaning.
In general, HTML5 provides a content model which can be broadly defined into the following categories: Metadata content, Flow content, Sectioning content, Heading content, Phrasing content, Embedded content and Interactive content as well as form-associated elements etc.. HTML5 defines new tags such as canvas, audio, video, keygen, header, footer, nav, article, aside, datalist and more.
CSS3
CSS3 has been broken out into a collection of modules, each of which have their own specifications and are currently in various states of completion. These modules include such examples as Selectors, Transitions, Animations, Namespaces, Color, Fonts, Advanced Layout, Background and more. Some rather amazing designs can now be created purely in CSS3.
JavaScript
Explaining what JavaScript is may seem like a moot point as it is the language of the browser and therefore, the language of the web. However, it is important to outline some key underlying specifics of the language. In particular, JavaScript is a dynamic, prototypal, object-oriented scripting language. Its prototypal nature is quite different from the classical concepts of traditional object oriented languages. In order to get the most out of the language one needs to understand and embrace prototypalism and dynamism. Many of JavaScript’s true potential can be mistakenly overshadowed by it’s assumed design flaws; however, this needn’t be the case. As long as one understands the fundamental concepts of the language, it’s true potential can be realized to enrich development and allow for a level of expressiveness unmatched in type-safe languages.
Microdata
HTML5 Microdata provides a mechanism which allows machine-readable data to be embedded in HTML documents in the form of annotations, with an unambiguous parsing model. Microdata is compatible with numerous data formats such as JSON. Micro-data is intended to provide a standard to replace other similar concepts such as RDFa, from which browsers and other applications can discover relevant content based on the context of an applications markup. Such examples include markup for contact information, calendar events and more. This markup is understood by HTML5 compatible browsers which can then automatically offer to add the relevant content to the appropriate application. At an implementation level, microdata simply consists of a group of name-value pairs; with the groups being called items, and each name-value pair is a property.
Geolocation API
The HTML5 Geolocation API is rather straightforward; it simply provides a means by which the location of a device can be determined via a native API (as opposed to say, determining the clients IP address). The Geolocation spec is currently in last call status in the W3C.
Device APIs
Device APIs are client-side APIs which allow for direct interaction with native device services such as a device Camera, Calendar, Contacts etc.
Web Storage API
The Web Storage API allows for the persistence of local (permanent) and session based (browser session) data on the client. The API for Web Storage is extremely simple as it is based upon simple Key / Value pairs; with which Keys are simply Strings. Each site contains its own separate storage area.
Web SQL Database
While not a part of the actual HTML5 specification, the Web SQL Database presents some extremely interesting possibilities within Web Applications. The Web SQL Database provides a set of APIs which allow for the manipulation of client-side databases using SQL. The Web SQL Database is based upon SQLite (3.1.19) thus supporting the features as specified therein.
Web Workers API
Web Workers provide a mechanism by which web content can execute scripts in background threads. Web Workers allow for a much needed multi-threaded implementation for web based applications executing in a browser. While somewhat similar, Web Workers are different from threads in that they are primarily intended for executing long running, expensive computations and algorithms so as to facilitate non-blocking UI background processes. One specific aspect of Web Workers which has considerable positive implications for the web moving forward is that they run in native threads as opposed to Green Threads; as is the case in VM architectures. This is quite significant as it essentially means Web Workers can scale vertically. Considering the inevitable proliferation of multi-core desktop and mobile devices, this is certainly something that will prove advantageous.
Web Sockets API
Web Sockets provide native, full-duplex communications channels which operate over a single socket that enables HTML5 compliant browsers to use the WebSocket protocol (exposed via a JavaScript API) for two-way communication with a remote host.
If you are interested in learning more about each of these technologies I recommend the following resources:
Moving forward, I plan to go into further detail for each of these associated HTML5 Family technologies, providing working examples and detailed information as to how each can be utilized to create some very unique and interesting possibilities on the Web.
Often I come across what I like to call “Misplaced Code”, that is, code which should be refactored to a specific, independent concern rather than mistakenly being defined in an incorrect context.
For instance, consider the following example to get a better idea of what I mean:
1
2
3
4
5
6
7
8
9
10
11
12
var url:String=Application.application.url;
if(url.indexOf("localhost"){
...
}elseif(url.indexOf("dev"){
...
}elseif(url.indexOf("staging"){
...
}
etc...
Taking the above example into a broader context, it is quite common to see code such as this scattered throughout a codebase; particularly in the context of view concerns. At best this could become hard to maintain and, at worst, it will result in unexpected bugs down the road. In most cases (as in the above example) the actual code itself is not necessarily bad, however it is the context in which it is placed which is what I would like to highlight as it will almost certainly cause technical debt to some extent.
Considering the above example, should code such as this become redundantly implemented throughout a codebase it is quite easy to see how it can become a maintenance issue as, something as simple as a change to a hostname would require multiple refactorings. A much more appropriate solution would be to encapsulate this logic within a specific class whose purpose is to provide a facility from which this information can be determined. In this manner unnecessary redundancy would be eliminated (as well as risk) and valuable development time would be regained as the code would need only be tested and written once – in one place.
So again, using the above example, this could be refactored to a specific API and client code would leverage the API as in the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
switch(DeploymentContext.host)
{
caseDeploymentContext.LOCAL_HOST:
...
break;
caseDeploymentContext.DEV:
...
break;
caseDeploymentContext.STAGING:
...
break;
}
This may appear quite straightforward, however, I have seen examples (this one in particular) in numerous projects over the years and it is worth pointing out. Always take the context to which code is placed into consideration and you will reap the maintenance benefits in the long run.
Recently I was going through some old drafts I had pending when I happened to notice I had never published this one, so I am finally doing so now…
Since first publishing an AS3 HashMap implementation back in December of 2006, much to my surprise the original post through which I released the API still yields a good amount of feedback each month.
In the time since I have extended the functionality of the HashMap to include a LocalPersistenceMap and ResourceMap in addition to the original HashMap; all of which implement the IMap interface and can be used interchangeably by client code.
The single most requested feature I have received has by far been to provide a Bindable HashMap implementation, and, just recently, I decided to implement one and share it with the community.
The implementation of the BindableMap is quite straightforward as it simply provides an API which wraps an IMap implementation in order to facilitate data binding capabilities to all read methods of the underlying Map.
Using the various IMap implementations with BindableMap yields some interesting possibilities; specifically when using BindableMap with LocalPersistenceMap as it essentially provides a bindable implementation of a LocalSharedObject, as can be seen in the following example (e.g. add some values and refresh the page):
