Author Archives: jeff

Myth of Sushi Grade Fish

by

What is sushi grade fish?

There are several common misconceptions regarding what is “sushi grade” fish floating around the internet.  Some are so common, they are repeated over and over, both in articles and by the zillion comments people leave behind.  I’ve decided to tackle a few of the most common misconceptions and state why it’s a myth and my own personal opinions.

Myth 1: “Sushi Grade”

The term “Sushi Grade Fish” is a marketing term seafood retailers tag onto their products so they can command a higher price.  It is not a registered term by any federal agency and should not be used blindly as a guarantee for safety or freshness.

I’ve personally seen big box stores sell vacuumed packed frozen whole fish labelled as “sushi grade” only to look at the fine print on the product to see a “Not recommended to be consumed raw” warning.

Conversely, there is another fish retailer close to my house that sells fresh whole fish that can certainly be served as sushi even though they are not explicitly labelled as “sushi grade” fish.  I usually ask the fish monger that I’m explicitly consuming it raw and he will point me to his recommendations.

I won’t go into detail on what a “fresh fish” is.  This in itself requires another blog article!  In the meantime, you can find very good instructional guides to tell if a fish is fresh on the internet.

That doesn’t mean you should totally ignore fish that have been labelled “sushi grade”.  At reputable retailers, this is used to describe fish that they believe is of i) High enough quality to eat raw and ii) handled in a way to minimize parasite and bacterial contamination.

Myth 2: “Previously Frozen”

Another common myth is that “Sushi Grade”  means it was previously frozen to kill parasites.

“Sushi grade” does not mean the fish was previously frozen.  Not all fish are required to be frozen before eaten raw.  For example, depending on the source, bluefin tuna can safely consumed without prior freezing.

The FDA maintains a guideline which describes the risks for parasites in common fish species used for sushi.  It also publishes best practices that restaurants and retailers should follow if they wish to serve raw fish.  This includes instructions on length of freezing and temperature.

Myth 3: “It’s the law”

Yet another myth is that the United States and Canada have federal laws concerning the freezing of sushi grade fish before selling to the public.

Both the US and Canada do not have federal level laws that state raw fish must be frozen before serving to the public.  As mentioned previously, the FDA publishes guidelines, but these are not enforced at the federal level.  It is up to individual municipalities and counties to optionally use the FDA guidelines when enacting their local laws.

This means you may eat previously frozen fish in New York City (which requires some species of fish to be frozen), but that fish may not have been previously frozen in another city.

Myth 4:  Always Eat Fresh, Never Frozen Fish

Unless you live by the ocean, most wild fish consumed will have been previously frozen at some time in its processing.  Many times, fish are flash frozen (frozen at very cold temperatures very quickly after initial processing) at sea, right on the boat.  They are then shipped in very cold temperatures to their destination where they are thawed (by the wholesaler or retailer/restaurant) and are either sold as is, cut into smaller chunks, or served to restaurant customers.

Sometimes, fish are labelled as “IQF”.  This means the fish was individually “quick” frozen at very cold tempters (around -35c).  This is way colder than home fridges can obtain and these cold temperatures helps lock in freshness.

Though many people believe fresh is best, flash frozen fish is often just as good as fresh fish.  One additional benefit about consuming flash frozen fish is that most parasites are killed off by the cold temperatures.  But this depends on the type of fish and the freezing mechanism.

Myth 5: A Clean Seafood Store

To minimize bacteria growth, fish needs to be handled properly all the way though the supply chain.  Not just at the seafood retailer.  The fish mongers I purchase sushi fish from all have pretty high standards in terms of their OWN handling of “sushi grade” fish.  Fish for raw consumption are usually not processed on the same line as “non-sushi grade” fish and if cut into fillets, are packaged in individually wrapped trys.  This is opposed to the fillets stacked on top of each other on an open bed of ice.

