From Craft to Code

This past week has been a more in depth look into React. It turns out there are many different ways to approach compartmentalizing code. Organizationally, React likes to keep everything in components. This way code can be written for a specific section, including its logic, its HTML, and its styling, all in one place that is separate from the rest. These components are likely to still be a piece of the whole page so in order to avoid typing the same code over and over there are a few different approaches. Inheritance is exactly as it sounds, small components can inherit properties from the section it is inside of or the larger component around it. Just like last week, these properties are passed down in the constructor. They can include defined variables, functions, or even state. In a way, inheritance is a method of linking the separated components together to allow for more reusable code. Children components are very similar. Some properties can still be passed down to childr

I have harped on this before but it is worth mentioning again - React is a library that allows for the rendering of small components. This is wonderful for applications that require a lot of changing data. A great organizational method for React is to piece each of these components in to their own file rather than lumping all code into one difficult to read file. This allows for easier manipulation of individual pieces. Some of those components require something called 'state'. State is a bit of a confusing concept. What it basically boils down to is a time frame. If you're building an application that requires anything to be remembered or recalled over time than state needs to be set. In Node I did this with a package called Session that handled a lot of the logic for me. In React, which is still JavaScript, then I can use a method called setState. When state isn't being used I still want to pass properties down to that component so I use 'props' in my const

No, not real earthquakes. Just another web application! I'm not entirely solid on React yet (still on shaky ground) but I've taken my first few steps. Set up is not as difficult as I anticipated. Rather than starting every project from scratch our activities are now set up in a way that simulates a more realistic situation. We're given a set of files and basically told to fix it. For this application that is covering how to map over an array (loop or iterate over a list in order to apply a function to each item) we are using a government API to access data about earthquakes. This data updates in real time and only the last hour's activity is displayed. This is possible through React! As mentioned before, React allows a page's components to update without a page refresh. It immediately creates a better user experience because it isn't up to the user to make sure the page is properly loaded or displaying the newest data. The biggest learning curve is organiz

React is built on a lot of ES6 syntax (an updated and more modern way to write JavaScript) and there are a few more concepts in JavaScript we're learning about before diving into anything else. Some of these concepts are function constructors, inheritance, prototypes, and classes. From what I understand these don't necessarily come up very often when building apps in React but it is an important concept to understand before moving forward. Essentially, function constructors work like object constructors. They can be seen as a schema, or a model, to be called on later when required. When building a lot of the same type a prototype can be used so that all of its children can inherit its properties. In less vague terms a prototype is exactly what it sounds like - a simply constructed piece that can be cloned over and over but look exactly the same. Classes on the other hand also seem to be the same exact thing. But prettier! Classes are what is called syntactic sugar for const

The last four weeks of my time at The Iron Yard is set aside for 'specialization'. That is, we as students had the choice between learning Ruby, React, and Java. Given my background in visual arts and design I started this programming boot camp assuming I would go in to front end development. After spending the last four weeks with back end fundamentals I have even more reason to believe I would be happiest working with React, the front end option, over the other two. React itself is a library for JavaScript written to keep up with the changing demands of web applications. On a page like Facebook, the creators of React, there is a need for constant updating. Without reloading your page you should be able to see when someone likes a post, when someone sends you a message, and every time someone you follow posts a status. This requires specific containers making updates without the entire page refreshing each time a change happens. React's speciality is handling these cont

Now that I have schemas in my models folder for both users and snippets I'm going to need a way to store them. I could use a SQL database which would store the snippets in the user table with a foreign key or a NoSQL database which is a bit more flexible. Even though SQL is the better choice, I am more familiar with Mongoose then Sequelize (both are the middleware used to help Node talk to the database).  For now, I will use Mongo and Mongoose to store the data from my application. Since I put each of those schemas in their own file I was able to export them. Once they were exported, I could require them in my main file along with the routes I created for each of my pages. I made a route for the login, the register page, the home page, and a place to render the results of a search. All of these are referenced in my app.js - the index of my project. In that same file is where I declare a url for Mongoose. Mongoose needs a connection between my application and the database inside o

Another model I need to use for this web application is for my user's. When someone visits my app I want to ask for username, name, and email. At some point, they should be able to edit their profile to add a picture or an avatar and I definitely want to encrypt their passwords for them. In order to make sure each user has these elements attached to their profile I created a schema, installed a package to handle my encryption, and a package to handle authenticating that password. I chose bcrypt and Password because that is what I'm familiar with and what we went over in class. However, there are other ways to encrypt passwords and other packages that do it similarly. The userSchema.methods and .statics was all 'boilerplate' code that I was able find in our reading material but if I ever need it again in the future I can either look back on this project or find bcrypt documentation. My next steps will be routing my login and register pages that I made templates fo

I have no idea if this is the best approach to a project but I'm implementing the MVC methodology to this web app that I'm building. As in, I'm first going to build as much of the model as I can then as much of the views as I can before working on the controller. As I mentioned yesterday, what I do know is that I will need two schemas for this project - one for the snippets and one for the users. I will be using a noSQL database because I already know how to use Mongoose to connect Mongo to my Node application. One trick I knew I would have to add in order to 'link' the two collections in my database is on line 15. I knew I would have to give each snippet a way to connect to its owner in order to only display that owner's snippets. This probably would have been easier to do in a SQL database where tables have a bit more structure and can include foreign keys to reference other tables. However, I wanted to use tools I have already learned how to use to accom

To wrap up our back end instruction The Iron Yard requires a final project that rounds out the skills we've learned over the last three weeks. In a nutshell, we use Node.js and a few of its packages to write an application. Our objective is to create a web app that requires a login and password, allows for registration, enforces password encryption, and brings the user to a home page. For this project, that home page is a code snippet organizer. This project has no mockup or wireframe because design is not the main objective. However, there are a set of abilities our app must have. A user must be able to view all of their snippets, be able to edit or add or delete their snippets, and there must be a search bar that filters through those snippet's tags and languages. That means there are two schemas being used in conjunction. There is a collection of users and a collection of snippets all being stored in the same database. They have to be two separate schemas because each mode

Last week I learned about Mongo - a NoSQL data structure. This week we've covered the opposite. SQL is much more structured and rigid but does allow for an 'easier to organize' approach. More time and thought has to be put into a table's creation. Extra data can be added after the fact but it is easiest to have all of the data you know you want to collect ahead of time. Basically you're turning your raw data into a spreadsheet. That is, SQL is great for data that already exists and needs to be organized.  Unfortunately most of this happens behind the scenes and is executed in the command line. That means I really don't have any images to share. Even when turning in my assignment I had to export my raw data into a file and upload that with a README file explaining what I did to achieve that success.  Tables are just organized data and can be joined to filter out needed information. Those queries look something like this:  SELECT title FROM todos WHERE com

Security is a huge topic in tech. As technology progresses so does cyber security. I know basically nothing about it either! However, we did learn about encrypting passwords yesterday and tried our hand at two different ways to do so. One package is bcrypt and another is Password. I played around with each and the biggest difference is that Password allows for logging in through twitter or facebook. Pretty neat, right? I didn't get the chance to play around with it that much though. I did local encryption instead. This all still looks foreign to me but a great benefit of Node.js is the ability to use these packages when you need them with the code you already have. As I get more comfortable with the language I'll be able to create a multi-page application with authentication, validation, and password encryption!

Last week we covered databases! Super exciting, right? It only makes sense, though, that the majority of back end development would be storing, accessing, and updating data. There are quite a few tools available for Node.js and the ones we covered are Mongo and Mongoose. Mongo or MongoDB itself stores data flexibly. Why does that flexibility matter? It is perfect for sets of data that are incomplete. If I had a list of contacts I wanted to store but I didn't have everyone's emails it wouldn't be a big deal - those email addresses would just be empty. Mongo stores the data and Mongoose is a tool that accesses it for you. This is the secure way to retrieve data and validate it rather than having potentially sensitive information stored right in the code for anyone to see. Mongoose is pretty straightforward to use and I implemented it into my robots database (that thing again!). In a nutshell, I was able to swap out the database I had stored in a file and put it into Mongo o

Today I've been tasked with teaching myself something new! In the coming weeks it will be time to decide what language to specialize in. I have the options of React, Java, and Ruby. All are wonderful options but as I've worked throughout this program I am still leaning towards a more visual career. That entails continuing to learn front-end development. In turn that makes React my best option. So today I'm going to get a little ahead of myself and learn some basics of React. I have no plans to build anything snazzy. From the little I've read about React it can be intimidating to get into. There are a lot of moving parts to code but it seems especially true of React. Just finding a tutorial on React itself instead of all of the other packages and frameworks that go into it was difficult. If I can just populate a page of images today using React I'll be satisfied! I'm using the first two tutorials listed here:  http://andrewhfarmer.com/getting-started-tuto

There seems to be a lot of debate around what Model View Controller (MVC) is. After almost 48 hours of discussion, intense Googling, and furious debate I believe I can comfortably say that MVC is a way to organize your code. To compare, there are dozens of ways to organize a craft room. On top of those dozens of ways you could think of to organize your stuff - there are overarching theories and methods to help. I've read articles on the psychology of organization and popular methods such as bundling your stamps based on theme versus month of the year you would use it. MVC is a method of organization for programmers. Keep in mind a lot of the implementation is dependent on the project itself. Also, a programmer's code is personal and nothing beats methods that work for that programmer. With that in mind, MVC attempts to propose an ideology to follow. Model can be a folder to store sets of data and any logic used to filter through that data. View's purpose is to hold any vi