Technical Notes http://blog.anthonychaves.net My experience with Java, C, Ruby and more. Mon, 06 Oct 2008 17:45:34 +0000 http://wordpress.org/?v=2.6.3 en GridGain grid computing meeting on October 22 http://blog.anthonychaves.net/java/2008/10/06/gridgain-grid-computing-meeting-on-october-22 http://blog.anthonychaves.net/java/2008/10/06/gridgain-grid-computing-meeting-on-october-22#comments Mon, 06 Oct 2008 17:45:34 +0000 Anthony Chaves http://blog.anthonychaves.net/?p=55 If anyone is in the Boston/Waltham, MA area on October 22nd the Boston Scalability User Group is having a meeting with Nikita Ivanov from GridGain.  Free pizza and a free talk about Java-centric grid computing sounds like a good deal to me (disclaimer: I’m the meeting organizer).  Check out the meeting details at the BostonSUG web site.

]]> http://blog.anthonychaves.net/java/2008/10/06/gridgain-grid-computing-meeting-on-october-22/feed Rails and Restful Authentication http://blog.anthonychaves.net/ruby/2008/07/11/rails-and-restful-authentication http://blog.anthonychaves.net/ruby/2008/07/11/rails-and-restful-authentication#comments Fri, 11 Jul 2008 16:28:01 +0000 Anthony Chaves http://blog.anthonychaves.net/?p=54 It’s been quite a while since my last Ruby on Rails post so let’s go over a little “gotcha” that you might encounter when using the restful_authentication plugin.

Getting started with restful_authentication is fairly easy.  After installing the plugin it’s just a matter of running the following generate command:

script/generate authenticated user sessions

This will create a migration for a users table, a model and controller for users and a sessions controller.  It will also add some named routes to config/routes.rb.

So far so good, right?  Well, a common mistake when generating the model and controllers is to user the singular form of both user and session.  The command will run successfully and do exactly what you told it to do.  You won’t become aware of a problem until you try to log in for the first time and see this:

NameError in SessionsController#create

uninitialized constant SessionsController

RAILS_ROOT: C:/rails/bookmarks

Application Trace | Framework Trace | Full Trace









Request


Parameters:


{"commit"=>"Log in",
"authenticity_token"=>"0c0f07222da8ed58d8c6ebcafb9bf32f0bc84143",
"login"=>"anthony",
"password"=>"mysupersecretpassword"}


Uh oh! what went wrong?  It looks like Rails is looking for a controller called SessionsController.  But we generated one named SessionController.  Why is this happening?  Take a look in the views/session/new.html.erb file.


<% form_tag session_path do -%>


<p><label for="login">Login</label><br/>


<%= text_field_tag 'login' %></p>


<p><label for="password">Password</label><br/>


<%= password_field_tag 'password' %></p>


<!-- Uncomment this if you want this functionality


<p><label for="remember_me">Remember me:</label>


<%= check_box_tag 'remember_me' %></p>


-->


<p><%= submit_tag 'Log in' %></p>


<% end -%>


The form_tag target is session_path.  session_path is created for us by magic because of its mapping in routes.rb.


map.resource :session


When mapping a resource like this Rails looks for the controller with the pluralized name of the resource name by default, which means session_path is getting SessionsController.  We can change the behavior by explicitly setting the controller for the resource.


map.resource :session, :controller => :session


Try to log in again and you will be authenticated!  Of course it may just be easier to remember to use the pluralized name of whatever controller you want to use for managing sessions.

]]>
			http://blog.anthonychaves.net/ruby/2008/07/11/rails-and-restful-authentication/feed
		
		
		Terracotta Tech Talk
		http://blog.anthonychaves.net/java/2008/05/20/53
		http://blog.anthonychaves.net/java/2008/05/20/53#comments
		Tue, 20 May 2008 17:21:01 +0000
		Anthony Chaves
		
		

		

		

		

		

		http://blog.anthonychaves.net/java/2008/05/20/53
		
			I’m developing a Java/Spring web application deployed on JBoss 4.2.2 that makes heavy use of memcached in order to reduce the latency experienced by the user.  The user interacts with data that is (unbeknownst to them) in the cache.  In order to make changes permanent a message is placed on a queue that is picked up by an MDB.  The message is just the key used to access the data in the cache.  The MDB takes the data out of the cache and then saves it to the database.  This greatly improves the user experience because they do not have to wait for the next page to load while costly database writes occur.  So far, so good.


In this case I am unfortunately duplicating data by separating the reads from the writes.  The data lives in the Hibernate session used by the read-only app server in order to load the data in the first place.  It also has to be loaded in the write-only app server in order for that Hibernate session to work with it, which brings me to the point of this post: Is there any way that I can use Terracotta to pool my Hibernate-managed objects into one pool used by both the read-only and write-only app servers?  I think I would like to pool my Hibernate second-level cache.  It seems like Terracotta can get the job done.


