The problem A well-written application should have well-written error handling. There are few things more frustrating to a developer than having code that eats exceptions with no trace of the error, instead only a null value returned from a callable. On the flip side exceptions can often dump out information that you users don’t need to know or are too cryptic to be useful. Proper error handling requires a understanding few things:
The problem I recently had a family member, just out of college, ask me about finding an entry-level position in IT. While he had plenty of scholarly knowledge of principals, paradigms, and even history of technology, his CS program had done little more than promise “They are all going to be lining up to hire you when you graduate our program” to prepare him for the inevitable job hunt once all those tuition checks were cashed.
The problem I have said many times that it is easy to write code that simply “does something”. The difference between “someone who can code” and a seasoned developer comes down to a few different things, one of them being code organization/readability. I can’t count the number of projects that I expected to be short scripts, or even started as one-liners in bash, that grew into something way bigger. One of the things that can come back to bite in these projects is a reckless attitude of “It’s a small app.
The problem Quinovas does a lot of Appsync. And I mean A LOT. The first time I worked on an Appsync project the thing that stood out most to me was how bad working with VTL was. Working with VTL felt like a penance paid to the GraphQL gods for using Appsync - the tradeoff for the ease of a fully managed service.Give how much I already work with AWS Lambda I immediately started taking advantage of Lambda for datasources, removing as much need for VTL as possible.
There are often times that, as a software engineer, I want to load a function to allow for dynamic behavior in a piece of software that I’m developing. For instance, I may want to allow the users of my software to store discrete function code in a database and then dynamically load that code and use it based upon the selected database record.
For performance reasons, once that function is loaded in my program I want it to behave in my software as if it were an integral part of my software and not something loaded from an external source.
QuiNovas has published over 130 open-source projects to date, and we continue to add many more. Predominantly these projects revolve around our work, focused on DevOps in AWS and Serverless architectures in AWS.
In addition, we contribute to serveral open-source projects, with major contributions to date in python-hl7 and pydicom.
All of our open-source projects may be found in our QuiNovas Github.
Building all these open-source projects has been very rewarding (and very useful to our consulting business), if no one else knows about them they they are the equivalent of one hand clapping.
Why Every Business Needs A Data Strategy. Today’s most valued commodity, and one of the most prized assets of any business, is not traded on any mercantile exchange. At least not like other precious commodities. Yet many of the most valuable companies in the world have successfully leveraged this commodity to build and expand their businesses. This commodity, the most valuable asset of just about every business, is data.
Data as an invaluable commodity has surpassed the value of other precious commodities such as oil, gold, etc.
Syncing AWS AppSync.
The pizza war proves it every company today is a technology company.
Managing an Amazon Web Services infrastructure.