Category: Post-midterm reflection

So starting off reading chapters 10 and 11, I can immediately point out the fact that my coding flies in the face of the teachings of this chapter. I have very little in the way of organization and my coding is more of an  amalgamation of then an organized set of well thought out functions. I thick that part of this lies in the fact that I originally didn’t know how to do what I wanted and ended up with a lot of errors in my code and in trying to brute force my way past these problems I ended up coding very inefficiently. I recognized that I needed help and took action to receive it however had I read these chapters before hand I might have been able to understand and work through some of the problems that came up rather then just give up and seek tutoring.

 

DISCLAIMER: THIS IS LATE DUE TO UPLOADING IT ON THE WRONG WORDPRESS BLOG!!!

I felt like reading chapters 10 and 11 validated some of the lessons that I began to learn over the course of working on the midterm. At the start of the project, my code was deeply disorganized. I was thinking of the whole project as one still image and not thinking more seriously about how to make the individual components work best. That said, as I continued working, I began to see the importance of organizing my code, which is underlined in chapter 10. I created way too many classes as a means of keeping my code clean, which is not quite what the book meant, but is along the same lines. If I had read the chapters before my project, I would’ve thought more about the individual components of the matchmaker, and I would have thought to do things like create a loop for lines instead of drawing 40 individual lines.

Reading these chapters, I began to think about how I might want to practice planning out my code more systematically. Until the mid-term sketch, I would just throw in a bunch of ideas into a long set of main code and organize them as I am revising the code. This method worked for me because I never start my code with a clear idea of what I want to create, probably because I am still getting myself used to Processing. However, I think I should start getting in the habit of beginning object-oriented sketches with multiple classes rather than a single tab of codes since that will help me in the future when I write more complicated code.

The debugging chapter was interesting, especially the use of println(). Separating the code into smaller sections, commenting out, and testing with a new sketch are steps that I naturally followed whenever I was faced with a problem. Indicating the location, color, array and etc. is something that I should keep in mind when some objects do not appear on the sketch. Previously, when this happened, I would just copy the code for the specific object on to a new sketch and play around with it until it works.

After reading both chapters, I realized for my past two assignments instead of looking at the assignments as a whole and if I started to break things down it would have been much easier. Instead of trying to focus on all aspects at once working on one aspect at a time is something I need to work on. This would have prevented me getting stuck so many times. I liked chapter 11 alot it helps to know that every coder gets bugs and its not just me.

After reading chapters 10 and 11 I have realized how complicated I have made my coding thus far. Whenever I have an idea, I’ve never really organized it in any way. Breaking my idea into parts is a good way to simplify my idea so that it seems less overwhelming. Going from idea to parts would probably be the most difficult part for me, just because I wouldn’t know how to separate my big idea into little parts. I guess it will take some practice. Overall, I think creating some sort of algorithms with parts will make my code more organized and less overwhelming. It will also help in the debugging process.

In chapter 11 I loved reading about how everyone who does coding always has some sort of problem with bugs in their code. I honestly thought it was just me. It’s super frustrating when my code doesn’t work as intended, and then how I have to search my (unorganized) code for a bug. I guess I should probably make my code simpler and more organized. Also making comments throughout my code could be helpful as well. The troubleshooting process that they talked about in chapter 11 was really helpful.

These articles were interesting to me. I have about two years of experience with Java and have competed in UIL competitions using Java, and until last semester I was majoring in Computer Science. Technically I still am since I haven’t officially filled out the major change form. Part of me revolts against the order and technicality of OOP techniques, and writing clean code when it comes to art. I can totally see the value in utilizing these techniques and how much easier it can make everything, but it does feel very technical to me. Perhaps this is why I have not used much of my prior knowledge in any of my sketches. Art feels like a different world, but in reality, you need both order and freedom of expression. There is freedom within constraints. The iPhone is beautifully designed and ingeniously programmed. Great products utilize both, and I suppose art is anything that guides us to wonder. Nevertheless, it is a challenge for me to abstract “a brush stroke”, or to create a class for each object I want to use, but I suppose it’s like a painter pre-mixing their paints to be able to use them during the painting process.

This is my first big project that I did in this class by myself. I took the idea from the eight ball that I used to play with as a kid, and basically tried to digitize the same process. After reading few chapters in our assigned reading, I realized that I should’ve done something more original and creative. Processing is a great way to be creative, and express it in an unique way that is quite different than other forms of art.

I also wish that I organized my code a bit more, I realized that if I don’t take time organizing my code when I first write it, it is going to get complicated in the far run. A great way to organize code is using different classes and also using arrays. After being almost one with my code, I realized that I can make my code simpler and more organized by taking some things out and separating them into its own class. When I did so, I was able to go through my code easier.

These chapters have really made me reconsider how I approach coding in Processing. If I had first approached what I wanted to do step-by-step and simplifying it, I would have an easier time laying out my code. The way I went along my midterm is simply work with conceptions floating around my head and trying to code off of that. However, upon reflection, there were many times that I was stuck because I did not know how to approach a problem. Other times, I would have progress accomplishing a certain task until I realize that the way I was going about doing it would not work out later on, then I have to scrap the work and try the other method. If I had laid out my idea, wrote pseudo-code, I would have a much clearer understanding of what code would work. I would have saved a lot of time. This goes for the debugging section too. I rarely used println, and I realize I could’ve to really see what was going wrong. I wholly agree with getting someone else involved. When I went to a tutor to look at my code when it wasn’t working, simply the process of me explaining it to him made me realize where I could be going wrong.

After reading these chapters, I’ve been reminded about one of the most important concepts of coding, algorithms.  I’m not the most visually creative person, so sometimes my processing sketches could be very one dimensional and not very impressive. But after reading this, I am going to try to implement my sketches in a more algorithmic style and have the algorithm behave based on user interaction.