That said, I’m anxious to explore this topic more when Orion Letizi from Terracotta Tech comes to speak at the Boston Scalability User Group next Wednesday on May 28th.  The meeting starts at 6 p.m. at the IBM Innovation Center in Waltham, MA.  Of course there will be pizza and soda (sponsored by Terracotta - thank you!) so come to the meeting to have some food and explore what Terracotta can do for your project.  All the details, including directions, are on the Boston Scalability User Group web site.  Remember, there will be pizza!

]]>
			http://blog.anthonychaves.net/java/2008/05/20/53/feed
		
		
		The Evil Query
		http://blog.anthonychaves.net/java/2008/03/18/the-evil-query
		http://blog.anthonychaves.net/java/2008/03/18/the-evil-query#comments
		Tue, 18 Mar 2008 16:21:47 +0000
		Anthony Chaves
		
		

		

		

		

		

		

		

		

		http://blog.anthonychaves.net/java/2008/03/18/the-evil-query
		
			Here is the use case: I want to search all of my bookmarks by multiple tags with an “and” operation.  That means I want to see bookmarks that are tagged with Java AND JavaEE, not just Java and not just JavaEE.  I want to see bookmarks tagged with C# AND 3.5 not just C# and not just 3.5.  For most of the project I’m using Hibernate and the Criteria API with a lot of success.  In this case I was not able to massage Hibernate into creating the correct query and that’s fine.  Hibernate has its uses and it is acceptable to write custom SQL when the need arises.  I wrote a method to build up the query and execute it.  Here is part of the method that builds up the query:





StringBuilder sqlString =

      new StringBuilder(

                                         “select distinct(b.id)

          from bookmarks b “);

    int counter = 0;

    for(Tag tag : tags) {

         String alias = “j” + Integer.toString(counter);

         String joinFragment = ” inner join bookmarks_to_tags {alias}

          on b.id = {alias}.bookmark_id

          and {alias}.tag_id = ? “;

            joinFragment = joinFragment.replace(“{alias}”, alias);

         sqlString.append(joinFragment);

         counter++;

    }		





Right away it looks like this query will get very expensive for large tag sets.  For smaller sets the query performs in a reasonable amount of time but more than 12 tags makes the query take quite a while.  This is exacerbated by the fact that this query will be executed multiple times if there is a sufficiently large result set (default is over 25) to give the user a paginated view.  This totally flies in the face of being nice to the database.  Hammering it with a complex query over and over won’t do the users any favors.


What are my options here?  I can work on making this query less complex (something that I will certainly do), but there is still the problem that, no matter how nice this query becomes, the query will be executed over and over as a user pages through the results.  The complexity of the query and its repeated execution makes the result set a good candidate for caching.  Caching the result set in memory with a key tied to the user or their session will allow the expensive query to be executed once with the bookmarks stored in a cache.  When the user pages through the results the cache will be consulted first where the result set will be stored.  I’m in the process of selecting a caching package for this project so I will post my selection and integration process soon.


Until then, I’d be happy to hear any suggestions on making this query a little nicer while preserving its “andness”.

]]>
			http://blog.anthonychaves.net/java/2008/03/18/the-evil-query/feed
		
		
		Spring Web MVC and the benefits of pagination
		http://blog.anthonychaves.net/java/2008/03/14/spring-web-mvc-and-the-benefits-of-pagination
		http://blog.anthonychaves.net/java/2008/03/14/spring-web-mvc-and-the-benefits-of-pagination#comments
		Fri, 14 Mar 2008 08:05:06 +0000
		Anthony Chaves
		
		

		

		

		

		

		

		

		

		

		

		http://blog.anthonychaves.net/java/2008/03/14/spring-web-mvc-and-the-benefits-of-pagination
		
			Lately I’ve been working on a project that keeps my web bookmarks sync’d across multiple computers and different web browsers.  The project is implemented in Java using JBoss 4.2.2, MySQL 5.0 and Spring 2.0.  It’s not a very big project right now, only about 40 class files and some small number of configuration files, but the amount of data the application deals with can get fairly large.



Since this app isn’t the only way to manage ones bookmarks that everyone has used since the dawn of the web, a feature to import bookmarks from browsers was very high on the to-do list.  So across the set of different browsers I’ve used on the different computers, and the backed up bookmarks that survived system formats I have around 700 bookmarks in total.  That probably isn’t a whole lot, but that many spread across thousands of users can add up quickly.


I used jhat to find out that each bookmark object uses 1.5 kilobytes of memory.  It doesn’t take much to see that a LOT of bookmarks will fit into 8 gigs of memory on a medium sized server.  It would take hundreds of thousands of users to generate enough bookmark data to fill that memory.  At this point it’s clear the application server box can handle the data load (that isn’t to say that it can handle the network load, however).


I spent some time coming up with a nice data model and ORM design so accessing the data once it’s in memory is lightning fast, maybe even faster.  But what about when it’s on a hard disk, deep in the database?  Dragging my 700 bookmarks out of the database when I only want to view the 25 most frequently visited is a bit overkill, especially when you consider dragging everyone else’s bookmarks out at the same time.  Even though this is still a small-time application I decided to be nice to the database anyway and implement some kind of paging solution.  Spring Web MVC doesn’t offer much that I’m aware of in regard to pagination help so it looks like I’m on my own.


