31 Days of Coding – spring challenge for R/Python programming skills improvement.

If you have ever tried to Google something like “What skills are necessary for a career in data science?”, you have probably been presented an extensive list of skills like statistics, mathematics, software development, machine learning, deep learning and many more. Each of those areas are disciplines in itself which may lead to a bit of overwhelming – what should I learn first? It’s so easy to get demotivated by the amount of learning. That’s exactly why I would add one more skill, just on the very first position of this list – motivation. Nobody ever talks about motivation in learning data science while without this, you’ll end up stopping halfway through and believing you cannot do this anymore.

Those who have been following me for a longer time should know that apart from this blog, I also run an Instagram account dedicated to the Polish data science enthusiasts (@datascientistdiaryPL). Over the last year, I have met many wonderful people there, who just as me are interested in the data topic. The idea of a larger interaction with this community, organizing some kind of a common initiative has been following me for a long time and… March turn out to be a right time!

Regardless of the type of activity (can be workout, playing video games, reading books, cooking or learning another language), I have always believed in the communities. Having similar freaks around you gives so much power and motivates you! You can share you reflections, ask questions, inspire from others. Why not to apply this or data science skills development? And without what we cannot develop ourselves in this direction? What’s the foundation? Programming skills!

“31 Days of Coding” challenge

The purpose of “31 Days of Coding” challenge was to gather people interested in data science or programming in general and help them to form a habit of a daily coding skills practice. When we challenge yourself, we often lose initial motivation and get discouraged after a few days and give up easily (everyone who has ever created New Year’s resolutions should know this). On the other hand, by taking part in a common challenge, even if you’re not having a good day, you don’t want to be worse than others! They inspire you to overcome procrastination. And you know what? Thanks to our spring challenge, I could test this hypothesis and it really works!

I have chosen coding skills improvement for our first topic. Every day of March I have promised to publish another problem to be solved by the participants. They could use R, Python or any other programming language. It wasn’t necessary to sign up anywhere, join any closed groups – all you needed was to follow my Instagram account and check out daily challenges there.

The rules of “31 Days of Coding” challenge

To fully participate in the challenge, participants were to share their solutions on their Instagram stories. To be honest, I had doubts whether they would want to participate such way but I have took this risk and… got positively surprised! So many wonderful people who not only have participated in the challenge fully from the first till the last day but also shared their code explainations and educated others! We have started from a very basic ground and scaled it according to participants level of experience.

Are you totally new to programming? Then solve the tasks using easiest possible way. More advanced? What if instead of loops you’ve challenge yourself with some oneliners in Python? Maybe instead of using inbuilt function in R/Python, you’ll try to find more complex solution? How about adding some unit tests? Or maybe something completely different – if you’re already an expert in R, you’ll challenge yourself with Python and compare both solutions? I feel that the second most important advantage of the “31 days of coding” challenge after the sense of a community was its scalability!

The excercises of “31 Days of Coding Challenge”

Although March is 31 days long, we have solved 23 excercises during the challenge. Why? Because I truly believe that to keep the motivation on the satisfying level, you need to dedicate some time to rest. So did we during the initiative. I have shared excercises from Monday till Friday, leaving weekends for other fun activities. 🙂

I have collected all solutions done in both R and Python and uploaded on my GitHub. Feel free to validate your answers with them.

Note! You’ll never learn programming just by reading someone’s code. Before you’ll investigate the answers, please try to solve below excercises on your own! Although “31 Days of Coding” challenge has already ended, you can still try solving below problems in your preferred time!

Day 1: Make a function lowercase that, given a string, returns the string, except in all lowercase letters.
def lowercase(string) <- ... #Python

lowercase <- function(string){ ... } #R


# Check: lowercase("123 CHECK!")
Day 2: Make a function switch_case that, given a string, returns the string with uppercase letters in lowercase and vice-versa. Include punction and other non-cased characters unchanged.
def switch_case(string) <- ... #Python

switch_case <- function(string){ ... } #R


# Check: switch_case("I love coding in Python/R!")
Day 3: Make a function reverse_string that, given a string returns that string in reverse.
def reverse_string(string) <- ... #Python

reverse_string <- function(string){ ... } #R


# Check: reverse_string("DataScientistDiary")
Day 4: Create gerund_infinitive function which will return the infinitive form of the input verb (e.g. doing -> to do). If the word doesn’t end with “ing”, return “This is not a gerund!”.

