- Para los principiantes que recién empiezan con PHP: siempre hay que ir al manual para resolver las dudas; esta práctica enriquece nuestro aprendizaje porque regularmente encontraremos elementos nuevos que pudieron habernos pasado desapercibidos. En esta situación es fundamental leer el primer capítulo del manual: capítulo I - Conceptos Básicos
- Para los iniciados en PHP, pero que aún no lo dominan (o ya leyeron el capítulo I): es recomendable leer todo el capítulo III - Referencias del Lenguaje, deteniéndonos -sin introducirnos- en el subcapítulo 18, Clases y Objetos (PHP4). No vamos a ver objetos con PHP4, porque para nosotros es obsoleto, y el subcapítulo siguiente sobre objetos en PHP5 lo veremos un poco más adelante.
- Sistemas de versionado de software (SCM): en nuestro caso particular usaremos SVN en sustitución al famoso y popular CVS, por ser mucho más moderno y contemplar muchas características que no están implementadas aún.
Para los que tienen problemas con la instalación de la infraestructura (tareas de la "Semana 0"): lo comenté en el blog, es parte de tú tarea resolverlo. Piensen de esta manera: seré el Gerente de Proyectos y ustedes están ahora a prueba:
La "empresa" te entregó la lista de herramientas que usan para desarrollar, te dieron una semana para que te prepares, y coordinaron para el próximo lunes empezar con el entrenamiento formal con una serie de pruebas para ver si estás a la altura del desafío, si puedes integrar la plantilla permanente de "trabajadores a distancia".
¿Tú, cómo piensas proceder? ¿qué es lo que vas a dar a cambio? ¿cuanto vas a invertir de tu tiempo? ¿enviarás constantemente correos a la empresa solicitando ayuda ante el menor inconveniente? ¿o serás autosuficiente?
Recuerden: esto no será un "jardín de infantes", aquí no se van a cambiar pañales. Vamos a hacer el simulacro de estar trabajando en una empresa con características muy particulares. Van a pasar un primer "entrenamiento" de un mes y posteriormente dos meses de prácticas reales dentro de uno de los varios proyectos de desarrollo existentes. Trataremos de recrear la infraestructura necesaria para gestionar cada uno de los proyectos y a los integrantes de la propia "empresa".
¿Va a funcionar? Ni idea, el problema no es que yo esté loco, es que ustedes me siguieron hasta aquí ;-)
16 comentarios:
Me parece perfecto y muy razonable estoy algo nervioso ya ke mis conocimientos son algo basicos pero kiero ver asta donde puedo llegar en esto y espero terminar ke es el fin de este cometido y gracias por la iniciativa
Me parece interesante y ya estoy ansioso por empezar.
Hay algo escrito sobre la semana 0, o todo es referente a los comentarios en un post anterior ??
Ya no me puedo arrepentir, estamos en el punto de no retorno con esto de PHP5.
Demosle nomas ..
Con respecto al Easyeclipse lo estoy probando y si bien me parece una herramienta a la altura, tambien creo que consume muchos recursos, ni modo.
¿Alguien tiene algun manual de uso del easyeclipse, que no sea referido a java?
Que buena iniciativa, soy de argentina y trabajo como programador de php y la verdad que nunca me meti en objetos espero poder ayudar a los compañeros
atte. gabriel
Pd: todo instalado en la noot.
pd2: gloffy es una masa
Estimado anónimo (por favor, por lo menos pongan en su firma sus nombres):
Sobre los "conocimientos básicos", eso depende del esfuerzo de cada uno. Las pautas ya están dadas, y como dije, no me considero un experto en el lenguaje PHP, y constantemente voy a consultar al manual.
Lee los capítulos que marqué en esta entrada.
PD: nada de "gracias", vas a tener que trabajar para seguir en carrera ;-)
Estimado Luis Enrique:
Si buscas por la etiqueta "taller" encontrarás todas las entradas que tratamos el tema.
Hay dos entradas que hacen referencia concreta a la "Semana 0".
Estimado Anónimo (pongan sus nombres):
> Ya no me puedo arrepentir,
> estamos en el punto de no retorno
> con esto de PHP5.
O sea, yo estoy en el punto de no retorno porque tengo "mi cara" en juego ;-)
> Con respecto al Easyeclipse
> lo estoy probando y si bien me
> parece una herramienta a la
> altura, tambien creo que consume
> muchos recursos, ni modo.
Si, es lo que tiene. Está desarrollada en Java y tiene su costo, pero también la aplicación no es un simple editor, es un IDE (entorno integrado de desarrollo) y cuenta con muchas herramientas y funcionalidades.
> ¿Alguien tiene algun manual
> de uso del easyeclipse, que no
> sea referido a java?
Mmmm... no he visto (tampoco quiere decir que no exista). Estoy viendo si puedo hacer mis primeros "screencasts" e ir contándoles tips sobre cómo usar Eclipse con PHP5.
En mi caso aprendí a los golpes ;-)
PD: si alguien ha encontrado información extra, será bienvenida.
Estimado Barcho:
> Que buena iniciativa, soy de
> argentina y trabajo como
> programador de php y la verdad que
> nunca me meti en objetos espero
> poder ayudar a los compañeros
Bueno, por esas razones es que se genera esta iniciativa. Participo en foros y constantemente veo que las consultas se repiten una y otra vez: "objetos".
Escribo en el blog artículos sobre conceptos de Java adaptados a PHP y me llueven los correos con consultas sobre el tema.
En el ambiente PHP estamos bordeando el analfabetismo al tener al 90% de los programadores sin conocer nada de objetos, y dentro del 10% restante, muy pocos dominan lo esencial de la POO.
Intentemos hacer algo para cambiarlo, compartiendo conocimiento y experiencias entre todos.
> Pd: todo instalado en la
> noot.
> pd2: gloffy es una masa
Espero que "masa" signifique "bueno" ;-)
Una pregunta, ¿Por qué te has decidido por escoger un IDE en vez de un buen editor de textos (Notepad++/Windows, VIM/EMACS/Linux. p.ej)?
No pongo en duda la utilidad de los IDEs (faltaría más, es obvia la gran utilidad de un IDE, o de un buen RAD) pero ya que vamos a tratar temas introductorios de PHP5 y los proyectos a realizar serán pequeños ¿No resultaría más enriquecedor y eficaz emplear editores de texto?
Los IDEs automatizan labores que puede que uno no sepa cómo hacer por sí mismo o que no se sepa muy bien cómo lo hace. Ahorran mucho tiempo y cuando te haces bien con el manejo de alguno de ellos puede ser nuestro mejor amigo para programar, pero... en fin, soy de los que piensan para aprender lo mejor es "volver a lo básico" (http://www.joelonsoftware.com/articles/fog0000000319.html recomendada lectura :))
Por mi parte, y si no va a resultar un problema para el buen funcionamiento del taller, ¿Podría utilizar mi editor de textos favorito (vim)?
He instalado y probado Eclipse y está claro que es un entorno inmenso: además de muy completo puedes programar casi con lo que te de la gana en él (lo dicho, inmenso, hay de todo). Sería interesantísimo aprender a manejar Eclipse pero ¿No sería mejor dejarlo para un taller a parte? (guiño) ;-)
Saludos
--
Juanjo Ortiz
dejo un link sobre php en eclipse en ingles :P
http://docs.schuetzengau-freising.de/modules/xdocman/index.php?doc=xo-002&lang=en
y segundo hago una consulta sobre si vamos a aplicar la librearia PEAR en nuestro proyecto, porque la verdad para que vamos a reinventar la rueda no?
"porque la verdad para que vamos a reinventar la rueda no?"
Pues podríamos reinventarla para aprender ¿no? Que, creo yo, de eso trata todo esto. No sé de qué va la librería PEAR (ahora buscaré en Google) pero ¿Sabemos implementar todo lo que está ahí implementado? Me da que no (es lógico, los aquí presentes primero tenemos que aprender) por lo que ¿Tan malo sería "reinventar la rueda"?
Vuelta a lo mismo que he comentado en mi comentario anterior: Back to basics, my friends.
Solo es mi opinión.
--
Juanjo Ortiz
Estimado Juanjo:
> Una pregunta, ¿Por qué te has
> decidido por escoger un IDE en
> vez de un buen editor de textos
> (Notepad++/Windows,
> VIM/EMACS/Linux. p.ej)?
Porque un IDE es un "Entorno de Desarrollo Integrado", un poco más completo que un buen editor.
Por ejemplo, cuando creas objetos puedes ver a través de la instancia la lista de métodos y atributos del objeto (algo que no se hacen los editores comunes).
Por ejemplo, tienes integrado el versionado de software, tanto cvs como svn, con solo presionar botón derecho sobre el proyecto o archivo.
Porque lo usan para Java, entonces nosotros también lo vamos a usar ;-)
> tratar temas introductorios de
> PHP5 y los proyectos a realizar
> serán pequeños ¿No resultaría más
> enriquecedor y eficaz emplear
> editores de texto?
Ahhh... ese es el punto. No serán tan pequeños. No es lo mismo una o dos, o veinte páginas interrelacionadas, que un "sistema". A pesar que vamos a hacer sistemas sencillos, vamos a aplicar el concepto de "3 capas".
¿Por qué me dirán? Por que no se me ocurre desarrollar ningún sistema sin separarlo "en por lo menos" 3 capas.
> Los IDEs automatizan labores
> que puede que uno no sepa cómo
> hacer por sí mismo o que no se
> sepa muy bien cómo lo hace.
En este caso, un IDE te ayuda con tareas triviales, no es un RAD que te haga cosas que tu no sabes cómo las hizo.
Además, el módulo que soporta Java en Eclipse está mucho más elaborado y estable que el de PHP, por lo cual vamos a tener funciones y ayudas muy básicas.
Pero es bueno también ver por qué hay programadores Java que usan estos entornos.
> Por mi parte, y si no va a
> resultar un problema para el buen
> funcionamiento del taller,
> ¿Podría utilizar mi editor de
> textos favorito (vim)?
No. No vas a poder.
1) La "empresa" te dio esa lista de programas, con esos programas trabajan todos los desarrolladores.
2) De la misma forma que no concibo no hacer un sistema en por lo menos 3 capas, no concibo hacer un sistema sin "versionado". Cuando usemos SVN ahí te vas a dar cuenta que lo necesitas integrado al entorno de desarrollo.
> He instalado y probado
> Eclipse y está claro que es un
> entorno inmenso: además de muy
> completo puedes programar casi
Te repaso, está más completo el soporte para Java que para PHP.
> Eclipse pero ¿No sería mejor
> dejarlo para un taller a parte?
> (guiño) ;-)
Ni se me ocurre hacer un taller aparte de Eclipse. ;-)
Estimado Barcho:
Gracias por el enlace ;-)
> y segundo hago una consulta
> sobre si vamos a aplicar la
> librearia PEAR en nuestro proyecto,
> porque la verdad para que vamos a
> reinventar la rueda no?
Esa no es la idea del taller, lo expliqué varias veces. No es un taller para expertos y no va a tocar una lista interminable de temas, solo a concentrarse en los conceptos de la programación orientada a objetos.
Vamos a sacrificar hacer "hermosos" diseños a favor de aprender.
Si reinventar aportar conocimientos, vamos a reinventar varias veces.
Hola :)
Por mí no hay ni un problema en emplear un IDE. Pero como a cualquier buen trabajador, a uno le gusta saber las razones de cuantas más cosas mejor.
Con respecto al desarrollo a tres capas (en qué patrón estás pensando, MVC imagino ¿no? Eso es muy de Java -eso dicen, jeje- :)) yo tampoco concibo otra cosa que no sea así (al menos cuando hablemos de aplicaciones (web) con almacenamiento de datos) por lo que en ningún momento lo he puesto en duda. Proyectos pequeños pueden aplicar este modelo de desarrollo, no hay problema. Y tampoco lo habría utilizando un editor de textos.
La razón por la que personalmente me habría decantado por vim, como dije (bueno, por un editor de textos) es porque el editor te da (mejor dicho, te obliga) mayor control de todo el "proceso de fabricación" que un IDE. Porque no es lo mismo darle a un botón y que el entorno haga un commit automático al SVN sin saber uno qué está haciendo (o cómo lo está haciendo el IDE, que es a donde voy: a que sepamos cómo hacerlo nosotros) que a que nosotros lo tengamos que hacer: ese verbo "tener que" implica que necesitamos saber cómo hacerlo. Es decir: aprender (y si ya sabemos, pues practicar)
Otro ejemplo más: "apt-get Vs. ./configure && make && make install" ¿Qué es mejor? Pues sinceramente, para _aprender_, la segunda opción.
En fin, que adelante con EasyEclipse :-) (incluso para mí mejor! Así aprendo un poco a manejar a este Mastodonte :)
PD: Imagino que esta clase de discusiones no representan ningún problema para el Gerente de Proyecto de la empresa. Presupongo que nuestro gerente está abierto a escucharnos y a acepar ideas que le parezcan bien, o a dar explicaciones del por qué en las decisiones para el desarrollo de nuestros proyectos. Con el ánimo de _aprender todos_, claro está. De no ser así, este trabajador (osea, yo :) se calla la boca y sigue (o no) adelante sin hacer tanta pregunta y/o generar tanta discusión. La intención con las discusiones es la de enriquecer ya sea los posts que se publican o las propias decisiones del gerente de proyecto.
--
Juanjo Ortiz
Estimado Juanjo:
> Por mí no hay ni un problema
> en emplear un IDE. Pero como a
> cualquier buen trabajador, a uno
> le gusta saber las razones de
> cuantas más cosas mejor.
No sé si todas las empresas te van a dar tanta libertada para discutir las herramientas que usan ;-)
Yo también uso vim, y alguna vez para editar PHP, pero no es el mecanismo más profesional para seguir un proyecto.
> Con respecto al desarrollo a
> tres capas (en qué patrón estás
> pensando, MVC imagino ¿no? Eso es
> muy de Java -eso dicen, jeje-
No, no entraremos en el tema de los patrones de diseño, el objetivo es otro (conceptos sobre POO en PHP5). Hay formas anteriores de separar en 3 capas y lo vamos a aplicar.
Muy probablemente los patrones MVC evolucionaron a partir de la que vamos a ver.
> La razón por la que
> personalmente me habría decantado
> por vim, como dije (bueno, por
> un editor de textos) es porque el
> editor te da (mejor dicho, te
> obliga) mayor control de todo el
> "proceso de fabricación" que un
> IDE. Porque no es lo mismo darle
El IDE Eclipse con soporte para PHP no es de los más completos, es decir, no te "automatiza" tanto trabajo.
Además, no tienes que pensar solo individualmente, hay que buscar unificar las herramientas para que todos aprovechen los mismos conocimientos y tengan probablemente los mismos problemas.
Vim sería una decisión personal, no posible de aplicar para todos, y te perderías de conocer una herramienta IDE.
> a un botón y que el entorno haga
> un commit automático al SVN sin
> saber uno qué está haciendo (o
> cómo lo está haciendo el IDE, que
Creo que estás un poco paranoico ;-) Un IDE no hace las cosas si nosotros no se las decimos, explícitamente.
> es a donde voy: a que sepamos
> cómo hacerlo nosotros) que a que
> nosotros lo tengamos que hacer:
> ese verbo "tener que" implica que
> necesitamos saber cómo hacerlo.
> Es decir: aprender (y si ya
> sabemos, pues practicar)
Si agregamos el Vim como editor solo agregamos dificultad extra. Eclipse nos da un mínimo entorno integrado para ordenarnos, par desarrollar un sistema.
> Otro ejemplo más: "apt-get
> Vs. ./configure && make && make
> install" ¿Qué es mejor? Pues
> sinceramente, para _aprender_, la
> segunda opción.
No te quedes en el "bajo nivel", para aprender a desarrollar sistemas no tienes que construir necesariamente la infraestructura de cero. Ser pragmático es tener la infraestructura pronta para luego solo concentrarnos en los problemas de desarrollo.
¿O me vas a sugerir que empecemos compilando el kernel y luego el servidor Apache... no, verdad? ;-)
> PD: Imagino que esta clase de
> discusiones no representan
> ningún problema para el Gerente
> de Proyecto de la empresa.
No ahora, no en este blog, pero sí más adelante, cuando estemos "simulando la empresa".
No hay que olvidar que un gerente debe ver "el bosque" y su misión final es cumplir con el cliente. Por más buenas intervenciones que hagas, si demoras o dificultas la misión puedes quedar fuera ;-)
Es muy lógica tu actitud, los desarrolladores perdemos la visión del gerente y viceversa. Pero cuando estamos en ambos lados, nos damos cuenta de los errores de ambas posturas y puntos de vista.
> Presupongo que nuestro gerente
> está abierto a escucharnos y a
> acepar ideas que le parezcan
> bien, o a dar explicaciones del
> por qué en las decisiones para el
> desarrollo de nuestros
> proyectos. Con el ánimo de
Sí, hay dos visiones. Puedo representar el clásico "gerente por ascenso" (centralizado, desconfiado, no delega, todos son inútiles y él sabe "todo") o tratar de hacer uno más profesional y moderno, al estilo "Google" (el gerente está para quitarte todos los problemas que te alejen del desarrollo, buscan consenso y no tener él la última palabra de todo, etc).
Va a ser el último, pero hay que gestionar el riesgo, las prioridades y el tiempo. Hay muchas cosas que se van a tener que descartar y para no fracasar tener claro siempre el objetivo primario y fundamental.
> _aprender todos_, claro está. De
> no ser así, este trabajador
> (osea, yo :) se calla la boca y
> sigue (o no) adelante sin hacer
> tanta pregunta y/o generar tanta
> discusión. La intención con las
> discusiones es la de enriquecer
> ya sea los posts que se publican
> o las propias decisiones del
> gerente de proyecto.
No hay problema, fuera de las bromas, se aceptan todas las sugerencias y comentarios, faltaba más. ;-)
hola todos soy de venezuela desarrollo en php desde hace un tiempo pero no me considero PHP senior espero q con esta magnifica iniciativa de enrique aprenda mucho mas este lenguaje q para mi es uno de los mejores en cuanto al entorno no e trabajado con eclipce si lo e visto y escuchado pero yo particularmente uso es zendstudio y estoy muy a gusto espero ver q tal eclipse y a lo mejor me cambie en cuanto al servidorweb el q tengo en mi maquina lo instale con appserv y poseo php 5.2 espero sea el adecuado una vez mas gracias por este taller q seguire muy entuciasmado y espero no morir en el intento.
Pedro caracas, venezuela
Publicar un comentario