Good morning, everyone.
The semester is officially over! What an incredible journey it has been, and it all went by so very fast!
So how about that last exam? I found it to be pretty difficult just because I felt kind of rushed when taking the exam. While there were only 10 multiple choice and the rest was written, I took the longest time trying to think up of a solution for the written portion and as a result, rushed through the multiple choice a bit. I am a bit disappointed with my results for the multiple choice so far, so I'll probably go in and see what I messed up on. Hopefully my short answers will make up for the rest of my test!
This class has been an awesome and amazing class. It's been tough considering everything we've learned in the class, but has been so extremely useful. I've applied all of the things we've learned into the real world, honestly. I've been doing some mobile app development, and things that we've talked about (especially in the second half of the semester) have really enlightened me to change what I've been doing so I can write cleaner and more efficient code. I've also been refactoring my SQL database so that redundant data becomes minimized. I look at what I had, and I look at how so much could go wrong with one edit in a row; so many other rows from other tables would have to be modified! With relational database management, this is easily solved.
This class has probably been the most helpful and useful class I've ever taken at UT. A lot of other classes teach their respective concepts and such, but most classes only go towards the theoretical aspects of what they teach. That is, they teach theorems and concepts, but we don't necessarily get a chance to incorporate them. Furthermore, when we do get a chance to integrate them, we attempt to based on our previous, introductory knowledge of writing code (a la 307, 315, etc). I feel like this class, if anything, should be taken as soon as possible so that people can learn the inner aspects of developing software. I seriously can't think of any other course that has taught me so much in so little time besides this class. I believe it has to do with the method of teaching (Socratic method), where Downing consistently asks students questions. Personally, as a student, I don't like getting called on and giving a wrong answer, because it makes you feel "stupid," especially if it's a relatively simple question. Granted, people who are put on the spot don't necessarily answer as well as they could if they weren't on the spot, but it's taught me that things like this will always happen to us in the future. In meetings where people have to present code and demonstrations in front of their team, there are bound to be questions. And one must answer them without having to feel nervous about it. It's helped all of us (I think) stay participated and engaged in the course, and prevents anyone from really slacking off in the class. I really liked how the class was taught. And of course, Professor Downing is down to earth and funny, so what else isn't to like about the class?
I feel more confident about what I write thanks to unit and acceptance testing, and I feel better about how I process things. While I still haven't fully inhabited the "test first, code later" mechanism, I think that this will be highly useful once I get into the job industry. Everything we've learned, be it from readings, code, projects: these techniques and tools will be used extensively in my career. I've actually noticed in a lot of job descriptions that things such as version control, and agile methods are almost requirements to know. While I haven't fully experienced an agile-ran environment, I know how it works, so whenever I get a job that involves that system, I know how it all will work without having to feel consistently pressured. Relational database management and just knowing the basics of SQL have also seem to be on many job descriptions.
I actually had a phone interview a week or two ago, and the interviewer had asked me what my most helpful class was at UT. I had told him it was this class, and I went on explaining what I learned/did in the class. Turns out, the interviewer had also gone to UT and had taken this class with Professor Downing. He too had stated that this was the most useful and helpful class he has ever taken. So it seems like it's a consensus that this class is highly important and highly useful for the future of students. I would highly recommend this class.
Professor Downing, thanks for all that you've taught me and the rest of the class. It has already proven to be useful, and I am positive the things that we've learned in class will be applied extensively when we approach the real world. Thank you so much!
Until next time,
Corey
Saturday, May 5, 2012
Sunday, April 29, 2012
4/23 - 4/27 CS373 Blog Post
Good morning, everybody!
Wow, it's already the last week of classes. It truly is incredible how fast time has flown by this semester. And for me, this marks my last semester as an undergrad at UT. After this, it's essentially the "real world" from here on out!
For the last few classes, we had talked about more refactoring, as well as different factory methods of refactoring. I actually have a pretty amazing story that revolves around these ideas. Last Wednesday after class, I had an interview for a start-up mobile development company. We had met up at a coffee shop just to discuss things casually. He began to ask me iOS specific questions, such as what a category is, what provisioning profiles do, delegation, et cetera. We get to one part that becomes more generalized in object oriented programming, and he asks me what a singleton is. Knowing this from the previous week, I began explaining the different kinds of singletons and what their general purpose is. Immediately after this, he asks me about factory methods; the thing we had JUST talked about in class that day. Thankfully, the idea was still very fresh in my head and I explain to him the different kinds. I just thought it was an incredible thing to know that I had just learned these concepts within an hour, and an interviewer had asked me about it.
Anyway, factory methods and just the general idea of design patterns has always intrigued me. I've taken a look at code that I wrote four years ago and I compare it to how I design things now, and it is incredibly different. I used to not write any methods; everything would just go into the main body, pretty much. Now I try to keep the main body as small and succinct as possible, and all of the inner methods the same. Breaking things down into small, reusable methods has proven to work very well for me. They are easily testable and it's easy to understand a function call just by seeing multiple method calls inside. Assuming the methods have names which are relevant, it is easy to know what is going on, rather than having to parse through old code that hasn't been looked at in such a long time.
Also, congrats to Team Cache Money! What an awesome presentation. The introductory video was very slick and a really intuitive idea; I kind of wish our team had done that! The website is pretty awesome and very catchy. Good job to you guys! I felt like our presentation was decent; nothing too fancy. There were a lot of things we could have done to make our website in general better, but we really just stuck to what needed to be done. We were all very pleased with our product and didn't want to mess with it if it already worked well. I'm proud of our group for all that we've got accomplished! It is an awesome site that we pretty much derived from scratch. I learned a tremendous amount of Python, HTML/CSS, Django, and database programming that I want to merge into my own websites. I currently run a website in PHP, but I want to try to convert that into Python+Django, because Django is such a nice template system! It's a lot easier to manage that than to hard-code the HTML into every PHP all the time.
Well, that's it for now. One more week and this class is finished!
Until next time,
Corey
Wow, it's already the last week of classes. It truly is incredible how fast time has flown by this semester. And for me, this marks my last semester as an undergrad at UT. After this, it's essentially the "real world" from here on out!
For the last few classes, we had talked about more refactoring, as well as different factory methods of refactoring. I actually have a pretty amazing story that revolves around these ideas. Last Wednesday after class, I had an interview for a start-up mobile development company. We had met up at a coffee shop just to discuss things casually. He began to ask me iOS specific questions, such as what a category is, what provisioning profiles do, delegation, et cetera. We get to one part that becomes more generalized in object oriented programming, and he asks me what a singleton is. Knowing this from the previous week, I began explaining the different kinds of singletons and what their general purpose is. Immediately after this, he asks me about factory methods; the thing we had JUST talked about in class that day. Thankfully, the idea was still very fresh in my head and I explain to him the different kinds. I just thought it was an incredible thing to know that I had just learned these concepts within an hour, and an interviewer had asked me about it.
Anyway, factory methods and just the general idea of design patterns has always intrigued me. I've taken a look at code that I wrote four years ago and I compare it to how I design things now, and it is incredibly different. I used to not write any methods; everything would just go into the main body, pretty much. Now I try to keep the main body as small and succinct as possible, and all of the inner methods the same. Breaking things down into small, reusable methods has proven to work very well for me. They are easily testable and it's easy to understand a function call just by seeing multiple method calls inside. Assuming the methods have names which are relevant, it is easy to know what is going on, rather than having to parse through old code that hasn't been looked at in such a long time.
Also, congrats to Team Cache Money! What an awesome presentation. The introductory video was very slick and a really intuitive idea; I kind of wish our team had done that! The website is pretty awesome and very catchy. Good job to you guys! I felt like our presentation was decent; nothing too fancy. There were a lot of things we could have done to make our website in general better, but we really just stuck to what needed to be done. We were all very pleased with our product and didn't want to mess with it if it already worked well. I'm proud of our group for all that we've got accomplished! It is an awesome site that we pretty much derived from scratch. I learned a tremendous amount of Python, HTML/CSS, Django, and database programming that I want to merge into my own websites. I currently run a website in PHP, but I want to try to convert that into Python+Django, because Django is such a nice template system! It's a lot easier to manage that than to hard-code the HTML into every PHP all the time.
Well, that's it for now. One more week and this class is finished!
Until next time,
Corey
Sunday, April 22, 2012
4/16 - 4/20 CS373 Blog Post
Good evening everybody.
It's been a fairly busy week for me. I've been working on three projects simultaneously: one due tomorrow, one due Wednesday (this project), and one due next week for my Korean class. It's the home stretch for these next few weeks, and once these projects get finished up, the stress level will most definitely go down!
We had discussed quite a bit about some pretty important concepts in programming: dynamic binding, abstract classes, and singletons. I had known about singletons through the practice of programming in Objective-C (iOS). Many variables within an app are designed to be only allocated once, since their resources are shared throughout the program. Such variables include the instance of the application, the user default item list, and the delegate manager. These are allocated when the application starts up, so these would best fit the definition of eager singleton variables. Since their resources are necessary when the application boots up, they need to be allocated when the program loads. It was pretty interesting to witness this in both Java and Python. Python is just a weird and unusual language for things like singletons. It's as if you can virtually do anything to it. You can replace the definition of a class with its instance. I mean, that just seems incredibly inconceivable to me, to overwrite the class with an instance of the class. Yes, it doesn't allow anyone else to create another instance of the class, but just by looking at it, it is so confusing. It makes sense when the singleton function binds a value to the callable object (which is the instance), and then spits out the lambda expression for it. It's ridiculously clever.
Abstract classes now seems to be a favorite topic for me to boggle my mind with. It pertains to another application I am writing, and many classes that are involved require the same methods to be written. Abstract classes would guarantee that these methods must be defined, which is helpful in the case that I forget to create some. Also, if I ever need to change the definition, it would immediately alert me that all of my other class methods no longer conform/define the new method. It's an incredibly useful idea to implement, which I will this coming week! I think it's a little weird to have multiple layers of abstraction: that is, have an abstract class with a child whose class is abstract, and so forth. I can understand maybe one or two layers of indirection, but not many more than that. I guess when building a giant library, this would make more sense.
We had also talked a little about dynamic binding, which was a pretty interesting topic. If the class is final, or the method is either marked final, private, or static, then static binding takes place. Definitely something useful to know. I know we discuss things per an example basis, but I think it would be interesting to see this being applied in a real-world example. It makes me wonder how much of the concepts of dynamic/static binding is really used in applications. I'm sure it's fairly often.
Just two more class days, and then project presentations. Then shortly after that, the last exam. It's insane that we've come this far!
Until next time,
Corey
It's been a fairly busy week for me. I've been working on three projects simultaneously: one due tomorrow, one due Wednesday (this project), and one due next week for my Korean class. It's the home stretch for these next few weeks, and once these projects get finished up, the stress level will most definitely go down!
We had discussed quite a bit about some pretty important concepts in programming: dynamic binding, abstract classes, and singletons. I had known about singletons through the practice of programming in Objective-C (iOS). Many variables within an app are designed to be only allocated once, since their resources are shared throughout the program. Such variables include the instance of the application, the user default item list, and the delegate manager. These are allocated when the application starts up, so these would best fit the definition of eager singleton variables. Since their resources are necessary when the application boots up, they need to be allocated when the program loads. It was pretty interesting to witness this in both Java and Python. Python is just a weird and unusual language for things like singletons. It's as if you can virtually do anything to it. You can replace the definition of a class with its instance. I mean, that just seems incredibly inconceivable to me, to overwrite the class with an instance of the class. Yes, it doesn't allow anyone else to create another instance of the class, but just by looking at it, it is so confusing. It makes sense when the singleton function binds a value to the callable object (which is the instance), and then spits out the lambda expression for it. It's ridiculously clever.
Abstract classes now seems to be a favorite topic for me to boggle my mind with. It pertains to another application I am writing, and many classes that are involved require the same methods to be written. Abstract classes would guarantee that these methods must be defined, which is helpful in the case that I forget to create some. Also, if I ever need to change the definition, it would immediately alert me that all of my other class methods no longer conform/define the new method. It's an incredibly useful idea to implement, which I will this coming week! I think it's a little weird to have multiple layers of abstraction: that is, have an abstract class with a child whose class is abstract, and so forth. I can understand maybe one or two layers of indirection, but not many more than that. I guess when building a giant library, this would make more sense.
We had also talked a little about dynamic binding, which was a pretty interesting topic. If the class is final, or the method is either marked final, private, or static, then static binding takes place. Definitely something useful to know. I know we discuss things per an example basis, but I think it would be interesting to see this being applied in a real-world example. It makes me wonder how much of the concepts of dynamic/static binding is really used in applications. I'm sure it's fairly often.
Just two more class days, and then project presentations. Then shortly after that, the last exam. It's insane that we've come this far!
Until next time,
Corey
Tuesday, April 17, 2012
My first app, officially in the App Store!
Good evening, everyone!
I'd like to announce that my very first iPhone application is now available in the App Store as of right now! It's called the Hands of Time Solver for FXIII-2.
It's a little difficult to explain how these puzzles work in the game, but I'll try with app screenshots. In the game, you stumble upon these things called Anomalies which are "temporal rifts" in the game's timeline. By solving the puzzles, the paradoxes (things that shouldn't happen in the timeline, basically) disappear and you can continue winning at life.
So then, how does the Hands of Time puzzle work? Well, let's offer a demonstration...
In each puzzle, there are numbers organized in a circle, with hands in the middle (hence, "Hands of Time"). The numbers can range from 1 to 6, and there can be as many as 13 of them. Each number represents the number of spaces that the hands will move in opposite directions. So, if a space had a '1' on it, if the person chooses this spot, then the hands would move to the selected spot. From here, the right hand would move one space right, and the left hand would move one space left. Sounds simple, right? It is for small puzzles, but when you encounter puzzles with 13 numbers with high values, this can be rather arduous.
In order to use this app, you must input the numbers in starting from the top-most number and going clockwise. Let's say, for instance, there were five numbers, and the top-most number started with 1, then 2, then 3, 1, 2 (pictured above). We would input them in that order. Once you press the solve button, magic happens. That's right, magic.
In the game, you have a choice of choosing which number to start on, but the app determines which number is most optimal for your puzzle. In this case, the app decided that the top number was the best choice for the first decision. When the user presses 'Next,' The hands will move in two directions: the right hand will move to the '2' on the right, and the left hand will move to the '2' on the left, as shown in the next picture.
Now that the hands have moved, we have two choices we can make, all depending on the number two. The app has decided automatically that the '2' on the left is the better and correct choice (note that the lighter blue is enclosing the correct choice). In this scenario, the choice actually doesn't matter, since they both lead to potentially correct solutions.
We choose the '2' on the left, and press next. When this happens, the hands will conform to this '2', and then the right hand will push two spaces to the right '2', and the left hand will push to the '3'.
Again, as we notice, the '2' has a brighter glow, indicating that this is the correct choice to make. Let's actually consider our options:
If we choose the '2', the left hand will hit the left-most blank spot, and the right hand will hit '1'. Then from the '1', we can hit the '3' and solve the puzzle!
But, if we choose the '3', the left hand will hit the left-most blank spot, and the right hand will hit the top-most blank spot. When neither hand targets a number, the puzzle is over and you are forced to retry with a different solution.
With this in mind, let's choose the '2' and see what happens.
As expected, the left hand hits a blank spot and the right hand hits the '1'. This is an obvious choice; we take the '1', which will push the left hand onto the '3.'
Well, this too is pretty obvious; we have no choice but to choose the '3'. And then...
Voila! Puzzle solved. You're so good!
The best part about this app is a nifty little implementation that I added. When you solve a puzzle, the puzzle is sent to a database. That database keeps track of the puzzles that users have entered in (when you download the app, you're prompted to register a username before starting). You can check out what other people are solving in the 'View Puzzles' section, located on the main screen. These updates occur in real-time, so you'll see updates from people who are submitting puzzles while it refreshes!
That's pretty much it on this app. It's completely free, and there are no ads at all! On your free time, go check it out in the App Store and download it! If you have any questions, comments, or criticism about the app, submit a post here.
Thanks again, and until next time,
Corey
I'd like to announce that my very first iPhone application is now available in the App Store as of right now! It's called the Hands of Time Solver for FXIII-2.
As the name suggests, it is a solver of sorts for the video game, Final Fantasy XIII-2.
So then, how does the Hands of Time puzzle work? Well, let's offer a demonstration...
 |
| The initial screen where you input your numbers. |
In each puzzle, there are numbers organized in a circle, with hands in the middle (hence, "Hands of Time"). The numbers can range from 1 to 6, and there can be as many as 13 of them. Each number represents the number of spaces that the hands will move in opposite directions. So, if a space had a '1' on it, if the person chooses this spot, then the hands would move to the selected spot. From here, the right hand would move one space right, and the left hand would move one space left. Sounds simple, right? It is for small puzzles, but when you encounter puzzles with 13 numbers with high values, this can be rather arduous.
In order to use this app, you must input the numbers in starting from the top-most number and going clockwise. Let's say, for instance, there were five numbers, and the top-most number started with 1, then 2, then 3, 1, 2 (pictured above). We would input them in that order. Once you press the solve button, magic happens. That's right, magic.
We choose the '2' on the left, and press next. When this happens, the hands will conform to this '2', and then the right hand will push two spaces to the right '2', and the left hand will push to the '3'.
If we choose the '2', the left hand will hit the left-most blank spot, and the right hand will hit '1'. Then from the '1', we can hit the '3' and solve the puzzle!
But, if we choose the '3', the left hand will hit the left-most blank spot, and the right hand will hit the top-most blank spot. When neither hand targets a number, the puzzle is over and you are forced to retry with a different solution.
With this in mind, let's choose the '2' and see what happens.
The best part about this app is a nifty little implementation that I added. When you solve a puzzle, the puzzle is sent to a database. That database keeps track of the puzzles that users have entered in (when you download the app, you're prompted to register a username before starting). You can check out what other people are solving in the 'View Puzzles' section, located on the main screen. These updates occur in real-time, so you'll see updates from people who are submitting puzzles while it refreshes!
 |
| Pretty neat, huh? |
Thanks again, and until next time,
Corey
Saturday, April 14, 2012
4/9 - 4/13 CS373 Blog Post
Good afternoon everyone,
Another week has gone by! It's incredible to realize that the semester is getting closer to the end. Just a few weeks, and then we'll be in final exam week mode. And then after that, we (or at least some of us) will have graduated from the University of Texas. It's a crazy thought to think about; to realize that it's already been four years since the first time I stepped onto campus as a freshman. It's a scary thought to think about because for now, I don't have anything planned. I have been looking for job postings, but I feel like I don't really qualify for some of them. It makes for a very worrisome experience, but I hope I can find something soon!
This week in class, we discussed about SQL and refactoring. SQL has always been a fun subject for me, and I feel like with some practice that I've had with database development on a website I've been working on, I understood the topics quite well. Relational database management, I've realized, is a highly important topic and is integral in attempting to minimize the amount of duplicated data in the database. I've noticed this in my website, and I've actually decided to change the database schema up completely so I can reduce all of the bloat in my tables. I probably won't get into this until later in May, since I have this project and a million of other things to work on. But it is definitely something I want to fix, and it's something I'm excited to work on! I've never understood joins very well, but they make complete sense with the use of primary and foreign keys.
Refactoring has been an interesting subject to talk about. I think it's one of those things that we just do subconsciously after we're done writing the code that produces the results we want. I do it all the time; I sometimes don't like where a method or a chunk of code is placed, and so I might create a subclass or a new method out of it to make it more organized. The cached variable versus calling methods multiple times argument is an interesting one, and I guess it makes sense that calling a method multiple times doesn't really affect the program's performance so long as it isn't so intensive. And while it is true that a local cached variable could get invalidated in between, it sometimes seems like it wouldn't be so likely. Although I guess the argument begins to matter more significantly with bigger projects with hundreds of source code files. The use of abstract classes was also an interesting one. I recall learning about abstract classes literally once in my CS307 class. I didn't really understand why it was necessary, other than to explicitly lay out what methods need to be implemented for a class that extends the abstract class. But now it makes much more sense, and I see how useful they could be in a project that contains similar classes but with slightly different implementations.
This is all I have for now. Until next time,
Corey
Another week has gone by! It's incredible to realize that the semester is getting closer to the end. Just a few weeks, and then we'll be in final exam week mode. And then after that, we (or at least some of us) will have graduated from the University of Texas. It's a crazy thought to think about; to realize that it's already been four years since the first time I stepped onto campus as a freshman. It's a scary thought to think about because for now, I don't have anything planned. I have been looking for job postings, but I feel like I don't really qualify for some of them. It makes for a very worrisome experience, but I hope I can find something soon!
This week in class, we discussed about SQL and refactoring. SQL has always been a fun subject for me, and I feel like with some practice that I've had with database development on a website I've been working on, I understood the topics quite well. Relational database management, I've realized, is a highly important topic and is integral in attempting to minimize the amount of duplicated data in the database. I've noticed this in my website, and I've actually decided to change the database schema up completely so I can reduce all of the bloat in my tables. I probably won't get into this until later in May, since I have this project and a million of other things to work on. But it is definitely something I want to fix, and it's something I'm excited to work on! I've never understood joins very well, but they make complete sense with the use of primary and foreign keys.
Refactoring has been an interesting subject to talk about. I think it's one of those things that we just do subconsciously after we're done writing the code that produces the results we want. I do it all the time; I sometimes don't like where a method or a chunk of code is placed, and so I might create a subclass or a new method out of it to make it more organized. The cached variable versus calling methods multiple times argument is an interesting one, and I guess it makes sense that calling a method multiple times doesn't really affect the program's performance so long as it isn't so intensive. And while it is true that a local cached variable could get invalidated in between, it sometimes seems like it wouldn't be so likely. Although I guess the argument begins to matter more significantly with bigger projects with hundreds of source code files. The use of abstract classes was also an interesting one. I recall learning about abstract classes literally once in my CS307 class. I didn't really understand why it was necessary, other than to explicitly lay out what methods need to be implemented for a class that extends the abstract class. But now it makes much more sense, and I see how useful they could be in a project that contains similar classes but with slightly different implementations.
This is all I have for now. Until next time,
Corey
Thursday, April 12, 2012
What I've been working on...
So, this was initially supposed to be a blog about tech news and things I have been working on, but that kind of turned into my weekly blog for a class of mine. That, and I got so caught up in school work that I have been unable to create sophisticated posts. I'm terribly sorry! I am going to try and write more often because it's fun and it might be helpful for others. Promise.
Anyway, while my busy semester has given me almost no room to breath in my normal life, I've actually spent some time for myself on developing applications for iOS (prominently iPhone). I haven't made much, but I've been working on two applications that I think some people would use in the (hopefully) near future. Of these two apps, one of them has been a big project for me, and that's the Texas Drums app.
Creating an application isn't as easy as it sounds, and without the proper tools, it can be an arduous and very cumbersome task. I've been having to work both on the front-end of the application (UI, data fetching/parsing, synchronization) as well as the back-end (database integrity, API construction). It's taken many hours to construct a resilient API that will send proper data (formatted in either JSON or XML) based on the URL parameters, and then to parse this data in a way that the iPhone API can understand. I've gotten most of it constructed, but much of it needs to be tested. That's one thing I've been trying to improve whenever I code: unit and acceptance testing. These ideas are so integral to programming. It's a good sanity check on whether your functions or methods return valid results for any kind of query, or if they throw exceptions out the wazoo.
Anyway, I feel like it would be cool to show some pictures of what I've been developing so that people can get a taste of what to expect when the application gets published into the App Store. Without further ado...
Here's a shot of the News screen. As you can notice, the organization is fairly similar to that of our website. Items highlighted in orange are member-only posts, a feature that will be utilized more when the app comes out. When you click on a news post, you'll be directed to the full post. Fairly simple.
In order to obtain this information, a call to the database must occur. Since iOS doesn't have any built-in connection library to SQL, I had to create an API so that a URL call will command a SQL query. Essentially, I created a PHP file that, when called with certain GET arguments, will formulate a SQL query, send the query to the database, and return the data. This data is converted into an array of arrays, and is then converted into a serialized JSON string. This is an interchangeable piece of data that can be converted back and forth in order to manipulate data properly. The PHP file returns this string, and the iOS library retrieves the response. With the help of a JSON library for iOS, I take the result and de-serialize it, which turns it into an NSDictionary of NSDictionaries. Then, it's just a matter of iterating through the dictionaries, storing the data into an appropriate container (NSArray or NSMutableArray), sorting appropriately (i.e. using the timestamp within each post), and then sending the proper data to the UITableView (title of the post, summary of the post). This concept is enumerated several times throughout the app, actually. It's all about calling the API, generating a result, parsing the result, saving the result, and sending the result on screen. This concept is also illustrated below, in the Roster page.
Similar to how we grabbed data for the News page, we do it here with the Roster page. Like our website, you can choose which year to browse. Upon clicking a year, you'll be directed to a list of members who were on the drumline within that year. You can then click on their name and view their nickname, quote, classification at the time (freshman, sophomore, etc.), and much more! If you are a member of Texas Drums, you'll also have access to their contact information.
One more shot. This is a brief display of our information page (similar to our About page). You can click on the items within the table to view information about us, common questions, our section leaders, and so on. I want to eventually incorporate a way for prospective members to be able to contact section leaders via email directly within the app. I feel like that would be a very convenient thing to incorporate. I get emails frequently about who to contact for camp information. Even though the emails are listed on the website, I feel like these aren't as obvious to find. Within the app, they will be easy to spot: by clicking on a section leader's bio, one will be able to email them directly.
Well, this is it for now; I can't spoil everything unfortunately. The media page isn't up and running right now, and I don't know if that will ship within the first version of this app. There's a lot of database maintenance that needs to be done with that section (prominently pictures; they are scattered everywhere). But I'll constantly be updating my blog for new improvements and updates, as well as how I've done the things I have done within this app.
Thanks for reading, and until next time,
Corey
Anyway, while my busy semester has given me almost no room to breath in my normal life, I've actually spent some time for myself on developing applications for iOS (prominently iPhone). I haven't made much, but I've been working on two applications that I think some people would use in the (hopefully) near future. Of these two apps, one of them has been a big project for me, and that's the Texas Drums app.
Creating an application isn't as easy as it sounds, and without the proper tools, it can be an arduous and very cumbersome task. I've been having to work both on the front-end of the application (UI, data fetching/parsing, synchronization) as well as the back-end (database integrity, API construction). It's taken many hours to construct a resilient API that will send proper data (formatted in either JSON or XML) based on the URL parameters, and then to parse this data in a way that the iPhone API can understand. I've gotten most of it constructed, but much of it needs to be tested. That's one thing I've been trying to improve whenever I code: unit and acceptance testing. These ideas are so integral to programming. It's a good sanity check on whether your functions or methods return valid results for any kind of query, or if they throw exceptions out the wazoo.
Anyway, I feel like it would be cool to show some pictures of what I've been developing so that people can get a taste of what to expect when the application gets published into the App Store. Without further ado...
 |
| Click to enlarge. It's eye candy. :3 |
In order to obtain this information, a call to the database must occur. Since iOS doesn't have any built-in connection library to SQL, I had to create an API so that a URL call will command a SQL query. Essentially, I created a PHP file that, when called with certain GET arguments, will formulate a SQL query, send the query to the database, and return the data. This data is converted into an array of arrays, and is then converted into a serialized JSON string. This is an interchangeable piece of data that can be converted back and forth in order to manipulate data properly. The PHP file returns this string, and the iOS library retrieves the response. With the help of a JSON library for iOS, I take the result and de-serialize it, which turns it into an NSDictionary of NSDictionaries. Then, it's just a matter of iterating through the dictionaries, storing the data into an appropriate container (NSArray or NSMutableArray), sorting appropriately (i.e. using the timestamp within each post), and then sending the proper data to the UITableView (title of the post, summary of the post). This concept is enumerated several times throughout the app, actually. It's all about calling the API, generating a result, parsing the result, saving the result, and sending the result on screen. This concept is also illustrated below, in the Roster page.
Similar to how we grabbed data for the News page, we do it here with the Roster page. Like our website, you can choose which year to browse. Upon clicking a year, you'll be directed to a list of members who were on the drumline within that year. You can then click on their name and view their nickname, quote, classification at the time (freshman, sophomore, etc.), and much more! If you are a member of Texas Drums, you'll also have access to their contact information.
One more shot. This is a brief display of our information page (similar to our About page). You can click on the items within the table to view information about us, common questions, our section leaders, and so on. I want to eventually incorporate a way for prospective members to be able to contact section leaders via email directly within the app. I feel like that would be a very convenient thing to incorporate. I get emails frequently about who to contact for camp information. Even though the emails are listed on the website, I feel like these aren't as obvious to find. Within the app, they will be easy to spot: by clicking on a section leader's bio, one will be able to email them directly.
Well, this is it for now; I can't spoil everything unfortunately. The media page isn't up and running right now, and I don't know if that will ship within the first version of this app. There's a lot of database maintenance that needs to be done with that section (prominently pictures; they are scattered everywhere). But I'll constantly be updating my blog for new improvements and updates, as well as how I've done the things I have done within this app.
Thanks for reading, and until next time,
Corey
Saturday, April 7, 2012
4/2 - 4/6 CS373 Blog Post
Good evening everyone.
This past week was fairly busy with the World Crises part two project. A lot of work was put into our project from all of our members, and the results turned out really well! The website interface has been improved thanks to Matt; the design looks a lot more sophisticated. With Garrett's help on the changes to the import script, and Andy's help on export, we now have a fully functional importer and exporter that takes in XML data that conforms to the newest, standard schema. Fahad kept us sane with unit and acceptances tests for the Google App Engine and our scripts, and Wes did an outstanding job with the initial paper, along with the GAE and UML design charts. As for me? I worked alongside Matt working with the Django templates and primarily with pulling data out of the Google App Engine. Our team is working really well. As a matter of fact, we actually got our project finished up by Monday. Everyone has their primarily responsibility, but we still understand each other's responsibilities. It's really amazing, and it's wonderful to know that everyone in the group is willing to commit themselves to do their best on this project!
In class, we had talked in depth about classes, subclasses, and how instance and class methods work. To be honest, I had never really understood the use of keywords like public, private, static, et cetera. They never really emphasized those key terms in 307 or 315. But now it makes much more sense! In Java projects, I've been used to shamefully throwing 'public static' or any other key term on every function, without really understanding that these are in fact, class methods. This is such an incredibly grateful thing to have learned, and I'm glad that I now fully understand it. This actually was helpful on Friday. I wasn't in class that day because I had an interview with Evernote Corporations. An interview question they had asked me was to design a brand new framework in a language of my choice of two dimensional geometric shapes. My idea, in short, was to create a general class, Shape, that had subclasses such as Triangle, Square, Rhombus, et cetera. These different subclasses would inherit properties by the general Shape class, such as number of points, average length (assuming that all sides were equal in length), and so on. They had also asked me about making a function that determines the area of a given Shape, and to decide what key words would be included in the function declaration. I had decided that it should be an instance method because the area of a given Shape requires certain things that can only be conceived with instances. So, what I had learned this week actually helped in the short run; not just for interviews, but for my complete understanding.
Anyway, it seems like we are also learning a bit of SQL, something which I am pretty familiar with. Looks like we will be talking more about it next week. I can't wait!
Until next time,
Corey
This past week was fairly busy with the World Crises part two project. A lot of work was put into our project from all of our members, and the results turned out really well! The website interface has been improved thanks to Matt; the design looks a lot more sophisticated. With Garrett's help on the changes to the import script, and Andy's help on export, we now have a fully functional importer and exporter that takes in XML data that conforms to the newest, standard schema. Fahad kept us sane with unit and acceptances tests for the Google App Engine and our scripts, and Wes did an outstanding job with the initial paper, along with the GAE and UML design charts. As for me? I worked alongside Matt working with the Django templates and primarily with pulling data out of the Google App Engine. Our team is working really well. As a matter of fact, we actually got our project finished up by Monday. Everyone has their primarily responsibility, but we still understand each other's responsibilities. It's really amazing, and it's wonderful to know that everyone in the group is willing to commit themselves to do their best on this project!
In class, we had talked in depth about classes, subclasses, and how instance and class methods work. To be honest, I had never really understood the use of keywords like public, private, static, et cetera. They never really emphasized those key terms in 307 or 315. But now it makes much more sense! In Java projects, I've been used to shamefully throwing 'public static' or any other key term on every function, without really understanding that these are in fact, class methods. This is such an incredibly grateful thing to have learned, and I'm glad that I now fully understand it. This actually was helpful on Friday. I wasn't in class that day because I had an interview with Evernote Corporations. An interview question they had asked me was to design a brand new framework in a language of my choice of two dimensional geometric shapes. My idea, in short, was to create a general class, Shape, that had subclasses such as Triangle, Square, Rhombus, et cetera. These different subclasses would inherit properties by the general Shape class, such as number of points, average length (assuming that all sides were equal in length), and so on. They had also asked me about making a function that determines the area of a given Shape, and to decide what key words would be included in the function declaration. I had decided that it should be an instance method because the area of a given Shape requires certain things that can only be conceived with instances. So, what I had learned this week actually helped in the short run; not just for interviews, but for my complete understanding.
Anyway, it seems like we are also learning a bit of SQL, something which I am pretty familiar with. Looks like we will be talking more about it next week. I can't wait!
Until next time,
Corey
Sunday, April 1, 2012
3/26 - 3/30 CS373 Blog Post
Good evening all.
Sorry for this blog post being a little bit late. I've got quite a lot on my hands: some Korean homework, a Network Security and Privacy project due Thursday, this project due Wednesday, 4 films I need to watch for Sociology alongside a 3 page (single-spaced) paper about said films due on Friday. Not my cup of tea; this will definitely be one of my more stressful weeks in the semester.
Our team is currently pounding away at the WC project. I think we're on a pretty good page with all that we've done so far. We've managed to get dynamic pages working and our import and export functions seem to be spewing out correct data. All in all, our team is moving things in rapid pace and we are doing (in my opinion at least) a pretty good job! Each person kind of has their own strengths in the project, which is interesting and kind of cool. It's like each person has a certain subset of tools/code that they're familiar with using/developing and they're able to mesh their stuff with everyone else's stuff, and it just works. I've never really worked in a small developmental group as this, but it is pretty awesome to see how everyone can come together and put in their two cents and create something pretty darn awesome. I could only imagine how tedious this project would be if it was assigned per individual!
About class: we're getting into some pretty in-depth stuff. I haven't been very clear with the whole class in a class idea throughout college. I actually didn't know that static variables declared in an outer class have full visibility to sub classes. It makes sense, but I never really thought about that; I guess because none of the programs I've ever coded in class ever used sub-classes. It's interesting but also difficult to wrap my head around. I guess it's just something I need to mess with myself in order to fully understand it. Also, I'm not a huge fan of Python's unusual syntax for private variables. I mean, it makes sense and all; I just think that they could have come up with a better macro than just two underbars.
We're also getting into constructors and deconstructors. Honestly, I've never dealt with them in Java. Mainly in C++ when I was learning it. I think of them as creating properties and data for variables as they are being instantiated, and then properly removed when their deconstructor is called. I never really understood the deconstructor, mainly because I never implemented anything in them. I can only assume we will talk about something like that later on, though.
Well, this is it for now. I must get some rest! It'll be a busy day tomorrow.
Until next time,
Corey
Sorry for this blog post being a little bit late. I've got quite a lot on my hands: some Korean homework, a Network Security and Privacy project due Thursday, this project due Wednesday, 4 films I need to watch for Sociology alongside a 3 page (single-spaced) paper about said films due on Friday. Not my cup of tea; this will definitely be one of my more stressful weeks in the semester.
Our team is currently pounding away at the WC project. I think we're on a pretty good page with all that we've done so far. We've managed to get dynamic pages working and our import and export functions seem to be spewing out correct data. All in all, our team is moving things in rapid pace and we are doing (in my opinion at least) a pretty good job! Each person kind of has their own strengths in the project, which is interesting and kind of cool. It's like each person has a certain subset of tools/code that they're familiar with using/developing and they're able to mesh their stuff with everyone else's stuff, and it just works. I've never really worked in a small developmental group as this, but it is pretty awesome to see how everyone can come together and put in their two cents and create something pretty darn awesome. I could only imagine how tedious this project would be if it was assigned per individual!
About class: we're getting into some pretty in-depth stuff. I haven't been very clear with the whole class in a class idea throughout college. I actually didn't know that static variables declared in an outer class have full visibility to sub classes. It makes sense, but I never really thought about that; I guess because none of the programs I've ever coded in class ever used sub-classes. It's interesting but also difficult to wrap my head around. I guess it's just something I need to mess with myself in order to fully understand it. Also, I'm not a huge fan of Python's unusual syntax for private variables. I mean, it makes sense and all; I just think that they could have come up with a better macro than just two underbars.
We're also getting into constructors and deconstructors. Honestly, I've never dealt with them in Java. Mainly in C++ when I was learning it. I think of them as creating properties and data for variables as they are being instantiated, and then properly removed when their deconstructor is called. I never really understood the deconstructor, mainly because I never implemented anything in them. I can only assume we will talk about something like that later on, though.
Well, this is it for now. I must get some rest! It'll be a busy day tomorrow.
Until next time,
Corey
Saturday, March 24, 2012
3/19 - 3/23 CS373 Blog Post
Good evening all!
What a busy week it has been! Dealing with the project and then preparing for an exam shortly thereafter was not a very fun turn-around. But the week is over, and I guess that might as well be the only good to have come out of this week!
This past week, my team and I worked our butts off on project 4: World Crises, Phase 1. This website is a collection of crises, people, and organizations that all will eventually be aggregated through the use of a Google App Engine (GAE). For this phase of the project, all we had to do was to collect data on our items and display them in static pages. While we were working on this, we were also supposed to get the back-end side to be able to import XML files given an XML schema, and to be able to export data stuffed into the datastore into an XML format. The static pages and collecting data weren't very difficult; our importer and exporter took some time to develop, though. We learned that such scripts are very nit-picky and like to take things in at a certain order. When we successfully figured out what order we wanted things in, we had to make our exporter export the material in the same pattern. It was more of a nuisance than anything, but we have things working! Things are linked in the datastore to prevent duplicates via a many-to-many relationship. This basically means that certain items may share a certain attribute one or more times. It eliminates redundant information that is duplicated, because no one wants that, you know? Anyway, the project seems to be not too bad, and our team is pretty awesome right now. I have pretty positive vibes with everyone and we gel pretty well! It's gonna be really promising when we complete this project.
As far as the test was concerned, it was a bit difficult for me. I thought I knew the material fairly well, but there was some questions I wasn't prepared for. As Downing had mentioned in class about being prepared for the programming questions, I hadn't really prepared for them, so I suffered from that aspect of the exam. I also didn't do as well as I had hoped on the multiple choice aspect. My Z score for the exam is still positive, but I felt like I could have done a lot better job. But, things like that happen and sometimes you don't always do the best all the time. So for the next exam, I'll try to compensate for my low grade!
I'm really wondering what's in store for the next part of the project. My thoughts are that we are going to make one Python page that regulates what will be displayed depending on what the user wants to view. We'll also probably incorporate the linking between the GAE datastore and the website to allow for other pieces of data to be displayed on the website.
Well that's it for now, I need to catch up on sleep.
Until next time,
Corey
What a busy week it has been! Dealing with the project and then preparing for an exam shortly thereafter was not a very fun turn-around. But the week is over, and I guess that might as well be the only good to have come out of this week!
This past week, my team and I worked our butts off on project 4: World Crises, Phase 1. This website is a collection of crises, people, and organizations that all will eventually be aggregated through the use of a Google App Engine (GAE). For this phase of the project, all we had to do was to collect data on our items and display them in static pages. While we were working on this, we were also supposed to get the back-end side to be able to import XML files given an XML schema, and to be able to export data stuffed into the datastore into an XML format. The static pages and collecting data weren't very difficult; our importer and exporter took some time to develop, though. We learned that such scripts are very nit-picky and like to take things in at a certain order. When we successfully figured out what order we wanted things in, we had to make our exporter export the material in the same pattern. It was more of a nuisance than anything, but we have things working! Things are linked in the datastore to prevent duplicates via a many-to-many relationship. This basically means that certain items may share a certain attribute one or more times. It eliminates redundant information that is duplicated, because no one wants that, you know? Anyway, the project seems to be not too bad, and our team is pretty awesome right now. I have pretty positive vibes with everyone and we gel pretty well! It's gonna be really promising when we complete this project.
As far as the test was concerned, it was a bit difficult for me. I thought I knew the material fairly well, but there was some questions I wasn't prepared for. As Downing had mentioned in class about being prepared for the programming questions, I hadn't really prepared for them, so I suffered from that aspect of the exam. I also didn't do as well as I had hoped on the multiple choice aspect. My Z score for the exam is still positive, but I felt like I could have done a lot better job. But, things like that happen and sometimes you don't always do the best all the time. So for the next exam, I'll try to compensate for my low grade!
I'm really wondering what's in store for the next part of the project. My thoughts are that we are going to make one Python page that regulates what will be displayed depending on what the user wants to view. We'll also probably incorporate the linking between the GAE datastore and the website to allow for other pieces of data to be displayed on the website.
Well that's it for now, I need to catch up on sleep.
Until next time,
Corey
Tuesday, March 13, 2012
3/5 - 3/9 CS373 Blog Post
Good evening everybody.
At last, we are finally in Spring Break! Although it is great to not have to deal with school for a full week, it is kind of unfortunate that we have to work on a project. Let alone, we have to work on this project with 5 other people, hoping that all of our schedules will match up properly.
The project seems like it'll be an interesting project to work on, but one that will have to be worked on very slowly since we are in groups with more than 2 people. Since we all (or at least most of us) haven't had experience using the Google App Engine or ElementTree, we'll have to research and work on it together in order to be fluent with it. I've been taking a look at it myself for a little bit, and while it doesn't seem too bad, we definitely will have to do some decent collaboration in order to make any headway into the project. So far, it seems like all of us will be available within the second half of spring break; more notably the weekend following. We'll have a lot of cramming to do in order to get this project done by next Wednesday! On top of that, we have an exam next Friday. What seemed like a nice vacation now just seems like a lot of work being pushed off until next week!
In class last week, we discussed the topic of overloading functions and overloading generics. I had basic knowledge of how that was used, and it seems like most of us use it subconsciously when writing out functions. I tend to design functions to support a decent amount of data structures. Maybe not every single kind, because then that just means I may have to re-consider the complete structure of my program. In Java, it's really a pain because of how *gross* the syntax really looks. Compared to Python, it is rather disgusting, but I suppose necessary if we want functions to be supported by a variety of data types. I mean, comparing
private static <T extends Comparable<? super T>> T max2 (T x, T y)
to
def my_max (x, y)
is a definite difference. Since Python is typeless too, this helps in dealing with possible types that are to be passed in as parameters.
It'll be an interesting end to the break to see how things progress with the project. We'll see what happens! Hope everyone is enjoying their break.
Until next time,
Corey
At last, we are finally in Spring Break! Although it is great to not have to deal with school for a full week, it is kind of unfortunate that we have to work on a project. Let alone, we have to work on this project with 5 other people, hoping that all of our schedules will match up properly.
The project seems like it'll be an interesting project to work on, but one that will have to be worked on very slowly since we are in groups with more than 2 people. Since we all (or at least most of us) haven't had experience using the Google App Engine or ElementTree, we'll have to research and work on it together in order to be fluent with it. I've been taking a look at it myself for a little bit, and while it doesn't seem too bad, we definitely will have to do some decent collaboration in order to make any headway into the project. So far, it seems like all of us will be available within the second half of spring break; more notably the weekend following. We'll have a lot of cramming to do in order to get this project done by next Wednesday! On top of that, we have an exam next Friday. What seemed like a nice vacation now just seems like a lot of work being pushed off until next week!
In class last week, we discussed the topic of overloading functions and overloading generics. I had basic knowledge of how that was used, and it seems like most of us use it subconsciously when writing out functions. I tend to design functions to support a decent amount of data structures. Maybe not every single kind, because then that just means I may have to re-consider the complete structure of my program. In Java, it's really a pain because of how *gross* the syntax really looks. Compared to Python, it is rather disgusting, but I suppose necessary if we want functions to be supported by a variety of data types. I mean, comparing
private static <T extends Comparable<? super T>> T max2 (T x, T y)
to
def my_max (x, y)
is a definite difference. Since Python is typeless too, this helps in dealing with possible types that are to be passed in as parameters.
It'll be an interesting end to the break to see how things progress with the project. We'll see what happens! Hope everyone is enjoying their break.
Until next time,
Corey
Sunday, March 4, 2012
2/27 - 3/2 CS373 Blog Post
Good evening all,
One week away until Spring Break! Unfortunately it comes with a long and enduring road for me. I have a project and four midterms that are in my way until then!
This week was mainly about the Netflix project. I wrote quite an extensive wiki of it (viewed here) detailing all of my algorithms that I tried testing, along with the problem itself. The basic idea of the Netflix project was to achieve a root mean squared error (RMSE) below Netflix's score, which was around .9474. The root mean squared error calculated a margin of error between a prediction of ratings (that I would generate based on data) and the actual ratings that users gave movies. Sifting through roughly 1.5 GB of data, I compiled some useful caches to be used in my program. The two main caches contained an average rating for each movie, and an average rating for each user. With these two caches, I was able to predict a movie rating based on what was sent to me in the probe file (this file contained a list of movies whose ratings that needed to be predicted). This project was not very hard to implement; the hardest part was tweaking the program and looking at what gave a better RMSE. I had stuck with taking the average movie rating and average user rating and figuring out how to implement these two to come up with a semi-decent prediction. I ultimately decided to make another cache: one that had the calculations of all movie ratings combined and all user ratings combined. I had then calculated some offsets based from the average and multiplied a given weight to some of the numbers in order to find a decent rating. All of this is explained in heavy detail in the wiki, linked above!
We had also talked about some more interesting things about Python, notably how many types inherit a lot of the same ideas. Strings, tuples, and lists are all able to work on things identically when a string is passed in their constructor. It's a really interesting idea and one that makes sense. I like how everything in Python is very succinct for the most part. Although, now I often catch myself writing code in my other classes and I forget to add semi-colons, brackets, and the likes. Honestly, this class is making me look down at Java and look up at Python more and more, every day. And I don't mind that!
I'm very curious as to how this new project is going to unfold. I'm excited to see what all we need to do to make a nice looking website, and it'll be fun working with a big group. It makes me wonder how we'll use Google Code and Python to build an aggregation-based website.
Well, I have lots to do right now, but next week should be a much more extensive blog post.
Until then,
Corey
One week away until Spring Break! Unfortunately it comes with a long and enduring road for me. I have a project and four midterms that are in my way until then!
This week was mainly about the Netflix project. I wrote quite an extensive wiki of it (viewed here) detailing all of my algorithms that I tried testing, along with the problem itself. The basic idea of the Netflix project was to achieve a root mean squared error (RMSE) below Netflix's score, which was around .9474. The root mean squared error calculated a margin of error between a prediction of ratings (that I would generate based on data) and the actual ratings that users gave movies. Sifting through roughly 1.5 GB of data, I compiled some useful caches to be used in my program. The two main caches contained an average rating for each movie, and an average rating for each user. With these two caches, I was able to predict a movie rating based on what was sent to me in the probe file (this file contained a list of movies whose ratings that needed to be predicted). This project was not very hard to implement; the hardest part was tweaking the program and looking at what gave a better RMSE. I had stuck with taking the average movie rating and average user rating and figuring out how to implement these two to come up with a semi-decent prediction. I ultimately decided to make another cache: one that had the calculations of all movie ratings combined and all user ratings combined. I had then calculated some offsets based from the average and multiplied a given weight to some of the numbers in order to find a decent rating. All of this is explained in heavy detail in the wiki, linked above!
We had also talked about some more interesting things about Python, notably how many types inherit a lot of the same ideas. Strings, tuples, and lists are all able to work on things identically when a string is passed in their constructor. It's a really interesting idea and one that makes sense. I like how everything in Python is very succinct for the most part. Although, now I often catch myself writing code in my other classes and I forget to add semi-colons, brackets, and the likes. Honestly, this class is making me look down at Java and look up at Python more and more, every day. And I don't mind that!
I'm very curious as to how this new project is going to unfold. I'm excited to see what all we need to do to make a nice looking website, and it'll be fun working with a big group. It makes me wonder how we'll use Google Code and Python to build an aggregation-based website.
Well, I have lots to do right now, but next week should be a much more extensive blog post.
Until then,
Corey
Sunday, February 26, 2012
2/20 - 2/24 CS373 Blog Post
Good evening everyone,
Another week has passed, and we are getting closer and closer to a glorious Spring break! Anyone have any plans?
In class this week, we had a great presentation by some employees of Mutual Mobile, a mobile software developer company. They had discussed what they do, how they do it, and why they do it. As a curious mobile application developer, I've always found it interesting creating apps for mobile technology. As they had said in their presentation, mobile development is becoming a lot more prominent with the rise in mobile technology. The influx of smartphone holders has allowed for the birth of mobile development. It's truly an exciting area of development. Even when I'm busy with projects in multiple classes, I find myself wanting to develop for my iPhone because it's a lot of fun. I'm so used to developing things in the command line; it's nice seeing some GUI output! It was also very cool to see the technologies they use. I had never heard of Jenkins or Jira until they had talked about it; I need to take a look and see if I can incorporate these things into any of my personal projects.
We had also started discussion about the Netflix project, which is due this coming Wednesday. I had heard about the "Netflix question" about two years ago in my 336 class, but that was more so figuring out the logical aspect of the question; not so much figuring out an algorithm that could beat theirs. It's been an interesting problem at the least, and there are a lot of things to take into consideration when trying to produce a better RMSE (Root Mean Squared Error). For instance, the plethora of different caches one could try to implement given the movie data. We had discussed two in class: providing the average rating for a given movie, and providing the average rating for a given user. I'm currently in the process of creating these caches to test out in my program (the average rating for a given user does seem to take a while to create, given that we have 1.5GB of files to look at!). But other ones that can be implemented may be a bit tricky to create. For instance, finding users who have similar tastes in movies would take a while to look at, unless we developed another meta-cache that could tally up all the different movies one user has seen, and then compare from there. Another cache is creating an average rating for movies that were created in a certain decade. For instance, we would have movie averages from the 1950-1960s, 1960-1970s, etc. We could also go further and develop another cache that had movie averages based on the year a user reviewed it. So many options to discover; the only downside is actually parsing all of the 1.5GB of data into a useable cache. But, the rest is fairly easy.
This class has been a great experience; probably one of my favorite classes. I have learned so much simply through practice. It wasn't until this class that I became devoted to creating multiple unit tests to assert that my programs work correctly, and it's kind of a crazy thought. I've looked back at some older programs and projects that I've worked on, and it's absolutely insane that I didn't use unit testing on them! Unit testing in Java was emphasized a little in 337 (Theory in Programming Practice) but they never emphasized on what we were to test on. We would test methods for some corner cases, but not so much the fact that it produces valid output all the time, that we can throw/catch appropriately given the potential input we could face, and so on. It's a little ridiculous. Unit testing, I've learned, keeps me pretty sane about my programs!
This is all for now, I've got to get working on multiple projects. More on the Netflix project will come next week!
Until then,
Corey
Another week has passed, and we are getting closer and closer to a glorious Spring break! Anyone have any plans?
In class this week, we had a great presentation by some employees of Mutual Mobile, a mobile software developer company. They had discussed what they do, how they do it, and why they do it. As a curious mobile application developer, I've always found it interesting creating apps for mobile technology. As they had said in their presentation, mobile development is becoming a lot more prominent with the rise in mobile technology. The influx of smartphone holders has allowed for the birth of mobile development. It's truly an exciting area of development. Even when I'm busy with projects in multiple classes, I find myself wanting to develop for my iPhone because it's a lot of fun. I'm so used to developing things in the command line; it's nice seeing some GUI output! It was also very cool to see the technologies they use. I had never heard of Jenkins or Jira until they had talked about it; I need to take a look and see if I can incorporate these things into any of my personal projects.
We had also started discussion about the Netflix project, which is due this coming Wednesday. I had heard about the "Netflix question" about two years ago in my 336 class, but that was more so figuring out the logical aspect of the question; not so much figuring out an algorithm that could beat theirs. It's been an interesting problem at the least, and there are a lot of things to take into consideration when trying to produce a better RMSE (Root Mean Squared Error). For instance, the plethora of different caches one could try to implement given the movie data. We had discussed two in class: providing the average rating for a given movie, and providing the average rating for a given user. I'm currently in the process of creating these caches to test out in my program (the average rating for a given user does seem to take a while to create, given that we have 1.5GB of files to look at!). But other ones that can be implemented may be a bit tricky to create. For instance, finding users who have similar tastes in movies would take a while to look at, unless we developed another meta-cache that could tally up all the different movies one user has seen, and then compare from there. Another cache is creating an average rating for movies that were created in a certain decade. For instance, we would have movie averages from the 1950-1960s, 1960-1970s, etc. We could also go further and develop another cache that had movie averages based on the year a user reviewed it. So many options to discover; the only downside is actually parsing all of the 1.5GB of data into a useable cache. But, the rest is fairly easy.
This class has been a great experience; probably one of my favorite classes. I have learned so much simply through practice. It wasn't until this class that I became devoted to creating multiple unit tests to assert that my programs work correctly, and it's kind of a crazy thought. I've looked back at some older programs and projects that I've worked on, and it's absolutely insane that I didn't use unit testing on them! Unit testing in Java was emphasized a little in 337 (Theory in Programming Practice) but they never emphasized on what we were to test on. We would test methods for some corner cases, but not so much the fact that it produces valid output all the time, that we can throw/catch appropriately given the potential input we could face, and so on. It's a little ridiculous. Unit testing, I've learned, keeps me pretty sane about my programs!
This is all for now, I've got to get working on multiple projects. More on the Netflix project will come next week!
Until then,
Corey
Saturday, February 18, 2012
2/13-2/17 CS373 Blog Post
Good evening everyone!
It's been a busy week! The PFD project was due and we had our first exam in the course. A little stressful, but I think we all survived!
This week, the primary focus was on the Project File Dependencies project. The basic concept of this project was to take in an input (essentially a graph of nodes that contained a list of dependencies) and output a result where numbers would be placed in a way so that the number before it did not depend on it. This definitely was a project that could have used several different implementations to get the job done right. In collaboration with my partner, we ended up choosing the easy route by using a list that would, through iterations, sort itself (with as few calls to sort as possible). In our program, we started off by reading the input and we read the appropriate amount of lines based on the number we obtained from the first line. The first number designated how many vertices (or nodes, if you prefer that) are in our graph, while the second number represented how many dependency rules to follow. We initialized a list filled with empty lists, with the number of empty lists being dependent on the number of vertices that would be in the graph. We then iterated through the rest of the input to determine the rules. Each line contained the node number, followed by the number of dependencies it has and the dependency node numbers following that. The construction of our graph rules ended up appending such data into the graph's corresponding index of the rule's node. So, for instance, a rule that contained "5 3 1 2 3" would create a list [1, 2, 3] that would fit in graph[4].
Once we filled up our graph, we went down through the list and appended the indices whose dependency lists were empty. These indices would be appended into an intermediate container (in our case, a sorted list). Since we would go down our graph every time, the list would be sorted initially. For every index we found to be empty, we replaced the empty list with a -1 delimiter to signify that it has been "removed" from our graph. Then, for each node in our intermediate list, we would search through all non-empty dependency lists and remove that node from the dependency list to again signify that it has been removed. After one run, we add the node to a result list. We search again and find for any empty lists; if there are, we add them to the intermediate container and sort. Rinse, repeat, profit.
Through observation, I understand that we could've done a better job in optimizing our code. Every time we add new nodes to our intermediate list, we sort, which can take a while depending on how big the graph is, and how many nodes become free through one removal. I did learn through research though, that Python's sort() function is an adapted merge sort which runs a lot faster than a traditional merge sort algorithm. Regardless, had we had used a different kind of container like a linked list or a binary heap, we could have been more efficient with more optimal code. Maybe I'll experiment with that later.
In class, we discussed about iteration, parallel assignments, argument keywords, default arguments, unpacking iterable items, and creating tuple and dictionary containers in functions (phew, so many topics!). I guess it never really hit me, but it makes sense that within a for each loop that items are copied. It abides to the iterablility (not really a word, but bear with me) standard. Most of our conversation this week revolved around some interesting quirks with Python. Parallel assignment was interesting in the sense that one could pass in any iterable object of a given length (designated in the parameters of the function), and it would work. I guess that's one amazing but potentially dangerous thing about Python; you can pass in just about anything, but it has to make sense. A list, tuple, set, dictionary, xrange, can all be passed in the example slide with the same value. Pretty ridiculous. Passing in arguments as keywords was also a really cool thing to learn about; as Professor Downing had mentioned, this is incredibly useful for defining what your variables are exactly in method calls. Someone looking at fresh code could see a function call like this:
custom_hash(24, 189, data, "x381jfs")
and would probably have no idea what it meant, other than it uses some kind of data to create some hash. If instead, it could be re-written as such:
custom_hash(data_begin_index = 24, data_end_index = 189, list_of_data = data, salt = "x381jfs")
one could then decipher that this is a hash function that takes a list that's only interested in a range of the list, and then salts it. Of course, it is very fragile. It can be easily broken if one decided that the parameter names were either too ambigious, too long, unnecessary, etc. Still a useful thing to use. You can also put the assignments in different places and it would still spit out the right answer, so long as you provide the necessary arguments in the right place for those that aren't assigned explicitly. Furthermore, you can provide default values for arguments if they aren't passed. Again, pretty useful if a function call is used several times and a fixed value is used consistently.
We also discussed about unpacking items, as well as creating tuples and dictionaries straight from the parameter line. Unpacking items was kind of cool. You could pass in just about any iterable item (like the parallel scheme discussed about above) of a given length, based on the parameter, and it would unpack the data inside to whatever you desire. That is, it would strip the data from a container to be used for other purposes. This helps with removing the need to iterate through data and add it to some kind of container. Alongside of unpacking, we can do the opposite with creating tuples and dictionaries. Again, useful functions that eliminate those extra lines of codes because programmers can be awfully lazy sometimes.
Lastly, we had a test last Friday. It didn't turn out as bad as I had expected! As Professor Downing had said, he geared the test to make the cheat sheet virtually useless, but it did indeed help as a very helpful review over all the material we talked about thus far. I stumbled a bit on the Haskell problem (I didn't really look into it that much; I had bet that it would've been a multiple choice question!) but I had a rough idea of the syntax. Hopefully not many points will be deducted from that problem. All I know is that all of us are anticipating what the final scores will be!
Until next time,
Corey
It's been a busy week! The PFD project was due and we had our first exam in the course. A little stressful, but I think we all survived!
This week, the primary focus was on the Project File Dependencies project. The basic concept of this project was to take in an input (essentially a graph of nodes that contained a list of dependencies) and output a result where numbers would be placed in a way so that the number before it did not depend on it. This definitely was a project that could have used several different implementations to get the job done right. In collaboration with my partner, we ended up choosing the easy route by using a list that would, through iterations, sort itself (with as few calls to sort as possible). In our program, we started off by reading the input and we read the appropriate amount of lines based on the number we obtained from the first line. The first number designated how many vertices (or nodes, if you prefer that) are in our graph, while the second number represented how many dependency rules to follow. We initialized a list filled with empty lists, with the number of empty lists being dependent on the number of vertices that would be in the graph. We then iterated through the rest of the input to determine the rules. Each line contained the node number, followed by the number of dependencies it has and the dependency node numbers following that. The construction of our graph rules ended up appending such data into the graph's corresponding index of the rule's node. So, for instance, a rule that contained "5 3 1 2 3" would create a list [1, 2, 3] that would fit in graph[4].
Once we filled up our graph, we went down through the list and appended the indices whose dependency lists were empty. These indices would be appended into an intermediate container (in our case, a sorted list). Since we would go down our graph every time, the list would be sorted initially. For every index we found to be empty, we replaced the empty list with a -1 delimiter to signify that it has been "removed" from our graph. Then, for each node in our intermediate list, we would search through all non-empty dependency lists and remove that node from the dependency list to again signify that it has been removed. After one run, we add the node to a result list. We search again and find for any empty lists; if there are, we add them to the intermediate container and sort. Rinse, repeat, profit.
Through observation, I understand that we could've done a better job in optimizing our code. Every time we add new nodes to our intermediate list, we sort, which can take a while depending on how big the graph is, and how many nodes become free through one removal. I did learn through research though, that Python's sort() function is an adapted merge sort which runs a lot faster than a traditional merge sort algorithm. Regardless, had we had used a different kind of container like a linked list or a binary heap, we could have been more efficient with more optimal code. Maybe I'll experiment with that later.
In class, we discussed about iteration, parallel assignments, argument keywords, default arguments, unpacking iterable items, and creating tuple and dictionary containers in functions (phew, so many topics!). I guess it never really hit me, but it makes sense that within a for each loop that items are copied. It abides to the iterablility (not really a word, but bear with me) standard. Most of our conversation this week revolved around some interesting quirks with Python. Parallel assignment was interesting in the sense that one could pass in any iterable object of a given length (designated in the parameters of the function), and it would work. I guess that's one amazing but potentially dangerous thing about Python; you can pass in just about anything, but it has to make sense. A list, tuple, set, dictionary, xrange, can all be passed in the example slide with the same value. Pretty ridiculous. Passing in arguments as keywords was also a really cool thing to learn about; as Professor Downing had mentioned, this is incredibly useful for defining what your variables are exactly in method calls. Someone looking at fresh code could see a function call like this:
custom_hash(24, 189, data, "x381jfs")
and would probably have no idea what it meant, other than it uses some kind of data to create some hash. If instead, it could be re-written as such:
custom_hash(data_begin_index = 24, data_end_index = 189, list_of_data = data, salt = "x381jfs")
one could then decipher that this is a hash function that takes a list that's only interested in a range of the list, and then salts it. Of course, it is very fragile. It can be easily broken if one decided that the parameter names were either too ambigious, too long, unnecessary, etc. Still a useful thing to use. You can also put the assignments in different places and it would still spit out the right answer, so long as you provide the necessary arguments in the right place for those that aren't assigned explicitly. Furthermore, you can provide default values for arguments if they aren't passed. Again, pretty useful if a function call is used several times and a fixed value is used consistently.
We also discussed about unpacking items, as well as creating tuples and dictionaries straight from the parameter line. Unpacking items was kind of cool. You could pass in just about any iterable item (like the parallel scheme discussed about above) of a given length, based on the parameter, and it would unpack the data inside to whatever you desire. That is, it would strip the data from a container to be used for other purposes. This helps with removing the need to iterate through data and add it to some kind of container. Alongside of unpacking, we can do the opposite with creating tuples and dictionaries. Again, useful functions that eliminate those extra lines of codes because programmers can be awfully lazy sometimes.
Lastly, we had a test last Friday. It didn't turn out as bad as I had expected! As Professor Downing had said, he geared the test to make the cheat sheet virtually useless, but it did indeed help as a very helpful review over all the material we talked about thus far. I stumbled a bit on the Haskell problem (I didn't really look into it that much; I had bet that it would've been a multiple choice question!) but I had a rough idea of the syntax. Hopefully not many points will be deducted from that problem. All I know is that all of us are anticipating what the final scores will be!
Until next time,
Corey
Sunday, February 12, 2012
2/6 - 2/10 CS373 Weekly Blog
Good morning, everybody!
Another week has passed in the realm of college; amazing how time can fly so fast.
This week in software engineering, we discussed several topics: memory allocations on the stack versus the heap, variables and how they're allocated and/or cached; conditional statements, arguments and whether or not they're mutable or not; and different implementations of summing up a container of elements either using an index or an iterator (and whether or not a given container is indexable or iterable).
Discussion about stacks and heaps were a review for me, considering I hadn't really talked about them in a long time (maybe two, three years ago even!). I knew there was a certain limit to how many records a stack can hold, but I didn't know of a specific number. I can't really think of a time that a program would need that many layers of stack records to perform a specific operation (unless, of course, it is an incredibly expensive, basic arithmetic function) that would either use more than 1000 stack frames or would cause it to overflow. Maybe that could be just because I haven't experienced the real world with actual software people use that I'm clueless on this idea, but the idea baffles me. With the heap, I can understand. Many programs can use a 'heap' of memory (get it?) that may cause a lack of memory issue. Again, I guess it'll be something that will be more significant later on in the future. I know this problem is a significant issue when dealing with smaller devices, such as mobile phones (iPhone, Android, Windows Phone 7, etc). Since memory is not as available than those in modern-day computers, it must be used wisely. Memory allocation and release must happen when variables need to be garbage collected; otherwise, memory leaks occur, and this intensifies the lack of memory issue. This is critical!
I never knew that variables were cached, at least to a certain range. It's kind of peculiar what kind of ranges Java and Python have specified (Java: [-128, 127] and Python: [-6, 256]). I guess I can kind of understand Java's range in binary terms (127 is 01111111, -128 is 10000000 with two's complements method). I guess Python decided with that range based on how frequently that range of numbers gets used? Who knows. Since this class, I also didn't know (or at least didn't realize it) that arrays were mutable and were passed by reference. In the past, many professors would just say that all things in Java were passed by value (that is, their values were duplicated and sent to methods). But arrays clearly seem to be the exception here.
We also had a great review and discussion about indexability and iterability (those aren't words in real life; just in the computer science world). As a refresher, indexability refers to those containers where items can be indexed; that is, they can be found by using a certain subindex/get method that can be processed in constant time. There are containers that can do this, but in linear time; these aren't truly indexable because we are merely walking down the list to find our item. Iterability refers to those containers that can be walked through but (usually) don't have an index/don't care to have an index. Such examples can include Maps and and Sets. These containers only care about what that value is rather than where the value is. Other containers, such as arrays and ArrayLists, care about where the value is rather than what the value is. We note that certain containers (ArrayLists, Lists, LinkedLists, etc) can also be iterated upon, but certain containers are better off being indexable (ArrayLists, Lists) and others, iterable (LinkedLists, Maps, Sets).
The PFD project has been an interesting one in using Python. I still get into the habit of using brackets to denote functions or loops; it's weird how everything is strictly bound by whitespace. Also, I have to get into the habit of knowing that for loops do not exist in Python. It's sort of inconvenient, but messier code (perhaps more elegant code when refactoring what to do) can be used to accomplish the same sort of thing. More on the project will come next week!
Until then,
Corey
Another week has passed in the realm of college; amazing how time can fly so fast.
This week in software engineering, we discussed several topics: memory allocations on the stack versus the heap, variables and how they're allocated and/or cached; conditional statements, arguments and whether or not they're mutable or not; and different implementations of summing up a container of elements either using an index or an iterator (and whether or not a given container is indexable or iterable).
Discussion about stacks and heaps were a review for me, considering I hadn't really talked about them in a long time (maybe two, three years ago even!). I knew there was a certain limit to how many records a stack can hold, but I didn't know of a specific number. I can't really think of a time that a program would need that many layers of stack records to perform a specific operation (unless, of course, it is an incredibly expensive, basic arithmetic function) that would either use more than 1000 stack frames or would cause it to overflow. Maybe that could be just because I haven't experienced the real world with actual software people use that I'm clueless on this idea, but the idea baffles me. With the heap, I can understand. Many programs can use a 'heap' of memory (get it?) that may cause a lack of memory issue. Again, I guess it'll be something that will be more significant later on in the future. I know this problem is a significant issue when dealing with smaller devices, such as mobile phones (iPhone, Android, Windows Phone 7, etc). Since memory is not as available than those in modern-day computers, it must be used wisely. Memory allocation and release must happen when variables need to be garbage collected; otherwise, memory leaks occur, and this intensifies the lack of memory issue. This is critical!
I never knew that variables were cached, at least to a certain range. It's kind of peculiar what kind of ranges Java and Python have specified (Java: [-128, 127] and Python: [-6, 256]). I guess I can kind of understand Java's range in binary terms (127 is 01111111, -128 is 10000000 with two's complements method). I guess Python decided with that range based on how frequently that range of numbers gets used? Who knows. Since this class, I also didn't know (or at least didn't realize it) that arrays were mutable and were passed by reference. In the past, many professors would just say that all things in Java were passed by value (that is, their values were duplicated and sent to methods). But arrays clearly seem to be the exception here.
We also had a great review and discussion about indexability and iterability (those aren't words in real life; just in the computer science world). As a refresher, indexability refers to those containers where items can be indexed; that is, they can be found by using a certain subindex/get method that can be processed in constant time. There are containers that can do this, but in linear time; these aren't truly indexable because we are merely walking down the list to find our item. Iterability refers to those containers that can be walked through but (usually) don't have an index/don't care to have an index. Such examples can include Maps and and Sets. These containers only care about what that value is rather than where the value is. Other containers, such as arrays and ArrayLists, care about where the value is rather than what the value is. We note that certain containers (ArrayLists, Lists, LinkedLists, etc) can also be iterated upon, but certain containers are better off being indexable (ArrayLists, Lists) and others, iterable (LinkedLists, Maps, Sets).
The PFD project has been an interesting one in using Python. I still get into the habit of using brackets to denote functions or loops; it's weird how everything is strictly bound by whitespace. Also, I have to get into the habit of knowing that for loops do not exist in Python. It's sort of inconvenient, but messier code (perhaps more elegant code when refactoring what to do) can be used to accomplish the same sort of thing. More on the project will come next week!
Until then,
Corey
Sunday, February 5, 2012
1/30 - 2/3 CS373 Blog Post
Good afternoon, everybody!
Another week, another blog post. Like always, lectures have been rigorous but very interesting. It's seriously amazing how much you can learn just by looking at small snippets of code and dissecting every meaning of every part of the syntax. It's almost as if, when beginning to learn the art of programming, that you take some things for granted. That, or they were just never talked about in great detail in the introductory classes. It makes me want to re-evaluate everything that I've learned and assure myself that I am understanding every part of a given programming language.
It's been interesting taking a look at Haskell code. The format is so different from other languages I've encountered! It is always cool to look at new programming languages and to see how they are similar and different. In the end though, they all have the ability to perform the most common tasks, and that in itself is pretty cool.
The Collatz project was actually a lot of fun to program. I had an enjoyable time attempting to optimize it as much as I can in order to get the speed of the program down to a minimum. It was good that I had finished the program early so I could tweak it as much as possible. I also wrote down an awfully lengthy wiki on it unintentionally. I just wanted to keep my information as detailed as possible so that someday (in the future) if I ever looked back at it, I could understand all that I did over again. Although, a mishap did occur when submitting the project. It seems like when I zipped up all of my files, I forgot to do a recursive zip, so my HTML files didn't get submitted! For starting early and finishing early, it was definitely a crucial hit to my grade (already 20 points off). I'm the only one to be blamed, though: I had checked all of my files after submitting, but I had assumed that the files existed within my subdirectories in the zip file when checking. Lesson learned: check everything for my own sanity.
Next week's project seems really interesting. Determining dependencies and listing them out seems like it'll be a pretty thoughtful project. I'll need to brush up on my knowledge of priority queues and binary heaps; it seems like that will be the data structure that will be used to solve this problem. Honestly, I can't recall ever learning about priority queues and binary heaps in CS315 (CS314 now, I suppose), but I have used priority queues in the past. Anyone else learn about those data structures elsewhere?
Until next time,
Corey
Another week, another blog post. Like always, lectures have been rigorous but very interesting. It's seriously amazing how much you can learn just by looking at small snippets of code and dissecting every meaning of every part of the syntax. It's almost as if, when beginning to learn the art of programming, that you take some things for granted. That, or they were just never talked about in great detail in the introductory classes. It makes me want to re-evaluate everything that I've learned and assure myself that I am understanding every part of a given programming language.
It's been interesting taking a look at Haskell code. The format is so different from other languages I've encountered! It is always cool to look at new programming languages and to see how they are similar and different. In the end though, they all have the ability to perform the most common tasks, and that in itself is pretty cool.
The Collatz project was actually a lot of fun to program. I had an enjoyable time attempting to optimize it as much as I can in order to get the speed of the program down to a minimum. It was good that I had finished the program early so I could tweak it as much as possible. I also wrote down an awfully lengthy wiki on it unintentionally. I just wanted to keep my information as detailed as possible so that someday (in the future) if I ever looked back at it, I could understand all that I did over again. Although, a mishap did occur when submitting the project. It seems like when I zipped up all of my files, I forgot to do a recursive zip, so my HTML files didn't get submitted! For starting early and finishing early, it was definitely a crucial hit to my grade (already 20 points off). I'm the only one to be blamed, though: I had checked all of my files after submitting, but I had assumed that the files existed within my subdirectories in the zip file when checking. Lesson learned: check everything for my own sanity.
Next week's project seems really interesting. Determining dependencies and listing them out seems like it'll be a pretty thoughtful project. I'll need to brush up on my knowledge of priority queues and binary heaps; it seems like that will be the data structure that will be used to solve this problem. Honestly, I can't recall ever learning about priority queues and binary heaps in CS315 (CS314 now, I suppose), but I have used priority queues in the past. Anyone else learn about those data structures elsewhere?
Until next time,
Corey
Sunday, January 29, 2012
1/23 - 1/27 Software Engineering Introductory Blog Post!
Good afternoon, everybody!
This will be the home of my weekly blog posts for my software engineering class, CS373. So far, this class has been pretty challenging. Professor Downing definitely keeps everybody awake and on their toes with his style of lecture, which I really like. Although many people are put on the spot for questions daily, it definitely reasserts the knowledge that I've learned in college thus far. I'm not very good at answering questions (regardless of how easy the question may be, I tend to overanalyze/become hesitant/nervous/etc) but I think this will help me be a better Q/A kind of person later in the future when I start my career.
I've really enjoyed what we've learned in class so far. Learning about the different forms of caches has been pretty interesting. You can make a lazy cache, which fills up values only when they're computed; or you can make an eager cache, which computes every value possible and then fills up an array with those values. Or, you could do a meta cache, which is an already-computed list of values that you can just stuff into your program. I've found that to be very interesting, and it is definitely one of those things that you need to test out in order to figure out which kind of cache is optimal for the program you're designing.
The seemingly-trivial questions about Java syntax has actually surprised me; it isn't really as easy as I thought it would be! From realizing that an obvious conditional statement of comparing two different objects would not compiles, to rejuvenating my lost knowledge on public/private/protected methods and public/final classes, it certainly has been a learning experience. I've also come to realize that Python's syntax, while very unusual to me still, is so much nicer than Java. Java requires packages, extraneous classes to do input/output, and lengthy syntax to do seemingly easy things. Python just seems so...nice! The classless thing has always been kind of weird to me, but I've been used to that with good ol' PHP.
Anyway, it's been a pretty interesting ride so far; let's see where we go to next in this class!
See y'all tomorrow,
Corey
This will be the home of my weekly blog posts for my software engineering class, CS373. So far, this class has been pretty challenging. Professor Downing definitely keeps everybody awake and on their toes with his style of lecture, which I really like. Although many people are put on the spot for questions daily, it definitely reasserts the knowledge that I've learned in college thus far. I'm not very good at answering questions (regardless of how easy the question may be, I tend to overanalyze/become hesitant/nervous/etc) but I think this will help me be a better Q/A kind of person later in the future when I start my career.
I've really enjoyed what we've learned in class so far. Learning about the different forms of caches has been pretty interesting. You can make a lazy cache, which fills up values only when they're computed; or you can make an eager cache, which computes every value possible and then fills up an array with those values. Or, you could do a meta cache, which is an already-computed list of values that you can just stuff into your program. I've found that to be very interesting, and it is definitely one of those things that you need to test out in order to figure out which kind of cache is optimal for the program you're designing.
The seemingly-trivial questions about Java syntax has actually surprised me; it isn't really as easy as I thought it would be! From realizing that an obvious conditional statement of comparing two different objects would not compiles, to rejuvenating my lost knowledge on public/private/protected methods and public/final classes, it certainly has been a learning experience. I've also come to realize that Python's syntax, while very unusual to me still, is so much nicer than Java. Java requires packages, extraneous classes to do input/output, and lengthy syntax to do seemingly easy things. Python just seems so...nice! The classless thing has always been kind of weird to me, but I've been used to that with good ol' PHP.
Anyway, it's been a pretty interesting ride so far; let's see where we go to next in this class!
See y'all tomorrow,
Corey
Subscribe to:
Posts (Atom)