A good night's sleep?

After moving to Australia, one thing I have noticed is most of my emails still tend to come through Boston time.

I still want the email, just not being told at 2am (noon Boston time). So, to counter this, I have added this cron job to my iMac:

    Ians-iMac:~ ianconnor$ crontab -l
    0 22 * * * /usr/bin/osascript -e "set Volume 0"

This will ensure that my volume is off every night at 10pm. I am hoping this will ensure my iMac doesn't wake me up at night with random noises.

Sorry I’m late. Traffic was awful!

The Mental Shift That Can Change Everything at Work, And Beyond

linkedin.com“Sorry I’m late. Traffic was awful!”How many of your meetings start with this lame excuse? You know it’s a cop-out, yet an irrepressible urge makes you take the easy way...

I know the article is more about control but regarding the traffic excuse, with google maps and live traffic feeds - even the traffic is really under your control (or at least predictable to a degree). When I hear the traffic excuse too often from the same person it means they just don't know how to schedule their time or don't care enough to leave a buffer. Too harsh?

Amazon for static websites

Although my experience with Amazon AWS has mostly been with 100+ EC2 VPC instances, elastic load balancers, and multi-zoned RDS extra large instances - it does not have to be such an expensive endeavor to get the scale and reliability of AWS.

I recently helped a friend increase his website's performance and reduce his cost of hosting. I helped switched him from a slow $100/year wordpress shared service to an approximately 60 cents per month Amazons S3 with Cloudfront solution.

He started with Wordpress because the intent was to be more dynamic however that was not the case (his updates were more than often in facebook than on the static web site). The site is mainly so he can show clients his awesome ski, snowboarding and fly fishing expertise in the Telluride area. Also, the shared Wordpress site was taking up to 11 seconds to deliver the HTML page (not cool for a website in 2013).

Amazon recently introduced the ability to serve static HTML directly from S3. The process involved dumping the Wordpress site to HTML/CSS/JS/images and then uploading it S3. We first tried a few plugins like really static (however because the Wordpress site was so slow - this was taking forever and some required extensions were not on the hosted server). So we used a much more crude approach (aka command line):

mkdir pancho
cd pancho
wget -k -K  -E -r -l 10 -p -N -F --restrict-file-names=windows -nH http://www.panchowinter.com

This then dumped all the html, images and supporting files to a 'pancho' folder and then we s3sync'ed them up to Amazon:

cd ..
s3sync -p -r pancho/ www.panchowinter.com:

(-r for recursive and -p to make them public).

To get cloudfront working, I created a distribution pointed to his site and then did a search and replace to serve any static content from the cloudfront distribution.

We set the s3 bucket www.panchowinter.com for static upload and index.html as the index document:

Then created a panchowinter.com bucket that forwarded to www.panchowinter.com:

We also moved the DNS to Route 53 and pointed alias record to the hosted S3 buckets:

and

The end result was page load times not in seconds (2.72):

But rather now in miliseconds (122):

Also thanks to cloudfront the supporting files are often less than 100ms. 

Technology while skiing

