Forem: Bevin Duncan

'Splain Like I'm Five: We Are Living in a Simulation

Bevin Duncan — Wed, 20 Apr 2022 20:43:10 +0000

Ever wonder if you are just an NPC in a videogame? You're not alone. The idea that the entire universe and everything in it could be a simulation has been the "shower thought" of humanity since philosophers of the ancient Greek, Aztec, and Mayan cultures, who mused about the possibility that our reality may be nothing more than a book, a painting, or simply a fever dream of the gods.

The dawn of the digital age inspired contemporary philosopher Nick Bostrom to postulate on our existence in a simulation as a very real possibility. Predicting that future humans will be capable of vast amounts of computational power (around the year 2050ish), Bostrom presented a trilemma called "the Simulation Argument". Bostrom's trilemma, presented in 2003, suggests that one of three possible arguments must be true:

The fraction of human-level civilizations that reach a posthuman stage (that is, one capable of running high-fidelity ancestor simulations) is very close to zero.
The fraction of posthuman civilizations that are interested in running simulations of their evolutionary history, or variations thereof, is very close to zero
The fraction of all people with our kind of experiences that are living in a simulation is very close to one.

Bostrom's logic continues: "If (1) is true, then we will almost certainly go extinct before reaching posthumanity. If (2) is true, then there must be a strong convergence among the courses of advanced civilizations so that virtually none contains any individuals who desire to run ancestor-simulations and are free to do so. If (3) is true, then we almost certainly live in a simulation."

So, what's the consensus? Depends on who you ask. Other proponents of the Simulation Hypothesis include Neil DeGrasse Tyson, Elon Musk, and Phillip K. Dick, all of whom have publicly expressed a belief in the possibility that we might be living in a simulation.

Arguments For:

True: A constant of any computational processing system is the "artifact", or the upper limit of its processing capability measured in terms of its processing speed. Also true: the differentiation of processing capability (or any additional hardware components) between programs is functionally irrelevant for any operations within the simulated reality of the program except when it is discovered as the maximum container size for that program. In other words, the observer within the program (the program itself) has no frame for quantifying its own processing capability except when it presents itself as an upper limit (aka the "artifact").

It serves to follow that if we live in a simulation of some kind there would be an artifact of our simulation's processing capability. So what is the upper limit in our universal simulation? Can you guess it?

That's right! It's the speed of light. If a maximum limit on the container size for a computer program is its processing speeds, the maximum limit of space on which one operation can be performed would appear in our universe as a maximum speed. We don’t know what hardware is running the simulation of our universe or what properties it has... but one thing we can say is that the memory container size for the variable "space" would be about 300,000 kilometers if the processor performed one operation per second. This observation serves as the primary evidence for our existence in a simulation, barring our ability to otherwise measure the hardware and properties of our simulation should we live in it.

Consciousness for who?

Another argument for the possibility of simulated reality is a thought experiment about consciousness... the tldr version of this discussion from Fouad Khan's article in Scientific American is a counter-argument to those stating that the existence of human consciousness is proof that we DON'T live in a simulation. Khan posits that because A. we don't have a working theory for an evolutionary PURPOSE of human consciousness, the only purpose is to simply "experience" and B. that the "product" of experience that we are creating in the form of consciousness is not here as an evolutionary mechanism for our own use, then C. the product of experiential consciousness must be for the consumption of someone else.

Kahn goes on to discuss how the consciousness of a Grand Theft Auto NPC becomes essentially an extension of our own consciousness in gameplay, because we are effectively experiencing and emoting through the NPC. While that might feel like an evidence argument for an NPC gaining consciousness, Kahn suggests that it's actually the inverse... a metaphor for how our consciousness is simply a projection of a greater simulant's consciousness in the same way the GTA NPC becomes sentient of ours by proxy. Try not to go too far down that logical rabbit hole.

Arguments Against:

As with any currently unprovable scientific theory, there are going to be some naysayers. Physicist Marcelo Gleiser's commentary on simulation theory posits that posthumans would be entirely too high-brow for such a pointless endeavor as ancestral simulation. "[Posthumans]...being so advanced they would have collected enough knowledge about their past to have little interest in this kind of simulation. ...They may have virtual-reality museums, where they could go and experience the lives and tribulations of their ancestors. But a full-fledged, resource-consuming simulation of an entire universe? Sounds like a colossal waste of time."

