Thursday, August 6, 2015

Thoughts on working and "working" on company time

It's been a while since I've done a blog post. A lot has changed since then: I've graduated from a university, moved, and started a job. A coworker asked me to type up my thoughts on working on things that aren't exactly work related to enhance your skills, the assertion being that any new skills could benefit the company in the long run. My first thought was "Hey, blog post!" and such this post was born/forged/hastily thrown together.

I've always been a fairly laid back developer in some regards and very much not in others. That's not a very descriptive way of putting it, so let me explain. I will take my shoes off, try to relax and write some code. I'll walk around and talk to other developers, maybe even playing a game of Go or helping with a jigsaw puzzle or two. I feel that environment helps foster creativity which is good for developers. Creating software is as much an art as it is a science. I like to compare it to writing an essay, in that an essay can be beautiful if it's well written. The problem comes when the most beautiful or "elegant" solution isn't the easiest to read. It may be the most concise which many developers have made the mistake of assuming is always the best. When we read a well worded essay, we skip over the part of deciding if it makes sense and immediately are able to see its effectiveness. The same happens when we design software. If code is well written, we can discuss high level concepts without looking at the gritty details. This is where I'm not laid back. I believe in continued refactoring and improvement. If a feature you're trying to implement doesn't fit perfectly, make room for it by first refactoring enough to create a nice place for it. If you're not sure exactly how the feature will work, you can always start with pure TDD, creating tests for it until it exists by itself or you understand exactly how you want to interface with this new object/feature.

I start with that long intro because I feel the background is necessary to show exactly why I feel the way I do. I believe that working on things that aren't strictly work related can be detrimental or beneficial,but it depends on both scope and attitude. Scope is referring to how closely related to your job it is. Writing doom to work on some piece of hardware may be beneficial if this piece of hardware is something your company makes that you need to support. You might learn a lot about the system that you would have never known beforehand that could be beneficial later. It would be like if you had been using a while(True) loop with a break statement based on some variable, but later found out there was this magical thing called a for loop. Your code would be cleaner because you decided to dig a little deeper into an area you were unfamiliar.