Pagination is something that must take place in the model with the help of the view.  Right away we’ve got two things to deal with, though it’s best to deal with them in isolation.  The first thing I did was get the model right.  I’m using Hibernate for ORM and the Criteria API makes it easy to set offsets and limits.  That is, I can ask for the 50 next items (limit) starting at row 20 (offset).


The Criteria API is great at getting your data into a workable format without HQL or SQL (not that either of them is a bad thing.  I enjoy working with them).  Let’s take a look at the method that gets some new bookmarks.









  public List<Bookmark> getNewestBookmarks(int offset, int numBookmarks) {

    DetachedCriteria c = DetachedCriteria.forClass(Bookmark.class);

    c.addOrder(Order.desc(“createdDate”));

    return getHibernateTemplate().findByCriteria(c, offset, numBookmarks);

  }		





So this method gets the model for us, but where do the offset and limit come from?  From the controller, of course.  This method is called from the controller like so:









  public ModelAndView newest(HttpServletRequest request, HttpServletResponse response) {

    int numberOfBookmarks = requestUtils.getSafeValueFromRequest(request, “numberOfBookmarks”, 250, defaultNumberOfNewest);

    int offset = requestUtils.getSafeValueFromRequest(request, “offset”, 300, 0);

    

    List bookmarks = bookmarkService.getNewestBookmarks(offset, numberOfBookmarks);

    

    Map model = requestUtils.generateBookmarkModel(offset, numberOfBookmarks, 300, bookmarks);

    model.put(“bookmarkListName”, “Newest Bookmarks”);

    return new ModelAndView(“index”, model);

  }		





After sanity checking the offset and limit received from the request they are passed on to the getNewestBookmarks method to create and execute a somewhat unsightly query.  At this point, rather than gathering up all 700 of my bookmarks only 25 or so are returned.  What if I one day want to view the top 50 most visited bookmarks though?  Or what if I want to scroll through them one page at a time?  Passing in 0, 25 for the offset and limit of every method call won’t cut it.  The view needs to tell us how many bookmarks to retrieve and where to start the search.


Let’s say I’m viewing the top 25 bookmarks in my collection and I want to view 26-50.  Somehow the view has to tell the controller to tell the model about the  desired offset and limit.   This can be done by passing them in as request parameters.  In the code sample above, the HttpServletRequest object passed in to the controller contains values for offset and limit (numberOfBookmark) variables.  The JSP code below shows how to pass these parameters when a user clicks a link. (Actually I’m having a hard time getting the JSP to show up right when the code is rendered as HTML.  Just click the link and view the entire file instead.)


JSP Pagination Operations


This page uses the JSTL core tag library to build the links that display the “previous/next/more/less” options.  Right after the body tag there is code to create four URLs, one for each action.  Each one starts off with a name and a value.  c:url var=”viewMoreUrl” value=”" creates a page-scoped variable called viewMoreUrl.  This variable will later be used to display the link that allows me to display five more bookmarks when I view the list.  The value is left blank which tells the tag to use the current base URL in creating the new one.  If I’m on a page that is located at /bookmarks/pages/viewUserBookmarks.html the new URL will start off as /bookmarks/pages/viewUserBookmarks.html.


Adding parameters to a URL is easy.  Using the c:param tag we get c:param name=”numberOfBookmarks” value=”${numberOfBookmarks + 5}”.  This tag appends a variable called numberOfBookmarks to the base URL described in the previous paragraph.  The value is a JSP expression that uses the numberOfBookmarks value passed in the model and increases it by five to pass back in the request.  Because we want the link only to display five more bookmarks and not change the offset that value will remain the value passed out in the model.  That gives us a URL that looks like /bookmarks/pages/viewUserBookmarks.html?numberOfBookmarks=30&offset=0.


When this URL is accessed the request values for offset and numberOfBookmarks are exposed in the HttpServletRequest object for use by the controller.  When the getNewestBookmarks method is called the offset and limit are 0 and 30 instead of 0 and 25.


Obtaining a new offset value is done like getting a new limit value.  We start off with the same base URL and leave the numberOfBookmarks value unchanged.  We need to change the offset value though. c:param name=”offset” value=”${offset + numberOfBookmarks}” creates the offset value of the URL.  If we are viewing the newest bookmarks (offset 0)  and we are viewing 30 bookmarks when we click the link we should see bookmarks 31-60.


Here is an interesting thing to consider: what if a user goes to the second page using the default values.  The user will be viewing bookmarks 26-50.  The user then clicks the “view more” link three times and is now viewing 40 bookmarks.  The “previous” will now request that the offset be -15.  Unfortunately we can’t have negative bookmarks.  In this case the controller has some sanity checking built in to it.  The input parameter values must always be validated before they are used.  The controller uses a utility method to get a safe value for the offset and limit and ensures that neither can be a negative value.  This safe value is then passed back to the view once the model has been built.  Even though the offset in the request says -15 the controller will only go as low as 0.  More interesting work takes place in the generateBookmarksModel method, which I will talk about more next week.


