Si te gusta la informática, estas condenado a estudiar de por vida

Ya iniciamos el 2016 y les voy a comenzar a dejar algunas reflexiones y comentario que me gustaría compartir con todos ustedes.

Hoy mientras escribo estas líneas, y veo desde mi escritorio a mi pequeña jugando con sus bloques, creando historias e imaginando aventuras, me puse a pensar en todas los proyectos que tengo que ir cerrando mientras voy investigando y realizando mis pruebas de conceptos.

Figura 1: Si te gusta la informática, estas condenado a estudiar de por vida

Lo primero que se me cruzó por la cabeza es pensar lo rápido que pasa el tiempo, y cómo el día a día nos lleva a las corridas y para eso lo mejor es tratar de mantener todo muy bien planificado o por lo menos algo organizado.

De todas maneras hoy no vamos a hablar de organización sino sobre otro tema: "Si te gusta la informática, estas condenado a estudiar de por vida".

Alguna vez se pusieron a pensar esta afirmación? Pues créanme que en varias oportunidades lo pensé y realmente todos los días me doy cuenta que es así en el mundo de la informática.

Pero si realmente les apasiona lo que están haciendo, estoy seguro que van a camuflar el "estudiar" por "aprender", que sin duda es algo un poco más motivador y que invita a un inevitable crecimiento.

Yo no soy de dar muchos consejos, pero si ustedes se están introduciendo al mundo de la informática en forma profesional o estudiando alguna carrera relacionada a la informática, por favor créanme que van a estar condenados a estudiar de por vida.

Y es que es inevitable, la informática es así, independientemente a la rama que se dediquen, Programadores, DevOps, SysAdmin, Networking, Security, etc "están condenados a estudiar de por vida". Lo que hoy es una buena solución a implementar, mañana estoy seguro que surgirá una mejor y nuevamente tenemos que dejar un esfuerzo grande para comprenderla, aplicarla y revisar los casos de estudio.

Cuando esto se transforma en un gusto personal, esa "condena" se transforma en necesidad y aquella pasión y amor por saber un poco más todo los días, transforma el estudio en aprendizaje y de esta forma podríamos cambiar el titulo de este post para que quede más elegante.

"Si te apasiona la Informática, vas a sentir la necesidad de aprender de por vida".

Saludos!

Se encuentra disponible la actualización en #Django 1.9.1 y 1.8.8

El pasado 2 de Enero, el proyecto Django inició el año con dos importantes actualizaciones para las ramas 1.9.x y 1.8.x

Figura 1: Actualización en Django 1.9.1 y 1.8.8

Es por ello que ya se encuentra disponible las versiones correspondientes 1.9.1 y 1.8.8

Correcciones en la versión 1.9.1

• Fixed BaseCache.get_or_set() with the DummyCache backend (#25840).
• Fixed a regression in FormMixin causing forms to be validated twice (#25548, #26018).
• Fixed a system check crash with nested ArrayFields (#25867).
• Fixed a state bug when migrating a SeparateDatabaseAndState operation backwards (#25896).
• Fixed a regression in CommonMiddleware causing If-None-Match checks to always return HTTP 200 (#25900).
• Fixed missing varchar/text_pattern_ops index on CharField and TextField respectively when using AlterField on PostgreSQL (#25412).
• Fixed admin’s delete confirmation page’s summary counts of related objects (#25883).
• Added from __future__ import unicode_literals to the default apps.py created by startapp on Python 2 (#25909). Add this line to your own apps.py files created using Django 1.9 if you want your migrations to work on both Python 2 and Python 3.
• Prevented QuerySet.delete() from crashing on MySQL when querying across relations (:ticket`25882`).
• Fixed evaluation of zero-length slices of QuerySet.values() (#25894).
• Fixed a state bug when using an AlterModelManagers operation (#25852).
• Fixed TypedChoiceField change detection with nullable fields (#25942).
• Fixed incorrect timezone warnings in custom admin templates that don’t have a data-admin-utc-offset attribute in the body tag. (#25845).
• Fixed a regression which prevented using a language not in Django’s default language list (LANGUAGES) (#25915).
• Avoided hiding some exceptions, like an invalid INSTALLED_APPS setting, behind AppRegistryNotReady when starting runserver (#25510). This regression appeared in 1.8.5 as a side effect of fixing #24704 and by mistake the fix wasn’t applied to the stable/1.9.x branch.
• Fixed migrate --fake-initial detection of many-to-many tables (#25922).
• Restored the functionality of the admin’s list_editable add and change buttons (#25903).
• Fixed isnull query lookup for ForeignObject (#25972).
• Fixed a regression in the admin which ignored line breaks in read-only fields instead of converting them to <br> (#25465).
• Fixed incorrect object reference in SingleObjectMixin.get_context_object_name() (#26006).
• Made loaddata skip disabling and enabling database constraints when it doesn’t load any fixtures (#23372).
• Restored contrib.auth hashers compatibility with py-bcrypt (#26016).
• Fixed a crash in QuerySet.values()/values_list() after an annotate() and order_by() when values()/values_list() includes a field not in the order_by() (#25316).

Correcciones en la versión 1.8.8

• Fixed incorrect unique_together field name generation by inspectdb (#25274).
• Corrected __len query lookup on ArrayField for empty arrays (#25772).
• Restored the ability to use custom formats from formats.py with django.utils.formats.get_format() and the date template filter (#25812).
• Fixed a state bug when migrating a SeparateDatabaseAndState operation backwards (#25896).
• Fixed missing varchar/text_pattern_ops index on CharField and TextField respectively when using AlterField on PostgreSQL (#25412).
• Fixed a state bug when using an AlterModelManagers operation (#25852).
• Fixed a regression which prevented using a language not in Django’s default language list (LANGUAGES) (#25915).
• django.views.decorators.cache.never_cache() now sends more persuasive headers (added no-cache, no-store, must-revalidate to Cache-Control) to better prevent caching (#13008). This fixes a problem where a page refresh in Firefox cleared the selected entries in the admin’s filter_horizontal and filter_vertical widgets, which could result in inadvertent data loss if a user didn’t notice that and then submitted the form (#22955).
• Fixed a regression in the admin which ignored line breaks in read-only fields instead of converting them to <br> (#25465).
• Made loaddata skip disabling and enabling database constraints when it doesn’t load any fixtures (#23372).
• Fixed a crash in QuerySet.values()/values_list() after an annotate() and order_by() when values()/values_list() includes a field not in the order_by() (#25316).

No se olviden de mantener su framework y proyectos actualizados a las últimas versiones estables, si no recuerdas como, aquí de enlazo la forma más práctica de actualizar Django.

Saludos!

Fuente | Bugfix releases issued: 1.9.1 and 1.8.8

Mi primer modelo en #Django

En una de las últimas entrega sobre lo que estamos aprendiendo a trabajar con #Django mostramos como sincronizar las bases de datos con Django, a partir del lanzamiento de la versión 1.9 el comando:

$ ./manage.py dbsync

deja de estar en funcionamiento y en su remplazo podemos utilizar

$ ./manage.py migrate

Esto es para tenerlo en cuenta de aquí en adelante y saber el traspaso de algunas funcionalidades. Además cabe aclarar que el comando migrate es una simple sincronización de tus modelos hacia tu base de datos. Este comando examina todos los modelos en cada aplicación que figure en la variable de configuración INSTALLED_APPS del archivo settings.py

El siguiente paso es casi inevitable, comenzar a crear nuestro propio modelo de datos para la aplicación creada llamada cursos.

Para ello les propongo editar el archivo cursos/models.py y agregar la siguiente líneas:

from __future__ import unicode_literals

from django.db import models

class Profesor(models.Model):
        nombre = models.CharField(max_length=30)
        apellido = models.CharField(max_length=40)
        email = models.EmailField()

class Curso(models.Model):
        titulo = models.CharField(max_length=50)
        descripcion = models.CharField(max_length=100)
        fecha_inicio = models.DateField()

Como se observa, dos clases creadas Profesor y Curso con sus correspondientes atributos que la describen. Por el momento y solo por ahora vamos a dejar de lado las relaciones e ir siempre por lo más simple de entender y seguir avanzando.

Como información adicional, podemos recurrir a la documentación de Django para conocer todos los Fields que soporta y las características que pueden incluir.

Que es lo que pasa si ahora intentamos realizar nuevamente la migración?

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, contenttypes, auth, sessions
Running migrations:
  No migrations to apply.

Si fueron atentos a este punto, se habrán dado cuenta que nuestra aplicación cursos no se encuentra dentro de la variable de configuración INSTALLED_APPS y por esa razón al chequear el resto de las aplicaciones y notar que no existe un cambio no lo toma como tal.

Es por ello que agregamos nuestra apps a la variable de la siguiente forma:

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'cursos',
)

$ ./manage.py makemigrations
Migrations for 'cursos':
  0001_initial.py:
    - Create model Curso
    - Create model Profesor

Ahora bien, si ejecutamos el comando migrate todo puede resultar como lo esperamos.

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, cursos, contenttypes, auth, sessions
Running migrations:
  Rendering model states... DONE
  Applying cursos.0001_initial... OK

Dejamos hasta aquí así podemos apuntar a nuevos conceptos en las próximas entregas.

Saludos!