milmazz

How to document your Javascript code

2014-08-27T12:00:00-05:00

Someone that knows something about Java probably knows about JavaDoc. If you know something about Python you probably document your code following the rules defined for Sphinx (Sphinx uses reStructuredText as its markup language). Or in C, you follow the rules defined for Doxygen (Doxygen also supports other programming languages such as Objective-C, Java, C#, PHP, etc.). But, what happens when we are coding in JavaScript? How can we document our source code?

As a developer that interacts with other members of a team, the need to document all your intentions must become a habit. If you follow some basic rules and stick to them you can gain benefits like the automatic generation of documentation in formats like HTML, PDF, and so on.

I must confess that I’m relatively new to JavaScript, but one of the first things that I implement is the source code documentation. I’ve been using JSDoc for documenting all my JavaScript code, it’s easy, and you only need to follow a short set of rules.

/**
 * @file Working with Tags
 * @author Milton Mazzarri <me@milmazz.uno>
 * @version 0.1
 */

var Tag = $(function(){
  /**
   * The Tag definition.
   *
   * @param {String} id - The ID of the Tag.
   * @param {String} description - Concise description of the tag.
   * @param {Number} min - Minimum value accepted for trends.
   * @param {Number} max - Maximum value accepted for trends.
   * @param {Object} plc - The ID of the {@link PLC} object where this tag belongs.
   */
  var Tag = function(id, description, min, max, plc) {
    id = id;
    description = description;
    trend_min = min;
    trend_max = max;
    plc = plc;
  };

  return {
    /**
     * Get the current value of the tag.
     *
     * @see [Example]{@link http://example.com}
     * @returns {Number} The current value of the tag.
     */
    getValue: function() {
      return Math.random;
    }
  };
 }());

In the previous example, I have documented the index of the file, showing the author and version, you can also include other things such as a copyright and license note. I have also documented the class definition including parameters and methods specifying the name, and type with a concise description.

After you process your source code with JSDoc the result looks like the following:

In the previous image you see the documentation in HTML format, also you see a table that displays the parameters with appropriate links to your source code, and finally, JSDoc implements a very nice style to your document.

If you need further details I recommend you check out the JSDoc documentation.

How to document your Javascript code was originally published by Milton Mazzarri at milmazz on August 27, 2014.

Grunt: The Javascript Task Manager

2014-06-28T16:00:00-05:00

When you play the Web Developer role, sometimes you may have to endure some repetitive tasks like minification, unit testing, compilation, linting, beautify or unpack Javascript code and so on. To solve this problems, and in the meantime, try to keep your mental health in a good shape, you desperately need to find a way to automate this tasks. Grunt offers you an easy way to accomplish this kind of automation.

In this article I’ll try to explain how to automate some tasks with Grunt, but I recommend that you should take some time to read Grunt’s documentation and enjoy the experience by yourself.

So, in the following sections I’ll try to show you how to accomplish this tasks:

Concatenate and create a minified version of your CSS, JavaScript and HTML files.
Automatic generation of the documentation for JavaScript with JSDoc.
Linting your JavaScript code.
Reformat and reindent (prettify) your JavaScript code.

You can install Grunt via npm (Node Package Manager), so, to install Grunt you need to install Node.js first.

Now that you have Node.js and npm installed is a good time to install globally the Grunt CLI (Command Line Interface) package.

$ sudo npm install -g grunt-cli

Once grunt-cli is installed you need to go to the root directory of your project and create a package.json file, to accomplish this you can do the following:

$ cd example_project
$ npm init

The previous command will ask you a series of questions in order to create the package.json file, package.json basically store metadata for projects published as npm modules. It’s important to remember to add this file to your source code versioning tool to ease the installation process of the development dependencies among your partners via npm install command.

At this point we can install Grunt and their respective plugins in the existing package.json with:

$ npm install grunt --save-dev

And the plugins that you need can be installed as follows:

$ npm install <grunt-plugin-name> --save-dev

Please note that the --save-dev parameter will change your devDependencies section in your package.json. So, be sure to commit the updated package.json file with your project whenever you consider appropriate.

Code documentation

If you document your code following the syntax rules defined on JSDoc 3, e.g.:

/**
  * A callback function returning array defining where the ticks
  * are laid out on the axis.
  *
  * @function tickPositioner
  * @see {@link http://api.highcharts.com/highstock#yAxis.tickPositioner}
  * @param {String} xOrY - Is it X or Y Axis?
  * @param {Number} min - Minimum value
  * @param {Number} max - Maximum value
  * @returns {Array} - Where the ticks are laid out on the axis.
  */
 function tickPositioner(xOrY, min, max) {

    // do something

    return tickPositions;
 }

If you need more information about JSDoc, read their documentation, it’s easy to catch up.

The next step to automate the generation of the code documentation is to install first the grunt-jsdoc plugin as follows:

$ npm install grunt-jsdoc --save-dev

Once grunt-jsdoc is installed you must create your Gruntfile.js in the root directory of your project and then add the jsdoc entry to the options of the initConfig method.

module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({
      pkg: grunt.file.readJSON('package.json'),
      jsdoc : {
          dist : {
              src: ['src/*.js', 'test/*.js'], 
              dest: 'doc'
          }
      }
  });

};

Then, you need to load the plugin after the initConfig method in the Gruntfile.js:

// Load the plugin that provides the 'jsdoc' task.
grunt.loadNpmtasks('grunt-jsdoc');

The resulting Gruntfile.js until now is:

module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({
      pkg: grunt.file.readJSON('package.json'),
      jsdoc : {
          dist : {
              src: ['src/*.js', 'test/*.js'], 
              dest: 'doc'
          }
      }
  });

  // Load the plugin that provides the 'jsdoc' task.
  grunt.loadNpmtasks('grunt-jsdoc');

};

To generate the documentation, you need to call the jsdoc task as follows:

$ grunt jsdoc

Immediately you can see, inside the doc directory, the available documentation in HTML format with some beautiful styles by default.

Linting your JavaScript code

In order to find suspicious, non-portable or potential problems in JavaScript code or simply to enforce your team’s coding convention, whatever may be the reason, I recommend that you should include a static code analysis tool in your toolset.

The first step is to define your set of rules. I prefer to specify the set of rules in an independent file called .jshintrc located at the root directory of the project, let’s see an example:

// file: .jshintrc
{
    "globals": {
        "Highcharts": true, // This is only necessary if you use Highcharts
        "module": true // Gruntfile.js
    },
    "bitwise": true,
    "browser": true,
    "camelcase": true,
    "curly": true,
    "eqeqeq": true,
    "forin": true,
    "freeze": true,
    "immed": true,
    "indent": 4,
    "jquery": true,
    "latedef": true,
    "newcap": true,
    "noempty": true,
    "nonew": true,
    "quotmark": true,
    "trailing": true,
    "undef": true,
    "unused": true
}

If you need more details about the checks that offer every rule mentioned above, please, read the page that contains a list of all options supported by JSHint

To install the grunt-contrib-jshint plugin, , please do as follows:

$ npm install grunt-contrib-jshint --save-dev

Next, proceed to add the jshint entry to the options of the initConfig method in the Gruntfile.js as follows:

jshint: {
 options: {
  jshintrc: '.jshintrc'
 },
 all: ['Gruntfile.js', 'src/*.js', 'test/*.js']
}

Then, as it’s done in the previous section, you need to load the plugin after the initConfig method in the Grunfile.js

// Load the plugin that provides the 'jshint' task.
grunt.loadNpmTasks('grunt-contrib-jshint');

To validate your JavaScript code against the previous set of rules you need to call the jshint task:

$ grunt jshint

Note that if you need more information or explanations about the errors that you may receive after the previous command I suggest that you should visit JSLint Error Explanations site.

Code Style

As I mentioned in the previous section, I suggest that you should maintain an independent file where you define the set of rules about your coding styles:

// file: .jsbeautifyrc
{
  "indent_size": 4,
  "indent_char": " ",
  "indent_level": 0,
  "indent_with_tabs": false,
  "preserve_newlines": true,
  "max_preserve_newlines": 2,
  "jslint_happy": true,
  "brace_style": "collapse",
  "keep_array_indentation": false,
  "keep_function_indentation": false,
  "space_before_conditional": true,
  "break_chained_methods": false,
  "eval_code": false,
  "unescape_strings": false,
  "wrap_line_length": 0
}

Next, proceed to add the jsbeautifier entry to the options of the initConfig method in the Gruntfile.js as follows:

jsbeautifier: {
  modify: {
      src: 'index.js',
      options: {
          config: '.jsbeautifyrc'
   }
  },
  verify: {
   src: ['index.js'],
   options: {
   mode: 'VERIFY_ONLY',
   config: '.jsbeautifyrc'
  }
 }
}

The next step it to load the plugin after the initConfig method:

// Load the plugin that provides the 'jsbeautifier' task.
grunt.loadNpmTasks('grunt-jsbeautifier');

To adjust your JS files according to the previous set of rules you need to call the jsbeautifier task:

$ grunt jsbeautifier:modify

Concat and minified CSS, HTML, JS

To reduce the size of your CSS, HTML and JS files do as follows:

$ npm install grunt-contrib-uglify --save-dev
$ npm install grunt-contrib-htmlmin --save-dev
$ npm install grunt-contrib-cssmin --save-dev

Next, add the htmlmin, cssmin and uglify entries to the options of the initConfig method in the Gruntfile.js as follows:

htmlmin: {
  dist: {
    options: {
      removeComments: true,
      collapseWhitespace: true
    },
    files: {
      'dist/index.html': 'src/index.html',     // 'destination': 'source'
      'dist/contact.html': 'src/contact.html'
    }
  }
},
cssmin: {
  add_banner: {
    options: {
      banner: '/* My minified css file */'
    },
    files: {
      'path/to/output.css': ['path/to/**/*.css']
    }
  }
},
uglify: {
 options: {
   banner: '/* <%= grunt.template.today("yyyy-mm-dd") %> */\n',
   separator: ',',
   compress: true,
 },
 chart: {
   src: ['src/js/*.js'],
   dest: 'dist/js/example.min.js'
 }
}

The next step it to load the plugins after the initConfig method:

// Load the plugin that provides the 'uglify' task.
grunt.loadNpmTasks('grunt-contrib-uglify');
// Load the plugin that provides the 'htmlmin' task.
grunt.loadNpmTasks('grunt-contrib-htmlmin');
// Load the plugin that provides the 'cssmin' task.
grunt.loadNpmTasks('grunt-contrib-cssmin');

To adjust your files according to the previous set of rules you need to call the htmlmin, cssmin or uglify tasks:

$ grunt htmlmin
$ grunt cssmin
$ grunt uglify

After loading all of your Grunt tasks you can create some aliases.

If you want to create an alias that runs the three previous tasks in one step do as follows:

// Wrapper around htmlmin, cssmin and uglify tasks.
grunt.registerTask('minified', [
        'htmlmin',
        'cssmin',
        'uglify'
    ]);

So, to execute the three tasks in one step you can do the following:

$ grunt minified

The previous command is a wrapper around the htmlmin, cssmin and uglify tasks defined before.

Wrapping all together we get the following [Grunfile.js][]

Other plugins

Grunt offers you a very large amount of plugins, they have a dedicated section to list them!

I recommend that you should take some time to check out the following plugins:

grunt-newer lets you configure Grunt tasks to run with newer files only.
grunt-contrib-watch lets you run predefined tasks whenever file patterns are added, changed or deleted.
grunt-contrib-imagemin let you minify images.

Conclusion

Certainly, Grunt do a great job when we talk about task automation, also, automating this repetitive tasks is fun and reduce the errors associated with tasks that in the past we used to run manually over and over again. That been said, I definitely recommend that you should try Grunt, you will get in exchange an improvement in your development workflow, also with it you can forget to endure repetitive tasks that we hate to do, as a result you will get more free time to focus on getting things done.

Last but not least, another option for Grunt is Gulp, I recently read about it, if you look at their documentation you notice that their syntax is more clean than Grunt, also is very concise and allows chaining calls, following the concept of streams that pipes offer in *nix like systems, so, I’ll give it a try in my next project.

Grunt: The Javascript Task Manager was originally published by Milton Mazzarri at milmazz on June 28, 2014.

The DRY principle

2014-06-24T19:00:00-05:00

The DRY (Don’t Repeat Yourself) principle it basically consist in the following:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

That said, it’s almost clear that the DRY principle is against the code duplication, something that in the long-term affect the maintenance phase, it doesn’t facilitate the improvement or code refactoring and, in some cases, it can generate some contradictions, among other problems.

Recently I have inherited a project, and one of the things that I noticed in some part of the source code are the following:

After a glance, you can save some bytes and apply the facade and module pattern without breaking the API compatibility in this way:

But, if you have read the jQuery documentation it’s obvious that the previous code portions are against the DRY principle, basically, this functions expose some shorthands for the $.ajax method from the jQuery library. That said, it’s important to clarify that jQuery, from version 1.0, offers some shorthands, they are: $.get(), $.getJSON(), $.post(), among others.

So, in this particular case, I prefer to break the backward compatibility and delete the previous code portions. After that, I changed the code that used the previous functions and from this point I only used the shorthand that jQuery offers, some examples may clarify this thought:

Another advantage of using the shorthand methods that jQuery provides is that you can work with Deferreds, one last thing that we must take in consideration is that jqXHR.success() and jqXHR.error() callback methods are deprecated as of jQuery 1.8.

Anyway, I wanted to share my experience in this case. Also, remark that we need to take care of some principles at the moment we develop software and avoid to reinvent the wheel or do overengineering.

Last but not least, one way to read offline documentation that I tend to use is Dash or Zeal, I can reach a bunch of documentation without the need of an Internet connection, give it a try!

The DRY principle was originally published by Milton Mazzarri at milmazz on June 24, 2014.

libturpial needs your help

2014-03-10T15:00:00-06:00

Do you want to begin to contribute into libturpial codebase but you don’t know where to start?, that’s ok, it also happens to me sometimes, but today, the reality is that we need your help to fix some errors reported by our style checker (flake8), this errors are:

E126: continuation line over-indented for hanging indent
E128: continuation line under-indented for visual indent
E231: missing whitespace after :
E251: unexpected spaces around keyword / parameter equals
E261: at least two spaces before inline comment
E301: expected 1 blank line
E302: expected 2 blank lines
E303: too many blank lines
E501: line too long
E711: comparison to None should be if cond is not None:
E712: comparison to False should be if cond is False: or if not cond:
F401: imported but unused
F403: unable to detect undefined names
F821: undefined name
F841: local variable is assigned to but never used
F999: syntax error in doctest
W291: trailing whitespace
W391: blank line at end of file
W601: .has_key() is deprecated, use in

As you can see, some errors are really easy to fix but are too many for us, so please, we desperately need your help, help us!

The following is how we expect the community can contribute code into libturpial via Pull Requests.

1) If you don’t have a Github account, please create one first.

2) Fork our project

3) Install Git, after that you should setup your name and email:

$ git config --global user.name "Your Name, not your Github nickname"
    $ git config --global user.email "you@example.com"

4) Set your local repository

$ git clone https://github.com/your_github_nickname/libturpial.git

5) Set satanas/libturpial as your upstream remote, this basically tells Git that your are referencing libturpial’s repository as your main source.

$ git remote add upstream https://github.com/satanas/libturpial.git

5.1) Update your local copy

$ git fetch upstream

6) Verify that no one else has been working on the same bug, you can check that in our issues list, in this list you can also check Pull Requests pending for the BDFL approval.

7) Working on a bug

7.1) In the first place, install tox

$ pip install tox

7.2) Then, create a branch that identifies the bug that you will begin to work on:

$ git checkout -b E231 upstream/development

In this example we are working on the bugs of the type: E231 (as indicated by our style checker, flake8)

7.3) Make some local changes and commit, repeat.

7.3.1) Delete the error code that you will begin to work from the ignore list located at the flake8 section in the tox.ini file (located at the root of the project)

Example:

# Original list:
    ignore = E126,E128,E231,E251,E261,E301

    # After we decide to work in the E231 error:
    ignore = E126,E128,E251,E261,E301

7.3.2) Execute tox -e py27 to check the current errors.

7.3.3) Fix, fix, fix…

7.3.4) Commit your changes

$ git commit -m "Fixed errors 'E231' according to flake8."

7.4) In the case that you fixed all errors of the same type, please delete the corresponding line in the tox.ini file (located at the root of the project)

7.4.1) Don’t forget to commit that.

8) Publish your work

$ git push origin E231

Please, adjust the name E231 to something more appropiate in your case.

9) Create a Pull Request and don’t hesitate to bug the main maintainer until your changes get merged and published. Last but not least, don’t forget to add yourself as an author in the AUTHORS file, located at the root of the project.

10) Enjoy your work! :-)

If you want to help us more than you did already you can check our issues list, also, you can check out the Turpial project, our light, fast and beautiful microblogging client written in Python, currently supports Twitter, and identi.ca.

You can find more details on our guide, also, in case of doubt don’t hesitate to reach us.

About libturpial

libturpial is a Python library that handles multiple microblogging protocols. It implements a lot of features and aims to support all the features for each protocol. At the moment it supports Twitter and Identi.ca and is the backend used for Turpial.

About Turpial

Turpial is an alternative client for microblogging with multiple interfaces. At the moment it supports Twitter and Identi.ca and works with Gtk and Qt interfaces.

libturpial needs your help was originally published by Milton Mazzarri at milmazz on March 10, 2014.

jQuery best practices

2014-02-24T18:20:00-06:00

After some time working with C programming language in a *NIX like operating system, recently I came back again to Web Programming, mostly working with HTML, CSS and JavaScript in the client-side and other technologies in the backend area.

The current project I’ve been working on, heavily relies on jQuery and Highcharts/Highstock libraries, I must confess that at the beginning of the project my skills in the client-side were more than rusted, so, I began reading a lot of articles about new techniques and good practices to catch up very quickly, in the meantime, I start taking some notes about “best practices”¹ that promotes a better use of jQuery², I hope you find this information useful, if you have more tips or any doubt please leave your comments at the end of this article.

The first recommendation is to use the last version of jQuery, the reason is that in new releases you will find new features, and also a good amount of bugs and performance problems are fixed.

One of the benefits to work with jQuery is that it lets you find elements inside of the DOM using a syntax similar to the CSS selectors³. But, please, take into account the following considerations.

Modern browser support getElementsByClassName, querySelector and querySelectorAll directives. However, old browser versions only offer support for getElementById and getElementByTagName directives. So, if you are only targeting recent version of browsers, you might not need anything more than what the browser offers.

One of the first tips that you need to know is this: Have preference over IDs whenever it’s possible, even in old browser versions the search based on the ID of an element is fast because the jQuery selector internally is converted to the native getElementById directive.

$("#myelement"); // Good

Avoid the tag prefix when you search for an id:

$("div#myelement"); // Bad

The example above creates an inefficient query because in the first place we traverse all the div tags in the document, after that we look up the myelement id.

In the same way, it’s redundant to nest multiple IDs in a jQuery selector:

$("#content #myelement"); // Bad

In this case always use the most specific id.

$("#myelement"); // Remember, keep it simple

Also, if you want to select multiple elements, this implies that you need to traverse all the DOM, which can generate a hit in your query performance, so, you can avoid this negative impact descending from the most near ID element, for example, imagine that you need to capture all the input elements inside of a form which id is #myform (yes, I know, this ID name sucks, remember, it’s just for example purposes)

$("#myform input") // Good
    $("#myform").find("input") // Better

Avoid the selection of elements only by class

Avoid to select an element only by its class, the major hit in performance occurs when your browser doesn’t support the native call getElementByClassName, in old versions (like IE 6/7/8 and Mozilla Firefox 2) jQuery needs to examine each element in the page to determine where is the class that we are looking for.

$(".myclass"); // Bad

One workaround that you can use is to prefix the search with the tag element associated with the class “myclass”.

$("div.myclass") // Good
    $("#container").find(".myclass") // Better

But if you are targeting only modern browsers, you better try getElementsByClassName().

See: jQuery class vs. tag qualified class selector

Cache

Whenever you need to use multiple times the object returned by a jQuery selector, please store that object in a variable, avoid the following practice:

$("#intro").css("color", "blue");
    $("#intro").css("font-size", "1.2em");
    $("#intro").text("Hello World!");

In this case you are making three queries to get the same object!, you can improve the example above as follows:

var $intro = $("#intro");
    $intro.css("color", "blue");
    $intro.css("font-size", "1.2em");
    $intro.text("Hello World!");

In the example above we store the object (cache) returned by the jQuery selector, after that we apply multiple methods over the same object.

Please note that the name of the local variable has the ‘$’ prefix, that’s not really necessary, but some JavaScript developers have adopted this convention that facilitates them to remember that local variable stores the results of a jQuery selector. If you prefer you can avoid this “convention”. The important thing here is that if you need to apply more than one method over the same object you must store this object in a local variable first.

Another advantage of storing objects in cache memory is that you can make sub- queries, just look at the following example:

<ul id="groceries">
        <li class="meat">Chicken</li>
        <li class="meat">Turkey breasts</li>
        <li class="oil">Olive oil</li>
        <li class="oil">Canola oil</li>
    </ul>

And now we apply some queries over the unordered list:

var $groceries = $("#groceries");

After that we make some sub-queries:

var $meat = $groceries.find("li.meat"),
        $oil = $groceries.find("li.oil");

The principal benefit of store jQuery objects in memory is that the subsequent queries don’t need to traverse again the DOM.

See: jQuery Cached Set

Method chaining

Look at the following example:

var $intro = $("#intro");
    $intro.css("color", "blue");
    $intro.css("font-size", "1.2em");
    $intro.text("Hello World!");

Most of the jQuery methods returns an object, that feature facilitate the method chaining over the same element:

var $intro = $("#intro");
    $intro.css("color", "blue")
          .css("font-size", "1.2em")
          .text("Hello World!");

See: jQuery chaining

Group the set of parameters over the same method

You can rearrange the previous example as this:

$intro.css({"color": "blue", "font-size": "1.2em"})
          .text("Hello World!");

This way you can reduce the number of times that you need to call the same methods over the same objects. This technique create a unique literal object that combines the set of parameters that we’ll use to pass information to the method.

Minimize the use of .append(), .insertBefore() and .insertAfter()

If you want to use the .append() method, try to avoid its use inside a loop, in the first place you can try to generate HTML strings in memory, after your cycle ends you can append your new string to the content instead of apply the .append() method inside your cycle.

Considering the following HTML structure:

<ul id="demo">
        <!-- Content added via JS -->
    </ul>

Please, avoid the following pattern:

var $demo = $("#demo"),
      elements = ["one", "two", "three"];

    $.each(elements, function(i) {
      $("<li/>").text(elements[i])
                .appendTo($demo);
    });

One approach can be this:

var $demo = $("#demo"),
        elements = ["one", "two", "three"],
        string = "";

    for (var i=0, l=elements.length; i < l; i++) {
        string += "<li>" + elements[i] + "</li>";
    }

    $demo.append(string);

Also, you can replace the .append() method with .replaceWith() in some cases:

var $demo = $("#demo"),
      elements = ["one", "two", "three"],
      string = "<ul id=\"demo\">";

    for (var i=0, l=elements.length; i < l; i++) {
      string += "<li>" + elements[i] + "</li>";
    }

    string += "</li>";

    $demo.replaceWith(string);

Event delegation

Take this HTML structure as an example:

<nav>
      <ul>
        <li id="home">Home</li>
        <li id="about">About</li>
        <li id="contact">Contact</li>
      </ul>
    </nav>

One way to manage the navigation buttons are this:

$("#home").click(function() {
      // do something
    });

    $("#about").click(function() {
        // do something
    });

    $("#contact").click(function() {
      // do something
    });

This is really terrible because you bound an event to multiple DOM elements.

You can mitigate the example above as this:

var $nav = $("nav");

    $nav.on("click", "#home", function() {
      // do something
    });

    $nav.on("click", "#about", function() {
      // do something
    });

    $nav.on("click", "#contact", function() {
      // do something
    });

In the example above we use event delegation, this means that we need to bind to a single element and intercept events as they bubble up the DOM tree.

If the previous methods do the same at the click event you can rearrange the example above as this:

var $nav = $("nav");

    $nav.on("click", "li", function() {
      // do something
    });

Remember, the idea behind event delegation is to bind to a single root element and then wait an intercept events as they bubble up the DOM tree.

Pseudo selectors

One the of the slowest jQuery selectors are pseudo and attribute selectors, so, use this selectors with precaution.

$(":visible, :hidden");
    $("[attribute=value]");

The performance hit is greater in this cases because jQuery can’t take advantage of a native call. In modern browsers querySelector() and querySelectorAll() can help us.

See: id vs. class vs. tag vs. pseudo vs. attribute selectors

$.each() or $fn.each() loops

Whenever you can, try to use a plain for (in some modern browsers forEach is even faster than for) over the jQuery $.each() function. Also, you can gain some benefits if you cache in memory the length of your container:

// Good
    for (i = 0; i < values.length; i++) {
        // do something
    }
    // Better
    for (var i = 0, l = values.length; i < l; i++) {
        // do something
    }

See: Nesteds: JQuery each vs native JS for loop

References

Efficient jQuery Selectors by Craig Buckler.
jQuery Performance rules by ArtzStudio.
jQuery best practices by Stephen A. Thomas.
jQuery best practices by Greg Franko.
jQuery proven performance tips & tricks by Addy Osmani.
DOM Core

Please take this “best practices” with a grain of salt, do your research and see if this recommendations applies in your web clients, in my case, I need to provide support for some older browsers (IE 7/8/9 mostly). ↩
As a side note, besides jQuery nowadays are used by a large percentage of sites, according to W3Techs, jQuery now runs on every second website (2012). However, currently exists a trend that states that you need to avoid jQuery when it’s possible, so, whenever it’s possible try to use native JavaScript, one example of this trend is You Might Not Need jQuery website. ↩
You might find useful some other alternatives as qwery and Sizzle. ↩

jQuery best practices was originally published by Milton Mazzarri at milmazz on February 24, 2014.

MongoDB University: M101P

2014-02-17T02:00:00-06:00

A finales del año pasado finalice satisfactoriamente el curso en línea M101P: MongoDB for Python Developers de MongoDB University (otrora conocido como 10gen Education). Sin embargo, no me había tomado el tiempo para compartirles la experiencia, sino hasta ahora.

Cualquier persona sin práctica en el área puede tomar este curso, pues es un abreboca al mundo detrás de MongoDB y explora un buen número de temas relacionados a esta base de datos NoSQL. Aunque está orientado a desarrolladores en Python lo exigido por el curso es mínimo en este lenguaje, incluso dentro de los temas está contemplado una introducción a este lenguaje. Sin embargo, para aquellos que decidan explorar otros lenguajes de programación, MongoDB University ofrece alternativas para programadores en Java, Node.js y también para DBAs.

