-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
250 lines (250 loc) · 13.9 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
<html lang="es">
<head>
<meta charset="utf-8"/><link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/black.css">
<!-- Code syntax highlighting -->
<!--link rel="stylesheet" href="css/zenburn.css"-->
</head>
<body>
<div class="reveal">
<div class="slides">
<section><h3>A lesson learned in life <br> Known from the dawn of time</h3>
</section>
<section><h4>Premature optimization is the root of all evil</h4>
</section>
<section>
<h4> Ariadne 5 ¿Qué puede salir mal?</h4>
Ariadne 5, un cohete diseñado por la agencia espacial europea, en su primer lanzamiento en Junio de 1996, tardó 37 segundos en..<i>explotar</i>.<br>
Mientras hacía cálculos para apuntar el propelente del cohete, convirtió float 64-bit a int 16-bit signed, causó overflow.<br>
No chequeó esa conversión y la unidad de respaldo, idéntica, falló con el mismo error.<br>
Datos basura entraron como válidos, desvió la boquilla girando el cohete en extremo, se expuso a fuerzas fuera de diseño.<br>
</section>
<section>
<img src="img/ariadne5.gif" style="width:80%" title="http://www.yourdailytrends.com/images/uploads/b746828fe1b0571b645fcaf96e01c27c.gif">
</section>
<section><h4>La pureza, independencia, desacople</h4><br>
Son fantasías
</section>
<section><h4>La Inter-dependencia en Teoría</h4>
<img style="width:40%" src="img/mc_escher_bird_design_fragment0001.jpg" title="http://rstessellation.wikispaces.com/file/view/mc_escher_bird_design_fragment0001.jpg"><br>
<img src="img/Pentagonal_tiling_type_9_animation.gif" title="https://en.wikipedia.org/wiki/Pentagonal_tiling#/media/File:Pentagonal_tiling_type_9_animation.gif">
</section>
<section><h4>La Inter-dependencia en la Práctica</h4>
<div>
<img src="img/PanteraProjectsInTheJungle.jpg" style="width:50%" title="https://upload.wikimedia.org/wikipedia/en/thumb/7/73/PanteraProjectsInTheJungle.jpg/220px-PanteraProjectsInTheJungle.jpg">
</div>
<i>Projects in the Jungle</i><br>
</section>
<section><h4>Tipos de Datos</h4>
<ul>
<li>Le dan sentido al compilador (sino usar javascript o hacer diseño gráfico)</li>
<li>En C facilitan más al compilador, para encajar con el micro, que al programador</li>
<li>Tipos primitivos: evitar</li>
</ul>
</section>
<section><h4>Tipos primitivos, casos necesarios</h4>
<ul>
<li>Datos cercanos a hard: bytes, words. Usar <stdint.h></li>
<li>Para declarar tipos compuestos (typedef struct) disfraza a C de "fuertemente" tipado</li>
</ul>
<pre><code class="hljs" data-trim data-noescape>
typedef struct {
uint32_t contador;
uint8_t flags;
}DatoCompuesto_t;
</code></pre>
No está de más repetir, <i>siempre</i> usar <b><stdint.h></b>
</section>
<section>
<h4>const</h4>
<i>const</i> siempre y en todos los argumentos, hasta que No compile nada. Partir de ahí.
</section>
<section><h4>Float, Double</h4>
No usar.
</section>
<section>
<h4>Sleeps, retardos</h4>
No usar.
</section>
<section>
<h4>Threads</h4>
No usar.
</section>
<section>
<h4>for, loops</h4>
1 solo.
</section>
<section>
<h4>if</h4>
No usar, salvo necesidad extrema.<br>
Cuestionar a cada if ¿qué hace ahí? ¿Por qué necesita el programa preguntar eso?<br>
Menos ifs, menos combinaciones, menos sorpresas y errores.<br>
</section>
<section>
<h4>if</h4>
Menos chequear una y otra vez en variables lo que el código ya sabe,<br> <i><b>o debería saber</b></i>.<br>
La función del programa debe estar embebida en su naturaleza, si no sabe lo que hace, no lo compensará preguntando con ifs y variables<br><br>
<i>«If you have to ask what jazz is, you'll never know.»</i> Louis Armstrong
</section>
<section>
<h4>if</h4>
El contexto de la función, el tipo de dato de sus argumentos, la posición de ejecución.. el diseño del programa debe representar información que ahorre preguntas.<br><br>
<i>«Quod natura non dat, Salmantica non præstat»</i>
</section>
<section><h4>Tipos Bit/Boolean</h4>
False. No usar.<br>
Macros útiles para bits :
<pre><code class="hljs" data-trim data-noescape>
#define SETBIT(var, nbit) ((var)|=(1UL<<(nbit)))
#define CLRBIT(var, nbit) ((var)&=(~(1UL<<(nbit))))
#define BITAT(var, nbit) ((var)&(1UL<<(nbit)))
</code></pre>
</section>
<section><h4>Para chequear "booleans"</h4>
<pre><code class="hljs" data-trim data-noescape>
if ( x!=0 ), mejor que if ( x==1 )
</code></pre>
Pero mejor aún constantes con nombres, enums, etc..
Obviamente NO a los magic numbers.
<pre><code class="hljs" data-trim data-noescape>
if ( music != PANTERA ) {
break;
}
</code></pre>
código claro
</section>
<section>
<h4><i>int</i> es enemigo, un mal innecesario</h4>
aceptarlo, conocerlo, es tipo default en constantes, esa basura convivirá con C hasta que se extinga en el infierno.
</section>
<section>
<h4>Periféricos, y DMA are friends</h4>
Todo lo que se pueda hacer por Hardware mejor (hard EXTERNO, aún mejor)
</section>
<section>
<h4>RTOS vs not RTOS</h4>
La elección de la pastilla de matrix.
</section>
<section>
<h4>Linux</h4>
Pastilla azul de matrix.
</section>
<section>
<h4>IRQ's are friends</h4>
Darle a la ISR tareas livianas, buffers, banderitas, pero nunca hard, ni write Outputs.
</section>
<section>
<h4>Hard IO</h4>
Máquinas de estados. No excuses.
</section>
<section>
<h4><i>functions</i> are best friends</h4>
<ul>
<li>Las funciones son para separar y componer, no para ocultar.</li>
<li>Los nombres de las funciones son pistas de su función o inutilidad.</li>
<li>Aprender a programar es sobretodo borrar, crear, nombrar y renombrar funciones.</li>
</ul>
</section>
<section>
<h4><i>Callbacks</i> are risky friends</h4>
No usar, excepto en caso necesario.
</section>
<section>
<h4>Recursividad</h4>
No<br>
</section>
<section>
<h4>Reserva dinámica de memoria</h4>
No.
</section>
<section>
<h4>Arrays, peligrosos</h4>
Evitar, y si acaso, encapsular acceso donde sea posible.
</section>
<section>
<h4>Strings en C: peligrosos (son arrays)</h4>
Mínimo: reemplazar todo uso de <b>strlen</b> por <b>strnlen</b><br>
</section>
<section>
<h4>Estados</h4>
NO. Ni globales, ni static.<br>
<br>
Bueno, se admiten algunos buffers y banderitas para que la amiga ISR nos informe.<br>
</section>
<section>
<h4><i>inline</i> functions</h4>
no confiar en el compilador.
</section>
<section>
<h4><i>volatile</i></h4>
no confiar en el compilador.<br>
volatile, ok, pero no evita accesos no-atómicos,<br>
no es para eso. <br>
Solución : ninguna, salvo horrible disable IRQ, CRITICAL_SECTION's<br>
minimizar lo compartido con ISR
</section>
<section><h4>Varios</h4>
<ul>
<li> Usar git</li>
<li> Manejo dependencias: elegir uno fácil de migrar.</li>
<li> Manejo compilación: elegir uno fácil de migrar.</li>
<li> Frameworks, no usar: ninguno es fácil de migrar.</li>
<li> Datos: JSON (world peace of data format), si se necesita DB, usar clásicas, viejas. Contratar a alguien.</li>
</ul>
</section>
<section>
<h4>Si no se entiende, REFACTOR</h4>
A toda escala, excepto si es algo nuevo o en urgencias.
</section>
<section>
Las consecuencias no son fáciles de preveer.<br>
<img src="img/1FcKXFz.gif" style="width:40%" title="http://i.imgur.com/1FcKXFz.gif">
<h4>Casi siempre CERO código es mejor que cualquier código</h4>
</section>
<section>
<h4>A la belleza incremental..just say NO</h4>
<ul>
<li>Primero el latido<br>
los detalles después (mejor aún, nunca)</li>
<li>Causa y Efecto: cosas de historiadores, fábulas.</li>
<li>Conexión proceso-resultado<br>suele ser incomprensible.</li>
<li>Si los caminos son bellos, es turismo.</li>
</ul><br><br>
<i>La belleza de una obra no necesita estar en el proceso de construcción.</i>
</section>
<section>
<h4>A la belleza incremental..just say NO</h4>
<i>"Así como π no puede sospecharse entre los infinitos términos de una serie que la calcule, menos aún aparecer literalmente entre ellos. Una gran obra nunca figura ni se deduce de los términos de su secuencia de construcción"<br><br>
"La belleza de una persona no se encuentra entre los pliegues de los genitales peludos de sus progenitores, aunque hubieran sido necesarios durante el proceso de reproducción."</i>
</section>
<section>
<h4>Futuro</h4>
<ul>
<li> No. No diseñar estructuras para futuro.</li>
<li> Ni una sola línea, ¿usted adivina el futuro?<br>vaya al casino.</li>
</ul>
<br><br>
Hello? Anybody home? Think, McFly! Think!<br><br>
<i>Es más probable reutilizar la cabeza que el código.</i>
</section>
<section>
"Por las dudas?"<-- NADA<br><br>
¿Qué dudas? <br><br>
Are you talking to me?<br>
...walk on home boy<br>
</section>
<section><h4>Respect, walk</h4>
<!--audio autoplay>
<source src="mp3/respect1.mp3">
</audio-->
</section>
</div>
</div>
<script src="js/reveal.js"></script>
<!--script src="js/plugin/highlight.js"></script-->
<script>
//hljs.initHighlightingOnLoad();
Reveal.initialize();
</script>
</body>
</html>