I started out by only coding CFML in tags, being self-taught I had to go by what people were using to show how to do basic things, as I progressed I learned how to expand on that knowledge, but kept working in tags because, well, that's what I was used to.
I've looked into CFScript in the past, but didn't really start practicing until more recently (A few months ago), writing new CFCs in script and taking the opportunity to practice my cfscript-fu while updating old code.
I saw Adam Camerons post about him helping someone convert old tag-based code into cfscript, and it made me think (And ask) "Why is cfscript better?"
After many messages between me and Adam Cameron, and between me an Sean Corfield (Both are programmers I highly recommend following on blogs and twitter), I'm *still* not sure what's so great about cfscript compared to cftags.
Ps. I hate twitter for discussions.
Neither Adam nor Sean can, in my not-always-so-humble-opinion tell me in simple terms what's so great about cfscript.
It seems to boil down to personal choice (Unless you ask Sean, who will tell you what an evil man you are for using tags. Not a direct quote.)
Check out Adams blogpost about script vs tags, it's an interesting read and he has a different take on it than I do.
I'm always looking to improve my skillset, because programming is awesomely fun :)
I'm now coding in both tags and script, mostly writing new CFCs in cfscript, because it means I'm learning new stuff, while adding useful skills to my skillset, learning cfscript was natural to do because it's used all over the place, and a lot of shops and companies use it to a varying extent.
Overall, I don't know of any inherent benefits to using cfscript, while it sometimes *feels* like it's executing faster than tagbased code, that's not exactly empirical proof, I've yet to find any *real and proven* benefits to cfscript in terms of performance.
It's been debated that it's better to use cfscript because it's closer to other languages, since CFML is the only tag-based language around.
Personally I don't find it very beneficial to know a language similar to a new one, and I still think of cftags and cfscript as just two different syntax-sets to the same language.
Sean thinks it's harder for someone to learn any other real language, coming from CFML tags, and noted it as a reason for not hiring someone.
I agree, but only if the person *only* knows CFML tags and nothing else..
But I don't know any web developer who don't also speak at least JS, so right there that argument fall, unless he's ever looked to hire someone who *only* speaks CFML, and literally nothing else.
From what I know there is nothing available in CFScript that isn't available in CFTags, and vice versa, there isn't any performance gain to either.
It seems that many people feel that tags are too close to html, being inside of <>, and should thus not be anywhere near business logic
I do find it amusing that CFML = ColdFusion Markup Language, which is only sortof true after the introduction of CFScript.
I'm not "defending" the use of tags, again I code in both, I just wanted to see if anyone could give me actual, specific reasons why cfscript is better than tags, and so far... I haven't seen it.
I'm filing this under "Personal preference", maybe some day I'll have that Aha-moment when working with script and write a post about it.
Saturday, July 19, 2014
Friday, June 13, 2014
AJAX currency converter, for funzies
Everyone loves AJAX, right?
Here's a simple, but functional, AJAX based currency converter based on the this api: https://www.mashape.com/warting/currency-converter.
You'll need to get an API key before you can use it (It's free). Here's the CFM file:
There's not a whole lot here!
We'll also need the cfc file, here it is (And don't forget to replace the YOURAPIKEY with your api key..), save it as currency.cfc in the same folder as your cfm file.
And that's it!
So what are we doing?
We're using IDs to grab the values for the amount and which currency to convert from USD into, then we send that to the convert function in the cfc, which sends the values to the api, converts the response to a struct and then returns the to_amount formatted to display up to 3 decimals.
When that's returned, we replace the text in the span ID with the new value.
Tested on OpenBD, but there's nothing fancy here at all, just some basic AJAX for those who are curious, should work on all engines (Should.. but not tested)
Here's a simple, but functional, AJAX based currency converter based on the this api: https://www.mashape.com/warting/currency-converter.
You'll need to get an API key before you can use it (It's free). Here's the CFM file:
<!DOCTYPE html>
<html>
<head>
<title>AJAX powered currency converter</title>
<cfajaxproxy cfc="currency" jsclassname="jscfc">
<script>
function convertCurrency(){
document.getElementById("final").innerHTML = "Please wait, doing magic...";
var e = document.getElementById("currency");
var selCurrency = e.options[e.selectedIndex].value;
var jscfcInst = new jscfc();
jscfcInst.setCallbackHandler( updateSpan );
jscfcInst.convert(target=selCurrency,amount=document.getElementById('amount').value);
};
function updateSpan(result) {
document.getElementById("final").innerHTML = result;
};
</script>
<style>
#leftie{
width:80px;
padding-right:40px;
display:inline-block;
text-align:right;
}
</style>
</head>
<body>
<h3>Currency converter</h3>
<div>
<span id="leftie">From:</span> USD<br />
<span id="leftie">Amount:</span> <input id="amount"><br />
<span id="leftie">To currency:</span> <select id="currency"><option value="EUR">Euro</option><option value="SEK">SEK</option></select><br />
<br />
<span id="leftie">Result:</span> <span id="final"></span><br />
<span id="leftie"><button onClick="convertCurrency();">Convert</button></span>
</div>
</body>
</html>
There's not a whole lot here!
We'll also need the cfc file, here it is (And don't forget to replace the YOURAPIKEY with your api key..), save it as currency.cfc in the same folder as your cfm file.
<cfcomponent>
<cffunction name="convert" access="remote" returntype="string">
<cfargument name="target" required="yes">
<cfargument name="amount" required="yes">
<cfhttp url="https://currencyconverter.p.mashape.com/?from_amount=#arguments.amount#&from=USD&to=#arguments.target#">
<cfhttpparam type="header" name="X-Mashape-Authorization" value="YOURAPIKEY">
</cfhttp>
<cfset var theResult = DeserializeJSON(cfhttp.filecontent)>
<cfreturn NumberFormat(theResult["to_amount"],"0.000")>
</cffunction>
</cfcomponent>
And that's it!
So what are we doing?
We're using IDs to grab the values for the amount and which currency to convert from USD into, then we send that to the convert function in the cfc, which sends the values to the api, converts the response to a struct and then returns the to_amount formatted to display up to 3 decimals.
When that's returned, we replace the text in the span ID with the new value.
Tested on OpenBD, but there's nothing fancy here at all, just some basic AJAX for those who are curious, should work on all engines (Should.. but not tested)
Friday, March 7, 2014
Respons till @Kryptoblogg
Jag vill svara på @Kryptobloggs tweet men twitter är inget bra ställe att föra dialog på (Blir en jäkla massa tweets väldigt snabbt), så jag valde att svara via min blogg istället.
Här nedan har jag klistrat in Kryptobloggs tweet för de som är intresserade av att se hela argumentet och inte bara mitt svar.
Jag håller inte med om att offensiva cybervapen skulle göra vårt samhälle svagare på något sätt.
Om jag läser dina tweets rätt verkar du anse att vi inte kan utveckla/köpa exploits därför att det skapar en kapprustning, samt att användandet av cybervapen ger motståndare vapen som kan användas mot oss, vilket inte gynnar vårt samhälle
Problemet med det argumentet är att en handfull länder redan har cyberavdelningar med offensiva förmågor som man får anta att dom skulle använda vid krigsföring, dessa länder köper/utvecklar redan offensiva förmågor, oavsett vad vi gör.
Kapprustningen har redan börjat från deras sida.
Hur lång tid brukar det ta innan en motståndare lyckats identifiera och kopiera en exploit som använts mot dom?
Det finns väl inget som säger att man inte kan använda en offensiv exploit för att sedan släppa redan gjorda patchar för sitt eget samhälle, vilket då i stor mån negerar problemet med att en motståndare skulle kunna använda samma exploit mot oss.
Det är precis som att utveckla nya bomber, man skyddar sina egna från densamma, även om man inte ställer i ordning skyddet innan det behövs, tack var risken att Den Lede Fi då lättare kan luska fram vad man pysslar med och skydda sig själv.
Men redan i fredstid kan man börja skydda sig själv, bygga kompetens, samt bygga upp en egen exploit databas genom att hitta och patcha säkerhetshål i både militära och samhällsviktiga system.
Att ha en avdelning programmerare som sitter och gör det här skulle ge en otroligt stark offensiv förmåga tack vare att de då redan HAR kompetensen, erfarenheten och verktygen som behövs för att använda samma information offensivt, som de tidigare arbetat med defensivt, samt inte minst vore det intressant att se patchar släppas i fredstid utvecklat av SVFM, vilket då skulle göra en potentiell motståndares arbete svårare och dyrare.
Vi behöver utan tvekan ett starkare arbete för att säkra vår infrastruktur mot cybervapen, det är helt otroligt att man kan ta sig in via nätet för att påverka samhällsviktiga system som visats i de senaste årens relativt små attacker.
Här nedan har jag klistrat in Kryptobloggs tweet för de som är intresserade av att se hela argumentet och inte bara mitt svar.
Jag håller inte med om att offensiva cybervapen skulle göra vårt samhälle svagare på något sätt.
Om jag läser dina tweets rätt verkar du anse att vi inte kan utveckla/köpa exploits därför att det skapar en kapprustning, samt att användandet av cybervapen ger motståndare vapen som kan användas mot oss, vilket inte gynnar vårt samhälle
Problemet med det argumentet är att en handfull länder redan har cyberavdelningar med offensiva förmågor som man får anta att dom skulle använda vid krigsföring, dessa länder köper/utvecklar redan offensiva förmågor, oavsett vad vi gör.
Kapprustningen har redan börjat från deras sida.
Hur lång tid brukar det ta innan en motståndare lyckats identifiera och kopiera en exploit som använts mot dom?
Det finns väl inget som säger att man inte kan använda en offensiv exploit för att sedan släppa redan gjorda patchar för sitt eget samhälle, vilket då i stor mån negerar problemet med att en motståndare skulle kunna använda samma exploit mot oss.
Det är precis som att utveckla nya bomber, man skyddar sina egna från densamma, även om man inte ställer i ordning skyddet innan det behövs, tack var risken att Den Lede Fi då lättare kan luska fram vad man pysslar med och skydda sig själv.
Men redan i fredstid kan man börja skydda sig själv, bygga kompetens, samt bygga upp en egen exploit databas genom att hitta och patcha säkerhetshål i både militära och samhällsviktiga system.
Att ha en avdelning programmerare som sitter och gör det här skulle ge en otroligt stark offensiv förmåga tack vare att de då redan HAR kompetensen, erfarenheten och verktygen som behövs för att använda samma information offensivt, som de tidigare arbetat med defensivt, samt inte minst vore det intressant att se patchar släppas i fredstid utvecklat av SVFM, vilket då skulle göra en potentiell motståndares arbete svårare och dyrare.
Vi behöver utan tvekan ett starkare arbete för att säkra vår infrastruktur mot cybervapen, det är helt otroligt att man kan ta sig in via nätet för att påverka samhällsviktiga system som visats i de senaste årens relativt små attacker.
Thoughts on LiveCode from RunRev
I'm a programmer, I build things, and I like to pick tools that gives me lots of power, speed of development and is fun to work with.
For the web I work with CFML using the OpenBD engine, it's fast, reliable and powerful, I use MySQL for database work for the same reasons.
For desktop I picked LiveCode.
If you have no clue what LiveCode is; It's a Crossplatform Rapid Application Development tool.
It's a graphical environment with a built-in IDE, it's the next-gen of what Delphi was and could have been.
The RAD part is seriously true, you can make things really fast with LiveCode.
But the more I work with it the more its quirks are starting to get to me though, and it's mostly small things that should not be issues!
Here's my list of petpeeves in LiveCode:
Over the day as I use it, it slows to an absolute crawl, and I have to restart it a couple of times a day to be able to continue working in it.
No hightlighting in the IDE. Seriously, none, just blocks of text, this brings me to my next point.
No way (That I know of) to use an external editor. I use Notepad++ for my web stuff, I LOVE that editor, it's as flexible as needed, does highlighting and I can make my own patterns if I want to, just being able to use that as my external editor would make my development that much fast.
The compiler can't handle \
Seriously guys, LiveCode is at version 6.x something, and your compiler still clonks out on the \ character?
I have a project that relies almost entirely on regex, which LiveCode "supports". I put support in citationmarks because.. it doesn't. The compiler has random breakdowns if you try to escape characters, which, you know, happens every once in a blue moon (All the time) in regex.
No simple "Stop" button. Loops happen, sometimes I would like to get out of that endless loop in a simple way, without having to hard-close the whole LiveCode editor, or by "inserting a break" (Which sometimes isn't possible because the *whole thing* has locked up due to a loop)
The Dictionary. The dictionary itself is an absolutely great feature, but for some reason that thing is so incredibly resource heavy or malcoded that it randomly locks up, forcing the whole editor to a grinding halt.
No built-in json handling, nope there's no built-in way to handle json. There is an excellent 3rd party library though, but even so, json is arguable pretty common (Industry standard...) and would be nice to have available by default.
The mouse scroll stops working when flipping between the various parts, but starts working if you press the Escape button once.
All of this is mostly minor, but they all add up to frustration.
That's a nice list of bad stuff, are there no good sides to this thing?
Oh yes there are.
The speed, the syntax (It's like broken English, lol), the community (I've only had a couple of bad experiences on their forums, other coders seem very willing to help most of the time)
It's an almost-mature product, I love coding in it and I'll continue to do so, but I can't rely solely on it because of the above issues, I have to use other solutions simply because LiveCode can't handle the simple stuff, like escaping characters.
I currently do not have a commercial license with LiveCode (And I haven't released any commercial software with it) but I plan to get it, simply because LiveCode IS that good, fast and fun to work with, and I think (hope) that these issues will be rectified in the future.
If it was me, I'd focus on fixing issues like these rather than put new functions on there, because I need Regex to work a whole lot more than I need a built-in json library (Especially since LiveCode claims to be fully regex compliant using the PCRE Perl regex engine)
There you have it, a 5-minute rant about LiveCode.
For the web I work with CFML using the OpenBD engine, it's fast, reliable and powerful, I use MySQL for database work for the same reasons.
For desktop I picked LiveCode.
If you have no clue what LiveCode is; It's a Crossplatform Rapid Application Development tool.
It's a graphical environment with a built-in IDE, it's the next-gen of what Delphi was and could have been.
The RAD part is seriously true, you can make things really fast with LiveCode.
But the more I work with it the more its quirks are starting to get to me though, and it's mostly small things that should not be issues!
Here's my list of petpeeves in LiveCode:
Over the day as I use it, it slows to an absolute crawl, and I have to restart it a couple of times a day to be able to continue working in it.
No hightlighting in the IDE. Seriously, none, just blocks of text, this brings me to my next point.
No way (That I know of) to use an external editor. I use Notepad++ for my web stuff, I LOVE that editor, it's as flexible as needed, does highlighting and I can make my own patterns if I want to, just being able to use that as my external editor would make my development that much fast.
The compiler can't handle \
Seriously guys, LiveCode is at version 6.x something, and your compiler still clonks out on the \ character?
I have a project that relies almost entirely on regex, which LiveCode "supports". I put support in citationmarks because.. it doesn't. The compiler has random breakdowns if you try to escape characters, which, you know, happens every once in a blue moon (All the time) in regex.
No simple "Stop" button. Loops happen, sometimes I would like to get out of that endless loop in a simple way, without having to hard-close the whole LiveCode editor, or by "inserting a break" (Which sometimes isn't possible because the *whole thing* has locked up due to a loop)
The Dictionary. The dictionary itself is an absolutely great feature, but for some reason that thing is so incredibly resource heavy or malcoded that it randomly locks up, forcing the whole editor to a grinding halt.
No built-in json handling, nope there's no built-in way to handle json. There is an excellent 3rd party library though, but even so, json is arguable pretty common (Industry standard...) and would be nice to have available by default.
The mouse scroll stops working when flipping between the various parts, but starts working if you press the Escape button once.
All of this is mostly minor, but they all add up to frustration.
That's a nice list of bad stuff, are there no good sides to this thing?
Oh yes there are.
The speed, the syntax (It's like broken English, lol), the community (I've only had a couple of bad experiences on their forums, other coders seem very willing to help most of the time)
It's an almost-mature product, I love coding in it and I'll continue to do so, but I can't rely solely on it because of the above issues, I have to use other solutions simply because LiveCode can't handle the simple stuff, like escaping characters.
I currently do not have a commercial license with LiveCode (And I haven't released any commercial software with it) but I plan to get it, simply because LiveCode IS that good, fast and fun to work with, and I think (hope) that these issues will be rectified in the future.
If it was me, I'd focus on fixing issues like these rather than put new functions on there, because I need Regex to work a whole lot more than I need a built-in json library (Especially since LiveCode claims to be fully regex compliant using the PCRE Perl regex engine)
There you have it, a 5-minute rant about LiveCode.
Subscribe to:
Posts (Atom)