Also, well, I mean... If there's all that time/effort involved... Just get yourself some tea, coffee, doodle on some piece of paper, do some push-ups, some yoga, prey, meditate, breathe and then... Code, lol!
So, actually, on the museum's ticketing site they say that the internet tickets are sold out, but if you actually get there, there's a limited amount of tickets that are sold each day (because not everyone uses the internet) : "Merci de noter que des places pour la visite le jour même sont en vente chaque jour directement à l'accueil de l'exposition, dans la limite des places disponibles.".
Yes, you can. It has to be where there is templating language of course (you cannot put a breakpoint on a arbitrary div for example), you can also debug the rendering of the template through Pycharm if you want to in order to have a full stack debug, but I'm used to doing that using the browser developer tools.
Well, as previously stated in Pycharm and Visual Studio (not tested on others) there is. If I remember correctly, both will install their requirements remotely and then allow you to do so. However, I would not recommend it:
- you will probably forget to clean up after the fact leaving you with both performance and security problems
- you should never debug in production, use something like Sentry instead also, better to replicate the production environment in a sandbox (either on your machine using Vagrant or Docker, etc. if feasible) or in the cloud by taking a snapshot of your production environment and using it as a sandbox to debug (and then of course destroying it after use).
Not trolling, but what's wrong with visual remote debugging using either Pycharm or Visual Studio? I find it much more rich information wise than using pdb.
Although it goes against certain opinions AND if you set a norm for their use, signals are the way to go.
You can either decide that signals code will live in the app where the objects reside or the app of the target objects and that's it. A built-in and simple interface between objects.
I've decided to play it simple albeit "old school" (because Docker seemed to add its own set of headaches - also not every project needs to do micro services or work with clusters or scale):
- Vagrant (so you don't have to worry about runtime executables) with the stack matching that of the production server (you can even ask ops to provide you with the provisioning script and remove the parts that you don't need - otherwise learning to provision your dev. VMs won't hurt you)
- Virtualenv
- pip
Then simply point your IDE (I only use Vim under duress) to the remote Python interpreter (the one you installed in the Vagrant VM).
It does add processing overhead but it worked with my 2010 MacBook Pro until it died and still works (only ten times faster) with the 2016 model. Your only limitation would be the RAM (I would recommend at least 8GB and if you plan to run multiple machines communicating together as much as you can afford - I do believe that Docker has less overhead, but again, for my use, not needed).
The best practice is what works for you, not the latest trend.
Does Duckduckgo makes a browser now? Or do you mean that like most of non geeky folks you access websites not by typing an url in the address bar of a browser but instead by going through a search engine (in this instance Duckduckgo)?