Good morning, y'all.
To those who follow this blog, I will no longer post any new material here. I've migrated my Blogger into a Wordpress, which you can find here.
Thanks!
Corey
Monday, February 3, 2014
Saturday, May 5, 2012
4/30 - 5/5 CS373 Blog Post
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
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
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
Subscribe to:
Posts (Atom)