Practicing Elixir or any programming language
ericdouglas.github.io
ericdouglas.github.io
This is probably why I wasn't very good at picking up musical instruments. I was never satisfied learning at a slow pace and only being able to play "twinkle twinkle little star". Programming is perfect for me because you can build things before you really know what you are doing.
At some point in my career i became a team lead and that's where this difference became obvious. It took me a long time to adapt to the fact that everyone but me on the team learned by doing
Another interesting thing is how people forget their path to personal journey regarding learning. "I did `y`, but you should do `x` because now that I look back I should have done `x`." "But, but, you did `y`! "Yes, but `x` is the way to go."
You mentioned musical instruments: great topic. The very best musicians have always been around music, sometimes not even being able to read music. There is no clear path, the only clear thing about this is the time + effort regarding learning something well: just have to put in the time.
Not sure how you meant this to be understood, but a 3 year old definitely knows that there are different word classes that behave differently. They don't know that they're called verbs, nouns, adjectives, etc. but they do correctly (to a large enough extent) use grammar applying specifically to the different word classes.
With Ruby, I actually learned Rails first, and built a few apps with it (one of which is in production and going well). Then I went back and took the approach in this article to learn Ruby better. I still wouldn't call myself an idiomatic Ruby programmer, but I know enough to do any task I'm faced with without writing complete rubbish.
With the little Elixir I've done I took the same approach: dived in with Phoenix and started porting one service from a large, complex API from Scala to Phoenix. I picked up some Elixir on the way, and later took some more time to look at Elixir, the language.
Building by doing is great. It gives you motivation and concrete rewards, which keep you inspired to learn more.
The big point should be: do some practical stuff to keep you motivated while you are learning!
To practice the language specifically though, coding challenges are pretty effective, funny and more focused IMO
pass one for me is usually "read all the books that are needed to cover the main parts of the language, toolchain, frameworks, idioms, etc and make sure to type in the code as you go." for elixir this means all the pragprog books and probably one book on OTP/beam.
second pass is once that surface level knowledge has been exposed and digested immediately start trying to solve real problems with the thing, using said books and code written above, in addition to language docs, as a primary reference, the internet (stack overflow, etc) as a secondary reference only when absolutely necessary.
if you don't have the first part of dedicated learning and wide exposure (without a motivating problem per se) you inevitably end up doing the lazily evaluated "stack overflow driven development" since you haven't been exposed to the breadth of the language, frameworks, etc systematically. in other words, you don't know what you don't know. the first part also sets you up to have some working examples you built yourself (with the help of books and documentation) as handy references that you are comfortable with since you've been in that code.
if you don't have the second part of solving a real problem you never actually form the skills that come from applying the tool to a real problem with no hand holding.
i think academic algorithmic problems are kind of the worst of both worlds. they don't really give you a systematic way of being exposed to the APIs and language quickly, and they also aren't real motivating problems so you end up probably only really learning a narrow scope of things that are practically useful for building stuff.
Totally agree. I'm doing exactly this. But instead of only read books and type the code, I'm also after each section of the resource (doc || book), practicing code challenges :)
You solve a short problem, and then immediately see how other people solved it. I'll frequently write something and then see a solution that uses a library function I wasn't aware of, or a solution that's similar but better follows the language conventions.
It's really helpful to solve something short and get immediate feedback on it. You aren't learning how to write big programs with the language, but it's still useful at first.
And the first language I learned was... well BASIC... but it was on the VIC-20 & later C-64; but that still required a translation as the PDP-11 BASIC was rather different that was was on the Commodore machines.
You mentioned tests: on exercism you don't write unit tests by yourself, the tests are only for you to check your solution. It certainly helps to see how tests can be written in any language, but you aren't forced into a strict TDD style.
The best feature on exercism for me is to be able to see the other solutions and learn from them.
One thing I like to have to write tests is actually practicing writing tests :)
Follow some of the top-code-golfers, get all the tests passing, and then marvel at how concise other people were able to make their solutions. Fun and educational.
Edit: bonus, got nerdsniped.. Clojure solution - https://gist.github.com/minikomi/4e42de3643118b5381c4d7e70a1...
I'm not an expert Alchemist by any means, but whenever I see a `cond`, I try to see if it can be refactored out using pattern matching (after I was picked up on the same thing during an interview!)
defp formatted_hour("AM", "12"), do: "00"
defp formatted_hour("AM", hours), do: hours
defp formatted_hour("PM", "12"), do: "12"
defp formatted_hour("PM", hours), do: 12 + String.to_integer(hours) defp formatted_hour("AM", hours), do: rem(hours, 12)
defp formatted_hour("PM", hours), do: 12 + formatted_hour("AM", hours) def convert(<<h::bytes-size(2)>> <> ":" <>
<<m::bytes-size(2)>> <> ":" <>
<<s::bytes-size(2)>> <> <<period::bytes-size(2)>>) do
"#{formatted_hour(h,period)}:#{m}:#{s}"
end
defp formatted_hour(hours,"PM"), do: "#{String.to_integer(hours) + 12}"
defp formatted_hour("12","AM"), do: "00"
defp formatted_hour(hours, "AM"), do: hours def convert("12:" <> <<m::bytes-size(2)>> <> ":" <> <<s::bytes-size(2)>> <> "AM") do
"00:#{m}:#{s}"
end
def convert(<<h::bytes-size(2)>> <> ":" <> <<m::bytes-size(2)>> <> ":" <> <<s::bytes-size(2)>> <> "PM") do
h = 12 + String.to_integer(h)
"#{h}:#{m}:#{s}"
end
def convert(<<h::bytes-size(2)>> <> ":" <> <<m::bytes-size(2)>> <> ":" <> <<s::bytes-size(2)>> <> "AM") do
"#{h}:#{m}:#{s}"
end
I'm wondering how our future-self would feel about such cleverness haha
"#{String.to_integer(hours) + 12}"
Where I'd want to stretch it is some data structure and algorithm exercises, maybe even some design patterns. I'd love to be able to have a common environment where I can start to learn any one of multiple languages using similar exercises.
when I thought I was too rusty on regex I went and tried to answer as many regex questions on stackoverflow
The great thing about stackoverflow is it presents real world problems that are often not straightforward. Even if you can't solve it, someone else more than likely will and you will have an "aha!"
Anyone familiar with hackerrank able to comment on that vs say project Euler?
Hacker Rank is best at teaching algorithms & problem solving. I did a couple the other day & at first I thought they looked difficult. After breaking them down & thinking about them, they surprisingly weren't all that hard.
I'm gonna try pointing to the relevant CSS, but be warned, I am not a CSS wizard. I am also probably not a smart man, posting about CSS on HN while not being a wizard.
The relevant classes seem to be .sidebar, .sidebar-toggle, .motion-element, and .posts-expand, the last of which seems to control the transforms and durations. This is where my knowledge breaks down, since I'm not sure how they .sidebar or .motion-element trigger .posts-expand or any of the other animation CSS. Hopefully someone can help fill in the rest! ¯\_(ツ)_/¯
I now can't be bothered to see what you have to say. It is not worth my while.
That said, 'has javascript' is a reasonable assumption for most websites these days. Most people outside the HackerNews echo chamber wouldn't dream of turning it off, but then I suppose this blog is aimed at the HackerNews audience (among others).
This is a theme from the Hexo platform I use.
I'll probably create a theme to address this and other issues.
> Because this kind of problem is an interesting way to put yourself searching all the API of the language in order to solve the challenge in the more elegant/concise way you currently can.
Bullcrap. APIs are either going to be irrelevant for solving an algorithm, or will simply do the job for you. "Implementing an algorithm" usually means writing it from scratch using simple data structures, primitives and basic flow control constructs.
But I believe that solving this kind of challenges forces one in a good way to know more about what the language has to offer, while keeping motivated to learn its constructs before being able to create real apps.
The goal is practicing a new language.
I think this kind of thing is more useful than hackerrank or euler-style problems, at least if you're learning a language in a paradigm you already know? If you can hack together a binary search in one functional language you can probably do it in another one pretty easily. Though might be more challenging moving from one paradigm to another.