Also, you can contribute to open source.
Btw, this project I'm contributing to called AudioKit (if you are interested in audio stuff on Apple hw, you should definitely check it out) is looking for contributors
Also pairing with someone who's more experienced than you.
- Prefer `reduce` over `inject`.
I haven't seen any other evidence to show reduce is more performance friendly.
I prefer `reduce` too, because it feels conceptually easier to understand (similarly `foldl`, though Ruby doesn't have that).
The first problem has a clear improvement.
I just checked ruby doc and 'reduce' and 'inject' seem to be synonyms, as far as I can tell.
> "#{x}#{input.split('').count(x)}"
Just because Ruby apparently allows you to do that much in a formatting directive doesn't mean you should.
1. Write a blog post about your experience with X. Your description shall not be complete nor correct.
2. Wrap it around with a thesis on a random topic, which is semi-related to your experience, and which is by no means proven by your description.
3. ??
4. profit!
William has looked back after 2 years learning. He's blown away and is showing those that are slogging it out, 2 years away from that point.
The author will learn that, actually, you can do this every 1 - 2 years and still get blown away. Even more shocking is looking at that newbie code at 4 years in.
Fact is there is clear improvement. He's on the right trajectory. He's just in the stage where you feel unstoppable and perhaps hasn't yet been humbled by a few bad projects.
He should be applauded and welcomed. He has put in the time, improved significantly in 2 years and is on the path away from mediocrity.
In the end, many programmers stop learning after Uni or at least outside of formal training. We are, here, part of a pack that practices continuous skill improvement out of love for our craft and it looks like we have a new member.
To the author, keep at it mate - great progress!
For the LCM example, the second solution doesn't show any understanding of the underlying problem. The point of project Euler is to think about algorithms -- not to take advantage of "batteries included" features of programming language standard libraries.
For the duplicate counting problem, while the second answer is shorter, it's a bad solution. Just a few of the problems: it calls `split` many times instead of once; `count` can be called directly on a string; `chars` is the right way to get the characters of a string in Ruby; and finally the problem can be solved in 1-2 passes over the data using something like Ruby's `Enumerable#group_by` or Python's `itertools.groupby` rather than in a number of passes proportional to the length of the data -- O(n) rather than O(n^2).
1) The popup at the bottom saying "Sign Up Now to Receive a Free Developer Career Cheat Sheet plus a Free Course to Help Get that First Coding Job! Let's make that breakthrough together".
and
2) Zero to Launch is on his calendar.
The author of this post has paid thousands of dollars to learn how to market and sell a course on how to get a programming job.
Am I misunderstanding the problem here? In the context of compression why would it just be about counting letters? Why wouldn't you just use a hash of character counts if that is all you care about? Don't you want to maintain the form of the string also so you can unpack the original value?
This is somewhat more difficult to program, but definitely the more efficient way of doing it.
The second are more ruby/functional lang specific.
I mean, if the tests pass.. amirite?
