Tech-Angels

MaxMind support for Geocoder gem

Wed, 16 May 2012 11:39:00 +0200

While using geocoder gem to fetch IP address info, we thought: default FreeGeoIP service is great, open source and freely available, it has all the info we need, quite fast and accurate.

But what if we don’t want to mess up with FreeGeoIP’s limit or just need to use MaxMind? Then we would be disappointed, because geocoder doesn’t support MaxMind and there’s been no way easily to include support in short period of time… Until now! Thanks to our angel Olivier, who has opened pull request with MaxMind support:

https://github.com/alexreisner/geocoder/pull/227

Moreover, this version has been used on production servers for 7 months. So, we are confident it’s stable.

Enjoy!

Gemfile trick for github repositories

Thu, 10 May 2012 11:35:26 +0200

Tired of writing long git paths to github repositories in Gemfile? Then you will find this useful. When the repository you need is public, you can use :github shortland instead of :git. And just specify github username and repository name separated by slash.

If repository name and username are the same, you can drop one:

    gem "rails", :github => "rails/rails"

    gem "rails", :github => "rails"

Are both equivalent to:

    gem "rails", :git => "git://github.com/rails/rails.git"

I wonder, how didn’t we enjoy this all the time? :)

Presentation at UTC - May 18th

Tue, 24 Apr 2012 21:24:16 +0200

Tech-Angels will be presented Friday May 18th at UTC (Université de Technologie de Compiègne - France). Meet us from 13:00 to 14:00 in Benjamin Franklin Building (room unknown for now). We will be available in the afternoon to answer your questions.

Krakow is full of <3

Sat, 21 Apr 2012 19:07:58 +0200

Krakow is full of <3

Railsberry 2012 KRK

Fri, 20 Apr 2012 14:33:00 +0200

We’re attending railsberry in Krakow for 2 days, and will have soon some exciting official announcements. If you’re there, you will probably find us, and we will be pleased to meet you.

So far, it was a real bunch of great speeches and presentation, with a special thanks to @tenderlove. We were hopping for some rails announcements, but so far, nothing new under the sun. It was still the occasion to meet face-to-face with some really interesting and nice people.

Stay tunned in the next days for news.

News, news, news!

Mon, 12 Mar 2012 20:07:53 +0100

Hey everyone, it’s been a while since we’ve updated our blog, but we have a couple of reasons for that.

We were working hard over the last months and found 4 angels, who joined our team! They’re working all over the Europe and even have girl-angel among them ;) (photos coming soon)

As for the main reason, we’re excited to tell that we’ve started our own projects development. And I tell you what, this is gonna be awesome.

Tech-Angels is hiring a Debian SysAdmin

Wed, 04 Jan 2012 11:05:36 +0100

We’re looking for (passionate) SysAdmin to join our existing team. You will be in charge of managing servers remotely with ssh and puppet.

Skills needed : Linux Debian, puppet, git, postgresql, mysql, redis
You will work remotely only, as all other employees in Tech-Angels, and will report hours through oDesk.

To improve communication between developers, we’re only accepting people in the UTC +-3 hours range.

Please apply here (only!).

Tech-Angels is hiring Ruby On Rails developers

Wed, 04 Jan 2012 11:02:29 +0100

We’re looking for (passionate) Ruby / Ruby on Rails developers to join our existing team. We work mostly with recent Rails versions, haml, sass/scss, jQuery, Redis and PostgreSQL.
You will work remotely only, as all other employees in Tech-Angels, and will report hours through oDesk.

To improve communication between developers, we’re only accepting people in the UTC +-3 hours range.

Please apply here (only!).

TcpSyslog is now a gem

Tue, 21 Jun 2011 10:17:45 +0200

We’ve just released TcpSyslog 1.0.0 gem. TcpSyslog is rails logger using syslog with TCP instead of UPD. This gem should be used in large apps, where a central syslog server is available using TCP, and no syslog server is present on the local node.

