Friday
Jan192024

Schedule a Meeting with Me

Click Meeting to schedule a meeting with me.

Friday
Jan192024

Mobile Hobby Apps Research

Wednesday
Oct182023

Redefining Error Monitoring: Breaking Free from Brittle Logs

In recent years, the landscape of error monitoring has undergone a significant transformation. Traditional log-based approaches, while invaluable for root cause analysis, have shown their brittleness in the face of evolving software applications. However, the good news is that it's now easier than ever to break free from the shackles of brittle logs and adopt a more reliable error monitoring strategy. This transformation has been made possible by tools like Micrometer, a powerful metrics collection library, and AWS EventBridge, a versatile event bus, each offering distinct approaches to error monitoring.

Micrometer has emerged as a game-changer in the world of error monitoring by providing developers with a simple and consistent way to emit custom metrics and events from their applications. Spring Boot, a popular framework in the Java ecosystem, has seamlessly integrated with Micrometer, making it incredibly easy for developers to harness its capabilities. By leveraging Micrometer, you can emit distinct error events, separate from your regular logs, that are designed to be stable and reliable. These events serve as beacons, allowing your monitoring and alerting systems to pinpoint critical issues, even as your application evolves.

On the other hand, AWS EventBridge offers an alternative approach to error monitoring. It acts as a centralized event bus that seamlessly connects various AWS services and third-party tools. By emitting error events to EventBridge, you can effortlessly integrate with a wide range of monitoring and alerting tools, such as AWS CloudWatch, Datadog, or even custom applications. This means that not only can you reliably capture errors, but you can also set up sophisticated workflows and responses based on these events. The result is a monitoring ecosystem that's both robust and flexible, adapting to your specific needs and evolving alongside your application.

In conclusion, the days of relying solely on brittle logs for error monitoring are behind us. Thanks to tools like Micrometer and AWS EventBridge, error monitoring has become more accessible and reliable than ever. Whether you choose the integrated simplicity of Micrometer with Spring Boot or the versatility of AWS EventBridge, you can ensure that your application's critical issues are detected and acted upon, regardless of how your application evolves. It's a transformation that empowers developers to build more resilient and responsive software systems while gaining deeper insights into application behavior.

Wednesday
Oct182023

Codebase Resurrection: From JavaMUG to the Houston JUG

I'm thrilled to share the exciting evolution of my presentation, "Codebase Resurrection: Revive and Refactor with AI," which I first introduced at JavaMUG. The experience was nothing short of amazing, with a warm reception, valuable feedback, and lessons that have fueled my passion for this topic. Now, I'm gearing up to take this journey to the next level at the Houston JUG next month.

Reflecting on JavaMUG

At JavaMUG, I had the privilege of sharing my insights and experiences with a wonderful audience. The main theme was clear: codebases often need a major overhaul, and developers frequently find themselves wrestling with tangled code, unsure of how to proceed. My mission was to show them how AI could be their secret weapon in the battle against subpar code.

With enthusiasm and passion, I guided attendees through the transformative journey of leveraging Codium.AI. This AI plugin combines the best practices and methodologies from industry experts with the precision of artificial intelligence. The audience was captivated by the potential of AI to bring codebases back to life.

A Sequel Worth Waiting For

Now, as I prepare for the Houston JUG, I'm excited to revisit and refine the core theme that resonated so strongly with the JavaMUG audience. Together, we'll dive deep into real-world examples, engage in live coding exercises, and explore captivating insights from my experiences.

I'll demonstrate how Codium.AI empowers developers to conquer code chaos and make well-informed refactoring decisions. The uncertainty that often accompanies codebase maintenance will be replaced by the guidance of AI, making the process smoother and more efficient.

Just Starting


During the live coding


Monday
Aug072023

Springboot 3.0 

Sunday
Feb262023

Stakeholders/Leaders/Boses

Stakeholder the development team is a stakeholder in the product they are creating.

Boses have you do a boarding on a vessel.

Leaders actually will bring you home alive from a boarding!

Friday
May282021

My Route for High Low Trip

Wednesday
Dec232020

Stacktraces rock what if you had nothing instead!

Try debugging a failure with a log  "application started" vs "java.lang.StringIndexOutOfBoundsException: String index out of range: 97 at java.lang.String.charAt(String.java:686) at AvLetter.main(AvLetter.java:14)"

 

Thursday
Jul022020

Awesome Quote

“You cannot antagonize and influence at the same time.”

John Knox

Friday
May012020

New Quote after reading some code

It is easy to write code, it is hard to author code! - David Parry

Wednesday
Feb122020

Getting Groovy with Spock

Great time giving my Spock Testing Framework

https://www.javamug.org/meeting/224

