Moodle guarda, yo creo que por tema de nacimiento en un sistema operativo tipo unix, la fecha en el estandar de Unix. Este formato es numerico, de forma que se guarda un numero de segundos dentro de la base de datos.
Por lo mismo es util conocerque la transformación de la fecha a formato calendario se puede hacer de la siguiente forma
to_date('1970-01-01','YYYY-MM-DD') + numtodsinterval(campo_que_contiene_unixtime,'SECOND')
En moodle muchas veces ocurre que el renderizado de la página aparece en otro idioma. Esto es por las idiosincracias del cache de moodle o porque por defecto, en la configuraciones de lenguaje tienes configurado que moodle autodetecte el lenguaje.
La autodetección ocurre cuando el browser tiene congigurado un lenguaje primario. Dependiendo del sistema operativo que tengas o quien sea el dueño de tu empresa (trabajo en Chile, hablo español, pero mi sistema operativo por la casa matriz en que trabajo esta en inglés).
Entonces, si en el config.php de Moodle estableces
$CFG->lang='es_utf8';
(en este caso español es el lenguaje primario por defecto, pero debes tener instalado el lenguaje).
Además la autodetección del lenguaje debe estar desactivada:
Recuerda tambien tener dentro de la carpeta mooledata/lang/xx/core_langconfig.php (en donde xx es tu lenguaje). De esta forma el core_langconfig.php podría lucir
< ?php $this->cache['es']['core_langconfig'] = array ( 'alphabet' => 'A,B,C,D,E,F,G,H,I,J,K,L,M,N,Ñ,O,P,Q,R,S,T,U,V,W,X,Y,Z', 'backupnameformat' => '%Y%m%d-%H%M', 'decsep' => ',', 'firstdayofweek' => '1', 'iso6391' => 'es', 'iso6392' => 'spa', 'labelsep' => ':', 'listsep' => ',', 'locale' => 'es_ES.UTF-8', 'localewin' => 'Spanish_Spain.1252', 'localewincharset' => 'WINDOWS-1252', 'oldcharset' => 'ISO-8859-1', 'parentlanguage' => '', 'strftimedate' => '%d de %B de %Y', 'strftimedatefullshort' => '%d/%m/%a', 'strftimedateshort' => '%d de %B', 'strftimedatetime' => '%d de %B de %Y, %H:%M', 'strftimedatetimeshort' => '%d/%m/%Y %H:%M', 'strftimedaydate' => '%A, %d de %B de %Y', 'strftimedaydatetime' => '%A, %d de %B de %Y, %H:%M', 'strftimedayshort' => '%A, %d %B', 'strftimedaytime' => '%a, %H:%M', 'strftimemonthyear' => '%B %Y', 'strftimerecent' => '%d de %b, %H:%M', 'strftimerecentfull' => '%a, %d de %b de %Y, %H:%M', 'strftimetime' => '%H:%M', 'thisdirection' => 'ltr', 'thisdirectionvertical' => 'btt', 'thislanguage' => 'Español - Internacional', 'thislanguageint' => 'Spanish (International)', 'thousandssep' => '.', );
Si quieres encontrar los lenguajes especificados por la iso6392 revisa el siguiente link
El proceso
Inicialmente existe uno o varios requerimientos que deben ser agrupados por el usuario o jefe de un proyecto (quien es el encargado de dar la prioridad a las necesidades del usuario). Ahí define la funcionalidad que uno o un grupo de requerimientos genera, y le encarga la tarea a un desarrollador.
El desarrollador debiese descargar la ultima version de desarrollo, generar los cambios de uno o más archivos, y comprometer al repositorio de codigo con alguna forma identificadora de la funcionalidad.
Con esto el desarrollador hace su liberación.
La persona encargada de QA debe descargar un copia de la ultima version de produccion, compila, ejecuta, hace las pruebas y da su veredicto. si la aprueba, se genera una version QA con la funcionalidad, sino, se devuelve al desarrollador.
Finalmente el encargado de generar el release, segun la planificcion o roadmap de la aplicacion se da el momento de fusionar todas las funcionalidades liberadas y que existan en QA ya probadas y liberadas. Esta construccion debiese ser limpia debido a que las funcionalidades no son dependientes unas de otras, eso es la idea que se transmitió al principio.
Con lo cual se tiene mas o menos lo siguiente
En muchos momentos he tenido que hacer entender a gente no informática que existe la necesidad de versionar lo que hacemos como proyecto debido a que de un punto al siguiente existen avances, y por ende modificaciones al original. Por lo tanto un ‘artefacto’ evoluciona a través del tiempo para perfeccionarse y llegar a ver la luz como el requerimiento que fue solicitado.
El problema me ocurre también con gente que si es informática, o sea, tampoco entienden porque existe esta necesidad y ven que es sólo una pérdida de tiempo. Aquí va una manito…
La situación
En general el desarrollador crea una version un archivo de código fuente de desarrollo, que luego debe ser probada por otros para asegurar la calidad (QA, de Quality Assurance) y ellos a su vez dan el paso a producción, algo más o menos así(perdon el dibujo a mano, pero carezco de tiempo, y me es más rápido así):
Ahora bien, existen distintos tipos de modificaciones dentro de desarrollo: nuevos desarrollos, optimizaciones, correcciones de errores, etc. Todos atacan alguna funcionalidad específica. Lo que hay que tener claro es que el desarrollador programa una funcionalidad y una funcionalidad puede estar compuesta de más de un requerimiento que para el caso de la funcionalidad son indivisibles. Algo que se puede representar asi:
Hay que tener cuidado en definir entonces los requerimientos y funcionalidades, en el primer caso no todo es indivisible, ya que 2 requerimientos pueden ser muy cercanos lo que no necesariamente los hace inidivisibles, quizas los puede hacer dependientes pero no indivisible, por ejemplo para calcular un bono de reconocimiento en Chile (un instrumento financiero) es necesario calcular la UF, el calculo de la UF es un requerimiento del cuan el calculo del bono depende, pero el calculo de la UF puede ser vista de forma independiente del calculo del bono.
Entonces, cuando un desarrollador termina una funcionalidad, recien entonces esa funcionalidad puede ‘pasarse’ a QA para que la revise. Este ‘pasarse’ implica pasar todos los archivos de codigo, scripts y configuraciones necesarias para la correcta ejecucion de la funcionalidad. QA lo revisa, lo acepta o lo rechaza, si lo acepta la funcionalidad, o sea, todos los archivos y configuraciones necesarias quedan a la espera de ser fusionadas con la version de produccion para generar un release productivo.
Si lo rechaza es otro cuento, debido a que la funcionalidad se ‘saca’ de la version de QA y no pasara al release, es aqui donde se debe poseer un proceso adecuado para que no se ‘ensucien’ las liberaciones de las funcionalidades junto con otras, este control es el que debe ser cuidadoso. Es aqui donde aparece el control de versiones y el proceso de versionamiento de software.
(Continuará…)
Uno de las cosas que evito siempre es reiniciar un servidor, sólo lo hago cuando los recursos se me han agotado. si se diera el caso de que se tuviese que cambiar el nivel de ejecución de linux, esto puede hacerse con el siguiente comando
init 3
En mi caso, luego de la instalación hecha por otra persona en un servidor que quedo con initlevel 5, pero que por operacion nunca se iba a ingresar en modo gráfico fue útil saber este comando.
En un desarrollo especifico cometi el error de borrar todos los cursos que no pertenecían a los datos que me entregaron, entre esos cursos que borre fue el curso con ID 1, que es el curso maestro de moodle. Esto hizo que apareciera el error
«Could not find a top-level course!»
El que resolvi reinsertando el curso base.
insert into [prefijo_moodle]_course (id, category, sortorder, fullname, shortname, idnumber, summary, summaryformat, format, showgrades, modinfo, newsitems, startdate, numsections, marker, maxbytes, legacyfiles, showreports, visible, visibleold, hiddensections, groupmode, groupmodeforce, defaultgroupingid, lang, theme, timecreated, timemodified, requested, restrictmodules, enablecompletion, completionstartonenrol, completionnotify)
Value
( 1, 0, 1, 'moodle', 'moodle', '', '', 0, 'site', 1, 'a:0:{}', 3, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, '', '', 0, 0, 0, 0, 0, 0, 0);