During our team meeting on Sunday, I was put in charge of getting part of the user's profile page working. This included getting the profile picture display/upload capabilities working as well as putting in placeholders for user statistics. Since Fernando was responsible for the "current challenges" display (which will be included on both the profile page and the challenges page), he and I decided to work together because neither of us has had any experience with Rails prior to this project. We ended up meeting yesterday (Wednesday) for about four hours and were able to get the Paperclip gem (used for image saving and uploading) working after about an hour and a half working on it.
I have found that diving into the Demigod Rails code is certainly a change from tutorials, especially when you are trying to working around other components that were not present in the tutorials (such as registration). These difficulties are what caused some of our issues with getting Paperclip to work. For instance, we had to figure out which "edit" view to modify for the user (there were two, each of which was accessed by different links). Eventually, we are going to have to decide which of these to use (or how to combine them) since there should only be one edit page. Anyway, we were able to modify the user show view page to show the profile picture once the user had uploaded it and we were able to modify the user edit view page to include an upload button for uploading a profile image.
I added an additional feature this morning, which included displaying a "blank" avatar icon (i.e. the typical generic silhouette seen in place of a profile picture when you haven't yet uploaded one) when the user had not yet uploaded an image. I also set up a condition in the show view code that check if the user does not have a profile image and, if true, will make the blank icon into a link to the edit page where the user can upload an image. Actually getting the blank icon itself to display was a bit of a challenge because I had forgotten (though I know remember Matt mentioning it in his crash course) that Rails looks for assets (i.e. photos, CSS, etc.) in the "assets" folder and that you do not need to give Rails the path name, just the image name (as long as your image is stored in "assets/images"). After 30 minutes of frustration, I did some googling and went over my notes from Matt's crash course and discovered by error. Problem solved!
Thursday, February 27, 2014
Second client meeting
We had our second client meeting yesterday (this time with Nikan) and I think it went fairly well except for the fact that we did not have a printed timeline for each member. We had written it out during our team meeting on Sunday, but weren't sure exactly how to "detail" all the future tasks for each member since the specifics get more vague in later weeks. Obviously, we have the details of the next 3 or 4 weeks mapped out fairly well and generally know what each of us will need to do in weeks 5-11, but the details about who does what were are not yet firmly in place for these later weeks. However, at our next team meeting, we are going to have to nail down these details as best we can so we can actually have a printed timeline for the next meeting. I feel that our first team meeting, which included storyboarding the app and creating the database diagram) was very helpful for giving us a good idea of where to go over the next 9-10 weeks. I had not really realized the importance of storyboarding until the meeting since it really helped us figure out not only how the app was going to come together but also where there were weaknesses that needed to be addressed (such as how challenges will be stored, etc.).
We also handed in our second version of our "great user story" at the client meeting and I think that this one was more in the "story-telling" format that we needed to use. We certainly tried to make it as detailed as possible, though there were some issues with this since Fernando and I were the main creators of the story and we did not get as much input from other members as I felt would be necessary in order to resolve some questions about wording and content. However, I feel that this story is more accessible to a first-time user and is more believable than our previous version.
We also handed in our second version of our "great user story" at the client meeting and I think that this one was more in the "story-telling" format that we needed to use. We certainly tried to make it as detailed as possible, though there were some issues with this since Fernando and I were the main creators of the story and we did not get as much input from other members as I felt would be necessary in order to resolve some questions about wording and content. However, I feel that this story is more accessible to a first-time user and is more believable than our previous version.
Sunday, February 23, 2014
First team meeting
This afternoon (and evening) we had our first official team meeting. Matt S. gave us a crash course in Ruby on Rails (mainly Fernando and I since Matt F. knows Ruby and Rails fairly well it seems). It was really good to see the connections between the various components (such as models, views, controllers, and routes) in the context of the basic application framework. Doing tutorials is helpful but it cannot really prepare you for actually starting an application from scratch. I took lots of notes while Matt was giving his mini-lecture and I learned a lot of shortcuts, conventions, and Rails commands that will make my life easier when I start working on a part of the project. However, I'm sure that when I actually sit down in front of the application and start working on my first part of the app, it's going to be interesting! Fernando and I have agreed to meet during the first few weeks so we can maybe do some pair programming since neither of us has ever worked in RoR before. We can help each other out as we're starting to work on our parts of the app.
During the meeting we also drew out the basic design of the database and created a simple storyboard that outlines the functionality and structure of each page in the app. This also allowed us to better fill out the database design and figure out our tasks for the next few weeks. Initially, Fernando and I will be in charge of creating the profile page for the users. Each of us will work on certain parts of this page, such as the profile picture, statistics, and current challenge. Overall, storyboarding the app was really helpful since it gave us all a better idea of what we needed to accomplish in order to finish this app by the end of the semester.
So, in the next few weeks, I'll really be diving into Rails. It is certainly a change from the programming languages that I do know. For instance, I was able to pick up the basics of C# (and even VB) since they are fairly similar to Java. However, Rails is on another level (not as crazy as Haskell or Scheme, but still....). As I've mentioned in previous posts, keeping track of all the folders, component connections, and naming conventions is tricky, though this should get easier as I start working through code. Hopefully, within the next week, I can report that I have been able to successfully implement some RoR "in the real world".
During the meeting we also drew out the basic design of the database and created a simple storyboard that outlines the functionality and structure of each page in the app. This also allowed us to better fill out the database design and figure out our tasks for the next few weeks. Initially, Fernando and I will be in charge of creating the profile page for the users. Each of us will work on certain parts of this page, such as the profile picture, statistics, and current challenge. Overall, storyboarding the app was really helpful since it gave us all a better idea of what we needed to accomplish in order to finish this app by the end of the semester.
So, in the next few weeks, I'll really be diving into Rails. It is certainly a change from the programming languages that I do know. For instance, I was able to pick up the basics of C# (and even VB) since they are fairly similar to Java. However, Rails is on another level (not as crazy as Haskell or Scheme, but still....). As I've mentioned in previous posts, keeping track of all the folders, component connections, and naming conventions is tricky, though this should get easier as I start working through code. Hopefully, within the next week, I can report that I have been able to successfully implement some RoR "in the real world".
Friday, February 21, 2014
RoR--more impressions
I've almost finished the Rails for Zombies tutorial and feel like I have a better grasp of how the parts of Ruby on Rails fit together. However, I'm still a little intimidated by the huge number of folders and files. So far, I understand the basics--models are used to access the database, views are for displaying content to the user, controllers are for taking data from the models and processing it so that it can be displayed in a view. Also, there are routes, which can recognize a URL and send them to the appropriate controller action. Though I understand how these (mostly) fit together, recognizing exactly what needs to be added to each model, view, or controller in order to get them all talking to each other is a little more complicated and something that I think will get easier with practice. I am hoping that having the group meeting over the weekend will be helpful in solidifying how all the pieces fit together.
As I mentioned in my previous post, the syntax of RoR is not really similar to other languages that I've used, so it's taken some getting used to. One thing that was tripping me up was the use of colons in the syntax. Sometimes I would see the colon before a word (such as ":id") and then I would see it after a word (such as "id:"). The tutorials were not very specific about these differences (other than stating that ":id" was a symbol, which I already knew) so I did some googling and discovered that having the colon before the word allows you to access the symbol while having it after indicated assignment. Example with a hash:
cars = {make: "Honda", model: "Civic", color: "Silver"} #creates the hash, assigning a value to each symbol.
cars[:make] #returns "Honda"
So it is little things like this that I have to pay attention to in order to fully understand what is going on in the code. I also found that RoR is very "convention oriented" (it follows convention over configuration in an attempt to reduce the number of decisions that have to be made by the developer). In other words, there are quite a lot of conventions about how parts are named and used, which makes it easy to connect everything together--if you can remember exactly what the convention specifies. In many ways, the idea of using convention over configuration makes sense because it simplifies and code and makes it easy to remember exactly what something is called. For instance, if you have a class in the model called "Post", then there will be a database table called "posts." Then you can reference this elsewhere in the code without having to rewrite things the way you would have to do if you named the table "blog posts", for instance. However, I wonder if this use of convention reduces the flexibility of the code. Personally, I haven't had an issue with a lack of flexibility, but I'll have a better sense of this once I have a little more experience.
As I mentioned in my previous post, the syntax of RoR is not really similar to other languages that I've used, so it's taken some getting used to. One thing that was tripping me up was the use of colons in the syntax. Sometimes I would see the colon before a word (such as ":id") and then I would see it after a word (such as "id:"). The tutorials were not very specific about these differences (other than stating that ":id" was a symbol, which I already knew) so I did some googling and discovered that having the colon before the word allows you to access the symbol while having it after indicated assignment. Example with a hash:
cars = {make: "Honda", model: "Civic", color: "Silver"} #creates the hash, assigning a value to each symbol.
cars[:make] #returns "Honda"
So it is little things like this that I have to pay attention to in order to fully understand what is going on in the code. I also found that RoR is very "convention oriented" (it follows convention over configuration in an attempt to reduce the number of decisions that have to be made by the developer). In other words, there are quite a lot of conventions about how parts are named and used, which makes it easy to connect everything together--if you can remember exactly what the convention specifies. In many ways, the idea of using convention over configuration makes sense because it simplifies and code and makes it easy to remember exactly what something is called. For instance, if you have a class in the model called "Post", then there will be a database table called "posts." Then you can reference this elsewhere in the code without having to rewrite things the way you would have to do if you named the table "blog posts", for instance. However, I wonder if this use of convention reduces the flexibility of the code. Personally, I haven't had an issue with a lack of flexibility, but I'll have a better sense of this once I have a little more experience.
Wednesday, February 19, 2014
Ruby on Rails--initial impressions
I discovered that Ruby on Rails (heretofore called "RoR") has a huge number of dependencies and actually making sure they are all installed is a real pain. The installation instructions vary by operating system, so you have to make sure you find one specific to your OS (in my case, Mac OS X). I made the mistake of installing Rails before installing RVM (Ruby Version Manager), which made it nearly impossible for me to check that all the dependencies were found. So, once I installed RVM, I then had to reinstall Rails. At this point, it still wouldn't work, so I did some googling and realized I needed to run "bundle install". Finally, success!
Pleased that I'd gotten the install to cooperate, I set about creating a new project and downloaded Aptana Studio 3 to use as my terminal/text editor for the RoR project. I had used Aptana for Javascript before and had found it fairly easy to work with so I figured I'd use it for this project as well.
In terms of learning RoR, I've been following a basic blog creation tutorial from the RoR API site and have gotten about half-way through it so far. I've also been doing the Rails for Zombies tutorials, which teach you the basics of Rails apps. I've found that RoR is quite a change from what I'm used to, which is mainly Java with some Javascript and HTML experience. I am finding the most difficult part is keeping track of where everything goes and how it is all connected (RoR projects have an insanely large number of folders). I find that I'll kind of have an idea of what I want to do, but then I'll get absolutely lost trying to implement it because I keep forgetting that I have to connect all these files in various folders (and on top of that, the syntax is fairly different from, say, Java, so I keep having to look it up). I'm hoping that I'll have a better feeling for this in a week or so since tutorials can only help you go so far. Eventually, you just have to start your own project and figure it out as you go.
Pleased that I'd gotten the install to cooperate, I set about creating a new project and downloaded Aptana Studio 3 to use as my terminal/text editor for the RoR project. I had used Aptana for Javascript before and had found it fairly easy to work with so I figured I'd use it for this project as well.
In terms of learning RoR, I've been following a basic blog creation tutorial from the RoR API site and have gotten about half-way through it so far. I've also been doing the Rails for Zombies tutorials, which teach you the basics of Rails apps. I've found that RoR is quite a change from what I'm used to, which is mainly Java with some Javascript and HTML experience. I am finding the most difficult part is keeping track of where everything goes and how it is all connected (RoR projects have an insanely large number of folders). I find that I'll kind of have an idea of what I want to do, but then I'll get absolutely lost trying to implement it because I keep forgetting that I have to connect all these files in various folders (and on top of that, the syntax is fairly different from, say, Java, so I keep having to look it up). I'm hoping that I'll have a better feeling for this in a week or so since tutorials can only help you go so far. Eventually, you just have to start your own project and figure it out as you go.
Sunday, February 16, 2014
Software bugs
According to a study by Cambridge University, software bugs cost the economy 312 billion (yes, with a "b") per year (see this link for the full article). The study also found that software developers spend up to 50% of their time finding and fixing bugs. This certainly emphasizes the importance of not just writing clean, well-commented code, but also being sure to perform thorough testing of the code. As a programmer, I find that sometimes the hardest part of debugging is reproducibility. Someone will run your program and find a bug, but then they can't remember exactly what they did to get the error. The article mentioned the concept of "reversible debugging", which essentially records everything that a program does so that when a bug is found, the developer can more easily find the cause. I would imagine that having a tool that implemented this concept would be incredibly helpful when it came to finding and fixing a bug. The article was not clear about whether this type of debugging is only used during development or whether it could be "attached" the deployment program as well. Obviously, having a tool that recorded everything the program does while an actual user is using it could be a big legal issue depending on exactly what the program itself does (i.e. you wouldn't want this debugger attached to a banking app). However, using a reversible debugger during alpha and beta testing could be extremely helpful since it would allow the developer to more easily find and fix bugs while the tool is in use.
Friday, February 14, 2014
Bjorklund algorithm
In doing research for another class, I came across an algorithm that I think might be worthy to discuss on this blog (even though it is more "computer science" than "software engineering"). It is called the Bjorklund algorithm and was discussed in a paper called "The Euclidean Algorithm Generates Traditional Musical Rhythms" by Godfried Toussaint (published in 2005). The link is here. Bjorklund's algorithm was developed by, you guessed it, a guy named Eric Bjorklund. Interestingly enough, he published papers on this algorithm while working at Los Alamos Laboratory (in 2003). He was tasked with the problem of maximizing evenness in the operation of components such as high voltage power supplies of spallation neutron source (SNS) accelerators used in nuclear physics. His solution was to use an algorithm that is based on the Euclidean algorithm for finding the greatest common divisor of two numbers. This allowed him to evenly distribute pulses over a given set of intervals for the purpose of setting the timing of the SNS accelerators.
Of course, it wasn't long before musicians and ethnomusicologists began to see the importance of Bjorklund's algorithm, and the Euclidean algorithm in general, when it came to generating rhythms in music. Euclidean rhythms can be found in nearly all world music, such as the rhythm where 3 pulses are distributed over 8 pauses, which can be represented as [x . . x . . x .], with "x" being a pulse and "." being a pause. According to Toussaint's paper, this 3,8 rhythm is very common--in "Cuba it goes by the name of the tresillo and in the USA is often called the Habanera rhythm used in hundreds of rockabilly songs during the 1950’s." The paper lists tens of other Euclidean rhythms used in music from the Middle East, Africa, Greece, and many other countries around the world.
Though I have never played a musical instrument, I do know a little about music and its mathematical properties so it is not a surprise to me that there would be a simple algorithm that can generate these rhythms. However, it is incredible to me that it can generate so many rhythms that are found all over the world. The Bjorklund algorithm itself has been coded in several languages, including Java and Python. The algorithm itself can be somewhat tricky to implement and, if you do it incorrectly, it can be difficult to find a corner case where it will produce incorrect output. However, once you download and/or code the algorithm, you can used it to "play" a MIDI synthesizer (such as in Java) to produce some very nice rhythms. I have also read about people incorporating the Bjorklund algorithm into Max For Live to produce some very nice songs based on these rhythms.
Of course, it wasn't long before musicians and ethnomusicologists began to see the importance of Bjorklund's algorithm, and the Euclidean algorithm in general, when it came to generating rhythms in music. Euclidean rhythms can be found in nearly all world music, such as the rhythm where 3 pulses are distributed over 8 pauses, which can be represented as [x . . x . . x .], with "x" being a pulse and "." being a pause. According to Toussaint's paper, this 3,8 rhythm is very common--in "Cuba it goes by the name of the tresillo and in the USA is often called the Habanera rhythm used in hundreds of rockabilly songs during the 1950’s." The paper lists tens of other Euclidean rhythms used in music from the Middle East, Africa, Greece, and many other countries around the world.
Though I have never played a musical instrument, I do know a little about music and its mathematical properties so it is not a surprise to me that there would be a simple algorithm that can generate these rhythms. However, it is incredible to me that it can generate so many rhythms that are found all over the world. The Bjorklund algorithm itself has been coded in several languages, including Java and Python. The algorithm itself can be somewhat tricky to implement and, if you do it incorrectly, it can be difficult to find a corner case where it will produce incorrect output. However, once you download and/or code the algorithm, you can used it to "play" a MIDI synthesizer (such as in Java) to produce some very nice rhythms. I have also read about people incorporating the Bjorklund algorithm into Max For Live to produce some very nice songs based on these rhythms.
Wednesday, February 12, 2014
Reflections on proposal writing
After redoing my project proposal several times, I feel that I have a better understanding of how to create a proposal as well as what to include. However, writing a proposal seems like something that you really need to do repeatedly in order to be good at. Having a basic outline or using the Volere template was helpful, even though the Volere template was so long and detailed that it was sometimes more of a hindrance than a help.
Creating the proposal really helped me focus on what I needed in my project and brought out issues that I had not previously thought about. It was not as difficult as I thought to reach the 15 page limit, but I think that was because I ended up repeating myself one too many times. This was something that was pointed out in my feedback and a problem which I hopefully fixed on my final proposal. I also was not always sure how much detail to include in the proposal, even after revising it several times. As was mentioned in class, you do not want to lock yourself into a tool, platform, or design too early, but, at the same time, you have to be able to know which tools would be best for creating your project. In my case, I found that Elgg provided a decent base functionality and, combined with AWS, could be a really powerful tool to use in creating my website. I was able to create a proof of concept by installing and running Elgg on AWS. I think it is important to identify one or more platforms/tools for creating a project in order to actually demonstrate to yourself that they are viable options.
I also found it surprisingly difficult to convey how my idea was different from traditional social media sites. It seems to be assumed that, if a project deals with social media or social networks, then it is identical to Facebook or Google+. I tried to emphasize the differences between my idea and these sites, but I do not think I was entirely successful. I guess this is something else that comes with practice--seeing the idea from a different perspective and being able to describe it so that your audience understands exactly what you are proposing. Overall, creating the proposal and the resulting pitch was quite a learning experience and I certainly have a lot more to learn before I become really proficient at writing and presenting my ideas.
Creating the proposal really helped me focus on what I needed in my project and brought out issues that I had not previously thought about. It was not as difficult as I thought to reach the 15 page limit, but I think that was because I ended up repeating myself one too many times. This was something that was pointed out in my feedback and a problem which I hopefully fixed on my final proposal. I also was not always sure how much detail to include in the proposal, even after revising it several times. As was mentioned in class, you do not want to lock yourself into a tool, platform, or design too early, but, at the same time, you have to be able to know which tools would be best for creating your project. In my case, I found that Elgg provided a decent base functionality and, combined with AWS, could be a really powerful tool to use in creating my website. I was able to create a proof of concept by installing and running Elgg on AWS. I think it is important to identify one or more platforms/tools for creating a project in order to actually demonstrate to yourself that they are viable options.
I also found it surprisingly difficult to convey how my idea was different from traditional social media sites. It seems to be assumed that, if a project deals with social media or social networks, then it is identical to Facebook or Google+. I tried to emphasize the differences between my idea and these sites, but I do not think I was entirely successful. I guess this is something else that comes with practice--seeing the idea from a different perspective and being able to describe it so that your audience understands exactly what you are proposing. Overall, creating the proposal and the resulting pitch was quite a learning experience and I certainly have a lot more to learn before I become really proficient at writing and presenting my ideas.
Tuesday, February 11, 2014
Finalized Project Proposal
The finalized PDF version of my project proposal can be found in the link below:
https://drive.google.com/file/d/0B4jV0EcSqqGGVTR1UWN1eUVsaXc/edit?usp=sharing
https://drive.google.com/file/d/0B4jV0EcSqqGGVTR1UWN1eUVsaXc/edit?usp=sharing
Saturday, February 8, 2014
Who is a software engineer?
We've discussed in class what it means to be a software engineer and the meaning of craftsmanship, but as was brought up in the last class, how do you know that someone is qualified to be a software engineer? Software engineering certainly does not have the same certifications and regulations that ME, EE, or CE fields have.
Typically, hiring companies require that you have a degree in CS or software engineering, but this is not always the case. At some companies (which shall go unnamed), having a master's degree or PhD holds more importance than having a degree in the field that you are working in. For instance, I know a person with a master's in ME who is working on developing complex code in VB and C# but they do not understand object-oriented programming or the basics of testing and debugging software. I know another person with a bachelor's in EE who wrote thousands of lines of analysis code in Java but did not understand how to properly use try-catch blocks, report exceptions, or utilize some more basic object-oriented design principles.
Yet, these people are considered "software engineers" even though, if they had to take a certification exam, they probably would not pass. So, I guess I can understand why having standards or, though I hate to say it, regulations, can be important in producing readable, commented, well-designed code. But, at the same time, I cringe at the thought of the miles of red-tape that will be produced once some sort of unified software engineering "certification" is standardized. Anytime a regulations, committees, and certifications enter a field, it becomes a headache for anyone wanting to make that their career path. However, when you look at some of the software glitches that have cost people a significant amount of money (or released prisoners early), it is understandable why people want the standardization and certification. And when I see people "coding" and "designing" software who do not know the first thing about basic testing, debugging, and design principles, well, let's just say, it is a cause of great frustration for me. And it probably will be for you too because you know that one day you'll end up having to use that software, or, even worse, add features to it.
Typically, hiring companies require that you have a degree in CS or software engineering, but this is not always the case. At some companies (which shall go unnamed), having a master's degree or PhD holds more importance than having a degree in the field that you are working in. For instance, I know a person with a master's in ME who is working on developing complex code in VB and C# but they do not understand object-oriented programming or the basics of testing and debugging software. I know another person with a bachelor's in EE who wrote thousands of lines of analysis code in Java but did not understand how to properly use try-catch blocks, report exceptions, or utilize some more basic object-oriented design principles.
Yet, these people are considered "software engineers" even though, if they had to take a certification exam, they probably would not pass. So, I guess I can understand why having standards or, though I hate to say it, regulations, can be important in producing readable, commented, well-designed code. But, at the same time, I cringe at the thought of the miles of red-tape that will be produced once some sort of unified software engineering "certification" is standardized. Anytime a regulations, committees, and certifications enter a field, it becomes a headache for anyone wanting to make that their career path. However, when you look at some of the software glitches that have cost people a significant amount of money (or released prisoners early), it is understandable why people want the standardization and certification. And when I see people "coding" and "designing" software who do not know the first thing about basic testing, debugging, and design principles, well, let's just say, it is a cause of great frustration for me. And it probably will be for you too because you know that one day you'll end up having to use that software, or, even worse, add features to it.
Friday, February 7, 2014
Software Design Patterns...there are a lot!
So, I knew that there were quite a few software design patterns, but I'd never really looked at any of them in great detail. The basic concept behind a software design pattern is that it provides a template that can be followed in order to solve a certain problem in a given situation. In essence, they are best practices that are implemented by the developer. Apparently there are software design patterns for everything from algorithms to structural design. As mentioned in class, these patterns are to developers what blueprints are to builders. They guide the developer in creating a program that will hopefully be better because it is based on a pattern that has been tested, used, and has been proven to improve the software structure and help prevent certain problems and issues from arising.
Obviously, a developer can't just choose any software design pattern since each is best suited for specific purposes (for instance, you probably wouldn't want to use a Monad design for an object-oriented project). Thus, it is up to the developer to choose the design that best fits their program and inappropriately choosing a design could harm the final project by introducing confusion and complications.
A problem with using a software design pattern also comes from the generalization of the design. The design cannot be too specific or else it will not work for majority of applications. Thus, the design has to contain some abstraction (or indirection as Wikipedia mentions) in order to remain flexible. This can introduce complications into the resulting software because of misunderstandings about how to implement the abstractions and can cause performance issues with the application.
I picked out a few of the patterns mentioned in the article to discuss here. The Interpreter pattern was especially interesting to me because I had to create an interpreter and parser for a calculator in a previous class. The Interpreter pattern basically provides a framework for interpreting a computer language (or something as simple as interpreting reverse polish notation). Each symbol in the language is given its own class (and it does not matter whether the symbol is terminal or not) and this class defines how to interpret that symbol. For instance, a Number class's interpreter function would return a number while a Plus class's interpreter would return the sum of it's left and right operands. I essentially used this method when I created my calculator, but I did not know that it was an actual design pattern. The pattern is helpful in that it provides a basic structure for creating the interpreter for a language, which can then be combined with a parser.
Another pattern that I looked at was the Decorator pattern. This is essentially a way of standardizing wrapper creation for a class. For instance, you have a class that has almost all the functionality you need except for one or two operations or components. In order to add this functionality, you create a decorator class which would extend the original class (or interface) and take the original class as an argument to the constructor. The additional functionality is added to this object once it is passed into the decorator class. As the example in the Wikipedia article shows, you could have a Window interface, subclass it into a WindowDecorator interface, which takes a Window as the constructor's parameter, and then further subclass the WindowDecorator to provide extra functionality such as scrollbars. This makes it extremely easy to add or remove features from a specific object without having to create ridiculous subclasses such as MyHorizonatalVerticalScrollBarBorderedWindow.
I also looked at the Wikipedia article "Software Design Patterns" in order to find a more complete list of such patterns. Browsing through them, I recognized some templates that are used in the coding languages that I use. For instance the "Hollywood Principle" is used in the Enterprise JavaBeans framework. The idea behind the Hollywood Principle is "Instead of your program running the system, the system runs your program." Basically this method allows the programmer to focus on creating the application without having to worry about all the system calls that happen behind the scenes. In essence, approaches that use this technique will provide a framework that the developer must follow and build on. This is helpful in that it allows the developer to focus on the specifics of the application being built, but it could also be restrictive or time-consuming if you have to create functionality that is not necessarily supported by the framework.
Obviously, a developer can't just choose any software design pattern since each is best suited for specific purposes (for instance, you probably wouldn't want to use a Monad design for an object-oriented project). Thus, it is up to the developer to choose the design that best fits their program and inappropriately choosing a design could harm the final project by introducing confusion and complications.
A problem with using a software design pattern also comes from the generalization of the design. The design cannot be too specific or else it will not work for majority of applications. Thus, the design has to contain some abstraction (or indirection as Wikipedia mentions) in order to remain flexible. This can introduce complications into the resulting software because of misunderstandings about how to implement the abstractions and can cause performance issues with the application.
I picked out a few of the patterns mentioned in the article to discuss here. The Interpreter pattern was especially interesting to me because I had to create an interpreter and parser for a calculator in a previous class. The Interpreter pattern basically provides a framework for interpreting a computer language (or something as simple as interpreting reverse polish notation). Each symbol in the language is given its own class (and it does not matter whether the symbol is terminal or not) and this class defines how to interpret that symbol. For instance, a Number class's interpreter function would return a number while a Plus class's interpreter would return the sum of it's left and right operands. I essentially used this method when I created my calculator, but I did not know that it was an actual design pattern. The pattern is helpful in that it provides a basic structure for creating the interpreter for a language, which can then be combined with a parser.
Another pattern that I looked at was the Decorator pattern. This is essentially a way of standardizing wrapper creation for a class. For instance, you have a class that has almost all the functionality you need except for one or two operations or components. In order to add this functionality, you create a decorator class which would extend the original class (or interface) and take the original class as an argument to the constructor. The additional functionality is added to this object once it is passed into the decorator class. As the example in the Wikipedia article shows, you could have a Window interface, subclass it into a WindowDecorator interface, which takes a Window as the constructor's parameter, and then further subclass the WindowDecorator to provide extra functionality such as scrollbars. This makes it extremely easy to add or remove features from a specific object without having to create ridiculous subclasses such as MyHorizonatalVerticalScrollBarBorderedWindow.
I also looked at the Wikipedia article "Software Design Patterns" in order to find a more complete list of such patterns. Browsing through them, I recognized some templates that are used in the coding languages that I use. For instance the "Hollywood Principle" is used in the Enterprise JavaBeans framework. The idea behind the Hollywood Principle is "Instead of your program running the system, the system runs your program." Basically this method allows the programmer to focus on creating the application without having to worry about all the system calls that happen behind the scenes. In essence, approaches that use this technique will provide a framework that the developer must follow and build on. This is helpful in that it allows the developer to focus on the specifics of the application being built, but it could also be restrictive or time-consuming if you have to create functionality that is not necessarily supported by the framework.
Thursday, February 6, 2014
Ideal team in 3 words
In 3 words: responsible, motivated, creative. I have worked on teams in both work and school situations and, honestly, I almost always dread it. Inevitably, the team suffers (and therefore the project suffers) because one or more team members do not want to work, habitually submit work late, fail to communicate with others, or expect others to fix problems with their code/report/spreadsheet/etc... Sometimes these issues are explainable because of interference from other commitments, work schedule, etc. However, in general, I see a trend where a few group members do most of the work. To me, those 3 words mean:
I think a team composed of members that can at least generally adhere to the above three descriptions will be able to accomplish their project goals and be able to improve on the original project concept.
Three other words that I would have included if I could: hardworking, detail-oriented, and honest. Having a team that is hardworking is important for getting all the tasks completed on time. This could also be interpreted as a willingness to work since, without that, very little would get done. I know "detail-oriented" is probably a completely over-used term, but I feel it is an important characteristic of any good programmer since you not only have to look at the "big picture" but you also have to pay attention to small things (tweaking code to make it better, performing thorough testings, etc.) that are also important to the overall success of the project. Finally, having a team that is honest is also a key attribute in my mind. By honesty, I mean being straightforward in communicating with others and being willing to report any problems. Any team that lacks honesty is going to suffer from issues that arise when members refuse to voice their thoughts or refuse to report a problem when they first see it. Any of these things could cause a setback in the project with regard to both time and money.
- Responsible: showing up on time, making sure their code is tested and well-documented, and willing to own up to their mistakes and learn from them.
- Motivated: taking the initiative, going above and beyond the minimum requirements.
- Creative: contributing ideas and suggestions that will help the project improve and finding solutions to problems.
I think a team composed of members that can at least generally adhere to the above three descriptions will be able to accomplish their project goals and be able to improve on the original project concept.
Three other words that I would have included if I could: hardworking, detail-oriented, and honest. Having a team that is hardworking is important for getting all the tasks completed on time. This could also be interpreted as a willingness to work since, without that, very little would get done. I know "detail-oriented" is probably a completely over-used term, but I feel it is an important characteristic of any good programmer since you not only have to look at the "big picture" but you also have to pay attention to small things (tweaking code to make it better, performing thorough testings, etc.) that are also important to the overall success of the project. Finally, having a team that is honest is also a key attribute in my mind. By honesty, I mean being straightforward in communicating with others and being willing to report any problems. Any team that lacks honesty is going to suffer from issues that arise when members refuse to voice their thoughts or refuse to report a problem when they first see it. Any of these things could cause a setback in the project with regard to both time and money.
Tuesday, February 4, 2014
Proposal Reviews
I reviewed the proposals from Kevin, Sonny, and Ben and the PDFs are accessible through the links below:
Ben:
https://drive.google.com/file/d/0B4jV0EcSqqGGNDdCWmZlUlB1MTg/edit?usp=sharing
Kevin:
https://drive.google.com/file/d/0B4jV0EcSqqGGQVV6SXBKZl9XUWc/edit?usp=sharing
Sonny:
https://drive.google.com/file/d/0B4jV0EcSqqGGTE9HUmMxcXg1VmM/edit?usp=sharing
Ben:
https://drive.google.com/file/d/0B4jV0EcSqqGGNDdCWmZlUlB1MTg/edit?usp=sharing
Kevin:
https://drive.google.com/file/d/0B4jV0EcSqqGGQVV6SXBKZl9XUWc/edit?usp=sharing
Sonny:
https://drive.google.com/file/d/0B4jV0EcSqqGGTE9HUmMxcXg1VmM/edit?usp=sharing
Monday, February 3, 2014
Software Craftsmanship
The first thought I had when I read the first two sentences of the Wikipedia article on Software Craftsmanship was "Agile!". And, sure enough, three sentences later, the article mentions the Agile Manifesto. Clearly, based on this article, developers have started to favor an approach to software that is more people-oriented and flexible (like Agile) and have even begun viewing software creation as a "craft", much like in a medieval guild.
To me, the term "craftsman" describes someone who creates things (anything from software to buildings) and takes pride in producing a product that is high quality. In this sense, I think any engineer, not just software engineers, are craftsmen. Engineers build or create things that help better the world (or at least a small piece of it) and any good engineer will take pride in producing a quality product. However, the Wiki article seems to imply that engineering (though not necessarily software engineering) is not a craft because it has a more mathematical and analytical (read, "stricter and more rigid") approach that requires licensing and certification.
I am somewhat torn about this view. On one hand, I can see how regulation and inflexibility can remove the person from the equation, thus removing the essence of "craftsmanship." On the other hand, just because there is licensing and regulation does not mean that engineering is not a craft. Medieval guilds were essentially a form of licensing--i.e. if you were a member, you had been trained in that guild's craft and were expected to follow certain rules. The article seems to imply that because software engineering does not have these restrictions, then it can be considered a craft while engineering in general cannot. I certainly think that the greater flexibility and few restrictions in software engineering mean that it is easier to pass on knowledge, but as far as skilled crafts go, software engineering is not the only engineering discipline that requires skill, practice, and some amount of pride to perform well in.
To me, the term "craftsman" describes someone who creates things (anything from software to buildings) and takes pride in producing a product that is high quality. In this sense, I think any engineer, not just software engineers, are craftsmen. Engineers build or create things that help better the world (or at least a small piece of it) and any good engineer will take pride in producing a quality product. However, the Wiki article seems to imply that engineering (though not necessarily software engineering) is not a craft because it has a more mathematical and analytical (read, "stricter and more rigid") approach that requires licensing and certification.
I am somewhat torn about this view. On one hand, I can see how regulation and inflexibility can remove the person from the equation, thus removing the essence of "craftsmanship." On the other hand, just because there is licensing and regulation does not mean that engineering is not a craft. Medieval guilds were essentially a form of licensing--i.e. if you were a member, you had been trained in that guild's craft and were expected to follow certain rules. The article seems to imply that because software engineering does not have these restrictions, then it can be considered a craft while engineering in general cannot. I certainly think that the greater flexibility and few restrictions in software engineering mean that it is easier to pass on knowledge, but as far as skilled crafts go, software engineering is not the only engineering discipline that requires skill, practice, and some amount of pride to perform well in.
Sunday, February 2, 2014
Reflections on creating a project proposal
Since I finished the first iteration of my project proposal, I thought that I'd talk a little bit about the process of creating it. This was essentially the first proposal that I'd ever done. It was certainly a different experience creating a proposal when I'm used to being the one that just gets told, "here's what we want, now go code it up." I found that even though I had an idea for my project, actually thinking about what would need to be done to create it was a little more difficult. It really forces to you contemplate the pros and cons of every approach and try to figure out which approach best suits your "vision" of how you want the project to take shape. I think the parts I struggled with the most were the specification requirements and the budget (though the timeline was a little tricky too since I was not quite sure how much detail to include). For me, the specification requirements were harder to write because I was not sure how "in-depth" I should get with the details of the system. Obviously, I don't want to lock myself down into doing something only one way, but I also want to provide enough detail so someone reading the proposal will have a general idea of how we plan to create the website and how all the parts will fit together. I also found the budget to be difficult since I have never had to price out a project. I've created budgets for personal use, but creating them for a project is an entirely different animal. I did some research on how people create project budgets and the advice that seemed to keep reoccurring was just to practice. Essentially, the first time you do a project budget, you're not going to know exactly what should be put in the budget or how much "padding" to include in order to offset problems and delays that arise. However, once you've done a few budgets, you start understanding what you need and the process becomes easier.
I feel that I've learned a lot from creating this proposal, though I know that I have a lot of room for improvement. Receiving feedback on it will be very helpful in order to show me what I've made mistakes on and how I can improve. Hopefully this means that the next iteration of the proposal will be a little more straightforward to create.
I feel that I've learned a lot from creating this proposal, though I know that I have a lot of room for improvement. Receiving feedback on it will be very helpful in order to show me what I've made mistakes on and how I can improve. Hopefully this means that the next iteration of the proposal will be a little more straightforward to create.
Link to Project Proposal PDF
Uploaded the PDF of my proposal to my Google Drive and the link for it is below:
https://drive.google.com/file/d/0B4jV0EcSqqGGdng2YWFpdnRGbGM/edit?usp=sharing
https://drive.google.com/file/d/0B4jV0EcSqqGGdng2YWFpdnRGbGM/edit?usp=sharing
Subscribe to:
Posts (Atom)