Today, I want to note down my thoughts on closures. Closures are important in Rust, because they are extensively used in iterator adapters paramount in development highly performant programs. However, to my point of view this topic is not well-covered in The Book. This may be a reason why it is considered among the most difficult parts of the language. In this post, I will try to shed more light on it, hopefully making it more clear to Rust learners. Note that I am still a novice to the language, and my understanding may not be fully correct.
When you develop your first binary application using new language, the first issue that you face is how to organize your code so that you can easily extend it in the future. There is a good example in The Book on how to organize your code, parse and process command line arguments by yourself. However, in real world you would use a library to parse command line arguments, which most probably would be the clap library in case of Rust. In this article, I describe my template for creating a CLI (command line interface) application.
In my previous articles (“Clearing Output Data in Jupyter Notebooks using Pre-commit Framework” and “Clearing Output Data in Jupyter Notebooks using a Bash Script Hook”), I described how to clear output data in Jupyter notebooks using the pre-commit framework and the git hook script correspondingly. Both these approaches are usable and could be applied for your project repositories. However, recently I have found the third way how to clear Jupyter notebook output cells that seems to me more clear and easier to implement. In this article, I describe my last findings.
In my previous article, I described why you may need to clear output data in your Jupyter notebooks. As at the time I participated in a pre-sail project for AI Superior, we required a quick solution to achieve this goal. That is why I used Python-based pre-commit framework to create a pipeline to clear output data. However, this approach requires you to install additional Python package into your system, that might not be always possible. Therefore, at the time I decided that I would implement this approach as a pure Bash script. Recently, I have found some spare time and decided to dig deeper into this topic. As a result of my explorations, I developed a git pre-commit hook that clears Jupyter output cells and wrote this article describing it. If you are an adept of ‘show me the code’ and do not want to read the article, you can find the final script here.
In my previous articles (Configuring Python Workspace and Configuring Python Workspace: Poetry), I have described how I use pyenv to create several virtual environments. With the lapse of time, the tools that you install in these environments become outdated and you need a tool to update them. I develop a pyenv plugin that updates all packages in all or particular pyenv environments and in this post I describe how to use it.
De facto, git is a standard version control system now. Not surprisingly that I use it for my projects. Working on a project, I often face with a situation when I have made a number of changes, and I need to describe them in a commit message. Of course, I try following the line when every change results in a new commit, however, on practice, sometime I face with the situation when I need to describe a number of changes in one commit message. If there are a number of changes (or peculiarities), mentioning all of them could be a challenge. Of course, you can open an additional terminal and do diffing, however, it would be great if this information is included in the commit message.
Hugo 0.56.0 introduced one notable feature called “Hugo Modules”. Hugo Modules allow you to add more flexibility to your Hugo project organization. Using this feature, you can import different modules that will implement one or more Hugo component types. For instance, you can use one module that provides layout for your website, and another one to add more shortcodes, etc. Moreover, this feature enables you to mount your own directories or files that are not necessary tracked by Hugo.
For my webpage, I use a modified “Academic” theme that has been recently renamed to Wowchemy. As a part of the rebranding, the author migrated it to use Hugo Modules. I have devoted some time to understand how Hugo Modules work and how to migrate my website to use this feature. This blog post is mostly a memo for myself, however, it may be useful for others as well.
Recently, I have updated my operating system, and as a part of this process I have installed the latest poetry version (a tool for Python dependency management). When I have started a new project using my typical routine, I have discovered that poetry cannot install development dependencies exiting with a weird SolverProblemError error.
Recently, I have participated in a project at AI Superior aimed at the analysis of a dataset with sensitive data. So as the data have to remain private, initially we shared the dataset through a secure channel and took measures to prevent its accidental distribution (we put the dataset in a separate directory and configured git to ignore this folder and other directories containing intermediate processing results). However, working on this project I have noticed that Jupyter notebook, that is a kind of standard tool used for data analysis, may be a source of sensitive data leakage.
In the series of articles on my time/task management approach, one article is dedicated to the tool set (VSCode + OrgMode) I use to track my tasks and performance. Since then, a number of people has asked me to share the templates of the week, month and year files what I did after the first request. However, recently I have discovered an approach that allows me to speed up the creation of the year, month and week files. In this article, I share the details of this improvement.