Marcelo, honey... Have you ever met humans before? They'll literally spend hours trying to run a digital frog across a digital road. I'm sure prehistoric humans would have thought we'd find better use of our time with the kind of technological firepower we have at our finger tips these days, but they would be wrong. Assuming the priorities of people who don't exist yet might not be tenable scientific theory. ;)

Or there's Sabine Hossenfelder who essentially states "We can't possibly test this theory, so why even bother thinking about it?", which, to me, is the scientist equivalent of taking your toys and going home because you don't have advanced enough tools to measure your hypothesis. Not very sciency, Sabine!

And many more scholars who dismiss the hypothesis entirely by throwing around phrases like "merely philosophical", "unfalsifiable", or "inherently unscientific" (Unfalsifiable fact: Those scholars seem pretty unfun at parties).

Alternate Theories

If you're not ready to believe that the entire universe and everything in it is a vast computer simulation, there are other theories born of Bostrom's ideas that may be more palatable. For example, theoretical physicist Lorenzo Pieri, deferring to occams razor, thinks the reality is more "likely to be one of such Brain-in-a-Vat or 'solo players', as it is much easier to simulate the inputs to the brain than the full-blown reality".

Fair, but in the end does that distinction really matter?

Conclusion:

There is a compelling case to be made for at least entertaining the idea that we may be living in a simulation created by our post-human descendants. The alternative possibilities can only be that 1. Humanity goes extinct before reaching the technological capability to do so, or 2. that post humanity reaches the capability to, but not one singular posthuman would want to recreate our reality as an ancestral experiment. Proof that we may be living in a simulation can be found in studying the inherent qualities of computer systems, and if those qualities can be extrapolated to our reality. Which possibility would you prefer? True existence but inevitable extinction? Sim? Brain in a vat? The world is your oyster.

References

Confirmed! We Live in a Simulation

Simulation hypothesis

Nick Bostrom

Sabine Hossenfelder

Lorenzo Peiri

'Splain Like I'm Five: Model-View-Controller (MVC)

Bevin Duncan — Wed, 06 Apr 2022 21:05:28 +0000

The Model-View-Controller(MVC) is a popular software programming architectural style meant to efficiently implement graphical user interfaces on mobile and web applications. MVC describes a relationship between the distinct purposes of your code resulting easier readability and a "separation of concerns" when designing the flow of your code. The idea is that each section of your code has a specific objective and the MVC model makes it easy to keep each of those objectives focused on their respective jobs.

Model
The model portion of your code can be described as the raw ingredients of your app. This is where your database is kept, and where essential components of your app are defined. Models are where you structure what your app is about, and how it's expressed on a foundational level.

View
The view portion of your code can be described as the client-focused side of your app. The view displays the information organized through your models, and creates an environment where the user can see and interact with that information. View code is generally design-oriented and structured around a front-end framework of displaying data.

Controller
The controller portion of your code is the go-between the Model core and the View shell of your app. It receives user input, decides what to do with that input based off of available model data, and decides what to return the user display. Controller code is generally made up of action functions that make decisions about what model data is displayed to the user while interacting with the view code to display a user request.

All of these elements work together in a cycle: A request made by the user comes to the controller, the controller calls/ edits data relevant to the request from the model, then pushes the data to a template in the view. Once complete, the request is handed back to the application server as rendered HTML.

History
The MVC model dates back to the late 1970's, when programmer Trygve Reenskaug imagined MVC while working on the Smalltalk-79 project at the Xerox Palo Alto Research Center (PARC). His goal was to create a pattern most efficient for when users interact with a large, complex data set. His design initially had four parts: Model, View, Thing, and Editor. Model and View functioned as described above. Thing was a variant of controller, and Edit was a specialized kind of Controller that is created by a particular view and used to modify that View.