However, even with these fish retailers, they often receive pre-gutted whole fish from their suppliers.  This means the fish has already been processed and handled in some way and it is almost impossible for the consumer to know if the supplier handled “sushi grade” fish appropriately.  Some retailers check with their supplier on fish they intend to mark as “sushi grade” but others do not.

It really comes down to asking questions and trusting the fish monger.

Myth 6: Sustainable Fish

Some websites and stores say that part of “sushi grade” means that it comes from a sustainable source.  They also say that non-sustainable fish such as bluefin tuna are high in mercury and should not be eaten.

The term sushi grade does NOT have anything to do with the sustainability of the fish species.  Though it is true that bluefin tuna have higher concentration of mercury and should be eaten in limited quantities, the term “sushi grade” does not pertain to this.

Myth 7: Trusting the Store

Some fish mongers take great pride in the quality they provide to their customers.  They know their product well and sell fresh seafood.  However, this is usually applies only to the store owner and experienced staff.  At big box stores and even local high quality seafood retailers, I’ve dealt with staff that have little or no seafood experience.  So you do need some common sense when you talk to the person behind the counter.  Make sure they know what they are talking about.

Myth 8: Japanese store

Some youtubers and blog posts recommend always going to a Japanese fish store. This is hogwash.  I’m Japanese Canadian and have a couple very good Japanese seafood retailers that I frequent, however, I still sometimes purchase fish I’m going to make sushi from non-Japan (non-asian) seafood stores.

Myth 9: Fresh = Good Taste

Freshness does not guarantee a tasty fish.

High end Japanese restaurants look for more than just freshness when looking for fish to serve raw.  Some fish species, like bluefin tuna, have a high level of flavor and texture variation even among fresh fish.  It is up to the skills of the chef to determine which fish will produce good sushi/sashimi.  Remember sushi and sashimi is more than just eating fresh raw fish.  It also involves the preparation and processing of the fish (among other ingredients) to create a high quality meal.

Myth 10: Only Eat Sushi at a Restaurant.

There are some fear mongering websites that state that you should only eat sushi at a restaurant.  They often tout that:

  • Regular people do not have the skills to find fresh fish
  • Are not trained to detect parasites
  • Do not have the still to make sushi and sashimi.

This is just ridiculous.  We’ve all seen sketchy sushi restaurants on the side of the road.  Just because it is served at a restaurant does not mean it is high quality.  Though it is true that consuming raw fish has its risks, if you follow the best practices, you will be limiting your risk to a negligible amount.

And finally, though I have heard of some sushi chefs saying “always eat sushi at a restaurant” , most chefs encourage having fun and preparing sushi at home.  Sure it might not look as nice or taste as good, but if you have fresh fish, keep it cool and have fun, that is what life is all about.

Beware that some YouTube channels that show you how make “sushi at home” are actually operated by (or have partnerships) with  online fish stores selling highly marked up “mail order sushi grade fish”.  They often over stress the need to buy fish only labeled as “sushi grade” (which we have just proved false by the arguments above) and try and scare viewers to purchase their product.

Myth 11: Higher Price is Better

Higher price does not always equate to better quality “sushi grade fish”.  Where I live, there are some Japanese fish stores that sell really high quality fresh fish, but their prices are quite expensive.  After much researching, I found a couple other non-asian fish mongers that not only sell fish of the same quality, but also have more variety!

Final Comments

Be wary of blindly trusting what people say in the comments section about “sushi grade”.  You don’t know who they are and where they got that information.  Don’t be fooled into only buying fish labelled as “sushi grade”.  Not only dose this lead to a sense of false safety, you end up overpaying in the long run.

Don’t compensate by buying non-fresh fish because you really desire to eat that kind of fish for dinner. This is how you get sick.  All your senses are telling you this fish no good for sushi, but if you really want it you are more likely to make a bad decision.  Instead, at the store, ask what is fresh, then of these choices, decide what to purchase.  Go to the store without a decision on fish type.

