[2020 devnexus] open development when you’re not in charge

Bob Paulin @bobpaulin

For more, see table of contents


Open Development

  • Code, processes of contribution available to whole organization.
  • Each project might have some extra governance
  • Developers can see, contribute and work with any code.

InnerSource

  • Communities not product teams
  • Communication is transparent
  • Code/doc/issues accessible to everyone
  • Code not usually externally available (outside company)

Apache Way

  • Community over code – can’t do something that helps one person, but is bad for the community
  • Consensus decision making
  • Open communications – message lists for all projects. “If it’s not on the list, it didn’t happen”
  • Earned authority – earned/voted on
  • Community of pears
  • Responsible oversight

More on Apache

  • Hard to kill an Apache project. Struts is still cutting releases. People are still maintaining it because important to someone.
  • When community goes away, project goes to attic

Open Development at work

  • Consultants – there to advise
  • “You can make buffalo go anywhere, just so long as they want to go there”. “You can keep buffalo out of anywhere, just so long as they don’t want to go there” – from “Secrets of Consulting” – recommends book for getting things gone
  • People will go to great lengths to avoid pain. They need to understand how open development reduces their pain

Stories

  • Tribal knowledge – once a month man comes down from the mountain and explains how things work to people
    • localized knowledge
    • can go with benevolent dictator on project
    • passed down mouth to mouth
    • only know if have relationship or proximity to person
    • document for different zip codes – needs to be clear to everyone. only use acronyms can google
    • document for dummies – should be clear to entry level developers
    • curse of knowledge – you’ve forgotten what is hard
  • Man behind the mirror decision making – architect went to talk to everyone. All felt good after meeting. Months later, realized things weren’t working together. Contradictions, misunderstandings
    • Set decision making to INFO – anyone can read decisions
    • People get upset/feel excluded when planning happens via direct message
    • People make decisions in meetings without realizing it was a decision
    • Appoint a decision crier – someone raise hands and says sounds like a decision and notes should write it down. Also helpful to have a secretary who should write things down.
  • Micro manager – can’t expect others to step up if still doing everything
    • Encouraged measured risk taking – let people take risks so can feel comfortable. Ex: can commit, but say something. Still don’t want it to go to production. Focus on learning over veto
    • Self driving car approach – still need to pay attention to wheel. Find bugs by finding mistakes people are continually making
    • Build reputation of new leaders – others start become accountable and show they can do it
    • Have to let make mistakes. Ok to commit something not perfect.
  • Bike shed to oblivion – people get passionate when arguing about something important (to them). What color should the bike shed be.
    • Enabling constructive dissent – community, consensus, earned authority
    • Elephant rules – acknowledge the undercurrents. What is actual reason for dissent. Knowing whether comes from gut feeling. Acknowledge what is problem and what is relevant
    • Build failure hedge fund – sometimes things go wrong. Determine if can learn from them or will ruin company? If the later, veto. Normal to fail from time to time

My take

Good end of the day. Some “obvious” and some to experiment with. Nice inspirational talk. I like the mapping of “general” principles to Apache principles.

Creating a tar.gz file in Java

Today’s article demonstrates how to create a tar.gz file in a single pass in Java. While there’s number of websites that provide instructions for creating a gzip or tar archive via Java, there aren’t any that will tell you how to make a tar.gz file without performing the same operations twice.

Reviewing Tar and Gzip Compression

First, download the Apache Commons Compression library. It is actually a subset of the code found in the Ant Jar for those performing compression operations that do not require all of Ant’s many features. Below is the code to create a tar and gzip archive, respectively, using the Compression library.

TarArchiveOutputStream out = null;
try {
     out = new TarArchiveOutputStream(
          new BufferedOutputStream(new FileOutputStream("myFile.tar")));
     // Add data to out and flush stream
     ...
} finally {
     if(out != null) out.close();
}
GZIPOutputStream out = null;
try {
     out = new GZIPOutputStream(
          new BufferedOutputStream(new FileOutputStream("myFile.tar")));
     // Add data to out and flush stream
     ...
} finally {
     if(out != null) out.close();
}

One subtlety in this example is that we use a BufferedOutputStream on the file stream for performance reasons. Often, archive files are large so that buffering the output is desirable. Another good practice is to always close your resources in a finally block after you are done with them.

The Solution

The solution is to wrap the tar stream around a gzip stream, since the order of writing goes inward from outer most to inner most stream. The code below first creates a tar archive, then compresses it inside a gzip stream. Buffering is applied and the result is written to disk.

TarArchiveOutputStream out = null;
try {
     out = new TarArchiveOutputStream(
          new GZIPOutputStream(
               new BufferedOutputStream(new FileOutputStream("myFile.tar.gz"))));
     // Add data to out and flush stream
     ...
} finally {
     if(out != null) out.close();
}

You can then treat the stream as a tar file using the TarArchiveEntry API to add entries and write data directly to the stream. The gzip compression will happen automatically as the stream is written.