Posterous
Arthur is using Posterous to post everything online. Shouldn't you?
3286618267_3db31c4cec_o_thumb
 

Arthur Chang

Week Four

Porcelain crab

 

Wow, I've almost lost count of how many weeks it has been since we started building our app (photo unrelated... mostly).  It literally started from scratch 4 weeks ago, and tomorrow we are already ready for our second beta release.  This isn't a pure web app, mind you, it's an iPhone app.  We got backend, frontend, api's, stat servers, natural language processing processes, and more, all playing nicely in 3 weeks, and now 4 weeks ready for another release.  On top of all of that, we have all the nitty gritty business details: seed funding, design work, branding work, marketing strategies, PR relationship building, shmoozing, twittering, and blogging.  It all really gets complicated, and it's amazing how we're getting everything in line and organized.

This week was dedicated to improving our first release, w hich I'd like to call our alpha.  After using the app ourselves along with 20 or so beta testers, we've really gotten to know how our idea works in real life.  An idea and a finished product are basically two completely different things.  What you think your product will be, is actually not how it will ever feel once materialized.  Focuses shift, things are stripped out, and the core features are redefined and polished.  Every release is going to throw curveballs at you, you just have to be ready for it.  All the features and ideas you thought were table stakes might just be superfluous things that really don't make your app cool.

With FanPulse, we've found that, sure, there's about a hundred different things people would love in the app, but does that make them more likely to open up the app again?  Nope.  What do they like the most, what do they use the app for?  That's what we need to focus on.  If there's an outrageous amount of demand for a feature that's outside the scope of our core, even more so than what the awesome feature the app is centered around, maybe it's time to look at another product that has been unearthed by your previous idea.  Yes that could happen, but don't force it.

Tomorrow we're releasing a set of features that is a continuation of our efforts to polish and make our core functionality work even better.  I still regard the next release as an alpha, as it's still testing out our earliest ideas.  I'm not against saying that it's not perfect or ready for the public yet, because it will be soon, and releasing small and often will pay off big time.

If you're not in our releases yet, and want to get in on this next beta, send an email to beta@wethefan.com with your name and email.  If you have an iPhone and know how to get your UDID, send that too!  We'll get you in for tomorrow.

And if you're all wondering what the heck the picture is above, it is of a Porcelain Crab.  The Neopetrolisthes ohshimai is not actually a true crab, but a squat lobster evolved into what is more or less a crab looking thing.  I think this evolution is called carcinisation.  Basically shows how crabs might have evolved from lobsters due to environmental factors (hiding under rocks for example).

Anyways, these guys are cool!  They use their claws to fend off predators or in my case a few harmless snails and fish, but use what's called setae to catch food.  Setae are basically a pair of arms that stretch out from underneath them that have "nets" in them.  They catch particles (planktonic food) and shove them into their mouths:

 

20091203

I currently have a mated pair in my tank, they sort of just hang out together and grab stuff out of the water column.  I doubt I'd be able to keep any of their offspring successfully, but it's fun having them as a pair nevertheless.

Tagged  //   photography   porcelain crab   reef   startup-week-by-week   startups  
Posted December 4, 2009
// 0 Comments

Getting data in rails ready for the iPhone with Property Lists (.plist)

Took me awhile to finally figure out exactly what the Property Lists were all about, once it came together, putting together a nice property list was pretty easy.  The problem I'm solving is giving a fairly static list of teams to an iPhone app.  The iPhone parses out binary plist files the most efficiently, so here it is if you want to generate these plists from a rails app:

First get an array of all the objects you want to put into the property list and create an plist array

 

teams = Team.find(:all)

plist_array = Array.new

teams.each do |team|

plist_array << {:id => team.id, :name => team.display_name}

end

 

This creates a nice array with a few attributes we want to add.  If you want all attributes added to the plist_array, instead of adding in a hash just add in team.attributes, which returns a hash of all attributes.  What comes next is the use of the plist gem

$ sudo gem install plist

 

