Monday, March 19, 2018

My First Certifications

I shared last time that I was enjoying learning Kotlin through the Android course I had started. That got me going back to the earlier Java based Android course I was working through, to better appreciate the differences. That course had been updated since I started it, including some Kotlin as well. I also learned that that instructor, Rob Percival of codestars.com, had started to offer access to various programming certifications through the Cambridge Certification Authority.

That led to me getting my first certification, a Java Level 1 certification. Then through a Complete Web Developer course from Codestars, which I had purchased and planned to get to at some point, I started learning more and working on more certifications.

As I wrote about some time ago, I had written my first websites back in about 1994 using basic HTML. Now I've had a lot of fun getting up to speed with HTML, CSS, and JavaScript. I've enjoyed working on the projects in the course and was also able to program a Nooka clock in short order. I enjoy having that run on my desktop at work all the time now.

Having completed the HTML, CSS, and JavaScript level 1 certifications, I'm now starting  to learn jQuery.

Knowing that some of my app ideas could also benefit from a web version, I knew that I wanted to learn some more web development at some point and now I'm really having a great time doing so.

i++

Saturday, September 23, 2017

Kotlin is fun

I'm having fun learning Kotlin so it's time to jump ahead. All of my previous posts have recounted my journey learning programming in chronological order. I was up to my time leaning Java in the Stanford course. There's more that I could write about that and about an Android course I started based on Java. And while I may get back to those topics at some point, I'm going to jump ahead.

I've recently started an Android course using Kotlin. I had heard about the new language and once it became an official language of Android I started thinking more about learning it. The course name is The Kotlin Developer Masterclass on Udemy, taught by Paulo Dichone.


Kotlin is fun

There are definitely things I like in Kotlin more than in Java. Kotlin is short and succinct. While it goes well beyond this, just a simple "Hello World" comparison shows some of this succinctness.

Java

    public static void main(String[] args) {
         System.out.println("Hello, World");
    }  

Kotlin

    fun main(args: Array<String>) {
         println("Hello, world!")
    } 

Note the differences. 

First, the function is declared with the simple fun. While I have seem some programmers online complaining about this, I like it. It's short and sweet and I think programming is fun so typing "fun" all the time is fine by me. On a more serious note, I like how more things can be inferred. If the return type is void (Unit in Kotlin) it doesn't need to be explicitly stated. What's more, if it's a single expression function and the compiler can infer the type, it doesn't even need to be indicated then. Less typing is a good thing.

    fun double(x: Int) = x * 2

Second, println() is better than System.out.println(). The Kotlin builds upon the Java code and saves some typing and extra code to read through.

And third, semicolons are not required. I liked this when I took a look into Python. You'd think that with as much OmniScript I write on a daily basis that adding semicolons, which are required, would be automatic, but I still find that I forget them here and there. I won't miss having to add while writing Kotlin.

I have some fun app ideas that I want to get to, but in the meantime I'm enjoying learning the differences between Kotlin and Java and the other languages I've worked with.

i++

Sunday, June 4, 2017

Search Algorithms

You know that a topic is interesting to you when you get excited about it even though the lecture you learn about it in isn't the best. Most of the lectures in the Stanford Programming Methodology Java course were pretty good and easy to follow for me but one taught by the teaching assistant was more difficult to follow. No offense is intended to that teaching assistant, I'm sure with more experience he's a better teacher now. Thankfully, as I said, the topic grabbed me anyway.

Seek and You Will Find

We learned about arrays, creating them and valuing them. Then we had to write something to reverse the order of the items in an array. But what about searching them for a value? That was one thing I was always curious about when creating queries in Access or writing things in OmniScript to search for database records. What was going on under the hood to make searching faster? Was writing something one way going to make for a quicker, more efficient search or not? Therefore I was quite interested in learning about search algorithms.

Linear Searches

Linear searches are the most basic kind of searches. To search an array for a value with a linear search is to look at each value in the array, one at a time, in sequential order, until the search value is found or the end of the array is reached. Naturally this takes some time. Computers are very fast, but if the array is very large, this still takes some time. If an array has 100,000 values, each one might have to be looked at.  I realized that there must be some more efficient ways to search, and there are.

Binary Searches

As long as an array's values are sorted in order, you can do a binary search. With a binary search, the value in the middle of the array is looked at first, and if that value in the middle is lower than the value being searched for, then the whole first half of the array can be eliminated as the value being searched for must be in the second half of the array, if it exists. The opposite is true if the value in the middle is higher than the value being searched for. So if the array has 100,000 values, with the first search, 50,000 values are eliminated and no longer need to be looked at.



