Measure Twice, Cut Once

Last night I had one of the neighbor kids come over and ask me to help him mount a new pair of bindings on a new pair of skis. He had been skiing earlier in the day and damaged his old skis. Naturally he wanted to get the new ones ready to go. I used to work in a ski shop and mount bindings professionally so I know what I am doing, otherwise I don't recommend mounting your own skis. I also have all of the equipment to mount bindings correctly.

Before he came over, I asked about the brand and model for both the skis and the bindings. This is important so I knew what I was getting into. Naturally he had Look Pivot 14 bindings, which are the most difficult binding to mount. Fortunately I have a jig for them to help drill the holes in the right place. I told him to bring a boot with him.

My neighbor arrived exactly when he said he would and we headed down to my ski tuning room. The first thing we did was measure the screw-hole distances on his new binding with those on the jig. I'm glad we checked as Look has 3 different hole patterns for their Pivot-line of bindings. I had pulled out the wrong one and needed to get the right one. Then we double checked it with the bindings. Everything checked out.

Now we needed to size the jig for the boots. My jig requires knowing the sole length of the boot. This is normally stamped on the bottom. My neighbor's boot had 2 numbers: 265 and 307. The smaller number is etched larger and prominently while I barely noticed the 307. Having looked at a lot of boot soles in my day, I knew that 265 wasn't right and so I pulled out my ruler which has imperial units as well as metric. The number I needed is in millimeters and so I used the metric side. As I suspected his boot sole is the larger of the 2. I set the jig accordingly.

Next is making sure I used the correct drill bit. Skis with metal in them can use a slightly larger bit while those without need a narrower one. Most skis will tell you which bit to use. My neighbor's skis did not. However they did say they contained a metal layer in the ski. That told me to use the larger of my 3 bits.

I drilled the holes and then added a waterproof glue into each one before placing the binding pieces on the ski. I then started each screw until it bit into the freshly drilled hole. Then I let my neighbor finish screwing the bindings to the ski. I followed along afterwards making sure the bindings hugged the skis tightly. Then we put the boot in and made sure it fit. It did. Next we made sure to set the DIN's and forward pressure appropriately so the skis fall off when they should but also don't release prematurely.

My neighbor felt a huge sense of accomplishment after helping to mount bindings on his new skis. Throughout the entire process, I had him double-check all of the settings and he felt included in the entire process. He is probably up on the hill right now testing them out.

So what does this have to do with computers? Throughout the entire process of mounting the bindings, we followed the rule of, "Measure twice, cut once." In our case we used a drill instead of a saw but the net result is the same. With computers, the consequences are much less severe and so we tend to measure once and if it doesn't work, go back and measure again. For me and some of my coding projects, this can often mean trying different values 3 or 4 times. Things go so much easier when I take the time to double check all of my values first.

The Art of Debugging

I mentioned in a previous post that I am in the process of creating a prototype web application using React. Unfortunately I am also learning how to debug my React code. I created a base version of the application using the tutorial I mentioned in my previous post. Once I got all of that working, I started expanding.

React takes the code you write and compiles the code so that it runs quickly. This compile step is where I find a lot of errors. I have a console window open that spits out a bunch of important information each time I save a file using my interactive development environment (IDE). Sometimes I will get errors and other times I get warnings. While the code is supposed to run with warnings, it generally means something is wrong and is best to fix it. Otherwise your application may not behave exactly as you thought it should.

The worst problems I have encountered are runtime errors. That means my code compiles just fine but the application doesn't look right or doesn't render at all. The first such problem that took me a while to solve involved the HTML break tag. I had a picture and wanted to have a caption underneath it. To make everything look clean, I laid out everything in a table. To get the layout perfect, I used a test HTML page and then just transferred everything to React when I was happy. I didn't know that React treats the break tag a little different and required a slash in the tag. Instead of using <br>, I had to use <br />. That looks pretty simple, right? Well it broke the whole application. Instead of seeing a funny-looking table, I didn't see anything. In order to find the offending tag, I had to copy each part of the HTML table into React and discover when things stopped working.

Today I ran into another problem. I have a button component that looks very integrated with the entire site. It is something I copied from the tutorial mentioned earlier. The guy giving the tutorial didn't bother to do anything special with the button other than to have it jump to a single page. I have put a number of those buttons all over the place but no matter which button you click on, it goes to the same page. Today I wanted to connect one of the buttons to a different page. I looked through the code and figured out a way to make it happen. Unfortunately when I added the code, it broke everything. Not a single page would load. It turns out that by adding the destination page as a parameter to the button, I broke every instance of that button. Seeing as I had a button on the heading of every page and on the footer, that should have been a sign to add the destination page as a parameter to all of the buttons in the application. Once I did that, everything started working again.

The Internet has been very helpful in solving a number of problems. I tried to embed a YouTube video into my application only to get an error from my browser saying that it can't show the video as a security precaution. A quick search showed that I needed to add a library to React and then things started working great.

I'm sure there will be many more problems I run across, but so far I have been able to solve them in a timely fashion. If I feel I am spending too much time on an issue, I put it on hold and work on something else. Sometimes I will go for a walk and the solution will come to me. Ultimately there are a number of tricks to debugging computer programs and it doesn't matter if you are coding in Python or React. I suppose the most important trick is to not get frustrated. I'm still working on that one.

Everyone Should Learn Python

If someone who wanted to learn a computer programming language asked me which one to learn, right now I would recommend Python. Back when dirt was new, dinosaurs roamed the earth, and I first started learning how to program a computer, BASIC was the language everyone learned. Then I moved onto Pascal before tackling C and C++. Nowadays I find that most of the coding I do is using Python and I love it.

