Simple genetic algorithm

Today I took a few minutes to do a simple little genetic algorithm that works toward a given statement. This is a fairly simple concept where the program randomly reassigns the value of a random set of indexes repeatedly until the goal is met. I first started with a simple non-directed algorithm where a string is constructed by indiscriminately and randomly reassigning a set of indexes in the hopes that it would eventually reach the goal statement. Well needless to say this worked wonderfully, with the exception that it took forever(I let it run for about 2 hours before becoming impatient). I didn't much feel like waiting for possibly days to see if it would even come close. So I decided to add direction. to do this I simply added a check to see if the current state in any way matched the goal state and if so, the indexes of the 2 strings that matched wouldn't be altered. The result of doing this was instead of it taking more than the 2 hours, the algorithm would instead finish within a few seconds.

What is a genetic algorithm:

A genetic algorithm is based on the concept of evolutionary biology where a sequence is randomly mutated, either for better or worse. For example let's say that you have a binary string of 0's and 1's like so:

1010001010011101

you will randomly pick a number of indexes within the string to be flipped. So let's say that we only want to mutate a single value, we select a random index between 0 and 15 for this string and mutate it. In this scenario mutating is going to be defined as randomly selecting a random value to reassign that index to. Since we are working with binary, the available set of values for mutation is {0, 1}. So let's say we randomly choose index 3 and when we randomly select a value to replace it with we get a 1. When we do this the original string of

1010001010011101 -> 1011001010011101

As I said earlier, this method on its own lacks direction and it may take literally forever to reach your goal state. So to make the path a little shorter, you can check the current state against the goal and see if the index you have randomly chosen to modify matches the same index within your goal state and if so then you don't make any changes. This is a bit of a short cut way of saying that you already know that switching the given index will result in a state that is further from the goal state than the current state, thus behaving something like a tree pruning algorithm. This was a fun little exercise for me to do, and I hope you enjoy it too. You can find the code here.

Web UI development principles for simplified testing

Today's topic is not only simple but quite important. While some projects have a dedicated UI developer that will make sure that templates are kept in pristine condition, there are many that don't. Instead the developers are left to create the UI and all it's niceties. As a developer I can say we generally aren't all that great at making things look pretty, but we are capable of setting up the necessities. With that said, there are some very basic things that should be kept in mind during UI development so that later on, testing is simple to create and maintain.

1. HTML tag ID's:

Ask any person who has ever created an html template, and they will tell you just how important it is to use IDs for things that appear only once. For example lets say you have a page with 2 tables, it is very important that you give each of those tables a unique id that can be used to identify them. The syntax is simple and it makes finding these elements easier when creating tests for the UI, by making the information simple to find in the DOM.

2. Don't repeat yourself(DRY)

When creating UI's it can be easy to duct tape in something simple, but it might not be the best choice. I recently had the experience of working on a project where the developers would regularly make something simple into multiple components, when one would have been cleaner and easier to test. The problem with trying to test such a system is that you are then exposed to multiple components with different ID's, names, content, etc. So when you interact with the component, you find yourself having to figure out which one is now displayed so that you can get your test to pass. Mind you that having multiple components in general is bad practice, so don't do it. Find a way to simplify your work so that you don't repeat yourself, and you'll find a project that is much easier to test and maintain.

3. Don't reinvent the wheel

If there is a simple way to do something that fits your needs, do it that way. Don't waste your time recreating it in some new way. When you are dealing with HTML for example, use a select/option like the rest of us. Whatever you do, don't go crazy and decide that you are going make drop down boxes with a series of divs. Seriously, don't recreate standard features in overly complex ways unless you are working on something so mind blowing that the standard doesn't fit your needs.

4. Use a templating framework

Whatever you do, don't use a library that is "amazing" because it offers UI development for programmers. This is just a fancy way of saying you'll do 10 times the work to get a simple template laid out than you would have if you had just used a templating framework that relies on HTML. You'll also spend 10 times more time trying to figure out how to add an ID to that one tag should you find you need to.


That's really about it. I may add to this list in the future, but these are the things where I've seen non UI developers go wrong the most. I do realize these are obviously pretty standard practice in most development and probably shouldn't need saying, but I did it anyway. Just remember, if you are a developer on a team, someone else is likely going to be testing your code. So construct your UI and code like the next person testing it is a violent psychopath that knows where you live.