RESTful Python Objects.

Designing RESTful resources that behave like the web in this day and age makes for good API design practice. The resulting API has a very high level of simplicity that is sought after and valued by many developers. However, what about the client end? Can they too benefit from this elegant design? They sure can. Just like anything else in software design, APIs can be abused or they can be used as intended. So, why not make the client work similarly to how the resources themselves behave? Better yet, why not make them identical?

This can be achieved by mapping individual resources to Python instances. This makes for a good abstraction mapping. One resource, one Python instance. But this doesn't really help the Python developer if there are "special" methods they need to invoke on the instance just to interact with the actual resource. This instances acts as a proxy and so both the instance data and the instance behavior should be the same as the resource. This can be done by using the following principles:

• The constructor could issue a POST HTTP request to create a new resource using the constructor parameters.
• The attribute retrieval could be overridden to issue a HTTP GET request.
• The attribute setting could be overridden to issue a HTTP PUT request.
• The object deletion functionality could be overridden to issue a HTTP DELETE request.

That's it, the instance can then behave like a regular Python instance and be a RESTful resource at the same time. Mind you, these are just principles and not and ideal implementation, obviously. So, what is needed is an HTTP library of some kind to fully implement each of these methods. There will no doubt be variations to these methods as well. For instance, there is often the requirement of retrieving lists of resources as opposed to a single resource.

The following is a simple example illustrating these principles.

#Example; RESTful Python instances.

class RESTful(object):
   def __init__(self, uri, **kw):
       #Issue a HTTP POST request construct a new resource.
       print "POSTING..."
      
   def __getattr__(self, name):
       #Issue a HTTP GET, possibly a conditional GET to 
       #retrieve the resource attribute.
       print "GETTING..."
      
   def __setattr__(self, name, value):
       #Issue a HTTP PUT request to update the resource
       #attribute.
       print "PUTTING..."
      
   def __del__(self):
       #Issue a HTTP DELETE request to destroy the resource.
       print "DELETING..."
      
class BlogEntry(RESTful):
   def __init__(self, uri, **kw):
       RESTful.__init__(self, uri, **kw)
      
if __name__=="__main__":
   entry=BlogEntry("/blog", title="Hello", body="World")
   entry.body="There"
   body=entry.body

Gaphor 0.14.0 Element Editor

The 0.14.0 Gaphor release has a new element editor widget. This element editor is displayed as a separate window instead of being displayed at the bottom of the modeling canvas. This allows for more space when working with larger models. Some people are not big fans of desktop applications with multiple windows. In most cases, it shouldn't be necessary. However, any application that requires a type of canvas interface such as UML modeling tools and image manipulation applications, the more space in the primary window, the better.

Also new in the 0.14.0 Gaphor release is the notion of abstract classes and static attributes. I myself have been waiting a while for this feature and am pleased to finally see it. Both of these features are illustrated below.

Open Source For America

In an interesting entry about open source software adoption, the announcement of the OSFA (Open Source For America) is discussed. So what exactly is the OSFA? The OSFA is a group of organizations who have invested heavily in open source technologies. The reason this group has formed is to promote the use of open source technology in the US federal government. This is simply a fantastic idea and a landmark in open source history. One may ask why a group of organizations is necessary to help a government adopt open source technology. The answer is that open source is relatively new. There aren't many professionals employed by the US government. The organizations that form the OSFA, however, have plenty of expertise in regards to open source. The US government is concerned with running a country, not choosing which software is best suited for the job.

The benefits of using open source technology apply to the government just as they would to any other organization or individual. That is, any government that chooses open source technology over the proprietary alternative gets treated just as though they are a regular user. There isn't any real discrimination in the open source world with who uses what.

The primary motivation for the US government is to cut costs. They savings are obviously in the fact that there aren't any license fees to pay with open source. However, they also gain everything else that comes with open source including generally better software. Additionally, there are hidden cost savings that generally occur on a per deployment basis.

