I've heard from many students that programming is too much work. No! Programming is for lazy people.
I'm teaching CIS 300 Project Management. I want to take the end of chapter questions from the class textbook and use them for on-line quizzes.
I use software called Moodle for managing the class. The user interface for entering quiz questions into Moodle was designed by trolls, making the tedious process of retyping the questions even more tedious.
I was happy to discover today that the whole book is available via PDF on the included CD. I converted the PDF to plain text. Then ran it through a Perl script to reformat it for Moodle. Then I uploaded the questions to Moodle.
In less time than it would take to enter the questions for one chapter, I had a program to do it automatically.
Wednesday, July 25, 2007
Tuesday, July 24, 2007
Aardvark Joel on Software Video
A while back I ordered a video called Aardvark'd. It was supposed to be better than The Apprentice, and actually show the management process. According to Joel, anyway. I thought this would be good to show during my project management or software development class.
When I first got the video, I got bored in the first 5 minutes, and thought I'd watch it later. Well, a couple years later, it is now later. It is still boring. And frustrating. I don't want a tour of the intern's appartment. I certainly don't want to spend so much time watching the kids try to figure if they could jump out the window of their building to a nearby building.
I'm a half hour into the film, and now they are trying to plan a party. They aren't social enough apparently. I haven't seen them do any work yet. I think my time might be better spent finding a different video, and give this up as a waste of money and time. Shame, most of Joel's stuff is really good.
When I first got the video, I got bored in the first 5 minutes, and thought I'd watch it later. Well, a couple years later, it is now later. It is still boring. And frustrating. I don't want a tour of the intern's appartment. I certainly don't want to spend so much time watching the kids try to figure if they could jump out the window of their building to a nearby building.
I'm a half hour into the film, and now they are trying to plan a party. They aren't social enough apparently. I haven't seen them do any work yet. I think my time might be better spent finding a different video, and give this up as a waste of money and time. Shame, most of Joel's stuff is really good.
Sunday, July 15, 2007
Harry Potter OOTP movie review
Having seen Harry Potter and the Order of the Phoenix twice now, here's a review:
Both my wife and I disliked the film on the first showing, and liked it the second time we saw it. The book was the same for me, I've enjoyed it more after I read it the first time.
OOTP is a movie that is less than the sum of its parts. So much is right with that movie, and it yet it still seems to fall flat.
Bad:
The score. The soundtrack was terrible. For a long movie, it should have helped drive it. Instead it was completely absent in slow parts. When there was music, it often had no discernible beat. There were some good parts, and I noticed my daughter pick up her attention when the music did. But when there was music it seemed to fly around aimlessly and did nothing for the tempo of the movie. Had there been good driving music (like Bear McCreary does for BSG), this would have been one of the best movies in my opinion. With no music, it reminds me of a terrible movie watched during weekday afternoon on TV when I was home sick. You were too bored to turn it off, yet it made you feel worse.
Camera angles with Dudley: I didn't like shooting straight on with Dudley and Harry. Looked awful.
Mrs Figg. Harry gets attacked by dementors, and Mrs Figg acts like a bag lady collecting cans. A complete lack of drama kills this part.
Luna's makeup at the end scene when she found her shoes. Rather than look like she was bruised, it looked like she had a couple holes in her head.
I missed the Quibbler storyline where Harry gets his version published.
The lighting was too dark and the colors too muted. The movie should have been figuratively dark, not literally dark.
The editing was choppy.
I disliked Hermione looking out the window at the lightning after Sirius's head was in the fireplace. That scene was lame. Dialog was ok, but not the setup.
The shelves with spheres were too high to be believable. It was too CGI for me.
Good:
The acting was great.
The special effects, particularly the end fight were also wonderful.
Snape was awesome. I particularly like that the occlumency lessons appeared to hard, and that several were required. Movie 3 in the series failed to show how difficult the Patronous charm was to produce, and this movie succeeded with occlumency.
Luna Lovegood was perfect. Brilliant casting with her.
Harry's relationship with Sirius was built well.
The scene of Voldemort possessing Harry was well done. It would have been so easy to screw that up.
Condensing an 800 page book into a 138 minute movie was well-done script-wise. Hard to see that on the first showing because so much was lost that I liked. But I think the story was done well.
Umbridge's office was perfect with the cats.
Both my wife and I disliked the film on the first showing, and liked it the second time we saw it. The book was the same for me, I've enjoyed it more after I read it the first time.
OOTP is a movie that is less than the sum of its parts. So much is right with that movie, and it yet it still seems to fall flat.
Bad:
The score. The soundtrack was terrible. For a long movie, it should have helped drive it. Instead it was completely absent in slow parts. When there was music, it often had no discernible beat. There were some good parts, and I noticed my daughter pick up her attention when the music did. But when there was music it seemed to fly around aimlessly and did nothing for the tempo of the movie. Had there been good driving music (like Bear McCreary does for BSG), this would have been one of the best movies in my opinion. With no music, it reminds me of a terrible movie watched during weekday afternoon on TV when I was home sick. You were too bored to turn it off, yet it made you feel worse.
Camera angles with Dudley: I didn't like shooting straight on with Dudley and Harry. Looked awful.
Mrs Figg. Harry gets attacked by dementors, and Mrs Figg acts like a bag lady collecting cans. A complete lack of drama kills this part.
Luna's makeup at the end scene when she found her shoes. Rather than look like she was bruised, it looked like she had a couple holes in her head.
I missed the Quibbler storyline where Harry gets his version published.
The lighting was too dark and the colors too muted. The movie should have been figuratively dark, not literally dark.
The editing was choppy.
I disliked Hermione looking out the window at the lightning after Sirius's head was in the fireplace. That scene was lame. Dialog was ok, but not the setup.
The shelves with spheres were too high to be believable. It was too CGI for me.
Good:
The acting was great.
The special effects, particularly the end fight were also wonderful.
Snape was awesome. I particularly like that the occlumency lessons appeared to hard, and that several were required. Movie 3 in the series failed to show how difficult the Patronous charm was to produce, and this movie succeeded with occlumency.
Luna Lovegood was perfect. Brilliant casting with her.
Harry's relationship with Sirius was built well.
The scene of Voldemort possessing Harry was well done. It would have been so easy to screw that up.
Condensing an 800 page book into a 138 minute movie was well-done script-wise. Hard to see that on the first showing because so much was lost that I liked. But I think the story was done well.
Umbridge's office was perfect with the cats.
Friday, July 13, 2007
Best Practices
Cramblitt: What do you think about the reliance on best practices?
Lister: I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices because that implies generic software development....from an Interview with Tom Lister.
Monday, July 2, 2007
SOA - No silver bullet
Service Oriented Architecture is in! It's hip and cool! It's better than objected-oriented programming! Better than exclamation marks in blogs!
But if you use SOA, understand the pitfalls.
I learned parallel computing the "academic" way. We had a task to speed up. We created mathematical proofs. We ran experiments. We backed our theories with the results. Then the results were reviewed by professors and peers.
We knew that distributed computing was going to be the next big thing. And it was! But it was taught to the masses in magazines and internet articles. Developers got all the coolness of SOA without seeing the hard parts, or having to work through the theory.
So here is my list of three major things I’ve seen people get bitten by. I came up with this list during my last project. That project handled 2.5 million page views per day, many of which were processed by using SOA. One page required 43 service calls. SOA was our lifeblood and our curse.
Top Three SOA Pitfalls
Distributed Computing is Slower: Conventional wisdom claims the opposite, lots of computers processing instead of one. So while we know it can be faster, the question is why did our app get slower?
Let’s answer that question with another question: How long does it take to make a function call on your local computer? Don’t know? Then run a quick experiment and come back. I’ll wait.
Ok, you’re back. I got about 20 nanoseconds with Java. What did you get?
What about making a distributed call? To do that I have to:
Just one network hop usually changes us from measuring time in nanoseconds to measuring time in milliseconds. Quick, go run your own experiment. (Making a network call localhost doesn’t count!)
I got 20 milliseconds. That makes a local call 1,000,000 times faster than a network call. What did you get? I’ll bet it was a lot slower than your local call!
But wait! That’s not slow enough for some people. What if we add another layer of middleware or a message queue? Heck, at my last job we added both. Architects love layers. The best architects are educated at Hogwarts. They draw diagrams and wave their hands at meetings. Then management gets a glazed look on their eyes and magically starts writing checks. Why didn’t I go to that school? (*)
Before SOA was big, I worked at a small company that built a user-customized portal called Agdayta. It showed futures quotes, news tickers, and other investment-type things. We pulled data using all sorts of services. By keeping in mind the expense of these calls, we managed to produce custom portal pages in less than 10 ms. Using Pentium II computers. And full session fail-over. Before any of this was built into Java.
Later I worked at a big company. We had 5 machine clusters, each machine with 8 processor cores. Even though we made less complicated pages, the pages took 50 times longer to render. Why? There were too many services and calls and leaky abstractions.
Distributed computing CAN be faster if the advantage of distribution makes up for the overhead. But you have to do the math and understand the theory.
Distributed computing is less reliable: Wait, isn’t it more reliable?
This is where some background in safety engineering can be good. I recommend learning to draw fault trees. Again, a skill often learned in graduate school. But you can pick it up in no time.
Distributed computing can increase reliability if you know how to assemble the systems correctly. Otherwise you end up with a system with lots of parts; any of them can bring the system down. If a system fails once per year, and you have two systems, expect a failure twice per year. Plus some extra down time for the equipment that hooks them together.
What about fail-over? One server goes down and the other picks up the slack? Great, unless the database dies. Or the service you are calling. Or the network line. Or you deploy the same bug to both servers. Common-mode faults can bring down your backup system just as easily as your primary. Draw your systems with fault-tree diagrams.
Versioning is hard: Often, quite the opposite is sold. For example, a selling point for SOA is that you can make an update in one place, and all systems calling that service will be updated. Perfectly logical.
But wait, you wouldn’t deploy that change to a production system without testing it, would you? So if you update a service, you have to test that update with each and every system that calls it. If a dozen programs use your service, you have to pay a dozen different teams to test your SOA update. And hope that none of them has more important things to do, forcing your update to get put on hold.
It gets worse! Applications using your service, are updating as well. So you can’t test their updated code with your updated code unless you deploy your code at the same time. You must ask them to go through a test with their current production code. This usually means putting their new code on hold.
At the large bank I last worked with, we have quarterly releases. This helped with issues on versioning between front-end applications and services because everyone released at once. There was a big disadvantage through. If an important service did not make a quarterly release date, no one made the quarterly release date. If a service was deployed and did not work, everyone rolled back (or you limped along with a broken system). And with small critical bugs, you still had to test against old code-bases.
Conclusion: I don't dislike SOA. In fact, I think it is a wonderful and critical tool in a developer's arsenal. But there is some kind of perverse thrill that developers get in making remote procedure calls. Some developers create remote calls without proving it will help improve speed and reliability. Some don't know how to prove it. Some go nuts and use it everywhere. And as for manageability, if anyone knows a solution, let me know.
(*) I liked our architects. They were smart. And if I was one, I would have loved making presentations with boxes and arrows.
But if you use SOA, understand the pitfalls.
I learned parallel computing the "academic" way. We had a task to speed up. We created mathematical proofs. We ran experiments. We backed our theories with the results. Then the results were reviewed by professors and peers.
We knew that distributed computing was going to be the next big thing. And it was! But it was taught to the masses in magazines and internet articles. Developers got all the coolness of SOA without seeing the hard parts, or having to work through the theory.
So here is my list of three major things I’ve seen people get bitten by. I came up with this list during my last project. That project handled 2.5 million page views per day, many of which were processed by using SOA. One page required 43 service calls. SOA was our lifeblood and our curse.
Top Three SOA Pitfalls
Distributed Computing is Slower: Conventional wisdom claims the opposite, lots of computers processing instead of one. So while we know it can be faster, the question is why did our app get slower?
Let’s answer that question with another question: How long does it take to make a function call on your local computer? Don’t know? Then run a quick experiment and come back. I’ll wait.
Ok, you’re back. I got about 20 nanoseconds with Java. What did you get?
What about making a distributed call? To do that I have to:
- Convert data to XML
- Pipe it over the wire
- Parse XML
- Process
- Convert response to XML
- Pipe it pack over the wire
- Parse XML into the data I want.
Just one network hop usually changes us from measuring time in nanoseconds to measuring time in milliseconds. Quick, go run your own experiment. (Making a network call localhost doesn’t count!)
I got 20 milliseconds. That makes a local call 1,000,000 times faster than a network call. What did you get? I’ll bet it was a lot slower than your local call!
But wait! That’s not slow enough for some people. What if we add another layer of middleware or a message queue? Heck, at my last job we added both. Architects love layers. The best architects are educated at Hogwarts. They draw diagrams and wave their hands at meetings. Then management gets a glazed look on their eyes and magically starts writing checks. Why didn’t I go to that school? (*)
Before SOA was big, I worked at a small company that built a user-customized portal called Agdayta. It showed futures quotes, news tickers, and other investment-type things. We pulled data using all sorts of services. By keeping in mind the expense of these calls, we managed to produce custom portal pages in less than 10 ms. Using Pentium II computers. And full session fail-over. Before any of this was built into Java.
Later I worked at a big company. We had 5 machine clusters, each machine with 8 processor cores. Even though we made less complicated pages, the pages took 50 times longer to render. Why? There were too many services and calls and leaky abstractions.
Distributed computing CAN be faster if the advantage of distribution makes up for the overhead. But you have to do the math and understand the theory.
Distributed computing is less reliable: Wait, isn’t it more reliable?
This is where some background in safety engineering can be good. I recommend learning to draw fault trees. Again, a skill often learned in graduate school. But you can pick it up in no time.
Distributed computing can increase reliability if you know how to assemble the systems correctly. Otherwise you end up with a system with lots of parts; any of them can bring the system down. If a system fails once per year, and you have two systems, expect a failure twice per year. Plus some extra down time for the equipment that hooks them together.
What about fail-over? One server goes down and the other picks up the slack? Great, unless the database dies. Or the service you are calling. Or the network line. Or you deploy the same bug to both servers. Common-mode faults can bring down your backup system just as easily as your primary. Draw your systems with fault-tree diagrams.
Versioning is hard: Often, quite the opposite is sold. For example, a selling point for SOA is that you can make an update in one place, and all systems calling that service will be updated. Perfectly logical.
But wait, you wouldn’t deploy that change to a production system without testing it, would you? So if you update a service, you have to test that update with each and every system that calls it. If a dozen programs use your service, you have to pay a dozen different teams to test your SOA update. And hope that none of them has more important things to do, forcing your update to get put on hold.
It gets worse! Applications using your service, are updating as well. So you can’t test their updated code with your updated code unless you deploy your code at the same time. You must ask them to go through a test with their current production code. This usually means putting their new code on hold.
At the large bank I last worked with, we have quarterly releases. This helped with issues on versioning between front-end applications and services because everyone released at once. There was a big disadvantage through. If an important service did not make a quarterly release date, no one made the quarterly release date. If a service was deployed and did not work, everyone rolled back (or you limped along with a broken system). And with small critical bugs, you still had to test against old code-bases.
Conclusion: I don't dislike SOA. In fact, I think it is a wonderful and critical tool in a developer's arsenal. But there is some kind of perverse thrill that developers get in making remote procedure calls. Some developers create remote calls without proving it will help improve speed and reliability. Some don't know how to prove it. Some go nuts and use it everywhere. And as for manageability, if anyone knows a solution, let me know.
(*) I liked our architects. They were smart. And if I was one, I would have loved making presentations with boxes and arrows.
Subscribe to:
Posts (Atom)
