Wow I was excited to see the TextMate icon in the screenshot at the end. Good memories.
Readit Newsdaniel_grady commented on Working quickly is more important than it seems (2015) jsomers.net/blog/speed-ma... · Posted by u/bschne
daniel_grady commented on Apple's Software Quality Crisis eliseomartelli.it/blog/20... · Posted by u/ajdude
Oh my gosh. Everyone can always do better, but also, has no one else here had to use Microsoft Teams recently?
daniel_grady commented on Lesser known parts of Python standard library trickster.dev/post/lesser... · Posted by u/rbanffy
I find defaultdict, OrderedDict, namedtuple among other data structures/classes in the collections module to be incredibly useful.
Another module that's packaged with the stdlib that's immensely useful is itertools. I especially find takewhile, cycle, and chain to be incredibly useful building blocks for list-related functions. I highly recommend a quick read.
EDIT: functools is also great! Fantastic module for higher-order functions on callable objects.
Although it's not part of the standard library, toolz is wonderful for rounding out these modules.
Without Smalltalk, there would have been no HyperCard, and HyperCard definitely succeeded in that goal to a significant degree.
It's a pity there's never been a modern reboot with the right factors aligned to continue that work.
I made a serious effort to integrate Muse into my work starting around late 2021 or early 2022, and in fact bought an iPad Mini and Apple Pencil specifically to use Muse. The work that comes out of Ink & Switch is always interesting, and I was excited to try some of it out in the real world. Over a year or so, I used it to read and review PDFs (mostly journal articles for work), wrote and presented a lunch-and-learn from Muse, dropped PNG plots from Jupyter for scribbling or easy comparison; I even got one of my colleagues interested enough to use the collaboration features semi-regularly.
It hasn’t stuck though, and I’ve stopped using it; subscription will lapse later this year. I’m sad; like others here I really wanted to like this and for it to make sense to keep using.
I don’t a have clear set of reasons for why it didn’t stick. Just thinking out loud. Partially, I was fighting against my organization — my immediate team is science / Apple / Python, but the larger company is Teams / Windows / PowerPoint, and that’s always friction. Partially, it was a workflow thing — most often I wanted to review PDFs, which live in Zotero, and then it’s like, did I copy that one over yet? Where are my notes about that one? Muse’s PDF excerpting feature is really wonderful; the lack of being able to zoom a PDF, or support for table of contents, was a bummer. Large PDFs like textbooks could be problematic. Partially it was that Muse on iPad vs macOS felt like two incomplete halves — can’t type on iPad, can’t ink on macOS. Partially: things I did in Muse, felt stuck in Muse; not literally true, but copy or export out of Obsidian vs Muse feels very different. Partially: always that nagging concern from lack of E2EE sync, and after Apple launched E2EE for iCloud, Obsidian + iCloud offered the sync I wanted with a subscription I already had anyhow. (Collaboration features aren’t as good, though!)
Anyhow. Muse did so many things well and first in this space, it remains impressive. Many iPad apps (in my opinion) are incrementally different versions of Apple Notes; Muse is a standout example that supports Apple Pencil as well as Apple first-party apps but targets a very substantially different use than drawing. Although I’m setting it aside, still optimistic about what this year will bring for Muse, and wishing the best to Adam Wulf!
daniel_grady commented on Data Science at the Command Line, 2nd Edition (2021) jeroenjanssens.com/dsatcl... · Posted by u/aragonite
Worth highlighting that make defines a DAG, and that you can run make tasks in parallel which will automatically bottleneck (as desired) on common dependencies, and fan out otherwise.
The sort of massive C++ build that make can handle are typically much more complicated than your average ETL pipeline. So, there is plenty of room to grow into make.
The classics never go out of style. Mike Bostock has a nice article about the use of Make for data workflows: https://bost.ocks.org/mike/make/.
daniel_grady commented on Forgetting the history of Unix is coding us into a corner theregister.com/2024/02/1... · Posted by u/lproven
OS X / macOS has always defaulted to using filesystems that are case-preserving but not case-sensitive. You can cd to ~/library and see the contents of ~/Library and trying to mkdir ~/library will fail because ~/Library exists.
Amazing, I can check off “learn something” early today!
daniel_grady commented on Forgetting the history of Unix is coding us into a corner theregister.com/2024/02/1... · Posted by u/lproven
> For instance, macOS is a Unix™. It passes the tests, and Apple pays for the certification. But it hides most of the real Unix directory tree, its /etc is relatively empty, it doesn't have an X server – it's an optional extra. And most of all, it's not case sensitive.
What does it mean for the operating system to be “case sensitive”? Certainly APFS is case sensitive, so this must refer to something else?
One reason to choose one over the other is the dependencies they’re bundled with. Take numpy. With PyPI, it’s bundled with OpenBLAS, and with conda, it’s bundled with Intel MKL, which can be faster. See https://numpy.org/install/#
That’s a great point; I didn’t know about that!
I can understand that well. A few articles from ByteCode! helped me to "follow my intuition" and do as much as possible with native Python tools.
https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv
https://www.bitecode.dev/p/relieving-your-python-packaging-p...
Those are interesting pointers; appreciate it! My own experience over the past three years has been similar. I tried using Pipenv, and then Poetry, for internal projects at my company; in both cases the tool seemed overly complicated for the problem, slow, and I had a hard time getting co-workers on board. About a year and a half ago, I saw [Boring Python: dependency management](https://www.b-list.org/weblog/2022/may/13/boring-python-depe...), which recommends using the third-party `pip-tools` library alongside the standard library’s `pip` and `venv`, and switched to that for the next project. It’s been working great. The project has involved a small team of scientists (four or five, depending) who use a mix of macOS and Windows. We do analysis and development locally and write production-facing algorithms in Python packages tracked in our repository, and publish releases to Gitlab’s PyPI. For our team, the “get up and running” instructions are “clone, create a venv, and pip install -r requirements.txt” and for the software team that manages the production systems, deploying an update just means pip installing a new version of the package. Every team’s got different constraints, of course, but this has been working very smoothly for us for over a year now, and it’s been easy, no pushback, with everyone understanding what’s going on. Really impressed with the progress of the core Python packaging infrastructure over the past several years.