The Canadian government seems to be falling behind in the information technology department. They certainly need to show more interest in advancing their infrastructure which can be achieved through open source. The OSFA serves as a good example of the next step that should be taken.

Three Languages For Learning How To Develop Software

In an interesting discussion, the question of which programming language is best suited for teaching computer science students is raised. It is an interesting question because it seems that there isn't any real consensus among schools as to what the standard language should be. This brings up another question; should there be a standard language that should be taught to computer science students? Or should a more adaptive approach be taken and teach a language geared more toward some specialization?

I think the introductory-level courses need at least some level of language standardization amongst schools. Later on in the computer science program, if there is a specialization the student is interested in, the language best suited for that purpose should be taught. However, there are countless specializations a computer science graduate could strive to be an expert in. I don't think it is possible to realize them all, but the schools that teach these computer science programs should at least open a few broad categories of computer science specializations rather than just a single end point.

During the introductory courses of a computer science program, the concepts take the top priority. I think three languages could serve as a powerful tool in teaching these concepts. First, the C programming language. C allows for a good introduction to low-level programming concepts. It is also a good example of language design and is still heavily used in the industry. Second, the C++ programming language. C++ is a natural progression from C in order to introduce object-oriented concepts. Still heavily used in industry and still low-level. Lastly, the Python programming language. Python gives a good introduction to high-level languages. Not as heavily used in industry but is always gaining popularity. Python and C are highly interoperable.

How To Volunteer Code

Have you ever had someone ask you what open source is all about? Once you tell them, do they in turn ask why would people volunteer their time for free? The latter is a much more difficult question to answer because more often than not, you have to be part of the open source community to "get it". Some people might answer along the lines of "its a cause we are fighting for" or "I simply don't like Microsoft". The good news is that you don't really need a justifiable reason for becoming part of the open source community. One answer to the question of why bother contributing my efforts to the open source community that isn't likely to be heard that often is that it is a world leading learning environment for technology. Open source is, well, open. So, by that virtue alone, one can take the necessary steps to learn. If you have a question about some aspect of some project, it is there for you to figure out on your own if need be.

Trying to dive right into open source project source code may not be the best approach to newcomers to the open source community. If not, then how do people get started with open source? The thing is, the method in which to contribute something back to the community varies on a project to project basis. This can be both good and bad. It is good because there are no restrictions on the development methodology used and other annoying restrictions found in proprietary environments. It is bad because some projects do a great job of letting newcomers know how they can contribute and other projects not so much. As for the projects that don't make clear how additional help could be applied, it is unfortunate since there are many very talented developers out there who are just getting started in their careers. If they would like to put their skills to use in the open source community but don't have a good starting point, those skills are waisted.

Also, as discussed here, There is also the prospect of starting a new open source project. This is another challenging problem since identifying valuable problems in which to solve in the open source world isn't easy. Another problem is there aren't any learning resources from other developers when starting a new project. The lack of mentors available isn't a big a problem for more experienced developers who start their own open source projects. However, younger, inexperienced developers might have a rough go of it own their own.

The best way to join an existing project of interest is simply to ask. But also give those concerned an idea of what you are capable of at the same time. This will also give you an indicator of what working with this particular community would be like.

Lastly, people can also volunteer data as is described here. This is geared toward non-developers who have an interest in contributing to the open source community.

Multiprocessing Firefox

With newer, modern hardware systems, it is likely that they will contain either multiple physical processors or a single physical processor with multiple cores. When writing applications with these systems as the target platform, it is often a good idea to utilize more than a single process within the application. Why is it that multiple processes make sense within a single application? One may be inclined to think of the concept of a process as being designated for a single running application, or a one-to-one cardinality if you will. On top of moving away from the comfortable idea of a single process for a single application that so many developers are used to, there is also the messy problem of inter-process communication. This particular problem isn't quite as bad as it is made out to be. We just need to use the appropriate abstractions on top of the inter-process communication functionality. Going back to the question of why it is a good idea in the first place, the chief benefit of using multiple processes within a single application is the performance gains. While the same application concurrency logic implemented using threads will offer better responsiveness, the multiprocessing approach offers an opportunity for true concurrency on systems with multiple processors.

