As a frequent contributor to open source projects (both within and beyond Red Hat), I find one of the most common time-wasters is dealing with code reviews of my submitted code that are negative or obstructive and yet essentially subjective or argumentative in nature. I see this most often when submitting to projects where the maintainer doesn’t like the change, for whatever reason. In the best case, this kind of code review strategy can lead to time wasted in pointless debates; at worst, it actively discourages contribution and diversity in a project and creates an environment that is hostile and elitist.
A code review should be objective and concise and should deal in certainties whenever possible. It’s not a political or emotional argument; it’s a technical one, and the goal should always be to move forward and elevate the project and its participants. A change submission should always be evaluated on the merits of the submission, not on one’s opinion of the submitter.
Continue reading “10 tips for reviewing code you don’t like”
Container-native development is primarily about consistency, flexibility, and scalability. Legacy Application Lifecycle Management (ALM) tooling often is not, leading to situations where it:
- Places artificial barriers on development speed, and therefore time to value,
- Creates single points of failure in the infrastructure, and
- Stifles innovation through inflexibility.
Ultimately, developers are expensive, but they are the domain experts in what they build. With development teams often being treated as product teams (who own the entire lifecycle and support of their applications), it becomes imperative that they control the end-to-end process on which they rely to deliver their applications into production. This means decentralizing both the ALM process and the tooling that supports that process. In this article, we’ll explore this approach and look at a couple of implementation scenarios.
Continue reading “Application lifecycle management for container-native development”
Knative is not just a hot topic in software development, it’s a whole new way to look at services and functions. As a developer, what do you need to know to take advantage of this cutting-edge technology? Are there important design or implementation considerations? Let’s take a look.
Continue reading “Knative: What developers need to know”
In most glibc-based operating systems, there’s a file /etc/nsswitch.conf that most people ignore, few people understand, but all people generally rely on. This file determines where the system finds things like host names, passwords, and protocol numbers. Does your company use LDAP? NIS? Plain files? The nsswitch file (it stands for “name services switch”) tells the system what service to use for each type of name lookup.
Continue reading The Non-complexity of /etc/nsswitch.conf
If you haven’t heard about the RISC-V (pronounced “risk five”) processor, it’s an open-source (open-hardware, open-design) processor core created by the University of Berkeley. It exists in 32-bit, 64-bit, and 128-bit variants, although only 32- and 64-bit designs exist in practice. The news is full of stories about major hardware manufacturers (Western Digital, NVidia) looking at or choosing RISC-V cores for their product.
Continue reading Why you should care about RISC-V
Excitement and Nervousness are part of one’s life whenever someone is about to live his dream or someone is too happy for something and so was the time when we gathered for the Red Hat Graduate Program at Red Hat Pune office to start the amazing journey as an intern.
It’s been more than a month now, we are so bound with the open culture that if we would still think of a second option after some time it could probably go off the mind because of only one reason and it could be the Open culture here. It is always noted that one common thing in hand always has related dependencies following it, it is the case with freedom, here FREEDOM is backed with RESPONSIBILITIES and thus you need to be a responsible person always if you think of leveraging the fun in freedom.
Continue reading “A walk down the Red Hat lane”
The idea that once our code is working, we are good to go is a very bad idea. An idea that needs to be reevaluated and analyzed. When you buy a car, it works at first, and then it begins to develop faults. Do you have to wait for the car to develop faults before you begin maintaining it? Well, the answer is obvious and the answer is NO.
But why then do we have to do the same thing to our code. Once a piece of code works or passes that test, we close that code and never ever look back. Even the car at Toyota passed the test before it was delivered to the client, but it also has to be maintained. Some people would argue that code maintenance is far more different from maintaining a car, but I would beg to differ. What is maintained in whatever form is better than what is never maintained?
Continue reading “Code Maintenance”
A lot of employees work on customers’ sites and need to engage people every single day. Mobile Internet isn’t something broadly reliable, which makes demonstrations of cloud products and complex solutions undoable.
After thinking about it for some time, I finally got something good, which I’d like to share with you in this post.
Microservices is probably one of the most popular buzz words among my fellow developer friends, and I do like the concept of being flexible, agile and having simply having more choices. But as a person that worked in the software integration space for years, I started to see some resemblance of the old ESB days.
Looking at the problem from ten thousand feet up. A decade ago, we had to come up with a better way of organizing the spaghetti connection in between systems, stop duplicating effort on the same piece of business logic. That is when service-oriented architecture (SOA) became popular. By modularizing services, sharing them among others systems, and organize ways of communication, routing of data. And ESB is one implementation of that, maybe not necessarily how it should be done.
Continue reading “Organizing Microservices – Modern Integration”
Integration is still around but in a different form. So, what does modern integration look like? Looking at how agile scrum has taken over traditional waterfall development framework, by enabling shorter delivery cycles, faster feedback, and having the flexibility to rapidly adapt to changes. I believe it’s time for traditional integration to be agile again. By breaking up traditional ESB into distributed microservices.
Continue reading “Reference Architecture for Agile Integration”