The key to purchasing “sushi grade” fish is to know your fish monger.  He/She should know where the fish came from and how it was processed before receiving it.   Go to a store that takes pride in selling quality fish products.

  • If buying a whole fish, trust your senses.
  • If the “sushi grade” fish is sold in smaller blocks (without the skin) wrapped in plastic wrap, ask questions. Find out how fresh it truly is.

But in the end, you senses are not enough.  Retailers do everything possible to make fish look fresh, so you need to trust your seafood retailer.  You have to know that fish they are selling has been processed in the best way possible to reduce bacteria and kill off parasites.  If you don’t trust where your food is coming from, I suggest going elsewhere.

Spring-Session with a relational database(Part 2)

by

Preface:

I recently had to work on a project where we had to turn an existing Java (Springboot) application whom was served by multiple web servers sitting behind a load balancer and required sticky sessions to an application that could be deployed to an environment using non-sticky sessions.

I wrote a blog article about how we setup our proof of concept using Spring-Session with our application here.  We initially wrote our tutorial using Redis as our session store, but it was decided to use a relational DB instead(Oracle).  Documentation was pretty sparse about how to exactly configure Spring-Session to use a different session store so I decided to write up a little blog post outlining what we did.

Spring-Session

Spring-Session provides a container portable method of persisting Http session data.   I won’t go into great detail on how to set it up in this post,  but full instructions to setup Spring-session can be found on their official website here.   For us,  we are going to configure Spring-session to use our own custom session store back by a MySQL database!  We do this by:

  1. Implementing our own SessionRepository and
  2. Injecting the custom SessionRepository to SessionRepositoryFilter

 

Create the SessionRepository

We first have to implement the SessionRepository interface.   It has four methods and they are all pretty self explanatory on what they do.   It’s worthwhile noting that the Session type here is not the container provided javax.servlet.http.HttpSession, but a org.springframework.session.Session instance instead.   In the context of a web application,  it does still represent a HttpSession in that the getId() method will return a jSessionId and attributes will be its session data.

  
public interface SessionRepository<S extends Session> {
           S createSession();
           void save(S session);
           S getSession(String id);
           void delete(String id);
}

For our “MySQL” storage sample,  the repository makes use of a “SessionStoreDao”.   This is simply our DAO object responsible doing CRUD operations on a table called “SessionStore”, which will store our user session data.  I won’t provide code for the DAO (as that depends on if you are using a ORM or stright JDBC-SQL) or the table.   We also have a SessionStore  “domain object”, which is just used to pass around information in our application.   This POJO contains information such as the jsessionId, timestamp and the serialized session data.  Let’s start:

public class MysqlSessionRepository implements SessionRepository {
	   @Autowired
	    private SessionStoreDao sessionStoreDao;

	    /**
	     * @return A new instance of MapSession
	     */
	    @Override
	    public Session createSession() {
	        Session s = new MapSession();
	        return s;
	    }

createSession() simply creates a new MapSession instance.  Spring-session will invoke this method whenever it needs to create a brand new session, for example, the first time the application invokes request.getSession().   You can do any additional initialization steps here, but in our simple example we simply return a empty map.

  