The same thing can happen if you want to learn a new language. You might learn a new language or framework (I'm currently loving the Haskell language and the Laravel php framework) which is beneficial to your way of thinking. Haskell has been useful for me because it allows me to see things as small modular and composable functions that can each be verified individually before being verified as a whole. Laravel has given me a new perspective on IOC and Dependency Injection that I would not have seen before. (Shout out to Laracasts for posting videos about testing and SOLID)

It's fairly easy to see if your scope matches with your company and your own objectives. Try and measure it from a scale of 1 to 10. If it's a 10, then it's highly cohesive and is a very good quick side project for you to experiment with. A 1 would be a project that's going to take way too long for it to be useful and has very little to do with what you're working with or plan to be working with.

The last aspect of this is attitude. Your attitude, or the reason for trying to do a project is a very good metric to decide on whether you should do it. If it's because you have a few spare minutes at work and you want to write a C compiler in Javascript (And by minutes I mean months) just because that's a thing that should exist (And I'm fairly certain does), then it's probably a waste of time.

Also, I am not responsible for you getting fired. Always talk to your boss first.

Thursday, December 25, 2014

BotQueue client updates!

It's been only a couple of months since the last software release, but it feels like it has been far too long. Instead of releasing 0.6, I'm releasing 0.5.1 today. There are two reasons for this, which I'll get to in a minute. But first, features!

Makerbot support

Or at least, mostly Makerbot support. It supports all of the printers that speak s3g/x3g, so no 5th generation (yet). There is also way to slice things. I have a solution for that, it's just somewhat difficult to work with closed source software. For now, you can upload your *3g files and it will run them just fine. It also allows you to upload .makerbot files, but those aren't supported yet.

Automatic updates

This is something I've wanted to do for a long time, and is the first reason why this only jumped up to 0.5.1. I released version 0.5.0, and in the very next commit, released 0.5.1. This was to test the auto update feature. Every 2 minutes, if your bots are either in idle, error, or offline mode, the client will check to see if there's another version. If there is, then it will automatically update itself.

This means that installing the client is now as simple as "pip install bqclient". To run it, simply run "bumblebee" in your command line. No more "python -m bumblebee" or similar schemes. Also, make sure you run it in the same directory that your config.json is the first time. It will automatically detect it, and move it to the correct directory. If it's not there, it assumes this is a new install, and will start to authenticate.

Future plans

Those aren't the only updates at all, but it's the two major points in this release. Many more features are coming soon, but I was having an issue. I needed to know that the client code and server code would work together. The easiest way to do that was make sure the clients take care of updating themselves. The caveat to that is that it might upgrade and break. If it breaks before the point it upgrades, then it will have to be upgraded manually. It also means that all clients would break at the same time, something I'm not exactly happy about.

Nevertheless, this helps with future plans, and moving to the 0.6 release, which will definitely contain some exciting new features. I hope to release much more often. I've been keeping the server within a few commits of the current master branch. There are some changes I can do that would break clients, unless they are up to date. I'd like to get some feedback, but I think I'm going to set a day in the future (some time next year) where the server will reject clients below a certain version. This allows me to make sure that add the cool new features that people want, without constantly asking that you update the clients.

Thank you for using BotQueue!

Friday, October 24, 2014

FTDI: The Clone Wars

I saw an article on Hackaday that talked about an FTDI driver update on windows that purposefully set the PID of the device to 0 on fake or 'cloned' FTDI chips. I've also seen a bit of confusion on this topic, so I'd like to clarify a few points.

First, what is FTDI? Basically, this company makes products that allow micro-controllers to communicate to a USB host, like your computer. The make both drivers, hardware, and most importantly here, chips.

1) Many people aren't aware if they even have a fake

One of the first arguments that I saw was in regards to how users should be punished for using a fake chip. Most of the people using these products are using end products, or products that are made using these chips. It's much easier for someone to include an FTDI chip with their device than to go through all of the trouble and cost of getting their own Vendor and Product ID. So, some devices have these chips in them without their users ever really knowing. This means that if the vendor accidentally or intentionally used a fake chip, then some end consumer could have a device break and have absolutely no idea why. It would literally just stop connecting to the computer.

2) This isn't a user mistake

The second most common argument that I'm seeing is asking why on earth any user would expect FTDI firmware to work on a non-FTDI chip. One person compared it to trying to sue Sony when your Sony TV knockoff stopped working. A user didn't re-flash their chip and mess up by getting the wrong firmware version, or putting it on a device it was never intended to. In fact, what updated silently and without warning was the FTDI driver on the host side. The FTDI driver itself checked if the chip connected to it was fake, and if so, it rendered it useless by changing the Product ID to 0.

3) This was intentional

Many people don't seem to understand how this could be intentional. One commenter on the Hackaday article asked how they could be expected to support all of the clones. It's not that they tried a new feature that only worked on the real ones but not the clones. The essentially initiated a challenge response protocol. The gave the chip some data or some set of data. The official ones would return one thing, the fakes another. After the fakes were identified, they were dealt with with extreme prejudice.

How does it work?

The FTDI device essentially makes a serial port through its driver. A USB device has several layers to go through. The first of which is a device descriptor. The descriptor has a lot of information on how to go through the layers, but most importantly, it has a vendor and product ID. The vendor ID is unique to the vendor, and the product id is unique to the particular product or chip. This attack sets the product id to 0 which makes windows fail to acknowledge its existence. A product or vendor id of 0 is considered invalid, so it will no longer be recognized by the computer much less the drivers.

I hope I've cleared up a little bit regarding this issue. My opinion is that it might have been better to give a small alert to users letting them know that their chips are fake. I don't think it was within their rights to destroy peoples' products, mostly because they were not aware they were using a fake chip. However, even if they did know they were using a fake, I still don't think that they should have morally done that. As far as market share goes, it might be a good decision, it might not be. The answer to that will lie in whether people keep buying their products after this.

Tuesday, September 9, 2014

Setting up Bumblebee to run on boot

