Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
curl cheat.sh — get an instant answer to any question on (almost) any programming language from the command line
tldr
do curl cht.sh/go/execute+external+program to see how to execute external program in go
And this question: why I actually should I start the browser, and the browser has to downloads tons of JS, CSS and HTML, render them thereafter, only to show me some small output,
some small text, number or even some plot. Why can't I do a trivial query from the command line
and instantly get what I want?
I decided to create some service that will work as I think such a service should work.
And that is how wttr.in was created.
Nowadays you probably know, how to check the weather from the command line, but if not:
curl wttr.in
or
curl wttr.in/Paris
(curl wetter in Paris if you want to know the weather in Paris)
After that several other services were created (the point was to check how good the console
can solve the task, so I tried to create services providing information
of various nature: text, numbers, plots, pseudo graphic etc.):
curl rate.sx/btc # to check exchange rate of any (crypto)currency
curl qrenco.de/google.com # to QRenco.de any text
And now last but not least, the gem in this collection: cheat.sh.
The original idea behind the service was just to deliver a various UNIX/Linux command line cheat sheets via curl. There are several beautiful community driven cheat sheet repositories such as tldr, but the problem is that to use them you have to install them first, and it is quite often that you have no time for it, you just want to quickly check some cheat sheet.
With cheat.sh you don't need to install anything, just do:
curl cheat.sh/tar (or whatever)
you will get a cheat sheet for this command (if such cheat sheet exists inf one of the most popular community-driven cheat sheet repositories; but it surely does).
But then I thought: why actually show only existing cheat sheets? Why not generate cheat sheets or better to say on the fly? And that is how the next major update of cheat.sh was created.
Now you can simply do:
curl cht.sh/python/copy+files
curl cht.sh/go/execute+external+program
curl cht.sh/js/async+file+read
or even
curl cht.sh/python/копировать+файл
curl cht.sh/ruby/Datei+löschen
curl cht.sh/lua/复制文件
and get your question answered
(cht.sh is an alias for cheat.sh).
And it does not matter what language have you used to ask the question. To be short, all pairs (human language => programming language) are supported.
One very important major advantage of console oriented interfaces is that they are easily
programmable and can be easily integrated with various systems.
For example, Vim and Emacs plugins were created by means of that you can
query the service directly from the editor so that you can just write your
questions in the buffer and convert them in code with a keystroke.
The service is of course far from the perfection,
there are plenty of things to be fixed and to be implemented,
but now you can see its contours and see the contours of this approach,
console oriented services.
The service (as well as the other mentioned above services) is opensource, its code is available here:
https://github.com/chubin/cheat.sh
What do you think about this service?
What do you think about this approach?
Have you already heard about these services before?
Have you used them?
If yes, what do you like about them and what are you missing?
26 -
HTTP return codes cheat sheet :
1** : Hold on
2** : Here you go
3** : Go away
4** : You fucked up
5** : I fucked up5 -
Weekend plan:
1. I will watch react conf
2. I want to complete vim cheat sheet
3. LFS project is too
4. Netflix
5. ........
...
.
.
Electricity : 😈
Fuck..
😡2 -
My boss just asked me for a cheat sheet I have that lists all our app server's paths.
The paths are attached as annotations throughout some Java files.
Anyway I send him the one I have but he asks if he could have an updated one.
Now imagine if I were like most monkeys and had made this cheat sheet by hand....
2 mins easy vs an(other) hour of grunt work
Why is it that I'm the only person on the team that writes utilities to automate boring grunt work while everyone else just does it manually whenever it needed....
Isn't DRY a core principle of being a developer?
I'm the only person that builds utility apps that automate frequent tasks that people keep asking us to do....21 -
For those struggling with imposter syndrome, keep a record of your progress.
Break it down into
* used
* learning
* dont need a manual or cheat sheet
* use every day
You can also break it down per project:.
"Project xyz (python: 2 years)"
"Project ijk (js:6 months)".
Etc.
Critically, keep these in something physical, like a notebook or whatever you use *regularly and frequently* to keep notes. That's important because you should be glancing over your progress as a remainder.
Each time you want to add a new line, rewrite your existing progress on a new page, before adding the new line.
So as you flip through the pages you get a large and larger chronological list of your progress, and improvement, and experience.
Add a date to the title for each and a brief note about something that you did or happened on that day or week.
You wont second guess yourself so much once you can see how far you came.
Like at one time I was actually competent at js! (Before I stopped the flash cards anyway).3 -
I don't know if this is the same thing everywhere over the world, but, in France, where I live, there's something that infuriates me on so many levels.
Dear HRs,
When you're processing through a recruitement process, you'll publish a job offer. In 95% of these offers, I notice things that follows the same pattern : "We require a highly trained developer in [insert language 1], especially with the [insert a framework from language 2] framework". This often happens when you're talking about Java in first place, but then switching to Javascript.
Please, dear HRs,
GET YOUR SH*T TOGETHER ! I don't know, ask to some of your developers to review your offer, to spot these beginner mistakes. This is an automatic turn-off for me when I notice this king of bullsh*t in job offers, and I understand that the person that wrote this offer has no fucking idea of the business his/her company is dealing with.
Later, these people are those who will interview you with generic IT questions, that they have no idea about what a correct answer might be, and they will only check if your answer matches what is written on their cheat sheet. If you're lucky enough, some people from the actual business will be with the interview crew, so you can actually expect some kind of understanding.
*angrily goes back to looking for a job*4 -
Working with assembly is just something different... note to self: keep a cheat-sheet with the labels and corresponding addresses at hand.....
8 -
My new favourite commit message:
"All changes as of 18th Sept"
How tremendously useful? There I was looking to know what changes were made to enable a feature / service, thought I could look for that in the commit message, but no you've given me a much more efficient way of finding out.
I simply need to download the contents of your memory, find out what date you made a change, and then dig through the massive commit to find the piece of info I need.
Forget experience using Git features, managing merges, following Git flow, or even any other SCM ... how can people be so tick when it comes to recording what they've done.
Heres a little cheat sheet for those struggling:
- Commit message
Describe what you actually ****ing did. Don't tell me the date or the time, thankfully Git records those. Don't tell me the day of the week, if I need to know I can figure that out, just tell me what ... you ... did.
- Feature branch names
Now this is a tricky one. You might be surprised to know that this isn't in fact suppose to be whatever random adjective or noun popped into your head ... I know, I too was shocked. The purpose of this is to let other people know what new feature is being worked on in this branch.
- Reusing feature branches
Now I know you started it to add some unit tests, and naming it "testing" is sort of ok. But its actually not ok to name it testing when you add 3 unit tests ... then rip out and replace 60% of the business logic. Perhaps it would have been wiser to create a new feature branch, given you are now working on a new feature.2 -
Back in college, we were taught to code in Java, nothing much more complicated than Hello worlds and non persistent CRUDs.
Somehow I eventually ended up discovering the auto completion function, which later I learned Emmet.
I had only found out how it worked with css classes, html elements and their IDs, but recently I started to wonder whether it could work also with the type attribute, so I went ahead and googled it.
I found this https://docs.emmet.io/cheat-sheet/
I was like:
2 -
1st day on the job and I am greeted with EOD, SIT, DEV, UT, POC..
Someone give me an Cheat sheet of this shh...11 -
I just scroll past this question asking how to get good at Git commands (https://devrant.com/rants/9997784/...). Figured I'd share my thoughts as a separate rant cause it's a topic I've tinkered with a bit.
So, My initial engagement with git-related queries on StackOverflow dates back to around 2021.. Surprisingly, one of my short and straight-to-the-point replies got a hand full of attention. You can check it here: https://stackoverflow.com/a/...
Now, about mastering Git commands – from my own trial and error:
1). Instead of trying to cram everything into your big brain, scribble down notes. Trust me, it’s more practical. I kept a cheat sheet of sorts as notes on my PC, noting down the commands I used day in, day out. Super handy beyond just work stuff.
2). You gotta get what each command does, but you don't need to nail it all at once. Spend a day diving into the basic commands. Leave the trickier ones for later; they start making sense as you get more into it.
3). I had this aha moment when dealing with a merge mess using a GUI tool. Switched to the command line, and bam! It made way more sense. The command line's like a secret passage to really understanding Git.
So, if you're wondering how to tackle Git commands, my take is: *notes, *baby steps, and *lean into that command line magic. Mix them up your way and see what sticks for you!1 -
To me this is one of the most interesting topics. I always dream about creating the perfect programming class (not aimed at absolute beginners though, in the end there should be some usable software artifact), because I had to teach myself at least half of the skills I need everyday.
The goal of the class, which has at least to be a semester long, is to be able to create industry-ready software projects with a distributed architecture (i.e. client-server).
The important thing is to have a central theme over the whole class. Which means you should go through the software lifecycle at least once.
Let's say the class consists of 10 Units à ~3 hours (with breaks ofc) and takes place once a week, because that is the absolute minimum time to enable the students to do their homework.
1. Project setup, explanation of the whole toolchain. Init repositories, create SSH keys for github/bitbucket, git crash course (provide a cheat sheet).
Create a hello world web app with $framework. Run the web server, let the students poke around with it. Let them push their projects to their repositories.
The remainder of the lesson is for Q&A, technical problems and so on.
Homework: Read the docs of $framework. Do some commits, just alter the HTML & CSS a bit, give them your personal touch.
For the homework, provide a $chat channel/forum/mailing list or whatever for questions where not only the the teacher should help, but also the students help each other.
2. Setup of CI/Build automation. This is one of the hardest parts for the teacher/uni because the university must provide the necessary hardware for it, which costs money. But the students faces when they see that a push to master automatically triggers a build and deploys it to the right place where they can reach it from the web is priceless.
This is one recurring point over the whole course, as there will be more software artifacts beside the web app, which need to be added to the build process. I do not want to go deeper here, whether you use Jenkins, or Travis or whatev and Ansible or Puppet or whatev for automation. You probably have some docker container set up for this, because this is a very tedious task for initial setup, probably way out of proportion. But in the end there needs to be a running web service for every student which they can reach over a personal URL. Depending on the students interest on the topic it may be also better to setup this already before the first class starts and only introduce them to all the concepts in a theory block and do some more coding in the second half.
Homework: Use $framework to extend your web app. Make it a bit more user interactive with buttons, forms or the like. As we still have no backend here, you can output to alert or something.
3. Create a minimal backend with $backendFramework. Only to have something which speaks with the frontend so you can create API calls going back and forth. Also create a DB, relational or not. Discuss DB schema/model and answer student questions.
Homework: Create a form which gets transformed into JSON and sent to the backend, backend stores the user information in the DB and should also provide a query to view the entry.
4. Introduce mobile apps. As it would probably too much to introduce them both to iOS and Android, something like React Native (or whatever the most popular platform-agnostic framework is then) may come in handy. Do the same as with the minimal web app and add the build artifacts to CI. Also talk about getting software to the app/play store (a common question) and signing apps.
Homework: Use the view API call from the backend to show the data on the mobile. Play around with the mobile project to display it in a nice way.
5. Introduction to refactoring (yes, really), if we are really talking about JS here, mention things like typescript, flow, elm, reason and everything with types which compiles to JS. Types make it so much easier to refactor growing codebases and imho everybody should use it.
Flowtype would make it probably easier to get gradually introduced in the already existing codebase (and it plays nice with react native) but I want to be abstract here, so that is just a suggestion (and 100% typed languages such as ELM or Reason have so much nicer errors).
Also discuss other helpful tools like linters, formatters.
Homework: Introduce types to all your API calls and some important functions.
6. Introduction to (unit) tests. Similar as above.
Homework: Write a unit test for your form.
(TBC)4 -
Perhaps as a tip for the junior devs out there, here's what I learned about programming skills on the job:
You know those heavy classes back in college that taught you all about Data Structures? Some devs may argue that you just need to know how to code and you don't need to know fancy Data Structures or Big o notation theory, but in the real world we use them all the time, especially for important projects.
All those principles about Sets, (Linked) lists, map, filter, reduce, union, intersection, symmetric difference, Big O Notation... They matter and are used to solve problems. I used to think I could just coast by without being versed in them.. Soon, mathematics and Big o notation came back to bite me.
Three example projects I worked in where this mattered:
- Massive data collection and processing in legacy Java (clients want their data fast, so better think about the performance implications of CRUD into Collections)
- ReactJS (oh yes, maps and filters are used a lot...)
- Massive data collection in C# where data manipulation results are crucial (union, intersection, symmetric difference,...)
Overall: speed and quality mattered (better know your Big o notation or use a cheat sheet, though I prefer the first)
Yes, the approach can be optimized here, but often we're tied to client constraints, with some room if we're lucky.
I'm glad I learned this lesson. I would rather have skills in my head and in memory than having to look up things and try to understand them all the time.5 -
How do you decide whether or not a program should be written to solve a problem or do some work?
Related to: https://devrant.com/rants/952746/...1 -
Wallpaper idea for my phone:
Create a stylish cheat sheet for e.g. git, made for mobile screen size.1 -
Was helping a friend fixing apache url redirects he says I've got cent os i was a bit nervous. The configs were in httpd.conf file but as soon as i try to edit i see there is no nano editor
But there was vi editor, now I'm on call helping this dev and googling vim cheat sheet 😂😂😂😂😂, i had no idea how to edit the file. Its not that hard though.4 -
big project at uni
group of 4
collectively decide to use LaTeX to write the documentation (like 50 pages or so)
me and one team memeber (bob) had TeX experience, and decided to write a cheat sheet for the others
bob says he'll make it
fast forward a few days
bob commits and pushes a docx file called "LaTeX Cheat Sheet.docx"
... que?2 -
Javascript - VS code
Python - VS code (linters sometimes show weird errors)
Dart/Flutter - VS code
Debugging qa instance via eb ssh - Vim with vim cheat sheet opened in browser tab -
You gotta love the actual useful stuff from XKCD.
Sometimes they apply extreme seriousness to some really unimportant stuff, like the tik-tak-toe cheat sheet.
At other opportunities, they hide some jokes completely serious looking stuff, like in 1688 the map identification chart. -
You know your cmdline utility sucks when you have to publish a cheat sheet yourself, too, along the manual.
I'm looking at you, Broadcom, and that horrible MegaCLI raid management utility. Storcli is superior.
https://broadcom.com/support/...
Top Tags
Weekly Rant
View