markdown: add to track#1060
Conversation
|
A couple things here. 1) I am not entirely sure why this recent build is failing. 2) I realize that I didn't fully read this README.md. This exercise is centered around refactoring a solution to be cleaner and still allow the tests to pass. Does anyone have ideas for how to make my optimal solution better and what things I could do to my solution to make it worse for learners to clean up. A forward and backward direction haha |
|
It seems like the Travis build is failing with the same issue it had in #1004 - I'll restart the build and see what happens! This is very odd, but both of these times have been when new exercises were added... Maybe this is a clue? (Sorry for the request Frida - misclicked! 😱 ) |
|
Hmm... seems to have failed again for the same reasons (those seen in #1004 too). I don't think any of the team have a clear idea of why this happens (but I'd rather not just keep clicking the restart button)! |
There was a problem hiding this comment.
Other than the mysterious case of the failing build, I think this PR overall is looking great!
One small suggestion that I would have is adding the topic refactoring in the config.json, as it is mentioned in the README.md. Feel free to disagree with me though - I'd be interested to hear what you think 🙂
Additionally, your starter implementation will need (very messy) code to perplex the users! 😆
FridaTveit
left a comment
There was a problem hiding this comment.
This is looking really good @bmkiefer :)
I've added some comments, mostly minor things about staying consistent with the code style we use on this track :)
The most important change is probably that as you remarked in your comment this exercise is about refactoring. So you should add a starter implementation with some really messy code that passes the tests :)
| "conditionals", | ||
| "pattern_matching" | ||
| ], | ||
| "unlocked_by": "word-search", |
There was a problem hiding this comment.
Exercises can only be unlocked by a core exercise (see https://github.com/exercism/docs/blob/master/language-tracks/configuration/exercises.md) so it can't be unlocked by word-search, sorry. word-search is unlocked by the core exercise scrabble-score so maybe this exercise could be unlocked by that as well? :)
| class Markdown { | ||
|
|
||
| String parse(String markdown) | ||
| { |
There was a problem hiding this comment.
Please put the opening curly bracket on the line above:
String parse(String markdown) {
That goes for everywhere else in the file as well. That's the most common code style for Java and it would be good to be consistent in every exercise :)
| { | ||
| String lineResult = parseLine(lines[i]); | ||
|
|
||
| if(lineResult.matches(".*(<li>).*") && !activeList){ |
There was a problem hiding this comment.
There should be a space before the opening curly bracket here :)
| result.append("</ul>"); | ||
| result.append(lineResult); | ||
| } | ||
| else { |
There was a problem hiding this comment.
Please put the else on the line above to be consistent with the code style in other exercises :)
| return parse_(parse__(markdown)); | ||
| } | ||
|
|
||
| private String parse_(String markdown) |
There was a problem hiding this comment.
Using underscores in method names can make them hard to read. I would recommend using words instead, e.g. parseUnderscore and parseDoubleUnderscore :)
| String input = "This will _be_ __mixed__"; | ||
| String expected = "<p>This will <em>be</em> <strong>mixed</strong></p>"; | ||
|
|
||
| assertEquals(expected, markdown.parse(input) ); |
There was a problem hiding this comment.
There shouldn't be any whitespace before the last closing bracket :)
|
@stkent @Smarticles101 any ideas why the build failed? |
|
I'm going to push a change real quick. I think this could fix it this Except then again it only happens sometimes, so I'm not sure why it's happening |
|
Hmm that does look very similar to what we're experiencing. Not sure why it only happens sometimes (unless it is to do with new exercises), but I'm excited to see if this works @Smarticles101 👍 |
|
Still the same old... 😱 |
|
And once more 😢 |
|
Not really sure why it's still failing... perhaps we can summon someone more familiar with bash |
|
It looks like it thinks |
|
Oh you're right @FridaTveit I see now |
|
Great, thanks @Smarticles101! Hopefully it'll work this time :) |
|
It's going to work this time but for a different reason... It's hit GitHub's API rate limit lol #772 |
|
Awesome feedback guys, thank you! Also, good to know why that build was breaking. List of code issues that I added to the sample solution. let me know what you want to see or not.
Making chaos was fun lol Might be worth keeping these as notes for mentors somehow or maybe included as hints? |
|
Hi @bmkiefer - I am not sure what the others think about keeping track of this, but I think it could be a good idea to take that list and stick it into the However, I am sure if this is not the ideal place to keep those notes then someone else might have a better idea! 🙂 |
FridaTveit
left a comment
There was a problem hiding this comment.
Nice! This is looking great!
As for where to put the hints, I definitely think it would be useful to have them somewhere. I don't think putting it in .meta/hints.md would be correct because I think that gets appended onto the readme. Is that right @stkent?
Also, the build is failing for the same reason as before, it appears we haven't quite managed to fix it yet. I think it would be a good idea to try and fix that in a separate PR to avoid adding too much unrelated noise to this PR. What do you think @Smarticles101, @sjwarner-bp, @stkent?
|
Ah - I didn't know these got appended to README.md @FridaTveit - thanks for letting me know that 🙂 In that case I'd suggest that they should be stored somewhere else, but probably in that As for CI fixes, I'd definitely open an issue and start fixes in a new PR to avoid noise - |
891a8f8 to
77c6a55
Compare
|
Okay, what would you like me to do with that CI fix commit? I am confident this fixes the issue with the CI, but there may be a better place in the scripts to fix it, if anyone has an opinion. This bug occurs when the settings.gradle file changes, an exercise changes, and it doesnt hit the API limit on GitHub. If the API limit is hit, it doesn't refer to the change set when running the test suite, it just runs all the tests. It basically thinks that settings.gradle is another exercise and has to be ignored when its walking through exercises in order for the tests to complete correctly. It probably could be filtered out when fetching the exercises from Github and not when you are walking through them. I didn't like moving it into another PR because you almost need to new exercise implemented for bug to show itself because thats the only time that you are changing the settings.gradle file. |
|
Thanks for looking into that @bmkiefer :) I've been fixing that in a separate PR (#1064) since it doesn't relate to adding this new exercise. Just changing something in settings.gradle should cause the bug to show itself I think :) Feel free to review/suggest changes to that PR. I think all the CI changes that have been added to this PR should be reverted since they aren't related to this PR. It's always best to only deal with one issue in a PR. Otherwise it become hard to review and it makes the history messy. Are you okay with that? Sorry for the confusion and adding lots of noise and additional problems to your PR! :) |
|
Yep, that is cool. I will revert the CI changes. Good teamwork! |
7b39709 to
77c6a55
Compare
|
Great work everyone! That is one mystery fixed 🙂 In regards to this PR @bmkiefer, I've seen you've undone the CI changes! That's great - I think this whole thing is ready to merge when we have added your list about all the code issues you have written! |
|
The PR with the fix has been merged now so if you merge/rebase on master then the build should hopefully be okay (fingers crossed!) :) |
|
I need to undo the earlier ones yet and we will have to do a squash commit here as well when this is merged given the reverts will be a little messy. |
|
Agreed, squash and merge should tidy it up :) |
|
Okay, now all the CI work done here is reverted! Woo |
trying something else
e7fe054 to
ac9cb0e
Compare
|
Weird, it gave the commits new hashes after I rebased the change that @FridaTveit made on master. |
FridaTveit
left a comment
There was a problem hiding this comment.
This looks great! Thanks for dealing with all of that @bmkiefer :)
And yes, rebasing does change the hashes :)
|
Great work, all! |
Agreed, notes for |
|
Given the notes that I previously wrote only helps the mentors of track, do we even want to keep them in the repo? The problem specification somewhat outlines that the learners should be identifying the changes that they made to the code. Either way, It's worth setting a precedent given there is a couple other refactoring exercises that haven't been implemented. If we want to forego using them, then we can merge this. |
|
I agree that since these are really notes for mentors, it doesn't really make sense for them to be kept in the repo. So I'm happy to merge this as is :) What do you think @exercism/java? |
|
If that is what you think @FridaTveit I am happy to agree! |
|
+1 we should figure out where to put mentoring resources (or wait for nextercism to drive a discussion along those lines) before including them. |
I implemented the markdown exercise because the java track did not yet have it. I am unsure where I should put this in the curriculum. I picked after word search because markdown parsing seemed like a similar skill set, but I am open to change it.
Reviewer Resources:
Track Policies