DEV Community: Michael Lamb

[Redis Hackathon Submission Post Placeholder Title]

Michael Lamb — Tue, 23 Aug 2022 12:29:53 +0000

Overview of My Submission

Submission Category:

[Optional: Video Explainer of My Project]

Language Used

Link to Code

BTW, your Github code’s README file should contain the details as per this template.

Additional Resources / Info

[Note:] # (Be sure to link to any open source projects that are using your workflow!)

[Note:] # Screenshots/demo videos are encouraged!

Collaborators

[Reminder]: # (Submissions are due on August 29th, 2022 @ 11:59 PM UTC).

Check out Redis OM, client libraries for working with Redis as a multi-model database.
Use RedisInsight to visualize your data in Redis.
Sign up for a free Redis database.

Spring Framework - Dependency Injection

Michael Lamb — Thu, 27 Feb 2020 07:04:44 +0000

The Spring Framework empowers developers to create Java applications and deliver on business focus quickly. The primary benefit of Spring is its inversion-of-control container approach to dependency injection, removing the need for hard-coded wiring as the framework can inject dependencies where they are needed.

Benefits

• Testability
• Maintainability
• Scalability

Testability

Because Spring decouples object contracts from their implementations and autowires them using Spring's Application Context, we can create units of work that are much easier to write tests for.

Maintainability

By using Spring's opinionated architecture, developers can quickly identify and familiarize themselves with an application's business focus. Most frameworks are popular because they operate on some fundamentals that are easy to grasp, which is one of Spring's strengths.

Scalability

Spring containers utilizing Spring Boot are able to deploy as standalone JARs and run on an included Tomcat server. Between Spring's @Profile annotations and the Spring Application Context Configuration, there is a lot of flexibility to control the behavior of a Spring application in varying environments.

IoC/Dependency Injection in Spring

Understanding dependency injection is a fundamental component of understanding the Spring Framework. Spring Boot is the most popular project developers get started with and is an excellent sandbox for development ideas around dependency injection. Let's take a look, getting started with how we can store configurations in a Java class and tell Spring how to use it with the @Configuration annotation.

ApplicationContextConfiguration

Using the @Configuration annotation enables Java configuration of specific dependencies. In the example below, we will tell Spring what implements theUserDao and what DataSource to build. We are assuming the UserDao uses constructor injection to determine its database connection dependency.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class MyApplicationContextConfiguration {  // (1)
     @Bean
    public DataSource dataSource() {  // (2)
        MysqlDataSource dataSource = new MysqlDataSource();
        dataSource.setUser("root");
        dataSource.setPassword("s3cr3t");
        dataSource.setURL("jdbc:mysql://localhost:3306/myDatabase");
        return dataSource;
    }
     @Bean
    public UserDao userDao() { // (3)
        return new UserDao(dataSource());
    }
}

The class name used with a @Configuration annotation will be used in configuring the ApplicationContext in Spring
A DataSource with the Spring @Bean is created
A UserDao Spring @Bean is created, calling the dataSource() method on the DataSource @Bean

ApplicationContext

Spring uses the ApplicationContext to determine what @Beans to instantiate and inject into dependencies.

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import javax.sql.DataSource;
public class MyApplication {
     public static void main(String[] args) {
    // (1)
        ApplicationContext ctx = new AnnotationConfigApplicationContext(MyApplicationContextConfiguration.class);
         UserDao userDao = ctx.getBean(UserDao.class); // (2)
        User user1 = userDao.findById(1);
        User user2 = userDao.findById(2);
         DataSource dataSource = ctx.getBean(DataSource.class); // (3)
        // etc ...
    }
}

Construct an ApplicationContext by passing in MyApplicationContextConfiguration class, which will create a UserDao and a DataSource
Get the fully configured UserDao, including its dependency on a DataSource for JDBC connection
We can also get the exact same instance of the DataSource used in UserDao from the ApplicationContext

Using @ComponentScan to inject @Components