	    /**
	     * Update or create a new SessionStore to save the session to the DB.
	     * @param session This will be serialized and stored in the DB.
	     */
	    @Override
	    public void save(Session session) {
	        String id = session.getId();
	        Timestamp currentTime = new Timestamp(System.currentTimeMillis());
	        SessionStore sessionStore = sessionStoreDao.findOneBySessionId(id);
	        if (session != null && sessionStore == null ) {
	            sessionStore = new SessionStore();
	            sessionStore.setSessionId(session.getId());
	            sessionStore.setCreatedDate(currentTime);
	        }

	        if (session != null){
	        	// searlize the object
	            byte[] bytes = Util.objectToByteArray(session);
	            sessionStore.setData(bytes);
	            sessionStore.setLastModified(currentTime);
	        }

	        // save
	        sessionStoreDao.save(sessionStore);
	    }

The save() method is where you will have to do any work required to persist your session data to the database.   You have to first check if the user session already exists in the database.  For web applications, a natural key for the session record (in the database) is the jsessionId.     In our example, we first try to obtain the existing data (domain object) from the database.   If it exists we then  serialize the data contained in the provided in the Session object.   The session data can be represented in any way you want it in the database, but for simplicity sake, we just serialized the entire Session object.  This of course assumes everything stored in the session serializable.  Here, we also save additional information along with the persisted session (such as last modified date).

The SessionStoreDao.save() method simply takes in our domain object and persists it to the MySQL database.  Of course, if this is the first time the session is being persisted to the DB, we’ll have to create a brand new row to save the user data (hence the null check).

  

	    /**
	     * Load the seralizied session from the DB.
	     * @param id The session id (jsessionId)
	     * @return the Session instance correspoinding to the jsessionid
	     */
	    @Override
	    public Session getSession(String id) {
	        SessionStore sessionStore = sessionStoreDao.findOneBySessionId(id);
	        if (sessionStore == null ) {
	            return null;
	        }
	        byte[] blobData = sessionStore.getData();
	        MapSession s = (MapSession)Util.byteArrayToObject(blobData);
	        return s;
	    }

getSession() is responsible for deserializing/re-creating a the org.springframework.session.Session if it exists in the database.  Our SessionStoreDao is used to query the database based on the “session id” provided by Spring-Session.  In the context of a web application, the id parameter will always be the jsessionId.

In our save() method example above, we simply serialized the entire Session object and stored it into the database so to recreate it,  we simply deserialize it back into the Session object.  If session is brand new, there should be no such record in the database yet.  For brand new user sessions, Spring-session will determine on your behalf when to call load() and create() .  To signify to Spring-session that the user session is new (or not found) and a brand new session needs to be created, getSession() should return null.

 

  

	    /**
	     * Handles requests to invalidate the session (ie logout).
	     * Delete the session from the DB.
	     * @param id The session id (jsessionId)
	     */
	    @Override
	    public void delete(String id) {
	        SessionStore sessionStore = sessionStoreDao.findOneBySessionId(id);
	        if (sessionStore != null ) {
	            sessionStoreDao.delete(sessionStore);
	        }
	    }
}

delete()  The final method that you need to implement is the delete() method.  A example of when Spring-session will invoke this method is if you invalidate the HttpSession.  In our simple example, we simply have to delete the SessionStore record from the MySQL database.

Inject it into SessionRepositoryFilter

After creating our MysqlSessionRepository implementation, we need to inject into SessionRepositoryFilter so that it will be used by Spring-session.  There many ways to do this, I will present one method here.

@Configuration
public class MysqlSessionStoreConfiguration {	

    @Bean
    public MysqlSessionRepository sessionRepository() {
        return new MysqlSessionRepository();
    }
    
    @Bean
    public <S extends ExpiringSession> SessionRepositoryFilter<? extends ExpiringSession> springSessionRepositoryFilter(SessionRepository<S> sessionRepository) {
        SessionRepositoryFilter<S> sessionRepositoryFilter = new SessionRepositoryFilter<S>(sessionRepository);     
        return sessionRepositoryFilter;
    }
}

The code is a bear-bones implementation of a configuration class that creates a MySqlSessionRepository bean and injects into a SpringRepsoitoryFilter.  Note the @Configuration annotation indicating this is a configuration class.

And that is it.  We’ve created a MysqlSessionRepository that implements SessionRepository.  This custom repository stores user session data into a MySQL database.  As your application handles http requests while storing data into the HttpSession object, Spring-session will invoke create/save/delete/load methods as required which will save the user session data to the MySQL database without the application knowing.  The changes on application developers is very minimal as Spring-session provides an almost seamless layer to route the session data anywhere.  Developers can more or less continue to use the application HttpSession as normal, but we do make an assumption here that the data stored in the session is serializable.

 

