[2018 oracle code one] graph databases

Let’s Make Graph Databases Fun agan with Java
Speaker: Otavo Santana & Elder Moraes
Tomitribe & Oracle

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


Sematics

  • Web 3.0 – More interaction between machines
  • Search JCP. Get JC Penny vs Java Community Process
  • Search Ajax. Get cleaner, technology and soccer team

Relationships

  • Link pieces of data
  • Having metadata on relatioships is useful. (Ex: reason for travel, not just that does travel)

NoSQL (not only SQL)

  • Doesn’t use structure or transactions
  • Five diferent types – key/value, columns, document, graph, hybrid of multiple types
Term Key/value Columns Document Graph
Table Bucket Column Family Collection N/A
Row Key Value pair Column Document Vertex
Column N/a Key/value pair Key/value pair Vertex and edge property

 

  • CAP – consistencyy, availability, fault tolerance
  • Graph – neo4j, infogrpi, sones, hybergraphdb
  • Apache TinkerPop  like JDBC – try to standardize database interaction
    • Can add edge/verfix
    • has()  – like where cause
    • OutE() – edges
    • BothV() – reurn both ends of relationship
    • repeat/times – repeat action mltiple times to go through graph
    • repeat.until – repeat action until condition is true
  • JNoSQL – mapping/communication API. Like  a demo. Maps to Java object

My take: I learned a lot at this session! I really like the comparison of different database types and terms. I also liked the build up of queries and the Noe4J demo

[2018 Oracle Code One] Developer Horror Stories

Development Horror Stories
Speaker: Roberto Cortez & Oleg Selajev

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


Stories

  • Broke filter so showed adult videos
  • Deleted inventory and no backups. Had to re-enter all data manually.
  • Units of measure
  • Emails with invalid address so bounced around for hours
  • Deleting a repository instead of a file
  • Used a magic number and it lived on forever..
  • Underpowered servers ad not enough tuning.
  • Off by one error because didn’t account for leap year
  • Recursive SQL statement caused issue with a very large bill of materials [and we all learned sql can be recursive]. Lesson: filter at as low a level as possible. Went from 100+ years to 75 milliseconds
  • Missig where clause so emailed too many people a scary message
  • Running a performance test on wifi is really slow.
  • Decompiling a jar making a change and recompiling it.
  • Running a performance test on prod. Didn’t tell security. Thought being DDoS’d
  • Deleted database. Thought was backed up vs being made permanently unavailable. Only two days of data entry to restore.
  • Exposing port publicly lets anyone delete your data
  • Ran test against prod. Looked like DOS so autoblocked headquarters. Prevented all reservations. Workaround was to use mobile site since run elsewhere.
  • Running CI on a laptop caused it to disappear when person got fired. It reappeared briefly when machine next booted up.
  • Project’s CM system is putting ode on CD and putting it in a file cabinet. Have software, but not OS or hardware to run it on
  • Added RAM instead of pagination
  • Rebooted prod (vs retired prod) by going to wrong building

They said youl could use a fake name or fake company name if you went up. Most everyone used their real name. It was funny because he kept asking if people used their real name. When I went up, I said I worked for an unnamed bank in NYC. The guy after me said he worked for an unnamed trading company in NYC.

I also liked how he “baseined” how many people would raise their hands by asking eveyone n the room t raise their hands hen he commented that 90% was like 100%

My take: I went to this session last year. It’s mostly stories from the audience which is fun and different. Great topic for lunchtime.

[2018 oracle code one] Bulletproof Java Enterprise Applications

Building Bulletproof Java Enterprise Applications
Speaker: Sebastian Daschner

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


 

Being resilient

  • Don’t crash
  • Prevent faiures from casading
  • Don’t allow actions that are doomed to fail

Timeouts

  • Avoid deadlocks
  • Kill at some point so overall system and continue
  • Especially http and database timeouts.
  • Some libraries default to no timeouts

Retries

  • Immediately retry to avoid temporary failure – but be careful that not putting more load on a failing server
  • Avoid unnecessary error codes
  • Decide how often and how many times to retry

Java EE Extensions

My take: I like that there are actual code examples. I don’t like that the text based slides are in vi (or a screenshot of vi). Such a smal font and tons of wasted whitespace.