We don't need to tell Spring to look at our Application Context Configuration to figure out what @Beans exist in our application. Instead, we can tell Spring where it can look for other @Components in our application using the @ComponentScan annotation on our main Application class.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
@Configuration
@ComponentScan  // (1)
public class MyApplicationContextConfiguration {
     @Bean
    public DataSource dataSource() {
        MysqlDataSource dataSource = new MysqlDataSource();
        dataSource.setUser("root");
        dataSource.setPassword("s3cr3t");
        dataSource.setURL("jdbc:mysql://localhost:3306/myDatabase");
        return dataSource;
    }
     // (2)
     // no more UserDao @Bean method!
}

Without any arguments, Spring will look for @Components in all Java classes in the same package
Why don't we need the UserDao @Bean in the Application Context Configuration anymore?

import javax.sql.DataSource;
import org.springframework.stereotype.Component;
@Component // (1)
public class UserDao {
     private DataSource dataSource;
     private UserDao(DataSource dataSource) { // (2)
        this.dataSource = dataSource;
    }
}

Spring now knows the UserDao is a dependency it should manage and inject where needed
How does Spring know what to provide to the UserDao for its DataSource dependency?

While not required in the latest versions of Spring (4.2 and later), the @Autowired annotation can be used to explicitly mark the constructor injection method as dependent on the DataSource @Bean Spring will create.

import javax.sql.DataSource;
import org.springframework.stereotype.Component;
import org.springframework.beans.factory.annotation.Autowired;
@Component
public class UserDao {
     private DataSource dataSource;
     private UserDao(@Autowired DataSource dataSource) {
        this.dataSource = dataSource;
    }
}

Injection Methods
• Constructor
• Setter
• Field

Sources

Code examples used in this blog were adapted from Marco Behler's What is Spring Framework?

We started a developer meetup

Michael Lamb — Wed, 29 Jan 2020 23:25:31 +0000

C Spire is a technology and telecommunications company headquartered in Ridgeland, Mississippi. I have been a full-time Software Developer here since December 2016. I wanted to work for C Spire because I believed that it corporately understands the importance of computer literacy. Evidenced by a growing number of initiatives like the Tech Movement, the C Spire Coding Challenge, and the Software Development Pathway, this faith has been well-placed. I'm glad I work for a company that invests in its community so intentionally.

In June 2019, I was approached by our Application Systems Architect team to discuss establishing some cultural changes to help the C Spire developer community. Just as in any enterprise-level company, information gets siloed and teams will sometimes work on redundant operations––or worse, they might work against each other. There are disparate standards, tools, and languages between development teams. Junior developers often don't even understand how a project starts and ends, let alone who determines requirements and specifications. The common solution for problems like these is to promote communication, which was exactly what the Architect group wanted to do. So, we set about writing a mission statement to establish our own initiative.

The way we wanted to execute this mission was to create an internal forum, communicate the goals of our efforts, and invite developers to speak on a wide array of topics.

Audience

The medium of a developer meetup would help us generate creative collisions between a wide audience at the company. We targeted our IT, Network, and HR departments. IT itself is comprised of a number of groups including web and application developers, UX designers, analysts, DBA, BI, QA, Billing, and Operations. HR and Network both have their own development teams. Network is responsible for infrastructure and they develop their own monitoring and reporting tools in-house.

Bringing in such a diverse audience has been rewarding and challenging. We have to organize our speakers so that their talks are enlightening to people who might otherwise be disengaged or unaware of their topic. Sometimes, speakers don't think their areas of expertise are interesting––though this is a problem we have yet to really face for an I/O session. Our audience, then, is really just the people we work with but don't know much about. As an organization, we keep finding ourselves with groups who send a speaker to say to our audience: this is who we are and what we do; how can we help you?

Goals

Even though the company clearly has a strong understanding of why computer science and software engineering are vital to collective success, we couldn't pitch a developer meetup without establishing why it was important to C Spire. We identified these goals which would help us measure the impact of our meetup:

Lower developer churn
Foster learning and developer contribution
Encourage cross-team culture sharing
Establish and communicate C Spire best practices
Reduce complacency and encourage creativity
Shift the paradigm toward CI/CD

So began C Spire I/O

