For me it shines when you need to write shell scripts but you prefer do some parts in python. As another commenter wrote os.system or calling the subprocess module works too, but I find it less satisfying.
I would not advise to replace your interactive shell with it as it's a pain when you stumble upon uncompatible commands, but writing shell scripts with xonsh is a wonderful experience.
> Only isolate your code from truly external services
That makes tests more trustworthy but also sometimes harder to maintain I think. I have seen cases where small changes on the code base created strong ripple effects with many tests to update.
Arguably, the tests were not very well written or organized and with too many high level tests. Still, this and the very large execution time of the test collection made me realized that for medium to large projects, I will be much more careful in the future before going all in with the no-mock approach.
I think I got your point but might have expressed myself badly. The pdf can run js and messes with the display right at opening time, without any warning or ask for permission.
You can manipulate form fields at anytime, and setInterval is provided so you can have things that run in an infinite loop. But yeah, as a first approximation, the only things js in pdf can do is mutate form fields and react to events related to form fields, unless your pdf reader is acrobat and that's something else entirely.
I made a game of life in pdf using this technique, but pdf.js is less open to chromium to respect the standard on letting the pdf designer defining the ON and OFF state.
One other way would be to use normal text fields and leveraging custom fonts. I think there are an enormous potential with fonts in the realm of pdf hacking. I think there is also a story of past vuln on pdf.js because fonts were evaluated outside the sandbox.
I was considering doing exactly that ahah. We should connect to share our hacks and pains. One could project would be to run wasm4 games because, yes, pdfium and pdf.js can run webassembly.
I second this recommendation for early startups. We learn from tons of lean books that customer discovery is crucial to not build the wrong thing, but this book gives very practical ways to do that well. Most recent useful read for me. Still in the lean canon, a great complementary read could be lean marketing, as validating your sales channel is of an equal importance of validating your PMF.
I schemed the readme, but did not see support for prefixing each line with line numbers, this is an absolute must have for people like me who have a workflow centered around generating git patchs. In my experience that gives generated patchs much more chances to be incorrect.
I use xonsh as a shell for few years but I think I will go back to another shell as I am too frustrated with incombatibilities. That's being said, my xonsh scripts are there to stay, I still think that's an excellent way to build scripts.
A related theory (and book with the same name) is 'Learning as a generative activity', which states that learning occurs when one uses informations / half-backed k owledge to produce new content.
It becomes more relevant these days since we tend more and more to outsource content creation to the machines. This theory would predict that we would learn less doing so.
As others wrote, in depth practice is a sensible choice. Once it's done, I believe spaced repetition is a nice insurance against memory fading and can be as simple as a few big cards listing the concepts learned even if that's really not what spaced repetition proponent would suggest.
Yep...the point is still valid though. Technically, scientific publishing is easy to replace by a sound solution. Yet, politically, it's so hard. Think also to all the students that fully realize that before commiting seriously to academia. They either leave in disgust or start to play along. The death of A. Schwartz moved me a lot during my Phd. But my supervisor forbade me to publish in a public solution based on post review only saying that it would threaten our lab reputation. I am not sure I would have stayed in academia even if the system was less ugly (nb I was in cognitive psychology), but I am fully certain that I would have been much more happy there with a better system.
I use frequently the basthon notebook https://notebook.basthon.fr/ which is also a wasm powered jupyter (based on pyodide) and quite like it. It's flying a bit under the radar as it's not translated in other langage than french. How does it compare to this project?
I sync my .xmind with .md files using homemade python scripts. Lately I went the extra mile to produce reveal.js friendly mds. Very handy. I did not gather enough energy to open source this stuff. But this comment made me realize this pain point I have with Xmind might be more common than I thought.