TwinTechs

Dream, Create, Deliver…

Go: Google’s new language on a test drive.

November 12th, 2009 Written by: Jesse Dailey · Uncategorized

So, the folks at Google have been as busy as ever.  They just released a new language Go.  It has a loosely C-like syntax, compiles directly to native code, and is meant to be a low-level “systems” language.

I happened to be right in the middle of performance-tuning a FastCGI library in Python, with a focus on concurrent I/O problems.  This means I was also right in the middle of being frustrated with Python’s poor support for concurrency.

So, when I read about Go’s emphasis on concurrency without threads (a focus of my current efforts to use asyncore to avoid threads in Python), I couldn’t resist learning enough of the language to compare it’s network I/O performance with Python.

I wrote a quick Echo server (40 lines of code) this morning, and was impressed at how quickly it was going.   Then I looked at the executable, 850kB!  Ok, so, we will have to forgive them for having some unoptimized build tools for now.  At this point I was already not excited about the potential for getting a meaningful performance comparison, but I was still interested to learn more so I decided to get more coffee, and go ahead and do a quick and dirty implementation of FastCGI.

The server works by running one master loop that accepts connections, creates new “goroutines” to handle each connection, and since in FastCGI each connection can potentially multiplex requests over one connection, each of these handlers spawns a “goroutine” for each request.  I’m pretty sure that I am using a couple too many, or too few, channels, but it’s a working library in one day.

For a language that is not intended to be about coding productivity, I am quite impressed at how quickly I was able to do the things I needed.  The documentation is decent, and every documentation page links directly into the source code, so it encourages reading the source, which can be very helpful with something this young.

So far, I would describe the language as immature, but promising.  Other people have complained about the lack of generics, but for a “systems” language, I can understand why they aren’t a priority.

My biggest problem  is that their asynchronous implementation of network I/O is incomplete.  While all the main socket system calls like Read, Write, Listen, Connect, etc. are internally made safe for use by “goroutines”, the Close() system call exposes a race condition when one “goroutine” is creating sockets, and another is closing them.  Hopefully, this is just a growing pain that will be ironed out soon.

For now, my Go implementation doesn’t come close to my Python library (the Go is about 40% the speed of the Python)… but it’s nothing close to a fair fight yet.

→ No CommentsTags:

Drew Shefman and Houston Adobe Users Group

November 12th, 2009 Written by: dshefman · Uncategorized

Drew Shefman, a Houston based senior flex consultant and manager of the Houston Adobe Users Group, recently had fantasic attendance at the MAX09 roundup  meeting where he presented tips and tricks and sneeks from the latest Adobe conference.

→ No CommentsTags:

Suba: Fast text templates in Python 3.0

November 8th, 2009 Written by: Jesse Dailey · Technical, innovation

There are many template engines available for Python already; Mako, Tenjin, Evoque, Cheetah, etc.

Unfortunately, many of these do not support Py3k, and of the ones that do, none of them were building their template objects the way I felt it should be done: by using python’s AST [abstract syntax tree] objects directly.

So, I wrote Suba.

Any of the template engines worth their salt use the text template to create a python program, then compile that program to byte code.  The byte code is typically cached, and exec() is used to run it for each rendering request.  Outside this central theme are a few variations; some of the systems generate a module (instead of just a script) and then import it rather than exec(), some cache to disk, some to memory, etc.; but, none of them create an AST.

The difference in using the AST is that there is no initial text stage; the language objects are instatiated directly.

For instance, the following template in Suba:

Hello, %(name)!

Would produce the following AST tree (some arguments omitted for brevity):

