There only one way to tell open the box
cherry valley forever

Love Begins

titsay

祝日 / Permanent Vacation
Not today Justin
art blog(derogatory)
trying on a metaphor
One Nice Bug Per Day

No title available
h
Sweet Seals For You, Always
2025 on Tumblr: Trends That Defined the Year

JVL
No title available
Misplaced Lens Cap

★
will byers stan first human second
hello vonnie

ellievsbear
🪼

seen from Türkiye
seen from Brazil

seen from Türkiye
seen from United States

seen from United States
seen from Türkiye

seen from South Korea

seen from Germany

seen from United Kingdom

seen from Bangladesh
seen from Germany
seen from United States

seen from Malaysia
seen from Australia
seen from Japan
seen from Colombia
seen from Colombia

seen from United States

seen from United States

seen from Colombia
@mdelira
There only one way to tell open the box
Anatomy of a Process Area
The CMMI uses Process Areas quite extensively throughout the Model. It is a very useful way to outline how to assess a process. To me, the concepts outlined here are over and above what usually describes a process (as per BPMN). There are overlaps, and where they do occur, I have found it a useful shift of thinking when asked to do assessments.
Process Area: a cluster of related processes in an area that, when implemented collectively, satisfies a set of goals important for making improvements to said area
Specific Goals: the unique characteristics that must be present to satisfy the process area.
Generic Goals: describes the characteristics that must be present to institutionalize processes that implement a process area
Specific Practices: the description of an activity that is considered important in achieving the associated specific goal.
Generic Practices: generic practices associated with a generic goal describe the activities that are considered important in achieving the generic goal and contribute to the institutionalization of the processes associated with a process area.
Example Work Products: sample artefacts
Sub-practices: a detailed description that provides guidance for interpreting and implementing a specific or generic practice
Generic Practice Elaboration: provide guidance on how the generic practices can be applied uniquely to process areas
Echa un vistazo al Tweet de @NodeAddiction:
Mendel’s Laws
1. the Law of Dominance 2. the Law of Segregation 3. the Law of Independent Assortment
The Law of Dominance
In a cross of parents that are pure for contrasting traits, only one form of the trait will appear in the next generation. Offspring that are hybrid for a trait will have only the dominant trait in the phenotype.
Mendel crossed many different combinations of pea plants
When pure tall plants crossed with pure short plants, all the new pea plants (referred to as the F1 generation) were tall.
Similarly, crossing pure yellow seeded pea plants and pure green seeded pea plants produced an F1 generation of all yellow seeded pea plants.
Instead of creating medium height plants or yellowy-green seeds that might have been expected, one trait came out as dominant
Ie there is a gene that codes for height. One allele (form of the gene) codes tall and another short. In this case, the tall is dominant
The dominant is represented with a capital letter (eg T for tall) while the recessive is lower case (t)
The cross Mendel performed was
Parents (P): TT x tt
where T = the dominant allele for tall stems & t = recessive allele for short stems
The punnet square looks like:
A plant that contains the dominant T will be tall, explaining why 100% of the plants he crossed came out tall.
The Law of Segregation
During the formation of gametes (eggs or sperm), the two alleles responsible for a trait separate from each other. Alleles for a trait are then “recombined” at fertilization, producing the genotype for the traits of the offspring.
Now, Mendel decides to cross the offspring from the above experiment - all Tt
Two of the “F1” generation (tall) are crossed
Would assume to get all tall again as tall is dominant
HOWEVER some come out short
“F2″ generation is about ¾ tall & ¼ short
Therefore:
Parent plants for this cross each have one tall factor that dominates the short factor & causes them to grow tall.
To get short plants from these parents, the tall & short factors must separate (allowing the possibility of 2 short factors coming together without a dominant tall) otherwise a plant with just short factors couldn’t be produced
The factors must SEGREGATE themselves somewhere between the production of sex cells & fertilization
Two hybrid parents, Tt x Tt.
The punnet square would look like this:
This splitting happens during meiosis.
The Law of Independent Assortment
Alleles for different traits are distributed to sex cells (& offspring) independently of one another.
Previously Mendel addressed one trait at a time.
He noticed that different traits had no effect on each other, eg being tall didn’t automatically mean the plants had to have green pods
The different traits seem to be inherited INDEPENDENTLY.
The genotypes of our parent pea plants will be:
RrGg x RrGg where "R” = dominant allele for round seeds “r” = recessive allele for wrinkled seeds “G” = dominant allele for green pods “g” = recessive allele for yellow pods
The results from a dihybrid cross are always the same:
9/16 boxes (offspring) show dominant phenotype for both traits (round & green),
3/16 show dominant phenotype for first trait & recessive for second (round & yellow)
3/16 show recessive phenotype for first trait & dominant form for second (wrinkled & green)
1/16 show recessive form of both traits (wrinkled & yellow).
Summary:
In 1994, a member of the newsroom named Rich Meislin wrote an internal memo about the value of “computer-based services” that The Times could offer its readers. One of the proposed services was RecipeFinder: a database of recipes “searchable by key ingredient” and “type of cuisine.” It took the company almost 20 years, several failed starts and a massive data cleanup effort…
… The most challenging aspect of the recipe parsing problem is the task of predicting ingredient components from the ingredient phrases. Recipes display ingredients like “1 tablespoon fresh lemon juice,” but the database stores ingredients broken down by name (“lemon juice”), quantity (“1″) , unit (“tablespoon”) and comment (“fresh”). There is no regular expression clever enough to identify these labels from the ingredient phrases.
… Extracting structured data from text is a common problem at The Times, and for 164 years the vast majority of this data wrangling (e.g. cataloging, tagging, associating) has been done manually. But there is an ever-increasing appetite from developers and designers for finely structured data to power our digital products and at some point, we will need to develop algorithmic solutions to help with these tasks. The recipe parser, which combines machine learning with our huge archive of labeled data, takes a first step towards solving this important problem.
…
[our data product (recipe database)] relies heavily on nearly six years of effort to clean, catalogue and structure our massive recipe archive.
We now have a treasure trove of structured data to play with: the database contains [at least] 17,507 recipes, 67,578, steps, 142,533 tags and 171,244 ingredients broken down by name, quantity and unit.
- ¿qué religión practicas? - Esa que tiene todas esas reglas bonitas que no aplican para la vida real ... cristiandad!
Simpson, Homero.
Uno de los factores que contribuyen a evitar que más personas acepten nuevas o diferentes formas de pensar estriba en que un buen número de seres humanos suele invalidar la información, las evidencias o los argumentos más racionales cuando éstos contradicen la forma en que el individuo entiende y concibe el mundo.
Alguien
Homero ...
Profundo EAP (Estúpido Afán Protagonista)
Es fundamental aprender a diferenciar a una persona que ha caído en una dependencia de aquéllas que buscan llamar la atención: Un adicto no grita a los cuatro vientos que tiene una adicción. Nadie nunca ha estado orgulloso de sus debilidades; no se puede presumir algo de lo que no se es consciente.
Tomarte una foto con una cerveza en la mano no te hace un alcohólico, por más que lo escribas en la descripción. Así mismo, los verdaderos fanáticos del sexo no van por ahí diciendo que son fanáticos del sexo, los falsos fanáticos del sexo son realmente fanáticos de la atención, ergo, los fanáticos de la atención no van por ahí diciendo que son fanáticos de la atención.
The science of data
The science of data applied to the understanding of software development and their predictable estimation.
Validation with experimental data is key. Knowing what experimental validation to conduct next is just as important. The science of data can be classified into a few separate high level components including:
Data Acquisition - Operating your own experimental lab, or software factory, is ideal when it comes to generating and collecting data. However, generated data can be fairly sparse for a data scientists compared to combining it with data sources from other institutions and databases around the world. Acquiring as much data as possible is important. Even more important is to have the ability to reduce the dimension of your data, keep it within a category, context or vertical. Data acquisition requires nimble chops in the area of computer science and standards organizations. Data pre-processing and normalization must be done as most data remains unstructured or in non-standardized formats. A variety of data types including, numerical, text, images even audio must be used in order to maximize discovery.
Data Processing or Data Munging - Data munging means taking data that's stored in one format and changing it into another format. There are several distinct components and steps involved in a data-munging operation
The munge operation: Once the source data is extracted, we begin our munge operation. This operation can be any kind of transformation. We can reverse data, expand data, and recombine data.
Sort algorithms: Some of the world's brightest mathematicians have created sort algorithms, and all of these algorithms can be programmed or used by us.
Data structure and design: The central munge operation must be able to represent the data structures for both the source and the sink (which is essentially the destination), no matter how complex. It must also be able to transform data from one structure into the other.
Business rules: The ability to easily encapsulate business rules within programming languages modules, and can provide reusable, business-specific data transformations.
The data sink: Our transformed data is finally deposited within a chosen data sink. A data sink works conceptually the same way as a "heat sink" does in engineering; it sucks away the final output from a processing operation. In data munging, this output is the final data generated, rather than the unwanted "heat" in the process. (In engineering, the heat would be generated by a piece of electrical equipment such as a satellite or a laptop computer.)
Then, being able to prepare data as input to sophisticated algorithms is one step in the data processing or data munging stage. Reformatting, parsing, structuring, dimension reduction and normalization are important when preparing data to be analyzed for patterns, hidden relationship extraction, exploration, interpretation and meaningful accurate visualization.
Data Analytics - This is by far the most important component of data science - the development of advanced algorithms. Many like to use general methods based on formal approaches. This only gets you so far. Putting the work into developing specialized algorithms that are based on experimental methods is key. Why use watered down approaches that everyone else is using for the last 20 years? Applied biomimicry can be a powerful approach in this area. Getting your algorithms to mimic portions of human cognition should be at the forefront of anyone's algorithmic development path. Algorithms should be processing data similar to the way a human might process data or extract hidden patterns and inferences from data. Applications in this area relate to true data science. Algorithms should be able to combine pieces of knowledge to infer a new direction for discovery.
Data Curation - The human brain remains the most intelligent data processor we have access to. Real humans combing over input data, output data or results while sending feedback to the algorithms is critical for accurate and meaningful results interpretation.
Data Interpretation & Visualization - Garbage in, garbage out or non-meaningful input to a visualization tool will provide non-meaningful results. Providing visualization tools with meaningful data cannot be over expressed. Only then will new insights, interptations, hypotheses and discoveries be made.
When a data science pipeline includes all of these components it can then be focused on a particular area. New insights gained from the interpretation of data can be used to form new hypotheses.
Qué ridículo ...
Yo veo al niño arrastrar los pies y me dan ganas de imitarlo. Lo hago, pero disimuladamente y no sin antes voltear a mi alrededor para ver si nadie me está mirando. Me río avergonzada: qué ridículo temer al ridículo por hacer algo carente de explicación, como si la adultez fuera vestirse de porqués, aunque sean falsos y nadie se los crea.
Big Data is like teenage sex ...
Everyone talks about it,
Nobody really knows how to do it,
Everyone thinks everyone else is doing it,
So everyone claims they are doing it ...
Proprietary software, a decrepit model
Steven Anthony Ballmer led Microsoft into an impasse because their business model, and their stubbornness, it was no longer adapted to the reality of today's technological world. He reacted late to beat competitors imposed believing his reputation preceded him and went from being challenged to become the challenger Lollipop and iOS8 Android in mobile and Linux on the desktop. The facts are:
Office free for iPad and Android. .NET Core is Open Source. Nokia to use Android on your N1 accepts his bad strategy and how expensive it cost to go for the Lumia family.
La insoportable levedad del ser.
¡50 publicaciones!
Por lo demás, bebía como un cosaco, fumaba habanos, usaba sombrero tejano, botas ídem y estaba habituado a vivir en un país donde los criminales eran individuos que mataban a otros: no una máquina estatal que tragaba personas y escupía sus huesos.
Leila Guerreiro
… no soy un desarrollador!
Erase una vez que se era, un lejano país donde vivían dos cerditos, Pablo y Adrián que, además, eran hermanos. Ambos eran los cerditos más listos de la granja y, por eso, el gallo Iván (el gerente de la misma) organizó una reunión en el establo, donde les encargó desarrollar un programa de computadora para controlar el almacén de reservas. Les explicó qué quería saber en todo momento: cuántos sacos de grano había y quién metía y sacaba sacos de grano del almacén. Para ello sólo tenían un mes pero les advirtió que, en una semana, quería ya ver algo funcionando. Al final de esa primera semana, eliminaría a uno de los dos.
Adrián, que era el más joven e impulsivo, inmediatamente se puso manos a la obra. “¡No hay tiempo que perder!”, decía. Y empezó rápidamente a escribir líneas y líneas de código. Algunas eran de un reciente programa que había ayudado a escribir para la guardería de la vaca Paca. Adrián pensó que no eran muy diferentes un almacén de grano y una guardería. En el primero se guardan sacos y en el segundo, pequeños animalitos. De acuerdo, tenía que retocar algunas cosillas para que aquello le sirviera pero bueno, esto del software trata de reutilizar lo que ya funciona, ¿no?
Pablo, sin embargo, antes de escribir una sola línea de código comenzó acordando con Iván dos cosas: qué era exactamente lo que podría ver dentro de una semana y cómo sabría que, efectivamente, estaba terminada cada cosa. Iván quería conocer, tan rápido como fuera posible, cuántos sacos de grano había en cada parte del almacén porque sospechaba que, en algunas partes del mismo, se estaban acumulando sacos sin control y se estaban estropeando. Como los sacos entraban y salían constantemente, no podía saber cuántos había y dónde estaban en cada instante, así que acordaron ir contabilizándolos por zonas y apuntando a qué parte iba o de qué parte venía, cada vez que entrara o saliera un saco. Así, en poco tiempo podrían tener una idea clara del uso que se estaba dando a las distintas zonas del almacén.
Mientras Adrián adelantaba a Pablo escribiendo muchas líneas de código, Pablo escribía primero las pruebas automatizadas. A Adrián eso le parecía una pérdida de tiempo. ¡Sólo tenían una semana para convencer a Iván!
Al final de la primera semana, la demo de Adrián fue espectacular, tenía un control de usuarios muy completo, hizo la demostración desde un móvil y enseñó, además, las posibilidades de un generador de informes muy potente que había desarrollado para otra granja anteriormente. Durante la demostraciónn hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa pero, salvo eso, todo fue genial. La demostración de Pablo fue mucho más modesta, pero cumplió con las expectativas de Iván y el programa no falló en
ningún momento. Claro, todo lo que enseñó lo había probado muchísimas veces antes gracias a que había automatizado las pruebas. Pablo hacía TDD, es decir, nunca escribía una línea de código sin antes tener una prueba que le indicara un error. Adrián no podía creer que Pablo hubiera gastado más de la mitad de su tiempo en aquellas pruebas que no hacían más que retrasarle a la hora de escribir las funcionalidades que había pedido Iván. El programa de Adrián tenía muchos botones y muchísimas opciones, probablemente muchas
más de las que jamás serían necesarias para lo que había pedido Ivan, pero tenía un aspecto “muy profesional”.
Iván no supo qué hacer. La propuesta de Pablo era muy robusta y hacía justo lo que habían acordado. La propuesta de Adrián tenía cosillas que pulir, pero era muy prometedora. ¡Había hecho la demostración desde un móvil! Así que les propuso el siguiente trato: “Les pagaré un 50% más de lo que inicialmente habíamos presupuestado, pero sólo a aquel de los dos que me haga el mejor proyecto. Al otro no le daré nada”. Era una oferta complicada porque, por un lado, el que ganaba se llevaba mucho más de lo previsto. Muy tentador. Pero, por el otro lado, corrían el riesgo de trabajar durante un mes completamente gratis. Mmmmm.
Adrián, tan impulsivo y arrogante como siempre, no dudó ni un instante. “¡Trato hecho!”, dijo. Pablo explicó que aceptaría sólo si Iván se comprometía a colaborar como lo había hecho durante la primera semana. A Iván le pareció razonable y les convocó a ambos para que le enseñaran el resultado final en tres semanas.
Adrián se marchó pitando y llamó a su primo Sixto, que sabía mucho y le aseguraría la victoria, aunque tuviera que darle parte de las ganancias. Ambos se pusieron rápidamente manos a la obra. Mientras Adrián arreglaba los defectillos encontrados durante la demo, Sixto se encargó de diseñar una arquitectura que permitiera enviar mensajes desde el móvil hasta un web service que permitía encolar cualquier operación para ser procesada en paralelo por varios servidores y así garantizar que el sistema estaría en disposición de dar servicio 24 horas al día los 7 días de la semana.
Mientras tanto, Pablo se reunió con Iván y Bernardo (el encargado del almacén) para ver cuáles deberían ser las siguientes funcionalidades a desarrollar. Les pidió que le explicaran, para cada petición, qué beneficio obtenía la granja con cada nueva funcionalidad. Y así poco a poco, fueron elaborando una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas. A continuación, Pablo fue, tarjeta a tarjeta, discutiendo con Iván y Bernardo cuánto tiempo podría tardar en terminarlas. De paso, aprovechó para anotar algunos criterios que luego servirían para considerar que esa funcionalidad estaría completamente terminada y eliminar alguna ambigüedad que fuera surgiendo. Cuando Pablo pensó que, por su experiencia, no podría hacer más trabajo que el que ya habían discutido, dio por concluida la reunión y se dispuso a trabajar. Antes que nada, resolvió un par de defectos que habían surgido durante la demostración y le pidió a Iván que lo validara. A continuación, se marchó a casa a descansar. Al día siguiente, tomó la primera de las tarjetas y, como ya había hecho durante la semana anterior, comenzó a automatizar los criterios de aceptación acordados con Iván y Bernardo. Y luego, fue escribiendo la parte del programa que hacía que se cumplieran esos criterios de aceptación. Pablo le había pedido ayuda a su amigo Hudson, un coyote vegetariano que había venido desde Holanda a pasar el invierno. Hudson no sabía programar, pero era muy rápido haciendo cosas sencillas. Pablo le encargó que comprobara constantemente los criterios de aceptación que él había automatizado. Así, cada vez que Pablo hacía algún cambio en su programa, avisaba a Hudson y este hacía, una tras otra, todas las pruebas de aceptación que Pablo iba escribiendo. Y cada vez había más. ¡Este Hudson era realmente veloz e incansable!
A medida que iba pasando el tiempo, Adrián y Sixto tenían cada vez más problemas. Terminaron culpando a todo el mundo. A Iván, porque no les había explicado detalles importantísimos para el éxito del proyecto. A la vaca Paca, porque había incluido una serie de cambios en el programa de la guardería que hacía que no pudieran reutilizar casi nada. A los inventores de los SMS y los webservices, porque no tenían ni idea de cómo funciona una
granja. Eran tantos los frentes que tenían abiertos que tuvieron que prescindir del envío de SMS y buscaron un generador de páginas web que les permitiera dibujar el flujo de navegación en un gráfico y, a partir de ahí, generar el esqueleto de la aplicación. ¡Eso seguro que les ahorraría mucho tiempo! Al poco, Sixto, harto de ver que Adrián no valoraba sus aportaciones y que ya no se iban a usar sus ideas para enviar y recibir los SMS, decidió que se marchaba, aún renunciando a su parte de los beneficios. Total, él ya no creía que fueran a ser capaces de ganar la competición.
Mientras tanto, Pablo le pidió un par de veces a Iván y a Bernardo que le validaran si lo que llevaba hecho hasta aquel momento era de su agrado y les hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvió para corregir algunos defectos y cambiar algunas prioridades. Iván y Bernardo estaban francamente contentos con el trabajo de Pablo. Sin embargo, entre ellos comentaron más de una vez: “¿Qué estará haciendo Adrián? ¿Cómo lo llevará?”.
Cuando se acercaba la fecha final para entregar el programa, Adrián se quedó sin dormir un par de noches para así poder entregar su programa. Pero eran tantos los defectos que había ido acumulando que, cada vez que arreglaba una cosa, le fallaba otra. De hecho, cuando llegó la hora de la demostración, Adrián sólo pudo enseñar el programa instalado en su portátil (el único sitio donde, a duras penas, funcionaba) y fue todo un desastre: mensajes de error por todos sitios, comportamientos inesperados... y lo peor de todo: el programa no hacía lo que habían acordado con Iván. Pablo, sin embargo, no tuvo ningún problema en enseñar lo que llevaba funcionando desde hacía mucho tiempo y que tantas veces había probado. Por si acaso, dos días antes de la entrega, Pablo había dejado de introducir nuevas características al programa porque quería centrarse en dar un buen manual de usuario, que Iván había olvidado mencionar en las primeras reuniones porque daba por sentado que se lo entregarían. Claro, Adrián no había tenido tiempo para nada de eso.
Moraleja:
Además de toda una serie de buenas prácticas y un proceso de desarrollo ágil, Pablo hizo algo que Adrián despreció: acordó con Iván (el cliente) y con Bernardo (el usuario) los criterios mediante los cuáles se comprobaría que cada una de las funcionalidades estaría bien acabada. A eso que solemos llamar “criterios de aceptación”, Pablo le añadió la posibilidad de automatizar su ejecución e incorporarlos en un proceso de integración continua (que es lo que representa su amigo Hudson en este cuento). De esta manera, Pablo estaba siempre tranquilo de que no estaba estropeando nada viejo con cada nueva modificación. Al evitar volver a trabajar sobre asuntos ya acabados, Pablo era más eficiente. En el corto plazo, las diferencias entre ambos enfoques no parecen significativas, pero en el medio y largo plazo, es evidente que escribir las pruebas antes de desarrollar la soluci ́on es mucho más eficaz y eficiente.