Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Im gonna start a thread where people can put there thoughts on how to get the development started.
I'll get the ball rolling with what I think we're gonna need.
1. Development platform. Probably a good idea if we start off (at least) using the same environment. I propose we have a crack off Fedora 7. For no other reason then I havent had the priviledge yet and my Mandrake 10 (!!!) install is getting me down.
I am open to suggestions here. Yes, I will even entertain the dark lords bag of bolts (aka M$).
2. Development source control. I'd say this decision is made already but lets get in written down. Show of hands for svn?
3. Development tools environment. I always like to keep my tools under source control too. That way when someone checks out the repos they are certain to get the exact version of tools that everyone else is using. It also means that makefiles can be guaranteed of finding the bloody things where it expects em.
4. Development environment structure. Something like? :
/tags - tags of the repos stored here
/tags/PRE_SVN_INDEXING (tag names in upper caps?)
/trunk/docs - holds any documentation
/branches/users/<userName> - our own private branches
/branches/users/<userName>/<branchName>/src - top level of source
/branches/users/<userName>/<branchName>/tools - the tools repos
/branches/int - branches get integrated into here. Holds the latests stable development code
/release - releases are thrown in here.
/release/R0.01 - etc
Something like that d'ye think? People can create branches in their own area to their hearts content. Each branch should be based off the latest integration branch (but doesnt have to be). In svn this is real easy:
svn mkdir svn+ssh://eolas.com/eolas/branches/users/johnoc/dev
svn cp svn+ssh://eolas.com/eolas/branches/int svn+ssh://eolas.com/eolas/branches/users/johnoc/dev
svn co svn+ssh://eolas.com/eolas/branches/users/johnoc/dev /local/eolas/dev
And yer done. Everything is checked out and ready to go. Major features live in a branch. Minor updates can be done straight into the integration branch.
I like to keep the trunk clear of code. So that people can check it out and read the documents if thats all they want to do. If they're interested in viewing the code then the trunk/docs/userManual.pdf will explain what they need to do.
5. Buld environment: makefile? ant? shell scripts? I'm open to suggestions here. They're all fine. I like makefiles. I just like the idea of writing "make eolas" and everything just working smooth like. But then I also like emacs. So dont listen to me! :)
Maybe you'd prefer some sort of eclipse / project / ide doohickey?
6. Source control hosting. Where will the repository reside? Will sourceforge give us space? What are the details there? Or do we need to source the repos elsewhere? Derm have you got access to a machine at work? Or are ye firewalled in?
Ok at this point we have standard dev setups. All using the same tools and make systems. And branching off the same integration branch.
After that we just have to write the damn thang!
Sounds good to me. I was a little worried initially but apparently SourceForge supports SVN so we're flying:
We might want to host an Eolas instance somewhere eventually but a Fedora VM sounds good to me too. Can we try keep it smallish?
My vote is to stick with Linux, mainly cos I like the appliance idea. Also I suspect that support for Apache, SVN and other server-side software we might wanna use is always going to be a bit better on Linux.
Some handy links
Torrents for all things fedora. Just noticed that theres a fedora8....feck it im after starting downloading 7 now...
Here be user manuals and binaries for virtual box.
Im putting the two of these together at the mo. i'll let ye know how i get on. the iso is gonna take a while to come down. first thing to do is create a virtual machine - i gave mine a gig of ram and 32gig of hard disk.
that should be loads.
after the vm is setup you then point it at the downloaded fedora iso image and yer away. no need to burn a dvd or anything.
i reckon pretty much everything we'll need will be in the standard install.
Happy to report that virtualBox is a joy.
Couldnt really be much simpler to install.
Fedora 7 up and running. Networking just worked.
svn, python, perl, ant, gcc all preinstalled.
play more tomorrow
Good man -- I want that level of handholding to continue!
I should have Fedora by the time I get home, no torrents allowed in the emc firewall
I presume Apache's on it too? (Or is that bundled with svn?)
To kick it off, how about we try and do Eolas Chorus v0.0 as follows:
Step 1: Amend the Eolas Solo client so that it gets and puts to/from svn rather than local fielsystem (assuming svn/apache already supports put, which it must when you think about it)
Step 2: errrm... I don't think we need a Step 2!
Step 3: Do Eolas Chorus v1.0 in Ajax
So basically we'd continue with Eolas in VB, for now, just to test svn, blithely skip step two, and then write what Eolas bits we need in Ajax?
Step 2 worries me, however ... ;)
Well I think we'll learn a lot in step 1, and it could go on indefinitely [ although I think John runs too tight a ship for that to happen ;-) ]
Superficially, Eolas Chorus differs from Eolas Solo as follows:
-- You just put your files on the network rather than local disk
-- Its not just you, its other people
Sounds simple, and in a way it *is* simple, since svn takes care of network storage, locking, versioning concurrency etc for us.
However theres loads of ways for subversion to store files, create associations between related files, and serve the correct version. In other words, the "backend". This is what I see us exploring in Step 1. At the end, we'll have a multi-user, networked application.
Then, since we don't want to require everyone to install clients all over the place, we make it into a web app, which is where the Ajax comes in.
As for dropping the VB code -- lets not be hasty. I dunno about ye but I've dabbled with Ajax a tiny bit and its not as easy as it sounds. Theres a massive choice of toolkits etc. Its a simple concept and fantastic tech but theres a million ways to do it. We have a VB prototype client right now, I think it could at least be a good test tool for 'step 1'.
Then again theres three of us! Ajax research and svn/backend research could proceed in parallel. Its gonna be a great lunch!
Hang on, dammit, must learn to read from top. Right, I've been suffering from a MAN-cold the last week or so. It wasn't tooo bad, (no ambulances, resus or anything) but it did mean that I wasn't sleeping great and so was tired and tired = no damn enthusiasm for anything.
Right, as my defense system seems to be getting the upper hand I'll try to get back on this particular rollercoaster...
I've downloaded virtualbox and will start on installing fedora but Eolas will haveta be ported to bag o' bolts at some stage, it should be a tool not a toy and currently MS owns the shed.
I'm firewalled here as well, Sourceforge will provide hosting but I have to check up the details. Should be ok for now though.
It appears that we should skip step 1 as well. Eolas was written in vb.net, and is just a starting point idea thing now (no real loss to the coding world if I do say so myself)
Hang on. I'm confused.
Just noticed you said it'll have to be ported at some stage.
I thought we were developing a network application. Unless its intended to be a peer-to-peer app, we get to have one or more servers somewhere. True the *clients* need to run on Windows at least (although an Ajax UI makes this irrelevant) but the server can be anything.
Now, if you want a p2p app, thats a whole new fascinating ballgame!
word of advice.
make a share folder (i called mine eolasShare) and do all of your work in here.
to mount the share :
mount -t vboxsf eolasShare /mnt/eolasShare
So all your code should live in the share point. That way you can change os flavour (ubuntu etc) and not affect your code. Also it makes it easier to get access to it from outside of virtualBox.
ive about another 100 package updates to download...should of kicked that off last night...
anyhoo, i think apache comes with svn but ive no eveidence. havent spotted apache anywhere yet.
disappointed that xmeacs wasnt preinstalled! ahh well.
also, be sure and read the manual about guest additions. this is important. it'll sort out full screen resolution, mouse capture, cut'n'paste and all that sort of thing.
its hard to see how vmWare can compete really. this is all for free!
you can even run vista in there. but i would not recommend it...:)
re. above confusion. you're in the wrong thread!! get off my "sticking stuff in a box and pressing the go button" thread!! :)
but seriously, i'd be all for trying to reuse the vb. this problem splits neatly between client and server. and we can have as many clients as we want.
i'd like to see some server scripts too. possibly we could build up a library of server scripts.
createProject.py <project name> [<propId=value> ...] // create a new class
addDocument.py <project namee> <doc location> <doc name> [<propId=value> ...] // add a doc to a class
addTransformer.py <path to app> <transformer name> <input type> <output type> [<propId=value> ...] // add a transformer
trasform.py <project name> <input doc name> <transformer name> <output doc name> // convert a doc
search.py <project name> <string> // search a class of docs' properties for a string
viewDocs.py <project name> // show all docs for a class
viewProjects.py // show all classes
importProject.py <input proj name> <output proj name> // pull in all docs from one class into another
sendDoc.py <project name> <doc name> <device> // rip to cd
The view scripts would just sent back an xml view of the data stored under svn.
The phrase "project name" above can obviously be substituted for classroom.
what other sorts of things do we want to do with the data?
these scripts may in time evolve into describing our client/server api.
to begin with they would be very useful way to play with svn and see what interesting operations we could get it to do.
Sorry for fecking the "press go" thread :-)
I was going to try move it but we're here now, for better or for worse! Lets keep it going until after the famous lunch, which we'll probably miss due to snow. In Southern Ireland. I reckon its a sign of the gods favour.
re. the scripts: looks like we've got ourselves an API ;-)
Before I think too much about API design though, I'd love to get the Apache/SVN integration running. I think we'll have two choices: (a) design an API that kind of abstracts away the architecture/components we've chosen OR (b) design an API that embraces it.
A REST system would probably fall into category (b). I'm too tired to try and paraphrase it here but theres thousands of docs on the net. (yet again!) heres my tags:
OK I will try and paraphrase it: instead of designing a procedure/method-based API with verbs like createProject etc, you restrict yourself to the actual HTTP methods (PUT, POST, GET, DELETE) and HTTP headers and response codes and design a very rich, descriptive URL namespace. Its kind of "verbs bad, nouns good". Resource-oriented. Proponents say it works with the very grain of the web. Its interesting.
Of course (a) has advantages too. As I say, I'd like to play with svn a bit more and let the tradeoffs become a bit clearer. Actually I really should go and look at your colleagues site John, will do that now, g'night!
sweet as a nut.
[johnoc@localhost ~]$ cd /home/johnoc
[johnoc@localhost ~]$ svn co file:///local/eolas/svn/branches/int
Checked out revision 8.
[johnoc@localhost src]$ cd int/src
[johnoc@localhost src]$ svn info
Repository Root: file:///local/eolas/svn
Repository UUID: 20e5cace-0533-41cd-848d-02f034161e09
Node Kind: directory
Last Changed Author: root
Last Changed Rev: 7
Last Changed Date: 2008-01-31 22:27:31 +0000 (Thu, 31 Jan 2008)
[johnoc@localhost src]$ whoami
Have created an svn repository on a shared directory (c:\eolasShare) which is mounted to /local/eolas/svn
Just checked out a working copy to /home/johnoc/int
OK I looked at Dave's site: nice job! Can we get him to join?
However the bee's in me bonnet so I'm gonna risk embarrassing Dave by using his URL as an example of a non-REST system:
Here is the URL for Yardbirds album art:
And heres the URL for Christy Moore/Voyage:
Thing is, they're the exact same. Most modern web apps have completely lost addressability.
A REST system would have URLs more like this:
Addressability isn't the only issue, I'm just trying to give a flavour of it. I'll try to remain objective. At the least, its a new and interesting trend that we shouldn't ignore.
dude you're online. wots your skype im?