Why? Because when an api is called with the right token, you want to use Auth::user() and Auth::check(), for example.

What you need to do is add (at the end) of app/start/global.php this three events that will bound the token events to the authentication system

Event::listen('auth.token.valid', function($user)  
{
    //Token is valid, set the user on auth system.
    Auth::setUser($user);
});

Event::listen('auth.token.created', function($user, $token)  
{
    //Token is valid, set the user on auth system.
    Auth::setUser($user);
});

Event::listen('auth.token.deleted', function()  
{
    //Token is removed, deauthenticate the user.
    Auth::logout();
});

I am glad to thank Giorgio, that has pinned the problem and made a website around it: shouldiaskmytechfriendtofixmypc

(Yes, there's a reference to dwsntletsieb.

Thanks Giorgio

There were lots of interesting talks and some ideas that needs to be metabolized - not an easy 'show your code' conference for sure! :-)

On a lighter side, what I couldn't resist to do after a couple of beers with friends, was updating my blog from wordpress to ghost.

Why?

Because it's minimal, because I love editing posts in Markdown and I find that WYSIWYG editors produce shitty HTML, and because it's on nodejs.

Thanks to Jon Hanshaw for the tips on the essentials customizations.

Now to sleep!

A little premise

I work in the interface development department of a big company, and I interview web designers, interface developers, frontend developers and sometimes assist my co-workers in other web related interviews

The first thing: character

The first and most important questions (IMHO) I ask are open questions about what the candidate thinks about some technology (or anything, really). Sometimes I ask about something that is universally known ad bad, ugly, or old. You can't know how many persons reply "I like that" thinking that if I asked then it interests me. No no no no. The worst mistake.

If you don't like something, say it. Even if the interviewer might disagree (but if he has skill, hardly will defend an old / ugly / old matter). First you must have character and skill and if something is wrong you must stand for your opinion.

I don't want to work with someone that doesn't have an opinion.

The basics: skills

I'd like to assume that if you apply for an Interface Developer position, you know your tools and the related programming languages. So the will be basic questions just to make sure that we speak the same language. Something incredibly stupid thing I (often) see is people that repeat what I say.

"Do you know javascript?" "Ah yes, javascript!" "Which framework do you prefer?" "Every framework!"

Please don't. If you don't know what we are talking about, have the guts to say it. At least there may be a chance to learn something.

The interviewer might not be interested in the most skilled guy on earth, but good curiosity and passion for the subject will compensate (And you can't fake those in the long time).

Stated that you have your skills, what matters if that you can relate to everything that happens around you, so you can do a better job. You want to work for the website X, then: How many users daily might the website have? How many production servers do you think they have? Less or more, of course, but being aware of the context will help, and it shows me that you are curious. Which at the end of the day, it's the only thing that matters.

The portfolio and the cv

You don't really have to have a old school portfolio but a couple of advices:

Triple check your CV: if you are being interviewed to work on the presentation layer, and the fonts are not - at least - consistent, ask yourself what are you doing.

Your CV is in word? You CV is on a standard format (like the european format)? You loose points. I'm not expecting to see an infographic every time - and I'm glad of it - but a bit of creativity helps.

Have ready some examples of previous works. You worked only on NDA and closed projects? Then have a personal website telling about how you like cats (or whatelse). You don't even have a personal website? What are you doing here?

My website

Well, actually the company website: since I work for a relatively big e-commerce, chances are that you have seen one of the company's websites. Please have the decency to come having seen the company website, and if interviewed as a webdesigner / interface developer have also the courtesy of spotting something you like and something you don't in the design or in the code. No you don't need to find a bug, but questions like "Why you use jquery instead of <name another framework>?" are welcome.

I know that all of these things seems trivial, but every time there is someone that slips on the basics and the interview becomes awkward. Please give yourself the gift of a chance.

The project i'm workin on is organized with a very big css/ folder with a css for every page, a couple css for the common classes and some css files with fixes for certains nations (I'm speaking of Russia, China and Japan, where we have different fonts and all the spacing changes); it is also deployed with continuous integration on several test environments and the production cluster.

In the past we did try a conversion to less, but it was unsuccessful, mainly because the less syntax is not compatible with css so we needed to restyle every page (a lot).

We planned a lot on how to introduce the scss files and after several tries we noted that:

• it was unnecessary to rewrite a single line of css: the scss syntax is superset of css
• we did not need to convert scss file live and cache them - at the beginning we could source control both

Once all the interface developers were the loop and motivated (pretty easy ;-), we decided to migrate in steps, to make the transition easy:

1. Copy the css folder to a new 'sass' folder and rename (batch rename) all the files to .scss, commit and celebrate. This is the core action to introduce sass.
2. Modify the continuous integration script to recompile all the css during the build/deploy task: this way we could remove the css file from versioning and avoid unnecessary merges
3. Modify the above script to deploy the generated sprites: we keep them on different servers and we decided it was not a vital step, so we separated from the second.

The big point is that between step 1 and 2 we let several days pass by. This way all the developers could taste the scss sweetness and bring their sub-projects up to speed. We don't like big changes   :-). Beside that, the first step is really the core of setting up scss, and it only takes a few minutes.

What we gained? Now the situation is pretty much the same ( the code is messy) but we can work a little every day, along the normal maintenance, to sort things out, and there is no need for a 'stop everyone and make clean' task: the business would never have allowed us that.

On the performance side, the minified css globally weight a third of the originals. Yo!

brew install ffmpeg --use-clang

I could not reach ffmpeg from the command line. For some reason the installer forgot to link the bin file. Simply solved with

ln /usr/local/Cellar/ffmpeg/1.0/bin/ffmpeg /usr/local/bin/

Posted just in case this happens to someone else.

image courtesy of Logophile
Basically it has rain-in-the-forest recording that loops. You have to listen to it with (a good pair of) headphones, and it will make you think that you are in a forest, during a storm (except you don't get wet).

I've discovered it a years ago, more or less, and I am always keeping it open when I work. It is a great way to isolate you acoustically and concentrate, without the distraction that random music with lyrics brings.

And, as a bonus, when the summer it's really hot (and in Bologna can be really hot), tricks your brain and makes the day bearable.

Go to: rainymood.com

Password:

On mobile devices, it's harder to look - we hold the device in hand - and it's easier to make a mistake.

When the password is a key step in your business (to buy something, for example), you don't want users to go away because they are tired of rewriting a miswritten password.

It would be nice to have a toggle button that can show the password, to avoid typos and in the same time guarantee privacy when needed.

The html is simple: a form and an anchor to toggle the status:

<input type="password" class="toggablePwd" />  
<button>show</button>  

And the javascript: we need to notice that for security reasons you can't change the type attribute of a password input field. So the idea is to copy the html of the tag (thus preserving classes and other attributes) and repopulate the value field.

$("button").on("click", function() {
  var elemtn = $(".toggablePwd")[0].outerHTML;

  if ($(this).html() === "show") {
    elemtn = elemtn .replace(/password/, "text");
    $(this).html("hide");
  } else {
    elemtn = elemtn.replace(/text/, "password");
    $(this).html("show");
  }

  var val = $(".toggablePwd&").val();
  $(".toggablePwd").replaceWith(elemtn);
  $(".toggablePwd").val(val);
});

You can see a demo here

This is the code to make a screenshot of a full web page:


var page = require('webpage').create();
page.open('http://google.com', function () {
page.render('google.png');
phantom.exit();
});

I'm totally hooked.