toastmasters pathways – how to see what your members are up to

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

November 2018
M T W T F S S
« Oct    
 1234
567891011
12131415161718
19202122232425
2627282930  

Past Posts

Java/Java EE

JDBC

Other

toastmasters pathways – how to see what your members are up to

November 4th, 2018 by Jeanne Boyarsky

In Pathways, three Toastmasters officers are able to access Base Camp Manager. They can view individual progress. For example, this bar chart shows how many members my club has currently working on level 2. (If you don’t see anything in your bar chart, refresh.)

I knew you could click the little arrow and view details (in a browser) or export to Excel to see which members are on which paths.

However, I didn’t realize you could tell how many projects they did within that level until yesterday. A big thanks to Cambria Heights Toastmasters for saying “what’s that” when I was demoing.

 

When you log in as a member, you see two percentages:

  1. The percentage complete within a level.
  2. The percentage complete within a path (aka across all five levels)

What do the percentages mean? (If you don’t like math, skip to the table at the end)

Ok, so what does this mean? Suppose a member has completed the Icebreaker and Evaluation/Feedback projects in level 1. This member has two projects remaining in level 1 (Research/Presenting and Level Completion.)

Therefore the member is 50% done with level 1. The member is also 10% done with the path. (Completing the full level would mean being 20% done with the path since one of five levels would be complete. Since the member completed half of level 1, the member completed half of 20%. Which means the member is 10% done with the path.)

Let’s try another example

In the screenshot above, we have three members at 20% done with the path. These members completed level 1 but did not complete any level 2 projects. We also have one member 25% done with the path. This member completed one level 2 project. (Remember 20% means completed level 1 and 40% means completed level 2.)

Can i just have a reference without doing math?

Sure

 

 

Percentage What it means
0% Signed up for a path, but didn’t do the icebreaker yet
5% Completed the icebreaker
10% Completed two projects in level 1
15% Completed all the projects in level 1 but needs to submit the level completion (or have it approved)
20% Completed level 1, but hasn’t yet done any projects in level 2
25% Completed one level 2 project
30% Completed two level 2 projects
35% Completed all level 2 projects but needs to submit the level completion (or have it approved)
40% Completed level 2, but hasn’t yet done any projects in level 3
45% Completed one level 3 project
50% Completed two level 3 projects
55% Completed all level 3 projects but needs to submit the level completion (or have it approved)
60% Completed level 3, but hasn’t yet done any projects in level 4
66% Completed one level 4 project
73% Completed all level 4 projects but needs to submit the level completion (or have it approved)
80% Completed level 4, but hasn’t yet done any projects in level 5
85% Completed one level 5 project
90% Completed two level 5 projects
95% Completed all level 5 projects but needs to submit the level completion (or have it approved)
100% Completed level 5; path complete!

five hours of real coding in Visual Studio Code

November 4th, 2018 by Jeanne Boyarsky

I tried to code for real in Visual Studio Code for the first time. This means not just dealing with my first impressions, but actually trying to get something done. I spent five hours coding today. The project I was working on uses Maven, Selenium and JUnit 5.

I tried to *only* use VS Code for the five hours of coding I did today. Learning any new tool is frustrating. I didn’t complete the development task I wanted to. But I made a decent amount of progress. And more importantly, I have a better understanding of the VS Code environment.

What I re-learned

I learned these when I was playing last time. But this time, I used them a bunch.

  • Shift Command/Windows P – Lets you type in the name of what you want to do. Useful when you don’t know the keyboard shortcuts or location of anything! I used it a lot for organize imports!
  • F12 – drill down into a class

What I learned for the first time

  • F2 – renames a method
  • The left explorer view has a “Maven Projects” section. This provides a visual way to run Maven clean/install/etc. it also provides a visual way to run effective pom. Or at least it did until I disabled the Maven integration. See the “challenges” section for why.

What I liked

  • Running a junit test is easy. Click “run test” over the class name or method name. This causes the test to run and a green (or red) status to appear in the bottom left line with how it went.
  • A green check or red x also appears next to each test method which you can click to see the test result details.
  • Extract to method is easy. Just highlight the code and click the lightbulb.
  • The git integration is good. It is clear on how to pull/push/commit/stash
  • Typing code was relatively easy.

“Challenges”

  • F2 does not rename a class completely. It does rename the “public class” line. But it doesn’t rename the file. There was a github issue logged about this in August. It was closed because it was going to be resolved “soon”, but still seems to be a problem.
  • JUnit 5 tests in classes that end with *IT.java run normally but report as if they were skipped. This means integration is partial. If you open the test class, the green check or red x are correct. And the test explorer recognizes integration tests as tests. But the bottom bar status and test report show as skipped. I had to temporarily rename my test to *Test.java and name it back before committing for this to be usable. I reported this as an issue in the vscode-java-test project
  • There doesn’t appear to be an easy way to make the editor (the part where you type code) full screen. You can choose the command “Maximize editor group and hide sidebar”, but the problems/terminal/etc group is still at the bottom along with some visual clutter on the right. This means you actually have to drag stuff around. In Eclipse, you just double click the “title” and get full screen. More importantly, in Eclipse you double click again to get your original view back. This was requested back in 2016 so I doubt it will be added.
  • Printing something in JUnit doesn’t play well with the Maven integration. Seriously, even if you remember to switch the output tab to “test output”, nothing gets output. I quickly learned that I wasn’t the only one with this problem. It was also logged as a defect this month and sounds like it is being worked on. In the meantime, I disabled the Maven plugin. This isn’t terribly inconvenient because of the Terminal tab. I can still run a Maven build right from my editor.
  • You have to create packages and classes “manually.” This is annoying from deeply nested packages. It is also annoying to have to type the package declaration when creating a new class. This is because VS Code has the concept of folders/files vs packages/classes

What I had to fall back to Eclipse for

There were two tasks where I decided to use Eclipse rather than VS Code:

  1. I needed to paste a very long string. Eclipse adds the line breaks and string concatenation to make this elegant. VS Code does not. I could have spent 15 minutes doing it by hand, but I let Eclipse do it for me.
  2. Eclipse is really good at showing all the differences visually between two Strings in an assertion. (See #1 for my long string.) I could have read the text assertion to see the differences. But again, Eclipse is just so good at this.

converting word to markdown

October 27th, 2018 by Jeanne Boyarsky

Scott and I used Microsoft Word for our Hands On Lab at Oracle Code One. This worked “mostly” fine. The quotes are because we had a one merge conflict when writing the instructions.

At the conference, an attendee (Barry Evans) said he had some improvements to the docs and he’d submit a pull request. Less than useful in Word so I asked him to email me with change tracking. i thought better of that and decided to convert to Markdown.

It wasn’t as bad as I thought:

  1. First, I used the Word to Markdown converter to do a first level pass
  2. Then I manually split it into a page per step (cut/paste) and changed the table of contents to links.
  3. Next, I converted the images to local ones in the repo.
  4. Finally, I did cleanup on code that didn’t format right, lists that were broken and using better code tags.

I used Visual Studio Code as the markdown editor. (I’ve been trying to get more comfortable with VS Code). I learned:

  • Having the markdown file in the left pane and a split view with the preview is nice. They even stay in sync with content/paging.
  • Command up/down goes to the top/bottom of the doc.
  • Home/End goes to the beginning/end of a line.
  • You can test markdown links directly in the preview editor.
  • The preview editor shows images so I could easily spot typos.

I tagged the repo version with the Word doc in case I ever want to go back to what it looked like.