Top speed skiers can reach 200km/h regularly. However, after just reaching 91km/h it seemed fast enough for me. This was done on a freshly groomed double blue run. There is a groomed black run here, but the end of it merges with another run and levels off quickly (which makes me worry that the G force will push me too far into my skis and pop my bindings (aka loose a ski or two and thus be falling down the hill out of control).

However, it has been a good place to play with technology. Here is a quick summary of some of the electronic toys I have experimented with in Telluride, CO this season.

The above app tracks your motion, and records your speed, altitude and even factors in ski lifts. It will take photos but the last think you want to do is take out your smart phone on a cold windy or snowy day. I have a Contour HD external camera for that.

I also just played with the Recon HUD system. It gave me eye strain but the heads up display was neat. Unfortunately it only would pair with an iPhone 4S (not my 4) so I was not able to test out the smart phone integration. Because of this, and the fact that the ski tracks app in my iphone already tracked my runs, and that it would not fit right into my goggles - I ended up returning it.

I do have speakers in my helmet with a built in microphone. It is great for listening to music or an audio book - but with poor mountain reception and wind noise you can't have any serious phone calls.

Boston Startup Weekend

I just attended Boston's Startup Weekend and I had a great time. This was my first Startup Weekend and I had no idea what I was getting into. I talked with Darius Kazemi from Bocoup just to make sure it would be fun - that was my 'must be' criteria.

My first goal was to pick my team: I listened to the 80 or so pitches and was texting a friend and my wife to see what they thought. I heard a few cool ideas but wanted to pick something I had half a chance of coding in the weekend. I was deciding between an app that orders beers at a bar or a website that located film sites and movie stars (perfect for tourists and movie lovers). As I mentioned, the goal was to have fun and of course, explore cool ideas.

The bar idea was swimming in people - lots of them. They also wanted to work in Cambridge - I wanted to fight for Boston. The movie guys said they would move to Boston for me - so the deal was sealed (how could you say no to that?). We also had some good experience on the team, a UI/UX guy from Amazon and a product manager from a medical software company (that knew enough javascript to be dangerous). The business guys were great also. We had a hedge fund VP, private equity analyst, marketer and chip manufacturing manager. We also had Ollie (but the team didn't know that yet), my dog.

We then worked until midnight laying out the plans for Saturday. I tried to get the free domain promised by a sponsor and organized a power strip for everyone's computer (I just can't help being the IT guy).

Next day was an 8am start at Bocoup. We met for breakfast and then I offered the Pubget offices for a quieter work environment (10 teams working on crazy ideas is far from tranquil). Our team had some of the provided breakfast and we then moved to Pubget where Ollie greeted everyone in typical miniature schnauzer style - jumping out of his skin he was so glad to meet everyone.

The business guys starting talking about the pitch and three of us started the plan to build the app. I now know that an app is not needed for StartupWeekend, but I would go mental spending 54 hours building a PPT deck with nothing functional. I was also curious how much we could get done in the time allowed.

The technology plan was to only commit to a few very easy features and make them possible to demo. The original ask was for finding where movie stars will be, but that meant crawling blogs and unstructured sources. This was a non-starter for a weekend project - we needed to populate the database fast. So we agreed to just demo the historical part - where films had been shot across the USA.

After a little bit of searching we found three services that do this and allowed crawling in their robots.txt file. Then within a few hours, I had written the code and imported over 4,300 scenes with a large amount of duplications. While I did this, our newly appointed javascript guru (Anthony) was getting a google maps key and figuring out how to display map points on a page and link to imdb, street view and some other cool things we actually had to cut for the demo.

After getting the data loaded, I wrote a JSON API using Ruby on Rails 3.2 (the latest version). The API was designed to be used by the javascript which powered the maps display. I also added facebook and google login via omniauth.

The next feature was to write a photo uploading page to let people checkin and share their photo at the scene. I started to use paperclip but switched to carrier wave as it seemed easier to use S3.

I then needed moved the html static pages Anthony had been working on into views and showed him how to edit these and use github to commit and push. To support the collaborative development, I used circle-ci to run the tests on each commit and then deploy if the tests passed (continuous integration and deployment).

The app was deployed to two existing instances I have running on EC2 in different AZs (availability zones) running apache and passenger (old school I know, butI have not moved to unicorn on those machines). This is behind an ELB and the domain was registered and running in Route 53. The database was also in RDS. Did I mention we had an amazon employee on the team? I was already a fan, and couldn't resist using as much as I could from their stack.

I also hooked up google analytics and intercom.io just in case people started to use it and we wanted a CRM. After an 8am start and a midnight end, anything was possible.

The UI/UX was finished around 8pm on Saturday, while this backend was  still being developed. At that time we realized we really did not have the HTML/CSS/JS skills to implement the UI. However, we had so much functioning (facebook, photos, maps, street view, api, crawling, etc) it would be a pity not to demo that. The pitch was a strict 4 min - so we could not do everything. We decided to switch from static mockups and work on the live site instead.

We worked solidly through to midnight (visiting Bocoup across the street for dinner). We agreed to return to Pubget on Sunday at 8am. The pitch practice was at 11am so we didn't have much time. The final hours were spent on the checkin pages, street view and a simple login home page. We also created a static home page of what an iPhone app could look like. The site mostly works on the iPhone but we decided very early on coding an iOS app was in none of our skill sets.

I ran through the demo a few times as practice. I also noticed that the room had two screens so could handle two computers. We decided to use one screen for the deck and one for the demo. This would allow us to maximize the 4 minutes and not have to fuss about switching from PowerPoint to Chrome.

Having said that, none of this prepared me very well for the demo. The Google maps locked up half way through the demo while scrolling. I was not able to demo the photo upload and facebook features at all. I let the team down and felt horrible - I really feel for everyone that has a demo hiccup and there is no chance to recover. The timer was not stopping so we moved on to the business side of the talk.

I later googled this and found it happens when you scroll off the screen and the javascript does not know if you are still scrolling or not. The fix for this is to click outside of the map and then back in. However, when my screen resized down from retina display to video projector resolution I had nothing else on the page to click - so I was just stuck clicking around and nothing working. 

Despite the demo fail, the business side still managed to impress the judges with their research and quickly gained knowledge of the tourism industry. We placed 3rd! Ollie also appreciated the walk when some of the team hit the streets to interview tourists nearby at the Boston tea party museum. Ultimately, I had a really great time doing what I love to do, building software!

A big thanks to my hardworking team and of course the volunteers/organizers at the startup weekend. 

I'd highly recommend a Startup Weekend for anyone interesting in startups. It was definitely fun, fast and best of all - inspiring!

If you would like to see the app, click here to see ontheset.co.

Support a charity or local cause with your 'data exhaust'.

The NYT has an interesting article about a startup that is turning your 'data exhaust' into money that you can use for charity. The company is called Enliken - they collect anonymized web statistics on your behalf and let you decide where the money from this goes.

It is a really neat idea to allow users to decide what to do with and how to profit from their data.  Rather than fight the data collection (which is going to happen in some form or another), it seems much smarter to consciously allow it to be collected in a safe way and then direct the profits towards causes you feel are deserving.

If you would like to start earning money for a local cause or charity, check them out!

Qantas joke applied to bug reports

Far too often, I see bug reports or issues opened without enough information to solve the problem. It always reminds me of this old Qantas joke about pilot and engineer exchanges around problems with air craft. It always pays to think about bug reports from the reader as well as the author's point of view. When you are filling out the report, the bug seems as plain as day. You can see it right there in front of you and apart from pointing, you probably don't see the value in writing anything. However, the problem with this, is that the engineer is not sitting there with you and so will only have what you write to reproduce the problem.

• Pilots: Left inside main tire almost needs replacement.
  Engineers: Almost replaced left inside main tire.
• Pilots: Something loose in cockpit.
  Engineers: Something tightened in cockpit.
• Pilots: Dead bugs on windshield.
  Engineers: Live bugs on back-order.
• Pilots: Autopilot in altitude-hold mode produces a 200 feet per minute descent.
  Engineers: Cannot reproduce problem on ground.
• Pilots: Evidence of leak on right main landing gear.
  Engineers: Evidence removed.
• Pilots: Friction locks cause throttle levers to stick.
  Engineers: That's what they're for.
• Pilots: Suspected crack in windshield.
  Engineers: Suspect you're right.

In these exchanges, you can see how both the pilot and engineers are 100% correct but are clearly missing each other.
When you write a bug report, please take the time to see if you can give clear steps to reproduce the problem. If you can back out of the screen or page you are on, and see if you can follow the steps to see the problem (screenshots can really help here also), this is even better.
If an engineer has taken the time to write software, they want people to use it and hate if it has bugs. I really like users that want to complain - they are the best type of users because they care and want the software to work.
If you take this extra time to explain and show the steps to reproduce the problem, it really helps the engineer who gets assigned the problem. Also, if the bug cannot be reproduced, there is no way an engineer can fix the problem. At best, you will get a polite response that will sound a lot like one of these Qantas jokes.