Better Living Through Software
"RDF is often a whipping-boy, but a red-herring in this discussion."
Good discussion of RDF and SemWeb, explaining it and the issues.
Sunday, August 31, 2003
Friday, August 22, 2003
The New X-Men
Wired 11.09: The New X-Men
The Mountain Dew-fueled all-nighter is history. Today's supercoders work 40 hours a week. And two to a computer. It's called extreme programming - and it's revolutionizing the software world.
The Mountain Dew-fueled all-nighter is history. Today's supercoders work 40 hours a week. And two to a computer. It's called extreme programming - and it's revolutionizing the software world.
Tuesday, August 19, 2003
An Extreme Programming Episode
Object Mentor - xpepisode.htm
In order to demonstrate XP (eXtreme Programming) practices, Bob Koss (RSK) and Bob Martin (RCM) will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob's actually did.
In order to demonstrate XP (eXtreme Programming) practices, Bob Koss (RSK) and Bob Martin (RCM) will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob's actually did.
Monday, August 18, 2003
xprogramming.com
XProgramming.com - an Extreme Programming Resource
XProgramming.com is a resource for information about Extreme Programming (XP), the exciting new streamlined software development process originally described by Kent Beck. XProgramming.com is offered as a community resource for those interested in XP and related topics.
XProgramming.com is a resource for information about Extreme Programming (XP), the exciting new streamlined software development process originally described by Kent Beck. XProgramming.com is offered as a community resource for those interested in XP and related topics.
Thursday, August 14, 2003
The Test/Code Cycle
Specifically, it shows how unit tests and simple design work together while programming. Observe how the coding process occurs in small steps, just enough implementation to make each test run. There's a rhythm to it, like a pendulum of a clock: test a little, code a little, test a little, code a little.
I'm a big fan of Test Driven Development (TDD). My favorite aspect is that it allows me to write the least amount of code possible. I spent time making tests pass, instead of coming up with the coolest way to do it.
Tuesday, August 12, 2003
Emergent Design vs Early Prototyping
Emergent Design vs. Early Prototyping - Software Reality
However, early prototyping (used correctly) provides many of the benefits of an agile approach (for example early feedback), whilst retaining the more rigorous benefits gained from designing a system before coding it up.
This article seems to forget all about XP's Spike Solution phase. In this phase, if the solution to a problem is unknown, it's OK to do a Spike Solution. This is a quick test of a small slice of an application to prove, or figure out, what and where the pieces of an application might be. For instance, if there is a new persistence layer that might be nice to use, test it out in a Spike Solution.
This seems to be sort of the ideas behind the article. I disagree with the article on a few points. For example, time is always important on projects. You never have time enough. Why waste it on prototyping code to throw it out? By using XP's other tenets (unit testing, constant refactoring) the beginning code is as good as the end code. No need to throw out an entire prototype.
Note that a Spike might be thrown out, but it's OK because it's a very small slice of the app.
From practical experience, every prototype solution always gets deployed to production. Why not, from the start, treat all code as production?
However, early prototyping (used correctly) provides many of the benefits of an agile approach (for example early feedback), whilst retaining the more rigorous benefits gained from designing a system before coding it up.
This article seems to forget all about XP's Spike Solution phase. In this phase, if the solution to a problem is unknown, it's OK to do a Spike Solution. This is a quick test of a small slice of an application to prove, or figure out, what and where the pieces of an application might be. For instance, if there is a new persistence layer that might be nice to use, test it out in a Spike Solution.
This seems to be sort of the ideas behind the article. I disagree with the article on a few points. For example, time is always important on projects. You never have time enough. Why waste it on prototyping code to throw it out? By using XP's other tenets (unit testing, constant refactoring) the beginning code is as good as the end code. No need to throw out an entire prototype.
Note that a Spike might be thrown out, but it's OK because it's a very small slice of the app.
From practical experience, every prototype solution always gets deployed to production. Why not, from the start, treat all code as production?
EJB’s 101 Damnations
Software Reality - EJB's 101 Damnations
Whilst writing the EJB modules for our JGenerator product, we started punting an email back and forth containing all the issues we had with EJB. And there were many. Before we knew it we ended up with 101 howlers.
This is an old document, one that I just dug up. Some of the points are valid, some less. But it all adds up to one thing: EJBs are often used as the wrong solution.
Whilst writing the EJB modules for our JGenerator product, we started punting an email back and forth containing all the issues we had with EJB. And there were many. Before we knew it we ended up with 101 howlers.
This is an old document, one that I just dug up. Some of the points are valid, some less. But it all adds up to one thing: EJBs are often used as the wrong solution.
Input Tag Library
Jakarta-Taglibs: Input Tag library
The "input" tag extension library lets you present HTML elements that are tied to the ServletRequest that caused the current JSP page to run, or to a JavaBean. That is, using this library, you can easily prepopulate form elements with prior values that the user has chosen -- or with default values for the first time a user hits a web page. This is useful when you need to present the same page to the user several times (e.g., for server-side validation).
This is to help me in my quest to find replacements for the pieces of Struts that I like
in an effort to move away from Struts.
The "input" tag extension library lets you present HTML elements that are tied to the ServletRequest that caused the current JSP page to run, or to a JavaBean. That is, using this library, you can easily prepopulate form elements with prior values that the user has chosen -- or with default values for the first time a user hits a web page. This is useful when you need to present the same page to the user several times (e.g., for server-side validation).
This is to help me in my quest to find replacements for the pieces of Struts that I like
in an effort to move away from Struts.
The Case Against Extreme Programming
Extreme Programming problems
This is a long article, and I admit I had trouble getting through it. I believe the author has some points worth mentioning, but fails to really grasp a major aspect: That XP is not for every project or team or situation.
I am a huge fan of XP for many reasons. Each methodology addresses a unique set of problems or issues. XP addresses two main issues: Change and the Risk associated with it. XP attempts to mitigate the risks of changing the system.
If you are lucky enough to be on a project where the customer can clearly articulate their requirements once, then maybe XP isn't right for you. From experience, most customers in the e-business arena, don't know what they are building. Some don't even know the problem they are trying to solve. XP, then, is a great way to tackle the problem.
Again, choosing the right methodology is not easy, but understanding the potential problems of the situation will help in picking the right one. Understand when XP is good, and understand when it's not. But don't try to change XP into something it's not, when all you needed was a different process.
P.S. A personal gripe. I've seen these types of arguments against XP before. They usually come from a person that feels threatened by the process. This person might fancy themselves an Architect, one that sits on the mountain and dispenses Beautiful UML Diagrams down to the people. XP completely removes this type of position from the team. It spreads it out, valuing an emergent design over one that is dictated.
This is a long article, and I admit I had trouble getting through it. I believe the author has some points worth mentioning, but fails to really grasp a major aspect: That XP is not for every project or team or situation.
I am a huge fan of XP for many reasons. Each methodology addresses a unique set of problems or issues. XP addresses two main issues: Change and the Risk associated with it. XP attempts to mitigate the risks of changing the system.
If you are lucky enough to be on a project where the customer can clearly articulate their requirements once, then maybe XP isn't right for you. From experience, most customers in the e-business arena, don't know what they are building. Some don't even know the problem they are trying to solve. XP, then, is a great way to tackle the problem.
Again, choosing the right methodology is not easy, but understanding the potential problems of the situation will help in picking the right one. Understand when XP is good, and understand when it's not. But don't try to change XP into something it's not, when all you needed was a different process.
P.S. A personal gripe. I've seen these types of arguments against XP before. They usually come from a person that feels threatened by the process. This person might fancy themselves an Architect, one that sits on the mountain and dispenses Beautiful UML Diagrams down to the people. XP completely removes this type of position from the team. It spreads it out, valuing an emergent design over one that is dictated.
Problem with XP?
Fundamental Problem with Extreme Programming
"XP requires too much of an investment from the business."
I disagree with that statement completely. XP allows the business do what they do best: solve business problems and be in control of the software deliverable.
If the business doesn't know enough about the problem they are trying to solve, then the project will never be correct. It doesn't matter how good the programmer is, if the customer doesn't know what they are trying to accomplish, then the project is doomed.
Of course, the question of "How to technically solve the problem" is up to the programmer.
XP is good because it acknowledges the customer is a participant in the process of developing software during the entire process.
"XP requires too much of an investment from the business."
I disagree with that statement completely. XP allows the business do what they do best: solve business problems and be in control of the software deliverable.
If the business doesn't know enough about the problem they are trying to solve, then the project will never be correct. It doesn't matter how good the programmer is, if the customer doesn't know what they are trying to accomplish, then the project is doomed.
Of course, the question of "How to technically solve the problem" is up to the programmer.
XP is good because it acknowledges the customer is a participant in the process of developing software during the entire process.
Python + Eclipse
PythonEclipse
PythonEclipse is just at it's start. So it currently only features an incomplete Python editor, the ability to create launch configurations for Python and to launch Python scripts.
PythonEclipse is just at it's start. So it currently only features an incomplete Python editor, the ability to create launch configurations for Python and to launch Python scripts.
GSS: Graph Stylesheets
IsaViz/GSS User Manual - Graph Stylesheets
Graph Stylesheets are a way to associate style to node-edge representations of RDF models, but also to hide part of the graph and to offer alternative layouts for some elements. This means that based on some selectors (detailed later), it is possible to assign, among other things, color, stroke width, bitmap icons or font style to specific nodes and edges in the graph. It is also possible to hide selected nodes and edges, or to lay them out (along with the node at the other end of the edge) in tables in order to group them in a region of the visualized space.
Graph Stylesheets are a way to associate style to node-edge representations of RDF models, but also to hide part of the graph and to offer alternative layouts for some elements. This means that based on some selectors (detailed later), it is possible to assign, among other things, color, stroke width, bitmap icons or font style to specific nodes and edges in the graph. It is also possible to hide selected nodes and edges, or to lay them out (along with the node at the other end of the edge) in tables in order to group them in a region of the visualized space.
IsaViz 2.0
IsaViz Overview
IsaViz is a visual environment for browsing and authoring RDF. It's now at version 2.0.
IsaViz is a visual environment for browsing and authoring RDF. It's now at version 2.0.
Monday, August 11, 2003
Jython
Jython Home Page
Jython is an implementation of the high-level, dynamic, object-oriented language Python written in 100% Pure Java, and seamlessly integrated with the Java platform. It thus allows you to run Python on any Java platform.
I just got this to work with PyServlet. It's a servlet w/ a Jython interpretor built-in. It can reload the python file when it changes, which is really nice.
The more I think about it, though, the more I want Eclipse to handle Python. I know Jython is really cool, but I can't take advantage of all the amazing code completion and refactoring tools Eclipse has to offer.
In short, I am looking for Eclipse + Python + Servlets. I just need a less verbose language that doesn't need to get compiled that has a kick ass IDE and that has a nice, mature web framework.
So close!
Jython is an implementation of the high-level, dynamic, object-oriented language Python written in 100% Pure Java, and seamlessly integrated with the Java platform. It thus allows you to run Python on any Java platform.
I just got this to work with PyServlet. It's a servlet w/ a Jython interpretor built-in. It can reload the python file when it changes, which is really nice.
The more I think about it, though, the more I want Eclipse to handle Python. I know Jython is really cool, but I can't take advantage of all the amazing code completion and refactoring tools Eclipse has to offer.
In short, I am looking for Eclipse + Python + Servlets. I just need a less verbose language that doesn't need to get compiled that has a kick ass IDE and that has a nice, mature web framework.
So close!
Enhancing Data Interoperability with Ontologies
Enhancing Data Interoperability with Ontologies, Canonical Forms, and Include Files
There are many different units-of-measure. Lengths, speeds, locations, etc can be expressed in many different ways. Fusing two independent pieces of data that, for example, express the same length but use different units requires the fusing agent to recognize that the data is related via a transformation. How can relationships which involve transformations be declaratively expressed?
There are many different units-of-measure. Lengths, speeds, locations, etc can be expressed in many different ways. Fusing two independent pieces of data that, for example, express the same length but use different units requires the fusing agent to recognize that the data is related via a transformation. How can relationships which involve transformations be declaratively expressed?
Just In Time Design
Demystifying Extreme Programming: Just-in-time design
People who aren't familiar with XP are bothered by the concept of just-in-time (JIT) design -- designing and implementing what you know you need right now and not worrying about future design issues until absolutely necessary. While this approach might seem unwise or even reckless, XP advocate Roy Miller wraps up his series by showing you how safe and easy JIT design is -- and how it just might revolutionize the way you write code.
People who aren't familiar with XP are bothered by the concept of just-in-time (JIT) design -- designing and implementing what you know you need right now and not worrying about future design issues until absolutely necessary. While this approach might seem unwise or even reckless, XP advocate Roy Miller wraps up his series by showing you how safe and easy JIT design is -- and how it just might revolutionize the way you write code.
Thursday, August 7, 2003
Struts and WebArch
The Apache Struts Web Application Framework
At first I thought this post wouldn't fit this blog's theme, but then again, I realized it's all about Web Architecture.
I've been using Struts for years, and it's a true love/hate relationship. Actually, it's more of a Like/Hate.
I'm going to try to enumerate why I like it, and why I don't.
Why I like it:
Why I don't like it:
I think there are other quirks in there. My main problem with Struts is it is trying to apply a GUI design principle (MVC) to the Web. I'm not convinced it's a perfect way to think about things.
I would like the framework to be more REST friendly and treat everything as a set of Resources, not Actions.
At first I thought this post wouldn't fit this blog's theme, but then again, I realized it's all about Web Architecture.
I've been using Struts for years, and it's a true love/hate relationship. Actually, it's more of a Like/Hate.
I'm going to try to enumerate why I like it, and why I don't.
Why I like it:
- Automatic form validation. In retrospect, I only use this sometimes. Still, it's nice to have a form fail validation and get redirected to the input page.
- Automatic form filling for those failed forms. It's nice to have the select box, for instance, come up to the correct option.
- It's a well known framework. Don't have to teach people much.
Why I don't like it:
- No support for action name with wildcards. For instance, you can't setup a mapping for
/person/*. There is some hacking you can do, but it only gets you half way. In the<html:form>tag, you can't use those wildcards without hacking the source deep down. - Too much emphasis on verbs instead of nouns. Here is my major beef with Struts. It wants you to think in terms of Actions (such as addUser.do or editAddress.do). This is too RPC for my tastes. We've been taught that the WebArch likes URIs that identify nouns. The HTTP method (GET or POST) is what identifies the action. Struts makes this too hard. It's fairly possible to work with struts where the Actions become nouns, but it's not pretty.
- Struts' I18N uses some weird class
MessageResourcesinstead of the standardResourceBundlelike the rest of Java's I18N implementations. We had to write an Adaptor from one to the other. This usually isn't the case when using property files for translations, but we are using Java classes for the translation resources. Why a separate class? - Often times, I need to do validation inside the Action. That's OK, but then I have to bypass Struts' auto-validation. That's OK, except that it's one of the main reasons I even use the framework! There may be a way around this. I know that
FormBeans have avalidate()method, but that may overridden when it's a ValidatorFormBean. Can I have Validator automatic validation plus custom validation logic in a form bean?
I think there are other quirks in there. My main problem with Struts is it is trying to apply a GUI design principle (MVC) to the Web. I'm not convinced it's a perfect way to think about things.
I would like the framework to be more REST friendly and treat everything as a set of Resources, not Actions.
Wednesday, August 6, 2003
Mapping London as RDF
this is a kind of collaborative mapping project. it consists of geographical models which are represented as RDF graphs. you can wander round them, like a MUD or MOO, with a bot interface which you can use to create and connect new places.
Friday, August 1, 2003
The Future of Human Knowledge
TechNewsWorld.Com: Real-Time Technology News from Around the World
Under an interdisciplinary project collectively known as the Semantic Web, computer scientists around the world are working on ways to revolutionize the Internet. The researchers -- from Europe, Asia and the United States -- are developing standards, protocols and technologies that will advance the development of a more meaning-oriented Web.
Under an interdisciplinary project collectively known as the Semantic Web, computer scientists around the world are working on ways to revolutionize the Internet. The researchers -- from Europe, Asia and the United States -- are developing standards, protocols and technologies that will advance the development of a more meaning-oriented Web.
Subscribe to:
Posts (Atom)
Disclaimer