Non-sticky sessions with Spring-Session (Part 1)

by

Preface:

I recently had to work on a project where we had to turn an existing Java (Springboot) application whom was served by multiple web servers sitting behind a load balancer and required sticky sessions to an application that could be deployed to an environment using non-sticky sessions.

The application was not stateless and was using the session to store data between requests.  After doing some analysis, changing the application to become stateless was not an option for us.  So we needed to save the session data somewhere, on disk, using Redis or a database.

Spring-Session

Spring-Session provided an API layer to persist session data without having to significantly change application code.  It basically provided an HttpSession implementation that saved data to disk and allowed application developers to continue freely using the Session object as before (as long as the data was serializable).

I won’t go into huge detail on how Spring-Session works, but it basically replaces the container provided HttpSession object with its own (via a Filter) and at some point, Spring-session will persist the data to someplace (as configured by us) without the application itself needing to know what is going on behind the scenes.

When the user’s request ends, the session data is persisted and when that same user makes another request, as expected, Spring-session will fetch the user’s session data and desearialize it.  The data will then be available using the HttpSession’s getParameter() methods as a conventional HttpSession object.

Proof of Concept and Session Store
Spring-Session comes with support using Redis as the session store (using Jedis).   So our first step in evaluating Spring-Session is to get a our application integrated with Spring-session,  setup a Redis and Redis backup (Redis slave) servers. This way we can determine if Redis is a good choice for our session store and if not, can we still use Spring-session with another session store (such as a relational DB).

One can argue if the redundancy of session data is actually required here.  That is, the data we are using Redis to store is only session data as the user navigates though our application and not actual user data that requires persistence.   I’ll leave that as a argument for a later time, but for our sake, we needed to see some redundancy features of Redis as a matter of “policy”.

Our PoC arcitecture looked like the following:

Setting Up With Maven
Spring-Session with Redis requires 2 dependencies,  i) the Spring-Session dependency and   ii) the Redis connector.   If you are are using a custom session store, you do not need to include the Spring-Session data-redis dependency.

  
      <dependency>
         <groupId>org.springframework.session</groupId>
         <artifactId>spring-session</artifactId>
         <version>1.0.2.RELEASE</version>
      </dependency>
      <dependency>
         <groupId>org.springframework.session</groupId>
         <artifactId>spring-session-data-redis</artifactId>
         <version>1.0.2.RELEASE</version>
         <type>pom</type>
      </dependency>

Springboot
If you are using Springboot, you have to create the JedisConnectionFactory bean that will be injected into the SessionRepositoryFilter.  Many of the configuration properties of a JedisConnectionFactory have default values, so the example below is pretty sparse.  I only specify the URL of my Redis master  instance, but it is in here where you can specify other properties such as password, etc.

  
    @Bean
    public JedisConnectionFactory connectionFactory() {
    	JedisConnectionFactory redisConnectionFactory= new JedisConnectionFactory();
        redisConnectionFactory.setHostName("redis.masterserver.com");
        redisConnectionFactory.afterPropertiesSet();
        return redisConnectionFactory;
    }

Testing the Setup
To test our Poc, we wanted to see that 1) our setup is truly session-sticky-less and 2) Redis data redundancy was working properly.

1) Session Stickiness
To test session non-stickiness, we send a HTTP request from a computer though the load balancer.   We find out it is being handled by application server A and the application puts some data into the session.  We then shut down server A and send another request from the same browser.  The request is now handled by server B, but because we’ve externally stored the session data, the user’s session (and data) are still alive.

2) Redis Redundancy
To test Redis redundancy, we sent a HTTP request to our app though the load balancer, but we don’t care which server handles the request.  We use the Redis client (redis-cli) check that the session data being stored in the master Redis instance.  We then connected the client to the slave instance and check that the same data is also in the slave.

 