Reenskaug's MVTE model gave rise to the simplified MVC model, which three decades years later was the inspiration for developing the Ruby on Rails framework. The Django framework (developed for Python) put forward a similar design, the "Model Template View (MVT)" wherein the view component becomes a controller of sorts, and the template becomes the GU interface. Both Rails and Django debuted with a strong emphasis on rapid deployment, which increased MVC's popularity in the mainstream of software engineering thus making MVC an industry-standard to this day.

Similar Models

There are some variants on the theme of MVC that have evolved since Reenskaug's original configuration:

Hierarchal Model View Controller
The HMVC variant of the MVC configuration is essentially a scalable version of the same MVC functioning. HMVC creates hierarchy of parent/child MVC layers. Each MVC subgroup (also known as a triad) functions independently from one another, but can communicate via their controllers. This is particularly useful for applications with a large variety of servers, platforms and protocols, and that have a scaling dataset.

Model View Adapter
The MVA structure is ideal for complex computer applications that present large amounts of data to users. In this scenario, you may wish to separate data and UI concerns so that changes to the user interface will not affect data handling or data can be reorganized without changing the user interface. MVA is different from MVC by arranging model, adapter (a mediating controller) and view linearly without any connections whatsoever directly between model and view. One benefit of this structure is that multiple adapters may be created to change the way one view presents data for a given model.

There are many more niche software design configurations out there, too extensive for the scope of this blog!

MVC and its variants are the industry standard for a user-interface-focused architectural design in software engineering. Separation of concerns, explicit purpose of code, and defining specific roles for sections of code create an efficient and powerful model for an effective, client-minded website. MVC's logic can be traced back to the early days of computer programming, which speaks to its timeless usability for software engineers. Variants on the theme can be used depending on the depth of data set and/or the scalability needs of your website. No need to reinvent the wheel with MVC!

Everything you need to know about MVC architecture

Hierarchical Model View Controller

Schematics of Reenskaug's MVC paradigm according to his descriptions in Reenskaug (1979b)

MVC: Model, View, Controller

Model–view–adapter

'Splain Like I'm Five: Ruby REPLs and Pry

Bevin Duncan — Tue, 22 Mar 2022 04:00:22 +0000

Welcome to the Back-End! If you're reading this Ruby blog, you've likely made your way here through front-end web development.

"Ok, front end was cool--I had a nifty browser console in which to test my code. Code goes in, changes on the browser come out! Easy-peasy!" -You, probably.

Well, now you're in back-end. Sunlight in the form of a browser console doesn't reach back here. You're now working in terms of creating and passing data to and between databases, and none of those tasks require a browser to write or operate. So how do we test our code??

The simple answer: REPLs -- or Read, Evaluate, Print, Loop programming environments. REPLs are an interactive terminal shell which takes a user's input, evaluates it, and returns the result to the user. REPLs are a back-end programmer's most-used and most powerful tool for debugging and modifying code in real-time.

Ruby's REPLs

Ruby installs with its own built-in REPL called IRB ("Interactive Ruby"). You can enter the IRB environment by simply typing "irb" in your terminal. You're now in a "sandbox" programming environment where you can test your code functionality. The unfortunate thing about IRB is that it's not connected with your actual program in any way-- it simply tests the code, then you have to exit IRB and retype the correct code in to your text editor or through terminal in order to add it to your program. In other words, it's a bare-bones testing REPL that has no interactivity to your program.

PRY

PRY is one of many third-party REPLs in the form of a installable Ruby gem. It, too, creates an interactive terminal programming environment with which to test Ruby code, only with tons of extra perks. The two main perks of Pry that IRB doesn't have are:

It can loop through code and pause at intervals of user-specified subsections of code.
Interact with and test-edit your code without ever leaving the Pry programming environment.

"Runtime Invocation" with Binding.pry

Pry is, at its core, a powerful debugging tool. It utilizes a Ruby class, Binding, which captures the objects-- specified by its placement-- for use outside of the program (aka in the REPL environment). You can then "pry" in to that specific bit of code and inspect it. It works by adding the line "binding.pry" in to any (or multiple) parts of your code.

As the line is invoked during runtime, it will freeze your program and open a REPL environment so you may inspect that specific line of code within the scope it was called. If you, for example, place a binding.pry in the middle of a method, when the program runs your code it freezes upon the binding call and enters a REPL so you can explore the data within that method.

