Sunday, June 27, 2010

Reacting to Exceptions

While preparing my slides for the Community Tech Days at Kolkata, I encountered a very interesting exceptional situation. Just to sync you up, I was evaluating Office 2010, specifically PowerPoint 2010. The very first slide had an effect exclusive to the 2010 version of PowerPoint. Just to check the compatibility I ran the slides on another system with PowerPoint 2007 version installed. To my amazement, the slides ran without any effects. No messages or warnings whatsoever! I went berserk (and FYI when I go berserk, that ends up into a new blog post).

The immediate question that spring up was: shouldn’t PowerPoint protest about missing effects? Should it just skip the problem-causing effect, and continue with the show (and prove itself to be robust) or at least caution the user about something that did go wrong at execution or runtime? This spawns up a simple yet important question for us developers: how should we react to exceptions that we don’t predominantly expect and when should we completely disregard them?

Missing effects in a PowerPoint show is surely not a consistent exception. In my personal view (and that’s what this blog is all about), the Office team has full rights to expect a v12 presentation to be opened with v12 of PowerPoint. When I ship an app’s v2 version and supposedly I have a custom document type registered with my application (say .vaibhav or .vaibhavx, to better match the document format trends), I surely would expect a v2 file to be opened by v2 of my app. If the user attempts to open my custom document with an earlier version, I would simply penalize the user for not using the most recent version of my app by throwing an exception, and maybe (I do this for fun) shutting the application. This, I believe is a common trail that most (if not all) of us take when determining on similar problems (saves time and heaps of code, trust me). But then, where exactly does app compatibility fit in?

Software is backwards or downwards compatible when it can work with input generated by an older version. If software designed for the new standard can receive, read, view or play older standards or formats, then the software is said to be backwards-compatible. Forward compatibility or upwards compatibility (sometimes confused with extensibility) is the ability of software to gracefully accept input intended for later versions of itself. The introduction of a forward compatible software technology implies that old software partly can understand data generated by new version of itself. A forward-compatible system is expected to "gracefully" handle input which is intended for a newer version, by ignoring the unknowns and selecting the known subset of the data that the system is capable of handling. Forward compatibility is harder to achieve than backward compatibility because a system needs to cope gracefully with an unknown future data format or requests for unknown future features.

The keyword above (for me at least) is graceful. But, should I leave the user in an indecisive status by removing the obtrusive exception messages? Will that tantamount to a tolerable UX (user experience)? Wouldn’t it be better if I could inform the user, what the problem was, and what its probable solution would (could) be?

How would you resolve a similar situation?

And in the meantime, let me continue to discipline my users with beautiful dialog boxes with subsequent calls to Application.Exit()

Happy Coding!

Saturday, June 5, 2010

Heard it somewhere!

