Sublimecoding

Pushing the boundaries of the webbernets.

Adobe ColdFusion Summit 2014 Afterthoughts

Another year comes to a close and Adobe’s second annual ColdFusion Summit has come and gone. The conference was good, but not quite as good as it was last year. The venue was definitively nicer, however, the talks were not all gems.

I understand it can be challenging to put together a presentation, and give that presentation in front of 50-100 of your peers. My hat is off to anyone who gives a talk at a conference or a meet-up. I do think you owe it to the crowd and the conference to try and make that talk the as interesting and entertaining as it can be.

So what makes a great talk? First of all try to tell a story, your talk should be polished and should tell the story of your idea or principal. This doesn’t mean you need to talk about slaying dragons or anything of that sort, but it does mean you are responsible for holding the audiences attention and keeping them engaged. Admittedly some of this stuff is just plain boring, but that is more of a reason that you need to convey excitement and passion to the crowd.

Explaining a concept is not quite as fun to listen to as something that feels interactive. Asking question to the crowd, and pausing a few seconds, only to give them the answer keeps their brains working and engaging with you. Adding your own flare to the presentation, such as funny gifs or cartoons can really bring a presentation to life. Something as simple as talking about code review and displaying the cartoon about code quality being measure in WTFs per minute. It keeps the crowd entertained and the endorphins rush of fun there.

Just remember you are responsible! So in the end there were a few gems that did stand out to me and they produced phenomenal presentations. They managed to engage with the crowd and delight the audience.

That being said I really cannot thank these people enough, the ones that really stood out in my mind were as follows.

Kev McCabe

Kev McCabe gave two wonderful presentations of software craftsmanship and TDD/BDD. He did a wonderful job of illustrating these concepts and bringing them to the ColdFusion community. Unfortunately these concepts are not as big of a part of the core fundamentals as they are in many other languages. Ruby being one of the biggest proponents of these concepts, and Java as well.

You have find both of his presentations on his website at bigmadkev.com/resources

Dan Wilson

Dan Wilson did a wonderful job of illustrating how to make your architecture scale. Pointing out some of the most obvious concerns and showing how those concerns could be addressed.

Unfortunately I do not have a copy of the slide or a link to this content. I will say if you have the chance to see him speak you wont regret it.

David Epler

Finally David Epler set the bar very high indeed, he was the first speaker I saw at CFSummit. His talk on security was top notch! He did a great job of holding the crowd and demonstrating some of the power that can be wielded by hackers both white hat and black hat a like. It was astonishing. His presentation allowed us to see just how quickly we could be hacked and how quickly that attacker could have access to almost all of our information, both scary and very captivating.

Ruby vs ColdFusion: Why I Chose to Switch

I get asked quite frequently “What made you switch from ColdFusion to Ruby?”. The truth is, ColdFusion is kind of a dead end. I’m not saying its a dying language, in fact far from it. The language is used by many large companies and its growing according to adobe. The truth is there are good things and bad things, however after using the language for a few years I realized the bad out numbered the good.

Server Efficiency

So lets start with the good things. ColdFusion is a JVM language and utilized the maturity and power of Java and this makes ColdFusion a very robust a powerful server side language. Well, atleast from the stand point of concurrency and memory usage. The language does very well for scalling and utilizing resources efficiently. In this regard ColdFusion is the winner over Ruby, MRI is not very memory efficient, and requires some tricks to establish concurrency and avoid the GIL. However, as far as a language goes efficiency is not the most important factor. Servers are cheap and programmer time is not. Respecitively you can get a 64gb RAM 16 core server for less than the average salary of the average software engineer.

Rapid Application Development

So if servers are cheap and programming time is not, then that brings me to the next point. Application time to market. Simply put ColdFusion was billed as being the RAD (Rapid Application Development) language. This may have been true at one point and may have warranted the 8,000 price tag of enterprise ColdFusion, but in recent years ColdFusion simply falls behind other languages. Ruby is the clear winner in this regard and allows or quicker time to market. This is a huge benefit to a language and explains the large number of startups choosing Ruby over other lanugages.

Package Management

Ruby has gems, this is awesome especially during initial application development when its crucial to get a product out instead of worrying about how to paginate, or how to handle parsing a CSV, or handling file uploads. Gems allow us to expedite our time to market. This is one area where Ruby is the clear winner.

ColdFusion still does not have an official package management system. Recently the community and more specifically Ortus Solutions wrote a package manager for ColdFusion. Unfortunately this is a bit late and should not have been the responsibility of the community of a very expensive language. If you are paying premium prices for a product it should be better than good and not be available for free on the street corner.

Price

It’s really hard to beat free and open source. Ruby is the clear winner here.

ColdFusion is expensive and can costs thousands of dollars. To get the full featured version of ColdFusion you can easily spend 5000+. For this price tag I feel like you should be getting a ferrari and recently it feels like you get a VW bug with some heavy milleage on it. There are some CFML variant available for free, and these tend to be better options than the Adobe flavor.