Conclusion and More Work
It turned out that integrating our application with Spring-Session was very straight forward. Our PoC Redis and replication process was also easy to get going. A architectural decision was made on not to use Redis as the session store but we determined that we still wanted to use Spring-Session with a relational database as our storage. This leads us to part 2 of our Spring-Session introduction, using Spring-Session with a relational DB (Oracle or MySql).

References and other tutorials
If you are interested in more details on how to setup Spring-Session with Redis, you can look at these sites below. They helped us a lot.

  1. Spring-Session Project Page
  2. Video: Spring-Session by Josh Long
  3. Basic Tutorial
  4. Spring-Data: Jedis
  5. Managing Users Data with Spring Session
  6. Another Redis Replication Tutorial

 

Obtaining Facebook page access tokens: The 4 step program

by


More and more businesses are creating Facebook pages to promote their products and services.    To keep content fresh, many websites and applications are automatically posting content to their pages.     They allow an application to post content on behalf of the user.   But how do these applications post content on a page, as the page?   That’s where page access tokens come into play.   I wrote a detailed article for The Jonah Group on how to do this.   You can view it on their blog here.

Grails Tip # 6: Service layer transitions

by

On my last Grails project, as good Grails developers, we faithfully put core application logic inside various service methods. Delightfully, the benefits of doing so paid off and we began re-using services though out the application.

One day, while using our application on a fairly complex set of test data (both in volume and the fact our domain model graph is complex), we stumbled on a huge performance problem. After profiling the controller-action, the problem was traced down to a call to a service method. Simplified, it look like:

class ArticlesController {
   def service

   def handleAction = {
      // stuff ...
      // more stuff ...
      for(int i=0;i < loopLimit;i++){
         service.serviceMethod(someParameters)
      }
      render(view: "article"...)
   }
}

This was a commonly re-used service method, but the interesting part of this method was the fact it was being called within a loop, a loop that could potentially be called several hundred times. The looping itself is not a problem (nor could it be avoided).

By trial and error, we discovered that the actual call to the serviceMethod() was causing the performance issue. If we
1) Simply removed the service method and embedded the application logic in the service method into the loop or
2) Made the service class non-transactional

The performance issue disappeared.  We realized that the under-the-hood work that goes on to setup the transactional service boundry, when there is a complex or large volume of data in the Hibernate session, causes a dramatic perfomrance impact when we repeadly cross the controller- service layer boundry.

The simplest and cleanest solution was to loop inside the service method, thus the application cross the boundary only once. This has the side effect that any errors will roll-back the entire set of data and not just the single record being updated but we were ok with this.

class ArticleService {
   static transactional = true
   def serviceMethod(def params){
      // do stuff..
   }

   def serviceMethodMultiple(def params){
      for(int i=0; i < loopLimit; i++){
         serviceMethod(params)
      }
   }
}

And in the controller:

class ArticlesController {
   def service

   def handleAction = {
      // stuff ...
      // more stuff ...
      service.serviceMethodMultiple(someParameters)
      render(view: "article"...)
   }
}

From the standpoint of a intermediate Grails developer, this isn’t a problem that could have been detected beforehand since it only manifests itself when there is a complex domain model graph already in the session.

We chalked this up as a life lesson. The final solution, avoid any code that may repeatedly crosses into the service layer, especially for services marked as transactional. Instead, create a new method that does the looping inside the service boundary. Identification and avoidance was the best action forward as we were in no position to fix any potential underlying issue with the framework (if there even was any).

Just Add Shoyu

by




Being Japanese (Canadian), people often ask me what I eat at home and if it is similar to those served at Japanese restaurants. I always have to explain, that Japanese food at a restaurant is quite different then the food prepared at home. For the record, very few Japanese people make their own sushi at home. It is just too time consuming and expensive to gather and prepare all the ingredients (analogous to homemade Dim Sum).

