Written by Luther Rochester on — 05:51 reading time
As we’ve moved increasing portions of our infrastructure to AWS, we’ve found more use cases for stashing things in s3 that we used to use traditional backup software to store. We keep our SSIS code in version control (currently TFS, grumble grumble), but we aren’t storing a copy of each database object definiton there. Recently we undertook setting up a job that would script out each object’s DDL and store it in an s3 bucket. We’re already doing this for our Postgres servers using pg_dump; we found a great little Python app called mssql-scripter that works similarly to script out the objects for us. This runs in a batch script, along with an aws-cli command to upload the resulting files. The batch script is then called from a SQL Agent job and run on a schedule. The AWS bucket has a lifecycle policy to handle retention for us.
You’ll need a few tools
The server that will run the code will need a few things installed on it. It’s easiest if you use the same server that SQL Agent...
Ansible inventory management is generally very simple and intuitive, but there are some infrastructure configurations that are difficult to express and configure with the built-in inventory and configuration variable functionality. Specifically, it is difficult to configure lists of a certain resource type (like users) across machines that are in different but overlapping groups (like QA environments overlapping with datacenters).
These situations are certainly possible to manage in Ansible, but we at Leapfrog wrote an Ansible plugin that offers a different way of declaring variables that we think can sometimes be more clear. That plugin is available here:
When you are new to Scrum, it’s easy to focus on the concept of finishing everything you have committed to within an iteration. Because when the process instructs that you write user stories of manageable size and deliver small increments of functionality, it’s unsatisfying when the work is not done by the Sprint Review or the next Planning session, right? That is how we define carryover – work that was not done in the sprint but is still valuable, so the story needs to be carried into the next sprint for completion.
Let’s be honest. It’s not just people who are new to Scrum who feel this way. It’s veterans, too. Carryover tends to create uncertainty because it doesn’t seem to fit cleanly into the Scrum framework. But what we are learning is that carryover is as much a part of Scrum as the Daily Stand (if it weren’t, would it have ever received a name?). There are a number of reasons that carryover can happen, these are just a few we witness at Leapfrog:
All software has bugs. From Microsoft Office to joeschmoe.com. Bugs are a reality. And a major part of representing a product is being a first line of defense against “bugs.” If users are allowed to, they will go and tell a developer every time they think they’ve found a bug. That’s the fastest way to a resolution. If what has been found is indeed a bug, the fastest way to fix it is to have someone who writes code be aware of it and write code to fix it. And in a perfect world, where users were wildly competent at diagnosing a system, this behavior might be okay. But this is not a perfect world. And it isn’t fair to assume that someone who casually uses software is going to know the ins and outs of each piece of functionality. And if every user had access to developers, nothing would ever get done. So if it’s your responsibility to own a product, it’s your responsibility to be the first responder to “bugs.”
The first and most important thing to establish here, is you need users and...
Last week a few in the Leapfrog team attended the Anyone Can Learn To Code (ACLTC) showcase at 1871 Chicago. Our goals in attending the showcase were to: share with these graduates who Leapfrog is, increase the pool of candidates for Leapfrog engineering job openings, and get an early chance to talk to people as they transition to their software engineering careers. The ACLTC showcase was from 11am-1pm, during which we had the opportunity to converse with almost all the graduates. The conversations started with the graduates individually sharing a demo of their project at their tables, our team asking questions, and us sharing who Leapfrog is and what we do.
Demos from graduates were generally succinct and well communicated. The demo format allowed the audience to understand the purpose of the project, its functionality, and, in some instances, features that the graduates were planning on adding. The best demos gave us an insight into the graduates’ development process: the development...