For the last three years an amazing thing has happened. The Triangle Area ColdFusion User's Group (TACFUG), has put a lot of blood, sweat and tears into organizing a conference, NCDevCon, that has ColdFusion at its center.
This by itself is an amazing feat; especially given that the large ColdFusion specific conferences are faltering and Adobe, the main source of CF, does not have an independent gathering focused on this topic.
On top of this, the conference manages to have broad coverage of many relevant areas of Colfusion and Web development while also giving beginners options for hands on sessions.
This is a major, major (yes two majors!) achievement. So definetly cudos to the organizers.
All this is available for a very small fee ($60) compared to the several hundreds of dollards we commonly pay. So definetly a deal in light of the knowledge that is being shared.
I have been selected to do two presentations this year on very different topics. The first one on Application Security, I can see eyes already glazing over, nope we'll provide some practical code here as well.
The other one is on mobile application developement with Sencha Touch and ColdFusion. This one is harder to organize as I have lots of material I am trying to decide what to cut out at the moment.
Hope to see you there.
Cheers,
-B
Bilal's view on tech and code (Java, C#, vb, cfml, JavaScript, NodeJS, etc, etc.) and some random other musings.
Wednesday, August 31, 2011
Wednesday, August 24, 2011
CF: Decide if we got enough memory to succeed
Since the beginning of computing there has been the struggle between available resources and the number of computing tasks to run on them. When we had 16KB of RAM our code looked very compact and we were critical of any extra bytes that we stored or computing cycles we ran.
When, today, we easily reach 16GB of RAM the level of individual byte analysis does not quite happen. More likely than not, we tend to worry less about do we have enough memory to run this operation and assume (to our chagrin) that things will work themselves out,... right until they don't.
Which brings me to the problem at hand. Rather than running a process, thread, task and hoping things work, can we predictably make that decision instead?
In my case, this being ColdFusion I needed to find out whether I had a snowballs change in the Hot-Place to open an Excel file. Remember that ColdFusion uses the Apache POI library to read Microsoft Office documents. Works normally fairly transparently but the downfall here (it is documented as well, see POI docs) is that POI will grab big chunks of memory for processing any access to, say, a spreadsheet.
This, if not managed, gets us into an unconfortable situation of crashing the server with OutOfMemroy exceptions. Yep, not good.
So our solution was first determine a common estimation factor (spreadsheet size to JVM memory size), then use it to see whether we would have a chance of opening / loading this spreadsheet at all given the current memory envelope on the server.
Nice message to user if we had no chance, go ahead and process otherwise.
This eliminates unneccesary server crashes. Which is, indeed, a very good thing.
Here is the code snippet we used to determine available CF server memory:
<cffunction name="getMemory" returntype="numeric"
access="private" hint="return server unused available memory">
<cfscript>
var intMB = 1024 * 1024;
var objRuntime = createObject("java", "java.lang.Runtime").getRuntime();
var intUsedMem = objRuntime.totalMemory() - objRuntime.freeMemory();
var intAvailableMem = objRuntime.maxMemory() - intUsedMem;
return (intAvailableMem/intMB);
</cfscript>
</cffunction>
The value here will have to be compared against the expected value of memory use for your operation. For example, if you expect your spreadsheet to occupy 100MB memory while loaded into JVM and want to have a margin on 50MB, you can only proceed with the operation if the return of the above function is a value of 150 or greater.
Cheers,
B.
When, today, we easily reach 16GB of RAM the level of individual byte analysis does not quite happen. More likely than not, we tend to worry less about do we have enough memory to run this operation and assume (to our chagrin) that things will work themselves out,... right until they don't.
Which brings me to the problem at hand. Rather than running a process, thread, task and hoping things work, can we predictably make that decision instead?
In my case, this being ColdFusion I needed to find out whether I had a snowballs change in the Hot-Place to open an Excel file. Remember that ColdFusion uses the Apache POI library to read Microsoft Office documents. Works normally fairly transparently but the downfall here (it is documented as well, see POI docs) is that POI will grab big chunks of memory for processing any access to, say, a spreadsheet.
This, if not managed, gets us into an unconfortable situation of crashing the server with OutOfMemroy exceptions. Yep, not good.
So our solution was first determine a common estimation factor (spreadsheet size to JVM memory size), then use it to see whether we would have a chance of opening / loading this spreadsheet at all given the current memory envelope on the server.
Nice message to user if we had no chance, go ahead and process otherwise.
This eliminates unneccesary server crashes. Which is, indeed, a very good thing.
Here is the code snippet we used to determine available CF server memory:
<cffunction name="getMemory" returntype="numeric"
access="private" hint="return server unused available memory">
<cfscript>
var intMB = 1024 * 1024;
var objRuntime = createObject("java", "java.lang.Runtime").getRuntime();
var intUsedMem = objRuntime.totalMemory() - objRuntime.freeMemory();
var intAvailableMem = objRuntime.maxMemory() - intUsedMem;
return (intAvailableMem/intMB);
</cfscript>
</cffunction>
The value here will have to be compared against the expected value of memory use for your operation. For example, if you expect your spreadsheet to occupy 100MB memory while loaded into JVM and want to have a margin on 50MB, you can only proceed with the operation if the return of the above function is a value of 150 or greater.
Cheers,
B.
Friday, August 19, 2011
Facebook and Automatic Granting of Permissions to Applications via Mobile Devices
I make it a policy of conduct not to install any Facebook application or grant any Facebook apps rights to my Facebook account. Call me paranoid (many have).
So, needless to say, I was surprised when I was looking at my settings page under application how many applications I seem to have granted access.
There they were, a little more than half a dozen apps that seem to have access to my information and friends, not remembering, having granted any of them the right to do so.
This baffled me to no end. How did this happen?
Well, the only thing that seemed to be a common pattern for these apps is that I had loaded similarly named application on my iPhone from the Appstore. Ahh, yes, here is where the plot thickens. Thus the best I can explain this is that the terms of acceptance of these apps includes that they can access my Facebook profile. Thus, if they detect the Facebook app loaded on your device they establish connection and register themselves as authorized apps with Facebook.
I might get this all completely wrong, but this is the only explanation I can come up with, since I got this policy of no apps etc.
Yes, some of you may now say that I was too trusting a soul, and this, too, might be true, so I am now checking more regularly to see whether I am being hoodwinked into approving this type of behavior.
I am now checking regularly what the Facebook app settings page looks like (see below) and killing the permissions. I truly wish that FB had explicit lock on this type of stuff as this is very sneaky behavior in my opinion.
As usual would appreciate some feedback.
Cheers,
-B.
So, needless to say, I was surprised when I was looking at my settings page under application how many applications I seem to have granted access.
There they were, a little more than half a dozen apps that seem to have access to my information and friends, not remembering, having granted any of them the right to do so.
This baffled me to no end. How did this happen?
Well, the only thing that seemed to be a common pattern for these apps is that I had loaded similarly named application on my iPhone from the Appstore. Ahh, yes, here is where the plot thickens. Thus the best I can explain this is that the terms of acceptance of these apps includes that they can access my Facebook profile. Thus, if they detect the Facebook app loaded on your device they establish connection and register themselves as authorized apps with Facebook.
I might get this all completely wrong, but this is the only explanation I can come up with, since I got this policy of no apps etc.
Yes, some of you may now say that I was too trusting a soul, and this, too, might be true, so I am now checking more regularly to see whether I am being hoodwinked into approving this type of behavior.
I am now checking regularly what the Facebook app settings page looks like (see below) and killing the permissions. I truly wish that FB had explicit lock on this type of stuff as this is very sneaky behavior in my opinion.
As usual would appreciate some feedback.
Cheers,
-B.
Subscribe to:
Posts (Atom)