(image credits : lamenta3)

TcpSyslog logger for rails

Sun, 26 Sep 2010 20:36:09 +0200

Weird enough, the default syslog librairy (ie: Syslog) doesn’t allow to sent logs to a distant server. Instead, localhost must be used, and the local syslog server will forward the message to a central server.

Anyhow, in some cases, there’s no local syslog server, or you might have to send your messages directly to that central position. In the cloud, that’s a lot of syslog servers you won’t have to monitor.

Here it comes, you can find the TcpSyslog for rails here. It was inspired from SyslogLogger and ActiveSupport::BufferedLogger. In fact, TcpSyslog will act exactly as a BufferedLogger, except messages are sent over TCP/IP (only for now) to syslog.

We’ll release a gem soon, stay tuned.

Improve IRB (and fix it on mac OS X)

Mon, 16 Aug 2010 17:39:00 +0200

Irb, the interactive Ruby shell should be the Ruby developer’s best friend.

Anyway, with a few customization, we can still improve this tool. First, you will notice the backward search won’t work out of the box on Mac OS X. This is an issue with readline.

To fix this, add this to your ~/.editrc file :

bind "^R" em-inc-search-prev

Now you may use CTRL-R to Reverse-search your history.

Also, you may want to give a try to Wirble, which is used to colorize your IRB output.

At tech-angels, we also use Hirb to format the ActiveRecord outputs.

Finally, this is a common .irbrc file :


require 'rubygems'
require 'wirble'
require 'hirb'
Wirble.init
Wirble.colorize
# hirb (active record output format in table)
Hirb::View.enable

# IRB Options
IRB.conf[:AUTO_INDENT] = true
IRB.conf[:SAVE_HISTORY] = 1000
IRB.conf[:EVAL_HISTORY] = 200

# Log to STDOUT if in Rails
if ENV.include?('RAILS_ENV') && !Object.const_defined?('RAILS_DEFAULT_LOGGER')
  require 'logger'
  RAILS_DEFAULT_LOGGER = Logger.new(STDOUT)
  #IRB.conf[:USE_READLINE] = true

  # Display the RAILS ENV in the prompt
  # ie : [Development]>> 
  IRB.conf[:PROMPT][:CUSTOM] = {
   :PROMPT_N => "[#{ENV["RAILS_ENV"].capitalize}]>> ",
   :PROMPT_I => "[#{ENV["RAILS_ENV"].capitalize}]>> ",
   :PROMPT_S => nil,
   :PROMPT_C => "?> ",
   :RETURN => "=> %s\n"
   }
  # Set default prompt
  IRB.conf[:PROMPT_MODE] = :CUSTOM
end

# We can also define convenient methods (credits go to thoughtbot)
def me
  User.find_by_email("me@gmail.com")
end

Diff joy for your migrations with git

Fri, 06 Aug 2010 10:00:00 +0200

Rails migrations are great. They allow to migrate and rollback, and maintain the DB in a consistent state. Thanks to Rails DSL (+ some plugins like rails_on_pg), they are even easy to read and write. Fine.

Enters our beloved friend language SQL. Whilst views (or functions, or whatever) creation is made easy, updating existing code can become a real nightmare, especially with long and complex queries.

Let’s illustrate our problem :

In a rails app, I’d like to create a view for confirmed users. Let’s leave rails_on_pg plugin for now, but the problem would be exactly the same. (Note: examples bellow are based on rails 2.3, they would be a little different in rails 3, but the problem is still there).

script/generate migration create_confirmed_user_view

In the migration file, you would add your code as :

Right, now your run your migration process :

rake db:migrate

and everything goes fine.

Later, you realize that the view was incorrect, you should have filtered also on the disabled boolean column. Now the migration will be something more :

Here comes the problem. You have to copy / paste your previous definition in the migration, each time you want to update a view or a function.

In this example, our view is 2 lines only. With a big fancy function of 20 lines, you won’t be able to notice differences easily (or at all).

Enters Git

To solve our problem, we can create a sql folder in our project tree, and put all functions and complex queries in there.

Now we can write our first implementation of the confirmed_users view :

Add the file to git :

git add sql/confirmed_users_view.sql

And commit it :

git ci

The file has been “saved” in git, at least in its original version. We can easily use git to manage the history of the file. Do your changes, and commit the file again (you know, git add, git ci).

Let’s spice up our migration now. First, grab the last commit ids from git :

git log --oneline -n 2

2d308a6 Update view confirmed users
1596b6d Create view confirmed users

We can use these 2 ids in our migration :

Migration files will be certainly harder to read, but you get a valuable tool with git diff :

git diff -p 2d308a6

[...]
CREATE OR REPLACE VIEW confirmed_user AS
-  SELECT * FROM users WHERE confirmed_at IS NOT NULL;
+  SELECT * FROM users WHERE confirmed_at IS NOT NULL
+  AND disabled IS FALSE;

Of course, this implies you have Git installed on your production servers, but why won’t you ? Especially if you’re using capistrano.

Make Ack look into haml files too

Wed, 04 Aug 2010 14:33:12 +0200

If you’re using Ack grep command in a Rails project, you’ll notice all haml views aren’t taken into account. This is because the haml file pattern is not recognized by Ack.

To fix this, simply create a ~/.ackrc file and add :

--type-add=ruby=.haml,.rake,.rsel

Make cookies more secure in Ruby On Rails

Wed, 21 Jul 2010 15:01:00 +0200

This subject is really not very often highlighted in rails security docs, even in the official guide.

We’re often happy with the basic cookie store options :

Anyway, secure websites (like e-commerce sites) must include some more secure options. Cookies have two attributes people usually don’t use :

Secure : “A server can specify thesecure flag while setting a cookie; the browser will then send it only over a secure channel, such as an SSL connection.”
Expires : “Cookies expire, and are therefore not sent by the browser to the server, under any of these conditions: […] An expiration date has been specified, and has passed.”

(Definition taken from Wikipedia)

The last means the session AND the cookie will expire after the given date. It’s generally a good idea to set this option, unless you’re running facebook.com, people won’t spend more than 1 hour on you site per day.

To enable these 2 options, you can use the configuration in config/environment.rb :

You should set the secure option per environment, otherwise your dev environment will fail. To do so, you can add a line in each secure environment :

Rails Freak: Be pragmatic with your time

Tue, 09 Mar 2010 17:30:08 +0100

Rails Freak: Be pragmatic with your time:

So you’re trying to write that awesome new feature you’ve been chomping at the bit for, right? Your gonna get it done and it’s gonna have so many bells and whistles! Let’s say you give yourself two weeks to get it done, but at the end of one week you realize you just can’t finish it in one more…

Nous sommes heureux et fiers d’accueillir dans nos rangs...

Mon, 01 Mar 2010 10:15:24 +0100

Nous sommes heureux et fiers d’accueillir dans nos rangs Olivier Gonzalez. Olivier a une formation d’ingénieur en génie informatique à l’UTC (Université de Compiègne), et une curiosité et une ténacité qui lui permettent de travailler sur tous nos projets. Il a notamment passé ces derniers mois à travailler sur le site http://woopets.com.

Au passage, nous sommes toujours à la recherche d’un designer / intégrateur web pour renforcer notre équipe.

[FR] Tech-Angels recherche un designer web

Tue, 26 Jan 2010 16:58:00 +0100

Tech-Angels recherche un(e) designer web avec ou sans expérience, mais avec beaucoup de curiosité et d’autonomie. Vous êtes un expert en (x)html, css, javascript (en particulier jQuery), et souhaitez collaborer sur des prototypes de projets innovants ? Rejoignez notre équipe d’ingénieurs.

