For my Capstone project I designed a piece of software called Ribbon. Ribbon is a word processor designed specifically for screenplays since screenplays have a very specific format in which they are supposed to be written. The format includes unusual capitalization and indentation to convey character dialog, actions, new scenes, and other components of film.
The process of designing and making Ribbon consisted of a lot more planning than I had anticipated. During Capstone Week, I spent a lot of time doing research on different ways of organizing the code I was writing. This was very helpful because it made the code I was writing much easier to understand and follow but it also made it more difficult to write code because I was forced to follow a rigid structure.
I learned a lot about programming and my personal capabilities. First, I learned that there are so many resources available for free and on the Internet to allow you to do things with computers that I did not think I was able to do so easily. Second, I learned that a huge amount of software development is spent on thinking about the way the code should be structured rather than writing the actual code. This makes it much easier for other developers to come along later and contribute to your work.
The source code for the application as well as the application itself can be downloaded here.
Buschmann, Frank, Kevlin Henney, and Douglas C. Schmidt. On Patterns and Pattern Languages. Chichester: Wiley, 2007. Wikibooks. Web. 2 Feb. 2016. Rather than focusing on the components of a piece of software, On patterns and pattern languages emphasizes the relationship between different components. These are called patterns and thinking of my software in terms of the patterns I'm using rather than the components I'm creating has become very helpful in the writing of my code. The more thought I put in to the patterns I use, the easier it becomes for others to understand what the code does and to contribute to the project. Writing using patterns introduces other problems. It’s easy for me to write code that is messy but does the job effectively. To write code following strict patterns is difficult. This source has also made me realize that I need to plan out what code I’m going to write a lot more before I get to writing it.
Demaree, David. "The Art of the Commit." The Art of the Commit · An A List Apart Article. A List Apart & David Demaree, 02 Feb. 2016. Web. 02 Feb. 2016. This article is an excerpt from David Demaree's Git For Humans. My open-source project is being hosted online by a website called Github. Each time I save my project to Github, I must save it with a short message describing what I've changed. This article describes the best way to construct those message so others (and myself) can understand how my project has changed overtime. This is particularly important for making my project open-source. If I want other people to contribute to my project, they need to be able to understand what is going on. If people want to look at an older version of my project, it will be easy for them to find which version they are looking for because every time I save the project to Github, there will be a short message associated with it.
Fedosejev, Artemij. React. js Essentials. Packt Publishing Ltd, 2015. I am using a software framework called React.js. This book is a great book to reference if I do not know how to do something in React. Using React in my application will help me make Ribbon organized and will ensure that I use effective and easy-to-understand programming patterns. React introduces a lot of new conventions and concepts to my code-writing. Therefore, a reference book about React is necessary so I can refer to it at points in the code-writing process where I’m lost. React.js Essentials comes with great examples of how to use React effectively that are easy to understand. Given the important role that React plays in my project, having a React reference book is an absolute necessity.
Fogel, Karl. Producing Open Source Software: How to Run a Successful Free Software Project. Sebastopol, CA: O'Reilly, 2005. Producing Open Source Software. Karl Fogel, 2005. Web. 2 Feb. 2016. Karl Fogel writes about how to create an open-source project that gains attention and support. He does not deal with the technical, programmatic side of development as much as he deals with how to publicize your project effectively and make sure that once people are aware of your project they continue to pay attention to your project. While I’m developing my app I must be mindful of how what I’m doing may affect how other people see my project. If I’m not careful about the changes I make to my project and how I share those changes publicly on the project page (http://github.com/blockaj/ribbon) it could alienate people who may otherwise contribute to my project.
"Gulp API Docs." GitHub. Gulp, 17 Dec. 2015. Web. 04 Feb. 2016. Gulp is a task manager. While I am developing my application, it’s important that I can easily compile the code I’m writing. It is Gulp’s job to manage all of that. The Gulp API Docs are documentation about how to use Gulp. Without this, the workflow of my project would be very slow and inefficient. Using Gulp will relieve me of a lot of tedious work. Knowing how to use it is obviously essential in being able to use it. This documentation is a very good instruction on how to use Gulp so that my workload is a little less.
Hahn, Jungpil, Jae Yun Moon, and Chen Zhang. "Emergence of new project teams from open source software developer networks: Impact of prior collaboration ties." Information Systems Research 19.3 (2008): 369-391. This source talks about why people join open-source projects. One of the most compelling reasons is that the contributors have strong ties to the initiator (in this case, me). This is important to keep in mind. The people who may contribute the most to my project may already be around me. In addition, this source is useful because I can use to market my open-source project to developers. At this point in my project, I’ve worked the least on trying to attract others to contribute to my project. If I want to start focusing on this more, I should learn more about why people contribute to open-source projects.
Kubrick, Stanley, and Anthony Burgess. A Clockwork Orange: A Screenplay. Hollywood Scripts, 1970. While having a description of the format of a screenplay is helpful, it’s also very helpful to see a full and polished screenplay. As I progress through the process of developing my application, I will compare the screenplays I write in Ribbon to this screenplay. If, by comparison, everything looks good, I know I’m okay to move on. I can also use the screenplay to see how character and story development works in a real screenplay. Similar to the McKee source, A Clockwork Orange: A Screenplay could give me good insights on some features that would be helpful for experienced and skilled screenwriters to have in a word processor.
McKee, Robert. Substance, Structure, Style, and the Principles of Screenwriting. New York: HarperCollins, 1997. This book describes the process of writing a screenplay. It goes over how to develop a story and characters. The reason I find it helpful is that it gives me an idea of what things are important to a screenwriter. This could clue me in onto some good ideas for features I may include in my software. It also has some good information about how screenplays should be styled which are also very helpful. If I want my software to format screenplays effectively, there should be a reputable source behind the way I chose to format the screenplay.
Mockus, Audris, Roy T. Fielding, and James D. Herbsleb. "Two case studies of open source software development: Apache and Mozilla." ACM Transactions on Software Engineering and Methodology (TOSEM) 11.3 (2002): 309-346. This case study looks at two of the biggest existing open-source projects: Mozilla and Apache. One of the things this source addresses that other sources in this bibliography do not discuss is an open-source project’s ability to compete with commercial products. This source is useful to me because it describes what makes open-source software so successful. It explains what Mozilla and Apache do right as open-source projects and what they do wrong. There’s is a lot I can learn from this source about how to make my project a successful open-source project and not just a successful piece of software.
Rising, Linda, and Norman S. Janoff. "The Scrum software development process for small teams." IEEE software 17.4 (2000): 26. This is a simple explanation of the Scrum software development process. It incorporates using patterns to develop software with a workflow. I can use this source to learn how to work more efficiently on my project while still writing good code. This source also relates to the Buschmann source which is all about using patterns in programming. Scrum software development may also be useful if others want to contribute to my open-source project. If they decide to, using a development process could help make sure that not only my code is good and organized but theirs is as well. Trust me, this is a good source.