ETL With Scala and Native SQL – Part 1

For almost as long as software engineers have been using object-oriented programming languages to access relational databases, we have been lamenting the “impedance mismatch” between the two. The lack of straightforward language constructs to allow data to move cleanly back and forth between objects and tables led to the rise of object-relational mapping tools. ORM tools provide the illusion that the programmer does not need to know SQL. But for any nontrivial data access, the ORM just obscures the engineers’ view of the native SQL of the RDBMS which they are trying to generate indirectly by manipulating JPA annotations or Spring Data method names.

Functional programming can be the solution to the impedance mismatch. It allows for the wiring between objects and tables to be expressed cleanly and concisely without the unwieldy amount of code needed for using native SQL with the JDBC API. In short, OOP + FP + SQL = Better Programs.

This requires a language that truly supports both OOP and FP, along with a database library which does not try to be an ORM. In this article we look at using Scala with the Anorm library.

Continue reading

Modeling Hierarchical Data in Postgres

Hierarchical data has historically been a challenge with relational databases. There are well-known solutions for implementing a hierarchy in a purely relational fashion, but their complexity and performance are not generally desirable. To overcome this, some modern RDBMSs have a special data type for hierarchical values. In the case of Postgres, this data type is the ltree.

The ltree data type allows for storing paths similar to filesystem paths or DNS records, and provides the ability to perform hierarchical queries which are much cleaner and more efficient than their purely relational counterparts. But often we want to have further constraints, such as requiring the existence of all ancestors in each path, and this requires additional work. Here we develop a complete implementation of the common use case of an entity hierarchy with the same properties as a filesystem directory tree.

ltree Basics

The ltree documentation refers to each ltree value as a path, and each component of the path as a label. A path is a series of labels separated by Continue reading

7 Habits of a Killer Sprint Team

This post was co-authored by Dave Arndt and Kevin Miles. With 40+ combined years of architecture/development experience on various Sprint teams at different companies, we have identified some key behaviors that all our most effective teams have exhibited as well as noting some (sometimes subtle) unhealthy behaviors.

If you are currently on a team that is performing poorly and claims that “Agile does not work for our team, we’re different, we’re unique” or you’re just experiencing pushback and foot-dragging while attempting to adopt these types of healthy habits you will have to be the change for the team. Or, you may want to change the team that you are on.

This article requires some basic understanding of Agile Software Development.

Focus on Commitments

Team pays attention to the story burndown as a primary chart during standup.

Unhealthy: Team pays attention to the task burn-down.

We all know that a story takes the time that it takes regardless of your best estimations, but keeping an eye on the burndown helps the team evaluate what actions may help get things back on track. For example, by watching burndown you may realize that QA is often light at the beginning of a sprint and slammed at the end, perhaps holding up several stories from finishing. This may tip you off that you can reorganize story priority so that some stories can be delivered to the QA column earlier. Delivering on Commitments helps to build trust with your team and its stakeholders.

Continuous Improvement

Team makes explicit efforts to identify what is going right and wrong and focuses on making changes necessary to improve. Retros are genuinely valued and anticipated by team members.

Unhealthy: Team views the retro as a gripe session without results and discontinues.

This is simply taking advantage of the power of continuous improvement or Kaizen. These changes are often small and easily achieved. When a team focuses and revisits items that they themselves have deemed important to change, add, remove or simply improve they will be making minor adjustments and corrections that will ultimately add up to big gains for productivity and collaboration. This also helps to breed trust between Product Owner and team members because of the effort put towards quality and productivity.

The Team Succeeds or Fails Together

Because the team is working to a known business goal each sprint, members are quick to Continue reading