La duración del curso es de 7 semanas, en base al conocimiento previo que se maneje de las tecnologías puede necesitar de unas 4 a 6 horas semanales de dedicación. La estructura del curso permite ver inicialmente varios videos introductorios que hacen referencia a un tópico en particular, luego podrá reforzar lo visto con una serie de quizzes, en este punto siempre es recomendable contrastar lo visto con la documentación oficial en línea y no dejar de responder todas las tareas de cada semana pues tienen un peso total del 50%, el plazo de respuesta es más que aceptable, se da una semana de plazo para responder. En la última semana será el examen final, el cual consta de 10 preguntas, con ello se obtiene el otro 50%.

En mi caso aprovechaba el tiempo al ser trasladado hacia/desde el trabajo y veía fuera de línea los videos ofrecidos por MongoDB University. Luego, al retornar a casa en las noches o los fines de semana respondía los quizzes y las asignaciones, de ese modo me fue posible lograr aprobar sin problemas el curso, además, al final recibes un certificado de aprobación, aunque lo más importante para mi fue aprender algunas cuestiones que aún desconocía de MongoDB, las semanas podrían resumirse como siguen:

En la primera semana se ve una introducción a MongoDB, se compara en cierta medida con el esquema relacional y se plasma un bosquejo del desarrollo de aplicaciones con MongoDB. También se explora el shell y se introduce la notación JSON, a partir de acá se crean arrays, documentos y subdocumentos, entre otros detalles de la especificación. También se comienza a preparar el ambiente de trabajo futuro, es decir, se explica como instalar MongoDB en diversas plataformas, así como Python, Bottle (microframework para desarrollo Web en Python) y pymongo, éste último ofrece un conjunto de herramientas para interactuar con MongoDB desde Python. Ya para finalizar las sesiones de la semana, se da una introducción al lenguaje de programación Python y manejo básico del framework Bottle.

La segunda semana se tiene mayor interacción con el shell de MongoDB, se inicia el proceso de CRUD, se podrán ejecutar consultas por medio de find, findOne. Se comienza el uso de operadores de comparación de campos como $gt y $lt, operadores lógicos como $or, $and, uso de operadores $exists, $type, conteo de consultas sobre colecciones con el método count(), uso de expresiones regulares (compatibles a las usadas en Perl) a través del operador $regex¹, consultas sobre elementos dentro de arrays con los operadores $in y $all, actualizaciones de arrays a través de $push, $pop, $pull, $pullAll y $addToSet. Además, uso de operadores de actualización $set y $unset para establecer o eliminar campos de un documento respectivamente. Actualización de documentos existentes y la posibilidad de utilizar opciones como upsert (operación que permite hacer una actualización si el documento en cuestión existe, de lo contrario, se realiza una inserción automática) o multi (actualización múltiple). Ya para finalizar la segunda semana se deja de lado un poco el shell y se comienza el mismo proceso de interacción descrito previamente pero en esta ocasión desde pymongo.

La tercera semana nos podemos encontrar con temas enfocados al área de modelado de datos, pues MongoDB ofrece un esquema flexible, incluso cada documento puede manejar un esquema dinámico. Por lo tanto, resulta conveniente estudiar las posibilidades existentes en el modelaje de datos y que la escogencia de un esquema particular apunte a cubrir los requerimientos de la aplicación, explotación de las características propias del motor de base de datos y los mecanismos comunes de obtención de dichos datos. En el transcurso de la tercera semana, se contrasta como ejemplo el modelado de datos relacional de las tablas que pueden estar asociadas a un blog y como cambia dicho modelado desde la visión no relacional, también se cubren temas como las relaciones uno a uno, uno a muchos con referencias a otros documentos, uno a muchos con documentos embebidos, en qué casos puede ser beneficioso embeber datos. Finalmente se explora GridFS para el manejo de blobs, ficheros que normalmente superen el límite de tamaño de cada documento (16MB).

El tema principal de la cuarta semana es el rendimiento, lo cual puede estar influenciado por muchos factores, desde el sistema de gestión de ficheros, hasta la memoria, CPU, tipos de discos, entre otros. Sin embargo, en esta semana se concentrarán en explorar los algoritmos que dependiendo de la situación puede ejecutar rápidamente o no las consultas. Por lo tanto, es necesario explorar conceptos básicos como índices, su creación y descubrimiento, índices con múltiples claves hasta temas como la detección de posible cuellos de botella al no utilizar índices o mala utilización de los mismos. Al finalizar se comienza a explorar los shardings, básicamente es una técnica que permite dividir largas colecciones de datos en múltiples servidores.

La quinta semana se explora una de las funcionalidades mas atractivas de MongoDB: Aggregation framework. Para los que vienen del mundo SQL puede parecerles una respuesta a la agrupación de resultados por grupos, en donde se pueden obtener sumas ($sum), conteos ($count), promedios ($avg) y otras funciones sobre un conjunto de colecciones agrupadas por ciertos valores particulares.

La sexta semana se cubren interesantes temas como la replicación y sharding. La última semana se tiene acceso a 2 casos de estudio, en particular, la primera entrevista es con Jon Hoffman (@Hoffrocket) de Foursquare y la segunda con Ryan Bubinski (@ryanbubinski) de Codecademy.

Después de las entrevistas viene el examen final, el cual cubre el 50% del curso. ¡Éxitos! y recuerde siempre reforzar lo visto en el curso con la documentación oficial, también existen recursos adicionales² en la red que podrían servirles.

Ya para finalizar quisiera decirles que se animen a intentar unirse al curso que se ofrece de MongoDB, vale la pena intentarlo y verán que son semanas bien aprovechadas.

Resalto que de llegar a necesitar hacer uso de expresiones regulares a través del operador $regex, tenga en cuenta que solo podrá hacer uso eficiente del índice cuando la expresión regular incluye el ancla de inicio de cadena: ^ (acento cincunflejo) y sea case-sensitive. ↩
Puede encontrar material de apoyo introductorio en el libro The Little MongoDB Book de Karl Seguin, también existen guías y presentaciones adicionales que pueden ayudarle a comprender aún más MongoDB, por ejemplo, esta presentación sobre distintas consultas y uso del aggregation framework para explorar datos de resultados la NBA. ↩

MongoDB University: M101P was originally published by Milton Mazzarri at milmazz on February 17, 2014.

Elixir: Primeras impresiones

2014-02-07T00:00:00-00:00

Elixir: Primeras impresiones

NOTA: Este artículo originalmente lo escribí para La Cara Oscura del Software, un blog colectivo dedicado a desarrollo de software.

Durante el segundo hangout de @rubyVE escuché a @edgar comentar sobre Elixir y en verdad me llamó la atención lo que indicaba, siempre me inquieta conocer al menos un poco sobre otros lenguajes de programación, siempre terminas aprendiendo algo, una buena lección es seguro, sobre todo por aquello de la filosofía del programador pragmático y la necesidad de invertir regularmente en tu portafolio de conocimientos.

Ahora bien, después de leer un artículo de Joe Armstrong, padre de Erlang, en donde afirmaba que tras una semana de haber usado Elixir estaba completamente entusiasmado por lo visto. Con esto era claro que se estaba presentando para mi una gran oportunidad para retomar la programación funcional con Elixir, inicié con Haskell en la Universidad en la materia de Compiladores y la verdad es que no lo he vuelto a tocar.

José Valim es un brasileño, parte del equipo core committer de Rails. Después de sufrir RSI, en su afán por encontrar qué hacer en su reposo se puso a leer el libro: Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages y allí conoció Erlang y su EVM (Erlang Virtual Machine), cierto tiempo después creo este nuevo lenguaje llamado Elixir, en donde uno de sus mayores activos es la EVM, tanto es así que de hecho no existe un costo de conversión al invocar Erlang desde Elixir y viceversa. Todo esto es seguramente es la respuesta de Valim a las limitantes físicas actuales en los procesadores o lo que se conoce también como: “se nos acabó el almuerzo gratis”, sobre todo ahora con recientes anuncios de Parallella y de Intel con los procesadores Xeon Phi.

A pesar de la horrible sintaxis de Erlang, o al menos después de leer a Damien Katz, autor original de CouchDB en What Sucks About Erlang y a Tony Arcieri, autor de Reia (otro lenguaje basado en BEAM), en su artículo The Trouble with Erlang (or Erlang is a ghetto) es fácil concluir que la sintaxis no es la más amenas de todas. Sin embargo, las inmensas habilidades que brinda Erlang para establecer sistemas concurrentes (distribuidos, tolerantes a fallas y code swapping) ha permitido llegar a mantener hasta 2 millones de conexiones TCP en un solo nodo. Es por ello que compañías como Whatsapp, Facebook, Amazon, Ericsson, Motorola, Basho (Riak) y Heroku por mencionar algunas están usando Erlang para desarrollar sus sistemas.

Rápidamente quisiera compartirles mi felicidad por haber iniciado a explorar este lenguaje. Para iniciar tu proyecto tienes un magnífico utilitario llamado mix (inspirado en Leiningen de Clojure). Mix también permite manejar las tareas más comunes como administración de dependencias de tu proyecto, compilación, ejecución de pruebas, despliegue (pronto), entre otras. Incluso puedes programar nuevas tareas, simplemente asombroso, en fin, vamos a jugar:

$ mix help
mix                 # Run the default task (current: mix run)
mix archive         # Archive this project into a .ez file
mix clean           # Clean generated application files
mix cmd             # Executes the given command
mix compile         # Compile source files
mix deps            # List dependencies and their status
mix deps.clean      # Remove the given dependencies' files
mix deps.compile    # Compile dependencies
mix deps.get        # Get all out of date dependencies
mix deps.unlock     # Unlock the given dependencies
mix deps.update     # Update the given dependencies
mix do              # Executes the tasks separated by comma
mix escriptize      # Generates an escript for the project
mix help            # Print help information for tasks
mix local           # List local tasks
mix local.install   # Install a task or an archive locally
mix local.rebar     # Install rebar locally
mix local.uninstall # Uninstall local tasks or archives
mix new             # Creates a new Elixir project
mix run             # Run the given file or expression
mix test            # Run a project's tests

Procedamos con la creación de un nuevo proyecto:

$ mix new demo
* creating README.md
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/demo.ex
* creating test
* creating test/test_helper.exs
* creating test/demo_test.exs

Your mix project was created with success.
You can use mix to compile it, test it, and more:

    cd demo
    mix compile
    mix test

Run `mix help` for more information.

La estructura del proyecto creado por mix es como sigue:

$ cd demo
$ tree
.
|-- README.md
|-- lib
|   `-- demo.ex
|-- mix.exs
`-- test
    |-- demo_test.exs
    `-- test_helper.exs

2 directories, 5 files

En mix.exs encontramos la configuración del proyecto así como sus dependencias en caso de aplicar, en lib/demo.ex ubicamos la definición del módulo que nos ayudará a estructurar posteriormente nuestro código, en test/test_demo.exs encontramos un esqueleto base para los casos de pruebas asociadas al modulo. Finalmente en test/test_helper.exs radica inicialmente el arranque del framework ExUnit.

Creemos un par de pruebas sencillas primero:

$ vim test/demo_test.exs
defmodule DemoTest do
  use ExUnit.Case

  test "factorial base case" do
    assert Demo.factorial(0) == 1
  end

  test "factorial general case" do
    assert Demo.factorial(10) == 3628800
  end

  test "map factorial" do
    assert Demo.map([6, 8, 10], fn(n) -> Demo.factorial(n) end) == [720, 40320, 3628800]
  end
end

Evidentemente al hacer “mix test” todas las pruebas fallaran, vamos a comenzar a subsanar eso:

$ vim lib/demo.ex
defmodule Demo do

def factorial(0) do
    1
end

def factorial(n) when n > 0 do
    n * factorial(n - 1)
end

end

En el par de bloques de código mostrado previamente se cubren los dos casos posibles del factorial.

Volvamos a correr las pruebas:

$ mix test       
..

  1) test map factorial (DemoTest)
     ** (UndefinedFunctionError) undefined function: Demo.map/2
     stacktrace:
       Demo.map([6, 8, 10], #Function<0.60019678 in DemoTest.test map factorial/1>)
       test/demo_test.exs:13: DemoTest."test map factorial"/1



Finished in 0.04 seconds (0.04s on load, 0.00s on tests)
3 tests, 1 failures

De las 3 pruebas programadas hemos superado dos, nada mal, continuemos, volvamos a editar nuestro módulo:

$ vim lib/demo.ex
defmodule Demo do
    def factorial(0) do
        1
    end

    def factorial(n) when n > 0 do
        n * factorial(n - 1)
    end

    def map([], _func) do
        []
    end

    def map([head|tail], func) do
        [func.(head) | map(tail, func)]
    end
end

En esta última versión se ha agregado la función map, básicamente esta función recibe una colección de datos y una función que se aplicará sobre cada uno de los elementos de la colección, para nuestros efectos prácticos la función que será pasada a map será el factorial.

Como nota adicional, los bloques de código vistos en el ejemplo anterior prefiero expresarlos de manera sucinta así, cuestión que también es posible en Elixir:

$ vim lib/demo.ex
defmodule Demo do
    @moduledoc """
    Demo module documentation, Python *docstrings* inspired.
    """
    def factorial(0), do: 1

    def factorial(n) when n > 0, do: n * factorial(n - 1)

    def map([], _func), do: []

    def map([head|tail], func), do: [func.(head) | map(tail, func)]
end

Acá se pueden apreciar conceptos como pattern matching, guard clauses, manejo de listas y docstrings (inspirado en Python). Atención, los docstrings soportan MarkDown, junto a ExDoc es posible producir sitios estáticos que extraen los docstrings a partir del código fuente.

Comprobemos los casos desde la consola interactiva iex antes de pasar de nuevo al caso automatizado:

$ iex lib/demo.ex
Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]

Interactive Elixir (0.10.2-dev) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> import Demo
nil
iex(2)> h(Demo)
# Demo

Demo module documentation, Python *docstrings* inspired.

iex(3)> Demo.factorial(10)
3628800
iex(4)> Demo.map([6, 8, 10], Demo.factorial(&1))
[720, 40320, 3628800]

Lo previo es una consola interactiva, vimos la documentación e hicimos unas pruebas manuales.

Seguro notaron que al final del ejemplo previo, al hacer el map he cambiado la forma en la que invoco a la función anónima la cual originalmente fue definida en las pruebas como fn(n) -> Demo.factorial(n) end, solamente he recurrido a un modo que permite Elixir y otros lenguajes funcionales para expresar este tipo de funciones de manera concisa, se le conoce como Partials.

Ahora corramos las pruebas automatizadas de nuevo:

$ mix test
Compiled lib/demo.ex
Generated demo.app
...

Finished in 0.04 seconds (0.04s on load, 0.00s on tests)
3 tests, 0 failures

Con eso hemos pasado los casos de pruebas.

En este caso particular, prefiero que las pruebas sean autocontenidas en el módulo, además, no recurrimos a fixtures ni nada por el estilo, así que vamos a cambiar el código para que soporte doctest

$ vim lib/demo.ex
defmodule Demo do
    @moduledoc """
    Demo module documentation, Python *docstrings* inspired.
    """

    @doc """
    Some examples

    iex> Demo.factorial(0)
    1

    iex> Demo.factorial(10)
    3628800

    iex> Demo.map([6, 8, 10], Demo.factorial(&1))
    [720, 40320, 3628800]
    """
    def factorial(0), do: 1

    def factorial(n) when n > 0, do: n * factorial(n - 1)

    def map([], _func), do: []

    def map([head|tail], func), do: [func.(head) | map(tail, func)]
end

Dado lo anterior ya no es necesario tener las pruebas aparte, por lo que reduzco:

$ vim test/demo_test.exs
defmodule DemoTest do
  use ExUnit.Case
  doctest Demo
end

Comprobamos la equivalencia:

$ mix test              
...

Finished in 0.06 seconds (0.06s on load, 0.00s on tests)
3 tests, 0 failures

Simplemente hermoso, cabe resaltar que lo mencionado es solo rascar un poco la superficie de Elixir :-)

Ah, por cierto, ya para finalizar, José Valim está apuntando el desarrollo de Elixir y Dynamo (framework) a la Web, lo ha dejado claro, por eso he visto que algunos programadores Rails están “echándole un ojo” a Elixir, al menos eso es lo que concluyo de los elixir-issues en Github, el reciente screencast de Peepcode (vale la pena comprarlo) y los libros que se avecinan de Dave Thomas y Simon St. Laurent.

Quizá en una nueva oportunidad hablemos de Macros, pase de mensajes entre procesos, Protocolos (inspirados en Clojure protocols), Reducers (inspirados también en Clojure Reducers), HashDict, el hermoso y *nix like operador pipeline (|>), mejorar nuestra implementación de la función map para que haga los cálculos de manera concurrente, entre otros.

Espero hayan disfrutado la lectura, que este artículo sirva de abreboca y les anime a probar Elixir.

Elixir: Primeras impresiones was originally published by Milton Mazzarri at milmazz on September 23, 2013.

Python: ¿Cómo puedo comenzar a programar?

2012-11-12T02:30:07-06:00

Hay mucha documentación sobre el lenguaje de programación Python, tal vez eso haya quedado claro en el artículo anterior.

Sin embargo, se puede iniciar revisando el tutorial oficial de Python. El libro Learn Python the Hard Way (LPTHW) de Zed Shaw está muy bueno para comenzar, tiene una buena cantidad de ejercicios. LPTHW no es el único libro de fácil o libre acceso, también podrá disponer de los siguientes:

Google también ofrece muy buen material a través de Google Python Class, no olvide revisarlo. Otros recursos muy interesantes son los del MIT Open Courseware A Gentle Introduction to Programming Using Python y Code Like a Pythonista: Idiomatic Python. Lamentablemente libros en español recuerdo pocos, el último que llegue a revisar fue Python para todos, también alcance a revisar un libro de la Universidad de Jaume, muestran una grata introducción a la programación con Python.

Considero que la mejor manera de engancharte con un lenguaje es trabajar en un proyecto personal o practicando, si no se te ocurre nada por el momento, puedes comenzar vía Learn Street, Code Academy, Python Challenge, Project Euler. Si quieres ver la ejecución paso a paso de tus programas en Python no dejes de revisar Python Tutor. El gran dilema: ¿Python 2 o 3? Si tienes un objetivo con Python y la versión 3 puede cubrirlo perfecto, pero ten claras las reglas del juego antes de escoger la versión 2.x o 3.x, este artículo te puede aclarar el panorama.

Python: ¿Cómo puedo comenzar a programar? was originally published by Milton Mazzarri at milmazz on November 12, 2012.

Python: El comienzo

2014-02-07T00:00:00-00:00

¿Qué es Python?

Lenguaje de programación orientado a objetos, interactivo e interpretado.
Estructuras de datos alto nivel, dinámicamente tipado.
Aumenta la productividad de desarrollo en comparación con otros lenguajes estáticamente tipados.
Multiplataforma:
- El interprete CPython puede ejecutarse nativamente en muchas plataformas (esto incluye Windows, OS X, GNU/Linux, entre otras).
- Jython corre dentro de la Java Virtual Machine.
- IronPython está orientado a plataformas .NET y Mono.
- PyPy es una implementación enfocada en el rendimiento con un compilador Just In Time
- Stackless es una rama de CPython con soporte a microthreads

Python es un lenguaje dinámicamente tipado, esto quiere decir que el tipo de cada variable se conoce en tiempo de ejecución, a su vez, Python es un lenguaje fuertemente tipado, lo anterior implica que si usted posee una variable de tipo entero no puede tratarla como una cadena de texto a menos que usted realice la conversión de manera explícita previamente.

CPython es la primera implementación del lenguaje Python, también es la de mayor uso a nivel mundial, dicha implementación esta escrita en el lenguaje de programación C. Esta es la implementación que todos conocemos al referirnos al lenguaje de programación Python, pero en aquellos escenarios en donde es necesario distinguirla de otras implementaciones alternativas se le conoce como CPython.

¿Por qué usar Python?

En uno de los primeros libros que leí sobre Python, Mark Lutz resumía estos puntos de la siguiente manera:

Calidad del software

Para muchos, Python se enfoca en la legibilidad, coherencia, y la calidad del software en general. Al ofrecer un diseño legible, el proceso de mantenimiento se hace más fácil y rápido.

Incremento en la productividad del desarrollo

El código en Python regularmente es de 1/3 a 1/5 el tamaño de un código equivalente escrito en C++ o Java. Esto quiere decir que el desarrollador tendrá menos que escribir, menos que depurar, y menos que mantener después de todo. Además, los programas en Python pueden ejecutarse inmediatamente, sin tener que recurrir a los largos y tediosos pasos de compilación y enlazado.

Portabilidad

La mayoría de los programas en Python se pueden ejecutar indistintamente en la mayoría de las plataformas. Por otra parte, Python le ofrece múltiples opciones para desarrollar interfaces gráficas de usuario portables, entre ellas contamos con: TkInter, wxPython, PyGTK, PyQT, WxWidgets. Además, cuenta con módulos de accesos a base de datos, sistemas Web, entre otros.

Integración de componentes

Los scripts en Python fácilmente pueden comunicarse con otras partes de una aplicación, usando una variedad de mecanismos para la integración. Actualmente, Python puede invocar librerías en C y C++, puede ser llamado desde programas en C y C++, puede integrarse con componentes en Java, puede comunicarse sobre Corba y .NET, puede interactuar en la red con interfaces como SOAP, protocolo estándar que define cómo dos objetos en diferentes procesos puede comunicarse por medio del intercambio de datos en XML, REST y XML-RPC.

Diversión

Ya que Python es tan fácil de usar y le brinda un gran conjunto de herramientas, puede hacer el acto de programar una tarea muy placentera.

¿Qué es el Zen de Python?

A través de Zen de Python puede conocer los principios del diseño y la filosofía detrás del lenguaje de programación Python. También resulta útil para comprender y utilizar el lenguaje.

1 >>>  import this
2     The Zen of Python, por Tim Peters

Obtendrá por respuesta algo como:

Hermoso es mejor que Feo.
Explícito es mejor que Implícito.
Simple es mejor que Complejo.
Complejo es mejor que Complicado.
Lineal es mejor que Cruzado.
Escaso es mejor que Denso.
Poder leer el código, cuenta.
Los Casos Especiales no son tan especiales como para romper reglas.
Lo Práctico le gana a Lo Puro.
Los Errores no deben pasar desapercibidos.
A menos de que Explícitamente se silencien.
En la ambigüedad, rehusa el Adivinar.
Sólo debería haber una, y preferiblemente Una, manera
obvia de hacer las cosas.
Aunque esa manera no se obvia al principio, a menos que seas (Dutch).
Ahora es mejor que Nunca.
A pesar de que Nunca es mejor que Ahora Mismo.
Si la implementación es difícil de explicar, es probable
que sea una mala idea.
Si la implementación es fácil de explicar, es probable
que sea una buena idea.
Namespaces son una Gran idea — Hagamos mas de esas.

¿Qué tipos de aplicaciones puedo desarrollar en Python?

Python es un lenguaje multipropósito, basta darle una revisión al Python Package Index para ver una muestra de las aplicaciones desarrolladas con este hermoso lenguaje.

Sin embargo, podemos ubicar el dominio de las aplicaciones en Python en:

Herramientas y utilidades para la administración de sistemas

Python provee interfaces para servicios de Sistemas Operativos, desde un programa escrito en Python podemos buscar ficheros y árboles de directorios, cargar otros programas, realizar procesamiento paralelo, entre otras cosas muy interesantes.

GUI (Interfaz gráfica de usuario)

Python viene con una interfaz estándar orientada por objetos llamada TkInter, la cual permite a los programas escritos en Python implementar GUIs con una interfaz nativa del Sistema Operativo. Además, pueden encontrarse implementaciones más atractivas como: wxWidgets, GTK+, Qt (pyqt o pyside), entre otras.

Internet

Python viene con módulos estándar para Internet que permiten a los programas realizar una gran variedad de tareas en redes, tanto en el modo servidor como cliente. Los scripts en Python pueden comunicarse sobre sockets; transferir ficheros vía FTP; procesar ficheros XML, JSON, también permite establecer comunicaciones sobre XML-RPC, SOAP, telnet, [hermosas APIs para la interacción con HTTP y más.

En el ámbito Web se pueden encontrar variadas opciones, desde CGI básicos, pasando por avanzados manejadores de contenido hasta frameworks de desarrollo como Django, Flask y microframeworks como Bottle.

Bases de Datos

Python ofrece módulos para interactuar con la mayoría de las bases de datos relacionales, existen interfaces en Python: PostgreSQL, MySQL, Sybase, Oracle, Informix, ODBC, y más. También ofrece un API estándar para la interacción con Bases de Datos. Es claro entonces poder observar proyectos que brindan una interacción de alto nivel con bases de datos como los ORM SQLAlchemy o DAL.

También hay cabida para el mundo NoSQL en Python, donde hay soporte para: Cassandra, Riak, MongoDB, CouchDB y Redis por mencionar solo algunas.

Juegos, Imágenes, AI, XML

Se pueden realizar fácilmente gráficos y programación de juegos en Python con la librería pygame, PyKyra, pyglet, cocos2d y más, incluso puedes participar en el concurso PyWeek.

También se puede incluir en el largo listado el procesamiento de imágenes con el paquete PIL y otros. Programación de Inteligencia Artificial con simuladores de redes neuronales y Sistemas Expertos, análisis de ficheros XML con el paquete de bibliotecas xml. Python soporta a traves de extensiones Programación numérica avanzada, NumPy/SciPy vuelve a Python en una sofisticada herramienta de fácil uso para la programación numérica y científica. De manera adicional, Python puede soportar animaciones,visualización 2D y 3D, Biología Molecular, cálculo estadístico (RPy) y más.

¿Quienes usan Python?

La lista incluye a grandes en el mundo de tecnología, un excelente resumen se puede encontrar en el listado de casos de éxito y citas del portal oficial de Python.

¿Cómo puedo mantenerme al día?

Son muchas las fuentes de información sobre Python, algunas interesantes son las siguientes:

En el siguiente artículo de esta serie espero poder listar algunos recursos que pueden ser de ayuda a los principiantes en este fabuloso mundo de la programación con Python.

Python: El comienzo was originally published by Milton Mazzarri at milmazz on November 09, 2012.

Fortaleciendo nuestras contraseñas

2011-12-30T20:53:55-06:00

Si una de las promesas que tiene para este cierre de año es fortalecer las contraseñas en sus equipos personales, cambiarlas mensualmente y no repetir la misma contraseña en al menos doce cambios. En este artículo se le explicará como hacerlo sin tener que invertir una uva en ello, todo esto gracias al paquete libpam-cracklib en Debian, el procedimiento mostrado debe aplicarse a otras distribuciones derivadas de Debian.

Pareciese lógico que algunas de las mejores prácticas para el fortalecimiento de las contraseñas son las siguientes:

Cambiar las contraseñas periódicamente.
Establecer una longitud mínima en las contraseñas.
Establecer buenas reglas para las nuevas contraseñas, es decir, mezcla entre letras mayúsculas, minúsculas, dígitos y caracteres alfanuméricos.
Mantener un histórico de las contraseñas usadas previamente, de ese modo, alentamos a los usuarios establecer nuevas contraseñas.
Indicarle a los usuarios que es inaudito que se anoten las contraseñas en un post-it y se dejen pegadas en los monitores o incluso en las gavetas de sus archivadores.

El primer paso es instalar el paquete libpam-cracklib

# apt-get install libpam-cracklib

A partir de la versión 1.0.1-6 de PAM se recomienda manejar la configuración vía pam-auth-update. Por lo tanto, por favor tome un momento y lea la sección 8 del manual del comando pam-auth-update para aclarar su uso y ventajas.

$ man 8 pam-auth-update

Ahora establezca una configuración similar a la siguiente, vamos primero con la exigencia en la fortaleza de las contraseñas, para ello edite o cree el fichero /usr/share/pam-configs/cracklib.

Name: Cracklib password strength checking
Default: yes
Priority: 1024
Conflicts: unix-zany
Password-Type: Primary
Password:
	requisite	pam_cracklib.so retry=3 minlen=8 difok=3
Password-Initial:
	requisite	pam_cracklib.so retry=3 minlen=8 difok=3

NOTA: Le recomiendo leer la sección 8 del manual de pam_cracklib para encontrar un mayor numero de opciones de configuración. Esto es solo un ejemplo.

En versiones previas el modulo pam_cracklib hacia uso del fichero /etc/security/opasswd para conocer si la propuesta de cambio de contraseña no había sido utilizada previamente. Dicha funcionalidad ahora corresponde al nuevo modulo pam_pwhistory

Definamos el funcionamiento de pam_pwhistory a través del fichero /usr/share/pam-configs/history.

Name: PAM module to remember last passwords
Default: yes
Priority: 1023
Password-Type: Primary
Password:
	requisite	pam_pwhistory.so use_authtok enforce_for_root remember=12 retry=3
Password-Initial:
	requisite	pam_pwhistory.so use_authtok enforce_for_root remember=12 retry=3

NOTA: Para mayor detalle de las opciones puede revisar la sección 8 del manual de pam_pwhistory

Seguidamente proceda a actualizar la configuración de PAM vía pam-auth-update.

Una vez cubierta la fortaleza de las contraseñas nuevas y de evitar la reutilización de las ultimas 12, de acuerdo al ejemplo mostrado, resta cubrir la definición de los periodos de cambio de las contraseñas.

Para futuros usuarios debemos ajustar ciertos valores en el fichero /etc/login.defs

#
# Password aging controls:
#
#       PASS_MAX_DAYS   Maximum number of days a password may be used.
#       PASS_MIN_DAYS   Minimum number of days allowed between password changes.
#       PASS_WARN_AGE   Number of days warning given before a password expires.
#
PASS_MAX_DAYS   30
PASS_MIN_DAYS   0
PASS_WARN_AGE   5

Las reglas previas no aplicaran para los usuarios existentes, pero para este tipo de usuarios podremos hacer uso del comando chage de la siguiente manera:

# chage -m 0 -M 30 -W 5 ${user}

Donde el valor de ${user} debe ser reemplazo por el username.

Fortaleciendo nuestras contraseñas was originally published by Milton Mazzarri at milmazz on December 30, 2011.

apt-get detrás de proxy con autenticación NTLM

2011-12-29T11:16:59-06:00

Por motivos que no vienen al caso discutir en este artículo tuve que instalar Debian GNU/Linux detrás de un proxy que aún utiliza NTLM como medio de autenticación, aunque NTLM ya no es recomendado por Microsoft desde hace años en pro de usar Kerberos.

Una vez instalada la distribución quería utilizar apt-get para actualizarla e instalar nuevos paquetes, el resultado fue que apt-get no funciona de manera transparente detrás de un proxy con autenticación NTLM. La solución fue colocar un proxy interno que esté atento a peticiones en un puerto particular en el host, el proxy interno se encargará de proveer de manera correcta las credenciales al proxy externo.

La solución descrita previamente resulta sencilla al utilizar cntlm. En principio será necesario instalarlo vía dpkg, posteriormente deberá editar los campos apropiados en el fichero /etc/cntlm.conf

Username
Domain
Password
Proxy

Seguidamente reinicie el servicio:

# /etc/init.d/cntlm restart

Ahora solo resta configurar apt-get para que utilice nuestro proxy interno, para ello edite el fichero /etc/apt.conf.d/02proxy

Acquire::http::Proxy "http://127.0.0.1:3128";

NOTA: Se asume que el puerto de escucha de cntlm es el 3128.

Ahora puede hacer uso correcto de apt-get:

# apt-get update
# apt-get upgrade
...

NOTA FINAL: Es evidente que cualquier comando o herramienta que necesite autenticarse contra el proxy externo deberá configurarlo para que utilice el proxy interno, lo explicado en este artículo no solo aplica para el comando apt-get.

apt-get detrás de proxy con autenticación NTLM was originally published by Milton Mazzarri at milmazz on December 29, 2011.

Enviando correos con Perl

2011-09-21T12:28:02-05:00

Regularmente los administradores de sistemas requieren notificar, vía correo electrónico, a sus usuarios de ciertos cambios o nuevos servicios disponibles. La experiencia me ha indicado que el usuario aprecia más un correo personalizado que uno general. Sin embargo, lograr lo primero de manera manual es bastante tedioso e ineficaz. Por lo tanto, es lógico pensar en la posibilidad de automatizar el proceso de envío de correos electrónicos personalizados, en este artículo, explicaré una de las tantas maneras de lograrlo haciendo uso del lenguaje de programación Perl.

En CPAN podrá encontrar muchas alternativas, recuerde el principio TIMTOWTDI. Sin embargo, la opción que más me atrajo fue MIME::Lite:TT, básicamente este módulo en Perl es un wrapper de MIME::Lite que le permite el uso de plantillas, vía Template::Toolkit, para el cuerpo del mensaje del correo electrónico. También puede encontrar MIME::Lite::TT::HTML que le permitirá enviar correos tanto en texto sin formato (MIME::Lite::TT) como en formato HTML. Sin embargo, estoy en contra de enviar correos en formato HTML, lo dejo a su criterio.

Una de las ventajas de utilizar Template::Toolkit para el cuerpo del mensaje es separar en capas nuestra script, si se observa desde una versión muy simplificada del patrón MVC, el control de la lógica de programación reside en el script en Perl, la plantilla basada en Template Toolkit ofrecería la vista de los datos, de modo tal que podríamos garantizar que la presentación está separada de los datos, los cuales pueden encontrarse desde una base de datos o un simple fichero CSV. Otra ventaja evidente es el posible reuso de componentes posteriormente.

Un primer ejemplo del uso de MIME::Lite:TT puede ser el siguiente:

#!/usr/bin/perl

use strict;
use warnings;
use MIME::Lite::TT;

my %options;
$options{INCLUDE_PATH} = '/home/jdoe/example';

my %params;
$params{first_name} = "Milton";
$params{last_name}  = "Mazzarri";
$params{username}   = "milmazz";
$params{groups}     = "sysadmin";

my $msg = MIME::Lite::TT->new(
    From        => 'jdoe@example.com',
    To          => 'milmazz@example.com',
    Charset     => 'utf8',
    TimeZone    => 'America/Caracas',
    Subject     => 'Example',
    Template    => 'example.txt.tt',
    TmplOptions => \%options,
    TmplParams  => \%params,
);

$msg->send();

Y el cuerpo del correo electrónico, lo que en realidad es una plantilla basada en Template::Toolkit, vendría definido en el fichero example.txt.tt de la siguiente manera:

Hola [% last_name %], [% first_name %].

Tu nombre de usuario es [% username %].

Un saludo, feliz día.

Su querido BOFH de siempre.

En el script en Perl mostrado previamente podemos percatarnos que los datos del destinario se encuentran inmersos en la lógica. Por lo tanto, el siguiente paso sería desacoplar esta parte de la siguiente manera:

#!/usr/bin/perl

use strict;
use warnings;
use MIME::Lite::TT;
use Class::CSV;

my %options;
$options{INCLUDE_PATH} = '/home/jdoe/example';

# Lectura del fichero CSV
my $csv = Class::CSV->parse(
    filename       => 'example.csv',
    fields         => [qw/last_name first_name username email/],
    csv_xs_options => { binary => 1, }
);

foreach my $line ( @{ $csv->lines() } ) {
    my %params;

    $params{first_name} = $line->first_name();
    $params{last_name}  = $line->last_name();
    $params{username}   = $line->username();

    my $msg = MIME::Lite::TT->new(
        From        => 'jdoe@example.com',
        To          => $line->email(),
        Charset     => 'utf8',
        TimeZone    => 'America/Caracas',
        Subject     => 'Example',
        Template    => 'example.txt.tt',
        TmplOptions => \%options,
        TmplParams  => \%params,
    );

    $msg->send();
}

Ahora los datos de los destinarios los extraemos de un fichero en formato CSV, en este ejemplo, el fichero en formato CSV lo hemos denominado example.csv.

Cabe aclarar que $msg->send() realiza el envío por medio de Net::SMTP y podrá usar las opciones que se describen en dicho módulo. Sin embargo, si necesita establecer una conexión SSL con el servidor SMTP es oportuno recurrir a Net::SMTP::SSL:

#!/usr/bin/perl

use strict;
use warnings;
use MIME::Lite::TT;
use Net::SMTP::SSL;
use Class::CSV;

my $from = 'jdoe@example.com';
my $host = 'mail.example.com';
my $user = 'jdoe';
my $pass = 'example';

my %options;
$options{INCLUDE_PATH} = '/home/jdoe/example';

# Lectura del fichero CSV
my $csv = Class::CSV->parse(
    filename       => 'example.csv',
    fields         => [qw/last_name first_name username email/],
    csv_xs_options => { binary => 1, }
);

foreach my $line ( @{ $csv->lines() } ) {
    my %params;

    $params{first_name} = $line->first_name();
    $params{last_name}  = $line->last_name();
    $params{username}   = $line->username();

    my $msg = MIME::Lite::TT->new(
        From        => $from,
        To          => $line->email(),
        Charset     => 'utf8',
        TimeZone    => 'America/Caracas',
        Subject     => 'Example',
        Template    => 'example.txt.tt',
        TmplOptions => \%options,
        TmplParams  => \%params,
    );

    my $smtp = Net::SMTP::SSL->new( $host, Port => 465 )
      or die "No pude conectarme";
    $smtp->auth( $user, $pass )
      or die "No pude autenticarme:" . $smtp->message();
    $smtp->mail($from)                 or die "Error:" . $smtp->message();
    $smtp->to( $line->email() )        or die "Error:" . $smtp->message();
    $smtp->data()                      or die "Error:" . $smtp->message();
    $smtp->datasend( $msg->as_string ) or die "Error:" . $smtp->message();
    $smtp->dataend()                   or die "Error:" . $smtp->message();
    $smtp->quit()                      or die "Error:" . $smtp->message();
}

Note en este último ejemplo que la representación en cadena de caracteres del cuerpo del correo electrónico viene dado por $msg->as_string.

Para finalizar, es importante mencionar que también podrá adjuntar ficheros de cualquier tipo a sus correos electrónicos, solo debe prestar especial atención en el tipo MIME de los ficheros que adjunta, es decir, si enviará un fichero adjunto PDF debe utilizar el tipo application/pdf, si envía una imagen en el formato GIF, debe usar el tipo image/gif. El método a seguir para adjuntar uno o más ficheros lo dejo para su investigación ;)

Enviando correos con Perl was originally published by Milton Mazzarri at milmazz on September 21, 2011.

Construyendo de manera efectiva y rápida imágenes ISO de Debian con jigdo

2010-12-02T08:04:39-06:00

Si usted desea el conjunto de CD o DVD para instalar Debian, tiene muchas posibilidades, desde la compra de los mismos, muchos de los vendedores contribuyen con Debian. También puede realizar descargas vía HTTP/FTP, vía torrent o rsync. Pero en este artículo se discutirá sobre un método para construir las imágenes ISO de Debian de manera eficiente, sobretodo si cuenta con un repositorio local de paquetes, dicho método se conoce de manera abreviada como jigdo o Jigsaw Download.

Las ventajas que ofrece jigdo están bien claras en el portal de Debian, cito:

¿Por qué jigdo es mejor que una descarga directa?

¡Porque es más rápido! Por varias razones, hay muchas menos réplicas para imágenes de CDs que para el archivo «normal» de Debian. Consecuentemente, si descarga desde una réplica de imágenes de CD, esa réplica no sólo estará más lejos de su ubicación, además estará sobrecargada, especialmente justo después de una publicación.

Además, algunos tipos de imágenes no están disponibles para descarga completa como .iso porque no hay suficiente espacio en nuestros servidores para alojarlas.

Considero que la pregunta pertinente ahora es: ¿Cómo descargo la imagen con jigdo?.

En primer lugar, instalamos el paquete jigdo-file.

# aptitude install jigdo-file

Mi objetivo era generar los 2 primeros CD para Debian Lenny, para la fecha de publicación de este artículo la versión más reciente es la 5.0.7. La lista de imágenes oficiales para jigdo las puede encontrar acá.

milmazz@manaslu /tmp $ cat files
http://cdimage.debian.org/debian-cd/5.0.7/i386/jigdo-cd/debian-507-i386-CD-1.jigdo
http://cdimage.debian.org/debian-cd/5.0.7/i386/jigdo-cd/debian-507-i386-CD-1.template
http://cdimage.debian.org/debian-cd/5.0.7/i386/jigdo-cd/debian-507-i386-CD-2.jigdo
http://cdimage.debian.org/debian-cd/5.0.7/i386/jigdo-cd/debian-507-i386-CD-2.template
milmazz@manaslu /tmp $ wget -c -i files
--2010-12-02 12:39:52--  http://cdimage.debian.org/debian-cd/5.0.7/i386/jigdo-cd/debian-507-i386-CD-1.jigdo
Resolving cdimage.debian.org... 130.239.18.163, 130.239.18.173, 2001:6b0:e:2018::173, ...
Connecting to cdimage.debian.org|130.239.18.163|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 31737 (31K) [text/plain]
Saving to: `debian-507-i386-CD-1.jigdo'

100%[===================================================================================================================>] 31.737      44,7K/s   in 0,7s

...

FINISHED --2010-12-02 12:50:15--
Downloaded: 4 files, 27M in 10m 21s (44,7 KB/s)
milmazz@manaslu /tmp $ ls
debian-507-i386-CD-1.jigdo  debian-507-i386-CD-1.template  debian-507-i386-CD-2.jigdo  debian-507-i386-CD-2.template files

Una vez descargados los ficheros necesarios, es hora de ejecutar el comando jigdo-lite, siga las instrucciones del asistente.

milmazz@manaslu ~ $ jigdo-lite debian-507-i386-CD-2.jigdo

Jigsaw Download "lite"
Copyright (C) 2001-2005  |  jigdo@
Richard Atterer          |  atterer.net
Loading settings from `/home/milmazz/.jigdo-lite'

-----------------------------------------------------------------
Images offered by `debian-507-i386-CD-2.jigdo':
1: 'Debian GNU/Linux 5.0.7 "Lenny" - Official i386 CD Binary-2 20101127-16:55 (20101127)' (debian-507-i386-CD-2.iso)

Further information about `debian-507-i386-CD-2.iso':
Generated on Sat, 27 Nov 2010 17:02:14 +0000

-----------------------------------------------------------------
If you already have a previous version of the CD you are
downloading, jigdo can re-use files on the old CD that are also
present in the new image, and you do not need to download them
again. Mount the old CD ROM and enter the path it is mounted under
(e.g. `/mnt/cdrom').
Alternatively, just press enter if you want to start downloading
the remaining files.
Files to scan:

El comando despliega información acerca de la imagen ISO que generará, en este caso particular, debian-507-i386-CD-2.iso. Además, jigdo-lite puede reutilizar ficheros que se encuentren en CD viejos y así no tener que descargarlos de nuevo. Sin embargo, este no era mi caso así que presione la tecla ENTER.

-----------------------------------------------------------------
The jigdo file refers to files stored on Debian mirrors. Please
choose a Debian mirror as follows: Either enter a complete URL
pointing to a mirror (in the form
`ftp://ftp.debian.org/debian/'), or enter any regular expression
for searching through the list of mirrors: Try a two-letter
country code such as `de', or a country name like `United
States', or a server name like `sunsite'.
Debian mirror [http://debian.example.com/debian/]:

En esta fase jigdo-lite solicita la dirección URL completa de un repositorio, aproveche la oportunidad de utilizar su repositorio local si es que cuenta con uno. Luego de presionar la tecla ENTER es tiempo de relajarse y esperar que jigdo descargue todos y cada uno de los ficheros que componen la imagen ISO.

Luego de descargar los paquetes y realizar las operaciones necesarias para la construcción de la imagen ISO jigdo le informará los resultados.

FINISHED --2010-12-01 14:43:50--
Downloaded: 6 files, 2,5M in 1,8s (1,39 MB/s)
Found 6 of the 6 files required by the template
Successfully created `debian-507-i386-CD-2.iso'

-----------------------------------------------------------------
Finished!
The fact that you got this far is a strong indication that `debian-507-i386-CD-2.iso'
was generated correctly. I will perform an additional, final check,
which you can interrupt safely with Ctrl-C if you do not want to wait.

OK: Checksums match, image is good!

Ahora bien, haciendo uso de un repositorio local, es bueno preguntarse en cuanto tiempo aproximadamente puedes construir tu imagen ISO, en mi caso el tiempo de construcción de debian-507-i386-CD-2.iso fue de:

milmazz@manaslu ~ $ time jigdo-lite debian-507-i386-CD-2.jigdo

...

real	8m35.704s
user	0m13.101s
sys	0m16.569s

Nada mal, ¿no les parece?.

Referencias

Construyendo de manera efectiva y rápida imágenes ISO de Debian con jigdo was originally published by Milton Mazzarri at milmazz on December 02, 2010.

Generar reporte en formato CSV de tickets en Trac desde Perl

2010-11-17T11:12:06-06:00

El día de hoy recibí una llamada telefónica de un compañero de labores en donde me solicitaba con cierta preocupación un “pequeño” reporte del estado de un listado de tickets que recién me había enviado vía correo electrónico puesto que no contaba con conexión a la intranet, al analizar un par de tickets me dije que no iba a ser fácil realizar la consulta desde el asistente que brinda el mismo Trac. Así que inmediatamente puse las manos sobre un pequeño script en Perl que hiciera el trabajo sucio por mí.

Es de hacer notar que total de tickets a revisar era el siguiente:

$ wc -l tickets
126 tickets

Tomando en cuenta el resultado previo, era inaceptable hacer dicha labor de manera manual. Por lo tanto, confirmaba que realizar un script era la vía correcta y a la final iba a ser más divertido.

Tomando en cuenta que el formato de entrada era el siguiente:

#3460
#3493
...

El formato de la salida que esperaba era similar a la siguiente:

3460,"No expira la sesión...",closed,user

Básicamente el formato implica el id, sumario, estado y responsable asociado al ticket.

Net::Trac le ofrece una manera sencilla de interactuar con una instancia remota de Trac, desde el manejo de credenciales, consultas, revisión de tickets, entre otros. A la vez, se hace uso del módulo Class::CSV el cual le ofrece análisis y escritura de documentos en formato CSV.

#!/usr/bin/perl 

use warnings;
use strict;

use Net::Trac;
use Class::CSV;

# Estableciendo la conexion a la instancia remota de Trac
my $trac = Net::Trac::Connection->new(
    url      => 'http://trac.example.com/project',
    user     => 'user',
    password => 'password'
);

# Construccion del objecto CSV y definicion de opciones
my $csv = Class::CSV->new(
    fields         => [qw/ticket sumario estado responsable/],
    line_separator => "\r\n",
    csv_xs_options => { binary => 1, }    # Manejo de caracteres non-ASCII
);

# Nos aseguramos que el inicio de sesion haya sido exitoso
if ( $trac->ensure_logged_in ) {
    my $ticket = Net::Trac::Ticket->new( connection => $trac );

    # Consultamos cada uno de los tickets indicados en el fichero de entrada
    while ( my $line = <> ) {
        chomp($line);
        if ( $line =~ m/^#\d+$/ ) {
            $line =~ s/^#(\d+)$/$1/;
            $ticket->load($line);

            $csv->add_line(
                {
                    ticket      => $ticket->id,
                    sumario     => $ticket->summary,
                    estado      => $ticket->status,
                    responsable => $ticket->owner
                }
            );
        }
        else {
            print "[INFO] La linea no cumple el formato requerido: $line\n";
        }
    }
    $csv->print();
}
else {
    print "No se pudieron asegurar las credenciales";
}

La manera de ejecutar el script es la siguiente:

$ perl trac_query.pl tickets

En donde trac_query.pl es el nombre del script y tickets es el fichero de entrada.

Debo aclarar que el script carece de comentarios, mea culpa. Además, el manejo de opciones vía linea de comandos es inexistente, si desea mejorarlo puede hacer uso de Getopt::Long.

Cualquier comentario, sugerencia o corrección es bienvenida.

Generar reporte en formato CSV de tickets en Trac desde Perl was originally published by Milton Mazzarri at milmazz on November 17, 2010.

Instalando dependencias no-libres de JAVA en ambientes pbuilder

2010-11-15T11:14:37-06:00

El día de hoy asumí la construcción de unos paquetes internos compatibles con Debian 5.0 (a.k.a. Lenny) que anteriormente eran responsabilidad de ex-compañeros de labores. El paquete en cuestión posee una dependencia no-libre, sun-java6-jre. En este artículo se describirá como lograr adecuar su configuración de pbuilder para la correcta construcción del paquete.

Asumiendo que tiene un configuración similar a la siguiente:

$ cat /etc/pbuilderrc
MIRRORSITE=http://example.com/debian
DEBEMAIL="Maintainer Name <mail@example.com>"
DISTRIBUTION=lenny
DEBOOTSTRAP="cdebootstrap"
COMPONENTS="main contrib non-free"

Para mayor información sobre estas opciones sírvase leer:

$ man 5 pbuilderrc

Mientras intenta compilar su paquete en el ambiente proporcionado por pbuilder el proceso fallará ya que no se mostró la ventana para aceptar la licencia de JAVA. Podrá observar en el registro de la construcción del build un mensaje similar al siguiente:

Unpacking sun-java6-jre (from .../sun-java6-jre_6-20-0lenny1_all.deb) ...

sun-dlj-v1-1 license could not be presented
try 'dpkg-reconfigure debconf' to select a frontend other than noninteractive

dpkg: error processing /var/cache/apt/archives/sun-java6-jre_6-20-0lenny1_all.deb (--unpack):
subprocess pre-installation script returned error exit status 2

Para evitar esto altere la configuración del fichero pbuilderrc de la siguiente manera:

$ cat /etc/pbuilderrc
MIRRORSITE=http://example.com/debian
DEBEMAIL="Maintainer Name <mail@example.com>"
DISTRIBUTION=lenny
DEBOOTSTRAP="cdebootstrap"
COMPONENTS="main contrib non-free"
export DEBIAN_FRONTEND="readline"

Una vez alterada la configuración podrá interactuar con las opciones que le ofrece debconf.

Ahora bien, si usted constantemente tiene que construir paquetes con dependencias no-libres como las de JAVA, es probable que le interese lo que se menciona a continuación.

Si lee detenidamente la página del manual de pbuilder en su sección 8 podrá encontrar lo siguiente:

$ man 8 pbuilder
...
--save-after-login
--save-after-exec
Save the chroot image after exiting from the chroot instead of deleting changes.  Effective for login and execute session.
...

Por lo tanto, usaremos esta funcionalidad que ofrece pbuilder para insertar valores por omisión en la base de datos de debconf para que no se nos pregunte si deseamos aceptar la licencia de JAVA:

# pbuilder login --save-after-login
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /dev/pts filesystem
I: Mounting /var/cache/pbuilder/ccache
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: entering the shell
File extracted to: /var/cache/pbuilder/build//27657

pbuilder:/# cat > java-license << EOF
> sun-java6-bin shared/accepted-sun-dlj-v1-1 boolean true
> sun-java6-jdk shared/accepted-sun-dlj-v1-1 boolean true
> sun-java6-jre shared/accepted-sun-dlj-v1-1 boolean true
> EOF
pbuilder:/# debconf-set-selections < java-license
pbuilder:/# exit
logout
I: Copying back the cached apt archive contents
I: Saving the results, modifications to this session will persist
I: unmounting /var/cache/pbuilder/ccache filesystem
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
I: creating base tarball [/var/cache/pbuilder/base.tgz]
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build//27657 and its subdirectories

Instalando dependencias no-libres de JAVA en ambientes pbuilder was originally published by Milton Mazzarri at milmazz on November 15, 2010.

Presentaciones

2010-11-12T21:38:53-06:00

Desde hace algunos meses he decidido recopilar y organizar algunas de las presentaciones que he dado hasta ahora en eventos de Software Libre, Universidades y empresas privadas.

El software que regularmente utilizo para realizar mis presentaciones es Beamer, una clase LaTeX que facilita enormente la producción de presentaciones de alta calidad, este software trabaja de la mano con pdflatex, también con dvips.

La lista de presentaciones que he recopilado hasta la fecha son las siguientes:

Análisis estático del código fuente en Python: Describe el concepto del análisis estático del código, se indica los pasos a seguir para la detección de errores mediante la herramienta Pylint, se exponen sus funcionalidades, reportes y se muestran ejemplos para corregir los errores encontrados por la herramienta.
Desarrollo colectivo en Turpial: Describe la visión del cliente para Twitter Turpial, sus funcionalidades actuales, el uso de herramientas como Transifex, PyBabel, Distutils, Sphinx, dichas herramientas facilitan y mejoran la calidad del software que se desarrolla.
Canaima GNU/Linux: Una introducción, se describe la historia, definición del proyecto Canaima, principales características, procesos para colaborar, enlaces de interés, entre otros.
Novela gráfica creada con el motor Ren’Py: Relata la experiencia del desarrollo de una novela gráfica para niños de 5to. grado de educación, de acuerdo a currículo impartido en las escuelas venezolanas.
Trac: Herramientas libres para el apoyo en el proceso de desarrollo de software, se discute las características y funcionalidades que ofrece el software. Además del proceso de personalización por medio de complementos o plugins.
GnuPG, GNU Privacy Guard: Importancia del cifrado de la información, diferencias entre llaves simétricas y asimétricas, criptografía, fiestas de firmado de llaves, beneficios. Instalación y suo práctico de GnuPG.
Uso de dbconfig-common: Presentación que es parte de la serie mejores prácticas para el empaquetamiento de aplicaciones en Debian, se describe el uso de la herramienta y su respectiva integración con el asistente debhelper
Conociendo el framework web Django: Introducción, historia, características, primeros pasos, instalación y demostración de desarrollo de una aplicación sencilla bajo este excelente framework basado en el lenguaje de Programación Python

Las fuentes en LaTeX de las presentaciones, así como su licencia de uso y proceso de conversión al formato PDF se describe en el proyecto Presentations que he creado en github.

Agradezco enormemente cualquier comentario que pueda hacer respecto a los temas presentados puesto que en el próximo mes trataré de actualizar el contenido, así como incluir nuevas presentaciones. ¿Desearía poder conocer más sobre un tema en particular?, ¿cuál sería ese tema?.

Nota final: Si encuentra algún error por favor notificarlo vía issues del proyecto Presentations.

Presentaciones was originally published by Milton Mazzarri at milmazz on November 12, 2010.

Mejoras en el comportamiento a la hora de eliminar un ForeignKey

2010-11-09T13:51:35-06:00

Cuando un objeto referenciado por una clave foránea (ForeignKey) es eliminado, Django por omisión emula el comportamiento de la sentencia SQL ON DELETE CASCADE y también se elimina el objeto que contiene el ForeignKey.

A partir de la versión 1.3 de Django el comportamiento descrito en el párrafo anterior puede ser sobreescrito al especificar el argumento on_delete. Por ejemplo, si usted permite que una clave foránea pueda ser nula y usted desea que sea establecida a NULL cuando un objeto referenciado sea eliminado:

user = models.ForeignKey(User, blank=True, null=True, on_delete=models.SET_NULL)

Los posibles valores para el argumento on_delete pueden encontrarse en django.db.models:

CASCADE: Eliminación en cascada, el comportamiento por omisión.
PROTECT: Prevee la eliminación del objeto referenciado al lanzar una excepción del tipo: django.db-IntegrityError.
SET_NULL: Establece la clave foránea a NULL, esto solo es posible si el argumento null es True.
SET_DEFAULT: Establece la clave foránea a su valor por omisión, tenga en cuenta que un valor por omisión debe ser establecido.
SET(): Establece el valor del ForeignKey indicado en SET(), si una función es invocada, el resultado de dicha función será el valor establecido.
DO_NOTHING: No tomar acciones. Si el gestor de base de datos requiere integridad referencial, esto causará una excepción del tipo IntegrityError.

A continuación un par de ejemplos de esta nueva funcionalidad:

# models.py
from django.db import models

class Author(models.Model):
    nickname = models.CharField(max_length=32)

    def __unicode__(self):
        return self.nickname

class Post(models.Model):
    author = models.ForeignKey(Author, blank=True, null=True, on_delete=models.SET_NULL)
    title = models.CharField(max_length=128)

    def __unicode__(self):
        return self.title

Nuestra sesión interactiva con el API sería similar a la siguiente:

$ python manage.py shell

>>> from ondelete.models import Author, Post

>>> Author.objects.all()
[]
# Creamos el autor
>>> author = Author(nickname='milmazz')
# Guardamos el objeto en la base de datos al usar de manera explícita el método save()
>>> author.save()

# Obtenemos el autor en base a su id
>>> Author.objects.get(pk=1)
<Author: milmazz>

# Creamos par de artículos
>>> article1 = Post(author=author, title="Article 1")
>>> article1.save()

>>> article2 = Post(author=author, title="Article 2")
>>> article2.save()

>>> for article in Post.objects.all():
     print("%s by %s" % (article.title, article.author))
Article 1 by milmazz
Article 2 by milmazz

# Eliminamos el autor
>>> author.delete()

>>> for article in Post.objects.all():
    print("%s by %s" % (article.title, article.author))
Article 1 by None
Article 2 by None

Un segundo ejemplo, ahora haciendo uso del valor SET() en el argumento on_delete:

# models.py
from django.db import models
from django.contrib.auth.models import User

def get_superuser():
    return User.objects.get(pk=1)

class Post(models.Model):
    user = models.ForeignKey(User, on_delete=models.SET(get_superuser))
    title = models.CharField(max_length=128)

    def __unicode__(self):
        return self.title

Nuestra sesión interactiva con el API sería similar a la siguiente:

$ python manage.py shell

>>> from ondelete.models import Post
>>> from django.contrib.auth.models import User

>>> User.objects.all()
[<User: milmazz>]
# Creamos un nuevo usuario
>>> author = User(username='milton')
# Guardamos el objeto en la base de datos, 
# de manera explícita al invocar el método save()
>>> author.save()
# Vista de los usuarios registrados en la base de datos
>>> User.objects.all()
[<User: milmazz>, <User: milton>]

# Creamos par de artículos
>>> article1 = Post(user=author, title="Article 1")
>>> article1.save()

>>> article2 = Post(user=author, title="Article 2")
>>> article2.save()

>>> for article in Post.objects.all():
     print("%s by %s" % (article.title, article.user))
Article 1 by milton
Article 2 by milton

# Eliminamos el usuario 'milton'
>>> author.delete()

>>> for article in Post.objects.all():
    print("%s by %s" % (article.title, article.user))
Article 1 by milmazz
Article 2 by milmazz

Mejoras en el comportamiento a la hora de eliminar un ForeignKey was originally published by Milton Mazzarri at milmazz on November 09, 2010.

Subversion: Notificaciones vía correo electrónico

2010-04-24T02:00:17-05:00

Al darse un proceso de desarrollo colectivo es recomendable mantener una o varias listas de notificación acerca de los cambios hechos (commits) en el repositorio de código fuente. Para este tipo de actividades es muy útil emplear SVN::Notify.

SVN::Notify le ofrece un número considerable de opciones, a continuación resumo algunas de ellas:

Obtiene información relevante acerca de los cambios ocurridos en el repositorio Subversion.
Realiza análisis sobre la información recolectada y brinda la posibilidad de reconocer distintos formatos vía filtros (Ej. Textile, Markdown, Trac).
Puede obtener la salida tanto en texto sin formato como en XHTML.
Le brinda la posibilidad de construir correos electrónicos en base a la salida obtenida.
Permite el envío de correo, ya sea por el comando sendmail o SMTP.
Es posible indicar el método de autenticación ante el servidor SMTP.

Para instalar el SVN::Notify en sistemas Debian o derivados proceda de la siguiente manera:

# aptitude install libsvn-notify-perl

Una vez instalado SVN::Notify, es hora de definir su comportamiento. Aunque es posible hacerlo vía comando svnnotify y empotrarlo en un script escrito en Bash he preferido hacerlo en Perl, es más natural y legible hacerlo de este modo.

#!/usr/bin/perl -w

use strict;
use SVN::Notify;

my $path = $ARGV[0];
my $rev  = $ARGV[1];

my %params = (
    repos_path      => $path,
    revision        => $rev,
    handler         => 'HTML::ColorDiff',
    trac_url        => 'http://trac.example.com/project',
    filters         => ['Trac'],
    with_diff       => 1,
    diff_switches   => '--no-diff-added --no-diff-deleted',
    subject_cx      => 1,
    strip_cx_regex  => [ '^trunk/', '^branches/', '^tags/' ],
    footer          => 'Administrado por: BOFH ',
    max_sub_length  => 72,
    max_diff_length => 1024,
    from            => 'noreply@example.com',
    subject_prefix  => '[project]',
    smtp            => 'smtp.example.com',
    smtp_user       => 'example',
    smtp_pass       => 'example',
);

my $developers = 'dev@example.com';
my $admins     = 'admins@example.com';

$params{to_regex_map} = {
    $developers => '^trunk|^branches',
    $admins     => '^tags|^trunk'
};

my $notifier = SVN::Notify->new(%params);
$notifier->prepare;
$notifier->execute;

Si seguimos con el ejemplo indicado en el artículo anterior, Instalación básica de Trac y Subversion, este hook lo vamos a colocar en /srv/svn/project/hooks/post-commit, dicho fichero deberá tener permisos de ejecución para el Servidor Web Apache.

Con este sencillo script en Perl se ha logrado lo siguiente:

La salida se generará en XHTML.
Las diferencias de código serán resaltadas o coloreadas, esto es posible por el handler SVN::Notify::ColorDiff
El sistema de notificación está integrado a la sintaxis de enlaces de Trac. Por lo tanto, los commits que posean este tipo de enlaces serán interpretados correctamente. Ej. #123 changeset:234 r234

Aunque el código es sucinto y claro, trataré de resumir cada uno de los parámetros utilizados.

repos_path: Define la ruta al repositorio Subversion, la cual es obtenida a partir del primer argumento que pasa Subversion al ejecutar el hook post-commit.
revision: El número de la revisión del commit actual. El número de la revisión se obtiene a partir del segundo argumento que pasa Subversion al ejecutar el hook post-commit
handler: Especifica una subclase de SVN::Notify que será utilizada para el manejo de las notificaciones. En el ejemplo se hace uso de HTML::ColorDiff, el cual permite colorear o resaltar la sintaxis del comando svnlook diff
trac_url: Este parámetro será usado para generar enlaces al Trac para los números de revisiones y similares en el mensaje de notificación.
filters: Especifica la carga de más módulos que terminan de difinir la salida de la notificación. En el ejemplo, se hace uso del filtro Trac, filtro que convierte el log del commit que cumple con el formato de Trac a HTML.
with_diff: Valor lógico que especifica si será o no incluida la salida del comando svnlook diff en la notificación vía correo electrónico.
diff_switches: Permite el pase de opciones al comando svnlook diff, en particular recomiendo utilizar --no-diff-deleted y --no-diff-added para evitar ver las diferencias para los archivos borrados y añadidos respectivamente.
subject_cx: Valor lógico que indica si incluir o nó el contexto del commit en la línea de asunto del correo electrónico de notificación.
strip_cx_regex: Acá se indican las expresiones regulares que serán utilizadas para eliminar información del contexto de la línea de asunto del correo electrónico de notificación.
footer: Agrega la cadena definida al final del cuerpo del correo electrónico de notificación
max_sub_length: Indica la longitud máxima de la línea de asunto del correo electrónico de notificación.
max_diff_length: Máxima longitud del diff (esté adjunto o en el cuerpo de la notificación).
from: Define la dirección de correo que será usada en la línea From. Si no se especifica será utilizado el nombre de usuario definido en el commit, esta información se obtiene vía el comando svnlook.
subject_prefix: Define una cadena de texto que será el prefijo de la línea correspondiente al asunto del correo electrónico de notificación.
smtp: Indica la dirección para el servidor SMTP que el cual se enviarán las notificaciones de correo electrónico. Si no se utiliza este parámetro, SVN::Notify utilizará el comando sendmail para el envío del mensaje.
smtp_user: El nombre de usuario para la autenticación SMTP.
smtp_pass: Contraseña para la autenticación SMTP
to_regex_map: Este parámetro contiene un hash que mantiene referencias de direcciones de correo electrónico contra expresiones regulares. La idea es enviar las notificaciones si y solo si el nombre de uno o más directorios son afectados por un commit y dicha ruta coincide con las expresiones regulares definidas. Este parámetro resulta muy útil en proyectos de desarrollo de software grandes y donde es posible disponer de varias listas de correo para informar a los desarrolladores interesados en secciones específicas. Para mayor detalle de las opciones mencionadas previamente vea SVN::Notify, acá también encontrará más opciones de configuración.

Observación

Hasta ahora he encontrado que el coloreado o resaltado de la sintaxis no funciona en algunos sistemas Webmail, como por ejemplo Gmail, SquirrelMail. Sin embargo, en otros sistemas Webmail como RoundCube si funciona. Este comportamiento se presenta porque en sistemas como Gmail las hojas de estilos en cascada (CSS) internas no son aplicadas en la interfaz. Es por ello que en estos casos es necesario recurrir a la definición de estilos en línea.

Subversion: Notificaciones vía correo electrónico was originally published by Milton Mazzarri at milmazz on April 24, 2010.

Instalación básica de Trac y Subversion

2010-04-22T21:14:51-05:00

En este artículo se pretenderá mostrarle el proceso de instalación de un ambiente de desarrollo que le permitirá hacerle seguimiento a su proyecto personal, de igual manera se le indicará el modo en el cual puede comenzar a utilizar un sistema de control de versiones. Todas las indicaciones mostradas en este documento han sido probadas en la distribución Debian GNU/Linux 5.0 (nombre código Lenny).

La herramienta de seguimiento o manejo del proyecto que se procederá a instalar es Trac, el sistema de control de versiones que se presentará será Subversion. Todo lo anterior se presentará vía Web haciendo uso del servidor Apache, de manera adicional se utilizará el servidor de bases de datos PostgreSQL como backend de Trac.

Dependencias

En primer lugar proceda a instalar las siguientes dependencias.

# aptitude install apache2 \
libapache2-mod-python \
postgresql \
subversion \
python-psycopg2 \
libapache2-svn \
python-subversion \
trac

La versión de Trac que se encuentra en los archivos de Debian Lenny es estable (0.11.1). Sin embargo, si usted compara esta versión con lo publicado en el sitio oficial de Trac, podrá encontrar que existen nuevas versiones estables de mantenimiento que contienen correcciones a errores de programación y algunas nuevas funcionalidades de bajo impacto, para el momento de la redacción de este artículo se encuentra la versión 0.11.7. Es recomendable que utilice el paquete trac desde el archivo backports de Debian.

# aptitude -t lenny-backports install trac

Si desea usar el paquete proveniente del archivo backports le recomiendo leer las instrucciones de uso de este repositorio de paquetes.

Con el fin de mantener este artículo lo más sencillo y conciso posible se describirá la versión que viene por defecto con la distribución utilizada en este caso.

Versión de desarrollo de Trac

Si desea conocer algunas características interesantes que se han agregado a Trac en las nuevas versiones, o si su interés particular es examinar las bondades que le ofrece Trac en su versión de desarrollo puede hacer uso del comando pip, si no tiene instalado pip proceda como sigue:

# aptitude install python-setuptools
# easy_install pip

Proceda a instalar la versión de desarrollo de Trac.

# pip install https://svn.edgewall.org/repos/trac/trunk

Creación de usuario y base de datos

Antes de proceder con la instalación de Trac se debe establecer el usuario y la base de datos que se utilizará para trabajar.

En el siguiente ejemplo el usuario de la base de datos PostgreSQL que utilizará Trac será trac_user, su contraseña será trac_passwd. El uso de la contraseña lo del usuario trac_user lo veremos más tarde al proceder a configurar el ambiente de Trac.

# su postgres
$ createuser \
--no-superuser \
--no-createdb \
--no-createrole \
--pwprompt \
--encrypted trac_user
Enter password for new role:
Enter it again:
CREATE ROLE

Nótese que se debe utilizar el usuario postgres (u otro usuario con los privilegios necesarios) del sistema para proceder a crear los usuarios.

Ahora procedemos a crear la base de datos trac_dev, cuyo dueño será el usuario trac_user.

$ createdb --encoding UTF8 --owner trac_user trac_dev

Ambiente de Trac

Creamos el directorio /srv/www que será utilizado para prestar servicios Web, para mayor referencia acerca de esta elección se le recomienda leer el documento Filesystem Hierarchy Standard en su versión 2.3.

$ sudo mkdir -p /srv/www
$ cd /srv/www

Generamos el ambiente de Trac. Básicamente se deben contestar ciertas preguntas como:

Nombre del proyecto.
Enlace con la base de datos que se utilizará.
Sistema de control de versiones a utilizar (por defecto será SVN).
Ubicación absoluta del repositorio a utilizar.
Ubicación de las plantillas de Trac.

En el siguiente ejemplo se omitirán los comentarios brindados por el comando trac-admin.

# trac-admin project initenv
Creating a new Trac environment at /srv/www/project

...

Project Name [My Project]> Demo

...

Database connection string [sqlite:db/trac.db]> 
postgres://trac_user:trac_passwd@localhost:5432/trac_dev

...

Repository type [svn]>

...

Path to repository [/path/to/repos]> /srv/svn/project

...

Templates directory [/usr/share/trac/templates]>

Creating and Initializing Project
 Installing default wiki pages

...

---------------------------------------------------------
Project environment for 'Demo' created.

You may now configure the environment by editing the file:

  /srv/www/project/conf/trac.ini

...

Congratulations!

Se ha culminado la instalación del ambiente de Trac, ahora procederemos a crear el ambiente de subversion.

Subversion: Sistema Control de Versiones

La puesta a punto del sistema de control de versiones es bastante sencilla, se resume en los siguientes pasos.

Creación del espacio para prestar el servicio SVN, de igual manera se seguirá los lineamientos planteados en el FHS v2.3 mencionado previamente.

# mkdir -p /srv/svn

Seguidamente crearemos el proyecto subversion project y haremos un importe inicial con la estructura básica de un proyecto de desarrollo de software.

$ cd /srv/svn
# svnadmin create project
$ mkdir -p /tmp/project/{trunk,tags,branches}
$ tree /tmp/project/
/tmp/project/
├── branches
├── tags
└── trunk
# svn import /tmp/project/ \
file:///srv/svn/project/ \
-m 'Importe inicial'

Adding         /tmp/project/trunk
Adding         /tmp/project/branches
Adding         /tmp/project/tags

Committed revision 1.

Apache: Servidor Web

Es hora de configurar los sitios virtuales que utilizaremos tanto para Trac como para subversion.

A continuación se presenta la configuración básica de Trac.

# cat > /etc/apache2/sites-available/trac.example.com <<EOF
> <VirtualHost *>
> ServerAdmin webmaster@localhost
> ServerName trac.example.com
> CustomLog /var/log/apache2/trac.example.com/access.log combined
> ServerSignature Off
> ErrorLog /var/log/apache2/trac.example.com/error.log
> LogLevel warn
> DocumentRoot /srv/www/project
> <Location />
> SetHandler mod_python
> PythonInterpreter main_interpreter
> PythonHandler trac.web.modpython_frontend
> PythonOption TracEnv /srv/www/project
> PythonOption TracUriRoot /
> </Location>
> </VirtualHost>
> EOF

Ahora veamos la configuración básica de nuestro proyecto subversion.

# cat > /etc/apache2/sites-available/svn.example.com <<EOF
> <VirtualHost *>
> ServerAdmin webmaster@localhost
> ServerName svn.example.com
> CustomLog /var/log/apache2/svn.example.com/access.log combined
> ServerSignature Off
> ErrorLog /var/log/apache2/svn.example.com/error.log
> LogLevel warn
> DocumentRoot /srv/svn/project
> <Location />
> DAV svn
> SVNPath /srv/svn/project
> </Location>
> </VirtualHost>
> EOF

De acuerdo a la configuración mostrada es necesario crear los directorios /var/log/apache2/svn.example.com y /var/log/apache2/trac.example.com para mantener por separado el registro de accesos y errores de los sitios virtuales recién creados. De lo contrario no podremos iniciar el servidor Web Apache.

# mkdir /var/log/apache2/{svn,trac}.example.com

Activamos el módulo DAV necesario para cumplir con la configuración mostrada para el sitio virtual svn.example.com.

# a2enmod dav

Activamos los sitios virtuales recién creados.

# a2ensite trac.example.com
# a2ensite svn.example.com

Como la puesta en marcha y configuración de un servidor DNS escapa a los fines de este artículo, simplemente definiremos los hosts en la tabla estática que se encuentra definida en el archivo /etc/hosts de la siguiente manera.

# cat >> /etc/hosts <<EOF
> 127.0.0.1 trac.example.com trac
> 127.0.0.1 svn.example.com svn
> EOF

Finalmente debemos forzar la recarga de la configuración del servidor Web Apache, esto con el fin de cargar el módulo DAV y los sitios virtuales definidos, es decir, trac.example.com y svn.example.com.

# /etc/init.d/apache2 force-reload

¡Felicitaciones!, ya puede ir a su navegador favorito y colocar cualquiera de los sitios virtuales que acaba de definir.

Recomendaciones

Una vez que haya llegado a este sección deberá comenzar a modificar adecuadamente los permisos para el usuario y grupo www-data (Servidor Web Apache) para que escriba en las ubicaciones que sea necesario tanto en Trac como en subversion.

La configuración de Trac podrá encontrarla en /srv/www/project/conf/trac.ini, para mayor detalle acerca de la configuración de este fichero se le recomienda leer el documento TracIni.

Si en su proyecto prevé que participarán otras personas, es recomendable establecer notificaciones de tickets y cambios en el repositorio subversion, para esto último deberá revisar el hook post-commit y la documentación del paquete libsvn-notify-perl que le ofrece una extraordinaria cantidad de opciones.

Conozca el entorno de Trac y Subversion. Si desea agregar nuevas funciones a su instalación le recomiendo visitar el sitio Trac Hacks.

Espero poder mostrarles en próximos artículos algunas configuraciones más avanzadas en Trac, incluyendo la instalación, configuración y uso de plugins.

Instalación básica de Trac y Subversion was originally published by Milton Mazzarri at milmazz on April 22, 2010.

Sistema de manejo y seguimiento de proyectos: Trac

2010-03-15T19:24:43-06:00

Trac es un sistema multiplataforma desarrollado y mantenido por Edgewall Software, el cual está orientado al seguimiento y manejo de proyectos de desarrollo de software haciendo uso de un enfoque minimalista basado en la Web, su misión es ayudar a los desarrolladores a escribir software de excelente calidad mientras busca no interferir con el proceso y políticas de desarrollo. Incluye un sistema wiki que es adecuado para el manejo de la base de conocimiento del proyecto, fácil integración con sistemas de control de versiones ((Por defecto Trac se integra con subversion)). Además incluye una interfaz para el seguimiento de tareas, mejoras y reporte de errores por medio de un completo y totalmente personalizable sistema de tickets, todo esto con el fin de ofrecer una interfaz integrada y consistente para acceder a toda información referente al proyecto de desarrollo de software. Además, todas estas capacidades son extensibles por medio de plugins o complementos desarrollados específicamente para Trac.

Breve historia de Trac

El origen de Trac no es una idea original, algunos de sus objetivos se basan en los diversos sistemas de manejo y seguimiento de errores que existen en la actualidad, particularmente del sistema CVSTrac y sus autores.

Trac comenzó como la reimplementación del sistema CVSTrac en el lenguaje de programación Python y como ejercicio de entretenimiento, además de utilizar la base de datos embebida SQLite ((Hoy día también se le da soporte a PostgreSQL, mayor detalle en Database Backend)). En un corto lapso de tiempo, el alcance de estos esfuerzos iniciales crecieron en gran medida, se establecieron metas y en el presente Trac presenta un curso de desarrollo propio.

Los desarrolladores de Edgewall Software esperan que Trac sea una plataforma viable para explorar y expandir el cómo y qué puede hacerse con sistemas de manejo de proyectos de desarrollo de software basados en sistemas wiki.

Características de Trac

A continuación se presenta una descripción breve de las distintas características de Trac.

Herramienta de código abierto para el manejo de proyectos

Trac es una herramienta ligera para el manejo de proyectos basada en la Web, desarrollada en el lenguaje de programación Python. Está enfocada en el manejo de proyectos de desarrollo de software, aunque es lo suficientemente flexible para usarla en muchos tipos de proyectos. Al ser una herramienta de código abierto, si Trac no llena completamente sus necesidades, puede aplicar los cambios necesarios usted mismo, escribir complementos o plugins, o contratar a alguien calificado que lo haga por usted.

Sistema de tickets

El sistema de tickets le permite hacer seguimiento del progreso en la resolución de problemas de programación particulares, requerimientos de nuevas características, problemas e ideas, cada una de ellas en su propio ticket, los cuales son enumerados de manera ascendente. Puede resolver o reconciliar aquellos tickets que buscan un mismo objetivo o donde más de una persona reporta el mismo requerimiento. Permite hacer búsquedas o filtrar tickets por severidad, componente del proyecto, versión, responsable de atender el ticket, entre otros.

Para mejorar el seguimiento de los tickets Trac ofrece la posibilidad de activar notificaciones vía correo electrónico, de este modo se mantiene informado a los desarrolladores de los avances en la resolución de las actividades planificadas.

Vista de progreso

Existen varias maneras convenientes de estar al día con los acontecimientos y cambios que ocurren dentro de un proyecto. Puede establecer hitos y ver un mapa del progreso (así como los logros históricos) de manera resumida. Además, puede visualizar desde una interfaz centralizada los cambios ocurridos cronológicamente en el wiki, hitos, tickets y repositorios de código fuente, comenzando con los eventos más recientes, toda esta información es accesible vía Web o de manera alternativa Trac le ofrece la posibilidad de exportar esta información a otros formatos como el RSS, permitiendo que los usuarios puedan observar esos cambios fuera de la interfaz centralizada de Trac, así como la notificación por correo electrónico.

Vista del repositorio en línea

Una de las características de mayor uso en Trac es el navegador o visor del repositorio en línea, se le ofrece una interfaz bastante amigable para el sistema de control de versiones que esté usando ((Por defecto Trac se integra con subversion, la integración con otros sistemas es posible gracias a plugins o complementos.)). Este visualizador en línea le ofrece una manera clara y elegante de observar el código fuente resaltado, así como también la comparación de ficheros, apreciando fácilmente las diferencias entre ellos.

Manejo de usuarios

Trac ofrece un sistema de permisología para controlar cuales usuarios pueden acceder o no a determinadas secciones del sistema de manejo y seguimiento del proyecto, esto se logra a través de la interfaz administrativa. Además, esta interfaz es posible integrarla con la definición de permisos de lectura y escritura de los usuarios en el sistema de control de versiones, de ese modo se logra una administración centralizada de usuarios.

Wiki

El sistema wiki es ideal para mantener la base de conocimientos del proyecto, la cual puede ser usada por los desarrolladores o como medio para ofrecerles recursos a los usuarios. Tal como funcionan otros sistemas wiki, puede permitirse la edición compartida. La sintaxis del sistema wiki es bastante sencilla, si esto no es suficiente, es posible integrar en Trac un editor WYSIWYG (lo que se ve es lo que se obtiene, por sus siglas en inglés) que facilita la edición de los documentos.

Características adicionales

Al ser Trac un sistema modular puede ampliarse su funcionalidad por medio de complementos o plugins, desde sistemas anti-spam hasta diagramas de Gantt o sistemas de seguimiento de tiempo.

Sistema de manejo y seguimiento de proyectos: Trac was originally published by Milton Mazzarri at milmazz on March 15, 2010.