Project Timeline

This blog article serves as the initial reference timeline for my project. Initially I was going to attempt to post something visual, like a PNG or PDF of a graphical timeline, but I have been unable to find a way to do so that I feel is suitable to be read on a blog. I am exploring ProjectLibre to become the general tool for managing our project, but it didn't seem feasible to upload anything from that program into this blog (Although maybe it is and I just didn't see it!).

---

Timeline

The timeline is focused around central Milestones. This being the case, before I go into the dates on the calendar I want to outline what those Milestones will be (Subject to change of course.)
For the time being, I am only listing must have milestones. If we are ahead of schedule, there will be several additional milestones we target as well. These I will define at a later date.

Milestones

• Milestone 1
  • After discussing with team, decide on concrete technologies (web server type, programming language, target platforms) for project.
• Milestone 2
  • Have initial documentation for Social Network Protocol complete.
  • Have initial documentation for Social Network Aggregator Application Complete.
  • Decide on better names for both of the above.
• Milestone 3
  • Finish prototype implementation of Social Network Protocol.
  • Provide test suites for prototype implementation.
  • Provide deliverable quality Social Network Protocol documentation.
  • Provide working draft quality Social Network Aggregator Application documentation.
• Milestone 4
  • Complete core libraries for reading from Social Network Protocol in the Social Network Aggregator Application.
  • Complete at least one handler for at least one social network.
  • Provide test suites for core libraries and social network handlers
  • Provide complete Social Network Aggregator Application documentation.
• Milestone 5
  • Complete core GUI for prototype implementation.
  • Provide test suites for GUI codebase.
  • Provide alpha 0.1 release of application.
• Milestone 6
  • Provide alpha 1.0 release of the application.
  • Provide addition test suites for all codebases.
  • Have website up to market the application/protocol.

Dates

Note, events listed as Completed on a given week, must be completed by the end of said week. Events listed without a Completed identifier, should be worked on during that week. Events that are not completed in a given week still require visible progress on the event to be shown to the client during the meets. This is to say that all weeks must be moving towards delivery (There are no weeks off!)

• Week 1
  • Milestone 1 - Completed
  • Meeting with client. - Completed
    • Inform the client of the specific technologies that we will be using and motivate their use. That is to say, we can't say we are writing this program in Lisp, just because Lisp macros are off the hook.
• Week 2
  • Milestone 2 - Completed
  • Meeting with client. - Completed
    • Present documentation for both the application and the protocol.
    • Get feedback on functionality that might be added/removed/made optional etc.
• Week 3
  • Meeting with client. - Completed
    • Show client updates to documentation.
    • Demo any prototypes that we currently have (Optional this week)
  • Milestone 3
• Week 4
  • Meeting with client. - Completed
    • Show client updates to documentation.
    • Demo prototype to client (Does not have to be complete, but must show something.)
  • Milestone 3
• Week 5
  • Meeting with client. - Completed
    • Show deliverable quality documentation for Social Network Protocol.
    • Show updates to Social Network Aggregator documentation.
    • Demo final prototype Social Network Protocol implementation.
    • Show that demo passes test cases.
  • Milestone 3 - Completed
• Week 6
  • Meeting with client. - Completed
    • Show updates to Social Network Aggregator Documentation.
    • Inform client of the first social network we will target for handler.
  • Milestone 4
• Week 7
  • Meeting with client. - Completed
    • Show updates to Social Network Aggregator Documentation (Should be pretty much done at this point.)
    • Show visible progress on core library implementation. Passing test cases, pulling data, etc.
    • Show visible progress on social network handler. Passing test cases, pulling data, etc.
  • Milestone 4
• Week 8
  • Meeting with client. - Completed
    • Demo core libraries and social network handlers.
    • Provide complete documentation set.
    • Show code passes our test cases.
    • Show GUI design ideas to client and get feedback.
  • Milestone 4 -- Completed
• Week 9
  • Meeting with client. - Completed
    • Discuss marketing with client. (Website, etc.)
    • Show GUI prototypes to client.
  • Milestone 5
• Week 10
  • Meeting with client. - Completed
    • Show more GUI progress to client.
  • Milestone 5
• Week 11
  • Meeting with client. - Completed
    • Show final 0.1 alpha version to client.
    • Discuss final marketing information.
  • Milestone 5 - Completed
• Week 12
  • Meeting with client - Completed
    • Show final 1.0 alpha version to client.
  • Milestone 6 - Completed

Terms

1. Social network handler
   A piece of code that exposes a given social network through the Social Network Protocol.


