Author Archives: Tony

The Dalai Lama, when asked what surprised him most about humanity, answered:

“Man…. Because he sacrifices his health in order to make money.

Then he sacrifices money to recuperate his health.

And then he is so anxious about the future that he does not enjoy the present.

The result being that he does not live in the present or the future;  he lives as if he is never going to die, and then dies having never really lived.”

I had been wearing a demo Apple Watch Sport for a few days, when I noticed a few scratches on the screen. Damn, I thought. It had only been a few days and I hadn’t bumped or scraped it on anything significant. In addition, I had been cleaning it with a microfiber cloth, so I was sure it hadn’t been from that. But it was still odd considering how long I’ve had an iPhone 6 with no cover and 0 scratches. So I did a little digging.

Sure enough there are a few threads on Apple’s own website detailing how common, everyday usage is resulting in scratches. Disappointing, but maybe people are simply being careless. However, for some non-transparent reason Apple has also quietly updated their product text removing all mention of being scratch resistant. 

Rolling back 2 weeks on Apple’s own product page for the watch, we see the following text. Notice the phrase, “especially resistant to scratches and impact.

Screen Shot 2015-09-27 at 6.41.28 AM

But if you look at the current version of the product page, you’ll see this text.

Screen Shot 2015-09-27 at 6.39.12 AM

Apple removed front page, product messaging referencing its watch being scratch proof.

nginx

I recently need to set up caching for a very slow API service I was working with.  However the app I was working with forced a query param of “timestamp” on all requests.  This effectively killed the cache because all api requests were flowing through a single endpoint, and only the query params differentiated the requests.  So here’s how to set up caching and strip out query params with nginx.

Originally posed to Instructables

Picture of Fiber Optic Star Ceiling Panel with Day Time Stars

I wanted to create a star ceiling, but since we are currently renting, I didn’t want to drill into the actual ceiling. So here’s how to create a portable star ceiling you can take with you. The total cost of this project is around USD $100

Step 1: Purchase fiber optic driver and cable

Picture of Purchase fiber optic driver and cable
0.jpg

I purchased this 150 light set off of ebay for around $60. This one came with a remote control and 16 colors to choose from. In addition, it’s low profile driver will be perfect to fit in the frame.

Step 2: Purchase a poster board

Picture of Purchase a poster board

I wanted something that was going to be sturdy enough to drill holes through, hold all the cables behind it, and look stylish. I came across this at Target for around $25.

Step 3: Remove the cardboard poster backing

Picture of Remove the cardboard poster backing

I removed the plastic cover from the poster to leave just the cardboard frame.

Step 4: Paint it black

Picture of Paint it black

Next I grabbed some MATTE black spray paint and gave a good solid coating over the back of the poster board

Step 5: (Optional) Day time stars

Picture of (Optional) Day time stars

I didn’t want my star ceiling to look like a solid black tile during the daytime, so using some white GLOSS spray paint I added some daytime stars. To do this, simply press down very gently on the top nozzle of the spray paint, till it sputters. It should look like it spitting. Then quickly aim it at your black background. It should only take a few spits to create the desired look

Step 6: Place the backboard in the frame

Picture of Place the backboard in the frame

Step 7: Drill holes for starfeild

Picture of Drill holes for starfeild

I highly recommend you drill holes where the daytime stars appear. This is because they will already have a very nice distribution across the entire surface of the board. I tried to make my own pattern instead and in looks very contrived instead of natural looking.

Step 8: Light shining through

Picture of Light shining through

Make sure all of your holes are clean and you patch up any unsightly looking spots on the front.

Step 9: Set your fiber optic driver foundation

Picture of Set your fiber optic driver foundation
IMG_9345.JPG

Place your fiber optic driver in a place off to the side of the frame. Then secure with zip ties.

Step 10: Place fiber optic lights through pre-drilled holes

Picture of Place fiber optic lights through pre-drilled holes
IMG_9349.JPG

Grabbing groups of lights at a time, start running the cables through your holes. You’ll want to keep these group somewhat organized, so I used more zip-ties. The group simply helps you lay the cables flat as you prepare to mount to ceiling. Don’t worry about the cables peaking through the front, we’ll trim those back later.

Step 11: Glue it good

Picture of Glue it good

Once you’ve got all of your cables placed in the holes, you can start gluing to keep them in place. I used Elmers Clear Glue liberally on every singly hole.

Step 12: Allow 12 hours for glue to dry

Picture of Allow 12 hours for glue to dry

Step 13: Trim back the ends

Picture of Trim back the ends
IMG_9362.JPG

After the glue has dried, you’ll have a lot of cables sticking through the front. I used fingernail clippers to trim these flush with the board.

Step 14: Mount it

Picture of Mount it
IMG_9378.JPG

That’s pretty much it for building the star panel. Now you can mount the panel in way you light and enjoy your new star field!

