I’ve been using Bootstrap for more than two years in multiple projects, and my frustration has been building. First of all, it’s too massive for a small web app. Second, it is not fully self-sufficient; no matter how much you follow its principles of design, you end up with your own CSS styles anyway. Third, and most importantly, its internal design is messy. Having all this in mind, I created tacit, my own CSS framework, which immediately received positive feedback on Hacker News.
Type casting is a very useful technique when there is no time or desire to think and design objects properly. Type casting (or class casting) helps us work with provided objects differently, based on the class they belong to or the interface they implement. Class casting helps us discriminate against the poor objects and segregate them by their race, gender, and religion. Can this be a good practice?
The problem is that Rultor is running all scripts inside Docker containers and Docker can’t build Windows projects. The only and the best logical solution is to trigger AppVeyor before running all other scripts in Docker. If AppVeyor gives a green light, we continue with our usual in-Docker script. Otherwise, we fail the entire build. Below I explain how this automation was configured in Takes framework.
JAXB is a 10-year-old Java technology that allows us to convert a Java object into an XML document (marshalling) and back (unmarshalling). This technology is based on setters and getters and, in my opinion, violates key principles of object-oriented programming by turning objects into passive data structures. I would recommend you use Xembly instead for marshalling Java objects into XML documents.
I used to utilize Servlets, JSP, JAX-RS, Spring Framework, Play Framework, JSF with Facelets, and a bit of Spark Framework. All of these solutions, in my humble opinion, are very far from being object-oriented and elegant. They all are full of static methods, un-testable data structures, and dirty hacks. So about a month ago, I decided to create my own Java web framework. I put a few basic principles into its foundation: 1) No NULLs, 2) no public static methods, 3) no mutable classes, and 4) no class casting, reflection, and instanceof operators. These four basic principles should guarantee clean code and transparent architecture. That’s how the Takes framework was born. Let’s see what was created and how it works.
I read a few technical specifications every week from our current and potential clients, and there’s one thing I can’t take anymore; I have to write about it: 99 percent of the documents I’m reading don’t have glossaries, and because of that, they are very difficult to read and digest. Even when they do have glossaries, their definitions of terms are very vague and ambiguous. Why is this happening? Don’t we understand the importance of a common vocabulary for any software project? I’m not sure what the causes are, but this is what a software architect should do when he or she starts a project—create a glossary.
Manager. Controller. Helper. Handler. Writer. Reader. Converter. Validator. Router. Dispatcher. Observer. Listener. Sorter. Encoder. Decoder. This is the class names hall of shame. Have you seen them in your code? In open source libraries you’re using? In pattern books? They are all wrong. What do they have in common? They all end in “-er.” And what’s wrong with that? They are not classes, and the objects they instantiate are not objects. Instead, they are collections of procedures pretending to be classes.
There are plenty of books, articles, and blog posts about team morale. They will all suggest you do things like regular celebrations, team events, free lunches, pet-friendly offices, coffee machines, birthday presents, etc. All of these are instruments of concealed enslaving. These traditional techniques turn employees into speechless monkeys, programming under the influence of Prozac. Their existence and popularity is our big misfortune. Let me present my own vision of how team morale can be boosted on a software team—a team that has a good project manager.
The decorator pattern is my favorite among all other patterns I’m aware of. It is a very simple and yet very powerful mechanism to make your code highly cohesive and loosely coupled. However, I believe decorators are not used often enough. They should be everywhere, but they are not. The biggest advantage we get from decorators is that they make our code composable. That’s why the title of this post is composable decorators. Unfortunately, instead of decorators, we often use imperative utility methods, which make our code procedural rather than object-oriented.
I received a haircut today, and the niceness of my hairdresser led him to fill the appointment with courteous questions about how I wanted my hair cut, what size of clipper he should use, how long the sides should be, and how much should be removed from the front. He also offered me many types of shampoo and a cup of tea. All this reminded me of the work we do as programmers, and I decided to write a short post about it. I’ve already mentioned before that trying to make a customer happy is a false objective. This hairdresser was a perfect illustrative example of this very mistake. By the way, in the end, I wasn’t happy, and he got no tip. How could this happen if he was so friendly and nice?
I was recently accused of being against functional programming because I call utility classes an anti-pattern. That’s absolutely wrong! Well, I do consider them a terrible anti-pattern, but they have nothing to do with functional programming. I believe there are two basic reasons why. First, functional programming is declarative, while utility class methods are imperative. Second, functional programming is based on lambda calculus, where a function can be assigned to a variable. Utility class methods are not functions in this sense. I’ll decode these statements in a minute.
At Zerocracy, we work in distributed teams and keep all our communications in tickets. Besides that, we encourage every developer on every project to report bugs whenever he or she finds them. We even pay for each bug found. Once in a while, I see bugs reported along these lines: “Can someone explain to me how to design this module?” or even “I haven’t used this library before; please help me get started.” My usual answer is, “This is not a school; nobody is going to teach you here!” I realize this sounds rather harsh to most developers who are just starting to work with us, so here I’ll try to illustrate why such an attitude makes sense and is beneficial to both the programmers and the project.
Disclaimer: I’m talking about software projects here, which PMBOK defines as “temporary endeavors undertaken to create unique products, services, or results.” If your team is engaged in continuous development or maintenance of software, this concept may not be relevant.
First, no matter what the methodology is, we all write software for our users (a.k.a. customers, project sponsors, end users, or clients). Second, no matter what the methodology is, we write incrementally, releasing features and bug fixes one by one. Maybe I’m saying something absolutely obvious here, but it’s important to remember that each new version should first of all satisfy the needs of the user, not of us programmers. In other words, the way we decompose a big task into smaller pieces should be user-targeted, and that’s why you always work top down. Let’s see what I mean through a practical example.
Code reviews (a.k.a. peer reviews) must be a mandatory practice for every serious software development team. I hope there is no debate about this. Some do pre-merge code reviews, protecting their master/development branch from accidental mistakes. Others do post-merge regular reviews to discover bugs and inconsistencies after they are introduced by their authors. Some even do both, reviewing before merges and regularly after. Code reviews are very similar to a white-box testing technique where a tester looks for defects with full access to the sources of the software. In either case, a code review is a great instrument to increase quality and boost team motivation.
Maven is a build automation tool mostly for Java projects. It’s a great tool, but it has one important drawback that has motivated the creation of similar tools, like Gradle and SBT. That weakness is its verbosity of configuration. Maven gets all project build parameters from pom.xml, an XML file that can get very long. I’ve seen POM files of 3,000-plus lines. Taking into account 1) recent DSL buzz and 2) fear of XML, it’s only logical that many people don’t like Maven because of its pom.xml verbosity.
But even if you’re an XML fan who enjoys its strictness and elegance (like myself), you won’t like the necessity to repeat yourself in pom.xml for every project. If you’re working on multiple projects, code duplication will be enormous. An average Java web app uses a few dozen standard Maven plugins and almost the same number of pretty common dependencies, like JUnit, Apache Commons, Log4J, Mockito, etc. All of them have their versions and configurations, which have to be specified if you want to keep the project stable and avoid Maven warnings. Thus, once a new version of a plugin is released, you have to go through all pom.xml files in the projects you’re working on and update it there. You obviously understand what code duplication means. It’s a disaster. However, there is a solution.
XSL transformation (XSLT) is a powerful mechanism for converting one XML document into another. However, in Java, XML manipulations are rather verbose and complex. Even for a simple XSL transformation, you have to write a few dozen lines of code—and maybe even more than that if proper exception handling and logging is needed. jcabi-xml is a small open source library that makes life much easier by enabling XML parsing and XPath traversing with a few simple methods. Let’s see how this library helps in XSL transformations.
We all have bosses. We also have customers who pay us for running their software projects. They are my bosses for the time of the contract. I’m also acting as a boss for developers who are working for Zerocracy. It is obvious that a good employee/contractor is one who makes his boss/customer happy. But only a bad employee works toward this goal. Trying to make your boss happy is a false target that, if pursued, ruins the project. A professional employee works for the project, not for the boss.
You have a task assigned to you, and you don’t like it. You are simply not in the mood. You don’t know how to fix that damn bug. You have no idea how that bloody module was designed, and you don’t know how it works. But you have to fix the issue, which was reported by someone who has no clue how this software works. You get frustrated and blame that stupid project manager and programmers who were fired two years ago. You spend hours just to find out how the code works. Then even more hours trying to fix it. In the end, you miss the deadline and everybody blames you. Been there, done that?
Do you name variables like textLength, table_name, or current-user-email? All three are compound names that consist of more than one word. Even though they look more descriptive than name, length, or email, I would strongly recommend avoiding them. I believe a variable name that is more complex than a noun is a code smell. Why? Because we usually give a variable a compound name when its scope is so big and complex that a simple noun would sound ambiguous. And a big, complex scope is an obvious code smell.
The purpose of Continuous Integration is to tell us, the developers, when the product we’re working on is not “packagable” any more. The sooner we get the signal, the better. Why? Because the damage will be younger if we find it sooner. The younger the damage, the easier it is to fix. There are many modern and high-quality hosted continuous integration services, but only one of them (to my knowledge) supports Windows as a build platform—appveyor.com. My experience tells me that it’s a good practice to continuously integrate on different platforms at the same time, especially when developing an open source library. That’s why, in Zerocracy we’re using AppVeyor in combination with Travis.
A stand-up meeting (or simply “stand-up”) is “a daily team-meeting held to provide a status update to the team members,” according to Wikipedia. In the next few paragraphs, I attempt to explain why these meetings, despite being so popular in software development teams, are pure evil and should never be used by good managers.
I’m not saying they can be done right or wrong; there are plenty of articles about that. I’m not trying to give advice about how to do them properly so they work, either. I’m saying that a good manager should never have daily stand-ups. Because they not only “don’t work” but also do very bad, sometimes catastrophic, things to your management process, whether it’s agile or not. On the other hand, a bad manager will always use daily stand-ups as his or her key management instrument.
Most of our clients are rather surprised when we explain to them that they will have full access to the source code from the first day of the project. We let them see everything that is happening in the project, including the Git repository, bug reports, discussions between programmers, continuous integration fails, etc. They often tell me that other software development outsourcing teams keep this information in-house and deliver only final releases, rarely together with the source code.
I understand why other developers are trying to hide as much as possible. Giving a project sponsor full access to the development environment is not easy at all. Here is a summary of problems we’ve been having and our solutions. I hope they help you honestly show your clients all project internals and still keep them on board.
After a few recent posts about immutability, including Objects Should Be Immutable and How an Immutable Object Can Have State and Behavior?, I was surprised by the number of comments saying that I badly misunderstood the idea. Most of those comments stated that an immutable object must always behave the same way—that is what immutability is about. What kind of immutability is it, if a method returns different results each time we call it? This is not how well-known immutable classes behave. Take, for example, String, BigInteger, Locale, URI, URL, Inet4Address, UUID, or wrapper classes for primitives, like Double and Integer. Other comments argued against the very definition of an immutable object as a representative of a mutable real-world entity. How could an immutable object represent a mutable entity? Huh?
Do you have a team of brilliant and enthusiastic programmers? Of course! You’ve carefully chosen them from a hundred candidates! Are they passionate about the product? Absolutely! They use cutting-edge technologies, never sleep, and hardly eat or drink anything except coffee! Do they believe in your business success? No doubts about it; they live and breathe all those features, releases, continuous delivery, user experience, etc. Are you sure they are developing the product correctly? Well, yes, you’re pretty sure; why wouldn’t they? …
What is the difference? The first class HTTP encapsulates a URL, while the second one expects it as an argument of method read(). Technically, both objects do exactly the same thing: they read the content of the Google home page. Which one is the right design? Usually I hate to say this, but in this case I have to—it depends.
I often hear this argument against immutable objects: “Yes, they are useful when the state doesn’t change. However, in our case, we deal with frequently changing objects. We simply can’t afford to create a new document every time we just need to change its title.” Here is where I disagree: object title is not a state of a document, if you need to change it frequently. Instead, it is a document’s behavior. A document can and must be immutable, if it is a good object, even when its title is changed frequently. Let me explain how.
When two or more software modules are accessing the same resource, they have to be synchronized. This means that only one module at a time should be working with the resource. Without such synchronization, there will be collisions and conflicts. This is especially true when we’re talking about “resources” that do not support atomic transactions.
To solve this issue and prevent conflicts, we have to introduce one more element into the picture. All software modules, before accessing the resource, should capture a lock from a centralized server. Once the manipulations with the resource are complete, the module should release the lock. While the lock is being captured by one module, no other modules will be able to capture it. The approach is very simple and well-known. However, I didn’t find any cloud services that would provide such a locking and unlocking service over a RESTful API. So I decided to create one—stateful.co.
TL;DR ORM is a terrible anti-pattern that violates all principles of object-oriented programming, tearing objects apart and turning them into dumb and passive data bags. There is no excuse for ORM existence in any application, be it a small web app or an enterprise-size system with thousands of tables and CRUD manipulations on them. What is the alternative? SQL-speaking objects.
A team working remotely requires much stronger discipline than a co-located crew sitting in the same office. First of all, I mean discipline of communications. At Zerocracy, we have developed software remotely for the last five years. We manage tasks strictly through ticketing systems (like GitHub, JIRA, Trac, Basecamp, etc.) and discourage any informal communications, like Skype, HipChat, emails, or phone calls. Every ticket for us is an isolated task with its own life cycle, its own participants, and its own goal. Over these years, we’ve learned a few lessons that I want to share. If you also work remotely with your team, you may find them useful.
A library is essentially a set of functions that you can call, these days usually organized into classes.
Functions organized into classes? With all due respect, this is wrong. And it is a very common misconception of a class in object-oriented programming. Classes are not organizers of functions. And objects are not data structures.
So what is a “proper” object? Which one is not a proper one? What is the difference? Even though it is a very polemic subject, it is very important. Unless we understand what an object is, how can we write object-oriented software? Well, thanks to Java, Ruby, and others, we can. But how good will it be? Unfortunately, this is not an exact science, and there are many opinions. Here is my list of qualities of a good object.
