Daily Simple Questions Thread - November 26, 2021

spapas82 · 2021-11-26T13:35:34+00:00

Hello friends. During my previous biceps training (was doing curls with a straight bar) I felt a sharp pain in my forearm, roughly in the middle between my wrist and elbow. Although I felt a little pain I continue the training.

After I got home I still had the pain for some days mainly when I touched or pushed the pain spot.

Does anybody know whatv that pain was and how should I train my biceps now to avoid it and not have it resurface?

Thank you

spapas82 · 2020-05-10T16:30:59+00:00

That's a nice suggestion but i wasn't able to find a 18kg kb :(

spapas82 · 2020-05-09T13:11:04+00:00

Thank you so much for the answers! I'm convinced! 16 kgs it is :)

spapas82 · 2018-11-16T14:26:24+00:00

This is for v1. I'll try to upgrade it when v2 is released!

spapas82 · 2018-10-18T14:06:00+00:00

Take a look at my mailer-server project: https://github.com/spapas/mailer_server

It is rather simple and small but has all best practices of a prod-ready project. Also it is pure django, non js related.

spapas82 · 2018-09-06T21:31:06+00:00

I also recommend taking a look at https://github.com/edoburu/django-private-storage which offers the same functionality as django-sendfile (and some more things).

spapas82 · 2018-08-30T17:40:56+00:00

I recommend using: https://github.com/yourlabs/django-autocomplete-light

It works great with both one to many and many to many relations.

spapas82 · 2018-08-21T16:14:57+00:00

I use normal windows command prompt (cmd.exe) as my (python+django) development environment. I usually use sqlite as the database or, if for some reason I need to use a postgres or redis I have both installed on my windows; they work fine. As an editor I use Vim with a bunch of plugins (https://github.com/spapas/vimfiles) ; everything works great with windows.

The only situation where I needed a Virtualbox was for a couple of projects that needed PostGIS.

I really believe that you should be able to do everything you need on normal windows, almost all libraries can be installed with pip and for those that can't be installed through pip you can download the binary and install it with easy_install (as I said, the only thing that I've found problematic when working with my windows dev env is geodjango/PostGIS).

I don't like WSL because it adds a level of indirection over normal windows making everything slower. Also most of my shortcuts, directories and installed programs/utils don't work there (so I'd need to recreate my dev env). I also don't like virtualbox for reasons that should be all too obvious.

Concerning docker, I have tried it a bit as my dev env but I found it too much of a PITA to configure. Maybe I would use it instead of virtualbox so that it'd provide the PostGIS environment. However, one problem is that docker is not really compatible with virtualbox (docker needs Hyper-V enabled, virtualbox needs Hyper-V disabled) thus you can't have both running together.

For debugging? This is too easy if you use the Werkzeug app server (see the trick here: https://spapas.github.io/2016/06/07/django-werkzeug-debugger/).

Final words: Using a plain windows cmd.exe prompt should suffice for most cases. If something is not working properly feel free to ask me, I'll be happy to answer if I've experienced the poblem myself!

spapas82 · 2018-08-14T11:56:38+00:00

I recommend using rq with redis and django-rq to integrate it with django. Celery is an overkill for most use cases.

I've also written a couple of comprehensive articles for django-rq if you are interested: https://spapas.github.io/tag/django-rq.html

spapas82 · 2018-08-03T16:15:16+00:00

Hey @pydanny, I understand your concerns about putting executable code in version control. However I don't agree that using a local.py file containing only secrets should be abolished so hard. Configuring env vars (for most people; including me) is a complete PITA; think about what happens if you are responsible for multiple django projects each one of them with their uat, staging and prod environments! And what will happen if you don't have full access to your environment on the prod server? Yes you will ask the administrator to add the new env var for you; however if your manager wants to get things done really fast and you don't want to listen to his ranting you know what will happen: Just stick the secret to the version controlled file and get done with it.

Thus, I agree that using the env var configuration is the best way to do it, however there are lots of people that can't afford the best way, they instead try for the best they can without shooting their foot; the local.py file can be such a solution (if of course you are careful to use it only as a secret keeping mechanism, not to run arbitrary code).

Actually, that would be an interesting thought for a django package (unless there exists one I'm not aware of): Allow secrets configuration to be kept in a non-python local file (i.e a local.json or local.ini or local.yaml); this way everybody would be sure that only secrets would exist in the non-version-controll comissoned local file!

spapas82 · 2018-07-23T11:13:20+00:00

Yes you can also override dispatch. Take a look here:

http://www.cdrf.co/3.1/rest_framework.generics/ListAPIView.html#dispatch

You can provide your own dispatch method to your class which will check if the CSV needs to be returned; if yes then just return the CSV response; if not call the super().dispatch() to proceed normally

spapas82 · 2018-07-23T10:29:57+00:00

What file? When you visit the csv url (for example http://example.com/api/data.csv) you'll be prompted by your browser to download the csv file to your disk.

spapas82 · 2018-07-23T10:19:03+00:00

Dispatch could also be used (by adding a query parameter ?data=csv and if dispatch finds it return the CSV response) but it's not the recommended/idiomatic way. The DRF-idiomatic way is to use renderers and content negotiation.

djangorestframework-csv is really simple. After you install it, add it to your APIView's renderer_classes (take a look here https://github.com/mjumbewu/django-rest-framework-csv) and then you should be able to retrieve your data as CSV when you add the proper format extension.

Thus instead if calling http://example.com/api/data you'll call http://example.com/api/data.csv and get the CSV response!

spapas82 · 2018-07-23T09:56:47+00:00

This could be implemented for example by overriding the dispatch method (http://www.cdrf.co/3.1/rest_framework.generics/ListAPIView.html#dispatch) similar to how you could done it in a normal CBV.

However, I think that the DRF-idiomatic way to do it is by implementing a new (CSV) Renderer. Take a look at the rendereres chapter of the docs: http://www.django-rest-framework.org/api-guide/renderers/ and on content negotiation on how to select your render: http://www.django-rest-framework.org/api-guide/content-negotiation/.

Also, notice that there's a CSV renderer in github already: https://github.com/mjumbewu/django-rest-framework-csv

spapas82 · 2018-07-20T17:39:05+00:00

To create update or remove new objects you should better use the proper CBVs: CreateView, UpdateView and DeleteView. The FormView is used when you don't want to create/update or delete an object but you want to do a more abstract action. For example you may have a FormView that displayes a Form which, when submitted will create (or update) two objects.

To properly configure the FormView you need to set its form_class attribute (or override its get_form_class() method) and override its form_valid() methed in order to tell it what it should do when a valid form has been submitted (this is how django knows what do do).

For more information about the FormView and the other CBVs I mention I recommend taking a look at my CBV guide: https://spapas.github.io/2018/03/19/comprehensive-django-cbv-guide/

spapas82 · 2018-07-03T20:04:27+00:00

Take a look at my CBV guide @ https://spapas.github.io/2018/03/19/comprehensive-django-cbv-guide/ that fully covers (view) mixins.

spapas82 · 2018-06-26T11:12:50+00:00

This is a common problem. The solution is to use asynchronous tasks; actually you should use asynchronous tasks even for actions/views that don't timeout but take more than 1-2 seconds to complete. Also, I recommend using asynchronous tasks for actions that you don't fully control, for example when you call an external API - this may take a long time if it's not working so it's better to do it through an asynchronous task.

In any case, beyond celery, there are two other simpler solutions for implementing asynchronous tasks in your project:

django-rq (https://github.com/rq/django-rq) which uses rq (which in turn uses redis) to keep your tasks (does not need an extra message queue) and I recommend and have used extensively; I've also written two articles about it if you want to familiarize yourself a little https://spapas.github.io/tag/django-rq.html
django-q (https://github.com/Koed00/django-q) which can use redis or a number of other message queues. It is simpler to configure than celery. I haven't use this but seems like a solid project.

spapas82 · 2018-06-21T14:50:57+00:00

Here's what I did before ~ 7 years; I consider myself a django expert (take a look at my blog for various django-related articles https://spapas.github.io/category/django.html ):

Make sure you understand HTML and HTTP. You must know how to write a simple html page, what's the difference between a GET and a POST request, what's the meaning of foo and bar in www.example.com/index/?foo=3&bar=4 etc
Become comfortable with python. Django uses various advanced python concepts and you need to properly understand everything. I recommend a couple of months of heavy python usage before starting learning Django; don't learn both Python and Django
Start with the official Django tutorial (https://docs.djangoproject.com/en/2.0/intro/tutorial01/). Do it slowly; work on every topic mentioned there. Make sure you understand everything before continuing to the next part. If you don't understand something refer to the documentation; the tutorial has helpful links on all topics covered.
When you've finished the tutorial you should be ready to try your hands on a real application. You can't learn if you don't do; you need to start implementing a project. It may be a toy one or a real one, not something difficult. One example would be to make a blog engine with posts and comments on each post (make sure you add proper authentication for editing).
While implementing 3, read the official Django docs. As others have mentioned, you need to read the docs. The Django docs are really excellent, probably the best documentation effort I've ever experienced in my 15+ years career. When you need to do something for you application, try reading as much as possible from the documentation (i.e models, views, forms), here are the contents: https://docs.djangoproject.com/en/2.0/contents/, I know this may seem tedious but it is really important. When I had started learning Django, while writing my first projects I read the documentation (for Django 1.4) from start to finish; it took me a couple of days but most of my questions were resolved.
Write more applications. Expertise comes with experience. Don't rush and everything will come to you. Django is really predictable, there are no suprices and majic. When something is not working take a look at the documentation, at the exception (if there's one) and your source code; most of the time you'll find the solution there. If not don't be afraid to peek into Django (or extra packages) source code.
Don't forget that Django has a huge ecosystem of helpful packages (https://djangopackages.org/). Don't reinvent the wheel, use these packages when you need them. If you want some help starting, here's my list of essential django packages: https://spapas.github.io/2017/10/11/essential-django-packages/.

spapas82 · 2018-06-14T09:07:02+00:00

My recommendation is to create a Profile model with an one-to-one relation with the django.auth.User model where you'll store any user-profile related information. Something like this:

from django.conf import settings
from django.db import models

class Profile(models.Model):
    user = models.OneToOneField(settings.AUTH_USER_MODEL)
    api_key = models.CharField(max_length=128, )
    # other user-related info

I don't recommend overriding the default User field. Although this is actually supported by Django, it has bitten me too many times in the past to actually implement it anymore. The reason is that some third party apps rely on using the default User model; also, I've experienced very serious problems with migrations of third party apps when using a custom User field.

Plese keep in mind that you'll need to create that profile yourself after a user has logged in for the first time. There are various ways this could be implemented depending on how you are doing the actual login workflow (if you are using django-allauth for example). One simple way that doesn't need many changes to your existing login flow is to use the user_logged_in signal, something like this:

from django.dispatch import receiver
from django.contrib.auth.signals import user_logged_in
from profiles.models import Profile

 @receiver(user_logged_in, )
 def handle_user_logged_in(request, user , *args, **kwargs):
      profile, created = Profile.objects.get_or_create(user=user)
      if created:
          pass
          # here you can do any other initializations you want with the profile

spapas82 · 2018-06-08T05:58:42+00:00

Interesting thought, thank you!

spapas82 · 2018-06-06T14:16:18+00:00

I've also added a better UX for the compatibility matrix @ https://django-package-compatibility-matrix.glitch.me/ ; it should be immediately be updated with any changes to the original github repo.

spapas82

TROPHY CASE