Developer Happiness

This one is a little loaded in Ruby’s favor, since ColdFusion never makes this claim but Matz does make this claim about Ruby. It may not be fair but I am happy when I work with Ruby, and ColdFusion not so much. That one is a little subjective and up for debate, but I support Matz’s claim, and Ruby is one of the more fun languages to work in.

Community

The Ruby community is one of the most vibrant and diverse communities on the internet. It’s wonderful and inviting and follows MINASWAN (Matz is nice and so we are nice). This lend to the community being very friendly and very helpful. I rarely see flame wars happening or name calling in this community. In addition the Ruby community is big on ensure best practices are followed by the community, TDD, SOLID, OO Design, all are part of the communities core values. These things alone are a huge value to the overall community, and new people starting get exposed to this.

The ColdFusion community is very small and not especially active. I think this is one of the bigger draw backs to the ColFusion language. The community is everything. If the community is small and not very active then this does not lend to people learning quickly and causes open source with in that community being almost non-existant. This is not to say there aren’t open source CFML projects, they are usually just fewer and farther between. Additionally the community for ColdFusion does not provide positive pressure on people comming into the community to follow best practices, and its is not as easy to setup TDD, or follow OO priciples. Which brings down the community as a whole.

Conclusion

ColdFusion isn’t exactly a bad language but it does have some major flaws and issues that cannot be ignored. It makes it easy for people to avoid best practices and in doing so brings down the bar for the language. These are just some of the reasons I chose to make the switch to Ruby development. I’m happy I made the switch. I still do some work with ColdFusion, but given my prefernce I would much rather work in Ruby.

I choose a language that makes it easier for me to be a better developer. I choose a language that has a community that surrounds it and forces me to develope at a high level. These are the reasons I choose to use Ruby and embrace it.

Scrypt Gem Native Extension Build Errors

Gem installation errors can be very frustrating for Ruby beginners and advanced users alike.

Recently I encountered a gem installation error on OSX Mavericks with a fresh install and brand new macbook pro.

1
ERROR: Failed to build gem native extension.

I recieve this error during a bundle install of a rather large project. The gem in question was scrypt. Some people may recognize that gem as being an alternative gem for encryption of data. The usual gem used for this is bcrypt, but some project choose to go with the more secure but less often used scrypt.

The C libs that are used for this particular gem need gcc 4.2 to be install on your system and aliased to CC. Unfortunately on brand new macbook pros you will not have this particlar version of the gcc compiler installed. To resolve this issue you will need to install and alias the correct version of the gcc compiler. My recommended method for this is using homebrew to install gcc 4.2

1
2
brew tap homebrew/dupes
brew install apple-gcc42

The above commands will add the homebrew tap which contains the forumula for apple-gcc42

Once you add this tap and install the gcc42 compiler you can follow up with exporting CC to equal gcc-4.2 and installing the gem that experiencing the extension build error, in this case its scrypt.

1
2
export CC=gcc-4.2
gem install scrypt

The gem should install properly and clear up that nasty extension build error.

Debugging: An Exercise in Thinking

One of the most important skills to learn as a programmer is how to debug an issue. More often then not your day will be spent debugging issues from small syntax errors you wrote while typing too quickly, to larger errors that do not fail critically and actully preform a task, they just preform that task wrong. In fact the bugs that you will spend the most time on only fail once in a while, or you may encounter a “heizenbug” which seem to change state just by looking at it. The bug doesn’t actually change state it’s just a way of saying simply looking at it will not reveal the issue.

No matter the kind of bug you encounter you will need to solve it somehow. Since the amount of times you can claim a bug is a feature is very low and only once in a great while does a bug fail in a serendipitous and fortuitous way.

So how do we track down bugs? How to you improve this skill? Simple! We find bugs, track them down, and fix them. The only way to get better at it is to practice. That being said I do have a particular methodology when tracking down a bug. I follow these simple steps.

  1. In what way is this failing?
  2. How do I expect this to respond when working correctly?
  3. What is the simplest solution to get us from A to B and produce the fix?
  4. Start Tracking.
  5. Find the most likely point of failure, start there.
  6. Keep tracking until you get no feed back
  7. Once you get no feed back, start to pull the code apart

Steps 1 through 3 can be asked very quickly and you usually have an answer long before you start looking at this bug. In most cases this gets passed down from a product manager or a customer support who submitted the ticket. In the case of you finding the bug before anyone sees it those are useful questions to ask, but I think those are pretty self explanatory. Which brings us to tracking.

How do we get started? Where do we start tracking?

We start with the user interface by replicating the bug as the user would see it. Now this can be done via TDD and writting a series of tests to replicate the issue, or it can be done by simply loading up a browser and clicking on things. I recommend the former of those two.

Using Tests to drive your debugging is a great way to duplicate the error effectively and ensure you know when you fix it. Once you have an appropriately crafted bug test you can run it and repeatedly duplicate the error. It will save you the time of flipping between you code the browser window.

