When going into it, I started with a pen and paper(well actually an iPad and pencil) and tried to picture how I wanted the request cycle to go for starting a command line interface project from a virtual terminal. I knew I needed a webpage, along with some AJAX to update the view and send inputs. I also knew that that, a virtual terminal couldn't be shared like a web server, I mean, what if there was only one virtual terminal shared between all users? That would be chaos.

So I had my work cut out for me.

A classy rewrite.

My first step was migrating the demo.coffeedust simple rack server to something a bit more usable. I didn't want to go rails since I had no use for really any of its features. The only thing I needed was a better routing system and sessions, so when I implemented the new terminal I could have controllers, routes and sessions up and running in no time. So I decided to go with Sinatra. The rewrite took a little longer than expected but in the long run, it made the implementation of the new terminal feature much easier.

Let's get to building some terminals.

Now to begin the tricky part, having one session = one new virtual terminal instance.

As I mentioned before, each user had to have their own terminal, with their own independent running project demo. So I started crafting a virtual terminal object and it's properties, mainly it's thread that the project will run on. I've previously dealt with multithreading in ruby before. Much like JavaScript, multithreading in ruby is concurrent, it operates on a single system level thread in a loop.

This thread would need to be responsible for dispatching commands and catching outputs. It would also need to keep track of the output history and somehow, it would need to sync up with the web controller to send the output to display on the webpage.

I was able to override the puts and gets methods on my project, that way I didn't have to do any major altering in my project's original code.

I overrode the gets method to where is doesn't even response to the Kernel, but instead to my terminal's project thread in a similar manor. Syncing all of this up was very technical, but I was able to mirror the functionality of those methods, so it communicated perfectly with my controller and web page.

The bugs.

There were plenty but I worked through them and it was a great learning experience for me.

A big issue I had was memory sharing between terminal sessions. Even though I had separated everything into different threads, I noticed that any objects that were created and stored in a separate file in the project, would not be scoped to that thread, but rather, it was scoped to that file, meaning you could have 2 instances of my Inventory Manager project running, but the .all class methods for non persistent storage, was all shared between instances because they required the same file. This would cause issues of objects being duplicated and removed in memory for all sessions. That wasn't going to work!

So I was able to override some of those storage methods, and assign them to arrays and hashes that were held in that thread instead of a file that was shared between everything.

Problem solved.(at least that one 😬)

What do you mean "command not found"? It worked on my system!

Now to run some implementation tests on the server, And… I found a strange bug. All of the virtual terminal code worked, however my project, Inventory Manager, was not recognizing commands when trying to view items. But it appeared to be random, and sometimes allowed for an item to be shown as it normally should.

After quite a while of some deep think debugging, I determined the issue was actually an error when calling a method, however because of try-catch implementation(it was my first project 😬) it would default to "command not found."

What was the error? Because I was using ObjectSpace and id2ref to find Items in memory (I know, again I plead first project) I was getting a "could not find object with that id" error, but only when an object was assigned an ID that was negative. I never had this issue on my computer because it has plenty of RAM that it never needed to assigned negative ID's, whereas the server, has much less RAM.

After going into a binding.pry, I was able to figure out that, for some reason, the object ID that was being passed to my search method, did not include the negative symbol (-). Turns out, the regex I had, only matched digits and not letters when sending that method. After updating the regex pattern, success, it all functioned properly. 👌

Overall, as I mentioned, the main reason I didn't use REPL-IT to run my CLI projects was because it felt like cheating. After all this is my portfolio site, there to demonstrate my skills. If possible, everything on that site should all be made by me. Also I really wanted to challenge myself, and I knew I would enjoy every minute of it, and I did!

Check demo.dust.coffee's innards here on GitHub: https://github.com/Coffee-Dust/demo-coffeedust-io

And don't forget to try it out yourself by starting the Virtual Terminal interactive demo at https://dust.coffee/projects/inventory_manager

Screenshot of the virtual terminal running Inventory Manager on demo.dust.coffee

Well, I'll tell ya. I was thinking ahead!

When designing the database, I knew I wanted to add more 'elements' in the future. So I planned for such a thing. I used a polymorphic database model for those elements, which allow me to keep my code DRY and pretty.

When coding the frontend, it was slightly more complicated to implement this functionality. I had to make sure I named everything in a semantic way, so I could easily figure out where code for the new element needed to go. With me following the Separation of concerns principle during the initial creation, I was able to figure out which files were responsible for 'element' objects and I setup the new FancyiFrame element, in around an hour!

Now I just need to improve the UI and UX for creating elements 🤔

Do I sacrifice a few cups of coffee to pay for hosting all my demos?

You probably already guessed my answer to that, no. Instead, I bought some coffee and got to thinking. I figured that there was no reason to host all my projects separately and have them run all the time. Instead I asked myself “what if I could have a server that started other servers?” A server within a server? :O

