On this episode of the podcast Script discusses where he has been for the last few months, a personal project he is undertaking to help learn new technologies, and answers a question posed to him by listener Brandon Kuenzi in the comments on Episode 2 about the changes he has seen in the last 20 years.




Welcome to Episode Three of the Script Van Winkle podcast! My name is Script Van Winkle, but my friends call me (singing) “maybe”.

Now on the last episode of the podcast I was telling you all about everything I learned at a great conference in North Carolina and what an awesome and growing tech community there is there.

In the first episode I was telling you how I was trying to get a job with a company in a nearby city but how in the end I decided not to apply at that company. That, it turned out was a good thing. Just a few weeks later, me and the Mrs. pulled up our roots in the Mid-Atlantic region, and set them in the soft, fertile, though sometimes sandy, soil of North Carolina. Nice how I tied those two things together.

Now, all of this is just really a lame excuse as to why I haven’t put out a podcast in over two months. But hey, it takes a long time to unpack a microphone. I’m just saying.

On the plus side, you can consider this episode my holiday gift to you. So Merry Christmas, Happy Hanukkah, or whatever other meaningful holiday you celebrate this time year.

So in this “present” tation (see what I did there) I am hoping to accomplish two things. Which would be two more than I’ve accomplished so far this week. First, I’ll tell you about a personal project that I’m going to be using as a vehicle for learning new technologies. Second, I’m going to try to fulfill the request of one of our listeners. After all, I’m rarely asked for my opinion on things.

When you are learning new technologies, especially when going through tutorials, you inevitably encounter a variety of sample programs you’re supposed to try out. These range from the ubiquitous “Hello World” programs to more complex ones showing you what the technology can do.

Now I HATE sample programs! Ok, I’m not talking about the examples that you find when you’re reading through a tutorial. I love those examples! Especially, because when you’re looking up how to do something, if it doesn’t have an example it can be really frustrating!

What I’m talking about is when they give you exercises to do to create sample programs for you to try out what you learned. Now don’t get me wrong, the sample programs probably are the best way to reinforce what the tutorial taught. After all, they give you a controlled environment where you don’t really have to consider other factors that may ultimately play into your application. It’s just a simple sample example. Nice alliteration if I do say so myself.

It’s those programs that I can’t stand doing. And I’ll tell you why. If I’m going to be investing my time writing a program it needs to have a real world application. Or, more than likely, something I HOPE will be a real world application that somehow never quite makes it big.

My hard drive is filled with “real world applications” that I never seemed to get launched before the next big “real world application” came along. And if you saw the number of the domain names I have registered and keep registered today just because I don’t want to let them go….it’s insane. But I digress.

Now there are several web technologies I want to learn including microservices, which I mentioned on the last episode, Node.js, and AngularJS. Plus, I really want to push the limit of keeping that hard line between the frontend and backend. So I decided to find a personal project that could accommodate all of the above and give me an opportunity to play with each one of the technologies.

My son is a Boy Scout. In fact, this year he earned his Eagle rank! Hey, a proud papa can boast can’t he?

His scout troop is affiliated with a Catholic Church. One of the biggest fundraisers for the troop every year is a fish fry they host one Friday during the Lenten season. Last year I joined a parent committee that works on the fundraiser. One of my first contributions was to help with the promotion of the event by creating a new website specifically for it as well as creating a Twitter account to promote it via social media. This went together with another member’s creation of both an Instagram and a Facebook account.
Now I am a web developer not a web designer. So I went out and found a great HTML5 template to use for the website. Because it’s a simple informational site, I quickly hand coded a couple of static HTML pages. To them I added some really delicious looking photos of the dishes they would serve provided to me by a member of the committee who is also pretty awesome professional photographer.

I then used ColdFusion to build a form for which users could order tickets. Once this form was submitted, the information was stored in a local MySQL database. Then the user was handed off to PayPal to complete the financial side of the transaction. Once they successfully completed the stuff in PayPal, they were redirected back to our site. Paypal included a bunch of information in that request so that we could identify what the transaction was and then update our database table to show the customer had paid.

I also created an admin side of the site where the orders could be viewed and the information taken from there to add to the list of information from the tickets the scouts physically sold.

Now given that it was the first year for online sales and we didn’t really get a chance to promote it too much the number of orders wasn’t exactly overwhelming but it did contribute to one of the most successful fish fry’s they ever held. My job the day of the Fish Fry? Manually thawing a couple hundred pounds of frozen fish….a chore that was decidedly Haddock forming.

Now if you’re wondering why I’m talking about a project I did in the past but I’m supposed to be talking about a project I’m going to work on in the future to learn all this new technology, it’s because I’m going to use that project as the basis for this one. You see, the chairman of the committee was so impressed at what I did he had an idea. One of the biggest problems he has on the day of the event is figuring out just how many tickets they can sell to people who didn’t purchase tickets in advance. Up until now he has just tried to look at how many people seem to have come to the event, and guestimate what they likely have left.