Command Shell Integration

Pry commands can be forwarded to the command line with the "." preface. This means you can navigate your file system, launch editors, run git commands, and utilize Rake directly from Pry!

Other features of Pry:

Syntax highlighting
Autocompletion (IRB has some, but very basic)
Introspection commands (list methods, variables, constants, etc.)
Documentation Browsing using pry-doc
And much more! Pry is fully customizable, so check out a full list of pry plugins here.

You Didn't Hear It From Me

Additionally, you can check out this video about some Pry hacks that are, on paper, not considered good practice... For example, editing your Ruby classes in-line using Pry. Yes, it's that powerful! But doing so does verge on the frowned-upon practice of "Monkey Patching" which you can read more about here.

I will say, taking 10 minutes to dive in to multi-line editing with Pry helped me understand how Pry works in the grand scheme of the command line and the program as a whole, so I found it helpful for context. You didn't hear it from me, though...

The Many Other Ruby REPLs and More:

Outside of the two most used Ruby REPLs--IRB and Pry-- there are countless other Ruby REPLs on the market, all with their own functional focus. This is probably because you can actually make your own Ruby REPL! Many folks have, and left them available on codebases like GitHub for public use.

Pry, though, remains the industry standard for debugging Ruby code in real-time. Pry is the best because you can freeze your code and debug at intervals of your choosing, interact with your code inside the REPL, and it has all kinds of other handy features and plug-ins to customize for your use! For a quick tutorial on how to install and use Pry for yourself, check out this article!

Give it a pry!

Resources

What is a REPL in Ruby? (IRB, Pry, and More...)

Debugging with Pry

Ruby Docs: Pry

Pry Irresponsibly - Things You Shouldn't Do But We Will Anyway

Monkey Patching in Ruby

What is Rake in Ruby & How to Use it

Make your own ruby REPL from scratch

Pry: A Simple Start

'Splain Like I'm Five: React Props and Components

Bevin Duncan — Wed, 09 Mar 2022 22:06:13 +0000

Among the many differences between React.js and Vanilla JavaScript, one of the most important is the interplay between Props and Components in React. The beauty of React is that your code is kept organized by compiling each individual subsection of your web page modularly -- in its own receptacle of code -- that is then referenced in parent receptacles. The component/props dynamic makes it easy to pass data and page functionality between subsections of your page. The benefits of modular coding via components and props include keeping code clean and organized, easier debugging, easier navigation, and a more manageable variable scope.

Components

Functional Components can be equated to a vanilla JavaScript function that returns JSX. A component is essentially a modularized function that returns a subsection of your webpage-- including the data you wish to display-- written in HTML. Components can drafted in to individual .js files, which are imported into sibling or parent Component.js files for rendering. All lower-level components are then referenced by your granddaddy index.js file to tie the components of your page together.

For example, you may have a "Cats.js" component on which you render your cat webpage Home Page functionality. You would then import your Cats.js component to its parent component (usually an App.js file) so it can exist with the rest of the components of your webpage.

Props

Props can be equated to function arguments in Vanilla Javascript passed as HTML attributes. Props are essentially a representative bit of variable data that can be imported and passed into child components as parameters. Props can be any kind of variable data type, though any prop that is not a string (numbers, booleans, objects, etc...) should be referenced in components with {curly brackets}. Prop object key value pairs are referenced with dot notation. One can also assign a "default prop" in the event that you need a default value to display in the absence of any assigned values.

Prop Destructuring

Sometimes we will want to pass an object as a prop. React has a lovely way of "destructuring" the prop object in our component so we may more easily use the key values of the object! Destructuring works by passing the props object imported in to the parent component and assigning them to variables with the same names of the object keys in the argument of the child component. See here:

Prop Drilling
Sometimes we need to send props through multiple layers of nested components to reach a base child component that needs to use the prop. This is referred to as "prop drilling". Prop drilling has some benefits, but is by and large is frowned upon as a practice. The benefits mean that there is a way to statically review the flow of the code without having to render any extra functioning or potentially break your code with complicated modifications. The main reasons prop drilling is so frowned upon include:

It often results in refactoring the shape of some data (ie, an Object: {catList: {name: 'Kitten Face'}} turns in to {Catlist: {firstName: 'Kitten', lastName: 'Face'}}) down the line.
It can result in over-forwarding props, or passing more props than necessary.
Conversely, it can result in under-forwarding props by way of abusing defaultProps-- Often times this results in not being made aware of missing props.
Renaming props halfway through (ie renders ). This evolution can make keeping track of the same prop differently named in another component tricky.

Component Lifecycle

Initialization: Props and/or State are assigned (State is an entire can of worms too big for the scope of this blog post, but you can read more about from how it works my colleague, Hannah Glazier, here).

Mounting:Then the component is "mounted" (created and then inserted in) to the DOM.

Updating: The component then undergoes the updating phase as soon as and every time props or state change.

Unmounting: The component unmounts from the DOM at the end of the cycle.

Here is a diagram of some of the possible rendering calls that can be made during the component lifecycle depending on the objective of your components:

Conclusion

Components and props are integral elements to the functionality of a React web page, and to cover their different use cases would make this an endless blog post. The basic points are: Components make your code modular, so they are easier to read, easier to debug, and easier to pass through your web application. Props are a way to pass all types of data through the component hierarchy with agility and ease, especially through methods like destructuring. Some prop methods, like prop drilling, can be helpful in some situations and hurtful in others. Components and their props are integral to the outcome of the component lifecycle, and therefore the functionality of your web page! As a software developer, I find using the component/prop system quite elegant in practice hand fun to boot! Happy modularizing!

Resources

React Props

React Components

React's Use State Hook by Hannah Glazier

Component Lifecycle

How to understand a component’s lifecycle methods in ReactJS

Intro to JSX

HTML Attributes

Introduction to the DOM

'Splain Like I'm Five: JavaScript Events

Bevin Duncan — Wed, 23 Feb 2022 22:03:42 +0000

It is safe to say that the heart and soul of any effective web page is the ability for a user to functionally interact with the contents of that web page. Being able to click on, scroll through, or input information through a web browser is fundamental to the usability of most modern-day web applications--from social media, to banking, to learning software engineering through an online bootcamp. But what exactly is going on under the hood when you click that like button, anyway? The answer to that question is: A JAVASCRIPT EVENT!

Javascript events describe a multi-process coding cycle that involves three major components: HTML Elements, Event Listeners, and Event Handling Functions. Let's dig in to how these three components work together to create an enriching, interactive experience for your user!

HTML Elements and the DOM
As you may know, the elements you see on a web browser are structured by HTML. Each HTML element has a specific purpose in the HTML document, and therefore the structure of the web browser. For example, if you'd like to add a "like" button to your page you would first craft its structure in the HTML document as an element. However, these HTML elements are static unless we use javaScript to animate them, which are then rendered in the DOM.

Javascript Event Listeners
Unless you use javaScript to tell the browser what to do with that "like' button once its clicked, that like button will be nothing more than a fancy icon decorating your browser with no real functionality. So how do we create a line of communication to the HTML document to animate our like button? Luckily, javaScript has a built-in system for "listening" for events! Simply put, an "event listener" is a built-in javaScript command that links an HTML element to the event you would like to have happen. This is done in three steps:

"Grabbing" the HTML element from the document with a query selector and attaching it to a constant variable.

const likeButton = document.querySelector("button");

Linking that constant variable to the event you would like to enact using .addEventListener().

likeButton.addEventListener("click", );

Referencing the "Event Handler" function in the event listener that will ultimately enact the event we want once it's called.

likeButton.addEventListener("click", handleLikeButton);

Event Handlers
Hold up, we referenced an event handling function with the event listener we just learned about! What's going on there?? The "event handler" is an important piece of this puzzle, because we need to tell our program what to do with the 'click' we just assigned in our listener using a function. An event handler is a callback function that indicates to the listener what the outcome of the event will be. For example:

function handleLikeButton(){
  likeNumber.textContent = ++likes
}

