Posts Mentioning RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mike 9:58 pm on June 30, 2008 Permalink | Reply
    Tags:   

    Fairy Tale of the Fruit Tree 

    This is a reprint of a fantasy authored by Yutaka Kachi and translated by Mikiko Kachi. Originally from http://www.catch.jp/openoffice/whats_oss/index_en.html.

    I am reprinting it because it is only available through PDF. I want to share it and make it easier to read and comment on. I found it in 2005 and saved the PDF. I found the the file this morning and thought it would be good to share and discuss.

    Long long time ago, there was a tree in a field of grass near a village. One day, this tree bore a lot of delicious fruit.

    The fruit were very delicious. So villagers soon harvested all of the fruits.

    There was no end to the number of people who cut branch of this tree and take them home.

    Because of this, the tree died in a few years.

    In the village, there was a clever merchant. He grafted the tree before the tree died.

    And he fertilized the tree, cut off branch when it’s too much. He took care of the tree for a long time.

    Then the tree bore fruit. He sold it and made big money.

    He was a real worrier. He fenced around the tree and was always watching the tree.

    This merchant was not just an worrier, but also a hard worker.
    His effort made the fruit more delicious and a lot of people bought it.

    Some people delivered it to busy villagers, and some people made jam from the fruits and sold it.

    The merchant monopolized the fruit tree.

    When someone said to him “ there are many worm holes ” , he heard nothing of it and said “ It’s cheap so you can’t complain that.”

    When someone asked him “ do you use any harmful fertilizer?”
    he said “ it’s company secret” and wouldn’t answer that question.

    When someone offered him “ I’d like to buy branch”, he said “ I don’t want to have competitors” and rejected the offer.

    More and more people started to sell the fruit and more and more people bought it.

    Then the merchant increased the price and made a big profit.

    In this village, there was a young man who really loved this fruit. When the merchant increased price of the fruit, he couldn’t afford it any more because he was very poor.

    So, he got interested in another tree near the village. This tree also bore a lot of fruit, but its taste was not so good and no one had cared for it. The young man started taking care of it with his friends.

    Therefore, the tree bore more fruit than they could eat. So they put up a sign board that said “ Free”. There were some people who take the fruit away although they didn’t take care of the tree, but the young man didn’t mind at all.

    The young men kept making effort for years to improve taste of the fruit as much as possible. Some people who took the fruit said “ I will help you”, “I will help you too because we don’t want to kill this tree like the first one” and helped doing time-consuming works.

    The more people helped, the more people took the fruit. When the fruit run short, the people grafted the tree to grow more. They put up “ Free” sign boards on new trees also.

    Some people delivered the fruit, and some people made jam from the fruit. They were very cooperative and sometimes they pay for agricultural equipment, fertilizer and inviting specialists to get advise.

    So they reduced warm holes, improved the taste of the fruit, and their fruit became much more popular.

    Years later, many fruit trees were planted around the village and bore a lot of delicious fruit.


    The villagers started delivering the young men’s fruit together to far-off town. In that town, many people said “I’ve never had such a delicious fruit !” and the fruit became popular. It sold like hot cakes.

    And not only the young man but also his friends and villagers all became happy.

    By the way, what happened to the merchant who monopolized the fruit tree?

    His business was also going well. For only a short while he had a fewer customers, but he expanded his business by hiring many people, shipping the fruits to far-off town, buying up fruit trees which had grown in other villages, etc.

    There was no difference between the young man and the merchant in terms of making delicious fruit.

    This is a great, simple explanation of how open source works and why the model it is successful. Growing a fruit tree is relatively easy compared to writing software, but as software development tools get easier to use, and more people learn to write code, it was and is inevitable that the number of open source tools and the quality of those tools will increase.

    There are two more PDFs that talk around open source licensing at http://www.catch.jp/openoffice/whats_oss/index_en.html.

     

  • Mike 5:54 pm on June 26, 2008 Permalink | Reply
    Tags: 2.1.0, , wildcard   

    If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off 

    Architecture Rules is proud to announce that it now support wild cards.

    Benefits of Wildcards

    Wildcards bring the ability to match multiple packages with one Rule entry. This falls inline with the original goal of the project, which was to simplify the usage of jDepend and to define rules in a way that is very readable, understandable, and modifiable.

    With wildcards, users can now define a package or violation in one line with the ability to match many packages. This means you won’t need to update your Rules each time you add a new package and your XML configuration file will be much shorter.

    Wildcard Patterns

    We identified a few different Wildcard Patterns. Some we don’t support and don’t plan on supporting, others we do support, and there are still a couple that we want to add.

    Here is a description of what we now support:

    Internal Wildcard Terminating Wildcard
    Wildcard stated within a package. Wildcard stated at the end of a package.
    com.company.*.dao com.company.project.dao.*
    Match One Package Match Many Packages
    Match to the depth of one package with the .* combination Match to the depth of one or more packages with the ..* combination
    com.company.*.dao matches only com.company.SOMETHING.dao com.company.project.dao..* matches ..dao.hibernate
    as well as packages below hibernate: ..dao.hibernate.user,
    ..dao.hibernate.account,
    etc.

    Example

    Now creating a rule to assert that the web layer does not interact with the DAO (or integration) layer is as easy as:

    <rule id="web-layer">
 <comment>web and dao mix like oil and water</comment>
 <packages>
  <package>com.company.app.web..*</package>
 </packages>
 <violations>
  <violation>com.company.app.dao..*</violation>
 </violations>
