I'm speaking at Iowa Technology Summit

I’m proud to announce I’ll be speaking at Iowa Technology Summit on October 2nd! The conference will be held at the Community Choice Credit Union Convention Center in down Des Moines.

I’ll be speaking on Secure by Design and how you can ensure security throughout development of your application. I’ll cover some of the OWASP top 10, best practices, and things I’ve implemented at work. I gave a similar talk at DevOpsDays Des Moines, but I have a lot of takeaways from that talk and my team at work has made a lot of progress that I’m excited to be able to share.

Registration is open now, so don’t delay in getting your tickets!

read more

Spring JPA add default timestamp to column

Spring JPA is awesome, but I ran into some issues adding a default timestamp to the column. The database should be set to have a default value, but that wasn’t an option here. I found the annotation pretty quickly, but instead of checking the database to see if it worked I was debugging in IntelliJ and that’s where the hiccup occurred. The value isn’t set on the object at object creation it’s only set once the entity has been saved. The following is what I ended up using

@Column(name = "creationDate")
@CreationTimestamp //this adds the default timestamp on save
private Timestamp createDate;

read more

Spring Boot DB2 and MSSQL Configuration

By default Spring boot does a lot for you in datasource configuration, but if you’re using two separate database types – DB2, MSSQL, MySQL, Oracle, etc. It doesn’t know how to infer which database type each is, so if you are configuring multiple different database types in Spring you need to specify the jpa.database type. In a yaml configuration your datasources should be defines like so.

    url: jdbc:sqlserver://${server}:${port};databaseName=${databaseName}
    username: ${username}
    password: ${password}
    database: sql_server
    jdbcurl: jdbc:db2://${server}:${port}/${databaseName}
    username: ${username}
    password: ${password}
    database: db2

read more

Jeff Hawkins - On Intelligence Notes

On Intelligence: How a New Understanding of the Brain Will Lead to the Creation of Truly Intelligent Machines by Jeff Hawkins is a truly fascinating book. It delves deep into how the brain works and why it is so hard to train a bot to do normal human things. Our brain is able to make low-level sensory predictions about what it expects to see, hear, and feel at given moment and it does all of these task in parallel. Here are other things I found interesting.

  • Deep blue beat Garry Kasparov at his own game, chess, but the successes were hollow. Deep blue didn’t win by being smarter than a human it won by being millions of times faster than a human, deep blue had no intuition.
  • These successful AI programs are good at one thing and one thing only just like a calculator is great at math but can’t do anything else.
  • A computer just mindlessly executes instructions. It doesn’t know any more context than we have given it.
  • Our intuition is often the biggest obstacle to uncovering the truth. Intuitive but incorrect assumptions keep us from seeing the correct answer.
  • The strengthening and formation of synapses is what causes memories to be stored.
  • The best ideas in science are almost always simple, elegant, and unexpected.
  • We teach children we have five senses – touch, smell, sight, hearing, and taste. We really have more vision is like three senses motion, color, and luminous. Touch has temperature, pressure, pain, and vibration.
  • The neo-cortex is infinitely smarter than any computer.
  • An artificial intelligence strategy to open every door is impossible. Every attribute a door can have has to be in a database, weight, hinges, handle location, etc. There would need to be similar lists for every object in the world. Your brain makes low-level sensory predictions about what it expects to see, hear, and feel at any given moment and it does it all in parallel.
  • Correct predictions result in understanding. “the door is normal” incorrect predictions result in confusion and prompt you to pay attention. “the door is too light” the door knob is moved, etc
  • When you miss a step you know immediately. If your foot misses its intended target by even a fraction of an inch you know something is wrong.
  • If you get stuck on a problem go away for a while and then start again rephrasing the problem as something new.
  • Brain uses memory and current context to predict what is written, words and letters that are unrecognizable on their own are easily recognized in context. Pattern matching with computers is not sufficient to the task.

read more

Leading the Transformation: Applying Agile and DevOps Principles at Scale Notes

My personal notes from Leading the Transformation by Gary Gruver

  • Additional reading – Many specifics referenced in this book are leveraged from a case study of transformation at HP, detailed in A Practical Approach to Large-Scale Agile Development, by Gary Gruver, Mike Young, and Pat Fulghum.
  • How teams come together to deliver value in large organizations is a first-order effect. How individual teams work is a second-order effect
  • Done means
    • feature is signed off
    • defect free
    • test automation is complete
  • Software development is such a discover process that many assumptions made in planning can quickly become obsolete during development
  • Capacity of an organization to absorb change is the biggest constraint to rolling out improvements
  • Should always set objective and review at the end of each iteration
  • When estimates are off many organizations react by spending more and more in planning instead of focusing on delivering software
  • Instead of scolding people who commit on a red build, create a process that eliminates the problem
    • Usually roll back the last commit
  • Many organizations ask their manual testers to learn to automation what they have been doing manually for years. Some orgs buy tools to record what the manual testers are doing and that’s even worse
    • Record and playback is awful because if any UI changes the whole test is trash
  • An acceptance test should test one thing and one thing only.
  • All configurations should be in version control
    • You can automate checking successful deployments by querying your log management software for a successful deployment
  • Developers want to do a good job, and they assume they have until they get feedback to the contrary
  • ROI on DevOps is substantial but you will never achieve full benefit until you get your automated testing built out and integrated into the development pipeline
  • Applying DevOps principles at scale really requires the executive to drive the cultural and technical changes for improving the stability of trunk. This is vitally important because of the productivity gains that are possible when you eliminate branches and integrate all work across the teams on trunk. To get your code trunk to this level of quality and to keep it there, you need to begin using a CD pipeline with both code and component-level gating. This pipeline must incorporate a robust test automation framework. You will need to have component-based automated tests. Executives will need some simple metrics that are auto-generated each day to understand what is working and what is not so that they can focus resources in the right place every day.


read more