Note: Please bear in mind that English verbs have various exceptions when it comes to its conjugation.

def gerund_infinitive(verb) <- ... #Python

gerund_infinitive <- function(verb){ ... } #R


# Check: gerund_infinitive("doing")
# Check: gerund_infinitive("getting")
Day 5: REST
Day 6: REST
Day 7: Write a function named capital_indexes. The function takes a single parameter, which is a string. Your function should return a list of all the indexes in the string that have capital letters.
def capital_indexes(string) <- ... #Python

capital_indexes <- function(string){ ... } #R


# Check: capital_indexes("Data Scientist Diary")
Day 8: Create a womensday function which will ask user for his/her name. As the majority of Polish female names are ended with “a”, if it’s the last letter of user’s name, function should return the Women’s Day wishes. Otherwise, the function should proceed with another output (up to your creativity 🙂 ).

If you’re from different country, you can try to modify the excercise. Maybe female names in your language have another endings? Is it possible to create any kind of rule? If not, try to do the excercise for Polish names. If you’re a Pole, you can scale up the excercise and exclude a few male names exceptions ending with “a” letter. 🙂

def womensday() <- ... #Python

womensday <- function(){ ... } #R


# Check: womensday()
Day 9: Create a function named mid that takes a string as its parameter. Your function should extract and return the middle letter. If there is no middle letter, your function should return an empty string. For example mid(“abc”) should return “b” and mid (“aaaa”) should return “”.
def mid(string) <- ... #Python

mid <- function(string){ ... } #R


# Check: mid("DataScientistDiary")
Day 10: We’re celebrating Men’s Day today! Create your own creative funny male names (name + surname) generator!
def funny_name() <- ... #Python

funny_name <- function(){ ... } #R


# Check: funny_name()
Day 11: Two strings are anagrams if you can make one from another by just rearranging the letters. Write a function named is_anagram that takes two strings as its parameters. Your function should return True if the strings are anagrams and False otherwise.

Two strings are anagrams if you can make one from another by just rearranging the letters.

def is_anagram(word1, word2) <- ... #Python

is_anagram <- function(word1, word2){ ... } #R


# Check: is_anagram("typhoon", "opython")
Day 12: REST
Day 13: REST
Day 14: Define a function named largest_difference that takes a list of numbers as its only parameter. Your function should compute and return the difference between the largest and smallest number in the list.
def largest_difference(numbers) <- ... #Python

largest_difference <- function(numbers){ ... } #R


# Check: largest_difference([1, 2, 3, 5, 6])
Day 15: Write a function named add_dots that takes a string and adds “.” in between each letter.

For example, calling add_dots(“test”) should return the string “t.e.s.t”. Then, below the add_dots function, write another function named remove_dots that removes all dots from a string. For example, calling remove_dots(“t.e.s.t”) should return “test”.
If both functions are correct, calling remove_dots(add_dots(string)) should return back the original string for any string. You may assume that the input to add_dots does not itself contain any dots.

def add_dots(string) <- ... #Python

add_dots <- function(string){ ... } #R


# *Place for remove_dots(string) function*


# Check: remove_dots(add_dots("Hello"))
Day 16: Write a function named is_palindrome that takes a single string as its parameter. Your function should return True if the string is a palindrome, and False otherwise.

A palindrome is a word, number, phrase, or other sequence of characters which reads the same backward as forward, such as madam or racecar. To scale up, there are also numeric palindromes, including date/time stamps using short digits 11/11/11 11:11 and long digits 02/02/2020.

def is_palindrome(string) <- ... #Python

is_palindrome <- function(string){ ... } #R


# Check: is_palindrome("abba")
Day 17: Define a calculate_factorial function that will return the factorial for the given number.
def calculate_factorial() <- ... #Python

calculate_factorial <- function(){ ... } #R


# Check: calculate_factorial()
Day 18: Define a function named all_equal that takes a list and checks whether all elements in the list are the same.
def all_equal(list_of_nums) <- ... #Python

all_equal <- function(list_of_nums){ ... } #R


# Check: all_equal([1, 1, 1])
Day 19: REST
Day 20: REST
Day 21: Write a function move_zero to push all zeros to the end of a list.
def move_zero(num_list) <- ... #Python

move_zero <- function(num_list){ ... } #R


# Check: move_zero([0,2,3,4,6,7,10])
Day 22: Write a perfectly_balanced function which, having a string containing only the characters x and y, check that the number of characters x and y are the same.
def perfectly_balanced(string) <- ... #Python
perfectly_balanced <- function(string){...} #R

