Gaphor, the UML modeling tool written in Python, has a new release available. The 0.15.0 beta release has many enhancements and features but there are two notable fixes that make this beta release a worthwhile upgrade from the latest stable release.
The latest stable Gaphor release introduced an element editor dialog. This dialog was a nice enhancement because it freed up more space for the diagram canvas. However, it was painful to use if you have multiple desktop windows open. Trying to switch between windows was a hassle. This has been fixed by making the element editor a modal dialog that is part of the main Gaphor window.
Another huge improvement was made in the element editor dialog. It can now be re-sized. This doesn't sound like a big deal but if you wanted to work with a large class that has dozens of attributes and methods, you simply could not do it. Now you can.
Tuesday, January 26, 2010
Tuesday, January 12, 2010
Proprietary Threats
In a recent entry about the state of the Postgres project, the author explains that the project is still in good health. This explanation was brought about by the recent idea that Oracle could simply buy them out by head-hunting the core developers. This is a lot more difficult to do than it sounds. Especially for open source projects such as Postgres.
The fear seems to be that Postgres will go the way that MySQL did. But, as the entry points out, they are entirely different in terms of development culture. Postgres is different in that it doesn't have a single authority in which to make decisions.
Proprietary vendors can threaten open source projects in more ways than one. It can overcome open source projects by nothing more than intimidation. They have a lot of resources. These resources include buying power. Large corporations can typically purchase their way out of potential competition.
Open source developers really shouldn't concern themselves with this threat for two reasons. One, open source projects are largely distributed both geographically and in interests. New people join open source projects every day. Again, as the entry suggests, there are more than enough developers that will be willing to pick up the slack of those who leave any given project.
Another reason why the open source community shouldn't concern themselves with proprietary vendor threats is that competition can also be a good thing. It can be a good thing for both parties.
In a given domain, lets say databases, users have a choice between proprietary products and open source projects. Both sides can benefit from one anther because they provide a reference point in which to do comparisons. So the open source project can say "you can pay for feature X or you can get feature YZ for free" while the proprietary vendors can say "sure, feature YZ is stable, but you paying for stability in feature X".
The list goes on. There is never going to be an entirely open source or an entirely proprietary software world. Threats will be posed from both directions. If you are a developer, your best bet is to just use what is made available to you to make the best software possible. Better than the last version anyway.
The fear seems to be that Postgres will go the way that MySQL did. But, as the entry points out, they are entirely different in terms of development culture. Postgres is different in that it doesn't have a single authority in which to make decisions.
Proprietary vendors can threaten open source projects in more ways than one. It can overcome open source projects by nothing more than intimidation. They have a lot of resources. These resources include buying power. Large corporations can typically purchase their way out of potential competition.
Open source developers really shouldn't concern themselves with this threat for two reasons. One, open source projects are largely distributed both geographically and in interests. New people join open source projects every day. Again, as the entry suggests, there are more than enough developers that will be willing to pick up the slack of those who leave any given project.
Another reason why the open source community shouldn't concern themselves with proprietary vendor threats is that competition can also be a good thing. It can be a good thing for both parties.
In a given domain, lets say databases, users have a choice between proprietary products and open source projects. Both sides can benefit from one anther because they provide a reference point in which to do comparisons. So the open source project can say "you can pay for feature X or you can get feature YZ for free" while the proprietary vendors can say "sure, feature YZ is stable, but you paying for stability in feature X".
The list goes on. There is never going to be an entirely open source or an entirely proprietary software world. Threats will be posed from both directions. If you are a developer, your best bet is to just use what is made available to you to make the best software possible. Better than the last version anyway.
Saturday, January 9, 2010
Fear Of Modeling
Does the idea that there is a general fear of modeling software sound like a real problem? Or, is it simply a matter of practicality? In most circumstances, modeling software, either during implementation or before, isn't beneficial to the project. Practicality aside, there are many large software projects in existence today haven't had requirement of any formal modeling in order to succeed. This doesn't mean that these development teams responsible for these projects have a fear of modeling. It means that they were able to approach the problem at hand tackle in a timely, and predictable manor.
So what does cause a fear of modeling? There are far too many reasons that organizations as well as individual developers don't model the software they are building to give here. There are, however, some very generic reasons that most software goes without a model. The chief reason being a generalized fear of modeling. Not just the act of modeling itself, which is often a very enjoyable experience. This fear of modeling arises due to a number of inter-connected factors.
The technology exists today to model just about anything, including software. Impossibility has nothing to with the problem. Further, there are many professional developers who have at least a fundamental grasp of modeling standards. These models, using standardized notation or not, can be illustrated using old, legacy technology, pen and paper. Shocking.
If the project is slightly more important than something you might contribute to on the side, such as an open source project, it is probably a better idea to construct any software models with software. It is easier to communicate with others using these models. Particularly, it is very helpful to provide a repository that stores all models for a given project. Nothing is lost, neither good nor bad. We can still learn from bad models.
Getting back to the fear that is involved whenever modeling software in various development cultures. Is the fear of modeling restricted to those team members intricately entwined with the code? Absolutely not. Any activities that are executed by a team affect every team member. In other words, modeling software that is about to be implemented requires both time and effort. And and here is the mythical part, the produced models aren't usable by paying customers and aren't worth doing. In some cases, the argument that software models aren't worth doing do to timing and resource constraints holds some merit. Consider an getting a patch out to an already deployed system. In this scenario, getting the design right is hardly more important than keeping the customer.
Is it possible to convince managers that modeling the software you, as a team are building has value? Of course it is. What really helps here is being able to produce high-level, non-technical, big-picture models of the system in question. If managers feel that they can better understand what is being built, they can better relate to why other modeling activities help developers better understand the system. And that means your boss is more likely to view software models as a valid product artifact.
Developers are obviously the main beneficiary of software models. The purpose of a software model is to better understand a software system. That is it. There are endless ways in which a developer can better understand a system but when they do, it results in a better product. Developer's fear of modeling often stems from an emphasis on producing a large, complete, and correct model before implementation has begun. It is true that you should start modeling before you start coding but don't get carried away. You'll often get a sense of when it is time to test out an idea, in code, while modeling. Don't resist the urge to code while modeling and don't abandon the model once coding has started.
What should software development teams be using to model software with? The UML offers a coherent set of standardized software modeling constructs. The UML in and of itself can be a source for fear of software modeling. A common misconception of the UML is that the entire set of modeling elements should be used for any given project. This couldn't be further from the truth. Use only what you need. The other elements are there if, and only if, you need them. I would recommend that each development team member have a basic understanding of commonly used UML elements. Everyone can jot down ideas, pass them around, using a standardized notation. More advanced users can then merge ideas into more formal models if, and only if, they are needed.
Modeling is not importing a set of classes that have already been written as specific programming language instructions into some modeling software in order to produce a class diagram. While this can provide some useful insight into older systems that have already been implemented, doing this with newer systems misses the mechanical act of constructing a conceptual illustration. Modeling can have some hidden, subtle benefits.
Software modeling can be be hugely beneficial more many reasons. Although there is the illusion of lost productivity due to building models, these fears can be put to rest by putting software models to work. They aren't going to jump up and prove their own worth.
So what does cause a fear of modeling? There are far too many reasons that organizations as well as individual developers don't model the software they are building to give here. There are, however, some very generic reasons that most software goes without a model. The chief reason being a generalized fear of modeling. Not just the act of modeling itself, which is often a very enjoyable experience. This fear of modeling arises due to a number of inter-connected factors.
The technology exists today to model just about anything, including software. Impossibility has nothing to with the problem. Further, there are many professional developers who have at least a fundamental grasp of modeling standards. These models, using standardized notation or not, can be illustrated using old, legacy technology, pen and paper. Shocking.
If the project is slightly more important than something you might contribute to on the side, such as an open source project, it is probably a better idea to construct any software models with software. It is easier to communicate with others using these models. Particularly, it is very helpful to provide a repository that stores all models for a given project. Nothing is lost, neither good nor bad. We can still learn from bad models.
Getting back to the fear that is involved whenever modeling software in various development cultures. Is the fear of modeling restricted to those team members intricately entwined with the code? Absolutely not. Any activities that are executed by a team affect every team member. In other words, modeling software that is about to be implemented requires both time and effort. And and here is the mythical part, the produced models aren't usable by paying customers and aren't worth doing. In some cases, the argument that software models aren't worth doing do to timing and resource constraints holds some merit. Consider an getting a patch out to an already deployed system. In this scenario, getting the design right is hardly more important than keeping the customer.
Is it possible to convince managers that modeling the software you, as a team are building has value? Of course it is. What really helps here is being able to produce high-level, non-technical, big-picture models of the system in question. If managers feel that they can better understand what is being built, they can better relate to why other modeling activities help developers better understand the system. And that means your boss is more likely to view software models as a valid product artifact.
Developers are obviously the main beneficiary of software models. The purpose of a software model is to better understand a software system. That is it. There are endless ways in which a developer can better understand a system but when they do, it results in a better product. Developer's fear of modeling often stems from an emphasis on producing a large, complete, and correct model before implementation has begun. It is true that you should start modeling before you start coding but don't get carried away. You'll often get a sense of when it is time to test out an idea, in code, while modeling. Don't resist the urge to code while modeling and don't abandon the model once coding has started.
What should software development teams be using to model software with? The UML offers a coherent set of standardized software modeling constructs. The UML in and of itself can be a source for fear of software modeling. A common misconception of the UML is that the entire set of modeling elements should be used for any given project. This couldn't be further from the truth. Use only what you need. The other elements are there if, and only if, you need them. I would recommend that each development team member have a basic understanding of commonly used UML elements. Everyone can jot down ideas, pass them around, using a standardized notation. More advanced users can then merge ideas into more formal models if, and only if, they are needed.
Modeling is not importing a set of classes that have already been written as specific programming language instructions into some modeling software in order to produce a class diagram. While this can provide some useful insight into older systems that have already been implemented, doing this with newer systems misses the mechanical act of constructing a conceptual illustration. Modeling can have some hidden, subtle benefits.
Software modeling can be be hugely beneficial more many reasons. Although there is the illusion of lost productivity due to building models, these fears can be put to rest by putting software models to work. They aren't going to jump up and prove their own worth.
Tuesday, January 5, 2010
Free MySQL Free Internet
Monty, the creator of the MySQL database, says that Oracle acquiring Sun could be the end of MySQL. MySQL is a major competitor for Oracle's proprietary offerings.
LAMP stacks, which make up a huge part of the Internet depend hugely on MySQL and would be affected in a big way by this acquisition.
But would it affect the Internet as a whole? Sure, there would be a sizable impact but it would by no means shut things down for good. There are other open source databases out there. MySQL happens to be a great one and it would be a shame to see it go.
LAMP stacks, which make up a huge part of the Internet depend hugely on MySQL and would be affected in a big way by this acquisition.
But would it affect the Internet as a whole? Sure, there would be a sizable impact but it would by no means shut things down for good. There are other open source databases out there. MySQL happens to be a great one and it would be a shame to see it go.
Monday, January 4, 2010
Documenting Code
There are many reasons why developers are told to document their code. As Jason Baker shows, many of these common reasons for commenting code are mythical. That is to say, the added benefit for documenting a piece of code may be misguided in certain contexts.
For instance, comments need to be updated as the code is updated. This means more in-depth maintenance for comments. Unless you strive to keep comments simple and generic enough. This is usually the best approach.
Often, the best way to document your code is to spend a short amount of time and overview your code as though you were someone else. If that person needs an explanation for some section of code, give it to them. But keep it simple.
You can still document trivial methods that are self explanatory. The best reason for doing this is consistency.
For instance, comments need to be updated as the code is updated. This means more in-depth maintenance for comments. Unless you strive to keep comments simple and generic enough. This is usually the best approach.
Often, the best way to document your code is to spend a short amount of time and overview your code as though you were someone else. If that person needs an explanation for some section of code, give it to them. But keep it simple.
You can still document trivial methods that are self explanatory. The best reason for doing this is consistency.
Sunday, January 3, 2010
Simple Code Editors
This question on Slashdot asks about VIM text editing capabilities in more modern integrated development environments. The answers to the question seems to indicate that a number of options are available for those that want to bring development capabilities to newer code editors.
So, is it that we want to bring enhanced text editing capabilities, that have worked for years with VIM, into an IDE? Or should this text-editing capability be brought to the more modest code editors, not necessarily IDEs.
In most cases, integrated development environments get in the way more than they lend a hand in producing quality code. In other, niche, cases, they can be the perfect tool for the job.
So what is wrong with VIM exactly? Nothing. That is, there is nothing wrong with VIM for using it as a simple code editor. It just so happens that simple code editors are in huge demand these days and so VIM is still the editor of choice for many developers for its advanced text editing capabilities.
I find the main beneficial feature that newer code editors bring to the table are hierarchical class navigators. It isn't a matter of being able to navigate by class; VIM can do that. It is more a matter of being able to visualize the classes in the given more you are editing.
So, is it that we want to bring enhanced text editing capabilities, that have worked for years with VIM, into an IDE? Or should this text-editing capability be brought to the more modest code editors, not necessarily IDEs.
In most cases, integrated development environments get in the way more than they lend a hand in producing quality code. In other, niche, cases, they can be the perfect tool for the job.
So what is wrong with VIM exactly? Nothing. That is, there is nothing wrong with VIM for using it as a simple code editor. It just so happens that simple code editors are in huge demand these days and so VIM is still the editor of choice for many developers for its advanced text editing capabilities.
I find the main beneficial feature that newer code editors bring to the table are hierarchical class navigators. It isn't a matter of being able to navigate by class; VIM can do that. It is more a matter of being able to visualize the classes in the given more you are editing.
Subscribe to:
Posts (Atom)