James Crisp

Software dev, tech, mind hacks and the occasional personal bit

Month: August 2009

Slides & Code: Securing your MVC site against Code Injection and X-Site Scripting

Here are the slides and code from yesterday’s talk at Sydney ALT.NET.

See Steve Sanderson’s post for the code/binary for subclassed aspx compiler and more information about the automatic encoding approach we covered in the talk.

Windows / .NET Dev Tools

Recently I visited a .NET dev team to take a look at design, code and processes with a view to making recommendations to improve delivery speed. One of the more minor, but easily generalisable areas is around tooling. I often find that the little extra tools you pick up can make your work significantly more efficient. Here are a few free ones I use:

KDiff3
A brilliant merge tool that plugs nicely into TFS or SVN. SVN integration is automatic from the Kdiff3 installer. TFS integration is manual, but quite easy.

Console2
A tabbed console which works well with classic windows shell and powershell. Good support for resizing, copy paste, etc.

.NET Reflector
.NET decompiler for those dlls that don’t have source. There is also a great plugin that lets you decompile entire assemblies to files on disk.

Fiddler
When you’re debugging SOAP or RESTful web services, Fiddler is great. It lets you see the messages sent / received and even change and impersonate them.

QueryExpress
If you’ve got SQLExpress or just no tools installed, QueryExpress is a tiny (~100K) and quick query analyser style application for all breeds of MS SQLServer. Download in a few seconds, and be running queries before a minute is up.

Unlocker
Don’t you hate it when Windows gets its locks in a mess and you can’t delete/rename files? Unlocker will automatically pop up, show you which applications are holding file locks and let you release the locks.

Process Explorer
A more powerful and accurate Task Manager application which allows you to see file locks and many other types of information.

Talk: Securing your MVC site against Code Injection and X-Site Scripting

I’ll be giving a lightning talk on securing your ASP.NET MVC site against code injection and x-site scripting next Tuesday 25 August at the Sydney ALT.NET group. I’ll be demonstrating potential pitfalls and dangers of arbitary code injection, and how you can protect against it, elegantly. We’ve got 6 interesting talks lined up for the night. See you there!

The Fallacy “Best of Breed” in Layered Solutions

Imagine you are designing a layered solution where data enters in a GUI, and passes through several layers for transformation and processing before being written to a database. Everyone knows that layering is a good way to do decomposition, right? It means you can work on each layer separately, without affecting any other layer? It means we can even hand off each layer to a separate person/group/company and different hardware to handle? This is all looking so good, now we can choose a “best of breed” solution for each layer. If each layer chooses the technology and implementation group that is the very best for that sort of work, it must lead to the very best solution overall, right?

Well, data needs to flow through all of the layers in this sort of design. Lets take an imaginary example. Say one layer in the middle has a data field length limit of 255 characters. This means that every layer is then limited to this data length, otherwise the data will be truncated or rejected on the way to/from storage. Instead of getting the advantages of each layer’s solution, you end up being limited to the lowest common denominator of all the layers.

A further problem is staffing and team structure. If each layer has chosen a very different “best of breed” technology, it will be difficult to find one team/company/group that can handle all of the layers (eg, Java front end, BizTalk middleware, Mainframe backend) and do vertical slices of functionality. Of course, you need the “best of breed” for the staffing! Hence, implementation is often split between different teams/companies (horizontal slicing of teams), each of which is known for skills in a particular layer. Although each team may be “best of breed”, we end up with the lowest common denominator again. Methodologies are likely to differ between teams (eg, waterfall vs agile) so the communication and planning is limited to the area of overlap between methodologies. The same applies for project goals. For example, one team may focus on user experience and another may focus on building an enterprise wide data model. It is only where/when these goals intersect that the project can progress efficiently.

What can we do to defuse this sort of architectural design in its infancy? Questions to ask:

  • How many times is the same data transformed, and does each transformation add value?
  • Can multiple layers be hosted in the same process rather than split between different machines/processes?
  • Integration is always time consuming. Do the “best of breed” advantages of a solution for a particular layer outweigh the cost of cross process or cross technology integration?
  • Can one co-located, multi-disciplinary team be formed to build the solution?
  • By comparison, how many people would be required, and how long would it take to build the application with the simplest architecture that could possibly work?

 

“Ruby for Rails” by David Black

Ruby For RailsRuby for Rails by David Black is a fun read that takes concentration but repays it with little epiphanies that explain syntax and language features that you had previously taken for granted.

The book aims to “help Rails developers achieve Ruby mastery”. The coverage of Ruby features is not complete and there are some concepts missed that I would have liked to have read more about (eg, how do instance variables work under the hood?). There are also a number of introductory chapters on Ruby and Rails and some chapters devoted to a sample Rails project (R4RMusic) which I flicked through but didn’t add much value for me (they are also a little dated). By far, the most interesting parts of the book for me were on the Ruby type system, ‘self’ in various situations and how method look up works with modules and inheritance.

An area of Ruby that I had not previously explored was adding singleton methods to instances (like what you can do in Javascript). Eg,

o = Object.new
def o.say_hi
  p "hi"
end

>> o.say_hi
"hi"

or alternatively

o = Object.new
class << o
  def say_hi
    p "hi"
  end
end

Now, the interesting thing is that this is the basis for the whole class system in Ruby!

Classes are just a special type of object, and when you add class methods, you are really adding singleton instance methods to the class object for the type.

Ie, when you do something like:

class Cars
  def self.find_all
    ...
  end

You are actually creating a new object, of type Class which has a singleton method called 'find_all'. 'self' in the code above is the Class object, so def self.xxx is adding a singleton method to it.

This also explains the alternative syntax for adding class methods:

class Cars
  class << self
    def find_all 
      ... 
    end
  end

The same thing could be done by saying:

Cars = Class.new
Cars.instance_eval { def find_all; ... end; }

In Ruby, the type and class system is not very different from the normal objects you work with every day. I find this really quite cute and internally consistent.

The way the method search path works in ruby was also nicely explained in the book. Basically, finding a method starts at the top of the list below and stops as soon as a method with a matching name is found (ie, that responds to the message sent to the object):

  • Singleton methods on the object
  • Methods defined by the object's class
  • Methods defined by modules mixed in to the class
  • Methods defined by parent class
  • Methods defined by modules mixed into parent class
  • Repeat checking parents until get to Object
  • Methods defined on Object
  • Methods defined on Kernel (module mixed into Object)

This also explains why you can always call methods like 'p' from anywhere. They are coming from Kernel which is mixed in at the top of the inheritance tree for your object. Another case of internal consistency - there's no 'special' mechanism for these seeming globals.

Overall, I enjoyed the book and would recommend anyone having a read who has worked with Ruby and Rails but would like to dig a bit deeper.

Mephisto Contact Form Plugin Moved to GitHub

Sorry the the confusion, anyone who has been checking out the the Mephisto Contact Form Plugin from the old SVN repository. The latest version with an update for Rails 2.3 is at:

http://github.com/jcrisp/mephisto_contact_form/tree/master

“Now, Discover your Strengths” and “Strengthfinder”

A while back I bought a copy of Now, Discover your Strengths by Marcus Buckingham and Donald Clifton, and have only just got around to reading it. The book comes with a single-use code that lets you take an online personality test with 180 questions, with the aim of determining your 5 core strengths. The test takes about half an hour and is not onerous.

The book outlines one main idea. Find your natural talents and capitalize on these, building them up into strengths. Shape your work and life in ways that use your natural talents, as this will make you more effective, productive and happy. Although anyone can learn anything, people with a natural talent in an area are going to be able to reach a higher level of capability and success. Mitigate your weaknesses by partnering with people who have complementary strengths, developing a support system to help you, improving your skills in the area just enough to stop them from detracting from your strengths or simply stop doing things that play to your weaknesses.

The core concept of playing to your strengths is covered from many angles in the book and with supporting stories of successful people like Bill Gates and Warren Buffett. There is then a detailed description of each of the strengths that the online personality test can highlight. The last part of the book is interesting and focuses on building organisations which play to people’s strengths, management of people with different strengths and some thoughts on the staff review process in organisations.

Overall, the book was a very quick read with low information density. The online test was fun. You can see my results below. I don’t think it told me anything too new – I already know that I’m pretty analytical, like to learn, focus strongly on achieving tasks etc. The core idea about playing to and building your strengths does seem a good one from the personal satisfaction and cost/benefit point of view (assuming society values the areas you have talents in, and your areas of weakness don’t get in the way too often).


Please note that the following text is Copyright 2000 The Gallup Organization.

Analytical
Your Analytical theme challenges other people: “Prove it. Show me why what you are claiming is true.” In the face of this kind of questioning some will find that their brilliant theories wither and die. For you, this is precisely the point. You do not necessarily want to destroy other people’s ideas, but you do insist that their theories be sound. You see yourself as objective and dispassionate. You like data because they are value free. They have no agenda. Armed with these data, you search for patterns and connections. You want to understand how certain patterns affect one another. How do they combine? What is their outcome? Does this outcome fit with the theory being offered or the situation being confronted? These are your questions. You peel the layers back until, gradually, the root cause or causes are revealed. Others see you as logical and rigorous. Over time they will come to you in order to expose someone’s “wishful thinking” or “clumsy thinking” to your refining mind. It is hoped that your analysis is never delivered too harshly. Otherwise, others may avoid you when that “wishful thinking” is their own.
Learner

You love to learn. The subject matter that interests you most will be determined by your other themes and experiences, but whatever the subject, you will always be drawn to the process of learning. The process, more than the content or the result, is especially exciting for you. You are energized by the steady and deliberate journey from ignorance to competence. The thrill of the first few facts, the early efforts to recite or practice what you have learned, the growing confidence of a skill mastered—this is the process that entices you. Your excitement leads you to engage in adult learning experiences—yoga or piano lessons or graduate classes. It enables you to thrive in dynamic work environments where you are asked to take on short project assignments and are expected to learn a lot about the new subject matter in a short period of time and then move on to the next one. This Learner theme does not necessarily mean that you seek to become the subject matter expert, or that you are striving for the respect that accompanies a professional or academic credential. The outcome of the learning is less significant than the “getting there.”

Command
Command leads you to take charge. Unlike some people, you feel no discomfort with imposing your views on others. On the contrary, once your opinion is formed, you need to share it with others. Once your goal is set, you feel restless until you have aligned others with you. You are not frightened by confrontation; rather, you know that confrontation is the first step toward resolution. Whereas others may avoid facing up to life’s unpleasantness, you feel compelled to present the facts or the truth, no matter how unpleasant it may be. You need things to be clear between people and challenge them to be clear-eyed and honest. You push them to take risks. You may even intimidate them. And while some may resent this, labeling you opinionated, they often willingly hand you the reins. People are drawn toward those who take a stance and ask them to move in a certain direction. Therefore, people will be drawn to you. You have presence. You have Command.

Focus
“Where am I headed?” you ask yourself. You ask this question every day. Guided by this theme of Focus, you need a clear destination. Lacking one, your life and your work can quickly become frustrating. And so each year, each month, and even each week you set goals. These goals then serve as your compass, helping you determine priorities and make the necessary corrections to get back on course. Your Focus is powerful because it forces you to filter; you instinctively evaluate whether or not a particular action will help you move toward your goal. Those that don’t are ignored. In the end, then, your Focus forces you to be efficient. Naturally, the flip side of this is that it causes you to become impatient with delays, obstacles, and even tangents, no matter how intriguing they appear to be. This makes you an extremely valuable team member. When others start to wander down other avenues, you bring them back to the main road. Your Focus reminds everyone that if something is not helping you move toward your destination, then it is not important. And if it is not important, then it is not worth your time. You keep everyone on point.

Input
You are inquisitive. You collect things. You might collect information—words, facts, books, and quotations—or you might collect tangible objects such as butterflies, baseball cards, porcelain dolls, or sepia photographs. Whatever you collect, you collect it because it interests you. And yours is the kind of mind that finds so many things interesting. The world is exciting precisely because of its infinite variety and complexity. If you read a great deal, it is not necessarily to refine your theories but, rather, to add more information to your archives. If you like to travel, it is because each new location offers novel artifacts and facts. These can be acquired and then stored away. Why are they worth storing? At the time of storing it is often hard to say exactly when or why you might need them, but who knows when they might become useful? With all those possible uses in mind, you really don’t feel comfortable throwing anything away. So you keep acquiring and compiling and filing stuff away. It’s interesting. It keeps your mind fresh. And perhaps one day some of it will prove valuable.

Spying on Instance Variables in Ruby

A little while back, a few colleagues and I were spiking a proxy concept based on extending an existing web server. We wanted to check out an instance variable (eg, @very_secret) in a framework object which did not have an accessor. In the past, we’d used send (eg, secretive_object.send :hello_private) to get at privates, but send is only for methods. We were just digging around doing some debugging, so we opened the relevant class and added a public accessor for the instance variable to see what was happening. However, we thought there must be a more elegant way to do access instance variables outside the class, and one has just come to mind (at last!):

secretive_object.instance_eval { @very_secret }

instance_eval lets us run the code block in the context of secretive_object. Ie, self == secretive_object, so we can get at all the hidden stuff.

It’s a rather different approach to other languages like C# and Java where accessing private variables and private methods are part of a reflection/introspection API.

“Learned Optimism” by Martin Seligman

Learned Optimism: How to Change Your Mind and Your Life is an interesting mix of a psychological treatise and a self-help book. Unlike many self-help books, this book is written by somebody with clear qualifications in the area. The author, Martin Seligman, is a professor of psychology at the University of Pennsylvania and a past president of the American Psychological Association. The concepts in the book were derived from well-designed studies of people and animals and were written up in reputable journals including Science.

The first part of the book focuses on the recent history of psychology and explains Seligman’s research into learned helplessness and his later shift into researching optimism. He describes multiple studies performed and the results, and how they were disputed by proponents of other theories. The most memorable study he describes was designed to show learned helplessness using dogs. The experiment used three dogs. The first was placed in a box that continued to give the dog electric shocks until it pressed a bar. The second dog was placed in a box that continued to give it electric shocks until the first dog pressed the bar in the other box. The third dog sat in a box with no electric shocks. In the final stage of the experiment, all three dogs were placed in boxes which gave electric shocks until the dogs jumped over to the other side of a partition. Across a large number of repetitions, the common behaviour was that the first dog quickly jumped over the partition and escaped the shock. The second dog (with learned helplessness) just lay on the bottom of the box being shocked. The third dog (the control) jumped over the partition and escaped as well. Similar experiments were performed with people and annoying sounds with similar results. Seligman also found that a small proportion of people and dogs did not give up and seemed immune to learned hopelessness. This later became the focus of his research into optimism.

An interesting observation made in the book is that previously, people used to have faith and trust in their community, church, country and government and this provided support in times of personal failure. However, in recent times, these supports are no longer present or as strong for many people. With rising work hours etc, community and neighbours are much less important than they were previously. Religion has declined and many people do not go to church in the western world. Governments have been caught out in lies and corruption (eg, Nixon, Howard). Faith in country has been eroded by globalisation and wars like Vietnam and Iraq. Simultaneously, marketing and consumer culture has focussed on elevating the importance of the self, personal choice and success. In this environment, where self is all important, and the supports of previous generations no longer apply, personal failure is far more debilitating and depressing than it has ever been before.

Later in the book, Seligman explains that everyone, when they have a set back or failure, are stopped in their tracks at least briefly. However, optimists recover faster and are able to act again sooner due to the way they explain the failure to themselves. When something bad happens to an optimist, they expect that the bad thing will be short lived (temporary), was caused by someone else (external) and only affects a partial area of their life (specific). Pessimists are the opposite. They expect bad things to go on for ever (permanent), were caused by them (personal) and will affect their whole life (pervasive). The opposite applies for each cognitive style as well – optimists see good things as permanent, personal and pervasive. Pessimists see good things as temporary, external and specific. Seligman also mentions that turning a thought over and over in one’s mind (rumination), with a pessimistic explanatory style leads to a magnification of the negative impact of the thought (often a factor in depression).

There are also a number of psychological tests in the book that aim to measure optimism. Variations on these were used successfully for selection of sales people who had to make cold calls at a large insurance company (MET Life). A high level of optimism meant that the sales people were able to keep on going despite multiple rejections.

In the last section of the book, Seligman talks about ways to dispute one’s internal dialogue and explain the set backs in life in less self-damaging ways (ie, temporary, external and specific). He suggests that your internal voice should not necessarily be given any more credence than an external voice as it can often be biased. He recommends disputing internal dialog with evidence, offering alternate explanations and analysing the implications. His other suggestion is to postpone thinking about the problem by distraction or writing it down and setting a time to think on it further.

Seligman finishes by discussing when optimism or pessimism is most appropriate. His theory is that optimism is generally a beneficial outlook as it allows one to be proactive and productive in the face of failure, to lead and to inspire and encourage others. However, his studies showed that mild pessimists had a more realistic world view than optimists. Hence in life critical situations, certain types of advisory and assurance roles, mild pessimism and the resulting realism was a better mindset to employ.

Overall, there are a lot of interesting ideas in the book. After reading it, I now think a lot more about my internal dialogue and pay more attention to the way I explain good and bad events to myself. I did find that the last part of the book about “Changing from Pessimism to Optimism” was a bit repetitive as it covers the same ground multiple times with emphasis on different areas such as relationships, work and teaching children. Although I found the historical information and descriptions of studies well written, convincing and interesting, I would have preferred a few less in the interests of concision. These small complaints aside, I would highly recommend reading this book, especially if you find yourself ruminating often on the difficulties in your life rather than enjoying the good parts and taking action.

Review: “Deploying Rails Applications” by Ezra Zygmuntowicz et al.

Deploying Rails Applications: A Step-by-Step Guide by Ezra Zygmuntowicz, Bruce Tate and Clinton Begin is a good read, if a little dated. It was published in May 2008, and you can see that things have moved on a little in the Rails world since then. None the less, quite a lot of the information is still relevant and useful.

The book covers some basic Rails and version control concerns at the start, then rapidly launches into chapters devoted to Rails hosting options available from shared hosts to virtual and dedicated servers. The advice given is good and is in line with my experiences. Unix configuration is given in depth which would be very handy if you had not set up a server before. Next is a good discussion of Capistrano and automating deployments. The examples all use subversion. However, these days I expect the majority of Rails source code is pulled with Git. There is also a chapter on managing mongrels and setting up monitoring solutions. This is still relevant if you want to use mongrels, however these days Passenger is probably the best choice, and it does not have such complex management and configuration requirements. The scaling out chapter is useful and pulls together handy information including details on MySql replication/clustering. There’s a chapter on deploying on Windows and also some suggestions around performance and profiling.

I haven’t come across another book that brings together a structured collection of useful information to help you move from running rails locally to having a cluster of scalable production servers and the automated deployment process required to support it. Despite being too old to cover Git and Passenger, I’d still recommend having a read of this book if you’re at the stage of planning to launch a Rails site or looking to scale your VPS up to a cluster.

Powered by WordPress & Theme by Anders Norén