May 30th, 2009 by Dante
Now i don’t mean this quite as literally as pictured here, and this may seem obvious after I say it, but recently I asked myself the question:
“Why do deadlines work?”
It’s pretty common knowledge that in order to make progress on any project a team needs deadlines to more forward, but why? Why are people so bad getting work done in the absence of a deadline?
My answer came to me in a bit of a round about way. Our team had a deadline that we did not hit. Everyone knew what what had to be done, they even had enough time to do it, but when the day came and went, the work was not done. Clearly, there could be 100s of reasons for this, but after i reflected on it for a while one in particular stands out for me.
We did not set up a face to face review.
My thesis is the following: knowing a deadline just isn’t enough. Deadlines are just dates on a calendar unless people feel social pressure to get something done. No one likes disappointing their team, and they especially don’t like looking teammates in the eye when they disappoint. So when we talk about deadlines, perhaps it would be best to frame them in the form of a review meeting. “Are we going to hit our report out to the boss?” To me, that is the real bite behind a deadline: social pressure.
It doesn’t have to be a negative thing of course. I would never want a team where there was unrealistic or antagonistic social pressure. However, I think a recognition that a little social pressure in a team setting is the real magic behind deadlines will help me to craft more effective ones.
May 11th, 2009 by Dante
I think i’m developing a bit of a split personality. Before jumping to conclusions, let me tell you what I mean. In one part of my life, abstraction is king. As a programmer, your ability to recognize, comprehend, and apply abstraction is a fundamental tool in your toolkit. Without abstraction - and proper application of it - large programs would be utterly incomprehensible. They would be just a mix of random words and numbers without any means of interpretation.
But on the other hand, in the realm of business, I’m finding that abstraction can be quite dangerous. Abstraction - and it’s evil cousin, vagueness - lead to all to many long meetings, or worse, miscommunication.
When communicating - with words, not code - I try my best to support everything with specific examples. This can be hard to do sometimes, and i certainly don’t always succeed, but specificity in language is - i think - a good goal to strive for.
So in the interest of following my own advice, here’s an example of what I mean (it would be a pretty ironic post if i ended with the last paragraph, huh
):
This evening I sent out an email to our RIA meetup group. I was asking for input on our next topic. Specifically, I need two people to prepare some examples of UI design patterns they have followed when using RIAs. Rather than just leaving the request at that, I provided an example about how my team used a JS call to caution the user away from hitting the back button and therefore losing all their work.
I hope that this specific example helped to clarify my request and hopefully made the task seem easier than it would have been if i had just left my request in a general form.
You have examples of how clarity in communication has helped you?
ps. the picture is totally random
May 2nd, 2009 by Dante
On Thursday, the Carrboro RIA Meetup had it’s latest installment of RIA learning. Rob Zelt, (and here) an expert on Silverlight and MS web technologies shared the basiscs of Silverlight with our group. Thanks very much to Rob for sharing with the group! It was a great session where I think everyone learned a lot.
Here are some of my key takeaways from the session:
- Silverlight has a stunningly powerful ability to skin and layout components without touching a single line of logic code.
- The “old” arguments that flash has such a wide install base it will be hard for MS to catch up are starting to be less relevant. The Silverlight install base is growing and growing fast.
- Silverlight 3 has awesome 3d rendering capabilities and will be able to deliver HD content efficiently
- Coding patterns between Silverlight and Flex are quite similar (although Cairngorm is a little different on the flex side)
- MS is working on RIA services, which seems strikingly similar to LCDS. This is a great move as LCDS can be a great productivity boost to Flex teams
There was much more in the presentation, but these are the highlights that come to mind. There was a suggestion at the end that we have a session where we compare building an app in Flex and Silverlight. A great idea, and something we will definitely have to try. If we do that, I’ll definitely post code examples here.
Thanks again to Rob!
April 5th, 2009 by Dante
Lately, I’ve been thinking a lot about marketing. Now that Lasso has a first version out in the wild, my focus must shift to reaching my potential customers. One challenge that i will have in this task is the fact that I, personally, am not a potential customer of my product (i.e. I’m not a business owner, the customer that i need to reach first).
Now, I don’t have a lot of experience in marketing (read that: none), but intuition tells me that step #1 in being a good marketer is having a deep understanding of your customer and your market. So, the question then becomes, how do I gain deep insight into how and why business owners make decisions about how they reach out to their customers.
One of those is, of course, directly visiting businesses. I talked about this in a previous post and it is still the #1 way to gain insight. But unfortunately, visits take a lot of time and resources. I want to find more ways to learn from the experts.
Being the self respecting techie that I am, I naturally turn to online resources to begin my learning process. I’ll start finding industry blogs. I’ll find influential + knowledgeable people on twitter. I’ll start reading relevant news. etc. There’s 2 problems with that approach
- This type of knowledge seeking falls in the “know that i don’t know” category. Useful, but I’m less likely to be surprised
- It’s pull not push. By that I mean, I have to seek out the information i’m looking for. And if, for some reason, i don’t do it for a few days I am liable to miss interesting opportunities.
Enter the wonderful world of data aggregation. This weekend, I spent about 3 hours setting up a series of data feeds that will deliver the news and information I need right to my feed reader. Using a combination of Google Blog search, Google site search, Postrank, Twitter search, and last but not least Yahoo Pipes. I made a very simple way to keep on top of all relevant and interesting news + articles about the restaurant industry. The great thing is that although the breadth of information that I am pulling is quite wide, the amount of information that i have to process is pretty low (thanks to awesome services like Postrank).
Now, it’s certainly not perfect yet and i still have a lot more tweaking to do, but I’m feeling confident that, used properly, powerful tools that allow for this type of data aggregation and transformation will (and certainly already are) positively transform the way that we think about market research.
March 26th, 2009 by Dante
As I was preparing for tomorrows RIA Meetup, it dawned on me that it probably would be a good idea to use my blog as a way to both document and share the work that goes into the meetups. From now on (time permitting), every time we have a meetup, I’ll try to accompany it with a blog post. Now on to the content:
Adobe AIR is runtime environment that liberates RIAs from the browser and brings them right onto a users desktop. When I first heard of a AIR prior to it’s formal release, I (mistakenly) thought of it as an extension to the Flex SDK. While this is correct in a limited sense, defining AIR in this way is too narrow.
In truth, AIR is desktop runtime that enables developers to build rich, web-enabled applications that are installed on a users OS. Developers can build AIR apps with their choice of Flex, Flash, and even DHTML. In the rest of this post I’ll build a case for why one would choose AIR and how AIR development differs across technology choices.
Why Choose AIR?
As you do when designing any software product, technology choices should be driven by customer requirements. Here are some of the customer requirements that would start to point me toward AIR
- Daily use. A customer will use your app frequently and is willing to install the application (an extra step compared to viewing a web page) because it is accessed often
- Connected. The application relies on data out in the cloud. It’s probably multi-user or social in some way
- Need for offline use. If offline use is a requirement, this could be a big push to AIR (or google gears, or some other local storage technology)
- File system access. Will the ability to read / write files on the users local machine enhance the usability or experience of the product?
Now let’s move one click down to some of the technical advandages you gain when choosing AIR
- Your product loads faster. No SWF DL or HTML page load. Your code is local and will boot up faster
- Multiple ways to store data including
- File system access. can read / write files
- SQLite database
- normal “browser-like” approaches like cookies
- Desktop notifications. notify users when there is some sort of state change
- Control over the window. Removing the standard looking window chrome does a lot more than you think to enhance the look and feel of your app. the window can even be transparent… ooooh
Using AIR with Different Technologies
Another very cool thing about AIR is that there are multiple ways to make use of the run-time depending on your background.
If you are a Flash developer, you can use your familiar Flash CS4 product to create AIR apps. I know the least about this option, so I’ll move on…
If you are a Flex developer (like me!) you can build an AIR app in much the same way that you would build a normal Flex app. You have an extended API at your disposal and the configuation of the app is slightly different. This page does a nice job of explicitly listing out all the API differences between Flex development and AIR development. I personally will gravitate toward this option since I think Flex provides a nicer development environment and UI capabilities than DHTML when we are talking about desktop experiences. The other cool thing is that as long as you are careful, it should be easily possible to port an app between a pure Flex browser experience and an AIR desktop experience.
Last but surely not least is DHTML. So for all you web standards lovers out there (and i consider myself among those ranks), you can translate all your HTML / JS / CSS skills straight to the desktop and create disconnected and/or file system aware experiences. Pretty cool stuff! DHTML development comes with a few caveats (not the least among them is that use of eval() is limited due to security concerns. It is overcomable, but needs to be pretty intentionally designed). I haven’t looked, but i suspect that there are probably some pretty good JS libraries out there to make DHTML + AIR development a snap.
Getting Started and References
So there is my 2c introduction to AIR and why i think it is a truly compelling platfrom. It is, of course, not the the answer to every problem in the world; however, for a certain subset of applications, AIR is a wonderful addition to a developer’s toolkit.
To get started with AIR, head to this adobe page and follow the directions. In the Meetup, I plan on exploring the the APIs around windowing (including notification mechanisms in the system tray or application bar) and file read/write capability. Obviously there is much more available, but i have a feeling we’ll be pressed for time with just that.
While preparing, i used the following very helpful references
thanks and have fun with AIR!
February 20th, 2009 by Dante
Over the last 3 weeks, I’ve spent quite a bit of time doing interviews with potential customers of the product i’m working on. I’ve done seven over the last 3 weeks and plan to do several more in the next few weeks. I’ve had an awesome time doing all of them so far and learned a ton, not just about my product, but also about being good at doing interviews
After reflecting for a bit on what went well and what didn’t go so well, i think i have a few ‘take-aways’ that i’d like to make sure to remember for the next time around
1. The less I talk, the better
In an interview format it never ceases to amaze me how amazingly easy to lead a subject. I don’t do this intentionally of course as my goal is to learn from them, not to lead them to whatever “answer” i think i have. Unfortunately, on several different occasions, I asked a question or made a statement and then watched in horror as the person I was interviewing stopped, thought about what i said, and then changed course. Ahh! sometimes i open my mouth too quickly and unfortunately once said, you can’t take that thought back
2. Allow for “digressions”
Being the all-too-often linear person that i am, i generally get annoyed by digressions in conversation. after all, in the case of an interview, I’m there for a specific reason right? Well.. true but with interviews like these, digressions are actually a really powerful tool for two reasons.
First, it puts the interviewee at ease. A quick question about something on the wall or the history of the building might not be what you take away from the interview, but it’s important to remember that the interviewee is usually nervous. They aren’t sure if you are judging them or if there are going to give the “wrong” answer. Digressions help them to relax.
Second, remember that there are 3 categories of knowledge: things you know, things you know you don’t know, and things you don’t know you don’t know. If you never digress, you will never uncover things in the latter category.
3. Never answer questions (at least until the end)
Usually the interviewee is really nervous about doing something “wrong”. They often become self concious and will start reverting to asking questions. I do my best to resist the temptation to answer them. Many times, questions will come regarding the product (if you are showing them one), but the topics can range a great deal.
It’s best to pretend you are a politician and just deflect the question. “what do you think that means?” or even at times a little white lie like “i’m not sure” will help avoid the inevitable leading that will occur if you answer a specific question. after all, you’re not going to be sitting there with them when they are actually trying your product
anyway, I’m still definitely just a beginner at customer inteviews, but i hope that this is a skill that i can continue to develop as i know that deep customer insight is a key ingredient to innovation, and speaking with customers is the main ingredient to deep customer insight!
January 18th, 2009 by Dante
Being totally new to an to an area is difficult. It’s difficult for a lot of reasons, not the least of which is not having connections to people. Although it took me a long time to realize it about myself, I thrive off of having people around. I enjoy listening, learning, and just talking with people that I know well, or am meeting for the first time.
When you are new to an area, opportunites to meet and talk to people seem limited. It’s really easy to feel isolated. However, it’s also an opportunity. It’s an opportunity to do things that you wouldn’t have “normally” done when you are in your comfort zome.
For me, Meetup has been an amazing resource for becoming more comfortable in my new location. I’ve found people with common interests and genuine desires to learn.
Last week, I took the plunge and started my own Meetup on Rich Internet Applications. We had our first meeting on thursday. There were 3 people in total. Not exactly a huge turnout, but I’m encouraged that there is some level of interest. It is great that I can meet a couple people who I would have no way of meeting otherwise and have a two hour long discussion about a topic that i love.
I’m definitely a newly minted big fan of meetup, and i’m looking forward to many more meetups in the future.
January 4th, 2009 by Dante
I’ve been thinking about doing a post like this for a little while now, but finally found the time to get around to it. a little late, but it’s the thought that counts.
08 was a really big year for my personal life. I got married and moved across the country. I’ve started making new friends in a new place and tried to challenge myself to expand beyond my social comfort zone. It is my hope that 09 is as big for my professional life as 08 was for my personal life. Therefore my 09 goals are mostly of a professional nature. I hope to come back to this post in a year and see that I’ve accomplished what i list here.
- Deep involvement in a volunteer activity, ideally with an international organization
- Create at least one product that has active and passionate users
- Build a local product team
- Run an active RIA user group
- Do another century bike ride
- Read more: ~A book a month, broaden topics beyond technical ones
some of these goals are loftier that others, but I hope that writing them down will help to keep me on task and focused on what is important for this year. I just want to add to the ‘goes w/o saying’ category: Keeping in better touch with my family and supporting sarah through her internship this summer regardless of where it is.
Happy 2009 everyone!
December 23rd, 2008 by Dante
My brother’s company, Increo, just released a new product called embedit.in. It’s a competitor to Scribd and gives you a really easy way to embed documents in your website. Way better than forcing a download for something that you really don’t want to have to download.
They got a nice review here:
http://thenextweb.com/2008/12/23/embed-any-file-or-url-with-embeditin/
Check it out. hope it’s useful!
December 11th, 2008 by Dante
I recently read book on Javascript Design Patters that really helped me to write better, cleaner javascript code. You can find it here. Being completely new to JS, I was using the language in a really primitive way. I was basically just responding to DOM events by calling functions directly. If I needed to swap an image on hover, I called a method. If I needed to validate a form, I called a method. JS was just a tool to manipulate the DOM rather than an environment to build an application.
Of course, I knew this wasn’t the best way any self-respecting programmer would code, but i needed some inspiration since JS lacks all the normal constructs I am used from C++, Java, Flex or any other language that I consider myself proficient in. After the Pro Javascript book, I had the tools i needed to start building applications and not what is essentially a javascript puppet show.
The first thing to go is the direct function calls. If you think about it, calling a function directly from UI code like that is really a ‘no no’. Really, what you want to do is fire an event which can be handled by any one or multiple event handlers. This allows for better reuse and more complex interactions. My approach was a simple command processor. When some action happens, i fire an event. The event enters into a loop where it is handled by Command that have registered as handling this event. The commands can either be synchronous or async, it doesn’t matter.
All of this is simply done with about 50 lines of code, but without classes, singletons, and encapsulation is really difficult (for me at least) to dream up how to do it effectively. Now, i’m happily MVC’ing away on the client side!