Continuing with 3-D Printing: The iPhone-based Colored Object Tracker

It stalks! It records video! My latest project is a lot more involved – I wanted to build a device that could track & record a colored object as it moved around.

Here’s a video of a prototype version:

As you can see, it’s a 3-D printed object that holds an iPhone in a sort of cage. The movable cage is connected to a servo, which turns the iPhone around as it tracks and records a colored object.

I have some applications in mind which require visual feedback. For example, I’d like to use it to follow and record an ice hockey player wearing a particular jersey/socks color combination. Because it’s constantly following the player, the video can be quite zoomed in, resulting in the player appearing quite large and clear in the video. This will be very helpful for training and feedback purposes.

I suppose it can be helpful in any situation where visual feedback is helpful, and the person is moving around, such as in ballroom dancing, etc.

Experiments in 3D printing: Bathtub Shelf

I first started designing objects for 3D printing using the open-source design software, Blender. However, I found it quite tedious. Blender was designed for a very different purpose: it was designed to model objects in 3D for rendering and animation. Designing a 3D object that is printable is a whole other story. And so with Blender it took me a long time to make 3D models that could be printed.

On the other hand, if a software were designed explicitly to make objects for 3D printing, then it could be much better. It could leave out the hundreds of features that are not needed for 3D printing (shading, lighting, physics effects, etc). And it could only allow operations that resulted in objects that could be 3D printed, making it idiot proof.

I was thrilled to find that such a software existed. And even better, it’s free and runs entirely in a web browser. Cloud-based, yeah! It’s called TinkerCad. It’s super easy to use and optimized for 3D printing. It took me just a couple of hours to custom design a shelf for my bathtub. And Shapeways readily accepted the design and printed it, and in a couple of weeks I got the shelf. Check it out!

3D printed bathtub shelf

Here’s my design file on TinkerCad, and here’s the design on Shapeways for printing. It’s pretty cool to compare the picture above with the design as you can see below:

 

3D model of shelf

 

What I liked about creating this design is that it’s quite complex with all the holes and angles, but yet it was very easy to do with TinkerCad. It would have taken me days with Blender.

I’m now working on an even more complex design with moving parts and round shapes. Let’s see if it prints well. I should be getting it in a few weeks, very excited! Here’s a preview.

Bedside box

Introducing SirraTeam.com

Since we at QuickSchools take remote working so seriously, I decided to create an app to help us track the hours logged by our contributors and to easily pay them via PayPal.

The result of that is SirraTeam.com.

Here’s what SirraTeam offers that I was specifically looking for:

  • It’s Free! The other solutions like PayMo charge by user. Since we have more than 30 contributors, that can add up. SirraTeam is free while in beta (which will be for a while) and after beta we plan to keep prices much lower than the competition.
  • Ultra-simple time tracking. I don’t want too many features that our contributors might get lost in. I just want simple time tracking.
  • Integration with PayPal for quick payments. This was the biggest thing. It’s our philosophy to pay our contributors frequently, sometimes as often as weekly. And with 30 contributors that got really time consuming, fast. SirraTeam is fully integrated with PayPal, so I can just click “Pay” and the PayPal payment is created.
  • Delegate payments. I can delegate the responsibility of paying specific users to managers. This is important as we scale up the team.

Lastly, I think it’s worth mentioning that SirraTeam.com works from the point of view of your organization/company: You create an account, you invite your contributors to log in, and they track hours with you. And then you pay them. Many other solutions are a little different in that they take the view of the freelancer – they log hours and invoice you.

SirraTeam.com is open to everyone. Check it out and let me know what you think. You can email me at aris at sirrateam.com if you have any questions or comments.

Having trouble working remotely?

Working remotely is getting better and smoother every day with the improvement in collaboration tools that are available. We continually try to push the boundaries of working remotely at my company QuickSchools. We have over 25 employees working remotely all over the US, with only 3 that work in our “central office” in Sunnyvale, CA.

Here are two simple tips that we’ve discovered that make working remotely much smoother.

Use Google Hangout video chat

Many of us use gmail and have gmail always open in our browser. The ability to reach someone in an instant by clicking on the video call button is so powerful. Now, I’m sure some of you are thinking, “I don’t want to be on video chat when I’m in my pyjamas!” Well, sure, that won’t be the best thing, but then I think keeping a decent appearance shouldn’t be necessary only when going into the office. Working remotely shouldn’t be an excuse to be a slob, methinks.

It’s just that human beings give off so many non-language cues that it’s imperative you use video to communicate at least some of the time. It’s too easy to get frustrated waiting for a chat response for example. But with video, you can see when someone is just paused to think, or when someone didn’t get what you said.

The beauty of Google Hangout is that screen sharing is built-in. That’s powerful.

It’s funny, we like Google Hangout so much that even when we have two or more people in the same meeting room in a multi-location meeting, those two or more people each have their own Google Hangout session running. All but one will mute their microphones and speakers to prevent audio crosstalk, but wow it works well.

Work off a “Discussion” Google Doc

We create a Google Doc that serves as a discussion doc every time we meet. New updates are put on the top, not at the bottom so that new updates are always visible when someone opens the doc. Also, don’t keep creating a new Google Doc every so often. Keep using the same Google Doc, even if it gets long. Don’t worry, Google can handle it. This makes it easy to scroll down to see older entries, and also allows you to use Ctrl-F to find old information.

Date every meeting. In fact, you can even put entries in advance of meeting. Suppose you are meeting in two days, and there’s something you want to bring up. Make an entry for that future date (on the top of course):

Wednesday, June 12, 2013

[Aris] Do we want to include the latest blog entries on our home page?

What you’ll find is that people will see that entry before the meeting date, without you having to explicitly email them, because they too are going in to put entries in advance. This means they’ll have a chance to start thinking about those topics. Even more awesome, they’ll start putting in their thoughts in the doc even before the meeting date! Issues get resolved without spending even a minute meeting on it.

Those are the two most important discoveries we’ve made. Please let me know how well these techniques work for you if you try them.

Couldn’t quite find the perfect java-based web stack

As I mentioned in this article, I wanted to find a nice lightweight java back-end that would:

  • Allow me to write a REST api on the java-side using as much of POJO as possible.
  • Be able to serve static HTML, CSS and JS files easily.
  • Be able to combine individual HTML, CSS and JS into a single file and serve them using unique MD5 file names so caching wouldn’t be an issue (this I didn’t mention in the earlier article).

At first I thought Apache Tapestry would do the job but now after deploying two apps I’ve decided against it. It mucks around too much with the front-end. You HAVE to serve static content under a specific folder, and you have no control over that. Yuck. It also forces you to put a bunch of their javascript on your html like Prototype.js. No, I don’t want that.

In the end I just built a framework using Jetty and Servlet 3.0. Of course, I made it do exactly what I want, but I feel my requirements are pretty common for today’s apps. I hope I can open-source it and put it on GitHub (and put it on the Maven repository as well). But that would require a bit of work so we’ll see!

Extreme HR

Over the next few weeks I’m going to write more about how we hire and how we structure HR at QuickSchools. But first and foremost, I need to give it a name. It needs a label. That would make it easier to talk about and identify.

I thought about the phrase “Extreme HR”. Not sure if that’s the best name for it or not. I guess it is a bit extreme. Some parts of it are reasonably common these days – 100% virtual arrangements, results-oriented work environment and hourly compensations for example. But I think some parts of it are pretty damn extreme. Resume-blind hiring, for example. I get some pretty strange looks when I tell people I don’t look at resumes when deciding between candidates. Or offering 5 people the same job so I can do an apples-to-apples comparison. Yup, that gets a fair amount of debate.

But we’ve done this “Extreme HR” so many times that it feels totally natural at this time. And totally logical given recent trends in work structure. And of course the kicker – it totally works and takes so little time to find great people.

Well, I guess we’ll call it Extreme HR for now, till we come up with a better name!

My favorite web-app stack for medium-sized applications

I have an ongoing goal of creating many subscription web applications in 40 hours. If 500 Startups’ goal is to fund many startups with micro funding, my goal is to create many small startups with little time.

I try to meet these criteria when creating those web applications:

  • It should reside on as much free infrastructure as possible.
  • It should be ready to scale in case it takes off.
  • It should be revenue generating from day 1.
  • It should be designed to support thousands of simultaneous users.
  • It should require minimum maintenance from me. Once it’s live, it should keep on going.

I have a very strong opinion on the stack. Here’s what I’d go for:

Heroku for the cloud server infrastructure

Absolutely Heroku. I wouldn’t go with anything else right now. It’s a joy to use once you figure it out. It has a free tier which is very performant for websites that are not busy yet. It can be scaled with one command. It has easy-add add-ons like memcache when you need to scale. It uses Git for deployments. It monitors the app and brings up a new one if any instances crash.

Postgres on Heroku