The above will install the plist gem onto your machine, make sure it's unpacked and/or avai lable on your production servers if you want this to be performed there as well.  Once you have the gem installed, require the gem in your controller and you can use the .to_plist to basically dump the plist_array into the accepted XML Property List format.

plist_array.to_plist

 

This of course does not give you a binary file yet.  For that, use the plutil that is usually installed on mac osx machines.  Mine just came with it.  If your machine doesn't have the util, it's part of the developer tools on your OSX install disks.

$ plutil -convert binary1 filename.plist

 

The option -convert basically takes one conversion parameter, either being binary1 or xml1.  binary1 converts the file, designated in the next parameter (in our case filename.plist), that contains the output of the to_plist.  The to_plist outputs the XML format of the Property List, and -convert binary1 will convert it to a nice binary representation.  You can go backwards with -convert xml1

$ plutil convert xml1 filename.plist

 

When it converts, it resaves the file, filename.plist for example.  Once you get that binary file, you can use it easily on the iPhone for retrieving the data.

For some more examples of how people are using the plist gem see this post to get you started: http://stackoverflow.com/questions/1264329/getting-active-records-to-display-as-a-plist

Tagged  //   code   iphone   property lists   ruby on rails  
Posted December 1, 2009
// 0 Comments

The Importance of Good Admin Pages

A good administration dashboard is key.  The whole reason behind an admin panel is to allow for human heuristic fine tuning of an app.  We need these either constantly or often, in order to maintain some aspect that just cannot be solved with computer magic (though many will argue that there is always a way, but the tradeoffs in some cases are not worth it).  Because of this, an aesthetically beautiful and equally easy to use admin interface is as important, if not more, than a user facing interface.  For computers, you want them to crank through really gross algorithms that would otherwise be impossible to maintain in your own brain.  For administrators, you want to make the experience of administering a site as pleasant and easy as humanly possible.

The big reason why people neglect and cut corners on admin facing pages is because "nobody ever sees it except us."  But isn't that the most important thing?  If you as employees only see the shittiest parts of your app all the time, or subject poor interns and new hires to this awful task, it just shows how little attention to detail you give to making your app hum like a well oiled engine.  When you develop any part of your code, always ask yourself if this is quality you are proud of, internal and external to your own company.  At some point horrible admin panels will just pile up, and there's no turning back.

If you start with a slick looking admin panel that works great and is easy to maintain when things change, then you will always have an awesomely tuned app with consistently great admin controls.  If you start with quite a grotesque arrangement of links and badly styled form fields, anything slicker than that just makes what you've built already look even uglier.  It's a bad snowball to be in.

It's easy to choose admin pages to cut corners on, because there's never an imminent need for them.  The time it saves is clearly good initially, but leads to plenty of cursing and swearing later on.  So what's the solution?  In some frameworks, such as Ruby on Rails, there are nice little things like Active Scaffold.  Unfortunately DHH and the rails maintainers aren't the world's best designers.  The usability, looks, and consistency are all pretty bad using the built in utilities.  At FanPulse, our current admin looks good, works great, is easy to maintain, and is even easier to expand on.  What we did is we used the somewhat popular web app theme utility for our rails based app called, "web-app-theme" by Pilu.  I guess it's not that clever of a name, but it works like it reads.

The tool is actually a ruby script that can be used with the script/generate command.  It basically sweetens up an existing active scaffold, or any model based controller.  It even creates all the files from scratch to you.  It comes prepackaged with a dozen nice themes that are super clean and easy to use.  It took me less than a day to create an expansive admin panel that can help us keep track of, modify, and add new teams, players, leagues, divisions, conferences, sports, beta users... you name it!  This will save us hundreds and hundreds of hours of work, and make administering the app just a tad less tedious.  Of course, if your app requires tons of administrative work constantly, there's some other decision that has gone wrong.  In our case, we need to do some fine tuning once to make sure all our data is totally perfect.  It's also great for adding new beta users and all that jazz.