BotQueue's client code no longer requires there to be a tty to function. You could simply add a line in your /etc/rc.local file to run bumblebee as your user:
( su -c /home/user/bumblebee user ) &
the /home/user/bumblebee file would just be an executable that runs the python code. An example:
cd ~/Bumblebee/
screen -dR botqueue python -m bumblebee
It's a much simpler process than previously. This should work exactly the same on a raspberry pi too.

Monday, September 8, 2014

BotQueue 0.5 released!

I know it's been quite a long wait since version 0.4 was released on July 4th, 2013. Since that time, Zach Hoeken has moved away from supporting BotQueue in code, but he still believes in the project and has continued to help whenever possible. For that support, I want to thank him. Now on to the fun stuff!

I'm so excited to release this for a couple of reasons. The main one is that this is my first major software release, so I expected it to be a bit rougher. Still, I expect bug reports in the future, so please post those here for the server, and here for the client.

I was originally going to summarize every cool now feature about this release. This release doesn't have too many amazing new features, but it has quite a few bug fixes. I wanted BotQueue to be more solid than ever, because that's what you should be able to expect. This involved fixing everything from UI issues, to a ton of fixes in the background so that everything runs smoothly.

Some of the new features I'd like to introduce are:

Auto Slic3r downloading

It's not perfect yet, but it's definitely pretty awesome. Basically, instead of downloading a bunch of huge binaries, bumblebee has been stripped of any extra weight, making it fast to download, and easy to run. It will automatically download the slic3r version you choose for your OS. This also makes it easier to run other types of slicers like Cura.

Local storage

It's long been a request to support storing files locally on the server instead of having to set up Amazon S3. I'm glad to announce that this support now exists in BotQueue.

Easy server install script

Now, it's pretty easy to run install/ on your debian/ubuntu server. It will ask for some configuration values, and install everything it can for you. If the options are filled out correctly, your site will pop right up, giving you your own BotQueue instance. This is useful if you have a private university and want the students to use a local server.

All in all, I hope you enjoy the new release. If you have any questions at all, feel free to comment here, or ask on the Google groups.

Monday, April 28, 2014

DSLogic unboxing

Today, my DSLogic came in the mail. For those that don't know about it, it's a logic analyzer with the ability to act as an oscilloscope and a DAQ.

Here are the unboxing pictures for those that want to follow along with this review. Note that I haven't actually gone and analyzed anything, so that review will come later.

The first thing I noticed is that the box that the logic comes in looks nice, but isn't going to make a nice case for it at all. I would have rather had a nice case that all of the probes and everything would fit into that I could carry around. It has four phillips screws on the bottom, so if anything goes wrong with it, at least the case is openable. There's a little hole for an LED, that really needs a lightpipe because it's down inside the case. I'm sure it will still be visible, just not diffused as well.

After seeing some other reviews,  I checked the cables to see what they meant by the poor quality. I hate to confirm that they're correct, but they are. The wires are very thin, and seem breakable. I know that eventually some of them are going to break.

I really am not fond of the clips. The first thing I noticed is that the part where the wire attaches isn't only in the center back of the clip, but that the pin was at an odd angle. After bending it back, it hooked on decently well, but not as well as I'd like. I prefer the pin to be off to the side of the clip so that I can press on the clip with my thumb completely. Also, in the last picture, I notices that the probe uses more of a claw mechanism, rather than the hook that I've seen on previous probes, so I don't think it will hold onto the pins as well.

That's all for now, but I'll add more posts once I start using it.

Tuesday, April 8, 2014

BotQueue and Heartbleed

Have no fear, for the system is secure... well... almost. It's currently not vulnerable to Heartbleed, however we need to get new private keys because we have no way of knowing if they were compromised.

Looking at what information I have available, it doesn't seem like anything was really attacked, but then again, it's almost impossible to know with the heartbleed attack.

Zach Smith will have to regenerate keys for the server just in case they were compromised, but it looks like everything updated correctly and no one was affected. If you were affected, please let me know immediately!

 According to SSL Labs, we currently have an A- rating because of 2 issues I'm still working on improving.

Enjoy using BotQueue knowing it's secure!