How could I do such a thing?

It was actually pretty simple to setup. I used Rack(what rails is built on) as a basic web server that would listen for a button press on coffeedust.io and then dispatch a start command in bash to run that demo. I foresaw a few issues with that approach however. One issue would be, how would I make that demo server run without blocking the main parent thread? Also, how would I have the server shutoff after a certain amount of time inactive?

Giving Parallelization a Good Bash(script)

As I have quite a bit of experience with Unix commands along with multithreading in Ruby, I was pretty confident in my ability to make this idea come alive and solve those issues. I first solved the issue of the main thread being blocked while the demo was starting and running. So I decided to make a parallel process with Unix’s Fork command and… Viola! No more blocked thread. However, the demo keep giving me an error when I ran it’s start command. Saying how it was missing a gem that was definitely in it’s Gemfile.

Then every programmers worst fear. No answers on stack-overflow!

After quite a bit of googling, I realized that no-one else has either attempted what I was doing, or never had this issue before. I was getting pretty discouraged, but I never gave up and I started doing some deep think debugging. First, I tried to figure out what exactly the problem was. I ran bundle install and got a success message. But I looked at the gems it installed, and they weren’t the correct ones, it was actually using the gem file for my Rack server, not the demo!

Very confused about this, I figured that maybe I wasn’t in the correct directory when running the server. After confirming I was indeed in the right directory, I was very much confusion. I then ‘traced’ the code’s steps and looked through the gem files, bundler settings for both servers and I found nothing that could be causing the Gemfile location issue.

After taking what I knew already and ruling out what I knew wasn’t causing it, I realized that the issue was not with my code, it was almost like it was an invisible configuration.

Then it hit me! There is an invisible configuration hash at the system level. The ENV hash! I then looked at it at runtime, and sure enough, there was a configuration for the Bundler Gemfile location. As the demo sever is a forked process of the Rack server, the ENV hash would have been copied. Thus the Gemfile that the demo Rails server was using, was indeed the one belonging to its parent process, the Rack server.

After resetting that ENV hash attribute in the context of the new forked process, the rails server for my demo ran, and it was all sunshine from here on.

But I don’t want the demo to run all the time if it’s not being used…

If this was Javascript, I could simply do a setTimeout to send a shutdown command to the process after a certain amount of time. However, this is Ruby, and asynchronous tasks ain’t that simple. Some might even say, such a thing is impossible, however, Ruby does have a concurrent multithreading system built in! So, I used that system to create an asynchronous shutdown timer, so after 15 mins, it will stop the demo server process, all without blocking the main thread.

Next, all I had left to do was configure this server to be able to run my different projects and code some bash scripts for correctly installing those demos and their dependencies on the server’s machine. After wrapping everything in a nice Docker container, it was ready to be installed on my one server machine.

It was quite a challenge but I loved every minute of it! It made me realize that backend and technical development is my passion, much more enjoyable than frontend development with CSS & HTML.

Mission accomplished! Just one server needed to run and host them all! All my project demos. Thanks for reading 😄

github repo for the project: https://github.com/Coffee-Dust/demo-coffeedust-io

Then that fateful day came.

I was staring at the assessment report of my final portfolio project, reading about how it explained that I passed with flying colors. It was at this point I realized, it was time, time to make that vision of my website a reality!

Building Coffeedust.io(now dust.coffee)

Github Repo

Creation of coffeedust.io, was relatively simple. It is an web application built in React, and hosted on Firebase. I first started with a sketchpad and I drew up the basic layout.

