A long time since my previous blog post. Deepest apologizes, I have had so little time for my "hobbies"...
But now! I faced so frustrating issue in my work so that I must forward it to you. We have been developing our system quite a time already. Real problems started when it was time for the first test deployment to the actual server. We are using Grails as our controller layer which includes a wonderful resource plugin that enables us to use newest techiques in our assets easily (such as Coffeescript or LESS). The production mode will be caching, zipping and minimizing all resource modules in order to reduce clients' overhead. These are not used in development mode. So, during the deployment I discovered that the resource plugin has a "bug" which prevents the definition of same file to multiple modules.
After a Google moment, I found that the plugin's author wasn't planning to support such a feature (GPRESOURCES-166). We had two options: either divide our code into multiple mini-mini modules (which reduces the usefulness of modules a lot) OR try to go around the bug/feature.
So, after a long moment of discovering plugin's source codes, I managed to find a detour. It is not an elegant way but working well enough. The resouces plugin uses a chain of resource mappers to transform original files into processed files. The bundling and bundle renamining (for cache prevention) are dealt by using file paths as identifiers for files. So so... The best bet is to rename the file with a unique prefix before the resource is "registered" into module. When registering is done, the resources plugin tries to fetch the resource file based on its defined filename. Thus, we need to translate the modified filename back to the original one so that resources plugin can find the actual file. When the file has been fetched, resources plugin starts to process the file with its processing chain. We must add our own custom resource mapper to the beginning of that chain to translate processed resource's URL back to the original so that later processors can deal with right files.
The solution is to override two resource plugin's methods by using meta-programming. First we modify the filename during the resource definition. Then we rename it back to the original for file handle fetching. After that, we use our own resource mapper to change resource's URLs back to the normal at the beginning of the processing chain. And hóle! Now the plugin supports multiple module definitions for same file also with cached-resources plugin.
Here is the actual code:
You must place that into your grails-app/resourceMappers folder. After that you must enable support by calling MultipleStaticResources.enable()
from your resources.groovy bean definition closure.
Of course this solution may conflict with our own resource mappers, but for me it works well enough: resource mappers for CoffeeScript, Handlebars, LESS, zipped and bundled/cached resoures (and also few own) are working fine with this hack.
Happy hacking!
Tuesday, 26 March 2013
Tuesday, 11 December 2012
CoffeeScript aspects
Hojoo! First "real" blog message coming, finally!
There are some cases when client implementation shoudn't be available for everyone. I encountered such a problem when I was creating Backbone views for different users: users may have different roles, and depending on those roles, some actions should be available or not.
Of course I could have just ignored the actions is my Javascript. In this case, the whole implementation had to be hidden so if-else was out of question. Making different views for different role combinations is just plain stupid.
I decided to solve the problem by using using aspect oriented programming. Javascript functions have apply-method so it was quite trivial to make a simple aspect library:
Usage is trivial: just call @around-method and give the function name (pointcut) which must be wrapped. When function is called, the wrapper code is called first. It can decide whether to execute the original code via joinpoint interface or not. It can also modify function call argumens and return value. Joinpoint supports following functions:
Now I just have to make a basic Backbone view which is public for everyone. When I fetch the roles during page render, I can include all needed logic in separate files. Those files add the logic by binding their advices to the basic view. I can also apply some security policy for those Javascript "extensions", completely hiding the "secret features" from unwanted users. Pretty handy, I think! :)
There are some cases when client implementation shoudn't be available for everyone. I encountered such a problem when I was creating Backbone views for different users: users may have different roles, and depending on those roles, some actions should be available or not.
Of course I could have just ignored the actions is my Javascript. In this case, the whole implementation had to be hidden so if-else was out of question. Making different views for different role combinations is just plain stupid.
I decided to solve the problem by using using aspect oriented programming. Javascript functions have apply-method so it was quite trivial to make a simple aspect library:
Usage is trivial: just call @around-method and give the function name (pointcut) which must be wrapped. When function is called, the wrapper code is called first. It can decide whether to execute the original code via joinpoint interface or not. It can also modify function call argumens and return value. Joinpoint supports following functions:
Now I just have to make a basic Backbone view which is public for everyone. When I fetch the roles during page render, I can include all needed logic in separate files. Those files add the logic by binding their advices to the basic view. I can also apply some security policy for those Javascript "extensions", completely hiding the "secret features" from unwanted users. Pretty handy, I think! :)
Saturday, 24 November 2012
Some definitions
Hi,
It's time to clarify the story behind the name of this blog. As you can guess, tunkkaus is a Finnish word. The direct translation of 'tunkkaus' is that someone is using a jack (tunkki = jack) to lift a car before changing its tyre.
However, when talking with other software engineering professionals, the word 'tunkkaus' may have an another meaning. When I say that I'm going to 'tunkata' the software somehow, it means that I'm going to develop the software, usually with some exotic solutions. These solutions may be marvellous or spaghetti or something just plain normal. Usually the word has a little bit negative tone when somebody says it. However, it can have also a positive tone.
Thus, tunkkaus is the way to go!
It's time to clarify the story behind the name of this blog. As you can guess, tunkkaus is a Finnish word. The direct translation of 'tunkkaus' is that someone is using a jack (tunkki = jack) to lift a car before changing its tyre.
However, when talking with other software engineering professionals, the word 'tunkkaus' may have an another meaning. When I say that I'm going to 'tunkata' the software somehow, it means that I'm going to develop the software, usually with some exotic solutions. These solutions may be marvellous or spaghetti or something just plain normal. Usually the word has a little bit negative tone when somebody says it. However, it can have also a positive tone.
Thus, tunkkaus is the way to go!
 |
