peel/forgetting-java.md

## forgetting-java.md

      
    Raw
  

              forgetting-java.md
            
          
    slidenumbers: true
footer: @peel #tricityjug
^ Abstract:
Java is old. Java is verbose. Java is ugly. Java is mocked and ridiculed but everyone and their dog. Hell, Java is dead. Well it's not but I'm preaching to the choir. Or am I? However convenient to say so, it's not exclusively Oracle to blame for Java's current state of the art. Java developers are guilty of laziness (the wrong kind), not questioning the tools they use (wrong again), following patterns (pretty much the right kind) they believe are blessed upon them yadda yadda yadda. Yet the communities around languages we find to be even lesser than Java offer world of a difference. The talk shows the tools, experiences and mindset we lack in the Java world. The virtues present elsewhere but needed here for Java to wipe the "enterprise-grade" solutions off the face of the world. Let's do this people. Let's do the right thing and get rid of the "enterprise" Java developers.
^ Contents:
PART I: Is Java Dead?
Tries to find the right angle at why Java is seen dead or dying.
Addresses often mentioned language quality as well as social arguments.
States that Java is a dying language not because of it's features but the social aspect that puts off innovative programming community members from working with Java and choose another language instead.
Sums up the topic with a claim that Java unlike some other languages/tools does not enable 'developer happiness' while writing code.
PART II: The Sins
States several 'sins' that we the Java developers often make. Sins that drive Java language down the line.
Compares the usual Java developer choices with a range of choices available to developers in other languages/communties.

Ignorance
States that we are way too lazy and often choose to ignore anything outside of what is comfortable and well known to us. Things that would come in handy if we had used them. Shell and command line tools are the first thing to notice.
Compares usual way shell is used by Java developers and notes why Java developers, unlike Go and Ruby devs, don't usual build small, handly CLI tools. Shows several useful tools that might be convenient to use.
Language version management
Java community is reluctant of upgrading both Java as well as dependencies. This no Jav
Distribution
We tend to ignore the way that we distribute and cache software versions. The part shows several approaches how distribution is handled. Hints the non-usual approaches that work better than usual.
Targets app servers as legacy software.
Dev w/o Ops
Describes tools, practices and facts from operations world that are usually ignored by Java devs.
Mentions continuous delivery and stability patterns.
Logging
Java devs tend to focus on using logging frameworks rather than thinking on how and why to log. And eventually how to make use of the logs.
Easy not Simple
Choosing the frameworks, tools and solutions that are easy not simple and elegant:

Build tools - addresses build tools in Java that haven't been changed for years and feel awkward when used. Shows the world of Ruby, Elixir.
Dependency management - tackles dependency management that in Java unlike other languages feels equally awkward as build scripts; shows newer approaches chosen by Clojure and Ruby
Web frameworks - Java web frameworks may be split in two: legacy (Struts, Spring MVC with JSP/JSF) and less legacy (Ratpack, JHipster, Dropwizard) all in all there is no real comparison with other solutions delivered in form of for instance Phoenix Framework
False idols - tackles the use of design patterns (especially GOF) even in Java 8 functional solutions in place
FINALE
Summs up the presentation.Leaves the attendee with a message to 'have fun' while programming.


[fit] Forgetting JAVA


[fit] Why Java Should Die in Flames and Take its Developers Along

[fit]

[fit] Piotr Limanowski

[fit] @peel


#[fit] PART I
##[fit] IS JAVA DEAD?

Nope.


Java might be


dy•ing (dīˈĭng)

v.  Present participle of die.
adj.  About to die: dying language.


#dying by
"verbosity"
"poor type inference"
"weak type system"
"low-level support for concurrency/parallelism"
"dependency hell"
"OSS mostly comes from android & enterprises"
^ Russel Winder - devoxx


If programming is going to be the thing I spend my time on,
it damn well better be awesome.
-- David Heinemeier Hansen

^ Venkat Subramaniam on evolution of programming languages

But, really...


Is Java dead?

^ do you know there is a COBOL magazine

[fit] COBOL


[fit] TO


[fit] OTHER LANGUAGES


[fit] COBOL TO JAVA

TRANSPILER


^they want to write the code and have it run the same way 50 years later, literally, truly
^ even when there are no programmers

Why?


Java does not change.

^hence will run the old software for another 50 years no changes

Why not C then?

^C changes depending on 64/32 architecture

[fit] source & binary compatible

[fit] since


[fit] FOREVER

^ horrible bugs

type erasure

^type erasure is a stupid bug to have in code
^type erasure wouldn't be there if the language was implemented two years later

[fit] let's change


attract those crazy, eager, young, passionate, enthusiastic
-- someone, somewhere, someday


Y U NO

CHANGE?


^ RxJava
^ Android/Scala community

#missing: happiness

^ruby community

PROFFESSIONAL

SINNERS

^ stockholm syndrome

PROFFESSIONAL ENTERPRISE

SINNERS


val virtues = "crazy" ::
              "eager" ::
              "young" ::
              "passionate" ::
              "enthusiastic" ::
              "happy"
              Nil

virtues.dropWhile(wat)

def wat = {

^ ruby values
^ python code of conduct

#[fit] PART II
##[fit] THE SINS

[fit] IGNORANCE

^ what do we ignore?
^ why?

#[fit] shell
^ide lock in
^recruitment

multiplexer tmux

shell ZSH w/ prezto

editor spacemacs

###sane defaults: skwp/dotfiles
^Rakefile
^ skwp = Yan Pritzker


test feedback

REPL


REPL driven development


experiment in repl
write test
[opt] how to make test pass in repl?
implement
refactor


^Conrad Irwin - REPL driven development

#gui git client?

then how about...


smart prompt

multiple sessions

session preserving

quick file changes

project generation

finding files

| operator

microservices

^ James Lewis - microservices

#CLI ALL THE THINGS


#Java can't into shell. Properly.

Grass is always greener: codegangsta/cli


package main

import (
  "os"
  "github.com/codegangsta/cli" //THIS
)

func main() {
  app := cli.NewApp()
  app.Name = "greet"
  app.Usage = "fight the loneliness!"
  app.Flags = []cli.Flag {
    cli.StringFlag{
      Name: "lang",
      Value: "english",
      Usage: "language for the greeting",
    },
  }
  app.Action = func(c *cli.Context) {
    name := "someone"
    if len(c.Args()) > 0 {
      name = c.Args()[0]
    }
    if c.String("lang") == "spanish" {
      println("Hola", name)
    } else {
      println("Hello", name)
    }
  }

  app.Run(os.Args)
}
^ cross-os
^ not the prettiest tho
^ bash completion
^ cross-os

#Commander.rb
#Shell
#scopt.scala
^ not a big fan of scopt tho

#[fit] version management
^ ignorance of java

$ rvm install 2.2.3
$ rvm use 2.2.3
$ cd ..
$ rvm install 2.2.4
$ rvm use 2.2.0 --default

#jenv.io

#[fit] distribution
^ ignorance of

#OS packages
#self-contained fatjars
#containers
^ torsten curdt - jdeb
^ there is nothing about deployaple wars/ears they are bad

#App Servers are DEAD

^ multiple apps in one for memory/processor

Server version dependency?


Server monitoring?

^JMX - 2 way API for monitoring; SNMP integration; Jolokia JMX - REST w/ JSON
^ Log files/ELK
^ servers make monitoring complex

Call home

^ let know the app works

Dead man's switch

^ turn off the app when misbehaves

Status page


[fit] DEV W/O OPS


##[fit] snowflake dev
^every machine is a bit different
^configuration in IDE

##[fit] every hour is Ship It hour


Continuous Delivery
-- Humble, Jez; Farley, David, Addison-Wesley, 2011


Release It!
-- Nygard, Michael, Pragmatic Publishing, 2007


#[fit] 2007

#bulkheading


#circuit breakers


#[fit] Logging (frameworks)


Timestamp | Status | Entity Id | What happened | What did user do

^ single line

---

# [fit] EASY
# [fit] NOT
# [fit] SIMPLE
^ not upgrading tools
^łatwe nie proste

---

#[fit] Build tools

---

**Maven**

```xml
      <project xmlns="http://maven.apache.org/POM/4.0.0" ...>
                      ...
      </project>


Maven
17    <project xmlns="http://maven.apache.org/POM/4.0.0" ...>
                      ...
1565  </project>

[fit] 1565


😵
Separation?

^ will not say which project
^ one I contributed to
^ OSS

Gradle
1     apply plugin: 'java'

#GREAT SUCCESS


$ ls
  gradlew/
  src/
  build.gradle
  gradle.properties
  gradlew
  gradlew.bat
  settings.gradle

Ant
25    <project name="Lang" default="compile" basedir=".">
                      ...
233   </project>
^ James Lewis
^ priperietary CMS
^ scriptable tasks
^ can fit into dev mind


If I knew then what I know now, I would have tried using a real
scripting language
-- James Duncan Davidson (creator of Ant)

^ why not... Java?

#[fit]XML


Grass is always greener: Rake

^ or leiningen (you can use it with java too!)

rails/rails

#[fit]67 lines
#of code

task default: %w[test]

task :test do
  ruby "test/unittest.rb"
end

#Sample
^ go to shell

#Grass is always greener: Mix (Elixir)
^ comes with a language that comes in brew/package manager near you ;)
^ go to shell
^ dave thomas - prag dave

mix new my_project --module MyProject
vim mix.exs
mix deps.get
npm install
^ project generation
^ typesafe

#[fit] Dependency management

#[fit]1565
#[fit]XML
^global dependencies
^can't setup per-directory config
^well, overriding settings.xml is not a solution
^json? - composer.php
^lein go gom vundle

#Grass is always greener: Bundler

$ gem install bundler
$ bundle init
source 'https://rubygems.org'

gem 'nokogiri'
gem 'rails'
gem 'rack',  '>=1.0'
gem 'thin',  '~>1.1'
gem 'globalid', github: 'rails/globalid', branch: 'master'
^ comes with RVM

#Grass is always greener: Mix (Elixir)
^ comes with a language that comes in brew/package manager near you ;)

$ mix phoenix.server
defmodule Chat.Mixfile do
  use Mix.Project

  def project do
    [app: :chat,
     version: "0.0.1",
     elixir: "~> 1.0",
     elixirc_paths: ["lib", "web"],
     compilers: [:phoenix] ++ Mix.compilers,
     deps: deps]
  end

  def application do
    [mod: {Chat, []},
     applications: [:phoenix, :phoenix_html, :cowboy, :logger]]
  end

  def deps do
    [{:phoenix, "~> 0.17"},
     {:phoenix_html, "~> 2.1"},
     {:phoenix_live_reload, "~> 1.0"},
     {:phoenix_ecto, "~> 0.9"},
     {:postgrex, ">= 0.0.0"},
     {:cowboy, "~> 1.0"}]
  end
end
^ gom

#[fit] Web Frameworks

(Don't) fight the HTTP

^ hacking the HTTP architecture w/ servlets

#Java EE is a dead fish
#🔥


@Spring

^ complex
^ slow
^ unnecessary


Thanks to @Annotations, @Progress is @Unstoppable!
-- annotationmania.com


#spring boot w/ velocity
^ asset pipelines

Dropwizard

no magic involved


#Grass is always greener: Phoenix

$ mix phoenix.new hello_phoenix
$ cd hello_phoenix
$ mix phoenix.server

[fit]FALSE IDOLS

[fit]WAY TOO OFTEN


##[fit]GOF Design patterns

###It's good to know them.

###It's essential to understand them.
^ why do you use OO patterns with functions?
^ know beyond GOF patterns

#[fit]FINALE


Update your tools

Look beyond the fence

Question everything

Kill the old

Have fun


One last thing...


_INASWAN

^ matz is nice and so we are nice
^ welcome diversity
^ introduce new people

HAVE FUN

^ if you're not. go find where you can.

HAKUNA MATATA

THANKS