The Zen of Python

In my opinion this must be the Zen of any programming language and of every developer.

The Zen of Python

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

 

Cambios importantes a partir de Chrome 80 en la gestión de Cookies. Seguridad y Privacidad.

Acabo de leer un artículo muy interesante que recomiendo encarecidamente a cualquier desarrollador de apps. Especialmente aplicaciones web.

Las cookies forman parte de los sitios web y de las aplicaciones web. Históricamente se diseñaron como un mecanismo simple de comunicación entre el servidor y el cliente, pero en la actualidad este mecanismo ha sido explotado y utilizado fundamentalmente para publicidad.

A partir de la version 80 de Chrome, por defecto, este navegador solo permitirá cookies del sitio que se visita, conocidas como “first party cookies”. Esto implica, que por defecto, todas las cookies que no provengan del sitio que se visita, “third party cookies”, serán bloqueadas.

Nuestra seguridad se verá incrementada porque será más difícil explotar ataques CSRF, pero al mismo tiempo la privacidad, al no utilizar cookies de terceros será imposible registrar los sitios web que vamos visitando.

En este artículo (en inglés) podréis leer perfectamente bien explicado todo el cambio e incluso encontrar herramientas para preparar nuestros sitios web y aplicaciones antes de Chrome 80.

https://textslashplain.com/2019/09/30/same-site-cookies-by-default/

docker on MacOS mkmf.rb can’t find header files for ruby

After the latest upgrade on MacOS when I tried to use docker on my mac to build my new images I got this error:

mkmf.rb can't find header files for ruby at /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/include/ruby.h

After trying multiple and different solutions the only thing that worked for me to get this fixed was removing the previously installed developer tools for command line and install them again by following these steps:

sudo rm -rf /Library/Developer/CommandLineTools 

xcode-select --install 

sudo xcodebuild -license accept 

open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

After running those commands and, of course, wait a bit to get everything downloaded and installed, docker commands are now working again.

Starting with Docker

Over the past years, Docker has become an essential technology used in software development. Developers, DevOps, Companies has adopted this new technology quite fast.

Nothing to be surprised about, its containerization concept has made it easy to set up, share and deploy software projects.

In this article we’ll what Docker is, what a container is and how to start playing with it.

Continue reading “Starting with Docker”

BitBucket Pipeline configuration for PHP, MongoDB and Symfony

Recently I’ve been playing around with BitBucket and their Pipelines. Just to let you know BitBucket Pipelines is an integrated CI/CD service built into Bitbucket. It basically means that on every commit you make your tests will be ran and your code will be deployed.

They say in their official website that it has a really basic and simple configuration and as far as I could experiment, it really is.

Continue reading “BitBucket Pipeline configuration for PHP, MongoDB and Symfony”

Projects killed by Google

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.

https://killedbygoogle.com

30 aniversario de Internet

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.

50-webs-mas-influyentes-de-internet-españa-1

30 Aniversario de Internet: las 51 webs que han hecho de la red lo que hoy es

9 Kubernetes Security Best Practices

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.

JavaScript things to learn for 2019

I was reading for new topics to learn in the JavaScript ecosystem or just things to keep in mind if you consider to start a new project.

I found this article Top JavaScript Frameworks and Topics to Learn in 2019 from Eric Elliot quite interesting.

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

Dec 2018 Job Board Postings Per Framework

Happy coding in this new 2019!

Quora.com hacked

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)

What happened

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.

Conclusion

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.

Does Switching Jobs Make You a Worse Programmer?

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?

GitHub + Microsoft

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.

 

Un español inventa un sistema para mandar mensajes de texto sin cobertura

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.

Continue reading “Un español inventa un sistema para mandar mensajes de texto sin cobertura”

Create a website or blog at WordPress.com

Up ↑