In the book Berkun (former program manager at Microsoft and now author and leadership consultant) describes how he took a break from consulting and joined Automattic (WordPress.com) as an employee for almost two years. He was brought in as part of their transition from a completely flat organizational structure to an organization of teams. Along with anecdotes about the company, he gives lots of great insights about management in software companies in general, and particularly about working in distributed teams (Automattic is a 100% remote employee company — hence the title of the book).
If you’re interested in those things, I highly recommend the book.
If you don’t have the time to read a book right now, this morning I found an interesting article by William Allen (of Behance): Never Stop Talking: How Small Teams Stay Great When They Grow. Although Allen makes no mention of Berkun’s book and uses examples from his own experience, I found it to be a great cliff-notes summary of some of the most compelling ideas I picked up from the book.
I recently read the book Microinteractions by Dan Saffer. I thoroughly enjoyed it, and I think it’s a must-read for anyone involved in Interaction Design, creating user interfaces, or is interested in learning more about those fields.
My favorite part of this book is that it exists at all. That probably sounds weird, so let me explain. When I first started hearing about the book I wasn’t at all sure what it would be about. I wasn’t familiar with the term “Microinteractions” – in fact as far as I can tell Dan invented the term to describe the small-level details of a single interaction. Once I understood what it is about, and the philosophy of interaction design that it promotes, I was hooked.
This book perfectly describes my personal philosophy of what is most important in interaction design. I think the microinteraction level is the most interesting and also the most potentially powerful aspect of interaction design. At the same time, it’s the part of IxD that is unfortunately often ignored in a fast-paced software project schedule. In my experience, too often the budget for interaction design doesn’t allow for much more than working out the flow and layout of screens. Meanwhile, the details of how the interactions actually work is left to whatever UI component or framework is fastest to add to the project. However, I believe that, as Dan points out, the greatest value can be gained from focusing on those small details.
The book provides a thoughtful, grounded framework for how to think about these interactions and how to go about designing them. It also includes lots of great tips and guidelines to follow in the process. It’s full of numerous great (visual) examples to help clarify the ideas being discussed. Many of these, I was pleased to see, come from the excellent site Little Big Details.
My only complaint about the book, which is something I would love to see fixed in a revision or future edition, is related to the examples. (Yes, I did say they were something I liked. =) While the examples themselves are great, it sometimes took some mental effort to work out the connection between the specific examples and the points they were linked to in the book. To be clear, the examples were all valuable – it’s just that for a stretch of a couple of chapters, whenever the book makes a point and then says “see figure x,” the caption that goes with figure x doesn’t give enough detail to make it clear how what that figure shows correlates with the specific point in the text at the point where it says “see figure x.” Sometimes I was able to figure it out, though a number of times it took a fair amount of mental effort to figure out the connection, and sometimes I never did figure it out.
That problem annoyed me enough that I decided to deduct a star from the book rating. However, the book is still very much worth reading, and still very valuable. That’s just the little detail that kept it from being perfect. But you should definitely read it anyway!
Update: Dan Saffer responded (via twitter) to my complaint about the connection between the examples and the text:
@probertson O’Reilly editors added a lot of those unclear/false connections from text to images, over my objections.
Is there a discussion somewhere on practical use cases for AS3 Workers? Best Practices? (Leif Wells on Twitter)
Use cases
I talked some about practical use cases in my presentation. The summary version is this: “any time you find yourself wishing you could make your code run asynchronously, consider putting it in a worker.” In other words, any time you’ve got code that’s doing some sort of work that takes so long that it causes pauses or stuttering in your user interface, that’s a good candidate for a Worker. In particular if the code is something you’d rather do “in the background.” Here are some concrete examples:
text/data processing (e.g. the example I gave in the slides of loading an xml file and looping over all the nodes to create an object graph)
visual/image/audio data processing (e.g. any image processing algorithm that isn’t already using PixelBender) – some examples are in the links below
Physics engine running in the background
Best practices
As for “best practices” that’s basically what I talked about in the section called “caveats” in slides 69-71. (These are also suggested and/or explicitly called out in the documentation.) The main suggestions I would make are:
Under normal circumstances, you shouldn’t use more than one or two background workers at most. Each worker is a full-blown instance of the ActionScript VM/runtime (without a visible stage). In essence you’re increasing memory use and (simultaneous, but distributed) processor use to trade off for not blocking your UI thread. Consider carefully if the cure is worse than the disease. (Remember that a single worker can do multiple operations – just not simultaneously.)
If you’re really done with a worker, terminate it to and the garbage collector will reclaim/free its memory.
Create a separate swf for your workers, rather than using the “same swf for main and worker” pattern. Many of the examples I link to below were created before Flash Builder 4.7 was released. Because of that, those examples tend to use the architecture of having a single swf file serve as both the main swf and the background worker SWF. Personally I strongly recommend against that just on general architectural principles. Before it was a matter of convenience – it’s a lot easier to test code if you only have to recompile one swf. In Flash Builder 4.7 they they added some nifty built-in features for creating and managing workers in projects, that’s no longer necessary because the IDE does the work for you =)
Links and resources
Leif’s question also made me realize that I’ve shared some links on Twitter about Workers, but it would be nice to compile them into a single post. So here is my collection of recommended links related to AS3 Workers:
Adobe documentation
Using workers for concurrency from the ActionScript 3.0 Developer’s Guide. In some ways this is a long-form version of my presentation. (Not surprising since I wrote both of them. =) he section on Understanding workers and concurrency has some of the same background as my presentation, and talks about best practices a bit. The other sections are more practical/hands on.
Worker class in the ActionScript Language Reference. I knew that most developers would go here first to learn about using workers, so I tried to give the class description enough content to help someone get started and find the important info they need.
Several weeks ago, I gave a presentation to the D-Flex users’ group about the new ActionScript workers features in Flash Player 11.4/AIR 3.4. Although I’m a few weeks behind on this, I wanted to share my slides and code.
A lot of the presentation involved talking through examples in the slides, but I also showed a “full” code example at the end.
If you’re interested you can view and download the example from GitHub. It’s a simple app that just counts from 0 to 100,000,000 in a loop. The counting happens behind the scenes – it’s not rendered on the screen – but it does have a progress bar and progress status text field that are updated as the counting happens:
Near the start of the presentation I showed a version of the app that does things the “wrong” way (on GitHub this is called the “NonWorkerVersion”). Since the code just counts in a loop, the code blocks in the loop and the UI freezes. (Depending on how busy your machine is and how high the number is, it can trigger a script timeout error.) Of course, the progress bar and the progress status text field don’t update either since they run in the same thread as the loop that’s counting.
while(i<targetValue){i++;// only send progress messages every so often// to avoid flooding the message channelif(i%oneHalfPercent==0){handleProgressMessage(i/onePercent);}}
Toward the end of the presentation I showed the version that does things the right way.
First, the UI thread spawns a worker and sets up the main thread-to-worker communication, then it starts running:
The worker contains the loop that counts. The worker is still just using a loop (and hence is running in a continuous thread without stopping the entire time). However, it dispatches events to the main thread/worker and it updates the display. This is the code for the worker’s counting loop (from “BackgroundWorker.as”):
while(i<targetValue){i++;// only send progress messages every so often// to avoid flooding the message channelif(i%oneHalfPercent==0){progressChannel.send(i/onePercent);}}
Even though this is just a simple example, it demonstrates how working with workers requires a bit of mind-bending and changing the way we think about coding in ActionScript. I realized as I started using workers that I’m so used to ActionScript’s single-threaded event-driven execution model that I make some assumptions sometimes about code execution. Once I started splitting my code into workers, I had to change my way of thinking.
On one hand, I realized that with the single-threaded model I subconciously made assumptions about certain things already having been processed or finished executing before other blocks of code were run. However, those assumptions aren’t necessarily true when the code is running in parallel, so I had to be more careful in planning my code to accomodate different states of completion at various milestones.
On the other hand, I was able to be more procedural and less event-driven (within my worker code) and just write all the code within a single method that was mostly a loop. This also requires a different way of thinking about the code. I’m so used to splitting code up into lots of event handlers that it’s weird to think that I can just run code in a loop and dispatch events, and know that they will actually be caught and run in the other thread even though the loop/method I’m in hasn’t returned yet.
Once the Worker apis are complete with the Mutex class and the Condition class, this will allow the potential for even more linear/procedural code. It will be possible to pause a thread’s execution, so you could conceivably write an entire worker within a single loop that never exits and just pauses execution until it’s needed. I know that’s normal in some other programming disciplines, but for an ActionScript programmer it’s a bit mind-bending.
I’ve been silent on this blog for a long time. There are several reasons for this:
Technical (the admin part of my Wordpress installation wasn’t working)
Content (there weren’t any new Flash Builder releases so I didn’t have any more Flash Builder-related things to write)
Career (I’ve been transitioning to doing a lot more Interaction Design work, so I’ve been doing more learning than having new thoughts to share)
Time (I’ve been busy with work projects, and some of my outside-of-work volunteer activities have gotten much busier, and my kids are getting older and needing more time – so overall my available time for writing has been much more limited)
In any case, I didn’t mean for this post to be an excuse for my silence. In fact, the title of the post isn’t actually meant to refer to me being “back” to writing on my blog. (Although I do plan to be doing more of that.)
Two years and a couple of weeks ago, I wrote a nostalgia-filled post about leaving my job at Adobe, moving to Texas, and starting a new job as an AIR application developer. Working for Dedo Interactive has been a very rewarding experience. I’ve gotten to work with some great people, on some of the most interesting projects being done right now (in my opinion of course). My employers have been great about working with me to find opportunities to work on projects that match my interests.
In spite of all that, for a time I’ve been feeling that I’ve achieved the goals I had for myself when I joined Dedo Interactive, and so I’ve been looking for a chance to move in some different directions. Fortunately for me, an opportunity opened up at a company that I know is a great employer, and I was selected for that opportunity.
As of yesterday, I’m now officially an Adobe employee once again. My new job is in the developer relations group, specifically in the team that is in charge of developer-related content such as the Adobe Developer Connection. (I’m in a sibling team to Michelle Yaiser and Brian Rinaldi’s team, and a close cousin to the evangelist’s teams.)
My specific area of focus is on the developer documentation and other instructional content (e.g. code samples, example apps, etc.) for ActionScript. Part of my job is to be one of the people who create that content (write documentation and create code examples). Another part (this is where the “developer relations” comes in) is to work with and in the ActionScript developer community to get and keep a deep understanding of how developers work, then use that understanding to design what content we present and how we present it. The end goal is for Adobe to provide the best and most useful instructional resources for developers.
In part this is similar to what I did with Adobe before. However, since this job is now part of Developer Relations, there is more freedom and flexibility to make significant improvements, and more support for working with real developers in the community, which are some of the things that I really wanted to do but were more difficult to do in the past.
I’m excited for the possibilities that this position offers. I’m excited to be working for Adobe again – they really are a great employer. Most of all I’m excited that I get to continue to work with ActionScript and the great ActionScript developer community, and that it’s an official part of my employment.
I’ve written several articles about Flash Builder 4.5’s code templates feature. However, I got a question by email today that made me realize another aspect of templates that’s potentially confusing.
Specifically, I was asked about the “Flash Builder” template category, and how to access those templates (since they don’t show up in the code hint list).
Unlike the other template types (ActionScript, MXML, and CSS), the Flash Builder templates aren’t templates you invoke directly via the code hint list. Instead, those templates give you a way to customize the code that Flash Builder generates when it creates methods, event handlers, and properties. Flash Builder uses these templates when you use Quick Assist to create a method or event handler, when you use the Generate Getter/Setter command (either from Quick Assist or from the menu), when you use the Override/Implement Methods menu item, or when you create a method override using the override code hint.
For example, by default several of these items have a comment in them that looks something like this:
// TODO Auto-generated method stub
I tolerated this for a while, but last week while preparing my Flash Builder coding productivity presentation I decided I was finally tired of deleting those comments every time, so I edited those templates to remove the comment.
Here’s another trick I use quite often in Flash Builder 4.5. To be honest, this feature may have been in Flash Builder 4 and I just didn’t notice it, but I discovered it with Flash Builder 4.5 (and I’ve enhanced it with templates, which are definitely a FB 4.5 feature =).
If you want to override an inherited method (or get/set accessor):
Type
override public function<space>
or
override protected function<space>
Flash Builder pops up a menu showing all the methods that can be overridden. This is also handy just to see what methods are available.
Choose a method name from the code hint list.
Flash Builder creates the method signature complete with parameters and a super.methodname() call.
However, being me, I like to save keystrokes as much as I can. I created a couple of templates to reduce the typing involved in this process:
“opf” contains just the text override public function (including a trailing space)
“oprf” contains just the text override protected function (including a trailing space)
Using these templates I just type “opf<space>” (or “oprf<space>”) and the code hint list appears. Then I type the first few characters of the name I want and I’m in business.
As a side note, if you want to customize the code that Flash Builder inserts when it generates the override method, it’s the template named “override method” in the Flash Builder templates category.
Yesterday I had the privilege of giving a session as part of Adobe Developer Week 2011, on the topic of “Coding Productivity Features in Flash Builder 4.5.” It’s pretty obvious from my recent posts that this is a topic that is important to me =).
Many of the features I talked about are the same ones I’ve discussed in recent posts about Flash Builder 4.5, so you’ll find more information in those articles, although the presentation takes a much more hands-on “watch how I really work in the real world” approach.
In addition to the posts, I talk about my Flash Builder templates several times in the presentation. I updated them a few times in the last week in preparation for the session, and the latest version is now available on my GitHub account:
Finally, if you’re interested in Flash Builder productivity, you’ll want to check out these articles and links for additional information, especially useful keyboard shortcuts:
Last week I presented to D-Flex (the Dallas Flex Users’ Group) on the topic of AIR SQLite for the real world. This is the description of the presentation:
Almost any real application needs to store data, and usually that means using a relational database. In the real world, building an application that uses a database is a complicated, even messy business. Complicated and messy mean slow and inefficient. This presentation is about the libraries, tools, techniques and workflow for developing AIR SQLite applications (learned through lots of trial and error) that help me work faster and better.
I won’t bother posting my slides because for the most part they were reused from my 360|Flex presentation ”AIR SQLite Optimization” (with some updating–mostly trimming content out).
I actually really enjoyed the presentation–I was comfortable enough with the material that I was pretty relaxed. That means I ended up sharing a lot of tips and bits of experience that aren’t reflected in the slides. Hopefully the recording will be available soon; when it is I’ll add a link here and I do encourage you to take some time to watch it if you want to learn some of the lessons I’ve learned about working with SQLite in AIR.
A big part of my presentation was describing (and showing) various libraries and tools that I’ve found useful in my AIR SQLite development. Rather than make everyone write them down, I promised to post them here (I’ve also included a couple that I didn’t mention but that are useful):
For example, suppose you have one or more lines of code you’ve entered, and now you realize you want them to be wrapped in an if statement.
First select the line(s) you want to wrap:
Next hit Ctrl+Space to trigger the code hint menu, then again to switch to the template code hints:
Choose the template name with the mouse, by using the arrow keys, or by typing the name of the template. (Sometimes it looks like the characters you’re typing replace the selected code, but don’t worry–your selection will reappear once you choose the template.)
Accept the code hint, and the template appears with your selection in its proper place:
If you want to create your own templates that support selections, there are two template variables you can use. Use the ${line_selection} variable for one or more lines of code. For example, I created this template to wrap any lines of code in curly braces:
{
${line_selection}
}
This also works with MXML. For example, here is a template I created to wrap a block selection in an MXML tag:
