Things i have become better at in 2018

It’s about 43 min left for 2018 to end in my timezone and i have no fancy plans.

So, here is an attempt to list down things i have learnt this year. There is no way i can list all the things, if i hadn’t been keeping track (which i haven’t).

  1. Django: I already was working with Django for 6 months in my previous job. Apart from that i had done a couple of projects in college. But, in this job, i think i have in depths with Django. I have also realised that although it makes it easier to ship products faster, it comes at a cost. Ex: The admin interface of django. It’s good for being a reflection of database and performing simple operations. The minute you want to do something even a little complex, it becomes really hard and makes ugly code.
  2. Debugger: Right now, i can’t believe that i wasn’t using the pdb since last 4 years. I used to rely on logging instead. The credit has to go to my Engineering Manager Manish . Writing code and debugging with him has helped me a become a lot better code in 2018.
  3. SQLI have gotten better at writing sql. Earlier, i never needed to think about it much. In all of the web applications i had built, including open source and at previous job, we always used an ORM. This year, we needed optimisations, raw sql queries for Metabase for which i wrote queries.
  4. Python: I have been writing python code since 2014, this is my language of preference. My learning of the standard library has grown this year.
  5. HTML/CSS/Javascript: I have a front end nano degree now ( \o/ ) . It took me a long time but, yes, as of December 2018 and by degree given to me by Udacity, I can totally pronounce (using Joey’s voice when he was marrying Chandler and Monica) myself:  A Full Stack Developer.
  6. Rabbitmq/Celery/Redis: I can say that i had some practice of this. I had already been using and the way i am using right now is same as before. Having said that, i did try to dig deep in Celery and i don’t think celery’s codebase is easy to mess with. (So is Django’s btw)
  7. AWS/EBS/: Towards the latter part of this year, i started using more of AWS console and EBS.

These were the broad categories of things i have gone better at. Actually, there is nothing new topic wise apart from EBS but, there are smaller details within each category that i didn’t know about.

Apart from all the progress that i have listed, there is a thing i haven’t done this year. I haven’t contributed to Open Source as much as i would have liked to. Actually, from the time i started contributing, this year i have contributed the least. I don’t think i have been able to give my 100% everyday which kills me sometimes. I know when i am not at my 100% and i know when i am. If i go by this logic, 2018 has been a crappy year.

Advertisements

Django’s transaction.on_commit

I am talking with Django’s 1.11 in mind.

Django provides a method using which you can execute a particular function when you are sure that a particular entry has made to the database, that’s transaction.on_commit.

There is also Django’s Post save signal. Both have their use cases. The difference between the two is that on_commit is executed when Django finally commits to the database and it’s only useful when you are inside a transaction. While, in case of post save signal, you are not even sure that the object you are currently saving will finally be committed to the database (if it’s inside a transaction block). Post save has it’s use case when you need to know the object which just got changed or got created since, you get boolean on whether it was updated or created and also the changed/created object itself.

How to work with transaction.on_commit?

When the code is running, you can register a function to be called, by calling

transaction.on_commit(my_fancy_function_to_be_called_on_commit).

Remember, you are trying to pass a function here and not the function’s returned value. What happens here is, Django adds the my_fancy_function_to_be_called_on_commit to a list of functions which it calls when it finally commits the ongoing transaction. There are few small things here:

  1. Since the transactions can be nested, when does django finally execute these functions?Django executes them after it is no longer inside an atomic block (wrapped in a transaction). If there is no transaction block and you are trying to register the function, it won’t get register rather get called instead. Here is the link to the source code:
    Registering and What happens on registering
    Things happening while executing the registered functions
  2. How do i pass arguments to the above functions?This is actually a basic python issue. You can wrap your function which has arguments inside a lambda expression or a normal function.

    transaction.on_commit(lambda: my_fancier_func_with_args(a, b))

     

  3. From where do we get this “transaction”?By importing:
    from django.db import transaction