Tag: node.js

Episode 4: Getting Real, Open Source, and Raymond Camden

Description:

On this episode of the podcast Script talks about getting “real”.  He also touches on “Open Source 101”, a conference he recently attended in Raleigh, NC. After an important fauxmercial message, he interviews Raymond Camden, an Evangelist for IBM.  Ray discusses his recent interests in static site generation and in serverless applications.

You can find out more about Raymond on his blog (https://www.raymondcamden.com).

Subscribe:

google-play-badge

Transcript:

Script:
Welcome to Episode 4 of the “Wake Up! With Script Van Winkle” podcast. My name is Chris Laning, aka “Script Van Winkle”, but my friends call me…..very rarely.

Now I am going to start off this episode with a mea culpa of sorts.  When I started this podcast I thought it was some grand stroke of marketing genius to create the Script Van Winkle persona. You know, the grizzled old developer who got way behind in technology and is desperately trying to play catch up.  Though come to think of it, the only part that that is made up is the name..

Well, then in episode 2 I got the really bright idea to add an acerbic sounding and very bad NY accent to the character.  Now I don’t drink so I really have no excuse for what I was thinking.

Lately though, I have come to the realization that these days, especially in this political climate, with so many people on both sides of the aisle puffing themselves up on Social Media and the like and talking tough from behind their keyboards, that being genuine is what stands out. Forgetting insecurities and opening up to each other and just being….real.  So while I am still hoping my self-manufactured nickname sticks, I am dropping the terrible accent and phony hard edge and am instead going to focus on the content more than the delivery. Don’t worry though, I still plan to keep cranking out the funny commercials!

This podcast will still document my journey to catch up with the state of the art, but I am going to steer it more in the direction of interviews with people about a wide variety of subjects throughout the profession.  This is because part of my journey also involves me being burnt out with what I am doing and my searching for a new passion within the community.  I know I am not alone. We all burn out from time to time and need to retool, revamp, and go in search of greener pastures.  So hopefully you will want  to explore those things along with me.

Ok…enough of the touchy feely stuff. Let’s get down to business!

A couple of weeks ago I attended an event called “Open Source 101”. It was a one day conference held in Raleigh, NC that focused on sessions around the basics of open source and encouraged attendees to jump in and become part of the open source community. It was put on in partnership with the folks that run the All Things Open conference,a huge open source centered conference which is held in October in Raleigh as well. It was a great turnout and featured attendees ranging from the college-aged to the decidedly more seasoned.  The attendees also covered the gamut from highly accomplished developers, to experienced developers looking to add to their skill set, and  yes Junior Developer I saw you there too.  But there were also attendees who weren’t developers at all.  Some were managers looking to understand their development teams better and some were people looking to switch careers and become developers.

Now I am not going to lie.  I did come out of most of the break out sessions I attended a little disappointed. It is quite possible that I set unrealistic expectations on what I would get out of each of those. So that could be on me.

The day also started with not one, not two, not three, but a whopping four “keynote” presentations! Now most conferences I have attended have either exactly one keynote or at least no more than one a day. But they kept using that word…and I do not think it means what they think it means.

While I was disappointed in some of the aspects of the conference that does not mean I regret going. You see it gave me a glimpse into another world of programming I have only touched upon.  Certainly I have consumed a few open source libraries over the years and even work with both an open source content management solution and shopping cart solution. But there were a lot of terms and products being thrown around that I sheepishly admit I did not know.  I felt like fish out of water.

The reality is that most of us work in our own little subsection of the programming verse. Maybe some of us have our foot in one or two other subsections as well either due to having multiple clients, or having personal projects quite different from our daily work ones.  And I am sure there are a few people who have a foot in several of the subsections simply because they are driven by a passion to know and learn as much as they can.  

In most cases though we are fairly familiar with the products and people in our subsection and blissfully unaware of those in others. This point was driven home to me in an interesting way at this conference.

As I mentioned before I have programmed in ColdFusion for nearly all of my 20+ year career.  That is the subsection I am most familiar with.  Until recently, the conferences I have attended were either entirely or mostly CF-based.  At those conferences, all you had to do is  simply say  the name “Ray”, and everyone knew who you were talking about.  Raymond Camden was a rock star in the CF community!  Kind of still is though he doesn’t work much with ColdFusion anymore.  But his face and name were instantly recognizable, and admittedly I always found myself a little tongue tied when I would try to introduce myself to him.

Raymond was one of the keynoters at Open Source 101.  He gave a great talk on how to identify the best open source projects for you to jump into. And his slides were filled with his signature use of cat pictures.

What was surreal though is that very few people at that conference knew him.  Now to be fair there were likely a number of Open Source rock stars there whom I didn’t know from Adam.  But it was different to not see a  huge pack of star struck developers vying for Ray’s  attention. Well, naturally I swooped in and took advantage of the opportunity and spent some time talking with him. He is a very cool and very humble guy. He even graciously agreed to an interview about topics that appeal to him.  That interview is coming up here in just a bit so hang on.

But the point I am trying to make and one that I better appreciate after attending Open Source 101 is the sheer enormity of the programming verse. There were so many different things there at that conference and yet it was still mostly focused on the web app side of things, which is in and of itself a small subset of the  much larger programming universe.  It’s a good thing to keep in mind when you have gotten burned out at your current job or miniscule subset of programming.  Even when your passion for it grows cold, which truthfully is the point I am at currently, there are so many areas to explore that could easily renew and reinvigorate what drives you!  So keep searching! Keep going! Keep growing!

Now Ray’s presentation clearly had an impact as I heard his name referenced in each and every one of the breakout sessions I attended, often by that session’s presenter!  I guess when you got it…you got it. So stick around, you are not going to want to miss my interview with him coming up right after this!

FAUXMERCIAL: Kitty Point

(Dark ominous music)

Announcer (in serious tone):

Mice. They may be cute in the cartoon realm, but in the real world they are disgusting rodents that can spread dangerous diseases like: Salmonella, Hantavirus, leptospirosis, rat-bite fever and even the plague!

And yet billions of people across the world come into contact with these dangerous entities each and every day while performing their work duties or surfing the net. In fact, odds are you have your hand on one of these disease carrying monsters as I speak!  It’s time to rid your home, your office, and your life of these repulsive rodents!

(Music changes to upbeat infomercial music)

Announcer (in upbeat tone):
Introducing Kitty Point, the fun, furry, feline optical pointer device from Peripheral Pets Incorporated. Kitty point makes it easy and relaxing to direct that pointer around your screen.  Just plug its USB compatible tail into your computer and its patented purr and play technology does the rest.  Scratch Kitty points left ear to move left and right ear to move right. Scratch the top of its head to move up and under its chin to move down. You can even scroll down by stroking Kitty point from head to toe (WARNING: Scrolling up can cause bodily harm). Kitty point comes in three softness styles including:   long hair, short, and the smooth and sleek Sphynx. A wireless Manx version is also available. Sorry dog lovers, pointing devices are strictly a game of cat and mouse.

Kitty Point is great for desktops but much prefers laptops! We guarantee you will simply adore Kitty Point. So get rid of the rodent, get your Kitty Point today and soon you will see just what we meme.

(Fauxmercial ends)

Script:
Welcome back to the “Wake up! With Script Van Winkle” podcast.  Let’s get right to my interview with Raymond Camden. Please note though that  this interview was recorded before I made the decision to lose my phony accent, so just bear with me on that. Besides, what Raymond has to say is far more interesting!  So here he his, Raymond Camden.

(Interview begins)

Script:
All right, so here I am walking around the Open Source 101 Conference, and who do I run into, but Ray Camden. Now, if you’re from the ColdFusion community like I am, he was a literal god. I mean, I remember seeing Ray back at the Allaire Conference, in DC in 2000. Confidentially, he looked a lot younger then, but then so did all of us.
Ray has kind of moved on from ColdFusion. He’s doing other things. But just to have him here, and to talk with him, I just wanted to get that out to you, and find out some of the exciting things he’s working on now. Welcome Raymond.

Raymond:
Hey, thank you for having me.

Script:
So again, I’ve talked about you had a background in ColdFusion and all that. What do you actually do currently?

Raymond:
I’m an evangelist for IBM. When I first joined them, I was working with a mobile enterprise server type thing that was really hard to sell because it was big and highfalutin. I was allowed to keep talking about mobile stuff, and I do a lot with Apache Cordova, which is a open source framework for using the web to build native applications. IBM was in favor of me doing that. Since I joined IBM, I switched to another team that is focused on Node.js, and APIs, with a product called LoopBack, which is an open source framework for building APIs and Node.js. I feel like I’ve said Node.js a lot.

Script:
That’s all right. I actually was going to hit you up when I back at NCDevCon, but I did sit in on your LoopBack presentation there, and Node is kind of an area that I’m hoping to really push into, as my listeners know.
But moving on from that though, one of the things that I asked you today that you wanted to talk about was this new idea of a serverless application. Let’s just pretend that some of our listeners, and maybe one of our hosts, doesn’t know what you mean by serverless. How would you describe it?

Raymond:
Well, sure, let me go a bit high level, and kind of talk about like my history of building web apps. I’ve been doing this since ’95 or so, so for a very long time. For most of that time, what I did was I got an app server and it was ColdFusion, but you can imagine PHP or .NET. I had this large application server, and I would talk to a database. I would generate HTML files. I had a big honking server to build my web apps. That worked fine for a very long time.
What has happened in the last five or six years is that the browsers are able to do a lot more. What we need to do on a server has gotten smaller, and smaller, and smaller. There’s two areas that I think are really exciting that relate to that. The first is static site generators. This is essentially the ability to have a dynamic server locally on your laptop, but it spits out to plain HTML files. I love that because it means in production, I don’t have Apache, ColdFusion, MySQL. I have files period. That means I worry about absolutely nothing. Not having to worry is a great thing.
To be clear, I’m still doing work. It’s not reducing the work. It’s basically saying, you know, my complexity now exist on my laptop, which I’m fine with, versus a server that may crash at three o’clock in the morning. That’s kind of like part one.

Script:
Oh, so basically, this would be kind of roughly comparable to a, saying a real-time application versus compiling it.

Raymond:
Yeah, so instead of having a live server that’s running ColdFusion or PHP, or even Node.js for example, it’s literally a flat file because I’ve taken the dynamic aspects that are potentially not changing very much. For example, I’m using ColdFusion to get a list of the Board of Directors. That’s a table that changes once a year maybe. There’s no reason to “SELECT * FROM EMPLOYEES“ to get that. Even if I cache it, there’s just no reason to do that live in production. I could take the static results from that because it’s a virtually static, and then not have to worry about running MySQL or SQL Server in production.
To me, that’s extremely exciting. I look back at the sites I’ve built in ColdFusion, and most, not all, but a lot of them could be static. Same with Node.js as well, you know. I went through a period of changing all my CF sites to Node.js. Now recently, I’m taking some of my Node.js stuff and turning them into static sites as well.
I said there were two main things. Serverless is like the second aspect of it where I may use Node to do something, ring cowbell. That’s kind of a bad example. In order to do that, I had to set up a web server, which was very easy with Express. I was still setting up a web server, and I was saying, “Start this application. Listen on port 80. Listen for a request for ‘/getcowbell’, do whatever it was, talk to Mongo, whatever crap I’m doing in the backend. Take the result, JSON, and spit it out.”
Serverless takes this idea … You know what? Let me handle all that particular routing for you. Let me handle the web request and all that. You literally just write the function. I think a better name for serverless is “function as a service”, where I can take that small function and deploy just that. I still have a server out there, but I’m not worried about actually running that server.
If my thing was addition, so take X and take Y, and return what they are together, I’m literally writing just X plus Y. I’m not writing all the routing and stuff to handle responding to that request. Hopefully, that makes a bit of sense.

Script:
Yeah, it kind of does. Where I’m getting a little confused here, you’re taking that, and you’re pushing it out to what type of service is going to run that?

Raymond:
Right, so there’s definitely a server involved with that. Amazon has their product offering Lambda. They have a server running, and you upload your action to them. They have a command line, I believe. So does IBM Solution, OpenWhisk , which is open source actually. It’s not just IBM Solution. I write my function in JavaScript, and they support Python, and Java, and maybe Go, I think. They support a couple of languages.
Essentially, I write my simple function. Take an addition. I write return X plus Y. It’s just a JavaScript file. I use a CLI to push it online. IBM’s Bluemix service hosts that file. They handle all of the routing. I don’t worry about setting up the server, or anything like that. I have my magical addition function, which by the way, don’t use addition for serverless. I have that and I’m not worried about provisioning, even like a virtual server, which is pretty darn easy. I’m not even worried about that. I literally worried about my one and two lines of business logic, and that’s it.

Script:
Alright, so let’s say you pushed that service up there. Now you have an application you want to use that service. Are you making an AJAX call of that?

Raymond:
Everyone does this a bit differently. I’m only familiar with IBM’s OpenWhisk version of that. The way they do, is they have a couple different ways that you can execute what they call a action. One of them is by providing a REST API. I could say for my addition, I want it available via GET, and not POST, or POST and not GET, whatever makes sense. I could define a URL for that, and I’m done. That’s it.

Script:
Now this is interesting because I … Back at the NCDevCon, they were talking about microservices and I kind of got all into that. Now you really got me interested in this. I don’t even have to worry about laying out the service, and getting that all. I just write a function, put it up there, and then I just access from whatever I need.

Raymond:
Right. The scenario to like push out a web app nowadays is a heck of a lot easier than it used to be in the old days. Especially with Node.js, right? I can write my Node.js application. I can use Express to handle all that web stuff. It’s all very, very easy. I could have, like say, four services. I define four routes. The particular URL params. Do that. I can deploy that to Bluemix or any of the variety of services that let you push a Node.js app, and be up and running in five minutes.
Serverless actually makes that even simpler than that. I don’t have to worry about setting up a Node.js server because OpenWhisk will do that for me behind the scenes. I don’t have to worry about the routing because it can do the routing for me. Essentially, it reduces the complexity around my microservices, and lets me just do the microservice, as nothing more.

Script:
Now at the risk of getting jumped and beat up here at an open source conference, let’s say you wanted to monetize that. Is there any applications that you can use to monetize that?

Raymond:
I’ve not looked into this. Technically, when I build, again, my simple addition service, and I create a REST based API for that … Again, it’s all pretty simple … I can require a username/password, and I can do validation. I could do billing based on how many times you call my particular service. There’s probably nicer, more enterprise ways of doing them. IBM may be working on that. Because I don’t deal with money ever, I don’t worry about that. My main answer is I don’t know. It’s definitely possible. Just how nice that is, is something I’m not very familiar with.

Script:
Alright, so thinking ahead to the bright future that might be involved here. It’s got to obviously vary by application, but if you looking ahead, what rough percentage of applications codebase do you think might ultimately benefit from being serverless?

Raymond:
That’s a great question. Because I’m doing the same calculations for static sites as well when I present static sites, and when I present serverless. I’ve had to be careful to make sure people know that this is not a 100% solution. It’s not going to kill Node.js as a server, or ColdFusion or PHP. Determining when it makes sense for you is like step one.
In terms of percentage, I’m just going to throw out 50% because I really don’t have any ideas. It depends on what you’re building, how complex it is, and just what your services is. If you’re building like a giant bank site that has a lot of content, and it has user sign-ins and all that, then you’ll definitely want a traditional app server. You may be using some microservices behind the scenes, but you’ll want something on the front end. You’ll want a CMS and all that.
If your service is just the weather, then you could possibly get by with something a lot smaller and a lot simpler.

Script:
Do you have any tutorials out there yet? Are you working on some projects you going to kind of put out on your blog?

Raymond:
Since late December, I’ve been blogging on serverless. Essentially what happened as things slowed down, and I got bored, so I finally looked at something that IBM had been talking about for a little while. I’ve written maybe 10 posts so far, so if you go to my blog, on the right side there’s a category list. There should be one for OpenWhisk. I have a tag for serverless or vice versa. You can quickly see the stuff I’ve done.
I’ve done basic how-to guides plus some examples. For an example, I built an application, this is totally not enterprise. What it does is it looks on your phone, and it finds all the contacts who don’t have pictures yet, where you haven’t assigned a nice picture to them. For those contacts, it calls a serverless function I wrote in OpenWhisk that returns a random Marvel superhero, and their picture, and name as well. So the service returns that, and then the app, which is running Apache Cordova, using Ionic, it updates the contact. Joe Blow becomes Miss Marvel, for example, and you’ll see that picture when Joe Blow calls you.

Script:
That’s a marvelous use of a technology there. Before I let you go, because people are going kill me if I don’t ask you about it. What is with all the cats?

Raymond:
I like cats. It’s simple. You know, since I’ve joined IBM, I keep waiting for someone to complain about the way I do presentations. No one has yet. Before I joined IBM, I really had this impression that they were old and stodgy. While they are old, they definitely are not stodgy at all, which is pretty cool. I work with some great people.

Script:
That’s awesome. Confidentially, between you and me, I’m a cat guy too.

Raymond:
Yeah …

Script:
If somebody wanted to find your blog or more information, Ray, how could they go about it?

Raymond:
Just go to raymondcamden.com.

Script:
Hey, that’s nice and simple. Well, Ray, I want to thank you so much for taking the time. Appreciate it, and I look forward to running into you at future conferences.

Raymond:
Thank you for having me again.

(Interview ends)

Script:
So that wraps up Episode 4 of the “Wake Up! With Script Van Winkle” podcast. If you’ve got questions or topics you would like me to cover, drop me a line at  script@scriptvanwinkle.com 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 scriptvanwinkle.com.

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

 

Episode 3: Fishies, Legos and Play-Doh

Description:

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.

Subscribe:

google-play-badge

Transcript:

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 ScriptVanWinkle.com.

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 script@scriptvanwinkle.com 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 scriptvanwinkle.com.

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

In a Fog – #NCDevCon Day 2 Live Blog 1

NCDevConLogo

NCDevCon North Carolina’s Premier Web & Mobile Conference

Day 2 of the the awesome tech conference #NCDevcon is well underway.  Participants were treated to a beautiful if not eerie fog which had settled over the area this morning.  Quite a few participants seemed to be in a fog too including yours truly.  Thinks are so much quieter this morning. After receiving all that amazing information yesterday it seems many are still processing. But who has time for that?!?  Still another day’s worth of learning ahead!

I kicked off my day with Building APIs in LoopBack by Raymond Camden.  Again, I am learning Node.js and have a few personal projects I want to build as APIs, so this was a natural.  It was a two session period with the first being discussion about LoopBack api framework and the second being a hands on session build an API.  To be able to do the handson stuff I needed to get my laptop set up with Node, LoopBack, and MongoDB.  I spent a good chunk of the first half trying to pay attention to the cool information and whip this old laptop in shape. The laptop refused to cooperate in the end…so I went “hands off” and bailed at the halfway point. Sorry @RaymondCamden!  Was looking forward to the hand on stuff. I am sure it was a blast!

So I hopped over to Git Source Control: for the Rest of Us by Nolan Erck (@southofshasta).  It was a great talk on using graphical tools like SourceTree to work with source control (Git in this case). I knew most of it of course, but still nice to see how other people set up their source control.  Big crowd. Lot’s of questions.  Good session!

Planning to wrap up the day with You Don’t Know Node.js by Azat Mardan (@azat_co).  I have some personal business to handle this afternoon so sadly I will be missing  the cool stuff planned for the afternoon.  I’ll split right after I grab lunch. So grab me there (and early into it) if you want to chat me up.  Otherwise, enjoy the rest of the day!  It has been a pleasure hanging out and meeting all of you.

 

© 2018 Script Van Winkle

Theme by Anders NorenUp ↑