There are basically two ways to validate a situation in Java and complain when something unexpected happens. It's either an exception or an assertion. Technically, they are almost the same, but there are some small differences. I believe that exceptions are the right way to go in all situations and assertions should never be used. Here's why.
I was talking yesterday with a few friends who were software conference organizers. They were asking about my opinion of the conferences I've recently attended. Basically, they were interested to know what I would suggest for improvement. So, I decided to summarize it in a list of the most typical mistakes all conferences keep making and give them some ideas. Remember, I'm judging from a speaker's position. The most serious mistakes and pieces of advice are at the bottom.
A project manager is very often confused with a leader. However, they are two very different things. A project manager is the one who predicts the future, while a leader is the one who builds it. And, in my opinion, a perfect project manager is much more valuable for a project than a leader. If a leader is valuable at all...
"Convertible Notes" is what you most likely will hear the first time you get money for your first startup. They will give you cash asking to give them the convertible notes (or SAFE, which is very similar). Convertible notes are just a few pages of paper with two signatures at the bottom. Not too much to worry about. It's basically a contract between your startup and an investor. Let's see what exactly it says and what you, as a founder, should pay attention to.
Over the last six months, I've attended 18 conferences and heard over 30 keynote sessions, mostly about software development and management. I think I now know all the secrets of a successful keynote speaker. It doesn't look so difficult to become one. Here are my thoughts.
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.