2. Version numbers x.y
   Changes in x reflect major releases. Changes in y reflect bug fix releases. Version numbering starts at 0.1

Concept Paragrah

    In the past ten years social media has become one of the most dominant tools for interaction and self expression. Attempting to capitalize on this trend, many different forms of social media have emerged. Some have replaced older incarnations that have now passed their prim, such as Facebook and MySpace. Others coexists together, serving similar but distinct services, such as Twitter and Instagram. Keeping track of all of these different information sources can be a daunting task, especially if one wishes to continue to have a life outside of social media in the real world.

    Several programs have attempted to aid users in aggregating and viewing their various social media feeds. These include such tools as Flipboard, HootSuite, HTC Blink Feed, among others. While these tools are generally well done, they do generally miss the mark. This is evidence by the fact that people still most often use the Facebook and Twitter app rather than the Flipboard app. The general problem with these apps is that they strive too hard to be "cool" rather than be useful. For instance, the Flipboard app displays the various feeds in an artistic tile layout. This type of layout can be good for some types of user interfaces, but is not what is generally desired for reading social media.

    What is needed is a simple, clean, friendly, application which aggregates data from arbitrary social media type sources. Something that will feel familiar and easy to use, no matter what set of social media applications a user wishes to integrate. This application needs to be above all useful and intuitive in data presentation, and secondarily it needs to offer seamless ability to interface with the various features of given social networks, such as image upload or adding a friend to your contacts.

    To accomplish this goal, I propose two discrete steps. The first is the establishment of a general purpose protocol to describe social media interactions. This will be similar in concept to classical RSS, but more flexible and rich so as to allow more diverse types of information to be retrieved and more complicated interactions between client and server, such as uploading an image. With the establishment of this protocol, we will implement an front-end that will create a one stop shop for social media interaction.

    Further, this protocol could be extended to implement new meta-features operating inside existing social media applications. These meta-features will provide additionally functionality through the existing social networks. For example, crawling social media for the purposes of web archiving is currently a non-trivial task. Social media environments often rely heavily on dynamic technologies, such as JavaScript and AJAX, which are difficult to handle while crawling. This protocol could provide an easily crawl-able interface for social media, allowing trivial web archiving of social media. Another example might be the implementation of a crypto layer inside the social network. Our application could post gpg encrypted messages to an arbitrary social network, which could then be read by select users of our application who also have access to the lower level social network.

    Users of this application will no longer need to have N amount of applications in order to be connected to their friends, they will only need our application. Further we will not try to awe them with a fancy interface alone (Although our interface should be attractive.) but rather provide them with powerful meta features that they will not be able to use inside the lower level social network itself.

    The protocol we develop will be open sourced and reference implementations given to the community. The application we create will be offered for free, with either a donation option, or a payed version with additional features. Our motivation for this method of support comes from the notion that people are unwilling to purchase a new application like this without trying it first to see how useful it is.

    It is my belief that both the protocol and application built on it will be very useful to a variety of consumers. Wouldn't you like to have a free and feature rich way to interact with your social networks that also aids the open source community?

Practical Style

In regard to my last post about the importance of a consistent code style in a VCS environment, I wanted to post a concrete example.

Consider the following code,

#include <stdio.h>
#include <stdlib.h>

int
printMessage(char* message);

int
getName(char* message);

void
checkExit(int code);

int
getName(char* message)
{
  char* name = malloc(sizeof(char)*10);
  int i = 0;
  int err = 0;
  char c = 0;
  while((c = getchar()) != '\n')
    {
      name[i] = c;
      ++i;
    }
  err = printf("%s %s\n", message, name);
  free(name);
  return err;
}

int
printMessage(char* message)
{
  return printf("%s\n", message);
}

void
checkExit(int code)
{
  if(code < 0)
    exit(code);
  else
    return;
}

int
main(int argc, char* argv[])
{
  int err = printMessage("What is your name?");
  checkExit(err);
  err = getName("Hello,");
  checkExit(err);
  return 0;
}

This is a simple little C program that will read in your name and print it back at you. It does have one issue (at least, I wrote it rather quickly). In the function getName function there is no check to make sure you aren't reading over the end of the buffer (In C you must worry about such primitive things!). Now, let's say another programmer with a different sense of style comes in to fix this later, but he also changes the code to match his personal style preferences, no camel-case, function return types on the same line as the function name, different feelings about braces, etc. Below are his changes.

#include <stdio.h>
#include <stdlib.h>

int printmessage(char* message);

int getname(char* message);

void checkexit(int code);

