Spark AR Studio — incorporating custom scripts

As a software engineering student, regardless of the language or framework, the pattern of learning is often as such: learn a concept, understand why it’s necessary, and then learn how to abstract it away so that one can focus on the next, slightly more complex problem. Entire libraries have been built to accomplish this never ending task, and now more and more programs are abstracting the need to write code almost completely. The goal (I presume) is to include technology users without coding skills in becoming technology contributors. This widens the net to creative thinkers and can produce some pretty incredible mods and apps. As a developer who has climbed the mountain high enough to see the endless range of complex technological mountains ahead and is often overwhelmed by such a sight, I found the opportunity to build custom AR effects that can be easily deployed to facebook and instagram exciting enough to download it, run through some tutorials and read some of the documentation.

While a ton of cool things can be built using this visual drag-n-drop style IDE, my real interest becomes, ‘where do custom scripts come into play?’ If you open a new project, you’ll see an assets column on the left hand side. Click ‘Add Asset’ at the bottom of this box and you’ll get a dropdown menu. Click script, and you have a nicely documented JS file appear in your assets folder that opens in the editor of your choice once it’s double-clicked. Getting into the documentation of custom script writing leads to some interesting “under-the-hood” observations. One is the fact that Spark AR studio uses reactional programming rather than imperative programming. The example the documentation gives is if you have the function

Y = 2x + 3

A typical JavaScript compilation (using imperative programming) evaluates the value of y when it runs the computation. If the value of x changes at any point in the future, an update function must run to update the value of y. With reactional programming, the value of Y is ‘bound’ to the value of the function itself, and that the updating of Y is stored in native code, increasing performance and scalability for when, say, that y value is a y-axis value of someone’s nose or iris being tracked by the program and needs to update every frame (which is a lot of y values). Abstractions are occurring at every level in Spark AR studio.

So ultimately, the question becomes — are programs like this useful or detrimental to developers? I love that I can build AR features quickly after downloading the IDE and without a ton of technical documentation or training, but I also love make levels on Super Mario Maker 2 — it doesn’t necessarily make me a game developer. Does it take away a step of analytical thinking that those who built programs from scratch 30 years ago attained? While I would say that the latter answer is ‘yeah it probably does to some degree’, I still think it is a useful tool for developers, as well as useful in inspiring other to become developers. As a developer, the fact that you understand compilation, call chains, env setups, object oriented programming, inheritances, etc., allows you a sense of ease and understanding of what’s probably under the hood without needing to know what’s actually under there. Finally, beginner accessibility to building custom tech software is the key to taking the next generation of tech users and inspiring them to become tech contributors. More contributions lead to the progressive advancement of ideas, and falls in line with the ideals of the founding mothers and fathers of the internet. I look forward to continuing to play around with this cool piece of software.

Feel free to share your experience with Spark AR studio in the comments below!

React/Redux Portfolio Project: Bringing an Idea to Life

This project was quite challenging but deeply rewarding. I had this tech business concept a couple months ago while talking to some fellow musicians about the troubles of breaking strings while performing, and described a concept of a monthly membership based string-replacement service. What I have loved about this program all the way through is that I can take an idea and create a prototype, which really changes an idea from a conceptual dream to the beginnings of developing a real business. When I finished the redux curriculum I was excited to build this project.

The casual nature of the project requirements page was unsettling in that it was asking us to do something we had never done before (or perhaps only in very sequestered pieces) - create a "backend Rails API" and use it to persist data to your react frontend interface. I wasn't sure where to begin with this (other than drawing out my models and their relationships) but Howard Devennish's live build video series was an excellent place to start. It helped me get some of the basic groundwork started, but way more importantly, it helped me understand the flow of information for the redux pattern. The fact that each time a new piece of information was added, you create an initial state in your store, and get ready to update the store and hold information from any forms in your program. Then to understand how the actions and action creators call reducers to declare exactly how the data is stored in redux becomes very clear. Even though the "how" and "why" were unclear and unclearer respectively at first, the fact that there are so many places to drop breakpoints and debuggers thoughout this info flow pattern makes it understandable. Once I felt I had seen enough group building/coding videos to try to add things in on my own, the excitement of being able to grab ANY piece of the redux store that I needed truly showed me how the organization of redux is so adventageous. I discovered this when I needed to user currentUser's information in a page that I hadn't originally built it for, and discovered through a quick google search that I could map multiple states to props in a component like so:

`

const mapStateToProps = (state) => {

  return {

    myGuitarForm: state.newGuitarForm,

    currentUser: state.currentUser

  }

}`

