After our class on Thursday I spent probably 4 hours or so trying to get Ubuntu on my computer, and I was finally successful! So far I really like it. It looks and feels a lot like OSX, but the fact that it's an Open Source Developed project makes it more exciting in a way. It's really cool to know that Open Source projects can really be successful, and I hope that our team this semester can really make a dent in an Activity for Sugar Labs.
So, we all met for about 4 hours on Saturday to see where we were all at as far as getting our development environment up and running. I started out just playing with the Sugar OS interface. You can install Sugar in Ubuntu by going to the Ubuntu Software Center, and typing in Sugar. After playing around with the OS to get a feel for it, I went ahead and started looking into setting up our development environment in Ubuntu.
First, I downloaded Eclipse. Eclipse has a Python plugin called Pydev, which will allow us to edit Python files. There's also a plugin for git called Egit, and another plugin for Subversion called Subclipse. I've installed all three of these to my version of Eclipse.
The next step was to get the code, and build it. This was probably the most difficult process yet. I think it's a bit more complicated process for us since we aren't just dealing with an application, but actually an Operating System. Building an OS and running just sounds a bit more difficult to me. SugarLabs has a few different guides about actually getting, building, and running the code. However, none of them seemed to be that clear. I looked at a few different guides on setting it up while we met on Saturday:
http://en.flossmanuals.net/ActivitiesGuideSugar/SetUpDevEnvironment
http://wiki.sugarlabs.org/go/Activity_Team/Getting_Involved
After a few hours of trying to figure out how to set up the development environment, we split up and went home for the day.
Linux seems to make the user work directly in Unix quite a bit more than I'm used to, but I'm starting to like it. You know you've spent a lot of time doing something when you start dreaming about it. After I went to bed last night, I was literally dreaming about typing Unix commands. After we left Saturday, I spent some time trying to figure out how to set this up some more. I found a guide on SugarLabs' website talking about jhbuild. Jhbuild let me download the source code directly (after installing the required dependencies). Once downloaded, I can start editing the python files. If I were ready to start testing out any changes I make, all I have to do is open Terminal and type the following commands:
./sugar-jhbuild build (This builds the project.)
./sugar-jhbuild run sugar-emulator (This runs the virtual Sugar OS and lets me test out any changes I make).
Just to be sure that this is in fact the best way for me to begin developing, I went onto the IRC chat for SugarLabs, and asked a couple of questions. They were very quick to respond, and very helpful. They told me to try using Sweets, which is similar to jhbuild. After downloading Sweets, it seems to be a very similar process. I can build/run the Sugar OS using the following commands:
sweets -ff make sweet (Builds the project)
sweets sugar:emulator (Launches the emulator)
I'm not entirely sure which is the better route to go, but I suppose time will tell. We've started looking at bugs. The bug we're most interested in has to do with setting up the user's profile name. If the user puts a space before or after their name, the space should be cut off, but currently it leaves the space in front of their name. This should be an easy bug for us to start with.
One more thing: I also was able to install the Subversion server using apache in Ubuntu following this very simple guide.
sudo apt-get install subversion libapache2-svn - installs subversion.
svnadmin create /svntest - created a subversion test directory at my root folder.
sudo htpasswd -c /etc/subversion/passwd jordan - creates my login/password.
once this was created, I can log in using the following command: svn co http://10.0.0.1/svn
It prompts me for my username/password combo, and lets me in. Assuming that I could give out my IP address to an external user, I think I'd be able to log into the server.
Sunday, January 30, 2011
Thursday, January 27, 2011
Day Five
Well, it's late. In the last two days I've spent about 9 hours at least trying to get Ubuntu installed on my Mac. First I find out that my Mac's disc drive is dead, so I've been trying to find a workaround. I really do not want to run Ubuntu in a virtual machine, I'd much prefer to partition my hard drive so that I can boot directly into Ubuntu. Turns out that my disk drive can't be partitioned just yet, Disk Utility keeps telling me that "some files can't be moved", so I'm either going to have to reformat (and reinstall OSX first), or if I'm lucky I'll be able to get away with just repairing the disk.
The reason I've been dedicating so much time to it is because I know I'm going to need it once we get going with SugarLabs, and I really want to set up a development environment that I'm comfortable with. Linux is the absolute best options when it comes to developing for the Sugar OS. I really would like to follow this guide in setting up my environment, but first I need to get Ubuntu running. Also, I'm kind of excited about it because I've never really used Linux before, and I want to know what it's like.
As far as Subversion goes, I just spent some time setting it up on the OSX side of my Mac. Things went well. I started out using a tutorial here that uses Terminal to connect to Subversion, but I wanted an easier way. I found a program called Versions that lets me use a GUI for subversion. The setup was simple: pointed it to the correct URL, my login, and password. Once in, I'm able to create folders and upload files as I please. I can check in and out files without any issues so far. I've used other version control systems (mostly Microsoft's TFS at work), so I would say I'm somewhat familiar with checking code in/out. The app that I'm running has some sort of trial I think, but I'm not too worried about it because I will eventually set up Subversion again once I'm in Linux.
TOS Chapter 4 goes through the basics of dealing with Subversion at the command line. I went ahead and tried connecting to subversion with Terminal, and I was able to check out the code pretty easily:
svn checkout https://cirdles.cs.cofc.edu/repos/462playground/
Once I start using Subversion in Linux, I may need to become more familiar with the commands rather than using a GUI, although I would prefer to try and make things as easy as possible. If I can, I would like to use a GUI-based Subversion client, like this.
Well, it's 2 AM, and I'm in the process of putting the OSX install disc onto a flash drive so that I can reformat my hard drive. It might be a long night.
The reason I've been dedicating so much time to it is because I know I'm going to need it once we get going with SugarLabs, and I really want to set up a development environment that I'm comfortable with. Linux is the absolute best options when it comes to developing for the Sugar OS. I really would like to follow this guide in setting up my environment, but first I need to get Ubuntu running. Also, I'm kind of excited about it because I've never really used Linux before, and I want to know what it's like.
As far as Subversion goes, I just spent some time setting it up on the OSX side of my Mac. Things went well. I started out using a tutorial here that uses Terminal to connect to Subversion, but I wanted an easier way. I found a program called Versions that lets me use a GUI for subversion. The setup was simple: pointed it to the correct URL, my login, and password. Once in, I'm able to create folders and upload files as I please. I can check in and out files without any issues so far. I've used other version control systems (mostly Microsoft's TFS at work), so I would say I'm somewhat familiar with checking code in/out. The app that I'm running has some sort of trial I think, but I'm not too worried about it because I will eventually set up Subversion again once I'm in Linux.
TOS Chapter 4 goes through the basics of dealing with Subversion at the command line. I went ahead and tried connecting to subversion with Terminal, and I was able to check out the code pretty easily:
svn checkout https://cirdles.cs.cofc.edu/repos/462playground/
Once I start using Subversion in Linux, I may need to become more familiar with the commands rather than using a GUI, although I would prefer to try and make things as easy as possible. If I can, I would like to use a GUI-based Subversion client, like this.
Well, it's 2 AM, and I'm in the process of putting the OSX install disc onto a flash drive so that I can reformat my hard drive. It might be a long night.
Sunday, January 23, 2011
Day Four
Today we had a class discussion about a few different topics. To start, each team went around and discussed our current progress about making a connection with the open source community. We told the class about our experience with SugarLabs. We were able connect to SugarLabs' IRC channel, and join their development mailing list. The development mailing list sends out roughly 20 emails a day which is somewhat overwhelming, but at least we know that the community is active. Their IRC is embedded directly into their website, and they have a ton of different channels (including a "newbie" channel -- which is where we started out). They also have a complete history of every conversation that's existed throughout their IRC chat rooms, which is very convenient.
The next topic was about our reflections on the Cathedral and the Bazaar. Everyone went around and made comments about interesting topics/ideas that were discussed in the readings.
Our team just finished meeting up tonight about our full report that we need to give on Tuesday. Meeting at Taco Boy was an excellent idea, much more exciting than the usual places (JC Long or the library). Good food makes the meeting much more relaxing and enjoyable, and feel less like work. Our report will be posted on the group's wiki by class time on Tuesday. Alex created a document collecting our ideas on the full report, while we all contributed things to add to the report.
For the majority of the time at the meeting, I focused on trying to get a head start on how our development environment will work, and what exactly we would like to do to contribute to the project. SugarLabs is a Linux-based operating system that runs on a USB stick that they like to call "Sugar on a Stick". Anyone can download it and begin using it whenever, however I'm still hung up on the best way to set up an efficient development environment. For example, if I were to change a few lines of code, I want to arrange the easiest way for me to test these changes on the Sugar OS. Since it runs on a USB stick, it sounds like it may be a more complicated process to get to since we can't develop directly in this OS. This would require developing in OSX (or Windows, Linux, etc.), and then possibly compiling/restarting the machine in the new environment to test out the changes... not exactly my ideal environment.
I found their source code and downloaded it onto my machine. Turns out they use a version control system called GIT. Since we'll be using Subversion for our class, looks like we'll have to keep track of both. We'll only really need to worry about GIT to get the latest version of the projects, and to publish any changes we make (probably towards the end of the semester). For the most part, we'll probably be dealing with Subversion.
Details about how we'll develop aside, the best way to get started will be to work on a bug. It'll help us get a feel for the code and to the development process. Further down the road, the team would like to focus on creating/modifying what SugarLabs calls "Activities" - the learning-based games that the users play within the Sugar OS.
Wednesday, January 19, 2011
Day Three
On the third day, we got to deliver to the class our top three candidates for our Open Source project choice this semester. I started off by speaking about our third choice: Open Office for Kids. We decided not to go with Open Office for Kids, because it seemed that it would be difficult to communicate with the community (considering that most of the developers were French). SugarLabs was our number one choice by far (and it turns our we're not the only group), and I'm very excited about jumping into the development process.
For the next half of class, we spent some time looking into more detail about SugarLabs. We managed to join the IRC chat just to get a feel for how that works. We also found out about a weekly meeting for SugarLabs on Thursday nights, so tomorrow night we will all be joining the IRC chat to see what's going on. We also found the mailing list on their website for developers, so we went ahead and signed up for that as well.
The Cathedral and the Bazaar was an interesting read. Throughout the reading, Raymond lists small tips for Open Source software, coming his experiences as a programmer over the last 25-30 years. Here's some of the tips that I found most useful:
"Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging." - With Open Source software, if you keep the user invested in your product, they will most likely be more interested in helping continue the software development process (fixing bugs, new features, etc.).
"Release early. Release often. And listen to your customers." - Listening to the customer is very important, because most of the time the customer has a lot to say. I can say from personal experience (working at Hawkes Learning Systems), that the customer always likes to give their two cents about our product (whether it be new features to release, or things they don't like -- any feedback is good).
"To solve an interesting problem, start by finding a problem that is interesting to you." - This is very true, and is also why we decided to go with SugarLabs for our project. Doing something that you want to do makes the process feel less like a job and more like an enjoyable experience to learn from.
Overall, Raymond has a lot of great things to say about Open Source Software in the Cathedral and the Bazaar.
For the next half of class, we spent some time looking into more detail about SugarLabs. We managed to join the IRC chat just to get a feel for how that works. We also found out about a weekly meeting for SugarLabs on Thursday nights, so tomorrow night we will all be joining the IRC chat to see what's going on. We also found the mailing list on their website for developers, so we went ahead and signed up for that as well.
The Cathedral and the Bazaar was an interesting read. Throughout the reading, Raymond lists small tips for Open Source software, coming his experiences as a programmer over the last 25-30 years. Here's some of the tips that I found most useful:
"Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging." - With Open Source software, if you keep the user invested in your product, they will most likely be more interested in helping continue the software development process (fixing bugs, new features, etc.).
"Release early. Release often. And listen to your customers." - Listening to the customer is very important, because most of the time the customer has a lot to say. I can say from personal experience (working at Hawkes Learning Systems), that the customer always likes to give their two cents about our product (whether it be new features to release, or things they don't like -- any feedback is good).
"To solve an interesting problem, start by finding a problem that is interesting to you." - This is very true, and is also why we decided to go with SugarLabs for our project. Doing something that you want to do makes the process feel less like a job and more like an enjoyable experience to learn from.
Overall, Raymond has a lot of great things to say about Open Source Software in the Cathedral and the Bazaar.
Tuesday, January 18, 2011
Day Two
On the second day of class, we were thrown right into the Open Source projects and were told to pick the top 3. There were so many options available (ranging from developing a music player like iTunes, to working on parts of an open source operating system for kids). While the list of options seemed endless, our team quickly narrowed it down to the following three options:
1. SugarLabs
2. One Laptop per Child
3. Open Office for Kids
The main reason we narrowed it down to these three was simple: easy to get involved, and there's a lot of work to be done. As a homework assignment, we decided to divide up the work by each of us looking a little deeper into one of the top 3 open source projects, and to report our findings on Tuesday to make our final decision. My responsibility was Open Office for Kids, and here's what I found:
Pro's:
- Available for development on all operating systems.
- Seems to be an active project -- recent contributions from other developers.
Con's:
- C++ -- not exactly my favorite, but I suppose I could use the experience.
- Not much documentation to get started easily.
- Most contributors speak French (which will make it difficult to get in contact on IRC... considering that none of us are fluent).
Overall, I don't think this will be the top choice. The impression that I got on Thursday was that our team was pretty much set on SugarLabs.
SugarLabs is the best option because it makes it really easy for us to start out. They have plenty of great documentation to follow (guides to follow, etc.) to help us get moving quickly. The community seems very active, and is open to new developers. What stands out the most is that SugarLabs is basically an environment for us to hopefully develop (start and finish) our own learning-based game for kids, using the existing operating system and API's that the community has to offer. In a way, it would be like developing an app for the iPhone or Android, but maybe a little less complex.
The idea mentioned in chapter two of TOS made an interesting point when it talked about "Contributor Mountain". Most people aren't driven to Open Source Software just by the sheer act of wanting to participate, but more because they see changes that can be made that can help improve the software. When someone spots a bug, an active user will (at the very least) inform someone about it. A more proactive user may even decide to take action themselves in fixing the problem, and Open Source Software allows us to have that capability -- to always actively make changes that will positively affect the software's development.
1. SugarLabs
2. One Laptop per Child
3. Open Office for Kids
The main reason we narrowed it down to these three was simple: easy to get involved, and there's a lot of work to be done. As a homework assignment, we decided to divide up the work by each of us looking a little deeper into one of the top 3 open source projects, and to report our findings on Tuesday to make our final decision. My responsibility was Open Office for Kids, and here's what I found:
Pro's:
- Available for development on all operating systems.
- Seems to be an active project -- recent contributions from other developers.
Con's:
- C++ -- not exactly my favorite, but I suppose I could use the experience.
- Not much documentation to get started easily.
- Most contributors speak French (which will make it difficult to get in contact on IRC... considering that none of us are fluent).
Overall, I don't think this will be the top choice. The impression that I got on Thursday was that our team was pretty much set on SugarLabs.
SugarLabs is the best option because it makes it really easy for us to start out. They have plenty of great documentation to follow (guides to follow, etc.) to help us get moving quickly. The community seems very active, and is open to new developers. What stands out the most is that SugarLabs is basically an environment for us to hopefully develop (start and finish) our own learning-based game for kids, using the existing operating system and API's that the community has to offer. In a way, it would be like developing an app for the iPhone or Android, but maybe a little less complex.
The idea mentioned in chapter two of TOS made an interesting point when it talked about "Contributor Mountain". Most people aren't driven to Open Source Software just by the sheer act of wanting to participate, but more because they see changes that can be made that can help improve the software. When someone spots a bug, an active user will (at the very least) inform someone about it. A more proactive user may even decide to take action themselves in fixing the problem, and Open Source Software allows us to have that capability -- to always actively make changes that will positively affect the software's development.
Wednesday, January 12, 2011
First Day
What was supposed to be the second day of school ended up being the first (by some miracle -- I really needed that extra day). Software Engineering Practicum was the perfect start to the new semester. It turns out that I'm the new kid in this class, since I had Boetje for CSCI 362 the year before. Seems that everyone else is already very familiar with working with each other, but the CS department is small enough that I already know most of the people here.
I'm very satisfied with the group that I'm in. Alex and I already know each other from work, and I met Megan last semester in a previous class. While Austin is the newest person to me, I know we've had classes together before.
We managed to decide on roles for our group pretty quickly. Alex is the group leader, Megan is the spokesperson, Austin is the writer, and I'm the chief programmer/liaison. My role consists of two major things:
1) Observing all the code checked in by each team member, making sure that each contributor's work compiles, and that the code maintains a consistent and readable format.
2) When communicating with the Open Source community, I'll be the one in charge of maintaing our code, communicating with other developers (in IRC chat, etc.), and making sure any work that we publish to the Open Source project is the best it can be.
While the roles worked out well for everyone, we did take quite a bit longer to come up with a name for our group. After roughly 10 minutes of googling a name, we finally decided on The Flux Capacitors. Can't go wrong with a Back to the Future reference I suppose.
All-in-all, day one of this class turned out great, and I'm excited to see where this semester is going to take the team and myself.
As for the readings, I agree with what is said in the first chapter. Creating your own "Senior Project" for programming isn't really the best practice for the field of Computer Science. Being thrown into a real programming project is not only more meaningful (since there will most likely be users that will actually use the program), but it provides students a way to understand the entire process of development -- by throwing students into a much larger task, much like one that would be seen from a future employer.
Conformation for POSSCON: Transaction ID: RKCHWVVPPL, Order Number: 10000247
I'm very satisfied with the group that I'm in. Alex and I already know each other from work, and I met Megan last semester in a previous class. While Austin is the newest person to me, I know we've had classes together before.
We managed to decide on roles for our group pretty quickly. Alex is the group leader, Megan is the spokesperson, Austin is the writer, and I'm the chief programmer/liaison. My role consists of two major things:
1) Observing all the code checked in by each team member, making sure that each contributor's work compiles, and that the code maintains a consistent and readable format.
2) When communicating with the Open Source community, I'll be the one in charge of maintaing our code, communicating with other developers (in IRC chat, etc.), and making sure any work that we publish to the Open Source project is the best it can be.
While the roles worked out well for everyone, we did take quite a bit longer to come up with a name for our group. After roughly 10 minutes of googling a name, we finally decided on The Flux Capacitors. Can't go wrong with a Back to the Future reference I suppose.
All-in-all, day one of this class turned out great, and I'm excited to see where this semester is going to take the team and myself.
As for the readings, I agree with what is said in the first chapter. Creating your own "Senior Project" for programming isn't really the best practice for the field of Computer Science. Being thrown into a real programming project is not only more meaningful (since there will most likely be users that will actually use the program), but it provides students a way to understand the entire process of development -- by throwing students into a much larger task, much like one that would be seen from a future employer.
Conformation for POSSCON: Transaction ID: RKCHWVVPPL, Order Number: 10000247
Subscribe to:
Posts (Atom)