LED Grow Lamp Update

22 June 2014

Some people have asked me how my Grow Lamp project worked out. To recap, it was a simple little board with a bunch of different coloured LEDs hooked up to a battery that would try to get a plant to grow without any sunlight.

To be quick, the project failed. The two main problems turned out to be:

  • Sunlight still overpowered the grow lamp. The plants ended up still being more sensitive to the sunlight (even in the not-so-well-lit room) so they would just reach towards the sunlight and more or less “ignore” the grow lamp.
  • Power consumption was too high. I was using a 9V battery to power the apparatus, and the batteries were dying out in usually a day or so. This is not a long-term sustainable solution since I’m not terribly interested in constantly buying and disposing of 9V batteries.

Both these problems are fixable. For the sunlight issue, I can attempt to grow the plants inside a dark closet (like where I brew wine). This will let me see exactly how the lamp is doing. For the issue with the power consumption, I can probably hook up some sort of power supply up to the main power to the house rather than relying on batteries.

The main reason why I haven’t really tried either at the moment is simply time – I haven’t really gotten around to doing either.

By Rob Britton

MongoDB and $exists Queries

12 March 2014

Since Mongo is a schema-less database, you’re not guaranteed to have the same field in all your documents. Often you’ll find yourself querying on a collection to only find documents containing that field:

db.myCollection.find({myField: {$exists: true}})

As it turns out, the $exists query does not use any indexes provided. If you’re working on a large dataset, this means that doing this type of query can take quite a long time.

One solution that we’ve found that works great and is much much faster is to use a sparse index on the field, and then query on a degenerate regex:

db.myCollection.ensureIndex({myField: 1}, {sparse: true})
db.myCollection.find({myField: /.*/})

Obviously this won’t work if myField is not a string, but there are definitely other ways to avoid the $exists query that does not use an index.

By Rob Britton

Why We Ditched Socket.IO

10 December 2013

Last summer when building SweetiQ, we had a need to use WebSockets for real-time communication with the client. The obvious choice was to use socket.io, which is the library that everybody uses since it simplifies a lot of WebSocket details, and allows it to work on browsers that don’t yet support it (this was more important a year ago than it is today, but meh).

I’m going to tell you why it was a bad choice.

Our first major issue is that when clients left the browser open for a long time, the socket.io connection would die. Not the end of the world, since socket.io has a reconnect capability. Unfortunately we had to do a bit of logic on socket reconnects, and the documented “reconnect_failed” event was never firing. I discovered this issue on Github which said that other people were having the same problem, so it wasn’t just me. I can’t remember where I saw the fix for it, but I posted a tiny code change on the issue so that other people are able to use the event properly. I can’t remember at this point whether there was a pull request or not, or whether I saw the fix on Stack Overflow; whatever the case is I didn’t make my own pull request.

People continued to have the same problem, and many people commented on the issue saying that the little fix I posted works. There are now three outstanding pull requests that supposedly fix the issue, yet none of them have been merged. It has now been over two years since this issue was opened, and the two line fix is still not in the core socket.io.

We started seeing some other issues: socket.io couldn’t get through firewalls, certain antivirus software would block the connection, etc. I’m not 100% certain what the issue was since the clients we had were on large corporate networks somewhere out there on the Internet.

One of my coworkers discovered SockJS, which is a library that provides a WebSocket-like system that uses the exact same interface as a native WebSocket (onopen, onclose, onmessage) and has a server-side supported in many different languages – which was handy, since we periodically have issues with Node.js and less-mature libraries than the other language we use daily (Python) so we had an option in the case we wanted to switch. Since we had no real idea on how to solve the corporate firewall problem, we ended up giving SockJS a go. The migration was pretty simple since the way you write code with SockJS and the way you write code with socket.io aren’t that different.

It worked beautifully. Every single one of our clients were able to use the WebSocket-based features without any problems at all, including those behind corporate firewalls. To this date we have not found a single bug with it, and it continues to work great a year into production without any updates.

I would recommend that if you’re using a web app that uses any sort of WebSocket functionality, I would recommend using SockJS. If you’re not using any sort of library then you’re even better off, as it is a drop-in replacement since everything works exactly the same as the normal WebSocket specification.

By Rob Britton

.NET and Startups

6 December 2013

I’ve been reading through the comments on this post that talks about how not many startups are using .NET and how the .NET conferences and meetups are largely older people.

A bit of a disclaimer before I get started: I worked with .NET for about 2 years. I used C# and VB.NET, later converting the VB.NET code to IronRuby because I was able to express complicated domain-specific logic (in this case it was stock trading logic) very easily using IronRuby in ways that were just not possible in VB.NET. As an outsider to the .NET world I was impressed that C# actually keeps up-to-date with modern programming techniques (type inference, async/await, anonymous delegates), unlike other C#-like languages that I’ve used in the past that seem to start thinking about adding them maybe 5-10 years after they’ve been mainstream in other languages.

So the question: why are the cool jobs not using .NET? Since “cool jobs” often is synonymous with “jobs at a startup or small company” I will use the two interchangeably.

My answer comes from this quote:

Why? I’d rather spend the time honing my skills in one area than learning languages I’m unlikely to ever use. Don’t want to be a ‘Jack of all trades, master of none’.

This is what I believe is the general mentality of the .NET world: the idea that what you are doing right now is unlikely to change quickly, so the best thing you can do is to master a single thing. In the enterprise world this is a virtue: your job is unlikely to go away, management is not likely to adopt a fancy new technology (how many places are still using COBOL?), and you have the budget to be able to hire specialists in the odd chance your project needs expertise that is not on hand.

On the other hand the startup/small business world that does the “cool things” is the complete opposite – the forces of natural selection are at work. Companies that embrace technologies that get you to market faster, that allow you to pivot faster, allow you to prototype-and-fail faster will be the ones that survive to become big. I don’t have valid evidence that languages like Node.js, Ruby, or Python satisfy any of these better than C# or VB.NET, but from my anecdotal experience this is certainly the case. This effect will feed on itself: .NET programmers either adapt to the startup environment, or they quit/fail and head back to the enterprise; we end up with a startup community full of people who either never did .NET, or people who came from it to “cool” technologies after seeing it fail them. Couple this with the fact that in the .NET world it is customary to pay for everything – imagine having to shell out cash every time you did an npm install – the .NET ecosystem just does not lend itself well to startups.

To answer the question, “why are the cool jobs not using .NET?” It may very well be that there are cool companies out there using .NET. Maybe they just aren’t surviving long enough for any of us to hear about them.

By Rob Britton

How To Get to the First Page of Hacker News

26 November 2013

Here are some strategies to getting to the first page of HN:

  • Talk about some government spy story.
  • Talk about how you had trouble getting into the United States.
  • Talk about how you hate MongoDB, Node.js, or Ruby (or X, where X is some language or technology that is not cool according to Hacker News).
  • Talk about how you love Go.
  • Talk about how you quit your job and launched a startup.

Here’s how you might get to the first page:

  • Post something genuinely interesting.

Here’s how to get downvoted immediately:

  • Talk about the pros of MongoDB, Node.js, or Ruby (or X, as defined above).
  • Talk about how you left your startup to get a salaried job with good benefits and sane working conditions.

By Rob Britton

See the index for more articles.