My son Max turned 4 yesterday. We had a rocket-themed birthday party for him so I found some instructions on the internet on how to make a water rocket. I'm not much of a handy man but this looked like an easy enough project. The results were somewhat disappointing for me, but luckily 4 year old boys are pretty easily impressed and it was a pretty big hit:
Launch I
Launch II
It looks like the seal at the mouth of the water bottle needed to be tighter and we were going a little overboard on the air pressure. The seal at the top was formed by heating up the PVC pipe with a candle until it became flexible, then pushing inward on both sides to create a bulge. The bulge I made was off to the side a little bit so I'm not surprised that caused a problem. I think if we could have figured out just the right amount of air pressure before it broke the seal we could have gotten a pretty decent launch. So I'm hoping to use it again in the near future to see if we can get better results. If we can't, it was easy enough to make that I'd like to try again, maybe when Max is a little older and can help build it.
Overall it was a fun experience and educational. It definitely made me want to find other projects to work on.
Sunday, August 14, 2011
Wednesday, August 10, 2011
30 Days to Success 1.1
On Monday, Apple approved the new version of my iPhone app, 30 Days to Success. The new version doesn't contain anything too compelling:
I also updated how I retrieved user Facebook information. To post to the app's Facebook page, the user must "like" my Facebook app. Because the user might like/unlike the app, I need to make sure I have the latest info and prompt them accordingly if they try to post one of their successful trials to my app's page. Because it was easier on me, I was retrieving that information when the app started up. But that was a sub-optimal user experience as that information only is needed when posting to the app page. So that was a needed change as I was putting myself ahead of the user.
For my next update, I plan on adding functionality for users to suggest potential trials. I'm going to create a small set of web services on Google App engine that will allow users to submit a trial suggestion, email me a notification so I can review the suggestion and then return the list of suggestions to the app.
- Added functionality to restore application state at launch.
- Updated application to only retrieve user Facebook info as necessary.
- Added nicer view for Facebook Wall of Fame page.
- Added functionality to share the application link with email contacts.
- Added a friendly reminder to provide a review for the application.
- Fixed some minor bugs.
I also updated how I retrieved user Facebook information. To post to the app's Facebook page, the user must "like" my Facebook app. Because the user might like/unlike the app, I need to make sure I have the latest info and prompt them accordingly if they try to post one of their successful trials to my app's page. Because it was easier on me, I was retrieving that information when the app started up. But that was a sub-optimal user experience as that information only is needed when posting to the app page. So that was a needed change as I was putting myself ahead of the user.
For my next update, I plan on adding functionality for users to suggest potential trials. I'm going to create a small set of web services on Google App engine that will allow users to submit a trial suggestion, email me a notification so I can review the suggestion and then return the list of suggestions to the app.
Tuesday, June 28, 2011
Javascript closures
A couple of days ago, there was a thread on Hacker News regarding Javascript closures. The thread referenced a question on Stack Overflow asking how best to explain closures. I'm not going to try and explain them here, but instead describe when the light bulb finally went off in my head regarding closures.
For one of my web app projects, I needed a small component to display the number of characters being typed into a text field (a la Twitter). Unfortunately, I didn't think to check for any existing jQuery plugins for such functionality as there are quite a few. Fortunately, I just rolled my own and in the process finally realized the power of closures.
My implementation turned out to be:
Then for any field that I wanted to attach such a counter, I just had to do the following:
For one of my web app projects, I needed a small component to display the number of characters being typed into a text field (a la Twitter). Unfortunately, I didn't think to check for any existing jQuery plugins for such functionality as there are quite a few. Fortunately, I just rolled my own and in the process finally realized the power of closures.
My implementation turned out to be:
this.AddCharacterCounter = function(textField, counterField, characterLimit)
{
var updateCounter = function()
{
// All the code here to count characters and set css styles
// based on whether or not the limit had been reached.
};
var handleKeyEvent = function(event)
{
updateCounter(textField, counterField, characterLimit);
};
textField.keydown(handleKeyEvent);
textField.keyup(handleKeyEvent);
updateCounter();
}
Then for any field that I wanted to attach such a counter, I just had to do the following:
that.AddCharacterCounter($('#field1'), $('#field1Counter'), 300);
that.AddCharacterCounter($('#field2'), $('#field2Counter'), 150);
that.AddCharacterCounter($('#field3'), $('#field3Counter'), 30);
Monday, June 27, 2011
Project Management: UI
One thing I struggle with both as a developer and PM is UI. There are two particular examples for my history as a PM.
The first project was for an iPhone app where the client asked us to take their comps and make them more iPhone-friendly. Our designer took their concepts and made what I thought was a much cleaner, usable interface. Unfortunately the client didn't like the design and we went through several more iterations of updates, each side getting more and more frustrated as our ideas weren't converging. In the end it became obvious that the client always wanted their original concept/layout but were just looking for us to create nicer UI assets for the implementation.
The other project was a web application in which the client was extremely picky about the web site matching their comps pixel-for-pixel. The client did come up with a very nice design and provided us with very detailed comps so their pickiness wasn't completely unwarranted. As a PM and someone who doesn't easily pick up on UI design issues, I did not do a good job of vetting our implementation of the design before sending it on to the client. As a result a lot of time was wasted in back-and-forth communication to work out small UI mismatches.
So how could I have avoided these situations? In the first case I think it was mainly a matter of communication. I interpreted the client's instructions as giving us free reign to generate a completely different implementation of the client's concepts. In the future I will make a point to thoroughly discuss with the client what they are looking for when asking us to do UI work.
In the second case I think it's just becoming more aware of UI issues in general. It was obvious from the start that the client didn't want much/any deviation from their comps. But the web application was packed with functionality and as a developer, functionality is what I find interesting. In contrast, I can't just look at a label and tell what its font styles are and if they match the styles in a comp. In the future, I think I just need to consciously check for these type of issues, along with learning/practicing more design in my own side projects. I will also be more aware that a client that gives us detailed comps will probably be particular about how those comps are implemented.
One other step that I think would help in such a case is getting the general HTML/CSS layout in place and signed off by the client before beginning to implement any major functionality. Such a workflow would really make HTML/CSS changes easier rather than trying to force-fit changes later on in the project.
The folks at Herding Code recently had a very interesting podcast on situations like the second project I described here.
The first project was for an iPhone app where the client asked us to take their comps and make them more iPhone-friendly. Our designer took their concepts and made what I thought was a much cleaner, usable interface. Unfortunately the client didn't like the design and we went through several more iterations of updates, each side getting more and more frustrated as our ideas weren't converging. In the end it became obvious that the client always wanted their original concept/layout but were just looking for us to create nicer UI assets for the implementation.
The other project was a web application in which the client was extremely picky about the web site matching their comps pixel-for-pixel. The client did come up with a very nice design and provided us with very detailed comps so their pickiness wasn't completely unwarranted. As a PM and someone who doesn't easily pick up on UI design issues, I did not do a good job of vetting our implementation of the design before sending it on to the client. As a result a lot of time was wasted in back-and-forth communication to work out small UI mismatches.
So how could I have avoided these situations? In the first case I think it was mainly a matter of communication. I interpreted the client's instructions as giving us free reign to generate a completely different implementation of the client's concepts. In the future I will make a point to thoroughly discuss with the client what they are looking for when asking us to do UI work.
In the second case I think it's just becoming more aware of UI issues in general. It was obvious from the start that the client didn't want much/any deviation from their comps. But the web application was packed with functionality and as a developer, functionality is what I find interesting. In contrast, I can't just look at a label and tell what its font styles are and if they match the styles in a comp. In the future, I think I just need to consciously check for these type of issues, along with learning/practicing more design in my own side projects. I will also be more aware that a client that gives us detailed comps will probably be particular about how those comps are implemented.
One other step that I think would help in such a case is getting the general HTML/CSS layout in place and signed off by the client before beginning to implement any major functionality. Such a workflow would really make HTML/CSS changes easier rather than trying to force-fit changes later on in the project.
The folks at Herding Code recently had a very interesting podcast on situations like the second project I described here.
Thursday, June 23, 2011
Project Management: Project History
One thing I wish I had done better on my current project is to keep track of decisions that were made throughout the project. Multiple requirements have been changed multiple times and have just become more complicated throughout the process. It would be nice if there was a one-stop place where I could go to review past changes/decisions and why they were made to better make sense of new change requests. Yes, most decisions can be retrieved by searching through email but I'd like something that I can just pull up and quickly glance over, digging down deeper if necessary.
So for future projects I'm planning on keeping a project journal to try and capture this information. I am going to focus on feature-level decisions as I can track task-level changes within our internal task system.
At first I was thinking that a wiki would be a good place to track this information, but I'm going to create a journal document within our internal collaboration system, FirstClass. Using a document will be pretty convenient since I can drag/drop emails into the document to create links back to the conversation threads where changes were discussed and approved. These links will then serve as a way for me to dig down deeper to revisit past changes and as a gentle reminder to clients of the change requests that were made during the project.
So for future projects I'm planning on keeping a project journal to try and capture this information. I am going to focus on feature-level decisions as I can track task-level changes within our internal task system.
At first I was thinking that a wiki would be a good place to track this information, but I'm going to create a journal document within our internal collaboration system, FirstClass. Using a document will be pretty convenient since I can drag/drop emails into the document to create links back to the conversation threads where changes were discussed and approved. These links will then serve as a way for me to dig down deeper to revisit past changes and as a gentle reminder to clients of the change requests that were made during the project.
Wednesday, June 22, 2011
TO B.R. HAYDON, ESQ.
High is our calling, Friend!--Creative Art
(Whether the instrument of words she use,
Or pencil pregnant with ethereal hues),
Demands the service of a mind and heart,
Heroically fashioned--to infuse
Faith in the whispers of the lonely Muse,
While the whole world seems adverse to desert:
And, oh! when Nature sinks, as oft she may,
Through long-lived pressure of obscure distress,
Still to be strenuous for the bright reward,
And in the soul admit of no decay--
Brook no continuance of weak-mindedness:
Great is the glory, for the strife is hard!
William Wordsworth
High is our calling, Friend!--Creative Art
(Whether the instrument of words she use,
Or pencil pregnant with ethereal hues),
Demands the service of a mind and heart,
Heroically fashioned--to infuse
Faith in the whispers of the lonely Muse,
While the whole world seems adverse to desert:
And, oh! when Nature sinks, as oft she may,
Through long-lived pressure of obscure distress,
Still to be strenuous for the bright reward,
And in the soul admit of no decay--
Brook no continuance of weak-mindedness:
Great is the glory, for the strife is hard!
William Wordsworth
Tuesday, June 21, 2011
Project Management: People
One of my favorite blogs is Rands In Repose. Rands is the only person I've ever read that makes project management sound both fun and challenging. He really seems to be able to get into the heads of people and understand what makes them tick. While reading his book Being Geek, I thought to myself that I would really enjoy the challenge of being a full-time project manager in the future (there's always time to write code in my off hours...just ask my wife ). But I don't think I'm at that point yet as I'm not ready to give up writing code during my day job.
One area of project management that Rands focuses on is managing people. At Art & Logic, I have the luxury of focusing most of my energies on the project. I'm not responsible for managing anyone's career path or filling out yearly evaluations. It's basically a matter of defining and doling out tasks. I do my best to try and match developers with tasks in which they have genuine interest, but that isn't too difficult given the unique types of projects we get.
One interesting aspect of project management at Art & Logic is that I'm always managing new people. Part of me enjoys the opportunity to work with new people. At the same time, it would be nice to gel with a consistent team of people and developer deeper relationships. But it really seems to be the nature of consulting where projects come and go much quicker and it's necessary to match the project with people having the appropriate skills.
But again, I'm thinking that it might be fun in the future to work for a product company and manage a team of developers on a commercial product. It would definitely be a new challenge to be responsible for a single product and a single team. I also think it would be fun to be more of a mentor and help people along their paths to become better developers.
One area of project management that Rands focuses on is managing people. At Art & Logic, I have the luxury of focusing most of my energies on the project. I'm not responsible for managing anyone's career path or filling out yearly evaluations. It's basically a matter of defining and doling out tasks. I do my best to try and match developers with tasks in which they have genuine interest, but that isn't too difficult given the unique types of projects we get.
One interesting aspect of project management at Art & Logic is that I'm always managing new people. Part of me enjoys the opportunity to work with new people. At the same time, it would be nice to gel with a consistent team of people and developer deeper relationships. But it really seems to be the nature of consulting where projects come and go much quicker and it's necessary to match the project with people having the appropriate skills.
But again, I'm thinking that it might be fun in the future to work for a product company and manage a team of developers on a commercial product. It would definitely be a new challenge to be responsible for a single product and a single team. I also think it would be fun to be more of a mentor and help people along their paths to become better developers.
Subscribe to:
Posts (Atom)
