472 subscribers
6 photos
1 video
2 files
550 links
python, go, code quality, security, magic

Website and RSS:
https://itgram.orsinium.dev

Source:
https://github.com/orsinium/itgram

Author:
@orsinium
https://orsinium.dev/
Download Telegram
πŸƒ maths is a math package for Go, with generics. And the readme deserves a special mention. It is beautiful, informative, well structured, and actively uses mathjax for markdown recently introduced on Github.
ziglings, rustlings, and gopherlings are tutorials for learning Zig, Rust and Go respectively by fixing bugs in tiny broken programs. It's great when you need some practice in a new language but don't have an idea or time for a proper project.
ifuckinghatejira.com ❀️
microservices.io describes different patterns and tricks for building microservice architecture. Because everyone nowadays wants some microservices. Well, it's a great way to decouple things when you have a big project and lot of people, but they introduce a lot of tech challenges and are hard to do correctly. I hope this guide will help you a bit if you have to go that way.
Testing in 2021 is a collection of good thoughts from one guy on testing. Very good thoughts. Without extremes and fanaticism, which is rare nowadays, especially in mainstream articles. Everyone says something "the only working testing is TDD" or "pyramid of testing is complete garbage". Stop making a religion from it. We need to get better at testing than we are now but think with your head, don't make dogmas. Oh, and the article also deserves a bonus point for having an audio version.
Today I want to tell you a bit about Livebook. It's like Jupyter Lab but for Elixir. And it is a bit of an understatement because Livebook is so much better. There are many reasons for it: Elixir is concurrent, they built the tool based on the negative and positive experiences of Jupyter, they already had a great Phoenix web framework to build it, and the team behind it are the go authors themselves. They fixed a lot of Jupyter issues, including out-of-order cell execution, custom widgets, and nice markdown rendering.

Livebook is a part of a bigger initiative of Elixir authors to bring Elixir into the world of ML, and they are doing great. There is nx for tenors, explorer for dataframe, axon for neural networks, and many other promising projects. And I think functional programming fits ML and datascience just great, much better than the messy world of OOP, mutations, and global states.
How we got to LiveView is a long read from Chris McCord, the creator of the Phoenix web framework for Elixir. It covers his experience with Ruby on Rails, what issues it had, how he fixed it in Phoenix, and then covers how LiveView is a continuation of these ideas.

Yes, I'm telling a lot here about Elixir, and I know that nobody cares. Still, I hope one day when you start a highly-concurrent and soft-realtime project with enough freedom to choose the tech stack, you may remember all my stories about Elixir, and give it a try. It's a relatively young language, but it is built on a very solid foundation and many great ideas.
If you want to learn Rust, the official website provides you 3 options: book, course, and examples. I started with the examples, and they are very bad. The first example is a classic Hello World but instead of just showing how to print text and move on, the resource goes into a lengthy explanation of what traits you need to inherit in your custom classes to make them printable. Without even explaining what is trait. And the same trend goes through all examples: dive into some details and use a bunch of terms without explaining them or even linking. I'm still not sure who's the target audience.

So, if you want to learn Rust, read the book, the book is pretty good.

The language itself is pretty strange too. Most modern languages realized that code is for humans, and the central goal of syntax and most of the high-level features should be readability and the principle of least surprise. And then there is Rust which consists of some obscure symbols, implicit behaviors, and strange decisions.

Rust requires each line of code to end with a semicolon. This is a strange decision for a modern language on its own. Most modern languages realized that you can tokenize code without it, and explicit semicolons are just visual noise.

But the best example of strange decisions is how to return a result from a function in Rust. In Python and Go, you always have to write an explicit return statement. In Elixir, Haskell, and Ruby function implicitly return the last expression. So, if you don't want to return anything, you make sure that the last expression is nil, which is, again, explicit.

Now, rust solves it in a very unique way. Instead of having an explicit return statement or nil at the end, it decides whether to return the expression or not based on if there is a semicolon at the end. If the line doesn't end with a semicolon, the result is returned. If it has a semicolon, a void is returned. Now, imagine you're reading some Rust code without going through the whole Rust book. What are the odds you'll figure it out? Some people will point out that the compiler will fail with a detailed error message if the semicolon and type annotation don’t match, but I’m talking about the experience of reading the code, not writing it.

