by Bozho | Aug 9, 2011 | Aggregated, Software
It’s common knowledge that commenting your code is a must. But that’s where the wrong interpretations come. “// incrementing i” above “i++” is one extreme example of useless comments, but what can be often observed is “shallow commenting” – i.e. comments describing what exactly is done, but not why. In other words programmers may forget to document the concepts and ideas behind the code. For example, imagine you see ClientDocumentIndexer and DocumentIndexer. What’s the difference? The code may have comments explaning what happens when sending the documents to the search engine, but there is nothing about the difference between the two. Same goes for things like DownloadRecord and DownloadLog. And for millions of examples throughout thousands of codebases. The comments in these classes fail to communicate their business purpose. Then there is the FooListenerBuilderFactory – yes, I know all these patterns, but it still doesn’t make sense without an explanation why each of them is required. Sometimes there is sufficient explanation about these concepts in some intranet document. There’s just no link between the code and the description. Adding a link will most likely be sufficient for the reader to understand what’s the purpose of a given class or method. What if there is no spec/document? Then you’d have to write that “document” in the code. Don’t be verbose – just outline the reason for the class existence, and how it fits into the program flow. Each piece of code should make sense to someone that is not familiar with all the business requirements. Sounding obvious? Well, if it was, you wouldn’t be seeing code that is hard to...
by Bozho | Jul 31, 2011 | Aggregated, Software
Spring has quartz support. But as you can see it requires a lot of old-style xml mappings for each of the jobs you want to run. And it looks more complex than needed. To an extent that it is a common opinion that if you have to use quartz and spring, you should use quartz separately (and not utilize the spring quartz support). On the other hand spring scheduling has become pretty nice: @Scheduled + task:annotation-driven is what you need for most scenarios. But it is not as feature-rich as quartz – you don’t have an interface for controlling the jobs execution – stop, pause, resume. So quartz can be considered superior. So what do we have as requirements: use quartz, as a feature-rich scheduling technology use spring to provide dependency-injection in quartz jobs make it as simple as possible to write and configure a new job It appears that you can’t do this. So I had to create something new, on top of existing spring classes, that would make it easier to work with quartz and still have every job instance as spring bean – with dependency injection, AOP, etc. My goals: Schedule the job with annotation – I started with @Scheduled, but it is based on the idea of annotating methods, rather than classes. And it doesn’t support the richer quartz meta-data (job name, group, durability, etc) Minimum xml – the whole setup should be enabled through one or two bean definitions, but adding new jobs should not require changes Ability to control the quartz jobs I asked a question on stackoverflow, to check if there’s an...
by Bozho | Jul 25, 2011 | Aggregated, Software
Before I start reading (and being influenced by) Joel Spolsky’s book about technical recruitment, I’ll share a thought on one important aspect of technical interviews. Whenever I happen to be interviewing someone, there are three types of questions I ask. First, the core questions. I’m not very much into computer science either, but you should know what a hashtable is. Or that your languages is statically/dynamically typed, and what polymorphism is. But they ask these questions everywhere. Second, questions about abstract thinking. You should test how the candidate can relate concepts and layer abstractions. A question that I once asked is, after the candidate answered what SOAP and REST is: Map these two web-service styles to programming language types. SOAP=statically typed, REST=dynamically typed. But this is also not rare on interviews – there are plenty of “thinking” questions. A third type of questions that are often asked are related to technologies that the company is using. You are using spring and hibernate – ask about session and transaction management. Using Swing – ask about layout managers. Even though the candidate have not used these technologies some interviewers often insist on the candidate trying to think of an answer. This is all not very good. Why? Because programming is a profession where you are learning all the time. And there are so many technologies that you can’t be experienced with all of them. So what difference does it make that the candidate doesn’t know what lazy collections are, how A* works, or what options exist for distributed caching? It may look like the candidate does not have the knowledge for...
by Bozho | Jul 12, 2011 | Aggregated, Software
DTOs, or data-transfer objects, are commonly used. What is not со commonly-known is that they originate from DDD (Domain-driven design). There it makes a lot of sense – domain objects have state, identity and business logic while DTOs have only state. But many projects today are using the anemic data model approach (my opinion) and still use DTOs. They are used whenever an object “leaves” the service layer or “leaves” the system (through web services, rmi, etc.). There are three approaches: every entity has at least one corresponding DTO. Usually more than one, for different scenarios in the view layer. When you display a user in a list you have one DTO, when you display it in a “user details” window you need a more extended DTO. I am not in favour of this approach because in too many cases the DTO and the domain structure have exactly the same structure and as a result there’s a lot of duplicated code + redundant mapping. Another thing is the variability of multiple DTOs. Even if they differ from the entity, they differ from one another with one or two fields. Why duplication is a bad thing? Because changes are to be made in two places, issues are traced harder when data passes through multiple objects, and because..it is duplication. Copy & paste within the same project is a sin. DTOs are only created when their structure significantly differs from the that of the entity. In all other cases the entity itself is used. The cases when you don’t want to show some fields (especially when exposing via web services to...
by Bozho | Jul 5, 2011 | Aggregated, Software
I’ve been answering spring and CDI questions on stackoverflow quite a lot, and what I notice as a recurring mistake (or misconception) is that people aren’t aware that they should not instantiate the objects in which they want their dependencies injected. They assume that when they do Foo foo = new Foo(), the dependencies of Foo will be injected by spring. No, they won’t be. Here’s an excerpt from an answer of mine to such a question: First, and most important – all spring beans are managed – they “live” inside a container, called “application context”. Second, each application has an entry point to that context. Web applications have a Servlet, JSF uses a el-resolver, etc. Also, there is a place where the application context is bootstrapped and all beans – autowired. In web applications this can be a startup listener. Autowiring happens by placing an instance of one bean into the desired field in an instance of another bean. Both classes should be beans, i.e. they should be defined to live in the application context. What is “living” in the application context? This means that the context instantiates the objects, not you. I.e. – you never make new UserServiceImpl() – the container finds each injection point and sets an instance there. So do not instantiate objects yourself. Configure them to be instantiated by spring (via xml, annotations or java config). (FYI: there is a way of getting dependencies injected into objects instantiated by the user rather than by the container. It uses AspectJ weaving, in short: it makes bytecode modifications so that whenever an object is instantiated it...
by Bozho | Jun 30, 2011 | Aggregated, Software
Recently I was introduced to a project that’s already 4 months in development. After a day of coding I realized there’s something wrong with the session and transaction management. Then I found something that I’ve never used and didn’t quite know when it should be used – the EntityManager was injected into DAO objects via @PersistenceContext(type=PersistenceContextType.EXTENDED) First thing to do – google. Found this spring forum discussion, which made it clearer, but not quite. Then I started debugging and realized that the application is de-facto using the session-per-application anti-pattern. Not only that, but each DAO got its own entity manager (and underlying session) instance. An important note here – I say “entity manager and underlying session”, because Hibernate simply wraps its Session with an implementation of the standard EntityManager interface. So it makes a little difference whether we talk about entity manager or session. What happens? PerssitenceContextType.EXTENDED means that you, rather than spring, are in charge of managing your session. All spring does is create it on startup and close it on shutdown. The other option (which is the default – PerssitenceContextType.TRANSACTION) lets spring’s transaction managers create the entity manager (and session) for each request, start a transaction, and when you are finished – commit the transaction and close the session. This is called session and transaction management, and it is one of the most important things to do in a spring & JPA project. It should be done right almost from the start, so the next time you do such a project, spend extra days to get this right. But what is wrong with the above situation? Here...
Recent Comments