Extensión de Chrome inglés

Para los que están estudiando inglés.
Un extensión de Chrome que lee lo que has seleccionado.

https://chrome.google.com/webstore/detail/pgeolalilifpodheeocdmbhehgnkkbak

Upstart

Página web en la que explica muy el sistema upstart (/etc/init)

http://upstart.ubuntu.com/cookbook/#mountall-ubuntu-specific

KnowledgeTree

Gestión de documentos en la nube.
https://www.knowledgetree.com/f

8 Best Practices for Adopting Document Management

View more documents from KnowledgeTree Inc.

Five Static Code Audits Every Developer Should Know and Use

http://www.infoq.com/presentations/Five-Static-Code-Audits

ESXi. Tech Support Mode for Emergency Support

Como apagar una maquina en ESXi 4.0 cuando VClient falla.

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1003677
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014165

Entrar en modo TSM

1. Alt+F1
2. Escribimos unsupported
3. Metemos el password
4. clear
5. vm-support -x
6. vm-suport -X
o
6. vm-suport -X -w

Mendix - Esto es marketing

Mendix Agile Business Platform™ in 90 Seconds from Mendix | No Code Just Glory on Vimeo.

DSL tools VS. Model Driven Software Factory

Un buen artículo que diferencia estos dos conceptos. DSL tools y MDS Factory

http://www.theenterprisearchitect.eu/archive/2009/02/18/model-driven-engineering-tools-compared-on-user-activities

DSL tool:

* Workbenches: DSL workbench and transformation workbench.
* Input: DSL definitions and transformation rules.
* Output: solution workbench and generator.
* Tool vendor activities: meta language definition, transformation language definition, workbench implementations.
* Tool user activities: DSL definitions, transformation rules, architecture definition, (domain) framework implementation.
* Examples: openArchitectureWare, MetaEdit+, Microsoft DSL Tools, JetBrains Meta Programming System.

Model Driven Software Factory:

* Workbenches: solution workbench.
* Input: functional specification.
* Output: working application.
* Tool vendor activities: DSL definitions, transformation rules, architecture definition, domain framework implementation, solution workbench implementation.
* Tool user activities: application modeling.
* Examples: Mendix (domain: Service Oriented Business Applications).




"--. Building your own DSLs, i.e. using DSL tools, gives you all the flexibility you'll ever need. However, it also comes with a cost: DSL design isn't that easy. Designing a full set of DSLs for modeling all application aspects will cost a lot of effort (the DSLs will evolve along with the applications you build with them). And don't forget the training, language support, standardization, and maintenance of your languages.

A Model Driven Software Factory, on the other hand, is only useful if it precisely targets the domain you're searching a solution for. You also need to commit you to the vendor of the factory. However, the domain of a Model Driven Software Factory can be quite broad and with current business process engines, workflow engines, and business rules engines, the used languages can be both applicable to multiple problem domains and easy to understand for business engineers. With a Model Driven Software Factory you can directly start using the DSLs for modeling your application and you don't need to have the expertise in-house to define the languages, transformations, and generators yourself"

Casos de Uso y Decision Model

Pueden vivir juntos CU y RN

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1442/Use-Cases-and-Business-Rules-Can-They-Work-Together.aspx

How to start a business analyst career

Dos blogs sobre análisis

Qué estrés cuando uno encuentra blog's tan buenos...

http://www.modernanalyst.com
http://www.pragnalysis.com/
http://www.bridging-the-gap.com/

Dos libros

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers [Paperback]

 Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers [Paperback]

MDA vs. MDD vs. SPL vs. DSL

Ayer, escribiendo un artículo se planteo una duda formal en la frase

"En el diseño del DSL se ha evitado la inclusión de elementos de asociados a la tecnología intentando  aumentar al máximo el nivel de expresividad del mismo acerdándolo al dominio del problema."

Algunos opinan que era incorrecta otros (sólo yo) opinan que es correcta.

En la conversación aperecieron otras discrepancias con la frases, "MDA no está alineado con SPL".

Bueno, intentaré expresar mejor mi opinión  en este post.

Lo primero que quiero decir es que el mundo de Model-Driven y  generación de código los conceptos, ideas y paradigmas se enlazan entre sí de una manera confusa y a veces peligrosa. He buscado en la bibligrafía una comparación entre MDA y MDD que incluyo al final del post.

Brevemente:

• MDA es una iniciativa de OMG interesada en la interoperabilidad entre herramientas,  portabilidad y estandarización. Y no en la productividad y la calidad

• MDA juega con los conceptos UML, MOF, PIM, PSM, XMI, Metamodelos

• MDA no excluye la idea de round-tripping (sincronización de código y modelo). MDD sí
• MDA no usa el concepto de DSL . 

En cambio MDD busca otros objetivos diferentes que son las productividad y calidad en el código.

• MDD usa el concepto de DSL
• Con los DSL hablamos de DSL técnicos o funcionales con mayor o menor grado de expresividad. 
• Si nos vemos forzados a meter detalles tecnológicos  lo que hay que pensar es "no estoy logrando en nivel de abstracción adecuado, ¿es necesario introducir esta semántica en el DSL?" y no "tengo 2 DSLs un PIM y otro PSM". Y mucho menos creer en los mundo de Jupi de MDA y decir "puedo crear otro DSL PSM para otra arquitectura.¡NO!". Si quieres otra arquitectura nos montamos otro generador. E intentaremos mantener el DSL lo más intacto posible de la nueva tecnolgía (si no tendremos otro DSL). El conocimiento de la arquitectura está en el generador y no en los DSL. ¡En algo sustancial se tiene que diferenciar MDD de MDA.!
• Mezclar la idea de DSL PIM y DSL PSM creo que no es buena idea. Pensemos en SQL (un DSL) que intenta abstraerse lo más posible de la integración del sistema gestor de base de datos pero aún así existen diferentes versiones de SQL para diferentes SGDB. No hay un SQL independiente del dominio y otro dependiente.

Sobre la discusión de SPL y MDA, dos detalles:

• La idea de SPL viene SEI y no de OMG
• SPL piensa en productividad y calidad. OMG en interoperabilidad y portabilidad