Our blogs walk you through usecases and show you how to make the most of CodeScene and your code. Our developers share best practices and cover topics less explored, but so valuable to development organizations.
Often, discussions and tutorials about refactoring focus on object-oriented languages. It's not clear if this stems from the fact that Martin Fowler's absolute masterpiece, Refactoring: Improving the Design of Existing Code, targets OO, or if it's simply that OO is still the dominant paradigm in the code out there needing refactoring, or some other reason.
"Am I getting satisfactory code coverage?" Over the years, this had become the question I asked myself to decide what unit tests to write. And I have to admit it was extremely satisfying to see the green bars in the CI/CD pipeline on my pull requests. But on joining CodeScene, I have been forced to re-visit my reasons for writing automated tests, coming up with more intelligent questions to guide me in my decisions.
I have sometimes heard people say that with the introduction of React's functional components, it's natural to expect functions to become larger and more complex. After all, the components are written as "one function", and therefore you have to accept a bit of swelling. It is also stated in React's documentation that:
In our staging environment, we recently found an odd issue: it was returning blank pages - for some people, sometimes. Unable to reproduce the problem on their machine, developers started suspecting it’s an infrastructure issue.
AWS Secrets Manager is a great place to store secrets that are needed by somebody else (machines or people) if you are running your infrastructure on AWS.
I started my career working for an enterprise, but after a while I changed my path and started working for CodeScene, which is still a startup. I thought it would be fun to share my experience of working with these two types of organizations. But I'll also share my thoughts on why I believe everyone should have a startup experience. Coming to CodeScene breaks all my stereotypes about the IT world and the way it works.
Let me tell you a story about debugging a problem with our CI build including unexpected dependencies via lein uberjar.
Work, on a software project is often linear. Point A to point B. From bug to fix. From task to release. Of course, the process might be complex, with iterations, reviews, forks and branches. In the end, those are just the wheels of train taking the project to where it needs to be. Ideally, cards just speed across the kanban, left to right.
This is a description of a high-level performance optimization workflow, primarily focusing on optimizing the design of our program, it's algorithms and data structures, and ignoring low-level optimizations unless its absolutely necessary.
If you know the size of your input beforehand, it should be safe to leave out the padding character ('=') so you don’t need to percent-encode it for safe usage in URLs.