What did I learn from making this effort?  Well, giving 8GB of RAM to an application server is a little overkill for a domain model like this.  The pagination that I came up with is still rudimentary, but a little more work could add more features, namely displaying page number links and the ability to change the number of bookmarks added at a time.


What is gained from this effort?  Being nice to the database opens up a few doors.  It dramatically improves scalability because it allows these requests to be stateless.  If an app server queried the database for all of my bookmarks then my session would have to be directed to that app server every time I made a request in order to not incur the cost of hitting the database again by another app server.  If round-robin load balancing is used the Hibernate session on each app server would contain a copy of my data and that’s a waste of resources, most notably it’s a hit to the database that didn’t have to happen.


Reducing the load on the database by getting only what we need and stateless sessions gives me the option of scaling the database with less difficulty.  A mostly-read application can get by with fewer hits to the write master and do a majority of their work from read-only slaves.   Spreading complex queries over multiple read slaves is much preferable to every app server hitting one database for every query.  By having stateless requests I can have more app servers (using less memory) hitting more database servers without maxing out the CPU utilization due to the cost of complex queries.


What should I do with the unused memory in the app server boxes?  Rather than give it to one app server instance for use as a cache it should be given to the pool of application servers for use as a cache.  One way to do that is with memcached.  I’ll talk about that more in the future too.


As always please leave comments.  I enjoy getting feedback on what I’ve written.

]]>
			http://blog.anthonychaves.net/java/2008/03/14/spring-web-mvc-and-the-benefits-of-pagination/feed
		
		
		Spring Web MVC lists
		http://blog.anthonychaves.net/java/2008/02/13/spring-web-mvc-lists
		http://blog.anthonychaves.net/java/2008/02/13/spring-web-mvc-lists#comments
		Wed, 13 Feb 2008 17:42:49 +0000
		Anthony Chaves
		
		

		

		

		

		

		

		

		

		http://blog.anthonychaves.net/java/2008/02/13/spring-web-mvc-lists
		
			I recently came across a blog post describing how *not* to use the Spring Web MVC form tag library.  Spring Web MVC is one of those things that has a high learning curve but it pays off big once you get the hang of it.  The form tag library is no exception.  The original blog poster seems to want to display a list of things the form user can manipulate and then send the changes back to the app server.  There are a few different ways we can do this with Spring Web MVC and some JSTL libraries so let’s take a look at the way I prefer to do it.


Spring Web MVC utilizes the ModelAndView class to encapsulate the M and V of MVC.  The model part is simply a map of objects associated with a request.  The key is the string name that you will use to access the object via the tag libraries.  Placing an object with a key of “userPrefs” into the map will make the UserPrefs object available to the HttpServletRequest and eventually part of the implicit request object that is part of JSPs.  In order to display any user data in a JSP it has to be part of the request object and it gets there by placing it in the Map used by ModelAndView.


In my experience with Spring Web MVC I’ve found that most form controller classes extend SimpleFormController.  SimpleFormController derives most of its lifecycle from AbstractFormController, which provides us with a few interesting methods.  There is one method in particular that is interesting.  The referenceData(HttpServletRequest request) method returns a Map and this method is called during the showForm(…) method.  showForm returns a ModelAndView object which will include whatever data is included in the Map returned by referenceData.  The default implementation of referenceData returns null, so we have to override it in our class that extends SimpleFormController.


Here is some example code from my controller class which extends SimpleFormController.  The point here is to provide a list of Bookmark objects to the form for a user to delete.




  @Override

  protected Map referenceData(HttpServletRequest request) throws Exception {

               List userBookmarkList =       bookmarkService.getUserBookmarks(

      request.getUserPrincipal().toString());

      

   Map model = new HashMap();

                model.put(“userBookmarks”, userBookmarkList);

                return model;

  }


This is pretty simple example.  It’s first getting the user from the request object.  This is an authenticated session where a user has provided a login name and password.  That name is retrieved from the request object and used to get a List of all of their bookmarks.  The List is then put into a HashMap with the key “userBookmarks”.


After referenceData returns the Map those entries are then passed on to the view by the showForm method.  We can use a couple JSTL tag libraries to iterate over the list and display each bookmark while building the form.  The following is an excerpt from the view (NOTE – This is pre-Spring 2.5):





 <%@ taglib prefix=“form” uri=“http://www.springframework.org/tags/form” %>

<%@ taglib prefix=“c” uri=“http://java.sun.com/jsp/jstl/core” %>

…

<form:form>

           <c:forEach items=“${userBookmarks}” var=“bookmark”>

                   <form:checkbox path=“bookmarkIds” value=“${bookmark.id}”/><c:out value=“${bookmark.id}”/> — <c:out value=“${bookmark.title}” escapeXml=“true”/><br/>

        </c:forEach>

        <input type=“submit” value=“Delete checked bookmarks”/>