Next, the middle value of the remaining values is looked at and the process is repeated. If needed, it is repeated again and again, each time cutting the number of values that need to be looked in half. This, of course, makes the search much more efficient and greatly reduces the time needed to perform the search.

A binary search is much like we humans would search a dictionary or phone book. We don't look at every entry, we jump in at a point and decide which way we need to turn to find what we're looking for and we repeat that until we find our entry.

So Which to Use?

Because binary searches can be so much quicker, one might think they are always preferred. But again, in order to do a binary search, the array has to already be sorted. So if an array is already sorted, then a binary search is the obvious choice. But what if the array isn't sorted? Of course you could sort the array so that you can do a binary search. But of course that's going to take time. So for each case you have to decide what's going to be faster. If you are going to need to do a lot of searches on this array then it's probably best to spend the time to sort it as each binary search you do will save a lot of time. If on the other hand, the search only needs to be performed once or a couple of times, then just running the linear search might be the fastest thing.


i++

Sunday, March 12, 2017

Random Number Generators

Another interesting topic I came to early in the Stanford Programming Methodology Java course was the generation of random numbers. As someone who early on thought about making simple video games, I knew that you would need a way to come up with random numbers to make aspects of the game unpredictable.

RandomGenerator

As the Stanford course uses the ACM libraries, professor Sahami had us use the RandomGenerator class. I've come to learn that the use of the ACM libraries is somewhat looked down upon and they aren't used very much outside of the academic setting, but this worked fine as an introduction. I believe this was also one of the earlier instances we had of learning about constructors for new objects.

The RandomGenerator methods include nextInt() for integers, nextDouble() for decimal values, nextBoolean() for true or false (1 or 0) values, and, unique to the ACM version, nextColor() for a randomly generated opaque color, with values 0-255.

The first example used was to simulate a six-sided die roll with the code below. As someone who has had an interest in dice, from the six-sided up to the twenty-sided dice used in role playing games, this was a fun application.

 int dieRoll = rgen.nextInt(1,6);  


PseudoRandomness

But are the numbers produced by computers through random number generators really random? No, they are actually determined by a complex algorithm, based on an initial value. Given the same initial value, the seed, they will always produce the same sequence of "random" numbers. For most practical needs, however, pseudorandom numbers are sufficient because the user does not know the what the seed is and so cannot determine the sequence of values that will be produced. The ACM RandomGenerator uses the system time in milliseconds, which no one will know, for the seed.

A process (or data produced by a process) is said to be pseudorandom when the outcome is deterministic, yet also effectively random, as long as the internal action of the process is hidden from observation. (NIST.gov)

Of course from a programming perspective, it's good that, though seemingly random to the user, the sequence is determined and will always be the same, given the same seed. That's for the purpose of debugging. If there was a problem in your program and it only occurred when a certain "random" number was used, you might have a very hard time tracking down the bug. If, on the other, hand, you can set the seed used and so always produce the same sequence of numbers, it will be much easier to reproduce the problem and find the bug that is causing it.

In a future post I want to write about a virtual dice throwing app that I just installed. Rather than just generating random number results, it uses a physics engine to throw the dice and the dice will even interact with each other, affecting the way that they land, just like with real dice.

i++

Sunday, February 5, 2017

Been Looping for a While / 2 AM Debugging

It has been a while since I've written here on the blog. The primary reason was that work was just too busy. For two and a half years I was working on new website for our retirement plan participants and sponsors. Almost 20 internal employees and lots of external resources were working on the development of this site. It has lots of new features compared to the old site and everything had to be built from the ground up.

My role in the project, along with two others, was writing OmniScript to pull the needed participant data from our recordkeeping system and send it to the web in the form of XML. As each retirement plan has it's own set of features and options, this involved a lot of variations. I'll write later about some of these various aspects and what I learned through the project, which was a lot.

After a lot of work and some optimization, the site went through extensive UAT testing and was finally launched to participants at the beginning of December. Overall the launch went very well and it was great to see all of that work finally in use in production. Naturally there were some bugs that were found over the first few weeks and that continued to keep us busy. Finally, though, things are slowing down, at least until the next big project, and I plan to get back to blogging about my experiences in learning programming.

2 AM Debugging


I just wanted to share one programming story, going along with the new website. When you become one of the experts on a new website that allows people control over their money, their retirement savings, then when there's a problem, your phone can ring at any hour of the day or night. I discovered this on New Year's Eve. I hadn't been in bed for long when I noticed at 2:00 AM that I had a couple of missed calls and texts. With the turn of the new year, something was preventing anyone from logging into the website.

So I woke myself up and called my boss back and proceeded to get logged in to find out where the error was coming from. I was probably not at my clearest thinking, and as it was coming from a script that I had not worked on, it took a little while to figure out the problem. By 3:00 AM I had found the problem, a logic bug that, with the turn of the year, was causing the low date in a date range to be higher than the high date. This produced a fatal error.