I’ve been learning a lot of Reactive Extensions (Rx) lately, and in the spirit of learning I decided to share some 984368initial thoughts on the concepts and give a very light overview.  Rx is very deep, but hopefully this article gives you an initial understanding and examples to solidify the knowledge.

If you haven’t heard of Rx before, I highly recommend reading Erik Meijer’s blog post in which he describes an alternate way of thinking about events.  In short, he describes events (mouse clicks, keyboard events) as a stream of data.  Think of an array where you have a list of items but with the added element of time in between each item.  For example, as your mouse moves it creates a stream of coordinates. (The dots represent time passing)

mouseMoves = [….{x: 45, y: 45}…….{x: 45, y: 50}…..{x: 50, y: 50}…]

See, mouseMoves is just an array with time between the items.  This is what is known as an Observable.

Once we have an observable, we can do all kinds of things to the stream of data.  We can filter it for certain items, we can map over each data item and transform it to something else, we can merge it with another Observable to create a new data stream.   The documentation for the javascript implementation, gives you just a taste of what you can do.

A Practical Example – Mouse Moves

Let’s say that we want to add a listener to our page that detects whenever the mouse hovers over an image tag.  In addition, while we want to know whenever the mouse is hovering over the image, we also want to throttle the number events actually occurring.  The following Rx code accomplishes this in just a few lines of code.

Let’s take this line by line to see just what is happening.

After querying the page for a list of image tags, we create two new Observables by attaching them to the images DOM list.  These observables are now listening to all mouseover and mouseout events.

Now that we are listening to events, we want to filter these events to only return every 300ms (as opposed to very fast which it would do right now) and only while we are still hovered over an image.  Here’s how this code works. We loop over the list of mouseover events streaming in using ‘map’. For each event we occur, we create a new Observable that is delayed by 300ms.  And lastly, we filter that nested observable with the ‘takeUntil‘ operator so that we only return a valid event if the mouse has not left the image.  At this point, the event is then returned to the outer ‘map‘ result for the final operator, ‘switchLatest.’ Switch latest takes in a stream of events and returns only the most recent event. This operator is especially useful for ajax calls, where you may have made a few requests, but only care about the data from the most recent request made.  Likewise, this returns the most recent mouseover event that was valid.

Now that we’ve created our observable with its propers filers, we simply ‘forEach‘ or ‘subscribe’ over the stream as if it were an array.

That’s it!  We can now listen for mouseover events on images like an array.

This is just scratching the surface of Rx and we haven’t even touched on how Observables automatically unsubscribe themselves from events or handle errors.  If you’d like to learn and play more with observables, I highly recommend giving Jafar Husain’s interactive tutorial a try.

I’ve participated in a lot of hackathons over the last few years and luckily even won a few. (TechCrunch twice, Facebook, Angelhack) Hackathons are a great way to try out a new idea and get immediate feedback from the community.  They’re social, challenging and always a blast.

But sometimes they can be extremely frustrating due to poor planning, crunched time and various other factors. Here are few lesson’s I’ve learned the hard way, but I write this in hopes of saving you some pain.  Here’s what TO DO, if you really want to “kill it” at your next hackathon.

Show Up With An Idea

I can’t even begin to tell you what a bad choice it is to show up with no idea of what you’ll be working on.  I’m going to be stressing this fact, on every bullet point, so here the first time.  Your time is extremely limited. You don’t have time to wander around trying to come up with an idea of what to build.  You should come prepared with at least a vague idea or two, of what you’ll be working on.  Now, I’m not saying you have to have it completely planned and mocked out, but come with a plan.

Also make sure that the problem you are trying to solve is actually a problem.  Ask a few friends if they would use it.  If you can’t find any takers, chances are the judges won’t either.

Sell The Idea, Not The Code

At the end of the day, you’re presenting an idea to the audience and your job is to sell it.  The code doesn’t have to be pretty or work flawlessly.  In fact, no one will most likely ever look at it again.  Focus on what problem your trying to solve and gear all of your effort towards demoing that. Visually.  Sell the crowd and judges on what makes your concept, not your code, amazing and disruptive.

The truest code ever written at a hackathon. Not pretty, but it will work.

Stick To What You Know

A lot of people use a hackathon as a time to try out a new frameworks and even programming languages.  If you goal is to learn, have at it. If you want any possibility of winning, stick to what you know.  Your time is limited and you can’t afford to spend 5 hours learning how to use a new 3rd party API, a new language, or anything else new.

Prepare For Bad WiFi

The wifi will be slow so prepare to work and demo locally.  This gives you the huge advantage of faster iteration cycles during development and a demo which is fast and smooth.  Why hinge your entire project on an uncontrollable external factor?

Deliver A Great Demo

Remember the demo is the ONLY thing any one sees at the end of the day.  Make sure the demo is clear and gets your idea across.  In addition, practice your presentation over and over, making sure you articulate the problem and how your project solves that problem.

With these time saving tips in mind, I wish you all the best in your hackathon endeavors and hope you have a blast at your next hackathon.