Desarrollo de software en equipo (Parte 2)


Tecnología

Es muy importante que tu equipo tenga claro el alcance y el matiz tecnológico que le darás a tu proyecto. Como seguramente ya sabes, no es lo mismo hacer una aplicación web que una aplicación de escritorio, o un videojuego 3D, o un sistema con backend al que se conectan múltiples tipos de aplicación cliente.

En el pasado quizá hubiese sido dicho, que es mas importante una gestión cuidadosa que una maleta llena de herramientas. Sin embargo, cada día las herramientas existentes nos dan un grado de poder y un alcance enorme. Piense como hubiese sido escrito su aplicación web favorita hace 7 años, cuando no existía AngularJS, Knockout.JS o (ponga aquí su framework favorito). Hubiese podido entregarse el mismo nivel de funcionalidad al mismo costo de hoy en día?

A continuación le daré un breve resumen de lo que la tecnología le puede entregar en el ahora y una recomendación sobre sus elecciones.

Lenguajes de programación

La promesa de la tecnología en este ámbito es interesante, los lenguajes de programación de ultima generación intentan ofrecer una elevada densidad de funcionalidad por linea de código escrita y un grado de abstracción aun mayor. Los mas modernos lenguajes intentan ser tan declarativos como sea posible con el fin de que el programador pueda expresar sus deseos sin ocuparse de los algoritmos para alcanzar esta expectativa.

“Los lenguajes declarativos de ultima generación … aun se enfrentan a un desafío técnico no superado”

languagesEl paradigma de programación declarativa estriba también en que construir software es realidad escribir una especificación para la cual una implementación será hecha de forma automática, por lo tanto la tarea de testing se hace innecesaria ya que es un supuesto que la implementación automática cumplirá los requerimientos de la especificación. Sin embargo estos lenguajes se enfrentan a un desafío técnico aun no superado, las descripciones declarativas aún son auto-implementadas de maneras suboptimas, por lo que se encuentran fuera de los fines prácticos o cuando mucho limitadas a casos donde el desempeño no es de gran importancia. Por esta y otras razones no seria una decisión sabia seleccionar esta tecnología para emprender tu nuevo proyecto de desarrollo.

Para emprender tu nuevo proyecto de desarrollo de software comercial la oferta tecnología es mucho mas madura fundamentalmente en dos ámbitos, lenguajes de programación imperativos con tipado estático y lenguajes de programación imperativos con tipado dinámico. En el primer grupo puedes encontrar lenguajes populares como C#, Java, Go y C++, y son mi recomendación para el desarrollo de proyectos de software en equipo y con enfoque de ingeniería claro.

La razón para escoger este grupo estriba en que el sistema de tipos fuerte le permite al arquitecto y los desarrolladores interactuar sobre garantías locales claras. Es decir, que el arquitecto puede fácilmente describir interfaces explicitamente en el código fuente que luego los desarrolladores implementarán. Así podrán ponerse de acuerdo con un menor esfuerzo debido a que el código fuente al contener explicitamente las interfaces puede ser auto descriptivo, luego las herramientas de compilación validarán una buena parte de las restricciones que impuso el arquitecto al hacer el diseño.

Por otro lado, los lenguajes de programación dinámicos no validarán las restricciones del diseño durante la fase de compilación por lo cual los detalles de la implementación deberán ser revisados con mayor atención de manera manual para verificar la correctitud de la implementación. La arquitectura por su parte no podrá ser inferida desde el código fuente, por lo que un esfuerzo de documentación será requerido por separado. Adicionalmente, las herramientas de compilación al tener garantías locales generan software mas eficiente ya que explota mas propiedades del código fuente escrito que las que podrían ser inferidas desde el código fuente escrito en un lenguaje dinámico.

Tendencias actuales

Entre las tendencias del desarrollo actual que seguro debes implementar se encuentran:

Control de versiones o Control de código fuente

logo_gitEs un mecanismo que le permite al equipo gestionar y compartir cambios de código fuente. Para tu próximo proyecto la recomendación es usar GIT, un sistema poderosamente flexible a la hora de gestionar el código fuente. La ventaja al usar git es que la evolución del código fuente se puede representar como un árbol donde cada nodo representa una versión del software, pero su gestión le permite fácilmente manejar las bifurcaciones y mantener muy baja la sobrecarga de gestionar diferentes sub desarrollos a la vez.

Automatización de pruebas

