Saturday, May 18, 2013

Software assembly line Pt2.

In part 1 of this series, we gathered our dependencies, and placed them into a known directory. In this part, we'll discuss how to build the software, and set up for 'installing'.

Creating the project

The first thing you need to do when creating the project is to set up your build script, makefile, CMakeLists.txt, or whatever your build environment calls for. In your build script, you'll need to refer to the dependencies area. Its a good idea to retrieve your dependencies before you attempt to create the makefile, as you'll have the file structure to reference.

One good thing about putting all your dependencies in one spot is you will always know where your dependencies are, in every project, so configuring multiple projects is consistent. Too many times, I've seen one project think that the dependencies are in some random folder, and another project think they are somewhere else.

Building the project

Next up, build the project. Make sure that it links, and VALIDATE THAT IT LINKS AGAINST YOUR DEPENDENCIES, and not your system's libraries. This is very important if you want to have consistent builds. Once you've validated that you're using the correct dependencies, you need to install the project.

Installing the project

When I say install the project, I do not mean install it for use. The install that I'm referring to is for packaging.  What I do is install into a directory in my project called "installed_files". Anything that goes in this directory is packaged up for use by the dependency manager. 

Submit to the dependency manager

Once you've installed, you'll want to submit those installed files to the dependency manager. This will give us the ability to use ant of our projects as a dependency.

In part 3, I'll do a walk through of the entire process, tying everything together. I will also have a few other hints to help build a stable development process. 

Saturday, May 11, 2013

The now of passwords Pt 1.

Most everyone is familiar with passwords. You give a username or email address, and you enter your password. This forms the basis of virtually everything we do online. With today's technology, using passwords to protect websites and other services is nearly useless. Why is that? Why do some websites have certain restrictions, like only using certain characters, or why can't I used more than 8 characters at some places.

How passwords are stored and checked

