converting word to markdown

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.

 

[2018 oracle code one] developing java applications with microsoft visual studio code

Developing Java Applications with Visual Studio Code
Speaker: Fred Bricon
@fbricon

For more blog posts, see The Oracle Code One table of contents


VS Code

  • Lightweight extensible “source code editor”
  • Open source
  • Developed by Microsoft, but vibrant community
  • Led by Erich Gamma (Gang of Four and one of the original authors of Eclipse)

Language Server Protocol

  • language specific smarts
  • standard protocol to minimize effort to support multiple development tools/languages
  • open source protocol
  • development led by microsoft
  • JSON RPC 2.0 messages
  • tool opens/edits docs/displays errors. language server initializes languages tools/identify compilation error/etc.

Eclipse JDT.LS

  • Implemented language server for Java in Java.
  • Running language server launches headless Eclipse behinds scenes
  • Adds custom commands
  • Extensible through OSGi bundles

Vs Code – Java

  • RedHat developed thin wrapper.
  • Launched late 2016
  • Updates about twice a month
  • Half a million extensions
  • Other Java tools
    • debugger (from MS)
    • test runner (from MS)
    • Fabric8 analytics
    • java decompiler
    • lombok support
    • checkstyle
    • maven
    • dependency analytics – new plugin to flag components with CVEs. Plugin not completely ready. Not all CVEs loaded yet. Just something to play with at this point.
  • VS Code LiveShare – plugin where can share content of workspace with up to 50 people. They can even set breakpoints in your workspace.

Next steps

  • Better refactoring support
  • Quick fixes from problems view
  • Huge backlog; more improvements soon

Demo

Note: I have a bunch of notes to myself of things I want to try. I also want to ask Thomas for a copy of his workspace preferences file. It seems more reasonable than the defaults.

  • Autocompletion
  • Lightbulb with option to run/debug – have to turn on code lens in workspace settings
  • Click triangle in bottom left corner to see problems/output/debug console view at bottom
  • F2 = rename variable [command F2 on Mac]
  • Debugger on left view on screen
  • Showed hiding . files . Preference > settings. Edit workspace settings to control Ant style patterns on what see. (Edit settings as json)
  • New Java Dependencies plugin. Came out recently. Can see Maven dependencies
  • Command shift o – see outline in file [want to try; didn’t work on first shot]
  • command p – list all files in project
  • Command click – navigate into class [want to try; didn’t work on first shot]
  • Organize imports – alt shift o
  • Saving gives instant feedback – need to turn on
  • Run test runner. Code lens shows red/green test status in class itself.
  • Can type “get” and getters are suggested (vs typing them in)
  • Showed changing code while app is running
  • Using a bad dependency gives CVE error in problems view

My take: FRC (FIRST Robotics Competition) teams are using VS Code this year. I’ve learned a little but am nowhere near fluent. So was really looking forward to the demo. Plus hearing the story of how the plugins came to be is interesting. But seeing someone use it who is comfortable with the tool is even more valuable.

[2018 oracle code one] JWT’s suck

JWTs Suck
Speaker: Randall Degges
@rdegges

For more blog posts, see The Oracle Code One table of contents


JWT (JSON Web Token)

  • pronounced “jot”
  • JSON data
  • cryptographically signed
  • Not encrypted most of the time
  • Prove that some JSON data can be trusted
  • Common use case: Website generates JWT after validating credentials. Website then sends JWT to browser and browser stores in localStorage. Then browser sends to website for subsequent requests.
  • There are stateless and stateful JWT. The later maps to a session id. People don’t use stateful JWTs.
  • 2012 – Spec came out
  • 2014 – began gaining adoption/marketing
  • seven of the first 10 hits on jwt are marketing pitches

Cookies

  • JWT stores session id as JSON blob. In cookie, just a string.
  • Session cookies are underappreciated
  • Use HttpOnly flag
  • Use SameSite-strict flag
  • Use secure flag
  • Browser sends cookie header to website

HTML Local Storage

  • JavaScript only accessible
  • Store key value pairs in browser

Myths about JWTs

  • JWTs are easier to use – JWTs require additional tools, libraries and knowledge to function. Developer effort. Vs session cookies which are built into all web frameworks.
  • JWTs are more flexible – Cookies can store one piece of data per cookie or serialize into a cookie. JWT has claims which are certain pieces of data that always included – ex: when token created/expires. Cookie actually expires at expiration times. Tokens don’t disappear automatically
  • JWTs are more secure – Cryptographically signed and can be encrypted. However, actually using the encryption feature is rare. The spec is complicated and libraries vary in support. Also multiple vulnerabilities in past two years.
  • JWTs prevent CSRF – Cookies are susceptible to CSRF because sent to server automatically. Local storage is safe from CSRF because developer needs to write JavaScript to send the data. However, you are now vulnerable to XSS which is worse. CSRF is far easier to fix than XSS because most websites link to Google Analytics, third party jquery, etc. OWASP recommends not storing any sensitive information in local storage.
  • JWTs are better for cross domain authentication – Good when create temporary token that lasts for 10 seconds. It is used between the login service and your app.
  • JWTs are more efficient than cookies – 179 bytes. If just sign the id part, is 64 bytes. Difference even greater when add data.
  • JWTS are easy to revoke – Could change signing key of application, but that also logs out the other users. Alternatively, use the revocation list pattern so can invalidate one. But now you’ve introduced state/database/cache.

Better use cases for JWT

  • Short duration (one minute or less) for one time use
  • ex: downloading a file, reseting a password

My take: I hadn’t heard of JWTs. So I learned a lot! It was fun hearing the audience questions/comments/statements was fun. That said, I need to read up on the topic to see the other point of view.