Author Archives: Jeanne Boyarsky

DevNexus 2018 – Gradle – the basics and beyond

Posted on by
Reply

Title: Gradle – the Basics and Beyond
Speakers: Ken Kousen

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

Install

  • requires Java 7+
  • Gradle 4.2.1+ supports Java 9
  • Gradle releases frequently but is very backward compatible
  • Just unzip and add to path
  • The complete distribute includes the samples. The sample sources are also available online.

General

  • Gradle is now much faster than Maven
  • gradle.com is the enterprise version which is built on top of open source gradle.org.
  • Gradle is mostly implemented in Java. Groovy is for the DSL.
  • Uses Ant behind the scenes as well
  • Groovy comes with Gradle. Don’t need to install Groovy separately
  • gretty is jetty for gradle; also contains tomcat

Docs

Future

  • Kotlin
    • Creating a Kotlin DSL for simple build files.
    • Kotlin is not replacing Groovy
    • Not yet at 1.0.0
    • Goal is better IDE integration
  • Generator
    • Looking at being able to generate projects on web project like Spring Boot has

gradlew

  • Recommend using gradlew. Checking in the file guarantees users are on version of gradle that you intended
  • Has effect of creating many gradle installs on your machine. Not that big.

Creating a project

  • Can generate new project or port basic pom files.
  • Use porting as a guide and then hand edit
  • Generate new project in current directory (make empty directory by hand first)
    • mkdir proj
    • cd proj
    • gradle init –type java-application (or java-library)
  • Files/directories in project
    • gradlew/gradlew.bat – wrapper script
    • gradle/wrapper – jar and properties
    • settings.gradle – lists multi project builds
    • gradle.properties – key/value pairs used by build
  • In home directory’x .gradle
  • wrapper/distx – the binarry/installs.

Daemon

  • Improves performance
  • Cache a lot of the JVM startup
  • For a few hours, same daemon used if using same version of gradle on every project.
  • Tip: turn off daemon on CI servers so every build is a clean build

Gradle file

  • repositories
    • can use jcenter or maven central.
    • or can specify a different one for any Maven or Ivy repo; like internal corporate one
    • can list multiple repos and searches in order
  • dependencies
    • ‘group:name:version’ – same concept as Maven GAV. Or can split into three sections. Ken likes the former better; either fine.
    • can write compile (‘g:n:v’) to specify fully. Groovy parens are optional except when they are not. The DSL can interpret without parens and easier to read.
    • New Java plugin has api/implementation to use as scope instead of compile.
    • compile files – lets you add files not in the classpath
    • compile fileTree – lets you add a directory not in the classpath
  • plugins
    • if registered on plugins.gradle.org, can list id and version numbers.
    • built in plugins (ex: java) don’t get a version number

Commands

  • gradle build -t – rebuilds and then sits idle until you change code. Like a rebuild loop
  • gradle build –dry-run – shows what would run (can use -m instead of –dry-run)
  • gradle -b… – use different build file name
  • gradle –stsatus – shows processes

Build scan

  • Starting Gradle 4.3, will prompt you if you haven’t accepted the license agreement and try to use.
  • It’s hosted at Gradle so sends some info out.
  • Gradle Enterprise does build scans in house

My take

Good structured intro/review. Happy that Ken changed the background to white when we were reading code. He also made the code sufficiently large. I didn’t even need my glasses. Go Ken! The only time I needed my classes was when he showed the manual which uses dark gray on a light gray background for the comments. I knew more of the basics than I realized. But good to have it gel better in my head! And I definitely learned things. Rushed at the end though and that was where most of the new stuff is. Glad I’m a New Yorker and can handle talking fast. Can’t type that fast though so stopped taking notes.

DevNexus 2018 – How to Hire Good Programmers

Posted on by
Reply

Title: How to hire good programmers
Speakers: Jennifer Bland

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

Propose: Stop doing at home programming challenges