I would say “Japanese Canadian” food is a mixture between traditional “Japanese food”, Chinese, and western foods. Many of the food we eat could be technically be classified as Korean or Chinese, but has become such a staple in Japanese Canadian households that we do consider it part of our culture as well.

In addition, much of the food recipes have been modified to use western ingredients. Take for example, Spam sushi and Japadogs sandwiches.

The Japanese Canadian Cultural Center(JCCC) recently published a cookbook, a project that focuses specifically on Japanese Canadian food. Not only will you find traditional sounding recipes, but also foods from other cultures have become a part of the foods Japanese Canadians eat.

The book was produced using recipes submitted by and produced by countless volunteers within the Japanese community. For example, my aunt was the project manager, my cousin was a principle photographer, and I made their website. This book is more than a regular cookbook as it also describes the personal stores behind the recipes.

The book is now out; you can find it at Chapters and other cookbook stores or directly though the JCCC. The book looks awesome and has some great recipes (including one for my grandfather’s roasted chicken).

Click here to view the official Just Add Shoyu website: Just Add Shoyu

Various reviews of the cookbook:

Grails Tip # 5: Apache POI

by

Apache POI with Grails

Many people have asked how to use Apache POI with Grails. A quick search on the Internet
reviews bits and pieces but no official documentation or tutorial. So I decided two quick ways of incorporating POI
with your Grails applications.

In a nutshell, POI provides a Java API for reading and writing MS documents such as Word and Excel documents.
You can find the library and full details here.

Write directly out to the output stream

The first method involves obtaining a handle to the response output stream and writing directly to it. You must
remember to set the content response header and content type appropriately or the user will see garbage. 

        package com.ex
        import javax.servlet.ServletOutputStream
        import org.apache.poi.hssf.usermodel.*

        class ShelfController {

            def index = {

                HSSFWorkbook wb = generateWorkbook();
                response.setHeader("Content-disposition", "attachment; filename=serverList.xls");
                response.setContentType("application/excel");

                // Write the output to the OutputStream
                ServletOutputStream f = response.getOutputStream();
                wb.write(f);
                f.close();
            }

            private HSSFWorkbook generateWorkbook() {
                HSSFWorkbook wb = new HSSFWorkbook();

                HSSFSheet sheet = wb.createSheet("new sheet");

                // populate the spreadsheet
                HSSFRow row = sheet.createRow((short)0);
                    .
                    .
                    .
                return wb
            }

    }

Use AbstractExcelView

Because Grails is built on Spring and your Grails controllers can return Spring’s ModelAndView objects, you can
extend Spring’s AbstractExcelView and implement its buildExcelDocument method. Your Grails controller will simply
return this Excel view as the one to render. It will set the header and content type for you. 

        package com.ex
        import javax.servlet.ServletOutputStream
        import org.apache.poi.hssf.usermodel.*

        class ShelfController {

            def index = {
                // forward to the list view to show them
                return new ModelAndView(new SheflExcelView(), [ bookList : "abc" ])
            }


        }

Implement the buildExcelDocument method in your Excel view: 

        package com.ex

        import javax.servlet.http.HttpServletRequest
        import javax.servlet.http.HttpServletResponse
        import org.apache.poi.hssf.usermodel.*
        import org.springframework.web.servlet.view.document.AbstractExcelView

        class SheflExcelView extends AbstractExcelView{

            protected void buildExcelDocument(Map<String, Object> model,
                HSSFWorkbook workbook, HttpServletRequest request,
                HttpServletResponse response) throws Exception {

                HSSFWorkbook wb = generateWorkbook(workbook);
            }

            private HSSFWorkbook generateWorkbook(HSSFWorkbook wb) {
                HSSFSheet sheet = wb.createSheet("new sheet");
                .
                .
                .
            }
       }

I personally prepare the second method. The Excel document is a “view” so I don’t want to pollute the controller
with a whole lot of code generate the Excel report. In addition, AbstractExcelView also sets your response and content
type headers on your behalf.

