bdkosher

import java.util.Optional;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import org.springframework.stereotype.Component;

@Component
@Path("/greeting")
public class GreetingResource {

bdkosher

Groovy: A Good Time to Let Go of java.util.Date

It's common knowledge that java.util.Date has undesireable qualities and should be avoided whenever possible by developers, especially now that a proper Date/Time API exists within Java SE. Despite its faults, however, there are actually some features of the Groovy language that may be encouraging the continued use of java.util.Date.

1. It is always imported

Groovy imports the java.util package by default because, more often than not, code will need something defined within that package. Date, of course, being in that package, becomes readily available for use. I've become accustomed to invoking new Date() and Date.parse(dateStr) without even thinking about my import statements.

The Java 8 Date/Time API is a different story. I often write my Groovy scripts without a full-featured IDE, so I have to manually add imports--usually after som

bdkosher

Map<String, String> conv = new HashMap<>();
conv.put("\u0200","\u0342\u0202\u0254");
conv.put("\u0202","\u0342\u0200\u0232");
conv.put("\u0203","\u0306\u0222");
conv.put("\u0204","\u0342\u0200\u0236");
conv.put("\u0205","\u0342\u0200\u0246");
conv.put("\u0206","\u0342\u0200\u0240");
conv.put("\u0207","\u0342\u0200\u0241");
conv.put("\u0210","\u0313\u0206");
conv.put("\u0211","\u0342\u0200\u0260");

bdkosher

void foo(double d) {
    println 'Double baby'
}

void foo(Number n) {
    println 'Number baby'    
}

foo(Double.valueOf(10d))

bdkosher

def factors(int n) {
    (2..<n).findAll { i -> n % i == 0 }
}

// FIXME. If you provide, e.g., 15 and 30 it should return [3, 5, 15]
def commonFactors(int... nums) {
    def commonFactors = factors(nums[0])
    for (int i = 1; i < nums.length; ++i) {
        commonFactors = commonFactors.intersect(factors(nums[i])) 
    }

bdkosher

6 Reasons Why Dev Teams Should Own their Data Model

Although it seems like it would be common knowledge that

1. It biases applications architectures toward transactional, relational databases.

Where I've worked, the data modeling teams specialized in relational databases, which contributed to the organizaitonal mindset of handling all data persistence requirements through use of an RDBMS. Unfortunately, the presumption of RDBMS usage limits discussion about application persistence requirements and associated trade-offs:

• "Is my system transactional?"
• "Do we need immediate consistency at the expense of availability?"
• "How do we best support the high write throughput we anticipate?"

bdkosher

It's the Organization, Stupid

DevOps is an architectural pattern, and architecture is a reflection of the organization.

Those familiar with 1990s American politics have likely heard the phrase "it's the economy, stupid." It was essentially the Clinton campaign's answer to the question of what single issue ultimately mattered to swing voters and consequently became its key message and unofficial slogan.

Although cliché, I feel the variant, "It's the organization, stupid," is a surprsingly fitting answer for some debatable yet important topics in the development world.

For this article I'm going to look at this answer's applicability to the question of "How do we ____ DevOps?" I never know which verb is appropriate--"do", "achieve", "implement", "enable", "become"--so pick one you're comfortable with; I'll be using the verb "blank" hereafter.

bdkosher

Static Code Analyzers: The Good, The Bad, and The Ugly

The Good

Finding code smells Helping you analyze a large codebase

The Bad

Lack of Context for Severity Lack of Context for Applicability Inability to know if code is just plain stupid

bdkosher

Tools, Process, People

We've all heard the DevOps transformation matra of "People, Process, Tools" where you start by getting People on board the DevOps movement, which in turns leads to Processes being overhauled to support the DevOps mindset, and finally Tools being brought in to support the processes.

That's nice. But I often find that people will not change until a new tool is introduced that devalues or is outright incompatible with current processes, which in turn challenges their worldview and opens them to transformation.

The most notable example I can think of is Git. As a longtime Subversion user, Git challenges my Continuous Integration beliefs, most of which have been shaped by the model and limitations of Subversion:

• Merging is a pain and should be avoided if possible
• Every developer has full commit access to the repository
• Change history is completely linear--"branches" are basically an illusion whereby you replicate the entire codebase

bdkosher

@Grab('com.github.bdkosher:goodtimes:1.2')
import static bdkosher.goodtimes.LocalDates.August
import static java.time.LocalDate.now

def lakeWeek = August 12
int daysTillLakeWeek = (now() >> lakeWeek).days
println "$daysTillLakeWeek days until the Lake"