In the above case, we've created a function that incrementally (++likes) increases the displayed (text content) number of likes (likesNumber) on our page! The event handler dictates the outcome of the event. The handler is called by the event listener--which links it to the 'click'--and increases the likes once the click is initiated.

Here's visual of how the components of the javaScript event cycle work together:

Types of Events
As you can imagine, click events are one of many, MANY javaScript events that can be applied to a webpage. Other common events include:

Mouse events: Any interaction having to do with mousing over, in/ out of, or clicking on an element.

Keyboard Events: Any interaction having to do with key presses of any kind.

Submit Events: Events pertaining to inputting and submitting values to forms.

Screen Sizing Events: Events that occur when resizing or scrolling through the browser window.

And many more.

Event Objects
Event objects are a way for you to call on the event in a handler as a parameter. Common usage for this would be to change specific properties of the event target (In our case, the LikeButton variable we grabbed from the HTML sheet):

function handleLikeButton(e){
   console.log('e: ', e.target);
    }

The target property of the event object is a reference to the element the event occurred upon. So, in the above example, we are logging the content of our like button to the console. Other uses for this method would be to modify the qualities of the event target (like the color or text content), or to link the event target to a database object (and many more). Event objects can be labeled in any way, but conventionally they're labeled "e", "evt", or "event" because they're short and easy to remember, plus it's always good to be consistent in shared code.

Bubbling and Capturing
Sometimes you'll want to link an event listener to a parent node that oversees multiple HTML elements with their own events. This can be super handy, like when we have lots of buttons on one page nested under the same parent node and only want to take the time to write out one event listener, or to link multiple events under the same parent node.

"Capturing" is a phase in the DOM's order of operations where the browser reads our code from the outermost layered node in the DOM tree, to the innermost. In this phase, the browser is "listening" for events starting from the top down.

"Bubbling" is essentially the opposite of the capturing phase, and starts at the time the event is triggered. The inner-most nested node is triggered first, then its parent node, grand parent node, and so on all the way back to the top of the document. If events are linked to these respective nodes the events will be triggered in order from the innermost nested event out to the top. It's important to note that modern browsers handle events in the bubbling phase by default.

Here is a diagram of the Capture/Bubble cycle:

You can read more about the Capture/Bubble cycle here.

Stop Propagation
There are times where bubbling can be detrimental to to the functionality of your page. One scenario is when two events firing in tandem with each other negatively effect the outcome of one or all of the events. Luckily, there's a way to "stop the propagation" of the bubbling phase! It's called, naturally, ".stopPropagation()".

Best practice is to call .stopPropagation() on the event object in your event handler, which will stop the bubbling phase at the time the event is called. When invoked on a handler's event object, .stopPropagation() makes it so that first handler is run but the event doesn't bubble any further up the chain.

An example of .stopPropagation() syntax:

likesBttn.addEventListener("click", function (event) {
    event.stopPropagation();
    likeNumber.textContent = ++likes

  });

Prevent Default
A default action of a submit form event is to reload the browser. In some cases, we want to prevent that default action. Luckily, javaScript has a built-in command to deal with this issue: .preventDefault(). Having this command included in your event handler function creates a catch-all scenario for those circumstances when you don't want the browser to automatically refresh the form.

Here's an example of .preventDefault() syntax in the context of a form event:

function handleReviews(e){
  e.preventDefault()
  let reviewLi = document.createElement('li')
  reviewLi.textContent = `${reviewInput.value}

  e.target.reset()
};

In the above example, we've created an event handler that handles a form for users to add new reviews to our page! The event object is referenced, then we use dot notation to add the preventDefault() command to it. The rest of the code displayed here allows us to add a new HTML element with our users new review to the DOM, and reset our review form input fields for the next user!

Conclusion
Events are hugely important to creating an interactive, functional web page. The options for how to deploy events and their handlers are endless, and there are many "best practices" to look for when planning your event cycles, depending on what events you'll be including on your page. Events exist in many coding languages and javaScript is only one of many iterations of this process in the field! The more you learn about events--and there is much, MUCH more to learn!-- the more empowered you'll be to make effective, functional, interactive web applications to attract users.

Happy eventing!

Resources