Webapp Blog Post 3

The Google App Engine eliminates the need to worry about web servers interacting with data that is spread around two many different locations around the world. The data repository is called a High Replication Datastore and uses the Paxos algorithm to replicate data across datacenters. Entities are data written to the datastore. Each entity has a key that uniquely identifies it in the database. There is also the option with each entity to designate another entity as a parent entity, making it the child of the parent entity. In this manner the datastore entities form a hierarchical structure. The hierarchical structure consists of ancestors, descendants and root entities. Ancestors are anything above the entity (its parents or its parents parents, etc.), descendants are anything below the entity, and a root entity is an entity without a parent. An entity descending from a common ancestor with another entity is said to belong to the same entity group as that other entity. These groups have a parent key, which is the common ancestor's key. This key identifies the entire group and ancestor queries which query of an entity group refer to the parent key instead of the specific entity key. A primary strength of the datastore is that it is very resilient in the face of catastrophic failure.

HTTP GET vs HTTP POST Requests

The primary difference between HTTP GET and HTTP POST requests is that HTTP GET request asks for data from the specific resource while the HTTP POST request submits data to be processed. For example, in the Guess Number lab the get() method in my code responded to the HTTP GET request from the browser by writing a response that output "Good luck!" with a form asking for the initial guess a submit button. The form then uses an HTTP POST request to provide the guess to be processed by the post() method in my web application.

There are also other differences between HTTP GET and HTTP POST requests. HTTP GET requests include the parameters in the URL, are used for fetching content, have a maximum length dictated by the maximum URL length, are okay to cache, and should not change the server. HTTP POST requests include the parameters in the body of the request, is used for updating data, has no maximum length, is not okay to cache, and can change the server.

Vectors and Arrays Advanced Computer Science

After working with both arrays and vectors in c++, the primary difference I see between the two is that while arrays are of fixed length, vectors can constantly be added to by inserting new elements. This naturally inclines both of these different data structures to be effective for different tasks. While arrays are very good for programs in which I know exactly how long of an array I need, vectors are good for performing operations in which the length of the vector either changes or depends on the value of an alternate variable. For this reason, I find vectors to be much more useful. They also are useful in that they store with them their size and their capacity (how many elements could potentially be stored in the currently allocated memory block). Vectors also change the amount of memory they are allocated as their size changes and the memory they took up is freed when they are destroyed. The trade off of all of the benefits of vectors is that for small, short-lived arrays vectors are not as efficient. One example of when vectors came in handy was when doing the lab that the group presenting vectors designed. In the lab I had to iterate through thousands of triangle numbers to find the one that had over 500 multiples. This would have been impossible to do with arrays because I didn't know how many triangle numbers it would take to come to an answer (it ended up being a lot). However, with vectors, I was able to continue to add triangle numbers to the first position of the vector and expand the size of the vector until I reached the triangle number I wanted. Overall, I like using vectors more than arrays, but both data structures have their own advantages and disadvantages and which one to use depends largely on the situation at hand.

Web Applications Blog Post 1

Learning HTML/CSS

I think that the way in which we learned HTML and CSS in the class was fairly effective. I enjoyed the different projects and think that those were the most helpful things we did. The powerpoints were also beneficial, but sometimes felt like an information overload because we went through them very fast. I didn't like using codeavengers. While it was sometimes helpful the majority of the time it was just regurgitating what was taught in the powerpoints and was not particularly innovative in how it did so; I didn't really like that codeavengers felt very tedious and was very particular about what it wanted. I would frequently do things correctly but not exactly how they wanted it, which was very frustrating. It felt a lot like busy work when we were doing it. I think that doing projects is the best way to learn to code because it forces me to figure out how to do things and I learn as I look things up while I go along. While the html projects were a little frustrating, I still learned a lot while I was doing them and think that they were worthwhile.

I learned the most when doing the Stanford assignments we did in class because they were very challenging. I had to spend a lot of time googling things and working with others to figure out how to make the assignments look right. The biggest thing I learned while doing the projects was the importance of divs, classes, and ids in organizing html to make for cleaner code and easier css. While these things are not necessarily visible on the page, they are very useful in organizing the page. Overall, I think that I learned a lot about HTML and CSS formatting and am much better prepared to use it effectively on projects in the future.

Algorithm Ted Talk (Advanced Computer Science)

I thought the most interesting part of the TED Talk was the idea that the algorithms that are written to do various things are beyond the control of the humans that created them. Many of the algorithms that are floating around on the internet are not understood by anyone and I find it very interesting that there are algorithms so complex that what they are actually doing is unknown. The possibility raised by the speaker that its possible that these algorithms could suddenly just stop working was something I had never previously considered. Almost everything is controlled by algorithms, many of them incredibly complex. When these algorithms stop working, it may be nearly impossible to figure out why, or even to know that they are no longer working.

