The baseline complexity of tiny big projects...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

The baseline complexity of tiny big projects...

Tim Mackinnon
I’m wondering if others might spot a better way of handling this - but with Exercism, I’ve got 100 exercises to manage. An Exercise is a TestCase and 1 or more solution classes (normally 1, but sometimes several). I had initially used Tags to manage this, there was an ExercismExercise package, and then a tag for each exercise. This was quite neat and tidy - however its flawed as it doesn’t allow extension methods on the tags (they live on the parent package - which is problematic as in use, the exercises are loaded one by one from tonel files as the student progresses), it also does let you critique an individual exercise… so essentially they aren’t sub-projects and I was recommended to promote them to proper Packages.

This was all quite trivial to support with tags but now I have to grapple with the BaselineOf for my project (to manage all these exercises in development mode - where you want to load them all, run all their tests, and add to them etc).

As each exercise depends on an ExercismTestCase - I have a single pre-req for each one, and then, in development mode, I have to load all 100 of them. The best I came up with was the following - but its a hell of a lot more complicated than the previous tag solution where effectively the owning package let me do this once (and membership of that package automatically gave a tag this pre-req and containment behaviour).

So instead I have to do the following (and I’m left wondering if I’m missing some easier way). The bold bits are where I’ve tried to do something to try and workaround this - its the array of  packageNames that is a bit distasteful to me, and it feels a lot like I have to express the same information twice - one in the iceberg window to add all these packages, and then again in the method of names, to set the identical pre-req on each of them… I find in this respect, I’m missing Envy developer here?

Anyone have some better suggestions? Or do we need to try and make the tools better?

Tim