My original sketch for coffeedust.io layout(I'm not an artist)

Next, I slowly but surely, hit enough keys on my keyboard to make it appear that way in a web browser. Then, I started to get really fancy with the CSS, and wrote transitions, fade-ins and animations for various views (actually, pretty much all of them😬).

After creating some data files to store information for my projects and language experience, I took a (figurative) step back and a full sip of coffee to admire my work and I was really happy with how it turned out.

Don’t forget to read part 2! It discusses my demo server creation process.

My achievements:

Swift/SpriteKit — The 8-bit Master:

After graduating high school, I went full force into learning programming on my own. I had a vision of a game I wanted to create. Although I did not have any formal/professional training in the language, I quickly got the hang of Swift and SpriteKit. I even did all of the graphics, artwork and even the music. I learned many things along the way, not just about Swift, but about software engineering in general. Before I knew it, I had a functional and pretty impressive game published on the App Store.

Flatiron School and my Portfolio Projects:

After completing my game, I realized that I should get some professional education in an employable field. I decided on full stack web development and enrolled in Flatiron school. During my curriculum, I learned many programming techniques, especially in Object Oriented programming. I further grew and improved on my previous experience in programming and learned the best practices and rules when writing and code and designing applications, along with many other things that I previously did not know.

Ruby — TicTacToe with AI:

(Many references to WarGames(1983). You have been warned.) Tic tac toe, a strange game, the only way to win against my AI is to press control + c before getting a tie. This was one of my first challenging projects with my school. My approach to building this project was a bit different than most students, basically I reversed engineered TicTacToe in order to build an unbeatable algorithm. I drew diagrams to help me visualize the logic flow of how such an AI would need to function. I went through and made notes of steps it would need to take in order to win, and also figured out how to prioritize those steps based on the state of the game. Ultimately, I built an unbeatable AI from scratch that may or may not eventually figure out “the only winning move is not to play.” This project was very challenging, especially for not having that much experience in programming, but it was a lot of fun to design, build and figure out on my own.

Ruby — Inventory Manager:

This project is a full SQL-less command-line interface database program. Why is it SQL-less? Up until this point, I had no knowledge of Structured Query Languages or how databases worked. What I did know, was how to create ruby objects in memory and relate them to each other. Now, the main premise of this project was to scrape data from the internet and allow the user to interact with that data via CLI. I read a little too much into it(actually a lot) and I ended up building a full inventory software that can Create, Read, Update, and Delete data, as well as organize and categorize that data. It scraped mock data for items from Publix’s website and as such, that took a long time. I realized that it would be pointless and take forever to scrape data every time the program ran and lose that data whenever the program quit. I looked into ways to quickly save data and decided to convert those ruby objects into hashes that can be written to a JSON file. The school’s courses never taught me on how to do this. I learned and built this parser by reading documentation and StackOverflow. In the end I had built a really impressive data manager with an intuitive command-line interface.

Ruby in Sinatra Framework — The Local Coffeeshop:

This was my first project in the world of Server Side web programming, as well as relational database design. I used technologies such as SQLite, the ORM ActiveRecord, Rake and Rack. I learned a lot about how the internet works, how browsers interact with servers on getting and posting data as well as conventions in web design, such as RESTful routing. Overall it was a great learning experience and I went above and beyond the basic project requirements.

Ruby on Rails — Coffee-Beans:

This project really cemented things I had previously learned. It also taught me about important things that make the internet the useful place it is today, such as sessions and cookies and how they work with authentication of users. I implemented views to display data using ERB and as far as the database design was concerned, I implemented something that the school had previously not taught me, polymorphic associations. You can read more about it here: https://coffee-dust.github.io/coffee-beans_social_my_rails_project

Javascript — My Coffee Table:

Learning a new language is hard, and Javascript is no different! In fact, some may argue that it is one of the most frustrating languages to learn. However, although it was very different from all previous languages I have learned, with its prototypal inheritance model and functional based programming, I did enjoy getting the hang of it and applying that knowledge to a real world use. This project really demonstrates that. With my use of OO ES6 Javascript syntax and design, event driven DOM manipulation and fetching data from my rails server and parsing that data into something Javascript can use. Overall it was a fun learning experience and I really enjoyed building this project.

React/Redux — React Coffee-Beans:

Javascript can be difficult to design and organize when you have to update the DOM and build interfaces that react to user input. It can get even more difficult to keep code organized when you have to update the DOM based on an async event, such as when you fetch and receive new data from a server. This was something I realized on my last project. JSX was a great thing to learn about and learning how the React framework can auto update the DOM when values in state changes, along with how it organizes elements into reusable components, was a great improvement over dealing with countless query selectors and adding event listeners that update values using more query selectors all while trying to connect it to a separate HTML file. Although React was a bit confusing at first, it is a very powerful tool that I am glad I learned. This project really demonstrates all the things I learned about react and I was able to build a single page version of my rails project ‘Coffee-Beans’ that can do everything, all without ever refreshing or redirecting the page.

So what about that initial question?

Along this journey, I have learned a lot and built a lot of impressive things. So what will I do next? Well, for one, I will continue to learn, grow and create software that will hopefully enhance the lives of those who use it, and find a Team/Company that will help me do just that.

WarGames(1983) AI Joshua playing TicTacToe

Tic tac toe, a strange game, the only way to win against my AI is to press control + c before getting a tie. This was one of my first challenging projects with my school. My approach to building this project was a bit different than most students, basically I reversed engineered TicTacToe in order to build an unbeatable algorithm. I drew diagrams to help me visualize the logic flow of how such an AI would need to function. I went through and made notes of steps it would need to take in order to win, and also figured out how to prioritize those steps based on the state of the game. I had to make my AI think to the future and decide which move to take, a move that will not only cause it to stop the other player from winning, but immediately identify threats that would cause it to loose and ultimately pull off a win/tie.

Ultimately, I built an unbeatable AI from scratch that may or may not eventually figure out "the only winning move is not to play." This project was very challenging, especially for not having that much experience in programming, but it was a lot of fun to design, build and figure out on my own. You can find my project Github repo here.