DevNexus 2019 – Containing the Cloud – Wes Widner

See the table of contents for my other blog posts from the conference

@kai5263499

Containers

  • Represent complexity
  • lots of components
  • notes help manage complexity – write down what doing
  • were not designed to be secure. Were designed for developers to have a feel of a greenfield system
  • just a set of processses
  • developers and ops have different goals. Need different images for debugging vs prod

Tips

  • Log and audit what is in the images. Logging smokes out bad practices. Can’t prevent password, but can catch it at build time
  • Prod image should come from CI/CD pipeline
  • Add forensics info to labels. Ex: git hash. Pretend the cloud is down. Can you explain what is in your image
  • Scan image regularly. The base image will become vunlerable over time. Scan hashes and layers of image
  • Build own scratch image or ami so know what is in it. This is hard, but then you know what is in it
  • Monitor what running to ensure what you intend
  • Config as code
  • Use read only mode in container where possible. Hard to break the container
  • Can tag so only data from specific pods can send certain data. Emerging tech. No standard yet
  • Can taint workers and only certain pods can run

Antipatterns

  • Allowing a broad set of system calls. Makes hard to find atypical patterns. Also broadens attack surface
  • Hypervisor shims – limit what can do
  • Chaos engineering – keeps you honest. A pod running for months and behaves differently on next start is hard to track down.

Cloud maturity

  • Access contol which can push
  • execution logs
  • images from a build system
  • version controk docker configs
  • tagged packets from pods and continuous image scanning

Links: https://www.selikoff.net/2019/03/07/devnexus-2019-containing-the-cloud-wes-widner/

My take

Lots of information. I learned a lot. I also realize how much I’ve forgotten about Kubernettes since i last poked it.

DevNexus 2019 – Mixed Paradigms – Method to the Madness Keynote- Venkat Subramaniam

See the table of contents for my other blog posts from the conference

@venkat_s

We are problem solvers

Programming languages

  • For communication
  • Expressive and fluent code
  • Uses about 15 languages. Not fluent in any of theM
  • Quadrants – static vs dynamic. Strong and weak typing. Ruby gives a lot of warnings because strongly typed.

“All problems in computer science can be solved by another level of indirection” -David Wheeler

  • procedural – pointers/references
  • object oriented – polymorphism
  • functional – lambdas

Imperative vs declarative

  • more important than OO vs functional.
  • Functional programming is declarative programming with higher order functions
  • imperative is easy to write but harder to read
  • functional is easy to read. Harder to write partly because we spent so many years writing in imperative style
  • Imperative gets harder as problem gets more complex
  • need to focus on both imperative and functional. Hybrid languages
  • lazy execution does not survive mutability. Dont work around compiler errors!

Future – will care more about async than running in parallel. Want to be able to make async without changing structure of code. Kotlin and JavaScript do this now. Java will in a few years with fibers

Changing mind is important. Not whimsickly. But to make progress

Wisdom is realizing there are no absolutes

My take

Great start to the day. I like how so many languages were compared. With humor too. I like how Venkat does a mix of slides and live coding/notes. I really like that he acknowleges that it is ok for things to feel hard

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!