Thursday
Nov072019

Less than a day Java Developer on boarding

I currently am between gigs and in interviewing was questioned with skepticism about my claim of less than a day to on board a professional developer. The first thing is to define on boarding and how to measure success in the context of a “Professional Software Developer” on boarding.

First to note, I quoted Professional Software Developer if you are not starting with a developer who has taken an oath similar to The Programmers Oath, then all stop! Question why and how this member got past interviewing.

In no way am I speaking about the all-star 10x developer who looks at the project and in 2 minuets rewrites it.

Ok so I am sure there are many more “what about” and “you forgot”. This brings me to the last point, David you are giving away the secret sauce everyone will just take your process and methodology and run with it. I say great if it helps and you can do implement it great maybe my next job, I will benefit from it and start contributing to the project.

 

As the below title eludes too you must first have a proper development shop. No one is perfect and not all of these items need to be followed this is why I can write this with confidence that unless you have experience with multitude of teams building projects/products you will not know what things are needed and what ones complement the others. Stop do not try to bring on another developer on board until your house is order. I argue if they are a professional developer this showed be a sign to them.

 

Development House in order first:

1.     Assessment of the current development environment;

a.     Source Control (reference) does the team love or hate it. Can the management explain the reason for which version is being used?

                      i.     Git

                      ii.     Subversion

b.     Project Build Tools, can the full lifecycle of the build be completed on CI and developer machine?

                      i.     Gradle

                      ii.     Maven

                      iii.     Ant

c.     IDE Battle, this can be directly connected to subpoint b, for a number of reasons:

                      i.     The project can only be built in the IDE

                      ii.     The project has dependencies added to it like OS, certain licensed binaries not available on developer box.

                      iii.     IMHO IDE lock-in or cannot build on developer machine points to design decisions that need to be addressed.

                      iv.     My opinion a developer should choose their IDE if they are a professional, they have learned productivity tasks for that IDE as a Professional that you will want to take advantage and even learn. Nothing like my favorite shortcut for my IDE to break the ice in introducing the new member.

2.     The day in the life of a Professional Developer (Beatles 2:21 start)

a.     Code Review, what does it look like, the process tools used to capture the feedback the vibe around the review, who is ultimately responsible for the code? Many of these questions deserve their own post that maybe I will someday write.

b.     Any branch check-in results in the automated static analysis tools running. Let the tools be the bad reviewer not allowing you to merge, the reviewer should be worried about the business logic you are implementing not curly braces and spacing. The reviewer should flag any design or architecture changes the code may be introducing.

c.     Unit Tests testing the code; Junit, Spock and what is measuring the quality of the test Jacoco.

d.     Do they have a fail fast mentality, fail on static analysis, unit tests not passing?

e.     What is the branching strategy is there a merge often fail fast or a wait and merge hell at the end?

3.     Continuous Automated Integration Builds;

a.     What CI are they using does it integrate seamlessly with the development build tools.

b.     This is key do the developers own the build server and the responsibility of keeping it building or is it to the junior IT staff guy?

c.     Is there a continuous feedback loop of failures is it public to the entire organization? Does the organization care or understand what it means?

d.     I have seen countless times setting up and running the builds and making sure all executives have view into the health of the product. Neat story is one time at a startup i.e. the Product was the only thing the company was based on and the top executive stated he did not really care or had the time to worry about the failure or health of the Product.

e.     How many branches are being built, do different pipelines build and run different tasks based on branch and tagging?

 

Finally, you say we have come to the truth how is it done. A little hint if you have not guessed many reasons for slow developer ramp up is nothing to do with what should be a simple process, instead it has to do with the current environment you are introducing them into.

 

Process:

Spend 30 minutes reviewing the high-level architecture of the system or product. Allow for 30 minutes for in-depth questions. 20 minutes the developer now explains back to you what the overall driving design of the product is and what the product does. Example, a set of Docker Swarm services that run in Azure that use Redis for shared state and MongoDB as a document store. The product provides a web front end written Angular that allows the customer to store a headshot and bio about themselves for Hollywood talent agents. Here is the next gotcha of the process if you have one monolithic project then stop the only developer you should be bringing on is one that can help you break apart the monolith into manageable pieces. I would recommend a Microservices approach Martin Fowler is a good start to understand it. So, we have a set of projects each one doing one thing very well. This is the test you now should review the tools, design and architecture choices this single service project is using. Example would be this is a Spring boot application that connects to MariaDB using JPA framework with a set of restful services that our called from a http client. Depending on the professional developer git, IDE, java, groovy is installed and ready to go.