FunctionDef(name='execute', ..., body=[
  Expr(value=Yield(value=Str(s='Hello, '))),
  Expr(value=Yield(value=Name(id='name')),
  Expr(value=Yield(value=Str(s='!')))])

When combined with a post-process walk of the AST, this  allows you to tune and manipulate the code generated from a template with precision that you can’t get when using code-strings.  (As an aside: the python-savvy have noticed that all templates become a  generator, the wiki has some discussion about why this works well).

For instance, suppose you want to filter whitespace from the output.  We could wrap the output in a whitespace filter,or, we can walk the AST tree and edit all the Str() nodes before the code even compiles.  So, when we cache the compiled bytecode, it doesn’t even contain the instructions that would emit the whitespace, meaning that we get this additional feature along with a reduction in run-time.  This is something that would be very difficult to do quickly and cleanly on a code-string using regex and string.replace().

This produces faster templates than the fastest competitor libraries (at the moment, the pool of Python 3.0 supporters is small enough for this to be true).

Here is an example, using Tenjin’s own benchmark templates and data:

tenjin_test: 2864.37 pages/sec (in 3.49 seconds)
suba_test: 5801.79 pages/sec (in 1.72 seconds)

→ 1 CommentTags: ···

Cross-Tile Communication in Adobe Mosaic Tiles

October 6th, 2009 Written by: Chris Turner · FLEX, LiveCycle

Adobe has a new a framework that allows developers to create standalone Flex applications and then gather them together into a larger application. If you haven’t seen Adobe Mosaic Tiles yet, check it out here http://www.adobe.com/products/livecycle/mosaic/. Tiles permits multiple applications to be “mashed” together into one larger application; of course, once they are, there needs to be an efficient way for the tiles to talk to one another. We could write a lot of server code to send messages back and forth between tiles, but luckily for us, Adobe has created an easy way to communicate between tiles.

Setting up cross-tile communication is simple because sending a message from one tile to another is like dispatching events in a Flex application. One tile will send a message and the other tiles can listen for it. The two main players that enable cross-tile communication in this relay are the IRuntime interface and the Message class.

Each tile specified by the <mc:Tile> tag has a protected property named runtime. The runtime property, as defined in the Adobe live docs, is a tile’s access to the runtime system. The focus of this article is on two methods of the runtime object: the addMessageListener function and the sendMessage function.

The addMessageListener function sets up a message listener just like the addEventListener method does with other Flex components. The syntax is slightly different, however: addMessageListener(ns:String, name:String, listener:Object). Let’s say I wanted to call the function named doSomething whenever the message name “callDoSomething” is sent in the namespace titled “myNamespace.” I would then add the code this.runtime.addMessageListener( “myNamespace”, “callDoSomething”, doSomething).

Before we can send a message, an instance of the Message class needs to be created. The Message class acts like an event in Flex except that it has different properties. A message object has three properties: a namespace, name, and payload. The namespace and name will match up a message with a given messageListener defined in another tile. The payload object is the data sent from one tile to the other. Taking the example above, the message that would call the doSomething method would look like this:

var msg:Message = new Message( “myNamespace”, “callDoSomething”, payload )

To send the message, simply call runtime.sendMessage( msg )

The example below sends a message with a string as the payload to any tiles that are listening. The tile that sends the message will be named SendMessageTile and the listening tile is named ReceiveMessageTile. The send message tile simply creates the message and calls the runtime.sendMessage function as shown.


private function sendSampleMessage():void
{
var payload:Object = new Object();
payload.theMessage = "Hello from Send Message Tile";

var message:Message = new Message( "sampleNamespace", "callDoSomething", payload );
this.runtime.sendMessage( message );
}

The ReceiveMessageTile’s job is to setup the messageListener. In this example, the doSomething method alerts a property named “theMessage” to the user.

public function onCreationComplete():void
{
this.runtime.addMessageListener( "sampleNamespace", "callDoSomething", doSomething );
}

private function doSomething( message:Message ):void
{
Alert.show( message.payload.theMessage, "Received Message" );
}

Once the sendSampleMessage() function is called from the SendMessageTile, an alert displaying “Hello from Send Message Tile” will be shown. Pretty simple, right? There are some limitations on the types of objects that can send through the IRuntime interface. If you have complex objects you may want to create helper methods that transform a typed value object to a simple object before calling runtime.sendMessage(). Then on the ReceiveMessageTile you would call a helper method to transform a simple object to your typed value object.

Depending on your requirements, tile communication may be an important part of your project. Now that we’ve discussed how messaging works between tiles, feel free to download the source and build off this simple example.

Sample Application Code

→ 1 CommentTags:

Adobe Flash Collaboration Service

October 5th, 2009 Written by: Michael Korthuis · FLEX, Flash, RIA

I recently had the opportunity to integrate the Adobe Flash Collaboration Service, also known as AFCS, with another application.  For those of you that don’t know, AFCS is a hosted Adobe service that gives Flex developers the ability to easily add real-time social capabilities directly into an application.

Getting Started:

Although it’s still in Beta, the product team at Adobe has done a great job with documentation and has released a slew of sample applications. Setting up an initial “Hello World” AFCS project with webcam, text chat, and a white board support can be done in less than an hour. The Adobe “Hello World” code sample is here.

Getting Down and Dirty:

As we all know, sample applications always work perfectly. But if you are trying to do something a little off piste…  well… many times, things can get a bit dicey.  Our application’s requirements resulted in us extending the base AFCS functionality a fair amount.   These extensions can be summed up into two distinct groups:

  1. Storage of additional data in AFCS.
  2. Enhancements/additions to the current AFCS components (pods).

Storing additional data in AFCS

Luckily, storing additional data in AFCS is easy.   AFCS has a three-deep level data hierarchy,  including:

  1. Collection Node: The highest level.  Collection Nodes wrap up functionality stored in components/pods and consist of a collection of nodes.
  2. Node: Second Level.   These generally wrap up functionality to a certain section, e.g. a history of a chat window and consist of a collection of message items.
  3. Message Item: Lowest level.  Message Item’s support both primitives and simple objects.

In addition, there is a whole bunch of additional goodness relating to all of these data structures including private messaging, session management, and user management.  Also, there is a rather extensive security model that allows you define read/write permissions at a granular level.

Retrieving data and notifying clients of data changes was very easy and the Nodes operated in much the same way as Shared Objects do in Flash Media Player. There were events notifying clients of both data changes as well as synchronization with the server.

I did find a couple of downsides with the data model. Creating a collection node requires owner permissions and  this ended up being a problem as our application had clients trying to dynamically add instances of pods. In addition, the data model is not N deep. This could be troublesome with some data sets, i.e. you want to store the data in nodes as a BST.

Extending AFCS Components

Extending the base components, while not particularly hard, is a little time consuming and does force a developer to get his hands dirty. Fortunately, the developers at Adobe followed some coding rigor and separated most of the pods into two components, model and view. Thus, if you only have to change the L&F of a component and not necessarily its underlying functionality, you can get away with just extending the view component.

In our case, we had to update both the model and the view components. This resulted in reading and understanding the individual components and updating them as necessary.

In hindsight, it might have been prudent to just write our own components.  Once you are comfortable with the API and its functionality, it is easy enough to write your own custom components and interface with AFCS.

Final Thoughts:

Overall, I was very impressed with AFCS and I think it has potential.  The ability to generate an application that gives you chat, webcam, and whiteboard functionality instantly is great. In addition, being able to develop Flex components without the fuss of configuring and installing (not to mention developing!) an app server is a huge plus. Recommendation to Adobe: a desktop sharing component would make this a killer service.

→ 1 CommentTags:

Shiny New Hammer?

October 1st, 2009 Written by: Scott Sayles · Uncategorized

It’s official. Rails is starting to look like a shiny new hammer* in my toolbox. Actually, it’s been that way for a while. An insane level of productivity, easy to understand persistence framework (unlike hibernate), baked-in REST, lots of community support, opinionated development guidelines, works on the JVM, etc. What’s not to like? It’s probably at the top of my list of considerations for any new web application. Of course, I know that part of my fondness is because I’ve gained a good level of familiarity and expertise with it.

Tools you’re familiar with tend to be the tools you use for most jobs. We (the development community) like to expound about having the right tool for the job and how some frameworks and languages are better suited to certain problems than others. This is true, of course, although not always practical. When you are unfamiliar with a certain tool then you have to weigh the costs of having to spend time learning about it in relation to a project timeline. You may also find that the new shiny thing you’ve learned to use doesn’t quite crack up to be what the salesman made it out to be. Another negative outcome is that you might end up wasting time learning something that produced no real benefit (other than learning what not to do or use [struts2 and JSF come to my mind]) and drops out of favor in the community; i.e. you just spent months wrestling with some framework and nobody wants to pay you to use it anymore and now you somehow feel dirty from the experience.

I realize I’m oversimplifying a bit. I just found myself wondering about what kind of strategy I take in selecting new things to learn or recommending new solutions. I think it boils down to direct analysis and a good deal of hearsay and gut feel.

* i.e. when you have a shiny new hammer, everything starts to look like a nail so you’ll use your hammer even when something is clearly not a nail. But hey, maybe pounding it will work anyways. ;-)