The web-app-theme generator is geared towards being a good launch point for an entire web app, not just an admin panel.  I'm not that excited to take these designs and showing them to the world, but they look and feel great for administrative purposes.  So I've tapped into using it exclusively in an admin only side of our app.

They key to making it an admin only app, is to use elegant Rails Namespaces, which came about in the rails Changeset 6594.  This allows you to group controllers for specific models inside a namespace.  I chose the namespace called "admin".  This effectively gave me the ability to create a subdirectory in the app/controllers directory called "admin".  Then under there were all my individual controllers for individual models.  My routes.rb looked as so:

 

  map.namespace :admin do |admin|

    # The below resource mapping directs /admin/teams/* to Admin::TeamsController (app/controllers/admin/teams_controller.rb)

    admin.resources :teams

    admin.resources :players

    admin.resources :users

  end

 

The above snippet shows how I have a model controller for each model.  By doing this, you can maintain a super restful way to setup your controllers, using the usual index, show, edit, update, new, create, destroy actions with their respective get, put, and delete request methods.  Also maintains a great way to use named routes with: admin_teams_path to goto the index action of the teams controller under the admin namespace.  Another example is new_admin_team_path for going to the new controller.  One thing to note is for other mentions of controllers outside of this admin namespace, use a prepended slash to specify no namespace.  For example:

redirect_to :controller => '/session', :action => 'new'

The above takes you out of the admin namespace because of the prepended slash in front of session.  Otherwise it will try to hit you with admin/session controller, which probably doesn't exist.

Once you've installed the web-app-theme generator, and setup your routes, you can then create initial admin layout and styles:

$ ruby script/generate themed admin --theme="drastic-dark"

The generator is called "themed" and the parameter "admin" is what we want the layout to be named, in this case it will automatically create an "admin.html.erb" layout file for you.  The option "--theme" is where you designate what theme style you want to go with.  Pick from here: http://pilu.github.com/web-app-theme

Once that's done, create a view for your first model controller (controller can be created after):

$ ruby script/generate themed admin/teams --layout=admin --with_will_paginate

The above will generate all the views for you under app/views/admin/teams using the layout we generated before as well as scaffolding the views up with will_paginate automatically.  Good if you have more than like 50 entries.  Then create your controller using the usual ActiveScaffold, but give it a namespace as well as a "global" layout:

class Admin::TeamsController < ApplicationController

layout 'admin'

...

The controller should be created inside the app/controllers/admin directory.  Given your routes were setup with admin.resources :teams, it should all be setup.  Oh and one last thing, if you used the will_paginate option, make sure you change the controller finds to paginate.  And that's it!  Do the same for all the other models you want to administer.  If you want to do one offs from models, it's easy to just use the usual template to put whatever you want in there.  Takes minutes, looks consistent, and is much nicer to use and expand on.

Make your employees happy in your startup, make the interns feel like they are not doing really sad work in, but actually being part of a really polished startup company.  Having a solid admin in your app is a huge indication of how well you plan everything you work on, including planning, researching options, and finding the most elegant and robust solution available.  If you can learn to use these tools quickly, you will go far in the rest of your development, user facing or not.

NOTE: I didn't do any editing of this blog post, just wrote what was in my head (as I usually do), so please excuse my crap grammatical errors and horrible organization of it all.  I'm not here to publish a book, just write my thoughts down.

Tagged  //   code   ruby on rails   startups   web-app-theme  
Posted December 1, 2009
// 2 Comments

Week Three - Stay focused especially with a release

When his home tumbles

 

The Calcinus laevimanus (Zebra Dwarf Hermit crab) in my reef tank gets blown around quite a bit.  I have flow that amounts to about 7500 gallons per hour flow through the tank, so as soon as the hermits lose grip on a rock, they go flying.  This little guy tumbled quite far, but was able to get back up after a little rocking back and forth.  Determination and focus to survive is as simple as getting your house upright again.  Well, maybe simple for a hermit.

Week three of my startup company has been pretty exciting.  We met up with one of our board of advisors, who provided really good feedback and information.  It's always great to have people who really make the effort to share their knowledge and insight.  It's not like you rely on that for direction, but it's good to keep your head out of any echo chambers you might be in, and really listen to other experts out there to see how other people and groups think in the same industries.  That is one of the most important things to learn in a startup: how everyone else is thinking about the same problems.

The worst that could happen to a company is for all the founders to put their heads down, bury themselves in code and business details, talk amongst themselves, and in essence, persuade each other that what they are doing is exactly right.  Echo chamber.  Everything really comes down to the same way of thinking for startups: release fast, often.  This will get you the most feedback from real life people, and with what they say you can easily determine what to build next as a feature.  There's no need for you and your founders to be geniuses, knowing exactly how people will want the app to behave, knowing the perfect UI flows.  There's also no need for countless hours discussing how exactly the best way to present information is.  Just present it as best you see it, and let the people tell you.

And of course there's simplifying.  If you find yourself needing more resources and hires to build stuff, you are definitely NOT focused on the one goal.  If you need to branch out to maintain some completely separate product to give your core product some value, you have just created two startups.  Whenever you are faced with tons of features that aren't maintainable, you've probably gone too far.  Focusing on one strong goal, either it be 140 character status updates (or face it, 140 characters of bragging), or it be checking into sports games with your friends, will keep you from biting more than you can chew.

Our next release will not be a ton of more features that 1 to 5% of our users wanted to see, but it's going to be polishing up and making the core functionality that 100% of the users have used, even better.  Of course making it even better doesn't mean just making buttons shiny, or fixing a few bugs, but it can definitely include features that all go towards the same goal of making the core functionality that much more appealing.

It all comes down to a fine balance of not building non-core functionality features, and giving people enough things to be excited about for the next release.

This will be our next biggest challenge!  Utilizing user feedback to determine what's next on the list.  I'm not going to lie, we do already want to do about 100 different things, but we're going to try our best to keep it simple.

Thanks to all the feedback so far on FanPulse!  Those beta testing are really the ones behind exactly what this product will become.

Tagged  //   photography   reef   startup-week-by-week   startups  
Posted November 24, 2009
// 0 Comments

FanPulse Beta Released!

I'm excited to announce that the FanPulse Beta has been released for the iPhone!  We (Joe, Vish, and I) have been working night and day (when not playing foosball or basketball) and the app has now landed in a handful of handpicked users' phones / touches.  This first phase of introducing sports fans to a socially centric sports application includes many novel yet simple concepts that naturally align with how people think and talk about sports today.  We've really tapped into how people interact with friends or even strangers about sports, making their sports knowledge more powerful in an effortless way (for us technically and for the sports fan!).

Instead of reinventing how sports fans should consume sports, we've simply provided a nice tool for sports fans to increase their casual to hardcore sports knowledge, as well as improve interaction socially with friends over a technology medium.

If you'd like to learn more and be part of our next release, you should follow FanPulse on Twitter here for updates on how to signup! 

 

Tagged  //   fanpulse   startups  
Posted November 20, 2009
// 0 Comments

Week Two

Week two has felt like an eternity, and surely the amount of productivity is close to that.  I've never expected to have put together something so quickly and with such high quality before in my life!  The requirements for the upmost quality of code and timeliness is as extreme as you could imagine, since the one I have to answer to here is simply: me.  You are your harshest critic.

Week two went really smoothly, as I started hitting my stride in feature development balanced with all the other planning, management, and what nots of the product.  There has been awesome feedback so far from our advisors, and just bouncing the idea off people is easier and easier, meaning the problem we're solving, and the solution, are understandable and clear.  It's not completely perfected yet, but everything's pointing in the right direction.  The minimum viable product is stripped down pretty far, and definitely scary to release since it's not exactly what our grand vision is (far from it really).  The human tendency to try to completely bedazzle the audience with the first splash upfront is difficult to ignore.  We must see the value in quick and lightweight releases of the product, as long as each release provides a solid, unique, and easy to understand message each time.