# Check: perfectly_balanced("xxyy")
Day 23: Write a function is_ugly to check whether a given number is an ugly number.

Ugly numbers are positive numbers whose only prime factors are 2, 3 or 5. The sequence 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, … shows the first 10 ugly numbers.

Note: 1 is typically treated as an ugly number.

def is_ugly(number) <- ... #Python

is_ugly <- function(number){ ... } #R


# Check: is_ugly()
Day 24: Write a function is_geometric to check if a sequence of numbers is a geometric progression or not.
def is_geometric(numbers) <- ... #Python

is_geometric <- function(numbers){ ... } #R


# Check: is_geometric([2, 6, 18, 54])
Day 25: Write a function to display the Fibonacci sequence up to n-th term.
def fibonacci_n(n) <- ... #Python

fibonacci_n <- function(n){ ... } #R


# Check: fibonacci_n(11)
Day 26: REST
Day 27: REST
Day 28: Write a function digit_adder which will take a number from the user, transform each of its digits to one digit larger, and eventually return a new number. For example, 998 becomes 10109.
def digit_adder(number) <- ... #Python

digit_adder <- function(number){ ... } #R


# Check: digit_adder(101112)
Day 29: Write an additive_persistence function that returns the number of loops it needs to do to sum the digits of a user-specified number to a single digit number. Examples: 13 -> 1, 1234 -> 2, 199 -> 3.
def additive_persistence(number) <- ... #Python

additive_persistence <- function(number){ ... } #R


# Check: additive_persistence(199)
Day 30: Given two Roman numerals, return whether the first one is less than the second one.

For the purpose of today’s challenge, a Roman numeral is a non-empty string of the characters MDCLXV, and I, each of which has the value 1000, 500, 100, 50, 10, 5, and 1. The characters are arranged in descending order, and the total value of the numeral is the sum of the values of its characters. For example, the numeral MDCCXXVIIII has the value 1000 + 500 + 2×100 + 2×10 + 5 + 4×1 = 1729.

This challenge uses only additive notation for roman numerals. There’s also subtractive notation, where 9 would be written as IX. You don’t need to handle subtractive notation (but you can if you want to, as an optional bonus).

def rom_num_compare(num1, num2) <- ... #Python

rom_num_compare <- function(num1, num2){ ... } #R


# Check: rom_num_compare("MDCLXV", "MDCLXVI")
Day 31: Write the function count_ones which, after receiving the number n from the user, will determine how many times “1” will appear if you print all the numbers from 1 to n inclusive.
def count_ones(number) <- ... #Python

count_ones <- function(number){ ... } #R


# Check: count_ones(101112)

My reflections

I need to admit that despite the fact of how much preparations from my side required the challenge, I haven’t managed to forsee some things! Although I consider the initiative successful and received a lot of positive feedback, I have collected some learnings to apply in future and I will share all of them with you below in case of you’d like to organize similar initiative for your community. 🙂

What I’ve learnt

  • Experiment less during the challenge – stick to the agenda you’ve prepared in advance! Being flexible is an advantage but I think I have modified my challenge with ad hoc ideas too much and then needed to race against the time. 🙂
  • It would be worth to spend more time thinking about scalability of the excercises, collect all ideas for people to apply on various levels of experience – so many ideas have come to me during the ongoing initiative while I had not that much time as expected!
  • It would be great to include unit testing in the challenge! Maybe someone here grabs the idea and organizes a challenge directly in this domain? 🙂
  • Next time I should allocate more time to be active on Instagram stories – people really follow them and it would make a challenge more complete to share more tips & tricks there.
  • It’s impossible to plan everything 100% accurately! One month is a long period of time and it can turn out that in fact you have less time daily than expected to dedicate due to other duties. Although I regret that I wasn’t as active every day as I could, I don’t blame myself – life is life. I am happy that so many people supported me on their stories sharing their reflections and ideas. 🙂

Summary

Summing everything up, I have learnt a little bit about online initiatives facilitation and Instagram community. I am so happy I have organized the challenge and would love to repeat similar initiative in the future with all the lessons learnt. Maybe one month is too long? Maybe it would be worth to focus more on the shorter period of time, less tasks but better planned and described? What do you think? And what’s more important, what kind of challenge would you like to participate in now?

Please let me know in comments!

Leave a Reply

Your email address will not be published.