Debido a que la verificación automática de programas aun es una promesa lejana y materia de fuerte investigación actual, nuestro software deberá ser probado para poder asegurar que su implementación es correcta. La mejor opción para equipos de desarrollo es escribir pruebas usando el propio código fuente que son ejecutadas automáticamente en cualquier momento para corroborar que un desarrollo nuevo no daña funcionalidad escrita previamente.
coverage_with_resharperComo regla general haga que el equipo implemente pruebas que recorran cada linea de código ejecutable en el sistema, luego deje que una herramienta automática le reporte el porcentaje de código que fue cubierto en dicha ejecución ademas de la cantidad de casos de prueba que fueron exitosos y fallidos. Asegure que su equipo mantiene un nivel de cobertura cercano al 100% y la totalidad de las pruebas resulten exitosas.

Análisis estático de código

static_analysisConsiste en tomar una herramienta automática que revisa el código fuente verificando que un sin numero de reglas están satisfechas. Estas reglas suelen ser configurables y mas blandas que las reglas propias del lenguaje de programación, es decir, el análisis estático no te dirá si un programa es o no correcto desde el punto de vista de como esta escrito, pero puede indicarte usos del lenguaje que aunque son legales para el compilador no son recomendados o no satisfacen restricciones de diseño impuestas para las necesidades particulares del proyecto, o van en contravia de las mejores practicas reconocidas. Entre las mejores herramientas en este rubro tenemos Resharper, StyleCop y SonarQube

Aplicación de formato y estilo automático al código fuente.

Consiste en aplicar un conjunto de reglas que hacen que el código fuente luzca siempre con el mismo estilo de codificación a pesar de que lo escriban personas diferentes.

js_code_style_indentsSuelen tener muchas opciones de configuración, establezca opciones que siempre favorezcan la legibilidad y la productividad de quien lee el código. Por ejemplo, ajuste un numero máximo de caracteres por linea de manera que quien lee el código no requiera hacer scroll en su propia pantalla, este valor solía ser 80 pero debido a las resoluciones que manejamos hoy en día en nuestras pantallas un valor de 140 a 160 es mucho mas útil. Establezca opciones que le permita maximizar la densidad de código siempre que este mantenga legible pero armonice con sus preferencias estéticas.  Instruya a su equipo en bajo la premisa de que el código se escribe primero para las personas y luego para el compilador. Entre las herramientas mas destacadas para este propósito tenemos Resharper, Visual Assist, IntelliJ IDEA

“el código se escribe primero para las personas y luego para el compilador”

Gestión automática de dependencias

nugetsActualmente existen los muy populares gestores de paquetes que le permiten administrar con mucha facilidad las bibliotecas de las cuales nuestro proyecto depende, estas son herramientas que hacen fácil nuestro proceso de construcción y entrega ya que nos permiten mantener actualizadas nuestras dependencias y facilitan la migración cuando deseamos hacer cambios en los paquetes que deseamos usar. Entre las herramientas mas reconocidas de este campo tenemos: Maven, Nuget, ChocolateyIvy, npm, bower, pip

Calidades de construcción

delphi-project-manager-debug-releaseCuando compilas y construyes tu proyecto puedes hacerlo con diferentes fines. Por ejemplo, con el fin de ejecutar pruebas manuales o depurar la ejecución de las ultimas lineas de código que escribiste, o entregarlo al cliente para uso en producción. Debido a esto el resultado de la construcción puede requerir ser configurado con diferentes opciones por ejemplo pedir al compilador el máximo nivel de optimización para una ejecución mas eficiente y de alto desempeño, o por el contrario favorecer la experiencia de depuración, o por ejemplo habilitar la optimización pero dejar también habilitada la comprobación de aserciones de código.
Es muy importante que el arquitecto y al menos un desarrollador senior conozca a fondo las posibilidades que la tecnología de construcción le brinda para tomar el máximo provecho de esta y conseguir los resultados esperados en menor tiempo.

Integración continua y Entrega continua

Es también el santo grial del desarrollo ágil moderno, cuando te encuentras trabajando en equipo, sabes que el trabajo que cada miembro hace al final deberá integrarse al software, pero con un poco de experiencia te das cuenta que puede convertirse en un dolor de cabeza debido a que el trabajo de los miembros puede fácilmente sobrelaparse con el de otros, este problema esta parcialmente resuelto con las herramientas control de código fuente o de control de versiones que vimos mas arriba.