People don't need your product right away, if they do then it has to be perfect right away.  Without even having people try it, there's no way to know what they want.  Instead the approach the company is taking is to give people something that's different, that begins to solve the fundamentals of the problems they have.  Once they commit to that one single idea we've released, they're hooked! Now they NEED new features.  And that's what we build =)

Aside from code, I decided to get out and take some pictures again this weekend.  This time I was pleasantly accompanied by my #1, and we did some exploring around Moss Beach / Fitzgerald Marine Reserve.

See all pictures here: http://www.flickr.com/photos/kinetic/

Teasers below:

sop

 

 

_DSC5078

 

 

messy hair

 

 

aliens have been here, seriously

 

 

putting in all the marbles

 

 

evening glow

Tagged  //   photography   startup-week-by-week   startups  
Posted November 15, 2009
// 0 Comments

Using TinyProxy with Rails

I have had quite the learning experience the last few days with a very unique situation.  For obvious reasons of concentrating on the core functionality of our app, we are using as many existing resources as possible, which basically means there's probably a startup that's sole purpose is to provide each individual piece of technology that we might need (other than the exact core functionality hopefully!).  The solution includes the use of Heroku as our backend web server to help scale and basically stay up, and a third party stats feed provider.  Stats as you know can be quite costly, and they restrict access to their feeds often by whitelisting your specific IP.

While we have a fairly static IP range with Heroku, we're also using Delayed Job as a worker in the backend that grabs live stats from our stats provider.  Unfortunately since we're running Delayed Job in the all powerful "cloud," the IP is ridiculously dynamic and has zero guarantee.  The only solution is to run a secured proxy from which the Delayed Job workers go through to maintain the static nature of an IP to be whitelisted.

In the future, Heroku's Morten says, Delayed Job workers will run through proxies to ensure IP's, but for now I had to setup my own on a separate VPS.  The real simple solution we have come up with is using TinyProxy running on Ubuntu Karmic on Slicehost that we use as our proxy to the stats server with all calls from our Delayed Job workers.  The code has been written easily enough for us to quickly switch out the proxy so that we can jump into Heroku's solution on moment's notice.  Reason for not just staying with our own proxy?  Just another process to maintain, monitor, and keep running (cost too for another VPS).

The setup for this entire process is quite simple once you get all the pieces in line.  Buy a VPS from Slicehost for example, and install Ubuntu.  From there install TinyProxy:

sudo apt-get install tinyproxy

That should also automatically start your default TinyProxy instance.  Check by listing the processes out, you will see a few:

 

root:~# ps -ef | grep tinyproxy

nobody    2826     1  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2827  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2828  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2829  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2830  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2831  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2832  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2833  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2834  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2835  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

nobody    2836  2826  0 03:18 ?        00:00:00 /usr/sbin/tinyproxy

 

Using the default values, you will see a number of tinyproxy processes running, the number here is the default for the number of tinyproxy's to run at a single time.  You can choose more or less depending on your needs, for now just run everything in default mode for testing.  The next step is setting up your Rails app to use the proxy.  Before that you have to allow your DelayedJob worker access using an IP, but we get into the problem of the DelayedJob IP being dynamic.  There are other options for authorizing use of the proxy, I'll let you choose that for yourself.  Read the docs for the config file for TinyProxy here.  OK enough, let's get on with it: fire up textmate or whatever your editor is and open your DelayedJob worker.

Our worker pulls a stats feed in XML using the (super fast) libxml-ruby plugin.  This is based off of the C libxml2 library, and is benchmarked as one of the fastest, at least as fast as other solutions like Nikogiri.  I would suggest either, but keep in mind that Nikogiri seems to be more modern but both are actively maintained and fast.  Avoid HPricot and REXML as their performance times are definitely not necessarily as fast in all situations.

We first get the XML feed by using the parxer: XML::Parser.file('path_to_feed').  The path_to_feed here is the URI to the stats provider, but there's no proxying going on here yet.  What we are using is the gem called rest_client made by Adam Wiggins of Heroku.  This is already installed on Heroku, so you won't need to worry about it (add it to your .gems manifest though just in case).  The most notable lines of code you will need are:

require 'rest_client'

RestClient.proxy = 'http://proxy.com:port'

RestClient.get = 'http://somefeed.com/feed.xml', :accept => 'text/xml'

First require the gem in your worker, then set the proxy.  The proxy is basically your slicehost IP, for example: http://204.123.123.123:8888.  After you can use the RestClient to get your feed (how restful!).  We have an extra header parameter to tell the server we're getting the feed from that we're accepting text/xml.  Our stats provider specifically requires us to tell them we can accept text/xml, otherwise they return the HTTP status code 406.  Other feed providers don't give a flying fart about what you accept, they give it anyway.  But best to be safe.  Now how do we get libxml-ruby to read this darn thing?  Easy, here it is:

 

RestClient.proxy = 'http://123.123.123.123:8888'

feed = 'http://livestats.com/get_feed/nba/boxscore.xml'

parser = XML::Parser.string(RestClient.get feed, :accept => 'text/xml')

doc = parser.parse

Of course the above is the watered down version of what we do, but you get the idea.  We make sure the proxy is already set, then get the feed with the text/xml accept header, then immediately parse.  If you want to see this in action, plug in all of the lines above into your console, and then tail your TinyProxy log file (tail -f /var/log/tinyproxy.log).  It will tell you who is connecting (the requester), and the request, then connect you, and close the connection.  We have a info message that says No Proxy for BLAH, where BLAH is the request server.  I'm thinking this is just that we don't have an explicit IP set for where this guy goes, but I haven't gotten that far yet, for now I just shrugged it off since it seems to be working =)

Anyway, enjoy playing around with RestClient, TinyProxy, libxml-ruby, and whatever else I mentioned.  It's all really cool stuff.

Big thanks to Morten at Heroku for awesome support and suggestions outside of Heroku!  Thanks to Matieu at Slicehost for giving me instantaneous support on our slice.  Superfeedr's Julien for his insight and suggestions in general on feeds.  And all the others who've helped steer me towards this solution.  Awesome to have such a great community that supports one another.

 

Posted November 9, 2009
// 0 Comments

Week One

The first week of being in my own startup has been quite exciting.  I have always imagined and thought about what it would be like, what I would do, and if it would be a whole lot of fun, or a whole lot of stress.  I thought it would either be really good, or really really bad, nothing in between.  Preparing for the worst by teaming up with talented people, Joe and Vishwas, along with making a lot of new connections with various companies and awesome people, has turned out to make this a stressfully exciting time.

I'm still trying to find my stride and my rhythm, or maybe there is none, and that's what makes starting your own company so intriguing.  The dynamic nature of it will always keep you on your toes.  The mentality of it all I'm quickly realizing, is to not get caught up and stressed about any little thing, and to constantly step back and look at the bigger picture.  As long as you don't get trapped into one little area of stress, it's good.  There are millions of line items to tackle, but if you just pause and breath, you'll realize it's not really that bad.

The people you surround yourself with while working is important too.  Vishwas is probably as awesome of a business guy / CEO you could possibly work with.  Joe goes without saying does nothing but help you stay on track, level headed, and on top of your foosball game.  We've done some cafe hopping, and camped out over at Dog Patch Labs on Pier 38 as well.  It's motivating being around your co-founders constantly, as well as others who are in similar positions as you.

Friday night, I started getting a little tired of just coding.  Given I get outside for a run and try to hit the gym daily, it just doesn't balance out entirely the other 10 - 12 hours of development I had done already that day.  I decided to take the day off (mostly) and just do some chores and take some photographs.  Keep sane so I can keep going full steam.  It's always better to work in solid productive blocks, then constantly but with little energy or motivation.

Today I jumped into the car and drove randomly into San Francisco.  I stopped by the Painted Ladies because everyone talks about it, and you always see those houses in the Full House t.v. show's intro.  These houses are about as boring as any house can be.  They're not that colorful, and there really isn't anything about them that's cool.  The park in front of it is awesome though.

