TI2011 Spring 2020

--Originally published at Coder Bebop

How long was this last partial? Three weeks long? I hardly even felt it. I only remember two guest speakers, honestly. If there was another one I feel bad for not remembering. Mr. Escobedo gave us a good talk about finances, and the last person, the unit testing guy.

Something I would recommend Mr. Escobedo (though, I have done it myself, and now I see it as a little disrespectful) is laughing at the guy who asked a question about the current mexican government. It is okay to make a point by laughing, but sometimes when you are in a more serious environment (I mean, half of the class does not even turn their cameras on, and the other half never talks), you should not take for granted that your audience will respond as you hope it will.

As for the Unit Testing fella (can’t remember his name), he kept talking about how Unit Testing almost by itself could land us a job, but I wish he would have been a little more direct and make emphasis on the job part (since I believe is what most people are really into throughout their career) and then tell us about his topic. I liked his examples on it, though.

In the end, the fact that testing is not only in our lives as software engineers, but also in our daily routines and outside activities gives this class an edge and allows students to experiment a satisfaction that few other courses give them.

--Originally published at Coder Bebop

In my heart at least, I feel like marrying a cybersecurity master’s degree in the future. So when I heard Maggie was into that, the very mentioning of the word made me pay even more attention than one usually does to a guest speaker (yes, I am generalizing to not feel bad about my lack of attention at times). It was beautiful to hear you can learn about the topic without the need to have a bachelor’s in Computer Science. On the other hand: it was painful to hear I didn’t need to study a bachelor’s to learn it, and I never did so (hey, I was in PrepaTec, in Sonora! They only care about teaching leadership without further knowledge here). It got me excited about the idea of purchasing infosec books, now that I am picking up the habit of reading more than ever.

Another interesting topic which is always good to bring up, since our lives revolve around it, whether we want to admit it or not, is that of money. With this, I am talking about the talk we had with Ricardo Escobedo, and it is always good to remind students to care for their earnings and maybe use them up on something which will prove more fruitful.

--Originally published at Coder Bebop

The Virtual Private Cloud, a.k.a. EC2-VPC, one of the main components you are bound to use when working with AWS. The first configuration question when working with WorkSpaces, VDI solution, or RDS will be: what VPC do you want?

A VPC is a logically isolated “data center” where your computer instances and various AWS services reside. Any failure to secure a correct VPC is on Amazon, while failure to provide a secure design for the hosted application is on the client.

AWS’s VPCs do not always contain the services promised to the client within themselves. Exposure to such services generally start and end at Layer 3 level, meaning they come from Amazon themselves, and are given whenever they are asked for. This is due to the fact that thousands of customers use them and are running on a massive shared network infrastructure, and running them internally would not offer such a flexible design to them. This is why AWS does not make use of VLANs either, since such technologies cannot scale well. Nor does it use MLPS.

--Originally published at Coder Bebop

A very important and more often than not overlooked aspect of any cloud infrastructure, in this particular case, working with AWS, is the location of the services. AWS has an extensive decentralization and a tight grip on the location of its main data centers, allowing for a more secure and less compromised site for their physical layer. Nevertheless, the location for one’s use of AWS varies in both intensiveness and offered services.

Something often slightly criticized about AWS is its Service Level Agreement (SLA). Something expected about a cloud service is for it to be available 24/7, without a hitch. The problem, as with everything, more larger its extension around the world, and the stronger its products become, they tend to be more complex; the maintenance is something essential, yet very hard to offer full-time. Most services at Amazon are attached to an SLA, though some do not have it at all.

The AWS Customer Agreement is the foundation for the terms and conditions of the overall service one may receive. Its major considerations are:

• Changes: There is bound to be, lots of them. With or without warning. This is the world of software engineering, after all.
• Security & Privacy: Backup images shall be created in order to keep a safe copy of all data, in case of some failure.
• Clients’ Responsibilities & Indemnification: Everything involving the end users is responsibility of Amazon’s client (you), including any illegal actions.
• Quality of Service: Amazon is responsible for this, only if the client proves he has done everything in his power to maintain everything running correctly (OS kernel up-to-date, required network speeds, optimized EBS instances, etc.).
• Availability: Not every service will be available, the customer must plan for this.

Something important to have in mind when using any cloud service is Continue reading "AWS – Designing Global Services"

--Originally published at Coder Bebop

I am not quite fond of testing (who is, honestly?), but seeing how it is an essential part of the process (sometimes), it is worth taking a look into the thoughts and methodologies thriving in the industry regarding it. Chaos engineering and TCR bring up some interesting insight to the mix, but I think I would very much rather the Webster Tomskins (gosh, did I even spell it right?) approach: when you are starting a project, you have absolute, total control of everything, the design being a fundamental part of it.

I am constantly seeing forward, thinking about my future, in life, in school, work, family, you name it. It is a habit I have been building up for a long time: planning my approach carefully. I know it is not the right way of thinking, and I probably already deviate too much from the topic, but what I am trying to say is that I have not only been looking forward in this class, but my life in general. This last year has been life-changing for most of us, there is no denying it, and the last few months have opened my eyes through a few experiences. I am mindfully in constant change, and I have been improving so many aspects of my life little by little that I am constantly distracted. I hate this, because this class offers me so much (readings, important guest speakers, etc.) and I feel useless at times when I cannot digest this amount of content.

It is not by any means your fault, Mr. Bauer, I am just too slow on processing input. That is another thing I must improve, because if I was up to the challenge, I would love to be as quick-witted as some of my classmates Continue reading "First Partial Reflection"

--Originally published at Coder Bebop

Up until 2010, what we have come to know as the “Cloud” was not the standardized practice that we know of today. An enterprise wanting to keep their data digital and safe had to invest up to US$800 million to implement these types of infrastructures (servers, virtual machines, and other hardware/software). This is what Amazon Web Service, or AWS, does best; it is a term known as IaaS, or Infrastructure as a Service, and it can help reduce these overgrown budgets down to US$2 million by providing it to businesses whose main concern is not maintaining a Cloud. Today, the National Institute of Standards or NIST has set rules and best practices to keep a safe infrastructure across the USA and probably the world.

Some of the characteristics of AWS include:

1. On-demand self-service – Procuring a virtual private cloud takes seconds.
2. Broad network access – HTTPS endpoints and cloud service access from almost anywhere across the globe (using the Internet).
3. Resource pooling – As a necessary standard for all public cloud providers, resources are accurately distributed around the numerous Availability Zones (AZ).
4. Rapid elasticity – The bigger an application grows, the more power and services it may need, something which AWS is perfectly capable of providing with EC2 (Elastic Cloud Computing).
5. Measured Services – You are only charged for what you use, and it is all present and accounted for by the bit and by the second.

--Originally published at Coder Bebop

HOLA MUNDO

1. Descargar SDK Emscripten haciendo uso de este link: https://emscripten.org/docs/getting_started/downloads.html
2. Crear archivo “hello.c” con el siguiente código:

#include <stdio.h>

int main(int argc, char ** argv) {

    printf(“Hola mundo\n”);

}

3. En el mismo directorio que “hello.c”, correr en línea de comando: emcc hello.c -s WASM=1 -o hello.html.
4. Abrir “hello.html” en el navegador de su preferencia.

FUNCIÓN PERSONALIZADA

1. Crear archivo “hello2.c” en un nuevo directorio y pegar este código:

#include <stdio.h>

#include <emscripten/emscripten.h>

int main(int argc, char ** argv) {

    printf(“Hello World\n”);

}

#ifdef __cplusplus

extern “C” {

#endif

EMSCRIPTEN_KEEPALIVE void myFunction(int argc, char ** argv) {

    printf(“MyFunction Called\n”);

}

#ifdef __cplusplus

}

#endif

2. Agregar archivo “html_template/shell_minimal.html” al directorio.
3. Correr en línea de comando: emcc -o hello3.html hello3.c -O3 -s WASM=1 –shell-file html_template/shell_minimal.html -s NO_EXIT_RUNTIME=1  -s “EXTRA_EXPORTED_RUNTIME_METHODS=[‘ccall’]”
4. Abrir “hello2.html” y agregar: 

<button class=”mybutton”>Run myFunction</button>

5. Al final del elemento <script>, agregar el siguiente código:

document.querySelector(‘.mybutton’)

    .addEventListener(‘click’, function() {

        alert(‘check console’);

        var result = Module.ccall(

            ‘myFunction’,    // name of C function

            null,    // return type

            null,    // argument types

            null    // arguments

        );    });

--Originally published at Coder Bebop

• Defining Software Quality

We all have goals in life, in our work, with our family or friends. So it is no surprise that the goal of software is to satisfy the needs of our client(s) in the swifest, most unnoticeable manner. When you ask: “what is software quality?”, you are in fact making reference to the ultimate step of building software. Does it work? More importantly, does it work in the same way it was agreed it would?

When talking about software quality, the ISO actually has eight characteristics to define it:

1. Maintainability: How easily the people working on the product can understand it and redesign it.
2. Portability: Ability of the product to move from one environment to another.
3. Functionality: Does the product reach the user expectations?
4. Performance: The scalability and speed at which a product can perform.
5. Compatibility: If the product is meant to work on certain environment and/or coexist with another product or device, it shall do so correctly.
6. Usability: Can clients understand and use it correctly?
7. Reliability: How likely is the product bound to fail, and if so, how quickly can it be back and running.
8. Security: The less vulnerable it is to attacks, the better.

• A Focus on Process

There exists many paths, and many of them get to Rome, but a very common methodology for is the Software Development Life Cycle, a systematic way of building software. It has seven phases:

1. Requirement collection and analysis: What is needed, and how can we reach that state?
2. Feasibility study: Can it be done accordingly (both technically and legally)?
3. Design: An outline worked by the team which will be the basis of every move from here on out. Whether it be Continue reading "Software Quality"