Sin embargo, aunque puedas combinar fácilmente el código de tu equipo en un solo repositorio, no esta garantizado que el código integrado funcionará correctamente estando junto, o peor aun, no dañará funcionalidad escrita con anterioridad. En calidad de agravante, el día que decidas tomar tu software y prepararlo para la entrega al cliente o a la puesta en producción encontraras que algunos aspectos adicionales deben ser solventados, por ejemplo, la creación de un instalador, poblar bases de datos con información semilla, inicializar servicios web, realizar cierta preparación de la maquina anfitriona, etc. Puedes ver que fácilmente esto puede convertirse en un dolor de cabeza que a menudo debe repetirse con cada release. Entonces, aparece el concepto de integración continua, el cual busca integrar automáticamente todos los aspectos del software de manera que en todo momento puedas contar con una versión del software listo para entregar, así podrás conocer y atender tempranamente los problemas propios de la integración y disminuir dramáticamente el riesgo de la entrega.

jenkins-plugin-diagram-saciA las herramientas de integración continua puedes agregar la automatización de muchas de las otras herramientas aquí mencionadas. Entonces el flujo de la integración continua quedaría mas o menos así: cuando un desarrollador somete su trabajo al servidor de control de versiones, el sistema de integración continua obtiene la ultima versión del código fuente obtiene los paquetes de los cuales depende el software, construye el software en las calidades para las cuales haya sido configurado y ejecuta las herramientas de análisis de código y ejecuta las pruebas automáticas. Como resultado de esto el director del proyecto puede ver el estado del desarrollo a medida que los desarrolladores realizan cada contribución. Este reporte puede incluir en forma gráfica la cantidad de código fuente que esta siendo probado en la integración continua a partir del porcentaje de cobertura de las pruebas automáticas y la cantidad de pruebas fallidas o exitosas.

teamcity-383469-1279080600

Algunos sistemas de integración continua permiten configurar un dashboard con métricas adicionales que le permiten al director de proyecto tener una visión mas amplia del estado del mismo.

Entre los servidores de integración continua mas conocidos tenemos: Jenkins, Team Foundation Server, TeamCity, AppVeyor, Travis-CI

Desarrollo de software en Equipo (Parte 1)


He decidido escribir este post con el fin de proveer una pequeña guía que exponga las mejores practicas que he encontrado en mis años de experiencia desarrollando software de clase empresarial.Si estas a punto de empezar un desarrollo o te encuentras dirigiendo un proyecto de desarrollo maduro, estas recomendaciones pueden ser de gran ayuda.

Para desarrollar software en equipo de manera exitosa es necesario tener en cuenta un sin numero de aspectos que dan cuenta de lo complejo que puede ser esta actividad, aquí me enfocare en tres rubros fundamentales: Metodología, Tecnología y Arquitectura.

Metodología

Adopta una metodología, abrázala fuerte y se fiel a esta. scrum-kanban-scrumban-intland-softwareSi desarrollas software comercial que no es de misión critica (donde fallas en el sistema nunca pondrían en riesgo el integridad de una persona) mi recomendación casi inmediata es Scrum y Agile, tambien llamadas metodologías ágiles. Esta metodologías te dirán con exactitud que hacer para sacar adelante un proyecto de desarrollo de software. Ademas utiliza las herramientas  visuales de gestión de equipos que adoptan estas metodologías, por ejemplo puedes usar Team Foundation Server (TFS) or JIRA para apalancar tu equipo si usas Scrum.

tfs_IC810589
TFS screenshot – Miembros del equipo asignados a alguna tarea

Una vez adoptas una metodología, cualquiera que sea, es casi un hecho que el concepto de REQUERIMIENTO llegará a tu vida. La mayoría de metodologías de desarrollo de software concuerdan en ahondar en las necesidades del usuario final y extraer de este las funcionalidades que son un requisito para que se sienta a gusto con el software que al final le entreguemos.

Desarrollar software es un proceso de ingeniería a menudo llevado a cabo por personas de muy variadas profesiones, sin embargo suelen ser ingenieros quienes mayoritariamente toman las riendas de los proyectos de desarrollo y a menudo su formación característica los lleva a cometer un error grave. Es muy común que los ingenieros tengan un visión que intenta “asegurar” el éxito del desarrollo desde la plena confianza en una metodología.

“En la practica satisfacer requerimientos no siempre es sinónimo de satisfacer al cliente”

