Este script en Bash nos permite automatizar tareas en Git como la subida de archivos al servidor, así como también la creación del archivo de cambios (changelog).
Su uso es bastante sencillo, solo hace falta ejecutarlo de la siguiente forma.
mygit.sh up|change|change-all|refresh
Entre las opciones que encontramos en este script están las siguientes.
Este script se encuentra disponible para su descarga desde su repositorio en Github.
No son los adornos, no es la nieve, no es el árbol, ni los regalos. La Navidad es el calor que vuelve al corazón de las personas, la generosidad de compartirla con otros y la esperanza de seguir unidos en paz.
Feliz Navidad!!!
Webmin es un interfaz basada en la web para la administración de sistema GNU/Linux. Utilizando cualquiera de los navegadores web modernos podemos administrar usuarios, Apache, DNS, Samba y mucho más. Webmin elimina la necesidad de editar archivos de configuración pero manteniendo la posibilidad de administrar el sistema de manera local o remota.
Existen paquetes para casi todas las plataformas y su instalación en Debian es bastante sencilla.
# apt install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl apt-show-versions python
# dpkg -i *.deb
Espero les sea útil…
Referencias:
CrudGen fue mi proyecto de tesis de mis estudios de pregrado, consiste en un generador de páginas Create, Report, Update y Delete para base de datos PostgreSQL utilizando el gestor phpPgAdmin. Es uno de los plugines “oficiales” del proyecto y al encontrar un poco de tiempo libre decidí actualizarlo para añadir ligeras mejoras, compatibilidad y mantener vivo el proyecto.
Hoy he lanzado la versión 1.0, pues considero que el plugin cumple con la tarea inicial para la que fue desarrollada y es compatible con las últimas versiones de Postgres y phpPgAdmin, el administrador web de la base de datos. Si te interesa el proyecto, ver como funciona y aprender a crear páginas web rápidamente usando esta herramienta, puedes ver mi entrada sobre este generador de páginas web para PostgreSQL usando phppgadmin que incluye vídeos, información, entre otros.
Ejemplo de una página de visualización usando CrudGen
Finalmente, te invito a chequear el código en el sitio de CrudGen en Github, para utilizarlo o colaborar con cualquier aporte. Deseo que lo prueben y reporten errores, y si son desarrolladores frontend, me gustaría que colaboraran con plantillas para las páginas generadas.
Continuando con la serie de artículos sobre el microframework de desarrollo web flask, ahora se mostrará como crear un sitio estático.
Este artículo se basa en un artículo en inglés llamado Introduction to Flask, Part 1 - Setting up a static site.
Se usará el mismo archivo utilizado en los artículos anteriores (app.py), en este caso simplemente se agregará el decorador y la función que se va a usar que será para llamar una página de bienvenida.
Aparte del archivo app.py se necesita crear dos directorios, uno llamado templates el cual contendrá la plantilla html y el otro se llamará static que contendrá archivos estáticos como archivos css y archivos javascript.
ernesto@heimdall:~/proyectos/tutorialflask$ ls -l
total 12
-rw-r--r-- 1 ernesto ernesto 792 jun 7 20:56 app.py
drwxr-xr-x 2 ernesto ernesto 4096 jun 7 21:09 static
drwxr-xr-x 2 ernesto ernesto 4096 jun 7 21:10 templates
El archivo app.py tendrá la siguiente información adicional:
#Se agrega el renderizado de la plantillaAhora en el directorio templates se crea el archivo bienvenido.html con el siguiente contenido:
from flask import Flask,request,redirect,render_template
#Se usa el decorador ruta para ver el url bienvenido.
@app.route('/bienvenido')
#Se crea la funcion welcome que renderiza una plantilla html.
def welcome():
return render_template('bienvenido.html') # renderiza la plantilla bienvenido.html.
Kodi (antes conocido como “Xbox Media Center” o XBMC) es un centro multimedia de entretenimiento multi-plataforma bajo la licencia GPL, inicialmente creado para la primera generación de la videoconsola Xbox. Sin embargo, el equipo de desarrollo de Kodi ha portado el producto para que pueda correr de manera nativa en Linux, Mac OS X, los sistemas operativos de Microsoft Windows y en la consola Ouya.
Kodi soporta una amplia gama de formatos multimedia, e incluye características tales como listas de reproducción, visualizaciones de audio, presentación de diapositivas, reportes del clima y ampliación de funciones mediante plug-ins. Como Media Center, Kodi puede reproducir la mayoría de los formatos de audio y vídeo, así como mostrar imágenes prácticamente de cualquier fuente, incluidos CD, DVD, dispositivos de almacenamiento masivo, Internet y elementos compartidos en LAN.
Para instalarlo en Ubuntu o Mint solo hace falta instalar unas dependencias y el PPA oficial mediante los siguientes comandos.
# apt install python-software-properties pkg-config software-properties-common # add-apt-repository ppa:team-xbmc/ppa # apt update # apt install kodi
También existe una distribución de GNU/Linux basada en Ubuntu llamada Kodibuntu que trae instalado todo lo necesario para ejecutar Kodi sin tener que realizar complicadas configuraciones, para descargarlo haga clic aquí.
Referencias:
BOINC cuenta con una gran comunidad que tiene como objetivo contribuir con capacidad de computo para los proyectos gestionados por BOINC y con herramientas que facilitan ese proceso, en este apartado es donde se ubica Dotsch/UX una distribución GNU/Linux basada en Ubuntu que cuenta con muchas aplicaciones para ayudar en el despliegue de una infraestructura dedicada a la computación distribuida con BOINC.
Aparte de tener instalado el cliente de BOINC por defecto (acá se explica como instalar BOINC en Debian), tiene una interfaz que permite configurar un servidor para luego iniciar múltiples clientes diskless (sin disco) y luego asignarles tareas mediante BOINC, entre sus principales características podemos encontrar las siguientes.
Dotsch/UX es una excelente distribución muy fácil de instalar, esta disponible en versiones para 32 y 64 bits y puede ser descargado desde aquí.
Referencias:
En sus comienzos, la historia de la navegación web tuvo altos y bajos desde el proyecto arpanet hasta el nuevo milenio. Antes del célebre Internet Explorer, los navegadores tuvieron que desplazarse por el texto, seguido de imágenes y animaciones. El auge de las empresas hechas en Silicon Valley motivó que la alguna vez HyperCard fuera el precursor comercial para surgir avances fusionados; y Mosaic, el gran impulsor.
Firefox comenzó como una rama experimental del proyecto Mozilla a cargo de Dave Hyatt, Joe Hewitt y Blake Ross. A su juicio, las exigencias comerciales del patrocinio de Netscape y el gran número de características de Mozilla Application Suite comprometían la utilidad de este. Para combatir lo que ellos denominaban inflada Mozilla Application Suite, crearon un navegador independiente con la intención de reemplazarla.
Dave Hyatt y Blake Ross decidieron aislar la rama matriz para centrarse en un solo proyecto para la navegación web. Previamente, la multinacional estadounidense AOL quiso que Netscape, no pusiera mucha atención en Internet Explorer, si no en un prototipo multiusos: Chat IRC, e-mail y navegador web. Una de las motivaciones para promover un modelo de desarrollo distinto fue mediante el libro The Cathedral and the Bazaar (La catedral y el bazar) de Eric S. Raymond. El libro, que motiva a las personas en mantener el equipo con otras más, cita que tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
El navegador cambió varias veces de nombre. Originalmente fue llamado Phoenix cuando, por razones legales, debió ser cambiado al estar ya registrado por el desarrollador de BIOS Phoenix Technologies. El nombre elegido fue «Firebird» (Pájaro de Fuego), lo que provocó una polémica por parte la base de datos Firebird. El 3 de abril de 2003, la Organización Mozilla anuncia que centrarán sus esfuerzos en Firefox y Thunderbird.
Sin embargo, la presión constante de la comunidad forzó a que, tras barajar otros nombres como «Firebird Browser» y «Mozilla Firebird», el 9 de febrero de 2004 se rebautizara finalmente como Mozilla Firefox, a menudo referido simplemente como «Firefox» y abreviado como «Fx» o «fx», o más común como «FF». Este nombre se eligió por su semejanza con Firebird y por ser único en la industria informática. Para garantizar la estabilidad del nuevo nombre, la Fundación Mozilla empezó en diciembre de 2003 el procedimiento para su registro como una marca depositada en Estados Unidos.
Aunque muestra una evidente inconsistencia con los nombres de los proyectos hermanos de Mozilla mencionados anteriormente, el nuevo nombre y logotipo del navegador fueron rápidamente aceptados. Mientras algunos usuarios se irritaron por estos cambios de nombre sucesivos, otros lo tomaron como filosofía.
Con más de 25 millones de descargas en los 99 días siguientes a la publicación de la versión 1.0, Firefox se convirtió en una de las aplicaciones libres más descargadas, especialmente entre los usuarios domésticos. El 19 de octubre de 2005, Firefox había alcanzado la cifra de 100 millones de descargas en menos de un año (344 días). La versión 1.5 llegó el 29 de noviembre de 2005, superándose la cota de los 2 millones de descargas en las primeras 36 horas.
Extended Support Release
En enero de 2012 la Fundación Mozilla anuncia la disponibilidad de una versión Extended Support Release (versión con soporte extendido) de Firefox. Firefox ESR está dirigida a aquellos grupos quienes despliegan y mantienen entornos de desarrollo en grandes organizaciones como universidades, países o gobiernos y empresas. Está disponible para Windows, Mac y Linux.
ESR se actualiza de forma automática durante 9 ciclos (54 semanas), pero dos ciclos antes de finalizar se publica la siguiente versión. Por ejemplo, ESR salta desde 10.0 a 17.0, luego a 24.0, y así sucesivamente.
Cada seis semanas es publicada una nueva versión en la línea principal de desarrollo de Firefox siguiendo el ciclo de desarrollo acelerado. Las versiones ESR seguirían este calendario. Por ejemplo, ESR 10.0.1 estaría prevista para ser publicada al mismo tiempo que Firefox 11. Luego se publicarían ESR 10.0.2, 10.0.3, etc. Para Firefox 16, ESR alcanzaría la versión 10.0.6. Para la versión 17 se iniciaría un nuevo ciclo de ESR, pero aún no habría finalizado el ciclo ESR anterior (es decir las versiones 17 y 18 tendrían dos versiones con soporte extendido). Tal que así: ESR 10.0.7 junto a ESR 17.0.0; ESR 10.0.8 con ESR 17.0.1. Finalmente, cuando Firefox (la línea principal) alcance la versión 19.0, ESR 10.0.x llegaría a su fin de ciclo coincidiendo con la publicación de ESR 17.0.2. El ciclo se volvería a repetir sucesivamente.
El proyecto GNU fue iniciado por Richard Stallman con el objetivo de crear un sistema operativo completamente libre. El 27 de septiembre de 1983 se anunció públicamente el proyecto por primera vez en el grupo de noticias net.unix-wizards. Al anuncio original, siguieron otros ensayos escritos por Richard Stallman como el “Manifiesto GNU“, que establecieron sus motivaciones para realizar el proyecto GNU, entre las que destaca “volver al espíritu de cooperación que prevaleció en los tiempos iniciales de la comunidad de usuarios de computadoras”.
Para asegurar que el software GNU permaneciera libre para que todos los usuarios pudieran “ejecutarlo, copiarlo, modificarlo y distribuirlo”, el proyecto debía ser liberado bajo una licencia diseñada para garantizar esos derechos al tiempo que evitase restricciones posteriores de los mismos. La idea se conoce en Inglés como copyleft (lo cual significa que el autor permite la distribución libre del mismo, en clara oposición a copyright o “derecho de autor”), y está contenida en la Licencia General Pública de GNU (GPL).
En 1985, Stallman creó la Free Software Foundation (FSF o Fundación para el Software Libre) para proveer soportes logísticos, legales y financieros al proyecto GNU. La FSF también contrató programadores para contribuir a GNU, aunque una porción sustancial del desarrollo fue (y continúa siendo) producida por voluntarios. A medida que GNU ganaba renombre, negocios interesados comenzaron a contribuir al desarrollo o comercialización de productos GNU y el correspondiente soporte técnico. El más prominente y exitoso de ellos fue Cygnus Solutions.
En 1990, el sistema GNU ya tenía un editor de texto llamado Emacs, un exitoso compilador (GCC), y la mayor parte de las bibliotecas y utilidades que componen un sistema operativo UNIX típico. Pero faltaba un componente clave llamado núcleo.
En el manifiesto GNU, Stallman mencionó que “un núcleo inicial existe, pero se necesitan muchos otros programas para emular Unix”. Él se refería a TRIX, que es un núcleo de llamadas remotas a procedimientos, desarrollado por el MIT y cuyos autores decidieron que fuera libremente distribuido; TRIX era totalmente compatible con UNIX versión 7. En diciembre de 1986 ya se había trabajado para modificar este núcleo. Sin embargo, los programadores decidieron que no era inicialmente utilizable, debido a que solamente funcionaba en “algunos equipos sumamente complicados y caros” razón por la cual debería ser portado a otras arquitecturas antes de que se pudiera utilizar. Finalmente, en 1988, se decidió utilizar como base el núcleo Mach desarrollado en la CMU. Inicialmente, el núcleo recibió el nombre de Alix (así se llamaba una novia de Stallman), pero por decisión del programador Michael Bushnell fue renombrado a Hurd. Desafortunadamente, debido a razones técnicas y conflictos personales entre los programadores originales, el desarrollo de Hurd acabó estancándose.
En 1991, Linus Torvalds empezó a escribir el núcleo Linux y decidió distribuirlo bajo la licencia GPL. Rápidamente, múltiples programadores se unieron a Linus en el desarrollo, colaborando a través de Internet y consiguiendo paulatinamente que Linux llegase a ser un núcleo compatible con UNIX. En 1992, el núcleo Linux fue combinado con el sistema GNU, resultando en un sistema operativo libre y completamente funcional. El Sistema Operativo formado por esta combinación es usualmente conocido como “GNU/Linux” o como una “distribución Linux” y existen diversas variantes.
Si desea saber mas del proyecto GNU puede ir a la siguiente dirección, donde encontrara la historia del proyecto narrada por el mismo Richard Stallman además de algunas definiciones relacionadas con el tema.
Linus Benedit Torvalds nació en Helsinki, Finlándia, en el año de 1969. Su abuelo, matemático y estadista le compró un Comodore en 1980 y fue quien “enganchó” a Linus al mundo de los computadores.
En 1988 Linus Torvalds entra a la Universidad. Ese mismo año fue cuando el sistema operativo didáctico, basado en UNIX y creado por Andy Tannenbaum, empezó a cobrar importancia. Dicho sistema era el Minix.
Linus entró a formar parte de la comunidad de usuarios Minix. Andy Tannenbaum cometió un error en su sistema operativo, era demasiado limitado, tanto técnicamente como políticamente, en ningún momento tuvo en cuenta la posibilidad de incluir Minix al proyecto GNU. Su primer error fue ceder todos sus derechos a Prentice Hall, que empezó a cobrar 150 dólares por licencia.
Así, Linus tomó la decisión de cambiar esta política debido a que el sistema Minix era ideal para los estudiantes de sistemas operativos, y su precio era considerablemente alto.
Año 1991, cuando Linus con 23 años se acababa de comprar su primer 386, la intención era crear un nuevo Kernel de UNIX basado en el Kernel de Minix y modificarlo periódicamente de manera que fuera capaz de ejecutar aplicaciones GNU. Esto fue al principio un emulador terminal, al cual Torvalds solía tener acceso en los grandes servidores UNIX de la universidad. Él escribió el programa expresamente para el hardware que usaba, e independiente de un sistema operativo, porque quiso usar las funciones de su nueva computadora personal con un procesador 80386. Este es aún el estándar de hoy, el compilador inicial fue el GNU C compiler, que aún es la opción principal para compilar Linux hoy (aunque Linux puede ser compilado bajo otros compiladores, tal como el Intel C Compiler).
Como Torvalds escribió en su libro “Solamente por diversión”), él tarde o temprano comprendió que había escrito un núcleo de sistema operativo. El 25 de agosto de 1991, 20:57:08 GMT, anunció este sistema en un envío a la red Usenet, en el newsgroup comp.os.minix.:
Hola a todos aquellos que usan Minix -
Estoy haciendo un sistema operativo (gratuito) (solamente una afición, no será grande ni profesional como el GNU) para clones 386(486) AT. Este ha estado gestándose desde abril, y está comenzando a estar listo. Me gustaría recibir cualquier comentario sobre las cosas que gustan/disgustan en minix, ya que mi SO (Sistema Operativo) se le parece un poco (la misma disposición física del sistema de archivos, debido a motivos prácticos, entre otras cosas).
Actualmente he portado bash(1.08) y gcc(1.40), y las cosas parecen funcionar. Esto implica que conseguiré algo práctico dentro de unos meses, y me gustaría saber qué características quiere la mayoría de la gente. Cualquier sugerencia es bienvenida, pero no prometeré que las pondré en práctica :-)
Linus Benedict Torvalds (torvalds@kruuna.helsinki.fi)
PD. Sí – es libre de cualquier código de minix, y tiene un sistema de archivos multi-hilo. NO es portable (usa 386 una conmutación de tarea etc.), y probablemente nunca será soportada por nada más que los discos duros AT, porque es todo lo que tengo :-(.
Linus Torvalds
Linus Torvalds había querido llamar su invención Freax, una unión de varias palabras, la primera freak (anormal o raro), free (libre), y “X”, una alusión a Unix. Durante el inicio de su trabajo sobre el sistema, él almacenó los archivos bajo el nombre “Freax” por aproximadamente medio año. Torvalds ya había considerado el nombre “Linux”, pero al principio lo había descartado por ser demasiado egocéntrico o egoísta.
Para dar a otra gente la capacidad de cooperar en el sistema o sugerir mejoras, los archivos fueron colocados en el servidor ftp (ftp.funet.fi) de la Universidad de Tecnología de Helsinki (Helsinki University of Technology), en septiembre de 1991. Ari Lemmke, colega de Torvalds en la HUT, que en ese entonces era responsable de los servidores, no estuvo de acuerdo con el nombre Freax, prefiriendo el nombre Linux. Él simplemente llamó a los archivos colocados sobre el servidor “Linux” sin consultar a Torvalds. Más tarde, sin embargo, Torvalds accedió a usar el nombre “Linux”:
“Después de muchas discusiones, él finalmente admitió que Linux era simplemente el mejor nombre. En el código original de la versión 0.01 de Linux, el nombre Freax fue, sin embargo, usado en el makefile. Sólo después fue usado el nombre Linux. Así el nombre, en realidad, no planificado en absoluto se hizo generalmente aceptado por todo el mundo.”
Linux bajo la Licencia pública general de GPL
Torvalds primero publicó el núcleo Linux bajo su propia licencia, la cual fue casi una licencia de código fuente compartida (en inglés, share source) y que tenía una restricción contra la actividad comercial. En 1992, él sugirió cambiar a la GNU GPL. Primero anunció este cambio en las notas de lanzamiento de la versión 0.12.4
A mediados de diciembre de 1992 él publicó la versión 0.99 usando la GPL. Más tarde, Torvalds dijo en una entrevista, “registrar a Linux bajo la GPL fue definitivamente la mejor cosa que alguna vez hice”.
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:
You can install Grunt via npm (Node Package Manager), so, in order to install Grunt you need to install Node.js first.
Now that you have Node.js and npm installed is a good time to installglobally the Grunt CLI (Command Line Interface) package.
$ sudo npm install -g grunt-cliOnce 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 initThe previous command will ask you a series of questions in order to create thepackage.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 facilitate the installation 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-devAnd the plugins that you need can be installed as follows:
$ npm install <grunt-plugin-name> --save-devPlease note that the --save-dev parameter will modify your devDependencies
section in your package.json. So, be sure to commit the updated package.json
file with your project whenever you consider appropriate.
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. */functiontickPositioner(xOrY,min,max){// do somethingreturntickPositions;}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-devOnce 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 theGruntfile.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 jsdocImmediately you can see, inside the doc directory, the available documentation
in HTML format with some beautiful styles by default.
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 ofall options supported by JSHint
To install the grunt-contrib-jshint plugin do the following:
$ npm install grunt-contrib-jshint --save-devNext, 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 jshintNote that if you need more information or explanations about the errors that you may receive after the previous command I suggest that you should visitJSLint Error Explanations site.
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:modifyIn order to reduce 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-devNext, proceed to 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 uglifyAfter loading all of your Grunt tasks you can create some aliases.
If you want to create an alias to run 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 minifiedThe previous command is a wrapper around the htmlmin, cssmin and uglify
tasks defined previously.
Wrapping all together we get the following [Grunfile.js][]
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 followingplugins:
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 consequence 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.
Para el año que comienza te deseo que las rutinas se transformen en sorpresas, los enfados en sonrisas, las tristezas en esperanzas y que tu bandera sea el amor, la esperanza y la paz.
¡Feliz Año Nuevo!
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 affects 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 shorthands 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 isDash or Zeal, I can access 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 25, 2014.
deb http://mirror.optus.net/deb-multimedia/ wheezy main
apt-get update
apt-get install mkvtoolnix mencoder x264 libfaac0
mencoder videoOrigen.mp4 -ovc x264 -x264encopts threads=auto:subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid=normal:weight_b -oac faac -vf scale=720:404 -sub videoOrigen.srt -subcp latin1 -subfont-text-scale 3 -o video.avi
mkvmerge video.avi -o videoFin.mkv
Continuando con la serie de artículos sobre el microframework de desarrollo web flask, ahora se mostrará como crear un sitio estático.
Este artículo se basa en un artículo en inglés llamado Introduction to Flask, Part 1 - Setting up a static site.
Se usará el mismo archivo utilizado en los artículos anteriores (app.py), en este caso simplemente se agregará el decorador y la función que se va a usar que será para llamar una página de bienvenida.
Aparte del archivo app.py se necesita crear dos directorios, uno llamado templates el cual contendrá la plantilla html y el otro se llamará static que contendrá archivos estáticos como archivos css y archivos javascript.
ernesto@heimdall:~/proyectos/tutorialflask$ ls -l
total 12
-rw-r--r-- 1 ernesto ernesto 792 jun 7 20:56 app.py
drwxr-xr-x 2 ernesto ernesto 4096 jun 7 21:09 static
drwxr-xr-x 2 ernesto ernesto 4096 jun 7 21:10 templates
El archivo app.py tendrá la siguiente información adicional:
#Se agrega el renderizado de la plantillaAhora en el directorio templates se crea el archivo bienvenido.html con el siguiente contenido:
from flask import Flask,request,redirect,render_template
#Se usa el decorador ruta para ver el url bienvenido.
@app.route('/bienvenido')
#Se crea la funcion welcome que renderiza una plantilla html.
def welcome():
return render_template('bienvenido.html') # renderiza la plantilla bienvenido.html.