Painted Ladies are boring!

Above you can see the Full House house, but the coolest part were just the people hanging out in the park.  There is a similar "let's just chill outside in the city" vibe like Dolores Park in the Mission, but minus the weed and homeless.  I found the scene absolutely peaceful and happy, so took the shot with people in front.  In the background of the photo, you can also spy a few people painting.  Boring!  Let's move on.

I walked around the park, noticed the majority of the people were young couples with their babies (dogs actually, no human babies in sight).  Some individuals as well watching their dogs play.

a family of three

 

topped

And then that was it, the park wasn't that big.  So I got in my car and drove through the Presidio, looked at the gigantic houses, and ended up on a random road that was curving me past the coast along the Pacific Ocean!  What the heck?  Suddenly I ended up at Baker Beach (notorious for the nude aspect of the patrons).  Avoiding the naked old fat people (there are no other naked people there, just fat and old, of course), I found a really intriguing sign.  It was backlit severely so I couldn't make it out until after I got back and processed the photo, I swear ;)

Not sure what this says, seems like an invitation...

Evidence above shows the sun almost setting right behind it, so there.  Past the sign, I mean in front of the sign, was quite the view.  Baker beach below to the south, the beautiful Pacific Ocean (and ridiculously large waves this time of year), and then the coastline topped off by the Golden Gate Bridge.  I was a little overwhelmed by what to take a picture of, but I ended up finding the old fencing to be the best subjects out there.

the keeper

 

line it up

And for those who must have color and sunlight:

pinched at baker beach

 

_DSC4789

The Golden Gate Bridge was definitely only about 1/10th as interesting as the fence poles =)  Here's a nice view of Baker Beach at sunset:

Baker Beach

And ok, here's a really boring black and white to the north of where i was standing.  Notice the fence posts below, that's where I was for the shots above:

No clouds, boring!

 

 

On yeah, and forgot to say, Halloween was a blast!  Had a party at the house, played foosball, wii, and just hung out.  It was great.  Even my Sea Urchin dressed up.  His costume was Reef Rubble:

_DSC4650

Tagged  //   photography   startup-week-by-week   startups  
Posted November 7, 2009
// 1 Comment

Mespilia Globulus: Algae eating beauty

The mespilia globulus, also known as the Tuxedo Pincushion Urchin, is amazing when viewing them close up.  I was lucky enough for mine to come right up to the glass for me to snap a few shots with my macro lens.  This is pretty close to a 1:1 magnification.  You can see some feelers coming out around his spines.  His blue stripes are totally uniform, it's insane.  Also an amazing Golden Ratio feat as well as the blue stripes are 3 to the spines 5.

 

Mespilia globulus: A moving, algae eating, beauty

Tagged  //   photography   reef  
Posted October 29, 2009
// 0 Comments

Assembling foosball tables are like putting together a startup company

Taking care of co-founders needs to be top priority for the success of the startup company.  First line item in our "office," is of course the Foosball Table.  Here's the first project we're working on, and given it's not a piece of code nor wireframe, it's good progress in the right direction.  It also teaches you a lot about a company and how it all gets started:

 

It all starts with the people, your users, your employees, your co-founders ...

_DSC4178

 

Then you gotta get some legs for what you're going to do.  Sure it might not be holding things up, but having them at all is a good first step.

_DSC4180

 

Fine tuning is always needed, but it's necessary (isn't this easier than setting up Passenger + Ruby enterprise edition, Joe?  Probably not)

_DSC4182

 

 

And then you're ready to go, kind of empty, but it's ready...

_DSC4186

 

 

Put it in context with where it fits, and it all makes sense!

_DSC4190bw

 

The next steps in this part of life are going to be big ones.  Never has responsibilities ever been so important, challenges so risky, nor potential so big.  You might lose a few, you might win a few, sometimes it's all luck, and sometimes it's pure determination.

Tagged  //   foosball   startups  
Posted October 28, 2009
// 1 Comment