Pero ten mucho cuidado, ya que en la practica satisfacer requerimientos no siempre es sinónimo de satisfacer al cliente. En un mundo ideal, tu le preguntarías al cliente que desea y el te dirá sus requerimientos, al cabo de un tiempo satisfaces esos requerimientos y el cliente no tendría razón para sentir frustración alguna. En la realidad, la amplia mayoría de oportunidades encontraras que tu cliente realmente no sabe lo quiere a pesar de que responda tus preguntas asertivamente. Es mas, puedes apostar a que cambiará de opinión en varias ocasiones. Esto es completamente natural ya que toda organización esta en ultimas formada por seres humanos a lo cual debe sumarse que tu cliente contrata tu equipo para realizar el desarrollo precisamente porque no tiene la habilidad o el conocimiento para desarrollar el software por si mismo, así que es apenas evidente que no tendrá claras una gran cantidad de cosas. Seguramente te preguntarás, entonces cómo es posible satisfacer al cliente? Esta respuesta vale oro y te la diré sin rodeos:

“Acércate a tu cliente, … busca entender qué lo hace o qué lo haría exitoso en su propio juego”

Primero: Acércate al cliente, conoce tanto como puedas de su actividad, entiende su negocio y busca entender que aspectos lo hacen o lo harían exitoso en su propio juego. suena fácil, verdad? pues no lo es. Cuando digo que entiendas qué lo hace exitoso, me refiero a que genuinamente comprendas por qué sus propios clientes lo buscarían y por qué ellos se quedarían con el, en caso de ser posible entiende de donde proviene su mayor beneficio financiero. No seas tímido, si lo deseas puedes ser transparente en todos estos objetivos. Asume a tu cliente como tu socio, solo entonces entenderás que necesita tu cliente.

“Pregúntale a tu cliente lo que quiere pero no esperes su respuesta”

Segundo: Pregúntale a tu cliente lo que quiere pero no esperes su respuesta. Invierte por adelantado parte de tu tiempo en formular desde tu propio equipo varias soluciones de software adecuadas, deja que el arquitecto y tus mejores hombres realicen prototipos de la tecnología que usarían y selecciona la mejor opción. Deja que sus mentes vuelen, permítete ser creativo. Pero finalmente deja a tu arquitecto seleccionar la mejor solución posible. Y en esto no seas transparente con tu cliente.

Tercero: Cuando su cliente le comunique sus requerimientos, escúchelo pero con su solución ya en mano, arrójese a persuadirlo y guiarlo hacia el camino que ya de antemano decidió de manera que para el sea natural y casi de su propia invención. Pero no le cuentes tu plan en forma completa. Aquí puedes cometer fácilmente un error: NO le presente varias opciones. NO le presente una visión donde empiezas desarrollando un proyecto pero que requiere el desarrollo de varios módulos de un gran software. En lugar de eso, déjalo asumir que existen pocos requerimientos a la vez. Siempre intenta guiarlo y no dejes que se salga del sendero que tu estas trazando para el, sin embargo, siempre como primera medida dale la experiencia de sentir que esta descubriendo el camino por si solo.

“No hay nada mas apaciguador que ver que se hizo solamente lo que estaba planeado”

Cuarto: Siempre debes parecer dar mas de lo esperado, planea un feature o un aspecto del desarrollo con el que puedas sorprender a tu cliente el día de la entrega. Recuerda que la satisfacción de tu cliente no necesariamente esta dada por la satisfacción de los requerimientos, asume el hecho de que esa organización tiene naturaleza humana y en ese sentido dale experiencias enriquecedoras, dale la oportunidad de decir WOW en la reunión de entrega de iteración o release. No hay nada mas apaciguador que ver que se hizo solamente lo que estaba planeado, por eso contribuya a mantener una relación dinámica en el buen sentido de la palabra generando expectativas positivas e instruya a su equipo para que en todo contacto con su cliente se comporte como un profesional exitoso y dinámico.

expectationSi aplicas estos consejos verás como en cada fase del desarrollo tanto tu equipo trabajará en lo que cree es la mejor solución, como tu cliente se mantendrá convencido de que dicho es desarrollo es el mas pertinente posible. Sin embargo debo advertirte que algunos de estos consejos pueden ir en contravía de lo que tu metodología puede decirte, por ejemplo, algunas veces Agile puede decirte que seas transparente con tu stakeholder (cliente) pero si lo haces no podrás entregar nada fuera de lo planeado como indico en el punto 4. Como este pueden existir otras diferencias. Analízalas con calma y verifica que existan formas de armonizarlas.

Mejorar estabilidad del Netgear DGN3500


Los propietarios del DGN3500 estarán de acuerdo conmigo en que es una maquinita muy problemática.