</form:form>		





This view uses two tag libraries, one from JSTL, the other being the Spring form tag library.  Within the form tags the JSTL forEach tag is used to iterate over the list of bookmarks.  The list is obtained via the ${userBookmarks} variable.  This calling convention takes advantage of the search order for finding request parameters used by JSTL.  Part of the search includes looking in the request object that is part of every JSP.  The items attribute is the object we want to iterate over, that being the object keyed by userBookmarks.


That object is the List of bookmarks we got from the business tier.  By iterating over the bookmarks we have access to each Bookmark object and each of it’s fields.  The checkbox tag is used to build up the HTML view of the each bookmark with a check box next to it for the user to click.  When the user is done selecting bookmarks to delete the onSubmit method is called back in the controller.


So how does Spring know which bookmarks have been checked in the form?  The form object bound to the form keeps track of the checked bookmarks.  This form object is very simple, it encapsulates an array of Strings and provides a getter and setter for the array.




package net.anthonychaves.bookmarks.dataobject;


public class DeleteBookmarksForm {

 

        private String[] bookmarkIds;


              public void setBookmarkIds(String[] bookmarkIds) {

                            this.bookmarkIds = bookmarkIds;

              }


             public String[] getBookmarkIds() {

                            return bookmarkIds;

              }

}


The “value” part of our checkbox contains the bookmark ID.  When the checkbox is checked and the form is submitted the Spring dispatcher servlet collects all of the checked values of the same path into an array and puts them into the DeleteBookmarksForm object.  The form object is then passed to the DeleteBookmarksController via the onSubmit method.  We don’t have to implement the entire onSubmit method, though.  The default implementation calls doSubmitAction which takes only our command object, in this case DeleteBookmarksForm, as an argument.  Once we have a list of bookmark IDs to delete we can call the business tier to remove them from the database (after appropriate error checking, of course).


Spring 2.5 introduces the form:checkboxes tag which eliminates the need to use the JSTL forEach tag to iterate over the list of objects.  The checkboxes tag takes care of that for you.


There is more to working with lists in Spring Web MVC than the material presented here.  I’ve included a few references below in case you’re interested in finding out more.  Thanks for reading and as usual let me know if you have any questions or comments!

]]>
			http://blog.anthonychaves.net/java/2008/02/13/spring-web-mvc-lists/feed
		
		
		Response to Web Application: To Couple or Not to Couple?
		http://blog.anthonychaves.net/java/2008/02/08/response-to-web-application-to-couple-or-not-to-couple
		http://blog.anthonychaves.net/java/2008/02/08/response-to-web-application-to-couple-or-not-to-couple#comments
		Fri, 08 Feb 2008 20:33:24 +0000
		Anthony Chaves
		
		

		

		

		

		

		

		http://blog.anthonychaves.net/personal/2008/02/08/response-to-web-application-to-couple-or-not-to-couple
		
			I just read this thread on The Server Side and it makes me nervous that people still ask this kind of question.  The thread starts off by asking “An usually annoying question when designing an action-based web application is: “Should I place everything in my action or should I separate the web logic from the business logic?” and the alarm bells in my head are going off already.


Business logic always belongs in its own layer.  Why?  Business logic is the thing that makes your application what it is.  It doesn’t matter how it’s dressed up - web app, desktop app, web service - the business logic accomplishes the task the user wants to perform.  Business logic is your application.  Because of its importance business logic should be placed in a sacred place where it will not be disturbed by presentation logic or infrastructure underpinnings - the business tier.  Separating the business concerns from all other concerns buys a lot of benefits for the development team.


What if aggregate data must be displayed in multiple locations?  For example, shopping cart data could be displayed on a checkout screen and also as a side bar while the user is still shopping.  In an action-based framework this code would be duplicated in two different actions.  It would be present in the action that generated checkout screen and again in the action that assembled the shopping view screen.  Rather than duplicate the code why not make a method call into the business layer that did the same thing?  The end result is the same except it separates the concerns of web and business logic.


Refactoring this code into a business tier method helps make our application more loosely coupled.  Loose coupling is important for business logic because it allows for easier reuse, testability and maintanence.  If the business logic is located in the action then creating a web service around it is going to be more difficult.  The business logic will have to be decouple from the web action and pulled into a layer where both the web action and web service can use it.  A good example of this would be a web page that displays new items available to a customer.  A web page is ok but the customer would have to keep checking back for updates.  An easier way to publish this information would be to make it available as an RSS feed the customer can subscribe to.  Duplicating the logic to get the new items isn’t particularly difficult, but why make maintenance more difficult than it has to be?  The application should be refactored to have a business layer that is responsible for getting the data which can be called by two different locations in the presentation layer (the web tier and the RSS feed creator).  Testing the business logic (you’re testing, right?) and bug fixing only have to be done in one location thanks to this refactoring too.


