Occasionally I run across a site that has a bunch of PDFs that I want to read. This wget lets me download them for later reading.
wget -r -np -l 1 -A pdf http://example.com/pagewithpdf.htmlIf you want to use the downloaded website for local browsing, you will need to pass a few extra arguments to the command above.
wget -m -k -p https://example.com
I recently ran across a table that was not able to be read and it occurred to me that I should be archiving my database on a regular basis, rather than relying on just the Linode backups that are done nightly.
This command will do it for you:
mysqldump -u root --all-databases | gzip > backup.sql.gz
Search engine behaviour has changed over the years in ways that make it more difficult for me to get results that I am looking for. For my vocabulary sites I often want to get a word and a specific context. For example, if I want to find the word gregarious used in the same context as buffoon, I used to be able to put both words in the search box and it would find pages with both words. Not any more. When using Google, you can force it to find both words in the text of the page by using:
allintext:gregarious buffoon
Another one that I can make use of is:
gregarious AROUND (4) buffoon
Unfortunately, these don’t work in DuckDuckGo.
There are a bunch more at the ahrefs blog
bobwaycott at ycombinator made a comment that summarizes my thoughts on developing software for end users.
Always. I’ve been practicing this for 10 years, most of which I’ve been working as a consultant building custom software for internal business processes, as well as customer-facing software for clients’ users. My typical process looks something like this when a feature/change request or random idea is asked for—which almost always comes in along the lines of, “Can we get X added in that does Y and looks like Z?”:
1. I never say yes to any request immediately. I always tell a client, “Anything is possible that doesn’t violate the laws of physics, but let’s dig into this more.”
2. Ask what they’re trying to accomplish. What problem are they trying to solve? What mistake are they trying to prevent? What is the end goal? I ask questions until I can explain back to the customer what they’re really wanting to do and why.
3. I the push back on why I think we should not do what they’re asking for in the way they’re asking for it. When doing this, I always try educating them on the tech behind the scenes, potential pitfalls, how adding something (especially if it’s visible to people) will make it nearly impossible to ever remove it once users get used to it, when they’re asking for something that would be more effort the way they’re asking for it to be done than it’s worth when it’s trying to solve for a rare edge case, etc.
4. After explaining the problems with their idea as given by non-experts, I start suggesting ways we could accomplish their goals with a simpler UX, or even no UX at all, relying on the ability to automate things if we have enough information, or hide all the complexities of a process behind a single button once we have the right info to intelligently take action.
5. I give a couple of recommendations for potential ways forward that solve the real problem in a way I’ll enjoy building it out. Then I let them make the choice.
Following this pattern has pretty much never failed me. What feels best about it is when I see clients actually learn how their software works when I’m working for them. I love it when they remember the discussions we’ve had, internalized it, and recall it when we talk 6 months later about their new idea. Over time, their ideas improve because their understanding of how their software works improves. They also become increasingly invested in our working relationship as their trust in my concern for solving their problems—and not just doing their bidding—increases.
Never shy away from challenging your customers’ ideas—but always do it in a respectful manner that gets to the heart of their real problems and educated them along the way. They’ll appreciate it, and will keep coming to you for more. I don’t think this is unique to being a consultant, either—the same sort of process can be followed with direct users of your own product