If the “professional?”  needs help then spend the 30 minutes tops to install these tools. You may say hey what about a new hired graduate. I say you will be surprised they may be far better off than the crusty developer, if this is not the case, I argue they are not professional yet. All stop this recipe is not going to work for them and not fair to them either.

Ok developer has the basic tools installed now have them build the project. Should take since the project does one thing very well about 1 to 3 tops to build tests and reports fully.

Now pick one part of the code base that either does not have test coverage or needs more documentation and have the developer write one-unit test that asserts what they think the method should be doing major score if they find a failure or bug logic one you owe them beer. Have them assign a code review/merge request, you pair review the request to show them the process for code review and see if they grok the piece of code.

Finally, after discussion and fixing from comments merge the request. The picking should already be decided so everything after that should take 2 hours tops.

I say you now have a professional developer with their tools to produce code installed, tested, working and first commit for them they are ready to get a Story or Bug and start working.

 

 

 

 

Sunday
Nov032019

Product I Designed and Developed

Sunday
Dec022018

Testing conductivity in JRedisSearch to Redis without a previous created Index

The Client Class, which wraps all connection and command calls to the RediSearch module, requires an index when creating an instance.

Any Client method invocation that cannot be connected to Redis with the connection information provided when calling the constructor you will get the following exception JedisConnectionException from Jedis this exposes the jedis api to all users of the JRediseach api.

If the connection information works and there is a successfull connection but the index used is not present then any valid call to the methods in the Client class will result in various exceptions depending on the call accept the one to createIndex which will create the index.

Examples:

 

  • dropIndex(boolean) will return false but really the api is suppressing the thrown exception that the index was not found.
  • getInfo() which will throw an “JedisDataException: Unknown Index name”.

 

None of these approaches are ideal but for now my vote would be to call getInfo since no harm can happen, dropIndex and others can actually alter the index if it did all ready exsist.

Reference to the API docs http://davidparry.com/storage/jrediseach-javadoc-v0-19-0/docs/io/redisearch/client/Client.html

 

Friday
Nov302018

Microstack Developer

Definition of Microstack: A set of Microservices developed to provide a coherent set of API's, UI/UX, Security and bridging legacy systems.

The popularity of Microservices has grown and many large companies have started to adopt Microservices. There are many books, blogs and opinions... on Microservices and their implementation. I have been using the term Microstack, to address the fact that the past traditional Fullstack way of development does not cut it. A colleague of mine never heard this before and has encouraged me to describe it. Hence the definition in this blog post to capture what I believe is the coining of the term Microstack.

In my own experiences in deploying the complete solution of Microservices there is a growing need for the Development, Architecture and Devop teams to work together to produce a complete deployable solution for Production. This new type of Microstack Team will address the needs of the stack to make a Production Product successful.


Thursday
Nov152018

JRedisearch Workshop

The talk @ JavaMUG, December 12, 2018 was fun and a success!

The Github account that has all the exercises can be found here https://github.com/davidparry/JRediSearchWorkshop

Some photos and screenshots to capture the talk for future reference.

Sunday
Jul082018

Inspiration Development

"Excuses do not compile" - David Parry #developer #quote
“Java is to JavaScript what car is to Carpet.”   - Chris Heilmann
  "Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”   - Martin Fowler
 “First, solve the problem. Then, write the code.”  - John Johnson
 “Talk is cheap. Show me the code. "  -Linus Torvalds
"Code does not lie." -David Parry
Walking on water and developing software from a specification are easy if both are frozen. ” - Edward V Berard
Programming is the real test of your creativity,its all about how you turn your ideas into codes. - Shreyansh Dwivedi
“[I do not] carry such information in my mind since it is readily available in books." - Albert Einstein
 

 

Tuesday
Jan162018

Digital Play Date DpD

#DpD : When 2 children make plans to meet digitally to either play a collaborative game like first person shooter or to watch youtube together and chat about the videos.

Friday
Jul312015

DavidWidgets Android Project

I have decided to take some of my code that I use on my own projects in Google Play and create a Library so they can be used in others projects. 

I also look forward to others inputs, code contributions please feel free to add to my code and request a pull request. I am excited to see what others think and to learn from others too.

https://github.com/davidparry/DavidWidgets

Thursday
May082014

Participant Content Context Switching PCCS

Definition: The act of disengaging from a piece content that a viewer or active participant were currently captivated by. The content usually but not exclusive to; video, webpage or interactive game.
Descriptions of PCCS: A player of Angry Birds stops playing by clicking on the popup advertisement that caught the users interest. A viewer of a TV show when an advertisement starts switches to view another channel during that commercial, this is not to be confused with channel surfing where a viewer is constantly changing channels from becoming disinterested in the current program. A viewer of a show, stream or video during that instance the user interacts with a responsive advertisement placed within the show.