se7entyse7en

Hi everyone, I’m Marvin

Years ago, I faced significant challenges transitioning to remote work. I had to apply to over 30 job positions, using a Trello board to keep everything organized—it was overwhelming!

After much struggle, I finally landed a remote job.

I started as a Mid Software Engineer, then became a Head of Engineering in a startup, and most recently as Director of Engineering at the Linux Foundation and a Software Architect consultant.

This experience was so impactful that when I started on my solopreneur path, I knew I wanted to help others overcome similar hurdles. That's why I launched NextCommit (https://nextcommit.careers/). The platform supports tech candidates throughout their journey to find remote jobs, from analyzing CVs to achieving their ultimate goal of securing a position.

I’m constantly looking to add new features, such as job application tracking, automatic job matching, and CV and cover letter optimization for specific postings.

I invite you to sign up for a free account to explore and filter the most recent job postings and receive a summary analysis of your CV.

I’d love to hear your thoughts on this tool! Feel free to DM me or connect on LinkedIn, X, or email—any feedback is highly appreciated!

Good luck and happy job hunt!

If you wanna know more about me, I’ve shared more about my journey in my newsletter here if you’re curious: https://se7entyse7en.beehiiv.com/p/jump-ball

## With who you'll be working with

At Athenian Engineering we are currently a team of 8. Everyone is a world-class Senior Engineer, each with a diverse area of expertise ranging from Language Analysis and System Architecture to Machine Learning on Code and modern APIs, and to modern Web Applications.

Athenian | Senior Data Engineer | Full Time | Remote (between UTC-3 and UTC+3)

Hi! I'm the Head of Engineering at Athenian.

## About the company

At Athenian, our mission is to help engineering leaders build better software, faster by leveraging metrics and insights. We provide a data-enabled engineering platform that offers end-to-end visibility into the software delivery lifecycle.

## About the role

As a Senior Data Engineer at Athenian you can expect to have a big impact in shaping the product.

You are expected to contribute to the Data Retrieval part of the backend. It involves fetching, updating, and archiving all the data related to different data sources in real-time (Github, JIRA, CI/CD services, etc.). It is structured as a graph with nodes performing different tasks, implemented either as workers on Kubernetes or as Google Cloud Functions, exchanging messages through edges, implemented with Google Pub/Sub.

## Culture

- We are inclusive and welcome diversity, we encourage applicants from all backgrounds to apply.

- Athenian is a fully remote company. At the moment, we are 20+ people from several different countries working closely together in a fully-distributed way.

- We put a lot of value into collaboration and feedback, no matter if it comes from our CEO, a customer, Product or Engineering because we know that the best ideas can come from anywhere.

- We believe in transparency and collaboration, which reflects how we operate internally and externally.

- We are humane and care about each other's growth and wellbeing.

- Flexible hours, set your own schedule that fits you.

Link to apply: - https://careers.athenian.co/jobs/1717378-senior-software-eng...

`pydockenv` has been completely ported to `golang`. This makes the installation much easier since it doesn't have any Python dependency, hence no conflicts during installation outside of a virtual environment.

Currently it has to be installed with `pip`, so Python is required to install it. Once different ways for installing it (package mangers, package in GH, etc.) are provided, Python itself won't be a dependency (you'll be able to run Python environments without having Python installed).

Having `pydockenv` written in non-Python makes also the development itself easier since no meta usage of `pydockenv` is needed.

That could be an idea, so in practice, you move the responsibility to the editor which I think is actually the correct thing to do. Regarding VSCode specifically I don't know, as I don't use it.

To share your environment with someone else you can run `pydockenv save` (see here: https://github.com/se7entyse7en/pydockenv/blob/master/pydock...). I'm sorry that any example is present in the README so far.

Under the hood, a new docker image is saved from the container corresponding to the currently active environment. A `*.tar.gz` file is created with the image the can be now loaded using `pydockenv load`.

Alternatively, you could push that image to Dockerhub for example and pull it from somewhere else. The problem is that currently there's no mechanism to make it recognize to `pydockenv`, but I'm also planning to add the possibility to create an environment from a user-defined image.

Using `pydockenv save` will ensure that the environment you'll share will be exactly the same. An alternative that I'm also planning to implement is to use a `toml` file that will simply create a new environment from it. Obviously, in your running container, there could be something not captured in the original `toml` file if you, for example, installed something manually inside the container.

But again, it's really in early stage, so all these feedbacks are really welcome!

That's a cool use case that I didn't think about! I'm really glad that this project that I started only a couple of weeks ago is actually useful.

When I have some time I could try adding a `How does it work` section.

Under the hood the creation of an environment corresponds to the creation of a docker container (that's how it relates to docker). The docker container is built starting from a the official python docker images as you can see here https://github.com/se7entyse7en/pydockenv/blob/master/pydock....

The activation of the environment corresponds to the start of the container. Hence inside the container, you don't have (don't need) to have any virtual env as the isolation is already provided by the container itself.

Every time you install a dependency, this is actually installed inside the container.

First of all, thanks for your interest!

> VSCode has no idea about your env because it's effectively non-local.

This is an issue that I'm aware of, and I actually didn't think about a possible solution yet. Currently, it is in a VERY early stage, but I wanted to share it to get feedback from the community and how much interest the project could raise.

The only things that I thought were adding support for example for aliasing of some commands such as running `flake8` will actually call `flake8` inside the container. But it's still very fuzzy in my head.

Color quantization using k-means compared to a random selection approach. The color spaces considered are RGB and Lab.

I would like to have some feedback either positive or negative about this library. Some ideas about future improvements are:

- generating more specific fields by using `faker`,

- integration with orm layers (`mongoengine` for example) to guess the structure of the data instead of defining it.