→ No CommentsTags:

Do You Speak Flex? Part Two: Recruiting the Right Experience

September 22nd, 2009 Written by: julie.colwell · FLEX, Project Delivery, RIA, innovation

CEO Ben Elmore’s second installment of his four part series on building a a Flex Team was recently featured in InsideRIA.  Read it here!

In our last post, I made the case for building out a Flex team and debunked the current misconceptions surrounding why companies choose not to: that the resources are too scarce, it’s too expensive, and you need a team of experts. With those roadblocks eliminated, the next step is to determine who you need and how to identify them. That’s what we’re going to address here.

Understanding Your Needs
It’s imperative to identify what your requirements are and the number of resources that you’ll need to address them. You must determine what your team needs to accomplish before you begin to assemble it, otherwise you risk redundancy, inefficiency, and slowed or stalled projects. It sounds elementary, but this step can save you a lot of headaches later on. Ask yourself these questions:

What is the size of the application(s) that you need built? You need to know this to decide the size of your team.

Are you building or augmenting your team? If you’re building, a senior resource along with two mid-level resources is ideal. If you’re augmenting, your decision will be based on the amount of work to be done.

Do you have time to train resources? If you do, consider hiring junior resources to pair with a senior resource who can provide mentoring and oversight.

How large and complex is your target application? This question will help you focus the size and needs of your team in direct relation to the duration of the project.