The world it seems, is moving towards an age where an intellectual person will be judged based on the blog posts per week he writes, the tweets he generates (or regenerates) per day, the number of new jargons demystified or created by him per minute and the number of questions he answers per second on stackoverflow.com (think before you rule out the possibility of such a world in near future). To validate myself as a deserving citizen of that world (as and when it comes to existence), I went ahead to demystify certain words and phrases which the gigantic personas of technology in general (credit for the inspiration of this post should go to Erik Meijer, Anders Hejlsberg, Scott Hanselman, Scott Guthrie and so many more who couldn't be declared for genuine space constraints), often use without even considering the fact that some of their audience (read me and only me) have no idea of what that word or phrase corresponds to.
This is an attempt to collate certain phrases which most of us have heard numerous times but haven't essentially researched our way into understanding them comprehensively.
  • Domain Specific Language (DSL): It's a programming or specification language dedicated to a particular problem domain or a particular problem representation technique. The concept isn't new—special-purpose programming languages and all kinds of modeling/specification languages have always existed, but the term has become more popular due to the rise of domain-specific modeling. Examples of domain-specific languages include Logo for children, spreadsheet formulas and macros, SQL for relational database queries, YACC grammars for creating parsers, regular expressions for specifying lexers.
  • Mashup (Web application hybrid): In web development, a mashup is a web page or application that uses or combines data or functionality from two or many more external sources to create a new service. The term implies easy, fast integration, frequently using open APIs and data sources to produce enriching results that were not necessarily the original reason for producing the raw source data. In the past years, more and more web applications provide APIs that enable software developers to easily integrate data and functions instead of building it themselves. Mashups can be considered to have an active role in the evolution of social software and Web 2.0. The term mashup is also used to describe a remix of digital data.
  • Cloud computing: It is Internet-based computing, whereby shared resources, software and information are provided to computers and other devices on-demand. It is a paradigm shift following the shift from mainframe to client–server that preceded it in the early 1980s. Details are abstracted from the users who no longer have need of expertise in, or control over the technology infrastructure "in the cloud" that supports them. Cloud computing describes a new supplement, consumption and delivery model for IT services based on the Internet, and it typically involves the provision of dynamically scalable and often virtualized resources as a service over the Internet. It is a byproduct and consequence of the ease-of-access to remote computing sites provided by the Internet.
    The term "cloud" is used as a metaphor for the Internet, based on the cloud drawing used in the past to represent the telephone network, and later to depict the Internet in computer network diagrams as an abstraction of the underlying infrastructure it represents. Typical cloud computing providers deliver common business applications online which are accessed from another web service or software like a web browser, while the software and data are stored on servers.
  • Atom: It is an alternate XML format for easily sharing content, much like RSS Really Simple Syndication (format). Blogs for example, publish Atom feeds. Atom and RSS have very similar uses; the motivation behind Atom sprang from a desire to add improvements to the RSS specification. Apparently the keeper of the RSS specification froze the spec (declaring that RSS 2.0 would be the last version) and so the authors of Atom felt that a new format was necessary.
  • OAuth and OpenId: OAuth is a simple way to publish and interact with protected data. OAuth attempts to provide a standard way for developers to offer their services via an API without forcing their users to expose their passwords (and other credentials). OAuth is not an OpenID extension and at the specification level, shares only few things with OpenID – some common authors and the fact both are open specification in the realm of authentication and access control. If OAuth depended on OpenID, only OpenID services would be able to use it, and while OpenID is great, there are many applications where it is not suitable or desired. OAuth talks about getting users to grant access while OpenID talks about making sure the users are really who they say they are.
  • OData: The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. The protocol emerged from experiences implementing AtomPub clients and servers in a variety of products over the past several years.  OData is being used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems and traditional Web sites.
  • Mixin: In object-oriented programming languages, a mixin is a class that provides a certain functionality to be inherited by a subclass, while not meant for instantiation (the generation of objects of that class). Inheriting from a mixin is not a form of specialization but is rather a means of collecting functionality. A class may inherit most or all of its functionality from one or more mixins through multiple inheritance. Mixins encourage code reuse and avoid well-known pathologies associated with multiple inheritance. However, mixins introduce their own set of compromises. A mixin can also be viewed as an interface with implemented methods. When a class includes a mixin, the class implements the interface and includes, rather than inherits, all the mixin's attributes and methods. They become part of the class during compilation. Interestingly enough, mixins don't need to implement an interface. The advantage of implementing an interface is that instances of the class may be passed as parameters to methods requiring that interface. A mixin can defer definition and binding of methods until runtime, though attributes and instantiation parameters are still defined at compile time. This differs from the most widely-used approach, which originated in the programming language Simula, of defining all attributes, methods and initialization at compile time.
  • Monads: A monad is a construction that, given an underlying type system, embeds a corresponding type system (called the monadic type system) into it (that is, each monadic type acts as the underlying type). This monadic type system preserves all significant aspects of the underlying type system, while adding features particular to the monad. In functional programming, a monad is a kind of abstract data type used to represent computations (instead of data in the domain model). Monads allow the programmer to chain actions together to build a pipeline, in which each action is decorated with additional processing rules provided by the monad. Programs written in functional style can make use of monads to structure procedures that include sequenced operations, or to define arbitrary control flows (like handling concurrency, continuations, or exceptions). Formally, a monad is constructed by defining two operations (bind and return) and a type constructor M that must fulfill several properties to allow the correct composition of monadic functions (i.e. functions that use values from the monad as their arguments). The return operation takes a value from a plain type and puts it into a monadic container of type M. The bind operation performs the reverse process, extracting the original value from the container and passing it to the associated next function in the pipeline.
  • Type Safety: In computer science, type safety is the extent to which a programming language discourages or prevents type errors. A type error is erroneous or undesirable program behaviour caused by a discrepancy between differing data types. Type safety is sometimes alternatively considered to be a property of a computer program rather than the language in which that program is written; that is, some languages have type-safe facilities that can be circumvented by programmers who adopt practices that exhibit poor type safety. The formal type-theoretic definition of type safety is considerably stronger than what is understood by most programmers. Type enforcement can be static, catching potential errors at compile time, or dynamic, associating type information with values at run time and consulting them as needed to detect imminent errors, or a combination of both. Type safety is closely linked to memory safety, a restriction on the ability to copy arbitrary bit patterns from one memory location to another. For instance, in an implementation of a language that has some type t, such that some sequence of bits (of the appropriate length) does not represent a legitimate member of t, if that language allows data to be copied into a variable of type t, then it is not type-safe because such an operation might assign a non-t value to that variable. Conversely, if the language is type-unsafe to the extent of allowing an arbitrary integer to be used as a pointer, then it is clearly not memory-safe.
  • Immutable Objects: In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created. This is in contrast to a mutable object, which can be modified after it is created. An object can be either entirely immutable or some attributes in the object may be declared immutable; for example, using the const member data attribute in the C++ programming language. In some cases, an object is considered immutable even if some internally used attributes change but the object's state appears to be unchanging from an external point of view. For example, an object that uses memoization to cache the results of expensive computations could still be considered an immutable object. The initial state of an immutable object is usually set at its inception, but can also be set before actual use of the object. Immutable objects are often useful because some costly operations for copying and comparing can be omitted, simplifying the program code and speeding execution. However, making an object immutable is usually inappropriate if the object contains a large amount of changeable data. Because of this, many languages allow for both immutable and mutable objects.
  • Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it functions correctly during simultaneous execution by multiple threads.
    Thread safety is a key challenge in multi-threaded programming. It was not a concern of most application programmers but since the late 1990s has become a commonplace issue. In a multi-threaded program, several threads execute simultaneously in a shared address space. Every thread has access to virtually all the memory of every other thread. Thus the flow of control and the sequence of accesses to data often have little relation to what would be reasonably expected by looking at the text of the program, violating the principle of least astonishment. Thread safety is a property aimed at minimizing surprising behavior by re-establishing some of the correspondences between the actual flow of control and the text of the program.
  • Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.
    The language in which the metaprogram is written is called the metalanguage. The language of the programs that are manipulated is called the object language. The ability of a programming language to be its own metalanguage is called reflection or reflexivity.
    Reflection is a valuable language feature to facilitate metaprogramming. Having the programming language itself as a first-class data type (as in Lisp, Forth or Rebol) is also very useful. Generic programming invokes a metaprogramming facility within a language, in those languages supporting it.
    Metaprogramming usually works in one of two ways. The first way is to expose the internals of the run-time engine to the programming code through application programming interfaces (APIs). The second approach is dynamic execution of string expressions that contain programming commands. Thus, "programs can write programs". Although both approaches can be used in the same language, most languages tend to lean toward one or the other.
  • Lambda lifting or closure conversion is the process of eliminating free variables from local function definitions from a computer program. The elimination of free variables allows the compiler to hoist local definitions out of their surrounding contexts into a fixed set of top-level functions with an extra parameter replacing each local variable. By eliminating the need for run-time access-links, this may reduce the run-time cost of handling implicit scope. Many functional programming language implementations use lambda lifting during compilation.
    The term lambda lifting was first introduced by Thomas Johnsson around 1982.
As expressed, it was never my intent to demystify all the trendy concepts in technology and programming world. Thanks to the definite source of information, Wikipedia, for assisting in collating the above information.

Hope you find some of it (if not all) useful.

Thanks Mr. Reader for your time! Comments as always, are cherished and welcomed!