I am currently working on a project where I need to display the size of a file on a web page. Most languages would require me to use IF..THEN logic show GB for gigabytes, MB for megabytes, or KB for  kilobytes. In Python, I just need to use the "filesizeformat" filter. It automatically converts the number 2600000000 into 2.4 GB (don't worry about it not being 2.6 GB as 1 KB = 1024 Bytes, not 1000).

Python is a very compact language and doesn't require a lot of coding to get a lot done. Chances are that someone has already figured out how to do something that used to require thousands of lines of code and reduced it to a single line in your program. The only problem with that is you need to know what line to use. That is an easy-enough problem to solve though. Just type a short description of what you are trying to do into your favorite search engine and you will get a number of suggestions. Most of the time one of them will work perfectly.

Python also has the advantage that is the computer programming language of choice for data science and data analytics, which is what I do a lot of. For a while, people used R but now Python has overtaken it.

Yes I still remember BASIC and Pascal really helped me understand a lot of fundamentals for computer programming. But if you are starting out on the path of learning your first programming language, my recommendation would be Python.

Relearning C++

I have a project at work that requires some C++ coding. For those that don't know, C++ (pronounced see-plus-plus) is a computer programming language. I learned it back in college but then never really did much with it. I spent part of my professional career writing C programs but it is slightly different and so I have been spending some of my spare time going through some old C++ books I have. Those that compare C to C++ have been most helpful.

It is fun to go back and relearn something I used to enjoy. While some software developers hate C++, I actually appreciate the language and prefer it to many others including Java. As I had a background in the language, it is much easier to pick it up again.

I had hoped when I started the project that I would simply be able to look at some example source code and remember everything I had forgotten. Unfortunately that is not the case. It has been helpful to run through my book and play with the examples.

Learning technology no longer requires a book to go through. You can use any number of tutorials and explanations found on websites. Once you get a basic understanding of the technology you are trying to learn, you may opt to supplement your learning with a book, but it is not necessary. The necessary thing to do when learning (or relearning) something new is to go through the examples. After all, we learn by doing.

Use It or Lose It

Today I started getting ready for a new project at work and needed to set up a PostgreSQL database. I have a database administrator that I works for me and normally I would ask him to set it up. However this is sort of a research project that I am doing in part to keep my technical skills sharp and so I wanted to set it up on my own. It has been a few years since I last administered a database and so it took some Internet searches to figure out everything again.

I felt like such a beginner as I got things configured. Fortunately I sort of remembered most of the steps and so I didn't have to comb through too much documentation. However it underscored the importance of keeping up on my technical skills.

After becoming a manager several years ago, I tried to do something technical on a daily basis. When that proved difficult, I tried to do something technical on a weekly basis. After today I can say that I failed at that goal. This new project will be good for me as I work to regain some of the skills lost and also dive into some coding that I have not done since back in school. It should be fun and the skills that I have lost seem to be returning quickly.

Video Game Algorithms

Recently I have felt the need to do a bit more software development and so this evening I pulled out the code for a game I have been writing. Yes it is taking me a long time to write this game but it is the journey I am more interested in than the destination. I need to create an algorithm that allows a bad guy to hunt down the player. It looks so easy to do graphically but is much more difficult as I try to think out the steps so I can translate them into computer code.

I threw together something simple and then discovered that it doesn't work very well. When the player gets close to the edge of the screen, the program gets stuck in an infinite loop. I know the cause and so I am having to create a more complex algorithm. Not only do I have to check if the bad guy is close enough to the player to see him, I also have to check to make sure I don't try to run off the board or through an object on that is supposed to be a barrier.

When I learned how to write computer programs in high school, my teacher taught me to pull out a scratch sheet of paper and step through the algorithm development process. So that is what I find myself doing this evening. I have a notepad with X's (the player) and O's (the bad guy). Then there are arrows showing player movement with the bad guy chasing him down. I am making progress but not nearly as quickly as I had hoped. I do have to admit it is an interesting algorithm I am trying to develop though. One that can be used for a number of video game situations. Unfortunately I had to wake up too early this morning to catch my flight from home to the Bay Area and so I am finding it hard to concentrate. Perhaps I will have more luck tomorrow.

Satisfaction in Coding

A couple of days ago I was adding an entry to this blog when I noticed that I had "Assembly Language" as one of my labels. It briefly reminded me of some assembly language programming I had to do while in college. For those that don't know, assembly language is one step above the ones and zeros that computers understand. Nobody wants to remember that 00000001 is the command to move the contents of register A to register B and so the designers of the Intel 8088 microprocessor created the MOVAB command. MOVAB is much easier to understand for us humans. Very few people program in Assembly Language as it can be rather tedious. However those programs are small and run incredibly fast.

Thinking back to my college classes reminded me how much fun coding is. When I first started at my current job, I got to do quite a bit of SQL coding. Now I do less and less as I am managing a bunch of developers. Every once and a while, I will get to do something technical and I feel a great sense of satisfaction.

Last night I got back to my boat early and had time to play around with a bit of coding. It felt good to create few lines of Python and watch them do something interesting. Once again, I am back on the boat early and plan to continue with my sample coding. I'm not planning to write the next version of Tetris or a better game than Angry Birds, but that doesn't matter. Coding allows me to build something. It allows me to create something. Writing software allows me to turn ideas into reality with virtually no cost other than my time. That alone is its own reward.