</rule>

    Prior to wildcards, you might have needed to define ..web.controllers, ..web.filters, ..web.views, ..web.forms, ..web.tags as the packages, and then you would have had to defined every ..dao package as a violation. Now its easy!

    Implementation

    Architecture Rules uses Regular Expressions to compare the packages with wildcards against the inspected packages. The regular expression needed to be able to handle exact packages, one package deep, and one or more packages deep. We accomplished this by modifying the given package with wildcards (such as com.company.project.*) to apply regular expression characters.

    Thank you to Ryan Stewart for helping us hash out this expression. This is what we came up with:

    final String regex = this.path
    // foo.bar exactly foo.bar
    .replaceAll("\\.", "\\\\.")
    // foo.bar.1 or foo.bar.1.2 and so on...
    .replaceAll("\\\\.\\\\.\\\\*", "\\\\.\\[A-Za-z_0-9.]")
    // packages only
    .replaceAll("\\.\\*", "\\.[A-Za-z_0-9]*");

    The break down is this: The third line of code looks for ..* combination and replaces it with the regular expression to allow for any string with any number of periods.

    The fourth line of code looks for the remaining .* combinations and replaces it the an expression to match package name but no more periods.

    If you consider yourself a regular expression wizard, please consider taking a moment to review this and offer any feedback or suggestions that you might come up with. Thank you.

    Outstanding Issues

    One usability issue that we have uncovered is the matching of the package prior to the wildcard. For example, some users think that com.company.project.* should match com.company.project in addition to the packages under project. Others aren’t sure it should match ..project. As of right now ..project is not included as a match. We are open to comments on this and welcome feedback from the early adopters.

    Roll Out

    Wildcard support has been slated for the 2.1.0 release which should happen any day now. We are just waiting for a couple of our early adopters to test the wildcards with the 2.1.0-SNAPSHOT that is currently in the maven repository.

    If you’ve been waiting and can’t wait to try it out, or if you can help out with testing, just grab the jar, or add our repository and dependency to your maven pom.xml.

    Thanks

    Finally. Thanks you to Andrew Swan for hounding us to get this feature implemented and for sticking with us while we worked on it. Also thank you for testing it for us. Thank you, again, to Ryan Stewart for helping out with the regular expression. And as always, thank you to Mykola Nickishov for working diligently on the Maven 2 plugin that will be released with the 2.1.0 release of Architecture Rules.

    And thank you to you for reading this far. Now go get Architecture Rules and start Asserting Your Architecture!

     

  • Mike 2:56 pm on June 21, 2008 Permalink | Reply  

    How does an established company adopt Open Source? 

    I don’t know the answer. Its a question not a statement.

    So lets say you’re a developer who programs in a corporate environment. You’ve found some great open source tool that you want to use at work, but your organization doesn’t use open source software. What do you do? What are your options? Where do you start?

    What if you’re a manager. You don’t write code, but you’ve read about open source and think it can help your guys write better code, faster. What course of action might a middle-tier manager take to get open source into the hands of your developers?

    Finally, put yourself in the shoes of your CIO. You’ve been to the conferences, you’ve enjoyed you’re free muffins and you’ve been convinced that open source is the way to go. What can you, the CIO, do to push open source down upon your developers?

    Thanks for reading, but this post really requires your participation. Please share a thought or two…

     

    • Mike 3:02 pm on June 21, 2008 Permalink

      I’ll start with this: If you’re the CIO, or a middle manager and you want to introduce open source tools and concepts to your organization, check with your developers. They may already be in the know when it comes to open source software.

      You might have developers under you who contribute to highly visible open source projects in the evenings or on the weekends. You may even have a developer or two who run their own projects, and orchestrate a team of remote developers from around the world. Actually, you might find out that one of your developers runs a team larger than the one that you do ( : Interesting…

    • welzie 9:40 am on June 23, 2008 Permalink

      I doubt a CIO is going to have any clue about what technologies should be used, unless they happen to see a 5 minute piece on the Today Show about the latest blogware.

      If a developer wants to move to an open source solution they should come up with working examples that will help show their coworkers how beneficial the os solution is to their company. You can’t just talk about how great something is, you also have to give concrete examples. Especially if your trying to get management to actually try something other than a “well that’s what we always use” solution from oracle, ibm, or m$.

    • peter lawrey 2:17 pm on June 23, 2008 Permalink

      It is hard for me to imagine an established company which doesn’t use some open source software, even indirectly.
      I believe you shouldn’t start with a solution e.g. open source software, and go looking for a problem for it to solve.
      Instead you should start with the known problems and look at all the realistic solutions. If open source software doesn’t come up, you should be asking why?
      But, I believe you shouldn’t be asking, how can I introduce open source software. You should be asking why haven’t you been using some open source software all along and see what you can do to address this mind set.

    • Jamo 4:18 pm on June 23, 2008 Permalink

      I wouldn’t even consider ‘adopting open source’ just like that, maybe ‘adopting open source for problem A, or problem B’. It should be considered on a per issue basis.

    • Mike 4:39 pm on June 23, 2008 Permalink

      @peter lawrey – re: “It is hard for me to imagine an established company which doesn’t use some open source software” The United States military, by policy does not utilize open source software.

      re:”You should be asking why haven’t you been using some open source software all along” Are you suggesting that this company has a problem at the core of the organization that probably stems out to a disaster? Like a string that if you pull on you uncover gigantic knot in?

      @Jamo – You’re absolutely correct. But I think you missed this point:

      There are some organizations out there who as a matter of policy do not use open source for any reason. They do not consider open source tools when analyzing a new project or on develop of an existing on on going product. This question was aimed at introducing one of these types of organizations to the value of open source.

  • Mike 11:17 am on June 15, 2008 Permalink | Reply  

    Greatest Barriers to Open-Source Adoption 

    CIO.com asked 328 information technology business executives and managers if they use open source applications in their organizations. The good news is that 53% answered that they are already using open source tools. The survey also uncovered why the other 47% had not.

    Greatest Barriers to Open-Source Software Adoption at Your Company?
    Concern Percent
    Product support concerns 45%
    Awareness/knowledge of available solutions 29%
    Security concerns 26%
    Lack of support by management 22%
    Licensing or legal concerns 21%
    Investment in architecture from other vendor(s) 20%
    Software quality issues 20%
    Customization concerns 15%
    Not relevant to our product or service 7%
    Pressure on open-source providers by commercial vendors 5%
    Software cost allocation policies 2%
    Other 9%

    For Corporate Software Developers

    Support

    To all you corporate software developers, the number one reason that some of your organizations do not allow open source products is because your bosses are afraid that there is no support for the tool. You need to show him that a particular tool is backed by a company who offers support. Show him or her the web page that explains the various support options that they provide.

    If there is indeed no support for a given tool, then you are the support. Explain how you have the source code, and how well it is documented. Discuss the benefits of an open product and how you can get help from user groups via forums, IRC, and mailing lists. Put your bosses at ease by showing them these mailing lists, and how active they are, or point out how many questions in the forum get answered on a daily basis.

    Awareness

    The number two reason was awareness. This is easy to fix. Show them the projects. Show the alternatives.  In some cases, you can show how the alternatives are interchangeable. Take for example Hibernate and an open source database. You could describe how a project using Hibernate backed by MySQL, two popular open source projects, can be migrated to Hibernate and Postgres in seconds, with no SQL changes, no new stored procedures and almost no risk.

    The point is, your managers are not surfing the internet researching open source projects and their alternatives. You probably are. You have to bring the projects to your managers and present them in a way to showcase the size of their communities, the available support, and the commitment of the project’s developers.

    To the Open Source Project Leaders

    For you project leaders of open source projects, this survey screams to us too.  If we review what these managers are telling us, and we can alleviate their concerns, then we can get into the corporate domain. Again, if we look at the top two reasons we see that corporate managers are telling us what they want and what they need.

    Support

    First is support. If you can provide support, then you can nix their number one concern. Support can come in many ways. The support that they were referring to in the survey was probably paid support. This is harder for smaller open source projects to setup but that doesn’t mean you can’t offer many lower levels of support. Mailing lists, IRC channels, forums, and issue lists are also valid types of support. If you don’t offer the paid support but do offer the other types of support, you are really leaving it on the corporate developer to sell those forms to their managers are good support.

    Try to stay active in your forums and mailing lists, don’t leave any questions unanswered, acknowledge every issue that is submitted, and hopefully this will show to the managers that while they can not pay for premium support, the project is indeed supported by the development team.

    Awareness

    And again, the number two reason that some organizations have not adopted your product is because the big wigs don’t even know that you exist. You have to promote your project and you have to stay committed to promoting your project. Most of us get into open source projects to write code, but project promotion is as important as the code and is often an overlooked or under appreciated aspect of the project.

    There are many ways to promote your project. Pushing Pixel’s Kirill Grouchnikov point out a few ways in Party of One: Promote. You can promote your project by simply spending some time writing documentation, or write up some tutorials or design decision explanations in a simple blog post. For our project, Architecture Rules, we recently posted Architecture Rules 101 and Architecture Rules 102 which provided simple tutorials of easy configurations. These two tutorials have landed us dozens of new users.  We also use a blog platform to document our project and provide code examples. These are simple things that we have done to promote our project and to increase awareness.

    Conclusion

    So weather you’re a software developer looking to introduce open source tools to your environment, or a project leader wanting to find more users, look to product support and project promotion.  These two project areas will alleviate up to 80% of a software manager’s concerns and increase both the end user developer and the project leader’s chances of the open source project finding its way into the corporate domain.

     

    • Esther Schindler 8:44 pm on June 21, 2008 Permalink

      Good analysis, Mike. I’d like to add a couple of points — since, of course, the original article (http://www.cio.com/article/375916) was written with the expectation that IT managers would read it, rather than developers (at least as the primary reader).

      It’s not just that the #1 barrier is support, as IT/business managers see it; it’s that nearly HALF of them say that’s a big deal (respondents could choose up to three items) and none of the rest got out of the 20something percent range. Sure the “hey I didn’t even know there WAS an open source option!” issue is #2, but security concerns are right behind that one.

      One thing that I find really interesting is that vendor pressure isn’t really an issue. When developers are asked what they think is holding FOSS back, in the Evans Data surveys, they have always practically shouted, “Microsoft!” But the bosses don’t really see that influence (or at least they don’t perceive it as such, which from the “convince her to let us use this” point of view comes to the same thing).

      So really, the way to go about it is to take on something very unnatural for most developers: marketing. I wrote about this in a CIO blog post at http://advice.cio.com/esther_schindler/foss_marketing (picking on Alfresco in a nice way, as they had briefed me about their views on enterprise open source adoption). Professional marketing people (by which I mean “the good ones”) learn to summarize benefits and show the features to back up their claims. In contrast, developers who get excited about a technology immediately want to dive deep into a single feature to see *just* how cool it is.

    • Mike 4:50 pm on June 23, 2008 Permalink

      @Esther Schindler – I updated the link to CIO at the entrance of the post to your editorial on CIO.

      I have enjoyed reading all of your editorials as a java developer who runs an open source project. I try to think about what you are saying as both a developer and a CIO (which I know almost nothing about. )

      Thanks for visiting, Esther.

    • RaiulBaztepo 7:49 pm on March 30, 2009 Permalink

      Hello!
      Very Interesting post! Thank you for such interesting resource!
      PS: Sorry for my bad english, I’v just started to learn this language ;)
      See you!
      Your, Raiul Baztepo

    • Mike 9:41 am on April 2, 2009 Permalink

      @RaiulBaztepo – You’re welcome ( : Thanks for reading and commenting.

  • Mike 8:48 pm on June 5, 2008 Permalink | Reply  

    Spring: Loading Multiple Contexts 


    I have already argued that many application contexts are better than a single application context. But how the heck do you load more than one context?

    There are a couple of ways to do this.

    web.xml

    Your first option is to load them all into your Web application context via the ContextConfigLocation element. You’re already going to have your primary applicationContext here, assuming you’re writing a web application. All you need to do is put some white space between the declaration of the next context.

    <context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml
        applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

    The above uses carriage returns. Alternatively, yo could just put in a space.

    <context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

    applicationContext.xml

    Your other option is to just add your primary applicationContext.xml to the web.xml and then use import statements in that primary context.

    In applicationContext.xml you might have…

    <!-- hibernate configuration and mappings -->
<import resource="applicationContext-hibernate.xml"/>

<!-- ldap -->
<import resource="applicationContext-ldap.xml"/>

<!-- aspects -->
<import resource="applicationContext-aspects.xml"/>

    Which Strategy?

    I always prefer to load up via web.xml This allows me to keep all contexts isolated from each other. With tests, we can load just the contexts that we need to run those tests. This makes development more modular too as components stay loosely coupled, so that in the future I can extract a package or vertical layer and move it to its own module.

    Any benefits to going with the application context import method?

     

    • Juliet 7:43 am on November 20, 2008 Permalink

      How to map dispatcher servlet, for multiple applicationContext?.
      Can you give me the solution.

    • Mike 8:20 am on November 20, 2008 Permalink

      @Juliet – Define the mappings in your applicationContext.xmls, then include those contexts in the web.xml as described in this post. Make sure that none of the beans have the same name or they will be overwritten as each context is loaded.

      If you have further questions about this I would recommend the spring forum over a comment in a blog.

  • Mike 7:52 am on June 5, 2008 Permalink | Reply  

    Architecture Rules 102 

    This is the second part in an introduction to Architecture Rules.

    The first part, Architecture Rules 101 went over a short, sweet, and simple configuration.

    Reminder

    So remember, the basics of Architecture Rules is that it is

    • Java.
    • Open Source.
    • Asserts architectural rules via unit tests.
    • You write your rules in XML.
    • Your run your tests with junit, ant, or a continuous integration server.

    Source Locations

    In this second installment of introductions to Architecture Rules, we’re going to go over source locations which enables the tool to support multi module projects, and allows you to define when a particular source must exist, or may be optional.

    By allowing a source to be optional, you can have different developers with different modules of code. So while one developer may have all eight modules of a project, another developer may only need to work on two or three of the modules.

    Configuration

    Here is an example that uses all of the current features supported by Architecture Rules 2.0.3.

    <configuration>

<sources no-packages="exception">
<source not-found="exception">core\target\classes</source>
<source not-found="ignore">web\target\classes</source>
<source not-found="ignore">ws\target\classes</source>
</sources>

</configuration>

    The first property that we see is the sources no-packages="exception". This tells Architecture Rule that, after reading all of the defined source directories, if no classes are found, then throw an Exception, more specifically, a NoPackagesFoundException. Here are the configuration options for no-packages:

    sources no-packages values
    Value Description
    exception causes a NoPackagesFoundException when zero classes are found among all of the defined sources
    ignore default all test continue although there are no classes to test

    The next interesting thing that we come across is <source not-found="ignore"> This configuration causes a SourceNotFoundException when the given path can not be found on the file system. This allows you to ensure that specific modules are present in the test. Alternatively, if you don’t particularly care if some source path is present, you can use the ignore value, which happens to be the default value. In the example above, the core module must be present for the tests to continue. The web and web services (ws) modules are optional.

    source not-found values
    Value Description
    exception causes a SourceNotFoundException when the path does not exist
    ignore default all test continue although the classes at the given path will not be included in the test

    So, after showing the simplistic configuration in Architecture Rules 101, we have now shown how you can customize your configuration to fit your needs with little work.

    In the next Architecture Rules lesson, we’ll demonstrate how to get the Configuration and show how easy it is to provide programmatic configuration instead of or in addition to the XML configuration. Also coming up right after that, we’ll finally introduce the Maven 2 Architecture Rules plugin that Mykola has been working on for the past couple of months.

     

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel