Great for steganography! We can finally put our passwords on post-its again!
58 karma · joined March 25, 2020
But that's the techy point of view. Most non-techies will probably prefer feel over functionality. I think most people do. If something is instant, it feels too good to be true. If something takes ages, you'll get bored or frustrated. While things that take a proportional amount of time feel satisfying.
It would be great if such a mechanism was part of the http standard, so you could easily connect compliant tools.
Rubber ducking can be a highly productive measure when your mentally clouded and can take many forms.
Finding and patching all possible locations which could interrupt your threads doing file operations is probably a foolish effort.
So, raising the limit, or load balancing (depending on the type of application) is probably the best solution.
To automate this process, we have some ansible playbook to automate most of it: give it a query and you'll get a bunch of files with the results.
While useful, the setup and cleanup can get tidious. So, I whipped up a little shell script that creates a temporary directory and symlink it to a location somewhere in $XDG_STATE_HOME. I created a few subcommands to create the directory structure, add a query, run the query, aggregate results and destroy the state. This keeps things simple for me. Even if I forget to cleanup after myself, a reboot will make sure nothing is left behind. The symlink trick to xdg state home helps me a lot to track my state, while I work on a certain problem. It allows me to easily handle multiple request at the same time, when necessary.
The two vertical screens are configured a little different. Vertical screens are terrible for screensharing. For that reason I virtually split one of them in 2 parts (using xrandr). This gives me two square screens that are ideal for screen sharing.
So, virtually, I have 4 screens in 3 different sizes and have no issue assigning stuff to them. The vertical screen is always used for Emacs and different chat apps used for work (have a workspace with all chats stacked vertically, so I can keep tabs easily). One of the square screens is used for browsing, while the other is used for screen sharing (or general browsing/terminal when my screen is not shared). The laptop screen is often used as a scratch pad (short term stuff).
I know it might be a bit overblown, but it works well for me. I really like the fact that I can run multiple things and monitor their output, without interrupting my workflow.
Can imagine that implementing bounds checking can be costly, when done in software. Wonder if there are any hardware improvements that could reduce risk in this area.
This year I added Miller [0] to my list; a tool to process tabular data, similar to sed, awk, etc. It handles csv, tav, json lines, etc. in a consistent way. I like the delimited key-value pairs format, which allows me to write simple oneliners in bash to collect some data (e.g. "ip=x.x.x.x,endpoint=/api/x") and use Miller to crunch the results. Not sure it saved me 100h, but it was one of the biggest time savers this year!
In my experience similar arguments hold for software developers. Especially caring can be a big factor; i.e. the "move fast, break things" mentality.
I've been back and forth between typed and untyped languages (somewhere in the range of haskell and tcl) and personally prefer less typing when hacking things together and more typing for high quality software. I'm currently working an infra job where we use both ansible and terraform. They're not direct competitors, but I tend to prefer terraform over ansible when possible, as terraform gives me more "static" guarantees, which translates to more confidence when we apply our code.
Like you said, it's the small things. The thing that annoys me most are probably variable scoping and precedence rules. Scoping is practically non-existent; a variable declared in one role can be freely accessed in another, which can easily lead to clashes when your variable names are too generic.
Have to say that lisps are very nice too, in my opinion. Started learning a little common lisp recently and was surprised by its elegance. I think lisps can be very maintainable, when care is taken. It's easy to write unreadable programs, but this also holds for tcl. With great power comes great responsibility.
I think it depends on how often you "win" the lottery. If a lottery event happens once or twice a year and it's fairly hard to resolve, we classify them as land mines (or sea mines for the more maritime oriented people among us). These issues get a lower priority, but we'll try to work through them to avoid emergencies or lower their impact. So, maybe not optimizing, but increase resilience against lottery events.
Glancing over the examples of this post, I think I like rx better, due to its lispy syntax.
Does someone know the origin of this trend? And why the two countries don't show the same trend?
Used gdb scripts in the past to make debug sessions repeatable. Stuck beyond the point your interested in? No problem, just restart the session with your gdb script and your right back on track! You can also add custom functions to output your state in a more meaningful way or to mock some state. In longer debugging sessions, a good debugger can be a life safer!
Still, for shorter sessions, reading logs and adding occasional prints are hard to beat.
I generally like deeper debug sessions, preferably without too much pressure. Getting deep understanding for a problem and figuring out a solution were the most valuable learning experiences in my career. The satisfaction you get from finding a solution to a hard problem, makes them more memorable. Even if the lessons learned afterward are not spectacular, then at least you got a chance to sharpen the tools in your belt to pin point problems as they occur!
Looks liken the author had a good introduction from his friend. The pages he found in a short time took me years to collect!
Although it only scratches the surfaces of what emacs is capable of, it nicely illustrates how emacs fills day-to-day gaps that otherwise would require learning completely new environments.
My main motivator was similar to yours. Most functionality I used came from plugins, but the language used to write plugins or other modifications felt crippled. When I came across orgmode, during my years on the university, I tried it in vim, through some Plugin. I liked how the format allowed me to dump most of my brain in plain text, but it still felt unnatural to edit it with vim.
During a history course on computer science, I learned more about lisp and its integration in emacs. At that point I decided to try it out. I wanted the full experience, to be able to form an honest opinion. So, I forced myself to do an entire course using emacs instead vim. No evil, just plain emacs. During this time, I fell in love and never looked back.
I still like vim, I just don't find any use for it anymore, except quick editing on servers. Knowing vi key bindings is useful, as vi is almost always present. However, I think that known/understanding emacs key bindings is underrated. Understanding the logic of emacs key bindings will not only makes you more proficient at handling emacs, it also makes moving around most shells more efficient. I know you can configure shells (or more specific: readline) to use vi key bindings, but the default is emacs!
My advise in learning emacs would be: dedicate some time on using it for something real. I'd say, don't get too tempted by the vimify plugins, as they will hide some of the logic of how emacs works. This might slow down or dumb down the learning process. But I'm not discouraging the use of vim plugins all together, just make sure you understand the core product, before modifying it beyond recognition.