Another quote from the thread is, “The other side of the story is that to have two separate classes, one dealing with the http/web layer (ex: UserAction) and one dealing with the business logic layer (ex: UserService) is bureaucratic.”  This statement shows a lack of understanding of functional decomposition.  Each module should be responsible for one and only one thing.  If the web layer is for dealing with actions then actions should only be dealt with in the web layer.  If the web layer is for dealing with actions then business logic should not be dealt with at the web layer.  Business logic belongs where it can remain undisturbed by other concerns.  Tight coupling of these concerns makes testing more difficult because it requires testing everything it once rather than testing in isolation.  Because your application is only as good as the business logic the business layer should have a test suite that can be run without depending on action or presentation logic.


There are plenty of other reasons you should keep business and web logic separate.  This is in no way an exhaustive list, but it’s certainly something to think about.  If you’re building any professional application then business logic should always be in its own layer.  Not only will your boss/team/successor thank you for it, it’s good software development and you’ll thank yourself for it too.

]]>
			http://blog.anthonychaves.net/java/2008/02/08/response-to-web-application-to-couple-or-not-to-couple/feed
		
		
		Boston Scalability User Group
		http://blog.anthonychaves.net/java/2008/02/04/boston-scalability-user-group
		http://blog.anthonychaves.net/java/2008/02/04/boston-scalability-user-group#comments
		Mon, 04 Feb 2008 20:59:16 +0000
		Anthony Chaves
		
		

		

		

		

		

		

		

		

		http://blog.anthonychaves.net/java/2008/02/04/boston-scalability-user-group
		
			I’ve been digging around lately for a Boston area user group dedicated to architectural scalability and I haven’t been able to find one.  Other user groups that I regularly attend have meetings centered around scalability once in a while, but I’m looking for something with a schedule dedicated to the topic.  It’s a hot topic in the industry right now with a lot happening on different fronts and there should be some ongoing professional discussion dedicated what goes into growing an application.


Here are some of the topics I want to talk about:


    

  • Data growth and access - What kind of DBMS topologies allow maximum scalability without breaking the budget?  What if the budget wasn’t a problem?  How do you migrate your data model from hundreds of users to millions of users?  Should you partition user data across shards or keep it in a central database?  How do you profile data access paterns?  Is your application mostly-read or mostly-write?  When should you use an LDAP directory for data storage?  When should you use MySQL and when should you use Oracle?
    • 

  • Application server scaling - app server clustering, web server integration, load balancing, application session management, data caching
    • 

  • Web Tier - load balancing reverse proxies, data caching, working with HTTP, considerations for exposing functionality via REST
    • 

  • Language conisderations and platform choices - Dynamic languages vs. Static languages, Linux vs. Windows, Solaris vs. Linux, RedHat vs. Oracle, IBM vs. Oracle - How do you make these choices?  What evaluation critera are most important?  Which ones are misleading?
    • 

  • Framework scalability - How can you scale if your framework can’t?  Does Rails really scale better than Spring Web MVC?  Where do PHP frameworks fit in?  What are the alternatives?  This is where we will investigate what you gain and lose by binding yourself to a particular framework, how to keep the coupling to a minimum and how to use your framework as a solid foundation instead viewing it as a cage.
    • 

  • Emerging technology - Should you become familiar with Map Reduce and Hadoop?  What kind of impact do object databases have on your application?  Should you buy your own Sun or Dell boxes or use Amazon’s EC2 and S3?
    • 

  • Application architecture - How do you write an application that scales?  What does your application look like as it grows from servicing hundreds to millions of users?  How does it handle session management?  How does it access datastores?  Are there any design patterns that are helpful?  What are the anti-patterns to be aware of?
    • 



Like I said, I haven’t found a group dedicated to discussing these topics.  If you know of one in the Boston area please let me know.  Assuming there isn’t one I am willing to start one.  I’d like to start off small and meet at coffee shops around Burlington or Lowell.  I have no delusions that this is going to start off or even become as big as NEJUG is now.  If it starts off as a few people getting together to talk about scalability trends, cool caching solutions and specific products then I’d call it a good start.


The meeting location is still TBD and will be based on how many people are interested in attending.  It will probably be somewhere in Burlington, MA.  There is no planned presentation at this time.  Instead we will have a meet and greet and then discuss scalability trends and news, what approaches to scalability are commonly used now and what are the plans for the future.


If you are interested in coming or in finding out more information please email me at <my first name>@<my domain name>.<my tld> or leave a comment below.  Please make sure to include your email address when you fill out the form so that I can get in touch with you - your email address will not be displayed on my site.

]]>
			http://blog.anthonychaves.net/java/2008/02/04/boston-scalability-user-group/feed
		
		
		Too Many Bugs - Conclusion
		http://blog.anthonychaves.net/work/2008/01/30/too-many-bugs-conclusion
		http://blog.anthonychaves.net/work/2008/01/30/too-many-bugs-conclusion#comments
		Wed, 30 Jan 2008 17:20:55 +0000
		Anthony Chaves
		
		

		

		http://blog.anthonychaves.net/work/2008/01/30/too-many-bugs-conclusion
		
			This is the final part (for now) of the thoughts I’ve collected on improving the relationship between software developer and QE to find high-risk bugs sooner.  You might want to check out parts one, two, three and four before continuing here.