I want to emphasize a couple salient points about building your team. You likely don’t need a huge team (our experience has been that 3-5 resources are sufficient for most projects), nor must that team be comprised of experts with years of experience under their belts. We’ve found that mixed teams of junior and senior level resources are the most productive.

That said, there are times when experience does matter, which returns to my point about clearly delineating the task at hand before you select resources. The key is to realize that while you’ll need an expert to accomplish certain complex tasks like performance profiling an application for scaling or custom visualization, their skill set isn’t typically necessary throughout the entire project.

Here’s a handy categorization:

  • Expert: min 2+ years experience with Flex. Built and produced highly available and/or interactive Flex application. Unique understanding of specific part(s) of Flex related to complex domain problem to solve. Not typically someone who will lead or grow a team.
  •  

  • Senior: min 2+ years experience with Flex. Been on teams before, led a project, solid grasp of MXML and AS. Understands Flex in context of product life cycle. If ‘Designer’ then custom components and look/feel. Min 2 other languages. Performance best practices on Flex. Implemented min 2 Flex projects.
  •  

     

  • Mid: 6m - 2yr working with Flex. Been on a team before, good grasp of MXML and AS languages. Has some understanding of performance related issues to actions.
  • Junior: 0 - 6 months: One other language, preferably scripting language. Has been through training and/or read and walked through good Flex book.

 

The Hiring Process
The hiring process has three components: identification, qualification, and on boarding. The first step is to make a list of how many resources you want to hire at which level of experience (expert, senior, mid and junior), and what skill set is needed (architect, designer, developer). The next thing to do is to locate them. You can use personal referrals, Monster, or similar sites, user group manager/lists, or a corporate recruiter.

Once a candidate has applied there are some specific things I look for on the resume. The most important thing for me is that the languages listed on their resume are consistent, complimentary, and parallel to Flex. If I need a Flex designer, I look for Flash, CSS, JavaScript, or other visually expressive languages; if I need a core Flex developer, I look for programming languages like Java, Ruby, .NET, JavaScript or CF. I’m looking for consistency here. Too much variety is often an indication of lack of focus.

I also look at experience with Flex itself: the length of time working with it and whether it was used peripherally or as a project core. I want to ascertain how they became exposed to the language to understand how they’ll think when working with Flex If I am looking for a senior level developer or architect I look at frameworks, patterns, and methodologies listed on their resume.

The last things I look for are soft skills and overall work experience. I look for both variety and stability here. Were past jobs remote, on-site, or both? Also, speaking or writing engagements are a good indication of a potential team mentor.

Once you’ve found an applicant that you believe matches the criteria you’ve established, it’s time to move on to the interview. This is the “qualifying” component of the hiring process and, arguably, the most important. The interview is generally where the decision to hire is made, and this decision is critical. You need to hire the right people at the right time and understand that mistakes made here could potentially doom a project. Although that sounds scary, knowing what skills resources need and how to identify them will help you make the most informed choice and that’s what we’ll discuss in our next post.

→ No CommentsTags:

UX Director Will Evans Elected to Information Architecture Institute

September 15th, 2009 Written by: julie.colwell · Clients, Flash, Project Delivery, RIA, Uncategorized, Web 3.0

User Design Expert Will Evans was elected to the Information Architecture Institute today. His term will last three years, and he’ll be responsible for developing and leading initiatives that provide networking opportunities for information architects, education and mentoring, and driving awareness around the evolution of user experience and design.

Will has been a member of the Information Architecture Institute for years, but this is the first time he’s been elected to the board. He’s a frequent guest and popular speaker at IA conferences. Will serves as Twin Technologies’ Director of User Experience, providing visionary creativity and guidance for clients that are interested in redefining how users experience their brand online. Will’s designs explore how people engage on and off-line, which tools act as the right catalysts for online engagement, and what factors contribute to social traction.

The IA Institute is a professional organization dedicated to advancing the state of information architecture through research, education, advocacy and community service.  IA Institute sponsors the IDEA conference each year, that explores the convergence of experience design with social and user experiences, and the growing importance of aligning expectations.

Congratulations, Will!

→ No CommentsTags:

Java Application Tier Framework Tailored For LiveCycle Data Services Projects

September 13th, 2009 Written by: Michael Korthuis · J2EE, Java, LiveCycle