At some point, people stopped using concise but hard-to-read languages, like Perl or APL. Well, there are still there but definitely not mainstream. Also, languages started to get rid of visual noise. You'll hardly find semicolons in most of them. I can't recall modern languages (except for PHP) that require a special symbol each time you need a variable. Many strictly typed languages, like Go, have some basic type inference. And here we are again, Rust gets into the mainstream with compiler-centric syntax.
πŸŽ₯ Seven Ineffective Coding Habits of Many Programmers by Kevlin Henney (text summary). I'm surprised I haven't published it before. A great conference talk about how humans read code, and so how to make your code a bit easier to read and understand.

This talk is what inspired me to create flake8-length that keeps line length short without compromising readability of messages, and flake8-comments that tries to catch useless comments.
🐍 I've made svg.orsinium.dev. It's an online playground for svg.py, and it has quite a potential. You can generate images in your browser. It's like processing but it's Python! Unfortunately, I there is no autocomplete in it (yet?), and a nice autocomplete is the whole point of svg.py. Still, quite useful for debugging your art.

The svg.py turned out to be more useful for me than I expected, TBH. I've created it to draw cards for my board game, and I still didn't get to it, shame on me. But despite of this, I already have used svg.py in punchline for producing punch stripes for my music box, and in generative-art which has only 4 images so far, but I hope it to grow.
πŸ”§ netlify is quite cool. It's a hosting for static websites with a lot of nice features, like custom domains, automatic integration with Github (provides CI and previews), automatically renewed let's encrypt certificates, configuration-as-code. I use it for all my open-source websites (wps.orsinium.dev, orsinium.dev, svg.orsinium.dev, gweb.orsinium.dev, you got the idea), and I'm quite far from running out of quotas they provide for free accounts.

I avoided for quite a long time all static website hostings because I thought they only can serve whatever HTML you already have in the repo. No, netlify can also build the pages. For each build, it spawns an Ubuntu Docker image with a lot of stuff already installed (like Python and Go) and calls whatever custom command you've provided (which can be a shell script if you have a complex build logic). For example, in svg-playground, the netlify.toml tells to run netlify.sh which installs and runs task. And task executes Taskfile.yaml which does quite a few things, producing at the end all HTML pages and WASM binary. That could be fewer files if you want but I felt like being more verbose there.
Registration for Hacktoberfest 2022 is open. Hacktoberfest is yearly event when you get some swag (T-shirt+stickers, or donation for planting a tree) for submitting 4 PRs to open-source projects during October.

Hacktoberfest 2020 had a lot of spam, so this year the initiative got some improvements, even more than in 2021:
1. Maintainers also will receive swag for reviewing and triaging Hacktoberfest PRs.
2. If 2 of your PRs are marked as spam, you automatically blocked.
3. You have to press 4 different checkboxes that you acknowledge the previous point.
SimpleParsing is a little Python library that "does one job and does it well".

If you, like me, want everything in your Python code to be type annotated (for the sake of autocomplete, semantic syntax highlighting, and safety) you may know that the container that argparse returns (argparse.Namespace) isn't type checked because mypy can't statically know what flags and of what type you registered in ArgumentParser. And if you want to make it type-safe, there is quite a bit of boilerplate: define flags, define type safe container, unpack flags into the container. And if the definition and the container mismtch, well, your code is wrong.

SimpleParsing solves exactly this problem. You define a dataclass class, annotate attribute types, set defaults, add comments to attributes, and then SimpleParsing will turn it into CLI args. Attribute names will form names of the CLI flags, types will be checked, defaults will be respected, and comments will be turned into help messages.

I've seen quite a few alternatives for that task, and all of them work on top of pydantic, click, or attrs. And I really like that SimpleParsing works with what we already have in stdlib, without bringing unnecessary dependencies.

And don't listen to anyone, click sucks. Testing it is quite hard, functions with 20 arguments and 20 decorators on top aren't nice, and passing all that stuff deeper into the code is hard and verbose. Using click will encourage dirty and verbose code and bad practice. Oh, and IMHO the CLI it produces is worse than that of argparse.

