EU cookie law: in video

A while back I pointed out that a new law about cookies was coming out. Well, that passed into law in the UK on 26th May 2011.

It is now illegal to have cookies on your website without explicitly asking for permission.

That includes your google analytics tracking tags!

Luckily, they've realised what a pain it is to update your website, and have told everybody that they will not actually prosecute anybody with this law for a year... as long as they are actually doing *something* about the issue.

It also makes sense to start thinking about now, if only to make sure we're not all madly stuck trying to rectify the problem at midnight May 25th next year.

Of course the problem is that there is still no consensus on what we actually need to *do* to meet compliance. The ICO's guidance on the topic still being woefully inadequate.

There's more from the Guardian on the cookie law shambles.

and here's a great YouTube video that briefly describes the whole issue.

What the hell is happening with Rails?

A whole slew of controversy has been stirred up with the post: What the hell is happening to rails - which managed to top the hackernews charts for quite a while last week.

It basically gave vent to a lot of concern in the rails community that rails is becoming too difficult to learn, and that may be scaring off newbies.

The new rails has certainly been in a great state of flux - and pushes the whole framework in a new direction. Whether or not you like that direction is one thing - but the fact that it is such a big change makes it difficult to know where to start if you're coming into the community for the first time.

I recently had an eye-opening experience at a hack-day where I suggested rails as a platform-of-choice for us to use... then spent the entire day helping one guy just get a basic rails stack up and running on his laptop, and then I still had to explain how to actually use it.. This isn't as easy a I remember when I first began.

One of the big benefits of original plain-ole-C was that anybody could learn the entirety of the language and keep it in their head all at one time. Contrast that with any of the big enterprise languages, which require a long ramp-up time even just to learn everything that is available in the basic suites. Not that having less is better - but it does make the early-learning stages much quicker... so I can see the point being made here.

In any case - I think the gist of the post/discussion is worry over the potential dilution of the framework. If we want to be all things to all people - it means a lot of work to genericise the platform, and that means big changes.

On one hand, I can see why it's being done. There are good reasons for all of the alternatives to the core-defaults... and being able to support them therefore opens up our audience to a greater market. But I can also see the point that it makes Rails *feel* a lot more bloaty than before... even if it isn't actually degrading performance, and it gives newbies so much more to learn just to get out the starting gates.

In any case - Yehuda Katz has now done a follow-up post explaining just What’s Up With All These Changes in Rails? - and it's worth a read to see why they've made some of their recent decisions.

and I plan to watch the continuing discussion closely...

Goal-oriented vs process-oriented motivation

There are heaps of processes that I enjoy far more than the actual end-result.

Crochet is my example.

I'm quite happy to continue crocheting something pretty (it has to be pretty - I don't enjoy crocheting abominations) for a long time and never "owning a crocheted thing" at the end.

Before I hit upon the solution, I spent a long time starting projects - some of which I finished, but lots I didn't... because I didn't care about finishing - just about doing. Of course, couple this with an aversion to destroying something I've already made (which might have solved the problem by turning it into a sisyphean task). and I got a lot of "why don't you ever finish anything?" from my mother.

The question usually comes as "why don't you ever finish anything, don't you want the [crocheted thing] you set out to create?" - and the honest answer is "no".... but if you say that - they ask "well why did you start making it in the first place?"

Most people don't seem to understand enjoying the process - at least not on a gut level...

I actually solved this particular dilemma by giving away my crocheted things to my grandma - who likes owning crocheted doilies et al. Works for embroidery projects too.

Unfortunately, I still tend to get lack of understanding from other people: "but why don't you ever make something for yourself?" I find it *very* hard to explain to goal-oriented people why I don't like crochet... I like crocheting.

I would definitely consider myself to be more process-oriented than goal-oriented. I like doing stuff... I like crocheting, not the goal of having crocheted something in particular. Especially, I like learning - not the feat of "having learned something".

So for me - it's very difficult to go to those "attain your goals" seminars etc - because I don't have set goals. I can't point at something and say I want to have achieved precisely that thing, because for me, the thing itself doesn't matter.

It can be frustrating, because I certainly do want to improve over time. I crochet better and more complicated things, I study more challenging topics that build on past learning that I enjoyed. but I can't necessarily quantify that I want to "learn X".

Because there is no X... or at least no specific X.

and then people tell me I'm drifting and that I'll "never accomplish anything"... but accomplishing specific things for me isn't the point. I enjoy the act, not necessarily the achievement.

Of course, over time, I *do* accomplish things - because if you continue to, say, crochet over a long period of time, eventually you will have piled up a very large back catalogue of doilies... and the same goes for learning or whatever other process you enjoy. Which I can then, of course, show to my mother...

who then invariably says "but why don't you finish the ones that are still in your cupboard?"

*sigh*

Project Euler

I've found a fun new site. Project Euler is a huge set of math+programming puzzles of increasing difficulty, starting out pretty easy (solved by tens of thousands of participants) and going up to puzzles that haven't been solved yet.

They're quite fun. Each one touches some aspect of mathematics, and requires some programming smarts to get it working. But don't worry if you're not cluey on maths. They start out fairly simple, and you can google for information about the math behind the puzzles if you need more.

Each puzzle has a specific, numerical answer. You submit the answer to prove you've solved the puzzle, and the site keeps track of how many you've done. It also gives you access to a forum for each puzzle - where others share their code or insights into how to make the program more efficient. Most puzzles also come with a short pdf to explain the maths behind it - generally showing you how to analyse the problem or prove the formulae behind the most efficient algorithm.

Each puzzle has been constructed so that the correct program/solution is expected to run in under a minute... and for many of the puzzles - that means you'll have to rethink how your program works to get in under that time.

Anyway, I think it's an interesting challenge to play with. Here's my score so far:

ruby encapsulation is for $%*t

Wow, I just learned that ruby encapsulation can be broken by simply using:

   my_object.send(:my_secret_private_method)

That's kinda useful to know if you're trying to unit test a private method, but makes the concept of encapsulation totally meaningless in ruby.

Apparently, Ruby 1.9 revokes this "special" privilege, but then there are still many ways to use the power of ruby meta-programming to get to them anyway (see above link for some examples).

Autologin to rubyCAS after create user

From restful_authentication I first got the idea that when a user signs up they can also be automatically logged-in. This as opposed to having them register - then sending them to the login page where they have to re-enter the details they just typed into the registration-form.

Unless you have some kind of click-on-the-email-activation-code-before-logging-in requirement, you shouldn't force your user to go through this dance. It's a tiny nice-to-have that (if all goes well) ends up with a more seamless experience for the user - all win.

If one of your rails apps also deals with signing up your new users - you should be able to mirror this autologin functionality to smoothly get them started straight after registration.

At first glance, it looked like rubyCAS didn't support this - or at least not easily... but it's all tied into the same functionality as logging-in via a form. Autologin uses the same login_to_service method in your create action. You should already have the user's login credentials, so post them to the service and redirect them to whatever "getting started" page they should begin with. You can even just reuse the same cas_login action itself.

So, in the action that creates/registers a new user, add this at the end:

  def create
    # creating a new user code goes here
    if success?
       redirect(cas_login_path(:login => @user.username, :password => params[:new_password]))
    end
  end

Just don't forget to use the pre-encrypted password. :)

---

This is one article in a series on Rails single-sign-on with rubyCAS