These resources (articles, books, and videos) are useful when you're starting to learn the language, or when you're learning a specific part of the language. This an opinionated list, no doubt. I've compiled this list from writing and teaching Clojure over the last 10 years.
My answer to: https://www.reddit.com/r/Clojure/comments/pcwypb/us_engineers_love_to_say_the_right_tool_for_the/ which asked to know when and at what is Clojure "the right tool for the job"?
My take is that in general, the right tool for the job actually doesn't matter that much when it comes to programming language.
There are only a few cases where the options of tools that can do a sufficiently good job at the task become limited.
That's why they are called: General-purpose programming languages, because they can be used generally for most use cases without issues.
Let's look at some of the dimensions that make a difference and what I think of Clojure for them:
Current as of 9front-5966.df2c352ae695
This is a collection of notes on how to complete tasks I've found myself commonly performing while using 9front.
Note that most of what is here is straight from various parts of the 9front FQA, just ordered differently. If not from the FQA, I'll provide the source under the header for the section.
As I'm in the process of learning Plan 9/9front, feel free to comment with suggestions or corrections.
I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
| // Just before switching jobs: | |
| // Add one of these. | |
| // Preferably into the same commit where you do a large merge. | |
| // | |
| // This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
| // and then it quickly escalated into more and more evil suggestions. | |
| // I've tried to capture interesting suggestions here. | |
| // | |
| // Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
| // @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
| #!/usr/bin/osascript | |
| # | |
| # now_playing.osascript | |
| # | |
| # Osascript to fetch the meta data of the currently playing | |
| # track in Spotify. This works only on Mac OS X. | |
| tell application "System Events" | |
| set myList to (name of every process) | |
| end tell |
| Nitty Gritty Gameboy Cycle Timing | |
| --------------------------------- | |
| A document about the down and dirty timing of the Gameboy's video hardware. | |
| Written by: Kevin Horton | |
| Version: 0.01 (preliminary) | |
| My findings here are based on the original DMG, Super Gameboy, and GB |
Many programming languages, including Ruby, have native boolean (true and false) data types. In Ruby they're called true and false. In Python, for example, they're written as True and False. But oftentimes we want to use a non-boolean value (integers, strings, arrays, etc.) in a boolean context (if statement, &&, ||, etc.).
This outlines how this works in Ruby, with some basic examples from Python and JavaScript, too. The idea is much more general than any of these specific languages, though. It's really a question of how the people designing a programming language wants booleans and conditionals to work.
If you want to use or share this material, please see the license file, below.
| #Model | |
| @user.should have(1).error_on(:username) # Checks whether there is an error in username | |
| @user.errors[:username].should include("can't be blank") # check for the error message | |
| #Rendering | |
| response.should render_template(:index) | |
| #Redirecting | |
| response.should redirect_to(movies_path) |