No matter how awesome NoSQL is, I still need the ability to query and sort structured data. I try to use a combination of NoSQL (to store large data) and Postgres (only for light data that needs sorting and querying).

Postgres on Heroku is absolutely the way to go. It’s managed so I don’t have to do upgrades, maintenance etc. It has a bunch of common utilities like making snapshots and backups, cloning, etc. I don’t have to worry about underlying physical hardware. Win.

And I have lots of experience with Postgres and I know it can handle millions of rows with no problems.

Beware of using one-schema-per-customer though. That is Postgres’ Achilles heel. It dies under the weight of hundreds of schemas. Backups and restores take 10 hours or more. Even Heroku says don’t do it!

Amazon DynamoDB

For the NoSQL layer, I like DynamoDB. It is very fast both from my local machine as well as from Heroku (Heroku uses Amazon US East – Virginia fyi). I trust Amazon’s cloud infra. They use it internally and since it powers Amazon surely it can power my little app.

HTML5 + JavaScript single page app

I like creating a single-page app. You completely remove all the headache of passing data back and forth between pages.

Yes you do have to deal with some History/back/forward button issues but only once. You also have to deal with dynamically loading resources if your app gets big. But after that it’s single-page nirvana.

It’s wonderful to be able to code all your front-end stuff purely in JavaScript.

Build server-side services as REST API and use them via your front-end

It is no more difficult to build your server-side services as REST APIs. You may as well do so. This way you can easily open up the API in the future. Plus it makes a lot of sense.

Server-side language: Java

This is not a hard decision for my personal projects since I’m very comfortable with Java. However, I can see that NodeJS is attractive because it’s easier to hire JavaScript developers than Java developers.

App Server: Tapestry

This is not the most ideal app server. I was actually looking for something far more lightweight than Tapestry. For some reason I thought Tapestry was that light-weight solution. But it’s definitely doable for me. Key features: It uses Java. It has nice injection framework. It’s use of Maven and the Maven Repository is wonderful. Adding new modules is so easy.

Maven

Maven as a build tool is great, especially with Tapestry. Heroku for Java kinda needs it too. I just really like how easy it is to add new modules and then deploy to Heroku.

GitHub

I especially like how I can push to GitHub to commit and then push to Heroku to deploy.

Conclusion

I really, really like the above web app stack. Cost effective, time effective, and ready to scale.

Tracking server configuration files with GitHub

I’m really digging Git and GitHub. It’s simple to set up, and GitHub provides a great hosted service.

So I wondered if it would be possible to commit configuration files from production and development servers onto GitHub. This way, we’d never get confused over changes, and if any of the servers were to die on us, we’d have the configuration files safe and sound. And if it were to work the way I thought it could, it would be as simple as adding any file, anywhere on the server, and committing it.

Alas, after a quick search on the web, the message I got was this: Git isn’t designed to track server configuration filles, and I should use one of the specialized configuration management tools out there. Git isn’t appropriate because:

  • It tracks all the contents in a working directory. It’s not great at cherry picking files from around the file system.
  • When you do a pull, you have to pull all the contents at once.

But darn it, I don’t want to have to install and learn a configuration management tool. And I couldn’t find any hosted solutions that was dead simple to use.


It took me a few days but finally the solution dawned on me. And, like most solutions that emerge only after your subconscious has a go at it, it IS dead simple. And yes, I can use Git. Score.

The idea is to create a central location where all your configuration files can be copied to, complete with directory structure. You then manage that central location as a normal git repository. The key is a script which will copy any configuration file to the git repo.

Here are the steps.

1. Create an empty repo on GitHub

I find it’s always easiest to create an empty repo on GitHub, and then to clone that.

2. Pull the empty repo to your server

You can do this on all your servers.

git clone {your github repo URL}

3. Create the script file, track.sh

I’m using linux, so modify as appropriate.

mkdir -p /home/maestro/{your git repo name}/`hostname``pwd`/
cp $1 /home/maestro/{your git repo name}/`hostname``pwd`/$1

This script file will copy whatever file you want to track to the git repo directory. It will insert the hostname so that all the files are separated by server.

4. Start tracking files!

To track a file, you first change to the directory of interest and then you run the script on the target file.

For example, let’s say I want to track my PostgresDB configuration file.

cd /var/lib/pgsql/data
track.sh postgresql.conf

Voila! Now the configuration file is in the git repo, and you can commit and push that as normal.

Tracking server configuration files via GitHub makes me happy.