The Architects, a System Analyst from my team, an intern, and myself were the core group planning what we decided to call C Spire I/O. The name came from the guiding principles of innovation and openness, but on a less high-minded level we were just ripping Google's I/O conference. The company name C Spire comes from our vision to be "customer inspired" so I like to think we are just borrowing inspiration.

The support we received for I/O from the leadership in IT was incredible. Managers bought in to the idea and agreed to honor the time we organized I/O sessions by encouraging their teams to attend and participate. Executive leadership gave us a blank check to make an event we would be proud to produce. What meant the most to me, though, was that everyone I talked to seemed to recognize what we're doing as a good thing, not just something that's necessary.

2019 Accomplishments

We predicted that we might average 40-50 attendees at each session. In 2019, we hosted 7 sessions with an average of 92 people attending!
Since our focus is internal, the speakers for each session come from the 20 groups that participate in I/O. 14 of those groups were represented.
21 different talks ranged from themes of Requirements, Architecture, Development, and Deployment.

2020 Aspirations

We are targeting 12 dates to host I/O sessions throughout the year
We want to improve the remote experience of I/O sessions to increase engagement at C Spire offices around the nation
We hope to bring in external speakers

Talk about your passions

As I reflect on how this all started, I remember a story from my first year at C Spire. In August 2017, the company held a hack-a-thon style event called Ideathon where groups would workshop their ideas to present to a board not unlike the well-known Shark Tank. I was still fresh under the gills and getting used to working in a corporate environment but I was curious as to what might happen.

I found a group of colleagues and we hashed out plans for a community coding club. The idea was not entirely the same as C Spire I/O because it wasn't specifically about development happening within the company. We rooted our conversation in how to best help people who were interested in learning how to create software for people with no experience. After drawing up a mock schedule filled with lecture series, workshops, and social events, I volunteered to give our 5-minute pitch. I think the passion I felt for creating community around technology became apparent while I spoke on all the ideas the group had come up with and stood by it. Even though our pitch didn't win the competition, I was proud to be company to others who were just as excited about computer science literacy and the many ways we might be able to impact our community by sharing our knowledge.

The drive to make software development an accessible skill aligns with C Spire's efforts to raise the bar in Mississippi. Only about half of the high schools in the state offer computer science courses, so the need here is great. Software creates so much opportunity for innovation, creativity, and community. To be included as a founding board member of C Spire I/O is an honor though it also seems it was inevitable. The lesson I've learned here is to talk about your passions and the people who are excited and able to help you will find you.

I hope that developers at C Spire young and old will see I/O as an platform for them to speak about their passions.

Why Smart City Technology Shouldn't Be Considered Out of Reach

Michael Lamb — Tue, 06 Aug 2019 01:13:37 +0000

The future of smart city technology is here. The opportunities presented by grassroots public infrastructure movements should be enough evidence for the work to be done. So let's start doing it.

The best smart cities are data-driven cities. The best data comes from the Internet of Things. The best Internet for those things is driven by connectivity. Connectivity is what integrators do best. Technology companies should be integrators. Sensor technologies can provide cities and citizens greater understanding of their surroundings by creating connections that propagate change. Small cell technologies enable robust, mobile connections more quickly and with greater ease of operation. Any company that can excel in this area will see the benefits.

Though I speak highly of the smart city potential, it is not without caveats. There are bureaucratic entanglements that tie up so many possibilities for partnerships between integrators and utilities companies. But the crowd can source its own way, too.

The Internet of Things opens up the doors to so many great features for families. Imagine automating a small garden to keep fresh food close to home. Think about setting up a mesh network along the path between your house and your beehives, about a 10 minute walk through the woods; reporting back could be a scale to measure the hive weight, or a thermometer to track the temperature. A small camera could be used to train a model to track the total population of bees.

All of these use cases are within reach, if only we are courageous enough to put in the work.

Senior Design Prepared Me for Real Life Development

Michael Lamb — Tue, 23 Jul 2019 15:54:57 +0000

This is the story of how I became a software developer.

At first, I wasn't

I was an English major. Well, before that I was studying Biblical Literature. And before that I was studying Music. And finally before that I was studying English.

Twice in that list I say I study English. I started off that way and ended that way in 2012 when I found myself in attendance of the Broadening Participation in Computing at Mississippi State University. Yes, I declared English as my major two different times. The first was at a bible college that doesn't exist anymore. The second was after the school shut down. Life is great when it makes no sense.