Grails Tip # 4: java.lang.Boolean.call()

by

No signature of method: java.lang.Boolean.call()

As specified by , Grails provides convenience method to check if a object contains errors and set the CSS class on the element.

I came across this problem where suddenly, under some conditions, I was seeing the following error:

No signature of method: java.lang.Boolean.call()

Further down the stacktrace, I notice something more interesting.

Caused by: groovy.lang.MissingMethodException: No signature of method: java.lang.Boolean.call() is applicable for argument types: (java.util.LinkedHashMap, java.lang.String) values: [[bean:{}, field:asc], input-error]Possible solutions: wait(), any(), dump(), wait(long), wait(long, int), and(java.lang.Boolean)

At first glance, the stacktrace looks like complicated garbage. However, after a few minutes of looking though the stacktrace, the parameter’s in the exception cause looked suspiciously like those specified in a invocation of the GSP’s hasErrors method.

I soon realized that this exception only occurs during situations where errors would be displayed on the GSP. Looking though the code flow, I soon realized something suspicious. 

		def save = {
			.
			.
			.
			
			command.validate()
			if (command.hasErrors()){
				render (view:input, model:[command:command, hasErrors:true])
				return
			}
		}

Notice that the if the command object has errors after validation, the model being returned to generate the GSP contains both the command and a variable hasError which is assigned to true.

I ran a quit test, what happens if try and execute the value of a boolean as a method. 

		true()

And volila, a No signature of method: java.lang.Boolean.call() error. It appears, when there is a variable in the model with the same name as a GSP method, under some conditions, Grails replaces the method invocation with the value of the variable and then it executes the method.

In this example, it appears that hasErrors(…) was being replaced by the value of the hasError variable, true, and then being executed. Thus the final statement looked like the following: true(bean:command, …) This of course, would result in a no method signature found error.

After changing the name of the hasError variable to something else, say, showErrors, the GSP rendered as expected. By reading this article, I hope that you can save yourself a couple of hours of struggle.

How to Read a TTC Transfer

by

The easiest to validate information are the color, date, and route. There is also a tear-off portion at the very top that lets TTC staff check if the transfer was issued during the day or “night” hours. No back-to-back days ever use the same color.

When you climb onto a bus, you often see a bunch of transfers in a holder above the fare box. That holder has metal clips that can slide up and down and cause notches on the transfer when the driver removes one from the holder. In addition to the small notches, the holder also allows the driver to tear the transfer to a specific length.

Along the side of the transfer, you see two columns of numbers. On the left column, you’ll see numbers 5 though 12 and then from 1 though 4. When the driver issues a transfer, it is torn to a specific length. The last number shown at the bottom of the transfer indicates the hour the transfer was issued.

On the right column, there are two digit numbers and the letters U and D. These indicate the minute of the hour the transfer was issued and if the bus/streetcar was going up or down the route.

“U” or “D” refers to “up” or “down”. This represents the direction of travel. Up means north or west and down means south or east. When a driver grabs a transfer, in addition to tearing it to a specific length, these notches indicate the time and direction you were traveling when it was issued.

<%= image_tag "articles/transfer/transfer2.gif" %>

Using the example picture on the above, this transfer was issued at 11:15. Since the “night” strip is torn off, it means the ticket was issued at 11:15am. The notch over the D means I was travelling southbound.

The transfers have also been designed so that a person cannot pretend to have the transfer look like it was issued at a later time. This why the hour and minute numbers are ordered in the way they are.

For example, a transfer issued at 7am could not be re-torn to make it look like it was issued at 2pm since the number 7 would have been torn off. Similarly, a 5am transfer could look like one issued at 6pm because at 5pm, the transfers must have the “night” strip on top.

<%= render :partial => “article/article_footer”, :locals => { :tags => [‘fun’, ‘ttc’], :date=>’January 10, 2011′} %>