Application Program Interface (API) is a service that provides raw data for the public. We reviewed how we can create our own APIs so that we can use them for CRUD functionality in apps, which was a pretty fun scenario to take a look at.
In class, we played around with the following code to make API requests – and I thought it was a pretty good chunk of code that I could use for future reference when it comes to API-related projects:
var url = "https://api.wunderground.com/api/api_key/geolookup/conditions/q/va/midlothian.json"
// $.ajax takes an object as an argument with at least three key-value pairs...
// (1) The URL endpoint for the JSON object.
// (2) Type of HTTP request.
// (3) Datatype. Usually JSON.
console.log("Ajax request success!")
console.log("Ajax request fails!")
console.log("This always happens regardless of successful ajax request or not.")
I learned about how directives are markers on a DOM element that tell Angular JS’s HTML compiler to attach a specified behavior to that DOM element. Angular expressions remind me a lot of inline Ruby code, which allow you to execute JS code in HTML files.
We got a head start on our homework, where I found myself running into errors. Hopefully when I work on it some more this weekend, all will get better.
After a long week of building CRUD app after CRUD app in Rails, today our Project 2 Week was kicked off with an intro to the project requirements. I’ll have to build an app in Rails that uses at least two models with at least one association, have complete RESTful routes, have error handling & validations for all resources, and utilize an ORM to create a database table structure.
I pretty much built the bare bones for my app at the beginning of the week as we went through learning CRUD. So today I worked on cleaning up my older code, adding a user login, styling the app a lot so I can get some inspiration on where to take it (for some reason when things look nicer, I get more motivated), and created another model.
Here’s a screenshot of my work in progress:
In the morning we presented our projects in a science-fair style, where several of us had our laptops set up on boxes. I realized I was way more excited to talk to people about the logic behind my incomplete Hangman project than I was about the logic behind my Flash Cards. It just goes to show that it’s better to work on something that you can get excited about because you’ll work even more at getting it right.
After projects, it was a day focussed on object-oriented programming with constructor functions and prototypes. I’m realizing I’m understanding the concepts a lot better now, but certain concepts are still a bit of a struggle, like when to use return statements.
Nevertheless, I’m excited to see how things pan out with this program. Next week we start working with the back-end, so that shall be interesting.
This week has been utterly exhausting! I started the day off tackling Hangman and was pretty proud of the progress I made. I was pretty ambitious and wanted to finish everything today, however, that’s somewhat ridiculous since I already completed one of the other projects for project one. Nevertheless, I did manage to get most the of logic coded. The main problem I ran into was figuring out how to get the masked word to show up, letter by letter, based on what the user guessed.
I’m excited to figure out drawing the frames of the Hangman as well, and figuring out the logic for how many guesses the user has until it’s a game over. Although I wasn’t able to complete the project today, I’m hoping to make some progress either tomorrow night or Friday. Interestingly enough, even though the day was filled with a lot of frustration, I was pretty proud of the small wins I achieved on my own, even when they were when I figured out what was wrong in the code and didn’t necessarily have an answer just yet.
Tomorrow we’re presenting our projects, so I plan to present my flash card application, and plan to also show off the canvas drawing element that I just got started with for Hangman.
This afternoon was a lot of fun since we met with the Outcomes team and had a career coach run a workshop with us where we did a couple of exercises to help us write our brand statement for who we are all about when it comes to being an employee. We broke off into groups where one of us pretended to be the interviewer, the other was the interviewee, and the third was the scribe who wrote down any words and phrases that described the qualities of the interviewee based on his/her responses to the interviewer. It was a fun exercise and I really enjoyed hearing more about my classmates’ stories.
This morning consisted of several hours of pure frustration, as I couldn’t figure out one particular issue. In the future, I really need to learn how to let some issues go and revisit them later, since today I ended up realizing the problem I wanted to solve, wasn’t a problem at all. In fact what I initially set out to do, didn’t make much sense!
I wanted to work on event listeners for keypresses, so users could move to the front and back of cards with the enter and right-hand arrow key. Then I realized that the enter key was sufficient enough for when users are adding input, but that the right arrow key wasn’t intuitive enough. Instead, I made the entire cards clickable, so users could navigate that way.
I also learned how important it is to really plan out the logic behind your applications before you start coding. If I had thought through more of the main functionalities I wanted, I may not have run into as many issues as I did, where I had to readjust my code along the way. However, I suppose you can’t always plan out everything. Sometimes your coding will unfold organically.
Today was the first day of our project week. This week, we’re all expected to get to GA bright and early and work away all day long on our first major project. Our task is to complete a familiar game with HTML and JS. We had the following games to choose from:
- Tower of Hanoi
- Flash Cards
I decided to go with flash cards, simply because creating a game on its own will be a challenge enough. I’m still struggling to figure out the logic when I start projects, and I’m hoping that will change over time.
Over the weekend I managed to complete most of the project’s functionality, so for the most part I worked on compiling the content for the cards, finding images for the front and back of the cards, and working out some of the styling issues. I kept running into issues with event listeners, since my game involves users guessing the answer to a card in an input, then clicking to view the back of the card, then clicking once more to see the next card. The game includes scoring, a timer, and the option to play again when the game is over.
I’m definitely out of my comfort zone now when it comes to WDI, which is great – let the learning commence!
Today was another lab day, and it was definitely a struggle. Our assignment was to create an ATM where users could deposit and withdraw funds in a checking and savings account. If the account value was zero, a CSS class needed to be assigned to the ATM that highlighted the balance in red.
At the end of the day, I managed to complete the lab along with the bonus assignments. My biggest issue was being able to make the code cleaner. I was able to get the functionality down right, it was just a matter of writing shorter code. I guess that’s something for me to aspire to?
- Console.log is really useful in figuring out how the browser is reading variables
- Figuring out when a user is clicking a button within a specific div
- Pseudo coding well in the beginning can really help you out later
The big takeaway was, when in doubt, console.log it! Or Google it…
In the afternoon we met with the Outcomes team who had a panel of GA graduates talk to us about their experience in the program. It sounds like there is definitely a struggle in the program – a lot of frustration when you’re beginning to learn complex problems – but ultimately, if you keep at it, things will click and make sense to you.