sparrovv.extend(Blog)

Power of Introverts

Just watched this ted talk, about power of introverts, and I really enjoyed it.

Introvert, it’s how I roll :D But truly saying sometimes I feel bad, that I didn’t go anywhere and stayed at home hacking or reading stuff. It’s good to know that this is quite common thought, and I shouldn’t feel wrong about that.

Just like Barney Stinson is saying: “When I’m sad, I stop being sad, and start being awesome instead, true story”

Handy scripts, that I started to use

This week, I’ve started to use some handy scripts, that I really enjoy, so I’d like to thank their creators, and spread a word.

• hacker-top - hacker news in terminal. Simple and neat interface.
• get-shit-done - this script blocks often visited sites. It’s quite handy, when I’m working on something.

chrismaury:

I was walking around downtown Philadelphia earlier today and seeing all the people walking around with nothing to do or panhandling, it got me thinking.

How can we inject money into this ecosystem in other ways than welfare or charity? For all the success that micro-lending has had in India and…

$0 in modern browsers console

I’ve just found  out recently, that when you’re inspecting some element using inspect tool (chrome, safari, firefox), then in console you can access this element with $0.

This is just awesome, no more long selectors.

console.log in production

Usually in development mode we put a lot of console.log(‘…’) to javascript code, that we sometimes forgot to remove, or we keep it on purpose for further debugging.

Of course it’s not elegant to keep this in a production mode, for users eyes.

To keep it hide, the easiest solution is to override console.log(). We can do this by adding this little code snippet:

try{ if(window.location.search.match(/console-debug/)){ window.MyAppDebugMode = true; } }catch(e){ }

if ((typeof console === "undefined") || !window.MyAppDebugMode) { console = { log: function(){} };}

In development always keep window.MyAppDebugMode set to true, and you won’t notice any difference. In production just remove this var, or set it to false.

From mocha to rspec-mocks

Recently in the projct we decided to switch to rspec-mocks from mocha. There are not many diffrences, but there are some, and most of them can be changed by these set of sed instructions:

sed -i '' -e "s/\.stubs/\.stub/" `find ./spec/ -name \*spec.rb`

sed -i '' -e "s/\.returns/\.and_return/" `find ./spec/ -name \*spec.rb`

sed -i '' -e "s/\.expects/\.should_receive/" `find ./spec/ -name \*spec.rb`

Receiving emails in your app

There are some methods to acomplish this task, amongs other there is a popular one that is described in railsquides

But I was looking for something, that is more generic and less coupled with my app, and the only responsibility is receiving emails and sending them through http to the app.

After some research I’ve found 2 gems, that were a great match for this job:

• mailman
• rest-client

First thing that you need to do is setup an email account where users are going to send emails. The simplest way is to start with gmail, and if there’s goinng to be more than one email address in context of your domain, then setup google app for it.

This gist is almost whole implementation of email client, that every 10s checks inbox, and if there is anything new, then sends it to endpoint (app).

On production server of course you need to use god or monit to be sure that it runs without any problems. “god” will help you to demonize it. If you expect a lot of email traffic, then you also need to think of some queue, like resque.

In your app you just need a controller with create action.

You also have to implement some kind of authentication mechanism, to make sure that your app gets emails from known source.