| Image: http://forum.f-bodyfinland.com/Yabbse/index.php?topic=59966.15 |
Greetings!
Hello folks!
Here is some background about me: I'm a software engineer and a computer science student from Aalto University Finland.
Coding is my passion - every commit I make I want to be the perfect one. I love beautiful code and genious solutions. I started my programming "career" when I was 12 years old. My first language was a BASIC language, CoolBasic. After that I moved on to C++ world and making games for my fun. By that time, C++ was the best language ever... at least in my opinion. That was until I discovered C# (I think it was .NET 3.0) which leaded me into carbage collected world. Java was the next one to learn. I wasn't so interested about Java when I begun my school at Aalto, but after a while I started to like it too...
I've always considered myself as a backend developer. That was what I said to my boss when I started my work in ICT cosulting company about two years ago. However, work challenges leaded me into Grails and dynamic programming. WOW! I must say that Grails/Groovy was the thing. Now I can't even think about making software without funcional languages. I've found frontend more and more interesting. Thanks to my collegue, I discovered Coffeescript which also is awesome! I must say that my "backend dream" is inevitably slipping towards front. Thus, I'll most likely cover some CoffeeScript/Grails/Groovy stuff in this blog.
I've noticed in my work that you can do things in two ways: right and wrong. Thus, I try to make this world a little bit better by telling you some of my experiences from the software engineering field. I hope that my experiences and adversities will motive you readers to select the right choices and also make this world better by producing higher quality softwares.
Cheers,
Matti
Here is some background about me: I'm a software engineer and a computer science student from Aalto University Finland.
Coding is my passion - every commit I make I want to be the perfect one. I love beautiful code and genious solutions. I started my programming "career" when I was 12 years old. My first language was a BASIC language, CoolBasic. After that I moved on to C++ world and making games for my fun. By that time, C++ was the best language ever... at least in my opinion. That was until I discovered C# (I think it was .NET 3.0) which leaded me into carbage collected world. Java was the next one to learn. I wasn't so interested about Java when I begun my school at Aalto, but after a while I started to like it too...
I've always considered myself as a backend developer. That was what I said to my boss when I started my work in ICT cosulting company about two years ago. However, work challenges leaded me into Grails and dynamic programming. WOW! I must say that Grails/Groovy was the thing. Now I can't even think about making software without funcional languages. I've found frontend more and more interesting. Thanks to my collegue, I discovered Coffeescript which also is awesome! I must say that my "backend dream" is inevitably slipping towards front. Thus, I'll most likely cover some CoffeeScript/Grails/Groovy stuff in this blog.
I've noticed in my work that you can do things in two ways: right and wrong. Thus, I try to make this world a little bit better by telling you some of my experiences from the software engineering field. I hope that my experiences and adversities will motive you readers to select the right choices and also make this world better by producing higher quality softwares.
Cheers,
Matti
Subscribe to:
Posts (Atom)