Maps and Entities and JPA, OH MY!

Ryan McCullough Problem Solving, Programming, Technology Snapshot Leave a Comment

A client I’m working with has an email templating system that needs an upgrade! The current design utilizes a denormalized table that needed to grow a column every time a new unique token is needed. After a review of the offerings through JPA, I was happy to see that JPA had some support for java.util.Map through joins through a variety of the @MapKey annotation.

In this post, I’ll demonstrate the less frequently used methodology of applying and populating a Map of entities using a single table and a composite key.

How Relative Story Sizing Won Me Over

RJ Dela-Cruz Agile, Consulting, Dev Methodologies, Problem Solving Leave a Comment

Anyone who practices agile methodologies such as scrum is going to be very familiar with the practice of story pointing user stories (also known as poker planning). The good ole’ fashion 4, 8, 13, etc. Fibonacci sequences we assign to user stories of a sprint.

If you’re not familiar, it’s where the team gathers together to discuss the user stories to bring into a coming sprint and assigning each a number called story points. These story points are estimates that represent the level of difficulty and time it is expected to take to complete the story.

The team often will have discussions on whether a story is a particular story point number and argue their point of view until the team comes to an agreement to what story point it should be. I’ve done this type of work estimation for a long time that it’s natural for me… until we did something a bit different on a scrum team that I was a part of.

In this blog, we discuss a different way to assign poker points to user stories that could be beneficial to your scrum team – relative story sizing.

Documentation: Enough Already! Not.

Mike McCoy Consulting, Other, Problem Solving, Soft Skills Leave a Comment

Documentation. I know we all hate having to create it. I don’t like writing it and feel like I always leave something out. However, our assumptions of what other developers should think we are trying to accomplish by our masterpieces of software are usually filled with potholes (sometimes big ones). The truth of the matter is that no matter how stellar your code or software is – if you’re the only one who understands how it works, it doesn’t do any good.

These are not paintings or sculptures that would live the rest of their days in a museum, untouched by human hands and just collecting dust as they run. In reality, documentation will be added to and changed as the information they describe evolves.

In this blog, we discuss two suggested strategies for the creation of useful and concise software documentation.

Picking A Graph Database: ArangoDB, Neo4j, or OrientDB

John Hoestje Databases, Opinion, Problem Solving, Programming Leave a Comment

TL;DR

– Spoiler alert! Graph databases are a great option for storing complex and highly connected data.
– In this post, I compare the benefits and risks of graph databases ArangoDB, Neo4j, and OrientDB for a client project.
– Due to the combination of performance and cost, I chose ArangoDB for my client’s needs.

JavaScript Optional Chaining – An Introduction

Lawrence Chabela CSS & HTML, JavaScript, Problem Solving, Technology Snapshot 1 Comment

There is a new exciting feature coming to JavaScript in the not-so-far future. That feature is Optional Chaining. At this moment, Optional Chaining is in Stage 3 of the TC39 process, so it’s in late stages of the process and will be here soonish.

In general terms, Optional Chaining is an approach to simplify JavaScript expressions for accessing deeply nested values, array items, and methods when there is a possibility that a reference may be missing.

In this blog, we give an introduction to Optional Chaining in JavaScript. We discuss what problems Optional Chaining solves, the various ways you can use it, and relatable code examples.