The Firefox web browser is currently implementing a version of the browser which incorporates multiple processes rather than having the entire application run in a single process. As discussed above, this entry provides some rationale behind why the development team decided to implement this functionality. Aside from the inherent performance gains offered by systems with multiple processors, there is increased stability. The stability is increased because independent processes decouple the entire browser architecture. This helps provide a degree of isolation not available in a single process. The stability gains are especially apparent when considering the multiple tabs used to view disparate web pages. Security could potentially be improved as a side effect of the isolation provided by processes. Finally, not mentioned in the entry but equally relevant in design terms, the distribution of responsibilities within the web browser system becomes very clear. It sometimes takes a drastic move to improve this design principle such as moving entire pieces of code to a separate process.

In this entry, a demonstration of the browser running a separate process for the tab content shows a clear stability improvement. Even after killing the content process, the user interface process remains in tact.

Leaky Abstractions

In an interesting entry, the issue of failed software abstractions is brought up. The title of the entry may be slightly misleading, stating that all abstractions are failed abstractions. In the majority of cases, I would agree that a given abstraction is destined to fail at one point or another. However, there are certain abstractions that can't fail. These are the types of abstractions that are miniscule by comparison with everyday abstraction a developer is likely to see. They are less likely to fail simply because of their small size. Attempting to stuff the entire world into a single class is infinitely stupid and should be avoided, obviously. That being said, there are small abstractions that fail as is illustrated in the entry.

The entry also discusses "leaky" abstractions. What exactly is a "leaky" abstraction? In object-oriented software development, a leaky abstraction can be viewed as an abstraction that doesn't hide underlying problems or inconsistencies. One of the key principles of object-oriented software development is encapsulation, or information hiding. So, it is not unusual for a given high-level software abstraction to use low-level functionality under the covers. This is exactly where the leaks can occur. Technology is almost never perfect, especially when attempting to design code that will run on multiple platforms. If this isn't taken into consideration, leaks will occur. A developer could design the worlds most pristine abstraction that could end up leaking because he didn't consider a subtlety in the underlying technology encapsulated within the class.

The entry uses an object-relational mapper to illustrate an abstraction leak. This has become a popular abstraction for developers in recent years and the problems caused by it are apparent across most if not all software that provides this technology. This particular problem would be an example of a solution domain abstraction leak since the abstraction applies to any business domains using it. One may argue that there exist countless stable software solutions that use object-relational mapper technology and I would agree. I would argue that these projects also had to implement there own niche object-relational mapper abstractions on top of the third party packages just to make them functional. And there is nothing wrong with this because these projects now contain abstractions that do not leak. If this additional abstraction layer weren't implemented, it is nearly impossible to discover where the problem originated, hence the term leak. These types of abstraction leak bug-hunting sessions aren't all that different from memory leak bug-hunting sessions.

In addition to the solution solution domain abstraction leak category, which the object-relation mapper problem falls under, there can also be leaks associated with problem domain abstractions. If the underlying business logic is not fully realized by the abstraction, it can leak in mysterious ways. Abstraction leaks can be as serious a bug as a memory leak and be just as difficult to locate and correct. The main difference being that once a memory leak has been fixed, it is fixed. This is a low-level solution domain issue. Fixing an abstraction leak can have adverse effects on the abstraction itself since the quality of the abstraction matters. It is less-than-ideal to patch an abstraction. Especially in the problem domain.

Subscribing To Event Subscritions In Python