My boss and I talked it over and decided on a temporary fix that would work until we returned to the office. By 3:30 I had made the fix and people were once again able to log in, though who's trying to log in to their retirement savings site at 3:30 AM on New Year's Day, I do not know. 😃

i++

Sunday, July 31, 2016

Characters and ASCII

Fun with Char

One of the things I found to be really interesting early on in the Stanford programming methodology course was chars in Java. I found that I was taking a lot for granted about characters when it comes to computers. I know what an 'A' and a 'B' and a 'C', and so on, are and so I thought that computers understood them in the same way. I think an 'A' and an a are two versions of the same character, upper and lower case. Therefore I sometimes found myself wondering why there was this case sensitivity thing you had to deal with with computers. Doesn't the computer know an 'A' is the same character as an 'a'? So I found it rather eye opening, and oddly fascinating. to learn that an 'A' doesn't mean anything to the computer, it's actually just a number. What's more an 'a' is also just a number, and it's a different number. So of course case sensitivity is an issue for a computer because there's nothing that really ties the two characters together for the computer, they're two entirely different characters, really two different numbers.

The ASCII Table

I had seen and heard about the ASCII table before but was only using it as a reference for the sort order of the numbers and special characters in relation to the letters.  Now I was coming to have a greater appreciation for what had been established and standardized so that we could effectively communicate with one another through different computers.

I learned that an 'A' was decimal number 65 and an 'a' was number 97. I learned that a '0' was actually the number 48.



So then I learned how to write my own method to change an upper case character to it's lower case equivalent. I learned that you could do math on letters! Yes, I am fully aware that the exclamation point at the end of that sentence means that I'm a geek. What's surprising to me isn't that I found this realization fascinating, but that I hadn't discovered this sooner in life so I could geek out on it.

I learned that to change an uppercase 'A' to a lowercase 'a' you actually add 32 (65 + 32 = 97), and the same is true for every other letter. But what's better, I learned that, even though ASCII is unlikely to be changed or abandoned, you wouldn't want to put 32 in your code, instead you want to use the characters themselves and let the computer figure out the number difference between them, just in case they ever did change.

What you know is that 'A' through 'Z' will always be sequential numbers in whatever code is used and 'a' through 'z' will always be sequential. In ASCII there are six extra characters ( [  \   ]   ^   _   ` ) between 'Z' and 'a' (26 letters + 6 characters = 32). But should some other table ever be used, the difference may no longer be 32. So what you write to convert an upper case character to it's the lower case version is something like this...

public static char toLowerCase(char ch){
   if (ch >= 'A' && ch <= 'Z') { /* to see if input character is upper case */
      return ch + 'a' - 'A'; 
        /* dynamically determines and adds the difference between the two */
   } else {
      return ch; /* if not upper case, return as is */
   }
} 

Since they are really just numbers, you can also use char in control statements to loop through the equivalent letters, such as...

for (char ch = 'A'; ch <= 'Z'; ch++)

This is actually a simple concept but it was an eye opening and fun realization.

i++

Thursday, June 30, 2016

Eclipse and Karel the Robot


The Eclipse IDE

One of the first things I did for the Stanford programming methodology course was to install the Java JDK and then the Eclipse IDE. This was my first experience with an IDE, a step up from Notepad++. While a later book I read encouraged avoiding IDEs and typing out code with no assistance, I found the automatic code completion and instant feedback for syntax errors helpful for beginning to learn Java. For the course, Stanford developed a customized version of Eclipse. This version made it possible for beginners to get started with some basic object-oriented programming ideas without having to start with something like the main() class.

I have since had experience with the Android Studio IDE, which seems quite similar to Eclipse, and have learned of a few others. In time I would like to try out Emacs, NetBeans and others.

Karel the Robot

The first few course assignments were to be written in Karel, a simple object-oriented language similar to Java. Karel is the name of a little robot that will follow programming commands as he moves through a grid. Karel has only four main functions:

  • move()
  • putBeeper()
  • pickBeeper()
  • turnLeft()

You are told what to have Karel do and then you must accomplish it using only those four functions. 

move() tells him to move forward one step. putBeeper() has him put down a marker in the grid and pickBeeper() has him pick a marker up. turnLeft() does what the name suggests. You may need to have him turn right but there is no turnRight() function. So you can have him turnLeft() three times, then you learn to write your own turnRight() function to use.

Karel the Robot was a fun introduction to programming. It teaches you to problem solve, using logic, and to begin to think in a object-oriented way. You can find the Karel the Robot Learns Java book here.



i++