Passwords are one of the most basic security features. A user enters a password, its received by the software processing the password (referred to as the "server" from now on.),then analyzed to see if its the expected password. Simple huh? (Note: we're ignore how the password is transfer from the user to the server.) I'll be going over how password storage and checking has evolved. This is a general overview, and will (hopefully) not be too technical. If you have questions or comments, please ask in the comment section below.

Simple password storage

In the early days of password protection, it was that simple. Password were stored, as-is, in a file or database. Anyone with access to those files or databases could read your password, and log in as you. Hackers had a field day, because all they needed was file or database access. 

Encrypted passwords

Eventually, servers added encryption. When you set your password, it would be stored encrypted. Then when you entered your password, it was received and then encrypted by the server. Then the server would compare the encryption results against the already encrypted password in the database. 

Hackers started doing several things here. First, they would analyze the encryption method for weaknesses. Depending on the encryption used, the length of the result encryption would change with the size of the password. So just knowing the length of the password would narrow down the possibilities. With this knowledge, they would "brute-force" the passwords, trying every combination of characters. As time went on, they started creating "rainbow tables" which are tables that contain all combinations of passwords, with the resulting encrypted value. This means that even with an encrypted password, it was relatively easy to find the password.

Hashed passwords

With encrypted passwords, the length of the encrypted password would give clues that would reduce the amount of work needed to crack the password. Servers then started to implement "hashed" passwords. Hashing uses an algorithm to come up with a single large number or represent the password. The advantage of this over encryption is that for every password, the hashed value is exactly the same length as all the other hashed passwords. Assume that the hashed value was 32 digits long. No matter if you have a password that was a single character, or 100 characters, the length of the hashed password is 32 digits.

This makes it so that the hackers do not know the length of your password by looking at it. Now they have to generate every single combination before they can crack a password.

In part 2 of this article, I'll cover multi-hashed passwords and salting.

Monday, May 6, 2013

The software development assembly line Pt1

As a software developer of 15+ years, I'm surprised at the number of other experienced developers that do not understand how software is assembled. This series of posts will describe what i see as an assembly line. My main focus will be on C and C++ based development, but all this could apply to any development environment.

This will be a multipart article. The first part will be about dealing with dependencies. The goal will be to build a reusable, predictable, sensible build system.

The most common issue I've run across is dependency management. Most places I've worked had none. You were expected to have all the libraries you needed installed, used whatever compiler was installed on the box, and hope for the best. This invariably leads to the release building machine having different compilers and libraries, which in turn leads to release bugs that no one can duplicate.

So the first step in the assembly line is to gather your dependencies, and place them into a known location. I personally prefer putting the dependencies into the same directory as my current project. This is as opposed to having a global area for dependencies. I do this for a few reasons:

  • I generally work on multiple projects with slightly different dependencies. This is much easier to manage.
  • Allow mobility on my local machine. I can move the project around as needed. I can copy it to another machine with a simple directory copy.
  • If you have multiple versions of the project your working on, you know exactly which dependencies you are using, just by looking in your dependencies directory.
  • You can build your build scripts/projects/makefile to always point to the same area. No worries about trying to find where on the system the dependencies are.

I do realize that this will mean having the same libraries on my machine, but I'm willing to pay that price. 

The next decision that needs to be made is what you dependencies really are. Depending on your requirements, your dependencies could include an entire OS. You need to draw a line somewhere. For most desktop applications, you can safely assume a base set of libraries are available. I personally do not like having to install extra dependencies when I want to run some application. That may be ok, you'll have to make the decision based on your target audience. Also remember that your compiler is also a dependency.

You've now determined where and what your dependencies are. You now need the 'how'. I've used shell scripts, python scripts, Ivy, and a few other things. I even wrote my own at one point, depvault. Now matter what you choose, you need a way to describe what you dependencies are, and how to retrieve them. A few things in mind when selecting a dependency manager:

  • I prefer dependency managers that use a separate, human readable file to specify the dependencies. This makes it easier to track changes in your source control, as you'll be able to see the changes in what version of a dependency you are using. Using things like externals (subversion) aren't a good solution. Not enough visibility.
  • You should also be able to specify a version of that dependency, and possibly additional information. The additional information could be anything from what platform you need, to debug or release mode, to developer versions (header files and .lib/.a) or distributables (executables or shared libraries.).
Once you've determined what you need to depend on and how you're managing them, you now need to use these dependencies to build your software. I'll cover that in part 2 of this series. 

 

Saturday, May 4, 2013

Good smoke! Review of the Traeger Junior

A few months ago, I bought a new smoker. Its a Traeger Junior, also know as Traeger BBQ055. I happen to find it on Amazon for $100 less than anywhere else! The shipping wasn't free, but it was only $50 for me. So it saved me $50. Here's a link to the cheap one.

This is whats known as a pellet smoker. The pellets are compressed wood dust. There are *no* fillers or binders. Originally when i was looking at these, I figured they had to have some sort of glue or something in there to hold it together. That turns out not to be the case, The pellets are fed into a 'fire box' where during the startup phase, there is an ignitor. After a period of time, the ignitor shuts off. 

It arrived in a fairly large box. Comes with all the tools to assemble it, and takes about an hour or so. The smoker comes with a simple controller for to controlling how fast the pellets are fed. Since I had saved some money, I decided to upgrade to a more advanced controller. Traeger Digital Thermostat Kit BAC236. The simpler one has three settings, smoke, med, and high. The more advanced one has several temperatures you can select from. It also has a digital read out of the current temperature of the grill. It has a temperature sensor in the grill, that it uses as feedback to determine how quickly to feed the pellets.

The advanced controller makes smoking food a no brainer. Especially if you use a remote temp sensor like this one: Maverick ET732 Long Range Wireless Meat Thermometer. You can set a temperature, and only need to check on it to make sure you don't run out of pellets. I've done several 14+ hour smokes without issue. Just monitor your sensor to know when you are done.

I love this smoker. It does have its flaws though. You need to clean it throughly after every smoke. Not just the grate and the drip pan, you need to vacuum the area below the drip pan. Not a big deal, but does take some time. If you don't, there is a reasonable chance that the smoker won't ignite properly the next time you use it. Also, the pellets in the hopper don't always fall into the auger that feeds the fire. This means that even if you have pellets, they don't make it, and the flame/smoke goes out. The easy solution is to keep the hopper full.

I have a few modifications I would like to do in the future. Such as adding firebricks to help it maintain a more consistent temperature. RIght now, it has a pretty wide swings and nearly 50 degree's. The firebricks should improve that. I will also think about increasing the size of the pellet hopper. This will help with the auger going dry issue I mentioned above. 

All in all, I'm very happy with my purchase, and will be smoking everything and anything I can think of.