En este sencillo video podrás ver como ha ido evolucionando Ferrari a lo largo de la historia.
There’s a saying that states “you will learn more from your failures than successes” and I do agree on that. But you can go further on that and try to learn as well from other’s failures.
So it’s always valuable and interesting to see how others did and what went wrong to learn from them and from their failures.
Today I found a rare though interesting project called Killed by Google that shows you all the projects already killed (or about to be killed) from Google.
You’ll found interesting that a very successful company such us Google has already killed 144 projects and it’s about to kill another 5 more, Google + between them.
Have to confess that I didn’t know anything about some of them, and got surprised about others.
Here you’ll find them and you can make you’re own research.
Hoy, 12 de marzo de 2019, Internet cumple 30 años. Nació el 12 de marzo de 1989. Han pasado ya 30 años desde que el ingeniero británico Tim Berners-Lee propuso un “vago pero ilusionante espacio, libre y abierto, para que toda la humanidad pudiera compartir ideas y conocimientos”.
Aquí os dejo una imagen que me ha gustado mucho, las 50 webs más influyentes de Internet de los últimos 30 años en España. Con algunas estoy más de acuerdo que con otras, pero muchas de ellas me han hecho recordar con nostalgia tiempos pasados, Barrapunto, Softonic, Altavista, Rincón del vago, son sólo algunas de las que me han hecho recordar.
Today I was reading an interesting article about the 9 Kubernetes Security Best Practices everyone must follow.
In that article they basically enumerate and briefly describe how to follow and accomplish those 9 security recommendations. I’ve extracted them here for you to simply go quickly through them.
1. Upgrade to the Latest Version
In the article they don’t specify if the order of this list is important, but for me the most obvious things must come first.
Keeping your cluster upgraded is always the first thing you should do.
2. Enable Role-Based Access Control (RBAC)
RBAC is the new access control they introduced in Kubernetes 1.6 and basically allows you to control who can access your API in a more secure and improved way.
Specially after discovering the security issue CVE-2018-1002105
3. Use Namespaces to Establish Security Boundaries
I’ve been using namespaces from my first cluster setup and they’re great to isolate components and even the logic of your different cluster parts.
DevOps guys immediately understand the namespaces and when working with the cluster the can easily focus on the part they want to work with avoiding making mistakes in other namespaces. Deleting a pod for another system part could be a good example of this 😉
Related to security it’s also really handy to be able to apply different security controls based on namespaces.
4. Separate Sensitive Workloads
Sensitive workloads should be ran in dedicated machines, this reduces the risk of an non authorised app accessing that sensitive info.
By using namespaces you can achieve this.
5. Secure Cloud Metadata Access
I thing this recommendation is more focused for GKE environments and any other cloud services, a recent Shopify bug bounty disclosure detailed how a user was able to escalate privileges by confusing a microservice into leaking information from the cloud provider’s metadata service.
They’re still working in a more robust & permanent solution for this.
6. Create and Define Cluster Network Policies
This is something that is purely related with cloud services that allows you to configure network policies for controlling network access into and out of your containerized applications.
However you can always apply same concept in your private cluster, by running them in isolated networks and stablish direct communications only when needed.
7. Run a Cluster-wide Pod Security Policy
A Pod Security Policy sets defaults for how workloads are allowed to run in your cluster. Consider defining a policy and enabling the Pod Security Policy admission controller — instructions vary depending on your cloud provider or deployment model. As a start, you could require that deployments drop the NET_RAW capability to defeat certain classes of network spoofing attacks.
8. Harden Node Security
They put this point at 8th position in their list. In my humble opinion should come at 1st position in this list.
At the end a cluster is a set of nodes orchestrated by Kubernetes, those nodes are just machines and they live in a network environment so hardening your machines should be the most important and the very first thing you must do.
- Uninstall non required software that is included in the operating system
- Keep all the software up to date
- Disable root SSH connections
- Reduce as much as possible sudo users
- Install firewall
- Only expose required ports, close the rest
- Install tools to track unauthorised login attempts and block them immediately
- logging, logging, logging ! You need to know what’s happening in your machines, logs all the actions to discover misconfiguration issues, security problems, etc.
Those are some personal recommendations I make for you, of course, depending on your needs, you need to apply more.
Please read this guide to understand server hardening.
9. Turn on Audit Logging
logging, logging, logging !
I told you 😉 the more you know about what’s happening under the hood, the more control you’ll have on your system.
Enable audit log to discover unauthorised API calls or any kind of authorization failures.
Thanks to Sentry.io I could realise that despite being an old browser Chrome49 is still used by the users using my projects. So I decided to fix those issues.
In summary despite being a lot of articles and people talking about vue.js, is still in adoption phase, Angular and React are clearly dominating the market and jQuery is still also active, probably due legacy code and because is the first thing you start learning if you start in this world.
Dec 2018 Job Board Postings Per Framework
Happy coding in this new 2019!
“Another one bites the dust“, this time Quora.com has been hacked and information for all the users exposed.
As you can read in their security update blogpost this was the information exposed:
- Account information, e.g. name, email address, encrypted (hashed) password, data imported from linked networks when authorized by users
- Public content and actions, e.g. questions, answers, comments, upvotes
- Non-public content and actions, e.g. answer requests, downvotes, direct messages (note that a low percentage of Quora users have sent or received such messages)
Last Friday the Quora.com team discovered that some user data was compromised by a third party who gained unauthorized access to one of their systems.
They’re conducting an investigation and while that investigation is still ongoing, in their own words “we have already taken steps to contain the incident, and our efforts to protect our users and prevent this type of incident from happening in the future are our top priority as a company”.
What’s Quora doing
Meanwhile they’re doing the investigation and working together with some external security and digital forensics firms they’re taking some steps to improve security and minimise the impact, such as:
- Notify users whose data has been compromised.
- Logging out all Quora users who may have been affected, and, if they use a password as their authentication method, we are invalidating their passwords.
They “believe” they’ve identified the root cause and taken steps to address the issue, although the investigation is ongoing and they’ll continue to make security improvements.
We as software engineers, sysadmins, DevOps, or whatever cool name appears in the near future, should take seriously the security of our applications and the privacy of our users.
This won’t be the last security issue we’ll see in this cloud world.
Today I was doing some personal research for my new role in my company team and while I was looking for some topic about productivity and team management I found quite interesting this comment from Slashdot.org.
I decided to quote it directly to not cause confusion so you can directly read it as it is and get your own conclusion.
For me, it’s clear, it doesn’t make you a worse programmer, you just simply need some time to perfectly fit in the new team, you’ll learn new tools, concepts, languages and you’ll adapt to the way of working, after that your experience will help to improve those aspects. However take in consideration the big amount of time and energy you’ll need to keep up in the new team, in the new company. Because looking for a new job / starting in a new job, is a job itself.
Slashdot reader theodp shares some thoughts from Virginia-based cloud architect Forrest Brazeal, who believes that switching jobs or teams makes you — at least temporarily — a worse programmer:“When you do take a new job,” Brazeal writes, “everybody else will know things you don’t know. You’ll expend an enormous amount of time and mental energy just trying to keep up. This is usually called ‘the learning curve’. The unstated assumption is that you must add new knowledge on top of the existing base of knowledge you brought from your previous job in order to succeed in the new environment.
“But that’s not really what’s happening. After all, some of your new coworkers have never worked at any other company. You have way more experience than they do. Why are they more effective than you right now? Because, for the moment, your old experience doesn’t matter. You don’t just need to add knowledge; you need to replace a wide body of experiences that became irrelevant when you turned in your notice at the old job. To put it another way: if you visualize your entire career arc as one giant learning curve, the places where you change jobs are marked by switchbacks.”
He concludes, “I’m not saying you shouldn’t switch jobs. Just remember that you can’t expect to be the same person in the new cubicle. Your value is only partly based on your own knowledge and ingenuity. It’s also wrapped up in the connections you’ve made inside your team: your ability to help others, their shared understanding of your strengths and weaknesses, and who knows what else. You will have to figure out new paths of communication in the new organization, build new backlogs of code references pertaining to your new projects, and find new mentors who can help you continue to grow. You will have to become a different programmer.
“There is no guarantee you will be a better one.”
This seems counter-intuitive to me — but what do Slashdot’s readers think? Does switching jobs make you a worse programmer?
Confirmado, Microsoft adquirió GitHub, y lo hizo por 7.500 millones de dólares, una de las operaciones económicas más costosas de su historia.
Según ha puntualizado Microsfot: “GitHub mantendrá su marca y operará de forma independiente.”
La operación es la tercera adquisición más importante en cuanto al montante económica de la misma. Microsoft pagó 26.200 millones de dólares por LinkedIn en diciembre de 2016 y 8.500 millones de dólares por SKype en mayo de 2011.
Al igual que hizo con LlinkedIn, Microsoft no influirá en la forma de operar de GitHub, por lo que inicialmente el servicio seguirá funcionando igual y GitHub seguirá operando de forma independiente “proporcionando una plataforma abierta para todo tipo de desarrolladores e industrias”.
Donde parece que habrá cambios es en la parte directiva de GitHub.
Dentro de un tiempo veremos como nos afecta esto al resto de desarrolladores que utilizamos GitHub.
In the previous article we talked about how to create, publish and use your private NPM packages.
This time is the moment to talk about how to simultaneously work on an application and a dependency used by that application.
No pierden la esperanza, pierden la cobertura del móvil. Eso es lo primero que les pasa a aquellos que tienen la mala suerte de perderse en el mar, en la alta montaña o que se ven envueltos en una catástrofe natural. Y justo eso, la telefonía, es precisamente lo que más necesitan, porque los mensajes de texto les podrían salvar la vida. Pero estas situaciones de tremenda vulnerabilidad están a punto de desaparecer. Y todo, gracias a un invento de un español.
After a long time working with different package systems I decided to migrate all my packages and dependencies to NPM. And the result couldn’t have been better.
When NPM reached the 5.x version they included a lot of things that improved the performance, speed and security of the packages.
There’re two commands that I specially like a lot.
npm outdated npm audit
Many of you have asked me for a quick Dart syntax cheat sheet.
Here you can find 4 different illustrations to help you out when working with Dart.
Recently I started to migrate all my code from ES5+jQuery to ES6 for different projects. I discovered a lot of cool things. Of course, I also faced some issues and I thought would be great to share all the stuff I’m learning and fixing with the rest of the people planning to migrate to ES6 as well.
I’m gonna write a serie of small articles covering all the new ES6 features and how to migrate your code from previous ECMAScript versions or from jQuery code.
I’m going to show you how easy is to deploy Fluent Bit into your Kubernetes cluster. I’ll configure Fluent Bit to work together with Loggly, an external logging tool to manage all your cluster logs.
But first, some quick concepts about the tools we’re going to use.
El otro día andaba navegando por internet… buscaba un operador de telefonía móvil que ofrezca una tarifa de datos barata, porque en realidad últimamente es para lo único que utilizo mi teléfono, seguramente como nos pasa a todos.
De pronto hice una de esas maravillosas búsquedas en Google que me tanto me encantan y esto fue lo que me encontré.