With the proliferation of LiveCycle Data Services, it surprises me that there has not been more attention paid to the creation of a Java framework for standard three tiered implementations of LCDS. Of course, in a perfect world, the application tier development should be completely agnostic to your service and UI tiers. However, long term, you can save yourself a lot of headaches if you think about the consequences of an application’s service tier and UI tier architectures. The most obvious case of this is how assemblers execute updates for all clients

As far as I know, the only application tier framework option available that is tailored to LCDS is the Adobe LCDS Hibernate plug-in. However, when using this framework, it quickly becomes apparent that it is not a good solution for enterprise level applications. Reason: the Hibernate plug-in makes the application tier little more than a transportation layer. Using the Hibernate plugin-in, one is effectively creating a client server application. This can be troublesome on many fronts, such as:

  • You can’t always assume the only consumer of the application tier is going to be a Flex client. Web Services and a “classic” or “ajaxy” HTML front end may also need to be implemented.
  • No business logic can be implemented on the middle tier and consumed across clients. All business logic must be implemented in the database and/or client.
  • Security becomes very complicated.
  • Hibernate is not good for bulk data transfers (example: reporting). It specializes in transactional operations.

Due to the lack of options available and lack of development time to come up with a clean architecture, my experience has been that the middle tier architectures of most LCDS applications are not well thought out. LCDS applications generally result in some sort of standard DAO and entity implementation (probably Hibernate) coupled with bloated mapping classes to handle all entity to value object creation. Business logic tends to be sprinkled in between the mappings and is not abstracted at all. This type of architecture (or lack thereof) might work well during the prototyping phase. However, it quickly becomes unwieldy and error prone.

To resolve the architectural problems I’ve seen, I came up with a personal framework that I use for LCDS application development. It covers the entire application tier from DAO’s and Entity Beans to the assemblers and value objects that are being passed back to the UI.

The goal of the framework was to speed up development, follow generic patterns, minimize bugs and ensure a flexible enough solution to fit any type of application. Ease of use was important but not the most critical requirement. I find that each application I write is slightly different and the framework needs to be generalized a little more for each project needs. The framework is meant to solve the common problems one faces and not every problem.

To get a high level overview of the framework and its usage, check out the document posted here.

Next Steps: The framework is still evolving, and there are some features I will likely need to add for future projects. Some big extensions that may need to be added are:

  • Utilization of the java scripting engine in 1.6 for writing business rules in JavaScript. This allows easy customization of the business rules without requiring a system restart.
  • Creation of an ActionScript rules engine that can leverage the same JavaScript rules in the application tier. This saves writing validation scripts on both the client and server side (Think email address).
  • Further streamlining of some of the mapping files, and removing full package names where possible by keying off of directory locations instead of mapping files.
  • Creation of a Web Service DAO Factory and a JDBC DAO Factory.
  • Creation of a generic web service client.
  • Usage of Session and Entity Beans in EJB3.

If you are at all interested in the framework, feel free to shoot me an email at michael.korthuis@twintechs.com and we can talk about it further.

→ No CommentsTags:

Iron George: Twin Tech resident triathlete finishes Louisville Ironman

September 2nd, 2009 Written by: julie.colwell · Government, Uncategorized

george-ironman1

Twin Technologies Director, George Jagodzinski competed in the Louisville Ironman this weekend.  He finished the 2.4 mile swim, 112 mile bike, and full 26.2 mile marathon in a blazing, but grueling 11 hours and 52 minutes.   George had competed in a marathon, several half Ironmans, and a few half-marathons, but this was the first time he’d attempted the full course.  

After a swim in the Ohio river with 2000 other competitors, the bike course wove through rolling farmland in Kentucky with lots of spectators cheering for the riders on the 112 mile journey. The marathon course was fairly flat and very well supported by volunteers.  It followed a two lap route that gave runners more exposure to the high energy spectators but made the final lap difficult mentally.

 A lifelong mountain biker, George had a learning curve to incorporate swimming, road riding, and running into his training.  “Swimming was a major hurdle for me mentally, it took quite a while to develop better form in the pool and then mentally survive open water swimming with over two thousand others kicking you in the face,”  George reports. “Not to mention how scary a large, dark and deep body of water can be. I used to think that monsters lived in the cold spots.”

“I felt great, my training, nutrition and coach from http://qt2systems.com/ made all the difference in the world.  I was prepared and I had a plan to follow,” he says.  George has not ruled out a repeat performance, and plans to be out on the training circuit again, but may opt for shorter distance races until he gears up for another full Ironman.  

Congratulations, George!

 

→ No CommentsTags: