Process & Portfolio
Let's start at the very beginning - a very good place to start.
I believe the start of the design process comes with meeting the client. Whether external or internal, learning about their wants and desires is essential to the process.
During my 3+ years as a UI/UX designer (as a vendor at State Farm), I worked across multiple lines of business. I consulted with everyone from C-level suites to other designers on other teams. I built wireframes, database schemas, prototypes, and more.
The most important thing I learned is that a plan beforehand saves so many meetings later. Every step should be discussed. As a Web Producer II at eventcore, I frequently had to plan ahead to assess how much time things would need (for billing). I am also involved in new product design, which also requires UI planning and testing.
Designing Beautiful and Meaningful Things With Others
I believe that in design, one must be open to change. One example is the app grouvie. Grouvie was a team project; I took design lead, thanks to my background in design and user experience. I started by crafting a palette, based around the idea person's favorite color. I created a few inital icons, and when we switch some colors around, revamped it to be more legible on a dark background.
I think that incorporating user and team feedback is incredibly important. For the above app, I also instigated user testing at multiple steps. I believe feedback is best if it follows the acronym ASK - actionable, specific, and kind. You can't grow without feedback. Having also pair programmed, I think one of the most difficult things is finding yourself working with people that you can't review their code without animosity.
There are many sites that are no longer live that that I have worked on. I wish I had gotten more screenshots of projects. However, I have prepared a handful of screenshots of projects I loved that you can look at or click through. I also added my CodePen and GitHub. More projects are always forthcoming, naturally.
One of my favorite requirements in my bootcamp, writing blogs always solidifies what I am learning. I am proud of the work that I put into these those many years ago, and I hope that you learn something, or at least enjoy my attempts at humor within them. Going forward, as I continue to learn, I plan to write more.
The subtle science of git-ting it done
Everyone's been there. You and your friends find a magical pair of pants, on the last summer before college. That might be a book. Anyway, you all want these pants, to work them, show off how fantastic they make you look. What if the pants were a piece of code? Maybe a fashion app? You all love it, want to work, but unlike pants, you can all work on it at once! How does this magic work? Version control! It's this magical ability to have a central file, and everyone can control their own version.
What are the benefits of version control?
Well, say you're writing code for a pants design app. Becky can write the section on bedazzling and merge it with the larger files. At the same time, Paula can present her code regarding plotting pleats in pants. The real benefit is allowing everyone to create versions separately, on their own local machines, and merge them into one document.
How does git help you keep track of changes?
Now, git is your new coding best friend when it comes to version control. It keeps track of the changes you've made. If a file is changed, saved again, new folders made, it keeps track. Anytime you are in your repository [The place where you store your code], you can check your git status by typing just that. You know quickly what changes have been made. Then you just type git add and tell them which file you are ready to commit [which means to make it the master copy as it were], and commit them each.
Why use GitHub to store your code?
GitHub is really well structured to work alongside your git. It also allows for cross-Internet collaboration. As well, GitHub enables others to view your code, offer suggestions and to allow you to see others work and use them to improve or assist your own.
That's why we do this!
Dev Bootcamp is an environment where everyone wants everyone to succeed. Using version control, git and GitHub to enchance our communication and our community is just one step in creating greatness!
Thanks for reading!
Have a fantastic day!
What is involved in making a Class?
First, let's break down what a class is. A class is a type of Object - like a String or an Array. You make a class so that you can make repetitive methods, and new variables, without having to do all this repeatedly. First you choose a class name.
class Gamer
Excellent. we've created the Gamer class! with this class, we will be able to check on our gamer friends. First, though, we have to initialize!
def initialize(name, library)
So we call the initialize method, which is the default for the creation of the method. Here we've also asked for the name of the Gamer and their game library to create your Gamer object.
@playing = false
@library = library
@name = name
end
Here, we set the inputs to instance variables. instance variables are different from local variables because they can transcend methods, and be used at any time. Local variables don't exist outside the methods they are called in. This makes instance variables more useful to store information across our class. But now what?
DANCE CLASS, DANCE
Now we have to write things that this class can DO! After all, what's a gamer who doesn't game? They're not whole without a console to game upon. I know! Let's give them the ability to take a game and play it.
def play_game(request, console)
@console = console
@library.each {|item|
if item != request
return "#{@name} doesn't own that game!"
else
@game = request
@playing = true
return "#{@name} is now playing #{@game} on their #{@console}"
end
}
end
Ok, whoa. That's a lot of info. Let's talk about what is actually going on here. First, we take the request [and set the console to a instance variable so we can have it any time] and make sure the Gamer has the game! Otherwise we return the fact that they don't to the method. If they DO have it, we breakout another instance variable, this time @game, and change our variable from the initialization of the method @playing to true. Why? Because Later we're going to write method to check what's being played and a method to stop playing. Anyway, then we return a string saying what the gamer is now playing. But what if we want them to stop?
def stop_playing(reason)
@playing = false
@reason = reason
return "#{@name}stopped playing, because #{@reason}"
end
So, this is a pretty straight forward method. Very readable, if I do say so myself (Yeah, obviously I do but I'm still proud of it). You give a reason as an input for the Gamer to stop playing, and they will! Perhaps it's unneeded to store the input reason as @reason, but we do repeat it later on when someone asks us if we're not playing. In fact, let's look at a method I cooked up for that!
def is_playing?()
if @playing => true
return "#{@name} is still playing #{@game} on their #{@console}"
elsif @reason !> nil
return "#{@name} isn't playing anything because #{@reason}!"
else
return "#{@name} isn't playing anything yet!"
end
end
Here we go again, one of those fancy flip methods. Let's go through is_playing if by if. If the Gamer is playing something, we return it. If the gamer has a @reason for not playing, we return that. Otherwise, we let them know that Gamer isn't playing anything! That's all I have planned for this class! I guess that's all? Oh WAIT
end
Classes need ends too, otherwise you'll get some gnarly errors. Well, that's it. Gamer class built. Nothing else to do. Right? WRONG. The best thing you can do for a class you just wrote is test it. This is called driver code! It allows you to look at some examples of your code. So let's initialize some examples:
JonJon = Gamer.new("Jon", ["SR3", "Star Wars"])
Lauren = Gamer.new("Lauren", ["Fallout 4","DA:Origins", "Hyrule Warriors", "Rare Replay"])
Look! We made Gamers! Tey've got names and a library of games.. but do the methods work?
p JonJon.play_game("SR3","XBox360")
p JonJon.is_playing?()
p JonJon.stop_playing("CUZ")
p JonJon.is_playing?()
p Lauren.play_game("Star Wars","XBox360")
p Lauren.is_playing?()
First, we print them to the screen so we can verify that the methods work! Do they? Yes! We get the correct answer. If you don't believe me, ask the dishes. Er, or you can ruby it. Trust me :)
So that's it! We made a GAMER class. Now you know how to build classes, initialize, the difference between local and instance variables, and much more! If you need anymore information, feel free to contact me! Have a great day!
Dec 19, 2015Let's Re-iterate It!
What is an Array?
Arrays are a structured and ordered list. You can put any object in an Array. It's basically like placing numbered bullets in a gun. They are all going to come out in the same order. You can pop or push them out to rearrange or discard them. However, they aren't really linked to any other values. The bonus to being so firmly ordered is that it makes them easy to manipulate by order. You could have lemmings_array, and use the iterator to have them do something.
lemmings_array.each do |lemmings|
# something inane, because lemmings
end
But you can also iterate over a hash with .each which leads us to...
What is a Hash?
Hashes are lists of items. They are paired, one key goes to a value. You give a key and get a value, like a dictionary. Now keys are unique - keys cannot have more than one value. However one value can have many keys. For example, if we were to use characters from the musical Hamilton as keys, we could see the values:
cast_ham = {
"Hamilton" => "writes like he is running out of time",
"Burr" => "talk less, smile more",
"my country" => "young, scrappy, and hungry",
"Lafayette" => "America's favorite fighting Frenchman",
"Angelica" => "Looking for a mind at work (WERK)",
"Eliza" => "Let historians wonder how Eliza felt"
}
Differences!
Now, to emphasize the differences - Arrays are singular objects in a very hierarchal and manipulative order. Hashes are a loose [only in recent iterations of Ruby are they even remotely ordered] collection of paired items - like a dictionary.
Dec 6, 2015Going Through the Module cycle
What is Enumerable?
Enumerable is a module, which is a mixin class that you can plug in, without it needing to be of a certain parentage. These classes of methods are for searching and traversing things. Ruby is fairly unique as a programming language, because it allows for these mixin modules. Basically, say there is a child of family X. Now being a child of X endows them with certain things, like a large bank account or trusting manservant. But if they wanted to fight crime, X child would have to get outside help, like from module Assassin or Vigilante. Then they could use all of the things in that module to fight crime or save their city.
For example, .injustice?(x) is a public instance method of module Vigilante that allows for sorting unjust events.
puts x_child.injustice?(list_of_events)
end
Now that we understand modules, mixins and Enumerable, let's move on!
What does #cycle do?
Cycle is a public instance method of Enumerable. It's used to cycle through an array. If you pass it a number, that's the toal number of times it will cycle through an array. You can also pair it with other items, like to go backwards through an array 3 times, you could do [1,2,3].reverse_each.cycle(3) and you'd get [3,2,1,3,2,1,3,2,1].
So in Summary
You can us enumerable methods to iterate and sort and seperate and do all kinds of neat stuff, because Ruby likes to let all the mixins and modules and code get together. It really allows for a great customization.
Dec 11, 2016Function-ing Well vs Being Method-ical.
What are these things, JAH-VAH-SCKRIPT and ROO-BEE?
Ok, let's start by defining some terms. JavaScript and Ruby are programming languages. They're languages programmers use to talk to computers. They are both Object-oriented, so they provide the ability to make objects within the code and then code to do stuff with those objects. Objects can be numbers, arrays, or words (in coding, they're called "strings" and usually seen between "these handy quotes"). Many programming codes share similarities. JavaScript (herein referred to as JS for short) and Ruby both have similar loops, similar objects, use numbers. There are some differences, however. For example, functions vs methods.
Is this where your punny subtitle comes in?
Oh how KIND of you to notice. Yes, here it is. So, let's start with functions. JS functions are bits of code that take an input (like "bubbles"), evaluate it and return a value(like "OOPS POPPED IT."). Got it? Now Ruby has these things called methods. They take input, evaluate it and return a value. Sounds familiar, right?
...they're the same.
No. See, they handle their operations differently. As Nick/Skilldrick wrote "A language like Ruby is a toolbox with some really neat little tools that do their job really nicely. JavaScript is a leather sheath with a really really sharp knife inside." I like this analogy, because it explains many of the chief differences between the two, including those that many of my classmates have covered. In terms of functioning, though, JS is again, very straightforward. You make the function, it does the thing. Done. You can pretty much declare internal objects outside the function. Methods are different in terms of changing, or adding anything. There's also a difference between Blocks, procs and lambda methods (for more on that check out this article or this).
So, sum this up for me?
Basically, JS and Ruby are two languages, both alike in object orientation. From these civil codes rise new mutiny - differences in how they operate functions. JS uses functions to do all manner of things - one weapon, many uses. Ruby has many different tools for processing these things. They all serve their seperate purposes. Hopefully this illustrates the massive difference between functions and methods. Thanks!
Jan 2, 2016Laying Out Inline and Block
What is inline? What is Block?
Many elements have a natural block state or inline state. what does this mean?
Inline means that the items are in a line. They do not have padding, they display everything in the same line. They're agile, but they don't really have a border. They're like a speedster in a video game. You can have loads of them, but sometimes they just aren't appropriate for the elements. Haveing all the paragraphs inline wouldn't look so good, right?
Block is a different style. it BLOCKS everything from being near it - refuses any other element in the same line. This your tough guy - has a border, but doesn't want anything else on the same line. For example, p has an inherent block style, which is why these paragraphs are all on different lines.
How about inline-block?
This is the code combination of both inline and block, just as the name would imply. Basically, if you want objects next to each other, but still have the ability to push around other elements like a big old block, you need inline-block. It's the all around warrior - it can protect itself but it also has some speed.
Here's an example: The blog sections above are sectioned using inline-block to allow for even-ness all around.
What do we do with a command like inline-block?
The key is to use all of these commands to the best effect. Much like in a raiding party or Mario Kart race, you have to take context into account. Inline is useful if the elements simply need to be next to each other. Block is good if you need borders but nothing else in the same area. Inline is the combo that makes both features available.
Don't Drop the Table
What is SQL Injection?
A SQL injection is when a malicious user inserts SQL commands or such to attack the database in which they are inserting the commands. First ingredient required is an unsecured SQL database. Then forms to search this database. Using these, hackers can attempt to gain and mainpulate data from the database
How the Attack Works
Basically, if you enter a SQL command in the form for an unsecured data. The mother in the above comic is illustrating that the name she gave her child will result, in any unsecured database, the table of students to be dropped. A hacker could even enter as simple of a comand as "=", given that the could could return true, and give them access.
How to protect Your databases
You could blacklist the inputs that would cause this, however, often the commands, like drop, are legitimate entry options. You wouldn't block someone from looking up "when the bass drops", because we all need to know. Parameterized queries [prepared statements with variable binding] should be used. The use and practice with these will allow the coders to teach the database the differene between data and code. The implementation of this is variable from language to language. This article has several recommendations broken down by language. You can also enter code that will escape out of any user entry, but it is frail. This is best saved for legacy code, that needs to be grandfathered in but also kept safe.
Conclusions
When learning to program SQL databases, protect them from malicious attacks by ensuring the database knows code from user input. Research methods to do this, and, if it's legacy code, try to at least escape out. Hopefully this has made things clear for you and you will know, when you go to program SQL databases, where to start.
Jan 8, 2016