But now his idea is to make a system that has all the ticket sales recorded, allows staff to check off people as they come in and in real time match that up with the inventory of the food we know we had to begin with, and give a relatively accurate count of how many pre-sales can still be sold.

So I decided that I’ll take on that challenge. And yes, my idea of a “real world app” is one that is going to be used by one person one day year. I know what you are thinking there junior developer but you can keep your opinions to yourself.

Besides, the jokes on you. Because you’re going along for the ride.

Now this time around we’re just going to focus on the initial planning steps. Dividing the application into logical parts and then kind of figuring out which technologies play what roles for each part.

Obviously the first logical part of the application already exists. The public facing website that we built last year. And while one could be easily tempted to go in there and rebuild it with newer technologies, we are going to leave that as is for now which means it’s going to be a combination of HTML, CSS, a little bit of vanilla JavaScript and some delicious pictures.

The second part of the site is the ticket order form. That’s is also using HTML, CSS, and JavaScript, but now adds on ColdFusion and interaction with a MySQL database. Once again we will let this one ride as it is for now.

The third major part is integration with the PayPal API. That’s working so we’re going to leave that one for now. And we will do the same for the admin side of things though we may build a few additional pieces to it to support adding inventory into the system.

Now things get interesting as we look at the newer functionality. A great thing to keep in mind with this new piece is where we are going to be using the application. All the previous pieces are used by users from various locations making it perfect for a web based architecture.But for this new stuff that is not the case. At the venue used for the fish fry the Wi-Fi is very spotty at best, and we pretty much know that this is going to be used by one person on one computer.

Right about now I can hear all you VBers or .Neters screaming “Hey! This is perfect for a Windows app!” I can also hear all you mobile developer screaming “Hey! iPhone or Android app!”.

Hey, I hear yah. But just remember here I’m a web developer looking to improve my web development techniques. So I want to stick with that technology. In this case, there is really only one logical choice, JavaScript baby!

I can hear a few of you out there going “Hey Script! You know that JavaScript is client-side? How are you planning on interacting with the database and get and set all that information you’re going to keep on the fishies and the shrimp and the other good stuff?”

To you I say, “Forget about it!” Because as you may or may not know Node.js is designed to do JavaScript on the server-side. You can use Node to do a lot of the same server-side functions like interact with the database. Now, Node has to reside on your server. Due to the limited network connectivity at the venue we are pretty much better off running this app local on a laptop anyway. We will have to install Node on that but again it’s one machine and we are controlling it.
This is also where that whole separation of front end and back end comes in the play. On the backend we’re gonna be doing things like pulling order records, updating the flag to say the how many meals been picked up and running calculations against the inventory to come up with a number of tickets we still can at the door.

So Node.js makes the most sense. We run a little node server on the laptop which could handle all the database interaction. We can even split these tasks into little microservices which I think would be fun to do. But what database are we going to use?

Now on a future episode I would like to go into a deep discussion of the differences between SQL and noSQL database. At least what little I know of. But for purposes of this discussion let me just give me a real quick synopsis. SQL databases are the kind most people generally think about.
You create structured tables, ones in which the records contain the same fields formatted the same way. You find your records by indexing and matching up records from one table to another all done through the structured query language, aka S Q L, aka SQL(sequel).
NoSQL on the other hand has a lot less structure. You create collections of objects and those objects can be any different type of data, mix-and-match, you name it. Generally you want to keep the same thing just so you can keep your sanity but it gives you more flexibility. One of the most commonly used ways to use NoSQL is to take data objects in your program and save that entire data structure to the database. You can use a lot less complicated statements to set and pull your data.

So let’s think about it. We’re gonna have a list of orders and are really going to just have to pull them by one key value… their ID right. And we are not going to be doing any sort of in depth searching on the orders. I mean it’s pretty cut and dry.

Also we are going to have a list of the foods we track. You know, the fishies and the shrimp. They’re going to be individual records we just need to pull up and update the count of the ones that we use. Also cut and dry. Not to mention we’re gonna put a copy of the database and run it locally on this computer. Nosql engines tend to be a little bit lighter than say MySQL and MSSQL.

The one downside to using NoSQL here is that on the website last year we collected the information in a MySQL database. To be able to move that data over to a local copy on our laptopwe are going to have to do one of two things. First, we can convert the website to using noSQL instead of SQL. While that shouldn’t take a ton of time, it violates our idea of not touching what was already working. The other option is to write some sort of function that crawls through the SQL tables, builds data structures from the results and stores those in the NoSQL database. That certainly wouldn’t violate the first principal about not touching the stuff is working. It would also be a rather interesting exercise in creating a microservice to do this.