To some people it might seem that a lot of what I’ve written about here is common sense.  The condensed version of this text might be “go talk to QE”.  But surprisingly there are exceedingly few people that actually do it.  QE, or any other group for that matter, is a mysterious team with bad intentions that lives on the other side of the fence we through our software over.  Working with QE over Bugzilla and email is like a 2400 bps modem.  You just don’t get what you need over it.  Software developers are typically even more prone to this reclusive behavior due to the kind of people attracted to the field.  I struggled with the same social problems for years, usually with less than satisfactory results.  Eventually I found a way to work with others that works well for everyone.  I had to struggle against my strongly introspective personality and force myself to communicate verbally, in person, with people around me and affected by my work.  Why?  Because it didn’t seem like anyone else was doing it and there had to be a better way to deliver high quality software that people wanted to use.


By paying attention to these things the quality of my technical work improved and my visibility to people both on and outside of my teams skyrocketed.  I’ve made an effort to improve how I work with others and in doing so I’ve made a name for myself.  Possessing superior technical skill is of little use if no one recognizes it.  Think about that for a minute.  You can be the greatest programmer of your generation and you’re not going anywhere if you can’t convince others you’re worthwhile.


Oh yeah, what effect does this have on the bug triage meeting?  If you’ve read this far then you know you’re showing up loaded with ammo.  Every bug you talk about is going to be important because you’ve eliminated all the small ones along the way.  Imagine being in a room with your peers and a cross functional team where every word you say is inherently more valuable because you’ve done your homework.  You’ve put in the effort to make this meeting more valuable for everyone else that attends.  You’re not wasting their time by even looking at bug 34987 that only had a minor impact on documentation.  You’re in front of an audience that wants to discuss things that matter, business or technical.


No one wants to get up in the morning and think, “I want to sit in a bug triage session all afternoon today and again tomorrow”.  In this meeting you’re able to talk about every bug as it comes up.  You know the issue, you know the root cause and you know what kind of scope it takes to fix the problem.  That’s the kind of information that’s needed at bug triage sessions.  That information helps to determine the severity and priority.  It let’s people decide whether or not the bug needs to be fixed right now and that is exactly the point of bug triage meetings.  People will notice that you’ve done your homework and they will appreciate it.  It will get you noticed.  People will realize you have in-depth technical skill and you can work well with others which almost guarantees a position as a successful technical lead and it will open up a lot of other doors in your career.  What, you just wanted to make the bug triage meeting shorter?


Well, like software this paper isn’t perfect.  I’m certain there are missing topics, incorrect statements and gaping holes in logic and arguments.  There are entire books written on this subject and I don’t have any delusion that I’ve covered even one one-hundredth of 1% of the social issues that hold our industry back from consistently releasing high quality software, on time, on budget.  But, like I do for my software, I keep a list of known risks for this paper and I’ve decided that it’s finally time to ship it, bugs and all.  Congratulations on reading the entire thing and bigger congratulations for just skipping to the end if that’s how you got here.  If you’ve found this to be worthwhile please submit it to Digg, Slashdot, StumbleUpon, del.icio.us or whatever other social network you use.  Also please leave your comments and discuss what I’ve written.  Feel free to add topics you think would be interesting.






]]>
			http://blog.anthonychaves.net/work/2008/01/30/too-many-bugs-conclusion/feed
		
		
		Too Many Bugs - Part 4
		http://blog.anthonychaves.net/work/2008/01/29/too-many-bugs-part-4
		http://blog.anthonychaves.net/work/2008/01/29/too-many-bugs-part-4#comments
		Tue, 29 Jan 2008 16:54:49 +0000
		Anthony Chaves
		
		

		

		http://blog.anthonychaves.net/work/2008/01/29/too-many-bugs-part-4
		
			Today brings us to part four in the series of thoughts I’ve put together on reducing bug triage brutality by creating a more productive relationship with your QE team.  You might want to check out part one, part two and part three before reading on.


There’s the old saying “when you’re in a hole stop digging”.  So far we’ve talked about how to stop digging but we haven’t talked about how to get out of the hole yet.  A bug list is a bit like Pandora’s box in that once the bugs are open they’re like all the sorrows let out of the box.  You just can’t put the sorrows back in the box and you just can’t get rid of all the bugs.  What happens to you when you’ve got a bug list a mile long?  You try to avoid looking at it for one.  But there are always people in management that subscribe to the mange-by-numbers theory who take bug metrics a little too seriously.  Eventually you’re going to make it to the top of the naughty list when they’re looking at who has the most open bugs.  This can be interpreted in a few ways and none of them are good.  They could think you’re a terrible developer if you write so many bugs.  They could think you’re lazy if you’ve got such a huge backlog.  They could think you can’t prioritize well if they see something related to their pet topic is on your bug list and you’re working on something different.  They could think any number of different things and whatever they come up with definitely will not benefit you one bit.  You need to massage your bug list to stay off the slacker radar.


