jennyjean8675309-blog

[jennyjean8675309-blog]

Exploring Recursive Routes with React

I’ve recently recovered from a big headache - my latest project required some nested routes. Basically, I had a big container that held some smaller containers, and each of those smaller containers held a bunch of items, each of which I wanted to see rendered on its own page. If this is confusing to you - yes, I agree.

My first attempts at routing, linking, and redirecting to these nested urls were pretty messy. I was getting some weird url params as I clicked through my app that were making it difficult to get anything in my app working properly. So, I decided I should revisit this topic to gain a better understanding. I made a brand-spanking-new React app with only one goal in mind - conquering recursive routes. Here’s what I’ve discovered...

The missing link - the secret key - the thing that makes it all come together

The key to understanding nested params is React’s <Route /> component. Any render method that you pass to <Route /> has the same three props:

match

location

and history

Match is what we really care about.

Have a plan

Your routes should live at the top-most tier of your application, which for me, was App.js. I needed to import a few things at the top of my Index.js file to get this working...

Notice that my <App /> component is nested within a <Router></Router> component... now I can set up my initial routes in App.js. First, I want to add

to the top of my file.

My app will use some nested data to render specific information at specific urls. Here’s what my data looks like...

This is right at the top of my App.js file, where I have access to it and can pass it down as props to all of my child components. My goal is to have a home page that has a link to the three rooms in my home (the kitchen, living room, and bedroom). When I click on any of those room links, my url will change (”/:id”) and I’ll see rendered on the page that particular room, with a list of furniture that that room contains. Each piece of furniture will be another link to that piece’s show page (”/:id/:f_id). Sounds easy enough, right?

Because I have a pretty good idea of what I want to render, and where, I’ll go ahead and set up my routes. Notice that within each <Route/>’s render method I’m passing in props - remember that the match prop is the key to making this whole thing come together.

Before we move on, let’s take a quick second to see what that magical match props is...

Aha! The match prop has a key, params, that shows some pretty good stuff - including my current url. Interesting, interesting...

Let’s start with our simplest component first... our Home page.

On my Home page I simply want to iterate through my rooms (this.props.rooms.map) and render each room on the page, using a <Room/> component. Notice that I’m passing through the props (from the App.js file) down to the <Room/> component.

Now this is where those match props really come in handy!!! Each room’s name is now a link. React’s <Link/> component needs a path (to link to of course) and we can tack our current room info (this.props.room.id) onto the end of our previous url (this.props.match.url) to create our first nested route. Yaaasss!!!

Uh-oh. But now if we check the routes we set in app, the route for “/:id” is expecting to render a <RoomShow/> component, which we haven’t yet made.

So... let’s make it!

Now things are getting a little bit tricky, but it’s nothing that we can’t handle - to find the current room that we’re in we’ll iterate through this.props.rooms to find the room that matches our current url (this.props.match.params.id). Then, we can use that information to render our current room, and iterate through that room’s furniture to create a list.

Here, we see that each piece of furniture is rendered as a link, and again, we’re using this.props.match to create a path for our link. Cool.

Checking our routes again, we see that our final route (”/:id/:f_id”) is expecting a <FurnitureShow /> component to render.

Our furniture show page is nothing to write home about (all we’re really doing is rendering the name), but... it’s working!!!

Now sit back, click away, and bask in the glory of your success.

[jennyjean8675309-blog]

UI Design Basics for Web Applications

A few months ago my sixteen year-old was taking an online course for Driver’s Ed (Yikes! - I know). The last lesson included a link to take the final test to earn her certificate for the course. We clicked on that link, which took us to another page with instructions to click on another link to find the final test. Well, that link took us right back to the original page we had started from! We were stuck in an endless link-loop with no final destination. Welcome to the Twilight Zone - online.

A lot of head-scratching, frustration, and several phone calls later, we were finally able to figure out what she needed to do and move forward. 

The (true) story above is an illustration of poor user interface - the website was confusing, and we weren’t able to get the (rather critical) piece of information that we needed. Now, after a couple months of coding bootcamp, and with a few projects under my belt, the importance of good UI (or User Interface) design has been made even more clear. And good UI takes some planning.

Before we dive too deeply into how to implement good UI design, let’s talk a bit about what UI design is.

UI design (if done properly) tries to see things from a user’s perspective. Today’s world is chock full of some pretty savvy Internet users. They’ve been around, and they will come to your website with some expectations. As developers, it’s our job to make sure that we at least meet (if not exceed) those expectations.

As a developer, you want to ask yourself three basic questions about your application:

Is it easy to access?

Is it easy to understand?

Is it easy to use?

Here are a few examples of some sites that don’t quite pass muster...

Argen  - http://www.arngren.net/

Whoa!!! Holy visual overload, Batman!

The designers of this site did make some attempt at organization - at least some of the boxes have borders around them. But if we’re being honest, there is no focus to this site! Links are just splashed everywhere and it looks like everything just got pushed and shoved onto the page in an attempt to fit as much as possible.

The following examples are a bit ironic:

University of Advancing Technology - https://www.uat.edu/

Now this one’s pretty fun. See all those boxes around that guys head? Those boxes are all links to the programs that this university offers - and they continually spin around the guy’s head! It’s kind of like a game - is the program you want offered? - you might have to watch and wait for it to come around, and catch it when it flies by! This is great for a little distraction, but not so much for users who are serious about finding their program. There is no static list that you can quickly scan to see what you want. Though the flying, rotating boxes feature is cool, this just isn’t the most appropriate way to use it.

And, last but not least, we have:

Serene Naturist - http://www.serene-naturist.com/

This site is... not so serene. You can’t see it from this still screenshot, but if you click on the link above, allow flash player, and hit the play button on all of the myriad flash boxes, you’ll see about a gajillion different features bubbling, sparkling, fluttering, scrolling and/or blinking. And if those don’t make your experience more tranquil, there’s also a clock continually displaying the time (in seconds) at the top of the page (maybe to remind you that you’re always one second closer to death so you’d better take the time to relax?). It always helps to keep your target audience in mind, and have the atmosphere of your site reflect the atmosphere you want your company to have.

Having called out these sites, I need to offer a caveat - good UI design is hard. It’s easy to point out others’ mistakes, but when you go to build an application yourself, it’s even easier to forget the user’s perspective and throw things into your site all willy-nilly.

So, how do we, as developers, go about our UI design?

First, plan before you build.

Second, plan before you build.

Third, PLAN BEFORE YOU BUILD.

Okay, plan before we build - plan what?

Design

Plan out your design, starting with the functional requirements of your application first. Ask yourself, what are the goals of my application? What do I want this app to achieve?

After you’ve gotten a solid grasp on the goals of your app, do some user analysis. Try to imagine different user scenarios, thinking about the variety of users that might visit your site. What would those users need in order to use it? What might those users expect?

Next, plan out the logical design of your application. How does information flow through your site? What processes are used to implement that information flow?

From logical design, you can then jump to physical design - how will your logical design be implemented on a visual platform? How is information rendered on your page(s)?

*Note that the Design phase is purely planning - we haven’t started building out anything yet!

Implement

I know you’re anxious to begin building, but we have one more step to go before we get our hands wet...

Make a prototype of your app. Create a mockup (either on paper or using some online service) where your sole focus is the interface (now is not the time to add any potentially distracting pieces). 

And now, drumroll please...

You can build. Construct your application (but remember to be flexible). 

But we’re not done yet...

Testing

Test, test, and test again. Test your application with as many users as you can find, and have them throw as many different scenarios at you as possible. Challenge them to break your app, find a bug, or discover an endless link-loop.

Before I go, I want to leave you with a quick list of best practices to consider when (first!) planning and (then) creating your user interface design:

Keep it simple - this doesn’t mean that you can’t showcase some great new feature or have fun - just make sure that you don’t overwhelm your user.

Be consistent and predictable - this will ensure that your users’ expectations are met and that they aren’t surprised (and turned off) by weird quirks.

Pay attention to layout, color and texture - aesthetics are important, ‘nuff said.

Use typography to express hierarchy and clarity - if your user can’t figure out what is most important on your site, they’ll have difficulty navigating it - lend ‘em a hand.

Communicate with your user - if they submitted a form successfully, let ‘em know! If they hit some error message, let ‘em know why, and how they might fix it. Let them know too where they’re at in your site, and how they might get around. 

If you keep these simple ideas in mind, hopefully you can avoid this kind of response when others visit your site...

[jennyjean8675309-blog]

Keeping it Clean - Data Validation with Ruby on Rails

Validation is super important. As my poor husband knows all too well, I often crave it. Who doesn’t need some affirmation every once in a while that they’re doing okay, that their thoughts and feelings are valid and worthwhile? My own personal neediness aside however, validation, when it comes to computer programming, can be critical.

As users of the Internet, we’ve all encountered a multitude of forms and fields that we have to fill out online - when creating a new blogging account, when completing a contact form for our children’s school, or even just typing something into a search field. How many times has your information gotten kicked back because of an error? My name is Jenny - it’s a pretty great name and it fits me real well - but there are also a bajillion other Jennys floating around the world. Every time I’ve tried to just create a simple username, ‘Jenny’, it’s gotten kicked back because some other Jenny has already beaten me to the punch and snagged up that username. As annoying as it is, validation for uniqueness of a username is really important - although I would love the coveted, clean, simple username of just plain ol’ ‘Jenny’ - I’m really glad that my username is unique. It makes it that much harder for someone to accidentally (or nefariously) get into my account. On the developer side, keeping the data clean makes it that much easier to manage. 

So how does validation happen in the world of program development? How is it set up and at what point in a user’s experience and on the developer end do those checks for errors happen? Well, funny you should ask - because I’m going to cover all that (and more!) in this post - and guess what? - Rails makes it super easy.

To start, let’s give our users the ability to create something super important - something that might require a lot of checks so that we can be sure that the information we get back is clean and will fit nicely into our database. How about... 

Smurfs!

Smurfs are perfect - they’re a little cultish, so they require a lot of checks before they allow you to join the village - your name must be smurfy (i.e. have “smurf” somewhere in it), you have to be at least 100 years old (but not older than Papa Smurf ‘cause he doesn’t want to be challenged), and your color MUST be blue - no exceptions. Oh, and we also don’t want any two Smurfs to have the same occupation - any form of competition might disrupt this otherwise peaceful community.

Active Record comes with a nice set of Validation Helpers that perform some fairly common checks, including (but not limited to!):

acceptance - for all of those checkboxes we click that ask if we ‘agree to the terms and conditions’

confirmation -  when you need to check that two fields are exactly the same (i.e. when you create a new password)

format - when you need data entered in a specific way (i.e. MM/DD/YYYY for a birthdate)

exclusion/inclusion - when you want to be sure that certain values are excluded or included for an attribute

length - when you want your user to create a password with X number of characters or a tweet that can’t be over 140

numericality - checks that info entered into a field is a number (this one comes with a number of sub-helpers that we’ll use in a moment)

presence/absence - checks that the user enters info/doesn’t enter info into a field

uniqueness - just what it sounds like - makes sure that user entered info that is unique (i.e. not already existing in your database)

Here’s some more information on Rails Validation Helpers.

Let’s see how some of these work...

Here you can see that I’ve created a simple form that our user can fill out to create a new Smurf.

*** Just a side note - if you’re familiar at all with Rails, you know that it uses some naming conventions when it comes to naming folders, files, paths, etc. I used the Rails Resource Generator for this project, using the word ‘Smurf’ - and Rails thinks that the plural of Smurf is Smurves (see the url above). Eh, at least it tries. We’ll just go with it. ***

Now we’ll navigate over to our Smurf model, and implement an easy validation (checking to see that a Smurf’s color is blue), using the #validates method...

Here I’ve used the #validates method, calling it on the Smurf attribute that I want to check, :color, and then the helper that I want to use, inclusion. The inclusion helper takes in an option in:, that accepts any values that you want to allow the user to enter for that particular attribute - because we only allow our Smurfs to be blue, I’ve given it just one option, blue. (If we were to allow more, we’d simply separate them with a single space (no commas). 

Now let’s pop over to our ‘Smurves’ Controller (thanks for the help, Rails) to see how we implement this validation with the user input.

Note that, at the beginning of my create action I’m using the params from the form (as strong params, defined below) to make a new Smurf instance, using the #new method, not #create. This is very important! Using #new will make a new instance without saving it to my database. Remember, we want to valid our user input before it gets saved to the database - because once it’s in our database, that’s where we might run into problems later on. So, before we save our new Smurf to our database, we want to check its validity first, using the #valid? method. This method is tied to the #validates method we defined in our Smurf model. If our Smurf is invalid (i.e. not blue) it won’t save to our database, but instead the user will be shown the edit form again.

Let’s see how this works...

Here’s my form, and, as you can see... I’m trying to create an invalid Smurf with the color green.

What happens when I click the button to ‘Create Smurf’ is that my validation checks the user input for validity and kicks me right back to my edit form. Cool, but not cool... how would a user even know what went wrong - they might just assume that my application is broken and move on to procatinator or something more fun. There is one place we can check though to see what’s going on under the hood, let’s inspect our web page’s html response...

Rails does something cool when our information is invalid... it creates a new division tag (<div>) in our HTML response with its own class - “field_with_errors”. This tells us that the user params came back with errors.

Sorry, little Smurf - ejected!

Okay, so now how do we tell our user what went wrong so that they can fix it?

Easy!  Remember the HTML response I just showed you after we submitted a form with an error? We can now expect that error response from Rails and use it in our own code to display errors (and messages) to our user...

The #errors method from Rails knows to look in our HTML response for any of those <div>s with a class of “field_with_errors”. Our code then counts those errors for us (using Rail’s handy pluralize method to differentiate between an error and errors) and then each error gets the #full_messages method called on it to display those messages (each validation helper comes with its own default message). Cool!

Now, when our user tries to create an invalid Smurf they see...

Wow! Now that’s really helpful! Now our user knows why the form came back (there was an error) and our super helpful code tells them exactly where the error occurred (in the color field) and why (’All Smurfs must be blue’).

Woah, woah, woah... ‘All Smurfs must be blue’ cannot be a default error message from Rails - unless those Rails developers are havin’ a whole lot of fun. Where did that super specific and smurftastic error message come from? Remember, way back a long, long time ago when we did this...

Oh yeah! There it is! We gave Rails a custom error message when we typed out our #validates method for inclusion! Smurfity Smurf! That’s so smurfin’ awesome!

Okay, now let’s implement our other validations.

Here I’ve added a validation for occupation, that checks to see if the user entered a unique occupation by setting uniqueness: to true. Let’s see if it works.

Uh oh!  Looks I already have a Smurf who is an artist. I didn’t do any magic tricks behind the scenes here - because I already added the code to my form to show error messages, what’s displayed here is the default message for a uniqueness validation error. Now my user knows that the value entered into the occupation field has already been taken. Hmm... I guess Van Gogh Smurf could take up basket weaving or something.

Now let’s set up our validation for a Smurf’s name. Hmm... now this one’s a bit tricker - we can’t use the inclusion helper, because anything we enter as an allowable field would have to be one of those values, and only one of those values. For example, if we did 

inclusion: { in: { %w(Smurf) } 

this would only allow our user to be named “Smurf” and nothing else. As cultish as they are, we do want to allow some individuality in Smurf Village. Sounds like this is a good time for a custom validation.

Rails has a few different ways to set up custom validations, but I’m going to tackle what I think is the simplest solution here - using custom methods. Let’s go back to our Smurf model to implement this.

Now you’ll see that I’ve added a couple of things to my Smurf model - let’s start by taking a look at the new method, #name_must_be_smurfified. Here, I want to check for a false case (i.e. an invalid name) so I’m checking to see that the name is not Smurfified through 

name.include?(”Smurf”) == false

If the name doesn’t include “Smurf” then I want to add an error message for the particular attribute I’m checking for, and a custom message to go along with it.

Then, under my other validations, I use the #validate method (in Rails a validation helper uses #validates, whereas a custom validation uses #validate (no ‘s’), calling it on the method I just defined, ‘name_must_be_smurfified’.

Let’s see if it works!

Ugh, Harold! It’s like you’re not even trying! Do you want to be a Smurf or don’t you!?

Smurf me blue all over! Harold came through, Smurfified his name, and now we can see that our validation method worked, it saved Harold Smurf as a new Smurf, and redirected our user to the Smurf’s show page! Yes!

And, if we take a peek at our Smurf Villagers, we’ll see he’s been added:

Yes!  There is he is!  He’s saved to our database and we can rest easy knowing that Smurf Village is neat and tidy.

One more validation to go!

Here, you’ll notice that I’ve switched things up a bit - using #validates_inclusion_of with a little bit different syntax. I want to validate the age attribute, making sure that the new Smurf’s age is somewhere between the range of 100 to 541 (Papa Smurf is 542 years old - I know, right!?), and I made another custom error message.

How do these two methods compare? Is one better than the other? Is one older than the other? The answer is... I don’t know! What I do know is that they both worked - so I may continue playing around with the syntax and continue checking that they work until I find out what my preferences are.

So, let’s check one final time to be sure that our validations are all working...

Awesome! Our system is working and our user knows how to re-submit the form correctly.

Smurf-a-rific! Now we’ll be sitting on database gold!

[jennyjean8675309-blog]

An Intro to OOP and Ruby (or, How to Create Your Own Spells)

Walking into the world of programming for the first time, I’ve felt a bit like Harry Potter, who entered the world of wizardry as a first year, and whose Muggle background didn’t quite prepare him for such a major cultural shift. Instead of hearing funny words like “quidditch”, “dementors”, and “gillyweed”, I hear things like “version control”, “command line”, and “BASH prompt”. Walking through our programming spaces, I see whiteboards full of funny signs and symbols that I don’t recognize, but that I suspect must be somehow related to our craft.

Like Harry, even though this world is strange, I’m excited to be part of it, and I’m determined to find my own way and prove myself (though for me, sadly, it won’t be as the youngest Seeker ever).

I’ve been learning the powerful language of Ruby, and, so far, so good. I’ve learned to write some simple methods and some more complex methods, learned what a hash is, what iteration is, and why scope is so very, very important. Though I’ve wanted to rip my hair out sometimes when I can’t get past a certain error message, or learned that I’ve forgotten the keyword ‘end’ for the umpteenth time, I’ve been truly amazed that I’ve been able to get my computer to do things for me. Cue Hermione’s slightly smug, satisfied look as she makes her feather levitate.

Ruby is very organized - information is categorized into certain data types, or classes. In the string class, for example, characters are wrapped in quotes. Integers are a different data type from strings, so they are organized into their own integer class.

Here, I’ve set a variable, snape_name, that refers to an instance, or an example, of the string class and another variable, page, that refers to an instance of the integer class.

snape_name = "Severus Snape" page = 394

Ruby can do certain things with some classes that it can’t do with others. If I tried to tell Ruby to add snape_name and page, like this...

snape_name + page

I’d get an error message!

TypeError: no implicit conversion of Fixnum into String

It’s my computer’s way of saying

only nicer.

The + sign is a mathematical operator, and is only intended to be used on number types, not strings. So it makes sense that when you try to add a number to a non-number your computer doesn’t know what to do.

Relating to the wizarding world again, we all know that the spell “Alohomora” unlocks things. Well, what would happen if we tried to call “Alohomora” on something like Crookshanks, Hermione’s cat?

A cat is not something that can be unlocked, so again, our wand (or programming language) doesn’t know what on earth it is that we are trying to do.

“Alohomora” is a spell - it does something to the things we call it on (i.e. unlocks things) - in the programming world we call these methods. If we were to call “Alohomora” on an instance of the LockedThing class, it would work! But if we try to call it on something that is not a LockedThing, it doesn’t work.

Ruby has a certain number of classes already defined for us and each one comes with a certain number of methods that we can call on it. (A handy tip is use the #methods method to see what kinds of methods you can call on a certain type of class - like this: String.methods - be sure to capitalize the class in question). You can also check out this Ruby documentation to get more exhaustive information on classes and methods (including how you can use them) - this has been the best resource I’ve found so far as a newbie - like Hermione, I’m found in this library quite often. 

So Harry, Ron, Hermione, and all of the other first years are well on their way to learning how to use their wands (programming languages) and their spells (methods) properly - learning which spell to use in which situation and how to say them correctly.

Not leviosA. Syntax errors - what a nightmare, honestly. 

But what if Harry, Ron, and Hermione were told that THEY COULD WRITE THEIR OWN SPELLS as first years?!!!

After all, only the most powerful witches and wizards are able to do that. 

Well, what if I told you that, as a newbie programmer, I can do just that. I can create my own classes in Ruby, create instances of those classes AND write my own methods that can be called on those classes and instances. 

This isn’t possible because I’m a super powerful witch, er, I mean, programmer - it’s because I’m building on the shoulders of those who have come before me - waaay back in the 60s and 70s when OOP, or Object Oriented Programming was born. 

In the 1960s the first programming language to use objects was Simula 67, developed in Norway by Kristen Nygaard and Ole-Johan Dahl. Then, in the 1970s, the term “object oriented programming” was first used by Adele Goldberg and Alan Kay with Xerox PARC in their Smalltalk programming language. Smalltalk was more dynamic than Simula 67 (meaning it could do more and was more flexible), and was also the first language to introduce the inheritance concept (don’t worry if you don’t know what that is yet... it’s super awesome, but a little more advanced than my current topic). If you’d like to read a little more about the history of OOP, you can do that here.

Object Oriented Programming simply refers to the process of using objects (classes) as the foundation for computation.

What does this mean? Well, let me demonstrate...

As of now, Ruby doesn’t have a built-in class for LockedThing or a method for Alohomora... so, let’s be programmers and build them!

Creating a new class in Ruby is as simple as using the ‘class’ keyword, like so:

class LockedThing end

That’s it!

Now if I want to create an instance of the LockedThing class I can do:

third_floor_corridor = LockedThing.new

Here, I’ve used the #new method to create a new instance of the LockedThing class and set it equal to a variable, third_floor_corridor.

To check this worked, you can use the #class method on third_floor_corridor to check which class it belongs to:

third_floor_corridor.class   => LockedThing

We did it! 

But remember, we want to create a spell (or method) for instances of our LockedThing class that will unlock them for us, so let’s build out our class a little more:

class LockedThing    def alohomora        puts "I am now unlocked!"    end end

Inside of the class we just created we can use the ‘def’ (define) keyword to define a new method, alohomora, that, when called on an instance of the LockedThing class, will puts out the string, “I am now unlocked!”

Let’s try it:

third_floor_corridor.alohomora

I am now unlocked!

Yaaas!!! This makes me feel like...

Let’s make another instance of LockedThing and see if it still works:

dumbledore_candy_cabinet = LockedThing.new

dumbledore.alohomora

I am now unlocked!

(We all know only Fred and George would be mischievous enough to use this one).

In conclusion, OOP, or Object Oriented Programming is an extremely helpful and powerful way of getting things done - now I’m off to create a spell to get my cat to stop coughing up hairballs.