I said on Tuesday that the next £5app meet would be in about a month
for judging the 5K competition. So now we just need to figure out
what the best date would be to avoid clashing with too many other
events, so as many people are able to attend/enter as possible. Plus
if anyone wants to suggest/volunteer a venue that'd be handy too ;^)
I'd in particular like to avoid clashing with FlashBrighton, so
Tuesdays are ruled out. Wednesdays are obviously the Farm, so that
leaves Mondays or Thursdays realistically (assuming Fridays are not a
good evening for an event) - probably between the 6th-30th of April.
Perhaps later in the month to allow for some more time?
I'm also still happy to change the rules to encourage a few more
entries. I've already removed on constraint, that meant the app had
to consist of a single file. Realistically having to base64 encode an
image to embed it in a html file was probably asking a bit much...
> I said on Tuesday that the next £5app meet would be in about a month
> for judging the 5K competition. So now we just need to figure out
> what the best date would be to avoid clashing with too many other
> events, so as many people are able to attend/enter as possible. Plus
> if anyone wants to suggest/volunteer a venue that'd be handy too ;^)
> I'd in particular like to avoid clashing with FlashBrighton, so
> Tuesdays are ruled out. Wednesdays are obviously the Farm, so that
> leaves Mondays or Thursdays realistically (assuming Fridays are not a
> good evening for an event) - probably between the 6th-30th of April.
> Perhaps later in the month to allow for some more time?
> I'm also still happy to change the rules to encourage a few more
> entries. I've already removed on constraint, that meant the app had
> to consist of a single file. Realistically having to base64 encode an
> image to embed it in a html file was probably asking a bit much...
Jack made a good suggestion on twitter (http://twitter.com/jackmoxley/ status/1282785487) to allow the entries to be zipped and use that as
the 5K limit. Means people can worry less about compressing/packing
their apps and more about crafting the minimal feature set they need.
Would also lower the barrier for entry, which is desirable.
Any thoughts?
On Mar 5, 10:06 am, lilspikey <lilspi...@gmail.com> wrote:
> I said on Tuesday that the next £5app meet would be in about a month
> for judging the 5K competition. So now we just need to figure out
> what the best date would be to avoid clashing with too many other
> events, so as many people are able to attend/enter as possible. Plus
> if anyone wants to suggest/volunteer a venue that'd be handy too ;^)
> I'd in particular like to avoid clashing with FlashBrighton, so
> Tuesdays are ruled out. Wednesdays are obviously the Farm, so that
> leaves Mondays or Thursdays realistically (assuming Fridays are not a
> good evening for an event) - probably between the 6th-30th of April.
> Perhaps later in the month to allow for some more time?
> I'm also still happy to change the rules to encourage a few more
> entries. I've already removed on constraint, that meant the app had
> to consist of a single file. Realistically having to base64 encode an
> image to embed it in a html file was probably asking a bit much...
Secondly, we could just cancel our FlashBrighton meeting one night and
I could tell everyone to come to £5app instead! Currently April is
pretty booked but we have 21st April free if you like?
cheers!
Seb
Seb Lee-Delisle
Technical Director
pluginmedia.net
On Thu, Mar 5, 2009 at 10:52 AM, lilspikey <lilspi...@gmail.com> wrote:
> Jack made a good suggestion on twitter (http://twitter.com/jackmoxley/ > status/1282785487) to allow the entries to be zipped and use that as
> the 5K limit. Means people can worry less about compressing/packing
> their apps and more about crafting the minimal feature set they need.
> Would also lower the barrier for entry, which is desirable.
> Any thoughts?
> On Mar 5, 10:06 am, lilspikey <lilspi...@gmail.com> wrote:
>> Hi Everyone,
>> I said on Tuesday that the next £5app meet would be in about a month
>> for judging the 5K competition. So now we just need to figure out
>> what the best date would be to avoid clashing with too many other
>> events, so as many people are able to attend/enter as possible. Plus
>> if anyone wants to suggest/volunteer a venue that'd be handy too ;^)
>> I'd in particular like to avoid clashing with FlashBrighton, so
>> Tuesdays are ruled out. Wednesdays are obviously the Farm, so that
>> leaves Mondays or Thursdays realistically (assuming Fridays are not a
>> good evening for an event) - probably between the 6th-30th of April.
>> Perhaps later in the month to allow for some more time?
>> I'm also still happy to change the rules to encourage a few more
>> entries. I've already removed on constraint, that meant the app had
>> to consist of a single file. Realistically having to base64 encode an
>> image to embed it in a html file was probably asking a bit much...
On Mar 5, 11:14 am, Seb Lee-Delisle <sebsta...@gmail.com> wrote:
> First of all the zip idea is such a cop out :-)
It is a bit. Though with the current dearth of confirmed entries I'm
trying to make it easier. You're probably right though and it's not
that hard to find some tools to do the same job without resorting to a
zip file I guess.
Perhaps then if I get a slew of people saying they'll enter for sure
if only they could zip their code I might allow it. Sort of bribery
by code. For now I won't change the rules though.
> Secondly, we could just cancel our FlashBrighton meeting one night and
> I could tell everyone to come to £5app instead! Currently April is
> pretty booked but we have 21st April free if you like?
> On Mar 5, 11:14 am, Seb Lee-Delisle <sebsta...@gmail.com> wrote:
>> First of all the zip idea is such a cop out :-)
> It is a bit. Though with the current dearth of confirmed entries I'm
> trying to make it easier. You're probably right though and it's not
> that hard to find some tools to do the same job without resorting to a
> zip file I guess.
> Perhaps then if I get a slew of people saying they'll enter for sure
> if only they could zip their code I might allow it. Sort of bribery
> by code. For now I won't change the rules though.
>> Secondly, we could just cancel our FlashBrighton meeting one night
>> and
>> I could tell everyone to come to £5app instead! Currently April is
>> pretty booked but we have 21st April free if you like?
> Cafe Scientifique (http://upcoming.yahoo.com/event/1160771/) is on the
> 21st, but if it'd mean getting a bunch of Flash entries it'd be an
> acceptable clash ;^)
> Tom would that Tuesday work for you too? Could do the Monday instead
> to not clash with Cafe Sci and "move" FlashBrighton too perhaps?
Zip idea may or may not be a copout, but in the demoscene files are
all compressed... (with crunchers/decrunchers in the executable) - the
same is possible for swfs.
Java is already basically distributed zipped (in jar files) - so this
would need to be ruled out as well.
+ Ofuscators are ok... so this is a little fuzzier.
In conclusion, allowing zips is good, as otherwise you'll need to rule
out/in executable compressors which is either more fair to technical
or non-technical people.
> On Mar 5, 12:17 pm, Tom Hume <tom.h...@futureplatforms.com> wrote:
>> Ah, Tuesdays are out for me I'm afraid - sorry, got a prior commitment
>> then :(
> Ok, well perhaps Monday 20th of April then? Would avoid the Cafe Sci
> clash too.
> Seb that way you could still run FlashBrighton on the Tuesday if you
> wanted? Or "move" it to the Monday and share with the 5K competition?
I think that if the delivery method for the particular file format
you're looking at included compression then that's fine (ie jars and
run-time decompression for exes). But to zip up a load of php files
and say that's 5k, well that's not cool as far as I'm concerned :-)
Seb Lee-Delisle
Technical Director
pluginmedia.net
On Fri, Mar 6, 2009 at 12:20 PM, Stu <stu.a...@gmail.com> wrote:
> Zip idea may or may not be a copout, but in the demoscene files are
> all compressed... (with crunchers/decrunchers in the executable) - the
> same is possible for swfs.
> Java is already basically distributed zipped (in jar files) - so this
> would need to be ruled out as well.
> + Ofuscators are ok... so this is a little fuzzier.
> In conclusion, allowing zips is good, as otherwise you'll need to rule
> out/in executable compressors which is either more fair to technical
> or non-technical people.
>> On Mar 5, 12:17 pm, Tom Hume <tom.h...@futureplatforms.com> wrote:
>>> Ah, Tuesdays are out for me I'm afraid - sorry, got a prior commitment
>>> then :(
>> Ok, well perhaps Monday 20th of April then? Would avoid the Cafe Sci
>> clash too.
>> Seb that way you could still run FlashBrighton on the Tuesday if you
>> wanted? Or "move" it to the Monday and share with the 5K competition?
On Fri, Mar 6, 2009 at 11:42 AM, lilspikey <lilspi...@gmail.com> wrote:
> On Mar 5, 12:17 pm, Tom Hume <tom.h...@futureplatforms.com> wrote:
>> Ah, Tuesdays are out for me I'm afraid - sorry, got a prior commitment
>> then :(
> Ok, well perhaps Monday 20th of April then? Would avoid the Cafe Sci
> clash too.
> Seb that way you could still run FlashBrighton on the Tuesday if you
> wanted? Or "move" it to the Monday and share with the 5K competition?
> I think that if the delivery method for the particular file format
> you're looking at included compression then that's fine (ie jars and
> run-time decompression for exes). But to zip up a load of php files
> and say that's 5k, well that's not cool as far as I'm concerned :-)
> Seb Lee-Delisle
> Technical Director
> pluginmedia.net
> On Fri, Mar 6, 2009 at 12:20 PM, Stu <stu.a...@gmail.com> wrote:
>> Zip idea may or may not be a copout, but in the demoscene files are
>> all compressed... (with crunchers/decrunchers in the executable) - the
>> same is possible for swfs.
>> Java is already basically distributed zipped (in jar files) - so this
>> would need to be ruled out as well.
>> + Ofuscators are ok... so this is a little fuzzier.
>> In conclusion, allowing zips is good, as otherwise you'll need to rule
>> out/in executable compressors which is either more fair to technical
>> or non-technical people.
>>> On Mar 5, 12:17 pm, Tom Hume <tom.h...@futureplatforms.com> wrote:
>>>> Ah, Tuesdays are out for me I'm afraid - sorry, got a prior commitment
>>>> then :(
>>> Ok, well perhaps Monday 20th of April then? Would avoid the Cafe Sci
>>> clash too.
>>> Seb that way you could still run FlashBrighton on the Tuesday if you
>>> wanted? Or "move" it to the Monday and share with the 5K competition?
Got a pretty big boost, as it cut the byte count in three.
So perhaps if I just prepare a similar tool for PHP that might help a
few people out. Would then also be useful for anyone doing straight
html+javascript too, as it'd just be a degenerate edge-case for using
php...
I think no compression should be allowed since the point of the exercise is
to be creative by using the smallest amount of code. If people want to
submit a zip file or something to submit their code that's fine, but only
the uncompressed size should count.
But I'm just a lurker on this mailing list, what do I know anyway? :-)
On Fri, Mar 6, 2009 at 4:42 PM, lilspikey <lilspi...@gmail.com> wrote:
> On Mar 6, 2:30 pm, Stu <stu.a...@gmail.com> wrote:
> > For phpers wanting to implement a decruncher gzip, zip, rar files are
> > supported so this helps make it trivially easy:
> Got a pretty big boost, as it cut the byte count in three.
> So perhaps if I just prepare a similar tool for PHP that might help a
> few people out. Would then also be useful for anyone doing straight
> html+javascript too, as it'd just be a degenerate edge-case for using
> php...
<nuno.morgadi...@gmail.com> wrote: > I think no compression should be allowed since the point of the exercise is > to be creative by using the smallest amount of code. If people want to > submit a zip file or something to submit their code that's fine, but only > the uncompressed size should count.
> But I'm just a lurker on this mailing list, what do I know anyway? :-)
I disagree ... using compression across the board levels the playing field wrt obfuscation and leaves the code readable to boot.
On Mar 6, 5:27 pm, Miles Sabin <mi...@milessabin.com> wrote:
> On Fri, Mar 6, 2009 at 3:48 PM, Nuno Morgadinho
> <nuno.morgadi...@gmail.com> wrote:
> > I think no compression should be allowed since the point of the exercise is
> > to be creative by using the smallest amount of code. If people want to
> > submit a zip file or something to submit their code that's fine, but only
> > the uncompressed size should count.
> > But I'm just a lurker on this mailing list, what do I know anyway? :-)
> I disagree ... using compression across the board levels the playing
> field wrt obfuscation and leaves the code readable to boot.
Given that Java apps are already zipped in a jar file and obfuscators
like pro-guard work really well, I'm inclined to let people zip their
entries to help level the playing field too. Otherwise Java et al
have a big advantage straight away.
My instincts tell me that people should just deal with the limit by
being creative, but at this stage I think just getting people to enter
at all is a bigger concern. I think allowing zipping of entries might
just make things simpler...
I think saying that compression should be allowed because certain
compilers output compressed code is a weak argument - is the limit not
supposed to be on source code?
As for obfuscation tools, comparing these to compressing tools is not
valid - yes, some languages such as C, Perl can be obfuscated better
than others such as Java, but you choose the language you use and you
have to weigh up these pros and cons - Java is difficult to obfuscate
and it takes a lot of code to do simple things; so maybe it's not the
language of choice for a minimal source code competition.
If I was to submit some source code that was 15k, then obfuscate it,
compile it into binary and then submit the number represented by that
(for example) unsigned binary sequence in ascii, would this be
acceptable?
An extreme example but my point is, when you start cutting corners
where do you stop?
> On Mar 6, 5:27 pm, Miles Sabin <mi...@milessabin.com> wrote:
>> On Fri, Mar 6, 2009 at 3:48 PM, Nuno Morgadinho
>> <nuno.morgadi...@gmail.com> wrote:
>> > I think no compression should be allowed since the point of the exercise is
>> > to be creative by using the smallest amount of code. If people want to
>> > submit a zip file or something to submit their code that's fine, but only
>> > the uncompressed size should count.
>> > But I'm just a lurker on this mailing list, what do I know anyway? :-)
>> I disagree ... using compression across the board levels the playing
>> field wrt obfuscation and leaves the code readable to boot.
> Given that Java apps are already zipped in a jar file and obfuscators
> like pro-guard work really well, I'm inclined to let people zip their
> entries to help level the playing field too. Otherwise Java et al
> have a big advantage straight away.
> My instincts tell me that people should just deal with the limit by
> being creative, but at this stage I think just getting people to enter
> at all is a bigger concern. I think allowing zipping of entries might
> just make things simpler...
On Mar 9, 3:11 pm, James Lawrie <stwa...@gmail.com> wrote:
> I think saying that compression should be allowed because certain
> compilers output compressed code is a weak argument - is the limit not
> supposed to be on source code?
No the limit is on the "executable code size".
> As for obfuscation tools, comparing these to compressing tools is not
> valid - yes, some languages such as C, Perl can be obfuscated better
> than others such as Java, but you choose the language you use and you
> have to weigh up these pros and cons - Java is difficult to obfuscate
> and it takes a lot of code to do simple things; so maybe it's not the
> language of choice for a minimal source code competition.
Actually for competitions like this Java fairs very well (given it's
large standard library), but yes I get your point.
> If I was to submit some source code that was 15k, then obfuscate it,
> compile it into binary and then submit the number represented by that
> (for example) unsigned binary sequence in ascii, would this be
> acceptable?
> An extreme example but my point is, when you start cutting corners
> where do you stop?
I know it's a "slippery slope" if the rules start getting more
relaxed, but this competition is worth exactly zero if no one enters.
At this point I'm just trying to work out what can be done to make the
competition suitably welcoming without destroying the point. Arguably
I shouldn't be allowing net-access in any form either, but that'd just
be boring...
However I am starting to think that it's easier to stick with the
rules as they stand - i.e. no separate de-compression needed to run
the app. So self-extracting apps are obviously ok, but zip files
aren't.
If I provide some tools to let people convert their apps into self-
extracting versions then maybe that would be better. It would help
level the playing field or perhaps it'd be more like supplying guns to
both sides of a war... Either way it means people can spend more time
on the app itself and less on worrying about the limit. Also tools
like that better match how Java does things (obfuscator + jar file).
I was finding I ended up for roughly similar amounts of source code
(300-500 lines) when using Java vs Javascript vs Python using this
sort of approach, so it seems pretty fair.
My job-doom-reposting bot is itself 4k (though that could be shrunk) and it
depends on the python-twitter module (12kb zipped) and the python JSON
module (66kb zipped). I'm only using python-twitter to post to twitter so
the whole pair of libs is massive overkill.
http://www.twitter.com/BrightonJobDoom
> On Mar 9, 3:11 pm, James Lawrie <stwa...@gmail.com> wrote:
> > I think saying that compression should be allowed because certain
> > compilers output compressed code is a weak argument - is the limit not
> > supposed to be on source code?
> No the limit is on the "executable code size".
> > As for obfuscation tools, comparing these to compressing tools is not
> > valid - yes, some languages such as C, Perl can be obfuscated better
> > than others such as Java, but you choose the language you use and you
> > have to weigh up these pros and cons - Java is difficult to obfuscate
> > and it takes a lot of code to do simple things; so maybe it's not the
> > language of choice for a minimal source code competition.
> Actually for competitions like this Java fairs very well (given it's
> large standard library), but yes I get your point.
> > If I was to submit some source code that was 15k, then obfuscate it,
> > compile it into binary and then submit the number represented by that
> > (for example) unsigned binary sequence in ascii, would this be
> > acceptable?
> > An extreme example but my point is, when you start cutting corners
> > where do you stop?
> I know it's a "slippery slope" if the rules start getting more
> relaxed, but this competition is worth exactly zero if no one enters.
> At this point I'm just trying to work out what can be done to make the
> competition suitably welcoming without destroying the point. Arguably
> I shouldn't be allowing net-access in any form either, but that'd just
> be boring...
> However I am starting to think that it's easier to stick with the
> rules as they stand - i.e. no separate de-compression needed to run
> the app. So self-extracting apps are obviously ok, but zip files
> aren't.
> If I provide some tools to let people convert their apps into self-
> extracting versions then maybe that would be better. It would help
> level the playing field or perhaps it'd be more like supplying guns to
> both sides of a war... Either way it means people can spend more time
> on the app itself and less on worrying about the limit. Also tools
> like that better match how Java does things (obfuscator + jar file).
> I was finding I ended up for roughly similar amounts of source code
> (300-500 lines) when using Java vs Javascript vs Python using this
> sort of approach, so it seems pretty fair.
> cheers,
> John
-- Ian Ozsvald (Professional Screencaster)
i...@ProCasts.co.uk
Which will add the right headers for authentication and read the
friends timeline (a safer example to test, than doing an update of
course). To add the post data you can use the "add_data" method of
the Request object with urlencoded form data via urllib.urlencode,
e.g.:
> My job-doom-reposting bot is itself 4k (though that could be shrunk) and it
> depends on the python-twitter module (12kb zipped) and the python JSON
> module (66kb zipped). I'm only using python-twitter to post to twitter so
> the whole pair of libs is massive overkill.http://www.twitter.com/BrightonJobDoom
> > On Mar 9, 3:11 pm, James Lawrie <stwa...@gmail.com> wrote:
> > > I think saying that compression should be allowed because certain
> > > compilers output compressed code is a weak argument - is the limit not
> > > supposed to be on source code?
> > No the limit is on the "executable code size".
> > > As for obfuscation tools, comparing these to compressing tools is not
> > > valid - yes, some languages such as C, Perl can be obfuscated better
> > > than others such as Java, but you choose the language you use and you
> > > have to weigh up these pros and cons - Java is difficult to obfuscate
> > > and it takes a lot of code to do simple things; so maybe it's not the
> > > language of choice for a minimal source code competition.
> > Actually for competitions like this Java fairs very well (given it's
> > large standard library), but yes I get your point.
> > > If I was to submit some source code that was 15k, then obfuscate it,
> > > compile it into binary and then submit the number represented by that
> > > (for example) unsigned binary sequence in ascii, would this be
> > > acceptable?
> > > An extreme example but my point is, when you start cutting corners
> > > where do you stop?
> > I know it's a "slippery slope" if the rules start getting more
> > relaxed, but this competition is worth exactly zero if no one enters.
> > At this point I'm just trying to work out what can be done to make the
> > competition suitably welcoming without destroying the point. Arguably
> > I shouldn't be allowing net-access in any form either, but that'd just
> > be boring...
> > However I am starting to think that it's easier to stick with the
> > rules as they stand - i.e. no separate de-compression needed to run
> > the app. So self-extracting apps are obviously ok, but zip files
> > aren't.
> > If I provide some tools to let people convert their apps into self-
> > extracting versions then maybe that would be better. It would help
> > level the playing field or perhaps it'd be more like supplying guns to
> > both sides of a war... Either way it means people can spend more time
> > on the app itself and less on worrying about the limit. Also tools
> > like that better match how Java does things (obfuscator + jar file).
> > I was finding I ended up for roughly similar amounts of source code
> > (300-500 lines) when using Java vs Javascript vs Python using this
> > sort of approach, so it seems pretty fair.
> > cheers,
> > John
> --
> Ian Ozsvald (Professional Screencaster)
> i...@ProCasts.co.uk
Super duper. I'll definitely do curl, might try your urlencoding trick.
@BrightonJobDoom will be safely under 5k now and is happily tracking
Brighton's descent into tribalism.
i.
> Which will add the right headers for authentication and read the
> friends timeline (a safer example to test, than doing an update of
> course). To add the post data you can use the "add_data" method of
> the Request object with urlencoded form data via urllib.urlencode,
> e.g.:
> On 31 Mar, 11:12, Ian Ozsvald <i...@ianozsvald.com> wrote:
> > Clarification please Mr. Adjudicator...
> > My job-doom-reposting bot is itself 4k (though that could be shrunk) and
> it
> > depends on the python-twitter module (12kb zipped) and the python JSON
> > module (66kb zipped). I'm only using python-twitter to post to twitter
> so
> > the whole pair of libs is massive overkill.
> http://www.twitter.com/BrightonJobDoom
> > I'm short of time and don't really fancy pulling all the libs apart just
> to
> > get under the 5k limit. What's the story on using a built-in tool on my
> > mac, e.g. 'curl', to auto-post to twitter? The twitter docs:
> http://apiwiki.twitter.com/REST+API+Documentation > > say I can do:
> > curl -u username:*password* -d status="*your message here*"
> http://twitter.com/statuses/update.json<
> http://twitter.com/statuses/update.xml%C2%A0>
> > which would rather solve my problem and easily keep the core py app under
> > 5k.
> > Can I spawn shell commands to use built-in cmd line tools? curl comes on
> my
> > MacBook and ISP (webfaction) by default.
> > > On Mar 9, 3:11 pm, James Lawrie <stwa...@gmail.com> wrote:
> > > > I think saying that compression should be allowed because certain
> > > > compilers output compressed code is a weak argument - is the limit
> not
> > > > supposed to be on source code?
> > > No the limit is on the "executable code size".
> > > > As for obfuscation tools, comparing these to compressing tools is not
> > > > valid - yes, some languages such as C, Perl can be obfuscated better
> > > > than others such as Java, but you choose the language you use and you
> > > > have to weigh up these pros and cons - Java is difficult to obfuscate
> > > > and it takes a lot of code to do simple things; so maybe it's not the
> > > > language of choice for a minimal source code competition.
> > > Actually for competitions like this Java fairs very well (given it's
> > > large standard library), but yes I get your point.
> > > > If I was to submit some source code that was 15k, then obfuscate it,
> > > > compile it into binary and then submit the number represented by that
> > > > (for example) unsigned binary sequence in ascii, would this be
> > > > acceptable?
> > > > An extreme example but my point is, when you start cutting corners
> > > > where do you stop?
> > > I know it's a "slippery slope" if the rules start getting more
> > > relaxed, but this competition is worth exactly zero if no one enters.
> > > At this point I'm just trying to work out what can be done to make the
> > > competition suitably welcoming without destroying the point. Arguably
> > > I shouldn't be allowing net-access in any form either, but that'd just
> > > be boring...
> > > However I am starting to think that it's easier to stick with the
> > > rules as they stand - i.e. no separate de-compression needed to run
> > > the app. So self-extracting apps are obviously ok, but zip files
> > > aren't.
> > > If I provide some tools to let people convert their apps into self-
> > > extracting versions then maybe that would be better. It would help
> > > level the playing field or perhaps it'd be more like supplying guns to
> > > both sides of a war... Either way it means people can spend more time
> > > on the app itself and less on worrying about the limit. Also tools
> > > like that better match how Java does things (obfuscator + jar file).
> > > I was finding I ended up for roughly similar amounts of source code
> > > (300-500 lines) when using Java vs Javascript vs Python using this
> > > sort of approach, so it seems pretty fair.
|
