Skip to content

Instantly share code, notes, and snippets.

@aitor

aitor/gist:2214391

Created March 27, 2012 09:35
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save aitor/2214391 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save aitor/2214391 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. aitor revised this gist Mar 27, 2012. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -16,7 +16,7 @@ No sirve para monitorizar el acceso a la información e introduce una barrera pa

    * **Acceso exclusivo a un API u otra -> MAL**

    Como se ve en la pantalla anterior, en el momento del registro es necesario indicar el formato de acceso a los datos. Obviamente no hay ninguna necesidad de limitar tal acceso, pero si hay un momento en el que negativo hacerlo es antes siquiera de que el desarrollador tenga acceso a una prueba de datos de los mismos.
    Como se ve en la pantalla anterior, durante el registro es necesario indicar el formato de acceso a los datos. Obviamente no hay ninguna necesidad de limitar tal acceso, pero si hay un momento en el que es negativo hacerlo es antes siquiera de que el desarrollador tenga acceso a una prueba de datos de los mismos.

    * **Acceso por tiempo a los datos -> UBER WTF**

  2. aitor revised this gist Mar 27, 2012. 1 changed file with 5 additions and 4 deletions.
    9 changes: 5 additions & 4 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -6,23 +6,24 @@ Obviamente la iniciativa es bienintencionada, pero como en muchas otras implemen

    Una lista rápida de WTFs sobre el proceso de acceso a los mismos:

    1. **Registro obligatorio para el uso -> MAL**
    * **Registro obligatorio para el uso -> MAL**

    Esta pantalla es un sin sentido

    ![](http://f.cl.ly/items/1x443S0g2p1r1h0K391h/Desarrolladores%20%7C%20Moveuskadi.png).

    No sirve para monitorizar el acceso a la información e introduce una barrera para el uso de los datos.

    2. **Acceso exclusivo a un API u otra -> MAL**
    * **Acceso exclusivo a un API u otra -> MAL**

    Como se ve en la pantalla anterior, en el momento del registro es necesario indicar el formato de acceso a los datos. Obviamente no hay ninguna necesidad de limitar tal acceso, pero si hay un momento en el que negativo hacerlo es antes siquiera de que el desarrollador tenga acceso a una prueba de datos de los mismos.

    3. **Acceso por tiempo a los datos -> UBER WTF**
    * **Acceso por tiempo a los datos -> UBER WTF**

    ![](http://f.cl.ly/items/0t2M1V2a353Y1I0b1U2x/Desarrollador%20moveuskadi%20-%20aitor.garcia@gmail.com%20-%20Gmail.png)
    "Este acceso tiene una validez de 30 minutos." No hay palabras para describir lo inutil que es un proceso así. Permitir un acceso limitado en el tiempo que solo se puede conseguir mediante una petición manual es el ejemplo perfecto de cadena de despropositos. Imposible construir un sistema automatizado para mantener al dia la información cuando esta cambie. Y eso nos lleva al ultimo punto.

    4. **Disposición estatica de los datos -> HORRIBLE**
    * **Disposición estatica de los datos -> HORRIBLE**

    A ver si nos enteramos de una vez. Salvo que los contratos con cada una de estas agencias esten escritos en marmol y todas ellas hayan prometido sacrificar a su hijo primogenito en caso de cambios... ¡es necesario que el acceso a los datos se ajuste a su naturaleza viva!. Los costes, la posición de las paradas y obviamente los horarios cambiarán y cuando lo hagan quedará patente lo inutil que es liberar datos de esta manera, porque la copia que me he descargado esta mañana estará desfasada y no habré podido construir un sistema automatizado que sea capaz de mantenerla al dia.

  3. aitor revised this gist Mar 27, 2012. 1 changed file with 4 additions and 0 deletions.
    4 changes: 4 additions & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -14,12 +14,16 @@ Una lista rápida de WTFs sobre el proceso de acceso a los mismos:
    No sirve para monitorizar el acceso a la información e introduce una barrera para el uso de los datos.

    2. **Acceso exclusivo a un API u otra -> MAL**

    Como se ve en la pantalla anterior, en el momento del registro es necesario indicar el formato de acceso a los datos. Obviamente no hay ninguna necesidad de limitar tal acceso, pero si hay un momento en el que negativo hacerlo es antes siquiera de que el desarrollador tenga acceso a una prueba de datos de los mismos.

    3. **Acceso por tiempo a los datos -> UBER WTF**

    ![](http://f.cl.ly/items/0t2M1V2a353Y1I0b1U2x/Desarrollador%20moveuskadi%20-%20aitor.garcia@gmail.com%20-%20Gmail.png)
    "Este acceso tiene una validez de 30 minutos." No hay palabras para describir lo inutil que es un proceso así. Permitir un acceso limitado en el tiempo que solo se puede conseguir mediante una petición manual es el ejemplo perfecto de cadena de despropositos. Imposible construir un sistema automatizado para mantener al dia la información cuando esta cambie. Y eso nos lleva al ultimo punto.

    4. **Disposición estatica de los datos -> HORRIBLE**

    A ver si nos enteramos de una vez. Salvo que los contratos con cada una de estas agencias esten escritos en marmol y todas ellas hayan prometido sacrificar a su hijo primogenito en caso de cambios... ¡es necesario que el acceso a los datos se ajuste a su naturaleza viva!. Los costes, la posición de las paradas y obviamente los horarios cambiarán y cuando lo hagan quedará patente lo inutil que es liberar datos de esta manera, porque la copia que me he descargado esta mañana estará desfasada y no habré podido construir un sistema automatizado que sea capaz de mantenerla al dia.

    En resumidas cuentas, es encomiable que el Gobierno Vasco siga investigando y demostrando buena fe en la apertura de datos. Sin embargo es triste que eso sea lo unico que demuestre.
  4. aitor revised this gist Mar 27, 2012. 1 changed file with 3 additions and 0 deletions.
    3 changes: 3 additions & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -7,12 +7,15 @@ Obviamente la iniciativa es bienintencionada, pero como en muchas otras implemen
    Una lista rápida de WTFs sobre el proceso de acceso a los mismos:

    1. **Registro obligatorio para el uso -> MAL**

    Esta pantalla es un sin sentido
    ![](http://f.cl.ly/items/1x443S0g2p1r1h0K391h/Desarrolladores%20%7C%20Moveuskadi.png).

    No sirve para monitorizar el acceso a la información e introduce una barrera para el uso de los datos.

    2. **Acceso exclusivo a un API u otra -> MAL**
    Como se ve en la pantalla anterior, en el momento del registro es necesario indicar el formato de acceso a los datos. Obviamente no hay ninguna necesidad de limitar tal acceso, pero si hay un momento en el que negativo hacerlo es antes siquiera de que el desarrollador tenga acceso a una prueba de datos de los mismos.

    3. **Acceso por tiempo a los datos -> UBER WTF**
    ![](http://f.cl.ly/items/0t2M1V2a353Y1I0b1U2x/Desarrollador%20moveuskadi%20-%20aitor.garcia@gmail.com%20-%20Gmail.png)
    "Este acceso tiene una validez de 30 minutos." No hay palabras para describir lo inutil que es un proceso así. Permitir un acceso limitado en el tiempo que solo se puede conseguir mediante una petición manual es el ejemplo perfecto de cadena de despropositos. Imposible construir un sistema automatizado para mantener al dia la información cuando esta cambie. Y eso nos lleva al ultimo punto.
  5. aitor revised this gist Mar 27, 2012. 1 changed file with 8 additions and 5 deletions.
    13 changes: 8 additions & 5 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -6,14 +6,17 @@ Obviamente la iniciativa es bienintencionada, pero como en muchas otras implemen

    Una lista rápida de WTFs sobre el proceso de acceso a los mismos:

    1. Registro obligatorio para el uso -> MAL
    Esta pantalla es un sin sentido ![](http://f.cl.ly/items/1x443S0g2p1r1h0K391h/Desarrolladores%20%7C%20Moveuskadi.png). No sirve para monitorizar el acceso a la información e introduce una barrera para el uso de los datos.
    2. Acceso exclusivo a un API u otra -> MAL
    1. **Registro obligatorio para el uso -> MAL**
    Esta pantalla es un sin sentido
    ![](http://f.cl.ly/items/1x443S0g2p1r1h0K391h/Desarrolladores%20%7C%20Moveuskadi.png).

    No sirve para monitorizar el acceso a la información e introduce una barrera para el uso de los datos.
    2. **Acceso exclusivo a un API u otra -> MAL**
    Como se ve en la pantalla anterior, en el momento del registro es necesario indicar el formato de acceso a los datos. Obviamente no hay ninguna necesidad de limitar tal acceso, pero si hay un momento en el que negativo hacerlo es antes siquiera de que el desarrollador tenga acceso a una prueba de datos de los mismos.
    3. Acceso por tiempo a los datos -> UBER WTF
    3. **Acceso por tiempo a los datos -> UBER WTF**
    ![](http://f.cl.ly/items/0t2M1V2a353Y1I0b1U2x/Desarrollador%20moveuskadi%20-%20aitor.garcia@gmail.com%20-%20Gmail.png)
    "Este acceso tiene una validez de 30 minutos." No hay palabras para describir lo inutil que es un proceso así. Permitir un acceso limitado en el tiempo que solo se puede conseguir mediante una petición manual es el ejemplo perfecto de cadena de despropositos. Imposible construir un sistema automatizado para mantener al dia la información cuando esta cambie. Y eso nos lleva al ultimo punto.
    4. Disposición estatica de los datos -> HORRIBLE
    4. **Disposición estatica de los datos -> HORRIBLE**
    A ver si nos enteramos de una vez. Salvo que los contratos con cada una de estas agencias esten escritos en marmol y todas ellas hayan prometido sacrificar a su hijo primogenito en caso de cambios... ¡es necesario que el acceso a los datos se ajuste a su naturaleza viva!. Los costes, la posición de las paradas y obviamente los horarios cambiarán y cuando lo hagan quedará patente lo inutil que es liberar datos de esta manera, porque la copia que me he descargado esta mañana estará desfasada y no habré podido construir un sistema automatizado que sea capaz de mantenerla al dia.

    En resumidas cuentas, es encomiable que el Gobierno Vasco siga investigando y demostrando buena fe en la apertura de datos. Sin embargo es triste que eso sea lo unico que demuestre.
  6. aitor created this gist Mar 27, 2012.
    23 changes: 23 additions & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,23 @@
    Recientemente OpenData Euskadi liberó datos relacionados con el transporte público. Información al respecto:

    http://ecodiario.eleconomista.es/espana/noticias/3850101/03/12/El-Gobierno-vasco-libera-los-datos-de-transporte-publico-a-traves-de-Moveuskadi-y-Open-Data-Euskadi.html

    Obviamente la iniciativa es bienintencionada, pero como en muchas otras implementaciones de datos públicos eso es lo mejor que se puede decir de ella.

    Una lista rápida de WTFs sobre el proceso de acceso a los mismos:

    1. Registro obligatorio para el uso -> MAL
    Esta pantalla es un sin sentido ![](http://f.cl.ly/items/1x443S0g2p1r1h0K391h/Desarrolladores%20%7C%20Moveuskadi.png). No sirve para monitorizar el acceso a la información e introduce una barrera para el uso de los datos.
    2. Acceso exclusivo a un API u otra -> MAL
    Como se ve en la pantalla anterior, en el momento del registro es necesario indicar el formato de acceso a los datos. Obviamente no hay ninguna necesidad de limitar tal acceso, pero si hay un momento en el que negativo hacerlo es antes siquiera de que el desarrollador tenga acceso a una prueba de datos de los mismos.
    3. Acceso por tiempo a los datos -> UBER WTF
    ![](http://f.cl.ly/items/0t2M1V2a353Y1I0b1U2x/Desarrollador%20moveuskadi%20-%20aitor.garcia@gmail.com%20-%20Gmail.png)
    "Este acceso tiene una validez de 30 minutos." No hay palabras para describir lo inutil que es un proceso así. Permitir un acceso limitado en el tiempo que solo se puede conseguir mediante una petición manual es el ejemplo perfecto de cadena de despropositos. Imposible construir un sistema automatizado para mantener al dia la información cuando esta cambie. Y eso nos lleva al ultimo punto.
    4. Disposición estatica de los datos -> HORRIBLE
    A ver si nos enteramos de una vez. Salvo que los contratos con cada una de estas agencias esten escritos en marmol y todas ellas hayan prometido sacrificar a su hijo primogenito en caso de cambios... ¡es necesario que el acceso a los datos se ajuste a su naturaleza viva!. Los costes, la posición de las paradas y obviamente los horarios cambiarán y cuando lo hagan quedará patente lo inutil que es liberar datos de esta manera, porque la copia que me he descargado esta mañana estará desfasada y no habré podido construir un sistema automatizado que sea capaz de mantenerla al dia.

    En resumidas cuentas, es encomiable que el Gobierno Vasco siga investigando y demostrando buena fe en la apertura de datos. Sin embargo es triste que eso sea lo unico que demuestre.