Oracle Code NYC 2018 – live blog table of contents

Today, I’m attending Oracle Code New York. As usual, here’s my live blog post summarizing the sessions I went to.

Good weather related intro. He took a poll on who had hot water this morning (most people) and who had a cancelled flight (some speakers.)

Sessions

DevOps @ Scale – Oracle Code NYC live blog

Title: DevOps at Scale; Greek Tragedy in Three Acts
Speakers: Baruch Sadogursky (JFrog), Alena Prokharchyk (Rancher Inc)

See my live blog table of contents from Oracle Cloud

Slides: https://jfrog.com/shownotes/

General notes

  • DevOps – intersection of dev + ops + qa
  • DevOps – intersection of tech, process and people

Reactive ops

  • Imaginary three person company  Eager to learn
  • Buzzwords – serverless, no ops. Both sound like don’t need to do anything. But…
  • Basic tools all in cloud – jira, github, travis ci, oracle cloud
  • Challenge: many logs because of microservices
  • Challenge: time zone of cloud provider vs your time zone
  • Two years ago “the internet broke” – NPM registry took down a dependency (left pad)

Scale

  • Hire ops person
  • Grow staff
  • Add Scrum
  • Add exploratory testing [surprised hardly anyone knew what this was; it’s just trying stuff an testing]
  • Developer on call
  • More tools – Confluence, Artifactory, Sumologic (analyze logs; like Splunk), Pingdom (monitoring)

More maturity

  • Root cause analysis  – includes syptoms, what happened to lead up to problem, next steps so can prevent happening again
  • Want to have new problems; not the same one happening ove and over
  • Retrospective
  • Importance of disclosure – ex:  gitlab lost 6 hours of data last year. Were forgiven because so transparent

Perfect storm

  • More scale – 5 ops people, 1 performance engineer, 74 deveopers, chief architect, customer success team (bridge between developers and customers like developer on call but a bunch of them that know system)
  • SAFE – scrum at scale
  • System testing
  • Ops team – two ways to do devops 1) hire brighest engineers in world (like Netlfix) where know dev and ops perfectly. Rare to be able to do this. 2) Specializations exist. The ops people set up everything and then evangelize it so devops can happen. Often called the tools team.
  • Escalation path: SME and manager on call. The manager can work on relationships. Also makes fixing faster since know will be escalated to management.
  • SOC II – regulation/audit for service organization. Requires separation of controls so people who write code cannot deploy to prod. Can’t write code and control system that deploys it. Interesting. Ex: the tooling team doesn’t allow skipping integration tests. So the people writing apps don’t control the deployment pipeline
  • Problem: Need to find out if have any code that uses a certai license. Lots of work to do manually. [easy if you have IQServer! Or a JFrog product; I didn’t catch which one]
  • Problem: Guessing how much to spend on servers for next year. Guess. Nobody will shut down server if need more resources
  • Problem: Will it scale. Guess. False confidence. It didn’t. Greek tragedy; everyone dies.

To avoid problems

  • Performance/scalability testing
  • License and seucrity management
  • Code in monitoring. Ex: docker. By extending base image, get things built in.
  • Tools support process – JFrog commercial :).
  • Showed pie chart of where time goes. Interesting way of looking at fragmentation. The pie hart had a lot of slices!
  • Can’t have a non-functional definition of done
  • Majority of industry is in fire alarm/reactive improvement mode. But still strive to proactive improvement. It is hard and expensive.

Takeways:

  •  must be responsible for what you build. “You build it; you own it”
  • Data is the key. Even if it is in Excel.
  • Pain in instructional. Results in improvements. Continuous improvement. If something hurts, do it more often.

My take

This was a fun start. It tells a great entertaining story and includes information. Watch the video. My notes nor the slides do it justice!

DevNexus 2018 – Bulletproofing your foot for Kotlin

Title: Bulletproofing your foot for Kotlin
Speakers: Enrique Zamudio

Slides (from the Devoxx version of this talk)

For more blog posts, see the DevNexus 2018 live blogging table of contents


About Kotlin

  • Created by JetBrains (makers of IntelliJ)
  • Static typing
  • JVM language
  • Can run on front end or back end
  • Good for Android

Data classes

data class Person(val name:String val birthDate:Date)
  • No need to write getters/setters.
  • toString() and equals() automatically added.
  • However hashCode() is not automatically added.

Destructuring

val p = Person("John", now)
val (n, f) = p
  • Like Scala
  • Stores each field in a variable
  • Similarly can do for ((k,v) in map) when iterating through a map

Functions

fun foo() {}

Takes no params, calls a function and returns Unit (void)

fun bar(f:() -> (Unit)) = f())

Method reference like in Java. Since a top level function, nothing before the ::

bar(::foo)

Passing a lambda directly to a function:

bar ( { println() })

Runs on Java 7

String interpolation

println "Name: $n"

Works like in Groovy

Type inference

Immutable (final) String:

val p = "hello"

Mutable:

var q = "hi"

Recommend specifying type for method so faster.

Smart casts

 val p:Any = "string"
if p is String) {
  println(p.toUppercase())
}
  • Any is a root class
  • Once you check the type, you can use it rather than having to cast.
  • Can still write explicit cast println((p as String).toUpperCase()). Stupid cast?

Typesafe null

var p:String? = "hello"
p = null
if (p != null) {foo(x)}
  • Want to catch errors at compile time
  • If just write var, can’t assign null.
  • Have to explicitly say it is ok by making it an “optional string”
  • Cannot pass an optional string to a method that takes a regular string [cool!]
  • Write guard to check if not null. That is a smart cast to turn String? into String so can call method that takes String
  • ?. returns null if it is null vs a runtime exception. So safe way is to write s?.length
  • The elvis operator ?: from Groovy is also supported.
  • BEWARE: There’s also a kill switch. Writing foo(p!!) you are forcing Kotlin to pass the String? into String without the check. It is a way to say you know what you are doing. Then you get a runtime error if it is null instead of a compiler error.

Operator overloading

class Foo(val x:Int) {
  operator fun plus(o:Foo) = Foo(o.x=x)
}
  • Can only overload simple operators – math operators and index (square square brackets)
  • BEWARE: only way to tell if can use overloading is to look at the class code (or release notes). It’s not in the docs.

Extension methods

fun Person.debug() { println("") {
  • Can add methods to a class even if don’t have the source code.
  • BEWARE: don’t use extension operators. Someone looking at the class won’t know they are there. Not obvious where to look for the code.

Non local returns

  • BEWARE: do not use.
  • Allows writing a return within a closure. In Groovy, it would return from the closure. In Kotlin, it returns from the whole method.
  • Can write return@forEach to return from just the closure. But yech.

My take

This was my first exposure to Kotlin. Some of the features are really cool!