int getname(char* message) {
  char* name = malloc(sizeof(char)*10);
  int i = 0;
  int err = 0;
  char c = 0;
  for(; i < 10 && (c = getchar()) != '\n'; i++)
    {
      name[i] = c;
    }
  err = printf("%s %s\n", message, name);
  free(name);
  return err;
}

int printmessage(char* message) {
  return printf("%s\n", message);
}

void checkexit(int code) {
  if(code < 0)
    exit(code);
  else
    return;
}

int main(int argc, char* argv[]) {
  int err = printmessage("What is your name?");
  checkexit(err);
  err = getname("Hello,");
  checkexit(err);
  return 0;
}

Now semantically are identical, except for fixing that buffer length check in getname (formally "getName"), but look at the diff that is produced from them.

4c4,5
< int printmessage(char* message);
---
> int
> printMessage(char* message);
6c7,8
< int getname(char* message);
---
> int
> getName(char* message);
8c10,11
< void checkexit(int code);
---
> void
> checkExit(int code);
10c13,15
< int getname(char* message) {
---
> int
> getName(char* message)
> {
15c20
<   for(; i < 10 && (c = getchar()) != '\n'; i++)
---
>   while((c = getchar()) != '\n')
17a23
>       ++i;
24c30,32
< int printmessage(char* message) {
---
> int
> printMessage(char* message)
> {
28c36,38
< void checkexit(int code) {
---
> void
> checkExit(int code)
> {
35,39c45,51
< int main(int argc, char* argv[]) {
<   int err = printmessage("What is your name?");
<   checkexit(err);
<   err = getname("Hello,");
<   checkexit(err);
---
> int
> main(int argc, char* argv[])
> {
>   int err = printMessage("What is your name?");
>   checkExit(err);
>   err = getName("Hello,");
>   checkExit(err);

Whoa! That is a large diff for such a small semantic change! Take a look at the diff that would have been produced if the style had not changed.

20c20
<   for(; i < 10 && (c = getchar()) != '\n'; i++)
---
>   while((c = getchar()) != '\n')
22a23
>       ++i;

A diff like this is much more clear.

Hopefully this illustrates why choosing and sticking to a particular code style is important in a VCS environment.

Standard Style in a VCS environment

Recently I have been thinking a lot of the important of standards in regards to programming. I have long felt that people should make the function of their programs perform according to a standard, and that they should make extensive use of contractual programming through interface type mechanisms (which I also view as coding according to a standard). I have not often thought about how the code's style should conform to a particular standard.
A little clarification is in order. By "style" I do not mean c90 vs c99 or Java 6 vs Java 7, but something more like the following.

if(a == b){
    a++;
}
return true;

if(a == b)
     a++;
return true;

In most languages the two sets of statements above are semantically identical, so choosing to write one over the other is generally thought of as matter of preference. Now, I am well aware that there are people out there who lobby, perhaps with good reason, that one style may be superior to another. The hypothetical merits of either method is not what I wish to consider here, but rather the consistency of either one's use. What I really want to address is the consistent use of a particular style in a team environment and more specifically when using Version Control.
If one programmer on a team creates a file according to their own personally, and equally valid, style preferences, it will inevitably be edited by a different programmer with different preferences at some point in the future. Let's suppose that this future programmer, while adding some feature, also changes the file to match his or her preferred style. Then he commits his changes to upstream. This is bad.
Why is this bad? Because the diff for the changes to the file will not include only the new feature related changes of the second programmer, but the all of the semantically meaningless changes to the style of the code. This makes understanding what has actually happened between one commit and another very difficult to discern at a glance.
This may and hopefully does seem obvious to anyone reading this article, but it is not something I had considered until recently.

Reactions to Wikipedia article on Software Engineering

The article on Wikipedia about software engineering seem to speak to me of one thing in general. Although people are being taught "Software Engineering", being hired as "Software Engineers", and writing books on the subject, people are still not quite sure what "Software Engineering is. Particularly, people seem to be unclear on how to separate it from Computer Science. At first glance, it seems to be some formalization or the practical application of Computer Science, but if this is the case does this mean that Computer Science is not in and of itself practically applicable? Perhaps...

And in other ways it seemed as though the article described Software Engineering as a commercialization of purely academic Computer Science.

Much of the article focused on discussing aspects of Programming that related to reusable, correct, code, such as testing, design, following standards, etc. Maybe the practices thought in Software Engineering could be summed up as teaching Computer Scientists how to not be lazy programmers? It does seem that this concept may be at the heart of the field. After all, an truly overwhelming amount of data shows how much of a negative effect that lazy and sloppy programming, testing, and documentation can have on a project, and these are areas that often even the most brilliant Computer Scientists struggle with.