Belighted

Platypus - Belighted developers' playground

Platypus

Belighted developers' playground

Belighted Dev’s Insider #5

Last news in live from Belighted dev chat room !

See you next week !

Comments

WTF: Beloved JS - Javascript … What Else ?

Here are the latest trending Javascript libraries we had a look at in the last few weeks ! We just can’t wait to use them in one of our future projects !

js
Comments

Belighted Dev’s Insider #4

Here is our last Belighted dev chat room summary proudly provided on Platypus !

And finally, here is what happens on the internet while you were reading our blog !

https://s3-eu-west-1.amazonaws.com/uploads-eu.hipchat.com/34861/246507/ZTEe4cO0qcJMoHz/Internet-minute.jpg

See you soon !

Comments

WTF: MapReduce and Columnar DB’s

At Belighted, we stay in touch with the latest technologies! Even more if they relate to huge amount of data, such as companies like Facebook, Google and Amazon are used to handle.

Here is a small introduction of key points of interest if you need to enter this new world of huge, distributed, and replicated databases.

This presentation introduces two fundamental topics: MapReduce and Columnar DB’s.

Comments

Gulp & Grunt: How to Automate the Work of Front-end Developer?

http://i.imgur.com/frWoyic.jpg

This article will be split in two distinct parts: the first will be more “theoretical” and will explain the main principles of Gulp and Grunt, as well as what I prefer to use; in the second, we will show you how to build a boilerplate for your project (in both way).

As front-end developers, we are often faced in our daily work with recurring and time consuming tasks. For the sake of efficiency and comfort of work, we have listed a few things that could improve the workflow of our team:

  • Fast and automated creation of a common working environment.
  • Automation of tasks such as image compression, JS files concatenation or SASS files compilation.

To meet these needs, two tools are in competition: Grunt and Gulp.

Grunt and Gulp are two task runners that automate most tasks (compilation, test creation,…), saving time and helping us to focus on the essential: development.

Ultimately, Grunt and Gulp do exactly the same job. The communities around the two systems are quite large and modules can be found fairly easily for each of the two systems. What differentiates the two is their mode of operation.

Grunt

Grunt works on the principle of “per plugins” configuration. This means that each plugin must be independently configured and used in tasks. Here’s how a plugin is configured, with options, a source and sometimes a destination file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
sass: {
  dist: {
    options: {
      style: 'expanded'
    },
    files: {
      'dist/assets/css/main.css': 'src/styles/main.scss',
    }
  }
},

autoprefixer: {
  dist: {
    options: {
      browsers: [
        'last 2 version', 'safari 5', 'ie 8', 'ie 9', 'opera 12.1', 'ios 6', 'android 4'
      ]
    },
    src: 'dist/assets/css/main.css',
    dest: 'dist/assets/css/main.css'
  }
},

grunt.registerTask('styles', ['sass', 'autoprefixer']);

This methodology allows to configure plugins, then inject them into tasks.

  • The advantage is that each plug-in is independent of the others.

  • The downside is manipulating files between tasks. If you plan a series of tasks via plug-ins, this means that the files will be handled as many times as the number of defined tasks.

Gulp

Gulp, meanwhile, works on the principle of “per tasks” configuration. The big difference is that here we will configure and inject all the plugins we need within the task configuration:

1
2
3
4
5
6
gulp.task('sass', function() {
  return gulp.src('src/styles/main.scss')
    .pipe(sass({ style: 'compressed' }))
    .pipe(autoprefixer('last 2 version', 'safari 5', 'ie 8', 'ie 9', 'opera 12.1', 'ios 6', 'android 4'))
    .pipe(gulp.dest('dist/assets/css'))
});

The situation here is quite different: the different desired plugins are injected into the “pipe”.

  • The advantage of Gulp is that the file does not pass from one task to another, but is transformed once. This prevents handling the final files multiple times. It also use the powerful NodeJS Stream (see at the end of this article for Stream)

  • The disadvantage is that the same configuration for a task can be repeated multiple times. (If we take care of the HTML files in a different way, it is possible to have re-write the same code in multiple places)

Conclusion

Both technologies meet our needs, with the same result. The big difference is their functional approach. You may prefer to configure the entire plugins and add tasks or conversely, create jobs and inject plugins.

Next week we will dive deeper in these two technologies, with more specific examples. So stay tuned!

Here are some good articles about streams:

Thanks to @zedissime, Dominique and Gregory for the review

Comments

Belighted Dev’s Insider #3 - Front-end Edition

This week, it’s a special edition of the Belighted dev chat room summary with a focus on front-end development!

CSS, Dev, HTML, JS, Web
Comments

Belighted Dev’s Insider #2

Let’s introduce this second Belighted dev chat room summary by a touch of humour !

http://i.imgur.com/VOe71EA.png

See you soon !

Comments

Belighted Dev’s Insider

We are proud to introduce a new series of posts on this blog ! As you’ve maybe already read in a previous article, we use Hipchat internaly as communication tool on a daily basis within our team.

One of the most interesting and animated chat rooms is clearly the dev one, filled with tips and tricks, news of the latest technologies provided by our ongoing readings, … such quality information that from now on, we have decided to share these pieces of information with all of you.

And here is this first Belighted dev chat room summary:

Enjoy reading our blog and see you soon !

Comments

Parse

DISCLAIMER: I wrote the first draft of this post 9 months ago. I only finished it now because I was very lazy busy.

BaaS and Parse have certainly evolved since them and although I believe everything in this post still holds, some details might be outdated. Feel free to correct me in the comments if you spot one.

(m)BaaS looks cool. Very cloudy, or whatever. So when we had the opportunity to use Parse for a real customer project, we took it. The backend was simple enough. The load was going to be high. It looked like a perfect match. Yet it wasn’t. It was a mistake, one I won’t make again. Here is why.

There is always that one feature

Whatever provider you use, unless it is fully customisable, you are always going to miss one feature. It might be something unimportant. It might be something small. But it will probably be a big pain in the ass.

For us, the feature was IP detection. The use case was incredibly simple: users could do some actions without registering, but were then identify by their IP. I know it may sound like a bad idea and I would generally agree, but in this case it was simply the best – and only good – solution.

Parse doesn’t support that. Something that would have been incredibly easy using Rails, Node.js or even freaking PHP is just not possible. We had to resort to using a less than good solution, because when you are facing such a missing feature in a BaaS, there is no way around it. You cannot add it yourself, no matter your expertise and the time you are willing to put on it. It is not possible, move along.

When something goes wrong, you are powerless

At some point during development, I started getting weird errors. Apparently the database was taking too long to respond and the server called timeout. I asked support and found a similar issue, but it took a while being fixed.

The real issue here is not that there was some problem at some point — that is bound to happen in any software project — but that when it happens, you are completely dependent on the willingness of the provider to fix it. You do not control the priority of the issue, the manpower assign to it, and you certainly cannot do anything to fix it yourself. You are thrusting someone else with your entire backend, including your data, and should they fail, so will you.

You are locked in

I always find it hard to argue about lock-in without sounding like a free software extremist. After all, the cloud is synonymous of less control for more convenience, and I am usually fine with that. BaaS vendors will always repeat ad nauseam that you are not locked in, because you are free to take your data and go whenever you want.

First of all, being free to export all your data seems obvious and doesn’t make a convincing argument. It also ignores one important fact: whatever the format in which you can get your precious data back, it won’t be exactly as you need it to be imported elsewhere. There will be work to re-arrange it, and that is part of the leave cost.

Second and most importantly, should you choose to leave, you can pretty much throw your code in the trash. Not only the custom backend code but also your front-end code will be closely linked to the BaaS you were using, with all their libs and frameworks that made your job so easy. So yes, you can expect to rewrite pretty much everything that made your app outside of CSS.

When we went back to Rails

As I said, one of the reason we chose Parse for this particular project was the expected load. The customer estimated 100,000 visitors per hour during a few hours of runtime. This was not a load we felt comfortable handling ourselves, but surely Parse could handle it. We felt we required around 100 requests per second, which is a little more than twice the basic limit, so surely we could figure something out with their Enterprise sales team. We were wrong.

A salesman responded with an offer: an Enterprise Plan running at $12,000/year. No monthly plan. No SLA. 400 requests per seconds. More than we needed, but not at all what we asked for. And for 12 times the amount we had in mind.

And so we were stuck: our only choices were to leave the limit and make our users suffer, pay a ridiculous amount of money for an app that was going to be live for a few hours, or re-write the whole damn thing.

In the end, we chose to re-write the entire backend in Rails, and change the front-end accordingly. And that is the last time I will ever use BaaS.

Comments

Handcrafted Xml Files With Ruby!

On a daily basis we build API in order to feed all our projects ( such as our hot new NomadSuite ) and in our way to face such difficulties, we rely on the good old JSON format.

But sometimes, the industry standards required us to use the well known and spread XML format.

Here are two gems that can allow you to easily craft your own xml file, an old one called Builder and another, a bit more complete, called Nokogiri.

We’ll take this last one to show you, what are these capabilities:

First of all, add gem "nokogiri" to your gemfile and run the bundle install command.

Then, start to write your script !

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
builder = Nokogiri::XML::Builder.new(:encoding => 'UTF-8') do |xml|
        xml.Documents {
          documents.each do |document|
            xml.Document {
              xml.DocumentTypeH document.document_type
              xml.DocumentNb document.document_nb
              xml.Lines {
                document.lines.each_with_index do |line, index|
                  xml.Line {
                    xml.DocumentType document.document_type
                    xml.DocumentNb document.document_nb
                    xml.LineNb (index + 1)
                  }
                end
              }
            }
          end
        }
      end
builder.to_xml

Another option that we consider sometimes, is also to use the famous erb template language to generate the desired XML output.

For instance, have a look at this small piece of code:

You basicaly need nothing more than ruby (as erb is a ruby core library).

Just instanciate the class: ERB.new(File.read("./documents.xml.erb"), 0, '>').result(binding) (binding allow you to access all call context variables).

Then, here is the XML template:

./documents.xml.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Documents>
  <% documents.each do |document| %>
    <Document>
      <DocumentTypeH><%= document.document_type %></DocumentTypeH>
      <DocumentNb><%= document.document_nb %></DocumentNb>
      <Lines>
        <% document.lines.each_with_index do |line, index| %>
          <Line>
            <DocumentType><%= document.document_type %></DocumentType>
            <DocumentNb><%= document.document_nb %></DocumentNb>
            <LineNb><%= index + 1 %></LineNb>
          </Line>
        <% end %>
      </Lines>
    </Document>
  <% end %>
</Documents>

Don’t hesitate to share your xml creation process !

Comments