I think they meant non-monetary personal expense. As in "I'll book the crappy motel that requires me to take the subway for 45 minutes, rather than spend an extra $25/night for the lovely hotel that's right next to where I need to go".
Willing to relocate: No
Technologies: Historically Java, but recently I've been working in Kotlin and Go. Mostly backend. Personal projects in Clojure, Arc, Emacs Lisp.
I just moved to Boston for my partner's doctorate program, and my current job isn't ok with remote work. So here I am. I've done mostly backend work, but have done a little bit of frontend for internal tooling and personal projects.
The thing I'm most proud of at a job is a hackathon project I made to schedule shipping services in a warehouse. It moved these schedule changes from taking an hour to taking less than ten seconds. We later extended it with more features, becoming the backbone of things like shipping pricing and capacity limits. It was the first multi-warehouse aware piece of software at the company.
I think the point the author is making is: unless you control all the code you're calling, in a language without immutable datatypes, you can't be sure the other functions don't change your data.
Very neat! It would be cool to see, I'm sure. Anarki hadn't changed too much, but there are some things for sure. Any especially cool features added or changed? Must be cool to work in a language you control.
It is extremely satisfying! I would enjoy having community feedback about it too, but so far publishing a new version has been too heavy a lift. Maybe one of these years.
https://news.ycombinator.com/item?id=11240350 has discussion of one change we made to Arc, though it's already 8 years old - the midpoint between today and the original release of Arc, I guess.
I've used other Lisps, but Arc for me fits a very enjoyable programming space. There's a small enough core that I don't have to spend a lot of time figuring out, say, how to change logging levels or why Spring isn't parsing a POST body into the object it's supposed to be. But it's also large enough that I don't need to rewrite an http handler.
I've tried to keep it Arc-compatible, but I always run it on Anarki.
Run it like `(gensite "path/to/site/base")`. The site root is a folder with the following things in it:
1. a config file `conf.arc`, with config for the site. It has these keys (but I don't think they're all required):
1. sitename -- title for the homepage
2. site root -- url; mine is "https://zck.org"
3. description -- used in the RSS feed.
4. slogan -- used in the sidebar
5. navbar-entries-at-top -- extra links at the top, as a hashtable. Mine is ((tagged table ((href "art") (content "my art"))))
6. mailing-list-cta -- A thing put at the bottom of each page (except the homepage) that is a call-to-action for my mailing list.
2. a folder called `published`. This contains the entries in the site. Each file is the html contents of the body of the entry, and I don't believe it matters what you call the file. Each entry also has a bonus set of options in it, which I'll explain later.
3. a folder `pregenerated` that has things in it copied verbatim over to the output. I use it for things like my favicon, css, images, and some html games (https://zck.org/numberdle/?variant=rationerdle).
4. a folder `frontpage`. This contains entries that do not directly result in a page; they merely result in entries placed on the frontpage and rss feed. They have the same options that the published entries do. I use it for things like announcing when I've given a talk, or launched something that's in `pregenerated`. This can be empty; it just won't generate any entries like this.
5. a folder `codegen`. This folder contains files that contain arc code. Each file, when executed, results in a list of pages. There's some busy work in passing args into it, and getting the results back. Don't start by using this; like `frontpage`, it can be empty, or maybe even nonexistent.
Now, the important part of each page entry -- the "options". This is a serialized arc obj that is put at the top of each entry. It has keys `url-slug`, `title`, `date` (in YYYY-MM-DD format), `navbar` (set it to t to put this entry in the navbar), `frontpage` (the string that gets put in the frontpage for this entry; an <a> link with no href gets set to link to the entry), and `tags` (a list of strings that tag that entry; see https://zck.org/tags).
((url-slug ruby-hashmap-syntax)
(title "til: Ruby's hashmap syntax")
(date "2024-03-20")
(navbar t)
(frontpage "Ruby's hash syntax is confusing. There are two different syntaxes, and they <a>work surprisingly differently</a>.")
(tags ("til" "ruby")))
<div>
<p>I was writing some Ruby for the first time, and I made a hashmap with some data in it.</p>
```rest of file snipped
The arc hashtable is not printed as part of the html output; it's only used for its values, and the page itself starts after it. In this case, the page starts at the <div> tag.
I write my blog in Emacs org files, for which I've also written my own org-mode exporter (https://hg.sr.ht/~zck/ox-zhtml). I've done this because the built-in html exporter creates some really ugly html. You shouldn't be able to tell what html exporter created your html; the org one puts in a lot of "org" properties that are terrible.
I'd love to know if you get this working! Feel free to email if you want to talk off-thread or get more help. I'm sure there is more I missed.
> However, channels are different from Git branches, and do not serve the same purpose. In Pijul, independent changes commute, which means that in many cases where branches are used in Git, there is no need to create a channel in Pijul.
I've never understood this. AFAIK, the only use case I've ever seen for git branches is "I have some code, but don't want it going live yet". Maybe it's a WIP demo, maybe you want someone else's eyes on it, maybe you just want to back your current state up on a remote server because your laptop is going to explode.
Am I misunderstanding, and Pijul manages that without channels? Or is there a common case git branches are used that I missed?
A common case for git branches is long-life versions. For example, one git branch can be for version 1.0 and one git branch can be for version 2.0. This can be good for major upgrades, as well as for site-specific installations, as well as for regulated industries that need to audit specific versions.
I think the most common use for git branches is topic branches. Independent lines of development you are not ready to share with your team, or your team with the rest of the company, or commit to production. I don't see how Pijul features can remove the need for such lines of development.
I also don't see how it matters whether a branch is long-lived or not. What Pijul may help with is a (broken, IMHO) workflow of some Git projects where the long-standing branches are constantly rebased. This workflow is bad, but having branches in Git does not force you to (mis)use rebase.
I am not saying anything against Pijul, and maybe there is a better way than branches to manage multiple lines of development, but I'd like it to be explained. So far I cannot guess what it might be.
So we have a git branch v1, and a git branch v2, and sometimes we pull commits into both, and other times just one. How does pijul manage that without using channels?
I had the same question. Turns out, it's mostly a future possibility, and for most current use cases of branches in git, you would use a channel in pijul. At least that's how I understand these discussions in the pijul discourse.
Thank for the links! I've looked at them, and while they gave me more and interesting information on Pijul, they did not explain how you can work without multiple channels in a realistic development environment. However, from these pages it appears that working with channels in Pijul is more cumbersome than working with branches in Git.
There are (unfortunately) a lot of git repositories with multiple long-lived branches, often to track what's released in different environments. Unfortunate because it leads to a _ton_ of merge conflicts and uncertainty about what code is live in what env.
It's interesting thinking about this. In my career, I would not think nearly anything I've done resembles research. Just pumping out development tasks.
The one thing I can think of that was like research was really enjoyable.
I should think about how to get more of this in my career. Even making personal projects isn't exactly "research".
I was on a moonshot team in a previous role. Research is a lot of fun to get paid for certainly doesn’t necessarily imply academic (being a DS lends to a bit more of this than typical SWE). In my experience it’s big open problems that no one really expects you to solve, and rarely would there be any top down direction on how to do so. And those problems aren’t always e.g. mathematical. It could be figuring out how a new product could enter a market, quantifying demand for some product, testing out a new algorithm, or doing a greenfield rebuild of something that exists but could only be meaningfully improved by starting over.
I think what is satisfying about this is the fact that your day to day is largely self directed and open ended. It’s not the type of thing that lends itself to backlogs and well defined tickets, and typical productivity methodologies like whole/scrum tend to fall flat in teams like this for this reason. You just sort of dive deep on a problem, put together prototypes, figure out how to quantify their utility, and keep trying new things. There also tends to be less pressure on deadlines because of the lack of top down.
This sounds right up my alley. Any suggestion on roles/titles/companies to keep an eye out for? I’ve been a SWE for 20+ years and have a background in mechanical engineering
Research scientist is one common role I’ve seen, but there are often supplemental engineering roles for these as well. Another way to find these is look for moonshot projects at any major company. Basically divisions that are outside of the core product and business operations. Some risk in these though, since they can be the first cut in a bad economy.
In your average job instead of “research” it’s really “discovery”. which is trying to decipher what some business guy at your company or a customer really wants
If people are asking you to do something that doesn't make sense, there's still nothing to discover. There are only a finite number of holistic social needs, simply do all of them.
> Software in general would be so much better if keybindings were always explicitly part of the user's configuration.
So you'd open up Emacs, and the only thing you'd be able to do is insert and delete text? No "beginning-of-line", no "find-file"? That seems...even less newbie-friendly than Emacs currently is.
No, inserting text is a command (it's the self-insert-command). Presumably how it would have to be done is when some software (like Emacs) launches it'd prompt the user for every required keybinding.
That concept breaks down with the multiple thousands of default key bindings in a typical Emacs setup (source: go into an org buffer press C-h b, then go to a Python buffer and press it again, and so on)
I'm not advocating we ban the default keymap. I'm advocating that we move it.
You may like it fine, but I find it in my way more often than not.
What does it truly mean to be newbie-friendly? Are you trying to teach them the functionality of your software, or your opinions about how to use it? Why not teach newbies (find-file) first? Would that really be so bad? Why not give them both options?
