I don't understand the CQRS pattern and the hype about it. Technically I believe I think I understand why people think why they want to use it.
But really? Do we really need a complete pattern of explaining that I'm writing or reading to a source? Is reading code so hard that I have to "encapsulate" the specific behavior of writing something to a database? What's wrong with update/insert?
I think we're overdoing simple things which are NOT hard and going full blown nuts with technical "solutions" which are already solved. It's incredible over engineered for something simple and its doesn't hold or solve the "benefits" of the pattern. Problem as I see it is that one is trying to create encapsulated behavior but thing is that you can't encapsulate behavior only technical things which solves it.
Do I really have to say SaveXCommand? Isn't SaveX enough? Are we that stupid that we can't figure out what SaveX means? Are the problems people working with so simple that we can only divide the in a query or a command? Really? Why stacking a http post on a command? I already KNOW it's a post! Or even more unbelievable I've seen solutions using a post and a command at the same time by including the command in the URL! What the hell?
Why stopping at creating commands or queries for a supposedly database? Shouldn't we consider writing or reading to memory a command or query? Wrap every other memory access in a command instead of simply doing an assignment? Heck you might be writing to the disk shouldn't you be writing a command for that? Hell now Samsung and Intel releasing hard drives which are 100000 faster than the current SSDs. We might ending up with a lot more closer to doing memory swapping because it's cheaper and "memory" might end up in a database.
Not only that it seems like there's a lot of different ways of implementing it since there are no real clear rules about it apparently. I've seen people trying to implement it and it always ends in with them believing the other as an complete imbecile. Why is that and why the damn effort? Making a pipeline or a "bus" instead of treating a thread or task as such and work with them instead? The cqrs pattern creates incredibly polluted code with technical details all over the code base and it smells so bad I choke on it.
Imo it's trying to solve a problem which is already solved and stop doing that.
Saturday, July 30, 2016
Thursday, July 14, 2016
Are the GoF patterns dead?
I read this post on the topic on getting rid of GoF patterns. I think the author is right about that patterns are bound to a paradigm and it is so that patterns in one language might not be as "effective" in another language, even though they are in the same paradigm. I can really relate to this.
But I think patterns should be considered dead because I think people try to pick a pattern and force a solution into it, instead of solving the problem and then and only then identify the patterns, but by then one could argue that there's no need of doing that.
Also if you are working in an agile environment things change, and if you build something it will change over time, and hopefully it will change rapidly. If you invest a lot of time building things to conform to a pattern and the next iteration the first thing you have to do is to tear it down again, I'd say it's a waste of time and effort. To use the design patterns you have to understand the problem and it's quirks and when you have only a vague idea of what is needed to be done to solve the problem, "designing" with those patterns before the solution is known will set you off on the wrong course and put you in a situation where you are trying to implement a pattern and not a solution. Also even if you know the solution and how it should be done, you should solve the problem not the pattern, which is happening most of the time,
But I think patterns should be considered dead because I think people try to pick a pattern and force a solution into it, instead of solving the problem and then and only then identify the patterns, but by then one could argue that there's no need of doing that.
Also if you are working in an agile environment things change, and if you build something it will change over time, and hopefully it will change rapidly. If you invest a lot of time building things to conform to a pattern and the next iteration the first thing you have to do is to tear it down again, I'd say it's a waste of time and effort. To use the design patterns you have to understand the problem and it's quirks and when you have only a vague idea of what is needed to be done to solve the problem, "designing" with those patterns before the solution is known will set you off on the wrong course and put you in a situation where you are trying to implement a pattern and not a solution. Also even if you know the solution and how it should be done, you should solve the problem not the pattern, which is happening most of the time,
Thursday, May 5, 2016
Trouble with maven-jaxb2-plugin and Eclipse?
Does your build work with plain mvn but won't build in Eclipse (Mars.2)? Does the project fail with:
and
have a "malformed" parent pom. If you check the Eclipse error log it may have an error message like:
The maven environment resolves java.home environment variable from eclipse's JAVA_HOME environment variable which, if eclipse is run with a JRE, points to a non existent library.
To fix this you need to set the JAVA_HOME Environment variable. However it seems like the authors have had their JAVA_HOME point to the <path to JDK>/bin folder so in order to reach the jre and lib folder they had to use .. to get there. However the proper way to set up JAVA_HOME is the root directory of the installation. So either way you'll break something.
To fix this in turn you have to put the following parameter in eclipse.ini after --launcher.appendVmargs:
You should use the JDK runtime since it needs the tools.jar and it should be the absolute path.
To check the java_home parameter you can go to Help->About Eclipse->Installation Details button->Configuration tab and look for the java.home parameter. It should be pointing to your JDK installation.
If you only have the JDK installation on your machine you probably won't see this issue. But if you, as I have, a notorious IT department it might happen they install the JRE and your Eclipse installation will run with the JRE version instead for the JDK one. It won't help to put the tools.jar in the project since the plugins runs in a different classloader to prevent them to mix classes and versions with the project they are running in. So the plugin will still fail. Hope it helps!
"Execution default of goal org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.13.1:generate failed: A required class was missing while executing org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.13.1:generate: com/sun/xml/bind/api/ErrorListener"The reason for this is that there are two dependencies;
org.glassfish.jaxb:jaxb-xjc:jar:2.2.11
and
org.glassfish.jaxb:jaxb-runtime:jar:2.2.11
have a "malformed" parent pom. If you check the Eclipse error log it may have an error message like:
"The POM for org.glassfish.jaxb:jaxb-xjc:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details"The reason for this is the following section from their shared parent; com.sun.xml.bind.mvn:jaxb-parent:pom:2.2.11 :
<profile>
<id>default-tools.jar</id>
<activation>
<file>
<exists>${java.home}/../lib/tools.jar</exists>
</file>
</activation>
<properties>
<tools.jar>${java.home}/../lib/tools.jar</tools.jar>
</properties>
</profile>
<profile>
<id>default-tools.jar-mac</id>
<activation>
<file>
<exists>${java.home}/../Classes/classes.jar</exists>
</file>
</activation>
<properties>
<tools.jar>${java.home}/../Classes/classes.jar</tools.jar>
</properties>
</profile>
<profile>
<id>default-rt.jar</id>
<activation>
<file>
<exists>${java.home}/../jre/lib/rt.jar</exists>
</file>
</activation>
<properties>
<rt.jar>${java.home}/../jre/lib/rt.jar</rt.jar>
</properties>
</profile>
<profile> <!--todo: remove me-->
<id>default-rt.jar-mac</id>
<activation>
<file>
<exists>${java.home}/../Classes/classes.jar</exists>
</file>
</activation>
<properties>
<rt.jar>${java.home}/../Classes/classes.jar</rt.jar>
</properties>
</profile>
where the incorrect java.home variable causes those two dependencies to be not loaded so the jaxb2 plugin won't have the classes to perform schema generation.The maven environment resolves java.home environment variable from eclipse's JAVA_HOME environment variable which, if eclipse is run with a JRE, points to a non existent library.
To fix this you need to set the JAVA_HOME Environment variable. However it seems like the authors have had their JAVA_HOME point to the <path to JDK>/bin folder so in order to reach the jre and lib folder they had to use .. to get there. However the proper way to set up JAVA_HOME is the root directory of the installation. So either way you'll break something.
To fix this in turn you have to put the following parameter in eclipse.ini after --launcher.appendVmargs:
-startup plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.300.v20150602-1417 -product org.eclipse.epp.package.jee.product --launcher.defaultAction openFile --launcher.XXMaxPermSize 256M -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile --launcher.appendVmargs -vm <path to JDK>\bin\javaw.exe -vmargs -Dosgi.requiredJavaVersion=1.7 -Xms256m -Xmx1024m
You should use the JDK runtime since it needs the tools.jar and it should be the absolute path.
To check the java_home parameter you can go to Help->About Eclipse->Installation Details button->Configuration tab and look for the java.home parameter. It should be pointing to your JDK installation.
If you only have the JDK installation on your machine you probably won't see this issue. But if you, as I have, a notorious IT department it might happen they install the JRE and your Eclipse installation will run with the JRE version instead for the JDK one. It won't help to put the tools.jar in the project since the plugins runs in a different classloader to prevent them to mix classes and versions with the project they are running in. So the plugin will still fail. Hope it helps!
Monday, April 25, 2016
Frustration
There's so much frustration in the software industry, not only that it tends to get religious about it as well. Sometimes fiercely sometimes in a sober fashion, but mostly its fierce. Sometimes its between languages and sometimes its between platforms.
I recently found myself in this situation where I changed job to a .NET shop, coming from a basically "use whatever works" (in terms of platform) to a proprietary, or more properly, constricted environment. It's working with a straight jacket and whenever you turn it tightens its grip around you until there's no other way of doing things. Not only that you are bound by the "physics" of the .NET and Windows platform, it soaks into your mind as some sort of brain wash. I'll get to that a bit later.
I started checking out C# and initially I thought "This is Java done right" and then I realized that it's even more than that. I had all these things which were really nice like LINQ, delegates even async/await which seemed like heaven initially. I finally got a language which I could use with really powerful tools without a fuss. I really thought I've found something which would make me happy and this shiny new tool would make me forget the "sorrows" of the JVM echo system.
Disappointments
I immediately started to check out frameworks to see what there was. I checked if there were ports for the most usual frameworks... and found fairly little, Not only that those I found they were not as "good" as their counterparts (YES there are good ones) there weren't much. I turned to the platform itself and found that most of the time you simply use the ones the platform had. Fair enough.
Most projects developed in this shop are developed individually by contractors which are hired whenever they are needed, and not only one person have worked on a single project. There have been several system overhauls where the code have been rewritten to suit the products, and supposedly it is in a state which would qualify as "good". Quite nervous to join such a professional shop, I eagerly dug into the code to see what I could expect and what I though would be expected of me.
I was stunned, I really couldn't believe it so I had to ask. And from one of the more senior and one of those which had worked there the longest I got this blank stare as not understanding what I were talking about. It was a freaking mess. I thought it might just that part of code I was looking at, but there were more, there were those patterns you'd expect and whatnot but all these "tools" just made it somehow worse. I can't really explain it more thoroughly but the code just were f*ked up.
Somewhat dis encouraged I started coding on my own, firmly determined to do a good job. I resorted to every tool I knew of to produce good code (and provided a solid baseline for coding in other languages). A few good frameworks like XUnit came to the rescue (damn that's a really nice framework) and I started doing quite good pace with features. Though then things started to turn ugly, most notably Dispose and the life cycle of objects. Why did they do this? It gets really ugly not only considering thread safety. Not going through all that but some of it can you read here.
Then It came to the solution part of the "ecosystem". It was just Microsoft's things. And really I do know that you can do things without it but it just sort of never gets right. You either do one thing but then you cannot do the other. And when you need help it's really hard to find out what you need to do to get things working. And there's the "easy" solution which is always the wrong one.
I do recognize that you can write good code with C#, its not that. It's the straight jacket which limits the possible solutions. And this somehow restricts the solution space of the developers. You can solve a lot of things bu using LINQ, but it's so easy to actually misuse it you don't see that you actually just did that. LINQ is a perfect example of "too much abstraction" which it seems like a viable tool to use but it really is the wrong one, though its so easy to make that decision and that's why I think the code gets so messy. There are too many tools which are easy to use so you are using it for everything, and you don't see the alternative, and suddenly its NOT the right tool anymore and suddenly you are in a dark corner with no way out.
Additional problem is that you start thinking like it as well, since you become blind for other solutions. Though I've fallen into that trap a few times myself, I feel it like its a real problem for C# developers or at least that's my experience. I don't blame the developers here, but the platform.
Quite frankly I think working with C# taught me that it's good to work with different platforms, though .NET is not the one, at least not for me. Well maybe when the Windows become Linux or any derivatives like such.
I recently found myself in this situation where I changed job to a .NET shop, coming from a basically "use whatever works" (in terms of platform) to a proprietary, or more properly, constricted environment. It's working with a straight jacket and whenever you turn it tightens its grip around you until there's no other way of doing things. Not only that you are bound by the "physics" of the .NET and Windows platform, it soaks into your mind as some sort of brain wash. I'll get to that a bit later.
I started checking out C# and initially I thought "This is Java done right" and then I realized that it's even more than that. I had all these things which were really nice like LINQ, delegates even async/await which seemed like heaven initially. I finally got a language which I could use with really powerful tools without a fuss. I really thought I've found something which would make me happy and this shiny new tool would make me forget the "sorrows" of the JVM echo system.
Disappointments
I immediately started to check out frameworks to see what there was. I checked if there were ports for the most usual frameworks... and found fairly little, Not only that those I found they were not as "good" as their counterparts (YES there are good ones) there weren't much. I turned to the platform itself and found that most of the time you simply use the ones the platform had. Fair enough.
Most projects developed in this shop are developed individually by contractors which are hired whenever they are needed, and not only one person have worked on a single project. There have been several system overhauls where the code have been rewritten to suit the products, and supposedly it is in a state which would qualify as "good". Quite nervous to join such a professional shop, I eagerly dug into the code to see what I could expect and what I though would be expected of me.
I was stunned, I really couldn't believe it so I had to ask. And from one of the more senior and one of those which had worked there the longest I got this blank stare as not understanding what I were talking about. It was a freaking mess. I thought it might just that part of code I was looking at, but there were more, there were those patterns you'd expect and whatnot but all these "tools" just made it somehow worse. I can't really explain it more thoroughly but the code just were f*ked up.
Somewhat dis encouraged I started coding on my own, firmly determined to do a good job. I resorted to every tool I knew of to produce good code (and provided a solid baseline for coding in other languages). A few good frameworks like XUnit came to the rescue (damn that's a really nice framework) and I started doing quite good pace with features. Though then things started to turn ugly, most notably Dispose and the life cycle of objects. Why did they do this? It gets really ugly not only considering thread safety. Not going through all that but some of it can you read here.
Then It came to the solution part of the "ecosystem". It was just Microsoft's things. And really I do know that you can do things without it but it just sort of never gets right. You either do one thing but then you cannot do the other. And when you need help it's really hard to find out what you need to do to get things working. And there's the "easy" solution which is always the wrong one.
I do recognize that you can write good code with C#, its not that. It's the straight jacket which limits the possible solutions. And this somehow restricts the solution space of the developers. You can solve a lot of things bu using LINQ, but it's so easy to actually misuse it you don't see that you actually just did that. LINQ is a perfect example of "too much abstraction" which it seems like a viable tool to use but it really is the wrong one, though its so easy to make that decision and that's why I think the code gets so messy. There are too many tools which are easy to use so you are using it for everything, and you don't see the alternative, and suddenly its NOT the right tool anymore and suddenly you are in a dark corner with no way out.
Additional problem is that you start thinking like it as well, since you become blind for other solutions. Though I've fallen into that trap a few times myself, I feel it like its a real problem for C# developers or at least that's my experience. I don't blame the developers here, but the platform.
Quite frankly I think working with C# taught me that it's good to work with different platforms, though .NET is not the one, at least not for me. Well maybe when the Windows become Linux or any derivatives like such.
Subscribe to:
Posts (Atom)