Si en principio sus especificaciones en papel son espectaculares, a la hora del té, este router se queda muy corto en estabilidad y fiabilidad. En mi caso este router tiende a colgarse inesperadamente dejando de responder a toda solicitud. Usualmente la funcionalidad de switch nunca se detiene, pero el enrutamiento y punto de acceso si mueren por completo. En ocasiones el router empieza a funcionar con una conectividad muy lenta hacia Internet de poco menos de 1Mbps.

Resumen de especificaciones

  • Modem ADSL2+ integrado
  • Puerto USB integrado
  • WiFi b/g/n con ancho de banda teorico de  300Mbps
  • Switch Ethernet de 1Gbps

Diagnóstico

Bueno, para no seguir criticando hablemos de las razones:

He notado que este router se calienta demasiado cuando es utilizado por largos periodos de tiempo ininterrumpidos. Por supuesto, para que otra cosa es un router Gigabit con modem ADSL y punto de acceso WiFi, si no es para operar continuamente?

El sistema esta compuesto de tres integrados principales. El PSB508010, un SoC de Lantiq (antes Infineon) que le da la capacidad de modem ADSL2+ y provee el procesador MIPS 4Kc principal. El chip Realtek RTL8366RB responsable del switch Gigabit Ethernet; y El chip Atheros  AR9233 que provee WiFi IEEE-802.11bgn esta conectado al resto sistema via bus PCI cableado en la tarjeta.

El culpable según mi análisis es el chip SoC Lantiq PSB que disipa demasiado calor. Por otro lado, el RTL8366RB  no tiene problemas de disipación excesiva de calor. El AR9233 también se calienta considerablemente.

DGN3500
DGN3500 – Placa PCB

Netgear DGN3500 - original

Solución propuesta

Para verificar si el calentamiento era una verdadera razón del mal funcionamiento, decidí añadir un disipador de calor al SoC de Lantiq, la mayor fuente de calor en el sistema y abrir una entrada de aire adicional dentro de la caja. Es curioso que el ensamblado no ofrece ningún tipo de blindaje ni siquiera para la sección de RF. Para ello fue necesario un disipador viejo tomado de una placa base de computador inservible, seguro puedes conseguir alguno fácilmente escarbando en computadores viejos o equipos de sonido dañados, un poco de pasta o crema disipadora de calor. Un moto-tool con disco de carburo para abrir el hueco en el acrilico. Y muchas ganas de ver tu router funcionando bien.

NETGEAR DGN3500 con disipado de calor añadido y funcionando
NETGEAR DGN3500 con disipado de calor añadido y funcionando
NETGEAR DGN3500 con disipado de calor añadido
NETGEAR DGN3500 con disipado de calor añadido

Este Post fue subido a traves de el 🙂

Undercover! HP Envy 4 – 1050LA


Que hay dentro de un Envy4-1050la?

En otros paises fuera de suramerica este PC tambien se vende con el nombre de ENVY 6t-1000 series

Specs

La verdad bajo las cubiertas. The truth under the hood!

Curiosidades

  • El promocionado Beats Audio fisicamente consiste de un codec de audio HD integrado fabricado por IDT y un sistema de bocinas con gomas que atenuan los trastabilleos cuando las bocinas vibran cerca del chasis.
  • El procesador Intel Core i5-3317U esta directamente soldado sobre la PCB, no hay socket y ya no tendremos oportunidad de reemplazarlo. Con esto se ha logrado un diseño de menor espesor.
  • El Intel Core i5-3317U es un modelo de muy bajo voltaje para lograr larga vida en la bateria logrando un sistema con estas dimensiones. Incorpora los ahora ya afamados transistores 3D  Tri-Gate fabricado en el nodo de 22nm. Sus caracteristicas pueden verse aqui.
  • La memoria RAM DDR3 viene en sockets, y por lo tanto es ampliable.
  • La memoria RAM OEM no viene en configuracion simetrica. En su lugar usa dos modulos: 4GB+2GB, algo un poco raro sabiendo que tenemos un diseño de controlador doble canal.
  • Un gran porcentaje del volumen es ocupado por la bateria de 52Wh
  • Hay un gran espacio vacio en la PCB contiguo al procesador. La gran isla de cobre en el parece indicar que se uso para crear una capacitancia para desacople de fuente de muy alta frecuencia.
  • Hay un modulo de PCB desacoplable con la pila del RTC sobre el. A mis ojos parece ser el alojador del firmware BIOS/EFI.

