Hi folks, Have just committed a big cleanup change to source control. The main part of it being standardising on tabs rather that spaces and on Windows line endings. Three reasons behind this and they are: a. it started off that way so it means we don''t mess up the file history and lose sight of what the actual changes were in each revision b. everyone who uses spaces rather than tabs has a different preference as to how many spaces are put in (I saw 2, 3 and 4 space indents in the code) so the code gets messy very quickly. Just use tabs instead and set them to display two spaces wide if you prefer narrower indents. c. spaces == wasted bytes As for the line endings I''ve set it to Windows for now but I''m not sure which is best, could do with doing a quick poll to find out what platform everyone is on and then go with that. Apart from the above I''ve removed some general whitespace and tried to improve readability in places. Have also added some JsDoc comments to the properties of the Mapstraction class so they appear in the documentation as I noticed they were in the v1 docs but weren''t being output in the v2. Finally, please make sure you run a build and hit the test page to ensure all is well before you commit your changes. The source is getting to the point where we need branch to rather than check breaking or half finished changes into trunk. I think in the not too distant future we''ll need to set up continuous integration and publish "stable" builds for people to download to avoid them downloading the source, finding it''s broken and not knowing what to do. Cheers, Derek -- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091215/438744c6/attachment.htm>
thanks for your efforts Derek. Great to see the project evolving in a positive direction Regarding saving bytes I''m all for it, but anyone using mxn in production should be minifying and then serving. thanks again, Ed On Tue, Dec 15, 2009 at 01:50, Derek Fowler <dezfowler at gmail.com> wrote:> Hi folks, > Have just committed a big cleanup change to source control. The main part of > it being standardising on tabs rather that spaces and on Windows line > endings. Three reasons behind this and they are: > a. it started off that way so it means we don''t mess up the file history and > lose sight of what the actual changes were in each revision > b. everyone who uses spaces rather than tabs has a different preference as > to how many spaces are put in (I saw 2, 3 and 4 space indents in the code) > so the code gets messy very quickly. Just use tabs instead and set them to > display two spaces wide if you prefer narrower indents. > c. spaces == wasted bytes > As for the line endings I''ve set it to Windows for now but I''m not sure > which is best, could do with doing a quick poll to find out what platform > everyone is on and then go with that. > Apart from the above I''ve removed some general whitespace and tried to > improve readability in places. Have also added some JsDoc comments to the > properties of the Mapstraction class so they appear in the documentation as > I noticed they were in the v1 docs but weren''t being output in the v2. > Finally, please make sure you run a build and hit the test page to ensure > all is well before you commit your changes. The source is getting to the > point where we need branch to rather than check breaking or half finished > changes into trunk. I think in the not too distant future we''ll need to set > up continuous integration and publish "stable" builds for people to download > to avoid them downloading the source, finding it''s broken and not knowing > what to do. > Cheers, > Derek > -- > Derek Fowler > m. +44 (0) 7966 512 369 > e. dezfowler at gmail.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >
Yeah - that was a minor point, I meant in source control. The build process generates the minified files for folks to use in production. We just need to get an automated build set up so folks can download a stable version both min''d and not rather than grabbing the whole source when they just want to use the library rather than change the Mapstraction code itself. Derek 2009/12/15 Ed Freyfogle <edf at sloan.mit.edu> thanks for your efforts Derek. Great to see the project evolving in a> positive direction > > Regarding saving bytes I''m all for it, but anyone using mxn in > production should be minifying and then serving. > > thanks again, > Ed > > On Tue, Dec 15, 2009 at 01:50, Derek Fowler <dezfowler at gmail.com> wrote: > > Hi folks, > > Have just committed a big cleanup change to source control. The main part > of > > it being standardising on tabs rather that spaces and on Windows line > > endings. Three reasons behind this and they are: > > a. it started off that way so it means we don''t mess up the file history > and > > lose sight of what the actual changes were in each revision > > b. everyone who uses spaces rather than tabs has a different preference > as > > to how many spaces are put in (I saw 2, 3 and 4 space indents in the > code) > > so the code gets messy very quickly. Just use tabs instead and set them > to > > display two spaces wide if you prefer narrower indents. > > c. spaces == wasted bytes > > As for the line endings I''ve set it to Windows for now but I''m not sure > > which is best, could do with doing a quick poll to find out what platform > > everyone is on and then go with that. > > Apart from the above I''ve removed some general whitespace and tried to > > improve readability in places. Have also added some JsDoc comments to the > > properties of the Mapstraction class so they appear in the documentation > as > > I noticed they were in the v1 docs but weren''t being output in the v2. > > Finally, please make sure you run a build and hit the test page to ensure > > all is well before you commit your changes. The source is getting to the > > point where we need branch to rather than check breaking or half finished > > changes into trunk. I think in the not too distant future we''ll need to > set > > up continuous integration and publish "stable" builds for people to > download > > to avoid them downloading the source, finding it''s broken and not knowing > > what to do. > > Cheers, > > Derek > > -- > > Derek Fowler > > m. +44 (0) 7966 512 369 > > e. dezfowler at gmail.com > > > > _______________________________________________ > > Mapstraction mailing list > > Mapstraction at lists.mapstraction.com > > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > >-- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091215/4dd6b395/attachment-0001.htm>
Derek Fowler wrote:> Yeah - that was a minor point, I meant in source control. The build > process generates the minified files for folks to use in production. > We just need to get an automated build set up so folks can download a > stable version both min''d and not rather than grabbing the whole > source when they just want to use the library rather than change the > Mapstraction code itself.Great Derek - thanks for this. I can setup something to run on mapstraction.com to do an Ant build and test with SVN hook - or if you have one already, that''s great. I agree that we want people downloading a stable/tested build rather than just whatever is on the top of the repository. Andrew> > Derek > > 2009/12/15 Ed Freyfogle <edf at sloan.mit.edu <mailto:edf at sloan.mit.edu>> > > thanks for your efforts Derek. Great to see the project evolving in a > positive direction > > Regarding saving bytes I''m all for it, but anyone using mxn in > production should be minifying and then serving. > > thanks again, > Ed > > On Tue, Dec 15, 2009 at 01:50, Derek Fowler <dezfowler at gmail.com > <mailto:dezfowler at gmail.com>> wrote: > > Hi folks, > > Have just committed a big cleanup change to source control. The > main part of > > it being standardising on tabs rather that spaces and on Windows > line > > endings. Three reasons behind this and they are: > > a. it started off that way so it means we don''t mess up the file > history and > > lose sight of what the actual changes were in each revision > > b. everyone who uses spaces rather than tabs has a different > preference as > > to how many spaces are put in (I saw 2, 3 and 4 space indents in > the code) > > so the code gets messy very quickly. Just use tabs instead and > set them to > > display two spaces wide if you prefer narrower indents. > > c. spaces == wasted bytes > > As for the line endings I''ve set it to Windows for now but I''m > not sure > > which is best, could do with doing a quick poll to find out what > platform > > everyone is on and then go with that. > > Apart from the above I''ve removed some general whitespace and > tried to > > improve readability in places. Have also added some JsDoc > comments to the > > properties of the Mapstraction class so they appear in the > documentation as > > I noticed they were in the v1 docs but weren''t being output in > the v2. > > Finally, please make sure you run a build and hit the test page > to ensure > > all is well before you commit your changes. The source is > getting to the > > point where we need branch to rather than check breaking or half > finished > > changes into trunk. I think in the not too distant future we''ll > need to set > > up continuous integration and publish "stable" builds for people > to download > > to avoid them downloading the source, finding it''s broken and > not knowing > > what to do. > > Cheers, > > Derek > > -- > > Derek Fowler > > m. +44 (0) 7966 512 369 > > e. dezfowler at gmail.com <mailto:dezfowler at gmail.com> > > > > _______________________________________________ > > Mapstraction mailing list > > Mapstraction at lists.mapstraction.com > <mailto:Mapstraction at lists.mapstraction.com> > > > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > > > > > > -- > Derek Fowler > m. +44 (0) 7966 512 369 > e. dezfowler at gmail.com <mailto:dezfowler at gmail.com> > > > > -- > Derek Fowler > m. +44 (0) 7966 512 369 > e. dezfowler at gmail.com <mailto:dezfowler at gmail.com> > ------------------------------------------------------------------------ > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-- Andrew Turner m: 248.982.3609 e: andrew at highearthorbit.com t: @ajturner b: http://highearthorbit.com w: http://geocommons.com Introduction to Neogeography - http://oreilly.com/catalog/neogeography -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100107/32ea1d29/attachment.htm>
Would be good to get it set up on mapstraction.com hooked into the SVN repository, yes. I guess we should add a build step that zips up the output too and a page for getting the stable build and the latest "nightly". You mentioned a while ago about getting folks to test the library - would be good to set up a page on the mapstraction site for "Help us test the latest version" or something. Basically get the current test "suite" into a page that can accept user input and stashes the results in a database alongside the user-agent string. Only once every feature passes in every browser on every platform can it be released. May be a bit of work but given the nature of the library I''m not sure how else we could do it. Derek 2010/1/7 Andrew Turner <ajturner at highearthorbit.com>> Derek Fowler wrote: > > Yeah - that was a minor point, I meant in source control. The build process > generates the minified files for folks to use in production. We just need to > get an automated build set up so folks can download a stable version both > min''d and not rather than grabbing the whole source when they just want to > use the library rather than change the Mapstraction code itself. > > > Great Derek - thanks for this. > > I can setup something to run on mapstraction.com to do an Ant build and > test with SVN hook - or if you have one already, that''s great. I agree that > we want people downloading a stable/tested build rather than just whatever > is on the top of the repository. > > Andrew > > > Derek > > 2009/12/15 Ed Freyfogle <edf at sloan.mit.edu> > > thanks for your efforts Derek. Great to see the project evolving in a >> positive direction >> >> Regarding saving bytes I''m all for it, but anyone using mxn in >> production should be minifying and then serving. >> >> thanks again, >> Ed >> >> On Tue, Dec 15, 2009 at 01:50, Derek Fowler <dezfowler at gmail.com> wrote: >> > Hi folks, >> > Have just committed a big cleanup change to source control. The main >> part of >> > it being standardising on tabs rather that spaces and on Windows line >> > endings. Three reasons behind this and they are: >> > a. it started off that way so it means we don''t mess up the file history >> and >> > lose sight of what the actual changes were in each revision >> > b. everyone who uses spaces rather than tabs has a different preference >> as >> > to how many spaces are put in (I saw 2, 3 and 4 space indents in the >> code) >> > so the code gets messy very quickly. Just use tabs instead and set them >> to >> > display two spaces wide if you prefer narrower indents. >> > c. spaces == wasted bytes >> > As for the line endings I''ve set it to Windows for now but I''m not sure >> > which is best, could do with doing a quick poll to find out what >> platform >> > everyone is on and then go with that. >> > Apart from the above I''ve removed some general whitespace and tried to >> > improve readability in places. Have also added some JsDoc comments to >> the >> > properties of the Mapstraction class so they appear in the documentation >> as >> > I noticed they were in the v1 docs but weren''t being output in the v2. >> > Finally, please make sure you run a build and hit the test page to >> ensure >> > all is well before you commit your changes. The source is getting to the >> > point where we need branch to rather than check breaking or half >> finished >> > changes into trunk. I think in the not too distant future we''ll need to >> set >> > up continuous integration and publish "stable" builds for people to >> download >> > to avoid them downloading the source, finding it''s broken and not >> knowing >> > what to do. >> > Cheers, >> > Derek >> > -- >> > Derek Fowler >> > m. +44 (0) 7966 512 369 >> > e. dezfowler at gmail.com >> > >> > _______________________________________________ >> > Mapstraction mailing list >> > Mapstraction at lists.mapstraction.com >> > >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> > >> > > > > > > -- > Derek Fowler > m. +44 (0) 7966 512 369 > e. dezfowler at gmail.com > > > > -- > Derek Fowler > m. +44 (0) 7966 512 369 > e. dezfowler at gmail.com > > ------------------------------ > > _______________________________________________ > Mapstraction mailing listMapstraction at lists.mapstraction.comhttp://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > -- > Andrew Turner > m: 248.982.3609 e: andrew at highearthorbit.com t: @ajturner > b: http://highearthorbit.com w: http://geocommons.com > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > >-- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100107/a8514835/attachment-0001.htm>