#python
Why sprint estimation has broken Agile. The only bad thing about this article is that it's on Medium. The rest is great. I was even going to write my own article on the subject, but someone already did it much better.

We've lost the meaning of story points along the way. Bob Martin (one of the people who signed the famous Agile Manifesto) in his talk on Clean Code covers why they introduced the idea of story points. You're starting a new big project. The business want to do a lot of things but the time is limited and not all of the features are needed for MVC. Would be great to estimate how long each task will take (before we even have the team), so we can better plan and prioritize. So, how to approach it? Uncle Bob suggest to write all features on cards (for example, "implement user registration"), pick one card, and put a number on it. Let's say, 5. Why 5? IDK, just a good number. And then estimate all other tasks compared to this one. Implementing log-in is faster than registration? Put 3 on it. The PoC of news feed is harder? Put 8. That's it.

This is why story points aren't hours. This is why they don't matter for not deadlined project. This is why the article is good.
I've stumbled across the work of Ray Toal, and there is a lot to explore. I wish I had lectures like this in my university. Algorithms, data structures, databases, programming languages, security, networking, and much more.

I especially like Computer Language Semantics. He covers what is syntax, syntax design, and has good introductions to many languages with lots of examples (for example, to Clojure). Quite a good way to get started with a new language when you already know some programming. He also published a book Programming Language Explorations which, I think, is based on these courses. He published a ple GitHub repo for the book with examples of programs on each language he covers (and that's a lot of languages). Also, the book landing page links a few similar resources, like Syntax Across Languages, a big page that compares how the syntax for different things (like function call) looks like in different languages. And he also provides this overview page of different languages, with a short description, application examples, links, and tags.

But there is more cool stuff, I can't reasonably cover it in a single post. For example, this guide on clean code. Or intro to command line. As I said, a lot to uncover. I recommend you to go right to his home page and find yourself what resonates with you:
https://cs.lmu.edu/~ray/
πŸƒ go-recipes is a collection of Go snippets and tools to make different cool little things in Go: draw a dependency graph, prettify test coverage report, parallelize tests, show Go assembly, etc.

#golang
Aging programmer is a short list of random thought by a 40 y.o. engineer on what has changed for him over the years and what stayed the same.
πŸ”§ onefetch is a little tool to show some basic stats about a git repo: authors (and percent of code contributed), commits, lines of code, languages, size. And that's it, really. Not much, but it's quite easy to install and quick to run (Rust at its best), unlike some other alternatives I tried before.

#cli
πŸ”§ d2 is a CLI tool (written on Go) for generating diagrams from a text definition of what is related to what and how. If you know what is PlantUML, MermaidJS, or GraphViz, it's the same, but a bit friendlier. For example:

block1 -> block2: text on arrow
block2 -> block3
block4

If you want more examples, the authors maintain a text-to-diagram.com website that compares D2 to similar tools.

I tried it for a few projects, and that's what I'm going to use from now on for all diagrams. It's easy to install, has a nice syntax, and gives quite a nice output. There is no way to apply a custom style to group of elements (like class in CSS), but other than that it's fine. When you need custom colors or something, you still can do it on per-element basis.

#cli
πŸŽ₯ Make Illegal States Unrepresentable is a beginner-friendly talk about writing good type annotations. The speaker covers what is type safety and illegal states, why it matters, and shows three techniques how to achieve that. Examples are on Scala, but can be translated to Python, Rust, or TypeScript. Not to Go, sorry, no algebraic types and atoms for you.
Go 1.20 has been released! I'm most excited about the addition of profile-guided optimization (PGO). Now you can run on production a copy of your service with the profiler enabled, redirect there a small percent of users, export the collected profile, and recompile the service with -pgo=/path/to/profile. The compiler will use the information from the profile about which lines of code are executed more often and optimize the binary for them. More specifically, Go 1.20 compiler will do more aggressive inline for the hot parts, which adds 2-4% of performance on average. That's not much but it might be much more in the future versions of the compiler.

I always liked the idea of PGO. There were many blog posts about people moving around parts of code (and also many PRs into Go itself doing the same for stdlib) to get a better performance for the most often executed path. And it always bothered me as one of the things that the compiler should do instead of humans. Well, now it can!

More in the Go documentation: Profile-guided optimization.

#golang