Muestra del Resaltado de sintaxis para Mozart OZ en Notepad++
Resaltado de sintaxis para Mozart OZ en Notepad++

Estos ultimos meses estuve escribiendo un poco de codigo en Mozart OZ y no era del todo mi gusto usar emacs para la edicion de código. Cuando se escribe aplicaciones con funtores no es de mucha utilidad el entorno y su resaltado de sintaxis funciona con algunos elementos.

Pongo a disposicion mi archivo de configuracion para que el editor el lenguaje Notepad++ resalte la sintaxis de Mozart OZ.

http://code.google.com/p/mozart-oz-notepad-plus-plus/

Por qué no usar el LM741 en nuestros circuitos de hoy en dia?


Pinout of a generic 741 operational amplifier ...
Image via Wikipedia

El mundialmente conocido amplificador operacional LM741 (caballito de batalla de todos los tiempos)  es un diseño muy antiguo cuyas especificaciones han sido enormemente superadas por muchos otros amplificadores operacionales de los ultimos tiempos. El 741 se gano el aprecio de multitudes de diseñadores por sus espectaculares prestaciones en su época, sin embargo hoy en dia (Octubre 2011) existen muchos nuevos modelos de op-amps que superan al 741 en prácticamente todos los escenarios donde un 741 antes hubiese sido ideal, especialmente en el tema de la alimentación.

El 741 es muy popular en diseños aficionados y de estudiantes debido a que es el ejemplo típico en los salones de clase y libros teóricos acerca del funcionamiento interno de los amplificadores a par diferencial.

Que alternativas hay?

En mi pais, Colombia, no es muy fácil conseguir ICs especializados pero los siguientes son los modelos que según mi experiencia son fáciles de conseguir en las tiendas de componentes electrónicos y son apropiados para aplicaciones de bajo ancho de banda.

Puedes considerar estos integrados para reemplazar el 741 en tus diseños: LF351, LF353, LM358, LM324, TSV321, TSV358, TSV324.

Las ventajas de los nuevos modelos usualmente estriban en el ancho de banda, slew rate, y sobre todo en el requerimiento de tensión de alimentación, ya que hoy dia la tendencia es usar bajos voltajes (especialmente si involucras circuiteria digital en la que el estandar es 3.3V o si esperas operar el circuito desde baterias comerciales). Normalmente todos estas opciones están disponibles también en empaquetados SMD SOIC-8 por un precio igual o menor al de un 741.

LM358 y LM324

Un solo chip LM358 contiene dentro de si, dos amplificadores operacionales. (ver datasheet)

Un solo chip LM324 contiene dentro de si, cuatro amplificadores operacionales (ver datasheet).

Los amplificadores integrados en el LM358 y LM324 son identicos.

Ancho de banda a ganancia unitaria: 1MHz

Alimentacion dual desde ±1.5V hasta ±16V (3V hasta 32V a fuente sencilla). Lo cual le permite reducir los requerimientos de tensión en la fuente.

LF353 y LF351 o TL084

Un chip LF351 contiene un solo amplificador operacional (ver datasheet).

Un solo chip LF353 contiene dentro de si, dos amplificadores operacionales (ver datasheet).

Los amplificadores integrados en el LF353 y LF351 son identicos.

Ancho de banda a ganancia unitaria: 4MHz  (lo cual lo hace a penas apropiado para aplicaciones de audio como preamplificadores, ecualizadores, filtros activos, etc).

Entrada JFET, lo cual le da una impresionante impedancia de entrada de 12MOhms. (Ideal para acoplar sensores u otros dispositivos de señal muy débil).

Alimentación a fuente dual desde +/-6V (o a fuente sencilla de 12V) menos de este valor causará una gran degradacion en el ancho de banda y rango de voltaje de salida, operable hasta +/-18V (o hasta 36V a fuente sencilla).

Fue diseñado para reemplazar al LM358 en casi todas sus aplicaciones pero observa bien los requerimientos de alimentación y encontrarás casos en donde no es posible el reemplazo.

TSV321, TSV358, TSV324

Su voltaje de operación es mucho mas limitado (+2.5V hasta +6V ) sin embargo se trata de dispositivos Rail to rail. (ver datasheet)

Ancho de banda a ganancia unitaria: 1.4MHz

Son dispositivos Rail-to-Rail (riel a riel) es decir que pueden operar en todo el rango de voltaje en el que están alimentados. Lo cual permite diseñar usando fuentes de voltaje de menor tension.