Upon completion you will have a sane, productive Haskell environment adhering to best practices.
sudo apt-get install libtinfo-dev libghc-zlib-dev libghc-zlib-bindings-dev
When doing or learning pretty much anything, the strategy where you tackle the whole thing all at once, but starting with a rough outline and then incrementally revisiting everything to go into increasingly more detail, is often more effective than doing things perfectly little by little and missing the big picture. (pun intended)
Back in the days of dial up internet, which was very limited in speed and capacity compared to modern internet connections, images on a web page could take very long to load. There were different strategies for dealing with that problem, and if you look hard enough (pun intended again), they can reveal some things about how to do and learn stuff.
Tests that pass when something is actually broken, and fail when things actually do work, are worse than useless- they are positively harmful.
Let's say we've been tasked with returning 400 when GET /users/<userId> is called with a negative userId.
The requirement can be turned into a test that hits the endpoint with a negative userId and checks that a 400 is returned:
A lot of Kotlin features can be traced back to functional programming languages, eg
However, Kotlin is missing many incredibly useful data types that are ubiquitous in functional programming languages, eg Either, Try etc.
I've been in tech 10 years now, and it never ceases to amaze me how bad even professional techies are at asking for help or reporting a problem.
How many times have you reached out to someone, or been reached out by someone else, something like this? (to be clear, I'm guilty as charged of this)
"I can't do x"
"y is broken"
Noargsconstructors and setters are outdated, 90's style old school Java. They needlessly allow entire categories of defects that are easily avoided by using only allargsconstructors and no setters. Please stop writing code like that.
How many times have you come across (or written) code like this
public class User {
Traditionally, most Java apps are organized by layer, which needlessly encourages large, unwieldy "God classes" and spaghetti dependencies, where every class and package depends on every other across the system.
Instead, consider packaging by feature.
How many times have you come across classes like this
Anki is a great open source flashcard app that can be used to learn anything.
This Gist is a full end to end example of how to:
Semantic indenting can greatly increase readability and maintainability of code. It can even increase the quality of code! (eg by making excessive dependencies more obvious etc)
How many times have you come across code indented like this (ignore the code, it's just gibberish, focus on the indenting itself)
@Autowired
public FooService(FirstDependency first, SecondDependency second, ThirdDependency third,
If you've been exposed to lambdas (whether in Java or Kotlin), you already know at least the basics of what lambdas are, the syntax for using them, that they're more succinct than instantiating anonymous classes etc etc.
Rather than talking about that, I figured we would talk about functions and lambdas on a higher level.
I think most of us are familiar with map and, having used it quite a bit, have an intuitive understanding of what any given call to map will do.
Does anyone know a bit more about map, what it is and where it came from?