Web Development Business

Life as a Software Consultant

John Boardman Business, Consulting, Keyhole, Opinion, Other Leave a Comment

I’ve been in the field of programming professionally since 1990. I started out as a corporate employee for 14 years, then as a consultant, back to an employee, and finally settled with consulting. In both positions, I’ve worked with small, medium, large, and huge Fortune 50 corporations. There are many similarities between being an employee and a consultant, but there are also some significant differences.

In this blog, I’ll explore what life has been like in each role and hopefully give some perspective to others who might just be starting out. Keep in mind when I write “employee,” I am specifically targeting programmers.



Web Development Business

Improving Performance in Enterprise Web Applications

Zach Gardner Opinion, Programming

Every team that builds a large web application can generally pick from the following: delivering application functionality on time, with high quality, or high performance. Teams can pick one or two of the options, but they can’t pick all three.

Most teams opt to only focus on performance if and when it becomes a problem. This, unfortunately, can be far too late for some projects. Anyone who has been in the industry can empathize with both sides of the equation – choosing to defer performance concerns, as well as seeing the negative impact it can have on the success of the product as a whole.

It is a lesson I’ve learned from hard experience, so I want to make sure others can learn from my mistakes. In this post, I suggest a handful of principles that help to find a happy medium for delivering high-quality software applications while focusing on performance.

Significant improvements can be realized even if only one or two of the principles are applied. Applying all of them, of course, will produce the best results.



OWASP Dependency Check for Vulnerability Reporting

John Hoestje Java, Security, Technology Snapshot, Tutorial Leave a Comment

TL;DR: Add OWASP Dependency-Check to your build process to get insight into your dependency vulnerabilities.

Recent major data losses and security vulnerabilities in open source frameworks *(and the applications that use them)* have caused the companies that use those frameworks to have elevated concerns regarding vulnerabilities. The elevated awareness is for good reason, too. After all, no one wants to be the next one to lose sensitive data, be the punching bag of others, or be the example of what *not* to do security-wise.

If you happen to be in a group that doesn’t have any open source vulnerability reporting, OWASP Dependency-Check may be your short-term answer to get at least something in place. Adding OWASP Dependency-Check into your build process takes a relatively low effort. Other than not having the technology that stack Dependency-Check can help you with, there isn’t a reason not to at least add Dependency-Check to give a little insight into your open source dependencies.

The following parts will help you get Dependency-Check integrated into your Java project’s build process. The instructions will be adaptable to the other technologies Dependency-Check supports, like Gradle or JavaScript. Dependency-Check is also available as a command line tool for your favorite OS. In this example, I’ll use a Java project with Maven….



Rethinking REST Practices: An Introduction to GraphQL with AWS AppSync

Mat Warger Amazon Web Services, AWS, JavaScript, Programming, Technology Snapshot Leave a Comment

The basic premise of data transfer and involves requesting and receiving lists. This is simplistic, but it gets to the root of why we’ve developed the technologies and best practices to pass data using web services. RESTful APIs have grown to serve the needs of numerous individuals, startups, and enterprise companies across the world. They are useful, productive, and the concepts surrounding them are relatively standardized. If you don’t know how to create one, you can quickly find information building a great API that can grow to fit your needs. That’s when things get complicated…

If you start digging into REST, you’ll realize there’s quite a bit more to throwing lists. There are common threads that many people encounter when developing an API, and you begin to encounter many of the same questions so many others have before, such as: How strictly should you adhere to the principles of REST? How should you handle versioning? Should you bother? How do you want to structure your objects? Are users able to easily figure out what API endpoints are available and how they should be used?

There are many ways approach these. It boils down to communicating the structures that a given endpoint will return or accept. The cascade of questions that results from the choices made here will ripple through from the back-end to the client. The secondary issue is that these questions and choices are not at all uncommon. There are answers to these that follow Best Practices. But there is still plenty of ambiguity involved when attempting to build a flexible API that works well. These are the Commonly Tolerated Situations.

If you hadn’t already guessed, there is a solution that frees us from the dogma of REST and allows us to solve all these issues in a declarative, powerful, and fun way. That solution is GraphQL. In this blog, I’ll provide an introduction to the GraphQL specification with code examples…