However, I’m curious to get your opinion on it. So in the comments let me know your arguments for going with SQL or NoSQL for this application.

So to recap so far, we’re going to have a database sit locally on this machine whether it’s SQL or NoSQL It’ll have the most up-to-date information as of the date of the event. We’re going to put Node.js on this machine to handle backend functions and DB interaction, with those steps possibly divided up as little microservices just for kicks.

Now for the frontend. To control all the interactive screens the person checking people in at the fish fry would use, we could pretty much go straight HTML and JavaScript. While it would be fun to try out a little AngularJS here, it might be a little extra complication we don’t have time for. But if the opportunity presents itself we should think about taking advantage of it.

The committee chair also said he thought it be a really cool idea if the tickets they sold had barcodes or QR codes so they could be scanned as the people come up to the ticket desk. It would pull up their order and the person working the desk would check off the meals that are being picked up. It’s a cool idea and worth considering. I just have to decide on how complicated that is.

So that gives you an overview of the program that I’m planning on using to try to figure out new technologies. As of this recording it’s already the middle of December actually even later just a few days before Christmas. The Fish Fry is held in March. So I don’t have a whole lot of time to get this together. As I work on it though, I’m going to try to bring you in on it and let you know some of the things I discover along the way. And, of course, I welcome any input you have, just leave it in the comments on the website at

Now coming up I’m going to fulfill the wish of one of our listeners who left me a comment on the website and fill you in on my opinion on a particular subject. That is coming up right after this.

(GitReal fauxmercial)

Welcome back to the Script Van Winkle podcast. Now listener Brandon Kuenzi’s comment on Episode 2 was very complementary. He mentioned how much he enjoyed the podcast and hopes that I continue it well into the future. As a long time podcaster I can tell you that kind of feedback means the world to me and I thank you so much for it. And yes junior developer I get that this is only the third episode of the podcast. But trust me I’ve done hundreds of episodes of other podcasts so I know whereof I speak.

Brandon also expressed an interest in getting my opinion on how the industry has changed over my 20 plus years in it. That is a request in which I would be happy to oblige.

Now being an old grizzled developer, well maybe not so old, but grizzled like a bear. I have seen so many changes it would really be hard to cover them all in one shot. So for now let me focus on one simple aspect of the industry. To me, I think one big change is the inversion of thinking on the development and programming of websites and applications.

You see, in those early days we didn’t have very much to work with. So you would start with the text that you wanted to show on the webpage. Then you would add some HTML tags around them to emphasize certain points of text and maybe, MAYBE add a few simple graphics to punch that up a bit.. You would save those into static HTML pages, usually one for each page of your website. When you had an element of the page that you wanted to make dynamic you would replace that hard coded text with either an active service page tag or a ColdFusion tag that would render that dynamic information. In fact, you would often put other ColdFusion or ASP code that computed the dynamic information right at that same spot. It was our version of just-in-time info.

Hey, in those early days we really didn’t have JavaScript or even JScript so those weren’t even a consideration.

So essentially, you were starting with your finished product. You know, the static content you want to get out there, and just dressing it up a bit either with style or a little bit of dynamic text.. And, doing whatever dynamic stuff you did when you needed it. It was pretty much a procedural way of doing things.

Now think about how we do it today. It’s more comparable to an object oriented environment. First we gather all the information we need from all the dynamic sources we need to get it from. This could be from databases or text files or even still some hardcoded HTML. But the point is we gather it and build the entire structure. Then using CSS, HTML templates and such, we llay out the format and combine it with the graphics and look and feel. Essentially we are starting with information first and styling second. Not to mention, where in the old days pretty much everything was in one big giant monolithic document, these days you try to make the files as small as possible and separate out and reuse assets and code as much as you can..

If you want a really bad analogy to describe the differences think of it this way. Twenty years ago a web page was like a big giant lump of Play-Doh. Everything we needed was pretty much in the Play-Doh and all we needed to do was kind of mold it, maybe take a piece from another lump of Play-Doh and mix it in, and maybe hang a couple of pictures on it.

Whereas today your building sites more like Legos. Lots of different specialized parts that are attached together through standard connectors to make the final product.

From Play-Doh to Legos, yeah I’d say that was a pretty big change. And don’t worry, I will resist the temptation to say I saw developers go from sculptors to blockheads. Hmmm, maybe I should look up the definition of the word “resist”.

And that’s all for this episode of the Script Van Winkle podcast. If you’ve got questions or topics you would like me to cover, drop me a line at or find me on Twitter @ScriptVanWinkle. You can subscribe to the podcast in iTunes, Google Play, or on Stitcher. You can comment on this episode, see blog posts and find more info at

Thanks for listening and I’ll talk to you next time.