mjmein
I still struggle to see how people actually use this with devops on a day to day basis.
I think that some type of integration with tmux would work well - have a running tmux session, and then just queue commands from emacs to that session, instead of running directly through emacs.
My main problem with it is that, unlike with executing commands in the shell, with org you don't get any progress, and emacs seems to hang while running the command.
For example, running apt update tends to freeze emacs without any progress reporting for a few minutes.
I'm hoping that I'm doing something wrong and that someone can chime in with a suggestion, because I really like org-mode, and I really like the idea of doing devops using it.
Basically, what I do is:
- make a list of books that I want to read
- over time, as I acquire the book, I have a tool to split up the book into separate chapters. These chapters are then loaded into the reading app.
- every day, I open the app and it chooses a chapter from a random book for me to read
- as I read, I highlight interesting, useful or difficult sections that I want to remember/study further
- instead of showing me a chapter, the app can also show a list of highlights from a previously read chapter. During this step it asks me to create little quizzes from the notes - either in the form of cloze replacements or simple q&a. Alternatively I can also create reflection questions or daily actions from the notes.
- in addition to the previous steps, the tool then also uses spaced repetition algorithm to review the little quizzes that I created from the books I've read
- every morning it chooses 10 of the actions that I identified and asks me how I am going to implement/practice them today
- every night it asks me how I practiced those actions
It does a bit more than this, but that's the main part. I've already seen great results from doing this, as I've always found the biggest problem with reading is that it tends to be too passive, and having the review and action steps helps alleviate that problem.
But then I tested their examples on my mobile phone and it looked really bad. It just seemed that it wasn't responsive at all, which really surprised me.
Not for heavy use, but for quick notes and calendar checking.
I ssh into my home server and drive my spacemacs instance from there.
However, the people generally working with/on emacs are not looking for that, they are looking for an editor optimized for customisation. They have already gone through the experience of setting it up, so why would they spend most of their time making it easier out of the box?
There is a cost to everything, and so far most people on emacs side have decided to spend their time on improving it's power, not it's ease of use.
There is some learning curve figuring put how things work, but the advantages of having SQL encoded as clojure data are worth it, in my opinion:
- s-expressions everywhere means that structural editing works
- allows for easy composing of sql queries - can very easily add custom filters, joins, etc and build up queries dynamically
- can easily add abstractions, for example something like https://github.com/metabase/toucan/blob/master/README.md
If you use postgresql, check out: https://github.com/nilenso/honeysql-postgres/blob/master/REA...
Instead, you develop code in a file, but constantly evaluate code as you go along.
When I work on a clojure project, I very rarely open the actual REPL, but I am constantly evaluating code and experimenting with different implementations of functions.
Then, when I'm happy with the results, I ask the editor to evaluate and insert the results back into the editor. This then becomes the unit test.
What makes a good REPL?
My workflow is generally to build up state, and then experiment with functions on that state until I get the correct output.
This workflow is very natural in Clojure, Common Lisp and even Python (with IPython and autoreload).
However, in Racket you have to restart everything on every change. This works ok for smaller applications, but if for example, your state is a large dataset that you pull from a remote database, it becomes a little more difficult.
There are possibly workarounds, and I'm not saying that Racket is bad because of this. There are definite advantages to this approach, mainly for keeping everything simple and predictable. However, this was a roadblock for me, and the main reason why I didn't spend more time working on it.
I also miss the ability to make changes to code, refresh the browser and instantly see the changes (instead of having to restart the server after each change).
Here's a good discussion (in my opinion) of what makes a good REPL for interactive development: http://vvvvalvalval.github.io/posts/what-makes-a-good-repl.h...
However, where it fails for me is in its lack of interactive development. When I investigated it, there seemed to be no way to actually connect a repl to a running program.
Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state.
This was a big disappointment to me, because even python with ipython and autoreload allows for more interactive development.
I suspect that this decision was made because of racket's start as a teaching language, because it is simpler, but way less powerful.
Not using a database makes it really simple to install or migrate servers (just copy the directory).
On the other hand, being a dynamic PHP app means there is no explicit build step needed, and you can build any kind of plugin that you need.
For some reason this made me think of clojurescript, and I think it might make a nice library for use in cljs as well.