I need help. I want to find sponsors for my Software Quality Award, but don't have time and connections to do that. Would you be interested to volunteer and help me? We need more money for the award, to better motivate programmers. Please, email.
At Webinar #19 we'll discuss the role of a project manager in a software project, join us on December 7, at 11am PST.
Constants... I wrote about them some time ago, mostly saying that they are a bad thing, if being public. They reduce duplication, but introduce coupling. A much better way to get rid of duplication is by creating new classes or methods—a traditional OOP method. This seems to make sense and in our projects I see less and less public constants. In some projects we don't have them at all. But one thing still bothers me: unit tests. Most programmers seem to think that when static analysis says that there are too many similar literals in the same file, the best way to get rid of them is via a private static literal. This is just wrong.
It's not just about InputSteam, this class is a good example of a bad design. I'm talking about three overloaded methods read(). I've mentioned this problem in Section 2.9 of Elegant Objects. In a few words, I strongly believe that interfaces must be "functionality poor." InputStream should have been an interface in the first place and it should have had a single method read(byte). Then if its authors wanted to give us extra functionality, they should have created supplementary "smart" classes.
Using object properties as configuration parameters is a very common mistake we keep making mostly because our objects are mutable—we configure them. We change their behavior by injecting parameters or even entire settings/configuration objects into them. Do I have to say that it's abusive and disrespectful from a philosophical point of view? I can, but let's take a look at it from a practical perspective.
Annotations were introduced in Java 5, and we all got excited. Such a great instrument to make code shorter! No more Hibernate/Spring XML configuration files! Just annotations, right there in the code where we need them. No more marker interfaces, just a runtime-retainedreflection-discoverable annotation! I was excited too. Moreover, I've made a few open source libraries which use annotations heavily. Take jcabi-aspects, for example. However, I'm not excited any more. Moreover, I believe that annotations are a big mistake in Java design.
Revenue means cash that is coming into your bank account every month from your customers. Not investors. Customers, those who are buying your products or services. You are doing everything you can to make sure this number grows, mostly because you use this money to pay your rent, buy food, and settle that graphic designer's invoices. Without revenue, your startup will die, right? Yes, maybe. But in my experience, growing revenue may kill it even faster.
Getters and setters are evil. No need to argue about this, it's settled. You disagree? Let's discuss that later. For now, let's say, we want to get rid of getters. The key question is how is it possible at all? We do need to get the data out of an object, right? Nope. Wrong.
CDN stands for a Content Delivery Network. Technically, it is a bunch of servers located in different countries and continents. You give them your logo.gif and they give you a URL, which resolves to a different server depending on who is trying to resolve it. As a result, the file is always close to the end-user and your website loads much faster than without a CDN. Sounds good, but all CDN providers want money for their service and usually a rather complex setup and registration procedure. My pet project jare.io is a free CDN that is simple to configure. It utilizes AWS CloudFront resources.
Your success depends on the quality of your elevator pitch. Basically, your success doesn't depend on much of anything else. The pitch is king. You have to impress the catcher investor in just a few seconds while the elevator is still moving (that's where you are supposed to hunt for that prey). It's not rocket science; you can learn a few basic principles and become a expert. Here they are, the principles.
There is a very typical mistake in pre-Java7 "try/finally" scenario, which I keep seeing in so many code reviews. I just have to write about it. Java7 introduced a solution, but it doesn't cover all situations. Sometimes we need to deal with non-AutoCloseable resources. Let's open and close them correctly, please.
I'm taking participation in over 50 repositories in GitHub. We manage all of our projects there. GitHub is sending me hundreds of emails every day. I'm serious. Hundreds! I tried to filter them somehow in Gmail, but it's not really possible. Gmail filters are not powerful enough to understand the difference between different types of notifications, and there are many other problems. I decided to create my own simple filtering machine. It's called wring.io.