Archive for the 'Technology' Category
21st Feb 2008
Some wheels need reinventing
Reinventing a square wheel is a common anti-pattern. The idea is a) we don’t need to reinvent the wheel because b) we’re likely to recreate it poorly compared to what is already available. But if we never reinvent any wheels, then we never progress beyond what we have. The real question, then, is when does it make sense to recreate a wheel? Some wheels need to be recreated.
I recently reinvented a wheel. A big one. The wheel is “Enterprise Messaging,” which much be complex because it has “enterprise” right in the name! I’d be a fool to reinvent that wheel, right? Maybe. Maybe not. We fit our “enterprise messaging system” into 92kb:
Some won’t consider 92kb to be “enterprisey” enough, but that’s ok with me. I know we were able to put 1.3 million real-world messages through our bus over a weekend. That’s enterprisey.
Jonas Bonér wrote an article about building a POJO datagrid using Terracotta Server, and I replied on his blog saying we did something similar by using Terracotta Server as a message bus. Another reader asked why I did this instead of using JMS.
I think there are several benefits to this reinvented wheel:
TINY!
92kb contains the entire server framework. We have another jar containing common interfaces we share with client applications that weighs in at 18kb.
It works!
A single “consumer” in our framework is bootstrapped into an isolated classloader, which enables our framework to load applications (the various apps we need to integrate) into their own isolated classloaders. One consumer can process a message for any integrated application.
This is utility computing without expensive VMWare license fees.
We’re consolidating servers instead of giving each application dedicated hardware. The servers were mostly idle, anyway, which is why enterprises are looking to utility computing and virtualization to make more efficient use those spare CPU cycles. In our framework, hardware becomes generic processing power without the need for virtualizing servers. Scaling out the server farm benefits all applications equally, whereas the prior deployments required separate capital expenditures for each new server.
Pure POJO
Our framework runs inside an IDE without any server infrastructure at all. No ActiveMQ, no MySQL, and no Terracotta Server. Developers can stand up their own message bus in their IDE, post messages to it, and debug their message code right in the framework itself.
We introduce Terracotta Server as a configuration detail in a test environment. Configuration Management handles this part, leaving developers to focus on the business logic.
So, I might not be writing my own servlet container anytime soon (not when Tomcat and Jetty are open source and high quality), but I think it made a lot of sense to reinvent the “enterprise messaging” wheel. Terracotta Server allows me, in effect, to treat my network as one big JVM. My simple POJO model went wide as a configuration detail. That makes my bus (and TC) remarkably transparent.
Reinventing a square wheel is a common anti-pattern. The idea is a) we don’t need to reinvent the wheel because b) we’re likely to recreate it poorly compared to what is already available. But if we never reinvent any wheels, then we never progress beyond what we have. The real question, then, is when does it make sense to recreate a wheel? Some wheels need to be recreated.
I recently reinvented a wheel. A big one. The wheel is “Enterprise Messaging,” which much be complex because it has “enterprise” right in the name! I’d be a fool to reinvent that wheel, right? Maybe. Maybe not. We fit our “enterprise messaging system” into 92kb:
Some won’t consider 92kb to be “enterprisey” enough, but that’s ok with me. I know we were able to put 1.3 million real-world messages through our bus over a weekend. That’s enterprisey.
Jonas Bonér wrote an article about building a POJO datagrid using Terracotta Server, and I replied on his blog saying we did something similar by using Terracotta Server as a message bus. Another reader asked why I did this instead of using JMS.
I think there are several benefits to this reinvented wheel:
TINY!
92kb contains the entire server framework. We have another jar containing common interfaces we share with client applications that weighs in at 18kb.
It works!
A single “consumer” in our framework is bootstrapped into an isolated classloader, which enables our framework to load applications (the various apps we need to integrate) into their own isolated classloaders. One consumer can process a message for any integrated application.
This is utility computing without expensive VMWare license fees.
We’re consolidating servers instead of giving each application dedicated hardware. The servers were mostly idle, anyway, which is why enterprises are looking to utility computing and virtualization to make more efficient use those spare CPU cycles. In our framework, hardware becomes generic processing power without the need for virtualizing servers. Scaling out the server farm benefits all applications equally, whereas the prior deployments required separate capital expenditures for each new server.
Pure POJO
Our framework runs inside an IDE without any server infrastructure at all. No ActiveMQ, no MySQL, and no Terracotta Server. Developers can stand up their own message bus in their IDE, post messages to it, and debug their message code right in the framework itself.
We introduce Terracotta Server as a configuration detail in a test environment. Configuration Management handles this part, leaving developers to focus on the business logic.
So, I might not be writing my own servlet container anytime soon (not when Tomcat and Jetty are open source and high quality), but I think it made a lot of sense to reinvent the “enterprise messaging” wheel. Terracotta Server allows me, in effect, to treat my network as one big JVM. My simple POJO model went wide as a configuration detail. That makes my bus (and TC) remarkably transparent.
Posted by Mark Turansky under 
Architecture, Engineering, Technology, Terracotta 
9 Comments »
03rd Feb 2008
Caveat emptor
I think the claims made by the people hawking this book are some of the most disingenuous things I’ve ever read:
http://sourcemaking.com/design-patterns-simply
They are selling a rehash of the classic Gang of Four (GoF) Design Patterns book as a PDF, making preposterous claims which I’ll cut & paste here. You can’t make this stuff up.
The Whys:
Why should I read it?
When you finish reading this book, you can go to your boss and ask him for a promotion.
Why? Because using design patterns will allow you to get your tasks done twice faster, write bugless code and create an efficient and reliable software architecture.
How to become programming guru?
The main difference between a programming guru and a novice is the knowledge of secret coding tricks, as well as awareness of most cornerstones and the ability to avoid them.
Design patterns were created as a Bible of avoiding problems related to software design. Isn’t it a true guru’s handbook?
“Bugless code” after learning design patterns! I must be a poor learner, because I still have bugs in my code and I’ve lived with the GoF book for many years now. Unless you are writing code for the space shuttle, you’ve probably written your share of bugs, too. And bosses don’t give promotions because you read a book about patterns. Mine gave me promotions because of hard work, passion, and creativity in problem solving.
“Testimonials”
If you follow through to the order page, you see the publisher is based in the Ukraine. That explains the broken English “testimonials”:
Daniel Sommers, UK
I have learned all design patterns about a 3 days with this book. Thank you very much!!!!
and
Jeremy Parkinson, USA
Four month ago I was just coder in Boeing corp. I had a lot things to learn to get a level up in my skills, and I started with this book. Now I am a software architect and I happy, because nobody in my department is so good with programming as me!
I’d be pissed off if I were Boeing. That “testimonial” makes me think the talent there must be terrible. Boeing does “aerospace engineering.” Rocket scientists. Literally. I suspect they are a smarter bunch than “Jeremy Parkinson.”
Free Book Offer:
Buy our book now and get a free gift! (limited offer)
It is classic “Design Patterns” book by “Gang of Four”.
Amazon is selling the classic GoF book for $38, but this publisher is going to sell you a PDF for $20 and give you a $38 book for free. If they gave a single GoF book away for free, would that be considered a “limited offer”?
The odd thing is that the quality of the rest of the site appears, at first blush, quite good. The writing on the pages describing each of the patterns is good and without any outlandish claims. It makes me wonder if they didn’t get that copy from somewhere else. Regardless, the content on the site is sufficiently good that one wouldn’t need to buy their PDF.
Save your money. Or better yet, buy the real GoF book. It’s a classic for a reason, and there are products that nicely complement the book, like a wall poster detailing the original patterns in a striking visual way.
I think the claims made by the people hawking this book are some of the most disingenuous things I’ve ever read:
http://sourcemaking.com/design-patterns-simply
They are selling a rehash of the classic Gang of Four (GoF) Design Patterns book as a PDF, making preposterous claims which I’ll cut & paste here. You can’t make this stuff up.
The Whys:
Why should I read it?
When you finish reading this book, you can go to your boss and ask him for a promotion.Why? Because using design patterns will allow you to get your tasks done twice faster, write bugless code and create an efficient and reliable software architecture.
How to become programming guru?
The main difference between a programming guru and a novice is the knowledge of secret coding tricks, as well as awareness of most cornerstones and the ability to avoid them.Design patterns were created as a Bible of avoiding problems related to software design. Isn’t it a true guru’s handbook?
“Bugless code” after learning design patterns! I must be a poor learner, because I still have bugs in my code and I’ve lived with the GoF book for many years now. Unless you are writing code for the space shuttle, you’ve probably written your share of bugs, too. And bosses don’t give promotions because you read a book about patterns. Mine gave me promotions because of hard work, passion, and creativity in problem solving.
“Testimonials”
If you follow through to the order page, you see the publisher is based in the Ukraine. That explains the broken English “testimonials”:
Daniel Sommers, UK
I have learned all design patterns about a 3 days with this book. Thank you very much!!!!
and
Jeremy Parkinson, USA
Four month ago I was just coder in Boeing corp. I had a lot things to learn to get a level up in my skills, and I started with this book. Now I am a software architect and I happy, because nobody in my department is so good with programming as me!
I’d be pissed off if I were Boeing. That “testimonial” makes me think the talent there must be terrible. Boeing does “aerospace engineering.” Rocket scientists. Literally. I suspect they are a smarter bunch than “Jeremy Parkinson.”
Free Book Offer:
Buy our book now and get a free gift! (limited offer)
It is classic “Design Patterns” book by “Gang of Four”.
Amazon is selling the classic GoF book for $38, but this publisher is going to sell you a PDF for $20 and give you a $38 book for free. If they gave a single GoF book away for free, would that be considered a “limited offer”?
The odd thing is that the quality of the rest of the site appears, at first blush, quite good. The writing on the pages describing each of the patterns is good and without any outlandish claims. It makes me wonder if they didn’t get that copy from somewhere else. Regardless, the content on the site is sufficiently good that one wouldn’t need to buy their PDF.
Save your money. Or better yet, buy the real GoF book. It’s a classic for a reason, and there are products that nicely complement the book, like a wall poster detailing the original patterns in a striking visual way.
Posted by Mark Turansky under Business, Technology No Comments »
30th Jan 2008
The Perils of Joel Spolsky
The Perils of Java Schools? Joel Spolsky — of Joel On Software fame — continues to ding Java whenever the opportunity arises, which just so happens (again) to be a recent article on his blog about “Java schools” and undergraduate programs. I think he still holds MSFT stock in his portfolio, which may explain the constant FUD coming from his bully pulpit.
I like Joel. I enjoy his articles and insight. Normally, I agree with him or learn something, but sometimes….!
Joel’s original article bemoaned the state of Computer Science curriculum in today’s universities, but what gets me (and he may be trolling, really, just to promote his products) is the continuing attacks on Java as a language and platform despite the fact that his former employer is following the exact same roadmap in order to claim Java’s marketshare. This does not change his choice in platform, naturally. He’s MSFT all the way, with the inclusion of *nix by writing his own language called ‘wasabi’ to crank out PHP code from a vbscribt-looking language. They must be bored over there at Fog Creek.
The Physicist, the Architect, and NASCAR
Physicists can tell you with great accuracy why things fall, why bodies of water ebb and flow, what makes up stardust, and why weight distributed across various building materials would support more or less weight than other materials in myriad configurations. There are formulas to calculate these things to the nth degree.
Architects will say they need a floor to support X people and design their building accordingly. Structural engineers make it happen.
I’d argue that one is science while the other is applied science. One is research and learning, while the other is a pragmatic use of today’s knowledge.
Architects do not need advanced degrees in physics to design a building. They need to get the job done on time and on budget. Most businesses don’t need computer scientists who understand relational algebra at a deep level. They just need pragmatic application developers who understand that relational algebra exists and that it underlies how modern databases are built. Knowing about relational theory at a superficial level is sufficient to take advantage of it by applying the right level of normalization on a database design. Folks who build NASCAR cars don’t need to be able to design next generation engines, they just need to be able to put horsepower under the hood.
Today’s curriculum
Colleges today are changing their curriculum to match the demands of the business world. There is is a schism forming between computer science and application development (for lack of a better term). We see this here in a local university from the eyes of a professor who consults with our company. One is science and research, the other is applied science to achieve business goals. The two don’t necessarily align, but we only have a single “computer science” degree that most closely matches what businesses need today.
I don’t know if Joel would support learning software engineering best practices in a computer science curriculum. His excellent “Joel Test” for software organizations may not have any place in today’s comp sci classrooms, but it’s still an excellent test. How do we teach people the merits of version control systems, build and smoke tests, and planning and scheduling? How do we teach good design with an eye towards maintainability? How do we teach young programmers that the project is not done when the coding is finished and that non-functional requirements will lengthen the schedule considerably? How do we write code that simultaneously meets the oft conflicting requirements and schedule pressure?
Does pedigree matter?
My daughter and I watched Underdog this past weekend. She held a huge bowl of popcorn in her lap while enjoying a canine protagonist that looks suspiciously like our beagle. We popped the popcorn in our microwave. Percy Spencer was a self-taught engineer working for Raytheon when he discovered microwave radiation. He didn’t get a comp sci degree from Yale. He didn’t even go to a Java school. He learned on his own. A childhood friend of mine is blowing up buildings in Connecticut as the Director of Technology for an NBC owned television station. He’s building a next generation studio and control center for NBC. Before that, he was the technical manager of the Today Show. He went to school to learn how to operate a camera. You know, a Java school for TV.
What most of us do everyday in the trenches isn’t rocket science. It isn’t even computer science. It’s application development where ingenuity, passion, and creativity drive the best of us, not pieces of paper.
The Perils of Java Schools? Joel Spolsky — of Joel On Software fame — continues to ding Java whenever the opportunity arises, which just so happens (again) to be a recent article on his blog about “Java schools” and undergraduate programs. I think he still holds MSFT stock in his portfolio, which may explain the constant FUD coming from his bully pulpit.
I like Joel. I enjoy his articles and insight. Normally, I agree with him or learn something, but sometimes….!
Joel’s original article bemoaned the state of Computer Science curriculum in today’s universities, but what gets me (and he may be trolling, really, just to promote his products) is the continuing attacks on Java as a language and platform despite the fact that his former employer is following the exact same roadmap in order to claim Java’s marketshare. This does not change his choice in platform, naturally. He’s MSFT all the way, with the inclusion of *nix by writing his own language called ‘wasabi’ to crank out PHP code from a vbscribt-looking language. They must be bored over there at Fog Creek.
The Physicist, the Architect, and NASCAR
Physicists can tell you with great accuracy why things fall, why bodies of water ebb and flow, what makes up stardust, and why weight distributed across various building materials would support more or less weight than other materials in myriad configurations. There are formulas to calculate these things to the nth degree.
Architects will say they need a floor to support X people and design their building accordingly. Structural engineers make it happen.
I’d argue that one is science while the other is applied science. One is research and learning, while the other is a pragmatic use of today’s knowledge.
Architects do not need advanced degrees in physics to design a building. They need to get the job done on time and on budget. Most businesses don’t need computer scientists who understand relational algebra at a deep level. They just need pragmatic application developers who understand that relational algebra exists and that it underlies how modern databases are built. Knowing about relational theory at a superficial level is sufficient to take advantage of it by applying the right level of normalization on a database design. Folks who build NASCAR cars don’t need to be able to design next generation engines, they just need to be able to put horsepower under the hood.
Today’s curriculum
Colleges today are changing their curriculum to match the demands of the business world. There is is a schism forming between computer science and application development (for lack of a better term). We see this here in a local university from the eyes of a professor who consults with our company. One is science and research, the other is applied science to achieve business goals. The two don’t necessarily align, but we only have a single “computer science” degree that most closely matches what businesses need today.
I don’t know if Joel would support learning software engineering best practices in a computer science curriculum. His excellent “Joel Test” for software organizations may not have any place in today’s comp sci classrooms, but it’s still an excellent test. How do we teach people the merits of version control systems, build and smoke tests, and planning and scheduling? How do we teach good design with an eye towards maintainability? How do we teach young programmers that the project is not done when the coding is finished and that non-functional requirements will lengthen the schedule considerably? How do we write code that simultaneously meets the oft conflicting requirements and schedule pressure?
Does pedigree matter?
My daughter and I watched Underdog this past weekend. She held a huge bowl of popcorn in her lap while enjoying a canine protagonist that looks suspiciously like our beagle. We popped the popcorn in our microwave. Percy Spencer was a self-taught engineer working for Raytheon when he discovered microwave radiation. He didn’t get a comp sci degree from Yale. He didn’t even go to a Java school. He learned on his own. A childhood friend of mine is blowing up buildings in Connecticut as the Director of Technology for an NBC owned television station. He’s building a next generation studio and control center for NBC. Before that, he was the technical manager of the Today Show. He went to school to learn how to operate a camera. You know, a Java school for TV.
What most of us do everyday in the trenches isn’t rocket science. It isn’t even computer science. It’s application development where ingenuity, passion, and creativity drive the best of us, not pieces of paper.
Posted by Mark Turansky under Technology 9 Comments »