Start by picking off some bugs that are related somehow.  They can be related on feature, topology specificity, platform specificity.  Pick a few that you don’t understand well.  Pick a few that you think are configuration error, user error, documentation error.  Make up a list with these bugs and a summary of each one or print out each bug report.  I hope you can guess what’s coming next.  That’s right - go get your QE person or people and ask when they will have time to sit down with you to address your concerns.  What you’re doing right here is proving to QE that they are valuable and their work is not in vain.  You’re validating their presence in the organization by asking them to talk about their work.  They need someone to listen to what they’re saying and it’s your job as a developer to do it.  You’re making them feel good by making them feel important.  This is a great way to start off a meeting or meeting request.


Let them know what bugs you want to discuss before the meeting starts to give them time to prepare too.  This meeting is going to go very smoothly if everyone comes prepared.  Your goal here is to find out enough information to resolve all of the bugs on your list you prepared.  Every one of them must have some resolution before you leave this meeting.  This is not a bug triage meeting because you know going into it that all the bugs must be resolved.  This is a technical meeting that results in action items from all parties.


Start the meeting by saying “I understand you have some concerns about… <fill in the software module blank>.  I was wondering if you could give me some insight into what you’re looking for from me”.  Begin the discussion on each bug by asking them how they encountered it even if it’s already logged in the bug report.  Ask questions about their process.  A lot of extra information that wasn’t captured in Bugzilla will come out of this conversation.


Sometimes enough information will come out that you will all see that the bug is clearly due to incorrect expectations or incomplete documentation.  These are easy bugs to resolve.  Sometimes you’ll get that a bug is clearly a bug and through your conversation you will find out exactly what you need to do to fix it.  These are also pretty easy to deal with.  Another kind of bug that can end up here is one that turns out to be an enhancement request.  I’ll talk in-depth about how to deal with enhancement requests another time, but if they come up in the meeting it’s best to just move on to the next bug.  If you don’t you’ll end up at a mini-triage meeting trying to decide the priority, whether or not it’s an enhancement request and so on.


At the end of the meeting there should be a list of developer action items for you to take care of and a list of QE action items for them to take care of.  Have these meetings as often as you can in order to drive down your list of bugs.  Remember you’re trying to show up at the bug triage meeting with the shortest bug list possible and this will drive down your list very quickly.


I can derive another relevant example from the first iteration I wrote about in part two.  Remember that QE had opened a huge number of bugs in a very short time period on my deliverable.  I was overwhelmed by the incoming load and I couldn’t just mark all the bugs “won’t fix”.  If QE wasn’t riled up already that would be the thing to do it.  Most of the bugs came from two people in QE so I had to get them into a room with me, if not to talk to them then just to keep them away from their keyboards so they couldn’t open any more bugs for me.


I went in to the meeting with a print out of every bug I wanted to discuss.  Each one was related to the feature that I had just delivered.  I started the meeting by saying, “John, I understand you have some concerns about this feature.  It seems like there are some things that are preventing you from testing further into the feature and I would like to know what I can do to help you get further along”.  Notice how I didn’t say anything about “Please stop opening bugs or I’m going to quit my job” or “I hate you QE guys so much that I’ve written a thousand more bugs that you’ll never discover” or even something nicer like “There are an awful lot of bugs against this feature and I’m not sure some of them are valid”.  Everything I said was phrased in a way that conveys my want to help QE.  And I really did want to help them.  Helping them helps me.  There is no rule that says developers can’t help QE and if there is a rule that says that it’s wrong.  Dev./QE is a two way street.


After that we went through each bug.  We discovered that some of them were duplicates of each other.  That gave QE the action item to close each duplicate bug.  Some of the bugs were discovered to be due documentation that wasn’t explicit or detailed enough.  Those bugs came into my action item list to fix the documentation.  I asked the QE guys what documentation details would have helped them navigate through the steps safely so that I could use it in my resolution.


Some of the bugs were because the user tried to set up the software on an unsupported platform.  You can’t use SuSE 7 and Perl 4 when the supported platform is Red Hat ES 4 and Perl 5.  Those bugs become action items for QE; retest those bugs on supported platforms.


The most interesting bugs were real bugs caused by unexpected QE needs, but needs vital to their testing.  Getting a firm grasp of what is causing these bugs is important and hopefully you can gain enough information that you can propose a fix in a relatively short period of time.  Those bugs became action items for me to resolve.


In creating these action items it’s also important to provide a time table as to when QE can expect to see the resolution.  Talking about the bug is one thing, but the goal is to drive down the bug list and the only way to do that is to actually fix the bugs.  For my action items I told the QE guys that they could expect to see a fix in the next patch release they get from development and I made sure to deliver.  Setting joint expectations and then driving toward them is a recurring pattern here and your consistency in doing so is important to your success.


Come back again tomorrow for the conclusion!






]]>
			http://blog.anthonychaves.net/work/2008/01/29/too-many-bugs-part-4/feed