Hello World: Software Development

I am working on a little tool at home in my free time to put some skills into practice.  The general idea (nothing novel) is this: I have some financial alerts sent to a new email address I have spun up on my domain.  I am creating an AWS Lambda that will wake up on an hourly schedule, read those emails, and publish SNS messages with parsed financial transaction information.  I then will have an SQS queue listen to the SNS message topic that is consumed by a Step Function.  The Step Function will: store the financial transaction information into a database send an SMS to me if the transaction is above a certain threshold. I could later extend this to do some aggregation reporting, etc if I wanted, too.  This will only work for my own financial transactions, and the data being gathered/stored will be sufficiently vague, so I am not really concerned about financial security for this project. The biggest hurdle I have run into so far is connecting to G...

I have spent a lot of time recently trying to understand the difference between Authority and Role in Spring Security.  This is a brief review of what I found. When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned.  This is important because the UserDetails interface really only cares about how to return one thing: Collection<? extends GrantedAuthority> getAuthorities(); A GrantedAuthority just seems like a glorified String wrapper that names some thing.  The question is... what is that thing? This is where the subtle difference between Authority and Role comes into play. I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role.  But completely forget about the code a...

I've got a bit of time between projects, so I've decided to brush up on Spring Security, as it has been a while since I've tried to follow updates. The first thing I noticed is that when playing around, Spring 5 really doesn't want you to deal with plain text passwords.  This is completely understandable; plain text passwords are BAD and cause bad things to happen in the real world.  Unfortunately, if I'm just trying to play around with the security framework, this can make things a bit clunky.  I've learned there are two ways to work around 1. Do simple inMemoryAuthentication after explicitly calling User.withDefaultPasswordEncoder() to allow plain text passwords while just playing around. 2. Roll a simple/custom UserDetailsService for configure() to use that knows the password doesn't get encryption by prefixing "{noop}" to the password text. (Thanks to ever helpful mkyong for this.)

I've been using React for a personal project, and I am delighted to say that I overall enjoy using it!  While I don't think I'll ever be a strong front end developer (I am much stronger in and really prefer backend development), it is nice to know that I have some front end chops that won't leave me unhappy. Working with React feels very natural to me.  Creating stateful components that are then composed with props and JSX is very similar to creating stateful objects in java, and the main thing to know is that we are extending a Component, and we are overriding render() and other related methods in order to show components the way we want to show them.  The other lifecycle methods get a little tricky here and there, but everything seems to be well documented, and there is tons of community support for problems. I haven't quite built something so sophisticated that it needs a separate state management module yet (read: redux).  I don't think I will go that di...

I have worked on two large projects now that both had grown large and complex testing frameworks.  When I work on projects, I like to see strong test suites; they help me feel more confident that any changes I make to the code base won't cause regressions/bugs.  This is important because in many legacy code bases, features become tangled and disorganized due to deadlines and scope creep.  We've all been there, so we know how such things come to be. At first glance, the test suites looked pretty good.  Coverage was not documented well, but I could tell that the tests did a good job at covering most important cases and a lot of edge cases.  As I started to dig into the test suites, however, I noticed both projects had a common problem -- the complexity of the test suite grew in a different direction than the intention of application it was meant to test.  I get frustrated when this happens because such suites leave me confused about things like the true lif...

There are so many ways to test software.  There are so many ways to organize software tests.  And there are so many opinions on which way is best... that it becomes difficult to decide on a path. I recently presented a short bit on mockito .  The focus of the presentation was on how mockito works.  In the middle of the presentation, someone asked "I understand what we are talking about...but is this even the right way to test?  Is this a good idea?"  Fundamentally, the person was questioning whether unit testing itself is a good idea.  In a previous post, I mentioned the test pyramid and unit tests, so it shouldn't surprise anyone that I believe in unit tests.  When this happened in the presentation, I was genuinely shocked to hear someone bring up an argument against unit tests.  That led me to start googling a bit for such things... and behold, there are a fair number of people out there who are against unit testing because they want to...

We are reading the DevOps Handbook at work, and today we discussed chapter 10 -- the testing chapter.  I was really excited to see that even in DevOps land, people recognize that more and faster running tests are better.  There were many references to google's testing transformation in the book for those that wanted a strong reference for why automated testing is so important. I really appreciated that the book referenced the Testing Pyramid and discussed the importance of focusing mainly on large numbers of unit tests instead of large numbers of slower integration/acceptance/ui/etc kinds of tests.  The Testing Pyramid really encourages a large unit test suite as the base of the pyramid as well-written tests.  I agree with this mindset; a large suite of unit tests encourages the coder to really think about the coder's public APIs and how they might be consumed.  Even if the API lives within the same code base as it's consumer because the consumer is just ano...