Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Lets get started

johnoc
2008-01-29
2013-03-25
  • johnoc
    johnoc
    2008-01-29

    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
    /trunk/docs - holds any documentation
    /branches
    /branches/users
    /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
    /branches/int/src
    /branches/int/tools
    /branches/int/tools/svn
    /branches/int/tools/python
    /branches/int/tools/etc
    /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!

     
    • Conor Fox
      Conor Fox
      2008-01-29

      Sounds good to me.  I was a little worried initially but apparently SourceForge supports SVN so we're flying:
      http://haacked.com/archive/2006/02/22/QuickstartGuidetoSubversiononSourceForge.aspx

      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.

       
    • johnoc
      johnoc
      2008-01-30

      Some handy links

      Torrents for all things fedora. Just noticed that theres a fedora8....feck it im after starting downloading 7 now...
      http://torrent.fedoraproject.org/

      Here be user manuals and binaries for virtual box.
      http://www.virtualbox.org/wiki/Downloads

      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.

       
    • johnoc
      johnoc
      2008-01-31

      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.

      laughin.
      play more tomorrow

       
    • Conor Fox
      Conor Fox
      2008-01-31

      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?)

       
    • Conor Fox
      Conor Fox
      2008-01-31

      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

       
      • Derm
        Derm
        2008-01-31

        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 ... ;)

         
        • Conor Fox
          Conor Fox
          2008-01-31

          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!

           
    • Derm
      Derm
      2008-01-31

      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)

       
    • Conor Fox
      Conor Fox
      2008-01-31

      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!

       
    • johnoc
      johnoc
      2008-01-31

      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.
      eg.
      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.

       
    • Conor Fox
      Conor Fox
      2008-01-31

      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!

       
    • johnoc
      johnoc
      2008-01-31

      sweet as a nut.

      [johnoc@localhost ~]$ cd /home/johnoc
      [johnoc@localhost ~]$ svn co file:///local/eolas/svn/branches/int
      A    int/tools
      A    int/src
      Checked out revision 8.
      [johnoc@localhost src]$ cd int/src
      [johnoc@localhost src]$ svn info
      Path: .
      URL: file:///local/eolas/svn/branches/int/src
      Repository Root: file:///local/eolas/svn
      Repository UUID: 20e5cace-0533-41cd-848d-02f034161e09
      Revision: 8
      Node Kind: directory
      Schedule: normal
      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
      johnoc

      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

      laughin.

       
    • Conor Fox
      Conor Fox
      2008-01-31

      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:
      http://davidoshea.homelinux.net/~david/db/

      And heres the URL for Christy Moore/Voyage:
      http://davidoshea.homelinux.net/~david/db/

      Thing is, they're the exact same.  Most modern web apps have completely lost addressability.
      A REST system would have URLs more like this:
      http://davidoshea.homelinux.net/albums/christy_moore/voyage/art
      http://davidoshea.homelinux.net/albums/yardbirds/with_eric_clapton/art
      http://davidoshea.homelinux.net/albums/art/christy_moore/voyage
      http://davidoshea.homelinux.net/albums/art/yardbirds/with_eric_clapton

      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.

       
    • Conor Fox
      Conor Fox
      2008-01-31

      dude you're online.  wots your skype im?