Github | Projects | Linkedin
THE Solution to the REPL snippets (using Emacs ofc)
Miro Bezjak wrote an interesting post called What to Do With Evaluated REPL Expressions?. The problem he describes is actually a bit different from the one I thought of when saw the title: it’s not about re-using evaluation results in the REPL (which is not really possible without re-evaluation or using weird numbering acces – as far as I know). No, it’s really about the expressions that should not go into the the released code, but the one the developer uses during the development – small chunks of the code with ops-tasks, small checks, calls to the external systems etc. Miro suggests to create the out-of-classpath user directory for every project developer, and create a common place for all those code snippets called everything.clj or something like that. This file should be committed to the repo (thus shared and easily referenced between the developers), but not become the part of “official code” (hopefully not even being compiled while release process).
I like the approach but I dislike several little problems that come with it. First of all, “operational” snippets are often bound to the exact configuration – hostnames, port numbers etc. Even secrets! Thus, you shouldn’t share it as is: they should either become some developer environment script, or go away with the repl history. Don’t encourage other users look into the pie if you’re not sure it is the same pie you’re both having.
But my main concern is that the problem is being resolved on wrong level. There are special programs that are perfect for using and managing snippets called text editors. Every text editor (and hopefully any IDE) provide search, copy and paste capability. Emacs even has a built-in buffer that can be used specifically for that reason called scratch buffer: something written there for the moment, edited, ran, saved somewhere else… and then scratched out as new tasks are coming. You may even configure project-related scratch buffer that will not erase its text after restart of Emacs. So for the development itself you may safely use scratch buffer (or anything having same function in your editor of choice). But what if you want to reuse it? Create either a devenv script or yasnippet file. What if you want to share it with colleagues? Use gist (or even better internal wiki). In that way when the code will change the behaviour (due to your or your colleauges’ work on the code or infrastructure) the snippet will not be incorrectly bound to the updated code. The script is outdated? Well, update it on separate PR, or let someone else do it. Wiki is outdated? Fix it on the spot. The idea is that the production code should not be contaminated with the operational code – or it should be a well-designed part of the code.
Programming in wartime
I’m Ukrainian, and Ukraine is fighting for its very existence right now. I’m a civilian (i.e. not conscripted yet) living in Kyiv. It’s relatively quiet here now, except maybe one or two raid attacks alerts per day.
This post is a mix of insights of how it is to work full day in wartime – in no particular order or structure. Of course this is very limited point of view, as I’m describing my own experience and my own surroundings. Being in Kharkiv, for instance, I would experienced quite a different conditions (Kharkiv is under constant shellings and bombing for a good year now).
Hardware
My current hardware setup was planned during my onboarding at Apptopia (great company, BTW!) in the beginning of 2022. I’ve decided to try MacOS for the first time in my life (was a Linux user for ~15 years), and have bought myself a M1 Macbook Pro. This was a great decision, mostly not due to the MacOS bells and whistles, but rather due to great battery life and capable processing power, that both led me through the time of blackouts in the late 2022. I was able to more or less use the whole stack locally, building and testing monorepo in around 30 minutes (including all integration tests that were based on services like Cassandra, Apache Druid and Spark ran in Docker Compose infrastructure).
I’m also using quite big external monitor (34“ Samsung Curved C34H890) that is connected to the M2 Mac Studio. This was my understanding of how ergonomic workplace should look like for me: standing desk, Kinesis Advantage with custom firmware (see https://github.com/vlnn/kinesis-advantage-2), the Apple Trackpad mounted on the keyboard etc. All this fine and dandy except one thing: this setup doesn’t have a battery and is shut down during the power outage. After russian shellings to the pretty much all the Ukrainian power plants infrastructure we’ve experienced blackouts as long as for 12-18 hours per day. This have disrupted my work abilities even lower, making me sometime to work in chunks of 2 hours (of which the overhead of constant household chores like getting the power station ready, dishes clean and teapot hot and ready took pretty much a good half). So 1 hour of work with electricity on, then you go into unknown timeslot of darkness and bad internet (my ISP relied on usual power lines too much. Now I have 4 independent ISP lines, one of which is cellular (i.e. works until mobile network is up – but unreliable and slow) and one is optical (was sluggish at first, requiring the hardware reboots, but quite OK in a year after the installation – I’m actually posting this text during blackout and have no problems with the internet at all)).
As I had some time and resources, the orders were made for some power supplies (or rather power accumulators) that made our life much easier. I have now two EcoFlows, the bigger one is connected to the fridge and is more of a reserve of electricity for even worse conditions, and the smaller one is powering the wifi APs and ISP’s routers. As I said, desktop and monitor are fully shut down during the power outages, and for now I’m OK with that: I’m just using my macbook.
But there’s a slight problem – instead of using the ergonomic way of work at my precious stand desk, with hilariously comfortable keyboard and big display, I’ve taught myself to work at macbook sitting at the sofa even when the electricity is allright. Actually I found that I’m more productive that way! Not sure how it works, I guess it’s more of a bad habit becoming a second nature.
Software
Main energy saving solutions I’m using now are Al Dente (program that controls the level of the battery to be always at the healthy level – even though I’m not sure it’s really that useful) and OrbStack instead of usual Docker Desktop. I’ve experienced huge energy saving after moving from OSS Docker Desktop to evil closed OrbStack. But let me tell you, this migration saved me a ton of time. OrbStack is really Docker made right, only proprietory. But we have to make our decisions.
Syncing two computers both using MacOs is pretty easy (just use iCloud!) but unreliable (you never can tell if things are really same on both sides). E.g. syncing the directory with org files brings me conflicts every time I’m using org-agenda. I’m sure there is a way to make it work, but for now I’m just using org-mode for the documentation, and calendar (BusyCal) for work planning.
Main power users on my system (according to Activity Monitor) are Emacs and Safari. Safari seems to be much easier on Memory and CPU consumption than Chrome or Arc, and also syncs good enough between phone and two Macs. So Safari it is.
General life tips
- Have all your shit charged when you have a possibility. That means all your phones, all your powerbanks, all your notebooks, tablets, kindles etc. Just get some kind of USB hub, and let it be busy every minute the power is on. You never know which 2% of battery could be converted into critical information or just a heart warming call from a friend. You need both.
- Prepare a stock of ramen-like stuff, anything that can be prepared quickly and easily. Let it be some high-priced tourist food or just a noodles from the nearest shop, have some extra. There are 1-minute instant soups, 2-minutes porridge, things ike that. Buy yourself a big box of candy or any sugar-high sweets, put it away and eat it when things are sour.
- Have a ready supply of hot drinking water: use thermos or anything like that, so you have have some tea, you can fill the heating bottle etc.
- Try to have your fridge working. I know people who just fill the freezer up so the freezed food itself was working as a cold accumulator, but I wonder how safe and sound the solution is. I’m using power station.
- Minimize the doomscrolling. It doesn’t help at all, but it’s very good in making yourself miserable. I mean it’s really hard to live without information, but don’t swim across the different opinions that don’t really matters in the time, when your every day can be your last day. You better have some extra brain resources to live through.
- Don’t expect to work full time. In reality I was able to work effectively around the half of my usual work time – and this is my optimistic estimates.
- Overcommunicate. Document everything and send to your colleagues. Push every commit. Write in slack. Talk in zoom. You need the society and society kinda needs you (not really). But it’s better to show that you’re alive and kicking than disappear for a week and then return with some crazy good PR that is not really needed anymore.
- Buy yourself a proper headlamp – they are crazy good now, with quite a long battery life. Buy your wife a headlamp. Buy a headlamp for your dog (I’m not joking).
- Don’t use elevators at all times. It’s easy for me, it’s not that easy for everybody – but you don’t want to stuck in the elevator during the air raid.
- Put all the important papers (passports, money etc) in a water-proof package, put that package in a backpack, have this backpack right near the door at all times.
Macos problem with HEX input
If you’re typing using non-english symbols like ς or ґ you might have problems with entering those into modern computers – there are different encoding systems, as well as different keyboard layouts, and it’s not that unusual to have problems with one that you can live with. Then you build yourself QMK or ZMK keyboard. They are programmable – you can make them type anything. ANYTHING! Right? RIGHT?
No, that’s not true. You can’t go fully independent of OS language layouts, that are converting scancodes into the keycodes and then into the characters themselves. You press [Q] in the UA mode, it gets to the OS as [Q], layout mapping makes it [Й], and you see it like that in the text you’re typing. Among others, this should resolve problems with shortcuts like [CTRL+S] that may become unusable in cyrillic layout (as there’s no such thing as [S] in Ukrainian, so you just can’t save!) or get to some very different place on the keyboard if you use COLEMAK or something even weirder ([ASDF] in QWERTY maps to [ARDT] in Colemak).
But why not make keyboard processor work even more? Why not provide the unicode code of the character instead of the scan code? Windows, Linux and Macos have their methods of the so-called [Unicode input](https://en.wikipedia.org/wiki/Unicode_input). Problem solved? Not really!
Macos has long lasting [bug](https://discussions.apple.com/thread/253636848) that prevents you from entering some codes using Unicode input. E.g. you may input [á] (code 0x00E1), but never could [à] (code 0x00E0). Similarly using the hex codes you can’t enter greek pi (code 0x03C0). You can’t enter cyrillic [р] (it is different from English [p]) – seemingly just because their hex code ends with zero! (codes 0x0440).
It seems to me that in my 40s anywhere I dig deep enough I get to something very different from the diamonds: I get more and more old rancid standards and piles of ancient bugs without wings.
#+title: Antiprogress of the Dropbox
Not that long time ago (or was it long time? 10 years ago or so?) Dropbox was the new kind of the services – very simple, very cheap, very direct kind of service. You want to share the photo or your hipster todo.txt, you put it in a special folder and that’s it: it will be delivered automatically to everybody whom you informed the link, or to every PC where Dropbox is running under your creds. That’s it! Super easy, super cool!
I just used current version of Dropbox app for Android, and it is just terrifyingly awful. For starters, it has tutorial wizards that break my needs; I want to press a button, but it is covered with a text cloud of a tutorial. Next, I want to download some video files to my android device: there are buttons “Sync”, “Make available offline” and “Save to Device” – and also “Duplicate”. Next, it asks to access my photos and my camera. And moreover, it shares the names of people who have access to the folder to anybody who has it already.
I can’t even…
I understand Syncthing could be infuriatingly complex, but at least it does one thing, and does it good.
Historical bits and pieces
Some time ago I was a part of a team who introduced modern software development processes (text-based sources, CI, CD, cloud here and there) across the company with humongous and very cleverly written monolith. Yup, internally sources were not stored as text files. Yup, the format was created in-house. Yup, you had to use internal toolings only to work with this code. Yup, it was a great revelation for me to understand how different real work is from the world of js-hipsters deploying things over heroku.
Interestingly enough, the core of the my team was consisted of people who actually wrote the most clever parts. I was a part of this project for couple years trying my best and watching superheroes around me trying their best to finish this project. At some point I left the company and all I have now is this screenshot of one-week project of providing developers possibility to load customized tools into the work environment.
Two unsettling ideas arise in my brain after I share the picture above:
- Software industry is expanding so fast that half of your colleagues perhaps have less than 5 years of experience (stole the idea from someone, but it’s as unsettling as my one).
- Some senior clever guys and girls right now are trying to help ’newcomers’ to work with legacy code bases they themeselves developed over the years. This task may be much harder than actually developing the legacy code base.