New in the latest version of the boduch Python library is the Subscription class. This abstraction is used to represent active event subscriptions to event handles. A Subscription instance ties together the Event class and the Handle class. The Handle providing the callback functionality that is executed when a given event takes place that the handle as a subscription to. As with previous versions, the event handle still uses the subscribe() function to subscribe to particular events. However, in previous versions, this function didn't actually return anything. The function will now return a Subscription instance. This functionality was added so that developers can have an easier method in which to reference which events will cause a given behavior to take place. The following is an example of a Subscription instance being returned.

#Example; Subscribing to a boduch Set event.

#Import required objects.
from boduch.event import subscribe, EventSetPush
from boduch.handle import Handle
from boduch.data import Set

#Simple handle.
class MyHandle(Handle):
  def __init__(self, *args, **kw):
      Handle.__init__(self, *args, **kw)
    
  def run(self):
      print "Running my handle."
    
if __name__=="__main__":
  #Create a new subscription instance by subscribing to the event.
  print "Subscribing"
  sub=subscribe(EventSetPush, MyHandle)
  print "Subscribed", sub

  #Make sure the simple handle works.
  Set().push("data")

In the example above, we define a simple event handle called MyHandle. We then subscribe this handle to the EventSetPush event to instantiate a new Subscription instance. Each Subscription instance holds a reference to both the handle and the event that the handle has subscribed to. Additionally, Subscription instances also define behavior. Since a Subscription instance holds a reference to the given event, we can use this instance hold build further subscriptions for this event. The core event handles inside the library already define and expose Subscription instances and can be used to create subscriptions for new event handles as the example below illustrates.

#Example; Subscribing to a boduch Set event via subscription.

#Import required objects.
from boduch.subscription import SubSetPush
from boduch.handle import Handle
from boduch.data import Set

#Simple handle.
class MyHandle(Handle):
   def __init__(self, *args, **kw):
       Handle.__init__(self, *args, **kw)
      
   def run(self):
       print "Running my handle."
      
if __name__=="__main__":
   #Create a new subscription instance by subscribing to the event.
   print "Subscribing"
   sub=SubSetPush.subscribe(MyHandle)
   print "Subscribed", sub
  
   #Make sure the simple handle works.
   Set().push("data")

Hackers and Architects

In an interesting entry, the question of whether hacker-type developers have a place in the modern-day IT field. That is, do hacker-type developers add any real business value in a business world? If not, who does in regards to producing software? Is the more standardized architect-type developer better suited for working on anything that isn't a hobby? The argument for not being able to hire the hacker-type onto a formal IT development team is well-grounded in some respects. However, the hacker-type developer wasn't just given that title for no reason. Any given hacker-type developer most likely earned the title through many years of trying things that were unheard of at the time. Believe it or not, organizations that produce anything but the most trivial software need the hacker-type developer as well as the architect-type developer.

The hacker-developer type tends to be experimental by nature. They are willing to go beyond the norm in order to realize a solution. More often than not, the hacker-type developer can get around extremely complex problems in a relatively short amount of time. I like to think that this is because they are able to step outside the standards imposed on the project at hand to find the necessary solution. It is this ability of the hacker-type developer that enables development teams to determine the feasibility of a problem without spending a year developing just to realized it can't be solved within the constraints imposed on the project.

At the other end of the development team we have the architect-type developer who is focused on standards-based development. But they aren't only concerned with standards, they also want to ensure that an elegant loosely-coupled, component-based, interface-conforming system is produced. This is obviously necessary within any serious IT organization. The architect-type developer often has a strong view of the implications of the development team's actions and implementations of problems.

In the field of software development, it seems that these two are closely related but are also different enough stereotypes that should easily be able to collaborate with one another. Not only should it be easy but I think it should also be a requirement. The hacker-type and the architect-type are codependent on one another even if neither wants to admit the fact. Hackers need discipline when it comes to sticking to standards and interface conformance. Architects can easily oversee subtle design flaws that will a particular implementation strategy impossible. Hackers who have a keen eye for this type of thing can help here. Hackers and architects and how they are codependent on one another is just a small slice of the software development ecosystem.