So We start with the user interface and dig our way deeper. This will most often tell us which controller which action or which file we should be looking in. Once we know where we need to look we start to dig into why its failing. We can start to push and pull on things. This is where you ask yourself “what is the most likely point of failure?”. If this is not obvious we need to start we start to pull the code apart by inserting aborts and raise errors checking to make sure we are getting the results we hope for. This should show us which logic gates are working and which ones are being passed over. Allowing us to eliminate chunks of code that are not executing during the failure and rule them out as possible oppotunities for fixes.

We keep moving the aborts or raises into different chunks of code and we dump our variables looking for the ones that have incorrect data or given X and we expect Z somewhere along the way it gets turned into Y and that causes the failure we have. Once we find the source of the issue we can then start to work our way through making a fix.

Do we patch it and just manipulate the data in a way to make it not fail? or do we keep tracking it to the root of the cause and fix it at its root?

For instance we expect to get the statment “The quick brown fox jumps over the fence”. Instead we get “The quick black fox jumps over the barn”.

1
2
3
4
5
6
str = "The quick black fox jumps over the barn"

final_str = manipulate_data str

puts final_str
# The quick black fox jumps over the barn

Given this example one fix might be to replace the values in final_str before it gets output. This might work but in most cases it would be a fix for this one case and would not respond well given a different input. Instead we need to look at the manipulate_data function which is the real cause of the issue.

1
2
3
4
5
6
7
8
9
10
def manipulate_data string
  string
end

str = "The quick black fox jumps over the barn"

final_str = manipulate_data str

puts final_str
# The quick black fox jumps over the barn

Turns out the manipulate_data function didn’t do anything except return the string every time. In which case the correct course is to not just replace the values before being output. The correct course is to alter the manipulate_data function to preform its intended job or remove it entirely since its vestigial.

In the above example The real issue is two things, a useless function as well as a misassignment of the str variable.

The above example is an over simplification but this is in general how bugs can be created. You may not see the definition for a function so it may not be apparent why the fucntion is failing, but once you find the function definition it becomes more apparent why its not preforming as you expect.

I showed you this example so you do not get in the habbit of fixing the symptoms and not the root cause of the issue. If I had implemented a string substitution fix then I would only be fixing the code for this one issue and it wouldn’t work for any other case. Fixing the symptoms this time and passing the issue to the next engineer, or bandaiding it until I am force to come back to it. This is a recipe for bad code and a non-flexible architecture.

In most cases the best course is to keep tracking the error and possible causes back into the layers of functions and fix the root cause. If you follow the steps above you should be able to track most errors back through your code and most code bases until you reach the root.

Happy Hacking and I hope this gave you some insight.

Protect Your Server Againt the Shellshock Bug

Step 1: Check Your System for the Vulnerability

On each of your systems that run Bash, you may check for Shellshock vulnerability by running the following command at the bash prompt:

1
$ env VAR='() { :;}; echo Your bash is vulnerable!' bash -c "echo Bash Tested"

If your bash is vulnerable you will see “Your bash is Vulnerable” followed by the “Bash Tested” line.

If the test is positive this is a very large concern. Suffice to say there are hundread of ways for an attacker to manipulate this particular flaw, however one of the most concerning is the web server header attack. Simply modifying the headers that someone uses to GET or POST to you server they could be running code on your server. This makes hearbleed look like a minor concern.

If you have the vulnerability you need to patch it as soon as possible.

This is not as big a concern for personal computers, since you do not run a internet accessible web server. This does not mean you should let it go unpatched, but you can wait for your operating system to release the official patch.

Step 2: Patch Your System and Retest the Vulnerability

Once you get a positive result. You will need to resolve the issue, you can do this in one of two ways.

You can use the package manager that came with your OS such as yum or apt-get.

Simply run these commands:

for Ubuntu or Debian:

1
$ sudo apt-get upgrade bash

or for centos, redhat, or Amazon Linux:

1
$ sudo yum update bash

or if those do not work you can always install and upgrade from source.

The commands to compile and replace your copy of bash follow. These are confirmed on a Linux Ubuntu system with build-essential meta package installed. It may vary on other OSs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
$ cd; mkdir src; cd src

$ wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz

# download all patches

$ for i in $(seq -f "%03g" 0 26); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done

$ tar zxvf bash-4.3.tar.gz

$ cd bash-4.3

# apply all patches

$ for i in $(seq -f "%03g" 0 26);do patch -p0 < ../bash43-$i; done

# build and install

$ ./configure --prefix=/ && make

# if you see no errors, continue

$ sudo make install

$ ls -l $(which bash) # should show a file with current date

# Rerun the test; if it passes, you can remove the source

$ cd ~; rm -r src

Once patched you will need to test again to make sure it resolved the issue.

1
$ env VAR='() { :;}; echo Your bash is vulnerable!' bash -c "echo Bash Tested"

you should only see “Bash Tested” output in the terminal window.

Happy patching!