Most of all, this project taught me to read error messages coming from the front end or the back end carefully and efficiently, allowed me to majorly sharpen my debugging skills, and to slow things down and follow the flow of information calmly and mindfully when it's all becoming overwhelming, all while getting to know my own code much better and understanding each peice of it intimately. Although my project exceeds the requirements, I am excited to continue to develop more advance features to allow this potential startup concept to reach it's full potential.

Rails + JavaScript Project: What's "this"?!


This project was yet another moment of the darkened map unlocking further. You learn that Rails is actually a more helpful framework for the backend, and that dynamic web applications use JavaScript for smooth UX (which I'm sure will get abstracted away with frontend frameworks...I haven't looked ahead but based on the learning patterns here at Flatiron that would be my best guess). Understanding the parts of the machine that is an AJAX call, from receiving HTML or JSON data, serializing data and the tools like activerecord serializer, reorienting your controllers to receive this new data, to wiping clean and repainting the DOM was a surprisingly large conceptual undertaking. Once the concepts became clear, and the steps of implementing an AJAX call/fetch request for data are understood and repeatable, the quantity of work was very manageable.

As I began to understand the process of the AJAX call as it pertains to my project, I found that I was frequently asking myself, "what is 'this'?", because understanding *what* data you have available becomes super important in your attempt to manipulate it. I started by using console.log before moving past a step I fully understood, then opened up my dev tools console and experimented with the in-scope data (I used debugger and devtools breakpoints later in the project as I became more accustomed to them). Besides giving me a clue as to what should come next in my code, understanding what "this", "data", or "response" were allowed me to create a mental picture of exaclty *what is happening under the hood*. Considering this is likely the predessor project for using a framework, I felt satisfied that I was painting a conceptual picture of how the parts of the machine work together to make the magic of AJAX, when for so long I felt lost in JavaScript during this unit.

This project was also a good opportunity to understand the asynchronous nature of JavaScript, as I spent a lot of time trying to understand why one clickHandler needs to be called above another. Finally, the moment when I realized that it would be **actually more convenient** to create a class Constructor for my comment data and create a prototype function for it to repaint the DOM was a big breakthrough for me, since the usefulness of constructor functions were lost on me up until that point. I had already created constructor and prototype functions for another class while following Cernan's "fetch" pattern from a study group video, which took care of the requirement. I planned on doing the comment submission form without a class constructor, so it was first time I independently recognized that it could make things easier. 

Although it felt strange to not build a new conceptual piece from the ground up for this project, I enjoyed taking an app that I was already invested creatively and added some JavaScript to improve UX and application speed.

MTG Challenge: Interactive Fan Site Rails Project

This project was beastly. From pushing to move through a large amount of rails material relatively quickly, to finally arriving at a project that needed to encapsulate over a dozen different specifications, I was highly nervous about the idea of creating a fully functional rails app from scratch. I took some time to think about the kind of project I wanted to design, when I had the idea of building a much more advanced version of my CLI gem project: something that can further propogate my band's brand and merchadising concept.

One of the biggest challenges with this project was accepting that if the conceptual design was to work AND I was were to finish all of requirements, it would be a complex rails app that would go pretty far beyond the minimum requirements of the project. I wanted a User to be able to create a profile and award themself any amount of currency called "Music Mana" that could be spent by creating Teams of musicians from different bands, discovering what songs the Team's musicians knew collectively, and virtually "perform" the song of their choice to gain XP in multiple categories. The XP would allow a user to "Level Up" from Novice, to Apprentice, Traveling Bard, Master, and finally "Ultimate Music The Gathering Master". In order to acheive this, I needed a User, Team, Character, and Song, with two join models CharacterSong and CharacterTeam, since both Team & Character, and Character & Song were many-to-many relationship. I also needed a join model called "Perform" so that a User's Team could Perform a Song. Finally in order to created a healthy and unincumbered nested route, I created a Comment model nested under Character, so that Users can comment about their favorite characters.  The model relationships can be depicted as such:


(alt: image of model relationships)

The most challenging hurdle was understanding my parent/child relationships. The key element in getting my comments to work successfully with my characters pages, as well as my  saving teams to the team index page, was the key line:

```

def create

    @character = Character.find_by(id: params[:character_id])

    @comment = Comment.new(comment_params)

   >>>> @comment.character = @character <<<<

    if @comment.save

def create

    if logged_in?

      @team = Team.new(team_params)

     >>>> @team.user = @current_user <<<<

      if @team.save

```

where even though the relationship belongs_to/has_many is set up in the macro, it needs to be stated that the @comment.character/ @team.user needs to be assigned to @character / @current_user, otherwise rails will still reject the assignment and it won't populate the instance variable, so you get all kinds of interestingly unhelpful error messages in your browser. Once I was able to iron this understanding out in office hours, it was  more or less smooth sailing for the rest of the project. 

The light at the end of the tunnel (though still quite far away) appeared after I successfully built out the many-to-many relationships, moving slowly and rubby-duck programming to be sure I understood what I wanted the program to do and what each line I was adding meant to me. Once I had full access to Character.songs and Song.characters, I was able to implement "the code I wish I had" fairly quickly. 

A spent a lot of time in my rails console to figure out some important instance methods I needed for the Team model, and I felt really proud of myself for being able to figure out how to write these custom methods from scratch. They are vinegary and need to be refactored, but I'm very proud of it's functionality.

I still have a problem with my OmniAuth through facebook, but I feel confident that I can debug it fairly quickly.

Overall I had a great time struggling with this project and it was greatly rewarding.

Sinatra project - starting to feel like a programmer.

I can't say that my sinatra project is done. I can say that it meets the requirements and I'm happy with where it is for version 0.0.0.0.1. I chose to work on an app idea that I had a little less than a year ago, well before I was even thinking about learning how to code or starting into a program like this. It was one of those "oh, wouldn't this be a really cool and convenient piece of software" ideas that I often have, so getting a chance to start actually building it myself is really exciting to me - even if it's the Flinstone's car version of the Tesla in my head.

As most people described in their blogs about the sinatra unit, I also flew through the initial material with sql, orms, html & css, and sinatra basics, followed by a screeching slow down as the labs grew increasingly difficult in the final 15 or so lectures and labs. But as I learned the ways I felt most comfortable debugging MVCs, I started to really love this integration of all of the symantic languages and conventions that we've gathered over this second unit. I spent a long time conceptualizing my models and their relationships, I took the time to draw out how I wanted my finished product to work before I started, and I took a TON of notes which can only be described as written rubber ducking (a process I sometimes find as helpful as verbal rubber ducking, since it forces me to slow down a little - I speak fast, even when it's to myself). With this careful foundation, I found that I moved much more quickly through actual coding phase of this project than I had antipated, and had several triumphant, "I CAN'T BELIEVE THAT JUST WORKED" moments, which felt great.

One major snag I had to overcome was that after a while, I had to admit that one of my models was conceptually flawed and needed a major overhaul. My Ingredient class, which is meant to keep track of your kitchen inventory, was given three attributes: fridge_freezer_item, pantry_item, and spice_cabinet_item, so that the user could input 3 items at a time into different categories on the new items page, and so I could easily organize the show page into "fridge & freezer", "pantry", and "spice cabinet". The problem came when I built my delete button and I realized that if you wanted to delete one of those items, you would end up deleting the entire Ingredient object, losing the other two along with it. Or if you didn't have anything to add in the spice cabinet while adding fridge and pantry items, my database was full of a bunch of ingredient objects with ingredient.spice_cabinet_item = "", which seems like a fast way to end up with a messy database. I switched to a new branch and altered my ingredients table to instead consist of simply "item" and "food_type", so that each food item is tied to it's own ingredient object, and "food_type" functions as the "where in the kitchen is it from" attribute. I think this also make creating a ingredient to recipe matching algorithm easier in the future.

Overall I had a great deal of fun making this project. I am so excited that I can start developing my ideas at this point, as it gives me a really strong motivation to work hard, thoroughly, and meticulously. 

SQL: Writing Queries

I notice a shift in my thinking now that I'm working through new material after having completed my first portfolio project. As much as I missed the gratification from completing readmes and smaller labs and "turning lights green" in my curriculum tab, the (week +) it took me to grapple with the CLI Gem project gave me an entirely different prospective on **how** we're learning within this program. You learn to appreciate the file structure of the labs FlatIron gives you instead of being overwhelmed when a new type of file is introduced. You garner a deeper understanding for how Object Oriented setup files can help streamline the lesson you are learning (I know I can focus better on what I'm being taught when I can see all of the levers and pulleys being the curtain). And your relationship goes from HATE to LOVE for rspec tests once you have to build something from scratch with no parameters whatsoever. It's that shift in thinking that has me so excited to continue moving forward into the first unit within the Sinatra section.

Maybe it's due to this shift in thinking, but for one reason or another, I found spending time writing queries in SQL to find specific peices of information in database tables super fun! They remind me of logic puzzles that take a nice amount of creative thinking without getting frustrating. The semantics of the language are very clear and create a strong mental picture. I can see the tables collaborating very clearly, while OO Ruby collaborating objects took a very long time to **visualize** how the objects are collobarting, and I feel that my understanding of OO Ruby objects is stronger now that I have a second way of collaborting a set of information with another set of information. 

It feels a bit nerdy, but I found buliding SQL databases and running queries really fun and rewarding. With so much of the material being difficult to grasp, it feels great when something makes a lot of sense. 

My First CLI Gem Portfolio Project

The process of understanding this project was a huge hurdle in this course (I'm submitting for review so I'm not completely done yet). There is so much that you don't experience in full until you reach this first final project: setting up a file structure on your own, continually using github and actually seeing why a repo is so important, messing around with gemspec files, understanding development dependecies and other "ignore it for now" aspects of how the guts of a program works, and no rspec tests to help push you in a specific direction. 

I spent a ton of time watching the video lectures and trying to code-along to understand how to make something happen. For the longest time I couldn't use my console because there was something I had missed sitting in my gemspec file that kept me from using Nokogiri within my program (until I eventually found it from watching another video about file structure, understanding 'require' and 'require-relative' more fully, and bundler). Overall I found it difficult to be stuck on a problem logistically and having to take more time to watch more videos or filter through overstack while recognizing that the bigger problem lay ahead:  I still wasn't understanding the relationship between information being scraped and how it could become information within an object. 

Sometimes for something to really solidify in your brain, you need to do things the long way. I started to see why having objects is useful when I had all these local variables saved in replit to try and keep track of the information I was scraping and organize it so my CLI interface could use it eventually. It finally made sense when I said to myself, "I need 5 of this thing. Each of those 5 things need to have info A, info B, and info C." And I realized **that's an object instance and it's attributes**. It might sound simple to others, but being told how that works and really understanding why you need it was pivotal for me in this project. 

Finally, using the memoization tool ||= to only scrape the site *once*  and then save the HTML as a class instance variable, like this: 

def self.doc

@doc ||= Nokogiri::HTML(open"https://musicthegathering.com"))

end

allowed me to call self.doc in my scrape methods while only asking the server for one HTTP request (I was getting a lot of "HTTP error 429: Too-many-requests" error because my scrapers were scraping every time I called @doc, and I guess the server I was working with didn't like it).

Overall I am proud of my project but I would love it to be fancier than it is. Part of knocking down milestones is being proud of what you accomplished while seeing what you will be able to do with more experience, time and knowledge. 

Understanding OO

Ever since I went through the pre-CLI section of Object Orientation, I have been nervous to return to the subject in full. I have had several "A-ha!" moments conceptually throughout the beginning of my journey to learn programming (albeit very basic ones), but I failed to internalize how changing some variables to variables with @ signs would do anything to help, for example, my procedural ruby tic tac toe - of which I was proud and viewed to be just fine. But as I keep hearing throughout lectures, metaphors help us understand why a functionality within a language might be needed or useful. And in this case, I have needed several different metaphors, including a metaphor I've created in my mind, to allow the usefulness of OO to sink in.

We want our methods to accomplish a specific task, and we want our methods to work together to accomplish a big task, but trying to give one method too much to do can get ugly. So if there is a way to classify the "big task" and then allow the "specific tasks" to live and work together within the Big Task, why wouldn't we want to do that? Things began to make more sense when I understood attr_accessors, and I finally started to see the bigger picture when we were introduced to @@class_variables and class methods. The idea that there is a hierarchy of variables and methods in terms of their functionality within a class made it clear why having complex functions encapsulated in a class can be so useful. 

The takeaway from my change of heart for Object Orientation is to recognize that learning a language might not be in the same order as the design of the language, but it's necessary to gain the knowledge one step at a time. I have to stay positive, learn the concepts in each section to the fullest, but remain open to the fact that my entire perception of that concept might change when a new element is added to it. 

Discovering New Worlds Of Information

I tend to get that glimmer in my eye - the spark of excitement that fires through every neural pathway in my brain and body - when I see a *new world*. A world of new information, a world of new people finding a weird niche of content to obsess over, a world of possibility that I hadn't been privy to before. It's something that has always driven me to learn new skills, to create new projects, and to figure things out in new ways. Sometimes it's to a fault - it can be a way of diverting when my chosen path becomes too difficult or I find that I'm losing interest. But whether it's "constructive procrastination" or it's a focused and saavy decision, it's always been important to me to follow the idea that sparking my curiousity will always be the strongest motivating force in my life. 

Choosing to start this programming course has it's practical reasons: I would love to find skill-based, higher paying jobs both in New York when I'm home and remote work when I'm on the road for months at a time. But beyond the practical, which never gets me through all the way (see flowery paragraph above), I am interested in this *new world*: one where with some creativity, team work, and a desire to fix what's broken using logic and reasoning, a person can build incredible things that everyone else in the world uses and expects to work automatically. A world that supports each other and fosters new ideas through collaboration and positivity, while so much of the surface cyber world tries to pull each other apart through divisiveness. I am excited to work with Flatiron school for the beginning of this journey because I have quickly realized that the thick, bullet proof cast iron door locking away all the secrets of the Internet is actually wide open. All you have to do is find that spark and say, "Yes, I want to learn" and there will be people waiting on the other side that say, "Welcome. Let's do it".