Le poste est à pourvoir dès aujourd’hui sur Chantilly, au nord de Paris, avec possibilité de travail à distance. Rémunération fonction de votre expérience.

Envoyez votre canditature à philippe|@|tech-angels.biz

"iPilule, chronique d’une application iPhone"

Fri, 18 Dec 2009 17:13:56 +0100

"iPilule, chronique d’une application iPhone":

“Du développement aux ventes dans l’AppStore, on vous dit tout”

Un retour d’expérience complet et argumenté, à lire absolument.

Don't complicate your billing

Thu, 03 Dec 2009 10:21:30 +0100

4beansoup:

Recently we have been working on adding billing support to tweet hopper, and we had all types of debates on how to handle each little nuisance. After much discussion and research, I have found the right answer: don’t make it complicated!

There is a saying, “no code is faster than no code”. Very smart coding proverb, which can be easily restated as “no functionality is less buggy than no functionality”. What I am trying to say is, adding complex billing functions just adds unneeded complexity to an already tough problem.

Once a month or 30 days?

This decision doesn’t have deep ramifications, but it is an important question to decide on. Do you bill every 30 days or the same day every month? Services like github charge on the same day every month, or be more like 37signals and charge every 30 days. The biggest difference is that going every 30 days means you get an extra payment every 10 years… Yes, 10 years, shrug.

There is also one other issue to consider if you charge on the same day every month, heard of February? What if someone signs up on the 31st? You have to start accounting for month end dates and make sure you get a monthly charge in on shorter and longer months, leading to more code complexity.

To prorate or not to prorate

Wait? Someone wants to upgrade in the middle of the month! There are two different schools of thoughts; prorate or just bill the higher amount on the next billing date. Linode, our hosting provider, charges on the 1st of every month and then charges prorated amounts if you need to upgrade or add services. On the other hand, github and 37signals both wait and charge you the upgraded amount on your next billing date, but you get immediate access to upgraded plans.

The prorating method has another down side that can lead to extra code complexity if you aren’t careful. What happens if you charge a customer $30 a month and they signup on November 29th? If you prorate and charge them, you will charge them $1, which will be almost nothing after credit card processing fees - depending on who you use to process transactions. Linode handles this by charging prorated amounts plus the next month if it is after the 20th, but that adds to complexity.

For tweet hopper, we decided to avoid complication and skip prorating and just go with the higher billing amount on the next billing date. Why write code that has to do complicated math? The side benefit of it all? Credit card billing can be completely separated from the app and run via cron scripts, there is no need to do on the spot prorate charging.

Refunds? We don’t need no stinkin’ refunds!

This one is pretty straight forward for me, don’t offer refunds. Don’t write any code in your app to push refunds - your gateway should have the tools you need for the few instances that you need it. It is the customer’s responsibility to cancel their account, and if they don’t it in time it isn’t your fault.

This is a clear cut “no code” win!

Freemium vs Trials

Free and paid plans versus 30 day trials with paid plans, it is less of a clear cut choice. The choice really depends on your product and the resources each plan uses.

With tweet hopper we have a lot of expense that goes into even just one twitter account. Due to that expense we decided to offer a free 30 day trial instead of a completely free account. We collect the credit card up front, mark the 30 day billing date, and charge your card once that date hits unless you cancel. By offering only paid plans, the plan changing and card collecting is pretty straight forward.

37signals offers both options in their products, either free plans or paid plans, taking credit cards up front. When you upgrade from a free plan to a paid plan, they have a bit of extra logic they need to handle to setup billing dates and get the charging going.

Keep it simple…

In the end, do whatever feels right when you are collecting payments. Keep it secure and keep it simple. The most important thing to understand is that no code is less complex than no code!

Axon Flux : "Building and Scaling a Startup on Rails: 12 Things We Learned the Hard Way"

Wed, 02 Dec 2009 22:22:58 +0100

Axon Flux : "Building and Scaling a Startup on Rails: 12 Things We Learned the Hard Way"