Problems

  • We don’t write new projects from scratch all the time at work.
  • Standing up an environment/project from scratch isn’t representative.
  • Being given 90 minutes to do something doesn’t count setup time and then judging them on code
  • [there’s also the problem that you don’t know if someone else did it and that you are expecting them to spend a lot of time on it]
  • [I like http://collabedit.com/ for a short at home exercise so can do real time and watch]

Propose: Implement short coding exercises – 10 lines or less

  • Assume 90 minute interview [I have shorter interviews]
  • Break questions into four areas of 15 minute chunks each. Pick four technologies that you use. Ex: html/css, core javascript, node
  • Goal of each section is to determine level of knowledge person has on that topic
  • For each chunk, ask questions.
  • Type 1: Test knowledge – traditional question. ex: what is difference between x and y. Start asking basic questions and ramp up.
  • Type 2: Write code – give structure and write code to do simple task. Ex: write a selector. Then make question a step harder. And so forth. [these questions are easy. I guess the target is for an entry level or junior developer?]
  • Scoring – set points for different levels of answer to each question and require minimum score to hire.

Propose: Casual tech discussions

  • Propose spending 30 minutes on this section.
  • At lunch at a conference, know people’s names, employer, where they live, what tech stack they use, etc.
  • At an interview, can find opinion. Do they have an opinion. Are they passionate. [I do this]
  • Allows candidate to be open, show understanding of topic, etc.
  • Goal: learn how person will fit into company
  • Also open ended questions like what online resources use.
  • [I thought this was going to be about having lunch with the candidate vs asking questions that are opinions.]

Q&A

  • What steps are in interview process other than the 90 minute interview? Post job and view resumes. HR will talk to the person first. Then spend a day and interview 5-6 people in one day. Usually half are “nos.” Then 1-2 strongest candidates and maybe someone close. Bring back the top couple and bring them back to write more code. Maybe 12 exercises in an hour where there isn’t enough time to complete all of them with half more common. You can see which ones they picked to determine strengths. Can have an offer in a a week. [that sounds like it assumes everyone is free to come in on same day]
  • Have you ever tested interview process on current team? No. But comparing candidates to each other. [I tested some of my questions on some teammates to ensure they aren’t too hard]
  • Do you recommend having candidates pair with current employees? Haven’t tried.
  • How batch candidates? Run job ads for two weeks. Have people come in over a week. It’s the second level where they come with a day or two.
  • How mitigate against people who can’t write code? Asking them to write code. Testing how they problem solve too.

Note: she works for and R&D division of Black and Decker. I imagine that gives them overall stronger candidates.

My take

I definitely agree with not giving a 90 minute project to do at home. I agree with the concept of having people write small code and do that. In less than 10 minutes I can tell if the person knows basic Java and then get on to the harder parts of the interview including more of soft skills and interests. (I suppose that is equivalent since it is on area?] I view the basic coding question as a screen. if they fail, the interview ends, but success doesn’t mean hire. And I agree on asking open ended/opinion questions. I don’t think anyone hires based on a 90 minute take home test though; I imagine they use that as a screen like i use my < 10 minute question on the phone/collabedit.

DevNexus 2018 – Intermediate Git

Posted on by
Reply

Title: Intermmediate git
Speakers: Amanda Olsen

Deck with pictures

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

Beginner git

  • add
  • commit
  • push
  • fetch – gets latest for other branches (I didn’t know this one)
  • checkout
  • pull

Concepts

  • current branch – the branch you are in when you run a command

Merge

  • git merge feature – merges the code from feature into current branch. All commits since branched in same commit in your branch
  • One cycle of merge conflicts (if merge conflicts)
  • If look at git log, see full chronological history looks as if all changes were made in one branch using original commit numbers.
  • Can see time of initial commit (from history looking like there).
  • Can see time of final commit (from the merge commit)

Rebase

  • git rebase feature – applies the commits one at a time but don’t have merge commits.
  • Potentially many cycles of merge conflicts
  • If look at git log, have new commit hashes for each commit
  • Don’t rebase a shared branch unless you coordinate the effort. If two or more people are developing in same branch, need to be really careful. Merge doesn’t have this problem. If you only have one person in a feature branch, it is a moot point. [at the robotics team, we have multiple people on the same branch; maybe this explains some of our challenges]
  • Rebasing rewrites history in that there are new commits. However, they are the same commits so it is more like a copy. Think of history as parent/child relationships instead. Since you have a new child/new commit, it isn’t really rewriting. Merge has a similar problem. It looks like commits were made in a branch when they were really made in a different branch and “moved” to target branch later.
  • Can see the time of final commit (from the commit)

Merge vs rebase

  • Merge
    • records that it was a merge commit
    • displays chronologically correct history if initial commits
    • Chronologically incorrect history of commits from perspective of master
    • Makes master more complicated
    • Difficult to roll back
    • Creates extra commits
  • Rebase
    • Simple master branch
    • Understanding master is easy
    • Rolling back is easy
    • Master doesn’t record when a branch is merged in
    • Golden rule – don’t rebase when multiple people working on a branch

Feature branch workflow

  • One branch per feature
  • Master is finalized work and intended to be bug free
  • Feature branches probably has bugs and that is fine
  • Very common workflow
  • Other workflows described

Rebasing

  • git rebase –continue – acknowledges that you merged one “group”
  • git rebase –abort – lets you start over

What to do when stuck

  • git reflog – portmanteau for “reference” and “log”
  • Remember that everything is saved if committed it. Local commits like a journal. (but then combine them before push!)
  • Commit any uncommitted changes
  • git reflog to find commit want to go back to
  • git reset –hard – move to that point in time
  • reflog goes back 90 days

Example with squashing commits

  • git clone
  • Create new feature branch
  • Start coding
  • Realize need the code from master
  • git fetch – pul remove branches/origin
  • git rebase -i HEAD-3 – reapplies the last three commits to the tip stepping through each commit. Combines them into one commit with a new commit comment.
  • git pull origin master –rebase – do a pull but rebase (instead of automatically merging). Faster to squash commits before rebase so less to go through when pull.
  • git push origin feature – pushes to the feature branch
  • Then can submit pull request so it gets merged into master

My take

Nice clear methodical explanation. I’m glad she mentioned what was “basic” git since I didn’t know about fetch. I like the recorded “non-live” demos. Great way to save time/reduce risk while still preserving the benefits of a demo.