The other part of the TED talk that I found interesting is how much money is poured into infrastructure that works solely towards knocking micro seconds off the amount of time it takes to send a single transaction. The idea that mountains are tunneled through by companies just to gain a seemingly intangible edge over the competition is incredible. The amount of time being saved by multi million dollar investments is less than the amount of time it takes for me to even click my mouse. The complexity of the algorithms involved and the amount of money poured into these fiber optic cables underground is astounding.

Overall the TED talk altered how I think about algorithms. I didn't realize the scope and importance they have in everything I use in my daily life, from watching videos on Netflix to driving my car. The TED talk taught me that there is a whole world of complex algorithms operating beneath the surface of the internet that i'm entirely aware of yet have a significant impact on my life, and that these algorithms can be studied and dissected in the same way that one might observe and dissect living organisms.

End of Year Reflection

 Throughout the year AP Computer Science has consistently been one of if not my favorite class to go to. While on B days, I often dread going to physics and sitting through an hour and a half of lecture, A days are not like that - and much of this is due to having computer science third period. While comp sci is not perfect, nor is it always enjoyable, it still maintains a relaxed atmosphere that makes the course not feel so much like an AP course. I took computer science because I am interested in computer science, not so I could gain some sort of exemption from college classes, and this probably influences my perspective of the course when looking back on it, but regardless I enjoyed computer science much more than I can say for many of my other classes. I took pleasure in coming each day to learn new aspects of java and programming as a whole, despite not loving every topic. There were parts of the class that felt unnecessary, parts that I forgot immediately after the lecture and never relearned, and parts that I wish we could have covered in more depth, but that is intrinsic in the nature of any class. Overall I had a positive experience that I feel has influenced the career I plan on pursuing in the future, whether it be engineering, computer science, or something entirely different I haven’t yet decided upon. AP Computer Science is one of the few classes that I can say that for.

 There were many things I liked about the class. Foremost among these is the labs. Some of the labs I feel could use improvement, among these the localization lab, gridworld labs, and pong lab, but others like the recursion lab I felt were very helpful. The localization lab falls under the category of labs that I feel is a good idea but just seemed too easy. It wasn’t really a bad lab, I just didn’t get any sense that I was really learning much new from it and upon finishing, I was left wondering if Weston and I had perhaps missed another page of things we were supposed to do or looked at the lab in too simplistic a way. Having said that, it was a good review of scanners and arraylists as well as a small introduction to abstract classes; I just feel it could have been fleshed out a little more. I understand that it is very difficult for you to make something like gridworld interesting, and that you were using previous AP problems for the gridworld labs, but they still felt boring and tedious. There is probably nothing you can do about it, but I felt it worth mentioning that the gridworld labs were among my least favorite labs of the year. As for the pong lab, I don’t feel entirely correct in putting it in the can be improved category of labs because it was also one of my favorite labs. However, I think there were elements of it that do warrant being placed in that category. I think the instructions in some areas could be clarified, and that implementing the collisions was a nightmare. My primary suggestions would be to put somewhere that by default only certain keys work to move the paddles, and also to provide a clearer explanation perhaps in pseudo code or a general algorithmic outline of how the collisions should work. With a few clarifications in the code and instructions, I think the pong lab would easily be the best lab we do. The recursion lab was one of the most helpful labs in my opinion. While practicing on coding bat I was a little confused by the concept of recursion, and it was not until I did the labs that I really felt I had a pretty good grasp on it. Overall, for me the labs were the most important part of the course and I can’t imagine learning computer science not through labs. Programming is a very experiential skill, and I think that doing labs is the only way to really learn the material.

5th Six Weeks

     This six weeks we have learned recursion and various methods of sorting lists as well as searching methods. An important concept we have been introduced to is the idea of efficiency, adding an additional element in deciding how to structure programs. Rather than just looking at how to solve a problem, I must also look at how to best and most efficiently solve a problem. Sorting algorithms we have learned include bubble, selection, insertion, and quick sorts. I like quick sort the best because it tended to have the shortest run time out of all the sorts when we tested it in the sorting lab. Between the binary and linear searches we learned I like the binary search much more because it is much faster and better in almost any situation. Recursion is a difficult topic to learn initially, but doing the labs and playing cargo bot helped me learn the concept, although I am still working on understanding it more fully. The thing I had the most trouble understanding when learning recursion was that I have to trust that the program will work. Instead of explicitly solving the problem, I have to establish the base case and through doing recursion allow the program to figure the rest out. It is also difficult to establish when recursion is necessary. After learning recursion, there is a tendency to want to use recursion to solve every problem I am confronted with, but often recursive solutions are not the best ways to do problems. I also started to learn how to combine HTML, Javascript, and CSS into one program in my free time because I was bored on Sunday. I discovered the website jfiddle.net and built a basic calculator using a combination of these three languages, something that took me way too long but I was proud of nonetheless. I found that while codecademy is helpful in learning syntax, when making actual programs it is more helpful to browse through other people's code and see how they did things in their programs, so I consequently spent a lot of time on stackoverflow looking at other people's solutions to issues.