I was studying Spanish to satisfy the basic requirements for an English degree when I met Daniel. Daniel introduced me to the BPC program because he had experienced it himself. He highly recommended it, and so I applied. I went to my favorite teacher at Hinds CC, Mrs Kathy Smith, and asked her to recommend me for the program. She agreed to show me the kindness of providing me a letter which acknowledged an ability to critically analyze a story and understand the differing motivations possible to explain the author's intent.

That's a skill I've found quite handy in reading code written by my coworkers. Does it sound complicated? It's really not. There are a million little things developers try to understand — and they all tend to bubble up in design patterns. Systems of design are intentional. The care put into them requires your attention if you plan on being able to improve them.

The rest of my college career was designed by people who generally understood that designing systems requires intention. My process for selecting to pursue a Bachelors of Science degree in Software Engineering at Mississippi State University was aided by a well-designed flow of balancing conversations about the pros and cons of other comparable programs; I am grateful for the counsel of many community members who gave me advice and impacted my life. Seeing the unique benefits offered at MSU, I decided that Starkville would be my home for a while.

1.5 years later, I was ready for Senior Design

The project was simple. Build a website to manage a library of audiobooks.

The project was not simple. The website's main audience was going to be people who could not see. What happened next has shaped how I understand my job, and I couldn't be more grateful for its impact.

Our team was large for my taste. 9 people total. But it seemed like everyone else understood we had too many people to form a single, cohesive group that could last an entire semester. We selected a project manager. He broke us up into 3 teams with separate concerns. There was even further fragmentation as one person took it upon himself to completely own all database components and he created a single way to write all our business logic in PHP. We self-selected our sub-teams: backend devs writing PHP, frontend devs writing HTML, JS, and CSS using Bootstrap, and an integration team which handled reviewing and handling the logistics that tied the two together. I joined the integration team.

9 people seemed perfect, now. We had stuff figured out. We knew what we were doing.

Except for all the mistakes

We did some things well but there were plenty of little things I'd change now that would have saved time back then. C'est la vie.

We poorly practiced trunk-based-development. Since everyone's concerns were primarily structured the same way using the Model-View-Controller paradigm, I ended up benefitting by getting a little exposure to a lot of different ways of thinking. This came in handy when comparing the mistakes I made in my team to the mistakes made in the other teams.

Frontend designers think differently when they have to spend time working with their users. That's where the requirements are gathered, really. Accessibility means your users are able to use your software. It can offer long periods of uncertainty in whether your work will be ultimately meaningful. Not every idea we have can survive forever, especially when there is a disparity between the users and the designers.

Our meeting notes included phrases like, "This doesn't make sense to me!" There was no note afterward indicating this had changed for the author. The difficulty arose from a misunderstanding between the author, her colleague, and two of the clients. There is still so much I have to learn about creating inclusive technology experiences when writing new software, but this project was where I first considered what truly accessible software means.

Backend designers are typically focused on analytics. This has been where I've found myself professionally. Learning from frontend designers became normal. Writing code that could be consumed by the frontend designers made it so that I was interested in listening to their complaints. If I could make it easier for them to work with us, I'd need information on their roadblocks. That meant errors.

Some of those errors were mine. Some of those errors belonged to others. All the errors were rooted in not understanding something. Maybe the software didn't 'understand' some input or the person who wrote it made a mistake or the actor tried to make the software do something it couldn't. Perhaps the software was configured incorrectly or something happened to the network. It is possible that some of my colleagues even went through breakups that affected their emotional states while writing their code, leading them to make assumptions just because they weren't interested in their work. All of these things were questions I ended up having while learning how to work with two separate groups that weren't always talking to each other.

Recognizing that this happens often in life shifted how I processed my own failures over time. Sometimes the failures ended up leaving some shame for changing my mind so often. The times I felt some grief at the different lives I might have lived if I had continued on in English or Music were met with meaningful friendships that have become pillars. Accessibility all starts with feeling empathy for the person who reads what you write, whether by being the actor or reviewing the design.