-
I do similar things with Hammerspoon, you can see it in my config.
-
I feel like a kid asking their parents to keep a dog they’ve found.. but can we keep this?
-
I already use mostly terminal-only, but still do a little ‘refresh’ every now and then, for similar reasons. Just yesterday I changed my shell prompt around, and it just gives a tiny bit of fresh air, and genuinely causes some ‘thinking anew’. Just like rearranging your bedroom, or anything else.
-
Did you try to apply terminal padding?
Like this: https://i.redd.it/rh3n3dxby8fy.png
Every terminal has its own setting how to do this kind of padding, i.e. for gnome-terminal or xfce4-terminal you can set it like this:
[~/.config/gtk-3.0]$ cat gtk.css VteTerminal, vte-terminal { padding: 20px; } -
-
Is anyone aware of the kind of “slow and subtle” niches the author hopes for? Any slow and simple and modern design philosophies, techniques, tutorials, communities, etc?
-
I’ve been doing simple web development on the side off and on. I’ve heard of the handmade network. I also like the how the Go community tends to build things, from an operational standpoint. You have the big things, like Docker, Kubernetes, and Mattermost which are big corporate things, but then you have smaller things, like linx, Hugo, or the various things built on boltdb.
I’d start by removing “modern” as a hard requirement and look at how older, stable tech works.
Any community where web development has mostly been in one place over the last 7 years probably has a lot of the basics covered already, and isn’t likely to be piling on the complexity in droves. My experiments in doing websites in Erlang (as opposed to Elixir) suggest that is one place where things seem to move slower. I suspect the Python web development is similar.
Learn some old, mature tools, like make, bash, python, awk, graphviz or TCL/tk, and use them when you have task that fits them
Build websites with as little JS as possible, just to see how far you can take forms and pages. Take time to evaluate how it works out over time, how the maintenance holds up, and so on.
You might see what sorts of things the modern stacks are trying to compensate for, or realize that there is an easier way to solve a certain set of problems. Mining the past for ideas allows you too get a notion of the fundamental vs incidental complexity
-
I’d start by removing “modern” as a hard requirement and look at how older, stable tech works.
“Modern” means having options anyway.
Back in the Old Days, large computers were the only option. They were great for large institutions with large problems or, at least, large endowments to effectively allow young programmers to build games on them, but if you wanted a small computer for something like process control or home office work or similar, you didn’t have that option. Vacuum tubes, and then discrete transistors, only got so small.
ICs allowed us to make small computers, but they also allowed us to make big computers more efficient, because some problems require big computers, large amounts of compute concentrated in one location to grind away at a task, or large amounts of RAM or storage to handle huge amounts of data, or both.
Similarly with graphics: We’ve gone from having command lines as the only option to having command lines coexisting with GUIs, each allowing the other to do what it does.
Do some older practices get replaced? Yes, particularly in hardware. Nobody but a hobbyist would build a computer out of vacuum tubes these days. Cardstock is no longer a valid input mechanism. CRTs are no longer RAM. But progress is more about having options.
-
To be fair, I’m not against using modern tech, just that if you want something simpler, sometimes older stuff is where it’s at. Not always, of course, but by comparing the old against the new, one can find where real progress has been made, and where something might just be the fad of the year.
React, for example, seems to be acknowledged as a real improvement in the state of SPA in JS. It is certainly unlike most things that came before it on the JS side of things, though it seems kinda similar to IMGUI, and some people have drawn similarities to old Win32 code.
-
-
The ‘slow movement’ really resonates with me and I’ve been slowly collecting links that feel (seemingly loosely) similar to me.
- https://loomcom.com/blog/2014/10/13/the-1993-social-network/ , http://www.ctrl-c.club/%7Egauntlet/tsot/
- https://www.slow-journalism.com/
- http://www.powells.com/post/original-essays/life-in-the-age-of-noise
- http://www.vanschneider.com/pendulum-swings-back
- https://sublevel.net/
- http://tttthis.com/rememberwebsites.php/
- http://manuelmoreale.com/tools
- https://ethanmarcotte.com/wrote/designed-lines/
- https://www.franzoni.eu/stopping-the-internet-of-noise/
- https://kinfolk.com/in-praise-of-slowness/
-
Thanks, I’ll check these out.
-
I’ve heard of the handmade network.
What does “handmade” mean? I read their manifesto, but I have no idea what criteria would be used to define which software falls under their umbrella. Is metafont handmade? Linux? The front page of Google? What about wordpress the software (and not the innumerable wordpress blogs)? All of these were created by a large amount of human effort over years of development. What would disqualify one of the other?
-
-
-
-
Hopefully finishing setting up a basic Packer → Terraform setup for my own website + side-projects so I can easily deploy things. I realised that was one of the blockers for me getting side-projects up and out there.
-
jrc
7 months ago
|
link
| on:
List.community - a wrapper on top of the various "awesome" lists on GitHub
Without JavaScript I get a blank page.
-
Yes… I’m also not a fan of simple webpages that need JavaScript for everything. But it was faster for me to implement it this way. Eventually this will be improved.
-
-
Just guessing based on 1990’s era sites since I don’t do web dev. Tiled series of images, descriptions, and links that CSS could probably handle. Clicking one generates a page with a list of stuff on one side and something for exploration on the right similar to frames I used ages ago. There’s delays for the text on the left appearing. Unless the sources change fast, this could be done statically where each source is periodically scraped, results turned into standard HTML/CSS file for each, and main tiles link to that. It would likely load and render faster, esp from caches, with server-side utilization being lower.
Again, it’s just me guessing based on stuff I did in DHTML days combined what this page looks like it’s trying to achieve. Some web dev people I read say they use JS frameworks for things like making it look right across all devices/OS’s. I don’t know how far vanilla CSS or CSS frameworks take you these days.
-
Yes @nickpsecurity, what you say makes perfect sense.
I implemented it this way simply because I didn’t want to have to maintain the jobs necessary to keep the website updated. I also wanted to be able to pick any GitHub link and replace “github.com” with “list.community” and get the page rendered with TOC, search and star/fork counters (which are the features I added).
So for me, the advantage of having this hosted for free on GitHub Pages, not having to maintain a server, and being able to render any GitHub readme, is worth the delay of having to do everything on the client. But I’m sure many people disagree and would prefer a different implementation.
Thanks for your thoughtful response.
-
Those advantages make sense in your position. You’re also not going to see me gripe much since it’s volunteer work on your part. ;)
-
-
-
-
How did you implement this?
-
I used create-react-app, which is a tool that bootstraps the code necessary to use React for static websites. It’s simple but comes with some limitations that they highlight here. For the styling, I used TailwindCSS which is what’s called an utility-first CSS framework. It provides simple CSS classes that you can build upon.
All the content comes from GitHub. The lists are curated by people and each one lives in its own repository. The descriptions and logos come from GitHub Explore which is also open source. The categories come from the “official” metalist.
The client uses the GitHub API directly. I started by getting readmes in markdown and processing them with remark. There’s lot of plugins for it, including to generate TOCs and render using React components. There were some limitations that prevented the output to look 100% equal to GitHub so I ended up fetching already rendered HTML from GitHub instead (the GitHub API provides that option) and using htmr to convert to React components. That way I can for example pass a custom React component for rendering links, so I can easily show the number of stars and forks, convert relative links to absolute, etc.. It’s not the most performant solution for sure, but the code becomes simpler.
That’s basically it, the source is available on GitHub: https://github.com/listcommunity/support
-
-
-
-
Who do you have your domains / hosting with? They might offer enough mailboxes to suit your needs, unless you’re needing to do transactional emails.
-
lygaret
7 months ago
|
link
| on:
atom/xray: An experimental next-generation Electron-based text editor
To me this points to one of the benefits of Electron being that javascript is a useful UI glue layer - Atom’s moving to push it’s text editng core to C++, xray is a ground up redo in Rust, etc. Emacs is similar, in that it’s an tower of ELisp managing user interaction on top of a c core.
And as a UI layer, I think javascript + dom + css has a lot going for it, not the least of which is a huge pool of people with the required background knowledge to tweak and play and experiment and discover. As an emacs user, I’m really thankful for the elisp package community (ht Magit), but think it could only be better if there was a much larger pool of people able and desiring to work up interesting extensions.
-
-
Why not a GUI using nvim server as the base?
Sure, that would be sweet! This isn’t my project, can’t speak for why that’s not a direction they might be headed, other than that’s not what they’re doing.
Is performance one of those things?
As a UI layer? Sure, why not? A lot of web apps I use everyday have acceptable+ performance in their UI layer. Did you have a specific example you’re trying to get at? I’m afraid I can’t convince you when you start at “attack a strawman”.
-
Sure, that would be sweet! This isn’t my project, can’t speak for why that’s not a direction they might be headed, other than that’s not what they’re doing.
Fair enough. :)
As a UI layer? Sure, why not? A lot of web apps I use everyday have acceptable+ performance in their UI layer. Did you have a specific example you’re trying to get at? I’m afraid I can’t convince you when you start at “attack a strawman”.
One of the big performance hits for Electron apps seems to be the DOM, rendering, etc. Here’s one link referencing that: https://blog.atom.io/2017/06/22/a-new-approach-to-text-rendering.html
-
Ok I understand that, but from the README on the project:
We want to avoid the DOM for rendering the text editor, for example, instead using a canvas, WebGL, or any other approach that can give us extremely good performance. This may make syntax themes slightly more difficult to build, and we accept that trade-off.
It’s really easy to put a line between text-rendering in an editor (which I 100% agree shouldn’t be DOM based, it’s too much overhead for single millisecond latencies), and UI rendering for the chrome around that text-editor, which needs to be fast, but doesn’t have the same requirements or restrictions.
My point throughout these conversations is that throwing out what the JS+DOM+CSS stack gives you (effortless cross-platform development, ease of development, a large community of people who can code to it, a large corpus of examples and good ideas) because it won’t work for 100% of the rendering needs of an application seems short sighted.
There’s a lot of benefit in the platform, and like any tool, you have to decide what’s best for what part.
-
-
-
-
-
It might be a bit old news, but finding some for microservices probably shouldn’t be too hard to find.
https://aadrake.com/posts/2017-05-20-enough-with-the-microservices.html
-
I’ve been building delimited continuations in Mu, my Basic-like statement-oriented language. Now I’m trying to find bugs in it by using continuations in programs. I’m not fluent with continuations, so any suggestions for programs to write are most appreciated. Currently I’m building coroutines, using Simon Tatham’s famous post as a guide.
-
-
Thanks! When I see interesting projects on Github I tend to scan their logs to get a sense for activity, coding practices, etc. So this approach started out as a way to help people who might be like me. (For most people, the log for a random project on the internet is just not on the radar.)
-
I like being able to refer to commits in later commits, thereby threading a conversation. Using a number rather than a hash allows me to get a sense for how distant a reference is. And since I’m developing alone and on a single branch, non-linearity hasn’t been a concern. If that ever changed and multiple people started doing parallel development, I wouldn’t be too concerned about dropping commit numbers.
-
Many of my commits are pretty low-level details. Saying nothing on the subject line is a way to make them less salient, so that the eye focuses on commits like “starting work on delimited continuations” or “done with delimited continuations”.
-
I like not having to come up with commit messages for trivialities like renaming a variable, or regenerating browseable versions of the sources. Since I’m mostly building for myself, I don’t have to put up with arbitrary rules about what mandatory commit messages :)
-
I really like those points—and thank you for taking the time to explain it.
It’s bothered me a bit too that hashes don’t really give away and information by themselves, so I think I might start adopting a similar pattern too. Causing more focus to be given to other commits is an interesting point! I have found it overwhelming sometimes when there’s commit messages for the sake of commit messages, and it can take longer to parse a log.
I stumbled onto your blog post about ‘Habitability’ and found it also quite interesting so far! Just subscribed to your RSS feed.
-
-
-
-
I do pretty much the same thing as @je, but I do it by ‘topic’, like I have work/servicename.txt or vacation/location.txt etc. New stuff goes at the top of the file.
This and https://github.com/BurntSushi/ripgrep gets me everything every note editor has with all the future proofing one could hope for.
-
I even do that too! Especially the vacations one. In each of my side-projects folder, I have an ‘idea.md’ file which is based off of a template I have which I then fill in per-project. The ‘log’ section is the equivalent of my general daily log file, just specific to this project.
# Initial thought Date: Location: Inspiration: Solution: Why is it worth the effort? Why is it not worth the effort? What already exists? Difficulty: Tags: # Log
-
-
This is something I’ve personally done since 2013! I started creating a text file almost every day in a directory structure of ‘../daily/2017/17-10-14.txt’.
I use it as a journal (I put the current time and wrote whatever it is down), a scratchpad, a temporary todo, habit tracker, etc. It’s been super useful for me. I’ve thought about formalising it, using tags, etc. but have found myself getting along fine.
I used to use Day One (macOS/iOS) religiously but have found that this daily txt log mostly sufficient. What I would like is to expand my macros from getting the current time to getting my current location and weather.
For work, I have a ‘log.txt’ in which I have a section for each day and copy-forward the previous day’s section. While we have our own company tracking tools, etc., this is purely for me and has helped me keep better track of everything I need/want to do without letting anything slip out.
I’ve found that doing each of these things takes up very little time too—partly due to not formalising it or making it fancy. I’ve thought about using a vimwiki which I’m a big fan of, and gave it a go once, but I stopped. It was no fault of vimwiki itself, but so far have found the text files sufficient.
For my phone (iPhone), I use https://ia.net/writer/, and I keep all these text files in Dropbox.
Another reason why I’ve stuck to text files is because of the fatigue of different apps and services disappearing due to whatever reasons.
-
-
Hi @jcs, thanks for creating Lobsters. I only joined recently and it has been a blast to be welcomed into the community.
Forgive me for being forward, but would it be possible for us to convince you to stick around in some capacity? I don’t know your situation, but maybe if you offloaded 90% of your current Lobsters duties to a trustworthy team, it would help? There’s no need for all your current duties to be operated by a single individual, and it’s understandable that it’s a ton of work for one person.
Moderation could be a team, the GitHub could be a team, and deployments could probably be automated.
I would be willing to help out on the Lobsters GitHub organization, since I’ve been slowly learning parts of the code. Also willing to chip in money for server expenses.
-
The idea of a change in ownership is scary before a plan is worked out. If we implemented nice mod tooling, did a small donation run once a year to keep things running, and took over development from you, would you have the capacity to handle the light administration and keep being the owner?
-
-
I was thinking of this as well - the BDFL model, perhaps?
-
-
Rewriting my (small) initial attempt at a side-project (the equivalent of gitignore.io, but for Brewfiles) from Go to Ruby because there’s a readily available DSL, and the Homebrew ecosystem is Ruby. Then, revisiting the design, and hoping to launch something on the weekend.
-
Profiling a website running Drupal. Attempting to install Prometheus to help with various profiling metrics…
Attempt to finish a sync of 2 sites, site migrations woes.
Try to stay above water.
-
-
I’m slowly switching away from as many streaming/cloud and other related services, and back to simply buying, owning, and storing things. A local copy, and then a couple remotely (i.e. rsync.net). I’ve had so many albums on Spotify, videos on YouTube, defunct web apps, etc. that I want to avoid this happening more.
I have an idea for a side-project that I’m kicking around in regards to this that I’ll hopefully make some way on soon.
-
For personal archiving I’ve had good mileage out of camlistore; though it doesn’t yet offer playlists or anything, the backup model fits well with how I want things stored.
-
-
-
I tend to just buy the DVDs at local stores.
Ripping from streaming services (eg youtube-dl) is an arms race I’m not keen to get too involved in (although it also seems to work well).
-
-
-
-
Trying to choose which of my side-project ideas to work on next. I’m thinking of starting to tackle my offline-first approach for everything I currently use an online service for (e.g. Pinboard for bookmarks, and another site for inspiration/moodboards). A core part is basically being able to define ‘views’ of the file system to give a lot more flexibility than having 1 pre-defined folder structure—this would use extra metadata that I record.
Or, I might try and finish off an annoying bug in another, tiny, side-project: shell-safety-check.
-
I’m also getting excited about reducing my dependency on offline services. Just think: by downloading a wikipedia dump or a Stack Overflow dump I can ensure that for the rest of my life I will have access to wikipedia, no matter what happens.
We need to re-federate the web post-haste, or we are going to find a surprising amount of institutional knowledge evaporating due to link rot and business failure.
-
Exactly. There’s been more and more instances of previous content disappearing (articles on a news website, repository on GitHub, an album on Spotify) on me that it’s been prompting me to speed this up.
For each of those instances, it’s pretty easy to preserve the content. The main thing is that with moving away from Spotify, is that instead of a relatively small monthly fee, to purchase all the albums I listen too, it’s simply not possible. This is a good and a bad thing!
-
-
-
Evaluating your own code can still be very useful. Some examples include: interpreting JSON data
Nooooooope. No. No. No.
While I generally agree with this article, I strongly disagree with everything said about eval- which wasn’t much. Code should never be passed around as string-ly typed data. Not to parse JSON, not to evaluate HTML templates, not to handle mathematical expressions, and… if you need to use eval to detect whether or not a feature is available, how can you use that feature in your code later anyway?
-
-
I got great utility out of eval just today. In 8 lines of python, I wrote a local testing system for aws lambda/gce compute functions/azure function code. The program reads in argv, with each argument being http_route:file_path:handler_func_in_file, slurps in each file, then attaches the handler func to a flask route. This program saves me enormous effort of deploying code to a cloud provider before knowing if some basic functionality works. My productivity increased dramatically because of eval. You can black label anything you want, but you’re just shooting yourself in the foot.
-
-
safety has 0 priority for this use case. it’s lube on the machine that spits out the hard fast product, not the hard fast product itself. your abstractions sit on top of a mountain of mis-aligned interfaces that do things far more evil than eval. they are ready for abuse without much trouble. s/eval// doesn’t keep you safe.
-
Safety has 0 priority, if and only if, this script is disposable. If I intend to use this more than once, I want to write something that isn’t going to hose my entire environment.
-
-
-
-
-
-
if you need to use eval to detect whether or not a feature is available, how can you use that feature in your code later anyway?
Two cases that come to mind:
- lazy loading of additional modules (JS), you might get code size gains with some features and might want to load the smaller code if possible
- for statistical purposes, to know what your users’ browsers support
-
If you like oh-my-zsh, I recommend checking out Zim as well. I haven’t used oh-my-zsh in a few years so I can’t speak about that, but my Zim-based setup’s startup time with 13 modules and a couple other plugins averages around 0.04 seconds, i.e. as fast as author’s bash startup time. And I haven’t done any profiling/optimizations beyond whatever Zim comes with.
I’m a big fan of Zim too. I’ve tried oh-my-zsh, Pure, and a few others too.