baseline: spec
<baseline>
spec
for: #common
do: [ 
self setUpExercisesFor: spec.
spec
package: 'ExercismPharo70'; "Pharo override/patch methods"
package: 'ExercismTools' 
with: [ spec requires: #('ExercismPharo70') ];
package: 'ExercismTests'
with: [ spec requires: #('ExercismTools' 'ExercismMocking'), 
self exerciseTestPackageNames ];
package: 'ExercismSystemTests'
with: [ spec requires: #('ExercismTests') ];
package: 'ExercismDev'
with: [ spec requires: #(
'OSProcess' "For shelling out to configlet"
'Ring2' "For mentoring support of shadow browsing"
'ExercismTools' ),  
self exercisePackageNames,
#('Exercism'

'ExercismTests' 
'ExercismSystemTests')];
group: 'default'
with: #('ExercismTools' 'Exercise@Welcome');
group: 'dev'
with: #('ExercismDev’)].

setUpExercisesFor: spec
self class exercisePackageNames, self class exerciseTestPackageNames 
do:
[ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ].

exercisePackageNames
"Answer the list of exercise package names (as we don't yet have proper projects)"

^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')

Reply | Threaded
Open this post in threaded view
|

Re: The baseline complexity of tiny big projects...

Richard O'Keefe
This is not an answer to your question, but it is an observation by someone who was trying all
the exercises.  As a user, it was just working.  Then suddenly, there was a change.  Instead of
a new exercise popping up underneath Exercism, it would appear as Exercise@Foobar.  No big
deal.  What *is* a big deal is that the "submit" menu item disappeared, and the only way I
have found to submit a solution is
 - File Out the class
 - Use the command line to download the exercise
 - Move the filed out class to the exercise directly
 - exercism submit Foobar.st
I had been quite impressed with how smoothly everything went in the UI before.


On Mon, 20 May 2019 at 09:57, Tim Mackinnon <[hidden email]> wrote:
I’m wondering if others might spot a better way of handling this - but with Exercism, I’ve got 100 exercises to manage. An Exercise is a TestCase and 1 or more solution classes (normally 1, but sometimes several). I had initially used Tags to manage this, there was an ExercismExercise package, and then a tag for each exercise. This was quite neat and tidy - however its flawed as it doesn’t allow extension methods on the tags (they live on the parent package - which is problematic as in use, the exercises are loaded one by one from tonel files as the student progresses), it also does let you critique an individual exercise… so essentially they aren’t sub-projects and I was recommended to promote them to proper Packages.

This was all quite trivial to support with tags but now I have to grapple with the BaselineOf for my project (to manage all these exercises in development mode - where you want to load them all, run all their tests, and add to them etc).

As each exercise depends on an ExercismTestCase - I have a single pre-req for each one, and then, in development mode, I have to load all 100 of them. The best I came up with was the following - but its a hell of a lot more complicated than the previous tag solution where effectively the owning package let me do this once (and membership of that package automatically gave a tag this pre-req and containment behaviour).

So instead I have to do the following (and I’m left wondering if I’m missing some easier way). The bold bits are where I’ve tried to do something to try and workaround this - its the array of  packageNames that is a bit distasteful to me, and it feels a lot like I have to express the same information twice - one in the iceberg window to add all these packages, and then again in the method of names, to set the identical pre-req on each of them… I find in this respect, I’m missing Envy developer here?

Anyone have some better suggestions? Or do we need to try and make the tools better?

Tim

baseline: spec
<baseline>
spec
for: #common
do: [ 
self setUpExercisesFor: spec.
spec
package: 'ExercismPharo70'; "Pharo override/patch methods"
package: 'ExercismTools' 
with: [ spec requires: #('ExercismPharo70') ];
package: 'ExercismTests'
with: [ spec requires: #('ExercismTools' 'ExercismMocking'), 
self exerciseTestPackageNames ];
package: 'ExercismSystemTests'
with: [ spec requires: #('ExercismTests') ];
package: 'ExercismDev'
with: [ spec requires: #(
'OSProcess' "For shelling out to configlet"
'Ring2' "For mentoring support of shadow browsing"
'ExercismTools' ),  
self exercisePackageNames,
#('Exercism'

'ExercismTests' 
'ExercismSystemTests')];
group: 'default'
with: #('ExercismTools' 'Exercise@Welcome');
group: 'dev'
with: #('ExercismDev’)].

setUpExercisesFor: spec
self class exercisePackageNames, self class exerciseTestPackageNames 
do:
[ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ].

exercisePackageNames
"Answer the list of exercise package names (as we don't yet have proper projects)"

^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')

Reply | Threaded
Open this post in threaded view
|

Re: The baseline complexity of tiny big projects...

Tim Mackinnon
Hi Richard, there isn’t an easy way to communicate with Exercism users (I’m arranging an email to be sent) but essentially just apply this upgrade

https://github.com/exercism/pharo-smalltalk/blob/master/docs/UPGRADE.md

Sent from my iPhone



Sent from my iPhone
On 20 May 2019, at 04:20, Richard O'Keefe <[hidden email]> wrote:

This is not an answer to your question, but it is an observation by someone who was trying all
the exercises.  As a user, it was just working.  Then suddenly, there was a change.  Instead of
a new exercise popping up underneath Exercism, it would appear as Exercise@Foobar.  No big
deal.  What *is* a big deal is that the "submit" menu item disappeared, and the only way I
have found to submit a solution is
 - File Out the class
 - Use the command line to download the exercise
 - Move the filed out class to the exercise directly
 - exercism submit Foobar.st
I had been quite impressed with how smoothly everything went in the UI before.


On Mon, 20 May 2019 at 09:57, Tim Mackinnon <[hidden email]> wrote:
I’m wondering if others might spot a better way of handling this - but with Exercism, I’ve got 100 exercises to manage. An Exercise is a TestCase and 1 or more solution classes (normally 1, but sometimes several). I had initially used Tags to manage this, there was an ExercismExercise package, and then a tag for each exercise. This was quite neat and tidy - however its flawed as it doesn’t allow extension methods on the tags (they live on the parent package - which is problematic as in use, the exercises are loaded one by one from tonel files as the student progresses), it also does let you critique an individual exercise… so essentially they aren’t sub-projects and I was recommended to promote them to proper Packages.

This was all quite trivial to support with tags but now I have to grapple with the BaselineOf for my project (to manage all these exercises in development mode - where you want to load them all, run all their tests, and add to them etc).

As each exercise depends on an ExercismTestCase - I have a single pre-req for each one, and then, in development mode, I have to load all 100 of them. The best I came up with was the following - but its a hell of a lot more complicated than the previous tag solution where effectively the owning package let me do this once (and membership of that package automatically gave a tag this pre-req and containment behaviour).

So instead I have to do the following (and I’m left wondering if I’m missing some easier way). The bold bits are where I’ve tried to do something to try and workaround this - its the array of  packageNames that is a bit distasteful to me, and it feels a lot like I have to express the same information twice - one in the iceberg window to add all these packages, and then again in the method of names, to set the identical pre-req on each of them… I find in this respect, I’m missing Envy developer here?

Anyone have some better suggestions? Or do we need to try and make the tools better?

Tim

baseline: spec
<baseline>
spec
for: #common
do: [ 
self setUpExercisesFor: spec.
spec
package: 'ExercismPharo70'; "Pharo override/patch methods"
package: 'ExercismTools' 
with: [ spec requires: #('ExercismPharo70') ];
package: 'ExercismTests'
with: [ spec requires: #('ExercismTools' 'ExercismMocking'), 
self exerciseTestPackageNames ];
package: 'ExercismSystemTests'
with: [ spec requires: #('ExercismTests') ];
package: 'ExercismDev'
with: [ spec requires: #(
'OSProcess' "For shelling out to configlet"
'Ring2' "For mentoring support of shadow browsing"
'ExercismTools' ),  
self exercisePackageNames,
#('Exercism'

'ExercismTests' 
'ExercismSystemTests')];
group: 'default'
with: #('ExercismTools' 'Exercise@Welcome');
group: 'dev'
with: #('ExercismDev’)].

setUpExercisesFor: spec
self class exercisePackageNames, self class exerciseTestPackageNames 
do:
[ :name | spec package: name with: [ spec requires: #('ExercismTools') ] ].

exercisePackageNames
"Answer the list of exercise package names (as we don't yet have proper projects)"

^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')