February, 2010

...now browsing by month

 

Unobtrusive Javascript

Sunday, February 28th, 2010

I’m trying to figure out the best way to create a menu from my database that will be useable with or without Javascript.  After spending some time with the language, massaging it, rubbing its feet, I’m getting a better idea of how I want to use it.  In fact, I’m really glad that I didn’t spend any time on Javascript for quite a while.  I kind of stumbled onto the concept of unobtrusive Javascript.  Basically, I’m trying to figure out how to make the web form for the menu look and function properly before I even think about pull in Javascript to make it snazzier.  Then, once the menu works, I can come back in and make it better for those of us who enjoy the nice things in life.

Programming with a baby

Sunday, February 21st, 2010

Working in my spare time was no problem 6 months ago.  I had plenty of it.  I’m glad that I made good use of it too, because now that Owen is here, my spare time is not as available.  Now, for instance, I’m typing this blog post with him strapped to my chest.  He doesn’t care, his head is cocked over to the side with little snores coming out periodically.  He’s adorable, I just find my time more constrained than before.

It turns out that Owen really likes computers.  If you set him in front of the laptop, he’ll reach out for it and play with the mousepad or bang on the keys.  We’ve also got a spare mouse lying around that he gets to chew on.  Often times, I can come into our office and turn on youtube and keep him entertained for a while.  He loves watching Sesame Street on youtube.  His favorite tv show so far is Curious George.  He’ll just sit bolt upright and talk back at the tv.  It’s humorous.

Some days, I can sit him in his Winnie the Pooh chair that he loves, give him a toy to play with and program right there on the floor next to him.  I can get  in a good 20 minutes with him where I only have to pause every 45 seconds or so.  Yep, 45 seconds is a long time to work on something when a baby is around.

Otherwise, I’ll get a good amount of work done after everyone’s gone to sleep.  I can usually get about 45 minutes of useful work in before I start nodding off in front of the computer.  Given that he likes to get up at 3:30, I try not to stay up too late.  Otherwise, the lack of sleep will kick my butt.

Software Development

Sunday, February 14th, 2010

I’ve been developing some sort of software for the past 6 years as a part of my job.  Most of the code I’ve written has been non-production utilities and has followed a very unstructured process.  I see something that has to be done and try to find the fastest way to automate that task.  This definitely doesn’t always result in the most structured or commented code.  That’s gotten me into trouble when others attempt to troubleshoot the code. Heck, it can be difficult to troubleshoot my own code a while after it’s been written!

With Python, I’ve actually found most of the code to be easier to troubleshoot.  It’s really similar to MATLAB, which makes me happy.  Something about the rapid prototyping and easily understood syntax just makes it a breeze to program with.

Over time, I’ve found that much of the difficulty I have in writing readable code comes from parsing data and dealing with complex code structures.  Once a code structure gets beyond about 3 levels, I tend to start throwing temporary or intermediate variables around too much without enough explanation.  Then I end up with a variable name like this: input_signalname_simple_muxed[j]

When a latent error pops up with a variable name like that, it always takes a while to figure out what the heck it even means.  Maybe I could make the variable name more descriptive, but that doesn’t seem to be the right direction (shorter is probably better).  I haven’t really found a good way around my signal naming.  I usually don’t realize how big a problem I am creating for myself until I’m about a quarter of the way through a particular program.

Some refactoring does help the code, but sometimes the problems are too ingrained into the code to make a refactoring very easy.  That’s not a good way to create maintainable code.  To anyone who has (or has ever had) to troubleshoot my code… I’m sorry.  To be fair, I usually hate troubleshooting other peoples code.

Interesting Blogs:

Chris Dixon’s Blog

Seeing Both Sides

Seth’s Blog

To pursue financing or not to pursue financing

Sunday, February 7th, 2010

I’d like to see my website succeed and be useful and used by lots of people.  I often wonder what the best route is for that to happen.  Obviously if I quit my job and started working on this project full time, I’d get a lot more done a lot faster.  However that is no guarantee that I’d get it far enough fast enough to get enough income to pay my bills before the savings went away.

I’ve also read a lot of advice about how to succeed with an online startup.  The advice I’m most inclined to take is to drive as fast as possible (in my spare time) to achieve ramen profitability.  Get my bills paid with this website so that anything else is just gravy.  As far as I can see it, that’d put me in a strong position to get good terms on any sort of funding.

The problem I have is that I don’t know if I even want financing.  Sure, it would make things happen faster, but that might just add unnecessary stress.  I’m more inclined to strive for some steady growth while still a side-project.  Who knows if my project will succeed.  I sure hope it will and I believe it can.  Otherwise I wouldn’t bother working on it.